慢启动阶段的TCP拥塞窗口大小

Question

我有一个关于TCP发送者在慢启动阶段的拥塞窗口增长率的问题。传统上，对于每个RTT，cwnd的大小呈指数增长。例如，如果初始cwnd值为1，则递增2->4->8->16->...。

在我的例子中，由于发送者使用的是linux内核3.5，所以初始cwnd是10。我预计cwnd会增加为10->20->40->...没有延迟确认(我在接收端把它关掉了)。但是，当接收方通过HTTP从发送方下载较大大小(超过1MB)的对象时，cwnd会增加为10->12->19->29->...我不能理解这个序列。

我将RTT设置为100ms，链路带宽足够高。在会话期间没有任何损失。我通过计算接收方在一个RTT内接收到的包的数量来估计发送方的cwnd。

有没有人对这种行为有想法？谢谢。

Answer 1

内核3.5中的dafault拥塞控制算法不是TCP Reno，而是CUBIC。CUBIC具有不同的行为。它源于BIC，我知道立方共享BIC的缓慢启动阶段。只需查看/usr/src/yourkernelname/net/ipv4/tcp_cucuic.c中的BIC和CUB立方代码。

此外，延迟ack可能导致这样的序列。你知道，“传统的”TCP拥塞控制行为是没有DACK和SACK的TCP reno。要知道，即使Linux中当前的TCP reno也不是reno，而是新的reno (带有SACK的reno)。

使用sysctl命令检查延迟ack和选择性ack的选项。