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