我有一个关于在慢启动阶段 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，链路带宽足够高。 session 期间没有损失。我通过计算接收方在一个 RTT 内收到的数据包数量来估计发送方的 cwnd。
有人知道这种行为吗？ 谢谢。
最佳答案
3.5内核默认的拥塞控制算法不是TCP Reno，而是CUBIC。 CUBIC 有不同的行为。它源于 BIC，我知道 CUBIC 共享 BIC 的慢启动阶段。只需在/usr/src/yourkernelname/net/ipv4/tcp_cubic.c 查看 BIC 和 CUBIC 的代码。
此外，延迟确认可能会导致这样的序列。你知道，“传统”的 TCP 拥塞控制行为是没有 DACK 或 SACK 的 TCP reno。 知道即使是 current TCP reno in Linux 也不是 reno 而是 new reno (reno with SACK)。
使用sysctl 命令查看Delayed ack 和Seletive ack 选项。
关于慢启动阶段的TCP拥塞窗口大小，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/16257148/