428. TCP 혼잡 제어 (Congestion Control)

핵심 인사이트 (3줄 요약)

본질: TCP 혼잡 제어는 전송 계층에서 핵심 동작과 제약을 이해하게 해 주는 개념이다.

가치: TCP 혼잡 제어를 이해하면 신뢰성과 지연 사이의 균형을 더 정확히 볼 수 있다.

판단 포인트: 설계 시에는 개념 자체보다 적용 조건, 운영 복잡도, 인접 기술과의 경계를 함께 판단해야 한다.

Ⅰ. 개요 및 필요성

개념: 네트워크 내의 트래픽 양이 처리 가능한 대역폭(Bandwidth)을 초과하여 라우터의 큐 오버플로우로 인한 패킷 유실이 발생할 때, 송신 측이 전송 윈도우 크기를 동적으로 조절하여 혼잡을 완화하는 알고리즘.
필요성: 1980년대 초, TCP는 흐름 제어(수신자 눈치 보기)밖에 몰랐다. 수신자가 "나 1GB 받을 수 있어!"라고 하면, 송신자는 그냥 냅다 1GB를 풀악셀로 때려 박았다. 문제는 이 둘을 이어주는 중간 통신사 라우터의 성능이 고작 10MB였다는 거다. 라우터는 쏟아지는 패킷을 감당 못 하고 다 쓰레기통에 버렸다(Drop). 패킷이 버려지니 송신자는 빡쳐서 1GB를 또 재전송했다. 라우터는 더 죽어났다. 전 세계의 모든 PC가 이기적으로 재전송을 갈겨대자 1986년 10월, 인터넷망 전체의 속도가 32Kbps에서 40bps로 추락하는 인터넷 대붕괴(Congestion Collapse) 사태가 터졌다. "안 되겠다! 수신자 눈치만 보지 말고, 도로(네트워크)가 꽉 막힌 거 같으면 우리 스스로 속도를 확 줄여주는 자제력(혼잡 제어)을 코딩해 넣자!!" 반 雅各브슨(Van Jacobson)의 이 천재적인 패치가 인터넷을 구원했다.
💡 비유: 혼잡 제어는 고속도로 톨게이트 전방의 **"가변 속도 제한 시스템"**과 같습니다.
- 흐름 제어: 목적지 펜션 주인(수신자)이 "우리 펜션 주차장 3자리 남았어"라고 해서 차를 3대만 보내는 겁니다.
- 혼잡 제어: 펜션 주차장은 100자리가 비어있지만, 명절이라 경부고속도로(인터넷 망) 전체가 주차장이 되었습니다. 차들이 가다가 서다를 반복합니다. 내비게이션(TCP)이 이걸 눈치채고 "야! 고속도로 꽉 막혔어! 시속 100km로 밟지 말고 시속 20km로 천천히 가!"라며 도로 전체의 붕괴를 막는 공공의 브레이크입니다.

[지연된 ACK]
    │
    ▼
[TCP 혼잡 제어]
    │
    └──▶ [혼잡 윈도우]

📢 섹션 요약 비유: ** 혼잡 제어는 뷔페에서 음식(데이터)을 쓸어 담으려는 손님에게, "당신 배(수신 버퍼)가 아무리 고파도, 지금 요리사(라우터)들이 파업 직전이니까 당장 접시 내려놓고 5분에 1개씩만 집어가라!"고 제지하는 식당 매니저의 위기관리 능력입니다.

Ⅱ. 아키텍처 및 핵심 원리

혼잡 제어가 돌아가는 큰 그림을 머릿속에 잡아야 다음 장의 알고리즘들이 이해된다.

1. 송신자의 뇌구조 (2개의 창문)

송신자는 데이터를 쏠 때 두 개의 눈치를 동시에 봐야 한다.

RWND (Receive Window): 수신자가 "나 이만큼 비었어"라고 헤더에 적어 보낸 빈 공간. (흐름 제어).
CWND (Congestion Window): "내가 찔러보니까 인터넷 도로 상태가 요 정도 되네?"라고 내 PC가 스스로 짐작하고 계산한 가상의 창문 크기. (혼잡 제어).

절대 규칙: 송신자는 패킷을 쏠 때, 무조건 **RWND와 CWND 중에서 "더 작은 값"**을 기준으로 삼아서 쏜다. 수신자 램이 100GB가 비어있어도, 도로가 1MB밖에 못 견딘다고 CWND가 계산되면 나는 눈물을 머금고 1MB씩만 찔끔찔끔 보내야 한다.

