개요

영상 미러링 테스트 중 Delay Variation(Jitter) 문제가 발생하여 이를 측정하고 개선하기 위한 테스트 방법을 구현한 사례입니다.
기존에는 시계 영상을 사용해 비교했지만, 화면 변화가 큰 일반 영상에서는 분석이 어려웠습니다.
이를 해결하기 위해 각 프레임에 프레임 번호(Frame Number) 또는 타임스탬프를 삽입한 테스트 영상을 생성했습니다.

문제 상황

• 문제
  • 미러링 기능에서 Delay 변동폭(Variation, Jitter) 발생
  • 기존 방법: 시계 영상 기반 비교
  • 한계: 일반 영상에서는 화면 변화가 많아 정확한 분석 어려움
• 개선 방향
  • 영상 자체에 프레임 번호 또는 타임스탬프 삽입
  • 비교 시 육안 확인이 가능하고, 자동 분석에도 활용 가능
  • FFmpeg을 사용하면 간단하고 빠르게 처리 가능

해결 방안

• FFmpeg의 drawtext 필터를 이용하여 영상에 Frame Number 또는 Timestamp 삽입
• 입력 영상의 코덱을 분석하여 적절한 인코딩 코덱 자동 선택
• 원본 오디오 스트림은 그대로 복사하여 변환 속도 단축

FFmpeg 빌드 종류 비교

Tip:

• 일반 빌드는 안정성이 높아 서버 배포용으로 적합
• Axiom 빌드는 최신 하드웨어와 함께 사용 시 속도 이점 큼
• AV1, HEVC 등 고효율 코덱 테스트 시 Axiom이 유리

스크립트 주요 기능

1. 인자 처리

• --input: 입력 영상 경로 (기본값: input.mp4)
• --output: 출력 영상 경로 (기본값: output_with_frame.mp4)
• --fontsize: 글자 크기 (기본값: 120)
• --mode: 표시 방식 (frame → 프레임 번호, timestamp → 시간 정보)

2. 비디오 코덱 확인

def get_video_codec(input_path):
    ffprobe로 입력 영상의 codec_name 추출

3. 코덱 매핑

def map_codec_to_encoder(codec_name):
    h264 → libx264, hevc/h265 → libx265, vp9 → libvpx-vp9, av1 → libaom-av1

4. 재인코딩 & drawtext 적용

ffmpeg -i input.mp4 \
  -vf "drawtext=text='Frame\: %{n}':x=10:y=10:fontsize=120:fontcolor=white:box=1:boxcolor=black@0.5" \
  -c:v libx264 -preset fast -crf 23 -c:a copy output.mp4

사용 예시

python add_timestamp_3.py \
  --input test.mp4 \
  --output test_with_frame.mp4 \
  --fontsize 120 \
  --mode frame

타임스탬프 모드:

python add_timestamp_3.py \
  --input test.mp4 \
  --output test_with_time.mp4 \
  --fontsize 100 \
  --mode timestamp

기대 효과

• Delay/Jitter 측정을 위한 정량적 비교 가능
• 일반 영상에서도 프레임 단위 분석 용이
• FFmpeg 활용으로 다양한 코덱 지원 & 빠른 처리
• Axiom 빌드 사용 시 하드웨어 가속을 통한 성능 향상

문제 정의

Streaming은 서버에서 동영상을 가져와서 단말에서 재생하는 기능이다. 컨텐츠가 서버 측에 있기 때문에 사용자에게 다양한 경험을 제공하기 어렵다. YouTube가 Streaming을 활용하는 대표적인 서비스이다.

YouTube는 아래 그림과 같이 Thumbnail을 보여 주면서 Seek을 하는 기능을 제공한다. 이러한 서비스는 어떻게 구현하는가? 실재 구현까지는 안해보더라도 어떠한 방법을 활용하는지 알아보자.

첫 번째 Prompting

"YouTube의 영상에서 아래 영상 thumbnail을 보여 주면서 seek을 하는 기능을 구현하려고 해. 우리 서버는 HLS를 지원해. Client는 Android에서 동작하는 앱이다. 이 부분을 유사하게 구현하려고 하면 어떻게 해야할지 가이드 해줘."

제공 답변

기본 개념 정리

YouTube에서 구현한 썸네일 프리뷰는 사용자가 seek bar를 움직일 때 해당 시점의 영상을 정적인 이미지로 보여주는 기능입니다. 이를 위해 필요한 요소는 다음과 같습니다:

• 각 시점(예: 매 5초)의 썸네일 이미지
• 썸네일들의 인덱스 정보 (타임코드 → 썸네일 매핑)
• UI에서 시킹 중일 때 보여줄 썸네일 뷰

서버 측 구현 (HLS 기반)

썸네일 생성

• ffmpeg을 사용해 주기적인 썸네일 이미지 (예: 1초, 5초 간격) 를 생성할 수 있습니다.
• 개별 이미지로 저장하거나, YouTube처럼 sprite 이미지로 만들어 저장합니다. (하나의 큰 이미지에 여러 프레임을 배치)

ffmpeg -i input.mp4 -vf fps=1,scale=160:-1 thumbnail_%04d.jpg

또는 sprite 형태:

ffmpeg -i input.mp4 -vf "fps=1,scale=160:-1,tile=10x10" sprite.jpg

WebVTT or JSON으로 인덱스 매핑

• YouTube는 WebVTT 파일로 썸네일 위치를 설명합니다.
  예: thumbnails.vtt

WEBVTT  00:00.000 --> 00:05.000 sprite.jpg#xywh=0,0,160,90  00:05.000 --> 00:10.000 sprite.jpg#xywh=160,0,160,90

또는 JSON 예시:

