深入分析 Linux 网络丢包问题.docxVIP

所谓丢包，是指在网络数据的收发过程中，由于种种原因，数据包还没传输到应用程序中，就被丢弃了。这些被丢弃包的数量，除以总的传输包数，也就是我们常说的丢包率。丢包率是网络性能中最核心的指标之一。丢包通常会带来严重的性能下降，特别是对TCP来说，丢包通常意味着网络拥塞和重传，进而还会导致网络延迟增大、吞吐降低。

一、哪里可能丢包

接下来，我就以最常用的反向代理服务器Nginx为例，带你一起看看如何分析网络丢包的问题。执行下面的hping3命令，进一步验证Nginx是不是可以正常访问。这里我没有使用ping，是因为ping基于ICMP协议，而Nginx使用的是TCP协议。

#?-c表示发送10个请求，-S表示使用TCP?SYN，-p指定端口为80

hping3?-c?10?-S?-p?80?0

?

HPING?0?(eth0?0):?S?set,?40?headers?+?0?data?bytes

len=44?ip=0?ttl=63?DF?id=0?sport=80?flags=SA?seq=3?win=5120?rtt=7.5?ms

len=44?ip=0?ttl=63?DF?id=0?sport=80?flags=SA?seq=4?win=5120?rtt=7.4?ms

len=44?ip=0?ttl=63?DF?id=0?sport=80?flags=SA?seq=5?win=5120?rtt=3.3?ms

len=44?ip=0?ttl=63?DF?id=0?sport=80?flags=SA?seq=7?win=5120?rtt=3.0?ms

len=44?ip=0?ttl=63?DF?id=0?sport=80?flags=SA?seq=6?win=5120?rtt=3027.2?ms

?

---?0?hping?statistic?---

10?packets?transmitted,?5?packets?received,?50%?packet?loss

round-trip?min/avg/max?=?3.0/609.7/3027.2?ms

从hping3的输出中，我们可以发现，发送了10个请求包，却只收到了5个回复，50%的包都丢了。再观察每个请求的RTT可以发现，RTT也有非常大的波动变化，小的时候只有3ms，而大的时候则有3s。根据这些输出，我们基本能判断，已经发生了丢包现象。可以猜测，3s的RTT，很可能是因为丢包后重传导致的。

那到底是哪里发生了丢包呢？排查之前，我们可以回忆一下Linux的网络收发流程，先从理论上分析，哪里有可能会发生丢包。你不妨拿出手边的笔和纸，边回忆边在纸上梳理，思考清楚再继续下面的内容。在这里，为了帮你理解网络丢包的原理，我画了一张图，你可以保存并打印出来使用

从图中你可以看出，可能发生丢包的位置，实际上贯穿了整个网络协议栈。换句话说，全程都有丢包的可能。

在两台VM连接之间，可能会发生传输失败的错误，比如网络拥塞、线路错误等；

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

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

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

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

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

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

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

当然，上面这些问题，还有可能同时发生在通信的两台机器中。不过，由于我们没对VM2做任何修改，并且VM2也只运行了一个最简单的hping3命令，这儿不妨假设它是没有问题的。为了简化整个排查过程，我们还可以进一步假设，VM1的网络和内核配置也没问题。接下来，就可以从协议栈中，逐层排查丢包问题。

二、链路层

当链路层由于缓冲区溢出等原因导致网卡丢包时，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????????