我正在阅读TCP大量数据章节中的[Stevens 1993]，显示了“ACK every other segment”策略，但在此之后，他给出了这样一个数字：TCP不会确认其他每个段
（很抱歉的低质量画面，我不知道如何上传高分辨率图片）
节段8获得确认4段，不以“ACK每隔段冲突“？我相信这与操作系统无关，因为作者在两个示例中使用了相同的机器。
另外我抬头RFC 1122这也表明
.....在全尺寸的段的流应该有在 至少每第二段的ACK。
Linux会确认每隔一个完整段，实际上是MSS值的两倍，并且在此之前大多等待MAX_DELAY。它在2012年可配置：https://lwn.net/Articles/502585/
可以使用TCP_QUICKACK套接字选项关闭延迟的ACK。（对于下一个ACK）
它看起来像大多数Windows版本ACK不太经常，不知道这是否是可控的。
我怀疑在插图中，他假设一个缓慢的发送者，或者不遵循每一个其他的SHOULD，因为它处理传入的请求非常缓慢，以至于接收者只是在确认时才看到其他未完成的数据他们（或者他没有关注这个细节）。它肯定只承认4 * mss恰好是RWin。
我猜你的怀疑是原因。迄今唯一合理的解释。 – ryuu
Steven提到“ACK every other segment”是很常见。这不是必须的。要引用他的话从你提到同一章：
“使用TCP的滑动窗口协议的接收器不必 承认每收到一个包使用TCP的ACK被 累积他们承认接收器已经正确接收 全部通过确认序号减去一个字节了”
是的，我读到了。但是如何解释RFC的“......在一个全尺寸的数据流中应该至少每隔一段都应该是一个ACK”。我认为在这里史蒂文森意味着不必承认每个数据包，而不必“确认其他所有数据段”，毕竟，“确认每一个数据段”确实使我们无法确认每个数据包。后者对前者至关重要。 – ryuu
所以，因为没有正确的答案。我做了一些测试。
从CentOS的7至OS X 10.12通过以太网，往返时间为10ms：
的TCP ACK至少每第三区段。
从FreeBSD的10.1到OS X 10.12通过WAN，往返时间为100ms：
FreeBSD的发送ACK为至少每第二链段，正如提到的RFC 。
仍然无法解释问题。 明确的是，似乎大多数实现在两个相邻ack之间确实有最大数量的段，尽管每个实现可能都有自己的值。
@RyanVincent不，我不是说我看到8段，它是第8段acks段4,5,6,7。 – ryuu