3、重传性能影响：重传对吞吐量的影响、重传对延迟的影响、重传风暴

重传这事儿，看着像是网络在“自我修复”，挺智能的对吧？
但说实话，每一次重传背后都是有代价的。不是数据丢了，我重新发一份就完事了。
它会吃掉你的带宽，拉长你的延迟，严重的时候甚至能把整个网络拖垮。

这一节，我们就来扒一扒重传到底是怎么影响性能的。
我个人习惯把影响分成三个层面来看：吞吐量、延迟，以及最可怕的——重传风暴。

3.1 重传对吞吐量的影响

先问一个问题：吞吐量是怎么算的？
简单说，就是单位时间内成功送达的数据量。

那重传干了什么事？
它让发送方把已经发过的东西，再发一遍。这就意味着，同样的数据占用了两次（甚至更多）的传输机会。
本来可以发新数据的时间窗口，被旧数据挤占了。

我举个例子你就明白了：

正常情况（无重传）：

发送方在 1 秒内发了 10 个数据包
接收方全部确认，吞吐量 = 10 包/秒

有重传的情况：

发送方在 1 秒内发了 10 个包，但丢了 2 个
发送方需要重传这 2 个包，加上新发的 8 个包
实际上 1 秒内只成功送达了 8 个新包，吞吐量 = 8 包/秒

你看，丢包率 20%，吞吐量直接掉了 20%。
这还只是理想情况。实际上，TCP 的拥塞控制机制会让情况更糟。

TCP 拥塞控制对吞吐量的“二次打击”：

超时重传（RTO）： 一旦超时，TCP 会把拥塞窗口直接降到 1 个 MSS（最大报文段长度），然后重新慢启动。这意味着吞吐量会瞬间暴跌，然后慢慢爬升。
快速重传（Fast Retransmit）： 收到 3 个重复 ACK 后，TCP 进入快速恢复阶段，拥塞窗口减半。虽然比超时好一点，但吞吐量也是实打实地砍了一半。

我在项目中遇到过一个问题：某业务高峰期，服务器吞吐量突然从 2Gbps 掉到 200Mbps。
查了半天，发现是中间交换机的一个端口有少量丢包。丢包率不到 0.1%，但 TCP 的拥塞控制被频繁触发，窗口反复减半，吞吐量就崩了。
嗯，这就是典型的“小丢包，大影响”。

丢包率	理论吞吐量损失	实际 TCP 吞吐量损失（含拥塞控制）
0.1%	0.1%	30% - 50%
1%	1%	60% - 80%
5%	5%	90% 以上

这张表是我自己整理的。你想想看，0.1% 的丢包，在 TCP 眼里就是一场灾难。

3.2 重传对延迟的影响

吞吐量是“量”的问题，延迟是“质”的问题。
重传对延迟的影响，比吞吐量更直接，也更让用户抓狂。

延迟增加的来源有两个：

等待重传的时间： 发送方发现丢包后，需要等待 RTO 超时（通常 200ms 起步）或者收到 3 个重复 ACK 才能触发重传。这个等待时间，就是额外的延迟。
重传数据的排队时间： 重传的数据包和正常的数据包一起在发送队列里排队，进一步增加了所有数据的排队延迟。

我举个例子：

正常 RTT（往返时间）是 10ms
如果发生超时重传，RTO 默认是 200ms
那么这一个请求的延迟就变成了 10ms + 200ms = 210ms
直接翻了 20 倍

你想想看，一个网页请求可能包含几十个数据包。只要其中一两个包丢了，整个页面的加载时间就会从 100ms 变成几秒钟。
用户感知到的，就是“卡了”、“转圈了”。

避坑指南：

我曾经在优化一个实时音视频应用时，发现通话质量时好时坏。抓包一看，RTT 在 20ms 和 300ms 之间剧烈抖动。
原因就是偶尔的丢包触发了超时重传。后来我们启用了 FEC（前向纠错）和 NACK（否定确认）机制，才把延迟抖动压下来。
记住：对于实时应用，延迟的抖动比平均延迟更致命。

3.3 重传风暴

如果说吞吐量下降和延迟增加是“慢性病”，那重传风暴就是“急性心梗”。
一旦发生，整个网络可能瞬间瘫痪。

什么是重传风暴？

简单说，就是网络中的重传行为失控了，像滚雪球一样越滚越大。
本来只是一两个包丢了，结果引发了一连串的重传，最终导致网络拥塞崩溃。

重传风暴的典型触发场景：

网络拥塞： 路由器缓存溢出，大量丢包。所有 TCP 连接同时触发重传，进一步加剧拥塞。
链路故障： 某条链路断了，流量切换到备用链路。备用链路瞬间过载，大量丢包，引发重传风暴。
中间设备性能瓶颈： 防火墙、负载均衡器等设备处理能力不足，导致丢包。重传流量进一步压垮设备。

重传风暴的恶性循环：

网络出现拥塞或丢包
TCP 检测到丢包，启动重传
重传数据增加了网络负载
网络负载增加导致更多丢包
更多丢包触发更多重传
回到步骤 3，循环加剧

我在一次大型线上故障中亲眼见过重传风暴的威力。
当时一个核心机房的交换机故障，导致 10% 的流量丢包。结果所有受影响的服务器的 TCP 连接都开始疯狂重传，网络流量瞬间飙升到正常值的 5 倍。
最终，整个机房的网络完全瘫痪，所有业务中断了 30 分钟。

重传风暴的典型特征：

网络流量异常飙升（通常是正常值的 3-10 倍）
丢包率急剧上升（从 0.1% 飙升到 10% 以上）
TCP 重传率超过 10%
应用层响应时间急剧增加或完全超时

一旦发现这些迹象，必须立即介入，否则后果很严重。

下面这张图，是我画的重传风暴的演进过程，你可以直观地感受一下：

你看这个循环，一旦进入阶段 3 到阶段 1 的反馈回路，整个系统就失控了。
我见过很多运维同学在重传风暴发生时手足无措，就是因为没理解这个恶性循环的本质。

3.4 如何量化重传的影响

说了这么多，我们得有个量化的手段来评估重传的影响。
我个人习惯用以下几个指标：

指标	计算公式	说明
重传率	重传包数 / 总发送包数	正常应 < 0.1%，超过 1% 需要关注
有效吞吐量	成功送达的新数据量 / 时间	排除重传数据的实际吞吐量
重传延迟惩罚	重传请求的 RTT - 正常请求的 RTT	衡量重传对延迟的额外影响
重传风暴指数	当前重传率 / 基准重传率	超过 10 倍时，风暴风险极高

实战建议：

我建议你在监控系统中至少保留重传率和有效吞吐量这两个指标。
重传率是“预警指标”，一旦超过阈值就报警。
有效吞吐量是“影响指标”，告诉你重传到底造成了多大的实际损失。
两个指标配合使用，才能准确判断是否需要介入处理。

好了，这一节的内容就到这里。
重传的影响，说白了就是三个字：慢、卡、瘫。
慢是吞吐量下降，卡是延迟增加，瘫是重传风暴。
理解了这些，你才能知道为什么我们要花那么大力气去优化重传。