2. 인터넷이 막혔다는 걸 어떻게 알까? (혼잡 징후 탐지)

내 PC는 라우터가 아니니까 라우터 속을 들여다볼 수 없다. 오직 '영수증(ACK)'이 오는 꼴을 보고 눈치껏 때려 맞춘다.

완벽한 타임아웃 (RTO Expiration) - "심정지 상태"
- 내가 패킷을 쐈는데, 정해진 시간(Retransmission TimeOut)이 훌쩍 지나도록 아무 대답도 안 온다.
- 내 PC의 판단: "헐, 길이 완전히 아작나서 패킷이 형체도 없이 터졌구나! 최악의 혼잡 상황이다! 속도 0으로 곤두박질 쳐라!!"
3 중복 ACK (3 Dup-ACKs) - "가벼운 접촉 사고"
- 영수증은 제깍제깍 오는데, ACK 300, ACK 300, ACK 300 이렇게 똑같은 번호가 3번 연속으로 날아온다.
- 내 PC의 판단: "음, 대답이 오긴 오니까 길이 아예 꽉 막힌 건 아니네. 근데 300번 패킷 딱 한 놈만 가다가 옆 차선 차랑 부딪혀서(유실) 드랍됐나 보네. 가벼운 정체 상황이군! 속도를 절반으로만 깎자!"

 ┌─────────────────────────────────────────────────────────────┐
 │                혼잡 제어(Congestion Control)의 거시적 사이클       │
 ├─────────────────────────────────────────────────────────────┤
 │                                                             │
 │   1. 출발! (Slow Start)                                      │
 │      - 도로가 어떤지 모르니까 아주 천천히 1개 쏘고, 2개 쏘고 조심조심 출발.│
 │                                                             │
 │   2. 가속! (Congestion Avoidance)                            │
 │      - 오? 뻥 뚫렸네? 영수증 잘 오네? 액셀 밟자! 속도 서서히 증가!       │
 │                                                             │
 │   3. 사고 발생! (Packet Drop 감지)                              │
 │      - 앗 ㅆ... 톨게이트 꽉 차서 내 패킷 죽음! 영수증이 안 오거나 징징댐! │
 │                                                             │
 │   4. 급브레이크! (Window Size 삭감)                            │
 │      - 타임아웃 났어?! ──▶ 속도 1로 완전 초기화! 찌그러져 있자...     │
 │      - 3 Dup-ACK 났어?! ──▶ 속도 절반으로만 줄이자! (Fast Recovery) │
 │                                                             │
 │   ▶ "이 짓을 평생 반복하며 톱니바퀴 모양(Sawtooth) 그래프를 그린다."   │
 └─────────────────────────────────────────────────────────────┘

3. 왜 이게 위대한가?

누가 시키지도 않았는데 전 세계 50억 대의 컴퓨터가 각자 자기 패킷이 유실될 때마다 스스로 브레이크를 밟아준다(Distributed Control). 이 거대한 분산 통제 이타주의 덕분에 우리는 지금 넷플릭스와 유튜브를 끊김 없이 보고 있는 것이다.

📢 섹션 요약 비유: ** TCP 혼잡 제어는 시각장애인이 **"지팡이(패킷)로 앞을 두드리며 걷는 것"**과 같습니다. 툭탁툭탁 두드려보고 걸림돌이 없으면 걸음을 재촉(속도 증가)하지만, 지팡이가 돌부리(패킷 유실)에 부딪히는 순간 즉각 걸음을 멈추고 웅크려서(속도 반토막) 자신이 낭떠러지로 떨어지는 것을 스스로 막아냅니다.

Ⅲ. 비교 및 연결

TCP 혼잡 제어를 볼 때는 앞뒤 개념과의 경계를 함께 봐야 전체 흐름이 선명해진다. 지연된 ACK가 기반 조건을 만든다면, TCP 혼잡 제어는 그 위에서 핵심 메커니즘을 구현하고, 혼잡 윈도우는 이를 더 확장된 적용 단계로 연결한다. 따라서 단일 정의보다 신뢰성과 지연에 어떤 차이를 만드는지 비교하는 것이 중요하다.

