네트워크 성능과 최적화 (1) - 지연 시간의 구성 요소 - soo:bak

작성일 : 2026년 01월 20일

네트워크 지연은 어디서 발생하는가

“느리다”는 말은 흔히 듣지만, 정확히 무엇이 느린 걸까요?

네트워크 성능을 개선하려면 먼저 지연의 원인을 이해해야 합니다.

지연 시간의 정의

Latency (지연)

데이터가 출발지에서 목적지까지 가는 데 걸리는 단방향(One-way) 지연 시간입니다.

RTT (Round Trip Time)

데이터가 왕복하는 데 걸리는 시간입니다.

클라이언트 ──────► 서버
           요청
    시간 t1          │
                    │
                    ▼
클라이언트 ◄────── 서버
           응답
    시간 t2

RTT = t2 - t1

대부분의 프로토콜이 요청-응답 패턴을 따르므로, RTT가 실제 사용자 경험에 직접적인 영향을 줍니다.

측정 방법

# ping으로 RTT 측정
ping google.com
# 64 bytes from 142.250.185.46: icmp_seq=1 ttl=116 time=32.5 ms
#                                                        ↑ RTT

지연의 4가지 구성 요소

총 지연 = 전파 지연 + 전송 지연 + 처리 지연 + 큐잉 지연

┌─────────────────────────────────────────────────────────────┐
│                                                             │
│   출발지  ─────────────────────────────────────►  목적지   │
│                                                             │
│   ├──전송지연──┤                           ├──처리지연──┤  │
│                ├────────전파지연────────┤               │  │
│                                                             │
│              └─큐잉지연─┘        └─큐잉지연─┘              │
│                (각 홉)             (각 홉)                  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

전파 지연 (Propagation Delay)

신호가 매체를 통해 물리적으로 이동하는 시간입니다.

전파 지연 = 거리 / 전파 속도

빛의 속도 한계

진공에서 빛의 속도: 약 300,000 km/s

광섬유에서: 약 200,000 km/s (굴절률 때문에 느려짐)

서울 → 부산 (약 400km):
전파 지연 ≈ 400km / 200,000 km/s = 2ms (단방향)
RTT ≈ 4ms

서울 → 미국 서부 (약 10,000km):
전파 지연 ≈ 10,000km / 200,000 km/s = 50ms (단방향)
RTT ≈ 100ms

서울 → 유럽 (약 9,000km):
전파 지연 ≈ 9,000km / 200,000 km/s = 45ms (단방향)
RTT ≈ 90ms

줄일 수 없는 한계

전파 지연은 물리 법칙에 의해 결정됩니다.

아무리 좋은 광섬유를 사용해도 빛의 속도보다 빨라질 수는 없습니다.

대안:

CDN으로 콘텐츠를 사용자 가까이에 배치
에지 컴퓨팅
왕복 횟수 줄이기 (프로토콜 최적화)

전송 지연 (Transmission Delay)

데이터를 링크에 밀어넣는 시간입니다.

전송 지연 = 패킷 크기 / 링크 대역폭

예시:

1500바이트 패킷:

100 Mbps 링크:
전송 지연 = 1500 × 8 / 100,000,000 = 0.12ms

1 Gbps 링크:
전송 지연 = 1500 × 8 / 1,000,000,000 = 0.012ms

10 Gbps 링크:
전송 지연 = 1500 × 8 / 10,000,000,000 = 0.0012ms

대역폭이 높을수록 전송 지연이 줄어들지만, 전파 지연은 그대로 유지됩니다.

처리 지연 (Processing Delay)

라우터/스위치가 패킷을 처리하는 시간입니다.

처리 내용:

헤더 검사
체크섬 확인
라우팅 테이블 조회
QoS 분류
NAT 변환
방화벽 규칙 검사

현대 네트워크 장비는 하드웨어 가속을 통해 마이크로초 단위의 처리가 가능합니다.

반면, 소프트웨어 기반 처리는 이보다 느릴 수 있습니다.

큐잉 지연 (Queuing Delay)

패킷이 버퍼에서 대기하는 시간입니다.

가장 가변적인 요소입니다.

트래픽 적음:         트래픽 많음:
┌─────────────┐      ┌─────────────┐
│ 버퍼       │      │ █████████████│
│   ○        │      │ █████████████│
│            │      │ █████████████│
└─────────────┘      └─────────────┘
큐잉 지연: 작음       큐잉 지연: 큼

큐잉 이론

도착률 λ, 서비스율 μ

이용률(Utilization) ρ = λ/μ

ρ가 1에 가까워질수록:

