pipilining

パイプライン (HTTP)

[10] 複数の要求を、それぞれの応答の到着を待たずに次々に送信することを、 パイプライン (pipeline) 化といいます。

[40] HTTP/1.1 で10年以上にわたり実装が試みられてきましたが、互換性の問題から失敗に終わりました。 HTTP/2 ではパイプライン化にかわりストリームによる多重化が導入されています。

仕様書

構文

[30] 持続的接続に関するもの以外に特別な構文的要素はありません。

文脈

[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] CONNECTUpgrade: も、 応答を待って次の送信を行うべきで、パイプライン化するべきではなさそうです。

[13] 利用者エージェントは、冪等でないメソッドの後、 それに対する最終的な応答状態符号を受信するまでは、 (何らかの方法でパイプラインの途中の要求の部分的な失敗を検出して回復できる場合を除き、) パイプライン化するべきではありません>>9

[16] クライアントは、接続が失敗した (最後の完全応答で明示的に閉じられなかった) 後に再試行する時には、 接続を確立した直後にパイプライン化してはなりません>>9

[14] 中間器は、パイプライン化された要求を受信した場合、 これを内向き転送する際にパイプライン化して構いません。 >>9

処理

[12] は、パイプライン化された要求がすべて安全なメソッドなら、 各要求を並列化して処理することができますが、応答要求を受信した順序で送信しなければなりません>>9

再試行

[15] クライアントは、すべての要求に対応する応答を受信する前に接続が閉じられた時には、 応答のない要求を再試行するべきです>>9

[17] 冪等メソッドではなくても再試行して良さそうな感じですが、 本当に良いのでしょうか。

[20] クライアントは、パイプライン化して要求を送信していた途中で close 接続オプションのある応答を受信した場合、 それ以降の要求が処理されたと仮定するべきではありません >>21

Connection: close も参照。

[18] 中間器は、応答を受信するより前に内向き接続が失敗した (最後の完全応答で明示的に閉じられなかった) 時には、 まだ応答を受信していない要求がすべて冪等メソッドなら、 再試行しても構いません。そうでない場合には、受信した応答があれば転送した上で、 外向き接続を閉じるべきです>>9

歴史

[8] RFC 2068・2616 (HTTP/1.1) 8.1.2.2 Pipelining

A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received.

持続接続に対応するクライアントは、その要求を「パイプライン化」しても (つまり、複数の要求を、それぞれの応答を待たずに送っても) 構いません。 サーバーは、その要求群に対する応答を、要求を受信した順序と同じ順で送らなければなりません

Clients which assume persistent connections and pipeline immediately after connection establishment SHOULD be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it MUST NOT pipeline before it knows the connection is persistent. Clients MUST also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.

接続を確立したすぐ後に持続接続とパイプライン化を仮定するクライアントは、 最初のパイプライン化の試行が失敗した時にその接続を再試行する準備をするべきです。 クライアントがこの再試行をするなら、接続が持続であると知る前にパイプライン化してはなりません。 クライアントは、サーバーが対応する応答のすべてを送る前に接続を閉じたらその要求を再送信する準備もしなければなりません

Clients SHOULD NOT pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see section 9.1.2). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to send a non-idempotent request SHOULD wait to send that request until it has received the response status for the previous request.

クライアントは、冪等でないメソッドや、 冪等でないメソッドの列を使った要求油送管化するべきではありません油送管化してしまうと、 輸送接続早期終端した時に不定な結果を招くこととなり得ます。 冪等でない要求を送ろうとするクライアントは、 以前の要求に対する応答状態受信するまでその要求送信を待つべきです。

関連

[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>

[32] HTTP Pipelining - The Chromium Projects ( 版) <https://www.chromium.org/developers/design-documents/network-stack/http-pipelining>

The option to enable pipelining has been removed from Chrome, as there are known crashing bugs and known front-of-queue blocking issues. There are also a large number of servers and middleboxes that behave badly and inconsistently when pipelining is enabled. Until these are resolved, it's recommended nobody uses pipelining. Doing so currently requires a custom build of Chromium.

[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] nginxGET 要求を連続して2つ送信すると、 最初の1つは認識しますが、2つ目は無視されます。 1つ目の応答が得られてから2つ目を送信すれば、2つ目も無視はされません。

[43] Example of Result of HTTP/1.1 Pipelining () <https://www.w3.org/Protocols/HTTP/Performance/PipeExamples.html>