これは、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つだけ一時停止することができる。
図で説明すると以下のようなかんじです。
(引用元: 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通信を行うサーバを立ててみるところまでやってみたいと思います。