GoogleのQUICの論文が知見の塊だった

雑 QUIC

20181107追記 QUICプロトコルについての概要は別途記事を書きました
asnokaze.hatenablog.com

概要

ACM SIGCOMM 2017という通信系の学会に、Googleの人 総勢21人によって書かれた「The QUIC Transport Protocol: Design and Internet-Scale Deployment」という論文が提出され、学会ホームページより閲覧出来る。

この論文は、QUICの設計仕様と実際にGoogleのサービスにデプロイした結果について書かれている。

すでにGoogler SearchやYoutubeでQUICは有効になっており、一日あたり数十億の接続を処理し、Googleのegress trafficのうち30%がQUICになっており、インターネットのトラフィックの内7%がQUICだと推定されるという説明から論文は始まる。

QUICはGoogle Searchのレイテンシをデスクトップユーザでは8%, モバイルユーザでは3%削減しており。Youtubeのリバッファリングをデスクトップで18%、モバイルで15%削減したようである。

QUICの設計、機能の説明とデプロイ結果からパフォーマンスについて詳細に書かれている。

特に7章の知見については面白かったので簡単に読んだことをまとめた。

雑であしからず

全体構成

  • 1.INTRODUCTION
  • 2.MOTIVATION: WHY QUIC?
  • 3.QUIC DESIGN AND IMPLEMENTATION
  • 4.EXPERIMENTATION FRAMEWORK
  • 5.INTERNET-SCALE DEPLOYMENT
  • 6.QUIC PERFORMANCE
  • 7.EXPERIMENTS AND EXPERIENCES
  • 8.RELATED WORK

個人的に面白いと思ったのは、3章、6章、7章である。

3.QUIC DESIGN AND IMPLEMENTATION

3章の「QUIC DESIGN AND IMPLEMENTATION」はQUICの基本的な機能とその仕組について書かれている。

  • Connection Establishment
  • Stream Multiplexing
  • Authentication and Encryption
  • Loss Recovery
  • Flow Control
  • Congestion Control
  • NAT Rebinding and Connection Migration
  • QUIC Discovery for HTTPS

6.QUIC PERFORMANCE

6章の「QUIC PERFORMANCE」が、今回のメインであるパフォーマンス測定に関する章である。
TLS/TCPとQUICのハンドシェイク遅延の比較、Google Search及びYoutubeのレイテンシの比較、South Korea・USA・India地域ごとの性能比較、サーバ側のCPU使用率の話

7.EXPERIMENTS AND EXPERIENCES

7章の「EXPERIMENTS AND EXPERIENCES」は直接QUICと関係ないが実験より得られた知見が書かれている。
個人的には非常に面白かったので、幾つかピックアップ。FECについては、以前書いたので割愛。

asnokaze.hatenablog.com

Packet Size Considerations

プロジェクトの初期に、UDPパケットの最大サイズを決定するための調査が行われていました。
2014年にネットワーク上のエコーサーバに向けて、UDPペイロードを1200バイトから1500バイトまで5バイトおきに接続性のテストを行っていたようです。

f:id:ASnoKaze:20170813015054p:plain
(引用: 7.1節 図12)

接続の失敗は、1450バイト後に急増しておりQUICでは1350バイトが選択された。

UDP Blockage and Throttling

UDPの疎通性に関して、2016年にビデオ再生に関するメトリックスで

  • 95.3% が問題なく使用できた
  • 4%が、UDPがブロックされるか経路のMTUが小さすぎて使用できなかった。これは企業内のファイアウォールケースが多いようです。
  • 残りの0.3はUDPのトラフィックが制限されており、トラフィックが高い場合はパケット損失率が大幅に上がるようです。ASレベルの制限は減少傾向にあるようです。
User-space Development

QUICはユーザスペースで処理されます。このメリットについて書かれています。

ユーザランドで開発することで、カーネルでは制限されているような機能でもロギングが可能で様々なバグの発見に役立ったようです。

Cubicをユーザランドで再実装することによってLinuxにあった古くからあったcubicの実装にバグを見つけたのはニュースにもなりました。
news.mynavi.jp

また、カーネルに組み込むよりもユーザに早く更新を届ける事が出来た旨も書かれています。これはセキュリティプロトコルにとっては非常に重要なことです。

Experiences with Middleboxes

ファイアウォールといった中間装置の振る舞いについて

QUICでは殆どのデータを暗号化していますが、一部は暗号化されていません。2016年10月にその暗号化されてない部分の1bitの変更を加えたところ、一部のファイアウォールが混乱し最初のパケットのみを疎通させその後はブロックするような振る舞いをするようになりました。その場合、TCPに正常にフォールバックされません。

フラグ部分をもとに戻すことで対応するとともに、ファイアウォールベンダーを特定し連絡を取りフラグの分類について更新することで問題は解決されたようです。

その時はベンダーを特定し対応できたが、インターネット上で特定のビットがファイアウォールにどのように影響するか答えることはできません。

これはファイアウォールの影響を避けるために殆どの領域を暗号化するQUICの設計の前提を強めた形になります。