작은 TCP 메시지 지연이 튈 때 Nagle과 지연 ACK를 의심하되 TCP_NODELAY를 무조건 켜면 안 되는 이유는 무엇인가요?

Nagle 알고리즘은 아직 확인되지 않은 작은 데이터를 한꺼번에 보내 패킷 수를 줄이려 하고, 지연 ACK는 수신자가 ACK를 잠시 묶어 보냅니다. 애플리케이션이 헤더와 본문을 작은 쓰기로 나누고 상대가 다음 조각을 기다리는 프로토콜이면 두 정책이 상호작용해 작은 메시지의 지연이 튈 수 있습니다. 그러나 같은 모양은 이벤트 루프 정체, TLS 레코드 버퍼링, 사용자 공간 배치에서도 생기므로 TCP_NODELAY를 먼저 켜고 결론 내리지는 않겠습니다.

어디에서 기다리는지 측정한다

write나 send를 호출한 시각은 데이터가 상대 애플리케이션에 도착한 시각이 아닙니다. 애플리케이션이 프레임을 만든 시각, 커널 송신 큐에 들어간 시각, 패킷 캡처의 세그먼트 전송 시각, 상대 ACK 시각, 상대 애플리케이션이 응답을 만든 시각을 구분해야 합니다. 송신 호출 뒤 커널에 데이터가 바로 들어갔는데 패킷이 늦다면 Nagle·혼잡·스케줄링을 보고, 호출 자체가 늦으면 애플리케이션 배치나 이벤트 루프를 봅니다. 이를 계층별 지연 분해(layered latency decomposition)라고 부르겠습니다.

작은 요청을 의도적으로 두 번 나눠 쓰는 실험, 애플리케이션에서 한 프레임으로 모아 쓰는 실험, TCP_NODELAY를 켠 실험을 각각 수행합니다. NODELAY가 지연을 줄였지만 패킷 수·인터럽트·CPU·대역폭이 증가하면 모든 연결에 적용하는 것이 정답은 아닙니다. 인터랙티브 입력처럼 한 바이트의 지연이 사용자 경험을 좌우하는 연결은 비용을 감수할 수 있지만, 대량 배치·스트리밍은 묶어 보내는 편이 효율적입니다.

TCP 옵션과 프레이밍은 별개다

NODELAY는 Nagle의 작은 쓰기 지연을 줄이는 옵션이지 TCP에 메시지 경계를 추가하지 않습니다. 한 번의 send가 한 세그먼트가 되거나 한 번의 recv로 돌아온다는 보장도 없습니다. 수신자는 길이 헤더·구분자·고정 길이 같은 프레이밍을 계속 처리해야 합니다. TLS를 쓰면 TLS 레코드 버퍼링·암호화·TCP 세그먼트 경계가 다시 겹치므로 패킷 캡처만 보고 애플리케이션 메시지 단위를 추론하지 않겠습니다.

애플리케이션 배치를 택한다면 최대 대기 시간을 두어 작은 메시지가 무한히 기다리지 않게 합니다. 측정은 동일 부하에서 p95·p99, 패킷 수, CPU, 대역폭, 재전송, 연결별 응답 분포로 비교합니다. 지연이 특정 크기나 일정 시간 간격에서만 튄다면 Nagle·지연 ACK를 후보로 삼되, 수신자가 데이터를 읽는 시점과 ACK 정책, 서버 큐도 함께 확인합니다. 옵션을 바꾼 뒤에도 부분 수신·백프레셔·프레이밍은 그대로 필요합니다.

Nagle과 지연 ACK의 상호작용은 모든 작은 메시지를 일정하게 늦추는 단일 규칙이 아니라, 아직 확인되지 않은 작은 세그먼트와 수신자의 ACK 생성 조건이 만나는 상황에서 나타납니다. 쓰기를 하나의 프레임으로 합치면 NODELAY 없이도 지연과 패킷 수를 함께 줄일 수 있는 경우가 많습니다. 반대로 인터랙티브 요청을 지나치게 배치하면 애플리케이션이 만든 대기 시간이 커집니다. 따라서 옵션을 바꾸기 전에 쓰기 호출 수, 프레임 완성 시각, ACK 간격을 기록해 어느 계층이 대기했는지 확인하겠습니다.

수신자가 ACK를 언제 보내는지는 운영체제와 세그먼트 패턴의 영향도 받으므로 특정 밀리초 값을 프로토콜 보장으로 하드코딩하지 않겠습니다. 애플리케이션은 프레임을 완성한 뒤 한 번에 쓰고, 필요하면 최대 대기 타이머로 flush합니다. 그 후 NODELAY 실험에서 개선이 없으면 다른 계층의 대기를 먼저 고치겠습니다.