我的设备连接到提供一些视频片段的服务器。连接到服务器后，我检查了 wireshark，发现从客户端（端口 40334）到服务器（80）有多个 RST，但服务器没有停止发送数据包。我假设一旦客户端发送 RST，服务器就应该关闭套接字。
10秒后，我看到客户端开始使用另一个端口（40520）并向服务器发送HTTP GET，并且客户端成功从服务器获取MP4数据包。
- 为什么客户端向服务器发送多个RST，而服务器却不停止发送数据包？
- 为什么客户端收到服务器发来的数据包时没有返回 ACK？
谢谢。
pcap 截图 1：来自客户端的多个 RST
pcap 截图 2：正常从服务器获取数据。
日志 ：https://drive.google.com/file/d/1gkt5c_WdLGYvZGMasrQLdP8a-RcQeqrt/view?usp=sharing
答案1
我强烈怀疑问题在于您将其设置SEQ为 1 并且没有给它一个与您的转账稍微对应的数字。
作为从旧重复中恢复的一个简单示例，请考虑图 9。在第 3 行，一个旧的重复 SYN 到达 TCP B。TCP B 无法判断这是一个旧的重复，因此它正常响应（第 4 行）。TCP A 检测到 ACK 字段不正确，并返回 RST（重置），其 SEQ 字段被选中，以生成段 可信。TCP B 在收到 RST 后，返回到 LISTEN 状态。
和
复位处理
在除 SYN-SENT 之外的所有状态下，所有重置 (RST) 段都通过检查其 SEQ 字段进行验证。如果重置的序列号在窗口中，则重置有效。 在 SYN-SENT 状态（响应初始 SYN 而收到的 RST）下，如果 ACK 字段确认了 SYN，则 RST 是可以接受的。
RST 的接收方首先验证它，然后更改状态。如果接收方处于 LISTEN 状态，则忽略它。如果接收方处于 SYN-RECEIVED 状态并且之前处于 LISTEN 状态，则接收方返回 LISTEN 状态，否则接收方中止连接并进入 CLOSED 状态。如果接收方处于任何其他状态，则它会中止连接并通知用户并进入 CLOSED 状态。
因此我建议不要将其设置SEQ为 1，而是将其设置为您得到的最后一个SEQ数字，否则它很可能会被忽略为无效。
RST如果序列号或确认号无效，则可能无法兑现。
恢复时间
控制位（重置），不占用序列空间，表示接收方应删除连接而无需进一步交互。接收方可以根据传入段的序列号和确认字段来确定，它是否应该遵守重置命令或忽略它。在任何情况下，收到包含 RST 的段都不会导致响应 RST。
您的客户端很懒，没有正确地重置连接，而是直接丢弃它并从另一个端口启动新的连接。