通信って。奥： 通信は相手と話せないと意味がないですから。で、もう一つの飯の食い方は、コストがかかっている部分をコンピュータサイエンスの技術を使って改善して、スケールメリットで儲けること。大きい会社のR&D部門に寄食する感じですよね。そこでは大きなイノベーションは不要なんです。新しいものを作るのではなくて、今あるものを改善するという話なので、着実に成果を出せる分野です。そういうところに属するのが合理的な選択だと思いますね。
竹馬： まさに今の一穂さんの立場ですよね。
奥： CDN（Contents Delivery Network ）ってなんだかんだ言ってWeb配信のための最適化をやる業界じゃないですか。僕みたいな仕事をやっている人がいっぱいいるわけです。そういう環境がどれだけあるかという話になりますね。
QUICは自由な進化のための基盤
竹馬光太郎氏
竹馬： 一穂さんが今取り組んでいるQUICについて、技術的なことをお聞きします。今はHTTP/3って言うんですか、より自由度の高いUDP（User Datagram Protocol ）の上でTCPのような機能を実現しているものですよね。TCPのようなレイヤだと、古いものは負債もたまっているんでしょうか。
奥： そう。TCPとTLS（Transport Layer Security ）を置き換える部分をQUIC、HTTP特有の部分をHTTP/3と呼ぶことになりました。TCPについてはいろいろあるのですが、TCPが発明された50年ほど前にはすごいネットワークが細かった。でも今はネットワークが太いので、通信のボトルネックがパケットの量ではなく、エンド間で往復するラウンドトリップにあるんです。
TCPがあって、TLSがあって、その上にHTTP/2がのっていたんだけど、やはりレイヤが多いのでオーバーヘッドがある。TCPのパケットをロスしたときにHTTPの別のストリームでHead of LINE Blocking（パケットが届いていても利用できない状態）が発生してしまったりとか。
また、TCP自体は平文なので、攻撃に対しても弱いんです。TCP/TLSを一体化させてしまえば攻撃耐性は上がるし、プライバシーも守れる。今はTCPが平文だから、中継装置が勝手にいろんなことやるんですね。そのせいでTCPの改良ができない。たとえばTCP Fast Open の導入もなかなか進まない。TCPは実質的に硬直化しています。
この現状を踏まえて、できる限り硬直化しないように暗号化／難読化されたプロトコルを作ろうというのがQUICのもう一つの目的です。より高速で、より安全なだけでなく、今後自由に進化するための基盤を作ろうということです。中継装置に関係なく、エンド間で自由に進化させることができるという、これがQUICの基本的な考え方です。
フロントエンドからQUICを見る
竹馬： HTTPはストリームの都合で上から順番にコンテンツを確定させないといけないじゃないですか。今のアプリケーションの設計は、場合によっては下側のコンテンツから上部のコンテンツを確定する可能性があって、突き詰めるときに最適化しづらいことがあります。このあたりはいじりようがないんでしょうか。
奥： いじりようがなくはないと思います。たとえば標準化のほうでちらほら出る話として、HTTPのレスポンスヘッダの中に優先度を埋め込みたいという話があります。ボディを同期的に取得している場合でも、ボディの中に埋め込んだもののレスポンス優先度を上げるとか。そういったことは可能にはなるかもしれません。
あとはまあ、HTTP/2のサーバプッシュがうまくいったら、やりようはあったんでしょうが……。
竹馬： 現状、サーバプッシュは使われなくて削除される見通しですよね。
奥： ちょっと使い方が難しすぎたのかなと感じます。次にこういうリクエストを送ってくるだろうからそれを先に送り込む、というそれだけのものだったのですが。
うまくいかなかった理由は、実際のユースケースで計測すると、サーバが余計なものを送って遅くなっているケースのほうが多かった。QUICになると、Webサーバ内でパケット単位で決められるようになるのでこの問題は改善するんですけど。
竹馬： ある種の投機的な実行ですもんね。Webを作る側はいろんな機能を使ってほしくていっぱいプッシュしたいけど、ユーザーはそこまで期待してないから離脱するっていうせめぎあいがある気がします。たぶんそういうところで仮に入ったとしてもうまくいかないのかも、という直感はありました。
奥： ページのレンダリングが終わってから裏で何か流していると嫌がられるんです。
竹馬： サーバプッシュと言うと、JavaScriptの話なんですがサーバプッシュによるCache Digest [2] がなくなってしまうと、依存性のある未結合のJavaScriptを配信するES Modulesの実用が困難だと言われています。現状webpackで1つのファイルにバンドルするのがベストプラクティスになってしまっているやつです。
奥： Cache Digest的なものをService Workerで実装することは一応できるんで、それをやるんですかね？
竹馬： フロントエンド的には大きく2つのKPI（重要業績評価指標）があって、1回目の初期化時間と2回目以降の初期化時間なんです。Sevice Workerが効くのは2回目以降です。ブログやニュースみたいなメディアは初回が大事で。
奥： なるほど。ただ、HTTPのサーバプッシュでも解決しない問題があるんです。何かというとレスポンスをまたぐ圧縮ができない。webpackみたいな静的解析による結合をしていると、それができる。HTTPのレスポンスをまたぐ圧縮というのは、みんなずっとやりたいやりたいと言っているけど、セキュリティ上の問題があって難しいんです。
竹馬： なるほど、最近CPUの投機的予測で問題になったSpectre みたいな。
奥： そうです。CRIME という攻撃手法があって、攻撃者がURLのパラメータに何か足してリクエストすると、レスポンスの圧縮後の長さの変化から、レスポンスの中に入っているデータが予測できるかもしれない、というものです。TLSの圧縮機能への攻撃なんですけど、HTTPでレスポンスをまたぐ圧縮をしてしまうと同様の問題が起きるかもしれない。
こういう圧縮はやはり難しくて、標準化するうえでそれをどういう風におさめるかっていうのは難しいのでwebpackでやってしまってもよいのかなという気はします。特に複数ファイルが送られなければいけないとわかっている場合、あらかじめ圧縮しておくっていうのは、少しでもデータを減らす、ちょっとでも表示を速くするにはよいと思います。
竹馬： フロントエンドの最近の潮流だと、CDNにHTMLのキャッシュを置いて、そのアセットバージョンの間では参照透過に作ろうという感じになっていて、今後はCDNがアプリケーションの形を決めてくる時代になるのかなと思っています。一穂さん的にはそれをどう思いますか。
奥： プロトコルをやっている側から言うと、今言ったようなサーバプッシュ自体はある程度意味はあるんだけど、結局1回分のラウンドトリップタイムしか削れないんです。先ほどのES ModulesのJavaScriptで、よっぽど依存関係がネストしている場合というのはつらいでしょうが、それ以外だったらそこまでつらくないんじゃないのか、という期待はあります。
たとえばHTMLの中からJavaScriptを参照している場合に、HTMLのサイズが1KBとかだったら、最初のスロースタートのときに15KBくらい投げられるのに1KBだけ投げて、残り14KBは使われないから、そこにJavaScriptを流したいっていう話はすごく意味がある。でもHTMLのサイズが20KBあるんだったら、どのみち最初にHTML全部を投げられないんだから、まずリンクタグとHTMLだけレスポンスを投げて、次のラウンドトリップでクライアントからのJavaScriptへのリクエストが届くから、そのときにJavaScriptを投げたっていいじゃないのという話は割とあるんですよ。アセットの粒度をどうするかというのと依存の関係なんでしょうけど。
OSSと日本のコミュニティ
竹馬： 先ほど話に出たOSSで食っている人たちは、一穂さんが仕事しているレイヤ的にそういった人たちとコミュニケーションすることが多かったから知っているんですか？
奥： 標準化の会議で会う以外にも、HTTP関係の人はHTTP Workshopという実装者の会合もあるし、PowerDNSの人はH2Oのライブラリバージョンであるlibh2oを使って、PowerDNS のDNS over HTTPS対応をやっていたり。そういう関係でオープンソースでつながりがある人もいるし、実装者のコミュニティでつながりがある人もいる。そんな感じですね。
竹馬： 普通にWebを見ていたら、どこにそういう人たちがいるのかわからなかったんです。
奥： その辺、日本だと時雨堂 のvoluntasさんのようにWebRTCのプロトコル実装をやっている人はいるけど、海外の実装者はあんまりつながりがないんですよね、日本のユーザーと。
竹馬： 日本の開発者コミュニティってユーザーとしての知見を共有することが活発で、その一方自分たちで何か作るという方向にあまり行かない気がしています。僕も人のことを言えないんですが。あと英語圏の議論にキャッチアップしていないのが不利になったりすることもありますね。
奥： 逆に僕からすると、日本のユーザーに届けようと思うと、日本語で発信しないと厳しいんだろうなと感じます。最近英語で標準化の提案を書いたら、ゆきさんが日本語でブログエントリ に書いてくれて助かりました。そういうことが結構あります。日本で広めたければ日本語で発信したほうがよいんだろうなと思います。
竹馬： 自動翻訳がシームレスになる時代がもうちょっとで来るのかなと思っていたけど、意外とまだ来ないですね。
奥： そうそう。その辺も含めて、もっと自動翻訳が発達してくれるといいんでしょうね。でも、ここ10年間、思いっきり進歩したと思いますよ。数十年前の全然使い物にならなかった時期と比べると。自分の使いたい言語で、世界中の情報にアクセスできるようになるまで、あと一歩でしょうか。
特集1 イミュータブルデータモデルで始める 業務の複雑さをシンプルに表現！ 特集2 いまはじめるFlutter iOS/Android両対応アプリを開発してみよう 特集3 作って学ぶWeb3 ブロックチェーン、スマートコントラクト、NFT
