TCPDump诊断网络故障案例-微服务集群间歇性通信失败排查

以下是一个结合TCPDump诊断复杂网络故障的实际案例，综合了多个真实场景的技术要点和分析方法：

---

​案例：微服务集群间歇性通信失败排查​

​故障现象​

某分布式系统中，微服务A调用服务B的API成功率突然降至95%，失败请求无规律，日志仅显示Connection reset by peer。常规检查（服务状态、资源监控）均未发现异常。

​排查步骤​

1. ​初步抓包定位方向​

   # 在服务A所在主机捕获与服务B的流量
   tcpdump -i any -nn -s0 'host 10.0.1.100 and host 10.0.1.200 and port 8080' -w service_ab.pcap

   • ​关键发现​：部分TCP连接在数据传输中被RST（Reset）包强制终止。

   • ​异常包示例​：

     14:05:23.456789 IP 10.0.1.100.54321 > 10.0.1.200.8080: Flags [R.], seq 12345, ack 67890

2. ​深入分析RST包特征​

   • 发送方：确认RST由服务B主动发出（非中间设备如防火墙）。
   • 时机：多发生在服务B重启后的5分钟内。
   • 序列号验证：RST包的序列号与当前连接匹配，非恶意攻击。

3. ​结合TCP状态追踪​

   # 捕获TCP状态变化（SYN/FIN/RST）
   tcpdump -i any 'tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0' -nn

   • 发现 ：服务B重启后，旧连接的TIME_WAIT状态未完全释放，新连接复用相同端口导致序列号冲突。

4. ​根本原因​

   • 服务B配置缺陷 ：未启用SO_REUSEADDR，导致端口复用时间过短（默认60秒），新连接与残留的TIME_WAIT连接冲突。
   • 负载均衡器干扰：健康检查间隔过短（1秒），加剧端口竞争。

​解决方案​

1. ​优化服务B配置​：

   # 启用端口快速复用
   sysctl -w net.ipv4.tcp_tw_reuse=1

2. ​调整负载均衡器​：将健康检查间隔从1秒改为30秒。

3. ​验证修复​：

   # 监控RST包数量
   tcpdump -i any 'tcp[tcpflags] & tcp-rst != 0' -c 10 -nn | grep "10.0.1.200"

​技术要点总结​

• RST包分析：需关注发送方向、序列号、时机，区分正常重置与异常中断。
• TIME_WAIT处理 ：微服务高频重启时需优化tcp_tw_reuse和tcp_max_tw_buckets。
• 多工具联动 ：结合ss -tulp查看端口状态，用Wireshark分析完整会话流。

---

​案例启示​

此案例展示了如何通过TCPDump从海量流量中定位关键异常包（如RST），并结合协议知识（TCP状态机）和系统参数调优解决复杂问题。实际生产中，类似问题还可能涉及MTU不匹配、TCP窗口缩放异常等，需灵活应用过滤规则（如tcp[13]分析标志位）。