多くの人はまだHTTP/3を無理して学ぶ必要はない

フューチャーアドベントカレンダー2018のピンチヒッターです。ワイキキの海を見下ろすホテルからこんばんわ。

QUICがリブランドされてHTTP/3になったというのはそれなりに大きな話題になりました。これを機に学ぼうという人も多いと思いますが、個人的には費用対効果を考えると、まだ早いのではないかと思います。HTTP/2のときともまた違ってそんな学んだことが役に立つ人も多くないのではないかな、と思います。

HTTP/2を学ぶべきだがHTTP/3を（あえて）学ぶ必要はないと思う理由

HTTP/1.1からHTTP/2はほとんどの部分が同じです。フレーム単位で送受信する方式になって、メールとかネットニュースと同じようなテキストベースのプロトコルから変わったりという「表現のシンタックス」上の変更が中心でしたが、その上で表現する、たとえばクッキーの意味だとか、フォームなどの情報をどのようにシリアライズしてサーバーに送信しようとか、認証をどのように実現しようといったウェブサービスの実装者が気にするべきセマンティクス部分は変わりませんでした。

しかし、実装者が気にするべきセマンティクスの変更もありました。

• Server Push
• 103 Early Hints

アプリケーションができることが増えて実現できることが増えたり、アプリケーション側が考慮することでさらなるパフォーマンスアップにつながるようなことがありました。そのため、HTTP/2を学ぶことはその上のアプリケーションを開発する人にも意義も大義もありました。

ですが、HTTP/3には今の所そういうところはないですよね（という理解です）。

実際のところ、HTTP/2の普及もそうだったと思うのですが、CDNなり、クラウドサービスの外側のロードバランサーなりの外側がサポートされたら、それで初めて使えるようになる、それで利益を得られた、という人が多かったんじゃないかと思います。今やインフラの知識とかインフラ作業といっても、ケーブルを引き回してラックを立てたとか、openStackでシステムを構築した、というところから、（新規案件のほとんどは）クラウドサービス上の設定方法だとか、Kuberentesをどう使うかとなってきていますし、ネットワークの関心事もほぼソフトウェア定義になってきていると思います。なので、そちら側で使えるようになるまではその新しいプロトコルのメリットを得ることもできません。

あと、現実問題として、HTTP/2もCDNやクラウドのロードバランサーの内側ではほとんど活用されてないんじゃないでしょうか？僕の知る限りだと、HTTP/2はHTTPSは必須ではないものの、多くの実装がHTTPSでないとHTTP/2を有効化していません。これはHTTP/2がHTTP/1.1と互換性がないため、ネットワークの途中に挟まっているゲートウェイなどのシステムが仮にHTTP/2をサポートしていなくても問題ないように、内部が暗号化されているときのみ有効、みたいな意味もありました。クラウドサービスのコンテナ間の通信でHTTPSで行う設定をどうすべきか、みたいな議論を見たことがないですし、内側はHTTPのことがほとんどじゃないですかね。gRPCだとInsecure（署名書の確認をしない）というオプションがあるので、オレオレ証明書だったりするんですかね。HTTP/3はHTTPS必須なので、さらに敷居が高いといえます。

2/4追記

いま見て気づいた本質的でない話ですが、gRPCのinsecureはTLSを使ってなくて、一切暗号化されていないと思います。普通はローカルホスト内とかみたいな用途ですhttps://t.co/z7qZUsEWZz

— Jun Mukai (@jmuk) February 2, 2019

Goの標準ライブラリがTLSじゃないとHTTP/2にならないのでgRPCはきっとinsecureでやっているんだろうな、と思い込んでいたのですが、今見たら、標準ライブラリ使っていないんですね・・・コピーして手を加えて利用しているんですかね・・・標準ライブラリにフィードバックしてくれないかな・・・

• https://github.com/grpc/grpc-go/tree/master/internal/transport

今HTTP/3を学ぶべき人

