Linux性能优化实战 47-48 服务器丢包的检测思路

一、消息收发流程图及丢包可能原因

1. 在网卡收包后，环形缓冲区可能会因为溢出而丢包；

2. 在链路层，可能会因为网络帧校验失败、QoS 等而丢包；

3. 在 IP 层，可能会因为路由失败、组包大小超过 MTU 等而丢包；

4. 在传输层，可能会因为端口未监听、资源占用超过内核限制等而丢包；

5. 在套接字层，可能会因为套接字缓冲区溢出而丢包；

6. 在应用层，可能会因为应用程序异常而丢包；

7. 如果配置了 iptables 规则，这些网络包也可能因为 iptables 过滤规则而丢包。

 

二、逐层排查丢包问题

 

使用hping3检查丢包情况：

发现问题：  50% 的丢包；RTT 的波动也仍旧很大，从 3ms 到 1s。

1. 链路层

1.1 检查虚拟网卡

执行netstat -i

RX-OK：接收时总包数

RX-ERR：总错误数

RX-DRP：进入 Ring Buffer 后因其他原因（如内存不足）导致的丢包数

RX-OVR：Ring Buffer 溢出导致的丢包数

从这个输出中，没发现任何错误，说明虚拟网卡没有丢包。

1.2 检查TC规则

检查 eth0 上是否配置了 tc 规则

发现问题：eth0 上面配置了一个网络模拟排队规则，并且配置了丢包率为 30%

处理方法：删除 tc 中的 netem 模块

2. 网络层和传输层

执行 netstat -s

发现有5个问题，如上。

这个结果说明，TCP 协议有多次超时和失败重试，并且主要错误是半连接重置。

即：，主要的失败，是三次握手失败。

3. iptables 和内核的连接跟踪机制

3.1 内核的连接跟踪机制

连接跟踪数只有 182，而最大连接跟踪数则是 262144，并没有问题。

3.2 查看iptables规则

发现问题：两条 DROP 规则，使用 statistic 模块，进行随机 30% 的丢包

处理办法：把这两条规则直接删除

重新执行刚才的 hping3 命令，看看现在是否正常：

现在已经没有丢包了。

hping3 工具，只能验证 Nginx 的 80 端处于正常监听状态, 还没有访问 Nginx 的 HTTP 服务

执行curl 命令，检查 Nginx 对 HTTP请求的响应：

可以发现，这次连接超时了。

4. tcpdump

4.1  tcpdump检查丢包环节在哪里

服务端执行tcpdump 命令，抓取 80 端口的包

客户端执行curl命令

查看 tcpdump 的输出

前三个包是正常的 TCP 三次握手，没问题。(SYN,SYN ACK,ACK)

四个包却是在 3 秒才收到，并且还是客户端发送过来的 FIN 包。

也就说明，客户端的连接关闭了。

4.2 重新执行 netstat -i 令，检查网卡有没有丢包

果然是在网卡接收时丢包了。

hping3 时不丢包，换成 GET 就收不到

4.3 检查最大传输单元MTU

发现问题： eth0 的 MTU 只有 100，而以太网的 MTU 默认值是 1500。

解决办法：MTU改成 1500

4.4. 再次执行 curl 命令

问题解决