| 词条 | Nagle's algorithm |
| 释义 |
Nagle's algorithm is a means of improving the efficiency of TCP/IP networks by reducing the number of packets that need to be sent over the network. It was defined by John Nagle while working for Ford Aerospace. It was published in 1984 as a Request for Comments (RFC) with title Congestion Control in IP/TCP Internetworks (see RFC 896). The RFC describes what he called the "small-packet problem", where an application repeatedly emits data in small chunks, frequently only 1 byte in size. Since TCP packets have a 40-byte header (20 bytes for TCP, 20 bytes for IPv4), this results in a 41-byte packet for 1 byte of useful information, a huge overhead. This situation often occurs in Telnet sessions, where most keypresses generate a single byte of data that is transmitted immediately. Worse, over slow links, many such packets can be in transit at the same time, potentially leading to congestion collapse. Nagle's algorithm works by combining a number of small outgoing messages and sending them all at once. Specifically, as long as there is a sent packet for which the sender has received no acknowledgment, the sender should keep buffering its output until it has a full packet's worth of output, thus allowing output to be sent all at once. AlgorithmThe RFC defines the algorithm as
Where MSS is the maximum segment size, the largest segment that can be sent on this connection, and the window size is the currently acceptable window of unacknowledged data, this can be written in pseudocode as{{Citation needed|reason=not how it is defined in RFC|date=July 2017}} '''if''' there is new data to send '''if''' the window size >= MSS '''and''' available data is >= MSS send complete MSS segment now '''else''' '''if''' there is unconfirmed data still in the pipe enqueue data in the buffer until an acknowledge is received '''else''' send data immediately '''end if''' '''end if''' '''end if''' This algorithm interacts badly with TCP delayed acknowledgments (delayed ACK), a feature introduced into TCP at roughly the same time in the early 1980s, but by a different group. With both algorithms enabled, applications that do two successive writes to a TCP connection, followed by a read that will not be fulfilled until after the data from the second write has reached the destination, experience a constant delay of up to 500 milliseconds, the "ACK delay". For this reason, TCP implementations usually provide applications with an interface to disable the Nagle algorithm. This is typically called the A solution recommended by Nagle is to avoid the algorithm sending premature packets by buffering up application writes and then flushing the buffer:[1]
Nagle considers delayed ACKs a "bad idea", since the application layer does not usually respond within the time window.[2] On the protocol level, he recommends disabling "delayed ACK" (for example, by Negative effect on larger writesThe algorithm applies to data of any size. If the data in a single write spans 2n packets, the last packet will be withheld, waiting for the ACK for the previous packet.[4] In any request-response application protocols where request data can be larger than a packet, this can artificially impose a few hundred milliseconds latency between the requester and the responder, even if the requester has properly buffered the request data. Nagle's algorithm should be disabled by the requester in this case. If the response data can be larger than a packet, the responder should also disable Nagle's algorithm so the requester can promptly receive the whole response. In general, since Nagle's algorithm is only a defense against careless applications, it will not benefit a carefully written application that takes proper care of buffering; the algorithm has either no effect, or negative effect on the application. Interactions with real-time systemsApplications that expect real-time responses and low latency can react poorly with Nagle's algorithm. Applications such as networked multiplayer video games or the movement of the mouse in a remotely controlled operating system, expect that actions are sent immediately, while the algorithm purposefully delays transmission, increasing bandwidth efficiency at the expense of latency. For this reason applications with low-bandwidth time-sensitive transmissions typically use Another option is to use UDP instead. Operating systems implementationMost modern operating systems implement Nagle's algorithms. In AIX[6] and Linux[7] it is enabled by default and can be disabled on a per-socket basis using the References1. ^{{cite | url=http://developers.slashdot.org/comments.pl?sid=174457&threshold=1&commentsort=0&mode=thread&cid=14515105 | title=Boosting Socket Performance on Linux | publisher=Slashdot | author=John Nagle | date=January 19, 2006}} 2. ^{{cite web|last1=Nagle|first1=John|title=Sigh. If you're doing bulk file transfers, you never hit that problem. (reply 9048947)|url=https://news.ycombinator.com/item?id=9048947|website=Hacker News|accessdate=9 May 2018}} 3. ^{{cite web|last1=Nagle|first1=John|title=That fixed 200ms ACK delay timer was a horrible mistake. Why 200ms? Human reaction time. (reply 9050645)|url=https://news.ycombinator.com/item?id=9050645|website=Hacker News|accessdate=9 May 2018}} 4. ^{{cite web|url=http://www.stuartcheshire.org/papers/NagleDelayedAck/ |title=TCP Performance problems caused by interaction between Nagle's Algorithm and Delayed ACK |publisher=Stuartcheshire.org |date= |accessdate=November 14, 2012}} 5. ^[https://bugs.freedesktop.org/show_bug.cgi?id=17868 Bug 17868 – Some Java applications are slow on remote X connections]. 6. ^https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.performance/tcp_nodelay_tcp_nagle_limit.htm 7. ^http://stackoverflow.com/questions/17842406/how-would-one-disable-nagles-algorithm-in-linux
External links
2 : Networking algorithms|Transmission Control Protocol |
| 随便看 |
|
开放百科全书收录14589846条英语、德语、日语等多语种百科知识，基本涵盖了大多数领域的百科知识，是一部内容自由、开放的电子版国际百科全书。