SPDY/QUIC/HTTP2 超要約
HTTP1.1 では、持続的接続(Connection: Keep-Alive)により、一つのドメインに配置された複数のコンテンツをダウンロードする場合、一つのTCPコネクションを再利用して次々にHTTPリクエストを送信することができる(HTTPパイプライン)。また、一つのドメインに対して、6つの接続を並行して利用することができる。
- HTTP1.1では、持続的接続によってTCPコネクションを再利用するが、HoL(head-of-line)ブロッキングの問題の影響を受ける。また、HTTP1.1の仕様上の制限*1により、あるHTTPリクエストの処理に時間がかかってしまった場合、その後のHTTPリクエストの処理が終わっているにもかかわらず、先のHTTPリクエストの処理を待つことになる*2。また、並行接続数もサーバのリソース消費の懸念から6に制限されている。
- SPDYでは、HTTP1.1のような改行・空行で区切られるヘッダではなく、バイナリフレーミングのヘッダを導入しており、一つのTCPコネクション上でデータをストリームとして多重化して送受信することができる。つまり、HTTP1.1の仕様に制限されているような、HTTPリクエストの受信順序通りの応答処理は必要ない。TCPコネクション上のストリーム多重数に上限もない。
- HTTP2はSPDYをベースとして策定されている。
SPDYでは、一つのTCPコネクションを共有するため、HoLブロッキングの問題の影響を受ける点はHTTP1.1と変わらない。ストリームはあくまでTCPコネクション上を流れるため、ネットワーク上でTCPパケットが欠損し、あるストリームが届かなかった場合、その後のストリームが届いている可能性があるにも関わらず、アプリケーションにストリームを渡す前に、欠損したパケット(前のストリーム)の再送を待つ必要がある。
コアネットワークは光ケーブルで繋がれており、光より速いものは無いので、これ以上は1パケットのRTT(ラウンドトリップ時間)は速くならない。コアネットワークの帯域を増強しても、これ以上HTTPの速度向上には貢献しないだろう。QUICでは、できるだけRTTを減らすために、キャッシュを用いることで経路暗号化のコネクション確立において0ラウンドトリップを実現する。
QUICについて特筆すべき点。
ネットワークスタック図
Current network stack | After introducing QUIC |
---|---|
SPDY(HTTP2.0) | SPDY(HTTP2.0) |
TLS | QUIC(TLS) |
TCP | UDP |
参考リンク
*1:https://tools.ietf.org/html/rfc7230#section-6.3.2
*2:順序通りに返さないと、HTTP RequestとResponseの対応が取れないため。TCPにあるようなシーケンス番号などが定義されていない。
*3:"CUBIC: A new TCP-friendly high-speed TCP variant"を読んだ - ゆううきブログ
*4:具体例は、802.3 Ethernet PAUSEフレームをμsecレベルでパケット間に挿入してバーストを回避し、スイッチのバッファ溢れを抑制する技術