クライアントとサーバーのコンポーネントがあります。サーバーは、ファイアウォールまたはロード バランサーの背後にインストールできます。多くのサイト/フォーラムは、非アクティブによる接続の終了を回避するために TCP キープアライブ機能を使用することを提案しました。問題は、クライアントからのキープアライブ メッセージが実際にサーバーに到達するかどうかです。tcptrace ユーティリティを使用して展開をシミュレートしようとしたところ、クライアントがキープアライブ メッセージの ACK を取得しているにもかかわらず、キープアライブ メッセージがサーバーに到達しないことがわかりました。LB/FW が同じように機能するかどうかはわかりません。
ファイアウォールとロードバランサーの場合、ソケットを介した非アクティブによる接続の終了を回避するためのキープアライブは適切なオプションですか?
もちろん、答えは「場合による」です。
多くのファイアウォールとロード バランサーは、フロントエンドとバックエンドの TCP 接続を別々に維持します。例:
client <-- TCP --> firewall/balancer <-- TCP --> server
このような状況では、TCP キープアライブを使用しても期待どおりに機能しません。なぜだめですか？TCP キープアライブはそのTCP セッションに対してのみ機能し、キープアライブ プローブ パケットは、データを運ぶパケットよりも「管理オーバーヘッド」パケットに似ています。これは、a)クライアント エンドで TCP キープアライブを使用することは、ファイアウォール/バランサーへの TCP 接続を維持することのみを意味し、b)ファイアウォール/バランサーはそれらのキープアライブ プローブ パケットをバックエンド接続に「転送」しないことを意味します。
では、TCP キープアライブの使用は有用でしょうか? はい。OSI スタックの下位層で動作し、それらのパケットを転送する他のタイプのプロキシがあります。TCP キープアライブを使用すると、これらのタイプのネットワーク仲介者を介してアイドル状態の接続を維持するのに適しています。
クライアント/サーバー アプリケーションが、ファイアウォール/バランサーを介してアイドル状態の可能性がある長寿命の TCP 接続を使用している場合、その接続が切断されないようにする最善の方法 (ファイアウォール/バランサーによって送信されたパケットを使用して、場合によっては丁寧に、場合によっては静かに)RST ) は、アプリケーション層で「ping」または「ハートビート」メッセージを使用することです。(これを「アプリケーションのキープアライブ」と考えてください。) これは、たとえばクライアントからサーバーに送信されるある種のメッセージです。シンプルで効果的な手法は、クライアントが定期的にサーバーに数バイトを送信し、サーバーがクライアントにエコー バックするようにすることです。クライアントは送信したバイトを認識しており、サーバーから同じバイトを受信すると、
お役に立てれば！