最近、TCP サーバーとクライアントの間の中間リンクがダウンするという問題に遭遇しました。プライマリ サーバーがダウンしている場合、クライアントはセカンダリ サーバーに接続する必要があります。プライマリ サーバーが購入されると (たとえば、ターミナルで ^C を実行することによって)、TCP シャットダウン シーケンスが実行され、クライアントは切断されたリンクを正常に検出し、セカンダリ サーバーを試行します。ただし、中間リンクがダウンした場合、クライアントとサーバーはそれを認識しません。クライアントが検出できる唯一の方法は、TCP バッファが失敗した「送信」操作でいっぱいになったときです。
これに対する解決策として、「TCP キープアライブ」メカニズムが使用されています。これは十分に機能します。
私の質問は、「TCP キープアライブ」が唯一の解決策ですか?
-プラブー
キープアライブは、一方の側 (通常は要求を受信するサーバー) が接続が切断されたことを認識していない、いわゆるハーフ オープン接続に対処するように設計されています。サーバーにリクエストを送信しようとするとエラーが返されるため、クライアントは通常それを認識しています。
別のオプションは、リスナーを実行し続けることです。クライアントが通信の問題を検出すると、サーバーへの接続を再試行します。サーバーは着信接続を取得し、それが同じ IP アドレスからのものかどうかを確認し、そうである場合は、開いている接続を閉じて新しい接続を確立します。
しかし、クライアントが接続がダウンしたことを認識せず、サーバーが何かを送信する必要がある場合、サーバーが接続を再確立する方法はありませんが、TCP キープアライブです。
キープアライブを使用したくない場合は、アプリケーション レベルのキープアライブを使用できます。たとえば、アプリケーション固有のエコー メッセージなどを送信します。
「キープアライブ」を使用してクライアントとサーバー間で TCP を介してやり取りされるプロトコルを拡張することにより、常にアプリケーションレベルでこれを処理しました-メッセージサーバーとクライアントは、このメッセージをたとえば毎秒送信し、「キープアライブ」メッセージを取得していない場合は 2 秒以内にメッセージを送信します。 、接続が閉じている可能性があります。
TCP の Keep-Alive メカニズムは優れていますが、特に異なるプラットフォームで作業している場合は使いにくいです。
別の解決策は、別のソケットでハートビートを使用することです。そうすれば、接続がダウンしているかどうかをすぐに知ることができます。これは、プライマリ接続がメッセージ境界なしでストリーミング データを送信している場合に役立ちます。
SO_KEEPALIVE が設定されていなくても、デッド tcp 接続に沿ってデータを送信しようとすると、通常はリセットされるか、最終的にタイムアウトになります。これらのいずれかが最終的にアプリケーションにエラーを送信します。
SO_KEEPALIVE は、それ以外の場合はアイドル状態の接続で、これがより早く検出される可能性があることを意味します。それで全部です。
TCP の Out-Of-Band 機能を使用して、独自のキープアライブを発明して実装することもできますが、すでに構築されているものに重大な問題がない限り、それは考慮しません。