TCP 전송이 느려졌는데 수신 앱도 느리고 네트워크에도 손실이 보입니다. 흐름 제어와 혼잡 제어는 무엇을 각각 제한하며 어떤 지표로 원인을 구분하나요?

흐름 제어는 수신 호스트가 자신의 버퍼와 애플리케이션 소비 속도로 감당할 수 있는 양보다 송신자가 많이 보내지 않게 하고, 혼잡 제어는 네트워크 경로의 공유 링크와 큐가 감당할 수 있는 전송률을 추정합니다. 전자는 수신 윈도우, 후자는 혼잡 윈도우와 손실·RTT 신호에 영향을 받습니다. 실제 송신 가능량은 애플리케이션이 제공하는 데이터, 수신 윈도우, 혼잡 윈도우 중 더 제한적인 조건과 큐 상태에 좌우됩니다.

수신자 병목과 경로 병목

수신 애플리케이션이 느리게 읽으면 수신 버퍼가 차고 TCP 수신 윈도우가 줄어듭니다. 송신자는 네트워크가 비어 있어도 그 윈도우만큼만 데이터를 보낼 수 있습니다. 이때 송신 측 애플리케이션 스레드를 늘리는 것은 수신 앱의 소비를 빠르게 하지 않으며, 소켓 버퍼를 무작정 늘리면 메모리에 긴 큐만 쌓일 수 있습니다. 수신 버퍼 점유율, 읽기 지연, 수신 윈도우, 송신 측 앱 큐를 같은 시간축으로 보겠습니다.

반대로 네트워크 중간 링크가 포화되면 패킷 손실·재전송·RTT 상승이 나타나고 송신 TCP는 혼잡 윈도우를 줄입니다. 수신 앱이 빠르게 읽어도 경로의 대역폭과 공유 큐가 병목이면 송신률이 제한됩니다. 다만 애플리케이션 송신 큐의 증가가 원인인지 느린 TCP 전송의 결과인지는 미리 단정할 수 없습니다. 큐 증가 시각을 수신 윈도우·혼잡 윈도우·ACK 간격·재전송과 맞춰 선후 관계를 확인하겠습니다. 이를 흐름 제어(flow control)와 혼잡 제어(congestion control)의 분리 진단이라고 부릅니다.

버퍼와 검증

수신 윈도우가 작고 수신 프로세스 소비 지연이 커졌다면 수신자 경로를 우선 봅니다. 수신 윈도우는 충분한데 RTT·재전송·혼잡 윈도우가 함께 변하면 경로 혼잡을 우선 조사합니다. 앱 큐만 먼저 증가하면 생산자와 소비자의 불균형을 볼 수 있지만, TCP 아래 지연 때문에 뒤늦게 쌓였을 가능성도 남아 있습니다. 대역폭·RTT가 큰 경로에서 버퍼가 너무 작으면 링크를 채우지 못하고, 너무 크면 bufferbloat로 지연이 늘 수 있습니다.

테스트는 수신자를 의도적으로 느리게 하는 경우와 네트워크에 손실·지연을 주는 경우를 분리합니다. 윈도우·RTT·재전송·앱 큐를 동일한 요청 구간에 기록하고, 조정 뒤 처리량뿐 아니라 p99 지연과 큐 길이도 비교하겠습니다. 소켓 버퍼나 송신 워커를 늘리는 결론은 이 증거가 어느 경로를 가리키는지 확인한 뒤 내리겠습니다.

추가 조건과 판단

예를 들어 수신 앱이 읽기를 멈춰 윈도우가 0이 되면 경로 대역폭이 충분해도 송신 데이터는 진행할 수 없습니다. TCP의 zero-window probe는 수신 윈도우가 다시 열렸는지 확인하기 위한 것이지 애플리케이션의 적체를 처리하는 장치가 아닙니다. 반대로 수신 윈도우가 큰데 경로 손실로 혼잡 윈도우가 줄었다면 수신 버퍼만 늘려도 해결되지 않습니다.

대역폭과 RTT의 곱은 경로를 채우기 위해 필요한 비행 중 데이터량을 가늠하는 대역폭-지연 곱(bandwidth-delay product)입니다. 예를 들어 초당 10MB를 보낼 수 있고 왕복이 0.1초라면 약 1MB를 확인받기 전까지 보낼 여유가 있어야 그 전송률을 활용할 수 있습니다. 이는 특정 소켓 버퍼를 반드시 그 값으로 설정하라는 공식이 아니라 경로와 윈도우 크기를 비교하는 단서입니다. 손실이나 수신자 처리 능력이 다르면 실제 전송률은 더 낮아집니다.

혼잡 신호도 손실만 있는 것은 아닙니다. ECN을 지원하는 경로는 패킷을 버리기 전에 혼잡을 표시할 수 있고, 알고리즘별로 RTT나 대역폭 추정을 활용하는 방식이 다릅니다. 따라서 손실이 없다고 혼잡이 없다는 뜻은 아니며 실제 사용 알고리즘과 큐 지연을 함께 확인하겠습니다.