TCP 동작 원리와 HOL 블로킹 깊게 파헤치기

네트워크의 핵심 프로토콜인 TCP가 데이터를 어떻게 신뢰성 있게 전달하는지, 그리고 성능 병목의 원인인 HOL 블로킹이 무엇인지 정리합니다.

1. TCP의 에러 정정 방식: GBN vs SR

TCP는 오류가 발생했을 때 재전송을 요청하는 ARQ(Automatic Repeat Request) 방식을 사용합니다 [1]. 흔히 GBN과 SR 방식 중 어디에 해당하는지 혼동하기 쉽지만, TCP는 두 방식의 특성을 모두 가지고 있습니다.

GBN (Go Back N) 유사점: TCP는 **누적 ACK(Cumulative ACK)**를 사용합니다 [2, 3]. 수신 측은 유실된 패킷이 있다면 그 이전까지 성공적으로 받은 마지막 패킷의 다음 순번을 ACK로 보냅니다 [3].
SR (Selective Repeat) 유사점: 타임아웃이 아닌 3개의 중복 ACK를 수신하여 발생하는 빠른 재전송(Fast Retransmit) 시에는 유실된 특정 패킷 하나만을 재전송하는데, 이는 SR의 동작 방식과 유사합니다 [3].

TCP는 네트워크 혼잡을 방지하기 위해 윈도우 크기를 조절하며 세 가지 상태를 오갑니다 [4].

Slow Start: 시작 시 또는 타임아웃 발생 시, 윈도우 사이즈를 1부터 지수 함수 형태로 빠르게 증가시킵니다 [4].
Congestion Avoidance: 임계치(ssthresh)에 도달하면 윈도우 사이즈를 선형적으로 완만하게 증가시킵니다 [4].
Fast Recovery: 중복 ACK가 3개 이상일 때 진입하며, 유실된 패킷만 재전송하고 윈도우 크기를 조정하여 혼잡에 대비합니다 [3, 4].

HOL 블로킹

HOL 블로킹은 줄 맨 앞의 패킷이 지연되면서 뒤에 있는 패킷들이 준비가 되었음에도 불구하고 함께 멈춰버리는 현상을 의미합니다 [5].

TCP 계층의 HOL: TCP의 누적 ACK 특성 때문에 패킷 하나가 유실되면, 이후에 도착한 패킷들이 정상이라도 상위 애플리케이션으로 전달되지 못하고 대기해야 합니다 [5, 6].
HTTP/1.x의 HOL: 요청한 순서대로 응답을 보내야 하는 구조적 한계로 인해 앞선 요청의 처리가 늦어지면 전체 응답이 지연됩니다 [7].
HTTP/2.0의 한계: 멀티플렉싱을 통해 애플리케이션 계층의 HOL은 해결했지만, 물리적인 TCP 연결은 하나를 공유하기 때문에 TCP 계층에서 발생하는 패킷 유실로 인한 HOL 블로킹은 여전히 피할 수 없습니다 [6].

TCP 기반 프로토콜의 고질적인 문제인 HOL 블로킹을 해결하기 위해 HTTP/3.0에서는 QUIC 프로토콜이 도입되었습니다 [8].

UDP 기반: QUIC은 TCP 대신 UDP를 표준으로 사용하여 TCP 계층의 엄격한 순서 보장으로 인한 블로킹 문제를 해결했습니다 [8].
독립적 스트림: 하나의 연결 안에서 여러 스트림이 독립적으로 동작하므로, 특정 패킷이 유실되어도 다른 스트림의 데이터 전달에는 영향을 주지 않습니다 [6, 8].