我正在閱讀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