amazon-web-services - TCP:SYN 请求收到 SYN 响应而不是 SYN-ACK

Question

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

Client向Server发送SYN请求，服务器响应SYN包而不是SYN+ACK，客户端响应 Out of Order 数据包消息，服务器用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)。

希望这对您有所帮助!