[네트워크] TCP 혼잡제어의 원리와 발전, QUIC 프로토콜의 발달 (TCP congestion control)

TCP Congestion Control: AIMD 메커니즘의 동작 원리

TCP(Transmission Control Protocol)에서 사용하는 혼잡 제어(congestion control) 메커니즘 중 가장 기본적인 형태는 AIMD(Additive Increase Multiplicative Decrease)이다.

이 메커니즘은 네트워크의 가용 대역폭을 효과적으로 탐지하고 활용하기 위한 접근 방식이다.

AIMD의 기본 원리

AIMD approach는 송신자가 패킷 손실(네트워크 혼잡 상태)이 발생할 때까지 전송 속도를 점진적으로 증가시키다가, 손실 이벤트 발생 시 전송 속도를 급격하게 감소시키는 방식으로 동작한다. 이 메커니즘은 두 가지 핵심 요소로 구성되어 있다.

Additive Increase(가산적 증가)

• 패킷 손실이 감지되기 전까지 매 RTT(Round-Trip Time)마다 전송 속도를 1 MSS(Maximum Segment Size)만큼 점진적으로 증가시킨다.
• 이 방식은 네트워크에 점진적으로 부하를 늘리면서 가용 대역폭을 탐색하는 과정이다.

Multiplicative Decrease(승산적 감소)

• 패킷 손실 이벤트가 발생할 때마다 전송 속도를 절반으로 급격하게 감소시킨다.
• 이는 네트워크 혼잡이 감지되었을 때 빠르게 부하를 줄여 혼잡 상황을 완화하기 위한 조치이다.

이러한 동작 방식 때문에 AIMD는 그래프에서 톱니(sawtooth) 모양의 패턴을 보이며, 이는 네트워크의 가용 대역폭을 지속적으로 probing하는 과정을 나타낸다.

---

TCP 혼잡 제어의 동작 방식

TCP의 혼잡 제어는 송신자 측에서 congestion window(cwnd)라는 변수를 통해 구현된다. 기본적인 동작 방식은 다음과 같다:

• TCP는 cwnd 바이트를 전송한 후 RTT 동안 ACK를 기다린 다음, 추가 데이터를 전송한다.
• TCP 전송 속도는 대략 cwnd/RTT bytes/sec로 계산할 수 있다.
• TCP 송신자는 항상 LastByteSent - LastByteAcked ≤ cwnd 조건을 유지하며 전송을 제한한다.
• cwnd는 네트워크의 혼잡 상태에 따라 동적으로 조정된다.

 

TCP Slow Start

새로운 TCP 연결이 시작될 때는 네트워크의 상태를 알 수 없으므로, 처음부터 높은 속도로 데이터를 전송하면 혼잡을 유발할 수 있다.

이를 방지하기 위해 TCP는 Slow Start 메커니즘을 사용한다:

• 연결이 시작되면 cwnd를 1 MSS로 초기화한다.
• 매 RTT마다 cwnd를 두 배로 증가시킨다(지수적 증가).
• 이는 각 ACK를 수신할 때마다 cwnd를 증가시키는 방식으로 구현된다.

Slow Start의 특징은 초기 전송 속도는 느리지만, 지수적으로 빠르게 증가한다는 점이다. 첫 번째 패킷 손실 이벤트가 발생하면, TCP는 일반적인 AIMD 모드로 전환된다.

---

TCP 혼잡 제어의 발전: Slow Start에서 CUBIC까지

TCP의 Slow Start와 Congestion Avoidance 전환

TCP connection이 시작될 때 slow start 단계에서는 exponential increase 방식으로 congestion window(cwnd)가 증가한다.

하지만 네트워크의 혼잡 상태에 접근함에 따라 이러한 공격적인 증가 방식은 적절하지 않게 된다.

Exponential에서 Linear로의 전환점

Exponential increase에서 linear increase로 전환하는 시점은 cwnd가 ssthresh(slow start threshold)의 절반에 도달했을 때이다. 이는 다음과 같이 구현된다:

