TCP拥塞控制

TCP有自己的拥塞控制机制。它的特点是缓慢启动，然后是拥塞避免阶段。动态由窗口大小（未确认的未确认数据包的数量）决定。
Flow开始缓慢。发送方在每次收到确认 (ACK) 消息时将窗口大小增加 1。它有效地使下一个路由行程时间 (RTT) 中的数据包速率加倍。此过程一直持续到发生数据包丢失为止。下图描述了慢启动过程。

 TCP 使用数据包丢失作为隐式拥塞通知。为了快速检测数据包丢失并从中恢复以减少其对整个 TCP 会话的影响，现代 TCP 实现了快速重传。作为对 TCP 的增强，快速重传不是等待 TCP 重传超时时间来确认数据包丢失，而是根据来自接收方的重复 ACK 消息检测数据包丢失。当预期序列号的数据包正确到达接收方时，接收方通过发送带有下一个预期数据包序列号的 ACK 消息来确认该数据包。当数据包乱序到达时，例如，当一个数据包丢失时，接收方重新发送最后一个 ACK​​ 消息以再次描述预期的数据包。发送方收到第三个重复ACK报文后，不等待定时器超时，重新发送丢失的数据包。收到重传的数据包后，接收方查看已收到的数据包，并发送带有预期的下一个数据包序列号的新 ACK 消息。
在下图的示例中，接收方通过发送带有下一个预期序列号（编号 5）的 ACK 消息来确认数据包 4。数据包 5 在途中丢失，数据包 6、7 和 8 到达接收方。在收到它们中的每一个后，接收方再次发送具有预期序列号 5 的 ACK 消息。此行为导致发送方收到三个重复的 ACK 消息，其预期序列号为 5。发送方现在知道数据包 5 丢失并将重新传输它。在收到重传的数据包 5 后，接收方在其接收窗口中查看数据包，并发送带有新预期序列号的 ACK 消息。在这个例子中，因为数据包 6、7 和 8 已经以正确的顺序接收到，下一个 ACK​​ 消息将具有序列号 9。在发送方，除了重传丢失的数据包之外，发送方认为数据包丢失是为了是网络拥塞的信号。因此，它将其传输窗口减少一半以缓解拥塞。

TCP FAST Retransmission

现代 TCP 堆栈使用快速重传来快速检测数据包丢失并通过重传丢失的数据包从中恢复。除了重新传输丢失的数据包之外，TCP 拥塞控制机制还将其传输窗口大小减半以避免额外的拥塞。如果先前的窗口大小为 W，则新的窗口大小变为 W/2。因为未确认的未确认数据包数量为 W，超过了新的窗口大小 W/2，发送方将暂停，直到未确认数据包数量减少到 W/2。然后发送方将恢复传输，并在收到每个 ACK​​ 消息后逐渐增加其窗口大小，直到再次发生拥塞：即，直到另一个数据包丢失导致窗口大小再次减小到 W/2。当流进入此拥塞避免阶段时，其窗口大小或数据包传输速率将呈现 W 和 W/2 之间的锯齿模式。图 下图显示了这个拥塞避免阶段的窗口大小动态。

TCP Window-Size Dynamics for Congestion Avoidance

如上TCP 使用 ACK 消息和数据包丢失作为信号来对其数据包传输进行自我计时。 TCP 的锯齿形拥塞控制算法旨在填充任何缓冲区并故意造成偶尔丢失以向发送方提供反馈。无论瓶颈链路的缓冲区有多大，TCP 偶尔都会溢出缓冲区。因此，TCP 需要丢包才能正常运行。数据包丢失和重传是 TCP 拥塞控制过程的正常部分。

看到这里，丢包是不是TCP的一种正常操作？

https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-738488.html