メインコンテンツまでスキップ

8. Connections (接続)

8.1 Persistent Connections (持続的接続)​

8.1.1 Purpose (目的)​

持続的接続の前は、各URLを取得するために個別のTCP接続を確立する必要があり、これによりHTTPサーバーの負荷が増加し、インターネットの輻輳が発生しました。インライン画像やその他の関連データの使用により、クライアントは通常、短期間に同じサーバーに複数のリクエストを行う必要があります。これらのパフォーマンス問題の分析とプロトタイプ実装の結果は入手可能です [26] [30]。実際のHTTP/1.1 (RFC 2068) 実装の実装経験と測定により、良好な結果が示されています [39]。T/TCP [27]などの代替案も検討されています。

持続的HTTP接続には多くの利点があります：

  • より少ないTCP接続を開閉することで、ルーターとホスト（クライアント、サーバー、プロキシ、ゲートウェイ、トンネル、またはキャッシュ）でCPU時間を節約でき、ホストでTCPプロトコル制御ブロック用のメモリを節約できます。

  • HTTPリクエストとレスポンスは接続上でパイプライン処理 (pipelining) できます。パイプライン処理により、クライアントは各レスポンスを待たずに複数のリクエストを発行でき、単一のTCP接続をより効率的に使用でき、経過時間が大幅に短縮されます。

  • TCP開放によって引き起こされるパケット数を減らし、TCPがネットワークの輻輳状態を判断するのに十分な時間を与えることで、ネットワークの輻輳が軽減されます。

  • 後続のリクエストの遅延が減少します。なぜなら、TCPの接続開放ハンドシェイクに時間を費やす必要がないためです。

  • HTTPはより優雅に進化できます。なぜなら、TCP接続を閉じるペナルティを負うことなくエラーを報告できるためです。将来のバージョンのHTTPを使用するクライアントは、新しい機能を楽観的に試すことができますが、古いサーバーと通信している場合は、エラーを報告した後に古いセマンティクスで再試行できます。

HTTP実装は持続的接続を実装すべき (SHOULD) です。

8.1.2 Overall Operation (全体的な操作)​

HTTP/1.1と以前のバージョンのHTTPとの主な違いの1つは、持続的接続が任意のHTTP接続のデフォルト動作であることです。つまり、別途指定されない限り、クライアントは、サーバーからのエラーレスポンスの後であっても、サーバーが持続的接続を維持すると想定すべき (SHOULD) です。

持続的接続は、HTTP/1.0およびHTTP/1.1アプリケーションが接続のクローズを示すメカニズムを提供します。このシグナルは、Connectionヘッダフィールド（第14.10節）を介して提供されます。"close"接続オプションが送信または受信されると、その接続は「持続的」とみなされてはなりません (MUST NOT)。

HTTP/1.1アプリケーションは、HTTP/1.0クライアントとの持続的接続を確立してはなりません (MUST NOT)。

8.1.3 Proxy Servers (プロキシサーバー)​

特に重要なのは、第14.10節で説明されているように、プロキシがConnectionヘッダフィールドのプロパティを正しく実装することです。

プロキシサーバーは、クライアントと上流サーバーに対して、持続的接続を個別にシグナル通知しなければなりません (MUST)。各持続的接続は、1つのトランスポートリンクにのみ適用されます。

8.1.4 Practical Considerations (実用的な考慮事項)​

サーバーは通常、非アクティブな接続を維持しなくなる何らかのタイムアウト値を持っています。プロキシサーバーは、クライアントがすでに既存の接続上で接続を確立している可能性があるため、このタイムアウト値を高く設定する場合があります。持続的接続の使用は、サーバーが無期限に接続を維持することを要求するものではありません。実際には、サーバーはいつでも接続を閉じることができます (MAY) が、優雅に行うべき (SHOULD) です。

クライアント、サーバー、およびプロキシは、非同期クローズイベントから回復できなければなりません (MUST)。クライアントソフトウェアは、リクエストシーケンスがべき等である限り（第9.1.2節を参照）、ユーザーの介入なしにトランスポート接続を再開し、中止されたリクエストシーケンスを再送信すべき (SHOULD) です。非べき等メソッドまたはシーケンスは自動的に再試行してはなりません (MUST NOT) が、ユーザーエージェントは、ユーザーがリクエストを手動で再試行する手段を提供できます (MAY)。

サーバーは、接続を閉じる前に、常に少なくとも1つのリクエストに応答すべき (SHOULD) です。サーバーは、ネットワークまたはクライアントの障害が疑われる場合を除き、レスポンスの転送中に接続を閉じるべきではありません (SHOULD NOT)。

