最近のインタビューで、オンライン チャット クライアント アプリケーションにどのようにアプローチするかを尋ねられました。標準の「ポーリング」ソリューションを使用しましたが、インタビュアーが「HTTP 1.1 キープアライブ」メソッドを探していたため、切断されました。かなり長い間 HTTP を使用しており、ポイント全体が「ステートレス」であることを思い出していたので、これは私には思い浮かびませんでした (また、キープアライブが一貫して実装されていないことは言うまでもありません)。
私の質問は、「keep-alive」ヘッダーが設定されている場合、Web サーバーがクライアントに情報をブロードキャストおよび/または送信することは可能ですか?
HTTP 1.1 では、キープアライブがデフォルトの動作です。(HTTP 1.0 では、デフォルトの動作は接続を閉じることでした。) サーバーは、最初の応答で接続を終了するために、'Connection: close" ヘッダーを送信する必要があります。サーバーからデータをプッシュすることは、HTTP プロトコルに大きく違反し、キープアライブを使用しても、クライアントはサーバーをポーリングする必要があります。
HTTP キープアライブと TCP キープアライブを区別することが重要です。HTTP キープアライブは、サーバーまたはクライアントによって接続が閉じられるのを防ぎます。TCP キープアライブは、接続が長時間アイドル状態であり、NAT プロキシまたはファイアウォールによってドロップされる可能性がある場合に使用されます。TCP キープアライブは、setsockopt() 呼び出しによってソケットごとにアクティブ化されます。
再ポーリングの必要性をなくすために「ロング ポーリング」を実行する場合、TCP キープアライブが必要になる場合があります。
キープアライブは単純に TCP ソケットを開いたままにするため、ポーリングするたびに、TCP セットアップ/ティアダウン パケットのオーバーヘッドを節約できますが、それでもポーリングする必要があります。
ただし、「ロング ポーリング」は、Web サーバーがクライアントに通知をブロードキャストするための戦略です。基本的に、クライアントは GET 要求を発行しますが、Web サーバーはすぐに応答するのではなく、送信する通知があるまで待機し、その時点で GET 要求に応答します。これにより、ポーリングの目的でパケットがネットワークを通過する必要がなくなり、接続がステートレスに保たれます。これは、プロトコルの目的の 1 つであると正しく述べています。