网络排障实战：从抓包分析到问题定位

## 引言 在日常运维和开发工作中，网络问题是最让人头疼的故障类型之一。问题表现千奇百怪——有时候是服务间歇性不可达，有时是响应延迟忽高忽低，还有一些时候"明明都正常却就是不通"。面对这些情况，如果没有一套系统化的排障方法，很容易陷入盲目猜测的困境。 本文通过一个真实案例，带你走完从现象到根因的完整排障流程。 ## 案例背景 某天下午，开发团队反馈测试环境的微服务之间调用偶发超时，频率大约每分钟出现2-3次，每次超时持续5-10秒后自动恢复。查看应用日志只看到连接超时错误，无法判断是应用层还是网络层的问题。 ## 排障第一步：缩小范围 首先确认故障范围： - 检查同一宿主机上的其他服务是否存在类似问题 → 存在 - 检查不同宿主机上的服务之间通信是否正常 → 也存在 - 检查外部网络（如访问公网）是否受影响 → 不受影响 由此初步判断：问题出在内网通信链路，而非应用本身或外网。 ## 排障第二步：抓包分析 在内网两台服务器上同时启动 tcpdump 抓包： ```bash # 服务器A (源端) tcpdump -i eth0 -nn -s0 -w /tmp/server_a.pcap host 10.0.1.20 # 服务器B (目标端) tcpdump -i eth0 -nn -s0 -w /tmp/server_b.pcap host 10.0.1.10 ``` 等待故障复现后停止抓包，将 pcap 文件下载到本地用 Wireshark 分析。 关键发现： 1. 在故障时间点，源端发送了 SYN 包但未收到 SYN-ACK 2. 源端在3秒后进行了第一次重传，6秒后第二次重传 3. 目标端的抓包文件中完全看不到对应的 SYN 包 这说明数据包在传输路径上丢失了，而非目标端处理能力不足。 ## 排障第三步：逐跳排查 内网链路经过一台交换机和一台路由器，逐跳检查： ```bash # 检查交换机端口统计 show interfaces eth0/1 counters errors # 检查路由器接口 show interfaces ge-0/0/0 extensive | match error ``` 在交换机连接上游的端口上发现了递增的 CRC 错误计数，同时伴随少量 input errors。至此根因定位清晰：物理链路质量问题导致间歇性丢包。 ## 排障第四步：解决方案 1. 更换交换机与路由器之间的网线 2. 更换后持续监控 24 小时，错误计数不再增长 3. 联系网络团队将该链路的 snmp 监控告警阈值从 1% 调整为 0.1%，以便更早发现问题 ## 经验总结 - **从现象到范围**：先确认问题是全局性还是局部性，是应用层还是网络层 - **抓包是利器**：tcpdump + Wireshark 组合是网络排障的"显微镜"，有条件的建议长期维护一台抓包分析专用机 - **逐跳原则**：网络问题遵循 OSI 模型自下而上排查，不要跳过任何一层 - **监控先行**：事后补救不如事前预防，关键链路的错误计数监控必不可少 ## 常用排障命令速查 | 命令 | 用途 | |------|------| | `ping -c 100 -i 0.2 host` | 快速连续 ping 检测丢包率 | | `mtr -r host` | 路由跟踪+丢包统计 | | `ss -tunlp` | 查看当前 TCP/UDP 连接状态 | | `tcpdump -i any port 80 -nn` | 抓取指定端口的流量 | | `ethtool -S eth0` | 查看网卡硬件统计信息 | | `ip neigh` | 查看 ARP 表，排查二层问题 | 掌握这些方法和工具，下一次面对网络故障时，你也能有条不紊地定位问题根源。