orangeitems’s diary

クラウドではたらくエンジニアの日々の感想です。

HTTP-over-QUIC(HTTP/3)の使いどころに気が付いたのでメモ

f:id:orangeitems:20181114194659j:plain

 

なぜHTTP/3はUDPを使おうとしているのか

前回のエントリーで、HTTP/3がUDPを使うと知っておののきました。

 

www.orangeitems.com

LAN内のセキュアなネットワークならともかく、インターネットでUDPをANYにオープンするサービスが増やすのはどうなんだろう---。

 

しかし、GoogleやIETFが精力的に策定を進めているところからすると、何か強いモチベーションがあるのだろうと思って考えていましたら、使いどころを思いつきました。しっくりきたので記事にしておきます(エンジニアの妄想ですので、話半分に捉えてください)。

 

思いついたこと

思いついたことはこうです。

CDNネットワークのエッジサーバーについては、UDPによるHTTP/3対応をします。そしてChromeなどのWebブラウザについてもHTTP/3クライアント対応をします。そのうえで、CDNが見に行くオリジンサーバーに対してはHTTPS (over TCP)のままとするのです。動的なページやキャッシュの時間切れのみオリジンサーバーにアクセスします。

そうすれば、データセンター側のサーバー運用は相変わらずUDPがクローズドのままで十分運用できます。サイズの大きい静的コンテンツはCDNにキャッシュさせておきUDPで配信するのです。

そもそも、HTTP/3の目的は大容量のバイナリファイルや、ストリーミングの高速化が目的と聞いていました。とすれば、CDNでのコンテンツデリバリーには最適です。かつオリジン側は動的ページの生成でありアウトプットとしてはサイズが小さいので、強いてHTTP/3にする必要はないと思います。

今後、4K/8K、そして5Gにて映像のサイズはどんどん大きくなっていくのに、相変わらずTCPでデリバリーしていかなければいけないCDNやGoogleの悲鳴が、HTTP/3を強く推進しているのではないか、と感じました。UDPで配信すれば速いのがわかっている。

もちろん、IP制限をしている拠点間で、サーバー側のHTTP/3を有効にしてUDPも通して大型のファイル転送をスムーズに行うのはアリだと思います。ただ大きな目的は、エッジのUDP化であり、インターネットにおける放送の最適化なのだと考えると腑に落ちた次第です。

 

セキュリティーも大丈夫っぽい

もしエッジだけUDPを開けるのであれば、ここにUDP Floodをかけたとしてもオリジンまでは届きません。オリジンに取りにすらいかないでしょう。HTTP/3はTCPのセッションを取り込むようなので、無茶苦茶なUDPパケットは破棄します。そしてCDNネットワークはそれこそ巨大な帯域を持ちますので、攻撃者のルーティングを捻じ曲げて終わりだと思います(GitHubのときにAkamaiがやったように)。

データセンター側は相変わらずTCPのみにしてファイアウォールでガチガチに固めておいて、配るエッジと端末の間はUDP。これがHTTP/3による近未来かどうかは、数年先にはわかると思います。もしかしたら全然違う実装を予定しているのかもしれません。引き続きHTTP/3の進展を待ちたいと思います。

(予想が当たるか外れるかはともかく)CDNとWebブラウザがHTTP/3を実装したら、ぜひ使ってみたいです!。