HTTP/1.1 パイプライン化 FAQ
通常、HTTP リクエストは、次のリクエストは完全に受け取られた現在のリクエストに対するレスポンスのあとにだけ発行されるという形で、連続して発行されます。ネットワークの待ち時間と帯域幅の制限により、次のリクエストがサーバによって受け取られるまでに、著しい遅れを生じさせることもあります。
HTTP/1.1 では、複数 HTTP リクエストを対応するレスポンスを待つことなくソケットに同時に書き出すことを許しています。リクエスト発行者は、リクエストされた順序での到着のためのレスポンスを待っています。リクエストの「パイプライン化」の作用でページ読み込み時に劇的に改善をみせることもあります。高い待ち時間をともなう接続においては特にそうです。
パイプライン化はまた、TCP/IP パケットの数を劇的に減少させることもあります。536 ～ 1460 バイトの典型的な MSS (最大セグメントサイズ) で、1 つの TCP/IP パケットにいくつかの HTTP リクエストが可能です。少ないパケットは通常、IP ルータとネットワークの負荷を減らすため、読み込みに必要なパケットの数を減らすことは、全体としてはインターネットに利益になります。
HTTP/1.1 に合致するサーバはパイプライン化のサポートが必要とされています。これはサーバにパイプライン化したレスポンスが必要とされることを意味するわけではありません。しかし、クライアントがパイプライン化したリクエストを選択した時に失敗してはいけないことを要求します。著名な Mozilla 以外のブラウザがパイプライン化を実装していないため、これは明らかにエバンジェリズム (啓蒙) に関する新しいカテゴリのバグとなる可能性があります。
GET や HEAD といったリクエストのように独立したリクエストだけが、パイプライン化可能です。POST と PUT といったリクエストはパイプライン化すべきではありません。新しいコネクションの上でもまた、パイプライン化したリクエストをすべきではありません。なぜなら、相手のサーバ (もしくはプロキシ) が HTTP/1.1 をサポートしているかどうかまだわからないからです。そのために、パイプライン化は存在する「keep-alive」接続の再利用時のみ可能です。
うーん。多くのリクエストのパイプライン化は、もし早い時点でコネクションが切断された場合コストが高くつきます。新しいコネクションの上でだけ繰り返せばいいのに、ネットワークへリクエストを書き出す時間を浪費するからです。そのうえ、最初のリクエストが完了するのに長い時間がかかると、長いパイプライン化は実際にユーザに知覚されてしまうほどの遅れを引き起こします。サーバあたり、2 つの「keep-alive」接続を超えないという制限を勧めます。明らかに、それはアプリケーションに依存します。Web ブラウザはたぶん、前述の理由のためにあまりに長いパイプライン化は望まないでしょう。2 というのは適切な値でしょう。しかし、この数値にはまだ試行により変えられる余地があります。
もし、リクエストがキャンセルされたとき、パイプライン全体がキャンセルされるのでしょうか？ それとも、パイプラインに属する他のリクエストを繰り返すことを強いてはいけないので、キャンセルされたリクエストだけがただ単に捨てられるべきなのでしょうか？ 答えは、受け取られていないままキャンセルされたリクエストに対するレスポンスの破片のサイズを含むいくつかの要素に依存します。実直なアプローチでは、ただパイプラインをキャンセルし、すべてのリクエストを再発行するというのもあるでしょう。これは、リクエストが一度の発行で何度も利用できるときだけできることです。パイプライン化さているリクエストは大抵、キャンセルされている同じ読み込みのグループ (ページ) に属するので、この実直なアプローチはよく筋が通っています。
もし、コネクションが失敗するか、サーバによってパイプライン化されたレスポンスのダウンロードの一部へ放り込まれた時、Web ブラウザは失ったリクエストの再開始の能力がなくてはなりません。この場合、単純にも、上述の取り消された場合と等価にハンドリンクされているでしょう。