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

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

1、有了这款Linux网络延迟排查方法，再也不用加班了在我的上一篇文章中，我向您展示了如何模拟DDoS攻击以及如何缓解它。简单回 顾一下，DDoS利用了大量的伪造请求，导致目标服务器消耗大量资源来处理这些 无效请求，从而无法正常响应正常用户请求。在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 SYNto 80# -p: Set port$ hping3 -c 3 -S -p HPING google (ethO data byteslen=46 ip=142.250.64.110 win=8192 rtt=9.3 ms len=46 ip=142.250.64.110 win=8192 rtt=10.9 mslen=46 ip=142.250.64.110 win=8192 rtt=l1.9 ms$ hping3 -c

5、 3 -S -p HPING google (ethO data byteslen=46 ip=142.250.64.110 win=8192 rtt=9.3 ms len=46 ip=142.250.64.110 win=8192 rtt=10.9 mslen=46 ip=142.250.64.110 win=8192 rtt=l1.9 ms80 google 142. 250. 64. 110):ttl=51 id=47908ttl=51 id=6788ttl=51 id=37699S set, 40 headers + 0sport=80 flags=SA seq=0flags=SA s

6、eq=lsport=80 flags=SA seq=2sport=80 baidu 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, comtraceroute to google, com (142. 250. 190. 110),30 hops max, 60 bytepackets 1* * *2

7、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. 60. 20718. 595 mstraceroute会在路由的每一跳（hop）发送三个

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

9、17eac3451114c9fab3c50e02be2e88ba2Latency version of ngi nx$ docker run -name nginx -network=host -itd feisky/nginx:latenc yb99bdi36dcfd907747d9c803fde0255e578bad6d66f4e9c32b826d75b6812724运行以下命令以验证两个容器都在为流量提供服务：$ curl :/127. 0. 0. 1 Thank you for using nginx.$ curl :/127.0.0.1:8080 Thank you for usin

10、g nginx. host2准备现在让我们用上面提到的 hping3 来测试它们的延迟，看看有什么区别。在 host2中，执行以下命令分别测试案例机的8080端口和80端口的延迟: 80 端口： $ hping3 -c 3 -S -p 80 192. 168. 0. 3040 headers40 headersHPING 192. 168. 0. 30 (ethO 192. 168. 0. 30) : S set,data byteslen=44 ip= 192. 168. 0. 30 n=29200 rtt=7.8 ms len=44 ip=192, 168. 0. 30 n=29200 r

11、tt=7.7 ms len=44 ip=192.168.0.30 n=29200 rtt=7.6 msttl=64 DF id=0 sport=80tt1=64 DF id=0 sport=80ttl=64 DFid=0 sport=80- 192. 168. 0. 30 hping3 packets transmitted,statistic3 packets received,0%flags=SA seq=0 flags=SA seq=lflags二SA seq=2packet losswiwiwiround-trip min/avg/max7. 6/7. 7/7. 8 ms8080 端口

12、： # 测试8080端口延迟$ hping3 -c 3 -S -p 8080 192. 168. 0. 30HPING 192.168.0.30 (ethO 192.168.0.30): S set, 40 headers + 0data bytes len=44 ip=192.168.0.30 win=29200 rtt=7.7 ms len=44 ip=192.168.0.30 win=29200 rtt=7.6 ms len=44 ip=192.168.0.30 win=29200 rtt=7.3 msdata bytes len=44 ip=192.168.0.30 win=29200

13、 rtt=7.7 ms len=44 ip=192.168.0.30 win=29200 rtt=7.6 ms len=44 ip=192.168.0.30 win=29200 rtt=7.3 msttl=64tt1=64tt1=64DFDFDFid=0id=0id=0sport=8080sport=8080sport=8080flags二SAflags=SAflags=SAseq=0seq=lseq=2192. 168. 0. 30 hpingstatistic3 packets transmitted,3 packets transmitted,3 packets received, 0%

14、 packet lossround-trip min/avg/maxround-trip min/avg/max7. 3/7. 6/7. 7 ms从这个输出中您可以看到两个端口的延迟大致相同,从这个输出中您可以看到两个端口的延迟大致相同,均为7毫秒。但这仅适用于个请求。如果换成并发请求怎么?接下来，让我们wrk ( s : /github. com/wg/wrk) 试试。80 :/192.168.0.30/wrk latency -c 100 -t 2 timeoutRunning 10s test2 threads andRunning 10s test2 threads and 100 c

