正常的TCP三向握手包括从客户端到服务器的 SYN，然后是从服务器到客户端的 ACK+SYN，然后是从客户端到服务器的 ACK。但是，TCP 旨在通过不可靠的介质提供可靠的数据传输：独立的 IP 数据包可能会丢失、损坏、复制或无序传输。这就是为什么首先需要 TCP。

收到 SYN 的服务器以 ACK+SYN 响应，然后期望ACK 作为响应。但是，服务器很清楚数据包可能会丢失，包括它自己的 ACK+SYN。所以服务器发送 ACK+SYN，然后等待……如果它没有收到来自客户端的最终 ACK，则服务器假定它的 ACK+SYN 可能已经丢失，所以它再次发出它。然后再次。直到收到来自客户端的 ACK（当客户端不是真正的客户端，而是只发送 SYN 的端口扫描器时不会发生这种情况），或者服务器失去兴趣并放弃。

每个给定的操作系统负责决定何时以及重复多少次 SYN 或 SYN+ACK 或 ACK。在 Linux 系统上，查看被/proc/sys/net/ipv4/调用的特殊文件tcp_syn_retries和tcp_synack_retries：它们包含内核在作为客户端（分别为服务器）时在给定连接尝试时发出 SYN（分别为 SYN+ACK）的次数。在 3.2.0 内核上，我看到两个文件都包含“5”，这意味着受端口扫描的服务器将发出五个SYN+ACK 数据包。如果您只观察到三个，那么您的特定服务器可能是这样配置的（这很简单echo 3 > tcp_synack_retries）。或者服务器仍然使用默认值 5，但您的检测系统不够耐心：连续重传使用指数延迟，因此最后一次重试可能需要大量秒数才能重传。

请注意，为了能够重新传输 SYN+ACK 数据包，服务器必须为该连接尝试分配一点 RAM，以便记住这个特定的原始客户端并重新传输 SYN+ACK。滥用这种分配是SYN洪水攻击的基础。降低最大重传次数将使服务器对此类攻击更加健壮。在极端情况下，SYN cookie是服务器不记住任何事情；因此，当服务器使用 SYN cookie 时，它​​只会对传入的 SYN 响应一个 SYN+ACK。由于您观察到您正在扫描的特定服务器多次发送 SYN+ACK，因此您已经证明该服务器没有使用 SYN cookie，因此可能容易受到 SYN 洪水的攻击。