神秘的40毫秒延迟与 TCP_NODELAY
TCP_NODELAY是用来 禁用 Nagle’s Algorithm
Nagle’s Algorithm 是为了提高带宽利用率设计的算法，其做法是合并小的TCP 包为一个，避免了过多的小报文的 TCP 头所浪费的带宽。如果开启了这个算法 （默认），则协议栈会累积数据直到以下两个条件之一满足的时候才真正发送出 去：
- 积累的数据量到达最大的 TCP Segment Size
- 收到了一个 Ack
TCP Delayed Acknoledgement 也是为了类似的目的被设计出来的，它的作用就 是延迟 Ack 包的发送，使得协议栈有机会合并多个 Ack，提高网络性能。
如果一个 TCP 连接的一端启用了 Nagle‘s Algorithm，而另一端启用了 TCP Delayed Ack，而发送的数据包又比较小，则可能会出现这样的情况：发送端在等待接收端收到上一个packet 的 Ack 才发送当前的 packet，而接收端则正好延迟了 此 Ack 的发送，那么这个正要被发送的 packet 就会同样被延迟。当然 Delayed Ack 是有个超时机制的，而默认的超时正好就是 40ms
现代的 TCP/IP 协议栈实现，默认几乎都启用了这两个功能，你可能会想，按我 上面的说法，当协议报文很小的时候，岂不每次都会触发这个延迟问题？事实不 是那样的。仅当协议的交互是发送端连续发送两个 packet，然后立刻 read 的 时候才会出现问题。
为什么只有 Write-Write-Read 时才会出问题
维基百科上的有一段伪代码来介绍 Nagle’s Algorithm：
if there is new data to send
if the window size >= MSS and available data is >= MSS
send complete MSS segment now
else
if there is unconfirmed data still in the pipe
enqueue data in the buffer until an acknowledge is received
else
send data immediately
end if
end if
end if
可以看到，当待发送的数据比 MSS 小的时候（外层的 else 分支），还要再判断 时候还有未确认的数据。只有当管道里还有未确认数据的时候才会进入缓冲区， 等待 Ack。
所以发送端发送的第一个 write 是不会被缓冲起来，而是立刻发送的（进入内层 的else 分支），这时接收端收到对应的数据，但它还期待更多数据才进行处理， 所以不会往回发送数据，因此也没机会把 Ack 给带回去，根据Delayed Ack 机制， 这个 Ack 会被 Hold 住。这时发送端发送第二个包，而队列里还有未确认的数据包，所以进入了内层 if 的 then 分支，这个 packet 会被缓冲起来。此时，发送端在等待接收端的 Ack；接收端则在 Delay 这个 Ack，所以都在等待，直到接收端 Deplayed Ack 超时（40ms），此 Ack 被发送回去，发送端缓冲的这个 packet 才会被真正送到接收端，从而继续下去。
那么 write-read-write-read 会不会出问题呢？维基百科上的解释是不会：
“The user-level solution is to avoid write-write-read sequences on sockets. write-read-write-read is fine. write-write-write is fine. But write-write-read is a killer. So, if you can, buffer up your little writes to TCP and send them all at once. Using the standard UNIX I/O package and flushing write before each read usually works.”
Write(A) - Write(A) - Read(A)
第一个Write立刻发出去，但是包比较小，接收端不会立刻发送ack；第二个Write也比较小，第二个Write只有当收到第一个Write的ack才会发送，所以会导致延迟40ms才发送第二个Write
Write(A) - Read(A) - Write(A) - Read(A)
第一个Write立刻发送出去，但是包比较小，接收端不会立刻发送ack，不过因为发送端此时为read，等40ms再收到ack也没关系，不会导致第二个Write延迟发送
