在使用 WRK(A 侧)对 nginx(B 侧)进行负载测试时,我看到了一些 TCPSynRetrans。在 180 秒的运行中,TCPSynRetrans 的数量少于 10,每秒请求数约为 400(根据 wrk 最终报告)。
wrk -t 1 -c 50 -d 180s -H 'Connection: close' https://<B_IP>/static/0kb.bin
从捕获的信息中,我看到 A 发出了一个 SYN,但 B 尚未应答
1秒后,A重新传输SYN,然后B用[SYN,ACK]进行应答
通过查看数据包捕获,我看到 SYN 到达目标 nginx。连接也正常关闭,因此我没有建立等待连接的时间队列。我还验证了 syn_backlog 队列没有问题(netstat -ant | grep -c SYN_REC),并且没有看到任何 ListenDrops ListenOverflows。
所以我想知道是否可以安全地假设三次握手完全由操作系统负责并继续进行调查?
hping3,关于如何进一步进行故障排除的任何提示,我们也非常感谢。
答案1
普通应用程序使用套接字接口访问 TCP 套接字。套接字接口抽象了 TCP 连接的底层细节,如握手、重传等。
因此,您的假设是正确的,即网络堆栈负责 TCP 三次握手。
通过查看数据包捕获,我看到SYN到达目标nginx。
这个说法是错误的。nginx 看不到 SYN 数据包。运行 nginx 的服务器上的网络堆栈可以看到 SYN 数据包。
nginx 仅看到进入绑定到某个 TCP 端口的套接字的字节。
https://www.alibabacloud.com/blog/why-are-linux-kernel-protocol-stacks-dropping-syn-packets_595251包含一些有关为什么 SYN 数据包偶尔被丢弃的信息。