TCP接続を開いたままにするにはハートビートが必要ですか？
TCP/IPを介して通信する2つのコンポーネントがあります。コンポーネントAはサーバー/リスナーとして機能し、コンポーネントBはクライアントです。 2人はできるだけ早く通信する必要があります。接続は常に1つしか存在できません（ただし、この質問は別です）。私の会社の上級開発者は、接続を開いたままにするために、2つのコンポーネント間でアプリケーションレベルのハートビートを使用する必要があると言いました。
TCP/IPとの接続は開いたままだと思っていましたが、これらのアプリケーション間のハートビートはかなり標準的な方法であると言っている多くのブログ/サイトを読みました。
コンポーネントAがハートビートコンポーネントBである理由の一部を知っているので、コンポーネントBとの通信に問題がある場合（リンクがダウンしているか、コンポーネントBが実行されていない場合）にサポートに通知できます。他の理由でハートビートが必要ですか？パイプを開いたままにするために、「パイプ内に」何かが頻繁にあることを確認するなどですか？
現在、コンポーネントAは20秒ごとにコンポーネントBをハートビートし、120秒以内にコンポーネントBから何も受信されない場合、接続を閉じます。次に、リンクが切断された場合にコンポーネントBが定期的に再接続を試行するという仮定の下で、接続のリッスンを再開します。これは正常に機能します。
繰り返しますが、TCP/IP接続を維持するにはハートビートが必要ですか？
接続shouldは関係なく開いたままですが、はい、多くの場合、死んだ接続の検出を支援するためにプロトコルがハートビートを実装するのを見るのが一般的です、IRC [〜＃〜] ping [〜＃〜] コマンドを使用します。
他の多くの人が指摘しているように、TCP接続はそれ自身のデバイスに残された場合、接続は維持されます。ただし、接続の途中にその状態を追跡するデバイスがある場合（ファイアウォールなど） ）、状態テーブルのエントリが期限切れにならないようにするために、キープアライブが必要になる場合があります。
コンポーネントの場合：
- 従来の有線ネットワーク内にある
- ファイアウォールがないか、それらの間にNATルーターがありません
- どちらもクラッシュしません
その後、ハートビートを持っている必要はありません。
これらの仮定のいずれかが間違っている場合（GPRSを見ています！）、ハートビートがかなり早く必要になります。
自分でハートビートを送信する必要はありません。 TCP接続は、使用方法に関係なく開いたままになります。
TCP=オプションの keepalive メカニズムを実装します。これは、後日データを送信する必要なく、タイムリーに閉じた接続を識別するために使用できます。その後、接続が閉じられたことを発見します。
Windowsを使用している場合、TCP Keep-aliveに注意してください。デフォルトでは、Windowsレジストリまたはsetsockoptを使用してグローバルに有効にしない限り無効になっています。
デフォルトのキープアライブ間隔は2時間です。
http://msdn.Microsoft.com/en-us/library/ms819735.aspx
2時間のキープアライブアライブが望ましくない場合は、独自のハートビートを実装し、WindowsでTCPキープアライブを無効にする必要があります。
ハートビートは、サーバーに生きていることを伝える良い方法です。つまり、サーバーがDoS攻撃防止システムを使用している場合、（サーバー）は、その特定の接続に割り当てられたすべてのリソースを、それが検出された後に削除します指定された期間の無活動。
ハートビートメカニズムを実装する義務はありません。
しかし、主な基準が応答性であるアプリケーションを設計している場合、それは良いことです。接続セットアップ、DNSルックアップ、およびパス検出に時間を無駄にしたくないでしょう。接続を常に維持し、ハートビートを送信し続けるだけで、アプリケーションは接続が有効であることを認識し、接続セットアップは不要です。簡単に送受信できます。
TCP/IP接続を維持するには、ハートビートが必要ですか？
接続がいつ切れたかを検出するのに役立ちます。
基本的にTCP接続はスイッチにルートに沿って保存されたリンク状態を作成します。接続が壊れたとき（適切な切断を送信せずにクラッシュしたときなど）、これらの状態を削除する必要がありますそして、これが起こると、TCP接続が閉じられました。これらのタイムアウトの長さを正確に知ることはできませんが、デバイスのプロデューサーやKabel-BWが提供する接続を使用して数時間開いたままだったときに、以前の1＆1インターネットプロバイダーによって、アイドル状態のSSHターミナルセッションが急速に（アイドル時間の15分未満）閉じられたことを覚えています...
最後に、前のスピーカーで締めくくります。ハートビートは、接続がまだ生きており、キックされているかどうかを判断する良い方法です...
TCPは接続を維持します。アプリケーションハートビートは、フェールオーバー、負荷分散、潜在的な問題に対する管理者への警告など、アプリケーションレベルの考慮事項です。
ハートビートは、TCPプロトコルの必要性ではありません。実装は、相手が非標準的な方法で接続を終了したかどうかを検出するためにあります（つまり、分解プロセスを経ていません）。
プロトコルとしてのTCP/IPは、閉じるパケットを送信するまで閉じられないように指定されています。むらのある無線接続やインターネット接続があっても、ソケットを開いたままにしておきました。
ただし、これはすべて実装に大きく依存しています。接続が「デッド」であると見なされる前に応答を待機する最大時間を意味する「タイムアウト」が存在する可能性があります。これは、アプリケーション自体に基づいていることもあれば、NATルーターに基づいていることもあります。
したがって、不良な接続を検出して開いたままにするために、「ハートビート」を保持することを強くお勧めします。
ハートビートと呼ばれるものは、タイムアウトを設定するときに役立ちます。あなたのソケットは開いているように見えるかもしれませんが、反対側の人はBSODに苦しんでいる可能性があります。無効なクライアント/サーバーを検出する最も簡単な方法の1つは、タイムアウトを設定して、メッセージが頻繁に受信されるようにすることです。
一部の人々はそれらをNOOP（No Ops）と呼んでいます。
しかし、いいえ、接続を維持する必要はなく、ステータスが何であるかを知るのに役立ちます。
ハートビートがなければ、TCP/IP接続が開いているかどうかは関係ないと思います。
接続は開いたままになります-ハートビートを実装する必要はなく、ソケットを使用するほとんどのアプリケーションはそうしません。