问TCP: SYN请求收到SYN响应，而不是SYN-ACK

EN

如果套接字在TIME_WAIT上，并且附加了新的syn，则内核将检查SYN的序列号是否大于或小于为此正在使用的套接字接收的最后一个序列号。

你可以查看这篇文章/答案：https://serverfault.com/questions/297134/server-not-sending-a-syn-ack-packet-in-response-to-a-syn-packet

通常，如果发送了一个SYN，接收到另一个没有ACK的SYN，则通常只是丢失了线路上的ACK (特别是在您的情况下)。当您从A(客户端)到B(服务器)的路由很短，而您的数据包从服务器到客户端的路径特别长，并且穿过的网络可能无法保证数据包在更远的距离上可靠传输时，这种情况就很普遍。如果您在线路上丢失了ACK，您将倾向于从客户端找到一条RST消息，本质上是要求服务器重新启动。

另一种可能性是某种类型的请求。通常，其中客户端将推送具有len: xx的PSH、ACK信号，其中x是所请求长度的数字。服务器通常会以ACK响应，告诉客户端它已收到请求，服务器正在处理(此ACK通常为空)。然后，它会将一个PSH，ACK - len: xx数据包推送到客户端，让客户端知道它已经接受了它的请求，并且这个数据包中将包含信息。

使用wireshark监视这些信息(非恶意的)通常有助于传播一些关于您的情况的信息，只要确保学习(如果您还不知道)如何过滤您的数据包，否则您将有大量的信息要挖掘(通常)。

我还会尝试向有问题的服务器发送一个数据包，您可以跟踪该数据包，以查看它是否偏离了常规路径。如果您的数据包正在通过循环跳转以到达目的地，那么它极有可能在返回的过程中做同样的事情。如果您愿意，可以尝试使用tcpdump(linux)或tracert(windows)。

希望这能有所帮助！