{   "0": { "url": "sprite.jpg", "x": 0, "y": 0, "w": 160, "h": 90 },   "5": { "url": "sprite.jpg", "x": 160, "y": 0, "w": 160, "h": 90 } }

서버는 썸네일 이미지 및 인덱스 파일(JSON 또는 VTT)을 static으로 서비스합니다.

Android Client 측 구현

SeekBar 커스터마이징

• SeekBar.OnSeekBarChangeListener로 사용자의 seek 위치를 감지하고,
• overlay UI에 썸네일 이미지를 표시합니다.

썸네일 표시 UI

• FrameLayout 위에 ImageView를 띄워서 seek 중일 때 표시
• 썸네일 좌표(x, y, width, height)를 통해 sprite 이미지에서 해당 부분만 crop 표시
  • Glide 혹은 Picasso로 sprite 이미지를 로드한 뒤 BitmapRegionDecoder 사용

VTT 또는 JSON 파싱

• VTT 파일을 다운로드 받아 각 타임코드 → xywh 정보를 파싱하거나,
• JSON 파일을 다운로드 후 Map 형태로 로딩

전체 동작 흐름

1. 앱 실행 시 영상 URL과 함께 썸네일 sprite 이미지와 인덱스 파일(VTT 또는 JSON)도 다운로드
2. 사용자가 seekBar를 움직이면 현재 seek 위치 기반으로 보여줄 썸네일 이미지 좌표 계산
3. sprite 이미지에서 해당 영역을 잘라서 썸네일 이미지로 표시

기술 스택 요약

참고 자료

• WebVTT spec for thumbnails
• YouTube thumbnail implementation via VTT (StackOverflow)
• ffmpeg sprites

네트워크 애플리케이션 성능은 Latency(지연 시간), Bandwidth(대역폭), 그리고 모바일 기기에서의 전력 소모라는 세 가지 주요 요소로 나눌 수 있다. HTTP/2와 HTTP/3는 기존 HTTP/1.1의 한계를 극복하기 위해 설계되었으며, 각 프로토콜이 이러한 성능 측면에서 어떻게 개선되었는지 살펴보자.

HTTP/2: Multiplexing과 Header 압축을 통한 효율성[1]

• Multiplexing: HTTP/1.1은 하나의 연결에서 하나의 요청-응답만 처리할 수 있는 문제점(Head-of-Line Blocking)을 가지고 있다. HTTP/2는 단일 TCP 연결에서 여러 요청과 응답을 동시에 처리할 수 있도록 개선하여 Latency를 크게 줄였다.
• Header Compression: HTTP/2는 HPACK을 사용하여 헤더를 압축한다. 이는 반복적인 헤더 전송에 소요되는 Bandwidth를 절약하는 데 유리하다.
• Push Promise: 서버에서 클라이언트가 요청하지 않은 리소스를 미리 전송할 수 있는 HTTP/2의 기능으로 페이지 로드 속도를 향상시킨다.

HTTP/3: UDP 기반의 QUIC 프로토콜로 Latency 최적화 [3]

• UDP 기반: HTTP/3는 TCP 대신 QUIC(Quick UDP Internet Connections) 프로토콜을 기반으로 설계되었습니다. QUIC는 연결 설정 속도가 빠르고 패킷 손실에도 연결이 유지되므로 Latency를 최소화한다.
• TLS 통합: QUIC는 TLS 1.3을 통합하여 보안을 강화하면서도 연결 수립 단계를 줄여 초기 Latency를 줄인다.
• 멀티플렉싱 개선: HTTP/2는 단일 TCP 연결에서 발생하는 Head-of-Line Blocking 문제를 해결했지만, TCP 수준에서 여전히 동일한 문제가 발생했다. HTTP/3는 QUIC을 통해 이 문제를 해결하였다.
• 모바일 기기 친화적: 모바일 환경에서 네트워크 변경(예: Wi-Fi에서 LTE로 전환) 시 연결을 유지할 수 있어 전력 소모와 재연결 Latency가 줄어든다.

성능 측면 분석

1. Latency
   • HTTP/2: TCP의 3-way handshake로 인한 초기 연결 지연이 존재.
   • HTTP/3: QUIC의 0-RTT Handshake로 초기 연결 Latency 최소화.
2. Bandwidth
   • HTTP/2: 데이터 압축 및 멀티플렉싱으로 대역폭 효율 증가.
   • HTTP/3: 패킷 재전송 감소와 멀티플렉싱으로 Bandwidth 활용 최적화.
3. 전력 소모
   • HTTP/2: 다수의 연결 유지 시 전력 소모가 증가 가능.
   • HTTP/3: 네트워크 변화 시 연결을 유지하므로 전력 소모 감소.

모바일 환경에서의 성능 최적화

• HTTP/2와 HTTP/3 모두 모바일 친화적인 특성을 가지지만, HTTP/3는 특히 고속 네트워크 변경 및 불안정한 환경에서 강력한 성능을 제공한다.
• QUIC의 효율성 덕분에 스트리밍 및 게임 같은 애플리케이션에서 HTTP/3 채택이 증가하고 있다.

참고자료

[1] IETF RFC 7540, https://datatracker.ietf.org/doc/html/rfc7540

[2] IETF RFC 9000, https://datatracker.ietf.org/doc/html/rfc9000

웹을 이루는 수많은 기술 중에서 진짜 뼈대라 할 수 있는 것이 바로 HTTP이다. 브라우저에서 URL을 입력하면 그 뒤에서 움직이는 가장 핵심적인 프로토콜이 이 HTTP이다. HTTP가 어떻게 발전해 왔는지, 왜 계속 진화해야 했는지를 살펴보자.

