从数据包捕获文件（pcap）中，在TCP握手期间观察以下内容
客户端向服务器发送SYN请求， 服务器使用SYN数据包而不是SYN + ACK进行响应， 客户端响应Out of Order数据包消息， 服务器终止与RST数据包的TCP握手
这是随机发生的，并非总是如此。 TCP连接确实已建立，但有时连接建立失败并出现以上观察到的模式。
客户端托管在AWS中，而服务器是CDN网络
答案 0 :(得分：0)
如果套接字在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消息，特意要求服务器重新启动。
另一种可能性是某种要求。通常客户端将推送PSH，ACK信号与len：xx，其中x是所请求长度的数字。服务器通常会回应一个ACK，告诉客户端它收到了它的请求并且服务器正在处理（这个ACK通常是空的。）然后它会将PSH，ACK-len：xx数据包推送到客户端以让客户端知道它接受了它的请求，这个数据包将包含信息。
使用wireshark监控此信息（非恶意）通常会帮助您了解情况，只需确保（如果您还不知道）如何过滤您的数据包，否则您将有很多要通过的信息（通常）。
我还会尝试将数据包发送到有问题的服务器，您可以跟踪该数据包以查看它是否被引导离开了常规路径。如果你的数据包跳过循环来建立它的目的地，它很可能在回来的路上做同样的事情。 如果您愿意，可以尝试使用tcpdump（linux）或tracert（windows）。
希望这有帮助！