Does Nagle's algorithm actually make sense on the modern web?
I've always seen it as an artefact from a bygone era that is more likely to cause performance issues than solve them today.
But that's just my intuition and it may be dead wrong.
I've always seen it as an artefact from a bygone era that is more likely to cause performance issues than solve them today.
But that's just my intuition and it may be dead wrong.
https://developers.slashdot.org/comments.pl?sid=174457&cid=1...
The original motivation (as I understand it, and recognizing I may well get corrected by John who is in this thread) were situations like a remote terminal where you'd be writing single bytes to a TCP stream. I just don't think much software is written that way any more, and if it is, it's probably latency sensitive.
And 200ms is an eternity to wait if you happen to build a tiny packet for real time situations and this trips you up.
I write multiplayer games for a living, and you're not always in control of the connection that you're passing data through. Usually, but not always. If Nagle is enabled you literally have to write padding data to the stream to make sure your packet is being sent like this poor soul [2].
Like I say, I'm happy to learn I'm wrong. Given the downvotes, people certainly seem to think I am, and I'm happy to believe they're experienced network engineers dumbfounded at my naïve stupidity.
[1] Eg here's a ten year trend, and it's been thirty years since Nagle's introduction: https://www.caida.org/research/traffic-analysis/pkt_size_dis...
[2] https://stackoverflow.com/questions/19560163/sending-filler-...
Someone was recently complaining that their Arduino project was gobbling up mobile data. They had used an Ethernet shield coupled to some 4G network something.
After a bit of back and forth the culprit was found: it was sending one byte packets.
The standard Arduino is extremely memory limited, so a typical trick is to use the Flash memory to store string constants, and then use those when writing to devices etc. The library code has some nice wrappers which makes things like sending a Flash string constant to some output stream like a serial port or say Ethernet shield fairly seamless.
However for reasons[1], the Flash variant of the "send constant string" call does this by reading and sending one character at a time. And the Ethernet library (memory constrained) or Shield did no extra buffering, so it sent minimum one packet per call...
[1]: IIRC the Arduino Flash is 16 bit and the characters in the string are stored zero-expanded, so it can just memcpy but has to strip away the top byte.
A lot of HTTP software writes things to sockets in small chunks though, especially headers and what not. I've seen some things with chunked encoded posts; I don't think it was visible at the TCP level, but I would get three TLS application data segments, one for $SIZE\r\n, one for the size worth of data, and one for the trailing \r\n. Ugh.
By its nature it also prevents fragmenting poorly written logical packets.
But you could also do this as a separate level of protection. Say a 5ms delay on any write without a flush, any further write resets the delay, up until a maximum of 20ms.
This would seem to reign in the worst of the behavior - developers not realizing they're sending multiple packets - without adding a large delay to developers using the system properly but not flushing.
And since the penalty is much less, it would be less likely to be turned off aggressively, see the Go example in sibling comments.
If the goal is to hand training wheels to developers of shitty apps, it's pretty important they actually use them.