at the front―前線にて

第5回 OSSを職とし,今後のWebの基盤を作る

この記事を読むのに必要な時間:およそ 3.5 分

フロントエンドから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を投げたっていいじゃないのという話は割とあるんですよ。アセットの粒度をどうするかというのと依存の関係なんでしょうけど。

画像

注2)
奥さんが考案し,IETFに提案中である。

OSSと日本のコミュニティ

竹馬:先ほど話に出たOSSで食っている人たちは,一穂さんが仕事しているレイヤ的にそういった人たちとコミュニケーションすることが多かったから知っているんですか?

奥:標準化の会議で会う以外にも,HTTP関係の人はHTTP Workshopという実装者の会合もあるし,PowerDNSの人はH2Oのライブラリバージョンであるlibh2oを使って,PowerDNS のDNS over HTTPS対応をやっていたり。そういう関係でオープンソースでつながりがある人もいるし,実装者のコミュニティでつながりがある人もいる。そんな感じですね。

竹馬:普通にWebを見ていたら,どこにそういう人たちがいるのかわからなかったんです。

奥:その辺,日本だと時雨堂のvoluntasさんのようにWebRTCのプロトコル実装をやっている人はいるけど,海外の実装者はあんまりつながりがないんですよね,日本のユーザーと。

竹馬:日本の開発者コミュニティってユーザーとしての知見を共有することが活発で,その一方自分たちで何か作るという方向にあまり行かない気がしています。僕も人のことを言えないんですが。あと英語圏の議論にキャッチアップしていないのが不利になったりすることもありますね。

奥:逆に僕からすると,日本のユーザーに届けようと思うと,日本語で発信しないと厳しいんだろうなと感じます。最近英語で標準化の提案を書いたら,ゆきさんが日本語でブログエントリに書いてくれて助かりました。そういうことが結構あります。日本で広めたければ日本語で発信したほうがよいんだろうなと思います。

竹馬:自動翻訳がシームレスになる時代がもうちょっとで来るのかなと思っていたけど,意外とまだ来ないですね。

奥:そうそう。その辺も含めて,もっと自動翻訳が発達してくれるといいんでしょうね。でも,ここ10年間,思いっきり進歩したと思いますよ。数十年前の全然使い物にならなかった時期と比べると。自分の使いたい言語で,世界中の情報にアクセスできるようになるまで,あと一歩でしょうか。

WEB+DB PRESS

本誌最新号をチェック!
WEB+DB PRESS Vol.119

2020年10月24日発売
B5判/160ページ
定価(本体1,480円+税)
ISBN978-4-297-11669-9

  • 特集1
    [古い技術,コードの重複,密結合]
    フロントエンド脱レガシー
    長く愛されるプロダクトをさらに改善していくために
  • 特集2
    インフラ障害対応演習
    「避難訓練」でいざに備える!
  • 特集3
    深層学習入門以前
    チュートリアルを動かす前に知っておくこと

著者プロフィール

竹馬光太郎(ちくばこうたろう)

フリーランスで先端技術の導入などを行う。

GitHub:mizchi
Twitter:@mizchi
URL:https://mizchi.hatenablog.com/