QUICプロトコルとは？次世代プロトコルのメリットと使い方を解説

QUIC（クイック／Quick UDP Internet Connection）とは、新しい暗号化トランスポート層ネットワークプロトコルです。QUICプロトコルは、HTTPトラフィックをより安全で効率的、かつ高速にするために設計されました。

理論的には、QUICはTCP接続とTLS暗号化の良いところをすべて取り込んで、UDP上に実装したものです。従来は、通信特性によりTCPまたはUDPを使い分けていましたが、長年使われてきたプロトコルに代わる可能性があるとして注目されています。

しかし、QUICがTCP+TLS+HTTP/2と似ているのであれば、なぜ作る必要があったのでしょうか？

ここからは、QUICプロトコルの特徴やメリットについてより詳細に説明します。

接続の高速化

QUICプロトコルがTCPより優位に立つ理由の主な点は、接続のセットアップがはるかに高速であることです。SSL/TLSによる暗号化がなくても、「3ウェイハンドシェイク」を伴う従来のトランスポートプロトコルを使った接続は、UDPベースのGoogleソリューションよりも多くのステップを要します。QUICは1つのパケット（最初の接続であれば2つのパケット）で接続を開始し、必要なTLSやHTTPSのパラメータもすべて送信します。ほとんどの場合、クライアントは応答を当てにすることなくサーバーに直接データを送ることができますが、TCPはまずサーバーの確認応答を取得し処理する必要があります。

多重化コネクションオプション

TCPは、接続されたシステムのTCPポートとIPアドレスを使用して、接続を識別します。このため、クライアントが1つの接続で複数のポートを使ってサーバーと通信することは不可能です。QUICプロトコルは、この状況を別の方法で解決します。64ビットの接続検出と、接続内のデータ転送にさまざまな「ストリーム」を使用します。したがって、QUIC接続は、必ずしも特定のポート、IPアドレス、特定のエンドポイントに縛られるわけではありません。その結果、ポートおよびIPの変更は、先に説明した多重化コネクションと同様に、実行可能なオプションとなります。

ユニークなシーケンス番号の割り当て

QUIC接続の各データセグメントは、オリジナルセグメントか転送されたセグメントかに関係なく、それ自身のシーケンス番号を受け取ります。デフォルトでは、TCPはこれを行わないため、ホストはシーケンスの状態を判断することができません。タイムスタンプ拡張を使用することによってのみ、古典的なトランスポートプロトコルはこの種の区別を可能にします。パケットを継続的にタグ付けすることは、より正確なラウンドトリップタイム（RTT）の推定が可能になるため、有利になります。

前方誤り訂正

QUICでデータを転送する場合、パケットの紛失は大きな問題ではありません。シンプルなXORベースのエラー訂正システムにより、対応するデータを再送信する必要はありません。また、前方誤り訂正パッケージ（データグループのオリジナルパッケージのバックアップ）を使用して、いつでも構築することができます。ただし、1つのデータグループから複数のパッケージが欠落している場合、エラー訂正は機能しません。

オーバーロード制御（パケットペーシング）

TCPは常に可能な限り高速にデータを送信しようとするため、高速なデータ接続ができるという利点がありますが、一定の損失率も伴います。パケットが失われた場合、再送（TCP Fast Retransmit）が迅速に開始されます。QUICプロトコルは、負荷のピークを「パケットペーシング」によって打ち消します。これにより、伝送速度が自動的に制限されるようになっています。そのため、低帯域の接続でも、過負荷になることはありません。ただし、これは新しい技術ではなく、いくつかのLinuxカーネルもTCPプロトコルにこの方式を採用しています。

認証と暗号化

QUICプロトコルの企画・設計では、当初から安全性が重要視されていました。また、TCPの最大の問題点である、送信パケットのヘッダーがプレーンテキストであるため、事前の認証なしに読み取られてしまうという問題に対する解決策を見つけることも優先されました。その結果、中間者攻撃は珍しくありません。しかし、QUICパッケージは常に認証され、大部分が暗号化されています（ペイロードを含む）。ヘッダーの暗号化されていない部分は、受信側の認証によって、インジェクション攻撃や改ざんから保護されます。

QUICプロトコルのデメリットはほとんどありませんが、あえて挙げるとするならば、QUICプロトコルはまだ試験運用版であるという点です。他のウェブサイトやウェブサーバーに広く採用されているわけでもなく、ファイアウォールなどのサイバーセキュリティツールでもサポートされていません。このため、実験的なQUICプロトコルは現在、セキュリティの抜け穴を開けてしまう可能性があります。

ファイアウォールは、HTTPとHTTPSのトラフィックをWeb保護モジュールに通し、マルウェアのスキャンを実行します。しかし、QUICで接続された場合はどうなるのでしょうか？ブラウザとサポートするウェブサーバーはQUIC接続として認識しますが、閲覧しているデバイスはそうではないかもしれません。QUIC接続は単純なUDPトラフィックとして扱われ、ファイアウォールのWeb保護モジュールに送信されることはありません。

Googleは、2010年代前半にQUICが誕生して以来、その普及を推進してきました。このプロトコルは技術的にはまだ実験的で草案の段階ですが、GoogleはすでにQUIC プロトコルをChromeブラウザで使用しています。Googleのサーバーへの接続は、すべてQUICを介して確立されます。予想通り、Googleの傘下にある企業のサービスはすべてQUICを使用しています。YouTube、Blogger、ハングアウト、これらはすべてQUICベースです。

QUICは、安定した高速接続に依存するビジネスにも採用されています。たとえば、UberはモバイルアプリにQUICプロトコルを採用しています。Uberは、待ち時間の短いデータ転送に依存していますが、QUICはそのようなデータ転送をサポートすることができます。パケットロスを減らすことは、より効率的なアプリを実現することにつながります。

QUICプロトコルは、標準的なTCP/IP接続よりも、選ぶ価値があるのでしょうか？スピードがものを言う世界において、QUICプロトコルは間もなくオンライン上でより大きな存在感を示すようになります。Googleが、「QUICによる検索はTCPによる検索よりも平均して1秒速い」と発表したように、QUICの時代は想像以上に早くやってくるかもしれません。

QUICは多重化方式を採用しており、これがTCPより優れている点です。TCPが1つのエンドツーエンドの接続ポイントを使用するのに対し、QUICは2つのエンドポイント間で複数の接続を確立します。接続の不備や外部からの干渉によって情報の流れの一方が中断された場合でも、複数の接続ポイントによって情報の流れが継続されます。ウェブサイトがTCPを使用していて接続が中断された場合、エンドポイント間の途中のパケットに含まれるデータが残りの情報を保留することになります。このHoLブロッキングは何十年も前から問題になっていましたが、QUICはそれを解決しています。

より広く採用され、ほとんどのファイアウォールで認識されるようになるまでは、QUICをブロックまたは無効にすることが推奨されます。

1. Chromeブラウザを開き、アドレスバーにchrome://flags/と入力する。
2. Experimental QUIC protocolを探し、「Disabled」を選択します。