1. HTTP 0.9: 한 줄로 시작된 혁명

1991년 팀 버너스 리가 만든 HTTP 0.9는 믿기 어려울 만큼 단순했다.

• 클라이언트는 단 한 줄짜리 요청(GET /index.html)을 보냄
• 서버는 HTML 문서만 반환
• 헤더도 없고, 연결도 요청마다 끊김

지금 관점에선 너무 부족해 보이지만, 이 단순함 덕분에 웹이 빠르게 확산될 수 있었다. 흥미로운 건 아직도 telnet 명령으로 HTTP 0.9 방식 요청을 실험해볼 수 있다.

2. HTTP 1.0: 웹 대중화의 기반

1990년대 초, 모자익(Mosaic) 브라우저의 등장과 함께 HTTP는 대중에게 본격적으로 노출되기 시작했다. 이 시점에 등장한 HTTP 1.0은 다음과 같은 변화가 있었다.

• 요청/응답에 헤더가 추가됨 (User-Agent, Content-Type 등)
• 다양한 MIME 타입 지원
• 여전히 요청마다 연결을 끊는 구조

RFC 1945로 정리되긴 했지만, 이건 공식 표준이라기보단 ‘정보 제공용 문서(Informational)’였다. HTTP 1.0의 가장 큰 한계는 매번 새로운 TCP 연결을 생성해야 한다는 점이다. 느린 시작(slow start)과 3-way 핸드셰이크 비용을 생각하면, 성능 측면에서 효율적이지 않았다.

3. HTTP 1.1: 커넥션 재사용으로의 전환

1997년 등장한 HTTP 1.1은 웹 성능을 획기적으로 끌어올린 버전이다. 핵심은 ‘Keep-Alive’를 기본으로 채택했다는 점이다.

주요 기능:

• Persistent Connections (기본적으로 연결 유지)
• Chunked Transfer-Encoding (스트리밍 전송 지원)
• Pipelining (연속 요청)
• 캐시 제어 및 콘텐츠 협상

여기서부터 웹은 단순한 텍스트 문서를 넘어서 하이퍼미디어 전송 플랫폼으로 진화하기 시작했다. 이미지, 동영상, 다양한 언어와 문자셋, 쿠키 기반 상태 관리 등도 이때 본격적으로 쓰이기 시작했다.

4. HTTP/2: 성능 재도약

웹의 무게가 점점 더 커지자, HTTP/1.1으로는 버티기 힘든 시대가 왔다. 그래서 2012년, HTTPbis 워킹 그룹이 HTTP/2 개발을 시작했다.

HTTP/2의 목표:

• 낮은 레이턴시
• 높은 처리량
• 기존 애플리케이션 수정 없이도 적용 가능

핵심은 단일 TCP 연결에서 멀티플렉싱을 지원한다는 것이다. 즉, 하나의 연결 안에서 동시에 여러 리소스를 주고받을 수 있으니 브라우저가 더 빠르고 효율적으로 동작할 수 있게 된다.

기존의 요청-응답 구조는 그대로 유지하면서 내부 전송 방식만 개선한 것이 특징이다. 덕분에 기존 서버나 클라이언트는 큰 수정 없이 HTTP/2의 이점을 누릴 수 있다.

정리하며: 왜 이걸 알아야 할까?

소프트웨어 아키텍처나 멀티미디어 서비스 설계를 고민할 때, 전송 계층의 성능은 전체 사용자 경험에 지대한 영향을 끼쳐. 특히 아래와 같은 상황에서 HTTP의 동작 원리를 이해하는 게 중요하다.

• CDN 및 캐시 정책 설계
• 스트리밍 서비스 아키텍처 구축
• 모바일/저지연 환경에서의 콘텐츠 전송 최적화
• SPA나 모바일 앱의 백엔드 API 호출 구조 설계

HTTP의 역사는 단순한 기술 진화가 아니라, 사용자 경험을 최적화하고자 하는 노력의 결정체이다. 브라우저 네트워킹을 이해하는 건, 결국 우리가 만드는 서비스의 퍼포먼스를 좌우하는 핵심이 된다고 볼 수 있다.

참고문헌

[1] 일리아 그리고릭, "구글 엔지니어에게 듣는 네트워킹과 웹 성능 최적화 기법", 정해권, 오현주 공역, 인사이트(insight)

모바일 네트워크는 우리가 스마트폰을 사용하는 방식, 그리고 모바일 앱이 동작하는 근본 구조에 지대한 영향을 준다. 특히 5G는 단순한 속도 향상을 넘어, 완전히 새로운 가능성과 도전을 함께 가져왔다. 이번 글에서는 모바일 네트워크의 진화를 간단히 짚어보고, 5G의 핵심 목표와 모바일 앱 관점에서 꼭 알아야 할 특징을 정리해보자.

5G의 핵심 목표: Speed, Coverage, Connectivity

5G의 비전은 단순히 "더 빠르게"가 아니다. 다음 세 가지 목표가 중심이다:

• Speed: 최고 속도 10Gbps 이상을 목표로 하며, 4G보다 최대 100배 빠르다. 이는 고해상도 영상 스트리밍, AR/VR 같은 애플리케이션을 실시간으로 가능하게 한다.
• Coverage: 기존보다 훨씬 넓은 커버리지를 확보하고, 밀집 지역에서도 연결 품질을 유지할 수 있도록 설계되었다.
• Connectivity: 단말 간 연결 수용량이 폭발적으로 늘어난다. 자율주행차, IoT 센서, 웨어러블 기기들이 동시에 연결되어도 문제없도록 하는 것이 핵심이다.

모바일 애플리케이션 개발 관점에서의 5G 특징