• ssthresh라는 변수를 사용하여 전환 기준점을 관리한다.
• 패킷 손실 이벤트가 발생하면, ssthresh는 손실 직전 cwnd의 1/2로 설정된다.
• cwnd가 ssthresh에 도달하면 slow start 단계에서 congestion avoidance 단계로 전환한다.

이러한 방식은 네트워크 상태에 따라 적응적으로 동작하며, 초기에는 빠르게 가용 대역폭을 탐색하다가 혼잡 가능성이 높아지면 보다 조심스럽게 대역폭을 탐색하게 된다.

---

TCP Congestion Control의 상태 다이어그램

TCP congestion control은 크게 세 가지 상태로 동작한다:

Slow Start

• 초기 cwnd = 1 MSS로 시작
• 매 ACK마다 cwnd += MSS, 결과적으로 매 RTT마다 cwnd가 2배로 증가
• Duplicate ACK가 발생하거나 cwnd가 ssthresh에 도달하면 congestion avoidance 모드로 전환

Congestion Avoidance

• cwnd가 선형적으로 증가: 매 RTT마다 cwnd = cwnd + MSS*(MSS/cwnd)
• 약 매 RTT마다 1 MSS씩 증가하는 효과
• Duplicate ACK가 3개 발생하면 fast recovery 모드로 전환

Fast Recovery

• 네트워크의 일시적 혼잡에 대응하는 메커니즘
• Timeout이 발생하면 slow start로 돌아감
• 새로운 ACK가 도착하면 congestion avoidance 모드로 돌아감

---

TCP CUBIC: 혼잡 제어의 개선

AIMD(Additive Increase Multiplicative Decrease) 방식은 단순하고 안정적이지만, 고속 네트워크에서는 대역폭을 충분히 활용하지 못하는 한계가 있다. TCP CUBIC은 이러한 한계를 극복하기 위해 개발되었다.

TCP CUBIC의 기본 개념

• Wmax: congestion loss가 감지된 시점의 sending rate
• 병목 링크의 congestion 상태는 손실 후에도 크게 변하지 않는다는 가정
• 손실 후 window를 절반으로 줄인 다음, 초기에는 빠르게 Wmax를 향해 증가하다가 Wmax에 가까워지면 천천히 접근

CUBIC의 window 증가 함수

TCP CUBIC은 window 크기를 시간의 3차 함수(cube function)로 증가시킨다:

• K: TCP window 크기가 Wmax에 도달하는 시점
• 현재 시간과 K의 거리에 따라 window 증가율이 달라짐
  • K로부터 멀리 있을 때: 더 큰 폭으로 증가
  • K에 가까워질 때: 조심스럽게 작은 폭으로 증가

TCP CUBIC vs TCP Reno

TCP CUBIC은 기존의 TCP Reno보다 다음과 같은 장점이 있다:

• 고속 네트워크에서 더 높은 throughput 달성
• 특히 긴 RTT를 가진 연결에서 성능이 우수
• 병목 대역폭에 빠르게 도달하고 안정적으로 유지

TCP CUBIC은 현재 Linux에서 기본 TCP 구현으로 채택되어 있으며, 대부분의 인기 있는 웹 서버에서 사용되고 있다. 이는 현대 인터넷의 높은 대역폭 환경에서 효율적인 성능을 제공하기 때문이다.

---

TCP와 병목 링크 혼잡 제어 메커니즘

TCP와 병목 링크(Bottleneck Link)의 관계

네트워크 통신에서 TCP(Transmission Control Protocol)는 전송 속도를 동적으로 조절하는 메커니즘을 가지고 있다.

기본적인 TCP(classic)나 이후에 발전된 버전인 CUBIC은 패킷 손실이 발생할 때까지 전송 속도를 계속해서 증가시킨다.

이러한 패킷 손실은 주로 네트워크 경로 상의 특정 라우터 출력 지점에서 발생하는데, 이 지점을 bottleneck link라고 부른다.

 

병목 현상의 발생 원리

Bottleneck link에서는 다음과 같은 현상이 발생한다:

• 패킷 queue가 거의 비지 않는 상태를 유지한다.
• 때로는 queue가 넘쳐 패킷 손실(packet loss)이 발생한다.
• 이 링크는 거의 항상 busy 상태를 유지한다.

