TCP-IP详解：Delay ACK

最新推荐文章于 2024-10-06 21:32:58 发布

CQ小子

最新推荐文章于 2024-10-06 21:32:58 发布

阅读量2.1w

点赞数 11

分类专栏： Networking 文章标签： network socket tcp

本文链接：https://blog.csdn.net/wdscq1234/article/details/52430382

版权

Networking 专栏收录该内容

23 篇文章 29 订阅

订阅专栏

参考书籍：TCP/IP详解，卷1：协议

基本概念

先了解一下，TCP传输的数据流的分类：

TCP交互数据流：一般情况下数据总是以小于MSS的分组发送，做的是小流量的数据交互，常见的应用比如SSH,Telnet等

TCP成块数据流：TCP尽最大能力的运载数据，数据基本都是按照MSS发送，常见的应用有FTP，Iperf等

交互数据

交互式的数据传输其实应用于日常生活中比较多一些，比如说聊天，远程登录等，我们通过一个实验来观察下交互数据流，我这里使用一个127.0.0.1让server和client进行通信，server不断的回显client发送过去的数据。

1. Client 使用port 57600 连接到 Server 6666 IP 127.0.0.1

2. Client 发送s到Server

3. Server 收到s，并将s回显给Client

上述的过程明显是一个交互式的输入，看下tcpdump的抓包，其中4/5/6/7 四个包是客户端发送s，然后回显的过程，简单的分析下

a. 4号包表示，客户端发送一个s数据到服务器

b. 5号包表示，单独的一个ACK，即告诉客户端已经收到s了

c. 6号包表示，服务器回显数据s

d. 7号包表示，客户端确认已经收到回显

不难看出，5/6号包可以将确认和数据完全一起发送，这样可以减少网络中ACK的小包了，提高这类数据的发送效率。其实这种技术就叫delay ACK

Delay Ack

简单的说，Delay Ack就是延时发送ACK，在收到数据包的时候，会检查是否需要发送ACK，如果需要的话，进行快速ACK还是延时ACK，在无法使用快速确认的条件下，就会使用Delay Ack。

TCP在何时发送ACK的时候有如下规定：

1.当有响应数据发送的时候，ACK会随着数据一块发送

2.如果没有响应数据，ACK就会有一个延迟，以等待是否有响应数据一块发送，但是这个延迟一般在40ms~500ms之间，一般情况下在40ms左右，如果在40ms内有数据发送，那么ACK会随着数据一块发送，对于这个延迟的需要注意一下，这个延迟并不是指的是收到数据到发送ACK的时间延迟，而是内核会启动一个定时器，每隔200ms就会检查一次，比如定时器在0ms启动，200ms到期，180ms的时候data来到，那么200ms的时候没有响应数据，ACK仍然会被发送，这个时候延迟了20ms.

3.如果在等待发送ACK期间，第二个数据又到了，这时候就要立即发送ACK！

优点：减少了数据段的个数，提高了发送效率

缺点：过多的delay会拉长RTT

先通过一组实验来看下效果：分别让服务器在0ms/30ms/40ms/50ms延时的情况下进行回显，看看数据的交互情况

0ms的状况：第一个字符没有Delay ACK的状况，后面的就一直出现data和ACK一起发送的状况，也就是说ACK不是立即回复，然后在定时器到达之前有数据发送和数据一块发送

30ms的状况：我们看到第一个字符和0ms的状况一样，也是快速回复ACK，之后的字符就是delay ACK，接收到数据不会立马回复ACK，等了30ms左右，有数据需要发送！看起来30ms定时器也没有到期

40ms的状况：这个就不在有delay ACK的状况，比较奇怪，可能是kernel有些优化吧，基本都是立即回复ACK了，感觉像是满足了快速回复ACK的条件

50ms的状况：50ms的情况和40ms的情况是一致的。

通过做实验我们可以得到这样的一个结论：

1.一般情况下载40ms内基本都会等待data，如果有data就会一块发送，但是超出了这个时间，都是使用的快速ACK，具体原因目前未知

2.无论多少ms的延时，第一个包都是使用快速ACK，具体原因未知

所以我们这个地方还留有2个疑问，等到后续弄明白再来补充。

关闭Delay ACK

如果需要立即回复ACK，那么可以使用TCP_QUICKACK这个选项来启动快速ACK，先看下Linux关于这个option的描述：

Enable quickack mode if set or disable quickack mode if cleared. In quickack mode, acks are sent immediately, rather than delayed if needed in accordance to normal TCP operation. This flag is not permanent, it only enables a switch to or from quickack mode. Subsequent operation of the TCP protocol will once again enter/leave quickack mode depending on internal protocol processing and factors such as delayed ack timeouts occurring and data transfer. This option should not be used in code intended to be portable.

总结一下要点：

1. 如果在快速的ACK模式下，ACK被立即发送

2. 这个flag并不是永久的，系统会判定是交互数据流，仍然会启动delay ACK，所以这个flag在recv之后需要重新设置

我们直接看下实验结果