모바일 앱을 개발하거나 서비스를 설계하는 입장이라면, 5G 환경에 맞는 접근이 필요하다. 다음은 중요한 특징이다:

전력 효율과 RRC 상태 관리

5G에서는 4G와 유사하게 연결 상태를 관리한다.

• 스마트폰은 항상 네트워크와 연결되어 있는 WiFi와는 달리, 필요할 때만 연결되는 무선 특성이 있다.
• RRC(Radio Resource Control)는 데이터 전송 시에만 라디오 리소스를 할당함으로써 전력 소모를 줄인다.
• 따라서 앱에서 데이터를 계속 조금씩 보내는 것보다, 몰아서 한 번에 전송하는 전략이 배터리 효율에 유리하다.

네트워크 지연(latency) 고려

• 5G의 초저지연(1ms 이하)은 클라우드 게임, 원격 제어, 라이브 인터랙션 앱에서 핵심 자산이다.
• 하지만 사용자의 위치나 단말 상태에 따라 RRC 연결 전환 지연이 여전히 발생할 수 있으므로, 앱은 이를 고려한 버퍼링, 프리로드 전략이 필요하다.

5G와 엣지 컴퓨팅(Edge Computing)의 만남

5G의 등장은 단지 네트워크 속도를 높이는 것을 넘어, 엣지 컴퓨팅(Edge Computing)과 결합해 새로운 컴퓨팅 패러다임을 만들어내고 있다. 특히 모바일 앱과 서비스가 요구하는 초저지연, 대용량 데이터 처리, 프라이버시 보호 같은 요소들이 엣지 컴퓨팅과 만날 때 큰 시너지를 낸다.

엣지 컴퓨팅이란?

엣지 컴퓨팅은 데이터를 사용자와 가까운 곳, 즉 "네트워크의 엣지(edge)", 예를 들어 기지국, 지역 서버, 또는 사용자 디바이스 근처의 마이크로 데이터 센터에서 처리하는 방식이다.

• 기존에는 모든 요청이 중앙 클라우드로 갔기 때문에, 거리로 인한 지연(latency)이 발생했고,
• 대역폭 소모도 컸으며,
• 개인정보 보호 측면에서도 이슈가 있었다.

엣지 컴퓨팅은 이런 문제를 해결하며 실시간성과 효율성을 동시에 해결한다.

왜 5G와 엣지는 함께 가야 할까?

앞에서 이야기 한 것과 같이 5G는 이론적으로 1ms 이하의 초저지연, 기가비트급 전송속도, 1㎢당 100만 개 이상의 단말 수용을 목표로 한다. 그러나, 이 모든 걸 제대로 실현하려면 데이터가 중앙이 아닌 로컬에서 처리될 수 있어야 한다. 즉, 엣지 컴퓨팅 없이는 5G의 약속도 절반의 구현에 불과할 수 있다.

모바일 애플리케이션에서의 활용 사례

클라우드 게임 스트리밍

• 지연이 중요한 FPS 게임, 레이싱 게임은 5G만으로도 부족할 수 있다.
• 사용자 근처의 엣지 서버에서 게임 데이터를 렌더링하고 스트리밍하면,
  • 조작 반응 속도(입력 ↔ 반응)가 현격히 줄어든다.
  • 실제로 Xbox Cloud Gaming, NVIDIA GeForce Now 등은 엣지 인프라를 적극 활용 중.

자율주행차와 스마트 시티

• 차량의 위치, 속도, 도로 상황 등의 데이터가 엣지에서 처리됨으로써,
  • 교통 신호와 차량 간 실시간 협업이 가능해짐.
• 스마트 시티에서는 CCTV, 센서 데이터를 엣지에서 실시간 분석하여 교통 제어, 범죄 예방 등에도 활용.

VR과 Edge Computing

• 클라우드까지 왕복하는 방식은 보통 50~100ms 이상의 지연이 발생할 수 있으나, VR은 일반적으로 20ms 이하의 지연 시간을 유지해야 자연스럽고 어지럽지 않은 경험을 제공할 수 있다.
• 8K 또는 16K 영상이 필요한 VR 콘텐츠는 데이터 용량이 매우 크다. 이걸 모바일 기기가 직접 처리하거나 원거리 클라우드에서 처리하면 부하가 크고, 지연이 생길 수 있다. 엣지에서 영상 렌더링을 처리하면, 최소한의 전송으로 최적의 영상 품질 제공이 가능하다.
• VR 헤드셋이나 스마트폰의 연산 능력은 제한적이다. GPU 렌더링, 딥러닝 기반 공간 인식 등을 엣지에서 처리하면, 기기 발열과 배터리 소모도 크게 줄일 수 있다.

앱 개발자가 고려해야 할 점

• 엣지 환경에 맞춘 API 및 서비스 설계가 필요하다. 예: Google Cloud’s Anthos, AWS Wavelength, Azure Edge Zones[3]
• 네트워크 지연, 연결 품질이 변수가 될 수 있기 때문에, fallback 전략(엣지 → 클라우드 대체)이 있어야 한다.
• 데이터 처리 위치를 사용자의 동의에 따라 동적으로 제어하는 기능도 점점 중요해진다.

정리

모바일 네트워크는 단순한 "통신 기술"이 아니라, 사용자 경험과 모바일 생태계를 뒤흔드는 근본 인프라다. 5G의 등장은 단지 더 빠른 유튜브 로딩을 의미하는 게 아니다. 그것은 개발자에게는 전혀 다른 설계 철학, 사용자에게는 새로운 서비스의 경험을 뜻한다. 특히, 엣지 컴퓨팅은 5G와 결합하여 단순히 속도를 높이는 것이 아니라, 네트워크를 유연하게, 그리고 스마트하게 만든다. 이제 중요한 것은 어디에서 데이터를 처리하느냐다. 사용자와 가까운 엣지에서 처리함으로써 얻는 이점은 앞으로의 모바일 앱과 서비스에 있어서 경쟁력을 좌우할 핵심 요소가 될 것이다.