관점	선행 개념	현재 개념	확장 개념
초점	지연된 ACK의 기반 정리	TCP 혼잡 제어의 핵심 동작	혼잡 윈도우의 확장 적용
자원 관점	기본 조건 확보	신뢰성 최적화	규모와 범위 확대
판단 포인트	도입 가능성 확인	현재 메커니즘의 적합성 판단	운영·확장 전략 연결

📢 섹션 요약 비유: TCP 혼잡 제어는 비슷한 기술들 사이의 차선을 구분하는 분기점과 같다. 어디서 갈라지는지 알아야 헷갈리지 않는다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서는 TCP 혼잡 제어를 단독 개념으로 외우기보다 어떤 병목을 줄이기 위한 선택인지 먼저 따져야 한다. 특히 지연된 ACK 수준의 기본 대책으로 충분한지, 아니면 TCP 혼잡 제어가 제공하는 메커니즘이 실제로 필요한지 구분해야 한다. 이후 확장 단계에서는 혼잡 윈도우와 같은 후속 기술, 자동화 체계, 표준 호환성까지 함께 검토해야 한다.

실무 체크리스트

현재 문제의 핵심이 신뢰성 부족인지, 지연 악화인지 먼저 분리한다.
TCP 혼잡 제어가 추가하는 복잡도와 운영 이득이 균형을 이루는지 확인한다.
도입 후에는 인접 기술인 혼잡 윈도우와의 연계 방식을 함께 검증한다.

안티패턴

TCP 혼잡 제어의 장점만 보고 트래픽 패턴이나 운영 비용을 무시한 채 과도 도입하는 설계
지연된 ACK와의 경계를 정리하지 않아 중복 투자나 정책 충돌을 만드는 설계
📢 섹션 요약 비유: TCP 혼잡 제어를 실제로 쓰는 판단은 도구 상자를 고르는 일과 비슷하다. 좋아 보이는 도구보다 지금 문제에 맞는 도구가 중요하다.

Ⅴ. 기대효과 및 결론

TCP 혼잡 제어는 전송 계층을 이해할 때 핵심 축을 잡아 주는 개념이다. 올바르게 적용하면 신뢰성 개선과 구조적 단순화에 기여하지만, 조건을 잘못 잡으면 오히려 복잡도와 운영 부담이 커질 수 있다. 앞으로는 혼잡 윈도우, 적응형 저지연 전송, 자동화 운영과의 결합을 통해 더 정교하게 발전할 가능성이 크다. 따라서 이 개념은 정의 자체보다 “언제 쓰고 언제 다른 방법으로 넘길 것인가”의 관점으로 기억하는 것이 좋다. 향후에는 적응형 저지연 전송 같은 자동화 흐름과 결합되어 더 정교한 형태로 확장될 가능성이 크다.

📢 섹션 요약 비유: TCP 혼잡 제어는 큰 흐름 속에서 기억해야 오래 남는다. 지금의 장점과 다음 확장 방향을 같이 보면 전체 그림이 선명해진다.

📌 관련 개념 맵

개념	연결 포인트
지연된 ACK	현재 개념이 등장하기 전에 갖춰야 할 배경이나 인접 선행 개념이다.
세그먼트 (Segment)	전송 계층이 다루는 기본 단위다.
흐름 제어 (Flow Control)	수신자 처리 속도를 넘지 않게 조절한다.
혼잡 윈도우	현재 개념이 확장되거나 적용 단계로 이어질 때 자주 함께 언급된다.

📈 관련 키워드 및 발전 흐름도

[선행 개념: 지연된 ACK]
    │
    ▼
[현재 개념: TCP 혼잡 제어]
    │
    ├──▶ [확장 A: 혼잡 윈도우]
    └──▶ [확장 B: 적응형 저지연 전송]

TCP 혼잡 제어는 지연된 ACK에서 출발해 현재 메커니즘을 정교화하고, 이후 혼잡 윈도우와 적응형 저지연 전송 같은 확장 흐름으로 이어진다고 보면 기억이 오래간다.

👶 어린이를 위한 3줄 비유 설명

물건을 보낼 때 받는 사람이 너무 빨리 받으면 놓칠 수 있어요.
이 개념은 천천히 보낼지, 다시 보낼지, 길이 막히면 멈출지를 정해줘요.
그래서 멀리 보내도 덜 잃어버리고 더 안정적으로 도착해요.