TCP上でQUICを喋る『QUIC on Streams』について復習しておく

QUIC internet-draft

TCP(+TLS)上でQUICおよびHTTP/3の通信を行うことを可能にする『QUIC on Streams』という仕様がFastlyのOku Kazuho氏らによって提案されている。

今年3月に行われたのIETF119で提案されている。

仕様は、TCP/TLS上でQUIC通信を行う『QUIC on Streams』と、それを使ってHTTP/3通信を行う『HTTP/3 on Streams』に分かれている。

今週IETF120があるので、キャッチアップしておく。

モチベーション

この提案の背景にあるのは、WebTransportといったHTTP上で動作する新しいプロトコルを設計する際に HTTP/3版とHTTP/2版の両方を設計・メンテナンスを行っているところにあります。


(引用: IETF119スライドPDFより)

なぜ新しいプロトコルでもHTTP/2版を設計するかと言うと、QUICのフォールバック先が必要だからです。

QUICはUDPで動作しており、一部のネットワークでは（そのネットワーク管理者が意図してか、意図せずか）QUICが通らないネットワークがあることが知られています。そのためHTTP/3は、疎通できないケースにおいては、TCPを使うHTTP/2にフォールバックするということが行われています。そのため、WebTransportのような新しいプロトコルも、フォールバック先としてHTTP/2版プロトコルを設計する必要があります。

もちろんHTTP/2とHTTP/3ではストリームやフレームの機能に違いがあるため、それぞれそれなりの仕様になっています。WebTransportのそれぞれの仕様は次の通り。

そこで、QUICそのものをTCP/TLS上で動作させることで、複数スタック用にプロトコル設計しなくても良くなります。それが、『QUIC on Streams』のモチベーションになります。


(引用: IETF119スライドPDFより)

『QUIC on Streams』の仕組み

『QUIC on Streams』はTLS over TCPのようなトランスポート上でQUICのフレームを送受信する仕組みを定義します。

下層のトランスポート

TLS over TCPが想定されていますが、使用上はそれだけに限定されているわけではなく、次の機能をもつトランスポートを想定しています。

  • 双方向のバイトストリーム通信
  • 信頼性 (再送などによる、データの配送保証)
  • 輻輳制御
  • 気密性と完全性
ストリームの送受信

『QUIC on Streams』では、トランスポート上で直接ストリームが送受信されます。QUICパケットヘッダは存在しません。

なお、送受信できるのは次のフレームに限定されます。

  • PADDING
  • RESET_STREAM
  • STOP_SENDING
  • STREAM
  • MAX_DATA
  • MAX_STREAM_DATA
  • MAX_STREAMS
  • DATA_BLOCKED
  • STREAM_DATA_BLOCKED
  • STREAMS_BLOCKED
  • CONNECTION_CLOSE

再送制御は下層トランスポートで行われるため、ACKフレームは送受信できません。また、コネクションマイグレーションも『QUIC on Streams』ではサポートされません。

一方で、次のフレームが追加で定義されています

  • QS_TRANSPORT_PARAMETERS: トランスポートパラメータを交換するフレーム
  • QS_PING: PINGの送受信
『QUIC on Streams』のその他
  • 一部トランスポートパラメータは使用禁止
  • 既存の拡張仕様がQUIC on Streams上で使えるかは、明示的に許可される必要がある
    • ただし、DATAGRAMは送信可能（下層のトランスポート特性により、信頼性が保証される）
  • QUICのバージョンネゴシエーションの仕組みはない

(UDP利用に起因するリフレクションがないとすれば、通信開始時のPADDINGの制約って緩和出来るんだろうか...?)

HTTP/3 on Streams

『HTTP/3 on Streams』の仕様は非常に短いです。