이러한 혼잡 현상을 이해하기 위해서는 bottleneck link에 집중하는 것이 유용하다. TCP 전송 속도를 증가시켜도 혼잡한 bottleneck이 있다면 실제로 end-to-end throughput은 증가하지 않는다는 중요한 insight가 있다.

 

혼잡 제어의 목표

TCP 혼잡 제어의 주요 목표는 "end-to-end pipe를 꽉 차게 유지하되, 그 이상은 아니게(keep the end-end pipe just full, but not fuller)" 하는 것이다.

이는 가용 대역폭을 최대한 활용하면서도 과도한 혼잡을 방지하는 균형점을 찾는 것을 의미한다.

TCP 전송 속도와 RTT의 관계

네트워크 경로에서 TCP 전송 속도를 증가시키면 다음과 같은 결과가 나타난다:

• 병목 지점이 없는 경우: measured RTT가 증가하지 않으면서 throughput이 증가한다.
• 병목 지점이 있는 경우: 전송 속도 증가가 대기열을 길게 만들어 RTT만 증가시킨다.

 

Delay-based TCP 혼잡 제어

기존의 손실 기반(loss-based) 혼잡 제어와 달리, delay-based 접근법은 RTT(Round-Trip Time) 측정값의 변화를 감지하여 혼잡을 예측하고 대응한다.

기본 원리와 작동 방식

Delay-based TCP는 sender-to-receiver pipe를 "충분히 차게 하지만 너무 차지 않게" 유지하는 것을 목표로 한다. 이는 병목 링크가 바쁘게 전송하도록 하면서도 높은 지연이나 과도한 버퍼링은 피하는 방식이다.

주요 개념과 작동 원리는 다음과 같다:

• RTTmin: 관측된 최소 RTT 값으로, 혼잡하지 않은 경로의 지연 시간을 의미한다.
• 혼잡하지 않은 상태에서의 throughput은 congestion window(cwnd)를 RTTmin으로 나눈 값이다.
• 측정된 throughput이 혼잡하지 않은 throughput에:
  • "매우 가까우면" → cwnd를 선형적으로 증가시킨다 (경로가 혼잡하지 않다고 판단)
  • "훨씬 낮으면" → cwnd를 선형적으로 감소시킨다 (경로가 혼잡하다고 판단)

Delay-based 접근법의 장점

Delay-based TCP 혼잡 제어의 주요 장점은 다음과 같다:

• 패킷 손실을 유도하거나 강제하지 않고도 혼잡을 제어할 수 있다.
• Throughput을 최대화("pipe를 꽉 차게")하면서도 지연을 낮게("더 차지 않게") 유지할 수 있다.
• BBR(Bottleneck Bandwidth and Round-trip propagation time)과 같은 여러 현대적 TCP 구현이 이 접근법을 채택하고 있다.
• Google의 내부 백본 네트워크에서는 BBR이 배포되어 사용되고 있다.

이러한 delay-based 접근법은 특히 고속 네트워크나 무선 네트워크와 같이 패킷 손실이 혼잡이 아닌 다른 이유로 발생할 수 있는 환경에서 더욱 효과적으로 작동한다.

---

TCP 혼잡 제어와 공정성: ECN과 Fairness 메커니즘

Explicit Congestion Notification(ECN)

TCP 구현에서는 네트워크 지원 혼잡 제어 방식인 network-assisted congestion control을 적용하는 경우가 많다. 이 방식은 네트워크 자체가 혼잡 상황을 감지하고 통신 당사자들에게 알려주는 메커니즘을 갖추고 있다.

ECN의 작동 원리

ECN은 다음과 같은 방식으로 작동한다:

• IP header의 ToS(Type of Service) 필드에 있는 두 비트를 사용하여 혼잡 상태를 표시한다
• 네트워크 라우터가 이 비트에 혼잡 상태를 표시하며, 표시 정책은 네트워크 사업자가 결정한다
• 혼잡 상황 표시는 패킷과 함께 목적지로 전달된다
• 목적지는 ACK segment의 ECE 비트를 설정하여 송신자에게 혼잡 상황을 알린다
• 이 프로세스는 IP(IP header ECN bit marking)와 TCP(TCP header C,E bit marking) 계층 모두에 걸쳐 작동한다

