進化するインターネット技術／IETFトピックス2016-17

第3回

TCP＋TLSに代わる高速プロトコル、Google生まれの「QUIC」の特徴と標準化の行方

  • 前田 薫

2017年5月26日 06:00

インターネット技術の普及に向け、IPv6、DNS、HTTPなど基本となるプロトコルを定めてきたIETF（The Internet Engineering Task Force）。今年11月には、100回目の会合（IETF 100）がシンガポールにて開催される予定である。IETFがこれまで手がけてきたインターネット技術も、技術の進歩と普及により、現在も多くの分野において議論が継続され、まだまだ目が離せない状況が続いている。本連載では、インターネットの普及と発展を目的に日ごろIETFを中心に活動を行っているISOC-JP（Internet Society Japan chapter）メンバー有志が、ここ最近のIETFでの活動状況について紹介していく。

　今回は、「QUIC」の標準化動向について、2016年の大まかな流れと今後の予定を紹介する。

　QUICは、Googleが開発しているトランスポートプロトコルだ。「HTTP/2」の仕様は、Googleの「SPDY」プロトコルをベースにスタートし、IETFでの標準化プロセスを経て現在のかたちに変貌を遂げた。同様に、QUICもIETFに提案されたことで、標準版としてのQUICを目指して仕様検討が始まり、2016年にWGが作成された。QUICを構成するパーツのいくつかはIETFの標準で置き換えられ、また、新しいアイデアも盛り込まれて議論が続けられている。QUICワーキンググループ（WG）はトランスポート（TSV）エリアのWGだが、その扱う内容にはTLS、HTTP/2の見識も求められるため、参加者はセキュリティエリア（SEC）、アプリケーション／リアルタイムエリア（ART）にまたがっている。

「QUIC」プロトコルの概要

　HTTP/2ではHTTPリクエスト／レスポンスの並列化によって、より効率の良い転送を実現した。HTTP/2の目標の1つは、あるリクエスト処理に時間がかかって他のリクエストが待たされる現象「ヘッド・オブ・ライン・ブロッキング（以下、HoLブロッキング）」を最小化することであり、これはおおむね達成された。

　一方で、HTTP/2はTCP上で転送されるプロトコルであることに起因して、大きく2つの問題を残した。1つは接続確立ハンドシェイクに多くのラウンドトリップが必要になること、もう1つはパケットロスからのリカバリーのために複数のリクエストが待たされることだ。QUICはこれらの点を改善し、接続確立までのラウンドトリップ、リクエスト間のHoLブロッキングを最小化する。

　QUICはUDPを利用し、ユーザーランド上にTCP同様の信頼性のあるトランスポートを構築する。TCPの長い歴史の中で培われた輻輳制御、ロスリカバリー制御の仕組みを採用し、現在のインターネット状況に合った制御を行う。ユーザーランド上で動作することにより、比較的長いOSカーネルのリリーススケジュールを待つことなく、新しいバージョンを展開できることもメリットだ。

　QUICの概要を以下の図に示す。

「QUIC A New Internet Transport / Presenter: Jana Iyengar」（PDF）より

　左側がHTTP/2 over TLS/TCP、右側がHTTP/2 over QUICである。QUICは、TCPの機能に相当する輻輳制御、ロスリカバリー、およびHTTP/2の機能の一部であるストリーム制御、フロー制御などを提供する。暗号方式のネゴシエーションや鍵交換にはTLS 1.3の仕組みを使う。

　QUICの特徴は以下の通り。

  • TLS同様のセキュリティ機能
  • 接続確立の高速化。TCP Fast OpenとTLS Snapstart相当の仕組みを持ち、また、0-RTTを実現
  • パケットロス検出のシグナリングを改善。単調増加なパケット番号による再送曖昧性の排除、256までのACKブロックなど
  • パケットロスを防ぐためのペーシング
  • コネクションIDの導入により、特にモバイルクライアントの再接続ロスを低減

IETFでの標準化動向

　QUICは次世代のトランスポートとしてIETFに提案され、WGが設立された。2016年11月のIETF 97（ソウル）において、最初の会合が持たれ、約300名が参加している。会議場は人であふれ、立見も出たほどで、関心の高さが分かる。この会合では、コアとなる4文書をWG文書として採用することが決定されるにとどまり、技術的な検討は次に説明するInterimが最初の議論の場となった。

　2017年1月に東京にて「QUIC Interim」が開催された。原型となったQUICプロトコルの開発者であるGoogleのほか、Facebook、Microsoft、Appleといったハイパージャイアント、ブラウザー開発者（Mozilla）、CDN各社（Akamai、Cloudflare、Fastly）、ネットワーク機器メーカー（F5）、ISP（IIJ、NTT、Orange、AT&T）も参加した。トランスポート、HTTP、TLSの分野ごとに、技術的な課題について検討し、GitHubのissue機能を使って整理した（quicwg/base-drafts）。

　GoogleのプロプライエタリプロトコルであるQUICから、IETFプロトコルとしてのQUICへの変更にあたり、以下の点が大きな設計方針となっている。

  • バージョンアップ可能性。Google版QUIC、検討中のQUIC version 1のあとに登場する将来バージョンとインターネット上で共存できるように、また、将来のバージョンアップができるように考える。特に、パケット中継を行うルーターなどのミドルボックスが、QUICの現行仕様をハードウェアに固定化し、将来の拡張パケットを通さなくなってしまう事態（硬直化：ossification）を防止するための方策もあわせて検討する
  • プライバシー尊重。同一のコネクションIDを別の通信経路で出すと、インターネット上の第三者による追跡が可能になってしまうというプライバシー上の問題がある。プライバシーの解決は議論の前提となっている。対策案がさまざま出されているが「何もしない案」は考えない
  • 暗号レイヤーとしてTLS 1.3を活用。Google版ではQUIC Cryptoが使われていた。また、コネクションのさまざまなパラメーターは、Google版QUICでは独自のデータフォーマットで渡されていたが、IETF版ではTLSの拡張として定義される。鍵交換や証明書とともにネゴシエーションが行われる
  • network byte-order。Google版QUICは、それを扱うすべてのプラットフォームがlittle-endianであるため、数値はすべてlittle-endianになっている。IETF版ではbig-endianとする

「QUIC」の今後

　ここでは、具体的なパケット形式やロスリカバリーの仕組み、ハンドシェイク、HTTP/2とのマッピングなどは紹介するスペースがない。これらの技術的な課題は、日々メーリングリスト上で議論され、次々に新しいアイデアが反映されている。上記のGitHub issuesにすべてまとめられるはずなので、そこを見ながら、興味があればメーリングリスト上の議論も追うのがよいかと思う。

　QUICの議論では、トランスポート技術（ロスリカバリー、輻輳制御）、暗号通信技術（クリプトハンドシェイク、鍵スケジューリング）、HTTP技術（ヘッダー圧縮、プライオリティ）など、その守備範囲が広く、ひとりで全体について詳細に理解するのは大変だ。自分の興味のある部分を中心に、少しずつ回りの技術を見ていくのがよいだろう。

　QUIC WGでは、2018年中にQUICベースプロトコルおよびHTTP/2へのマッピングをRFCにするというマイルストーンで動いており、2017年後半には開発者実装によるinteropなども行われるだろう。議論が早すぎて追いついていけない部分はあるが、2017年は技術的に面白い部分がたくさん検討されると思うので楽しみだ。