在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？
非常感谢！
首先，根据流量控制设置窗口大小。通常它是4096字节或8192字节，它可能会改变。
因此，您的窗口大小不依赖于拥塞参数或丢失的数据包。
现在，在一开始，发送一个数据包（1个MSS大小的数据包）。如果成功接收到第一个数据包的ack，则会增加发送数据包的速率。它会使每个确认的大小加倍。因此拥塞窗口呈指数级增长。在某些时候，由于拥塞，它会计算出由于超时或收到的重复ACK造成的损失。如果它收到重复的ACk，那么它将占用拥塞窗口大小的一半，然后通过加1增加congwin。它线性增加。如果丢失是由于超时，则将conwin设置为1并执行慢启动算法。如果收到重复的ack，它运行快速恢复算法。
慢启动阶段是分组被发送到传输的速率，如指数增长，并且在计算由于丢失事件引起的拥塞之后，它是拥塞窗口值的一半并且线性地增加。现在它将处于拥堵避免阶段。
虽然这可能是StackOverflow的主题，但我仍然认为这是一个重要且有趣的问题。我发布了我在这里找到的答案：
类似（实际上几乎相同）的问题：Does TCP increase its congestion window when Dup Acks arrive?
答：https://tools.ietf.org/html/rfc5681#section-3.2
更详细：
在发送方收到的第一个和第二个重复的ACK ... TCP发送方不得更改cwnd以反映这两个段
对于收到的每个附加重复ACK（在第三个之后），cwnd必须通过SMSS递增。