SYN Cookie 的抓包痕迹
正常情况下服务端收到 SYN 后会为这条半开连接分配资源，等待对方完成握手；当半开连接堆积（例如遭遇来源伪造的 SYN 洪泛）时，资源会被占满。SYN Cookie 机制让服务端不为半开连接保存状态，而是把连接参数编码进 SYN-ACK 的初始序号里，收到最终 ACK 时再解码还原。抓包看到的表现是握手流程一切正常，而服务端的连接状态表几乎没有增长。
基本信息
| 适用系统 | Linux 内核网络参数 net.ipv4.tcp_syncookies |
|---|---|
| 取值含义 | 0 关闭、1 仅在队列将满时启用、2 无条件启用 |
| 统计数据 | 在 /proc/net/netstat 的 TCP 扩展统计段中，按 syncookie 关键字检索 |
| 抓包线索 | SYN-ACK 的初始序号不再是常规的递增随机值，而是编码值 |
| 代价 | 启用后部分选项可能无法协商，例如窗口缩放，影响大窗口场景 |
| 验证方式 | 结合连接成功率判断效果，不只看能否抓到包 |
典型使用场景
- 攻击期间确认防护是否生效：看统计计数增长，同时确认正常用户仍能完成握手
- 性能回归：开启防护前后对比握手成功率与首字节耗时
- 参数核查：确认生产环境按预期配置了取值，而不是默认状态
- 容量评估：半开连接堆积与防护启用之间的时间关系，判断阈值是否合理
- 协议教学：用抓包直观展示状态不落地的握手机制
查看开关与计数
查看开关与计数
sysctl net.ipv4.tcp_syncookies # 查看当前取值
grep -i syncookie /proc/net/netstat # 统计段中的各类 syncookie 计数
ss -s # 连接总览, 观察半开与各状态连接数量
# 抓包核对: 关注 SYN-ACK 的初始序号是否呈现编码特征
tshark -r a.pcap -Y 'tcp.flags.syn == 1 && tcp.flags.ack == 1' -T fields -e ip.src -e tcp.seq_raw | head -20观察点与判读
| 观察点 | 正常表现 | 异常线索 |
|---|---|---|
| 开关取值 | 按设计配置为 0 或 1 或 2 | 默认值被误以为已开启防护 |
| 发送计数 | 攻击时段明显上升 | 长期为零说明未触发 |
| 失败计数 | 接近零或很低 | 上升说明链路或校验存在问题 |
| 半开连接数 | 启用了防护时不应持续涨满 | 持续堆积说明防护未生效 |
| 握手成功率 | 正常用户仍可完成 | 成功率下降说明防护影响了正常流量 |
该机制通常只在半开队列接近上限时启用，低负载环境下统计计数为零是正常的，不能据此判定防护未开启。
启用后可能丢失部分 TCP 选项，依赖超大窗口的长距离传输场景要评估影响；验证防护效果时应同时观察连接成功率，而不只是看攻击流量是否被挡住。