15、onnectionsThread StatsLatencyReq/SecAvg9.19msStdev12. 32msMax319.61ms6. 20k426. 808. 25k+/- Stdev97. 80%85. 50%Latency Distribution50%7. 78ms75%8. 22ms90%9. 14ms99%50. 53ms123558 requests in 10.01s,100.15MBreadRequests/sec:Transfer/sec:Requests/sec:Transfer/sec:12340.9110.00MB8080 端口：$ wrk -latency

16、0/-c 100 -t 2timeout2 .168. 0. 30:808Running 10s test2 threads andRunning 10s test2 threads and :/192.168.0.30:8080/100 connectionsThread StatsThread StatsLatencyReq/SecAvg 43. 60msStdev6. 41msMax56.58ms1. 15k120. 291. 92k+/- Stdev97. 06%88. 50%Latency Distribution50%50%44. 02ms75%44. 33ms90%47. 62m

17、s99%48. 88ms22853 requestsRequests/sec:Transfer/sec:in 10. 01s, 2283.3118.55MB read1.85MB从以上两个输出可以看出，官方Nginx （监听80端口）的平均延迟为9. 19ms, 而案例Nginx （监听8080端口）的平均延迟为43.6ms。从延迟分布上来看，官方Nginx可以在9ms内完成90%的请求；对于案例Nginx, 50%的请求已经到达 44ms o那么这里发生了什么呢？我们来做一些分析：在hostl中，让我们使用tcpdump捕获一些网络数据包:$ tcpdump -nn tcp port 808

18、0 -w nginx. pcap现在，在host2上重新运行 wrk 命令$ wrk -latency -c 100 -t 2 -timeout 2 :/192.168.0.30:808 0/当 wrk 命令完成后，再次切换回Terminal 1 （hostl的终端）并按Ctrl+C结 束 tcpdump 命令。然后，用 Wireshark 把抓到的 nginx. pcap 复制到本机 （如果VM1 （ host!的虚拟机）已经有图形界面，可以跳过复制步骤），用 Wireshark 翻开。由于网络包的数量很多，我们可以先过滤一下。例如，选中一个包后，可以右键选择 “Follow” - “TCP

19、 Streamv ,如下列图：Mark/Unmark Packet 算 MIgnore/Unignore Packet第DSet/Unset Time Reference然TTime Shift.仑算TPacket Comment.、然CEdit Resolved Name=43 Win=29056 Len=0 TSva 1 Ack=43 Win=29056 Len=2： k=239 Win=30336 Len=0 TS、k=851 Win=31616 Len=0 TS851 Ack=85 Win=29056 Len： k=1089 Win=32768 Len=0 T；Apply as Fil

20、terPrepare a FilterConversation Filter Colorize Conversation-SCTP k=1701 Win=34048 Len=0 T! :be)Follow TCP Stream X 分界 TCopyProtocol PreferencesDecode AsShow Packet in New WindowUDP Stream*UTLS Stream分算S Stream能H然后，关闭弹出的对话框并返回 Wireshark 主窗口。这时你会发现 Wireshark 已经自动为你设置了一个过滤表达式 tcp. stream eq 24 o如下图所示（

21、图中省略了源IP和目的IP）：tcp.stream eq 24TimeProtocolLength Info52 0.003657 TCP55 0.003676 TCP2552702724244424454766506970.0072700.0073090.0073130.0087760.0092400.0092530.0094910.0110100.012670TCP TCP TCP TCP TCP TCP1173.056483 TCP1175 0.056488 1225 0.056931 TCP74 58644 - 8080 SYN Seq=0 Win=29200 Len=0 MSS=14