참고 자료

[1] High Performance Browser Networking: Ch 07 모바일 네트워크, https://technical-leader.tistory.com/171

[2] Edge Computing Helps 5G Networks: A Practical Guide to Optimising Campus Network Architecture, https://community.fs.com/article/edge-computing-helps-5g-networks-a-practical-guide-to-optimising-campus-network-architecture.html

[3] AWS Wavelength 소개, https://aws.amazon.com/wavelength/

요즘 모바일 앱을 개발하다 보면 "왜 이렇게 느리지?" 혹은 "배터리 너무 빨리 닳는데?"가 주된 고민이다. 사실 이건 단순히 코드나 UI 문제가 아니라, 모바일 네트워크 자체가 갖고 있는 특성과 한계에서 비롯된 문제라고 할 수 있다. 여기서는 모바일 네트워크 최적화를 위한 진짜 핵심을 다룬 내용[1]을 정리해 보자.

배터리, 네트워크, 프레젠테이션 – 무시할 수 없는 세 가지 제약

모바일 앱을 만들 때 우리가 가장 많이 신경 쓰는 게 아마 반응형 디자인일 것이다. 그런데 네트워크 구조와 배터리 사용에 대한 이해가 부족하면, 아무리 멋진 UI를 만들어도 실사용자에겐 ‘답답한 앱’으로 느껴질 수 있다. 중요한 건 세 가지를 균형 있게 고려하는 것이라 할 수 있다.

• 프레젠테이션: 작은 화면 안에 어떻게 정보를 전달할지
• 네트워크 성능: 레이턴시, 처리량
• 배터리 수명: 무선 전파 사용 최소화

이 중 하나라도 무시하면 전체 경험이 망가질 수 있다..

배터리를 아끼는 네트워크 설계법

모바일 네트워크에서 배터리를 아끼는 건 사용자를 포함한 모든 이해관계자의 관심사이다. 이를 위해서 우리가 고려해야 할 건 다음과 같다.

• 무선 전파가 배터리 소모의 주범이라는 점
• 데이터 크기와 무관하게, 전파를 켜는 순간 에너지를 소비한다는 점
• 폴링보다 푸시가 효율적이라는 점

즉, 자잘한 데이터를 자주 보내는 방식은 최악이다. 가능하면 다음처럼 접근해야 한다.

• 데이터를 묶어서 보내기
• 네트워크 상태가 활성화됐을 때 전송 몰아서 처리하기
• 중요도 낮은 요청은 연기하거나 합치기

예를 들어, Android의 Google Cloud Messaging(GCM)은 기기가 활성화됐을 때만 메시지를 전달한다. 이런 최적화는 상당히 효과적이다.

RRC 상태와 레이턴시를 고려하라

모바일 네트워크의 RRC(Radio Resource Control) 상태는 앱에서 전혀 제어할 수 없는 부분이지만, 레이턴시에 어마어마한 영향을 미친다. LTE에서도 첫 패킷 전송을 위해 수백 ms의 추가 지연이 생기고, 3G에서는 수초까지도 걸린다. 그래서 앱 설계 시에는 다음을 고려해야 한다.

• 사용자 인터랙션과 네트워크 요청을 분리하기
• 즉각적인 UI 피드백 제공 후 백그라운드에서 처리
• 프리페치(prefetch)와 캐시 전략 활용

점진적 로딩 vs 몰아서 전송

모바일에서는 점진적 로딩이 항상 좋은 건 아니야. 무선 전파가 자주 활성화되면 배터리 소모는 기하급수적으로 커지고, 레이턴시는 늘어난다. 대신 다음과 같은 전략이 유리하다.

• 콘텐츠를 예측해서 미리 다운로드
• 여러 요청을 한 번에 전송
• 유휴 상태를 최대한 활용

예를 들어, 음악 스트리밍 앱이라면, 노래를 소량씩 계속 스트리밍하는 것보다는 곡 전체를 한 번에 다운받는 게 전력 효율에 훨씬 좋다.

실패를 기본값으로 생각하라

모바일 네트워크는 언제나 불안정하다. 연결이 갑자기 끊길 수도 있고, 처리량이나 레이턴시가 들쭉날쭉할 수도 있다. 그래서 다음을 반드시 고려해야 한다.

• 요청 실패 시 재시도 로직
• 오프라인 모드 고려
• 상태 저장 및 로컬 캐시 사용

요즘은 HTML5의 AppCache나 IndexedDB를 활용해서 오프라인 UX도 나쁘지 않게 만들 수 있다.

WiFi로 넘겨라

가능하면 사용자에게 WiFi를 쓰도록 유도하는 것도 하나의 전략이다. 무선 전파보다 WiFi가 배터리에도 덜 부담되고, 처리량도 안정적이다. 특히 대용량 콘텐츠를 다룰 땐 필수이다.

마치며 – “적게, 빠르게, 한 번에”

모바일 네트워크는 PC와 달라. 예측 불가능한 네트워크 품질, 제어할 수 없는 레이턴시, 에너지 테일 이 모든 요소가 얽혀 있다. 그래서 우리의 전략은 단순해져야 한다.

적게 보내고, 빠르게 받고, 한 번에 끝내라

이게 바로 고성능 모바일 네트워킹의 핵심이다. 

참고문헌

[1] 일리아 그리고릭, "구글 엔지니어에게 듣는 네트워킹과 웹 성능 최적화 기법", 정해권, 오현주 공역, 인사이트(insight)

