항상 문제는 TCP_NODELAY다

• 분산 시스템의 지연(latency) 문제를 디버깅할 때 가장 먼저 확인해야 하는 항목이 TCP_NODELAY 설정임
• Nagle 알고리듬은 1984년 RFC896에서 제안된 방식으로, 작은 패킷 전송 시 TCP 헤더 오버헤드를 줄이기 위해 설계됨
• 그러나 지연된 ACK(delayed ACK) 메커니즘과 결합될 때, 데이터 전송이 ACK 수신까지 지연되어 지연 민감형 애플리케이션의 성능을 악화시킴
• 현대 데이터센터 환경에서는 RTT가 매우 짧고, 대부분의 시스템이 이미 큰 메시지를 전송하므로 Nagle 알고리듬의 이점이 거의 사라짐
• 따라서 현대 분산 시스템에서는 TCP_NODELAY를 기본으로 활성화해야 하며, Nagle 알고리듬은 더 이상 필요하지 않음

Nagle 알고리듬의 배경

• 1984년 John Nagle의 RFC896은 키보드 입력처럼 작은 데이터 전송 시 발생하는 40바이트 헤더 대비 1바이트 데이터의 4000% 오버헤드 문제를 해결하기 위해 제안됨
  • 당시 문제는 사용자가 한 글자씩 입력할 때마다 작은 패킷이 전송되어 네트워크 효율이 낮아지는 현상
  • 해결책은 이전 데이터가 ACK되지 않은 상태에서는 새로운 세그먼트를 전송하지 않도록 제한하는 방식
• 이 접근은 당시 네트워크 환경에서는 효과적이었으나, 지연 시간(latency) 이 중요한 현대 시스템에는 부적합

Nagle 알고리듬과 Delayed ACK의 상호작용

• Delayed ACK(RFC813, RFC1122)는 수신 측이 즉시 ACK를 보내지 않고, 응답 데이터가 생기거나 타이머가 만료될 때까지 ACK를 지연시키는 방식
• Nagle 알고리듬은 ACK를 기다리며 전송을 멈추고, delayed ACK는 ACK를 늦추므로 양쪽이 서로 기다리는 교착 상태가 발생
• John Nagle 자신도 이 조합을 “끔찍한 조합”이라 표현하며, 두 기능이 독립적으로 도입되었지만 함께 사용될 때 지연을 유발한다고 지적

현대 환경에서의 문제점

• 데이터센터 내 RTT는 약 500μs, 동일 리전 내에서도 수 밀리초 수준으로 매우 짧음
• 이런 환경에서 한 RTT만큼 전송을 지연하는 것은 성능 손실로 이어짐
• 또한 현대 분산 시스템은 TLS, 직렬화, 프로토콜 오버헤드 등으로 인해 이미 충분히 큰 메시지를 전송하므로, 단일 바이트 패킷 문제는 거의 존재하지 않음
• 작은 메시지 최적화는 이제 애플리케이션 계층에서 처리되고 있음

TCP_NODELAY의 필요성

• 지연에 민감한 분산 시스템에서는 TCP_NODELAY를 활성화해 Nagle 알고리듬을 비활성화하는 것이 권장됨
  • 이는 “비효율적”이거나 “잘못된 설정”이 아니라, 현대 하드웨어와 트래픽 특성에 맞는 선택
• 저자는 TCP_NODELAY가 기본값이 되어야 한다고 주장
  • 일부 “write() 호출마다 전송”하는 코드가 느려질 수 있으나, 그런 코드는 근본적으로 수정되어야 함

기타 관련 옵션

• TCP_QUICKACK 옵션은 ACK 지연을 줄이지만, 이식성 문제와 비일관적 동작으로 인해 근본 해결책이 아님
• 핵심 문제는 커널이 애플리케이션이 의도한 시점보다 데이터를 오래 보유하는 것이며, write() 호출 시 즉시 전송되어야 함

결론

• Nagle 알고리듬은 과거 네트워크 효율을 높이기 위한 훌륭한 발명이었으나,
  현대의 고속 네트워크와 분산 시스템 환경에서는 오히려 지연을 초래하는 구시대적 기능
• 따라서 TCP_NODELAY를 항상 활성화하는 것이 현대 시스템 설계의 기본 원칙으로 제시됨