所谓丢包，是指在网络数据收发过程中，由于各种原因，数据包在传输到应用程序之前就被丢弃了。这些丢弃包的数量除以总传输包的数量，我们常说丢包率。这些丢弃包的数量除以总传输包的数量，我们常说

。丢包率是网络性能的核心指标之一。

丢包通常会导致严重的性能下降，尤其是对 TCP 丢包通常意味着网络拥塞和重传，进而导致网络延迟增加，吞吐量减少。

案例准备

今天的案例需要两台虚拟机。

使用vagrant拉起两台虚机。

机器配置：2 CPU，2GB 内存。预先安装 docker、curl、hping3 等工具

案例分析

我们今天要分析的案例是一个 Nginx 应用，如下图所示，hping3 和 curl 是 Nginx 的客户端。

我在这里对应ip是192.168.56.10 和192.168.56.11

?

启动项目

[root@hadoop100 /opt]#docker run --name nginx --hostname nginx --privileged -p 80:80 -itd feisky/nginx:dropUnable to find image 'feisky/nginx:drop' locallydrop: Pulling from feisky/nginx6ae821421a7d: Pull completeda4474e5966c: Pull completeeb2aec2b9c9f: Pull completec6797838e67f: Pull completed61fc363525d: Pull completeDigest: sha256:c16b8286464e50b4c9704ed83e3e111f9c19a60f4ceca775d752b4bd0108637fStatus: Downloaded newer image for feisky/nginx:drop5867df6e997b047bf995ade980f0db0206bec2df1d9e8738bef415c55c55bb71You have mail in /var/spool/mail/root[root@hadoop100 /opt]#[root@hadoop100 /opt]#[root@hadoop100 /opt]#docker psCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES5867df6e997b feisky/nginx:drop "/start.sh" 43 seconds ago Up 42 seconds 0.0.0.0:80->80/tcp, :::80->80/tcp nginx

模拟访问，观察丢包情况

我们切换到终端二中，执行以下内容 hping3 进一步验证命令 Nginx 能否正常访问？注意，我没有在这里使用它 ping，是因为 ping 基于 ICMP 协议，

。

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

[root@hadoop101 yum.repos.d]# hping3 -c 20 -S -p 80 192.168.56.10HPING 192.168.56.10 (eth1 192.168.56.10): S set, 40 headers 0 data byteslen=46 ip=192.168.56.10 ttl=63 DF id=0 sport=80 flags=SA seq=1 win=5120 rtt=1201.8 mslen=46 ip=192.168.56.10 ttl=63 DF id=0 sport=80 flags=SA seq=4 win=5120 rtt=1.9 msDUP! len=46 ip=192.168.56.10 ttl=63 DF id=0 sport=80 flags=SA seq=4 win=5120 rtt=1002.7 mslen=46 ip=192.168.56.10 ttl=63 DF id=0 sport=80 flags=SA seq=5 win=5120 rtt=1.4 mslen=46 ip=192.168.56.10 ttl=63 DF id=0 sport=80 flags=SA seq=9 win=5120 rtt=0.9 mslen=46 ip=192.168.56.10 ttl=63 DF id=0 sport=80 flags=SA seq=10 win=5120 rtt=0.8 mslen=46 ip=192.168.56.10 ttl=63 DF id=0 sport=80 flags=SA seq=11 win=5120 rtt=0.8 mslen=46 ip=192.168.56.10 ttl=63 DF id=0 sport=80 flags=SA seq=12 win=5120 rtt=1.9 mslen=46 ip=192.168.56.10 ttl=63 DF id=0 sport=80 flags=SA seq=13 win=5120 rtt=0.9 msDUP! len=46 ip=192.168.56.10 ttl=63 DF id=0 sport=80 flags=SA seq=10 win=5120 rtt=3204.2 ms--- 192.168.56.10 hping statistic ---20 packets transmitted, 10 packets received, 50% packet lossround-trip min/avg/max = 0.8/541.7/3204.2 ms

从 hping3 在输出中，我们可以发现发送 20 个请求包，却只收到了 10 个回复，50% 丢了所有的包。观察每个请求 RTT 可以发现，RTT 也有很大的波动变化，只有候只有 1ms，而的时候有 3s。观察每个请求 RTT 可以发现，RTT 也有很大的波动变化，只有候只有 1ms，而的时候有 3s。

3s 的 RTT -很有可能是包后重传造成的。

根据这些输出，我们基本上可以判断丢包已经发生了。可以猜测，3s 的 RTT ，很可能是丢包后重传造成的。丢包到底发生在哪里？

在调查之前，我们可以回忆一下 Linux 网络收发过程，首先从理论上分析，哪里有可能丢包。拿出手边的笔和纸，边回忆边在纸上梳理，想清楚再继续下面的内容。

?

从图中可以看出，丢包的位置实际上贯穿了整个网络协议栈。换句话说，整个过程都有丢包的可能。例如，我们从下往上看：

在两台 VM 传输失败的错误可能发生在连接之间，如网络拥塞、线路错误等；网卡包装后，环缓冲区可能因溢出而丢失；在链路层中，由于网络帧验证失败，QoS 等等，丢包；在 IP 由于路由失败，组包大小可能超过层 MTU 等等，丢包；在传输层，由于端口不监控，资源占用超过核心限制，可能会丢失包；在连接层中，由于连接缓冲区溢出，可能会丢失包；在应用层中，由于应用程序异常，可能会丢失包；此外，如果配置 iptables 这些网络包也可能是因为规则 iptables 过滤规则和丢包。

当然，这些问题也可能同时发生在两台通信机器中。

当然，上述问题也可能同时发生在通信的两台机器中。然而，因为我们不对， VM2 做任何修改 VM2 它只操作最简单的一个 hping3 命令，这里假设没问题。

这样，问题可能发生在容器内部。

你可以通过 ethtool 或者 netstat ，查看网卡丢包记录。

TX-OK、TX-ERR、TX-DRP、TX-OVR 它代表类似的含义，只是指发送时对应的指标。

注意，由于 Docker 容器的虚拟网卡实际上是一对 veth pair，一端用于接入容器 eth0，另一端接入主机 docker0 网桥中。

注意，由于 Docker 容器的虚拟网卡实际上是一对 veth pair，一端用于接入容器 eth0，另一端接入主机 docker0 网桥中。veth 网络统计实现网络统计的功能，所以使用 ethtool -S 命令无法获得网卡收发数据的汇总信息。

从这个输出中，我们没有发现任何错误，说明容器的虚拟网卡没有丢包。不过要注 意，