모바일 네트워크의 진화와 그 영향

모바일 네트워크는 빠른 속도로 진화하고 있으며, 이는 사용자 경험과 웹 성능에 직접적인 영향을 미친다. 2013년 기준으로 전 세계에는 약 64억 개의 모바일 연결이 있으며, 이 숫자는 계속 증가할 것으로 예상된다. 이러한 성장은 소비자들의 스마트 기기에 대한 욕구가 크다는 것을 의미한다. 하지만 단순히 연결된 기기의 수만 늘어나는 것이 아니라, 이들 기기를 지원하기 위한 고속 인터넷과 유비쿼터스한 광역 무선 연결의 수요도 함께 증가하고 있다.

세대별 무선 네트워크 기술의 발전

모바일 네트워킹 기술은 GSM, CDMA, HSPA 그리고 LTE와 같은 몇 가지 주요 무선 기술로 구성되어 있다. 예를 들어, 1G는 데이터를 지원하지 않는 아날로그 시스템이었고, 2G는 최초의 디지털 시스템이 도입된 시점이다. 3G와 4G는 각각 향상된 데이터 전송 속도를 제공하며, 특히 4G는 데이터 전송 속도가 기가비트급에 이른다. 그러나 '최대' 데이터율은 이상적인 환경에서만 가능한 수치임을 명심해야 한다. 여기서는 5G 나오기 전까지의 책이어서 포함되어 있지 않다.

3GPP와 3GPP2 표준의 진화

3GPP와 3GPP2는 각기 다른 경로로 표준을 발전시켜 왔다. 3GPP는 유럽의 GSM을 기반으로 UMTS와 LTE 표준을 개발했으며, 3GPP2는 미국의 CDMA2000 기술을 기반으로 표준을 발전시켰다. 이렇게 다른 기술 기반의 두 표준이 따로 발전해 오다가 파트너십을 가지고 진행하였고, LTE 부터는 통합 표준을 만들기 시작했다. 이러한 표준들은 사용자 장비의 성능에 따라 다양한 성능을 제공하며, 네트워크마다 지정된 사용자 장비 카테고리의 요건을 충족시켜야 최상의 성능을 발휘할 수 있다.

프로토콜의 개요

Radio Resource Controller (RRC)는 3G/4G의 유니크한 기능으로 무선 기기와 기지국 사이의 연결을 관리하는 기능이다.

WiFi와 Ethernet는 항상 네트워크와 연결되어 있다고 본다. 그러므로 무선 기기 혹은 다른 쪽에서도 항상 패킷을 전송할 수 있고, 지연시간(latency)를 최적화 하기 용이하다. 그럼에도 불구하고 전송 매체를 공유하기 때문에 예상하지 못한 패킷 충돌로 인해 성능 저하가 발생할 수 있다. 그리고, 네트워크가 항상 켜져 있기 때문에 파워 소모가 높을 수 있어서 무선 기기의 배터리 효율이 중요한 최적화 요소가 되기도 한다.

이러한 측면에서 RRC는 네트워크 효율적인 사용과 무선 전력 소모를 효과적으로 할 수 있다. 즉, 전송할 데이터가 있는 경우에만 무선 자원(radio resource)를 할당하도록 한다. 거꾸로 수신할 데이터가 있는 경우에도 유사한 과정을 통해서 연결되게 된다.

스마트폰과 같은 무선 기기의 경우, 대형 화면이 가장 큰 전력 소모를 하는 모듈이다. 그 다음이 WiFi 혹은 무선 네트워크 연결과 같은 모듈이다. 그렇기 때문에, 이 무선 모듈을 항상 켜 놓는 것은 무선 기기에게 적절한 해결책이 아니다. 그러므로, 데이터를 전달해야 하지 않는 경우에는 무선 자원을 끊고 데이터 전송이 필요한 경우에만 무선 자원을 사용하는 것이 효과적이다. RRC는 이러한 동작을 수행하는 중추적인 역할을 한다.

RRC 상태 설명

RRC Idle은 저전력 상태이다. 이 때에는 모바일 기기를 컨트롤 하는 작은 메시지만 수신하고 데이터 전송을 위한 라디오 리소스는 할당이 되어 있지 않은 상태이다. 실재로 데이터를 전송해야 하는 상황이 되면 몇번의 컨트롤 메시지 교환을 통해서 라디오 리소스가 할당된다.

RRC Connected가 되면 실재로 많은 데이터 량을 전송하는 상태(State)로 많은 배터리를 소모한다. 데이터를 송신하거나 수신하기 위해 기다립니다. 지정된 라디오 리소스(dedicated radio resource)가 할당되게 되어 있다.

Shrt DRX(Discontinous Reception) 상태는 네트워크의 연결 컨택스트와 네트워크 리소스 할당은 해 놓은 상태로 조금 더 빠르게 다시 네트워크와 연결 상태가 될 수 있다. 이와는 다르게 Long DRX의 경우는 연결 컨텍스트는 유지하지만, 리소스는 해제하여 연결의 시간을 줄이지만 리소스를 다른 곳에 할당하여 전송 효율을 높일 수 있다. 아래 그림과 같이 단말은 모니터링 해야 하는 슬롯을 줄여서 사용 전력을 절약할 수 있다.

이러한 모바일 네트워크의 특징을 참고한다면 데이터를 뜨문뜨문 보내게 되면 빈번한 연결 동작을 요구하게 되어 지속적으로 베터로 소모가 많을 수 있다. 그러므로 데이터를 몰아서 보내고 수신하는 방법을 사용하는 것이 배터리 소모에는 효과적일 수 있다. 즉, 아래 그림에서 데이터 전송 구간(Data Transfer)을 하나로 몰아서 추가적으로 소모 될 수 밖에 없는 구간(energy tail)이 발생하는 것을 줄일 수 있다면 효과적일 수 있다.

