18-TCP 协议(迟到的 ACK—— Linux)

在上一篇文章中已经分析了 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