参数说明

你的数据传输并不需要总是准确地遵守某一选项或者其它选择。在那种情况下，你可能想要采取更为灵活的措施来控制网络连接：

在发送一系列当作单一消息的数据之前设置TCP_CORK，而且在发送应立即发出的短消息之前设置TCP_NODELAY。

如果需要提供网络的传输效率，应该减少小包的传输，使用TCP_CORK来做汇总传输，在利用sendfile来提高效率；

但如果是交互性的业务，那应该让任意小包可以快速传输，关闭Nagle算法，提高包的传输效率。

TCP_CORK优化了传输的bits效率，tcp_nodelay优化了传输的packet效率。

语法: tcp_nodelay on | off;

默认值:

tcp_nodelay on;

上下文: http, server, location

开启或关闭nginx使用TCP_NODELAY选项的功能。 这个选项仅在将连接转变为长连接的时候才被启用。(在upstream发送响应到客户端时也会启用)。

语法: tcp_nopush on | off;

默认值:

tcp_nopush off;

上下文: http, server, location

开启或者关闭nginx在FreeBSD上使用TCP_NOPUSH套接字选项， 在Linux上使用TCP_CORK套接字选项。 选项仅在使用sendfile的时候才开启。

首先了解两个概念

Nagle：

假如需要频繁的发送一些小包数据，比如说1个字节，以IPv4为例的话，则每个包都要附带40字节的头，也就是说，总计41个字节的数据里，其中只有1个字节是我们需要的数据。

为了解决这个问题，出现了Nagle算法。它规定：如果包的大小满足MSS，那么可以立即发送，否则数据会被放到缓冲区，等到已经发送的包被确认了之后才能继续发送。

通过这样的规定，可以降低网络里小包的数量，从而提升网络性能。

DelayedAcknowledgment：

假如需要单独确认每一个包的话，那么网络中将会充斥着无数的ACK，从而降低了网络性能。

为了解决这个问题，DelayedAcknowledgment规定：不再针对单个包发送ACK，而是一次确认两个包，或者在发送响应数据的同时捎带着发送ACK，又或者触发超时时间后再发送ACK。

通过这样的规定，可以降低网络里ACK的数量，从而提升网络性能。

Nagle和DelayedAcknowledgment是如何影响性能的

Nagle和DelayedAcknowledgment虽然都是好心，但是它们在一起的时候却会办坏事。

如果一个 TCP 连接的一端启用了 Nagle‘s Algorithm，而另一端启用了 TCP Delayed Ack，而发送的数据包又比较小，则可能会出现这样的情况：

发送端在等待接收端对上一个packet 的 Ack 才发送当前的 packet，而接收端则正好延迟了此 Ack 的发送，那么这个正要被发送的 packet 就会同样被延迟。

当然 Delayed Ack 是有个超时机制的，而默认的超时正好就是 40ms。

现代的 TCP/IP 协议栈实现，默认几乎都启用了这两个功能，你可能会想，按我上面的说法，当协议报文很小的时候，岂不每次都会触发这个延迟问题？

事实不是那样的。仅当协议的交互是发送端连续发送两个 packet，然后立刻 read 的 时候才会出现问题。

现在让我们假设某个应用程序发出了一个请求，希望发送小块数据。我们可以选择立即发送数据或者等待产生更多的数据然后再一次发送两种策略。

如果我们马上发送数据，那么交互性的以及客户/服务器型的应用程序将极大地受益。

例如，当我们正在发送一个较短的请求并且等候较大的响应时，相关过载与传输的数据总量相比就会比较低，而且，如果请求立即发出那么响应时间也会快一些。

以上操作可以通过设置套接字的TCP_NODELAY选项来完成，这样就禁用了Nagle 算法。

另外一种情况则需要我们等到数据量达到最大时才通过网络一次发送全部数据，这种数据传输方式有益于大量数据的通信性能，典型的应用就是文件服务器。

应用Nagle算法在这种情况下就会产生问题。但是，如果你正在发送大量数据，你可以设置TCP_CORK选项禁用Nagle化，其方式正好同 TCP_NODELAY相反(TCP_CORK 和 TCP_NODELAY 是互相排斥的)。

