나글 알고리즘

Nagle's algorithm

Nagle 알고리즘은 네트워크를 통해 전송해야 하는 패킷 수를 줄임으로써 TCP/IP 네트워크의 효율성을 향상시키는 수단입니다.Ford Aerospace에서 일하는 동안 John Nagle에 의해 정의되었습니다.1984년에 IP/TCP 네트워크에서의 congestion 제어라는 타이틀로 코멘트 요구(RFC)로서 발행되었습니다. RFC896.

RFC에서는, 「소패킷의 문제」라고 불리는 것에 대해 설명하고 있습니다.이 문제에서는, 애플리케이션이 작은 청크로 데이터를 반복해 송신해, 사이즈는 1바이트 밖에 되지 않는 경우가 많습니다.TCP 패킷에는 40 바이트의 헤더(TCP의 경우 20 바이트, IPv4의 경우 20 바이트)가 있기 때문에, 1 바이트의 유용한 정보를 얻기 위한 41 바이트의 패킷이 생성되어 오버헤드가 커집니다.이 상황은 대부분의 키 누르기에서 즉시 전송되는1 바이트의 데이터가 생성되는 Telnet 세션에서 자주 발생합니다.게다가 저속 링크에서는, 이러한 패킷이 동시에 전송 되어 congestion의 붕괴가 발생할 가능성이 있습니다.

Nagle의 알고리즘은 다수의 작은 발신 메시지를 조합하여 한번에 송신함으로써 동작합니다.구체적으로는, 송신측이 확인 응답을 수신하지 않은 송신 패킷이 있는 한, 송신측은, 완전한 패킷의 값이 출력될 때까지 출력을 버퍼링 해, 출력을 동시에 송신할 수 있도록 할 필요가 있습니다.

알고리즘.

RFC에서는 알고리즘을 다음과 같이 정의하고 있습니다.

는, 유저로부터 새로운 발신 데이터가 착신했을 때에, 이전에 송신된 데이터가 확인 응답되지 않은 채로 있는 경우, 새로운 TCP 세그먼트의 송신을 금지합니다.

여기서 MSS는 최대 세그먼트사이즈, 이 접속으로 송신할 수 있는 최대 세그먼트사이즈, 윈도사이즈는 현재 승인되지 않은 데이터의 허용 가능한 창입니다.이것은 의사 코드로[citation needed] 다음과 같이 기술할 수 있습니다.

전송할 새 데이터가 있는 경우 창 크기가 mss MSS이고 사용 가능한 데이터가 mss MSS인 경우 완전한 MSS 세그먼트를 전송하십시오. 그렇지 않으면 파이프에 확인되지 않은 데이터가 아직 있는 경우 확인을 받을 때까지 데이터를 버퍼에 큐에 넣고, 그렇지 않으면 데이터가 종료되면 즉시 종료됩니다.

지연 ACK와의 상호작용

이 알고리즘은 TCP에 거의 동시에 도입된 기능인TCP 지연 확인 응답(Delayed Acknowledgement)(지연 ACK)과 올바르게 상호 작용하지 않습니다.이 기능은 1980년대 초에 다른 그룹에 의해 도입되었습니다.두 알고리즘을 모두 유효하게 하면, TCP 접속에 대해서 2회 연속 기입을 실시하고 나서, 2회 기입을 실시한 데이터가 수신처에 도달할 때까지 읽기를 실시하지 않는 애플리케이션은, 최대 500 밀리초의 일정한 지연을 경험합니다.이것은 ACK 지연입니다.Nagle은 실시간애플리케이션용으로 이미 존재하기 때문에 기존에는 Nagle을 디세블로 하는 것이 더 쉽지만 둘 중 하나를 디세블로 하는 것이 좋습니다.

Nagle이 권장하는 솔루션은 응용 프로그램 쓰기를 버퍼업한 [1]후 버퍼를 플러시함으로써 알고리즘이 너무 이른 패킷을 전송하지 않도록 하는 것입니다.

유저 레벨의 솔루션은, 소켓상에서 기입과 기입의 시퀀스를 회피하는 것입니다.쓰기-읽기-쓰기-읽기-읽기-좋습니다.쓰기-쓰기-쓰기-쓰기 문제 없습니다.하지만 쓰기-쓰기-읽기는 치명적입니다.따라서 가능하면 TCP에 대한 작은 쓰기를 버퍼링하여 한 번에 모두 전송합니다.통상, 표준 UNIX I/O 패키지를 사용하고, 각 읽기를 실시하기 전에 기입 플래시를 실시합니다.

Nagle은 지연된 ACK를 "나쁜 생각"으로 간주합니다.이는 애플리케이션 계층이 보통 시간 [2]창 내에 응답하지 않기 때문입니다.일반적인 사용 사례에서는 "빠른" ACK는 많은 작은 [3]패킷만큼 오버헤드가 발생하지 않으므로 알고리즘 대신 "지연 ACK"를 비활성화할 것을 권장합니다.

Nagle 또는 지연 ACK 중 하나의 디세블화

TCP 의 실장은, 통상, 애플리케이션에 Nagle 알고리즘을 디세블로 하는 인터페이스를 제공합니다.이것은 통상, 「」라고 불립니다.TCP_NODELAY선택.Microsoft Windows 의 경우는,TcpNoDelay디폴트는 레지스트리 스위치가 결정합니다. TCP_NODELAY4.2의 TCP/IP 스택 이후에 존재하다1983년의 BSD, 많은 [4]후손이 있는 스택.

