其实并没有必要。因为如果后续的包都能正常到达，那么说明网络并没有严重拥塞，只需要在接下来传输数据时减缓一些速度即可。
RFC 5681 规定，在发生拥塞时还没被确认的数据量的 1/2（但不能小于 2 个 MSS）设为临界窗口值。然后将拥塞窗口设置为临界窗口值加 3 个 MSS，继续保留在拥塞避免阶段。这个过程被称为快速恢复，其拥塞窗口的变化可以用下图表示：
超时重传
在网络中，发生拥塞后会影响到发送方，因为发送方发送的数据包可能无法像往常一样得到及时的确认。当无法收到确认时，发送方会等待一段时间来判断是否存在网络延迟。如果超过了一定时间仍然没有收到确认，发送方就会认为这些数据包已经丢失，只能通过重传来保证数据的正确性。这个过程被称为超时重传，而从发送原始数据包到重传该数据包的这段时间被称为 RTO。
在 Linux 内核编译时，RTO 的最小值就已被确定，默认值为：200 ms
#define TCP_RTO_MAX ((unsigned)(120*HZ)) #define TCP_RTO_MIN ((unsigned)(HZ/5))
然而，超时重传对传输性能有严重的影响。
- 首先，发送方在等待 RTO 的过程中不能传输数据，相当于浪费了一段时间。
- 其次，拥塞窗口会急剧减小，这将导致接下来的传输速度变慢。
即使是一次万分之一的超时重传，也可能对传输性能产生不可忽视的影响。
如何检查重传情况呢？
Wireshark 单击 Analyze–>Expert Info Composite 菜单，就能在 Notes 标签看到它们了，如图所示。点开 + 号还能看到具体是哪些包发生了重传。
从 Notes 标签中看到 Seq 号为 1458613 的包发生了超时重传。于是用该 Seq 号过滤出原始包和重传包（只有在发送方抓的包才看得到原始包），发现 RTO 竟长达 1 秒钟以上。这对性能的影响实在太大了。找出瓶颈彻底消除重传之后：
SACK
SACK（Selective Acknowledgment 选择性确认）是一种重传机制，其可以向发送方发送接收状态信息。通过 SACK，发送方可以准确地知道哪些数据包已经被接收，哪些数据包还未接收到，从而只需要重传丢失的数据包。
在真实环境中，我们可以抓取到 SACK 的实例。结合“Ack = 991851”和“SACK = 992461-996175”这两个条件，发送方可以知道 992461-996175 的数据已经被接收，而 991851-992460 的数据则还未被接收。这为重传丢失的数据包提供了有力的指引。
总结
除了众所周知的算法外，Linux 内核还提供了多个 TCP 拥塞控制算法，这些算法具有不同的传输特性，可以在 TCP 传输的重要指标，如往返传输时延（RTT）和吞吐量方面表现出不同的效果，包括：Reno、Cubic、BIC、Westwood+、Highspeed、Hybla 等。
# 查询支持的TCP拥塞控制算法 sysctl net.ipv4.tcp_available_congestion_control > net.ipv4.tcp_available_congestion_control = reno cubic bbr # 查询应用的TCP拥塞控制算法 sysctl net.ipv4.tcp_congestion_control > sysctl net.ipv4.tcp_congestion_control
在实际应用中，我们可以根据具体需求和网络环境选择合适的 TCP 拥塞控制算法，以达到最佳的网络传输效果。
小包问题（Small packet problem）
为了保证数据的可靠性，它使用了流量控制、拥塞控制、确认机制等多种技术，这些技术都需要消耗网络带宽和处理资源。
当发送端发送的数据包大小过小时，就会导致网络中出现大量的TCP头部、IP头部等固定长度的协议头。因为一个 TCP 包的头部和 IP 头部至少会占用 40 个字节的空间，而携带的数据很小时就像快递员开着大货车去送小包裹一样浪费。
协议头会占用大量的网络带宽和处理资源，从而导致网络传输效率下降。为了避免TCP小包问题，发送端可以使用一些方法来增加数据包的大小，比如使用 Nagle算法、延迟确认。
Nagle 算法
Nagle 算法的原理是在发出去的数据还没有被确认之前，如果有小数据生成，就先把这些小数据收集起来，凑满一个最大报文段长度（MSS）再进行发送。这样可以减少网络中的小数据包，提高网络的利用率。
延迟确认
延迟确认的原理是这样的：如果接收方收到一个数据包后没有需要立即回复的数据要发送给发送方，那么它就会延迟一段时间再发送确认信息。如果在这段时间内有需要发送的数据，那么确认信息和数据就可以在同一个数据包中一起发送出去。
当与 Nagle 算法同时启用时，延迟确认可能会导致性能下降
问题排查
理解 TCP 协议的机制和字段含义，是为了当传输性能问题发生时，更好地应用它。
当出现延迟问题时：
延迟指标 = 新建连接耗时 + RTT + （Retransmission + RTO） + （Fast Retransmission + Dup ACK) + Retransmission（Out-Of-Order） - SACK + Delay ACK + Nagle Algorithm
- 首先，应查看连接状态（是否频繁新建连接）及 RTT 情况
- 其次，关注是否有重传，是那种类型的重传，以及 SACK 是否有开启
- 最后，确认延迟确认和 Nagle 算法对延迟的影响
类似的，当出现吞吐问题时：
吞吐指标 = （总耗时 - (新建连接耗时 + 重传耗时 + RTO 耗时））/ RTT * MSS * （Cwnd / MSS） - Retransmission
- 首先，应查看连接状态（是否频繁新建连接）、RTT 情况
- 其次，关注是否有重传，是哪种类型的重传
- 最后，确认窗口大小、MSS 等值的状态
本文作者 ： cyningsun
本文地址 ： https://www.cyningsun.com/03-30-2023/network-transmission.html
版权声明 ：本博客所有文章除特别声明外，均采用 CC BY-NC-ND 3.0 CN 许可协议。转载请注明出处！
