HTTPパイプライニング
From Wikipedia, the free encyclopedia
| HTTP |
|---|
| 主要項目 |
| リクエストメソッド |
| ヘッダーフィールド |
| ステータスコード |
| 認証方式 |
| セキュリティホール |
HTTPパイプライニング（英: HTTP pipelining）は、HTTP/1.1において、持続的接続上で先行するレスポンスの受信完了を待たずに複数のHTTPリクエストを連続して送信する方式である。サーバは、受信したリクエストに対応するレスポンスを、受信順と同じ順序で送信しなければならない。[1][2]
HTTPパイプライニングは、各リクエストごとにレスポンスを待ってから次のリクエストを送る方式に比べて待ち時間を減らせる可能性がある一方、先行するレスポンスが後続のレスポンスを妨げるヘッド・オブ・ライン・ブロッキングの問題や、中継装置との相互運用上の問題を抱えていた。このため広範な環境での実装は難しく、HTTP/2ではより堅牢な多重化方式が採用された。[3][4][5]
HTTP/1.1では持続的接続が既定であり、その上でクライアントは複数のリクエストをパイプライン化できる。RFC 9112では、持続的接続をサポートするクライアントは、各レスポンスを待たずに複数のリクエストを送信してよいとされている。サーバは、それらのリクエストを並列に処理してもよいが、対応するレスポンスは受信順どおりに返送しなければならない。[1]
HTTP/1.1の初期仕様であるRFC 2616では、持続的接続とパイプライニングは通信効率を高める仕組みとして位置づけられていた。持続的接続によってTCP接続の確立回数を減らし、パイプライニングによって複数の資源取得時の待ち時間の削減を図る設計であった。[6]
歴史
動作
HTTPパイプライニングは、持続的接続上で複数のリクエストを連続送信することにより動作する。たとえば、クライアントは最初のレスポンスを待たずに2件目、3件目のリクエストを送信できる。ただし、サーバが返すレスポンスの順序はリクエストの受信順に一致していなければならない。[1]
RFC 9112は、クライアントが接続障害後に失敗した要求を再試行できるよう考慮すべきであるとしている。そのため、クライアントは冪等でないメソッドの直後にパイプライニングを行うべきではなく、非冪等なリクエストの結果を再現なく失う危険がある場合は、最終レスポンスを待つ必要がある。HTTPの意味論を定めるRFC 9110では、冪等なメソッドとしてPUT、DELETE、および安全なリクエストメソッドが挙げられている。[8][1]
また、RFC 9112では、接続が失敗した直後に再度同じ接続方針でただちにパイプライニングすることは認めていない。これは、失敗の原因がパイプライニング自体にある可能性を考慮したものである。[1]
利点
問題点
HTTPパイプライニングでは、サーバがレスポンスを受信順どおりに返す必要があるため、先行するリクエストの処理や転送が遅いと、後続のレスポンスが待たされる。この性質は、HTTP/1.1接続上でのヘッド・オブ・ライン・ブロッキングの要因となる。RFC 9112でも、時間のかかるリクエストや大きな内容の転送が後続要求を妨げる場合があるとしている。[1][3]
さらに、現実のネットワーク環境では、古いソフトウェアや中継装置との共存により実装が難しかった。MDN Web Docsでも、HTTPパイプライニングは既存のネットワークにおいて実装が難しいことが実証されたと説明されている。[5]
HTTP/1.0時代の持続的接続との互換性も問題となった。RFC 2616は、HTTP/1.0の持続的接続との互換性に関する節を設け、古いプロキシとの相互運用上の問題を説明している。[10]