결론

모바일 네트워크의 미래는 밝지만, 그 도달에는 여러 도전이 따른다. 기술적 장벽과 높은 비용은 모바일 네트워킹의 발전을 어렵게 만들 수 있다. 하지만 기술이 진화함에 따라 사용자 경험은 향상되고, 웹 성능은 최적화될 것이다. 이러한 변화를 이해하고 준비하는 것이 중요하다.

참고 문헌

[1] 일리아 그리고릭, "구글 엔지니어에게 듣는 네트워킹과 웹 성능 최적화 기법", 정해권, 오현주 공역, 인사이트(insight)

[2] High Performance Browser Networking Ch7 Ch8, https://docs.google.com/presentation/d/17UMWZ8V_CcBBTaqg50Ug_yvB2csL9SB_QgoPlniFoqo/edit?usp=sharing

오늘날 디지털 시대에 WiFi는 기술 발전의 증거로서, 우리 일상에 자연스럽게 통합되어 있다. WiFi의 여정은 1997년 802.11 프로토콜로 시작되었지만, 1999년 802.11b 표준이 도입된 후에야 WiFi 기술이 진정으로 발전하기 시작했다. 이 기술은 기존 로컬 영역 네트워크를 무선으로 확장할 수 있는 간단하고 저렴한 수단을 제공한다.

WiFi 표준의 진화

WiFi는 Ethernet에 무선을 고려하며 만들어져서 아래 그림과 같이 L1, L2의 표준화를 통해서 이루어 졌다. 이로 인해 Ethernet의 Carrier Sense Multiple Access (CSMA), 즉 공유 채널을 사용하는지 확인하는 것은 동일하게 사용한다. Ethernet의 경우는 Collision Detection 즉, CSMA를 하지만 보낼 수 있으면 바로 보내고 다른 쪽과 충돌이 발생하면 Random한 Interval을 가지고 다시 시도하는 반면, 무선은 CSMA를 하지만 Collision Avoidance를 하기 위해서 채널이 비어 있는 상황에서만 시도하는 방식을 사용한다.

WiFi 기술은 누구나 접근할 수 있고 비용 효율적인 비허가 ISM 스펙트럼에서 운영된다. 802.11b에서 802.11ac와 같은 더 정교한 프로토콜로의 진화는 지속적으로 높은 처리량과 고급 변조 기술을 추구함으로써 WiFi 성능을 크게 향상시켰다.

802.11 표준 가족은 802.11b부터 802.11n, 802.11ac에 이르기까지 다양한 기능을 제공하며, 이는 우리의 증가하는 데이터 전송 요구를 충족하기 위해 설계되었다. 이 표준들은 점진적으로 20MHz에서 최대 160MHz까지 대역폭을 확장하고 MIMO 기술을 도입하여 WiFi를 단순한 연결 옵션에서 강력한 네트워크의 중추로 전환시켰다.

WiFi 문제 극복

그럼에도 불구하고, WiFi는 특히 여러 네트워크가 겹치는 밀집된 도심 환경에서 많은 도전에 직면해 있으며, 이는 혼잡과 성능 저하로 이어진다. WiFi를 쉽게 배포할 수 있는 매우 단순함이 오히려 취약점을 초래하기도 하며, 간섭 및 예측 불가능한 네트워크 부하와 같은 문제를 포함한다.

WiFi는 대역폭이나 지연 시간을 보장하지 않으며, 그 성능은 주변 환경에 크게 좌우된다. 802.11n 표준의 프레임 집약과 802.11ac의 5GHz 대역 적응과 같은 혁신이 일부 문제를 완화했지만, 공유 채널 접근과 간섭의 근본적인 도전은 여전히 남아 있다.

WiFi 사용 최적화

WiFi 배포를 이해하고 최적화하는 것은 애플리케이션 성능을 크게 향상시킬 수 있다. 예를 들어, 혼잡하지 않은 대역에서 다른 사용이 확인되지 않은 대역폭을 활용하거나 가변 대역폭을 사용하는 것은 서비스 중단을 방지하고 사용자 경험을 향상시킬 수 있다.

데이터 집약적 애플리케이션에 대해 WiFi 오프로딩과 같은 전략을 사용하면 네트워크 리소스를 효율적으로 사용하면서 성능을 유지하고 셀룰러 네트워크를 통한 데이터 전송과 관련된 비용을 최소화할 수 있다.

미래 방향

앞으로 WiFi 표준과 지속적인 개선이 필수적일 것이다. 서비스 품질을 애플리케이션 수준에서 향상시키는 혁신과 공유 네트워크 리소스의 관리 방법이 WiFi의 다음 단계를 정의할 것이다.

결론적으로, WiFi가 우리 네트워크 인프라의 핵심 요소가 되었지만, 그 복잡성을 이해하고 전략적으로 관리하는 것이 그 잠재력을 진정으로 활용하기 위해 필요하다. 더 연결된 미래를 향해 나아가면서, WiFi의 역할은 의심할 여지 없이 확장될 것이며, 우리가 서로 연결된 세계의 증가하는 요구를 충족하기 위해 더욱 정교한 솔루션을 요구할 것이다.

참고자료

[1] 일리아 그리고릭, "구글 엔지니어에게 듣는 네트워킹과 웹 성능 최적화 기법", 정해권, 오현주 공역, 인사이트(insight)

[2] High Performance Browser Networking Ch5 Ch6, https://docs.google.com/presentation/d/1WCDXTVjy9hoou3Ehjz-meoZQUJoPEjc-hGLCPGOkh3M/edit?usp=sharing

