Congestion Control & Window Mechanics

1. Overview

혼잡 제어와 윈도우 역학(Congestion Control & Window Mechanics)은 인터넷을 오가는 수억 개의 트래픽이 한꺼번에 좁은 통신사 라우터(Router) 골목으로 몰릴 때, 도로가 마비되는 것을 막기 위해 모든 컴퓨터가 이타적으로 속도를 줄이는 TCP의 극강의 공공도덕 메커니즘을 해부합니다.

학습자는 수신자 1명을 배려하는 흐름 제어(Flow Control)를 넘어, 보이지 않는 수천 개의 라우터(네트워크 전체)가 터지지 않도록 전송 속도를 스스로 조절하는 **혼잡 제어(Congestion Control)**의 본질을 뜯어봅니다. 나아가 맨 처음 패킷 1개부터 시작해 기하급수적으로 속도를 올려보는 Slow Start와, 임계점(ssthresh)에 도달하면 선형으로 조심스레 속도를 올리는 Congestion Avoidance의 우아한 수학적 페달링을 장악합니다. 마지막으로, 패킷이 유실되었을 때 3번의 중복 ACK(3 Duplicate ACKs)를 감지하고, 타임아웃 전이라도 재빠르게 반 토막 속도로 복구하는 Fast Recovery(빠른 회복) 알고리즘의 최적화 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Congestion Control Core: 수신 윈도우(rwnd)와 혼잡 윈도우(cwnd)의 차이, 네트워크 붕괴 방지.
• TCP Reno Algorithm: Slow Start (지수적 증가), Congestion Avoidance (선형 증가).
• Loss Detection: Timeout (치명적 에러), 3 Duplicate ACKs (경미한 에러).
• Fast Retransmit & Recovery: 타임아웃을 기다리지 않는 빠른 재전송 및 윈도우 반 토막 회복.

Out-of-Scope

• 현대 TCP 알고리즘 비교 (BBR, CUBIC): 패킷 유실 기반(Reno)과 대역폭/지연 기반(BBR)의 심층 수학 모델 비교 $\rightarrow$ 네트워크 최적화 랩 영역.
• 흐름 제어 (Flow Control): 수신자 버퍼 기반의 속도 조절 $\rightarrow$ 08-02-01 IP & TCP Core Dynamics 영역에서 기학습.

Boundaries

• Flow Control vs Congestion Control: 다시 한번 명확히 선을 긋습니다. 내가 쏘는 속도는 min(수신 윈도우, 혼잡 윈도우)로 결정됩니다. 내 친구(수신자) 컴퓨터가 아무리 1Gbps 처리가 가능한 슈퍼컴퓨터(rwnd가 큼)라도, 나와 친구 사이를 잇는 통신사 공유기가 10Mbps짜리면 공유기가 터집니다(혼잡 발생). 혼잡 제어는 내 친구가 아니라 '얼굴도 모르는 중간 라우터들'을 위해 내가 알아서 브레이크를 밟아주는 무언의 사회적 약속입니다.

3. Counterexample

• 이기적인 UDP 폭격: 토렌트 같은 프로그램이나 커스텀 P2P 클라이언트를 짤 때 TCP의 혼잡 제어(Congestion Control)가 답답하다며 전부 UDP로 바꿔버립니다. 네트워크(라우터)에 병목이 생겨 패킷이 버려지기(Drop) 시작하는데도, 이기적인 UDP 클라이언트들은 브레이크 없이 데이터를 더 퍼붓습니다. 결국 통신사 라우터의 큐(Queue)가 터져버리면서 그 대역을 쓰는 모든 사람의 인터넷이 끊기는 '혼잡 붕괴(Congestion Collapse)'의 주범이 됩니다.
• 타임아웃(Timeout) 방치: TCP 통신 중 패킷 하나가 유실되었습니다. 정상적인 TCP라면 수신자가 보내는 '3번의 중복 ACK(3 Dup ACKs)'를 감지하고 즉시 패킷을 재전송하며 속도를 절반(Fast Recovery)으로 늦췄을 것입니다. 그러나 낡은 TCP 스택(Tahoe)은 이걸 무시하고 타임아웃(약 1초 이상)이 날 때까지 멍 때리다가, 속도를 아예 1(Slow Start)로 바닥부터 리셋시켜 버립니다. 유저의 체감 다운로드 속도가 들쭉날쭉 널뛰기하는 끔찍한 네트워크 튜닝 실패입니다.

