摘要

  • SYN Cookie 把可验证、可重建的临时 TCP 状态编码进服务器的 SYN-ACK 初始序列号，使服务器可以等到第三个 ACK 返回后再建立显式 SYN-RECEIVED 记录。
  • 返回的 Cookie 证明有人近期接触过发往特定四元组的回程报文；它不是人的身份认证，也不能证明连接善意或应用有能力接待。
  • 32 位序列号是一项严格的信息预算。触发门槛、可恢复选项、丢包行为以及后续资源瓶颈，都必须以实际运行的内核、前端和监听器为准。

被动打开 TCP 连接时，服务器先承担一笔信用。客户端发来 SYN，服务器进入 SYN-RECEIVED，生成 SYN-ACK，并在半开队列中保存识别这次尝试所需的状态。直到最后一个 ACK 回来，远端才表明它至少能够接收服务器刚才发出的回答。可服务器的内存承诺已经发生。

SYN flood 利用的正是这段时间差。攻击者制造大量从不完成的开场，让服务器为不存在或不响应的来客保留队列项，等待重传与超时。半开资源一旦用尽，正常客户端也可能无法进入，即使链路、应用与既有连接尚未同时耗尽。RFC 4987 特别把这类问题限定为连接建立状态的枯竭；不能据此宣称整个系统的所有资源都已饱和。

不同缓解方式把损失分给不同的人。扩大 backlog 延长缓冲，但也增加暴露的内存。缩短 SYN-RECEIVED 超时更快回收条目，却可能误伤长时延或丢包路径。回收最旧条目让年龄代替真实性决定谁被抛弃。SYN cache 保存更小的请求记录。前置代理则在另一台设备上完成握手，把语义与风险一起移动。

SYN Cookie 做得更彻底：第一次 SYN 到来后，不保存显式请求记录。服务器选择一个特殊的初始序列号，在其中压入未完成交换的必要信息，并加入依赖本地秘密的校验。历史方案通常把两端地址与端口、客户端初始序列号、缓慢变化的时间计数、一个 MSS 档位以及服务器秘密组合起来。RFC 4987 介绍的是一组方法与权衡，并未规定所有实现都使用同一种算法。

客户端无需理解编码。它照常收到 SYN-ACK，再把服务器序列号加一后放进第三个 ACK。服务器收到后还原刚才的值，检查仍可接受的时间窗口，并以眼前四元组重新计算秘密函数。结果吻合，便重建足够状态并进入 ESTABLISHED；结果不合，便直接丢弃，无需查询一条从未存在的半开记录。

这更像一张由来客代为携带的收据，而不是护照。服务器开出一张自己能验证的收据，却不在柜台留下副本。收据归来说明某个参与者近期收到、观察到或以其他方式得知了发往该地址与端口组合的 SYN-ACK。这种证据足以支持一次本地内存准入，却不能回答对方是谁、代表哪家公司、接下来做什么或服务成本多高。

秘密校验提高了离路径猜测的难度，但不会把 TCP 变成身份协议。位于路径上的观察者可以看到交换；使用真实地址的僵尸网络可以返回有效 Cookie；正常客户端也可能在建立连接后压垮 TLS、工作进程、数据库或业务配额。SYN Cookie 推迟了一个承诺，而不是消灭了所有承诺。

无状态并非没有代价，代价首先体现在信息空间。初始序列号只有 32 位，而且仍要履行 TCP 序列号的本职。普通半开记录可以保存首个 SYN 携带的各项选项；基础 Cookie 却要同时容纳新鲜度、完整性校验与必要参数。早期常见方案只给 MSS 留下一个小型档位索引。任何既未编码、又不能从完成 ACK 推断的信息，在重建时都已经丢失。

Window Scale 让这种损失变得具体。RFC 7323 规定该选项只在带 SYN 的报文中交换，并在连接打开时确定双向缩放因子。服务器若忘记了客户端的报价，Cookie 扩展又无法找回，就不能等第三个报文之后再补谈。RFC 4987 因而记录了基础 SYN Cookie 在 Window Scale、SACK 等能力上的历史限制，同时也描述了 FreeBSD 利用对端回显的 Timestamp 位恢复更多状态的办法。

