Linux下排查网络偶现超时问题

目录：

• • 一、问题现象
  • 二、网络丢包测试
  • • 1、方法一hping3命令
    • 2、方法二nc命令
  • 三、测试端口占用（服务起不来）
  • 四、tracert、traceroute命令
  • 五、网络抓包分析丢包
  • • 1、明确测试场景与抓包位置
    • 2、分析客户端（245）的抓包（图1）
    • 3、分析服务器（246）的抓包（图2）
    • 4、跨节点抓包对比，定位问题
    • 5、补充证据：TCP重传机制的验证
  • 六、linux命令分析丢包
  • • [1、如何判断存在 rx_dropped？](#1、如何判断存在 rx_dropped？)
    • [2、rx_dropped 产生的可能原因（结合244节点背景）](#2、rx_dropped 产生的可能原因（结合244节点背景）)
    • 3、建议的处理措施

一、问题现象

二、网络丢包测试

1、方法一hping3命令

hping3 -c 1404 -p 65341 -S 10.6.51.xxx

参数说明：

• -c 1404：发送 1404 个探测包（对应输出中的 1404 probes sent）；
• -p 65341：指定目标 TCP 端口 65341；
• -S：发送 TCP SYN 包（半开扫描，用于探测端口是否开放，减少被防火墙记录的概率）；
• 10.6.51.xxx：目标 IP 地址。

效果如下：

2、方法二nc命令

nc -v -w3 10.0.0.xxx 65341  

三、测试端口占用（服务起不来）

netstat -tunpl | grep 25  # 查看端口 25（SMTP默认端口）的占用情况

ps aux | grep 3020  #确认该进程是 Postfix（邮件服务，master 进程）

• 核心错误：

haproxy/nginx 启动失败，提示 bind() to 0.0.0.0:25 failed (98: Address already in use)→ 端口25已被其他进程占用，导致新服务无法绑定。

• 占用进程定位：

netstat 结果显示 10024/qmgr（进程ID：3020）占用了 0.0.0.0:25，结合 ps aux | grep 3020 确认该进程是 Postfix（邮件服务，master 进程）。

四、tracert、traceroute命令

traceroute www.baidu.com      # 查看我们访问百度经过的网关
traceroute -d www.baidu.com  # 访问百度并且不将地址解析成主机名。

五、网络抓包分析丢包

1、明确测试场景与抓包位置

测试操作：从 10.x.xx.245（客户端）通过 nc 测试 10.x.xx.246（服务器）的 SSH 端口（默认22端口，但截图中显示端口为 65341，可能是自定义SSH端口或测试端口）。

抓包节点：

图1：客户端 245 的抓包结果（仅能看到 245 自身发出/接收的包）。

图2：服务器 246 的抓包结果（仅能看到 246 自身发出/接收的包）。

2、分析客户端（245）的抓包（图1）

关键现象：仅发送SYN，无任何接收包

第1行：245 向 246:65341 发送 TCP SYN包（握手第一步：客户端请求建立连接）。

第2-3行：245 后续多次发送 TCP Retransmission（SYN重传包）。 原因：客户端未收到服务器的SYN-ACK响应，触发超时重传机制（默认TCP重传策略：指数退避，多次尝试后放弃）。

结论（客户端视角）：

245 仅发出SYN请求，未接收到任何来自246的响应包（无SYN-ACK，也无RST/ICMP错误包）。

3、分析服务器（246）的抓包（图2）

关键现象：服务器发出SYN-ACK，但客户端无回应

第1行：245 向 246:65341 发送 SYN包（服务器收到客户端请求）。

第2行：246 向 245:56602 发送 SYN, ACK包（握手第二步：服务器同意建立连接，回应SYN+ACK）。

第3-8行：246 后续多次发送 TCP Retransmission（SYN-ACK重传包）。 原因：服务器未收到客户端的ACK确认（握手第三步），触发SYN-ACK重传。

结论（服务器视角）：

246 正确收到了客户端的SYN请求，并发出了SYN-ACK响应，但未收到客户端的后续ACK，因此不断重传SYN-ACK。

4、跨节点抓包对比，定位问题

核心矛盾点：

服务器抓包（图2） 显示 246 已发出SYN-ACK包（证明服务器处理正常，网络层以下无问题）。

客户端抓包（图1） 完全没有SYN-ACK包（证明该包未到达客户端，排除客户端本地处理问题）。

推导结论：

SYN-ACK包在从246到245的传输路径中丢失（可能原因：网络拥堵、防火墙拦截、路由故障等），导致客户端收不到响应，服务器持续重传。

5、补充证据：TCP重传机制的验证

客户端（245） 的SYN重传：因未收到SYN-ACK，客户端按TCP协议重传SYN（图1第2-3行）。

服务器（246） 的SYN-ACK重传：因未收到客户端ACK，服务器按TCP协议重传SYN-ACK（图2第3-8行）。 两者的重传行为均符合"未收到预期响应"的TCP标准处理逻辑，进一步印证了"SYN-ACK包未送达客户端"的结论。

总结分析逻辑

单节点抓包确认行为：客户端仅发SYN，服务器发SYN-ACK并重传；

跨节点对比定位丢失点：服务器发出的包在客户端抓包中缺失，排除本地问题；

结合TCP协议规则：重传行为证明双方均未收到对方的后续响应，最终锁定"SYN-ACK包传输丢失"。

因此，结论"246节点发出了【SYN，ACK】包，245节点没有收到"成立。

六、linux命令分析丢包

1、如何判断存在 rx_dropped？

关键依据：/proc/net/dev 文件的接收丢包统计

/proc/net/dev 是Linux系统中反映网络接口收发数据包详细状态的核心文件，其中 drop 列 直接表示因各种原因被内核丢弃的接收包数量（即 rx_dropped）。

从提供的 第二张截图（/proc/net/dev 输出） 中，eno1 接口 的接收统计行（第2行）明确显示：

补充验证：ifconfig 输出的 RX dropped

第一张截图的 ifconfig eno1 输出中也有对应体现：

• dropped:数值 与 /proc/net/dev 中的 drop 列数值完全一致，进一步确认接收丢包的存在。

2、rx_dropped 产生的可能原因（结合244节点背景）

• 接收缓冲区不足（最可能）

ethtool -g eno1 显示：eno1接口的 当前接收缓冲区（RX Buff）为512（"Current hardware settings" → RX Buf: 512），而默认最大值（Pre-set maximums）为4096。

若节点网络流量较大（/proc/net/dev 显示eno1接收字节数达 403GB， packets超5.4亿），512的缓冲区可能不足以应对突发流量，导致内核因"缓冲区溢出"丢弃数据包。

• 硬件或驱动问题

节点未重启可能导致网络驱动异常（如固件bug、资源泄漏），或网卡硬件临时故障，引发数据包处理异常丢包。

• 系统资源耗尽

故障后未重启可能残留进程占用CPU/内存，导致内核网络栈（如软中断处理）无法及时处理接收包，触发丢包。

3、建议的处理措施

• 临时缓解：

调整eno1接收缓冲区至最大值：ethtool -G eno1 rx 4096（需root权限），观察 rx_dropped 是否减少。

• 根本解决：

重启节点：解决因未重启导致的驱动/资源异常（故障后未重启是关键背景，重启通常能修复大部分临时软件问题）。

• 长期监控：

重启后持续跟踪 rx_dropped 数值（watch -n 1 cat /proc/net/dev），若仍高频出现，需排查网卡硬件或更换驱动。