目录：
-
- 一、问题现象
- 二、网络丢包测试
- 三、测试端口占用（服务起不来）
- 四、tracert、traceroute命令
- 五、网络抓包分析丢包
- 六、linux命令分析丢包
-
- [1、如何判断存在 rx_dropped？](#1、如何判断存在 rx_dropped？)
- [2、rx_dropped 产生的可能原因（结合244节点背景）](#2、rx_dropped 产生的可能原因（结合244节点背景）)
- 3、建议的处理措施
一、问题现象
二、网络丢包测试
1、方法一hping3命令
powershell
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命令
powershell
nc -v -w3 10.0.0.xxx 65341 
三、测试端口占用（服务起不来）
powershell
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命令
powershell
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），若仍高频出现，需排查网卡硬件或更换驱动。