下服务器总是时不时丢包，我该怎么办？ _生活知道

目录
iptables
iptables 的原理
iptables -nvL 查看iptables配置
hping3模拟访问
检查端口状态
tcpdump
TCP 交互的流程图
为什么刚才用 hping3 时不丢包，现在换成 GET 就收不到了呢？
再次执行curl命令
上一节，我们一起学习了如何分析网络丢包的问题，特别是从链路层、网络层以及传输层等主要的协议栈中进行分析。
不过，通过前面这几层的分析，我们还是没有找出最终的性能瓶颈。看来，还是要继续深挖才可以。今天，我们就来继续分析这个未果的案例。
在开始下面的内容前，你可以先回忆一下上节课的内容，并且自己动脑想一想，除了我们提到的链路层、网络层以及传输层之外，还有哪些潜在问题可能会导致丢包呢？
iptables
首先我们要知道，除了网络层和传输层的各种协议，iptables 和内核的连接跟踪机制也可能会导致丢包。所以，这也是发生丢包问题时，我们必须要排查的一个因素。
我们先来看看连接跟踪，我已经在如何优化 NAT 性能文章中，给你讲过连接跟踪的优化思路。要确认是不是连接跟踪导致的问题，其实只需要对比当前的连接跟踪数和最大连接跟踪数即可。
不过，由于连接跟踪在 Linux 内核中是全局的，我们需要退出容器终端，回到主机中来查看。
【下服务器总是时不时丢包，我该怎么办？】你可以在容器终端中，执行 exit ；然后执行下面的命令，查看连接跟踪数：
root@nginx:/
连接跟踪数只有 19，而最大连接跟踪数则是 10485760 。显然，这里的丢包，不可能是连接跟踪导致的。
接着，再来看 iptables 。
iptables 的原理
它基于 Netfilter 框架，通过一系列的规则，对网络数据包进行过滤（如防火墙）和修改（如 NAT）。
这些 iptables 规则，统一管理在一系列的表中，
包括 filter（用于过滤）nat（用于 NAT）mangle（用于修改分组数据）raw（用于原始数据包）等。
而每张表又可以包括一系列的链，用于对 iptables 规则进行分组管理。
对于丢包问题来说，最大的可能就是被 filter 表中的规则给丢弃了。要弄清楚这一点，就需要我们确认，那些目标为 DROP 和 REJECT 等会弃包的规则，有没有被执行到。
你可以把所有的 iptables 规则列出来，根据收发包的特点，跟 iptables 规则进行匹配。不过显然，如果 iptables 规则比较多，这样做的效率就会很低。
当然，更简单的方法，就是直接查询 DROP 和 REJECT 等规则的统计信息，看看是否为 0 。如果统计值不是 0 ，再把相关的规则拎出来进行分析。
iptables -nvL 查看iptables配置
我们可以通过 iptables -nvL 命令，查看各条规则的统计信息。比如，你可以执行下面的 docker exec 命令，进入容器终端；然后再执行下面的 iptables 命令，就可以看到 filter 表的统计数据了：
[root@hadoop100 /usr/local/src/sysstat-11.5.5]
从 iptables 的输出中，你可以看到，两条 DROP 规则的统计数值不是 0，它们分别在 INPUT 和 OUTPUT 链中。
再观察一下它们的匹配规则。0.0.0.0/0 表示匹配所有的源 IP 和目的 IP ，也就是会对所有包都进行随机 30% 的丢包。看起来，这应该就是导致部分丢包的“罪魁祸首”了。
既然找出了原因，接下来的优化就比较简单了。比如，把这两条规则直接删除就可以了。我们可以在容器终端中，执行下面的两条 iptables 命令，删除这两条 DROP 规则：
root@nginx:/
hping3模拟访问?
这次输出你可以看到，现在已经没有丢包了，并且延迟的波动变化也很小。看来，丢包问题应该已经解决了。
检查端口状态
到目前为止，我们一直使用的 hping3 工具，只能验证案例 Nginx 的 80 端口处于正常监听状态，却还没有访问 Nginx 的 HTTP 服务。所以，不要匆忙下结论结束这次优化，我们还需要进一步确认， Nginx 能不能正常响应 HTTP 请求。
curl 命令，检查 Nginx 对 HTTP 请求的响应：
[root@hadoop101 yum.repos.d]
从 curl 的输出中，你可以发现，这次连接超时了。可是，刚才我们明明用 hping3 验证了端口正常，现在却发现 HTTP 连接超时，是不是因为 Nginx 突然异常退出了呢？
不妨再次运行 hping3 来确认一下：
$ hping3 -c 3 -S -p 80 192.168.0.30HPING 192.168.0.30 (eth0 192.168.0.30): S set, 40 headers + 0 data byteslen=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=0 win=5120 rtt=7.8 mslen=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=1 win=5120 rtt=7.7 mslen=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=2 win=5120 rtt=3.6 ms — 192.168.0.30 hping statistic —3 packets transmitted, 3 packets received, 0% packet lossround-trip min/avg/max = 3.6/6.4/7.8 ms
奇怪，hping3 的结果显示，Nginx 的 80 端口确确实实还是正常状态。这该如何是好呢？别忘了，我们还有个大杀器——抓包操作。看来有必要抓包看看了。
tcpdump
接下来，我们切换回终端一，在容器终端中，执行下面的 tcpdump 命令，抓取 80 端口的包：
root@nginx:/
经过这么一系列的操作，从 tcpdump 的输出中，我们就可以看到：
前三个包是正常的 TCP 三次握手，这没问题；但第四个包却是在 3 秒以后了，并且还是客户端（VM2）发送过来的 FIN 包，也就说明，客户端的连接关闭了。
我想，根据 curl 设置的 3 秒超时选项，你应该能猜到，这是因为 curl 命令超时后退出了。
也可以把tcpdump的包保存下来，在wireshark中个分析
1、容器中 root@nginx:/
2、容器外 [root@hadoop100 /usr/local/src/sysstat-11.5.5]
TCP 交互的流程图
?
这里比较奇怪的是，我们并没有抓取到 curl 发来的 HTTP GET 请求。那么，究竟是网卡丢包了，还是客户端压根儿就没发过来呢？
我们可以重新执行 netstat -i 命令，确认一下网卡有没有丢包问题：
root@nginx:/
从 netstat 的输出中，你可以看到，接收丢包数（RX-DRP）是 84，果然是在网卡接收时丢包了。不过问题也来了
为什么刚才用 hping3 时不丢包，现在换成 GET 就收不到了呢？
不妨先去查查工具和方法的原理。我们可以对比一下这两个工具：
hping3 实际上只发送了 SYN 包；(-S 选项)而 curl 在发送 SYN 包后，还会发送 HTTP GET 请求。
HTTP GET，本质上也是一个 TCP 包，但跟 SYN 包相比，它还携带了 HTTP GET 的数据。(1、这个包是多大呢？ifconfig可以看；2、怎么看是否允许拆包呢？)
那么，通过这个对比，你应该想到了，这可能是 MTU 配置错误导致的。为什么呢？
其实，仔细观察上面 netstat 的输出界面，第二列正是每个网卡的 MTU 值。eth0 的 MTU 只有 100，而以太网的 MTU 默认值是 1500 ，这个 100 就显得太小了。
当然，MTU 问题是很好解决的，把它改成 1500 就可以了。我们继续在容器终端中，执行下面的命令，把容器 eth0 的 MTU 改成 1500：
?
再次执行curl命令
?
?
以上就是朝夕生活（www.30zx.com）关于“服务器总是时不时丢包，我该怎么办？（下）”的详细内容，希望对大家有所帮助！

下 服务器总是时不时丢包，我该怎么办？

猜你喜欢

下服务器总是时不时丢包，我该怎么办？