Linux 网络丢包怎么排查？终于搞懂了！从零基础到精通，收藏这篇就够了！

Python_chichi

于 2025-04-29 16:20:30 发布

阅读量889

点赞数 11

文章标签： linux 网络 arm开发网络安全安全系统安全

本文链接：https://blog.csdn.net/Javachichi/article/details/147614423

版权

1、丢包疑云：网络协议栈的“死亡万花筒”？

一张图胜千言？恐怕未必。这张看似清晰的丢包路径图，实际上隐藏着无数的坑。要知道，网络协议栈的每一层都可能成为“猪队友”，导致数据包神秘失踪。

VM连接？别高兴太早，网络拥塞、线路老化，随时教你做人。
网卡收包？Ring Buffer溢出，分分钟教你认识什么叫“爆仓”。
链路层？帧校验失败、QoS策略？呵呵，你的数据包可能还没出生就死了。
IP层？路由黑洞、MTU限制？数据包表示：臣妾做不到啊！
传输层？端口监听？资源占用？内核表示：我也很为难啊！
套接字层？缓冲区溢出？应用程序表示：这个锅我不背！
应用层？程序Bug？这... 程序员表示：先让我改完这个bug再说！
Iptables？防火墙规则？恭喜你，人为制造丢包，没谁了。

所以说，丢包排查，简直就是一场噩梦！

2、链路层：网卡背锅？先别急着下结论！

想甩锅给网卡？没那么容易！Linux会忠实地记录网卡收发数据的错误次数。ethtool和netstat，就是你的验尸官。

netstat -i
Kernel Interface table
Iface             MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0             100       31      0      0      0         8      0      0      0 BMRU
lo             65536        0      0      0      0         0      0      0      0 LR

RX-OK：收了多少个包，心里有点数没？
RX-ERR：错了多少个包，别装作看不见！
RX-DRP：进Ring Buffer后被抛弃的孤儿，内存不足是主因。
RX-OVR：Ring Buffer直接爆仓，挤都挤不进去！

TX-OK、TX-ERR... 类似指标，只不过是发送时的统计。

等等，没发现错误？虚拟网卡很清白？Too naive！tc工具配置的QoS策略导致的丢包，网卡统计信息才不会告诉你呢！

tc qdisc show dev eth0
qdisc netem 800d: root refcnt 2 limit 1000 loss 30%
  sent 432 bytes 8 pkt (dropped 4, overlimits 0 requeues 0)
  backlog 0b 0p requeues 0

看到了吗？loss 30%！这TM是人为制造丢包啊！8个包丢了4个，这酸爽！

解决方法？简单粗暴，干掉netem模块！

tc qdisc del dev eth0 root netem loss 30%

再来一发hping3：

hping3 -c 10 -S -p 80 192.168.0.30
HPING 192.168.0.30 (eth0 192.168.0.30): S set, 40 headers + 0 data bytes
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=0 win=5120 rtt=7.9 ms
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=2 win=5120 rtt=1003.8 ms
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=5 win=5120 rtt=7.6 ms
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=6 win=5120 rtt=7.4 ms
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=9 win=5120 rtt=3.0 ms

--- 192.168.0.30 hping statistic ---
10 packets transmitted, 5 packets received, 50% packet loss
round-trip min/avg/max = 3.0/205.9/1003.8 ms

What？还是50%丢包？RTT波动上天？看来，链路层只是背了部分锅，真凶另有其人！

3、网络层/传输层：协议栈的“罗生门”？

网络层和传输层，丢包因素多如牛毛。不过，Linux提供了协议收发汇总，想赖都赖不掉！netstat -s，真相只有一个！

netstat -s
Ip:
    Forwarding: 1
    31 total packets received
    0 forwarded
    0 incoming packets discarded
    25 incoming packets delivered
    15 requests sent out
