Linux 网络延迟排查方法详解

这篇具有很好参考价值的文章主要介绍了Linux 网络延迟排查方法详解。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

Linux 网络延迟排查方法详解,linux,网络,tcp/ip


 概要

 

在 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,这使得我们无法使用 ping 来测试网络服务的可用性和往返延迟。在这种情况下,您可以使用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 和 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 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 端口的延迟:

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

从以上两个输出可以看出,官方 Nginx(监听 80 端口)的平均延迟为 9.19ms,而案例 Nginx(监听 8080 端口)的平均延迟为 43.6ms。从延迟分布上来看,官方 Nginx 可以在 9ms 内完成 90% 的请求;对于案例 Nginx,50% 的请求已经达到 44ms。

那么这里发生了什么呢?我们来做一些分析:

在 host1 中,让我们使用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打开。

由于网络包的数量很多,我们可以先过滤一下。例如,选中一个包后,可以右键选择 “Follow”->“TCP Stream”,如下图:

Linux 网络延迟排查方法详解,linux,网络,tcp/ip

 然后,关闭弹出的对话框并返回Wireshark主窗口。这时你会发现Wireshark已经自动为你设置了一个过滤表达式tcp.stream eq 24。如下图所示(图中省略了源 IP 和目的 IP):

Linux 网络延迟排查方法详解,linux,网络,tcp/ip

 从这里,您可以看到从三次握手开始,此 TCP 连接的每个请求和响应。当然,这可能不够直观,可以继续点击菜单栏中的 Statistics -> Flow Graph,选择 “Limit to display filter”,将 Flow type 设置为 “TCP Flows”:

Linux 网络延迟排查方法详解,linux,网络,tcp/ip

 请注意,此图的左侧是客户端,而右侧是 Nginx 服务器。从这个图中可以看出,前三次握手和第一次 HTTP 请求和响应都相当快,但是第二次 HTTP 请求就比较慢了,尤其是客户端收到服务器的第一个数据包后,该 ACK 响应(图中的蓝线)在 40ms 后才被发送。

看到 40ms 的值,你有没有想到什么?事实上,这是 TCP 延迟 ACK 的最小超时。这是 TCP ACK 的一种优化机制,即不是每次请求都发送一个 ACK,而是等待一段时间(比如 40ms),看看有没有“搭车”的数据包。如果在此期间还有其他数据包需要发送,它们将与 ACK 一起被发送。当然,如果等不及其他数据包,超时后会单独发送 ACK。

由于案例中的客户端发生了 40ms 延迟,我们有理由怀疑客户端开启了延迟确认机制(Delayed Acknowledgment Mechanism)。这里的客户端其实就是之前运行的 wrk。

根据 TCP 文档,只有在 TCP 套接字专门设置了 TCP_QUICKACK 时才会启用快速确认模式(Fast Acknowledgment Mode);否则,默认使用延迟确认机制:

TCP_QUICKACK (since Linux 2.4.4)
              Enable  quickack mode if set or disable quickack mode if cleared.  In quickack mode, acks are sent imme‐
              diately, rather than delayed if needed in accordance to normal TCP operation.  This flag is  not  perma‐
              nent,  it only enables a switch to or from quickack mode.  Subsequent operation of the TCP protocol will
              once again enter/leave quickack mode depending on internal  protocol  processing  and  factors  such  as
              delayed ack timeouts occurring and data transfer.  This option should not be used in code intended to be
              portable.

让我们测试一下我们的质疑:

$ strace -f wrk --latency -c 100 -t 2 --timeout 2 http://192.168.0.30:8080/
...
setsockopt(52, SOL_TCP, TCP_NODELAY, [1], 4) = 0
...

可以看到wrk只设置了TCP_NODELAY选项,没有设置TCP_QUICKACK。现在您可以看到为什么延迟 Nginx(案例 Nginx)响应会出现一个延迟。

 

结论

在本文中,展示了如何分析增加的网络延迟。网络延迟是核心网络性能指标。由于网络传输、网络报文处理等多种因素的影响,网络延迟是不可避免的。但过多的网络延迟会直接影响用户体验。

  • 使用hping3和wrk等工具确认单个请求和并发请求的网络延迟是否正常。

  • 使用traceroute,确认路由正确,并查看路由中每个网关跳跃点的延迟。

  • 使用tcpdump和Wireshark确认网络数据包是否正常收发。

  • 使用strace等观察应用程序对网络 socket 的调用是否正常。

 
欢迎点赞收藏转发,感谢🙏

-End-



 

 文章来源地址https://www.toymoban.com/news/detail-533250.html

