从图中可以清楚地看出超时时发生的情况……拥塞窗口大小回落到其原始值 1，然后再次运行慢启动。

TCP 堆栈如何处理拥塞事件的细节取决于您使用的变体。这张图看起来像是TCP Reno算法的一个例子。

当看到 3 个重复的 ACK 时，TCP Reno 断定存在拥塞，但网络仍在工作，因为某些段被确认。如果超时，情况会更糟：网络似乎完全没有响应。实际上，在重传计时器到期之前接收到重复确认的事实意味着另一方仍在接收段，即使有些可能已经丢失（或重新排序）。

因此，在 3 个重复 ack 的情况下，拥塞窗口减半，然后线性增加。这称为快速恢复，其目标实际上是避免等待重传超时。

当重传超时确实发生时，反应会更加激烈。TCP Reno 从大小为 1 的拥塞窗口开始以慢速启动，以及发生超时时拥塞窗口值的一半的慢启动阈值。当达到阈值时，增加再次变为线性（加性增加）。

TCP Tahoe不包括快速恢复，并且在两种情况下都会以相同的方式做出反应，将拥塞窗口重置为其初始值并执行慢启动。TCP Reno 的快速恢复基本上跳过了慢启动，立即将拥塞窗口设置为阈值并开始线性增加。

请注意，存在更多变体，实际实现可能更复杂。同样在工作中观察这些算法并不容易，因为其他 TCP 机制可能会干扰。

我不知道您的想法（在两种情况下都使用快速恢复）是否存在作为已知和已实现的拥塞避免算法。在 Reno 实施时，它可能已经过测试并被丢弃。随意在这个领域的科学论文中做一些挖掘。