Linux 网络访问慢?使用这个方法快速定位

在 linux 服务器中,可以通过内核调优、DPDK 以及 XDP 等多种方式提高服务器的抗攻击能力,降低 DDoS 对正常服务的影响 。在应用程序中,可以使用各级缓存、WAF、CDN 等来缓解 DDoS 对应用程序的影响 。
但是需要注意的是,如果 DDoS 流量已经到达 Linux 服务器,那么即使应用层做了各种优化,网络服务延迟一般也会比平时大很多 。
因此,在实际应用中,我们通常使用 Linux 服务器,配合专业的流量清洗和网络防火墙设备,来缓解这个问题 。
除了 DDoS 导致的网络延迟增加,我想你一定见过很多其他原因导致的网络延迟,例如:

  • 网络传输慢导致的延迟 。
  • Linux 内核协议栈数据包处理速度慢导致的延迟 。
  • 应用程序数据处理速度慢造成的延迟等 。
那么当我们遇到这些原因造成的延误时,我们该怎么办呢?如何定位网络延迟的根本原因?让我们在本文中讨论网络延迟 。
Linux 网络延迟谈到网络延迟?.NETwork Latency),人们通常认为它是指网络数据传输所需的时间 。但是,这里的“时间”是指双向流量,即数据从源发送到目的地,然后从目的地地址返回响应的往返时间:RTT(Round-Trip Time) 。
除了网络延迟之外,另一个常用的指标是应用延迟(Application Latency),它是指应用接收请求并返回响应所需的时间 。通常,应用延迟也称为往返延迟,它是网络数据传输时间加上数据处理时间的总和 。
?通常人们使用 ping 命令来测试网络延迟,ping 是基于 ICMP 协议的,它通过计算 ICMP 发出的响应报文和 ICMP 发出的请求报文之间的时间差来获得往返延迟时间 。这个过程不需要特殊的认证,从而经常被很多网络攻击所利用,如,端口扫描工具 nmap、分组工具 hping3 等 。
因此,为了避免这些问题,很多网络服务都会禁用 ICMP,这使得我们无法使用 pi?ng 来测试网络服务的可用性和往返延迟 。在这种情况下,您可以使用 traceroute 或 hping3 的 TCP 和 UDP 模式来获取网络延迟 。
例如:
# -c: 3 requests# -S: Set TCP SYN# -p: Set port to 80$ hping3 -c 3 -S -p 80 google.comHPING google.com (eth0 142.250.64.110): S set, 40 headers + 0 data byteslen=46 ip=142.250.64.110 ttl=51 id=47908 sport=80 flags=SA seq=0 win=8192 rtt=9.3 mslen=46 ip=142.250.64.110 ttl=51 id=6788sport=80 flags=SA seq=1 win=8192 rtt=10.9 mslen=46 ip=142.250.64.110 ttl=51 id=37699 sport=80 flags=SA seq=2 win=8192 rtt=11.9 ms--- baidu.com hping statistic ---3 packets transmitted, 3 packets received, 0% packet lossround-trip min/avg/max = 9.3/10.9/11.9 ms当然,你也可以使用 traceroute:
$ traceroute --tcp -p 80 -n google.comtraceroute to google.com (142.250.190.110), 30 hops max, 60 byte packets 1* * * 2240.1.236.340.198 ms * * 3* * 243.254.11.50.189 ms 4* 240.1.236.170.216 ms 240.1.236.240.175 ms 5241.0.12.760.181 ms 108.166.244.150.234 ms 241.0.12.760.219 ms ...24142.250.190.11017.465 ms 108.170.244.118.532 ms 142.251.60.20718.595 mstraceroute 会在路由的每一跳(hop)发送三个数据包,并在收到响应后输出往返延迟 。如果没有响应或响应超时(默认 5s),将输出一个星号 * 。
案例展示我们需要在此演示中托管 host1 和 host2 两个主机:
  • host1 (192.168.0.30):托管两个 Nginx Web 应用程序(正常和延迟)
  • host2 (192.168.0.2):分析主机
host1 准备在 host1 上,让我们运行启动两个容器,它们分别是官方 Nginx 和具有延迟版本的 Nginx:
# Official nginx$ Docker run --network=host --name=good -itd nginxfb4ed7cb9177d10e270f8320a7fb64717eac3451114c9fab3c50e02be2e88ba2# Latency version of nginx$ docker run --name nginx --network=host -itd feisky/nginx:latencyb99bd136dcfd907747d9c803fdc0255e578bad6d66f4e9c32b826d75b6812724【Linux 网络访问慢?使用这个方法快速定位】运行以下命令以验证两个容器都在为流量提供服务:
$ curl http://127.0.0.1<!DOCTYPE html><html>...<p><em>Thank you for using nginx.</em></p></body></html>$ curl http://127.0.0.1:8080...<p><em>Thank you for using nginx.</em></p></body></html>host2 准备现在让我们用上面提到的 hping3 来测试它们的延迟,看看有什么区别 。在 host2 中,执行以下命令分别测试案例机的 8080 端口和 80 端口的延迟:
80 端口:
$ 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=64 DF id=0 sport=80 flags=SA seq=0 win=29200 rtt=7.8 mslen=44 ip=192.168.0.30 ttl=64 DF id=0 sport=80 flags=SA seq=1 win=29200 rtt=7.7 mslen=44 ip=192.168.0.30 ttl=64 DF id=0 sport=80 flags=SA seq=2 win=29200 rtt=7.6 ms--- 192.168.0.30 hping statistic ---3 packets transmitted, 3 packets received, 0% packet lossround-trip min/avg/max = 7.6/7.7/7.8 ms


推荐阅读