고성능 브라우저 네트워킹: 무선 네트워크 개요

유비쿼터스 환경이 급성장하며, 언제 어디서나 온라인 서비스를 이용할 수 있는 시대가 되었다. 이에 따라 무선 네트워크의 중요성도 커졌으며, 현재 사용되는 무선 기술만 해도 WiFi, Bluetooth, ZigBee, NFC, WiMAX, LTE, HSPA, 위성 서비스 등 다양하다.

무선 네트워크의 기본 원리와 성능 결정 요소

무선 네트워크는 유선 네트워크와는 다르게 공유 매체(전파)* 사용하며, 다음과 같은 요소들에 의해 성능이 결정된다. 

1. 대역폭(Bandwidth): 주파수 범위가 넓을수록 전송 속도가 증가한다. 예를 들어, WiFi 802.11n은 40MHz 대역폭을 사용하여 더 빠른 속도를 구현했다.
2. 신호 대 잡음비(SNR): 신호의 세기와 잡음의 비율로, 방해 전파가 많을수록 성능이 저하된다.
3. 변조(Modulation): 디지털 데이터를 아날로그 신호로 변환하는 방법으로, SNR과 기기의 처리 능력에 영향을 받는다.

특히, 샤논의 법칙은 정보 전송량이 대역폭과 신호 대 잡음 비로 결정된다는 것을 보여 준다. 특히, 변조에 따른 정보 효율이 달라 질 수 있다.

무선 네트워크의 종류와 사용처

• PAN (Personal Area Network): Bluetooth, ZigBee, NFC를 사용하여 개인 기기간 연결.
• LAN (Local Area Network): WiFi를 사용해 건물 내 네트워크 확장.
• MAN (Metropolitan Area Network): WiMAX 등으로 도시 네트워크 연결.
• WAN (Wide Area Network): LTE, 위성 서비스 등을 통해 전 세계 연결.

무선 통신 성능 최적화의 중요성

무선 네트워크는 공유 매체 특성상 방해 전파의 영향을 많이 받고, 전송 전력, 변조 방식, 송수신 거리 등 여러 요소에 의해 성능이 좌우된다.

• 셀 호흡(Cell-breathing): 주변 방해 신호가 많을수록 통신 가능 거리가 줄어든다.
• 근거리/원거리 문제(Near-far Problem): 강한 신호가 약한 신호를 밀어내는 현상.

실제 무선 네트워크 성능 측정과 고려사항

무선 네트워크의 성능은 위치, 방해 전파, 송수신 거리 등에 따라 변화무쌍하다.

• 이상적인 환경: 최대 대역폭, 낮은 잡음, 효율적인 변조 방식 사용 시 최적의 성능.
• 실제 환경: 사용자의 위치와 주변 환경에 따라 성능이 크게 달라집니다.

결론 및 전망

무선 네트워크는 편리성과 이동성을 제공하지만, 잡음, 방해 신호, 대역폭 한계 등 여러 제약이 존재합니다. 앞으로 더 빠르고 안정적인 무선 통신을 위해 5G, WiFi 6 등 차세대 기술이 도입될 것이다.

참고 자료

[1] 일리아 그리고릭, "구글 엔지니어에게 듣는 네트워킹과 웹 성능 최적화 기법", 정해권, 오현주 공역, 인사이트(insight)

TLS의 개념 및 역할

• TLS(Transport Layer Security)는 데이터 암호화, 인증, 무결성을 제공하여 안전한 통신 환경을 조성.
• 초기 SSL 프로토콜에서 발전된 것으로, TCP 위에서 작동하여 HTTP, 이메일 등 애플리케이션의 보안을 강화.

TLS의 작동 원리

• 핸드셰이크 과정: 클라이언트와 서버가 암호화 방식과 키를 협상하여 안전한 터널을 생성.
• 암호화: 대칭키 암호화를 통해 효율적이고 안전한 데이터 전송.
• 인증: 신뢰 사슬을 기반으로 클라이언트와 서버의 신원을 확인.

최적화 기법

• 세션 재개: TLS 핸드셰이크 과정에서 발생하는 레이턴시를 줄이기 위해 세션 캐시나 세션 티켓을 활용.
• TLS 레코드 크기 조정: 레코드 크기를 TCP MSS(Maximum Segment Size)에 맞춰 설정해 효율적 데이터 전송.
• 조기 종료: CDN(콘텐츠 전송 네트워크)나 프록시 서버를 활용해 클라이언트와 가까운 서버에서 세션을 종료해 레이턴시 최소화.
• 압축 비활성화: TLS 레벨에서의 압축은 보안 문제(CRIME 공격) 및 이중 압축 문제로 인해 비활성화 권장.

TLS 관련 최신 기술

• ALPN (Application-Layer Protocol Negotiation): 핸드셰이크 과정에서 애플리케이션 프로토콜 협상을 포함시켜 추가 레이턴시를 줄임.
• SNI(Server Name Indication): 하나의 서버에서 여러 도메인을 운영할 때 필요한 확장.

실무에서의 TLS 활용

• 최신 OpenSSL 및 TLS 버전 사용으로 성능 최적화.
• 인증서 길이 최소화 및 중간 인증서 포함으로 불필요한 레이턴시 방지.
• TLS를 지원하지 않는 구형 클라이언트를 고려해 세션 캐시와 세션 티켓을 병행 사용하는 것이 권장됨.

참고 자료

[1] 일리아 그리고릭, "구글 엔지니어에게 듣는 네트워킹과 웹 성능 최적화 기법", 정해권, 오현주 공역, 인사이트(insight)