将 TCP_QUICKACK 与 nginx 一起使用答案

【问题标题】：Using TCP_QUICKACK with nginx将 TCP_QUICKACK 与 nginx 一起使用
【发布时间】：2023-03-04 14:54:01
【问题描述】：

我最近对服务器端的延迟 ACK 和客户端的 Nagle 算法的组合感到不满，产生了可识别的 40 毫秒延迟，此处记录：http://www.boundary.com/blog/2012/05/know-a-delay-nagles-algorithm-and-you/

解决这个问题的最简单方法是在客户端使用 TCP_NODELAY（或者 TCP_CORK 在我们的情况下也应该可以工作）。但是，我无法直接控制客户端，并想尝试服务器端修复。似乎 TCP_QUICKACK 选项在这里可以解决问题，因为服务器会立即 ACK，从而导致客户端的 Nagle 算法立即发送下一个数据包。

令人惊讶的是，我找不到任何关于以前尝试过这个的人的参考资料。这是一个坏主意吗（除了我们将发送更多，可能是无偿的 ACK 的事实）？由于看起来这个选项不能通过任何 nginx 配置使用，最好直接修补 nginx（可能在 http://hg.nginx.org/nginx/file/dcae651b2a0c/src/http/ngx_http_request.c#l3025 附近）？

谢谢！

【问题讨论】：

我在研究 Nagle 本人时发现的一句有趣的话，“[...] 真正的问题是 ACK 延迟。200 毫秒的“ACK 延迟”计时器是一个坏主意，伯克利的某个人坚持使用BSD 大约在 1985 年左右，因为他们并没有真正理解这个问题。延迟的 ACK 是赌注会在 200 毫秒内得到应用程序级别的回复。即使每次都输掉这个赌注，TCP 也会继续使用延迟的 ACK。如果我“我当时仍在从事网络工作，这永远不会发生。但我正在为一家名为 Autodesk 的初创公司做事。” news.ycombinator.com/item?id=9045125

标签： sockets nginx tcp nagle

【解决方案1】：

我知道这个问题很老，但还是让我回答吧。

因为看起来这个选项不能通过任何 nginx 配置获得

有 nginx tcp_nodelay 指令来处理它。通常与tcp_nopush和sendfile结合使用。

更多nginx优化请阅读article。

【讨论】：