我对慢速启动阶段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。
有没有人知道这种行为？ 感谢。
答案 0 :(得分：1)
内核3.5中的dafault拥塞控制算法不是TCP Reno，而是CUBIC。 CUBIC有不同的行为。它起源于BIC，我知道CUBIC分享了BIC的慢启动阶段。只需在/usr/src/yourkernelname/net/ipv4/tcp_cubic.c上查看BIC和CUBIC的代码。
此外，延迟的ack可能导致这样的序列。你知道，＆＃39;传统＆＃39; TCP拥塞控制行为是没有DACK或SACK的TCP reno。 知道即使是Linux中的当前TCP reno也不是reno而是新的reno（带有SACK的reno）。
使用sysctl命令检查Delayed ack和Seletive ack的选项。