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

[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つの接続HTTP接続で1組の要求と応答しかやり取りできず、パイプライン化はできません。

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

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

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

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

[19]

TCPリセット問題参照。

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

再試行

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

[17]

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

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

Connection: close も参照。

[18] 中間器は、応答を受信するより前に内向きの接続が失敗した (最後の完全な応答で明示的に閉じられなかった) 時には、まだ応答を受信していない要求がすべて冪等なメソッドなら、再試行しても構いません。そうでない場合には、受信した応答があれば転送した上で、外向きの接続を閉じるべきです。 >>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 頭が見えたりごみ (多分前後の資源) が混ざったりすることがありますね。 (設定画面にもまだ不安定だよん☆て書いてあるし。)

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

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

仕様書

構文

文脈

処理

再試行

歴史

関連