最近、SYNフラッディングのために非常に遅い応答をするApacheサーバーがありました。これの回避策は、tcp_syncookies（net.ipv4.tcp_syncookies=1 in /etc/sysctl.conf）を有効にすることでした。
あなたがより多くの背景が必要な場合、私はこれに関する質問をここに投稿しました。
syncookiesを有効にした後、約60秒ごとに/ var / log / messagesに次のメッセージが表示されるようになりました。
[84440.731929] possible SYN flooding on port 80. Sending cookies.
Vinko Vrsalovicは、これがsynバックログがいっぱいになっていることを通知してくれたので、tcp_max_syn_backlogを4096に上げましたsysctl -w net.ipv4.tcp_synack_retries=3。これを行った後、頻度は低下しているようで、メッセージの間隔は約60〜180秒の間で変化しました。
次に、を発行しましたがsysctl -w net.ipv4.tcp_max_syn_backlog=65536、まだログにメッセージが記録されています。
このすべてを通して、（実行watch --interval=5 'netstat -tuna |grep "SYN_RECV"|wc -l'することによって）SYN_RECV状態の接続の数を監視してきましたが、それが約240を超えることはなく、バックログのサイズよりはるかに低くなりません。それでも、約512個のRed Hatサーバーがあります（このサーバーの制限はデフォルトの1024です）。
バックログのサイズを制限する他のtcp設定はありますか、または間違ったツリーを起動していますか？SYN_RECV接続の数はnetstat -tuna、バックログのサイズに相関する必要がありますか？
更新
ここで合法的な接続を処理していると言えば、netstat -tuna|wc -l5000前後です。今日これを調査していて、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 -psyncookiesを実行して無効にしましたsysctl -w net.ipv4.tcp_syncookies=0。
これを行った後、SYN_RECV状態の接続の数はまだ約220〜250のままですが、接続は再び遅延し始めていました。これらの遅延に気づいたら、syncookiesを再度有効にし、遅延を停止しました。
私が見ていたことはまだ初期状態からの改善だったと思いますが、syncookiesを有効にするよりもはるかに悪いリクエストがまだありました。したがって、負荷に対処するためにさらにサーバーをオンラインにできるようになるまで、それらを有効にしておく必要があります。それでも、サーバーのバッファーがいっぱいになったときにのみ（見かけ上）送信されるため、再度無効にする正当な理由がわかりません。
ただし、SYNバックログは、SYN_RECV状態の接続が〜250だけでいっぱいになっているようには見えません！SYNフラッディングメッセージが赤いニシンであり、syn_backlog以外がいっぱいになっている可能性はありますか？
まだ試していない他のチューニングオプションがあれば、喜んで試してみますが、syn_backlog設定が何らかの理由で適切に適用されていないのではないかと思い始めています。