Hacker News 의견

요약:

• Nagle의 알고리즘은 배치 쓰기를 시도한 것으로, 하드웨어나 네트워크, 애플리케이션, 사용 사례에 상관없이 배치 쓰기가 더 나은 경우가 있음
• 오늘날의 많은 컴퓨팅은 배치 쓰기를 사용하며, QUIC와 같은 새로운 고수준 프로토콜도 쓰기 배치를 수행하여 TCP의 독립적인 연결 및 오류 처리를 사용자 공간으로 이동시킴
• 네트워크가 포화 상태가 되면, Nagle의 알고리즘은 QUIC 수정의 형태로 애플리케이션 코드에서 더 깊이 반환될 것임
• Nagle의 알고리즘은 작은 패킷으로 인해 초당 패킷(PPS)이 포화 상태가 되는 경우에도 유용함
• Nagle의 알고리즘은 일부 워크로드에는 잘 작동하지 않으므로, 엔지니어가 소켓을 만들 때 강제로 설정해야 하는 것이 좋음
• TCP_QUICKACK 소켓 옵션이나 /proc/sys/net/ipv4/tcp_delack_min 및 /proc/sys/net/ipv4/tcp_ato_min을 사용하여 지연 ACK를 비활성화할 수 있음
• 대역폭이 제한된 세상에서 TCP 패킷을 모든 바이트에 대해 보내는 것은 대역폭을 낭비하므로, Nagle의 알고리즘이 필요함
• 애플리케이션 소스에 액세스할 수 없는 경우 TCP_NODELAY를 활성화하는 좋은 방법은 아직 없음
• Go와 같은 최신 언어는 기본적으로 TCP_NODELAY를 활성화하므로 이 문제가 발생하지 않음
• 애플리케이션이 TCP 스택에게 대화형 쉘이라는 것을 알려줄 수 있는 방법이 있다면, TCP_NODELAY를 기본적으로 꺼두고 해당 애플리케이션에 대해서만 켤 수 있어 오버헤드를 줄일 수 있음