最近、TCP / IPスタックのいくつかのパラメーターを最適化する問題に遭遇しました。 このトピックは私にとって興味深いものでした。多くの人がハックされているように思えるかもしれませんが、誰かがカスタマイズの新しい興味深い瞬間を紹介します。 それでは始めましょう...
まず、 tcp_conn_req_max_qやtcp_conn_req_max_q0などの2つのパラメーターを検討します。これらのパラメーターがなぜ必要なのか、これらのパラメーターのどの値が最適なのかを考えます。
簡単に言えば、これらのパラメーターは、サーバーによって処理されるIPアドレスとポートに対する要求の最大数に責任を負います。
tcp_conn_req_max_qは、ポートによって処理される着信接続の最大数です。
tcp_conn_req_max_q0は、ポートに存在できる「ハーフオープン」TCPセッションの最大数です。
Solarisのこれらのパラメーターを使用すると、管理者は、SYNパケットが確実にブロックされ、DOS環境でのサービス拒否攻撃を防ぐことができます。
Solarisのtcp_conn_req_max_qパラメーターのデフォルト値は128のみであり、 tcp_conn_req_max_q0パラメーター1024の場合、これらのパラメーターは原則として少数のクライアントにサービスを提供するサーバーには十分ですが、デフォルト値よりも多くの呼び出しがサーバーに期待される場合、これはシステムの神経を著しく損ないます管理者に。 最初はこのように見えます。
root@T1000-spare # ndd /dev/tcp tcp_conn_req_max_q 128 root@T1000-spare # ndd /dev/tcp tcp_conn_req_max_q0 1024
これらのパラメータを変更するときが来たとき、実際には、ドロップされたパケットの数がスケールから外れている場合、時間が来たと判断するのは非常に簡単です。 この数量の決定方法は、通常の選択を使用します。
root@T1000-spare # netstat -s | fgrep -i listendrop tcpListenDrop = 0 tcpListenDropQ0 = 0 sctpListenDrop = 0 sctpInClosed = 0
私の場合、テストサーバーは値の変化を表示できないため、ゼロがあります。 ただし、スキームは次のとおりです。tcpListenDropの値がゼロに等しくない場合はtcp_conn_req_max_qを増やし、tcpListenDropQ0がゼロと異なる場合はそれぞれtcp_conn_req_max_q0パラメーターの値を増やします。
ただし、tcp_conn_req_max_qがすぐに大幅に増加すると、SYNパケットを使用するDOSに対して当然脆弱になります。 そのためには、2番目のパラメーターが必要です。これは、このような場合を防ぐために理想的に作成されます。 2番目のパラメーターは、SYNパケットを受信した後にサーバーのキューに入れられるセッションを担当します。 残念なことに、アプリケーションが遅い場合、クライアントはキューに入れられ、サーバーに接続せずにそこにとどまるため、無次元に増やすことはできません。
これらの値の変更は、nddコマンドを使用して簡単に実行できます。例として、負荷の高いサーバーの1つの値を指定します。これらのパラメーターは作業で使用できます。
# ndd -set /dev/tcp tcp_conn_req_max_q 16384 <==== # ndd -set /dev/tcp tcp_conn_req_max_q0 16384 <==== # ndd -set /dev/tcp tcp_max_buf 4194304 # ndd -set /dev/tcp tcp_cwnd_max 2097152 # ndd -set /dev/tcp tcp_recv_hiwat 400000 # ndd -set /dev/tcp tcp_xmit_hiwat 400000
結論として、これらのパラメーターについては、これらのパラメーターの変更に十分な細心の注意を払い、不必要に変更しないようにする必要があると言いたいと思います。
PS他のパラメーターに興味がある人は、次の記事で説明することができます。 ご清聴ありがとうございました。