TCP：SYN请求收到SYN响应而不是SYN-ACK

Question

从数据包捕获文件（pcap），在TCP握手期间观察以下内容

客户端向服务器发送SYN请求，服务器以SYN数据包而不是SYN + ACK进行响应，客户端以乱序数据包消息进行响应，服务器以RST数据包终止TCP握手

这是随机发生的，并非总是如此。 确实建立了TCP连接，但有时连接建立因上述观察到的模式而失败。

客户端托管在AWS中，而服务器是CDN网络

Answer 1

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

您可以查看以下帖子/答案： 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）。

希望这可以帮助！