9

I've been bit recently by the combination of a delayed ACK on the server-side and Nagle's algorithm on the client side, producing the recognizable 40ms delay that is documented here: http://www.boundary.com/blog/2012/05/know-a-delay-nagles-algorithm-and-you/

The easiest way to fix this is to use TCP_NODELAY on the client side (or TCP_CORK should work in our case too). However, I don't have direct control over the client, and would like to try a server side fix. It seems that the TCP_QUICKACK option would do the trick here, since the server would immediately ACK, causing Nagle's algorithm on the client side to send the next packet without delay.

Surprisingly, I couldn't find any reference to people trying this before. Is it a bad idea (besides the fact that we'll be sending more, possibly gratuitous, ACKs)? Since it doesn't look like this option is available via any nginx config, is the best bet to just patch nginx directly (perhaps around http://hg.nginx.org/nginx/file/dcae651b2a0c/src/http/ngx_http_request.c#l3025)?

Thanks!

Ryan Madsen
  • 1,187
  • 1
  • 8
  • 14
  • 4
    An amusing quote I found while researching, by Nagle himself, "[...] 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." https://news.ycombinator.com/item?id=9045125 – Ryan Madsen Jul 08 '15 at 17:57

1 Answers1

0

I know this question is old but let me answer anyway.

Since it doesn't look like this option is available via any nginx config

There is nginx tcp_nodelay directive to take care of it. It is usually combined with tcp_nopush and sendfile.

For more nginx optimizations, please read this article.