有了这款 Linux 网络延迟排查方法再也不用加班了.docx

《有了这款 Linux 网络延迟排查方法再也不用加班了.docx》由会员分享，可在线阅读，更多相关《有了这款 Linux 网络延迟排查方法再也不用加班了.docx（9页珍藏版）》请在第一文库网上搜索。

1、有了这款Linux网络延迟排查方法，再也不用加班了在我的上一篇文章中，我向您展示了如何模拟DDoS攻击以及如何缓解它。简单回顾一下，DDoS利用了大量的伪造请求，导致FI标服务器消耗大量资源来处理这些无效请求，从而无法正常响应正常用户请求。在Linux服务器中，可以通过内核调优、DPDK以及XDP等多种方式提高服务器的抗攻击能力，降低DDoS对正常服务的影响。在应用程序中，可以使用各级缓存、WAF. CDN等来缓解DDoS对应用程序的影响。但是需要注意的是，如果DDoS流量已经到达Linux服务器，那么即使应用层做了各种优化，网络服务延迟一般也会比平时大很多。因此，在实际应用中，我们通常使用L

2、inux服务器，配合专业的流量清洗和网络防火墙设备，来缓解这个问题。除了 DDoS导致的网络延迟增加，我想你一定见过很多其他原因导致的网络延迟，例如：网络传输慢导致的延迟。Linux内核协议栈数据包处理速度慢导致的延迟。应用程序数据处理速度慢造成的延迟等。那么当我们遇到这些原因造成的延误时，我们该怎么办呢？如何定位网络延迟的根本原因？让我们在本文中讨论网络延迟。Linux网络延迟谈到网络延迟(Network Latency),人们通常认为它是指网络数据传输所需的时间。但是，这里的“时间”是指双向流量，即数据从源发送到目的地，然后从目的地地址返回响应的往返时间：RTT (Round-Trip T

3、ime)。除了网络延迟之外，另一个常用的指标是应用延迟(Application Latency),它是指应用接收请求并返回响应所需的时间。通常，应用延迟也称为往返延迟，它是网络数据传输时间加上数据处理时间的总和。通常人们使用ping命令来测试网络延迟，ping是基于ICMP协议的，它通过计算ICMP发出的响应报文和ICMP发出的请求报文之间的时间差来获得往返延迟时间。这个过程不需要特殊的认证，从而经常被很多网络攻击所利用，如，端口扫描工具 nmap、分组工具hping3等。因此，为了避免这些问题，很多网络服务都会禁用ICMP,这使得我们无法使用ping来测试网络服务的可用性和往返延迟。在这种情

4、况下，您可以使用 traceroute 或 hping3 的TCP和UDP模式来获取网络延迟。例如：# -c: 3 requests# -s： Set TCP SYN# -p: Set port to 80$ hping3 -c 3 -S -pHPING (ethOdata byteslen=46 ip=142.250.64. 110win=8192 rtt=9.3 mslen=46 ip=142.250.64. 110win=8192 rtt=10.9 mslen=46 ip=142.250.64.110win=8192 rtt=l1.9 ms80 142. 250. 64. 110):tt

5、l=51ttl=51ttl=51id=47908id=6788id=37699S set, 40 headerssport=80 flags=SAsport=80 flags=SAsport=80 flags=SA hping statistic 3 packets transmitted, 3 packets received, 0% packet 1round-trip min/avg/max = 9.3/10.9/1L 9 ms当然，你也可以使用 traceroute：$ traceroute -tcp -p 80 -n traceroute to google, com (142.25

6、0. 190. 110),30 hops max, 60 bytepackets1* * *2 240. 1. 236. 340. 198 ms * *3 * * 243. 254. 11. 50. 189 ms4 * 240. 1. 236. 170. 216 ms 240. 1. 236. 240. 175 ms5 241. 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. 6