持続的接続を送信したいクライアントは、リクエストを「パイプライン化」できます (MAY)（つまり、各レスポンスの到着を待たずに複数のリクエストを送信します）。サーバーは、対応するリクエストを受信した順序でレスポンスを送信しなければなりません (MUST)。

8.2 Message Transmission Requirements (メッセージ転送要件)​

8.2.1 Persistent Connections and Flow Control (持続的接続とフロー制御)​

HTTP/1.1サーバーは、可能であれば、自身のために持続的接続を維持すべき (SHOULD) です。ただし、持続的接続を維持する場合、特定のTCP接続について、その接続を少なくとも1つのリクエスト-レスポンスシーケンスに使用すべき (SHOULD) です。

8.2.2 Monitoring Connections for Error Status Messages (エラーステータスメッセージの接続監視)​

HTTP/1.1（またはそれ以降）クライアントがリクエストを送信するとき（特に認証に重要なリクエスト、または安全でないメソッドを持つリクエスト）、クライアントがリクエストメッセージの送信を完了する前にトランスポート接続が閉じられるかリセットされた場合、リクエストを再送信しなければなりません (MUST)。

8.2.3 Use of the 100 (Continue) Status (100 (Continue) ステータスの使用)​

100 (Continue) ステータス（第10.1.1節を参照）の目的は、リクエストメッセージボディを送信するクライアントが、クライアントがリクエストボディを送信する前に、オリジンサーバーがリクエストを受け入れる意思があるかどうか（リクエストヘッダに基づいて）を判断できるようにすることです。サーバーがボディを読み取らずにメッセージを拒否する場合、クライアントがボディを送信することは不適切または非効率的な場合があります。

リクエストメッセージボディを含むHTTP/1.1（またはそれ以降）クライアントの要件：

  • クライアントが合理的な時間内に100 (Continue) レスポンスを待つ場合、クライアントは、"100-continue"期待値を含むExpectリクエストヘッダフィールド（第14.20節）を送信しなければなりません (MUST)。

  • クライアントは、HTTP/1.0（またはそれ以前）サーバーに "100-continue" 期待値を持つExpectリクエストヘッダフィールドを送信してはなりません (MUST NOT)。

  • 100 (Continue) 期待を送信したが100 (Continue) ステータスを受信しなかったクライアントは、不確定な期間待機すべき (SHOULD) です。クライアントは、その後タイムアウトしてリクエスト（そのメッセージボディとともに）を送信するか、接続を閉じることができます (MAY)。

HTTP/1.1（またはそれ以降）クライアントからリクエストを受信するHTTP/1.1（またはそれ以降）オリジンサーバーの要件：

  • "100-continue"期待値を含むExpectリクエストヘッダフィールドを含むリクエストを受信した後、オリジンサーバーは、リクエストメッセージボディを読み取って処理する予定の場合は100 (Continue) ステータスで応答しなければならず (MUST)、または最終ステータスコードで応答しなければなりません。オリジンサーバーは、100 (Continue) レスポンスを送信する前にリクエストボディを待ってはなりません (MUST NOT)。最終ステータスコードで応答する場合、トランスポート接続を閉じることができる (MAY) か、リクエストの残りを読み取って破棄し続けることができます (MAY)。リクエストを拒否する予定の場合、リクエストのメソッドを実行してはなりません (MUST NOT)。

  • オリジンサーバーは、HTTP/1.1（またはそれ以降）クライアントからリクエストヘッダを受信した直後に100 (Continue) で応答すべき (SHOULD) です。ただし、リクエストに "100-continue" を含まない期待値を含むExpectリクエストヘッダフィールドが含まれている場合を除きます。

8.2.4 Client Behavior if Server Prematurely Closes Connection (サーバーが接続を早期に閉じた場合のクライアント動作)​

HTTP/1.1クライアントがレスポンスを受信する前にHTTPリクエストを送信し、サーバーがその接続でこれ以上リクエストを受信したくないことを示すレスポンスを受信した場合、クライアントは、シーケンス内のすべてのリクエストがべき等であることを確認できる限り（第9.1.2節を参照）、リクエストを再送信すべき (SHOULD) です。

非べき等メソッドまたはシーケンスは自動的に再送信してはなりません (MUST NOT) が、ユーザーエージェントは、ユーザーがこのシーケンスを手動で再試行する手段を提供できます (MAY)。リクエストを自動的に再送信する前に、以前のリクエストシーケンスがすべて完了できなかった場合、クライアントは現在の状態と期待される状態との差異を確認すべき (SHOULD) です。

に最終更新