HTTP プロトコルは TCP プロトコルに基づいています。ブラウザはサーバーから Web ページのデータを取得する必要がある場合、HTTP リクエストを発行します。 Http は、TCP 経由でサーバーへの接続チャネルを確立します。このリクエストに必要なデータが完了すると、HTTP はすぐに TCP 接続を切断します

TCP プロトコルは FIN パケットを送信することで接続を解放するため、FIN パケットはエンドマーク、つまり接続が切断されるまで受信されることを意味します。

でも

時間が経つにつれて、HTML ページはより複雑になり、多くの画像が埋め込まれている可能性があります。このとき、画像にアクセスするたびに TCP 接続を確立するのは非効率です。そこで、効率が悪いという問題を解決するためにキープアライブが提案されました。 HTTP/1.1 以降、接続機能を維持するためにキープアライブがデフォルトで有効になり、Web ページが開かれた場合、クライアントとサーバー間の HTTP データの送信に使用される TCP 接続は閉じられません。クライアント このサーバー上の Web ページに再度アクセスすると、この確立された接続が継続して使用されます。キープアライブには保持時間があり、別のサーバー ソフトウェア (Apache など) で設定できます。ここでTCPコネクションは一定期間維持されますが、この時間は限られており、その時点ではまだクローズされるため、各コネクションが完了するたびにクローズするものともみなします。

それでは、キープアライブをオンにした後の終了をどのように判断するのでしょうか?
実際、HTTP ヘッダーには、HTTP パケット本体の長さである content-length があります

もちろん、コンテンツ長がない場合、つまり、データが一連のブロックに分割されて送信され、各ブロックにサイズの記述がある場合もあります。サーバーがヘッダーの生成時にエンティティ全体のサイズを認識していない場合でも (通常はエンティティが動的に生成されるため)、チャンク エンコーディングを使用して既知のサイズの多数のチャンクを送信できます。

エンコーディングは複数のチャンクを使用し、長さ 0 でマークされたチャンクで終わります。各チャンクは 2 つの部分で構成され、最初の部分はチャンクの長さと長さの単位 (通常は記述されません) であり、2 番目の部分は内容、各部分は CRLF (フルネーム キャリッジ
リターン/ライン フィード キャリッジ リターン/ライン フィード) で区切られます。長さ 0 の最後のチャンクの内容はフッターと呼ばれ、追加のヘッダー情報です (通常は直接無視できます)。

さらに、HTTP メッセージ ヘッダーとメッセージ本文は CRLF (キャリッジ リターンとライン フィード) で区切られており、rnrn