例えば、CDNの運営会社ですとか、WebRTCの配信基盤を作って動画配信をしているとか、IETFの会合に参加してプロトコルの改善に協力したい、プロキシを実装したり、みたいな人はぜひ学ぶべきだと思います。HTTP/3の実装リストでも最新の仕様に準拠した実装はないとのことですし、そういうのにコミットする、あるいはオリジナルのサーバーやミドルウェアを実装して名を上げたい人は5年に一度みたいなチャンスだと思います。

あとは、TLSを内部で活用しているといっても、TLS/1.3とは多少違うところがあるみたいなので、セキュリティ関係の人は見たほうがよいかもしれません（僕も詳細は把握していません、すみません）。

1/4追記

TCPがやっていることがユーザーランドに来るというのがHTTP/3。TCPはもろもろの最適化をカーネルで行っていたので、カーネルのネットワーク周りをやっている人もいろいろ楽しそうですね。

めっちゃ面白かった。QUICの効率化のためにLinux Kernelのレイヤで何をするべきかという論文。UDP Segmentation Offloadとpacingなどの効率化を施せばTCPの最適化に近づくだろうとする結果が出て… https://t.co/3tE4jGP4SC

— Yosuke FURUKAWA (@yosuke_furukawa) January 3, 2019

（普通のウェブアプリケーション開発者は）いつHTTP/3を学ぶべきか

