[10] 複数の要求を、それぞれの応答の到着を待たずに次々に送信することを、 パイプライン化といいます。
[40] HTTP/1.1 で10年以上にわたり実装が試みられてきましたが、互換性の問題から失敗に終わりました。 HTTP/2 ではパイプライン化にかわりストリームによる多重化が導入されています。
[11] クライアントは、持続的接続に対応していれば、 要求をパイプライン化することができます。すなわち、 要求に対する応答を待たずに次の要求を送信できます。 >>9
[25] HTTPパイプラインは、普通は HTTP/1.1 の機能と考えられています。
[26] HTTP/1.0 keep-alive でもパイプラインは実現できるはずで、 実際に使っていることもあるかもしれません。主に HTTP/1.1 について言及されるのは、 HTTP/1.1 が普及してきてからパイプライン化が実用化されてきたからでしょうか。
[27] HTTP/2 ではストリームによる多重化でパイプライン化 (よりも高度な順序制御) が基本機能として行われるようになっています。 HTTP/1 的意味なパイプラインは存在せず、本項の内容は HTTP/2 とは無関係です。
[42] HTTP/0.9 は1つの接続で1組の要求と応答しかやり取りできず、 パイプライン化はできません。
[28] 安全なメソッドによるアクセスが多数続く場合 (例えば HTML文書から参照されている資源が多数ある場合) には有用かもしれません。
非安全や非冪等なメソッド (例えば POST
)
のパイプライン化は、失敗時の再試行処理を考えると、避けた方が良いかもしれません。
[29] CONNECT
や Upgrade:
も、
応答を待って次の送信を行うべきで、パイプライン化するべきではなさそうです。
[13] 利用者エージェントは、冪等でないメソッドの後、 それに対する最終的な応答の状態符号を受信するまでは、 (何らかの方法でパイプラインの途中の要求の部分的な失敗を検出して回復できる場合を除き、) パイプライン化するべきではありません。 >>9
[16] クライアントは、接続が失敗した (最後の完全な応答で明示的に閉じられなかった) 後に再試行する時には、 接続を確立した直後にパイプライン化してはなりません。 >>9
[14] 中間器は、パイプライン化された要求を受信した場合、 これを内向きに転送する際にパイプライン化して構いません。 >>9
[12] 鯖は、パイプライン化された要求がすべて安全なメソッドなら、 各要求を並列化して処理することができますが、応答は要求を受信した順序で送信しなければなりません。 >>9
[15] クライアントは、すべての要求に対応する応答を受信する前に接続が閉じられた時には、 応答のない要求を再試行するべきです。 >>9
[20] クライアントは、パイプライン化して要求を送信していた途中で
close
接続オプションのある応答を受信した場合、
それ以降の要求が処理されたと仮定するべきではありません
>>21。
Connection: close
も参照。[18] 中間器は、応答を受信するより前に内向きの接続が失敗した (最後の完全な応答で明示的に閉じられなかった) 時には、 まだ応答を受信していない要求がすべて冪等なメソッドなら、 再試行しても構いません。そうでない場合には、受信した応答があれば転送した上で、 外向きの接続を閉じるべきです。 >>9
[22] 持続的接続、TCPリセット問題も参照してください。
[23] RFC 6202 - Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP ( ( 版)) <http://tools.ietf.org/html/rfc6202#section-5.2>
[24] Issue 8991 - chromium - Optional HTTP pipelining mode - An open-source project to help move the web forward. - Google Project Hosting ( 版) <https://code.google.com/p/chromium/issues/detail?id=8991>
[31] HTTP Pipelining - The Chromium Projects ( 版) <https://www.chromium.org/developers/design-documents/network-stack/http-pipelining>
[33] Guy Podjarny「HTTP Pipeliningはwebを速くも遅くもしない」 - 以下斜め読んだ内容 ( 版) <http://vwxyz.hateblo.jp/entry/20130118/1358488156>
[34] HTTP Pipelining FAQ | MDN ( 版) <https://developer.mozilla.org/ja/docs/HTTP_Pipelining_FAQ>
[35] 264354 – Enable HTTP pipelining by default ( 版) <https://bugzilla.mozilla.org/show_bug.cgi?id=264354>
[36] Issue 10105002: Enable HTTP pipelining field trial on dev channel for 10% of users. - Code Review ( 版) <https://chromiumcodereview.appspot.com/10105002>
[37] Security/Reviews/Firefox9/ReviewNotes/HTTPPipelines - MozillaWiki ( 版) <https://wiki.mozilla.org/Security/Reviews/Firefox9/ReviewNotes/HTTPPipelines>
[38] Issue 364557 - chromium - Remove pipelining code from Chrome - An open-source project to help move the web forward. - Google Project Hosting ( 版) <https://code.google.com/p/chromium/issues/detail?id=364557>
[39] HTTP pipelining - Wikipedia, the free encyclopedia ( 版) <https://en.wikipedia.org/wiki/HTTP_pipelining>
[41] nginx に GET
要求を連続して2つ送信すると、
最初の1つは認識しますが、2つ目は無視されます。
1つ目の応答が得られてから2つ目を送信すれば、2つ目も無視はされません。
[43] Example of Result of HTTP/1.1 Pipelining () <https://www.w3.org/Protocols/HTTP/Performance/PipeExamples.html>