尽管SYN_RECV连接数较少，但日志中仍存在“可能的SYN泛洪”
最近，我们有一个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 …