除了 DDoS 导致的网络延迟增加,我想你一定见过很多其他原因导致的网络延迟,例如:
网络传输慢导致的延迟。 Linux 内核协议栈数据包处理速度慢导致的延迟。 应用程序数据处理速度慢造成的延迟等。
Linux 网络延迟
谈到网络延迟(Network Latency),人们通常认为它是指网络数据传输所需的时间。但是,这里的“时间”是指双向流量,即数据从源发送到目的地,然后从目的地地址返回响应的往返时间:RTT(Round-Trip Time)。
除了网络延迟之外,另一个常用的指标是应用延迟(Application Latency),它是指应用接收请求并返回响应所需的时间。通常,应用延迟也称为往返延迟,它是网络数据传输时间加上数据处理时间的总和。
ping
命令来测试网络延迟,ping
是基于 ICMP 协议的,它通过计算 ICMP 发出的响应报文和 ICMP 发出的请求报文之间的时间差来获得往返延迟时间。这个过程不需要特殊的认证,从而经常被很多网络攻击所利用,如,端口扫描工具 nmap
、分组工具 hping3
等。traceroute
或 hping3
的 TCP 和 UDP 模式来获取网络延迟。# -c: 3 requests
# -S: Set TCP SYN
# -p: Set port to 80
$ hping3 -c 3 -S -p 80 google.com
HPING google.com (eth0 142.250.64.110): S set, 40 headers + 0 data bytes
len=46 ip=142.250.64.110 ttl=51 id=47908 sport=80 flags=SA seq=0 win=8192 rtt=9.3 ms
len=46 ip=142.250.64.110 ttl=51 id=6788 sport=80 flags=SA seq=1 win=8192 rtt=10.9 ms
len=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 loss
round-trip min/avg/max = 9.3/10.9/11.9 ms
当然,你也可以使用 traceroute
:
$ traceroute --tcp -p 80 -n google.com
traceroute to google.com (142.250.190.110), 30 hops max, 60 byte packets
1 * * *
2 240.1.236.34 0.198 ms * *
3 * * 243.254.11.5 0.189 ms
4 * 240.1.236.17 0.216 ms 240.1.236.24 0.175 ms
5 241.0.12.76 0.181 ms 108.166.244.15 0.234 ms 241.0.12.76 0.219 ms
...
24 142.250.190.110 17.465 ms 108.170.244.1 18.532 ms 142.251.60.207 18.595 ms
traceroute
会在路由的每一跳(hop)发送三个数据包,并在收到响应后输出往返延迟。如果没有响应或响应超时(默认 5s),将输出一个星号 *
。案例展示
host1 (192.168.0.30):托管两个 Nginx Web 应用程序(正常和延迟) host2 (192.168.0.2):分析主机
host1 准备
# Official nginx
$ docker run --network=host --name=good -itd nginx
fb4ed7cb9177d10e270f8320a7fb64717eac3451114c9fab3c50e02be2e88ba2
# Latency version of nginx
$ docker run --name nginx --network=host -itd feisky/nginx:latency
b99bd136dcfd907747d9c803fdc0255e578bad6d66f4e9c32b826d75b6812724
运行以下命令以验证两个容器都在为流量提供服务:
$ 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 端口的延迟:$ hping3 -c 3 -S -p 80 192.168.0.30
HPING 192.168.0.30 (eth0 192.168.0.30): S set, 40 headers + 0 data bytes
len=44 ip=192.168.0.30 ttl=64 DF id=0 sport=80 flags=SA seq=0 win=29200 rtt=7.8 ms
len=44 ip=192.168.0.30 ttl=64 DF id=0 sport=80 flags=SA seq=1 win=29200 rtt=7.7 ms
len=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 loss
round-trip min/avg/max = 7.6/7.7/7.8 ms
8080 端口:
# 测试8080端口延迟
$ hping3 -c 3 -S -p 8080 192.168.0.30
HPING 192.168.0.30 (eth0 192.168.0.30): S set, 40 headers + 0 data bytes
len=44 ip=192.168.0.30 ttl=64 DF id=0 sport=8080 flags=SA seq=0 win=29200 rtt=7.7 ms
len=44 ip=192.168.0.30 ttl=64 DF id=0 sport=8080 flags=SA seq=1 win=29200 rtt=7.6 ms
len=44 ip=192.168.0.30 ttl=64 DF id=0 sport=8080 flags=SA seq=2 win=29200 rtt=7.3 ms
--- 192.168.0.30 hping statistic ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 7.3/7.6/7.7 ms
从这个输出中您可以看到两个端口的延迟大致相同,均为 7 毫秒。但这仅适用于单个请求。如果换成并发请求怎么办?接下来,让我们用 wrk
(https://github.com/wg/wrk) 试试。
80 端口:
$ wrk --latency -c 100 -t 2 --timeout 2 http://192.168.0.30/
Running 10s test @ http://192.168.0.30/
2 threads and 100 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 9.19ms 12.32ms 319.61ms 97.80%
Req/Sec 6.20k 426.80 8.25k 85.50%
Latency Distribution
50% 7.78ms
75% 8.22ms
90% 9.14ms
99% 50.53ms
123558 requests in 10.01s, 100.15MB read
Requests/sec: 12340.91
Transfer/sec: 10.00MB
8080 端口:
$ wrk --latency -c 100 -t 2 --timeout 2 http://192.168.0.30:8080/
Running 10s test @ http://192.168.0.30:8080/
2 threads and 100 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 43.60ms 6.41ms 56.58ms 97.06%
Req/Sec 1.15k 120.29 1.92k 88.50%
Latency Distribution
50% 44.02ms
75% 44.33ms
90% 47.62ms
99% 48.88ms
22853 requests in 10.01s, 18.55MB read
Requests/sec: 2283.31
Transfer/sec: 1.85MB
tcpdump
捕获一些网络数据包:$ tcpdump -nn tcp port 8080 -w nginx.pcap
现在,在 host2 上重新运行 wrk
命令
$ wrk --latency -c 100 -t 2 --timeout 2 http://192.168.0.30:8080/
wrk
命令完成后,再次切换回 Terminal 1(host1 的终端)并按 Ctrl+C 结束 tcpdump
命令。然后,用 Wireshark
把抓到的 nginx.pcap
复制到本机(如果 VM1(host1 的虚拟机)已经有图形界面,可以跳过复制步骤),用 Wireshark
打开。然后,关闭弹出的对话框并返回 Wireshark
主窗口。这时你会发现 Wireshark
已经自动为你设置了一个过滤表达式 tcp.stream eq 24
。如下图所示(图中省略了源 IP 和目的 IP):
从这里,您可以看到从三次握手开始,此 TCP 连接的每个请求和响应。当然,这可能不够直观,可以继续点击菜单栏中的 Statistics -> Flow Graph,选择 “Limit to display filter”,将 Flow type 设置为 “TCP Flows”:
wrk
。TCP_QUICKACK
时才会启用快速确认模式(Fast Acknowledgment Mode);否则,默认使用延迟确认机制:$ traceroute --tcp -p 80 -n google.com
0
traceroute to google.com (142.250.190.110), 30 hops max, 60 byte packets
1 * * *
2 240.1.236.34 0.198 ms * *
3 * * 243.254.11.5 0.189 ms
4 * 240.1.236.17 0.216 ms 240.1.236.24 0.175 ms
5 241.0.12.76 0.181 ms 108.166.244.15 0.234 ms 241.0.12.76 0.219 ms
...
24 142.250.190.110 17.465 ms 108.170.244.1 18.532 ms 142.251.60.207 18.595 ms
让我们测试一下我们的质疑:
$ traceroute --tcp -p 80 -n google.com
1
traceroute to google.com (142.250.190.110), 30 hops max, 60 byte packets
1 * * *
2 240.1.236.34 0.198 ms * *
3 * * 243.254.11.5 0.189 ms
4 * 240.1.236.17 0.216 ms 240.1.236.24 0.175 ms
5 241.0.12.76 0.181 ms 108.166.244.15 0.234 ms 241.0.12.76 0.219 ms
...
24 142.250.190.110 17.465 ms 108.170.244.1 18.532 ms 142.251.60.207 18.595 ms
可以看到 wrk
只设置了 TCP_NODELAY
选项,没有设置 TCP_QUICKACK
。现在您可以看到为什么延迟 Nginx(案例 Nginx)响应会出现一个延迟。
结论
在本文中,我们向您展示如何分析增加的网络延迟。网络延迟是核心网络性能指标。由于网络传输、网络报文处理等多种因素的影响,网络延迟是不可避免的。但过多的网络延迟会直接影响用户体验。
使用
hping3
和wrk
等工具确认单个请求和并发请求的网络延迟是否正常。使用
traceroute
,确认路由正确,并查看路由中每个网关跳跃点的延迟。使用
tcpdump
和Wireshark
确认网络数据包是否正常收发。使用
strace
等观察应用程序对网络 socket 的调用是否正常。
好文推荐
推荐站内搜索:最好用的开发软件、免费开源系统、渗透测试工具云盘下载、最新渗透测试资料、最新黑客工具下载……
还没有评论,来说两句吧...