TCP不会每隔一段确认一次

Question

我正在阅读[Stevens 1993]，在TCP Bulk Data的章节中，显示了“确认每隔一段”策略，但在此之后，他给出了这样一个数字：

（对不起质量低的图片，我不知道如何上传高分辨率图片）

第8段确认4段，与“每隔其他段确认”没有冲突吗？我确信这与操作系统无关，因为作者在两个例子中使用了相同的机器。 / p>

我也查了RFC 1122，这也表示

  

.....在一个全尺寸段的流中，应该是一个ACK   至少每隔一段。

Answer 1

AFAIK你可以为每个PSH / ACK发送一个ACK。我想如果你想使用批量数据，那一点就是只对每个窗口进行确认（这是向前滑动窗口所必需的）。

Answer 2

史蒂文提到“确认其他所有细分”是非常常见。这不是必须的。从你提到的同一章引用他：

  

“使用TCP的滑动窗口协议，接收器不必   确认每个收到的数据包。使用TCP，ACK是   累积 - 他们承认接收者已正确接收   通过确认的序列号减去一个“

的所有字节

Answer 3

所以，因为没有正确答案。我做了一些测试。

1. 从CentOS 7到OS X 10.12到以太网，往返时间为10ms：

   TCP至少每隔三个段确认一次。

2. 从FreeBSD 10.1到OS X 10.12到WAN，往返时间100ms：

   FreeBSD至少每隔一段发送一次ACK，就像RFC一样 提及。

仍然无法解释问题。 很清楚的是，似乎大多数实现在两个相邻的ack之间确实具有最大数量的段，尽管每个实现都可以获得它们自己的值。

Answer 4

Linux将确认每个其他完整段，实际上是MSS值的两倍数据，并且在此之前大多等待MAX_DELAY。它在2012年可以配置：https://lwn.net/Articles/502585/

可以使用TCP_QUICKACK套接字选项关闭延迟的ACK。 （对于下一个ACK）

大多数Windows版本看起来不那么频繁，不确定这是否可以控制。

我怀疑在插图中他假设一个慢速的发送者，要么不跟随其他人应该跟随，因为处理传入请求的速度很慢，接收者只是在看到其他未完成的数据时才会认出它们（或者他没有注意这个细节）。肯定只承认4 * mss恰好是RWin。