読者です 読者をやめる 読者になる 読者になる

けいぞうのメモ帳

言語設計のお勉強

QUIC追っかけ日記01

QUIC QUIC追っかけ日記

QUICについて

Googleが主導しているHTTP+TLS+TCPに変わる新たなプロトコル
アップグレードされたHTTPにたいしてそのTLS+TCPの部分を効率よく通信するために策定されている。 まだインターネットドラフト段階で、

https://tools.ietf.org/html/draft-ietf-quic-transport-00 がJune 1, 2017まで議論される様子。
このrevisionから更新を追いかけていきつつQUICについて記述する。

公開して、意図を訂正してもらう目的が大きいため、なんらかの参照にするのは望ましくない。

改善点

よく取り上げられる順番で書いていく。

Head of Line blocking (HOL blocking)

Head-of-line blocking - Wikipedia

Head of Line Blocking - High Performance Web 2015 - Qiita

HTTP/1.X or TCPの通信は並列化されていないため、複数のストリームを一つのコネクションを用いて流す場合、
直列に送信するため先行するストリームが重かったり、輻輳が発生したりすると、送信時間や再送時間分だけ後続のストリームが 到達する時間が遅くなる。

HTTP1.1のRFCの邦訳

https://triple-underscore.github.io/RFC7230-ja.html#section-6.4

によると、

複数接続は、概して, “head-of-line blocking” 問題 — [ サーバ側に重い処理を要したり, 巨大なペイロードを持つ ]ような要請が、同じ接続上の後続の要請を阻むこと — を避けるために利用される。 しかしながら、接続のそれぞれは,サーバリソースを消費する。 更には、複数の接続が利用された場合,混雑したネットワークに,望ましくない副作用をもたらし得る。

とあるため、HTTP1.1においてもTCPのコネクションを複数接続させることでHead of Line Blockingを避ける場合もある。 ただし、そういった場合にはTCPのコネクションを複数もつリソースだけ余分なリソースが消費される。増やしすぎるとTCPのコネクションのリソース消費と並列化による高速化が釣り合わなくなるため、 TCPのコネクションをむやみに増やせばいいというものではない。例えば、chromeは6本の固定値である。

HTTP/2そしてQUICにおいては一つのコネクション上でストリームが並列に送信され、輻輳制御もストリームごとに行われるため、Head of Line Blockingがそれぞれのレイヤで発生しなくなる。 HTTP/2 over QUICを用いれば、上記の理由によるHead of Line Blockingは発生しなくなる。

TLS + TCP

TCPでスリーウェイハンドシェイク、TLSでセッション鍵交換を行ってから、HTTP/2 over TLS over TCPの通信が行われる。
これを冗長とし0RTT つまり要求してすぐに通信が始まるようにQUICは設計される予定だ。 ID 0のストリームでコネクション要求とTLS接続に用いる情報、clientのQUIC versionをサーバに渡し、サーバのQUIC versionの比較とデータの送受信を始める。

QUIC Wire Layout Specification - Google ドキュメント

FEC

前方誤り訂正を用いて、一割程度の損失があった場合でも回復できるようにしていたらしい。

QUICはXORベースのFECをやめるらしい - あすのかぜ

QUIC FEC v1 - Google ドキュメント

chrome-devとyoutubeを用いた検証では芳しくない結果が出たためFECの仕様を改めて決める。