这里不能下两个方便却错误的结论。并非每一种实现都会丢掉同样的选项；较新的或平台特定的编码可以恢复更多信息。也不能因为某一实现找到额外空间，就推定所有生产路径都完整保留选项。真正的合同由内核版本、NIC offload、负载均衡器、代理配置和最终接收流量的监听器共同构成。

第三个 ACK 丢失时，服务端先发言的协议会暴露另一处差异。RFC 4987 以 SMTP 为例：客户端发出完成握手的 ACK 后，可能认为连接已经建立，并等待服务器问候。如果这个 ACK 丢失，无状态服务器手里没有可供重传的半开记录，也尚未通知应用。后续能否恢复，取决于具体重传与实现。节约内存改变了哪一方最先看见失败。

因此，混合运行比永久口号更可信。正常负载下，常规队列或 SYN cache 保存较完整的协商与重传状态；只有当监听器的本地门槛溢出时，才退到 Cookie，而不是驱逐已有请求。这样一来，无状态模式是一项具有进入条件、退出条件和可见副作用的应急分配策略，不是连接建立的永久替代品。

Linux 当前文档把界线写得很清楚。tcp_syncookies 被描述为套接字 SYN backlog 溢出时的后备机制，并明确警告不得用它让过载服务器硬扛合法连接率。tcp_max_syn_backlog 则单独描述每个监听器愿意记住多少个 SYN_RECV 请求。如果正常需求长期触发后备模式，运营者应调查容量、排队与服务处理能力，而不是把资源不足包装成安全功能。

即使 Cookie 完美，主机仍要接收并解析 SYN，计算并发送 SYN-ACK，再验证返回 ACK。链路、软中断、队列与 CPU 依旧可以饱和。握手成功后，accept queue、已建立套接字、加密握手、工作池与下游依赖也都可能耗尽。防护把瓶颈移到下一层并非失败；看不见或无人负责下一层才是失败。

源地址验证解决的是互补问题。BCP 38 与 BCP 84 让网络更难输出伪造来源的流量，从而减少服务器向虚假地址发送无用回复。但它无法阻止持有真实地址的攻击主机完成握手，也不能吸收合法流量高峰。上游决定哪些源声明可以离开，本地主机决定何时投入状态，两种权限彼此不能替代。

监测还必须补回被无状态设计从表格里拿掉的证据。RFC 4898 区分胚胎连接、完整资源分配和应用接受等事件，并指出 SYN Cookie 系统没有一个显式的编码态 SYN-RCVD 记录。因此，“半开连接为零”既可能代表平静，也可能代表服务器已停止记忆。

可靠视图要同时记录 SYN 到达率、SYN-ACK 与重传、backlog 占用和溢出、Cookie 生成、有效/无效/过期返回、握手完成、accept queue 压力和应用接受率。还要对普通连接与 Cookie 连接抽样比较 MSS、Window Scale、SACK、Timestamp、ECN 与 Fast Open。若模式切换没有计数器，消失的状态也就带走了告警。

TCP Fast Open 把应用数据放进 SYN，并使用另一套 Cookie 语义与重放假设。RFC 7413 并不授权运营者假设传统 SYN Cookie 后备模式会保留这些数据。生产前端、代理、内核和卸载路径需要一起验证；两个机制都叫 Cookie，并不意味着它们拥有同一份协议合同。

SCTP 则展示了协议从一开始为延迟分配预留容器时会怎样。RFC 9260 的四步建立过程携带可变长度 State Cookie，其中能够包含建立关联所需信息，并受 MAC、时间戳与寿命约束。它既不是 TCP 的格式，也不是 TCP SYN Cookie 的算法。它只说明：若无状态准入属于协议设计，显式容器比把不断增长的协商压进旧序列号更容易保持语义。

共同规范可以定义握手不变量，记录已知取舍，却不知道某个监听器的内存、时延分布、必需选项与应用成本。恒路的“最小初始规范”原则因此把触发门槛与可接受损失留给运行系统的人。“运行代码优先”随后提出验证标准：配置文件写了什么只是意图，真实连接保住了哪些状态、选项和用户，才是现实。

来源