重传风暴定位与根治方案 - 第1节
一、风暴初现：什么是重传风暴？
各位好，我是老赵。做网络运维十几年，要说哪种故障最让人头疼，重传风暴绝对排前三。
先说说什么是重传风暴。说白了，就是网络里大量数据包同时超时重传，像滚雪球一样越滚越大，最后把整个链路堵死。我见过不少刚入行的同事，一看到 Wireshark 里全是重传包就慌了，其实这背后是有规律可循的。
重传风暴的定义：当网络中出现大量 TCP 重传报文，且重传数量呈指数级增长，导致有效吞吐量趋近于零的现象。
1.1 正常重传 vs 风暴重传
这里有个关键区别。正常网络里，偶尔丢一两个包，TCP 协议自己就能搞定。但风暴不一样——它像多米诺骨牌，一个包超时，引发一连串重传，然后整个网络就崩了。
| 对比维度 | 正常重传 | 重传风暴 |
|---|---|---|
| 重传比例 | < 1% | > 20%，甚至 80% 以上 |
| 触发原因 | 偶发丢包、链路抖动 | 拥塞、缓冲区溢出、配置错误 |
| 恢复能力 | RTO 超时后自动恢复 | 自我恶化，无法自愈 |
| 对业务影响 | 轻微延迟 | 业务中断、连接超时 |
我遇到过最夸张的一次，某电商大促期间，重传比例飙到 70%。前端页面直接打不开，后台监控全是红色告警。嗯，那次教训太深刻了。
1.2 风暴是怎么形成的？
你想想看，TCP 重传机制本身是好的，但一旦触发条件不对，就会出问题。核心流程是这样的：
- 发送方发出数据包，启动重传计时器
- 接收方没收到，或者 ACK 丢了
- 计时器超时，发送方重传数据
- 如果网络已经拥塞，重传包加剧拥塞
- 更多包超时，更多重传——风暴来了
注意：很多人以为重传风暴是网络设备坏了。其实大部分时候，是 TCP 协议栈的自我保护机制被触发了，但触发后失控了。我曾经排查过一个案例，最后发现是交换机端口缓存太小，导致瞬间丢包率暴增。
二、典型特征：怎么一眼认出重传风暴？
做运维这么多年，我总结了一套「望闻问切」的方法。不用看复杂的日志，几个关键指标就能判断。
2.1 网络层面的特征
- 重传率飙升：正常网络重传率 < 1%，风暴时可达 30%-90%
- 吞吐量骤降：链路带宽没跑满，但有效数据吞吐量几乎为零
- RTT 异常增大：正常延迟从 1ms 变成 500ms 甚至更高
- TCP 窗口归零：接收窗口不断缩小，最后变成 0
2.2 应用层面的特征
- 连接超时：客户端频繁报 Connection Timeout
- 响应变慢：页面加载时间从 1 秒变成 30 秒
- 错误率上升：HTTP 502、504 大量出现
我的经验：抓包时别只看重传包数量。要看重传包的分布——是集中在某个 IP 段，还是全网都有？我曾经遇到一个案例，重传风暴只影响了一个机柜，最后发现是那台交换机的光模块坏了。
三、重传风暴的危害：不只是慢那么简单
很多人觉得重传风暴就是网络慢一点，忍忍就过去了。说实话，这种想法很危险。
3.1 直接危害
| 危害类型 | 具体表现 | 影响范围 |
|---|---|---|
| 业务中断 | 数据库连接超时、API 调用失败 | 核心业务不可用 |
| 数据不一致 | 分布式事务超时，数据未同步 | 数据完整性受损 |
| 资源耗尽 | CPU 100%、内存溢出、连接池占满 | 服务器宕机 |
| 连锁反应 | 一个服务超时，引发上下游雪崩 | 整个集群不可用 |
3.2 间接危害
我见过最惨的一次，重传风暴持续了 20 分钟，结果：
- 订单系统数据丢失，需要人工补单
- 缓存集群雪崩，后续恢复花了 2 小时
- 用户投诉量暴增，品牌声誉受损
血的教训：别等到风暴发生了再处理。我建议每季度做一次重传风暴演练，就像消防演习一样。平时不练，真出事的时候手忙脚乱。
四、知识体系：一张图看懂重传风暴
下面这张图是我自己整理的，把重传风暴的核心知识点串起来了。你保存下来，以后排查问题时对照着看。
五、写在开头的话
重传风暴这东西，说白了就是网络世界的「心脏病」。发作起来快，后果严重。但别怕，只要掌握了正确的诊断方法和根治手段，完全可控。
我个人习惯是把重传风暴分成三个阶段来处理：
- 第一阶段：快速识别（本章内容）
- 第二阶段：精准定位（后续章节展开）
- 第三阶段：彻底根治（核心章节）
给新人的建议：别一上来就学各种高级工具。先把 TCP 重传的基本原理搞懂，把抓包工具用熟。我见过太多人，工具用得花里胡哨，但连重传包和快速重传都分不清。