Edit

Page

Page title:

Page body:

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

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

* 仕様書

[REFS[
- [9] '''[CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) <https://tools.ietf.org/html/rfc7230#section-6.3.2>'''
- [21] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) <https://tools.ietf.org/html/rfc7230#section-6.6>
]REFS]

* 構文

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

* 文脈

[11] [[クライアント]]は、[[持続的接続]]に対応していれば、
[[要求]]を[[パイプライン]]化することができます。すなわち、
[[要求]]に対する[[応答]]を待たずに次の[[要求]]を送信できます。 [SRC[>>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つの[[接続][HTTP接続]]で1組の[[要求]]と[[応答]]しかやり取りできず、
[[パイプライン]]化はできません。

-*-*-

[28] [[安全なメソッド]]によるアクセスが多数続く場合 (例えば [[HTML文書]]から参照されている[[資源]]が多数ある場合) には有用かもしれません。
[[非安全]]や非[[冪等]]な[[メソッド]] (例えば [CODE(HTTP)@en[[[POST]]]]) 
の[[パイプライン]]化は、失敗時の再試行処理を考えると、避けた方が良いかもしれません。

[29] [CODE(HTTP)@en[[[CONNECT]]]] や [CODE(HTTP)@en[[[Upgrade:]]]] も、
[[応答]]を待って次の送信を行うべきで、[[パイプライン]]化するべきではなさそうです。

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

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

;; [19] [[TCPリセット問題]]参照。

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

* 処理

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

* 再試行

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

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

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

;; [CODE(HTTP)@en[[[Connection: close]]]] も参照。

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

* 歴史

- [1] ''HTTP/1.1 パイプライン化 FAQ'' <http://www2.starcat.ne.jp/~unha/projects/netlib/http/pipelining-faq.html>
- [2] ''WWWDに関連したうんちく'' <http://www.koizuka.jp/wwwd/memo.html#19990410_2>
- [3] ''ApacheのHTTP/1.1パイプライン制御のサポートについて'' <http://mm.apache.or.jp/pipermail/apache-tech/2001-April/thread.html#148>
- [4] ''Network Performance Effects of HTTP/1.1, CSS1, and PNG'' < http://www.w3.org/TR/NOTE-pipelining>
- [5] ''Esehttpd: ESE HTTP Server'' <http://ghost.math.sci.hokudai.ac.jp/esehttpd/>
- [6] ''株式会社オープンループ'' <http://www.openloop.co.jp/press/release/011031.html> パイプラインを使って [[WinIE]] を高速化させるらしい。
- [7] [[Mozilla]] 1.3 のパイプラインにはまだ不具合があるのか、 [[HTTP]] [[頭]]が見えたりごみ (多分前後の資源) が混ざったりすることがありますね。 (設定画面にもまだ不安定だよん☆て書いてあるし。)

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

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

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

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

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

]INS]
]FIG]

* 関連

[22] [[持続的接続]]、[[TCPリセット問題]]も参照してください。

[23] [CITE@en[RFC 6202 - Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP]]
( ([TIME[2014-07-20 07:14:03 +09:00]] 版))
<http://tools.ietf.org/html/rfc6202#section-5.2>

[24] [CITE[Issue 8991 - chromium - Optional HTTP pipelining mode - An open-source project to help move the web forward. - Google Project Hosting]]
([TIME[2015-03-22 00:59:38 +09:00]] 版)
<https://code.google.com/p/chromium/issues/detail?id=8991>

[31] [CITE[HTTP Pipelining - The Chromium Projects]]
([TIME[2015-08-03 23:16:58 +09:00]] 版)
<https://www.chromium.org/developers/design-documents/network-stack/http-pipelining>

[FIG(quote)[
[FIGCAPTION[
[32] [CITE[HTTP Pipelining - The Chromium Projects]]
([TIME[2015-08-03 23:16:58 +09:00]] 版)
<https://www.chromium.org/developers/design-documents/network-stack/http-pipelining>
]FIGCAPTION]

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

]FIG]

[33] [CITE@ja[Guy Podjarny「HTTP Pipeliningはwebを速くも遅くもしない」 - 以下斜め読んだ内容]]
([TIME[2015-08-04 00:17:46 +09:00]] 版)
<http://vwxyz.hateblo.jp/entry/20130118/1358488156>

[34] [CITE@ja[HTTP Pipelining FAQ | MDN]]
([TIME[2014-03-27 20:03:38 +09:00]] 版)
<https://developer.mozilla.org/ja/docs/HTTP_Pipelining_FAQ>

[35] [CITE@en[264354 – Enable HTTP pipelining by default]]
([TIME[2015-08-04 00:25:07 +09:00]] 版)
<https://bugzilla.mozilla.org/show_bug.cgi?id=264354>

[36] [CITE[Issue 10105002: Enable HTTP pipelining field trial on dev channel for 10% of users. - Code Review]]
([TIME[2015-08-04 00:25:34 +09:00]] 版)
<https://chromiumcodereview.appspot.com/10105002>

[37] [CITE@en[Security/Reviews/Firefox9/ReviewNotes/HTTPPipelines - MozillaWiki]]
([TIME[2015-08-03 19:23:31 +09:00]] 版)
<https://wiki.mozilla.org/Security/Reviews/Firefox9/ReviewNotes/HTTPPipelines>

[38] [CITE[Issue 364557 - chromium - Remove pipelining code from Chrome - An open-source project to help move the web forward. - Google Project Hosting]]
([TIME[2015-08-04 00:26:10 +09:00]] 版)
<https://code.google.com/p/chromium/issues/detail?id=364557>

[39] [CITE@en[HTTP pipelining - Wikipedia, the free encyclopedia]]
([TIME[2015-07-25 19:24:18 +09:00]] 版)
<https://en.wikipedia.org/wiki/HTTP_pipelining>

[41] [[nginx]] に [CODE(HTTP)@en[GET]] 要求を連続して2つ送信すると、
最初の1つは認識しますが、2つ目は無視されます。
1つ目の[[応答]]が得られてから2つ目を送信すれば、2つ目も無視はされません。
[TIME[2016-09-09T07:24:34.000Z]]

[43] [CITE[Example of Result of HTTP/1.1 Pipelining]]
([TIME[1998-01-26 10:56:18 +09:00]])
<https://www.w3.org/Protocols/HTTP/Performance/PipeExamples.html>

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Errors

Page name(s)