Nagle's algorithm: Difference between revisions

Revision as of 01:12, 20 February 2021

Revision as of 06:24, 1 March 2021

Line 44:

The Nagle algorithm applies to data writes of any size. If the data in a single write spans 2''n'' packets, where there are 2''n''-1 full-sized TCP segments followed by a partial TCP segment, the original Nagle algorithm would withhold the last packet, waiting for either more data to send (to fill the packet), or the ACK for the previous packet (indicating that all the previous packets have left the network).<ref>{{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}}</ref>

In any non-pipelined stop-and-wait request-response application protocol where request data can be larger than a packet, this can artificially impose a few hundred milliseconds latency between the requester and the responder. Originally this was not felt to be a problem, since any non-pipelined stop-and-wait protocol is probably not designed to achieve high performance in the first place, so a few hundred milliseconds extra delay should make little difference. A later refinement to Nagle’s algorithm, called Minshall’s Modification,<ref>{{cite IETF|title=A Proposed Modification to Nagle’s Algorithm|draft=draft-minshall-nagle}}</ref>, solved this problem with stop-and-wait protocols that send one message and then wait for an acknowledgement before sending the next, removing the incentive for them to disable Nagle’s algorithm (though such protocols will still be limited by their design to one message exchange per network round-trip time).

In general, since Nagle's algorithm is only a defense against careless applications, disabling Nagle’s algorithm will not benefit most carefully written applications that take proper care of buffering. Disabling Nagle’s algorithm will enable the application to have many small packets in flight on the network at once, instead of a smaller number of large packets, which may increase load on the network, and may or may not benefit the application performance.