linux – 尽管SYN_RECV连接数很少,但在日志中“可能发生SYN泛滥”

概述最近我们有一个apache服务器,由于SYN泛滥而响应非常慢.解决方法是启用tcp_syncookies(/etc/sysctl.conf中的net.ipv4.tcp_syncookies = 1). 如果你想要更多背景,我发布了一个关于这here的问题. 启用syncookies后,我们开始大约每60秒在/ var / log / messages中看到以下消息： [84440.731929]可 最近我们有一个apache服务器,由于SYN泛滥而响应非常慢.解决方法是启用tcp_syncookies(/etc/sysctl.conf中的net.ipv4.tcp_syncookies = 1).

如果你想要更多背景,我发布了一个关于这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=5net.ipv4.tcp_synack_retrIEs = 3        # default=5net.ipv4.tcp_max_syn_backlog = 65536        # default=1024net.core.wmem_max = 8388608        # default=124928net.core.rmem_max = 8388608        # default=131071net.core.somaxconn = 512        # default = 128net.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连接的创建(非常低级别和资源非密集型),这听起来像是一个严重的负载问题

总结

以上是内存溢出为你收集整理的linux – 尽管SYN_RECV连接数很少,但在日志中“可能发生SYN泛滥”全部内容，希望文章能够帮你解决linux – 尽管SYN_RECV连接数很少,但在日志中“可能发生SYN泛滥”所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。