Comment by Animats
11 years ago
To avoid network congestion, the TCP stack implements a mechanism that waits for the data up to 0.2 seconds so it won’t send a packet that would be too small. This mechanism is ensured by Nagle’s algorithm, and 200ms is the value of the UNIX implementation.
Sigh. If you're doing bulk file transfers, you never hit that problem. If you're sending enough data to fill up outgoing buffers, there's no delay. If you send all the data and close the TCP connection, there's no delay after the last packet. If you do send, reply, send, reply, there's no delay. If you do bulk sends, there's no delay. If you do send, send, reply, there's a delay.
The real problem is ACK delays. The 200ms "ACK delay" timer is a bad idea that someone at Berkeley stuck into BSD around 1985 because they didn't really understand the problem. A delayed ACK is a bet that there will be a reply from the application level within 200ms. TCP continues to use delayed ACKs even if it's losing that bet every time.
If I'd still been working on networking at the time, that never would have happened. But I was off doing stuff for a startup called Autodesk.
John Nagle
Are you John Nagle, or was that a quote?
He is. Check his Animats blog. And it's a kind of awesome that here we have a bare-bones internet forum, in which we can have uninformed discussion about Nagle's algorithm only to be enlightened by Mr. Nagle. Hooray for HN and John :)
Indeed! Thanks for confirming :)
1 reply →
Toward the end of the post the author does explain why NODELAY applies - nginx apparently does send, send, reply to write a header and then sendfile.
Are you suggesting using TCP_QUICKACK more often? Can you give examples on when it is desired or not.