最近，我们有一个apache服务器，由于SYN泛洪，响应速度非常慢。解决方法是启用tcp_syncookies（net.ipv4.tcp_syncookies=1 in /etc/sysctl.conf）。
如果您需要更多背景知识，我在这里发布了一个与此有关的问题。
启用syncookie之后，我们大约每60秒开始在/ var / log / messages中看到以下消息：
[84440.731929] possible SYN flooding on port 80. Sending cookies.
Vinko Vrsalovic告诉我，这意味着syn待办事项已满，因此我将tcp_max_syn_backlog提高到4096。在某些时候，我还通过发出来将tcp_synack_retries降低到3（从默认值5降低）sysctl -w net.ipv4.tcp_synack_retries=3。之后，频率似乎下降了，消息间隔大约在60到180秒之间变化。
接下来，我发出sysctl -w net.ipv4.tcp_max_syn_backlog=65536，但仍在日志中获取消息。
在所有这些过程中，我一直在观察SYN_RECV状态下的连接数（通过运行watch --interval=5 'netstat -tuna |grep "SYN_RECV"|wc -l'），它从不超过约240个，远低于积压的大小。但是我有一台Red Hat服务器，它徘徊在512左右（此服务器的限制是默认值1024）。
是否还有其他tcp设置会限制待办事项的大小，或者我吠叫了错误的树？SYN_RECV连接的数量是否应该netstat -tuna与待办事项的大小相关？
更新资料
尽我所能告诉我，我在这里处理合法连接，netstat -tuna|wc -l徘徊在5000左右。我今天一直在研究此问题，并从last.fm员工那里找到了这篇帖子，这非常有用。
我还发现启用syncookies时tcp_max_syn_backlog不起作用（按照此链接）
因此，下一步，我在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 -p并通过运行和禁用了syncookie sysctl -w net.ipv4.tcp_syncookies=0。
完成此操作后，处于SYN_RECV状态的连接数仍保持在220-250附近，但是连接又开始延迟。一旦发现这些延迟，便重新启用了syncookies，并且延迟停止了。
我相信我所看到的仍然比初始状态有所改善，但是一些请求仍然被延迟，这比启用syncookies更糟糕。因此，在我们让更多的服务器联机以应对负载之前，我似乎一直启用它们。即使这样，我也不确定是否有再次禁用它们的正当理由，因为它们仅在服务器缓冲区已满时才发送（显然）。
但是，在SYN_RECV状态下，仅约250个连接就无法满足syn积压！SYN泛洪消息是否有可能是一条红色鲱鱼，而不是填充了syn_backlog的东西？
如果有人还有其他调优选项，但我还没有尝试过，我会很乐意尝试一下，但是我开始怀疑syn_backlog设置是否由于某些原因未正确应用。