73

TCP経由でメッセージを受け入れ、内部メッセージングの一部にTCPを使用するアプリケーションを調整しようとしています。負荷テスト中に、システムに対してより多くの同時要求が行われると、応答時間が大幅に低下する（そして完全に停止する）ことに気づきました。この間、多くのTCP接続のTIME_WAITステータスが表示され、誰かがTIME_WAIT環境変数をデフォルトの60秒から30秒に下げることを提案しました。

私が理解していることから、このTIME_WAIT設定は基本的に、接続が閉じられた後にTCPリソースがシステムで再び利用可能になる時間を設定します。

私は「ネットワークの男」ではなく、これらのことについてほとんど知りません。そのリンクされた投稿にあるものがたくさん必要ですが、少し「唖然としました」。

  • TIME_WAIT値を0に設定できない理由は理解できたと思いますが、安全に5に設定できますか？10はどうですか？この値の「安全な」設定を決定するものは何ですか？
  • この値のデフォルトが60であるのはなぜですか？私よりずっと賢い人には、これを合理的なデフォルトとして選択する正当な理由があると思います。
  • この値を上書きすることの潜在的なリスクと利点について、他に何を知っておく必要がありますか？
4

7 に答える 7

103

TCP接続は、タプル（送信元IP、送信元ポート、宛先IP、宛先ポート）によって指定されます。

セッションのシャットダウン後にTIME_WAIT状態が発生する理由は、ネットワーク内で（または何らかの応答を要求する可能性のある）ライブパケットがまだ存在している可能性があるためです。同じタプルを再作成し、それらのパケットの1つが表示された場合、そのパケットは接続の有効なパケットとして扱われます（おそらく、シーケンス処理が原因でエラーが発生します）。

したがって、TIME_WAIT時間は通常、パケットの最大経過時間の2倍に設定されます。この値は、ネットワークがパケットを破棄する前にパケットが到達できる最大経過時間です。

これにより、同じタプルとの接続を作成する前に、そのタプルの以前のインカネーションに属するすべてのパケットが無効になることが保証されます。

これは通常、使用する必要のある最小値を示します。最大パケットエージングは​​、ネットワークプロパティによって決まります。たとえば、パケットの残り時間がはるかに長いため、衛星の寿命はLANの寿命よりも長くなります。

于 2008-12-03T13:46:17.170 に答える
21

通常、「アクティブ クローズ」を発行するエンドポイントのみが TIME_WAIT 状態になります。したがって、可能であれば、クライアントにアクティブクローズを発行してもらい、TIME_WAIT をサーバーではなくクライアントに残します。

ここを参照してください: http://www.serverframework.com/asynchronousevents/2011/01/time-wait-and-its-design-implications-for-protocols-and-scalable-servers.htmlおよび詳細についてはhttp://www.isi.edu/touch/pubs/infocomm99/infocomm99-web/を参照してください (後述では、TIME_WAIT を考慮しないプロトコル設計のために常に可能であるとは限らない理由についても説明しています)。

于 2008-12-03T15:40:34.863 に答える
10

TIME_WAIT の理由と、デフォルト設定を下げることに注意する必要がある理由について、Pax は正しいです。

より良い解決策は、ソケットの発信側に使用されるポート番号を変更することです。これを行うと、個々のソケットを待つ時間はあまり気にしなくなります。

リッスン ソケットの場合、SO_REUSEADDR を使用して、TIME_WAIT ソケットが存在しているにもかかわらず、リッスン ソケットをバインドできるようにすることができます。

于 2008-12-03T14:05:28.003 に答える
4

Windows では、レジストリから変更できます。

; Set the TIME_WAIT delay to 30 seconds (0x1E)

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters]
"TcpTimedWaitDelay"=dword:0000001E
于 2013-03-24T00:47:03.220 に答える
0

20 スレッドのテスト プログラムを使用して、サーバー アプリケーション (Linux 上) の負荷テストを行っています。

959,000 回の接続/クローズ サイクルで、44,000 回の接続に失敗し、TIME_WAIT に何千ものソケットがありました。

クローズ コールの前に SO_LINGER を 0 に設定し、その後のテスト プログラムの実行では、接続エラーは発生せず、TIME_WAIT のソケットは 20 未満でした。

于 2016-04-28T06:54:48.537 に答える
-2

TIME_WAIT が原因ではない可能性があります。

int listen(int sockfd, int backlog);

Unix Network Programming Volume1 によると、バックログは、完了した接続キューと未完了の接続キューの合計であると定義されています。

バックログが 5 であるとします。3 つの完了した接続 (ESTABLISHED 状態) と 2 つの不完全な接続 (SYN_RCVD 状態) があり、SYN を持つ別の接続要求があるとします。TCP スタックは、SYN パケットが別の機会に再送信されることを認識して無視します。これが劣化の原因になっている可能性があります。

少なくともそれは私が読んできたものです。;)

于 2008-12-03T18:04:41.250 に答える