TCP 혼잡 제어 기초: 인터넷이 막힐 때 속도를 조절하는 알고리즘

인터넷이 막힐 때 TCP 혼잡 제어가 보이는 증상

TCP 혼잡 제어는 인터넷이 붐비는 구간에서 전송 속도를 스스로 올리고 내리며, "끊김·지연·재전송"이 섞여 나타날 때 원인을 구분하는 기준이 된다.

파일 다운로드가 어느 순간부터 들쭉날쭉하거나, 같은 서버인데도 시간대에 따라 응답이 느려지는 경우가 있다.

서버 CPU는 여유인데도 처리량이 안 나오고, 재시도나 타임아웃이 늘어나는 경우도 있다.

이런 상황을 디스크나 애플리케이션 문제로만 보면 방향이 틀어질 수 있으므로, TCP 혼잡 제어가 "무엇을 혼잡으로 보고 어떻게 반응하는지"부터 잡는 편이 빠르다.

핵심 개념 1: 혼잡 윈도우(cwnd)와 전송 속도

혼잡 윈도우(cwnd)는 송신자가 네트워크에 "동시에 떠 있게" 허용하는 미확인(ACK 미수신) 데이터의 양을 제한하는 값이다.

핵심 특징은 전송 속도가 대략적으로 "cwnd / RTT"의 형태로 결정된다는 점이다. cwnd가 커지고 RTT가 안정적이면 처리량이 올라간다.

또 다른 특징은 cwnd가 한 번에 무한히 커지지 않고, 단계적으로 증가하다가 혼잡 신호를 만나면 감소하는 식으로 움직인다는 점이다.

주의점은 cwnd가 크다고 항상 빠르지 않다는 점이다. 수신 윈도우(rwnd), 애플리케이션 송신 속도, NIC/OS 큐, 디스크 I/O가 더 먼저 제한이 될 수 있다.

또한 RTT가 증가하는 순간에는 cwnd가 같아도 체감 속도가 떨어지며, 사용자 입장에서는 "갑자기 느려졌다"로 느껴지기 쉽다.

TCP 혼잡 제어를 구성하는 cwnd·RTT·재전송 관계

핵심 개념 2: 혼잡 신호(손실·지연)와 알고리즘의 선택

TCP 혼잡 제어 알고리즘은 네트워크가 혼잡하다는 "신호"를 보고 cwnd를 조절한다.

대표적인 혼잡 신호는 패킷 손실(재전송 발생, 중복 ACK, RTO)과 지연 증가(RTT 상승, 큐 적체)다.

손실 기반 계열은 손실을 혼잡의 강한 신호로 보고, 손실이 보이면 cwnd를 줄이는 방향으로 움직인다. 지연 기반 또는 모델 기반 계열은 RTT 변화와 대역폭 추정을 적극 활용해 큐 적체를 줄이려는 방향으로 설계되기도 한다.

주의점은 "손실이 없으면 혼잡이 아니다"로 단정하면 안 된다는 점이다. 큐가 길어지면 손실 없이도 RTT만 커져 체감이 느려질 수 있다(버퍼블로트 형태).

또한 알고리즘 이름만으로 성능을 단정하기 어렵다. 동일 알고리즘이라도 RTT, 링크 대역폭, 라우터 큐 정책, 무선 구간 유무에 따라 결과가 크게 달라진다.

다음 비교표는 TCP 혼잡 제어를 이해할 때 자주 헷갈리는 지점을 정리한 것이다.

항목	손실 기반(예: Reno/CUBIC 계열)	지연/모델 기반(예: BBR 계열)
혼잡을 감지하는 단서	재전송, 중복 ACK, 타임아웃 같은 손실 징후를 중심으로 본다.	RTT 변화와 대역폭 추정으로 큐 적체를 간접적으로 본다.
느려짐이 체감되는 형태	손실이 발생하면 급격히 속도가 떨어졌다가 다시 올라가는 파형이 나오기 쉽다.	큐를 짧게 유지하려는 경우 지연은 안정적이지만 환경에 따라 처리량이 흔들릴 수 있다.
흔한 오해	손실만 없으면 항상 안정적이라고 착각하기 쉽다.	지연이 낮으면 언제나 처리량도 높다고 착각하기 쉽다.

YES/NO 체크리스트로 '혼잡'부터 가르기

• YES/NO: 같은 서버·같은 파일인데 시간대에 따라 속도가 크게 출렁이는가?
• YES/NO: 재전송(retransmission) 지표가 평소보다 눈에 띄게 늘었는가?
• YES/NO: 손실은 거의 없는데 RTT만 계속 올라가며 응답이 둔해지는가?
• YES/NO: 서버 CPU/디스크는 여유인데 네트워크 송수신이 "톱니 모양"으로 끊기는가?
• YES/NO: 특정 구간(와이파이·VPN·해외 회선)에서만 유독 느려지는가?

첫째와 둘째가 YES면 혼잡(손실/재전송) 가능성을 먼저 본다. 셋째가 YES면 큐 적체로 인한 지연 증가를 의심한다.

넷째가 YES면 애플리케이션 처리 문제가 아니라 전송 제어(윈도우/ACK/큐)의 제약일 가능성이 커진다.

