你的网络还好吗

LinkinStar

发布于 2022-09-01 14:05:29

1.7K0

发布于 2022-09-01 14:05:29

文章被收录于专栏：LinkinStar's BlogLinkinStar's Blog

之前说了 CPU、内存、IO 在排查过程中可能出现的问题以及出现问题会影响的指标，这次就来看看在 linux 中网络的问题。

在实际中我们遇到的最多的网络问题就是：不通！！！无论是 ping 不通，物理链路不通，还是 dns 解析有问题导致的不通，还是容器间网络访问网络隔离造成的不通，等等，这个问题总是由于部署上的环境导致的。还有一类比较烦的问题就是网络带宽本来就不高的情况下，大量的请求导致网络的拥塞，最明显的感受就是接口请求超时，各种超时，nginx 超时，请求本身超时等等。对于这些问题如何进行排查呢？

诊断指标

sar

命令

sar -n DEV 1

[root@Linkin ~]# sar -n DEV 1
Linux 3.10.0-1062.9.1.el7.x86_64 (Linkin) 	07/04/2020 	_x86_64_	(2 CPU)

03:03:40 PM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
03:03:41 PM br-22dd849a79f5      0.00      0.00      0.00      0.00      0.00      0.00      0.00
03:03:41 PM br-dac186ab0c70      0.00      0.00      0.00      0.00      0.00      0.00      0.00
03:03:41 PM veth860c89a      0.00      0.00      0.00      0.00      0.00      0.00      0.00
03:03:41 PM      eth0      5.00      4.00      0.30      2.43      0.00      0.00      0.00
03:03:41 PM        lo      0.00      0.00      0.00      0.00      0.00      0.00      0.00
03:03:41 PM   docker0      0.00      0.00      0.00      0.00      0.00      0.00      0.00

指标

这个命令可以清楚的看到整体的网络吞吐情况

rxpck/s、 txpck/s 接收和发送的 PPS 包 / 秒

rxkB/s、txkB/s 接收和发送的吞吐量 KB/ 秒

iperf3

命令

用于测试网速、带宽

# -s 表示启动服务端，-i 表示汇报间隔，-p 表示监听端口
$ iperf3 -s -i 1 -p 10000

# -c 表示启动客户端，192.168.10.30 为目标服务器的 IP
# -b 表示目标带宽 (单位是 bits/s)
# -t 表示测试时间
# -P 表示并发数，-p 表示目标服务器监听端口
$ iperf3 -c 192.168.10.30 -b 1G -t 15 -P 2 -p 10000

nslookup & dig

命令

千万不要小看 DNS 的问题，很多时候 DNS 解析会出现很多问题，特别是有 DNS 缓存的时候

# 安装
yum install bind-utils

# 使用
nslookup www.baidu.com

# +trace 表示开启跟踪查询
# +nodnssec 表示禁止 DNS 安全扩展
dig +trace +nodnssec www.baidu.com
dig linkinstar.com @localhost

tcpdump

这个抓包工具可太强大了，命令参数也很多，举例常用的：

# -i eth0 指定网卡
# -nn host 10.0.2.1 主机过滤
# -nn tcp 协议过滤
# -nn dst port 80 端口过滤

内核参数修改提及

其实很多网络优化的参数都是可以通过修改 linux 内核参数进行调优

vi /etc/sysctl.conf

但是这里的调整可太讲究了，涉及的知识点太多，缓冲区最大值、队列长度等等，其实我的建议是，要不就直接不动，等到有问题再说，要不就直接交给有经验的运维搞定，直接复制网上的配置文件覆盖不太可取，万一出现问题不知道如何进行处理。

排查步骤

保证网络通，那肯定一上来最靠谱的就是 ping 了，网络要是都不通的话，那就没啥好说的了
查看网络请求情况，就是看，现在网络是否确实请求量很大，或者说请求数量很多，或者带宽资源不足等情况
查看网络资源状态，查看当前有多少连接数，各个 TCP\UDP 连接状态是否正常，很大程度上就能反映出问题

排查原因

其实网络导致的问题可以分为两种：

不通
卡了

但是导致这两种情况出现的原因纷繁复杂，太多无厘头的问题出现了，导致网络一直是 linux 里面的一座大山。

下面举例说几种现实中出现过的情况。

防火墙

几乎所有的人都会被这个玩意坑过一次，长记性之后又会被坑第二次。

第一次玩 linux 服务器的时候就被这个玩意坑了一天，所有东西查到最后，发现防火墙没关，或者端口没开放，导致无法访问。

第二次是云服务器坑了一波，服务器的防火墙是关了，但是云厂商有着自己的安全策略规则，你必须手动去网页上开放进行设置。

DNS 解析问题

这里分为两种，一种是外网的 DNS 解析，这种要不就是 DNS 服务器没配置，要不就是 DNS 解析服务器确实有问题。

一种是内网的 DNS 解析，因为内网里面也会使用 DNS 进行访问和请求，这个时候很多时候就会出现问题，一般就是 ping 不通，然后就用 dig 进行查。

还有就是前面的 LB 层，也就是如 NGINX 这样的负载均衡上缓存了 DNS 解析，当后面的 IP 更换导致负载出现问题。

大量 TIME_WAIT

出现原因是程序 bug，大量客户端请求后异常关闭，说 TCP 的时候这个状态之前说过，这里就不再详述了。

大量 SYN_RECV

可能由于 SYN FLOOD 攻击导致，那这个调内核参数可以缓解，但是如果真的是外网部署遇到这样的情况，如果出现频繁，优先考虑封 IP，云厂商的服务或者 CDN

容器间网络不通

虽然现在又 K8S 这样的容器编排，但在这之前容器间的网络总是有着各种问题，无论是使用 host 网络，还是网桥，总之网络不通服务无法访问，总是存在，这个时候抓包往往就成了最靠谱的解决方案。ping，然后直接抓 icmp 包，一个个抓过来，eth0，docker0，flannel0…

请求过多

其实很多时候，网络上的问题就是请求发过去相应时间过长了，导致用户感受就是卡，而卡在网络情况不好的时候反映尤为明显，需要注意的是，有的时候带宽资源占满，你可能连服务器都无法进行登录了。

这个时候你需要做的就是分析出现这样情况的原因，多数情况下都是由于最底层的数据查询有问题，导致 IO 瓶颈等，一般来说，优化数据库查询时间往往成为了解决问题的关键。其次就是缓存，这个往往马上就能瞬间提升性能。最后就是，要做好安全和限流工作，再怎么说服务器总是有瓶颈的，如果用户之间压你的服务，就是想把你带宽占满，如果没有做好合理的安全策略和限流工作，恐怕很快就凉了。