Wireshark TS | 服务器在三次握手后发送RST ？

7ACE

已于 2024-07-20 11:00:55 修改

阅读量3.6k

点赞数 1

分类专栏： NetShark 文章标签： wireshark 网络网络协议 tcpip tcpdump

于 2021-11-15 19:36:36 首次发布

本文链接：https://blog.csdn.net/weixin_47627078/article/details/121337705

版权

NetShark 专栏收录该内容

93 篇文章 19 订阅

订阅专栏

问题背景

用户提到在大多数时候，服务器响应就像标题所描述的那样出现断连问题，简化的拓扑如下，

客户端 --- 防火墙(NAT/PAT) --- 互联网 --- 防火墙 --- 负载均衡 --- Web 服务器

案例取自 Wireshark 官方问答论坛

问题分析

来自于某一台 Web 服务器上的数据抓包文件，可能的问题会是什么呢？

正常的流
RST-01
比较简短的交互过程，没有任何异常。

问题流
RST-02
确实，充斥了 Bad TCP 和 TCP RST 的着色，而且有一些很特殊的问题，简析如下：

服务器 SYN/ACK 重传

从流中的前 3 个包（帧 70-72）上来看，其实 TCP 三次握手已经完成了，但是服务器仍然在 1.3s 后重传了 SYN/ACK，很奇怪的重传。因为如果像该用户所说，数据包是在服务器上所抓取的话，那么在明显收到客户端第三个 ACK 的情况下，服务器是否仍然认为三次握手没有完成，所以才进一步进行 SYN/ACK 重传。

基于此现象，按以前的经验，个人认为可能需要在服务器上进一步检查此连接具体的状态，是否 ESTABLISHED 等等，但论坛上的专家提到了一个可能引起此现象的问题 TCP_DEFER_ACCEPT 。

❤️ 感谢专家解锁数据包新世界，在此数据包文件的现象中确实匹配这种情况。

TCP_DEFER_ACCEPT (since Linux 2.4)
Allow a listener to be awakened only when data arrives on the socket. Takes an integer value (seconds), this can bound the maximum number of attempts TCP will make to complete the connection. This option should not be used in code intended to be portable.

如果在 Linux 服务器上开启了此选项，服务器会在接收到最后一个 ACK 之后，并不会进入 ESTABLISHED 状态，而是会忽略掉此 ACK ，保持 SYN_RECV 状态不变，然后接下来等待客户端发送数据。而如果客户端数据没有快速跟随时，由于服务器还处于 SYN_RECV 状态，因此就会在超时后进行 SYN/ACK 重传。

正常时的交互，客户端在约 82ms 时发送了 GET 请求，而发生问题时，客户端在约 1.5s 左右才发起 GET 请求，也是造成上述重传的原因。对于客户端的行为也需要同时在负载均衡前后抓包对比分析才能判断，此处缺失。

服务器 RST

服务器在收到客户端 GET 请求后，直接 RST 了连接。此处需要检查 TCP 中的 Seq Num、Ack Num 等，关闭 TCP 选项 Relative sequence numbers 后，观察到客户端发送的帧 74 ACK 编号 2106390967 明显与帧 72 或 73 所要求的 2962498563 不一样，且远在 ISN 之外。服务器因此丢弃这个数据包，并发送帧75 RST 。
RST-03
但在随后帧 76 至最后，客户端也有比较奇怪的行为，在收到 RST 之后仍然发送 ACK，这能解释的也可能是 RST 的 Seq Num 不在有效范围内，因此忽略。

在最后客户端 GET 请求不断重传无响应后，发送 FIN/ACK 关闭连接。