到了这里,关于Linux 网络延迟排查方法详解的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Linux网络编程——C++实现进程间TCP/IP通信

    地址接口 1、通用地址接口 共16字节 = 2字节地址类型 + 14字节地址数据 2、自定义地址接口 地址转换 1、需要将点分字符串ip转化为程序ip,使用inet_addr函数: 2、字节序转换 地址接口配置中的端口需要字节序转换,网络规定使用大端字节序。 地址接口配置 1、socket:创建套接

    2024年02月20日
    浏览(53)
  • Linux网络-UDP/TCP协议详解

    2023/10/17 14:32:49 Linux网络-UDP/TCP协议详解 零、前言 一、UDP协议 二、TCP协议 1、应答机制 2、序号机制 3、超时重传机制 4、连接管理机制 三次握手 四次挥手 5、理解CLOSE_WAIT状态 6、理解TIME_WAIT状态 7、流量控制 8、滑动窗口 丢包问题 9、拥塞控制 10、延迟应答 11、捎带应答 12、面

    2024年02月07日
    浏览(53)
  • Linux内核--网络协议栈(五)TCP IP栈的实现原理与具体过程

    一、引言 二、Linux内核的结构 三、Linux网络子系统 四、TCP/IP协议栈 ------4.1、网络架构 ------4.2、协议无关接口 ------4.3、套接口缓存 ------4.4、重要的数据结构 五、网络信息处理流程 ------5.1、硬中断处理 ------5.2、ksoftirqd内核线程处理软中断 ------5.3、网络协议栈处理 ------5.4、

    2024年01月21日
    浏览(69)
  • 【Linux】网络基础常识{OSI七层模型/ TCP/IP / 端口号 /各种协议}

    了解网络发展背景,对局域网/广域网的概念有基本认识; 了解网络协议的意义, 重点理解TCP/IP五层结构模型; 学习网络传输的基本流程,理解封装和分用; DHCP(动态主机配置协议,Dynamic Host Configuration Protocol)是一个局域网的网络协议,使用UDP协议工作,主要有两个用途:

    2024年04月14日
    浏览(51)
  • Linux网络编程之TCP/IP实现高并发网络服务器设计指南

    目录 引言: 多进程服务器 例程分享: 多线程服务器  例程分享: I/O多路复用服务器 select 例程分享: poll 例程分享: epoll 例程分享: 总结建议         随着互联网的迅猛发展,服务器面临着越来越多的并发请求。如何设计一个能够高效处理大量并发请求的服务器成为

    2024年02月20日
    浏览(50)
  • Linux TCP队列的实例详解,提高网络性能和稳定性!

    📚 个人网站:ipengtao.com TCP 队列是 Linux 操作系统中关键的网络管理组件,它们有助于控制和优化网络连接的性能。在这篇文章中,将深入研究 Linux TCP 队列的工作原理、配置选项以及提供丰富的示例代码,以帮助大家更好地理解和管理 TCP 队列。 在理解 TCP 队列之前,需要了

    2024年01月18日
    浏览(51)
  • linux 网络配置三种方法(ip、ifconfig、nmcli)

    语法: ip [ OPTIONS ] OBJECT { COMMAND | help }        #[option]与{command|help}参数不是必要参数  OBJECT={ link | addr | addrlabel | route | rule | neigh | ntable | tunnel | maddr | mroute | mrule | monitor | xfrm | token } OPTIONS={ -V[ersion] | -s[tatistics] | -d[etails] | -r[esolve] | -h[uman-readable] | -iec | -f[amily] { inet | inet6 |

    2024年02月04日
    浏览(39)
  • Linux 管理联网 配置网络的四种方法 配置临时连接( ip 命令)

              #         网络接口是指网络中的计算机或网络设备与其他设备实现通讯的进出口。这里,主要是                   指计算机的网络接口即   网卡设备                           #         网络接口 --  网卡 的命名   :                    从RHEL7开

    2023年04月09日
    浏览(55)
  • 【Linux】Linux网络故障排查与解决指南

       🍎 个人博客: 个人主页 🏆 个人专栏: Linux ⛳️   功不唐捐,玉汝于成 目录 前言 正文 检查网络连接状态: 检查路由表: 检查DNS配置: 检查网络连接状态: 检查防火墙设置: 使用网络诊断工具: 检查日志文件: 重启网络服务: 结语  我的其他博客 在Linux系统中

    2024年03月14日
    浏览(46)
  • 详解TCP/IP网络模型

    目录 第一层:物理层 第二层(数据链路层) 第三层(网络层) 第四层(传输层) 第五层(应用层) 网络模型有好几种,其中最常讨论的有俩种: OSI七层参考模型 、 TCP/IP四层参考模型 。 OSI模型 是国际标准模型,结构分的很细,然而既复杂又不实用,我们这篇文章来讲已

    2024年02月05日
    浏览(41)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包