缓慢启动阶段的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的选项。