HTTP 持続接続

HTTP持続接続( HTTP キープアライブ、 HTTP 接続の再利用とも呼ばれる) は、単一のTCP接続を使用して複数のHTTP 要求/応答を送受信するであり、要求/応答のペアごとに新しい接続を開く必要はありません。新しいHTTP/2プロトコルは同じ考え方を採用し、さらに進化させて、単一の接続で複数の同時要求/応答を多重化できるようにしています。

HTTP 1.0では、レスポンスの送信後、サーバーは常に接続を閉じる必要があります。 ^[1]

少なくとも1995年後半から、^[2] HTTP/1.0を使用する一般的な製品（ブラウザ、ウェブサーバーなど）の開発者は、複数のリクエスト/レスポンスで接続を再利用できるようにするために、「keep-alive」という非公式の拡張機能（プロトコルへの）を追加し始めました。^{[3] [4]}

クライアントがキープアライブをサポートしている場合は、リクエストに追加のヘッダーが追加されます。

接続: キープアライブ

サーバーがこの要求を受信して​​応答を生成するとき、サーバーがキープアライブをサポートしている場合は、応答に上記と同じヘッダーも追加します。その後、接続は切断されず、開いたままになります。クライアントが別の要求を送信すると、同じ接続が使用されます。

これは、クライアントまたはサーバーが会話が終了したと判断するまで継続され、この場合、"Connection:"最後に送信されたメッセージのヘッダーが省略されるか、またはより良い方法として、キーワード「close」が追加されます。

接続: 閉じる

その後、指定されたルールに従って接続が閉じられます。

1997年以来、HTTP/1.1仕様のさまざまなバージョンでは、この非公式な拡張機能の使用が認められ、HTTP/1.0（キープアライブ）とHTTP/1.1クライアント/サーバー間の相互運用性に関するいくつかの注意事項が含まれていました。^[5]

HTTP 1.1 では、特に宣言しない限り、すべての接続は永続的であると見なされます。^[5] HTTP の永続的接続では、個別のキープアライブ メッセージは使用されず、複数のリクエストが 1 つの接続を使用することが許可されます。ただし、Apache httpd 1.3 および 2.0 のデフォルトの接続タイムアウトは 15 秒と短く^{[6] [7]}、Apache httpd 2.2 以上では 5 秒です。^{[8] [9]} タイムアウトが短いことの利点は、Web ページの複数のコンポーネントをすばやく配信できる一方で、複数のサーバー プロセスまたはスレッドを長時間実行してリソースを消費しないことです。^[10]

キープアライブは、特にパイプライン化されたHTTP操作中に、クライアントが1つの応答が終了し、次の応答が始まる場所を判断することを困難にします。^[11]Content-Lengthこれは、ストリーミングのために使用できない場合に深刻な問題になります。 ^[12]この問題を解決するために、HTTP 1.1では、ビットを定義するチャンク転送コーディングlast-chunkが導入されました。^[13]このlast-chunkビットは各応答の最後に設定され、クライアントが次の応答がどこから始まるかを知ることができます。

• 後続のリクエストのレイテンシが短縮されます(ハンドシェイクやスロースタートはありません)。
• 新しい接続とTLS ハンドシェイクが減ったため、 CPU使用率とラウンドトリップが削減されました。
• リクエストとレスポンスのHTTP パイプラインを有効にします。
• ネットワーク輻輳の軽減（TCP 接続数の減少）。
• TCP 接続を閉じるというペナルティなしにエラーを報告できます。

RFC 7230 のセクション 6.4 によると、「クライアントは、特定のサーバーに対して同時に開く接続の数を制限する必要があります」。以前のバージョンの HTTP/1.1 仕様では、特定の最大値が規定されていましたが、RFC 7230 では、「これは多くのアプリケーションでは非現実的であることが判明しました...代わりに...複数の接続を開く場合は慎重にしてください」とされています。これらのガイドラインは、HTTP 応答時間を改善し、輻輳を回避することを目的としています。HTTP パイプラインが正しく実装されている場合、追加の接続から得られるパフォーマンス上の利点はありませんが、追加の接続は輻輳の問題を引き起こす可能性があります。^[14]

必要なデータをすべて受信してもクライアントが接続を閉じない場合、サーバー上で接続を開いたままにするために必要なリソースは他のクライアントが使用できなくなります。これがサーバーの可用性にどの程度影響するか、およびリソースが使用できない時間は、サーバーのアーキテクチャと構成によって異なります。

また、サーバーがTCP接続を閉じるのと同時にクライアントがサーバーにリクエストを送信すると、競合状態が発生することもあります。 ^[15]サーバーは、接続を閉じる直前にクライアントに408 Request Timeoutステータスコードを送信する必要があります。クライアントがリクエストを送信した後に408ステータスコードを受信すると、サーバーへの新しい接続を開き、リクエストを再送信することができます。^{[16]すべてのクライアントがリクエストを再送信するわけではなく、リクエストに}べき等HTTPメソッドがある場合にのみ再送信するクライアントが多くいます。

Google Chrome、Firefox、Internet Explorer（4.01以降）、Opera（4.0以降）^[17]、Safariなどの最新のウェブブラウザはすべて永続的な接続を使用しています。

デフォルトでは、Internet Explorerバージョン6と7は2つの持続接続を使用し、バージョン8は6つの持続接続を使用します。^[18]持続接続は、60秒間操作がないとタイムアウトしますが、これはWindowsレジストリで変更できます。^[19]

Firefoxでは、同時接続数をカスタマイズできます（サーバーごと、プロキシごと、合計）。持続的な接続は、115秒（1.92分）の非アクティブ後にタイムアウトしますが、これは設定で変更できます。^[20]

Pythonのrequestsライブラリにはrequests.Session()、永続的なHTTP接続を確立するが含まれています。これにより、基礎となるTCP接続を再利用することができ、パフォーマンスが大幅に向上します。^[21]

• HTTPパイプラインにより、応答を待たずに複数のリクエストを送信できます。
• HTTP/2は、リクエストとレスポンスの順序外パイプライン化と、リクエストされる前のコンテンツの予測プッシュを可能にします。

• ハイパーテキスト転送プロトコル (HTTP/1.1): メッセージ構文とルーティング、接続管理、永続性
• 一般的なブラウザの持続接続動作（日付付き）
• Apache HTTPD キープアライブ サポート
• HTTP/1.1、CSS1、PNG のネットワーク パフォーマンスへの影響