2. Packet Loss 概念：丢包定义、分类及影响
说起丢包，很多刚接触网络诊断的朋友第一反应就是「数据丢了呗」。对，也不全对。我个人习惯把丢包理解成：本该到达目的地的数据包，在中途被「抛弃」了——可能是被设备主动扔掉，也可能是被链路「吃掉」了。
我在项目中遇到过不少人，一听到丢包就怀疑光模块坏了。其实丢包原因千差万别，诊断方法也不同。今天咱们先把最基础的定义理清楚，后面才好对症下药。
2.1 丢包的正式定义
在 IEEE 802.3 标准和 RFC 相关文档里，丢包（Packet Loss）指的是：发送端成功发出一个帧，但接收端从未收到该帧的任何有效数据，或者收到的帧被校验为无效（FCS 错误等）。
注意，这里有几个关键点：
- 必须是「发出而未到达」：如果一个帧在交换机里因队列满被丢弃，设备通常会在 MAC 计数器里明确记录「丢弃计数」。这叫显式丢包。
- 还有「隐含丢包」：比如接收端收到了一个帧，但 FCS 校验失败，它会把该帧扔掉。从应用层看，数据丢了；从物理层看，信号确实到了。这类丢包在 MAC 计数器里体现为 FCS 错误帧计数。
- 丢包率通常用百分比表示：丢包率 = (丢包数 / 总发送包数) × 100%。咱们后面做 MAC 计数器分析时，会频繁跟这个公式打交道。
一句话总结：丢包 = 数据帧在传输过程中被意外丢弃，导致接收端无法获得完整、正确的原始数据。
2.2 丢包的三种分类
诊断丢包，第一步不是查计数器，而是先给丢包「分个类」。我把丢包分成三类：随机丢包、拥塞丢包、故障丢包。这三类在 MAC 计数器上的表现完全不同，诊断思路也截然不同。
| 分类 | 根本原因 | 典型 MAC 计数器指标 |
|---|---|---|
| 随机丢包 | 线路噪声、电磁干扰、单比特错误 | FCS 错误帧、Alignment 错误 |
| 拥塞丢包 | 端口缓存溢出、背压丢包、流量整形丢包 | TxDrop、RxDrop、Pause 帧计数 |
| 故障丢包 | 光模块故障、链路中断、设备硬件异常 | 链路 Down 计数、错过包计数、严重 CRC 错误 |
2.2.1 随机丢包——天生的「噪音受害者」
随机丢包其实就是物理层的「天灾」。铜缆、无线、甚至光纤，都存在一定概率的比特翻转。我最早做 10M 以太网时，AUI 线的共模干扰那叫一个头疼。现在 10G/25G 虽然抗干扰能力强了，但信号衰减和色散依然会制造误码。
这类丢包的特点是：没有固定模式，偶尔丢几个，链路利用率不高时也丢。看 MAC 计数器，FCS 错误帧通常是个位数的增长，而且别的计数器（比如 RxDrop）基本不动。
避坑提示：我曾经被误导过一次——看到 FCS 错误帧在增长，想当然认为是光模块问题。结果替换了三个模块后问题依旧。后来发现是光纤连接器端面脏了，清洁后 FCS 计数立刻归零。记住：随机丢包先查物理层，别急着动配置。
2.2.2 拥塞丢包——最常见的「人为故障」
拥塞丢包说白了就是「水管太细，水龙头开太大」。当设备入端口接收到的帧速率超过了出端口的发送能力，或者超过了设备内部交换背板的带宽，队列就会溢出。数据帧要么被直接丢弃，要么触发流量控制（Pause 帧）。
怎么判断是拥塞丢包？看端口利用率。如果出端口利用率超过 80% 甚至 90%，而 RxDrop 或 TxDrop 在同步增长，那基本就是拥塞。另外，Pause 帧计数上涨也是一个信号——不过现在很多高性能数据中心网络关掉了 Pause，改用 ECN 和 DCQCN，但 MAC 计数器里 Pause 帧计数依然值得关注。
拥塞丢包最大的特点是：你压测它就丢，你不压它就不丢。而且往往只影响某几个特定端口或 VLAN。
特别提醒：不要把「偶然一次的端口利用率 60% 时发生的丢包」直接判定为非拥塞。有时候瞬时微突发（Microburst）在秒级采样下是看不出的，必须用更细粒度的计数器（比如每 100ms 的快照）才能发现。我踩过这个坑——一次现网故障，秒级统计平均利用率不到 50%，但 MAC 计数器却在疯狂丢包，后来用硬件历史计数器才抓到 10ms 级别的 100% 拥塞。
2.2.3 故障丢包——必须立即处理的「硬故障」
故障丢包是三类中最严重的，通常是硬件损坏、链路中断、光模块老化或配置严重错误导致。MAC 计数器里会出现一些异常指标，比如：
- 链路 Down 计数：一段时间内反复出现 UP/DOWN，往往是光模块或线缆接触不良。
- 错过包计数（Missed Packet）：表示设备接收 FIFO 溢出或 DMA 传输失效，常见于 FPGA 或老式网卡。
- 严重 CRC 错误成片出现：不像随机丢包那样零星几个，而是连续十几个甚至上百个帧都 FCS 错误。
故障丢包的特点是：丢包率通常 > 1%，而且持续增长，不会自己恢复。 我遇到过一次，某个 40G 端口连续一个小时丢包率 3%，排查发现是光模块的激光器功率衰减到接近收灵敏度极限。换了模块后一切正常。
2.3 丢包的影响
丢包不是孤立事件，它会像涟漪一样影响整个网络和应用。咱们从三个层次来归纳。
2.3.1 对传输层的影响
TCP 协议对丢包非常敏感。一个丢包可能触发：
- Duplicated ACK 和快速重传：接收端收到乱序数据时，会重复确认上一个已收序号，发送端收到三个重复 ACK 后就开始重传，并降低拥塞窗口。
- RTO 超时重传：如果丢包导致确认迟迟未到，发送端等待 RTO 超时后重传，这个等待时间可能长达几百毫秒甚至几秒，直接导致应用卡顿。
- 吞吐量腰斩：TCP 的拥塞控制算法（比如 CUBIC、BBR）会在丢包后减少窗口，即使后续没丢包，吞吐量恢复也需要几十个 RTT。
一个数据：在 1Gbps 链路上，0.1% 的随机丢包就可以让 TCP 吞吐量降到 500Mbps 以下。你想想看，千兆链路只有一半的实际带宽，业务不卡才怪。
2.3.2 对应用层的影响
不同应用对丢包的容忍度差别很大：
| 应用类型 | 容忍丢包率 | 典型表现 |
|---|---|---|
| 网页浏览（HTTP/TCP） | < 1% | 页面加载慢，偶尔超时 |
| 视频流（UDP） | < 0.5% | 马赛克、画面卡顿 |
| VoIP / 实时音视频 | < 0.1% | 声音断断续续、丢字 |
| 无损存储网络（FC / RoCE） | < 1e-6 | 重传风暴、IO 延迟飙升 |
可以看到，金融交易、超算、存储网络等场景，对丢包的容忍度极低。哪怕一个丢包，也可能导致交易失败或 IO 超时。
2.3.3 对网络运维的影响
丢包还会引发「二次伤害」：
- 大量重传占用带宽：丢包后 TCP 重传和 ACK 风暴，进一步加重网络负载，形成恶性循环。
- 影响网络监控：很多监控工具基于 SNMP 轮询，如果轮询报文本身被丢，监控数据就会失真。我见过一个案例——NetFlow 数据采集器因为自身链路丢包，导致统计的丢包率变成了实际的两倍。
- 故障难定位：拥塞丢包和故障丢包容易混淆，如果只盯着总丢包率而不细分端口和计数器，可能花几天时间找不到根因。
2.4 本章知识体系总览
说了这么多，咱们用一张图把这章的核心逻辑串起来，方便后面查漏补缺。
2.5 小结
这一章我们把丢包的「定义、分类、影响」理顺了。总结三条铁律，我自己做排障时经常默念：
- 丢包未必是故障——拥塞丢包通过流量工程就能解决，随机丢包可能只是脏了接头。
- 分类决定下一步——先判断是随机、拥塞还是故障，再去看对应的 MAC 计数器。别翻大海捞针。
- 影响要从传输层往应用层推——一个丢包在 TCP 眼里可能是灾难，在 UDP 视频里可能只是画面抖一下。了解你的业务，才能评估严重程度。