How the Nagle Algorithm Works
The Nagle algorithm processes data on the sending side of TCP applications by a method called nagling. It detects small-sized messages and accumulates those messages into larger TCP packets before sending data across the wire. This process avoids the generation of unnecessarily large numbers of small packets. The technical specification for the Nagle algorithm was published in 1984 as RFC 896. The decisions for how much data to accumulate and how long to wait between sends are critical to its overall performance.
The Benefits of Nagling
Nagling can efficiently utilize the bandwidth of a network connection at the expense of adding delays, or latency. An example described in RFC 896 illustrates the potential bandwidth benefits and the reason for its creation:
If a TCP application that intercepts keyboard keystrokes wants to communicate each character being typed to a receiver, it can generate a series of messages, each containing 1 byte of data. Before these messages can be sent across the network, each one must be packaged with TCP header information as required by TCP/IP. Each header ranges in size between 20 and 60 bytes. Without nagling, this example application would generate network messages consisting of 95 percent or more header information (at least 20 out of 21 bytes) and 5 percent or less actual data from the sender’s keyboard. Using the Nagle algorithm, the same data could be delivered using fewer messages, resulting in large bandwidth savings.
Applications control their use of the Nagle algorithm with the TCP_NODELA socket programming option. Windows, Linux, and Java systems normally enable Nagle by default. Therefore, applications written for those environments need to specify TCP_NODELAY to switch the algorithm off.
Limitations
Applications that require a fast network response, like video calls and online gaming, may not work well when Nagle is enabled. The delays caused while the algorithm takes extra time to assemble smaller chunks of data can trigger noticeable lag visually on a screen or in a digital audio stream. Such applications typically disable Nagle. This algorithm was originally developed at a time when computer networks supported less bandwidth than they do today. The example described above was based on John Nagle’s experiences at Ford Aerospace in the early 1980s, where nagling tradeoffs on Ford’s slow, heavily-loaded, long-distance network made good sense. There are increasingly fewer situations today where network applications can benefit from his algorithm.