병목을 찾는 실전 점검 절차와 예시

TCP 혼잡 제어 관점의 점검은 "손실이 있는지"와 "큐가 쌓이는지"를 분리해 확인하는 순서가 효율적이다.

1. 알고리즘 확인: 혼잡 제어 알고리즘을 확인한다(경로: /proc/sys/net/ipv4/tcp_congestion_control / 체크 포인트: 현재 값이 무엇인지 기록한다).
2. RTT와 cwnd: RTT와 cwnd를 본다(경로: ss -ti 또는 ss -tin / 체크 포인트: rtt, cwnd, pacing 관련 값이 비정상적으로 튀는지 본다).
3. 재전송 신호: 재전송 신호를 확인한다(경로: nstat -az 또는 /proc/net/netstat / 체크 포인트: TCPRetransSegs, TCPLostRetransmit 같은 항목이 증가하는지 본다).
4. 링크 오류 분리: 인터페이스 오류와 드롭을 분리한다(경로: ip -s link / 체크 포인트: RX/TX dropped, errors가 증가하면 혼잡이 아니라 링크 문제일 수 있다).
5. 큐 적체: 큐 적체를 확인한다(경로: tc -s qdisc / 체크 포인트: backlog, drops가 쌓이면 버퍼/큐 병목 가능성을 본다).
6. 검증 재현: 검증 트래픽으로 재현한다(경로: mtr 또는 ping으로 RTT 변동 확인 / 체크 포인트: 피크 시간대에 RTT가 함께 오르는지 본다).

실전 예시로 "다운로드는 되는데 초반만 빠르고 중간부터 느려지는" 상황을 가정한다.

서버에서 연결 상태를 보면 다음과 같은 형태가 나올 수 있다(예시는 민감정보를 제거한 샘플이다).

ss -ti 예시(샘플)
rtt: 92.4/18.1  cwnd: 14  ssthresh: 10
retrans: 4/320  lost: 2  pacing_rate 8.2Mbps
skmem:(r0,rb87380,t0,tb262144,f0,w0,o0,bl0)

rtt가 높고 변동 폭도 크며(recent RTT 분산), retrans가 보이므로 손실 기반 혼잡 신호가 이미 나타난 상태로 해석할 수 있다.

이때 "서버를 더 빠르게 만들기"보다 먼저 할 일은 손실이 어디서 생기는지 구간을 좁히는 것이다. 동일 시간대에 ip -s link에서 드롭이 늘지 않는데 retrans만 늘면, 네트워크 경로 중간 혼잡 가능성이 커진다.

반대로 ip -s link에서 errors/dropped가 함께 늘면 NIC, 케이블, 스위치 포트, MTU 불일치 같은 링크 문제를 먼저 의심하는 편이 맞다.

큐 적체까지 동시에 의심되면 tc -s qdisc에서 backlog가 계속 쌓이는지 확인하고, 필요하면 큐 정책과 버퍼 크기 조정을 검토한다.

TCP 혼잡 제어 기반 병목 판별 6단계 흐름

결론

TCP 혼잡 제어는 혼잡 신호(손실·지연)를 근거로 cwnd를 조절해 네트워크를 망가뜨리지 않는 범위에서 속도를 맞춘다.

속도가 느려졌을 때는 알고리즘 이름부터 단정하지 말고, RTT·cwnd·재전송·드롭·큐 적체를 분리해 "혼잡인지 링크 문제인지"부터 가르는 편이 재현성이 높다.

점검 순서를 잡아 두면 서버·디스크·애플리케이션 병목과 TCP 혼잡 제어 병목이 섞여 보이는 상황에서도 원인 좁히기가 쉬워진다.

연계 주제로는 RTT와 p95/p99 지연의 관계, 버퍼블로트와 큐 관리(qdisc), UDP/QUIC의 혼잡 제어 차이가 이어진다.

FAQ

Q1. TCP 혼잡 제어가 있으면 네트워크가 절대 막히지 않는가

그렇지 않다. 혼잡 제어는 막힘을 "완전히 없애는 장치"가 아니라, 막힘이 생겼을 때 전송 속도를 줄여 전체를 더 나빠지지 않게 만드는 방식이다.

경로 중간 장비의 큐 정책이나 무선 구간 품질이 나쁘면 혼잡 신호가 더 자주 발생할 수 있다.

Q2. 혼잡 제어 문제와 서버 처리 문제를 가장 빨리 구분하는 방법은 무엇인가

서버 CPU/디스크 여유가 있는데 RTT 상승, 재전송 증가, 큐 적체(backlog)가 같이 보이면 TCP 혼잡 제어 관점의 병목 가능성이 커진다.

반대로 RTT는 안정적인데 애플리케이션 처리 시간이 늘어나는 형태면 서버 내부 병목을 먼저 본다.

Q3. 혼잡 제어 알고리즘을 바꾸면 항상 속도가 좋아지는가

항상 그렇지 않다. 알고리즘은 환경 의존성이 커서, RTT·대역폭·큐 정책·무선 여부에 따라 유리한 선택이 달라진다.

변경 전후에는 동일 조건에서 RTT, 재전송, 처리량을 함께 비교해 실제 개선인지 확인하는 절차가 필요하다.