这是一个创建于 3787 天前的主题,其中的信息可能已经有所发展或是发生改变。
最近研究 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 时确保可以反解
希望对大家有帮助
6 条回复 • 2014-09-14 05:25:47 +08:00
|
|
1
itsjoke 2014-08-13 09:41:02 +08:00
膜拜大神,合个影 一般应用中是开启过timestamp,但后面的参数不太清楚
|
|
|
2
ryd994 2014-08-13 16:33:56 +08:00
本来syn cookie就不是正常用的嘛,防防小规模syn flood而已,正规机房基本都有硬件清洗吧?
|
|
|
3
ptcracker 2014-08-13 22:13:44 +08:00
和是否是攻击无关,流量大了并发高了也会触发 syncookie,此时坑就出现了
|
|
|
4
ptcracker 2014-09-02 08:25:58 +08:00
@ ryd994 机房不会为你做这个事情的,他们没有这个义务,也没有这个能力
|
|
|
6
ryd994 2014-09-14 05:25:47 +08:00
@ ptcracker 流量高而出cookie的话,你应该考虑调backlog,很多地方都说过,cokkie不是给你日常用的。只是为了让你在syn flood中多一点机会幸存而已。
|