69

サーバーへの短時間の接続を多数行うクライアントがあると仮定しましょう。

TIME_WAITクライアントが接続を閉じると、クライアント側で多くのポートが状態になります。クライアントがローカル ポートを使い果たすため、すぐに新しい接続を試みることができなくなります。

サーバーが接続を閉じるとTIME_WAIT、サーバー側に多くの が表示されます。しかし、これは何か害がありますか？クライアント (または他のクライアント) は、ローカル ポートが不足することはなくTIME_WAIT、サーバー側で状態の数が増えるため、接続を試行し続けることができます。最終的にはどうなりますか？何か悪いことが起こりますか？(スローダウン、クラッシュ、接続の切断など)

TIME_WAIT私の質問は「目的は何ですか？」ではないことに注意してください。しかし、「サーバー上に非常に多くの状態がある場合はどうTIME_WAITなりますか?」TIME_WAITTCP/IP で接続が閉じられたときに何が起こるか、および状態が必要な理由は既に知っています。トラブルシューティングを行うつもりはありませんが、潜在的な問題を知りたいだけです。

簡単に言えば、netstat -nat | grep :8080 | grep TIME_WAIT | wc -lprintとしましょう100000。何が起こるでしょうか？OS のネットワーク スタックは遅くなりませんか? 「開いているファイルが多すぎます」エラー？それとも、何も心配する必要はありませんか？

4

6 に答える 6

66

各ソケットTIME_WAITはカーネル内のメモリをいくらか消費しますが、通常はソケットよりもいくらか少ないですが、ESTABLISHED依然として重要です。十分な数を指定すると、カーネル メモリが使い果たされるか、少なくともパフォーマンスが低下する可能性があります。これは、そのメモリが他の目的に使用される可能性があるためです。 TIME_WAITソケットは開いているファイル記述子を保持しないため (適切に閉じられている場合)、「開いているファイルが多すぎます」というエラーについて心配する必要はありません。

ソケットはまた、その特定のsrc/ dstIP アドレスとポートを拘束するため、TIME_WAIT間隔中に再利用することはできません。(これは、TIME_WAIT状態の意図された目的です。) 同じポート ペアに再接続する必要がない限り、通常、ポートを結合することは問題になりません。ほとんどの場合、一方の側は一時ポートを使用し、一方の側だけがウェルノウン ポートに固定されます。TIME_WAITただし、同じ 2 つの IP アドレス間で繰り返し頻繁に接続している場合、ソケットの数が非常に多いと一時的なポート スペースが使い果たされる可能性があります。これは、この特定の IP アドレス ペアにのみ影響し、他のホストとの接続の確立には影響しないことに注意してください。

于 2009-12-06T02:56:34.593 に答える
15

各接続は、タプル (サーバー IP、サーバー ポート、クライアント IP、クライアント ポート) によって識別されます。重要なことに、TIME_WAIT接続 (サーバー側またはクライアント側のいずれであっても) はそれぞれ、これらのタプルの 1 つを占有します。

クライアント側のTIME_WAITs を使用すると、これ以上接続できない理由が簡単にわかります。ローカル ポートがなくなります。ただし、同じ問題がサーバー側にも当てはまります。単一のクライアントに対してTIME_WAIT64k 接続の状態になると、そのクライアントからの接続をこれ以上受け入れることができなくなります。古い接続と新しい接続 - 両方の接続が同じタプルによって識別されます。この場合、サーバーは、そのクライアントからの新しい接続試行に対して s を送り返すだけです。RST

于 2009-11-26T22:58:39.960 に答える
13

これまでの調査結果:

サーバーがシステムコールを使用してソケットを閉じたとしても、TIME_WAIT 状態に入ると、そのファイル記述子は解放されません。ファイル記述子は、後で TIME_WAIT 状態がなくなったときに解放されます (つまり、2*MSL 秒後)。したがって、TIME_WAIT が多すぎると、サーバー プロセスで「開いているファイルが多すぎます」というエラーが発生する可能性があります。

OS TCP/IP スタックは適切なデータ構造 (ハッシュ テーブルなど) で実装されているので、TIME_WAIT の総数が OS TCP/IP スタックのパフォーマンスに影響を与えることはないと思います。TIME_WAIT 状態のソケットを所有するプロセス (サーバー) のみが影響を受けます。

于 2009-11-26T14:25:25.333 に答える
2

多くの異なるクライアント IP からサーバー IP への多数の接続がある場合、接続追跡テーブルの制限に遭遇する可能性があります。

小切手：

sysctl net.ipv4.netfilter.ip_conntrack_count
sysctl net.ipv4.netfilter.ip_conntrack_max

すべての src ip/port および dest ip/port タプルに対して、追跡テーブルには net.ipv4.netfilter.ip_conntrack_max のみを含めることができます。この制限に達すると、ログに「nf_conntrack: テーブルがいっぱいです。パケットをドロップしています。」というメッセージが表示されます。サーバーは、追跡テーブルに再びスペースができるまで、新しい着信接続を受け入れません。

この制限は、エフェメラル ポートがなくなるずっと前に発生する可能性があります。

于 2016-08-29T11:48:51.983 に答える
-1

サーバーは、着信接続に割り当てるポートを使い果たす可能性があるようです (既存の TIMED_WAIT の間) - DOS 攻撃のケースです。

于 2009-11-26T13:09:09.577 に答える