TCP 不确认所有其他段答案

【问题标题】：TCP doesn't ACK every other segmentTCP 不确认所有其他段
【发布时间】：2017-05-13 14:55:58
【问题描述】：

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

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

段 8 确认了 4 段，这与“每隔一段确认”不冲突吗？而且我确信这与操作系统无关，因为作者在两个示例中使用了相同的机器。

我还查了RFC 1122，这也表明

.....在一个完整尺寸的段流中应该有一个 ACK 至少每隔一段。

【问题讨论】：

标签： tcp

【解决方案1】：

Linux 将确认每隔一个完整的段，实际上是两倍于 MSS 的数据，并且在这样做之前主要等待 MAX_DELAY。早在 2012 年就可以进行配置：https://lwn.net/Articles/502585/

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

看起来大多数 Windows 版本的 ACK 频率较低，不确定这是否可控。

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

【讨论】：

【解决方案2】：

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

【讨论】：

【解决方案3】：

Steven 提到“每隔一段确认”是非常普遍。这不是必须的。引用您提到的同一章中的他：

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

【讨论】：

是的，我读到了。但是如何解释 RFC 的“......在一个完整大小的段流中，至少每隔一个段应该有一个 ACK”。而且我认为史蒂文斯在这里的意思是不必确认每个数据包，而不是不必“确认每个其他段”，毕竟，“确认每个其他段”完全允许我们不必确认每个数据包。后者对前者至关重要。

【解决方案4】：

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

仍然无法解释问题。显而易见的是，似乎大多数实现在两个相邻 ack 之间确实有最大数量的段，尽管每个实现都可能有自己的值。

【讨论】：