TCP의 혼잡 제어

Transmission Control Protocol (TCP)란?

---

TCP(Transmission Control Protocol)는 이름 그대로 전송 계층에서 작동하는 규약(Protocol)으로서, 데이터 전송 전 3-Way Handshake를 통해 End-to-End으로 신뢰성 있는 연결을 만들고 데이터를 주고 받도록 제어하는 역할을 합니다.

Reference: ClouDNS

이 과정은 총 3단계로 이루어져있습니다.

1. SYN(Synchronize): 클라이언트는 서버에 클라이언트의 ISN(Initial Sequence Number)을 담아 SYN을 서버로 보냅니다. ISN은 첫번째 패킷에 담겨진 random한 번호(e.g 123456)입니다.
2. SYN + ACK(Acknowledgment): 서버는 클라이언트에게서 SYN을 수신하고, 서버의 ISN을 Client에게 보내면서 승인번호로 ISN + 1을 보냅니다.
3. ACK: Client는 서버의 ISN + 1 값을 승인번호에 담아 ACK를 서버에 보냅니다.

이 과정 때문에 TCP는 신뢰성이 있는 계층이라고 하며, UDP는 이런 과정이 없기 때문에 신뢰성이 없는 계층이라고 합니다. 

 

TCP 혼잡제어

---

TCP 혼잡 제어는 네트워크의 과부하를 막기 위해 송신하는 패킷의 양을 조절해서 오버플로우를 관리하는 방법입니다.

 

예를 들어, 서버와 클라이언트 모두 초당 10GB씩 처리할 수 있는 뛰어난 능력이 있더라도, 중간에 거쳐 가는 라우터가 10MB밖에 처리하지 못한다면 결국 병목 현상이 발생하게 됩니다. 이러한 상황이 오면 라우터의 버퍼가 넘쳐 패킷이 유실되고, 데이터가 잘 도착했다는 응답(ACK)이 송신 측에 도달하지 못합니다. 이때 TCP의 신뢰성 보장 메커니즘 때문에 송신 측은 동일한 데이터를 다시 재전송하게 되는데, 이러한 재전송은 도심 속 교통 체증처럼 네트워크의 혼잡을 더욱 가중시켜 결국 네트워크를 Overflow 상태로 몰고 갑니다.

TCP는 이 oveflow를 막기 위해 혼잡 윈도우(CWND) 크기를 조절하며 데이터 전송량을 조절합니다. 그럼 혼잡 윈도우는 뭘까요?

 

혼잡 윈도우 (CWND, Congestion Window)

---

혼잡 윈도우란 송신자가 "상대방의 확인 응답(ACK)을 받지 않고도 한 번에 네트워크로 쏘아 보낼 수 있는 데이터의 최대 양"을 의미합니다.  결국 혼잡 제어란 혼잡 윈도우의 양을 조절하는걸로 생각을 하면 됩니다.

 

 

혼잡 제어 기법 (Congestion Control Strategy)

---

AIMD (Addictive Increase Multiplicative Decrease)

대표적인 혼잡 제어 기법 중 하나입니다. 알고리즘 순서는 아래와 같습니다.

 

1. 송신자가 수신자에게 패킷을 보냅니다.
2. 패킷 수신이 성공하면 혼잡 윈도우 크기에 +1씩 늘려줍니다.
3. 만약 혼잡이 발생하면 "현재 윈도우 크기 / 2"로 절반씩 줄여줍니다.

이러한 방식으로 윈도우 사이즈를 조절한다면, 전체적인 윈도우의 변화 또한 아래처럼 간단한 모습일겁니다.

Reference: GeeksForGeeks

 

네트워크 혼잡이 발생했을 때 윈도우 크기를 크게 줄임으로써 패킷 유실과 이로 인한 오버플로우를 방지할 수 있습니다. 또한, 새로운 호스트가 네트워크에 진입할 때도 혼잡 윈도우 크기를 서서히 늘려가기 때문에 기존 트래픽에 가해지는 부담을 최소화하고 자원을 공평하게 나누어 쓸 수 있다는 장점이 있습니다.

하지만 이러한 순수 AIMD 방식은 초기에 윈도우 크기를 1씩만 선형적으로 늘리기 때문에, 처음 진입한 호스트가 네트워크의 가용 대역폭을 가득 채워 최적의 전송 속도에 도달하기까지 시간이 너무 오래 걸리는 결정적인 단점이 있습니다.

Slow Start

Reference: Stackoverflow

Slow Start는 이름과 다르게, 급진적으로 혼잡 윈도우 크기를 늘려갑니다.

 

현대의 고속 대용량 네트워크 환경일수록, 처음부터 속도를 1씩만 올리는 AIMD 방식은 너무 느리기 때문에 초반에 대역폭을 빠르게 채워주는 Slow Start이 돋보이기 시작했습니다. Slow Start는 수신자로부터 ACK를 받을 때마다 혼잡 윈도우 사이즈를 1씩 증가시킵니다. 이 방식은 결과적으로 한 RTT마다  윈도우 사이즈가 2배씩 증가하는 효과를 냅니다. 예를 들어 첫 패킷 송신이 성공하면 혼잡 윈도우 사이즈는 2, 그다음 라운드에는 4, 그다음은 8, 16과 같은 방식으로 전송량이 폭발적으로 늘어납니다.

 

이렇게 빠르게 대역폭을 채우며 달리다가, 네트워크의 안전 임계점(ssthresh)에 도달하면 앞서 언급한 혼잡 회피(AIMD) 단계로 전환하여 조심스럽게 속도를 올립니다. 이 과정에서 패킷 유실이 발생했을 때 TCP가 대처하는 방식은 Tahoe와 Reno 정책에 따라 명확히 구분됩니다.

• TCP Tahoe: 타임아웃(Timeout)이나 3번의 중복 ACK 등 어떤 유실이든 발생하면, 안전을 위해 혼잡 윈도우 사이즈를 1로 완전히 줄여버리고 처음부터 Slow Start를 재시작합니다.
• TCP Reno: 유실의 원인에 따라 다르게 대처합니다. 데이터 전송이 완전히 끊긴 타임아웃(Timeout) 상황에서는 Tahoe처럼 윈도우 사이즈를 1로 줄입니다. 하지만 다른 패킷은 잘 가는데 특정 패킷만 누락된 3번의 중복 ACK 상황에서는, 윈도우 사이즈를 1이 아닌 현재 크기의 절반으로만 줄인 뒤 그 자리에서부터 다시 이어가는 빠른 회복(Fast Recovery) 정책을 수행합니다.

Reference

---

https://velog.io/@nnnyeong/Network-TCP-%ED%98%BC%EC%9E%A1%EC%A0%9C%EC%96%B4-Congestion-Control#%ED%98%BC%EC%9E%A1-%EC%A0%9C%EC%96%B4-%EC%A0%95%EC%B1%85

[Network] TCP 혼잡제어, Congestion Control

 

https://jjunsu.tistory.com/358

[컴퓨터 네트워크] TCP 혼잡 제어(Congestion Control)

https://en.wikipedia.org/wiki/TCP_congestion_control