TCP 혼잡 제어 이해하기 — 슬로우 스타트, AIMD, 혼잡 윈도

핵심 메시지

• TCP는 연결된 네트워크가 얼마나 크고 빠른지 미리 알 수 없기 때문에, 여러 패킷을 한 번에 보내는 '플라이트'와 보낼 양을 가늠하는 '혼잡 윈도'로 효율을 끌어올린다.
• 혼잡은 직접 측정할 수 없으므로, 패킷 손실 신호(삼중 중복 ACK나 타임아웃)와 왕복 시간(RTT)을 단서로 삼아 간접적으로 감지한다.
• 기본 원리는 AIMD, 즉 '덧셈식 증가·곱셈식 감소'다. 잘 도착하면 윈도를 한 칸씩 천천히 키우고, 손실이 보이면 절반으로 확 줄여 톱니 모양의 변화를 만든다.
• 시작 단계에서는 '슬로우 스타트'라는 이름과 달리 윈도를 1, 2, 4, 8…처럼 지수적으로 빠르게 키워 느린 초반 구간을 빨리 벗어난다.
• 현실의 트래픽은 교과서의 깔끔한 톱니와 달리 훨씬 복잡하며, 1980년대에 만들어진 TCP는 헤더 공간과 중간 장비 제약 탓에 크게 바꾸기 어렵지만 약 50년간 제 역할을 잘 해오고 있다.

쉽게 이해하기

이 영상은 앞 편에 이어 전송 계층의 TCP를 다루며, 이번에는 '신뢰성'을 넘어 '효율'에 초점을 맞춘다. 데이터 하나를 보내고 확인(ACK)을 기다린 뒤 다음을 보내는 방식은 너무 느리기 때문에, 여러 패킷을 한꺼번에 내보내고 받는 쪽이 누적 확인으로 '여기까지 다 받았다'고 알려주는 구조가 필요하다. 아직 확인받지 못한, 네트워크에 떠 있는 패킷들의 묶음을 '플라이트(flight)'라고 부른다.

문제는 보내는 쪽이 상대 네트워크의 크기를 알 수 없다는 점이다. 상대는 멜버른에 있을 수도, 베이징에 있을 수도, 바로 옆방에 있을 수도 있고, 연결은 거대한 광케이블일 수도 위성을 거치는 느린 경로일 수도 있다. 게다가 네트워크에는 '혼잡 측정기' 같은 것이 없으므로, TCP는 확인이 돌아오는 데 걸리는 왕복 시간(RTT)과 그 변동, 그리고 손실 신호를 보고 스스로 혼잡 여부를 판단해야 한다.

핵심 도구는 '혼잡 윈도(congestion window)'다. 이는 보내는 쪽과 받는 쪽이 '이 네트워크가 감당할 수 있다고 믿는 데이터 양'을 추적하는 값이다(이와 별개로, 받는 쪽의 처리 한계를 알리는 수신 윈도도 헤더에 담기지만 혼잡 윈도만큼 중요하지는 않다). 대부분의 TCP 변형은 단순하게 '패킷이 실제로 사라졌는가'라는 손실 신호를 본다. 중간 패킷이 빠지면 받는 쪽은 같은 ACK를 반복해 보내고, 같은 ACK가 세 번 더(삼중 중복) 들어오면 손실로 판단한다. 반대로 아무 응답도 없는 타임아웃은 더 심각한 혼잡 신호로 해석한다.

윈도를 키우고 줄이는 규칙이 AIMD(Additive Increase Multiplicative Decrease)다. 한 묶음이 모두 잘 돌아오면 윈도를 한 칸 늘리고(덧셈식 증가), 손실이 감지되면 절반으로 잘라낸다(곱셈식 감소). '65마일이 괜찮으니 70, 75로 올려보다가 문제가 생기면 확 줄이는' 식이어서, 이론적으로는 톱니 모양의 그래프가 그려진다. 감소를 빠르게 하는 이유는 이미 과부하된 네트워크를 계속 짓누르지 않기 위해서다.

다만 처음부터 한 칸씩 늘리면 큰 윈도에 도달하기까지 너무 오래 걸리므로, 초반에는 윈도를 1, 2, 4, 8, 16…처럼 두 배씩 키우는 '슬로우 스타트'를 쓴다. 이름과 달리 지수적으로 매우 빠르게 커지며, 첫 손실이 발생하면 AIMD 국면으로 넘어간다. 타임아웃을 얼마나 기다릴지는 측정한 RTT의 배수로 정하기 때문에, 같은 알고리즘이 데이터센터 내부든 지구 반대편이든 위성 연결이든 두루 동작한다. 진행자는 와이어샤크로 잡은 실제 트래픽을 보여주며, 가정용 메시 네트워크나 TLS 같은 요소 때문에 현실의 그래프는 교과서처럼 깔끔하지 않지만 우분투를 내려받는 사례에서는 슬로우 스타트의 모습이 실제로 또렷이 보였다고 설명한다.

주요 인사이트

• 혼잡 제어의 본질은 보수적인 증가와 공격적인 감소의 비대칭에 있다. 좋아질 때는 한 칸씩 조심스럽게 늘리지만, 나빠지는 신호가 오면 절반으로 단번에 줄여 과부하를 빠르게 해소한다.
• TCP는 헤더에 담을 수 있는 정보가 적어 '나는 1, 3, 5번은 받았고 2번이 빠졌다'처럼 복잡한 보고를 할 수 없다. 그래서 같은 ACK를 반복하는 식의 최소한의 신호로 손실을 알린다.
• 타임아웃 기준을 고정값이 아니라 측정된 RTT의 배수로 잡는 설계 덕분에, 왕복 시간이 크게 다른 환경에서도 같은 알고리즘이 무리 없이 작동한다.
• TCP에는 '맛(flavor)'이라 불리는 여러 변형이 있고, 손실에 어떻게 반응할지를 다르게 정한다. 오늘날 윈도우·맥·리눅스 등 대부분은 Cubic이라는 변형을 널리 사용한다.
• TCP는 1980년대에 처음으로 '동작한' 프로토콜이고, 헤더 공간 제약과 중간 장비·방화벽의 감시 때문에 함부로 손대기 어렵다. 크게 바뀌지 못한 채로도 약 50년간 복잡한 현실을 잘 감당해 왔다.

자주 묻는 질문

관련 AI 소식