聞いたことはないかもしれないが、あなたがChromeユーザーなら既にGoogleのQUICプロトコルを使っている可能性は高い。先週Googleが公表したところによると、ChromeからGoogleサーバーに送られるリクエストの約半数には、QUICが使われている。
いったいその何が重要なのか？ QUICはGoogleによるUDPレベルの実験的低遅延インターネットプロトコルであり、UDPはゲーム、ストリーミングメディア、およびVoIPサービスでよく使われるプロトコロルだ。’QUIC’ という名前は Quick UDP Internet Connectionから来ている。
プロトコルの世界でUDP（およびQUIC）と比較されるのはTCPだ（Internet Protocol［IP］との組み合わせでインターネットの核となる通信言語となっている）。UDPはTCPより著しく軽量だが、その代わりにTCPよりもサポートしているエラー訂正サービスが少ない。これは送信サーバーが、例えばデータが届いているか、正しい順番で届いているかを調べるために、受信サーバーと頻繁にやり取りしていないことを意味する。UDPがゲームサービスに最適である理由はそこにある。この種のサービスではオーバーヘッドを減らして遅延を最小にすることが望まれており、もし最新のマウス動作をサーバーが受け取っていなければ、1～2秒を費して訂正する必要はない ― なぜならアクションはもう先へ進んでいるから。しかし、ウェブサイトのリクエストには向いていない、なぜなら全データが届いたことを保証できないからだ。
QUICにおけるGoogleの狙いは、UDPとTCPの良いところを取り、最新のセキュリティー技術と組み合わせることだ。
通常のセキュアなTCP接続では、ブラウザーが実際にデータを受信し始めるまでに、2～3回やりとりが行われるのが普通だ。QUICを使うと、ブラウザーは過去にやりとりしたサーバーとは直ちに通信を開始することができる。さらにQUICは、輻輳（ふくそう）制御や自動再送信等の新機能を導入することによって純粋なUDPよりも信頼性を高めている。
Googleは、後にHTTP/2標準の基礎となったSPDYという、QUICKと同様の目的を持つ代替プロトコルを既に開発しているが、HTTP/2はTCP上で動作しているため同じ遅延問題を抱えている。
それならなぜGoogleは、TCPの改善に取り組まないかと疑問に思うのは当然だ。問題は、同社の指摘によると、TCPサポートはしばしばオペレーティングシステムに直接組み込まれていることにある ― そしてOSはGoogleの制御が一切及ばない部分である。「QUICなら新しいアイデアを実験してすぐに結果を見ることができる」とチームはこの方式を採用した理由を書いている。「効果が証明された暁には、QUICの機能がTCPとTLSに移行されることを望んでいる」。未だにインストールされているWindows XPの数を踏まえると、それは一夜にして起こることでないことは明らかだ。
もしGoogleが全く新しいプロトコルを設計すれば、インターネットの根幹を支える全マシンもそれを理解しなければならない ― しかし彼らが既に理解しているのはUDPだ。
Googleによると、QUICはGoogle検索において、平均ページ読み込み時間で約3%の改善を見せている。大したことがないように聞こえるが、Google検索が既に最適化できるだけ最適化されていることを忘れてはならない。他のサイト ― 特に遅延の大きいウェブアプリ ― ではもっと大きな改善が見込める。YouTubeをQUIC経由で接続したユーザーは、ヒデオ視聴中に再バッファリングが約30%少なくなったという報告がある他、QUICの改善された輻輳制御およびUDPのロスリカバリーによって、非常に遅い接続のユーザーでも、QUICによるページ読み込み時間の改善が見られている。
Googleは、HTTP2-over-QUICを、将来の新たなインターネット標準としてIETFに提案する計画だと話している。
これは様々な意味でGoogleのSPDYへの取り組みと類似している。同社はあの時もまずChromeと自社サービス上でプロトコルのプロトタイピングを行い、その後HTTPの新バージョンの基盤として提案した。
なお、自分のChromeがQUICを使って接続しているかどうかを知るには、このブラウザー機能拡張をインストールすればよい。
[原文へ]
（翻訳：Nob Takahashi / facebook）