4. Prerequisites

• 흐름 제어 기초 (Basic): Sliding Window와 ACK 메커니즘. (08-02-01 IP & TCP Core Dynamics)
• 라우터 큐잉 역학 (Basic): 라우터 버퍼에 패킷이 쌓이고 버려지는 병목. (08-01-04 Hardware & Observability)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 도로가 마비되는 순간, 혼잡 붕괴 (The Network Collapse)

• Why to Learn: 10차선 고속도로(수신자 버퍼)를 놔두고 왜 요금소(중간 라우터)에서 트래픽이 멈춰 서는지, 네트워크 전체의 병목 현상을 통찰하기 위함입니다.
• What to Learn:
  • Concepts: Congestion (혼잡), Congestion Collapse (혼잡 붕괴), Router Queue Overflow, Congestion Window (cwnd), min(rwnd, cwnd).
  • Skills: 송신자의 최종 전송 속도를 결정하는 수식(최종 창문 크기 = 최소값(수신자 여유 공간, 네트워크 여유 공간)) 원리 파악.
• How to Learn:
  • 1단계: 개인의 이기심: 1980년대 초 인터넷은 혼잡 제어가 없었습니다. 라우터에 병목이 생겨 패킷이 늦어지자, 컴퓨터들은 패킷이 유실된 줄 알고 '재전송'을 미친 듯이 쏴댔습니다.
  • 2단계: 공멸의 물리학: 라우터는 10개를 처리할 수 있는데 재전송 때문에 20개가 들어옵니다. 라우터가 뻗어버리고, 컴퓨터는 재전송을 40개 쏩니다. 전체 인터넷이 완전히 마비되어 아무도 통신하지 못하는 '혼잡 붕괴'의 악순환을 해부합니다. 이를 막기 위해 내가 스스로 보낼 양(cwnd)을 제어하는 이타심이 탄생합니다.
• Implement: 혼잡 붕괴 시뮬레이터. Router_Capacity = 10. Sender_A와 Sender_B가 각각 패킷 6개씩 쏨 (Total 12). 라우터는 2개를 드롭. Sender A, B는 패킷 드롭(Timeout)을 감지하고, 속도를 줄이긴커녕 '재전송(Retransmission)' 로직을 태워 원본 6개 + 재전송 2개를 쏴 트래픽이 16 -> 24로 폭발하여 라우터가 기절하는 콘솔 애니메이션.

Recommended

Core Topic 02: 엑셀 밟기, 슬로우 스타트와 혼잡 회피 (Slow Start & Avoidance)

• Why to Learn: 처음 연결하자마자 100개의 패킷을 들이붓지 않고, 라우터의 간을 보며 기하급수적으로 스로틀(Throttle)을 올리는 우아한 주행 알고리즘을 장악하기 위함입니다.
• What to Learn:
  • Concepts: Slow Start (지수적 증가), Congestion Window (cwnd), ssthresh (Slow Start Threshold), Congestion Avoidance (혼잡 회피/선형 증가).
  • Skills: TCP 커넥션이 맺어지고 cwnd가 1부터 시작하여 임계점에 도달할 때까지 변하는 그래프 그리기.
• How to Learn:
  • 1단계: Slow Start (지수 폭발): 처음에는 네트워크 상태를 모릅니다. 창문 크기(cwnd)를 1개로 쏩니다. 성공하면 2개로, 성공하면 4개, 8개, 16개로 엑셀을 밟습니다. 이름은 Slow Start지만 실제로는 $2^n$으로 엄청나게 빨리 속도를 올리는(지수적 증가) 원리를 해부합니다.
  • 2단계: Congestion Avoidance (눈치 보기): 속도가 ssthresh(예: 16)에 도달하면 "이제부터는 조심해야겠다" 모드로 바뀝니다. 이때부터는 성공해도 17개, 18개, 19개처럼 선형적(+1)으로만 조심조심 속도를 올립니다. 그러다 패킷이 펑 터지면 다시 브레이크를 밟는 역학을 뜯어봅니다.
