緩慢啓動階段的TCP擁塞窗口大小

Question

我有一個關於在慢啓動階段期間TCP發送端擁塞窗口增長率的問題。 傳統上，每個RTT的cwnd大小會呈指數增長。例如，如果初始cwnd值爲1，則會增加2-> 4-> 8-> 16 - > ....。在我的情況下，由於發件人使用Linux內核3.5，初始cwnd是10. 我預計cwnd增加爲10-> 20-> 40 - > ...沒有延遲的ACK（我把它關掉了收件人）。但是，當接收者通過HTTP從發送者下載大尺寸（超過1MB）的對象時，cwnd會增加爲10-> 12-> 19-> 29 - > ....我無法理解這個順序。

我將RTT設置爲100ms，鏈路帶寬足夠高。會議期間沒有任何損失。我通過計算接收者在一個RTT內接收到的數據包的數量來估計發送者的cwnd。

有沒有人有這種想法？ 謝謝。

Answer 1

內核3.5中的默認擁塞控制算法不是TCP Reno，而是CUBIC。 CUBIC有不同的行爲。它源自BIC，我知道CUBIC分享BIC的啓動階段緩慢。只需在/usr/src/yourkernelname/net/ipv4/tcp_cubic.c上查看BIC和CUBIC的代碼即可。

此外，延遲確認可能導致這樣的序列。您知道，'傳統'TCP擁塞控制行爲是沒有DACK或SACK的TCP reno。 知道，即使是目前在Linux的TCP Reno不是reno，但新reno（與SACK reno）。

使用sysctl命令檢查Delayed ack和Seletive ack的選項。