Windows 发送RST消息的服务器_Windows_Sockets_Tcp_Wireshark

Windows 发送RST消息的服务器

windows sockets tcp

Windows 发送RST消息的服务器,windows,sockets,tcp,wireshark,Windows,Sockets,Tcp,Wireshark,我正在开发一个服务器，客户端消息通过手机发送。服务器和手机通过Wifi连接客户端向服务器发送一条HTTPPOST消息，服务器应该用200 ok回复。它在大多数系统中工作，但在某些系统中，服务器接收到POST消息后，会使用TCP RST进行回复服务器IP为：192.168.1.2，客户端IP为：192.168.1.9。这是不工作时的流 |Time | 192.168.1.9 | | |

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

客户端向服务器发送一条HTTPPOST消息，服务器应该用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)   |

对于不起作用的情况，TCP握手没有完成。原因是本地侧没有向接收到的SYN/ACK发送ACK。为了更好的可读性，我提供了一个三向握手的简短/编辑版本：

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

对于失败的情况，三方握手完成：

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（）未通过或延迟，则不应发送该连接上的任何数据

对于不起作用的情况，TCP握手没有完成。原因是本地侧没有向接收到的SYN/ACK发送ACK。为了更好的可读性，我提供了一个三向握手的简短/编辑版本：

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

对于失败的情况，三方握手完成：

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

在它不工作的情况下，当我展开wireshark日志时，ACK通过POST消息发送。但在它工作的情况下，ACK作为单独的消息发送。我没有访问客户端代码的权限，但我认为他们在发送数据之前会等待连接通过。这仅在某些系统中发生。TCP ACK将始终作为connect消息的一部分发送。connect（）步骤仅在三方握手完成时返回（除非是非阻塞的）。因此，我们在这里处理两个问题。首先，为什么应用程序在connect（）成功返回之前发送POST消息。接下来，为什么TCP层不响应来自服务器的3条conrequisive SYN-ACK消息。对于第二步，如果这是一个紧急情况，那么我们就无能为力，因为TCP层可能有很多其他的处理要做，这可能会导致（很少）这样的延迟。这看起来更像是TCP堆栈中的一个bug，而不是应用程序在connect（）中被阻塞时神奇地发送数据，这是不可能的。connect（）会一直阻塞，直到它完成为止，并且在任何情况下，堆栈都应该确保在建立连接之前不会发送数据，即，它已经发送了最终的ACK，该ACK可以在数据上进行备份。程序当然不需要“等待”。除非您有一个多线程应用程序，其中一个应用程序线程发送数据时没有充分等待connect（）线程通过@user1692342您正在使用多线程吗？但是，我同意你的观点，如果套接字没有连接，任何好的TCP堆栈都不应该发送数据。@ManojPandey我已经用wireshark dump更新了这个问题。请查收。我不确定客户端是如何实现的。在这种情况下，当我展开wireshark日志时，ACK通过POST消息发送。但在它工作的情况下，ACK作为单独的消息发送。我没有访问客户端代码的权限，但我认为他们在发送数据之前会等待连接通过。这仅在某些系统中发生。TCP ACK将始终作为connect消息的一部分发送。connect（）步骤仅在三方握手完成时返回（除非是非阻塞的）。因此，我们在这里处理两个问题。首先，为什么应用程序在connect（）成功返回之前发送POST消息。接下来，为什么TCP层不响应来自服务器的3条conrequisive SYN-ACK消息。对于第二步，如果这是一个紧急情况，那么我们就无能为力，因为TCP层可能有很多其他的处理要做，这可能会导致（很少）这样的延迟。这看起来更像是TCP堆栈中的一个bug，而不是应用程序在connect（）中被阻塞时神奇地发送数据，这是不可能的。connect（）会一直阻塞，直到它完成为止，并且在任何情况下，堆栈都应该确保在建立连接之前不会发送数据，即，它已经发送了最终的ACK，该ACK可以在数据上进行备份。程序当然不需要“等待”。除非您有一个多线程应用程序，其中一个应用程序线程发送数据时没有充分等待connect（）线程通过@user1692342您正在使用多线程吗？但是，我同意你的观点，如果套接字没有连接，任何好的TCP堆栈都不应该发送数据。@ManojPandey我已经用wireshark dump更新了这个问题。请查收。我不确定客户端是如何实现的