【Linuxネットワークプログラミングノート】TCP短接続で大量のTIME_が発生WAITが新しいTCP接続を対外的に確立できない原因と解決方法―実践編
9102 ワード
前のノート主にTIMEと紹介したWAITに関する基礎知識については,本稿では,文章のタイトルで提起された問題をどのように解決するかを実践的に説明する.
1.システムのネットワーク構成と現在のTCPステータスを確認し、アプリケーションで発生したネットワークの問題を特定して処理する際に、システムのデフォルトのネットワーク構成を理解する必要があります.x 86_で64プラットフォームLinux kernelversion 2.6.9のマシンを例にとると、ipv 4ネットワークプロトコルのデフォルト構成は、TCPプロトコルスタックに関連する構成項目がtcp_xxxネーミング、これらの構成項目の意味については、ここのドキュメントを参照してください.また、linuxソースツリーで提供されている公式ドキュメント(src/linux/documentation/ip-sysctl.txt)も参照してください.以下に、このマシンで注目すべきいくつかの構成項目とそのデフォルト値を示します.
ここで,前3項ではlocal portの割当て範囲(デフォルトで利用可能なポート数は3 w未満),incomplete connection queueの最大長,握手時のSYNの最大再試行回数の3項構成の意味についてそれぞれ説明し,概念があればよい.次の3つの構成の意味は、位置決め、問題解決の過程で使用されるため、以下に重点的に説明する必要があります. 1) tcp_max_tw_buckets この文書は、Maximal number of time wait sockets held by system simultaneously.If this number is exceeded TIME_WAIT socket is immediately destroyed and warning is printed. This limit exists only to prevent simple DoS attacks, you must not lower the limit artificially, but rather increase it (probably, after increasing installed memory), if network conditions require more than default value (180000). この構成項目は、単純なDoS攻撃を防ぐために使用され、場合によっては適切に大きくすることができますが、決して小さくするべきではありません.そうしないと、結果は自負します.の 2) tcp_tw_recycle Enable fast recycling of sockets in TIME-WAIT status. The defaultvalue is 0 (disabled). It should not be changed without advice/request of technical experts. このコンフィギュレーション・アイテムは、TIME_での迅速な回収に使用できます.WAITステータスのsocketを再割り当てします.デフォルトはオフです.必要に応じて設定をオンにできます.しかし、この構成項目を開くと、注意すべき点がいくつかあります.後述します. 3) tcp_tw_reuse Allow to reuse TIME-WAIT sockets for new connections when it is safe from protocol viewpoint. The default value is 0. It should not be changed without advice/request of technical experts. このオプションをオンにすると、kernelはTIME_に多重化されます.WAIT状態のsocketは,当然多重化の前提は「プロトコルの観点から多重化は安全である」である.「どのような場合、プロトコルが多重化が安全だと考えているのか」という質問について、この文章はlinux kernelソースコードから答えを掘り出し、興味のある学生は見ることができます.
2. ネットの問題の位置決めの構想は前編ノートの初めで説明する線上の実際の問題を参考にして、ある機械が対外的に新しい接続を創立することができないという警報を受け取った時、位置決めの問題を調べる過程は以下の通りである:netstat–at|grep“TIME_WAIT”の統計で発見して、当時問題を出したあの機械の上で全部で10 w+がTIME_にあるWAIT状態のTCP接続、さらに分析したところ、アラームモジュールによるTIME_WAIT接続は2 w+あり.netstat出力の統計結果をファイルに再配置して分析を継続すると、一般的にネイティブのportが大量に占有されていることがわかります.本明細書で前に説明したシステム構成項目から分かるように、tcp_max_tw_bucketsのデフォルト値は18 wで、ip_local_port_rangeの範囲は3 w未満で、大量のTIME_WAIT状態では、TIME_にlocal portがWAIT継続期間中は再割り当てできません.つまり、使用可能なlocal portがありません.これは、新しい接続に失敗する最大の原因になります.ここで注意します:上記の結論は私たちの初歩的な判断にすぎません.具体的な原因は、コードの異常な戻り値(socket apiの戻り値やerrnoなど)とモジュールログに基づいてさらに確認する必要があります.新しい接続を確立できない原因は他のモジュールにブラックリストに入れられた可能性があります.私はこの方面の教訓を持っています.プログラムの中でlibcurl apiで下流モジュールを要求するのに失敗しました.初歩的な位置決めは機械TIME_を発見しました.WAIT状態が多く、curl出力ログを細かく分析していないとTIME_WAITによる問題は、多くの時間を浪費し、半日を振り回して変なことを発見した後、下流モジュールには攻撃防止メカニズムがあり、要求を開始した機器ipは下流モジュールのアクセスホワイトリストに含まれていないことを思い出した.ピーク時に上流モジュールがcurlを通じて下流を要求した回数が頻繁にブラックリストに登録され、新規接続時に下流モジュールのTCP層によって直接RSTパケットで接続を切断された.curl apiが「Recv failure: Connection reset by peer」を返すエラーが発生しました.痛ましい教訓ですね==また、RSTパッケージの送付時期については、『Unix Network Programming Volume 1』第4.3節で説明するが、メモとして、An RST is a type of TCP segment that is sent by TCP when somethingis wrong.Three conditions that generatean RST are: 1) when a SYN arrives for a port that has no listening server; 2) when TCP wants to abort an existing connection; 3) when TCP receives a segment for a connection that does not exist. (TCPv1 [pp.246–250] contains additional information.)
3.解決方法は二つの考え方で機械TIME_を解決できるWAITが多すぎると、新しいTCP接続を外部に確立できないという問題が発生します.3.1システム構成の変更具体的には、前述のtcp_を変更する必要があるmax_tw_buckets、tcp_tw_recycle、tcp_tw_reuseの3つの構成項目.1)tcp_をmax_tw_bucketsが大きくなっていることは、本稿の第1部からわかりますが、デフォルト値は18 w(カーネルによって異なる可能性がありますが、機械の実際の構成を基準にする必要があります)であり、ドキュメントによっては、上限がいくらなのか、ドキュメントには説明がありません.個人的にはTIME_WAITの過剰な問題は緩和の役割を果たし、アクセスの圧力が続くにつれて、この問題は遅かれ早かれ現れ、根本的な解決策がない.2)tcp_を開くtw_recycleオプション:shell端末でコマンドを入力」echo 1>/proc/sys/net/ipv 4/tcp_tw_recycleは、この構成をオンにします.明確にする必要があるのは、実はTIME_WAIT状態のソケットが急速に回収されるかどうかはtcp_tw_recycleとtcp_timestampsの2つの構成項目が共同で決定したのは、tcp_timestampsのデフォルトはオンなので、多くの文章ではtcpの設定についてしか言及していません.tw_recycleは1です.より詳細な説明(kernelソースコードの解析)は、この文章を参照してください.特に、クライアントとサーバの間にNATのようなネットワーク変換装置がある場合、tcp_をオンにすることに注意する必要がある.tw_recycleオプションを使用すると、サーバ側drop(RSTを直接送信)がclientのSYNパッケージから発生する可能性があります.具体的なケースおよび原因分析は、ここ、ここまたはここおよびここの分析を参照することができ、本明細書では後述しない.3)tcp_を開くtw_reuseオプション:echo 1>/proc/sys/net/ipv 4/tcp_tw_reuse.このオプションもtcp_とtimestampsが共に機能し、socket reuseにも条件があります.具体的にはこの文章を参照してください.多くの資料を調べ、NATやFireWallを使ったネットワーク環境でtcp_を開く.tw_recycle後に副作用をもたらす可能性があるのに比べてtcp_は発見されていないようですtw_reuseによるネットワークの問題.3.2アプリケーションの修正具体的には、2つの方法に細分化することができる:1)TCP短接続を長接続に変更する.通常、接続を開始するターゲットも自分で制御可能なサーバである場合、それらの自分のTCP通信は長接続を採用することが好ましく、大量のTCP短接続が確立/解放されるたびに発生する様々なオーバーヘッドを回避する.接続を確立する目的が自分の制御を受けない機器である場合、長接続を使用できるかどうかは、相手機器が長接続方式をサポートしているかどうかを考慮する必要があります.2)getsockopt/setsockoptapiでsocketのSO_を設定するLINGERオプション、SO_についてLINGERオプションの設定方法は、『UNP Volume 1』7.5節で詳しく説明されており、深く理解したい学生はこの教材を調べたり、この文章を参考にしたりすることができ、まだはっきりしている.
4.補足説明が必要な質問TIME_WAITが多すぎると、外部に新しい接続を確立できない可能性がありますが、実際には例外がありますが、一般的な状況があります.SモジュールはWebServerとしてサーバに配備され、ローカルのポートをバインドします.クライアントとSとの間は短い接続であり,インタラクションが完了するたびにSがアクティブに接続を切断する.これにより、クライアントの同時アクセス数が高い場合、Sモジュールが存在する機器がTIME_に大量に存在する可能性があるWAIT状態のTCP接続.ただし、サーバモジュールにポートがバインドされているため、この場合、「TIME_WAITが多すぎて新しい接続が確立できない」という問題は発生しません.すなわち、本明細書で説明する場合、通常は、オペレーティングシステムによってランダムポートが割り当てられるプログラムが実行されるたびにのみ、(ランダムポートが割り当てられるたびに、後でポートが使用できない)発生します.
【参考資料】1.ipsysctl-tutorialのtcpvariables 2. proc_sys_net_ipv4 3. linux+v3.2.8/Documentation/networking/ip-sysctl.txt 4. シリーズ記事—tcp短接続TIME_WAIT問題解決方法大全1-5 5. tcp_を開くtw_recycleによる問題 6. dropping of connections with tcp_tw_recycle = 1 7. tcp_tw_recycleとnatによるsyn_ack問題
================= EOF ==================
1.システムのネットワーク構成と現在のTCPステータスを確認し、アプリケーションで発生したネットワークの問題を特定して処理する際に、システムのデフォルトのネットワーク構成を理解する必要があります.x 86_で64プラットフォームLinux kernelversion 2.6.9のマシンを例にとると、ipv 4ネットワークプロトコルのデフォルト構成は、TCPプロトコルスタックに関連する構成項目がtcp_xxxネーミング、これらの構成項目の意味については、ここのドキュメントを参照してください.また、linuxソースツリーで提供されている公式ドキュメント(src/linux/documentation/ip-sysctl.txt)も参照してください.以下に、このマシンで注目すべきいくつかの構成項目とそのデフォルト値を示します.
cat /proc/sys/net/ipv4/ip_local_port_range 32768 61000
cat /proc/sys/net/ipv4/tcp_max_syn_backlog 1024
cat /proc/sys/net/ipv4/tcp_syn_retries 5
cat /proc/sys/net/ipv4/tcp_max_tw_buckets 180000
cat /proc/sys/net/ipv4/tcp_tw_recycle 0
cat /proc/sys/net/ipv4/tcp_tw_reuse 0
ここで,前3項ではlocal portの割当て範囲(デフォルトで利用可能なポート数は3 w未満),incomplete connection queueの最大長,握手時のSYNの最大再試行回数の3項構成の意味についてそれぞれ説明し,概念があればよい.次の3つの構成の意味は、位置決め、問題解決の過程で使用されるため、以下に重点的に説明する必要があります. 1) tcp_max_tw_buckets この文書は、Maximal number of time wait sockets held by system simultaneously.If this number is exceeded TIME_WAIT socket is immediately destroyed and warning is printed. This limit exists only to prevent simple DoS attacks, you must not lower the limit artificially, but rather increase it (probably, after increasing installed memory), if network conditions require more than default value (180000). この構成項目は、単純なDoS攻撃を防ぐために使用され、場合によっては適切に大きくすることができますが、決して小さくするべきではありません.そうしないと、結果は自負します.の 2) tcp_tw_recycle Enable fast recycling of sockets in TIME-WAIT status. The defaultvalue is 0 (disabled). It should not be changed without advice/request of technical experts. このコンフィギュレーション・アイテムは、TIME_での迅速な回収に使用できます.WAITステータスのsocketを再割り当てします.デフォルトはオフです.必要に応じて設定をオンにできます.しかし、この構成項目を開くと、注意すべき点がいくつかあります.後述します. 3) tcp_tw_reuse Allow to reuse TIME-WAIT sockets for new connections when it is safe from protocol viewpoint. The default value is 0. It should not be changed without advice/request of technical experts. このオプションをオンにすると、kernelはTIME_に多重化されます.WAIT状態のsocketは,当然多重化の前提は「プロトコルの観点から多重化は安全である」である.「どのような場合、プロトコルが多重化が安全だと考えているのか」という質問について、この文章はlinux kernelソースコードから答えを掘り出し、興味のある学生は見ることができます.
2. ネットの問題の位置決めの構想は前編ノートの初めで説明する線上の実際の問題を参考にして、ある機械が対外的に新しい接続を創立することができないという警報を受け取った時、位置決めの問題を調べる過程は以下の通りである:netstat–at|grep“TIME_WAIT”の統計で発見して、当時問題を出したあの機械の上で全部で10 w+がTIME_にあるWAIT状態のTCP接続、さらに分析したところ、アラームモジュールによるTIME_WAIT接続は2 w+あり.netstat出力の統計結果をファイルに再配置して分析を継続すると、一般的にネイティブのportが大量に占有されていることがわかります.本明細書で前に説明したシステム構成項目から分かるように、tcp_max_tw_bucketsのデフォルト値は18 wで、ip_local_port_rangeの範囲は3 w未満で、大量のTIME_WAIT状態では、TIME_にlocal portがWAIT継続期間中は再割り当てできません.つまり、使用可能なlocal portがありません.これは、新しい接続に失敗する最大の原因になります.ここで注意します:上記の結論は私たちの初歩的な判断にすぎません.具体的な原因は、コードの異常な戻り値(socket apiの戻り値やerrnoなど)とモジュールログに基づいてさらに確認する必要があります.新しい接続を確立できない原因は他のモジュールにブラックリストに入れられた可能性があります.私はこの方面の教訓を持っています.プログラムの中でlibcurl apiで下流モジュールを要求するのに失敗しました.初歩的な位置決めは機械TIME_を発見しました.WAIT状態が多く、curl出力ログを細かく分析していないとTIME_WAITによる問題は、多くの時間を浪費し、半日を振り回して変なことを発見した後、下流モジュールには攻撃防止メカニズムがあり、要求を開始した機器ipは下流モジュールのアクセスホワイトリストに含まれていないことを思い出した.ピーク時に上流モジュールがcurlを通じて下流を要求した回数が頻繁にブラックリストに登録され、新規接続時に下流モジュールのTCP層によって直接RSTパケットで接続を切断された.curl apiが「Recv failure: Connection reset by peer」を返すエラーが発生しました.痛ましい教訓ですね==また、RSTパッケージの送付時期については、『Unix Network Programming Volume 1』第4.3節で説明するが、メモとして、An RST is a type of TCP segment that is sent by TCP when somethingis wrong.Three conditions that generatean RST are: 1) when a SYN arrives for a port that has no listening server; 2) when TCP wants to abort an existing connection; 3) when TCP receives a segment for a connection that does not exist. (TCPv1 [pp.246–250] contains additional information.)
3.解決方法は二つの考え方で機械TIME_を解決できるWAITが多すぎると、新しいTCP接続を外部に確立できないという問題が発生します.3.1システム構成の変更具体的には、前述のtcp_を変更する必要があるmax_tw_buckets、tcp_tw_recycle、tcp_tw_reuseの3つの構成項目.1)tcp_をmax_tw_bucketsが大きくなっていることは、本稿の第1部からわかりますが、デフォルト値は18 w(カーネルによって異なる可能性がありますが、機械の実際の構成を基準にする必要があります)であり、ドキュメントによっては、上限がいくらなのか、ドキュメントには説明がありません.個人的にはTIME_WAITの過剰な問題は緩和の役割を果たし、アクセスの圧力が続くにつれて、この問題は遅かれ早かれ現れ、根本的な解決策がない.2)tcp_を開くtw_recycleオプション:shell端末でコマンドを入力」echo 1>/proc/sys/net/ipv 4/tcp_tw_recycleは、この構成をオンにします.明確にする必要があるのは、実はTIME_WAIT状態のソケットが急速に回収されるかどうかはtcp_tw_recycleとtcp_timestampsの2つの構成項目が共同で決定したのは、tcp_timestampsのデフォルトはオンなので、多くの文章ではtcpの設定についてしか言及していません.tw_recycleは1です.より詳細な説明(kernelソースコードの解析)は、この文章を参照してください.特に、クライアントとサーバの間にNATのようなネットワーク変換装置がある場合、tcp_をオンにすることに注意する必要がある.tw_recycleオプションを使用すると、サーバ側drop(RSTを直接送信)がclientのSYNパッケージから発生する可能性があります.具体的なケースおよび原因分析は、ここ、ここまたはここおよびここの分析を参照することができ、本明細書では後述しない.3)tcp_を開くtw_reuseオプション:echo 1>/proc/sys/net/ipv 4/tcp_tw_reuse.このオプションもtcp_とtimestampsが共に機能し、socket reuseにも条件があります.具体的にはこの文章を参照してください.多くの資料を調べ、NATやFireWallを使ったネットワーク環境でtcp_を開く.tw_recycle後に副作用をもたらす可能性があるのに比べてtcp_は発見されていないようですtw_reuseによるネットワークの問題.3.2アプリケーションの修正具体的には、2つの方法に細分化することができる:1)TCP短接続を長接続に変更する.通常、接続を開始するターゲットも自分で制御可能なサーバである場合、それらの自分のTCP通信は長接続を採用することが好ましく、大量のTCP短接続が確立/解放されるたびに発生する様々なオーバーヘッドを回避する.接続を確立する目的が自分の制御を受けない機器である場合、長接続を使用できるかどうかは、相手機器が長接続方式をサポートしているかどうかを考慮する必要があります.2)getsockopt/setsockoptapiでsocketのSO_を設定するLINGERオプション、SO_についてLINGERオプションの設定方法は、『UNP Volume 1』7.5節で詳しく説明されており、深く理解したい学生はこの教材を調べたり、この文章を参考にしたりすることができ、まだはっきりしている.
4.補足説明が必要な質問TIME_WAITが多すぎると、外部に新しい接続を確立できない可能性がありますが、実際には例外がありますが、一般的な状況があります.SモジュールはWebServerとしてサーバに配備され、ローカルのポートをバインドします.クライアントとSとの間は短い接続であり,インタラクションが完了するたびにSがアクティブに接続を切断する.これにより、クライアントの同時アクセス数が高い場合、Sモジュールが存在する機器がTIME_に大量に存在する可能性があるWAIT状態のTCP接続.ただし、サーバモジュールにポートがバインドされているため、この場合、「TIME_WAITが多すぎて新しい接続が確立できない」という問題は発生しません.すなわち、本明細書で説明する場合、通常は、オペレーティングシステムによってランダムポートが割り当てられるプログラムが実行されるたびにのみ、(ランダムポートが割り当てられるたびに、後でポートが使用できない)発生します.
【参考資料】1.ipsysctl-tutorialのtcpvariables 2. proc_sys_net_ipv4 3. linux+v3.2.8/Documentation/networking/ip-sysctl.txt 4. シリーズ記事—tcp短接続TIME_WAIT問題解決方法大全1-5 5. tcp_を開くtw_recycleによる問題 6. dropping of connections with tcp_tw_recycle = 1 7. tcp_tw_recycleとnatによるsyn_ack問題
================= EOF ==================