평균 큐 길이가 급격히 증가
지연도 급격히 증가

평균
지연
 │        ┌
 │       /
 │      /
 │     /
 │    /
 │___/
 └───────────────── 이용률 (ρ)
    0%           100%

네트워크를 100% 가까이 사용하면 지연이 급격히 증가합니다.

Bandwidth-Delay Product (BDP)

BDP는 네트워크 “파이프”에 들어갈 수 있는 데이터 양입니다.

BDP = 대역폭 × RTT

예시:

100 Mbps 링크, RTT 100ms:
BDP = 100 Mbps × 0.1s = 10 Mbit = 1.25 MB

1 Gbps 링크, RTT 100ms:
BDP = 1000 Mbps × 0.1s = 100 Mbit = 12.5 MB

TCP와 BDP

TCP는 윈도우로 flow control을 합니다.

송신자              수신자
  │                   │
  │ ───데이터1────► │
  │ ───데이터2────► │ 윈도우 크기만큼
  │ ───데이터3────► │ ACK 없이 전송
  │                   │
  │ ◄────ACK1────── │
  │                   │

윈도우 크기가 BDP보다 작으면?

BDP = 12.5 MB
윈도우 = 64 KB (기본값)

파이프 용량의 0.5%만 사용!

긴 뚱뚱한 파이프 (LFN: Long Fat Network)

높은 대역폭 + 높은 지연 = 큰 BDP

위성 링크:

대역폭: 100 Mbps
RTT: 600ms (정지궤도 위성)
BDP: 7.5 MB

기본 16비트 윈도우(64KB)로는 부족하므로, TCP 윈도우 스케일링(Window Scaling)이 필요합니다.

버퍼블로트 (Bufferbloat)

과도한 버퍼링이 오히려 문제가 됩니다.

왜 버퍼가 문제인가?

네트워크 장비 제조사들은 패킷 손실을 줄이려고 큰 버퍼를 넣었습니다.

버퍼 작음:
높은 부하 → 패킷 손실 → TCP가 속도 줄임 → 혼잡 해소 (빠름)

버퍼 큼:
높은 부하 → 버퍼에 쌓임 → 손실 없음 → TCP가 속도 유지
         → 버퍼 계속 증가 → 지연 증가 → 결국 손실
         → 지연이 엄청 길어진 후에야 혼잡 해소

버퍼블로트의 증상

# 유휴 상태
ping google.com
# time=20 ms

# 대용량 다운로드 중
ping google.com
# time=500 ms  ← 버퍼에 패킷이 쌓여서 지연 증가

실시간 애플리케이션(VoIP, 게임)에 치명적입니다.

해결책: AQM (Active Queue Management)

버퍼가 차기 전에 미리 패킷을 드롭하거나 마킹합니다.

CoDel (Controlled Delay):

패킷이 큐에 머무른 시간(sojourn time) 측정
임계값(5ms) 초과 시 패킷 드롭
Linux 커널에 포함

fq_codel (Fair Queuing CoDel):

CoDel + 흐름별 공정 큐잉
각 연결에 공정한 대역폭 배분
Linux 기본 큐잉 discipline

# fq_codel 확인
tc qdisc show
# qdisc fq_codel 0: dev eth0 root ...

지연의 실제 구성

서울에서 미국 서버로 HTTP 요청:

구성 요소          시간
─────────────────────────────
DNS 조회           ~50ms (캐시 미스 시)
TCP 핸드셰이크     ~100ms (1 RTT)
TLS 핸드셰이크     ~200ms (2 RTT, TLS 1.2)
HTTP 요청/응답     ~100ms (1 RTT)
─────────────────────────────
총                 ~450ms

TLS 1.3 사용 시:   ~350ms (TLS 1 RTT)
HTTP/2 사용 시:    연결 재사용으로 이후 요청 빠름
HTTP/3 사용 시:    0-RTT 가능

대부분의 지연은 왕복 횟수에 의존합니다.

따라서 RTT 자체를 줄이거나, 왕복 횟수를 줄이는 것이 핵심입니다.

정리: 지연은 줄이기 어렵다

지연의 구성 요소 요약:

구성 요소	제어 가능	최적화 방법
전파 지연	거의 불가능	CDN, 지리적 분산
전송 지연	대역폭 증가	링크 업그레이드
처리 지연	장비 성능	하드웨어 가속
큐잉 지연	트래픽 관리	AQM, 용량 계획

빛의 속도는 불변이므로, 지리적 거리에 의한 지연은 줄일 수 없습니다.

Part 2에서는 TCP 혼잡 제어 알고리즘의 발전을 살펴봅니다.

관련 글