SYN Cookie与连接队列优化：SYN Flood防御配置差异

面对SYN Flood，很多管理员会先开启SYN Cookie，再调大监听队列。但这两项措施解决的并不是同一个问题：前者重点保护内核免于保存过多半连接状态，后者重点提高正常连接的排队和处理能力。理解这一区别，才能制定有效的SYN Flood防御配置，而不是单纯把参数调到很大。

一、SYN Cookie和连接队列分别保护什么

TCP建立连接通常经历客户端发送SYN、服务端回复SYN-ACK、客户端返回ACK三个阶段。服务端收到第一个SYN后，往往会在半连接队列中保留状态。如果攻击者持续发送SYN却不完成握手，队列、内存和处理资源就可能被消耗。

SYN Cookie的做法是把部分连接信息编码到服务端返回的序列号中，暂时不为每个SYN建立完整状态。只有对端返回有效ACK后，内核才恢复并创建连接。它对伪造源地址、无法完成握手的流量尤其有效，是SYN Flood防御配置中的基础保护项。

不过，SYN Cookie不是带宽清洗，也不能阻止攻击报文抵达网卡。启用后，部分TCP选项的协商行为还取决于操作系统实现；如果业务依赖时间戳、窗口扩大等能力，应在变更后检查实际连接参数。

连接队列优化通常包括半连接队列、已完成连接队列、监听套接字上限和应用程序accept处理速度。它能缓冲突发连接，降低短时流量峰值造成的丢包，但不会消除攻击者发送的大量SYN。

因此，两者的差异可以概括为：SYN Cookie偏向“少保存状态”，队列优化偏向“多容纳连接”。前者适合应对握手不完整的资源消耗，后者适合应对真实用户集中上线、发布后连接瞬时增加或后端处理稍慢的场景。

如果只调大队列而不启用SYN Cookie，攻击流量可能只是把消耗从小队列推迟到更大的内存和CPU压力。反过来，只启用Cookie而忽略应用处理能力，也可能让真实客户端在握手完成后仍然排队。

先记录基线。在Linux主机上使用“ss -s”查看TCP总体状态，使用“ss -lnt”确认监听端口和队列字段；同时记录正常时的半连接数量、已建立连接数、CPU使用率和网卡吞吐。
启用Cookie保护。确认“net.ipv4.tcp_syncookies”处于启用状态，可临时执行“sysctl -w net.ipv4.tcp_syncookies=1”。正式环境应写入系统持久化配置，并在重启后复核。
按实测情况调整队列。可从“net.ipv4.tcp_max_syn_backlog=4096”或“8192”这类范围开始观察；监听上限“net.core.somaxconn”也要与应用设置保持协调。具体值受内存、监听端口数量和并发模式影响，不宜直接套用。
检查应用接收能力。确认工作进程是否及时调用accept，观察是否存在单进程阻塞、连接池耗尽或后端数据库响应变慢。队列很大但应用不取走连接，最终仍会溢出。
增加入口策略。在边界设备或云防火墙上按端口、协议和来源信誉实施限速；当流量已经压满公网链路时，应切换到上游清洗或具备SYN代理能力的设备。
验证回滚。逐项记录修改前后的参数、握手成功率、P95连接建立时间和服务端错误数。若出现合法客户端连接异常，先恢复最近一次变更，再分析队列与应用日志。

有效的SYN Flood防御配置不应只看Cookie开关。可以同时观察三个比例：收到的SYN数量、完成握手的连接数量，以及应用最终接受的连接数量。若SYN暴涨但完成握手很少，Cookie和入口过滤应当发挥作用；若握手成功但应用接受速度下降，重点应转向队列、CPU和工作进程。

还要区分攻击和业务高峰。真实用户通常会继续重传或完成握手，并产生后续协议请求；伪造源地址的SYN Flood则可能只留下大量未完成握手记录。移动网络、企业代理和IPv6部署会改变来源特征，因此不能仅凭来源地址数量下结论。

需要视业务而定。Cookie保护半连接资源，队列优化服务于正常连接，两者可以同时存在，但应根据监控数据逐步调整。

不是。过大的队列会增加等待时间和内存压力，无法解决带宽、CPU或应用处理能力不足的问题。

不能。它主要降低主机保存半连接状态的压力；当攻击量超过链路、网卡或防火墙处理能力时，仍需要上游限速、清洗或SYN代理。

当握手成功率正常、监听队列却持续增长，或者CPU、数据库连接池和工作进程出现瓶颈时，应先检查应用接收和后端处理链路。合理的SYN Flood防御配置应让内核保护、队列容量和应用吞吐相互匹配。