ECN은 패킷 손실이 발생하기 전에 혼잡 상황을 미리 알려주므로, 더 효율적인 혼잡 제어가 가능하다.

 

 

TCP Fairness

TCP fairness는 네트워크 리소스가 서로 다른 TCP 연결 간에 얼마나 공정하게 분배되는지에 관한 개념이다.

Fairness goal은 K개의 TCP session이 대역폭 R의 동일한 bottleneck link를 공유할 경우, 각 세션이 평균적으로 R/K의 속도를 가져야 한다는 것이다.

TCP 공정성의 작동 원리

병목 라우터의 capacity R을 여러 TCP 연결이 공유할 때, 이상적인 상황에서는 각 연결이 동일한 throughput을 얻게 된다. 이는 다음과 같은 이유로 가능하다:

• AIMD(Additive Increase Multiplicative Decrease) 알고리즘의 특성 덕분이다
• 각 연결은 병목 대역폭의 일정 비율을 차지하는 방향으로 수렴한다

TCP의 공정성 분석

TCP의 공정성에 대한 질문에 대해, 이상적인 가정 하에서는 TCP가 공정하다고 할 수 있다. 이를 설명하기 위한 예시로 두 개의 TCP session이 경쟁하는 상황을 살펴볼 수 있다:

• Additive increase는 throughput을 일정한 기울기(1)로 증가시킨다
• Multiplicative decrease는 throughput을 비례적으로 감소시킨다
• 두 연결의 throughput을 그래프로 표시했을 때, 시스템은 동일한 대역폭 공유 지점으로 수렴하는 경향이 있다

이러한 공정성은 다음의 이상적인 가정 하에서만 성립한다:

• 모든 연결이 동일한 RTT를 가짐
• 연결 수가 고정되어 있음
• 모든 연결이 congestion avoidance 단계에 있음

 

네트워크 애플리케이션과 공정성

모든 네트워크 애플리케이션이 "공정"해야 하는지에 대한 질문은 네트워크 설계에서 중요한 문제이다.

UDP와 공정성

멀티미디어 애플리케이션은 종종 TCP를 사용하지 않는다:

• 혼잡 제어에 의한 속도 제한을 원치 않음
• 대신 UDP를 사용하여:
  • 오디오/비디오를 일정한 속도로 전송
  • 패킷 손실을 감수함
• "인터넷 경찰"이 없어 혼잡 제어 사용을 강제할 수 없음

병렬 TCP 연결과 공정성

애플리케이션은 두 호스트 간에 multiple 병렬 연결을 열 수 있다:

• 웹 브라우저가 이러한 방식을 사용함
• 대역폭 R을 가진 링크에 9개의 기존 연결이 있는 경우:
  • 1개의 TCP를 요청하는 새 앱은 R/10의 속도를 얻음
  • 11개의 TCP를 요청하는 새 앱은 R/2의 속도를 얻음

이는 병렬 연결을 사용하는 애플리케이션이 단일 연결을 사용하는 애플리케이션보다 더 많은 대역폭을 차지할 수 있음을 보여준다.

 

---

전송 계층 기능의 진화: TCP에서 QUIC까지

전송 계층 프로토콜의 진화

인터넷이 발전하면서 전송 계층(transport layer)에서 사용되는 프로토콜도 함께 진화해왔다. TCP와 UDP는 지난 40년간 인터넷의 주요 전송 프로토콜로 사용되어 왔다. 하지만 다양한 네트워크 환경과 애플리케이션 요구사항에 맞춰 TCP의 여러 변형(flavors)이 개발되어왔다.

다양한 시나리오별 TCP 변형

네트워크 환경에 따라 다양한 TCP 변형이 개발되었다:

 

Long, fat pipes(대용량 데이터 전송)

