「使用中のアドレス」またはTCP接続を終了する際の問題を回避する方法

正しいシャットダウン

ネットワーク接続を正しく完了するには、両方の当事者が完了信号（FIN）を含むパケットを送信する必要があります。完了信号（FIN）は、当事者がデータを送信しなくなることを示し、ネットワークデータ交換を完了するために信号の受信を確認（ACK）する必要があります。 FINは、アプリケーションがclose（）、shutdown（）、またはexit（）メソッドを呼び出すとトリガーされます。 close（）メソッドが完了すると、カーネルは完了信号の2番目の側から確認するためにスタンバイモードに入ります。 これにより、シャットダウンを開始したプロセスは、カーネルが接続に関連付けられたリソースを解放する前に完了し、再びポートを使用して別のプロセスと通信できるようにします（この場合、ポートを使用しようとすると、AddressAlreadyInUse例外が発生します）。







画像上：

1. 確立された接続、ステータスESTABLISHEDがあります
2. クライアントは接続の終了を開始し、サーバーに信号を送信して接続を完了し（FIN）、サーバーが応答するのを待機状態に切り替えます（FIN_WAIT_1）
3. サーバーは、接続の完了に関する信号を受信し、確認（ACK）を送信し、接続の完了を待機する状態（CLOSE_WAIT）になります（close（）を呼び出します）
4. サーバーは、接続を正常に閉じたという信号（FIN）をクライアントに送信し、クライアント確認（ACK）の読み取りを試みた後、待機せずに切断します。
5. これで、クライアントは異なる順序で2つの信号を受信できます
   
   
   
   ACK-クライアントは、サーバーが接続を閉じる意図を理解したという確認を受け取りました
   
   
   • クライアントは、サーバーからの接続終了（FIN）信号のアイドル状態に入ります（FIN_WAIT_2）
   • クライアントは、サーバーが接続を閉じる（FIN​​）に関するシグナルを受信し、確認（ACK）を送信し、しばらく待機（TIME_WAIT）し、切断（カーネルがリソースを解放）（CLOSED）
   
   
   
   
   FIN-クライアントは、サーバーからの確認（ACK）よりも早く、サーバー側の接続を閉じる（FIN​​）ことに関するシグナルを受信します。
   
   
   1. クライアントは、サーバーが接続を閉じているというシグナルの確認応答を送信し、シャットダウン状態（CLOSING）に入ります
   2. 切断後、サーバーから確認信号（ポイント2のクライアントから完了信号を受信した直後にサーバーによって送信された）からの確認信号の読み取りを試み、しばらく待機し（TIME_WAIT）、カーネルがリソースを解放します（CLOSING）。
   
   
   

この図は、FINおよびACKパケットがリモート側から受信される順序に応じて、正しい完了中に発生する可能性のあるすべての状態を示しています。 接続の完了（図の左半分）を開始した場合、相手側はFINパッケージ（図の右半分）の受領の確認を待たないことに注意してください。 TIME_WAITは、送信した確認応答（ACK）が相手側で受信されなかった場合、または何らかの理由で誤ったパケットが発生した場合に必要です。 サーバー側でTIME_WAIT状態が発生しなかった理由はわかりませんが、クライアントが閉鎖を開始した場合、これは無条件であり、待機する必要はありません。 TIME_WAIT状態は、プロセスが完了した後、数分間ポートを保持できます。 保持時間はオペレーティングシステムによって異なります。一部のオペレーティングシステムでは動的であり、標準値の範囲は1〜4分です。



両方の当事者が反対側からそれを受け取る前に完了信号を開始する時間がある場合、両側は待機（TIME_WAIT）を通過することを強制されます。

リスニング側の正しい切断

リスニングソケットはすぐに閉じることができ、着信接続がない場合、その状態はすぐにCLOSEDになります。 着信接続がある場合、FIN_WAIT_1に進み、次にTIME_WAITになります。



リスニングソケット側では、完全なクローズを保証できないことに注意してください。 クローズする前にselect（）メソッドで接続の使用をテストしますが、select（）を呼び出してからclose（）を呼び出す前に着信接続が表示される可能性はわずかですがあります。

リモート側の予期しないシャットダウン

サーバーが突然シャットダウンした場合、ローカル側は接続のクローズを開始します。この場合、TIME_WAITは不可避です。 ネットワーク障害またはマシンの再起動（まれなケース）のためにリモート側が消えた場合、ローカルポートはTIME_WAIT状態タイムアウトが期限切れになるまでバインドされたままになります。 さらに悪いことに、一部の古いオペレーティングシステムはFIN_WAIT_2状態のタイムアウトを実装しておらず、無期限にその状態を維持できます。その場合、システムの再起動のみが保存できます。



アクティブな接続中にローカルアプリケーション（クライアント）がクラッシュした場合、TIME_WAIT状態が終了するまでポートはビジーになります。リモート側への接続中に閉じたアプリケーション（保留中）についても同様です。

問題を回避する方法

