現在の状況

QUIC ワーキンググループは2016年後半からプロトコルの策定のために活発に活動し、現在(2020年6月)はリリースのための最終段階に近づいています。

2018年の11月現在では、いまだ HTTP/3 の大規模な相互運用テストは実施されていません。2つの実装が存在し、いずれについても、ブラウザや主要なサーバーソフトウェアにも実装が行われていません。

2019年から2020年にかけて HTTP/3 の相互運用性テストの数は増え、CDNとブラウザは、しばしばオプションのフラグが必要ですが、初期サポートを開始し始めてました。

QUIC ワーキンググループの wiki ページには多くの QUIC 実装リスト が掲載されています。

QUIC の実装は簡単ではなく、プロトコルは毎日のように変更され続けています。

サーバー

NGINX による QUIC および HTTP/3 のサポートは現在開発中で、プレビュー版はすでに告知されています。

Apache が QUIC をサポートしたという公式な発表はありません。

クライアント

IETF バージョンの QUIC や HTTP/3 をサポートしたブラウザをリリースした大規模ベンダーはまだありません。

Google Chrome には Google 版の QUIC が何年も前から組み込まれており、最近はオプションで IETF 版のサポートを開始しました。Firefox も同じようにオプションでサポートを開始しました。

curl は最初の実験的な HTTP/3 サポート (draft-22) を2019年9月11日リリースのバージョン 7.66.0 で対応しました。curl は Cloudflare の Quiche ライブラリ と ngtcp2 ファミリのライブラリを用いてこれを成し遂げました。

実装の障害

QUIC は TLS 1.3 を暗号化とセキュリティのために採用することにしました。これは車輪の再発明を避け、信頼できる既存のプロトコルを利用するためです。しかしながら、これと並行して、QUIC での TLS の利用を本当に効率化することにしました。QUIC では "TLS messages" のみを利用し "TLS records" は利用しないことにしました。

これは無害な変更に聞こえますが、この決定は QUIC を実装している人たちにとってとても高いハードルとなりました。既存の TLS 1.3 をサポートしているライブラリにはこれらの機能にアクセスする API が不足しており、QUIC ではアクセスできないのです。一方で多くの QUIC の実装者は大きな組織に所属しており、それぞれがもっている TLS スタックを別々に使用しているため、全員にとって問題とはなっていません。

2018年11月現在、例えば広く使われているオープンソースの OpenSSL では、これらの必要な API は全くなく、また近々で追加するような要望も上がっていません。

これにより QUIC スタックは OpenSSL 以外の TLS ライブラリを使う、パッチをあてた OpenSSL のビルドを使う、将来の OpenSSL に対しての更新を求める、といったいずれかの選択を取る必要があり、最終的にはデプロイの障害となります。

カーネルと CPU 負荷

Google と Facebook は QUIC を彼らの膨大なトラフィックに適用した場合、HTTP/2 over TLS に比べ約2倍の CPU が必要になると言っています。

しかし、下記のような説明が含まれています。

• 歴史的に多くの Linux の UDP スタックはこのような高速通信に利用されることを想定していなかったため、TCP スタックに比べて最適化がされていない

• TCP と TLS の負荷を軽減するハードウェアは存在しているが、UDP のものはほとんどない。基本的に QUIC 向けのものは存在していない

このような問題点がありますが、パフォーマンスと CPU の要求が将来的に改善されると信じています。