シミュレーションの問題TCP SYNフラッド
TCP SYNフラッドをシミュレートしてWebサーバーを調整しようとしています（AWSにデプロイする予定です）。
「ターゲット」VMをセットアップし、iptablesを無効にして、いくつかのローカル「ソース」マシンからhping（hping -p 80 -i u1000 -c 1000 -S destaddr）を実行します（それらのOUTPUTチェーンでRSTをフィルタリングします）。
ターゲットサーバーのnetstat出力に1000のSYN_RECVレコードが表示されると予想していましたが、最大256（「ソース」マシンごとに256）しか表示されません。 「ターゲット」マシンで制限に達しているようで、どこにあるのかわかりません。 tcp_max_syn_backlogが8096に増加しました。
この制限がどこに設定されているか考えていますか？
OK、それで私はwebhostingtalkで同じ質問をしました、そして直接の答えは得られませんでしたが、それは視野を広げるのに役立ちました:)
基本的に、アプリケーションレベル（Webサーバー）の制限は無視しました。しかし、オランダから来たこの素敵な紳士たちは、深く掘り下げて、彼の非常に関連性のある発見をここに投稿しました：
http://blog.dubbelboer.com/2012/04/09/syn-cookies.html
基本的に、Webサーバー（私はnginxを使用していました）は定数（リッスンバックログ制限）をlisten関数に渡しています。これは次のように定義されています。
https://github.com/git-mirror/nginx/...x_config.h#L97
nGX_LISTEN_BACKLOG511を定義します
そのため、カーネルの制限はまだ機能していません。
Nginx定数がコンパイルされているので、Apacheをすばやく確認しました。幸い、構成可能です。
http://httpd.Apache.org/docs/2.0/mod...#listenbacklog
だから私はそれを8kに設定し、必要なものを手に入れました（まあ、2つのパケットが失われました：
ソース：
hping -S -c 20000 -i u20 -p80ターゲット
目標：
netstat -nta | grep SYN_RECV | wc 8192 49152 729088
最後に、元の256接続の制限は、実際には最初にポート22に要求を送信したためでした（sshdでは明らかにtcp接続バックログが256に設定されています）。