当在慢启动阶段发生丢包时，TCP 拥塞窗口会发生什么？答案

【问题标题】：What happens to the TCP congestion window when packet loss occurs at slow start stage?当在慢启动阶段发生丢包时，TCP 拥塞窗口会发生什么？
【发布时间】：2018-01-03 21:50:33
【问题描述】：

在 TCP 中，可以通过两种方式检测丢包：超时和三个 ACK（针对一个特定的数据包，即丢失的数据包）。

假设尚未达到超时，如果在慢启动阶段发生丢包，拥塞窗口会发生什么？收到第一个重复的 ACK 时，拥塞窗口还会增加 1 吗？

例如，在发送者看来，最初的窗口大小是 3： [1 2 3]

发送和接收数据包 1 及其 ACK（数据包 1 的 ACK）。因此窗口大小增加1，即。到 4： [2 3 4 5]

数据包 2 已发送，但已丢失。那么当数据包3发送成功时，一个重复的ACK（仍然是数据包1）到达，此时的窗口大小是多少？

1) 如果由于接收到第一个重复的 ACK，窗口大小可能会增加（请注意，发送方现在不知道丢包，因为只有一个重复的 ACK 并且尚未达到超时），它应该是： [2 3 4 5 6]

2) 否则，可能因为已经收到包 1 的 ACK（因为包 1 发送成功），窗口大小可能保持 4： [2 3 4 5]

哪一个适用于 TCP？

非常感谢！

【问题讨论】：

@EJP 对不起，我的意思是 ACK 等待新的传入数据包 2。我已经编辑了这种歧义的描述。
@EJP 并且，ACK 号是接收到的最高序列号 +1。这就是我想说的。
它正在确认接收到的所有数据，不包括序列号。将其描述为未收到数据包的 ACK 是没有意义的，“等待数据包 2 的 ACK”也没有意义。只需消除混乱。
@EJP 是的，你是对的 - 对于第一个版本。因此我对其进行了编辑。它确认数据包 1 之前的所有数据包（包括），或者只是数据包 1（因为没有前一个数据包），或者等待数据包 2。
如果您只是停止说“等待数据包 2”，那么您的问题和 cmets 就有意义了。试着改掉这个习惯。

标签： tcp

【解决方案1】：

首先，根据流控制设置窗口大小。一般为 4096 字节或 8192 字节，可能会发生变化。

因此您的窗口大小不取决于拥塞参数或丢失的数据包。

现在一开始，发送一个数据包（1 MSS 大小的数据包）。如果第一个数据包的 ack 被成功接收，那么它会增加发送数据包的速率。每个确认的大小都会增加一倍。因此拥塞窗口呈指数增长。在某个时刻，由于拥塞，它会计算出由于超时或收到重复 ACK 而导致的丢失。如果它接收到重复的 Ak，那么它会将拥塞窗口大小减半，然后通过增加 1 来增加 congwin。它线性增加。如果丢失是由于超时，它会将 conwin 设置为 1 并执行慢启动算法。如果收到重复的确认，它会运行快速恢复算法。

慢启动阶段是数据包发送到传输的速率呈指数增长，在计算出由于丢失事件引起的拥塞后，它是拥塞窗口值的一半并线性增加。现在将处于拥塞避免阶段。

【讨论】：

【解决方案2】：

尽管这在 StackOverflow 上可能不是主题，但我仍然相信这是一个重要且有趣的问题。我在这里发布我找到的答案：

一个类似（实际上几乎相同）的问题： Does TCP increase its congestion window when Dup Acks arrive?

回答： https://www.rfc-editor.org/rfc/rfc5681#section-3.2

更详细的：

在发送方收到的第一个和第二个重复的 ACK ...... TCP 发送方不得更改 cwnd 以反映这两个段

对于收到的每个额外的重复 ACK（第三个之后）， cwnd 必须按 SMSS 递增。

【讨论】：