オプションSO_REUSEADDR

setsockopt（）メソッドを使用してSO_REUSEADDRオプションを設定できます。これにより、ポートがまだTIME_WAIT状態にある場合でもポートへのバインディングを作成できます（1つのプロセスのみがポートにバインドできます）。 これは、「アドレスがすでに使用されています」というメッセージを回避する最も簡単で効果的な方法です。



しかし、奇妙なことに、SO_REUSEADDRオプションを使用すると、「すでに使用されているアドレス」よりもキャッチしにくいエラーが発生する可能性があります。 SO_REUSEADDRを使用すると、TIME_WAITでスタックしたポートを使用できますが、最初にバインドされたプロセスでこのポートを使用できます。



なに？



ローカルポート1010を使用してfoobar.comサーバーのポート300に接続すると、クライアントが切断されてポートがTIME_WAIT状態になり、ポート300でfoobar.comに接続する以外の接続でこのポート（1010）を使用できるとします。

これにより問題が発生する可能性がある状況は次のとおりです。予約済みポートを必要とするサービスに接続するために、プログラムがバインド用の予約済みローカルポート（<1024）を見つけようとし、SO_REUSEADDRオプションを使用すると、マシンでプログラムを起動するたびにTIME_WAITでハングした場合でも、同じ予約ポートを受け取り、ポートが最後に使用された場所で「すでに使用されているアドレス」を取得できます。 この場合、SO_REUSEADDRオプションの使用を拒否する必要があります。



SO_REUSEADDRを使用したくない人もいます。なぜなら、 このオプションにはセキュリティ上の問題があります。 一部のオペレーティングシステムでは、このオプションにより、異なるプロセスが同じポートを同時に使用できる場合があります。 ほとんどのサーバーは特定のアドレスを使用せずにポートにバインドするため、代わりにINADDR_ANYを使用するため、これは問題です（netstatコマンドでは* .8080として表示されます）。 したがって、サーバーがアドレス* .8080と通信する場合、ローカルマシンの別のユーザーからの別のプロセスは、アドレスlocal_machine.8080に接続でき（その意図はまったく良くないかもしれません）、すべての接続をインターセプトできます。 彼はより具体的な住所を示した。 この問題は、アカウント制限のないマルチユーザーシステムでのみ現れます。これはローカルマシンの外部からアクセスできる脆弱性ではありません。特定のマシンアドレスにバインドすることで簡単に回避できます（INADDR_ANYを使用せずに）。



システムのコアが何百または何千ものTIME_WAIT状態にリソースを費やすという事実を好まない人もいますが、この問題は以下で説明するアプローチを使用することでも回避できます。

クライアントが最初に切断する

上の図を見ると、リモート側で閉鎖が開始されるとTIME_WAIT状態を回避できることがわかります。つまり、サーバーがクライアントに最初にシャットダウンを開始させることを許可すれば、問題を回避できます。 これを行うには、クライアントがクロージャを開始する必要があるときにクライアントが認識するような方法で、ユーザープロトコルのアーキテクチャを構築できます。 サーバーはクライアントからEOFコマンドを受信することで安全なシャットダウンを行うことができますが、タイムアウトを設定して、クライアントが正しくシャットダウンできるようにクライアントがシャットダウンするのを待つ必要があります。 ほとんどの場合、サーバーへの接続が正しく完了するまで数秒待つだけで十分です。



この概念は、おそらく「リモート側が最初に切断する」と呼ぶのが理にかなっています。そうでなければ、クライアントとサーバーの名前に依存します。 同じマシン上にあり、異なるサーバーにアクセスする複数のクライアントプログラムで構成されるシステムを開発している場合、クライアントマシンのリソースを節約するために、サーバーへの切断の責任を移したいと思うでしょう。



たとえば、リモートシェル（rsh）を使用してネットワーク上のすべてのマシンと通信するスクリプトを作成しましたが、複数のオープン接続を常に使用して並行して動作します。 rshで使用できるポートは1024未満です。 最初に「rsh -n」コマンドを使用しました。これにより、ローカル側が最初にシャットダウンされます。 いくつかのテストの後、使用可能なポートはすべて1024未満で、TIME_WAIT状態であり、プロセスは停止しました。 -nオプションを削除すると、リモート側で切断が開始され、TIME_WAITの問題は解決されますが、着信接続を待機しているときにrshがハングする可能性があります。 また、ローカルで着信接続を閉じると、ポートは再びTIME_WAIT状態になります。 最後に、rshの使用を拒否し、perlで実装を記述しました（ 現在のバージョンはここからダウンロードできます ）。

タイムアウトの削減

何らかの理由で上記のオプションがどれもあなたに合わない場合、TIME_WAIT状態のタイムアウトを減らす機会があります。 このような操作の機能と実装は、使用しているオペレーティングシステムによって異なります。 タイムアウトが短すぎると、特にパケットが失われたりネットワークが混雑したりする場合に、マイナスの結果を招く可能性があることを覚えておく価値があります。