假设客户端的请求发生需要等待服务端的应答后才能继续发生下一包，即串行执行，

好比在用ab性能测试时只有一个并发做10k的压力测试，测试地址返回的内容只有Hello world；ab发出的request需要等待服务器返回response时，才能发生下一个request；

此时ab只会发生一个get请求，请求的相关内容包含在header中；而服务器需要返回两个数据，一个是response头，另一个是html body；

服务器发送端发送的第一个 write 是不会被缓冲起来，而是立刻发送的(response header)，

这时ab接收端收到对应的数据，但它还期待更多数据(html)才进行处理，所以不会往回发送数据，因此也没机会把 Ack 给带回去，根据Delayed Ack 机制， 这个 Ack 会被 Hold 住。

这时服务器发送端发送第二个包，而队列里还有未确认的数据包(response header)，这个 packet(html) 会被缓冲起来。

此时，服务器发送端在等待ab接收端的 Ack；ab接收端则在 Delay 这个 Ack，所以都在等待，

直到ab接收端 Deplayed Ack 超时(40ms)，此 Ack 被发送回去，发送端缓冲的这个 packet(html) 才会被真正送到接收端，

此时ab才接受到完整的数据，进行对应的应用层处理，处理完成后才继续发生下一个request，因此服务器端才会在read时出现40ms的阻塞。

tcp_nodelay为什么只在keep-alive才启作用

TCP中的Nagle算法默认是启用的，但是它并不是适合任何情况，对于telnet或rlogin这样的远程登录应用的确比较适合(原本就是为此而设计)，但是在某些应用场景下我们却又需要关闭它。

在Apache对HTTP持久连接(Keep-Alive，Prsistent-Connection)处理时凸现的奇数包&结束小包问题(The Odd/Short-Final-Segment Problem)，

这是一个并的关系，即问题是由于已有奇数个包发出，并且还有一个结束小包(在这里，结束小包并不是指带FIN旗标的包，而是指一个HTTP请求或响应的结束包)等待发出而导致的。

我们来看看具体的问题详情，以3个包+1个结束小包为例，可能发生的发包情况：

服务器向客户端发出两个大包；客户端在接受到两个大包时，必须回复ack；

接着服务器向客户端发送一个中包或小包，但服务器由于Delayed Acknowledgment并没有马上ack；

由于发生队列中有未被ack的包，因此最后一个结束的小包被阻塞等待。

最后一个小包包含了整个响应数据的最后一些数据，所以它是结束小包，如果当前HTTP是非持久连接，那么在连接关闭时，最后这个小包会立即发送出去，这不会出现问题；

但是，如果当前HTTP是持久连接(非pipelining处理，pipelining仅HTTP 1.1支持，nginx目前对pipelining的支持很弱，它必须是前一个请求完全处理完后才能处理后一个请求)，

即进行连续的Request/Response、Request/Response、…，处理，那么由于最后这个小包受到Nagle算法影响无法及时的发送出去

(具体是由于客户端在未结束上一个请求前不会发出新的request数据，导致无法携带ACK而延迟确认，进而导致服务器没收到客户端对上一个小包的的确认导致最后一个小包无法发送出来)，

导致第n次请求/响应未能结束，从而客户端第n+1次的Request请求数据无法发出。

在http长连接中，服务器的发生类似于：Write-Write-Read，即返回response header、返回html、读取下一个request

而在http短连接中，服务器的发生类似于：write-read-write-read，即返回处理结果后，就主动关闭连接，短连接中的close之前的小包会立即发生，不会阻塞

我的理解是这样的：因为第一个 write 不会被缓冲，会立刻到达接收端，如果是 write-read-write-read 模式，此时接收端应该已经得到所有需要的数据以进行下一步处理。

接收端此时处理完后发送结果，同时也就可以把上一个packet 的 Ack 可以和数据一起发送回去，不需要 delay，从而不会导致任何问题。

我做了一个简单的试验，注释掉了 HTTP Body 的发送，仅仅发送 Headers， Content-Length 指定为 0。

