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

最近我们有一个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=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设置是否由于某种原因没有正确应用.