지연 ACK 를 디세블로 하는 인터페이스가 시스템간에 일관성이 없습니다.그TCP_QUICKACK플래그는 2001년(2.4.4) 이후 Linux에서 사용할 수 있으며 공식 인터페이스가 다음과 같은 Windows에서 사용할 수 있습니다.SIO_TCP_SET_ACK_FREQUENCY설정[5]TcpAckFrequencyWindows 레지스트리에서 1로 설정하면 [6]디폴트로 지연 ACK가 꺼집니다.

대용량 쓰기에 대한 부정적인 영향

Nagle 알고리즘은 모든 크기의 데이터 쓰기에 적용됩니다.만약 단일 쓰기의 데이터 수명이 2n-1 통해 보통 크기의 TCP세그먼트 부분적인 TCP세그먼트가 뒤따른다 2n 패킷을 원래의 Nagle알고리즘은 더 많은 데이터(패킷을 채우기 위해) 보낼 수도 있고, ACK는 이전의 패킷(모든 이전의 패킷은 네트워크 남아 있는지 여부를 나타내는 값)을 기다리며 지난 패킷을 보류할 것이다.[7]

요청 데이터가 패킷보다 클 수 있는 비파이프라인 정지 및 대기 요청-응답 애플리케이션 프로토콜에서는 요청자와 응답자 사이에 수백 밀리초의 지연이 인위적으로 발생할 수 있습니다.처음에는 파이프라인 이외의 Stop-and-Wait 프로토콜은 처음부터 고성능을 달성하도록 설계되지 않았을 수 있으므로 수백 밀리초의 추가 지연은 거의 차이가 없습니다.Nagle알고리듬에 대한 후 다듬고, Minshall의 Modification,[8]이라 불린 다음 승인을, 동기(그런 프로토콜은 여전히 그들의 디자인으로 한 messag으로 한정될 것이라고 그들을 위해 Nagle알고리듬을 제거하여 다음 보내기 전에 기다려야 짧은 메시지를 보내stop-and-wait는 프로토콜에서 이 문제를 해결했다.e네트워크 라운드 트립 시간별 교환).

일반적으로 Nagle의 알고리즘은 부주의한 응용 프로그램에 대한 방어일 뿐이므로 Nagle의 알고리즘을 비활성화해도 버퍼링을 적절하게 처리하는 대부분의 주의 깊게 작성된 응용 프로그램에 도움이 되지 않습니다.Nagle 알고리즘을 무효로 하면, 큰 패킷의 수가 적은 대신에, 애플리케이션이 네트워크상에서 동시에 다수의 작은 패킷을 송신할 수 있게 되어, 네트워크의 부하가 증가해, 애플리케이션의 퍼포먼스에 영향을 줄 수도 있고, 그렇지 않을 수도 있습니다.

실시간 시스템과의 상호작용

실시간 응답과 짧은 지연 시간이 요구되는 애플리케이션은 Nagle의 알고리즘에 대해 제대로 반응하지 못할 수 있습니다.네트워크 멀티플레이어 비디오 게임이나 리모트 제어 operating system의 마우스 이동등의 애플리케이션은, 즉시 액션이 송신되는 것을 상정하고 있습니다.그 한편, 알고리즘은 의도적으로 전송을 지연시켜, 지연 시간을 희생해 대역폭 효율을 높입니다.이 때문에, 저대역폭의 시간 의존 전송이 가능한 애플리케이션은, 통상,TCP_NODELAYNagle 지연 ACK [9]지연을 바이패스합니다.

또 다른 옵션은 UDP를 사용하는 것입니다.

운영 체제 구현

대부분의 최신 운영체제는 Nagle의 알고리즘을 구현합니다.AIX,[10] Linux 및 Windows 에서는 디폴트로 유효하게 되어 있습니다.소켓 단위로 비활성화하려면TCP_NODELAY선택.

레퍼런스

  1. ^ John Nagle (January 19, 2006), Boosting Socket Performance on Linux, Slashdot
  2. ^ Nagle, John. "Sigh. If you're doing bulk file transfers, you never hit that problem. (reply 9048947)". Hacker News. Retrieved 9 May 2018.
  3. ^ Nagle, John. "That fixed 200ms ACK delay timer was a horrible mistake. Why 200ms? Human reaction time. (reply 9050645)". Hacker News. Retrieved 9 May 2018.
  4. ^ tcp(4) – FreeBSD 커널 인터페이스 매뉴얼
  5. ^ "sockets - C++ Disable Delayed Ack on Windows". Stack Overflow.
  6. ^ "New registry entry for controlling the TCP Acknowledgment (ACK) behavior in Windows XP and in Windows Server 2003".
  7. ^ "TCP Performance problems caused by interaction between Nagle's Algorithm and Delayed ACK". Stuartcheshire.org. Retrieved November 14, 2012.
  8. ^ A Proposed Modification to Nagle’s Algorithm. I-D draft-minshall-nagle.
  9. ^ Bug 17868 – 일부 Java 응용 프로그램은 원격 X 연결에서 속도가 느립니다.
  10. ^ "IBM Knowledge Center". www.ibm.com.
  11. ^ "How would one disable Nagle's algorithm in Linux?". Stack Overflow.

외부 링크