読者です 読者をやめる 読者になる 読者になる

Webinar

Web関連情報のウェブセミナー

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を構築するネットワーク機器は、セキュリティ上の要求から、トランスポート層プロトコルとして、基本的にTCPUDPしか通しません。

だからGoogleUDPをベースにしたのです。しかし、TCPの「信頼性を担保する機能」だったり、「輻輳制御する機能」だったりは捨てたくありません。

要は、QUICはUDPTCPのいいとこどりをしています。さらに徐々に当たり前になりつつある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と同じような流れで今後標準化されるプロトコルのベースになるのだと思います。もうこの辺は規定路線かと思います。

私の興味は、今と比べてどれくらいの高速化効果があるのか、どのくらいのペースで普及するのか、です。

高速化効果などは機を見て検証し、また記事にて公開してみたいと思います。