SPDY/QUIC/HTTP2 超要約

  • ハイパフォーマンスブラウザネットワーキング読了 - RAMEN is the best food.

  • 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パケットが欠損し、あるストリームが届かなかった場合、その後のストリームが届いている可能性があるにも関わらず、アプリケーションにストリームを渡す前に、欠損したパケット（前のストリーム）の再送を待つ必要がある。

  • QUICでは、TCPコネクションを用いず、UDPストリームを並列化することにより、本当の意味で並列化を実現する。

  • コアネットワークは光ケーブルで繋がれており、光より速いものは無いので、これ以上は1パケットのRTT（ラウンドトリップ時間）は速くならない。コアネットワークの帯域を増強しても、これ以上HTTPの速度向上には貢献しないだろう。QUICでは、できるだけRTTを減らすために、キャッシュを用いることで経路暗号化のコネクション確立において0ラウンドトリップを実現する。

  • QUICについて特筆すべき点。

    • HoLブロッキングを排除した本当の意味の並列化
    • TCP Fast Openのようなキャッシュによるラウンドトリップ時間削減
    • XORを運ぶFECパケットによる誤り訂正で再送パケット削減
    • TCP-Cubic*3やペーシング*4を含む輻輳制御アルゴリズムを複数実装
    • 5-tuple(Src IP, Src Port, Dest IP, Dest Port, Protocol)から独立したコネクションIDによりMobile-to-WiFiなどの網間のハンドオーバを実現
    • 既存のネットワークスタックを利用することで、実世界へのより早い展開（SCTPはそうはいかない）

  • ネットワークスタック図

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レベルでパケット間に挿入してバーストを回避し、スイッチのバッファ溢れを抑制する技術