• Implement: TCP cwnd 변화 그래프 (콘솔 플로팅). ssthresh = 16. Round 1: cwnd=1 Round 2: cwnd=2 Round 3: cwnd=4 Round 4: cwnd=8 Round 5: cwnd=16 (Threshold 도달!) Round 6: cwnd=17 (Congestion Avoidance) Round 7: cwnd=18 이 수학적 곡선을 터미널에 별표(*) 길이로 찍어내는 렌더링.

Practical

Core Topic 03: 비명 소리 듣기, 3 Dup ACKs와 타임아웃 (Loss Detection)

• Why to Learn: 패킷이 중간에 증발했을 때, 타임아웃(Timeout)까지 1초를 멍 때리며 기다리는 멍청함을 버리고 수신자의 다급한 힌트로 즉각 눈치채는 에러 탐지 기법을 쥐기 위함입니다.
• What to Learn:
  • Concepts: RTO (Retransmission Timeout), 3 Duplicate ACKs (중복 확인 응답), Fast Retransmit (빠른 재전송).
  • Skills: Wireshark 로그에서 타임아웃에 의한 치명적 에러와 3 Dup ACKs에 의한 경미한 에러를 육안으로 분별하기.
• How to Learn:
  • 1단계: 치명적 에러 (Timeout): 1, 2, 3번을 쐈는데 아무 응답이 없습니다. 1초 뒤 송신자가 "아, 네트워크가 꽉 막혀 붕괴했구나"라고 판단합니다. 이건 중증 장애입니다.
  • 2단계: 경미한 에러 (3 Dup ACKs): 1, 2, 3, 4, 5번을 쐈습니다. 2번만 유실되었습니다. 수신자는 1번을 받고 ACK 2를 쏩니다. 3번이 오자 "어? 2번 줘!" 하고 또 ACK 2를 쏩니다. 4번이 와도 또 ACK 2를 쏩니다. 송신자가 똑같은 ACK 2를 3번(중복) 연달아 받는 순간, "네트워크는 멀쩡히 굴러가는데(3,4,5가 도착했으니) 2번만 쏙 빠졌구나!"라고 눈치채고 타임아웃 전에 즉시 2번을 던져주는(빠른 재전송) 천재적 발상을 뜯어봅니다.
• Implement: 중복 ACK 탐지기 파이썬 봇. 송신자가 [1, 2, 3, 4, 5]를 전송. 망에서 2 드롭. 수신자가 받는 순서대로 ACK를 응답 [ACK 2, ACK 2, ACK 2, ACK 2]. 송신자 봇이 ACK 2 카운터를 모니터링하다가 3을 찍는 순간 [TRIGGER] 3 Dup ACKs Detected -> Fast Retransmit Packet 2를 실행하고 RTO(타임아웃) 타이머를 취소하는 로직 렌더링.

Advanced

Core Topic 04: 상처만 반 토막 내기, 빠른 회복 (Fast Recovery - TCP Reno)

• Why to Learn: 에러가 났다고 무조건 전송 속도를 1(바닥)로 떨어뜨리는 원시적 알고리즘을 벗어나, 경미한 에러 시 속도를 반 토막만 내고 고속 주행을 유지하는 모던 TCP의 최적화를 장악하기 위함입니다.
• What to Learn:
  • Concepts: TCP Tahoe (구형 알고리즘), TCP Reno (Fast Recovery), Window Halving (반 토막), AIMD (Additive Increase Multiplicative Decrease).
  • Skills: 혼잡 발생 시 ssthresh를 현재 윈도우의 절반으로 설정하고 윈도우 사이즈가 떨어지는 과정 추적.
