在上一篇文章中已经分析了 windows 在回复确认时的情况，在接收到 TCP 段的情况下，等待 200ms 再回复 ack，除非在这 200ms 里接收方也有数据要发给对方，于是就在发送数据的时候将 ack 捎带过去。

本文我们分析 Linux 中的情况，我使用的是 Unbutu 14.4.

1. 实验

1.1 实验步骤

• 服务器 unp/protocol/tools/winserver/tcp_server.cpp，部署在 windows 上。

• 客户端 unp/protocol/tools/tcpclient/echo_cli.c，部署在 Linux 上。

• 启动 tcp_server

tcp_server.exe 192.168.80.2 8000

• 在 Linux 中启动 tcpdump

$ sudo tcpdump port 8000

• 在 Linux 中启动客户端

$ ./echo_cli 192.168.80.2 8000

然后随便输入一些字符。

1.2 tcpdump 结果

图1 tcpdump 抓的包

图 1 是我截取的部分数据，红色和蓝色框框中的第二行，表示对服务器回显的数据进行确认。

红色框框中的确认是有延时的，即 delayed ack，而蓝色框框中的 ack 几乎都是在收到数据后立即发送出去的。

另外注意，所有的延时的 ack，延时时间都在 40 ms 左右（从收到数据到发送 ack 之间的时间）。

按照官方的说法：

当协议栈接受到TCP数据时，并不一定会立刻发送ACK响应，而是倾向于等待一个超时或者满足特殊条件时再发送。对于Linux实现，这些特殊条件如下：

1）收到的数据已经超过了 full frame size
2）或者处于快速回复模式
3）或者出现了乱序的包
4）或者接收窗口的数据足够多

如果接收方有数据回写，则ACK也会搭车一起发送。当以上条件都不满足时，接收方会延迟40ms再回应ACK。

然而在图 1 中，很多立刻回送的 ack 并不满足上述条件。也许是内核中 TCP 协议栈的策略有所改变吧……

2. 关于延时的 ack

有时候，我们不希望 ack 被延时发送，可以设置 TCP_NODELAY，这些知识后面会再讲的。

3. 总结

• Linux 中的 delayed ack