号主：老杨丨11年资深网络工程师，更多网工提升干货，请关注公众号：网络工程师俱乐部

网络丢包，是运维中最常见、最头疼的问题。它不像“完全断网”那样一目了然，而是像“慢性病”一样，持续消耗用户体验，却难以定位。

更糟的是，丢包可能发生在 从物理层到应用层的任何一环。

是网线问题？交换机过载？还是应用层处理不过来？

今天给大家一套“分层排查法”，带你像侦探一样，逐层追踪，揪出那个“偷走数据包”的真凶。

一、丢包的本质：数据在哪一层被丢弃？

数据包从发送端到接收端，要经过7层模型，每一层都可能成为“丢包现场”：

[应用层] → 数据生成
↓
[传输层] → TCP分段、UDP封装
↓
[网络层] → IP路由、TTL检查
↓
[数据链路层] → MAC转发、CRC校验
↓
[物理层] → 光/电信号传输

★

排查思路：
从底层向上查，
先排除物理层和链路层，
再看网络层和上层。

二、第1层：物理层

症状：

• CRC错误持续增长

• 端口频繁 up/down

• 光功率过低

排查命令：

<Huawei> display interface gigabitethernet 0/0/1

关键指标：

Input: ... 125 crc ← CRC错误 > 0
3 giants ← 巨帧（>1518字节）
0 runts ← 碎片帧（<64字节）

常见原因：

• 网线质量差：水晶头氧化、线序错误、铜包铝

• 光模块问题：光衰过大（RX Power < -20dBm）

• 电磁干扰：网线与电源线并行走线

解决方案：

• 更换高质量Cat6网线

• 检查光模块收发光功率

• 避免与强电线并行

三、第2层：数据链路层

症状：

• 同一VLAN内通信不稳定

• MAC地址漂移

• 交换机CPU升高

排查点1：环路（Loop）

<Huawei> display stp brief

若端口状态为 DISCARDING 或频繁切换，可能STP在收敛，存在环路。

解决方案：

• 启用 BPDU Guard 和 Loop Detection

• 检查是否有私接HUB或AP

排查点2：广播风暴

<Huawei> display interface | include broadcast

若广播包占比 > 20%，可能有设备在发大量广播（如ARP泛洪）。

解决方案：

• 划分更细VLAN

• 配置 广播抑制：

  [Huawei] interface gigabitethernet 0/0/1
  [Huawei-GigabitEthernet0/0/1] broadcast-suppression 80
  

四、第3层：网络层—— 路由的“陷阱”

症状：

• 跨网段丢包，同网段正常

• Traceroute在某跳开始丢包

排查点1：路由不对称

• A→B走路径1，B→A走路径2

• 路径2存在拥塞或ACL拦截

排查方法：

# 从A Ping B
> ping -r 1 192.168.2.100

# 从B Ping A
> ping -r 1 192.168.1.100

对比路径是否一致。

排查点2：TTL过期

> tracert 8.8.8.8
1 1 ms 1 ms 1 ms 192.168.1.1
2 * * * ← 请求超时

可能是中间设备TTL减为0，或防火墙丢弃ICMP。

五、第4层：传输层

症状：

• TCP连接建立慢

• 大文件传输速度上不去

• Wireshark显示大量重传（Retransmission）

根因分析：

• 接收窗口（RWIN）过小：接收方处理不过来

• 乱序（Out-of-Order）：路径不一致导致包乱序

• MTU不匹配：导致IP分片，易丢包

排查工具：

用 Wireshark 抓包，过滤：

• tcp.analysis.retransmission
• tcp.analysis.out_of_order

解决方案：

• 调整TCP窗口大小

• 确保路径MTU一致（避免分片）

• 使用TCP优化中间件

六、第5-7层：会话/表示/应用层

症状：

• HTTP 504网关超时

• 数据库连接池耗尽

• 应用日志报“连接重置”

可能原因：

• 应用处理慢：服务器CPU/内存不足

• 连接数限制：防火墙或应用限制并发

• 协议错误：TLS握手失败

排查方法：

• 查看服务器资源使用率（CPU、内存）

• 检查应用日志（如Nginx、Tomcat）

• 用 netstat 查看连接状态：

  $ netstat -an | grep :80 | wc -l
  

七、实战：一个完整的丢包排查流程

场景：服务器A → 服务器B 丢包10%

1. 物理层：display interface → CRC=0，正常

2. 数据链路层：同VLAN，无环路，广播正常

3. 网络层：tracert 路径一致，无TTL问题

4. 传输层：Wireshark抓包 → 发现大量TCP重传

5. 应用层：查服务器B → CPU 95%，应用日志满

根因：服务器B过载，无法及时ACK，导致A重传。

总结：丢包排查决策树

是否全网丢包？ → 否 → 定位具体链路
↓
查看物理层：CRC、光功率 → 异常 → 换线/模块
↓
查二层：环路、广播风暴 → 异常 → 启用环路检测
↓
查三层：路由、TTL → 异常 → 检查ACL/路由表
↓
查四层：TCP重传、乱序 → 异常 → 抓包分析
↓
查五~七层：服务器负载、应用日志 → 定位瓶颈

原创：老杨丨11年资深网络工程师，更多网工提升干货，请关注公众号：网络工程师俱乐部