这样就不会有第二个 write，变成了 write-read-write-read 模式。此时再用 ab 测试，果然没有 40ms 的延迟了。

因此在短连接中并不存在小包阻塞的问题，而在长连接中需要做tcp_nodelay开启。

那tcp_nopush又是什么？

TCP_CORK选项的功能类似于在发送数据管道出口处插入一个“塞子”，使得发送数据全部被阻塞，直到取消TCP_CORK选项(即拔去塞子)或被阻塞数据长度已超过MSS才将其发送出去。

选项TCP_NODELAY是禁用Nagle算法，即数据包立即发送出去，而选项TCP_CORK与此相反，可以认为它是Nagle算法的进一步增强，即阻塞数据包发送，

具体点说就是：TCP_CORK选项的功能类似于在发送数据管道出口处插入一个“塞子”，使得发送数据全部被阻塞，

直到取消TCP_CORK选项(即拔去塞子)或被阻塞数据长度已超过MSS才将其发送出去。

举个对比示例，比如收到接收端的ACK确认后，Nagle算法可以让当前待发送数据包发送出去，即便它的当前长度仍然不够一个MSS，

但选项TCP_CORK则会要求继续等待，这在前面的tcp_nagle_check()函数分析时已提到这一点，即如果包数据长度小于当前MSS &&((加塞 || …)|| …)，那么缓存数据而不立即发送：

在TCP_NODELAY模式下，假设有3个小包要发送，第一个小包发出后，接下来的小包需要等待之前的小包被ack，在这期间小包会合并，直到接收到之前包的ack后才会发生；

而在TCP_CORK模式下，第一个小包都不会发生成功，因为包太小，发生管道被阻塞，同一目的地的小包彼此合并后组成一个大于mss的包后，才会被发生

TCP_CORK选项“堵塞”特性的最终目的无法是为了提高网络利用率，既然反正是要发一个数据包(零窗口探测包)，

如果有实际数据等待发送，那么干脆就直接发送一个负载等待发送数据的数据包岂不是更好？

我们已经知道，TCP_CORK选项的作用主要是阻塞小数据发送，所以在nginx内的用处就在对响应头的发送处理上。

一般而言，处理一个客户端请求之后的响应数据包括有响应头和响应体两部分，那么利用TCP_CORK选项就能让这两部分数据一起发送：

假设我们需要等到数据量达到最大时才通过网络一次发送全部数据，这种数据传输方式有益于大量数据的通信性能，典型的应用就是文件服务器。

应用Nagle算法在这种情况下就会产生问题。因为TCP_NODELAY在发生小包时不再等待之前的包有没有ack，网络中会存在较多的小包，但这会影响网络的传输能力；

但是，如果你正在发送大量数据，你可以设置TCP_CORK选项禁用Nagle化，其方式正好同 TCP_NODELAY相反(TCP_CORK 和 TCP_NODELAY 是互相排斥的)。

下面就让我们仔细分析下其工作原理。

假设应用程序使用sendfile()函数来转移大量数据。应用协议通常要求发送某些信息来预先解释数据，这些信息其实就是报头内容。

典型情况下报头很小，而且套接字上设置了TCP_NODELAY。有报头的包将被立即传输，在某些情况下(取决于内部的包计数器)，因为这个包成功地被对方收到后需要请求对方确认。

这样，大量数据的传输就会被推迟而且产生了不必要的网络流量交换。

但是，如果我们在套接字上设置了TCP_CORK(可以比喻为在管道上插入“塞子”)选项，具有报头的包就会填补大量的数据，所有的数据都根据大小自动地通过包传输出去。

当数据传输完成时，最好取消TCP_CORK 选项设置给连接“拔去塞子”以便任一部分的帧都能发送出去。这同“塞住”网络连接同等重要。

总而言之，如果你肯定能一起发送多个数据集合(例如HTTP响应的头和正文)，那么我们建议你设置TCP_CORK选项，这样在这些数据之间不存在延迟。

能极大地有益于WWW、FTP以及文件服务器的性能，同时也简化了你的工作。

参考文献:

https://www.cnblogs.com/68xi/p/13418497.html