多くの場合、キープアライブを明確に理解せずに、独自のサーバーを含む多くの学生、混乱し、TCPもHTTPもしばしばこれらの概念を混同し、また、キープアライブと呼ばれる可用性をキープアライブキープアライブ。名前は基本的に同じですが、表現の意味と範囲は非常に異なっているが、これらの概念の説明は、次の行います。
可用性keepalivedの
サービスの可用性は、障害のIP単一点を回避するために利用することができるベースkeepalivedのVRRPプロトコル実装プログラム、です。その役割は、keepalivedのが検出された、サーバーがダウンした場合、サーバーの状態を検出することである、または障害が発生したサーバーの作業keepalivedのサーバーが自動的にサーバーファームに追加代わりに、サーバーの操作の他のサーバ、。
keepalivedのは、一般的ではないだけではなく、他の負荷分散技術を持つ（例えばLVS、haproxy、nginxのような）高可用性クラスタを実現するために一緒に働きます。
ロードバランシングマシンにDNSの使用の簡単な例では、その後、WEBにリバースプロキシマシンを負荷分散します。一つだけのバランスをとるミドルロードは、高可用性を実現することができない、MASTERの負荷分散が失敗した場合の二台のマシンの後、keepalivedのあなたは、サービスが唯一の外部仮想IPであることを確認できるように構成し、少なくとも二つを行う必要があります時間は、自動的にバックアップの負荷分散サービスは影響を受けませんに切り替えます。これらを確実にするためにkeepalivedの。
我々は以前、その後TwemproxyにHAProxyは、高可用性と負荷分散を提供するために、高可用性と負荷分散、Twemproxy Redisのクラスタを提供し、高可用性を提供するために、もう少し複雑なサービス構成、keepalivedのHAProxyを持っていました。高可用性を保証する基本的なロードバランシングサービスを提供し、我々は、高可用性のWebサービスを保証することができリバースプロキシサーバとして最もnginxのを使用しています。
nginxの+ keepalivedのビルド高可用性サービス多くのチュートリアルがあります。あなたは、自分の関心を構築しようとすることができます。
TCP的キープアライブ
TCPキープアライブ主な目的は、サーバリソースのタイムリーなリリースです。
接続が何もデータ送信が存在しないときに、他の側にも長蛇の列に接続されている方法を決定するためにデータを送信する前に、TCPプロトコルのクライアントとサーバを経由して、クライアントがデータを送信していない場合、または非常に長い時間を越えて確立された後、最終的にドロップされる、または実際に何のデータ伝送接続は維持されていないか、閉じて、またはどのくらいの接続がどのようなメカニズムの下でリソースを解放するためにシャットダウンする必要があります。TCPキープアライブは、この問題が導入された解決することです。
制御するための3つの主要なTCPキープアライブパラメータ
tcp_keepalive_time 7200
心跳周期
tcp_keepalive_intvl 75
侦测包发送间隔
tcp_keepalive_probes 9
侦测包重试次数プロセスパラメータと解釈。
クライアントがサーバとの接続を確立した後、任意のデータを送信しないtcp_keepalive_time（7200S）の後に両側場合、サーバは、（75S）をtcp_keepalive_intvlするすべてのクライアントは、おそらく、クライアントがクラッシュを含むクライアントの接続状態を、決定、プローブパケットを送信します、到達不能な異常状態をホスト、アプリケーションを終了することを強制。検出パケットがtcp_keepalive_probesを送った後に、（9）時間はまだ（つまり、ACKパケットである）、クライアントへの応答を受け取っていない場合は、サーバーは捨てたり閉じたりすることができ、この接続が利用できないと思われます。
nginxの的キープアライブ
TCP層はキープアライブ、なぜnginxのアプリケーション層に必要なキープアライブを持っていますか？
私は、TCPキープアライブを保証するトランスポート層接続、デフォルトの設定を使用して可用性が2時間の検出期間であることを理解しています。キープアライブ接続のnginxのは、アプリケーション層を確実にするために利用可能です。第四層、第七層にアプリケーション層の可用性を確保するためのアプリケーション層プロトコルのトランスポート層の可用性を確保します。
：前述の本があり
、アプリケーション層TCPキープアライブハートビートを交換できないのはなぜか？アプリケーションハートビートを記述することに加えて（まだプロセス、スムーズなネットワークで）、それは、アプリケーションが正常に働くことができるということであるより重要であるまだ生きていました。オペレーティングシステムによるTCPキープアライブでも、プロセスのデッドロックまたは閉塞あれば、探査のための責任がある、オペレーティングシステムは、他の当事者が例外を知ることができない、いつものようにTCPキープアライブ情報を送受信します。
基本的には同じですが、名前のnginxのキープアライブTCPの設定は何も同じではありません。以下のように設定
so_keepalive=on|off|[keepidle]:[keepintvl]:[keepcnt] SO_KEEPALIVE = 30メートル:: 10オープンTCPには、パケットデータ送受信パケットが10回送信検出するために、システムデフォルトを使用して検出時間間隔を送信しない30分後に検出を表します。
HTTPの的キープアライブ
より一般的なHTTPキープアライブは、長いリンク短いリンクになることです。各短い接続要求応答、クライアントとサーバは新しい接続がすぐに完了した後に切断されて作成する必要があります。長い接続を使用する場合、クライアントからサーバーへの接続が確立されるキープアライブは、接続が応答した後に完了していない、次のリクエスト直接これを繰り返し接続と切断を確立するオーバーヘッドを避け、元の接続を取ります。
そして、クライアント側とサーバー側は、合意された長いか短い接続通信の通信接続を使用する方法です。
メインの接続ヘッド
客户端请求长连接头部：Connection: keep-alive
服务端同意使用长连接的响应头部：Connection: keep-alive
两者缺一不可，如果服务器端不支持长连接：Connection: Close
如果是HTTP/1.1默认使用长连接，无论头部是不是 Connection: keep-alive：ポイントに注意してください
、現在の接続のための接続二つの側面のみ有効、とだけ彼らの接続状態を識別するために、後方接続ヘッドを通過しません。
エージェントは、多段階のプロセスである場合は何ですか？
1クライアントとの接続でプロキシサーバー場合でも、内蔵さ：キープアライブが、プロキシサーバ1は、長い接続をサポートしていませんが、接続答えた：閉じるので、2つが短いことにより、接続されている
2 1プロキシサーバおよびプロキシサーバ2のビルド接続使用した場合でも：閉じる短い接続を、プロキシサーバ2は、接続答え：閉じるので、2つの短い接続の使用
時間3 Webプロキシサーバ2をしても、接続使用してマシンを構築し：キープアライブを、ウェブマシンは、長い接続をサポートしていますまたは接続に返信：キープアライブ、長い間接続を使用して、両方の
HTTPはそう余分に気をつけて、最長遭遇キープアライブの開発者です。サーバー接続が長い長い接続を使用する必要がない、双方が同意し、長い接続通信を使用する必要があります。以前に遭遇アリ雲SLBは、SLBとの長い接続、WEBサーバやプロキシサーバー接続をサポートしていない短い接続されています。