QUIC meetup に参加してきました(1/25)

QUIC meetup に参加してきました(1/25)

Clock Icon2017.02.20

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

去る1/25に開催されたQUIC meetupに参加してきました。

ずいぶんと時間が経ってしまって申し訳ないのですが、その時の話を書きたいと思います。

ちなみに今回のmeetupは、(場内アナウンス含め)全て英語で行われたため、
自分の英語能力ではほとんどメモが取れませんでした、ということを予め言い訳しておきます…

プレゼンテーションの題目は以下の通りとなります :

  • QUIC - A New Internet Transport
  • h2q

その前に : QUICとは

ひとことで言えば、UDPによる、Webに最適化されたトランスポート(L4)層 です。

Quick UDP Internet Connectionsという名の通り、
軽快・高速なインターネット通信を目指して開発されています。

詳細な解説は後に紹介する記事を参照して頂きたいのですが、
HTTP(含むHTTP/2)が足回り(トランスポート層)に使っているTCPは非常に使いやすく機能も揃っているプロトコルであるものの、
現在のWebに特化していえば少々重すぎる、
それであれば、ほぼ素の状態のUDPに必要な機能だけ盛り込もう、

…というものになります。

QUICの提唱された時期は2013年で、既に提唱元であるGoogleの主要サービスで数年動き続けており、実績ももう十分積まれているとのこと。

HTTP/2も、Google発のSPDYという独自プロトコルから始まって後に標準化されましたから、QUICもその経験を活かしつつ同じ流れに乗っているといえます。

QUIC - A New Internet Transport

ひとつ目のプレゼンテーションは、Jana Iyenger氏によるものです。

  • QUIC with TLS1.3
    • TCP-like congestion control, loss recovery (TCPのような輻輳制御と欠落補完)
    • Multistreaming and per-stream flow control (多重ストリーミング?と、ストリームごとのフローコントロール)
    • Encrypted transport (暗号化トランスポート層?)
    • Low latency connenction establishment (低遅延のコネクション生成)
    • 0-RTT
    • Resilience to NAT-rebinding (NATへの柔軟性)
  • First WG meeting in Nov 2016 (2016年11月に最初のワーキンググループミーティング)
  • Few years to get to complete standard (数年かけて標準化を終了する)
  • Google(のあるサービス?)では既に、大部分のリクエスト/帯域がQUICでやり取りされている
  • Fallback to HTTP/2 (QUIC未対応環境ではHTTP/2にフォールバック = 互換性の確保)

h2q

ふたつ目はMartin Thomson氏によるもので、HTTP/2からQUICへ、という意図のタイトルです。

プレゼンの中で個人的に興味深かったのは、
HTTP/2で導入されたHPACKはQUICでは問題がある、という話でした。

  • header compression problems

HTTP/2のヘッダ圧縮(HPACK)はベースに差分転送が盛り込まれているので、
結果としてTCPのパケット到達順保証に依存していることになります。

QUICではそこを必ずしも保証しないため、転送する前に参照されてしまうなどの問題が発生します。

  • qpack [wip]
    • evolution from hpack

それを解決するための仕様がQPACK。

HTTP/2の仕様の中でもHPACKは個人的にかなりトリッキーに感じていたので、
それがよりシンプルになるのか、さらに複雑になるのか、今後の動きに注目したいです。

QUICの今後

QUICは現在標準化作業が進められている最中なのですが、
実際、これに先立つ1/24から3日間、IETFの会合が東京で行われたとのことでした。

そういうタイミングということで、
登壇してくださったお二人も、標準化に参加されている第一人者ばかりという、非常に贅沢なmeetupとなっておりました。

ちなみに

QUICは実績十分という話を上でしました。サーバはGoogleとして、じゃあクライアントはというと、
実はChromeブラウザ / Chromiumは既にQUICに対応しています。

QUICでの通信をしているかどうかは、上記記事の最後にふれられている機能拡張を使うことで簡単に調べることが出来るので、興味のある方は試してみるのも面白いかもしれません。

参考

書き留められなかった部分にも興味深い話は多かったんですが、
残念ながら今の時点で資料は公開されていないようなので、まとめられた方に感謝しつつTogetterのURLを貼っておきます。

また、QUICについては既に良質な情報がいくつも出回っています。
そのなかからいくつかご紹介します。

弊サイトでも以前虎塚が記事でふれております。HTTP/2からの流れをおさえることで背景が分かりやすくなるかと思いますので、あわせてご紹介します。

次世代Webカンファレンス「HTTP2」レポート #nextwebconf

標準化が進めば、PoCを経て様々な実装が出てくることでしょう。

一方で、UDPに起因するセッションの取り回しの複雑化やDDoS耐性への影響、セキュリティ上の懸念なども心配されています。このあたり、ロードテストを進めているGoogleの知見が気になるところですね。

今後の動きがとても楽しみです。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.