22、1i74 8080 58644 SYN, ACK Seq=0 Ack=l Win=28960 Ler6610866304666786610830458644 8080 ACKGET / /1.18080 586448080 5864458644 8080 /1.1 20058644 8080ACK PSHr ACKSeq=l Ack=l Win=29312 Len=0 TfSeq=l Ack=43 Win=29056 Len=0 ACK Seq=l Ack=43 Win=29056 L( Seq=43 Ack=239 Win=30336 Len=(OK (text/html)ACK Seq=4

23、3 Ack=851 Win=31616 Len=(GET / /1.18080 58644 PSHr ACK Seq=851 Ack=85 Win=2905666 58644 - 8080 ACK Seq=85 Ack=1089 Win=32768 Len：678 /1.1 200 OK (text/html)66 58644 - 8080 ACK Seq=85 Ack=1701 Win=34048 Len=从这里，您可以看到从三次握手开始，此TCP连接的每个请求和响应。当然，这可能不够直观，可以继续点击菜单栏中的 Statistics - Flow Graph ,选择u Limit to d

24、isplay filter”，将 Flow type 设置为 TCP Flowsn ：Time192.168 0 30Comment0.0036570.0036760.0072700.0073090.0073130.0087760.0092400.0092530.0094910.0110100.0126700.0564830.05648811158644 *I- 808058644 %; 808011iack158644 180803-way handshake .58644 jACK - 3： 42的前11iacki58644 M； 808058644 t.叫 A2385 808011|AC

25、K158644 ；808058644 M：8080111ack58644 r 8080First request and response58644 ；5H: A - 5：孤808058644 Mi:80801158644 ；808058644 L魁-12： 8。8。Second request and responseseq = 0seq = 0 Ack = 1Seq = 1 Ack = 15eq = 1 Ack = 1Seq = 1 Ack = 43Seq = 1 Ack = 43seq = 43 Ack = 239Seq = 239 Ack = 43Seq = 43 Ack = 851s

26、eq = 43 Ack = 851seq = 851 Ack = 85seq = 85 Ack = 1089seq = 1089 ACK S 85Packet 1173: Seq 2 85 Ack 1089Q Limit to display filterFlow type: TCP FlowsAddresses:请注意，此图的左侧是客户端，而右侧是Nginx服务器。从这个图中可以看出，前三次握手和第一次 请求和响应都相当快，但是第二次 请求就比拟慢了，尤其是客户端收到服务器的第一个数据包后，该ACK响应(图中的蓝线)在40ms40ms后才被发送。看到40ms的值，你有没有想到什么？事实上，这

27、是 TCP延迟ACK的最小超时。这是TCP ACK的一种优化机制，即不是每次请求都发送一个ACK,而是等待一段时间(比方40ms),看看有没有“搭车”的数据包。如果在此期间还有其他数据包需要发送，它们将与ACK 一起被发送。当然，如果等不及其他数据包，超时后会单独发送ACKo由于案例中的客户端发生了 40ms延迟，我们有理由怀疑客户端开启了延迟确认机制(Delayed Acknowledgment Mechanism )。这里的客户端其实就是之前运行的 wrko根据TCP文档，只有在TCP套接字专门设置了 TCP_QUICKACK时才会启用快速确认模式(Fast Acknowledgment

28、Mode)；否那么，默认使用延迟确认机制:TCP_QUICKACK (since Linux 2.4.4)Enablequickack mode if set or di sab 1e quickackmode if cleared.In quickackdiately,mode,ratheracks are sent imme -than delayed if neededin accordance to normal TCP operation.This flagis notperma -nent,nent,itonlyenables aswitch to orfrom quickack

29、mode, willSubsequentoperation of theTCPprotocolinternal protocolThis option shouldonce again processing delayed ack not be used portable.enter/leave quickackand factors suchtimeouts occurring in code intendedmode depending onasand data transfer.to be让我们测试一下我们的质疑:t 2 timeout 2 :/192.$ strace -f wrk 一

30、一latency -c 100168.0.30:8080/setsockopt (52, S0L_TCP, TCP_NODELAY, 1,4)可以看到 wrk只设置了 TCP_NODELAY 选项，没有设置 TCP_QUTCKACKO现在 您可以看到为什么延迟Nginx （案例Nginx）响应会出现一个延迟。结论在本文中，我将向您展示如何分析增加的网络延迟。网络延迟是核心网络性能指标。 由于网络传输、网络报文处理等多种因素的影响，网络延迟是不可防止的。但过多 的网络延迟会直接影响用户体验。 使用 hping3和 wrk等工具确认单个请求和并发请求的网络延迟是否正 常。 使用traceroute,确认路由正确，并查看路由中每个网关跳跃点的延迟。 使用 tcpdump和 Wireshark确认网络数据包是否正常收发。 使用strace等观察应用程序对网络socket的调用是否正常。