千兆丢包的分类与特征
遇到千兆丢包，最怕的就是拿着日志一头雾水。我刚开始做网络运维那会儿，碰到丢包就只知道重启设备，结果问题反复出现。后来才明白——丢包不是一件事，是几件事堆在一起。物理层、链路层、传输层，每一层的症状和排查手段都不一样。
我个人习惯先把丢包按照影响层次拆开，再逐层看计数器。这样做效率高，也容易定位到底是谁的问题。
核心观点：丢包分为物理层、链路层、传输层三类。前两类通常在交换机/网卡上就有明确硬件计数器，第三类需要靠抓包和协议分析。不要一上来就怀疑网线，八成是别的层在搞鬼。
1. 物理层丢包 — 传都没传过去
物理层丢包是最底层的，说白了就是信号没有完整到达对端。你可以想象成打电话时声音断断续续，对方听不清。主要现象包括：
- CRC（循环冗余校验）错误——以太网帧尾部校验失败，说明传输过程中比特翻转了。
- FCS（帧校验序列）错误——与CRC类似，但有些厂商分别统计。
- 链路抖动——端口频繁up/down，或者清除光模块信息。
- 信号衰减——过长网线、劣质水晶头、光模块功率过低。
判断依据很简单：登录交换机，敲命令看端口误码。
# Cisco
show interface gigabitEthernet 1/0/1 | include CRC|runts|errors
# Juniper
show interfaces diagnostics optics ge-0/0/0我曾经历过一个案例：机房刚上架一批新服务器，千兆链路三天两头丢包。查了CRC错误持续增长，最后发现是跳线扭结太严重，换了一根超五类线就解决了。有时候你想想看，物理层的问题往往最简单，也最容易忽略。
2. 链路层丢包 — 到了但没拿到
链路层丢包发生在数据链路层。帧已经传到对端网卡，但因为冲突、队列满、或MAC地址问题而被丢弃。典型表现：
- FCS错误增多（有些交换机归入链路层）
- 过载丢包（Tx/Rx drop）——端口带宽打满了，缓冲溢出
- MAC冲突——同一VLAN里两个设备用了相同MAC（比较少，但遇到过）
- 流量控制问题——pause帧协商失败导致短时丢帧
判断时重点看接口的“input errors”和“output errors”，以及队列丢弃计数器。我习惯先看端口利用率：
# 查看端口统计
show interfaces counters errors gigabitEthernet 0/1
show interfaces queue gigabitEthernet 0/1小技巧：我在排查链路层丢包时，会先看端口有没有造成环路。STP（生成树协议）收敛过程中，端口会临时丢弃所有帧，这种情况下的丢包往往是瞬时的。我曾经遇到过一台交换机因为根桥选举失败，导致几分钟内所有帧都被丢弃——整个机房断网，后来查到是BPDU报文被错误过滤了。
3. 传输层丢包 — 收到了却不认
传输层丢包发生在TCP/UDP层面。帧到了对端，但TCP校验和错误、窗口满、或长时间未收到ACK导致重传。这是用户最敏感的丢包，因为直接表现为应用卡顿或连接断开。
特征：
- TCP重传（Retransmisión）——Wireshark里看到大量“[TCP Retransmission]”
- 零窗口（ZeroWindow）——接收端来不及处理，TCP窗口降为0
- 丢ACK——中间设备丢弃了ACK包，导致发送端超时重传
- 乱序（Out-of-Order）——不是一个严格的丢包，但也会触发重传
判断依据：在两端跑tcpdump，然后分析抓包文件。
# 监听80端口，保存为pcap
tcpdump -i eth0 -w trace.pcap tcp port 80
# 查看重传率
tcpdump -r trace.pcap | grep -o 'Retransmission' | wc -l我记得有一次业务方反馈“文件上传很慢”，我抓了5分钟包，发现TCP重传率高达15%。再往下查，发现中间路由器配置了错误的MTU，导致大包被分片后重组失败。嗯，这种问题最有意思——物理层和链路层都显示正常，只有传输层在拼命重传。
4. 三层丢包的区分方法
实际排查中，不要一条一条翻日志。我自己的排查流水线是这样的：
- 先看物理层——检查光功率、电口协商速率、CRC错误。如果CRC多，肯定是物理层问题。
- 再看链路层——查端口丢弃计数、MAC表异常、STP状态。如果丢弃计数增长但CRC很少，链路层嫌疑大。
- 最后看传输层——tcpdump分析重传和ACK行为。如果物理层和链路层都干净，那就大概率在应用或中间设备上。
| 层次 | 典型丢包原因 | 排查工具 | 关键指标 |
|---|---|---|---|
| 物理层 | 信号衰减、光模块故障、线序错误、电磁干扰 | 交换机端口统计、光功率计、网线测试仪 | CRC错误、FCS错误、链路抖动 |
| 链路层 | 端口过载、MAC冲突、队列溢出、STP收敛 | 交换机接口计数器、SNMP、netstat -i | Rx/Tx drop、FCS错误、冲突计数 |
| 传输层 | TCP重传、零窗口、丢ACK、MTU分片 | Wireshark、tcpdump、ss -t | 重传率、RTT波动、窗口大小 |
注意：有些设备将FCS错误归到物理层，有些归到链路层。跨厂商排查时，先搞清楚计数器定义。我曾因为这个细节跟厂商扯皮了半天，最后发现是硬件手册写错了。
5. 一张图看懂三层丢包关系
我把三层丢包之间的关系画成了流程图，你排查时可以参照这个逻辑走。
这张图把排查流程串起来了。从丢包事件开始，一层一层往下剥。如果物理层有问题，上层计数器也会异常，但根因还是物理层。我个人习惯先解决物理层问题，再去管链路层和传输层，否则容易做无用功。
实战提醒：有时候抓包看到TCP重传，别急着调TCP参数。先用交换机的端口统计确认物理层和链路层有没有误码。我见过太多次“调了TCP参数但问题依旧”的例子——结果最后发现是网线接触不良。
6. 总结必知要点
- 物理层丢包——查CRC、FCS、光功率、链路抖动。工具：交换机命令、光功率计。
- 链路层丢包——查端口丢弃、MAC冲突、队列溢出、STP事件。工具：show interfaces counters、SNMP。
- 传输层丢包——查TCP重传、零窗口、丢ACK。工具：tcpdump、Wireshark。
- 排查顺序：物理 → 链路 → 传输。不要跳层，不要凭感觉。
嗯，这一章的内容大概就是这些。记住一点：丢包本身不是问题，问题是丢在哪一层。搞清楚层，后面修复就水到渠成了。