とりあえず、クラウドサービスとして簡単に利用できるようになってからでいいんじゃないかな、と思います。RFCを読むのに躊躇がない人ばかりではないと思いますし。現時点でも、日本人有志ががんばってくれた[詳解 HTTP/3]
(https://http3-explained.haxx.se/ja/)のおかげで敷居は少し低いと思いますが、実際にハンズオンできる状態になって、もっと試しやすい環境になってからの方が単位時間あたりの学習効率は良くなるんじゃないかな、と思います。

いちおう、この論点としてはネットワーク内部の通信もすべてTLSになっていくのであれば問題ない話ですので、開発環境とかも含めて証明書をきちんと作って設定するなり、クライアント証明書も入れてさらに強固にするなり、オレオレ証明書を作ってinsecureでやるなりの手順とかが整って（情報が増えて）、Terraformではこうやります、Cloud Formationではこうします、docker-composeではこうします、みたいな情報が出そろって、息を吸うように証明書を設定する時代になったら、当然やっていくべきです。

あ、↑こういうのを俺たちはやっていくぜという取り組みとセットであれば、HTTP/3を今すぐ学ぼう！というのは異議はありません。ただこれも、HTTP/3以前に、HTTP/2をもっと活用しましょう！という取り組みになるはずで、そういう意味では、まとめると次のような感じになるかと思います。

• HTTP/3には、HTTP/2にあったような、アプリケーション層の実装に大きく影響を与えるような機能要件はない
• HTTP/3はまだ仕様が最終決定ではなく（名前がHTTP/3になった、というのがセンセーショナルだったけど）、活用できるソフトウェアはまだ世の中にないので、学んでも実践で役立つのはまだだいぶ先
• HTTP/3以前に、実践として取り組むべきはHTTP/2の活用
• それをわかった上で学ぶのであれば、どうぞどうぞ
• とりあえず概要を軽くおさらいするのであれば詳解 HTTP/3をちら見するのでも十分かと思います。

HTTP/3を学んでも、HTTP/1.1とHTTP/2が不要になるわけではない。

2/4追記

HTTP/3という名前がいかに新しそうでも、HTTP/1.1とHTTP/2が駆逐されることはありません。それぞれ、必要なフィールドが明確に異なります。

• 非TLSではHTTP/1.1。一番ポータビリティが高い。
• HTTP/2はTCPが使えてTLS環境であればまず使える（多くの実装では）。
• HTTP/3はUDPが使えてTLS環境があれば使えるかもしれない（まだリリース前なので詳細な条件は未知数）

TLS環境というのは証明書をきちんと発行して使えるにする、という意味です。3→2→1.1の順に性能は高いはずですが、ポータビリティは下がります。あと、HTTP/2を学べばHTTP/3（及びその下のQUICトランスポート）のキャッチアップはかなり簡単になります。もうすでに現物が得られて解説も多いHTTP/2を最短コストで学んで、HTTP/3はまたリリース後に必要になってから学ぶ、という選択肢も有効だと思います。

なんでこんなことを書いたのか

昨年はイマドキのJavaScriptの書き方2018というエントリーを書いて、（たぶん）Qiitaの2017年の記事としてはいいね数が年間一位のようです。

もともとこのエントリーは、フューチャーのお仕事の中で、若手のメンバーから、社員研修ではjQueryは多少触るものの、ReactやらVue.jsやらで仕事をするにあたってのイマドキのJavaScriptの書き方をきちんとは学んでない、ということを聞いたところから生まれました。いい本があれば紹介しようとしたのですが、なかなかコンパクトにまとまったいい本がない。じゃあ自分で書いてしまえ、ということで書きました。実際に書くにあたっては社外のPySpaメンバーと楽しく議論をしていたら、ネタがわっと集まってきたので一気に書き上げました。

かといって、新人研修が悪いかというと別にそんなことはありません。フューチャーは大学でコンピューターをやっていなかった学生も含めて、ポテンシャル採用をしています。短い期間で本当に多くのインプットをした上でプロジェクトにアサインされます。歴史的経緯もあってJavaの学習がメインです。Javaでなくても何かしらの言語をきちんと学びきればそれが基礎になって他の言語の学習は高速に行えますし、実際に社内でもJava以外の案件も増えています。文系出身者の若者も交えてES2017なJavaScriptを本格的に書くのは初めてという若者たちと一緒にReactでNext.jsでSPAでSSRという案件をやったわけですが、↑のエントリーの効果がどれぐらいだったのかはわからないのですが本当にみんな飲み込みも早く、教えるのもすごく楽しかったです。社内のベストプロジェクトを決める年に一度のイベントをフューチャーではやっていますが、うちのプロジェクトは無事予選でベスト10に残り、さきほどハワイ（家族で参加しました）での決勝のプレゼンもありました（残念ながら優勝は逃しましたが）。

「○○を学ぶべき」みたいなものはたくさんありますが、同じ成果を出すのであれば、なるべく時短したいですよね。一緒に仕事をしている若い人たちにはなるべく早く帰って人生をエンジョイして欲しいし、何かを学ぶにしても業務優先ではなくて楽しみ優先で選んで欲しいと思っています。業務で必要な知識のキャッチアップは業務時間の中で効率よく取れるようにすべき。なので、１人ぐらい「今は学ぶべきときじゃないよ」というオジサンがいてもいいかな、と。新卒からの質問をソシャゲっぽい仕組みにしたら捗った話みたいなのがバズってますが、僕は基本的にどんな質問でもいつでもいくらでもしていいよ、同じ質問でも何度でもいいよ、というスタンスでやっていました。若者の工数も含めて見積もりしているので、悩んでいる時間はチーム全体にとって損という単純な話でもありますし、実際には同じ事象に対する悩みであっても、知識がないと以前の質問と同じかどうかもわからないことは数多くあります。そもそもオジサンで記憶力も弱っているので、誰が過去にどんな質問をしたのか覚えきれないので、二度目判定を正確にやる自信がない、という後ろ向きな理由もあります。

働き方改革というのが話題ですが、アウトプットの量を減らさずに時短するには、アウトプットにつながらない無駄を減らすか効率を上げるかの2択です。とくにIT系は知識マウンティング的になりがちなので、「今は学ぶべきではない」と言うのにも勇気がいります。炎上するにしても、若者が炎上するよりは、僕の方が精神的HPは高いので、タンク役になるにはいいかな、という気持ちです。まあ炎上して「他よりも優先してHTTP/3を学ぶべき」といえる論拠が出てきたのであれば、それはそれでこういうエントリーを書いたかいがあったと思うので、反論はウェルカムです。

あ、HTTPそのものをまったく知らないので、これを機にHTTP/1.1、HTTP/2ともども学ぼうというのは意味はありますよ。まあ、それも活用という意味では「HTTP/2の活用」と互換な努力にはなると思いますが。ちなみに、HTTP/2以前を手っ取り早く学ぼうという方にはReal World HTTPという本があります（ステマ）。