Article does not discuss TCP_QUICKACK, which disables delayed ACKs. It is less portable than TCP_NODELAY, which disables Nagle’s algorithm, but it’s still worth mentioning considering both delayed ACKs and Nagle’s algorithm are discussed there.
Why would it? From the look of it @mjb wouldn’t recommend it anyway:
Unfortunately, it’s not just delayed ACK. Even without delayed ack and that stupid fixed timer, the behavior of Nagle’s algorithm probably isn’t what we want in distributed systems. A single in-datacenter RTT is typically around 500μs, then a couple of milliseconds between datacenters in the same region, and up to hundreds of milliseconds going around the globe. Given the vast amount of work a modern server can do in even a few hundred microseconds, delaying sending data for even one RTT isn’t clearly a win.
One of the main points of the article is that TCP_NODELAY basically dominates TCP_QUICKACK, to such an extent that in maybe 99.9+% of the time, TCP_NODELAY does what you want, at which point you don’t really care about delayed acknowledgements. (As far as I understand the article).
Had I written the article, I would probably not have bothered mentioning the flag I wouldn’t almost never recommend.
TCP_QUICKACK kinda sorta disables delayed ACKs. To quote the man page:
This flag is not permanent, it only enables a switch to or from quickack mode. Subsequent operation of the TCP protocol will once again enter/leave quickack mode depending on internal protocol processing and factors such as delayed ack timeouts occurring and data transfer.
It also doesn’t fix the problem with sometimes waiting an extra RTT, which isn’t great.
Go’s stdlib turns TCP_NODELAY on by default. It’s possible to opt out when desired but I can only find 2 examples of code doing that and I think it might be misguided in those cases too.
A Go project I was involved in turned it off, after we discovered it was sending lots of tiny packets hat hurt performance. IIRC there was a WebSocket library involved. In hindsight it was probably that library’s fault for not using a buffered writer to write the pieces of the frames to the socket.
Article does not discuss
TCP_QUICKACK, which disables delayed ACKs. It is less portable thanTCP_NODELAY, which disables Nagle’s algorithm, but it’s still worth mentioning considering both delayed ACKs and Nagle’s algorithm are discussed there.Read this first as
TCP_QUICKHACKand nodded sagely before catching it.Why would it? From the look of it @mjb wouldn’t recommend it anyway:
One of the main points of the article is that TCP_NODELAY basically dominates TCP_QUICKACK, to such an extent that in maybe 99.9+% of the time, TCP_NODELAY does what you want, at which point you don’t really care about delayed acknowledgements. (As far as I understand the article).
Had I written the article, I would probably not have bothered mentioning the flag I wouldn’t almost never recommend.
TCP_QUICKACK kinda sorta disables delayed ACKs. To quote the man page:
It also doesn’t fix the problem with sometimes waiting an extra RTT, which isn’t great.
FWIW TCP_QUICKACK is mentioned in the cited quote from Nagle on HN, and the post is worth reading.
Go’s stdlib turns TCP_NODELAY on by default. It’s possible to opt out when desired but I can only find 2 examples of code doing that and I think it might be misguided in those cases too.
A Go project I was involved in turned it off, after we discovered it was sending lots of tiny packets hat hurt performance. IIRC there was a WebSocket library involved. In hindsight it was probably that library’s fault for not using a buffered writer to write the pieces of the frames to the socket.