[分享] syncookie 中的坑

最近研究 TCP Performance，发现 Linux 中的 syncookie 存在一些很重要的坑

首先说一下它的机制
1. 如果 syncookie 没有打开，半连接队列满的时候直接丢包
2. 如果打开了 syncookie，则 syncookie 机制代替 TCP stack 回应 SYN/ACK 包，在关闭了 timestamp 选项的情况下 syncookie 会阉割掉 TCP Options
3. 不仅如此，SYN/ACK 代应答的机制取消了 timeout 后的 retransmission，也就是 SYN/ACK 发丢之后不会主动重传

这里的坑有几个地方

1. SACK 选项被阉割了
根据 RFC 1323 的定义，在没有 SACK 前，发包从 1 ~ n 的话，如果中间 m 丢包，则需要从 m ~ n 重传
而有了 SACK 后，可以只补传 m，节省带宽，提升 TCP 回复速度
不过很可惜，启用 syncookie 的话有可能代应答的时候没有 SACK 选项

2. WS 选项被阉割了
同样根据 RFC 1323 的定义，滑动窗口扩展功能 WS 如果被取消，最大 window size 则只有 16bit 大小，也就是 65535
而根据 TCP 的传输特性，throughput = WND/RTT
当 RTT 一定的时候，比如 100ms，则最大传输速率 = 64KB / 0.1 = 640KB/s
也就是说，即使你的带宽再大，链路质量再好（不丢包），在没有 WS 时也只能有 640KB/s 的速度

3. timestamp
timestamp 是一个 TCP 选项，可以协助 TCP 做 RTT 评估，但是在 NAT 环境下与 tw_recycle 和 tw_reuse 一起使用会导致传输异常而停滞
因此，很多人都不使用 TS 选项（也确实意义不是很大）
而 syncookie 在高版本内核里已经弥补了 #1 和 #2 的不足，但问题是它需要借助 TS 的字段进行 Option 传输，当系统配置了 TS = 0 时，SACK 和 WS 还是被阉割掉的

所以，推荐大家几个做法
1. 一定要打开 syncookie 功能
2. 要么打开 timestamp 选项，要么加大 backlog 和 somaxconn，要么自己修改内核中的 syncookie 算法，在 cookie 中加入选项数据，并在解析 ACK 时确保可以反解

希望对大家有帮助