QUICにおける信頼性のないストリームの提案仕様

QUICはUDPを使用しますが、内部的にストリームという信頼性のある通信単位をもちます。ストリーム上では正しい順序での配送が保証され、パケットロスしたデータも回復されます。

そのようなQUICに対して、信頼性のないストリーム、つまりパケットロスしても回復しないようなストリームの検討を行うInternet-Draftが出ている。また、合わせてその信頼性のないストリームを用いてHTTPボディを送るための仕様も提出されている。

ぞれぞれ下記の通りである

これらによって、HTTPヘッダは確実に届けるが、HTTPボディはロスしても良いというHTTPが実現できるのは面白い点である。

現状の標準化動向としては、QUICの仕様に取り込まれるかは分からないが(個人的には険しいと思う)

面白そうなので簡単に読む

Considerations for Unreliable Streams in QUIC

信頼性のないストリームに関する考慮事項と要件について書かれている。ちなみに、この仕様はQUICのdraft-04を参照している点にも注意である。

  • コネクション確立時に、この仕様に対応していることを示すaccept_unreliable_stream_framesトランスポートパラメータを用いてネゴシーエションする
  • 信頼性のないストリームをオープンする際に'R' (RELIABLE)フラグを立てる
  • ゾンビストリームを防ぐため、ストリームのクローズ(FIN)はロスした場合は再送される
  • 信頼性のないストリームは、輻輳制御およびフロー制御をうける
  • アプリケーションは、任意の再送戦略を取れる(再送しても良い)

Unreliable Transmission Extension for HTTP/2 over QUIC

メディアなどの配信のために、HTTPボディの送信に信頼性のないQUICストリームを利用するための仕様。基本的には上記の「Unreliable Streams in QUIC」の仕組みを用いる。

  • クライアントから「Transport-Response-Reliability: unreliable」ヘッダを用いることで、レスポンスに信頼性のないストリームの利用を要求できる
  • 「Transport-Response-Reliability: unreliable-after DATE」で時間を指定することで、指定時間経過後は再送しないことも要求できる
  • HTTPヘッダに関しては信頼性のあるストリームで送信されるなければならない(draft-ietf-quic-http-04, 05に言及)