7、0. 20718. 595 mstraceroute会在路由的每一跳（hop）发送三个数据包，并在收到响应后输出往返延迟。如果没有响应或响应超时(默认5s),将输出一个星号*。案例展示我们需要在此演示中托管hostl和host2两个主机：# hostl (192. 168. 0. 30)：托管两个Nginx Web应用程序(正常和延迟)# host2 (192. 168. 0. 2)：分析主机hostl准备在hostl上，让我们运行启动两个容器，它们分别是官方Nginx和具有延迟版本的 Nginx：# Offi cial nginx$ docker run -network=host -nam

8、e=good -itd nginxfb4ed7cb9177dl0e270f8320a7fb64717eac3451114c9fab3c50e02be2e88ba2# Latency version of nginx$ docker run -name nginx -network=host -itd feisky/nginx:latencyb99bdi36dcfd907747d9c803fde0255c578bad6d66f4e9c32b826d75b6812724运行以下命令以验证两个容器都在为流量提供服务：$ curl http:/127. 0. 0. 1 Thank you for us

9、ing nginx. $ curl http:/127.0.0.1:8080 Thank you for using nginx.host2准备现在让我们用上面提到的hping3来测试它们的延迟，看看有什么区别。在host2中，执行以下命令分别测试案例机的8080端口和80端口的延迟:80 端口:$ hping3 -c 3 -S -p 80 192. 168. 0. 30HP I NG 192. 168. 0. 30 (ethO 192. 168. 0. 30) : S set,40 headers + 0data byteslen=44 ip=192.168.0.30 ttl-64 DFn=

10、29200 rtt=7.8 mslen=44 ip=192.168.0.30 ttl=64 DFn=29200 rtt=7.7 mslen=44 ip=192.168.0.30 ttl=64 DFn=29200 rtt=7.6 msid=0 sport=80id=0 sport=80id=0 sport=80192.168.0.30 hping statistic3 packetsround-triptransmitted, 3 packets received,min/avg/max = 7.6/7.7/7.8 ms0%flags二SA seq=0 wiflags=SA seq=l wifl

11、ags=SA seq=2 wipacket loss8080 端口：#测试8080端口延迟$ hping3 -c 3 -S -p8080 192. 168. 0. 30HPING 192. 168.0.30 (ethO 192.168. 0. 30):S set,40 headersdata byteslen=44 ip=192.168.0.30win=29200 rtt=7.7 mslen=44 ip=192.168.0.30win=29200 rtt=7.6 mslen=44 ip=192.168.0.30win=29200 rtt=7.3 ms 192.168.0.30 hping3 p

12、ackets transmitted,round-trip min/avg/maxttl-64tt1=64tt1=64DFDFDFstatistic3 packetsid-0id-0id=0sport=8080sport=8080sport=8080flags=SAflags二SAflags=SAreceived, 0% packet loss7. 3/7. 6/7. 7 msseq=0soq=lseq=2从这个输出中您可以看到两个端口的延迟大致相同，均为7毫秒。但这仅适用于个请求。如果换成并发请求怎么?接下来，让我们wrk (https:/github. com/wg/wrk) 试试。80w

13、rk latencyRunning 10s test2 threads and-c 100 -t 2 -timeout http:/192. 168. 0. 30/100 connectionshttp:/192.168.0.30/Thread StatsLatencyReq/SecAvg9.19msStdev12.32msMax319.61ms+/- Stdev97.80%6. 20k426. 808. 25k85. 50%Latency Distribution50%7. 78ms75%8. 22ms90%9.14ms99%50. 53ms123558 requests in 10.01s,100.15MBreadRequests/sec:Transfer/sec:12340.9110.00MB8080 端口：$ wrk -latency0/-c 100 -t 2timeout2 http:/192.168.0.30:808Running 10s test2 threads and http:/192.168.0.30:8080/100 connectionsThread StatsLatencyReq/SecAvg43. 60msStdev6. 41msMax56.58ms+/- Stdev97. 06%1. 15k120. 291. 92k88. 50%Latency