• 문제점: 많은 패킷이 "in flight" 상태에 있고 loss가 발생하면 전체 pipeline이 중단됨
• 해결책: 고속 네트워크에 최적화된 TCP 버전(CUBIC, BBR 등)

Wireless networks(무선 네트워크)

• 문제점: 노이즈가 많은 무선 링크나 이동성으로 인한 패킷 손실이 발생하며, TCP는 이를 혼잡으로 오인함
• 해결책: 무선 환경에 최적화된 TCP 버전(TCP Westwood 등)

Long-delay links(긴 지연 링크)

• 문제점: 극도로 긴 RTT(Round-Trip Time)
• 해결책: 위성 통신 등 긴 지연 링크에 최적화된 TCP 변형

Data center networks(데이터센터 네트워크)

• 문제점: 지연에 민감한 애플리케이션
• 해결책: 낮은 latency를 목표로 하는 DCTCP(Data Center TCP) 등

Background traffic flows(백그라운드 트래픽)

• 문제점: 우선순위가 낮은 "백그라운드" TCP 흐름
• 해결책: TCP Nice, TCP-LP와 같은 저우선순위 TCP 변형

---

전송 계층 기능의 애플리케이션 계층 이전: QUIC

최근에는 전송 계층의 기능을 애플리케이션 계층으로 이동시켜 UDP 위에서 구현하는 접근법이 등장했다.

이러한 접근법의 대표적인 예가 QUIC(Quick UDP Internet Connections)이다.

QUIC의 기본 개념

QUIC은 다음과 같은 특징을 가진다:

• UDP 위에 구현된 application-layer protocol
• HTTP의 성능을 향상시키기 위해 설계됨
• 구글의 많은 서버와 애플리케이션(Chrome, 모바일 YouTube app 등)에 배포되어 사용 중

QUIC의 주요 특징

QUIC은 TCP에서 배운 방식을 차용하면서도 개선된 방식으로 구현한다:

Error and congestion control

• TCP의 loss detection과 congestion control 알고리즘과 유사한 메커니즘 사용
• QUIC 명세에 따르면, "TCP의 loss detection과 congestion control에 익숙한 독자들은 여기서 잘 알려진 TCP 방식과 유사한 알고리즘을 발견할 것"

Connection establishment

• 신뢰성(reliability), 혼잡 제어(congestion control), 인증(authentication), 암호화(encryption), 상태 설정(state established)을 한 번의 RTT로 처리
• TCP+TLS는 2번의 연속적인 handshake가 필요한 반면, QUIC은 단 한 번의 handshake로 모든 설정 완료

Stream multiplexing

• 하나의 QUIC connection을 통해 여러 application-level "streams"를 다중화(multiplexing)
• 각 stream은 별도의 신뢰적 데이터 전송과 보안을 유지하면서도 공통된 혼잡 제어 사용

QUIC의 장점: HOL 블로킹 문제 해결

 

QUIC은 여러 stream의 병렬 처리를 통해 TCP에서 발생하는 HOL(Head-of-Line) blocking 문제를 해결한다:

• HTTP/1.1에서는 TCP의 in-order delivery 특성으로 인해 하나의 패킷 손실이 모든 후속 전송을 차단
• QUIC은 독립적인 stream 처리를 통해 한 stream의 패킷 손실이 다른 stream에 영향을 미치지 않도록 함

 

HTTP/3와 QUIC

HTTP/3는 이전 HTTP/2의 후속 버전으로, TCP 대신 QUIC을 기반으로 구현되었다:

• 기존 HTTP/2는 TCP 위에서 구현되어 TCP의 제한사항에 영향을 받음
• HTTP/3는 QUIC의 이점을 활용하여 더 빠른 연결 설정과 효율적인 멀티플렉싱을 제공
• 이를 통해 웹 페이지 로딩 시간 단축 및 네트워크 상황 변화에 더 빠르게 적응 가능

이러한 전송 계층 기능의 진화는 다양한 네트워크 환경과 애플리케이션 요구사항을 충족시키기 위한 지속적인 노력의 결과이며, 현대 인터넷 서비스의 성능과 안정성 향상에 중요한 역할을 하고 있다.