• How to Learn:
  • 1단계: 원시 TCP의 절망 (Tahoe): cwnd가 100(100MB/s)까지 시원하게 뚫렸습니다. 그런데 패킷 하나가 살짝 유실(3 Dup ACKs)되었습니다. 낡은 TCP(Tahoe)는 벌벌 떨며 속도(cwnd)를 1(바닥)로 곤두박질치게 만듭니다. 다운로드 속도가 100MB/s에서 갑자기 1MB/s로 뚝 떨어집니다.
  • 2단계: 반 토막 타협 (Reno & Fast Recovery): 3 Dup ACKs는 네트워크가 꽉 막힌 게 아니라 패킷 하나만 살짝 튄 거(경미한 혼잡)라고 배웠습니다. 그래서 최신 TCP(Reno)는 속도(cwnd)를 1로 안 떨구고 딱 절반(50)으로만 깎습니다(Fast Recovery). 그리고 거기서부터 다시 51, 52 조심스럽게(Avoidance) 올립니다. 속도가 크게 널뛰지 않고 고속을 유지하는 AIMD (더할 땐 1씩, 깎을 땐 반 토막) 수학을 해부합니다.
• Implement: TCP AIMD 톱니바퀴 시각화. cwnd 상승 루프 (1->2->4... 16->17->18->19->20). [EVENT] 3 Dup ACKs 발생! Tahoe_Logic: cwnd를 1로 폭락시킴. (그래프가 바닥을 찍음) Reno_Logic: cwnd를 현재 절반인 10으로 반 토막 내고, 11->12 로 다시 선형 회복함. 이 두 알고리즘의 극명한 속도(면적) 효율 차이를 텍스트 기반 차트로 출력하는 증명.

7. Terminology

8. References

Primary

• [P1] CS2023 - Networking and Communication (NC) - Congestion Control
• [P5] SFIA - Network Design (NTDS) - Traffic and Congestion Engineering

Secondary

• [Computer Networking: A Top-Down Approach] Kurose & Ross - Principles of Congestion Control (TCP Reno)
• [TCP/IP Illustrated, Volume 1] Kevin R. Fall - TCP Congestion Control

Industry

• [IETF RFC 5681] - TCP Congestion Control (Slow Start, Fast Retransmit, Fast Recovery)
• [Cloudflare Learning Center] - Congestion Control and BBR

9. Final Checklist

Primary

• 수신자(Receiver)의 버퍼 넘침을 막는 흐름 제어(Flow Control)와, 통신사 라우터(네트워크)의 버퍼 넘침을 막는 혼잡 제어(Congestion Control)의 아키텍처적 타겟 차이를 명확히 구분할 수 있는가?
• 인터넷 트래픽이 폭주하여 라우터의 큐(Queue)가 가득 차 패킷이 폐기될 때, TCP 클라이언트들이 무지성 재전송(Retransmission)을 때릴 경우 발생하는 '혼잡 붕괴(Congestion Collapse)'의 메커니즘을 설명할 수 있는가?

Secondary

• TCP 송신자가 통신을 시작할 때, cwnd(혼잡 윈도우)를 1부터 시작하여 임계점(ssthresh)에 도달할 때까지 지수적($2^n$)으로 증가시키는 슬로우 스타트(Slow Start) 알고리즘의 엑셀링(Acceleration)을 추적할 수 있는가?
• 임계점(ssthresh) 돌파 이후, TCP가 네트워크 병목을 찌르기 직전 선형적(Additive Increase)으로 조심스레 윈도우를 늘려가는 혼잡 회피(Congestion Avoidance)의 눈치 싸움을 증명할 수 있는가?

Industry

• 특정 패킷 유실 시 발생하는 치명적인 에러인 타임아웃(Timeout)과, 뒤따라오는 패킷들에 의해 트리거되는 3개의 중복 ACK(3 Dup ACKs)가 송신자에게 전달하는 네트워크 상태(혼잡 강도)의 차이를 평가할 수 있는가?
• TCP Reno 알고리즘에서 3 Dup ACKs를 수신했을 때, 타임아웃까지 기다리지 않고 즉각 패킷을 쏘는 빠른 재전송(Fast Retransmit)과 윈도우 사이즈를 반 토막(Halving) 내어 고속을 유지하는 빠른 회복(Fast Recovery)을 설계할 수 있는가?