TCP：SYN请求接收SYN响应代替SYN-ACK

Question

从包捕获文件（PCAP），观察TCP握手

客户端在以下发送SYN请求到服务器， 服务器与SYN分组的代替SYN响应+ ACK， 客户端使用乱序分组消息响应， 服务器终止与RST分组的TCP握手

这种情况是随机发生的，并非总是如此。 TCP连接确实已建立，但有时连接建立失败，出现上述观察模式。

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

Answer 1

如果插槽是TIME_WAIT，新SYN附加内核将检查如果SYN的序列号是大于或小于为此使用的套接字收到的最后一个SEQ。通常https://serverfault.com/questions/297134/server-not-sending-a-syn-ack-packet-in-response-to-a-syn-packet

如果SYN发送，另一个SYN被收到没有ACK通常只是ACK过线（特别是在你的情况下）的损失：

您可以查看这个帖子/答案。无论何时从A（客户端）到B（服务器）的路由很短，并且从服务器到客户端的数据包路径特别长，并且遍历网络可能无法保证在远远更远的距离上可靠的数据包传输时，这种情况非常普遍。如果你在线路上丢失了ACK，你会倾向于从客户端发现一条RST消息，并要求服务器重新启动。

另一种可能性是某种请求。通常在客户端将推送PSH，ACK信号与len：xx，其中x是请求长度的数字。服务器通常会回应一个ACK，通知客户它已收到请求并且服务器正在处理（这个ACK通常是空的），然后它会将PSH，ACK-len：xx数据包推送给客户端，让客户端知道它已经接受了它的请求，并且这个数据包中会有信息。

使用wireshark监控此信息（非恶意）通常会帮助传达您的情况，请务必学习（如果您还不知道）如何过滤数据包，否则您将有很多（通常）挖掘信息。

我也会尝试发送一个数据包到有问题的服务器，您可以追踪它是否被引导离开旁路。如果你的数据包通过循环跳转到目的地，它很可能会在返回时做同样的事情。 如果你希望你可以尝试使用tcpdump（linux）或tracert（windows）。

希望这会有所帮助！