Edited at
http2Day 11

QUICを使ったWebサーバを立ててみたい(導入編)

More than 1 year has passed since last update.

これは、http2 Advent Calendar 2016の11日目の記事です。前日は @flano_yuki さんの投稿分でした。

導入編ということで、今回はHTTP/2とQUICについての簡単な概要でも書くことにします。


はじめの前のおまけ

これは是非入れておきましょう。


はじめに

昨年、HTTP/2が正式に文書化され、Web界隈では大きな話題となりました。

早くもChromeでは従来のSPDYを使った通信はすっかり封印され、

現在はHTTP/2またはQUICを使った通信がサポートされています。

そこで、HTTP/2とQUICについて、一旦おさらいしてみたいと思います。


HTTP/2

元々はSPDY(スピーディ)という名前で、Googleを中心としたワーキンググループによって開発されていた、

従来のレガシーなHTTP通信を向上させるための新しい通信プロトコルです。

簡単に言えば、実に16年以上前に規格の作られた古くて遅いHTTPを、完全な後方互換性を保ったまま

現代っぽく改善しようとする試みの結果です。

ストリームの多重化やフロー制御などの概念を取り入れつつも、従来の規格を完全に包括するよう作られているため、

エンジニアサイドとしては導入のハードルがかなり低い規格となっているはずです。

強いて言えば、規格上ではなく実装上の問題としてTLSの導入が必須であるため、必然的にHTTPS化が必要である点は重要です。

こちらこちらなどをご参照いただければ、より詳しく書かれているかと思います。


HTTP/2の限界とQUIC開発の意味

さて、上記で説明したように、HTTP/2では非常にシームレスな環境移行ができ、確実にWebの高速化を見込めます。

しかしながら、高速化という観点において、HTTP/2には致命的な欠点が存在します。

それは、TCPの上に成り立っているということです。

TCP/UDPはOSI参照モデルにおける第4層(トランスポート層)のプロトコルです。

知らんって人はググってください。

ものすごくざっくり説明すると


  • TCPは遅いが、データのエラーチェック等を含み、データ到達の信頼性を重視したプロトコル

  • UDPは速いが、データを100%の精度で届けることは保障されていないプロトコル

一般的に、メールやWeb閲覧においてはデータが確実に到達することが重視されます。Webページの内容が確実に届かないと、文字化けしてしまったり、あるいは予期せぬ動作を呼び込むことになるからです。

それにもかかわらずQUICはUDP上で実装されています(????)

どういうことなのかみてみましょう。


QUICの立ち位置

QUICは、HTTP/2の高速化における限界を超える目的で開発されています。Wikipediaを引用すると


TCPの改善はGoogleにとって長期的な目標であり、QUICの目的は独立したTCP接続と同等に近づけることだが、できるだけレイテンシを削減し(目標はラウンドトリップタイム無しの一般的な接続)とSPDY対応の推進で、もしQUICの機能が効果的に実証されたらTCPとTLSの後継バージョンに移行することができる。

QUIC開発の動機の1つが、TCPにおけるシングルパケットの遅延がSPDYストリームの集合体全体でヘッド・オブ・ライン・ブロッキングを引き起こす事実であり、QUICでは多重化に対応することでストリームを1つだけ一時停止することができる。


図で説明すると以下のようなかんじです。

tcp_udp_quic_http2_compared.png

(引用元: https://ma.ttias.be/googles-quic-protocol-moving-web-tcp-udp/)

つまり、QUICは厳密に言えばHTTP/2と同等のレイヤに位置するのではなく、UDP通信のもと、HTTP/2 APIによって渡されたリクエストをQUIC独自の規格でリクエストの処理、暗号化、エラーチェック等まで行いながら通信しているのです。

文字通り、従来の互換性を犠牲にしつつWebのさらなる高速化を計った新しいプロトコルであると言えます。

QUICはまだ実験段階である故、日本語のドキュメントもあまり充実しておらず、実装した例も多くはありません。

実際、QUICをサポートしているWebサーバは非常に少なく、GWS(Google独自のWebサーバ)やCaddyくらいしか私は知りません。他にあれば教えてください!

ただし、QUICに対応しているリバースプロキシとしては、Dockerイメージはあったりします。

しかしながら、nginx、Apache、h2oなどのメジャーなブラウザは軒並み非対応の状態です。

次回の投稿(カレンダーの最後の方だと思います)では、Caddyをつかって実際にQUIC通信を行うサーバを立ててみるところまでやってみたいと思います。