Icmp:
    0 ICMP messages received
    0 input ICMP message failed
    ICMP input histogram:
    0 ICMP messages sent
    0 ICMP messages failed
    ICMP output histogram:
Tcp:
    0 active connection openings
    0 passive connection openings
    11 failed connection attempts
    0 connection resets received
    0 connections established
    25 segments received
    21 segments sent out
    4 segments retransmitted
    0 bad segments received
    0 resets sent
Udp:
    0 packets received
    ...
TcpExt:
    11 resets received for embryonic SYN_RECV sockets
    0 packet headers predicted
    TCPTimeouts: 7
    TCPSynRetrans: 4
...

关注重点：错误数、丢包数、重传数！

11次连接失败重试（11 failed connection attempts）？握手失败？
4次重传（4 segments retransmitted）？网络不稳定？
11次半连接重置（11 resets received for embryonic SYN_RECV sockets）？SYN Flood攻击？
4次SYN重传（TCPSynRetrans）？服务器压力山大？
7次超时（TCPTimeouts）？网络延迟爆炸？

TCP协议问题多多！但具体原因？呵呵，继续往下挖！

4、Iptables：防火墙的“任性”？

Iptables和内核连接跟踪，也可能偷偷丢包！

先看连接跟踪：

sysctl net.netfilter.nf_conntrack_max
net.netfilter.nf_conntrack_max = 262144
sysctl net.netfilter.nf_conntrack_count
net.netfilter.nf_conntrack_count = 182

连接跟踪数182，最大连接跟踪数262144？看来不是连接跟踪的锅。

再看Iptables。Filter表中的DROP和REJECT规则，是丢包的重灾区！

iptables -t filter -nvL
Chain INPUT (policy ACCEPT 25 packets, 1000 bytes)
 pkts bytes target     prot opt in     out     source               destination
    6   240 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            statistic mode random probability 0.29999999981
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
Chain OUTPUT (policy ACCEPT 15 packets, 660 bytes)
 pkts bytes target     prot opt in     out     source               destination
    6   264 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

两条DROP规则，统计数值不为0！INPUT和OUTPUT链中，随机丢包30%！

凶手找到了！干掉它们！

iptables -t filter -D INPUT -m statistic --mode random --probability 0.30 -j DROP
iptables -t filter -D OUTPUT -m statistic --mode random --probability 0.30 -j DROP

再来一发hping3：

hping3 -c 10 -S -p 80 192.168.0.30
HPING 192.168.0.30 (eth0 192.168.0.30): S set, 40 headers + 0 data bytes
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=0 win=5120 rtt=11.9 ms
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=1 win=5120 rtt=7.8 ms
...
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=9 win=5120 rtt=15.0 ms

--- 192.168.0.30 hping statistic ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 3.3/7.9/15.0 ms

hping3正常了！但别高兴太早！hping3只验证了80端口监听状态，HTTP服务呢？

curl --max-time 3 http://192.168.0.30
curl: (28) Operation timed out after 3000 milliseconds with 0 bytes received

What？hping3正常，curl超时？抓包！

5、Tcpdump：终极武器，真相浮出水面！

tcpdump -i eth0 -nn port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

wireshark flow graph

再来一发netstat -i：

netstat -i
Kernel Interface table
Iface             MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0             100      157      0   3440      0        94      0      0      0 BMRU
lo             65536        0      0      0      0         0      0      0      0 LR

RX-DRP 3440！网卡接收时丢包！

为什么hping3不丢包，curl就丢？

hping3只发SYN包；
curl发SYN包，还发HTTP GET请求（TCP包，带HTTP数据）。

真相只有一个：MTU配置错误！

eth0的MTU只有100！以太网默认MTU是1500！

改！

ifconfig eth0 mtu 1500

再来一发curl：

curl --max-time 3 http://192.168.0.30/
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...
<p><em>Thank you for using nginx.</em></p>
</body>
</html>

熟悉的Nginx响应！丢包问题，彻底解决！