如果你想要更多背景,我发布了一个关于这here的问题.
启用syncookies后,我们开始大约每60秒在/ var / log / messages中看到以下消息：
[84440.731929]可能在端口80上发生SYN泛洪.发送cookie.
Vinko Vrsalovic告诉我,这意味着syn backlog已经满了,所以我将tcp_max_syn_backlog提升到4096.在某些时候,我还通过发出sysctl -w net.ipv4.tcp_synack_retries = 3将tcp_synack_retries降低到3(从默认值5下调). .在这样做之后,频率似乎下降,消息的间隔在大约60到180秒之间变化.
接下来我发出了sysctl -w net.ipv4.tcp_max_syn_backlog = 65536,但仍然在日志中收到消息.
在这一切中,我一直在观察SYN_RECV状态下的连接数(通过运行watch –interval = 5’netstat -tuna | grep“SYN_RECV”| wc -l’),它永远不会超过240左右,很多远远低于积压的大小.然而,我有一个徘徊在512左右的Red Hat服务器(此服务器的限制是1024的默认值).
是否有任何其他tcp设置会限制积压的大小,还是我咆哮错误的树？ netstat -tuna中SYN_RECV连接的数量是否与积压的大小相关？
更新
最好的我可以告诉我我在这里处理合法连接,netstat -tuna | wc -l徘徊在5000左右.我今天一直在研究这个问题,并从last.fm员工那里找到了this post,这对我来说非常有用.
我还发现启用syncookies时tcp_max_syn_backlog没有效果(根据this link)
因此,作为下一步,我在sysctl.conf中设置以下内容：
net.ipv4.tcp_syn_retries = 3
# default=5
net.ipv4.tcp_synack_retries = 3
# default=5
net.ipv4.tcp_max_syn_backlog = 65536
# default=1024
net.core.wmem_max = 8388608
# default=124928
net.core.rmem_max = 8388608
# default=131071
net.core.somaxconn = 512
# default = 128
net.core.optmem_max = 81920
# default = 20480
然后我设置我的响应时间测试,通过sysctl -w net.ipv4.tcp_syncookies = 0运行sysctl -p和禁用syncookies.
执行此操作后,SYN_RECV状态下的连接数仍然保持在220-250左右,但连接开始再次延迟.一旦我注意到这些延迟,我重新启用了syncookies并且延迟停止了.
我相信我所看到的仍然是从最初的状态改善,但是有些请求仍然被延迟,这比启用syncookies要糟糕得多.所以看起来我已经坚持使用它们,直到我们可以在线获得更多服务器来应对负载.即便如此,我也不确定我是否有理由再次禁用它们,因为它们仅在服务器的缓冲区满时发送(显然).
但在SYN_RECV状态下,只有~250个连接似乎没有完整的syn积压！ SYN flooding消息是否可能是一个红色的鲱鱼,而且它不是正在填充的syn_backlog？
如果有人有任何其他调整选项,我还没有尝试过,我会非常乐意尝试它们,但我开始怀疑syn_backlog设置是否由于某种原因没有正确应用.
解决方法
最初,我很惊讶您在SYN_RECV状态下看到启用了SYN Cookie的任何连接. SYN cookies的优点在于你可以无状态地参与TCP 3次握手作为使用加密技术的服务器,所以我希望服务器根本不代表半开连接,因为这将是非常相同的状态.不被保留.
实际上,快速查看源代码(tcp_ipv4.c)会显示有关内核如何实现SYN cookie的有趣信息.本质上,尽管打开它们,内核的行为与通常的待处理连接队列已满的情况一样.这解释了您在SYN_RECV状态下的现有连接列表.
仅当挂起的连接队列已满,并且收到另一个SYN数据包(连接尝试),并且自上次警告消息起已超过一分钟,内核是否发送了您看到的警告消息(“发送cookie”) ).即使没有警告信息,也会发送SYN cookie;警告信息只是为了让您了解问题并未消失.
换句话说,如果您关闭SYN Cookie,该消息将消失.如果您不再被SYN淹没,那只会为您解决问题.
要解决你做过的其他一些事情：
> net.ipv4.tcp_synack_retries：
>增加此值不会对那些被欺骗的传入连接产生任何积极影响,也不会对任何接收SYN cookie而不是服务器端状态的连接产生任何积极影响(也不会对它们进行重试).
>对于传入的欺骗性连接,增加此值会增加发送到虚假地址的数据包数量,并可能增加该欺骗性地址留在连接表中的时间(这可能会产生严重的负面影响).
>在正常负载/传入连接数量下,此值越高,您就越有可能通过丢弃数据包的链路快速/成功完成连接.增加收益的回报递减.
> net.ipv4.tcp_syn_retries：更改此项不会对入站连接产生任何影响(它只会影响出站连接)
你提到的其他变量我还没有研究过,但我怀疑你的问题的答案就在这里.
如果您没有被SYN泛洪并且计算机响应非HTTP连接(例如SSH),我认为可能存在网络问题,您应该让网络工程师帮助您查看它.如果机器通常没有响应,即使您没有被SYN泛洪,如果它影响TCP连接的创建(非常低级别和资源非密集型),这听起来像是一个严重的负载问题
