GoogleがQUICへの本格的な取り組みを発表 -QUICが生まれた背景-
Googleは、「Make the Web Faster」という名を付けられた取り組みによって、常にWeb高速化に向けた取り組みを続けています。
今回は、そのWeb高速化の取り組みのひとつであるQUICについて紹介します。
QUIC（Quick UDP Internet Connections）
QUICは、SPDYやHTTP/2と同様、Webアクセスの高速化を目的としたプロトコルです。
プロトコルスタックとしては、Web用のプロトコルにも関わらず、TCPを使っていません。
どうなっているのかというと、UDP上にTCP相当の信頼性や輻輳制御の機能を持った層が乗っかっていて、さらにその上にTLS相当の暗号化層が乗っかっています。その上に最上位のアプリケーション層としてHTTP 1.1やHTTP/2が乗ります。
TCPには、Webの高速化にあたり以下のような課題があり、プロトコル仕様上、越えられない壁になっています。
- Long Fat Pipe：前のパケットのACKが返ってくるまで次のパケットを送信できない。
- Head of Line Blocking：先頭パケットがロスしたら、後続パケットは先頭パケットの再送を待ってから処理される。
- Slow Start：スループットは徐々にしか上がらない。
今までは、HTTP層が高速化のボトルネックになっていたので、TCPのボトルネックが目立っていなかったのですが、SPDYがある程度普及し、HTTP/2が検討されるようになり、トランスポート層で高速化の限界が見えてきていました。そこでTCPの代替としてのプロトコルがGoogle内で検討されるようになりました。
ただ、全く新しいトランスポート層プロトコルを作るのは、理想的ではありますが現実的ではありません。何故ならば、すでにWebはできているからです。Webを構築するネットワーク機器は、セキュリティ上の要求から、トランスポート層のプロトコルとして、基本的にTCPかUDPしか通しません。
だからGoogleはUDPをベースにしたのです。しかし、TCPの「信頼性を担保する機能」だったり、「輻輳制御する機能」だったりは捨てたくありません。
要は、QUICはUDPとTCPのいいとこどりをしています。さらに徐々に当たり前になりつつあるTLSを使ってEnd to Endの暗号化も実施しています。
ちなみに仕様は公開されており、詳細を確認したい方はこちらの記事を入り口にQUICの森の中に入ってみてください。英語です。
Chromium Blog: Experimenting with QUIC
Googleのスタンス
さて、上記のような背景から生まれ、Googleによって開発/検証されてきたQUICですが、2015年4月17日にChromium Blogにて今後の取り組み計画が発表されました。
Chromium Blog: A QUIC update on Google’s experimental transport
発表内容は大きく2点です。
今でも既にそうですが、気づかないうちにQUICを使っているという状況が増えそうです。 Googleがここまで本格的な取り組みを実施しているということで、SPDYと同じように様々なステークスホルダを巻き込んで普及していくのだと思います。また、SPDYと同じような流れで今後標準化されるプロトコルのベースになるのだと思います。もうこの辺は規定路線かと思います。
私の興味は、今と比べてどれくらいの高速化効果があるのか、どのくらいのペースで普及するのか、です。
高速化効果などは機を見て検証し、また記事にて公開してみたいと思います。
