8080 端口:
# 测试8080端口延迟$ hping3 -c 3 -S -p 8080 192.168.0.30HPING 192.168.0.30 (eth0 192.168.0.30): S set, 40 headers + 0 data byteslen=44 ip=192.168.0.30 ttl=64 DF id=0 sport=8080 flags=SA seq=0 win=29200 rtt=7.7 mslen=44 ip=192.168.0.30 ttl=64 DF id=0 sport=8080 flags=SA seq=1 win=29200 rtt=7.6 mslen=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 lossround-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 connectionsThread StatsAvgStdevMax+/- StdevLatency9.19ms12.32ms 319.61ms97.80%Req/Sec6.20k426.808.25k85.50%Latency Distribution50%7.78ms75%8.22ms90%9.14ms99%50.53ms123558 requests in 10.01s, 100.15MB readRequests/sec:12340.91Transfer/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 connectionsThread StatsAvgStdevMax+/- StdevLatency43.60ms6.41ms56.58ms97.06%Req/Sec1.15k120.291.92k88.50%Latency Distribution50%44.02ms75%44.33ms90%47.62ms99%48.88ms22853 requests in 10.01s, 18.55MB readRequests/sec:2283.31Transfer/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 网络访问慢?使用这个方法快速定位](http://img.jiangsulong.com/230321/16251I962-0.jpg)
文章插图
然后,关闭弹出的对话框并返回 Wireshark 主窗口 。这时你会发现 Wireshark 已经自动为你设置了一个过滤表达式 tcp.stream eq 24 。如下图所示(图中省略了源 IP 和目的 IP):
![Linux 网络访问慢?使用这个方法快速定位](http://img.jiangsulong.com/230321/16251H536-1.jpg)
文章插图
从这里,您可以看到从三次握手开始,此 TCP 连接的每个请求和响应 。当然,这可能不够直观,可以继续点击菜单栏中的 Statistics -> Flow Graph,选择 “Limit to display filter”,将 Flow type 设置为 “TCP Flows”:
![Linux 网络访问慢?使用这个方法快速定位](http://img.jiangsulong.com/230321/16251K292-2.jpg)
文章插图
请注意,此图的左侧是客户端,而右侧是 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)Enablequickack 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 isnotperma‐nent,it only enables a switch to or from quickack mode.Subsequent operation of the TCP protocol willonce again enter/leave quickack mode depending on internalprotocolprocessingandfactorssuchasdelayed ack timeouts occurring and data transfer.This option should not be used in code intended to beportable.
推荐阅读
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 如何实现OT网络安全?
- 永远不要在你的 Linux 系统上运行这些命令
- 手机为什么连不上网(网络正常但手机连不上)
- 什么是mac(什么是手机mac)
- 网络优化是做什么的(无线网络优化是做什么的)
- 丢包率是什么意思(网络正常但是一直丢包)
- 为什么淘宝打不开(为什么网络正常淘宝却打不开)
- 4glte是什么手机(LTE是几G网络)
- 什么网络机顶盒最好(有宽带自己买个机顶盒)
- kgs是什么意思(kgs3)