Nginx中tcp_nopush和tcp_nodelay如何搭配才能优化网络包？

Nginx里的tcp_nopush和tcp_nodelay经常被放在一起讨论，但它们控制的是TCP栈里两个不同层面的行为。简单来说，tcp_nodelay对应套接字选项TCP_NODELAY，主要解决小数据包发送延迟的问题；tcp_nopush则对应Linux下的TCP_CORK机制，用来在发送大块数据时把多个小包聚合起来。很多人以为这两个指令是互相排斥的，实际上Nginx官方文档也建议在开启sendfile的同时把它们都设成on。想搞清楚为什么，就得先弄明白Nagle算法和TCP_CORK各自的触发条件。

tcp_nodelay如何作用在Nagle算法上

TCP协议默认会启用Nagle算法，这是RFC 896里定义的一种减少小包数量的策略。它的核心逻辑是：当一个TCP连接上还有未被确认的数据时，后续要发送的小段数据不会立刻发出，而是被内核缓存起来，直到收到之前数据的ACK，或者缓存的数据量达到一个MSS（最大报文段长度）。这个设计在上世纪低速网络里确实能避免大量只有几个字节的数据包占满链路，但放到今天的HTTP场景里，它带来的延迟可能比节省的带宽还要明显。

比如一个典型的HTTP请求响应流程里，客户端发送请求头后，服务器先回一个响应头，再回响应体。如果响应头很小，而Nagle算法又正好在等待之前某个数据包的ACK，这个响应头就可能被延迟几十毫秒。在开启长连接的情况下，这种延迟会被后续请求反复触发。Nginx里设置tcp_nodelay on后，会为每个连接关闭TCP_NODELAY选项对应的Nagle算法，让内核在每次调用write或send时都立即把数据推出去，不再等待ACK或缓冲到MSS。

http {
    server {
        listen 80;
        # 关闭Nagle算法，降低小包发送延迟
        tcp_nodelay on;
    }
}

这个指令默认就是on的，适用范围包括反向代理转发、动态接口响应、WebSocket以及任何对实时性要求较高的场景。有人担心关闭Nagle会让网络上小包数量暴涨，但在现代局域网和数据中心内部，这种开销几乎可以忽略，而且带宽利用率可以通过后面的tcp_nopush来弥补。单独把tcp_nodelay设成off，反而容易在延迟确认和Nagle算法叠加时出现经典的40ms卡顿，所以在Nginx里不建议关闭它。

tcp_nopush与TCP_CORK的大包聚合机制

tcp_nopush的作用对象是Linux内核的TCP_CORK选项。开启这个选项后，TCP连接会进入一种类似软木塞封住的状态：内核会尽量把多次写入的数据合并成一个大的数据包再发送，直到数据积累到MSS，或者应用层显式取消TCP_CORK。和Nagle算法不同的是，TCP_CORK不会等待ACK，它只关心当前缓冲的数据量是否足够大。这种机制非常适合Nginx发送静态文件时的场景。

当Nginx处理一个静态文件请求时，它会先发送HTTP响应头，然后调用sendfile系统调用把文件内容从磁盘直接复制到内核发送缓冲区。如果此时没有开启tcp_nopush，响应头和文件的前几个数据包可能会分开发送，造成网络上出现多个小包。开启tcp_nopush后，Nginx会在发送响应头之前设置TCP_CORK，让响应头和后续的sendfile数据尽量在同一个大包里发出去。文件发送完成后，Nginx会取消TCP_CORK，保证剩余数据能正常送达。需要注意的是，Nginx文档明确说明tcp_nopush只有在sendfile开启时才生效，单独开启它而没有sendfile，等于没配置。

http {
    sendfile on;
    tcp_nopush on;
}

这个组合特别适合大文件下载、图片或视频静态资源服务器。把

tcp_nopush

http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
}

Nginxtcp_nopushtcp_nodelay修改时间：2026-09-22 01:51:26