背景说明

开发团队最近遇到网络延迟问题，从国内访问国外的业务接口耗时超过2s，这严重影响用户体验。我们正在寻找通过网络优化来减少请求延迟的方法。因此，我们决定利用这个问题分析案例，解析 curl 在检测网络连接各阶段的耗时情况，并分享给大家。希望在将来，当您遇到类似的问题时，这个分析方法能够帮助到您。当然如果您有更好的工具和方法，欢迎在评论区留言，分享给大家。

Ping 延时检测

❯ ping 169.8.10.11
PING 169.8.10.11 (169.8.10.11): 56 data bytes
64 bytes from 169.8.10.11: icmp_seq=0 ttl=45 time=213.884 ms
64 bytes from 169.8.10.11: icmp_seq=1 ttl=45 time=213.133 ms
64 bytes from 169.8.10.11: icmp_seq=2 ttl=45 time=213.938 ms
64 bytes from 169.8.10.11: icmp_seq=3 ttl=45 time=213.264 ms
64 bytes from 169.8.10.11: icmp_seq=4 ttl=45 time=213.599 ms
64 bytes from 169.8.10.11: icmp_seq=5 ttl=45 time=213.412 ms
64 bytes from 169.8.10.11: icmp_seq=6 ttl=45 time=213.210 ms
64 bytes from 169.8.10.11: icmp_seq=7 ttl=45 time=213.477 ms
64 bytes from 169.8.10.11: icmp_seq=8 ttl=45 time=213.172 ms
^C
--- 169.8.10.11 ping statistics ---
9 packets transmitted, 9 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 213.599/213.121/213.477/0.259 ms

测试用例

[root@demo ~]# curl -o /dev/null -s -w time_namelookup:"\t"%{time_namelookup}"\n"time_connect:"\t\t"%{time_connect}"\n"time_appconnect:"\t"%{time_appconnect}"\n"time_pretransfer:"\t"%{time_pretransfer}"\n"time_starttransfer:"\t"%{time_starttransfer}"\n"time_total:"\t\t"%{time_total}"\n"time_redirect:"\t\t"%{time_redirect}"\n" --location 'https://api.rockylinux.cn' --header 'Content-Type: application/json' --header 'Cookie: ID=xxx;' --data '{"key":["xxx","xxx"]}'
time_namelookup:        0.000391
time_connect:           0.226977
time_appconnect:        0.694236
time_pretransfer:       0.695058
time_starttransfer:     0.993051
time_total:             0.993199
time_redirect:          0.000000

curl 参数说明

curl 命令的参数非常多，可以使用 curl --help all 命令查看所有参数，这里使用 curl 命令来测试接口性能，下面是每个参数的具体含义：

• -o /dev/null：告诉 curl 将下载的数据丢弃，不输出到任何文件中。"/dev/null" 是一个特殊的设备，它会丢弃所有写入它的数据。
• -s：告诉 curl 在操作过程中不显示进度信息或错误信息。这通常用于在脚本中静默运行 curl。
• -w：允许您设置显示的格式，后面跟的是具体的格式字符串。在这个命令中，它被用来显示各种时间信息。
• time_namelookup：DNS 解析的时间，即从请求开始到域名解析完成的时间。
• time_connect：建立到服务器的 TCP 连接所需的时间。
• time_appconnect：建立到应用级别协议的连接所需的时间。例如，在使用 HTTPS 时，这将包括 SSL 握手的时间。
• time_pretransfer：从请求开始到文件传输即将开始所需的时间。
• time_starttransfer：从请求开始到第一个字节被 curl 接收的时间。
• time_total：整个请求所需的总时间。
• time_redirect：所有重定向步骤所需的时间，包括 DNS 解析、连接、预传输等。
• https://api.rockylinux.cn：想要访问的网站的 URL。

这个命令的总体目的是测试访问指定 URL 各个阶段所需时间。

耗时拆解分析

time_namelookup: 0.000391 # DNS 解析耗时 0.0003s，可以通过绑定 hosts 提高响应速度。
time_connect: 0.226977 # TCP 建立连接耗时 0.226977 – 0.000391 = 0.226586s，如果走的是国际互联网，Ping 的请求延时也在 213 ms，那么这个时间也是正常的。
time_appconnect: 0.694236 # SSL 握手完成耗时：0.694236 – 0.226977 = 0.467259s，SSL 连接还是非常耗时的，这里走 CDN 加速，有一定的缓解。
time_pretransfer: 0.695058 # 从连接建立以后，到第一个数据包传输前的准备时长为: 0.695058 – 0.694236 = 0.000822s，说明服务器本身处理的速度是很快的。
time_starttransfer: 0.993051 # 客户端接收到服务器端第一个数据包传输的时长为: 0.993051 – 0.695058 = 0.297993s，也就是耗时 298 ms 左右，这与走国际互联网 Ping 的请求延时 213ms，相差只有 298 – 213 = 85ms。也就是实际服务器端处理只花费了 85ms，如果这个值比较大，那么这可能意味着服务器处理请求的时间比较长，也就是说，服务器在收到请求后，需要花费一些时间来准备和开始发送响应。这个时间可能包括了服务器的处理时间，例如查询数据库、执行服务器端的计算或脚本等。这可能是由于服务器负载高、处理能力较低、服务器跨互联网进行数据传输网络耗时长或者服务器端程序处理效率低下等原因造成的。您可能需要检查服务器的负载情况，或者优化服务器端的处理逻辑，以改善响应时间。
time_total: 0.993199 # 从接收到第一个数据包后，到最后全部接收完成，耗时: 0.993199 – 0.993051 = 0.000148s，说明数据包并不大，所以耗时短。
time_redirect: 0.000000 # 整个过程没有重定向（redirect），所以 redirect 的耗时为0 。

写在最后

网络分析工具的种类繁多，其中包括了诸如 Ping、Traceroute、MTR、Curl、Netstat、Nmap、Tcpdump、Route 等。然而，这些工具只能为我们提供操作的手段，真正能够解决问题的，还是解决问题的方法与思路，这就需要我们自身不断积累的知识和经验。因此，如何更有效地利用这些工具，发挥其最大的作用，显得尤为重要。

赞赏