Linux 网络延迟排查方法 linux查看网络延迟
sinye56 2024-12-23 13:26 11 浏览 0 评论
在 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”，如下图：
然后，关闭弹出的对话框并返回Wireshark主窗口。这时你会发现Wireshark已经自动为你设置了一个过滤表达式tcp.stream eq 24。如下图所示（图中省略了源 IP 和目的 IP）：
从这里，您可以看到从三次握手开始，此 TCP 连接的每个请求和响应。当然，这可能不够直观，可以继续点击菜单栏中的 Statistics -> Flow Graph，选择 “Limit to display filter”，将 Flow type 设置为 “TCP Flows”：
请注意，此图的左侧是客户端，而右侧是 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 的调用是否正常。
链接：https://zhuanlan.zhihu.com/p/525246901
相关推荐
- CTO偷偷传我的系统性能优化十大绝招(万字干货)
-
上篇引言：取与舍软件设计开发某种意义上是“取”与“舍”的艺术。关于性能方面，就像建筑设计成抗震9度需要额外的成本一样，高性能软件系统也意味着更高的实现成本，有时候与其他质量属性甚至会冲突，比如安全性、...
- 提升效率!VMware虚拟机性能优化十大实用技巧
-
我40岁，干跨境婚恋中介的。为服务各国用户，常得弄英语、日语、俄语系统环境，VMware虚拟机帮了不少忙。用久了发现优化下性能，效率能更高。今儿就来聊聊优化技巧和同类软件。一、VMware虚拟...
- 低延迟场景下的性能优化实践
-
本文摘录自「全球C++及系统软件技术大会」ScottMeyers曾说到过，如果你不在乎性能，为什么要在C++这里，而不去隔壁的Pythonroom呢？今天我们就从“低延迟的概述”、“低延迟系...
- Linux性能调优之内存负载调优的一些笔记
-
写在前面整理一些Linux内存调优的笔记，分享给小伙伴博文没有涉及的Demo,理论方法偏多，可以用作内存调优入门博文内容涉及:Linux内存管理的基本理论寻找内存泄露的进程内存交换空间调优不同方式的...
- 优化性能套路:带你战胜这只后段程序员的拦路虎
-
来源｜极客时间《卖桃者说》作者｜池建强编辑｜成敏你好，这里是卖桃者说。今天给大家推荐一篇文章，来自倪朋飞老师的专栏《Linux性能优化实战》，文章主要讲的是优化性能的套路，这几乎是每个后端程序员...
- SK海力士CXL优化解决方案已成功搭载于Linux:带宽提升30%，性能提升12%以上
-
SK海力士宣布，已将用于优化CXL（ComputeExpressLink）存储器运行的自研软件异构存储器软件开发套件（HMSDK）中主要功能成功搭载于全球最大的开源操作系统Linux上，不但提升了...
- Linux内核优化:提升系统性能的秘诀
-
Linux内核优化：提升系统性能的艺术在深入Linux内核优化的世界之前，让我们先来理解一下内核优化的重要性。Linux内核是操作系统的核心，负责管理系统资源和控制硬件。一个经过精心优化的内核可以显著...
- Linux系统性能优化:七个实战经验
-
Linux系统的性能是指操作系统完成任务的有效性、稳定性和响应速度。Linux系统管理员可能经常会遇到系统不稳定、响应速度慢等问题，例如在Linux上搭建了一个web服务，经常出现网页无法打开、打开速...
- 腾讯面试:linux内存性能优化总结
-
【1】内存映射Linux内核给每个进程都提供了一个独立且连续的虚拟地址空间，以便进程可以方便地访问虚拟内存；虚拟地址空间的内部又被分为内核空间和用户空间两部分，不同字长的处理器，地址空间的范围也不同...
- Linux文件系统性能调优《参数优化详解》
-
由于各种的I/O负载情形各异,Linux系统中文件系统的缺省配置一般来说都比较中庸,强调普遍适用性。然而在特定应用下,这种配置往往在I/O性能方面不能达到最优。因此,如果应用对I/O性能要求较高,除...
- Nginx 性能优化(吐血总结)
-
一、性能优化考虑点当我需要进行性能优化时，说明我们服务器无法满足日益增长的业务。性能优化是一个比较大的课题，需要从以下几个方面进行探讨当前系统结构瓶颈了解业务模式性能与安全1、当前系统结构瓶颈首先需要...
- Linux问题分析与性能优化
-
排查顺序整体情况：top/htop/atop命令查看进程/线程、CPU、内存使用情况，CPU使用情况；dstat2查看CPU、磁盘IO、网络IO、换页、中断、切换，系统I/O状态;vmstat2查...
- 大神级产品:手机装 Linux 运行 Docker 如此简单
-
本内容来源于@什么值得买APP，观点仅代表作者本人｜作者：灵昱Termux作为一个强大的Android终端模拟器，能够运行多种Linux环境。然而，直接在Termux上运行Docker并不可行，需要...
- 新手必须掌握的Linux命令
-
Shell就是终端程序的统称，它充当了人与内核（硬件）之间的翻译官，用户把一些命令“告诉”终端程序，它就会调用相应的程序服务去完成某些工作。现在包括红帽系统在内的许多主流Linux系统默认使用的终端是...
- Linux 系统常用的 30 个系统环境变量全解析
-
在Linux系统中，环境变量起着至关重要的作用，它们犹如隐藏在系统背后的“魔法指令”，掌控着诸多程序的运行路径、配置信息等关键要素。尤其在shell脚本编写时，巧妙运用环境变量，能让脚本如虎...
欢迎 你 发表评论:
- 一周热门
- 最近发表
- 标签列表
-
- oracle忘记用户名密码 (59)
- oracle11gr2安装教程 (55)
- mybatis调用oracle存储过程 (67)
- oracle spool的用法 (57)
- oracle asm 磁盘管理 (67)
- 前端 设计模式 (64)
- 前端面试vue (56)
- linux格式化 (55)
- linux图形界面 (62)
- linux文件压缩 (75)
- Linux设置权限 (53)
- linux服务器配置 (62)
- mysql安装linux (71)
- linux启动命令 (59)
- 查看linux磁盘 (72)
- linux用户组 (74)
- linux多线程 (70)
- linux设备驱动 (53)
- linux自启动 (59)
- linux网络命令 (55)
- linux传文件 (60)
- linux打包文件 (58)
- linux查看数据库 (61)
- linux获取ip (64)
- linux进程通信 (63)