因此，假设有人通过欺骗 IP 向服务器发送大量 SYN 请求，在收到来自客户端的 ack 之前，服务器是否在其内存中保留了连接的窗口大小？如果不是，那么如果客户端发送大量SYN请求而没有发送ACK，那么这里浪费的资源是什么？当从客户端获得 ACK 时，服务器保留哪些资源？
我还看到，当路由器被 TCP SYN 请求（例如端口 22/SSH）淹没时，CPU 使用率非常高，但我不明白为什么，对 SYN 请求数据包的响应不是很直接向前？考虑到 SYN 请求数据包很常见，路由器和服务器不是以一种它们可以以低 CPU 使用率非常快地响应 SYN 请求数据包的方式构建的吗？
每当服务器收到 SYN 请求时，它就会打开通信通道，并根据使用该端口的操作系统和应用程序，分配额外的资源。通常在服务器上设置 SYN 超时，之后资源将被释放。要使拒绝服务起作用，发送方必须在该超时期限内发送大量 SYN 数据包以压倒服务器。
同样适用于路由器，路由器必须为 SSH 会话保留 Socket，直到超时。因此，虽然它会用 ACK+SYN 回复原始 SYN 数据包，但期望它会收到它自己的 SYN 的 ACK 以进行相同的握手以完成通信通道。同样，如果发送方发送大量 SYN 数据包，它将使路由器不堪重负。
主机可以自由地进行其内部资源管理。
主机在发送 SYN-ACK 之前分配资源（不仅仅是 TCB）似乎是合理的，否则它怎么知道它能够接受传入的连接？尽可能延迟延迟似乎也是合理的，以最小化“无意义”传入请求的影响。
您的问题最好被视为有关不同制造商软件的实证问题。我的建议是在任何你可以登上板凳的设备上尝试一下。尝试将 SSH 与 telnet 与路由器进行比较——它很可能是使用 CPU 的加密初始化。还要查看内存分配，而不仅仅是 CPU 使用率。
最后我从 RFC 793 第 3.4 节注意到：
这些示例没有显示使用数据承载段的连接同步，这是完全合法的，只要接收 TCP 在明确数据有效之前不会将数据传送给用户（即，数据必须缓冲在接收者直到连接达到 ESTABLISHED 状态）