Description
Nagle's algorithm is a TCP congestion control mechanism that delays sending small packets to reduce network overhead. It works by buffering small amounts of data until either:
- Enough data accumulates to create a reasonably full packet (close to Maximum Segment Size)
- An acknowledgment arrives for previously sent data
- A timeout occurs (typically 200ms)
The algorithm was designed to prevent sending many tiny packets that waste bandwidth with protocol overhead. It was originally designed to avoid the network overhead of TCP/IP headers when sending tiny packets like 1-byte key-presses over the network. For p2p connections over a local network it is only going to add latency to the connection, and if connectivity is spotty, then without TCP_NODELAY, packets should get sent straight away within the connectivity window. TCP's own retry mechanism will ensure packets actually get delivered. None of the packets we send are small, so the possible overhead from TCP headers and the gains from buffering data and sending it together are minimal, especially since we are on a relatively high-bandwidth local network, not sending data over the internet.
See also:
noDelay is already default true for Node http connections and curl enables noDelay by default
TL;DR Nagle's algorithm was not designed for modern network conditions and should always be turned off (noDelay turned on)
Tasks
Description
Nagle's algorithm is a TCP congestion control mechanism that delays sending small packets to reduce network overhead. It works by buffering small amounts of data until either:
The algorithm was designed to prevent sending many tiny packets that waste bandwidth with protocol overhead. It was originally designed to avoid the network overhead of TCP/IP headers when sending tiny packets like 1-byte key-presses over the network. For p2p connections over a local network it is only going to add latency to the connection, and if connectivity is spotty, then without TCP_NODELAY, packets should get sent straight away within the connectivity window. TCP's own retry mechanism will ensure packets actually get delivered. None of the packets we send are small, so the possible overhead from TCP headers and the gains from buffering data and sending it together are minimal, especially since we are on a relatively high-bandwidth local network, not sending data over the internet.
See also:
noDelayis already defaulttruefor Node http connections and curl enables noDelay by defaultTL;DR Nagle's algorithm was not designed for modern network conditions and should always be turned off (noDelay turned on)
Tasks
noDelaytofalseon serversnoDelaytofalseon outgoing connections