1

我有一个关于 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。

有人知道这种行为吗？谢谢。

4

1 回答 1

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 的选项。

于 2014-06-21T06:35:00.700 回答