web-dev-qa-db-ja.com

TIME_WAITの設定TCP

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

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

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

  • TIME_WAIT値を0に設定することはできませんが、安全に5に設定できますか？ 10はどうですか？この値の「安全な」設定を決定するものは何ですか？
  • この値のデフォルトが60なのはなぜですか？私よりも賢い人がこれを合理的なデフォルトとして選択する十分な理由があると推測しています。
  • この値をオーバーライドすることの潜在的なリスクと利点について、他に知っておくべきことはありますか？
tcpnetwork-protocols
65
Vinnie

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

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

そのため、通常、TIME_WAIT時間は、パケットの最大有効期間の2倍に設定されます。この値は、ネットワークがパケットを破棄するまでにパケットが到達できる最大年齢です。

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

一般的に、使用する必要がある最小値が決まります。最大パケットエージはネットワークプロパティによって決まります。たとえば、パケットにはさらに先が行くため、衛星のライフタイムはLANのライフタイムよりも長くなります。

92
paxdiablo

通常、「アクティブクローズ」を発行するエンドポイントのみが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は考慮されません）。

19
Len Holgate

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

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

リスニングソケットの場合、SO_REUSEADDRを使用して、TIME_WAITソケットが座っているにもかかわらずリスニングソケットをバインドできます。

9
Darron

Windowsでは、 変更可能 it レジストリ経由 ：

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

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters]
"TcpTimedWaitDelay"=dword:0000001E
3
Synetech

tcp_reuseの設定は、パラメータ（カーネル3.2以降、残念ながらRHELとXenServerのすべてのバージョンを失効させる）がある限り、time_waitを変更するよりも便利です。

特にVPN接続ユーザーの場合、値をドロップすると、アウトバウンド接続でプロキシトンネルが常に再作成される可能性があります。デフォルトのLinux構成よりも低いデフォルトのNetscaler（XenServer）構成では、Chromeは1つのWebページを取得するためにプロキシトンネルを最大で数十回再作成する必要があります。 MavenやEclipse P2などの再試行は失敗します。

パラメーターの元の動機（重複を避ける）は、すべてのTCP要求にタイムスタンプを含めることを指定するRFC TCP RFCによって冗長化されました。

2
andrew glynn

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

959,000の接続/クローズサイクルでは、TIME_WAITで44,000の接続の失敗と数千のソケットが発生しました。

呼び出しを閉じる前にSO_LINGERを0に設定し、その後のテストプログラムの実行では、接続エラーが発生せず、TIME_WAITで20ソケット未満でした。

0
Michael Taylor