windows - 服务器发送 RST 消息-6ren

windows - 服务器发送 RST 消息

转载作者：可可西里更新时间：2023-11-01 02:52:16

我正在开发服务器，客户端消息通过手机发送。服务器和手机通过 Wifi 连接。

客户端向服务器发送 HTTP Post 消息，服务器应该回复 200 ok。它适用于大多数系统，但在某些系统中，服务器收到 POST 消息后，它会回复一个 TCP RST。

服务器 IP 为:192.168.1.2，客户端 IP 为:192.168.1.9。这是不起作用时的流程。

|Time     | 192.168.1.9                           |
|         |                   | 192.168.1.2       |                   
|103.313276|         49988 > 5901 [SYN]            |TCP: 49988 > 5901 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=306973 TSecr=0 WS=64
|         |(49988)  ------------------>  (5901)   |
|103.313469|         5901 > 49988 [SYN,            |TCP: 5901 > 49988 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=8 TSval=0 TSecr=0 SACK_PERM=1
|         |(49988)  <------------------  (5901)   |
|106.281619|         5901 > 49988 [SYN,            |TCP: 5901 > 49988 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=8 TSval=0 TSecr=0 SACK_PERM=1
|         |(49988)  <------------------  (5901)   |
|112.316765|         5901 > 49988 [SYN,            |TCP: 5901 > 49988 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=8 TSval=0 TSecr=0 SACK_PERM=1
|         |(49988)  <------------------  (5901)   |
|124.381196|         POST 192.168.1.2:59           |HTTP: POST 192.168.1.2:5901/ftcontentserver.rcs.mnc.mcc.pub.3gppnetwork.org HTTP/1.1 
|         |(49988)  ------------------>  (5901)   |
|124.381300|         5901 > 49988 [RST]            |TCP: 5901 > 49988 [RST] Seq=1 Win=0 Len=0
|         |(49988)  <------------------  (5901)   |

这是它起作用的地方:

|Time     | 192.168.1.3                           | 192.168.1.2                           |
|         |                   | 192.168.1.2       |                   
|117.828732|         42956 > 5901 [SYN]            |                   |TCP: 42956 > 5901 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=2994458 TSecr=0 WS=64
|         |(42956)  ------------------>  (5901)   |                   |
|117.828828|         5901 > 42956 [SYN,            |                   |TCP: 5901 > 42956 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=8 TSval=0 TSecr=0 SACK_PERM=1
|         |(42956)  <------------------  (5901)   |                   |
|117.930471|         42956 > 5901 [ACK]            |                   |TCP: 42956 > 5901 [ACK] Seq=1 Ack=1 Win=14656 Len=0 TSval=2994490 TSecr=0
|         |(42956)  ------------------>  (5901)   |                   |
|117.930932|         [TCP Window Update]           |                   |TCP: [TCP Window Update] 5901 > 42956 [ACK] Seq=1 Ack=1 Win=262800 Len=0 TSval=75822 TSecr=2994490
|         |(42956)  <------------------  (5901)   |                   |
|117.941444|         POST 192.168.1.2:59           |                   |HTTP: POST 192.168.1.2:5901/ftcontentserver.rcs.mnc.mcc.pub.3gppnetwork.org HTTP/1.1 
|         |(42956)  ------------------>  (5901)   |                   |
|117.964006|         HTTP/1.1 204 No Con           |                   |HTTP: HTTP/1.1 204 No Content 
|         |(42956)  <------------------  (5901)   |                   |

这是我在第一种情况下遇到的错误:专家信息(警告/协议(protocol)):确认号:断开的 TCP。确认字段为非零且未设置 ACK 标志

有人可以提出可能出错的地方吗？

这是wireshark转储

No.     Time        Source                Destination           Protocol Length Info
      1 0.000000    192.168.1.9           192.168.1.2           TCP      74     49988 > 5901 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=306973 TSecr=0 WS=64

Frame 1: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)
Ethernet II, Src: Lge_4c:96:28 (5c:17:d3:4c:96:28), Dst: IntelCor_d4:8d:40 (00:23:14:d4:8d:40)
Internet Protocol Version 4, Src: 192.168.1.9 (192.168.1.9), Dst: 192.168.1.2 (192.168.1.2)
Transmission Control Protocol, Src Port: 49988 (49988), Dst Port: 5901 (5901), Seq: 0, Len: 0

No.     Time        Source                Destination           Protocol Length Info
      2 0.000193    192.168.1.2           192.168.1.9           TCP      78     5901 > 49988 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=8 TSval=0 TSecr=0 SACK_PERM=1

Frame 2: 78 bytes on wire (624 bits), 78 bytes captured (624 bits)
Ethernet II, Src: IntelCor_d4:8d:40 (00:23:14:d4:8d:40), Dst: Lge_4c:96:28 (5c:17:d3:4c:96:28)
Internet Protocol Version 4, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.9 (192.168.1.9)
Transmission Control Protocol, Src Port: 5901 (5901), Dst Port: 49988 (49988), Seq: 0, Ack: 1, Len: 0

No.     Time        Source                Destination           Protocol Length Info
      3 2.968343    192.168.1.2           192.168.1.9           TCP      78     5901 > 49988 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=8 TSval=0 TSecr=0 SACK_PERM=1

Frame 3: 78 bytes on wire (624 bits), 78 bytes captured (624 bits)
Ethernet II, Src: IntelCor_d4:8d:40 (00:23:14:d4:8d:40), Dst: Lge_4c:96:28 (5c:17:d3:4c:96:28)
Internet Protocol Version 4, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.9 (192.168.1.9)
Transmission Control Protocol, Src Port: 5901 (5901), Dst Port: 49988 (49988), Seq: 0, Ack: 1, Len: 0

No.     Time        Source                Destination           Protocol Length Info
      4 9.003489    192.168.1.2           192.168.1.9           TCP      78     5901 > 49988 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=8 TSval=0 TSecr=0 SACK_PERM=1

Frame 4: 78 bytes on wire (624 bits), 78 bytes captured (624 bits)
Ethernet II, Src: IntelCor_d4:8d:40 (00:23:14:d4:8d:40), Dst: Lge_4c:96:28 (5c:17:d3:4c:96:28)
Internet Protocol Version 4, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.9 (192.168.1.9)
Transmission Control Protocol, Src Port: 5901 (5901), Dst Port: 49988 (49988), Seq: 0, Ack: 1, Len: 0

No.     Time        Source                Destination           Protocol Length Info
      5 21.067920   192.168.1.9           192.168.1.2           HTTP     148    POST 192.168.1.2:5901/ftcontentserver.rcs.mnc.mcc.pub.3gppnetwork.org HTTP/1.1 

Frame 5: 148 bytes on wire (1184 bits), 148 bytes captured (1184 bits)
Ethernet II, Src: Lge_4c:96:28 (5c:17:d3:4c:96:28), Dst: IntelCor_d4:8d:40 (00:23:14:d4:8d:40)
Internet Protocol Version 4, Src: 192.168.1.9 (192.168.1.9), Dst: 192.168.1.2 (192.168.1.2)
Transmission Control Protocol, Src Port: 49988 (49988), Dst Port: 5901 (5901), Seq: 1, Ack: 1, Len: 82
Hypertext Transfer Protocol

No.     Time        Source                Destination           Protocol Length Info
      6 21.068024   192.168.1.2           192.168.1.9           TCP      54     5901 > 49988 [RST] Seq=1 Win=0 Len=0

Frame 6: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)
Ethernet II, Src: IntelCor_d4:8d:40 (00:23:14:d4:8d:40), Dst: Lge_4c:96:28 (5c:17:d3:4c:96:28)
Internet Protocol Version 4, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.9 (192.168.1.9)
Transmission Control Protocol, Src Port: 5901 (5901), Dst Port: 49988 (49988), Seq: 1, Len: 0

最佳答案

对于这种情况，它不工作，TCP 握手没有完成。原因是本地端没有向接收到的 SYN/ACK 发送 ACK。为了更好的可读性，我提供了 3 次握手的简短/编辑变体:

49988 > 5901 [SYN]  |TCP: 49988 > 5901 [SYN] Seq=0 Win=14600 Len=0 MSS=1460
5901 > 49988 [SYN,  |TCP: 5901 > 49988 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460
5901 > 49988 [SYN,  |TCP: 5901 > 49988 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460
5901 > 49988 [SYN,  |TCP: 5901 > 49988 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460

对于失败的情况，3次握手完成:

42956 > 5901 [SYN]  ||TCP: 42956 > 5901 [SYN] Seq=0 Win=14600 Len=0 MSS=1460
5901 > 42956 [SYN,  ||TCP: 5901 > 42956 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460
42956 > 5901 [ACK]  ||TCP: 42956 > 5901 [ACK] Seq=1 Ack=1 Win=14656 Len=0

现在，为什么部分.. 一旦发出 connect()，底层 TCP 将发送 SYN 并响应 SYN-ACK，所以我在这里看到任何不好的事情，除了本地堆栈正在采取有更多时间响应 SYN-ACK。此外，客户端在发送请求之前是否等待 connect() 成功。如果 connect() 没有通过或被延迟，那么它不应该在该连接上发送任何数据。

关于windows - 服务器发送 RST 消息，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19099031/

文章推荐：客户端/服务器之间的 C++/Winsock TCP 发送/接收问题

文章推荐： java - 返回 0 的本地化消息的输出键

文章推荐： java - 守护线程启动的线程也是守护线程吗？

vba - 如何将 rst.FindFirst 与 rst.NoMatch 一起使用？
除了这一行，我的代码有效 .FindFirst "[DONOR_CONTACT_ID] = strTemp2" 我希望我的代码检查是否有记录，其中存在特定的 DONOR_CONTACT_ID，因为有多
linux - 是什么原因以及如何避免 [FIN, ACK] , [RST] 和 [RST, ACK]
[FIN, ACK]、[RST]和[RST, ACK]是什么原因，如何避免？是否是由于 SO 的 TCP 参数之间存在某种不匹配？服务器在 TCP/IP 连接中回复 [FIN, ACK] 是什么意思
c - 为什么内核在发送一定数量的字节后会强制从客户端强制发送TCP RST？
我有简单的“echo”客户端-服务器代码，并通过tcpdump监视tcp流，客户端在发送274之后始终发送RST。总是。但是我不知道如何找到问题所在。客户端: //FILE to read from
c++ - RST 数据包是否会被发送到应用程序而不考虑其序列号？
当应用程序从套接字接收数据时，它将按照数据发送的正确顺序接收数据。 TCP 将知道如何根据每个数据包 header 中包含的序列号对数据重新排序。但是 RST 数据包呢，例如:如果另一方发送了一些数
tcp - 如何使用自定义服务器手动发送 RST？
我正在尝试调试一个场景，为此我希望 http 服务器通过 RST 关闭连接。现在它正在使用 fin/ack 进行优雅的关闭。有什么方法可以手动发送 RST 数据包以关闭连接作为当前流的一部分？可能是
TCP RST 数据包详细信息
为什么 TCP RST 数据包不需要确认？是不是因为RST的发送端每次收到对方的包都会继续发送RST？相关说明，有效RST包中的确认号怎么会是0呢？最佳答案 On a related note,
markdown - 如何创建没有前置空格的 RST 代码块？
我真正喜欢 Markdown 的地方在于我可以执行以下操作: 写```回车粘贴我剪贴板中的所有垃圾编写``` 我现在有一个工作代码块在 RST 中，我必须执行以下操作: 编写.. codeblo
python-sphinx - rst 中的粗体代码
如何获得在 rst 中加粗的代码(等宽)文本(我使用的是 Sphinx)？ :: 中的任何内容似乎是按字面呈现的，就像 `` 一样，所以 ``**bold**`` 不起作用。最佳答案一般来说，嵌套
python - 具有内部缩进的 RST 代码块
我正在使用 Sphinx 来记录返回字典的方法。 def do_stuff(foo, bar): """Do some stuff :param foo: I'm an argumen
python - 将图像放入 .rst 的语法
我对将图像放入 pelican 的 markdown 语法感到困惑。当我有了这个，一切正常。 .. image:: /images/Rugby-Tackle.jpg :alt: About
c - 是否可以在不发送 RST 的情况下中止关闭套接字？
我有一个已连接的套接字，我想中止关闭它，但我不希望将 RST 发送到另一端。这可以吗？最佳答案您的问题体现了自相矛盾。 “异常关闭”== RST。即使实际的中止关闭没有立即发送，TCP 也有义务
c++ - 客户端在关闭后向收到的数据包发送 RST(SHUT_WR)
使用 shutdown() 关闭套接字连接的写入方向后，所有后续接收到的数据都会导致发送 RST 数据包，并且 read() 返回大小为 0 的数据，表示读取方向的 EOF。即使阅读方向没有关闭，为什
c - 使用双指针从 RST 树中删除节点
我有一个 RST 树，它的结构是: struct node { int key; node *left, *right; } *root; 我的功能是删除带有“v”键的节点: void
c - 是否保证在进程终止时发送 RST 数据包？
如果我有一个带有连接套接字的进程，并且我终止了这个进程，那么 Windows 将导致发送一个 RST 数据包。是否保证(是否在某处记录)当进程终止时始终发送 RST 数据包，还是可以发送 FIN 数
python - 将命令行工具的使用帮助添加到 README.rst
我写了一个小命令行工具，想在文档中添加“--help”用法消息。因为我很懒，所以我希望更新过程尽可能简单。这是我希望更新工作流程的样子: 导致更新使用消息的更新代码。运行更新文档的脚本:新的用法消
linux - 为什么主机总是响应 `RST` 虽然服务器正在监听端口？
我正在使用 gitlab docker image 来部署服务，Web 端口是主机上的 8080。运行 gitlab 后，我可以看到端口正常: CONTAINER ID IMAGE
windows - 服务器发送 RST 消息
我正在开发服务器，客户端消息通过手机发送。服务器和手机通过 Wifi 连接。客户端向服务器发送 HTTP Post 消息，服务器应该回复 200 ok。它适用于大多数系统，但在某些系统中，服务器收到
sockets - TCP RST 会导致主机丢弃接收缓冲区吗？
在收到一个 TCP RST 数据包后，主机是否会丢弃接收缓冲区中已被远程主机确认但未被使用套接字的应用进程读取的所有剩余数据？我想知道一旦我对其他主机所说的不再感兴趣(例如，为了节省资源)就关闭套接
c - 客户端被杀死或崩溃时内核发送的 TCP RST
我有一个客户端和服务器运行在同一台服务器(Linux 机器)上，它们之间有 TCP 连接。我观察到，当我杀死客户端时，内核/操作系统会在客户端被杀死 2 秒后发送 RST 数据包。我的问题是哪个内核参
winsock生成reset(RST)的tcp closesocket方法
Windows socket close(closesocket)函数生成RST。在 Linux 上，当我调用 close 函数关闭一个 tcp 套接字时，它会通过来自客户端服务器的 fin/ack

可可西里

个人简介

我是一名优秀的程序员,十分优秀！

作者热门文章

滴滴打车优惠券免费领取

全站热门文章

首页

博学

6Ren·AI

商城

windows - 服务器发送 RST 消息