TCP接続を開いたままにするためにハートビートが必要ですか？

TCP / IPを介して通信する2つのコンポーネントがあります。コンポーネントAはサーバー/リスナーとして機能し、コンポーネントBはクライアントです。2つはできるだけ早く通信する必要があります。接続は常に1つしかありません（ただし、この質問は別です）。私の会社の上級開発者は、接続を確実に開いたままにするために、2つのコンポーネント間でアプリケーションレベルのハートビートを使用する必要があると述べています。

TCP / IPでも接続は開いたままであると思っていましたが、これらのアプリケーション間でハートビートを行うのはかなり標準的な方法であると多くのブログ/サイトを読んだことがあります。

コンポーネントAがコンポーネントBをハートビートする理由の一部を知っているので、コンポーネントBとの通信問題（リンクがダウンしているか、コンポーネントBが実行されていない）がある場合にサポートに通知できます。他の理由でハートビートが必要ですか？たとえば、「パイプの中に」何かを頻繁に開いておくためにそれを確実にするために？

現在、コンポーネントAはコンポーネントBを20秒ごとにハートビートし、120秒以内にコンポーネントBから何も受信されない場合は接続を閉じます。次に、リンクが切断された場合にコンポーネントBが定期的に再接続を試行すると想定して、接続のリスニングを再開します。これは正常に動作します。

私の質問を繰り返します：TCP / IP接続を維持するためにハートビートは必要ですか？

接続は関係なく開いたままにする必要がありますが、はい、多くの場合、プロトコルがハートビートを実装してデッド接続の検出に役立つことがよくあります。たとえば、IRCにPINGコマンドを使用します。

他の多くの人が指摘しているように、TCP接続は、それ自体のデバイスに委ねられている場合はアップのままです。ただし、接続の途中にその状態を追跡するデバイス（ファイアウォールなど）がある場合は、状態テーブルのエントリが期限切れにならないようにキープアライブが必要になることがあります。

コンポーネントの場合：

• 従来の有線ネットワークにある
• それらの間にファイアウォールやNATルーターはありません
• どちらもクラッシュしません

その後、あなたはハートビートを持っている必要はありません。

これらの仮定のいずれかが誤っている場合（私はGPRSを参照しています！）、ハートビートがかなり早く必要になります。

ハートビートを自分で送信する必要はありません。TCP接続は、使用状況に関係なく開いたままになります。

TCPはオプションのキープアライブメカニズムを実装していることに注意してください。キープアライブメカニズムを使用すると、後日データを送信して接続が閉じていることを検出するだけでなく、閉じられた接続をタイムリーに識別することができます。

Windowsを使用している場合は、TCPキープアライブに注意してください。デフォルトでは、Windowsレジストリでグローバルにオンにするか、setsockoptでオンにしない限り、無効になっています。

デフォルトのキープアライブ間隔は2時間です。

http://msdn.microsoft.com/en-us/library/ms819735.aspx

2時間のキープアライブアライブが望ましくない場合は、独自のハートビートを実装し、WindowsでTCPキープアライブを無効にする必要がある場合があります。

TCP / IP接続を維持するためにハートビートは必要ですか？

これらは、接続がいつ停止したかを検出するのに役立ちます。

TCPは接続を維持します。アプリケーションハートビートは、フェイルオーバー、ロードバランシング、または潜在的な問題に対する管理者への警告などのアプリケーションレベルの考慮事項です。

ハートビートは、サーバーが生きていることをサーバーに伝える良い方法です。つまり、サーバーがDoS攻撃防止システムを使用している場合、サーバー（サーバー）は、特定の接続に割り当てられたすべてのリソースを、それが検出された後で削除する可能性があります指定された期間の非アクティブ。
ハートビートメカニズムを実装する義務はありません。

しかし、主な基準が応答性であるアプリケーションを設計している場合、それは良いことです。接続設定、DNSルックアップ、パス検出に時間を費やしたくないでしょう。常時接続を維持し、ハートビートを送信し続けるだけで、アプリケーションは接続が有効であることを認識し、接続設定は不要です。単純な送受信。

プロトコルとしてのTCP / IPは、クローズパケットを送信するまで閉じられないように指定されています。無線またはインターネットの接続が不安定な場合でも、ソケットを開いたままにしておきました。

ただし、これはすべて実装に大きく依存しています。ほとんどの場合、「タイムアウト」が発生します。これは、接続が「デッド」であると見なす前に応答を待機する最大時間を意味します。これは、アプリケーション自体に基づく場合もあれば、NATルーターに基づく場合もあります。

したがって、不良な接続を検出して開いたままにするために、「ハートビート」を維持することを強くお勧めします。

基本的に、TCP接続は、ルートに沿ってスイッチに保存されるリンク状態を作成します。（適切な切断を送信せずに、ある相手がクラッシュした場合など）切断された接続を検出するために、これらの状態は、非アクティブな状態が続いた後に削除する必要があります。これが発生した場合、TCP接続は閉じられています。これらのタイムアウトの長さは正確にはわかりませんが、デバイスプロデューサーやインターネットプロバイダーに依存しているようです。Kabel-BWが提供する接続を使用しているときに、アイドル状態のSSHターミナルセッションが以前の1＆1インターネットプロバイダーによって数時間開いたままになっている間に、アイドル状態の15分未満で急速に閉じられたことを覚えています...

最後に、これまでの講演者との結論をまとめます。ハートビートは、接続がまだ生きていてキックしているかどうかを確認する良い方法です...

タイムアウトを設定しようとするときに、ハートビートと呼ばれるものが役立ちます。あなたのソケットは開いているように見えるかもしれませんが、反対側の人はBSODに苦しんでいるかもしれません。機能していないクライアント/サーバーを検出する最も簡単な方法の1つは、タイムアウトを設定して、メッセージが頻繁に受信されるようにすることです。

一部の人々はそれらをNOOPs（No Ops）と呼びます。

しかし、いいえ、それらは接続を維持する必要はなく、ステータスが何かを知るのに役立ちます。

ハートビートがない場合、TCP / IP接続が開いているかどうかは関係ありません。

ハートビートは、TCPプロトコルの必要ではありません。その実装は、相手側が非標準的な方法で接続を終了したかどうかを検出するためにあります（つまり、ティアダウンプロセスを通過していません）。

接続は開いたままになります-ハートビートを実装する必要はなく、ソケットを使用するほとんどのアプリケーションはそうしません。

多くのプロトコルは、ロイドが言ったようなハートビートまたは健康状態タイプのものを実装します。接続がまだ開いていること、および何かを見落とした可能性がある場合