00:00
Nginx界のときに、HTTP2とかHTTP3周りの話が ちょこっとだけ出てきたかなと思うんですけど、
実はですね、HTTP2とか3のことを なんかすごい並列で高速にアクセスできて、
高速にレスポンスもらえるみたいな、 そういうざっくりとしたイメージなんですけど、
これってあってますかね?
そうですね。ブラウザから見たら、 確かにそういう感じではあるんですけど、
高速なウェブサービスを本気で実装していくなら、 その認識では甘いかなと思ってます。
なるほど。じゃあちょっと違うって感じなんですかね?
そうですね。もうちょっと深掘りしたいなって感じですね。
どういうものなんですかね? ざっくり解説してもらえると非常に嬉しいんですけど。
ざっくりって結構難しくて、
なんでそもそもHTTP2とか3が生まれてきたのかっていうのを、 まず深掘りしていきたいかなと思ってます。
じゃあそうすると、まずHP1.1にどういう問題があったのかっていうところをまず認識しないといけなくて、
そこからまず話していきます。
まずHP1.1はもともとすごく使われていたんだけど、
HP1.1だとウェブページがどんどん重くなっていったんですよね。
HTMLがあって、そのHTMLがCSSとかJavaScriptとか画像とか、
すごいたくさん読み込むようになっていったわけじゃないですか。
HP1.1の最大の問題は、
1コネクションでリクエストを並列に送ったり送信したりができなかったんですよ。
なので1コネクションで1個1個リクエストとレスポンスやり取りしてたんですね。
それだとさすがに遅いっていうので、
ブラウザーは6個コネクションを1つのドメインに対して作ってたんですね。
けどこれは別に仕様とかじゃなくて、
ブラウザーが6個っていう設定にしていた。
クライアント側の実装でそうしてた。
クライアント側の実装でそうしていて、
もちろん並列を増やすとその分並列化できるんですけど、
その分、例えば6個作るんだったら6個分TCP接続もしないといけないし、
TLSハンドシェイク、HPSだったらTLSハンドシェイクもそれぞれでやらないといけない。
っていうのでどんどんコストが増えてたんですね。
1つのリクエストを並列でやってたとしても、
それぞれでオーバーヘッドがかかってるって感じですね。
そうですね。コネクション1つ1つ作るのにまずオーバーヘッドがある。
でもたくさん作らないと速度が出ないっていう状況だったんです。
無駄が多かったってことですね。
無駄が多かったですね。
これのおかげで、昔は例えばCSSとかJavaScriptとか画像とか複数のドメインを分けて用意しちゃう。
例えば画像を複数のドメインに分ければ、
それぞれのドメインごとにコネクションが6個貼れるから、
ドメイン分けた方が早いみたいなことを昔やってたんですよ。
03:03
すごいハックですね。
すごい。当時ね、後でまたいろいろ話すんだけど、HP1.1の時の話。
本当に辛い感じの最適化をみんな頑張ってやってたんですよ。
いっぱいサブドメイン発行するんで。
そう、いっぱいサブドメイン発行した方が早いみたいな。
イメージ1、イメージ2みたいな感じで。
本当にそういうことやってましたよ。
なるほど。
それって無駄じゃないですか。
無駄というか何ですかね、すごく頑張って回避しようとしてるって感じですかね。
一つのコネクションが複数のリクエストとレスポンスを同時に扱えれば、
こんな変なことやらなくていいんですよね。
そういうのがあって、Googleが最初のHPをもっと早くしようっていうので、
スピーディーってやつとクイックってやつを作ったんですよ。
このスピーディーっていうのがHP2に繋がったやつで、
このクイックってやつが、また後で話すんですけど、HP3に繋がったものになります。
それぞれが2と3に分かれたんですね。
そんな感じですね。この後またちょっとずつ補足していきますが、
まずはHP2の話をしていきたいかなと思ってます。
スピーディーの方ですね。
スピーディーの方です。
HP2に行くにあたって、まずHP1.1のヘッドラインブロッキングって呼ばれてる問題があったんですよ、HP1.1には。
これはさっきも言った通り、一つの接続でリクエストとレスポンスを順番に一個一個扱っていたので、
前のレスポンスが詰まると、後ろのレスポンスも全部待たされちゃうんですよね。
直列で全部繋いでるから全部待たされちゃうんですよ。
これがHP1.1で言われていたHTTPレイヤーのヘッドラインブロッキングってやつなんですよ。
これをHP2で解決しましょう。
HP2はTCP接続1本張ったら、そこで複数のリクエストとかレスポンスを並列に扱えるようになる。
これによってHTTP1.1のヘッドラインブロッキングを解決したと言われていますね。
単純に並列化できるようにしたんですよね。
直列しかできなかったのを並列に通信できるようにした、一つのコネクションで。
他にもたくさん最適化があって、
例えばHP1.1の時代ってHTTPのボディはGZIP圧縮できたんですけど、
ヘッダーについては圧縮する方法ってなかったんですね。
それでしょうがなくて、HPヘッダーの中にいろいろ情報が入っていて、
しかも例えばボディがGZIP圧縮されてますよみたいな情報も入っているから、
ヘッダー圧縮されちゃうともう訳わかんなくなっちゃうんですよ。
先に読みたい情報がそこに入っているから、
そもそも圧縮することができなかったってことですよね。
06:00
けどやっぱりHPヘッダーも圧縮したいよねっていうところで、
じゃあどうやって圧縮するのっていうところで、
ここがHPヘッダーの特性を使うんですけど、
HPヘッダーってそのユーザーが送ってきたHPヘッダーって、
次も同じようなヘッダーを送る可能性が非常に高いんですよね。
同じクライアントからのリクエストだったらそうですよね。
結構大きいのがクッキーとか結構大きくなるし、
しかもだいたい毎回同じ値を送ってくる。
確かに。かぶってること多そうですね。
やっぱり一つのユーザーは似たようなヘッダーをずっと使ってるんで、
なのでこれハフマフ語っていう圧縮方法を使ってます。
これコンピュータサイエンスだったら結構最初の方でやると思うんだけど、
聞いたことあります。
頻度が高いやつは短くする。
みたいな圧縮方法でやる。
これがHPackって呼ばれるものですね。
なるほど。聞いたことある単語が出てきました。HPack。
これがHP2でHPヘッダーを圧縮するための仕様ですね。
それでヘッダー部分が圧縮できたわけじゃないですか、HPackで。
どのぐらい効果あったんですかね、実際。
ボディがめちゃくちゃでかいのは分かるんですけど、ヘッダー部分は。
でもこれまで無視されてきたわけじゃないですか。結構でかいんですかね。
これって大事なのってその上り帯域を使うってところなんですよね。
リクエストのヘッダーって。
正直全体のサイズ見たらレスポンスのボディの方が圧倒的にでかいに決まってるじゃないですか。
画像とかいろいろあると。
そりゃそうですよね。
じゃあリクエストって大したことないんじゃないのって思うかもしれないんですけど、
リクエストの圧縮って上り帯域に効くんですよ。
なるほど。クライアントからサーバーに送るものだからってことですね。
上り帯域って結構細いことが多いんですよね、下りに比べて。
確かに。下りのダウンロードに比べると上りの方が回線帯域細いですよね。
大体細いじゃないですか。
一般的には。
なので上りが縮むっていうのは結構大きいんですよ、実は。
確かに。
なので結構これは効果があると思ってます。
じゃあクライアントからリクエスト投げるときにかなり効果的だったよねっていうところがヘッダーの圧縮なんですね。
そうですね。
ありがとうございます。で、その次がって感じなんですかね。
そうですね。他にもいろいろな仕様があったんですけど、残念ながら、例えば優先度を制御するみたいな仕様も元々あったんですけど、
例えばCSSを先に優先的に送ろうとか、画像を後にしようみたいな細かい制御が元々できる予定だったというか、
仕様としてはあるんですけど、実際にはこれほとんど活用されてないですね。
ちょっと仕様が複雑すぎてほとんど活用されてないっていうものになりますね。
リソースごとに優先度を明示的にヘッダーとかで付けられてって感じなんですかね。
09:02
そんな感じだったんですけど、結局ここはあんま使われてないです。
そういう複雑すぎてあんま使われてないみたいな仕様もあったりはしますね。
一応仕様としてはあったけども、みんな使わなかったよねっていう現実があるんですね。
そうですね。そういうのは結構ありますかね。
ざっくり基本としてはこういうところですね。
がHTTP2。
特徴としてはって感じですね。
次は実際に具体的にどう通信するとHTTP2になるのっていうところで、
まずHTTP2は使用上TLSは必須ではないんですよ、実は。
そうなんですね。必須だろうとなんとなく思ってたんですけど。
ここがちょっと厄介なところで、RFCよく見るとTLSが有効なときとTLSが有効じゃないとき両方でちゃんと定義されているんですよ、HTTP2って。
けどちょうどこの時ってちゃんとウェブは全部HPSにしようみたいな動きがあった時期でもあるんですよ。
活発になってた時期。
そうですね。その時期でもあって、なのでブラウザの新機能はHPSでしか使わなくしようみたいなのも動きとしてあったんですよ。
これ今でもあるんですけど、なのでHP2もTLS以外では使わせないようにしようみたいなブラウザの流れがあったんですよ。
なのでHP2はTLS必須じゃないんですけど、使用上は。
けどブラウザで実装されているのはTLSだけなので、実質的にTLS必須って思っておいたほうが都合が良いです。
なるほど。使用上は定義されているが、それは実装されていない。
それは実装されていないです。
なるほど。
ちなみにTLSありの方はH2って書いて、平文のTLSなしのHP2はH2Cっていう風に言われることもあるんですけど、H2Cはほぼ実装されていないです。
実装してるクライアントあるんですかね、逆に。
僕はしてる限りない。
Firefoxも実装してないです。
ないんですね。
僕はしてる限りない。
なので無視していい。サーバー側の実装もほぼないので無視していいと思います。
なるほど。基本はHTTPSで。
なのでHPS必須って思っておいても問題ないです。
なのでウェブではHP2は実質TLS必須だと思ったほうが良いと。
じゃあ例えばクライアントが通信してきました。そのクライアントがHP2が使えるかどうかってどうやって判断するのっていうのがあって、これってどうやって判断してるかっていうと今はALPNっていうのを使ってます。
ALPN。
そうですね。ALPNっていうのはTLSの拡張です。
なのでTLSのヘッダーの中に、これ実は暗号化されてなくて平文で入ってるんですけど、HTTP2が使えるかどうかって情報が入ってます。TLSの中に。
クライアントが対応してるかどうかの情報を送信してるってことですか、クライアント側が。
12:04
クライアントがTLSの中のALPNっていう拡張を使ってH2使えますよっていうのを送ってくるんですよ。
サーバーはそれを見て、この人じゃあH2使えるんだったらHP2で返そうっていう判断ができるようになる。
なるほど。
なのでこれが結構HP3との違いにもなってくるので、まずここをちゃんと押さえてほしくて、HP2はそのTLSのALPNっていうので判断できるので、いきなり最初のリクエストからHP2が使えるかどうかっていうのを判断できるサーバー側。
使えるならHP3返ってくるし、使えないならHP1.1で返す。
レスポンスでHTTP2で返しますよみたいな感じで判断できるサーバー側。
なのでHP2とHP1.1は両方ともTLSで、TLSじゃない、TCPで動いてるので、そういう判断ができる。
まあなんかシンプルですね、わかりやすいですね。
わかりやすいと思います。
使えなかったら1.1にフォローバックするだけなので。
そうですね。なのですごいHP2は比較的わかりやすいかなと思います。
このPodcast、Yayoiro'sのOSSってPodcastなので、じゃあちょっとOSSのEngineXで使うとしたらどうなるのっていう話を軽くすると、
今は設定ファイルにHTTP2オンって書けばだいたい使えると思います。
すごいシンプルですね。
対応してるOpenSSLが必要ではあるんですけど、最近のやつは多分大体対応してるだろうし、
普通にAppTwinストーリーとかで入れた場合はOpenSSLも使えるようになってると思うので、
HP2オンって書けば大体の場合使えます。
なのでそれで大体使えるのかなとは思ってます。
そこに対してHTTP2を有効にしたから気にしないといけないところとかってあったりするんですかね、EngineX使う上で。
そうですね。リソースの使われ方は若干変わるんですよ。
HP2ってさっき言ったHPackの仕様があったりとかするので、
HPackってハフマン符号の辞書ファイルをクライアントとサーバー両方で同じやつ作らないといけないんですよ。
なのでコネクションそれぞれに辞書ファイルっていうのも必要だし、
保持されるコネクションの数っていうのもやっぱりHP2だとしばらくコネクション保持したりするので、
メモリーは一定使うんですよね、HP1.1より。
なるほど。
その代わりTLSのハンドシェイクの数は多分減るんですよ。
さっき言った通りHP1.1だとコネクション6個ぐらい作っちゃうんだけど、
HP2だと1個にまとまるんでTLSハンドシェイクの数は減るんですよね。
なのでCPU使用率は多分減ることが多いけど、メモリー使用量はちょっと増えるみたいな注意点はありますかね。
15:03
なるほど。
あとコネクション周り、通信の順番だったりとか、
そういうところは別に気にしなくても大丈夫そうって感じなんですか?
通信の順番っていうのはどういう順番ですか?
例えばどういう状況があり得るのかなっていうのが、
若干具体的な例がパッと思いつかないんですけど、
クライアントでAPIで通信して、リソースとか画像だったりとかをダウンロードしてくるみたいなのが、
クライアント側の普通な実装と役割なのかなと思うんですけど、
その時に1.1だったら普通に6個の並列でリソースとかダウンロードしてきたっていうところを、
2になるともうちょっとまとめて並列度合いが高くなるみたいなところで、
実装上気にしないといけないところもしかしてあるのかなとか若干思ったんですけど。
サーバー側の実装で気にすることは多分そんなにないんですけど、
結構クライアントのジャバスクリプトの作り方っていうのは、
やっぱりHP 1.1の時代とHP 2の時代で結構変わったと思ってますね。
やっぱ変わるんですね、クライアント側の実装が。
HP 1.1の時代って本当に辛かったと思っていて、
例えばリクエスト1個1個のオーバーヘッドが大きかったので、
そのリクエスト数自体を減らしたいっていうのがあったんですよ、HP 1.1の時代。
なので、CSSスプライトだっけ、やったことあると思うんだけど、
その画像を1個1個ダウンロードさせるのが大変だから、
画像1個、全部くっつけた画像1個作って、
CSSで画像のここだけ表示してくださいみたいなの昔やってたんですよ。
分割するやり方ですよね。
1枚の画像を、でかい画像をダウンロードさせて、
その中の一部だけ使って。
そうですそうです。
分割して使っていくっていう。
昔やられてたし、あとJavaScriptも1個でっかいファイルに全部結合して、
これ配った方がいいよね、みたいなことも昔やってたんですよね。
Webpackで1つにまとめるとか、そういう感じですよね。
そうですね、Webpackも使ってたし、
JQueryの時代だったら多分手でまとめてた人もいると思うんだけど、
何かしらの方法でファイル1個にまとめた方がいいって言って、
頑張ってファイルまとめてたんですよね。
けど今言ったやつって、やっぱり問題があって、
例えばさっき画像だと、
例えばこの画像を使わなくなったんだよね、みたいな画像が出てきた時に、
その画像を消すのめんどくさくて放置してたら、
結局無駄な画像をダウンロードさせることになるじゃないですか。
確かにバイナリー増えてますよね、それだけ。
そう、バイナリー増えちゃってるし。
じゃあ頻繁に変えればいいかっていうと、
結局1個でも画像変えちゃうと、
全部ダウンロードし直さないといけないんですよね、ユーザーが。
クライアント側のキャッシュが使えない。
キャッシュがエクスパイヤーしてるってことですよね。
クライアント側のキャッシュがうまく使えない。
ジャパンスクリプトも同じで、
結局ちょっとでもファイル変えたら全部変わっちゃうから、
18:02
全部ダウンロードし直しになっちゃうから、
クライアント側のキャッシュがうまく使えないんですよ。
ただ1個でっかいファイルにまとまったほうが、
gzipとかの圧縮率は確かにちょっと高くなるので、
全く無駄ではないんだけど、
やっぱりユーザーがうまくキャッシュ使えないっていうのは結構致命的な問題ではあるんですよね。
確かに。
なので、ファイルをめちゃくちゃ分割していい話ではないんだけど、
やっぱりある程度意味のあるファイルの単位で、
ちっちゃめのファイルにしたほうがいいし、
あと画像も1個1個ダウンロードさせて、
必要なくなったら単純に使わない。
必要な画像だけダウンロードさせるっていうのが、
今の時代、HP2の時代にとってはいいんですよね。
なので、実際にNext.jsとか、
最近のJavaScriptのフレームワークって、
基本的にそのJavaScript1個にまとめるというよりは、
細切れにして必要なファイルだけダウンロードさせるっていう作り方をすることが多いし、
あと画像を1個にくっつけるみたいな機能を持っているフレームワークなんて、
今時もう1つもないはず。
やっぱりそういうのが、
フロントエンドの考え方っていうのをガラッと変えたのがHP2ではあるんですよね。
確かに言われて気づきましたね。
昔そうだったなというところと、
最近そこまでそういうの気にしなくなったよなっていうのが。
それはHP2のおかげなんですよ。
やっぱりさっき言ったドメインを分割するとか、
そういうことを一切考えなくてよくて、
1個のドメインで配信したらいい感じにブラウザー側でやってくれる。
だからJavaScriptの実装も結構それに依存した実装になっているんですよね。
1.1の頃が異常で、
2になってからすごい普通にやってたら、
自然にやってたら早くなるよね、になったってことですよね。
フロントエンドの実装って観点だとそうですね。
ですよね。自然になってよかったねって感じですね。
ただやっぱり大変なのもあって、
HP1.1ってTCP上で単純にテキストプロトコルで、
ただ1行1行ヘッダー書いて空行2つ入れてボディ書いてっていうすごい単純な仕組みだったんですよね。
シンプルだったってことですよね。
すっごいシンプルで実装も簡単だった。
けどHP2ってバイナリプロトコルだし、
さっき言ったHPackの実装も必要だし、
本当に実装難易度っていうのはすごく上がっちゃったっていうのがあるんですよね。
それはサーバー側の実装の難易度。
どっちもですね。
サーバーのクライアント側。
なるほど。
でも大体においてそこら辺はライブラリとか、
そもそもブラウザがサポートしてたりだったりとか、
そういうサポートはもちろんあるよねって話。
そこもやっぱり結構大事なところで、
HP1.1の時は結構自作してる人多かったんだけど、
HP2になってやっぱり自作するのが難しくなっちゃったんで、
21:00
それこそカール?
カールですらNGHTTP2っていうライブラリがあって、
カールですら自作してないっていうのが実態だったりするんですよね。
じゃあカール対応してないんですね。
NGHTP2っていうライブラリを使って対応してるんだけど、
自前の実装ではない。
カールですら自作できないぐらい、
HP2は複雑だっていうことの証拠でもあるんだよね。
なるほど。
でももう難しいんですね。
難しい。
HP2はやっぱり実装が難しくなってしまった。
だからカールですら自作できなくなってしまった。
その代わり、
JavaScriptの実装は明らかに楽になったよねっていうところがあるんですよね。
見方変えると、
共通の資産として全員が使えるライブラリとして実装されていた上に、
みんなが変えるであろうアプリケーション層は、
すごくシンプルに実装ができるようになったってことですよね。
そうですね。
じゃあハッピーな気がしますね。
HP2になってみんなハッピーになったってみんなが思ったわけですよ。
なんか不穏。
ここが不穏なんですけど、
HP1.1の方が早い事例があるってことが分かっちゃったんですよ。
おっと?なぜ?
これヒントはインドなんですけど、
確かGoogleの論文がインドだったと思うんですけど、
インターネットが不安定な国、
インド以外にもいろいろあると思うんですけど、
インターネットが不安定な国だとHP2よりHP1.1の方が早いよね、
っていう論文が出ちゃったんですよ。
インフラが整ってなかったりとか、
あとは単純にインターネット回線が弱かったりとか、
そういうことなんですかね。
そういうことですね。
なんでかっていうと、
HP1.1の時ってコネクションが例えば6個ありましたと。
しかも1個1個リクエスト送ってるんで、
そのTCPのパケットがドロップしましたって時に、
今送ってる最中のリクエストだけ再送すればよかったんですよ。
位置並列だし。
シンプルだからこそそういうことができたってことですよね。
そこだけ再送すればいい。
し、6個コネクションあるから、
6個あるうちの1つが例えばブロックしましたとかだったら、
その全体が影響受けるわけじゃないんですよね。
確かに。
HP2だと1個しかコネクションがなくて、
そこにたくさんのリクエストレスポンスが並列で動いてる。
で、1個パケットドロップしましたってなった時に、
今やってる最中のリクエストレスポンス、
全部再送になっちゃうんですよ。
逆に無駄ってことですよね。
再送が走っちゃうと、逆にHP1.1より遅くなっちゃう。
むずいな。
これが、さっきHDPのヘッドオブラインブロッキングって言ったんだけど、
HP2の方は、HDPの方は解決したんだけど、
TCPのヘッドオブラインブロッキングが残ってるよねっていう批判があったんですよ。
24:02
ほうほうほう。
TCPで詰まっちゃうと、もう全部詰まっちゃうよねっていう。
そもそもねっていうような話が出てきたと。
HPレイヤー解決したけど、TCPレイヤー解決してないじゃんって批判があったんですよ。
単純に1.1はシンプルだからこそ対障害性が高かったんだけど、
2の方は複雑になったからこそ障害性がちょっと置き去りになってしまったみたいな。
パケットドロップ、ちょっとドロップした時の影響がデカい。
賢い仕組みにしたからこそ。
これなんか先にわかったんでは?ってなんとなく思っちゃうんですけど、
そういうもんでもなさそうなんですかね。
どうなんですかね。その辺の時系列はちょっと自分も把握してないんですが。
先進国だとHP2、前進のスピーディのやっぱり効果が大きかったんだと思うんですよね。
いいところだけ見て、これめっちゃいけるやんって思ったって感じ。
とりあえずTCPが安定してる国だったらめちゃくちゃ良くなるから、
とりあえず実装しようぜっていうノリだったかもしれない。
ちょっと時系列を把握してない。
それはわかるって感じがしますね。
実際だって我々のJavaScriptのフロントエンドの実装は大きく変わったんで、やっぱり効果はあったと思いますよ。
大部分の国とか地域とかではかなりインターネットがやりやすくなったんだけど、
そういったインフラが整ってないところだったら逆にやりづらくなってしまったっていうところなんですね。
難しいですねこれ。
いつも開発者の人は高機能のiPhoneだったりとか最新のiPhoneとかMacとか使ってるから、
気づけない問題みたいなのも普通にサービスとしてあるかなと思うんですよ。
あとはWi-Fi環境しか開発者いないから通信は速い前提でいるみたいな。
そんな感じがちょっとレイヤーは違うけど起きたのかなっていうのが若干感想なんですけど。
かもしれないですね。
そこに対する解としてできたのがHP3なんですよ。
そういう流れなんですね。
そういう流れです。
なるほど。今の話で聞くと対障害性がすごく高まったんじゃないかなってさんでは思うんですけど。
さてどうなんでしょうか。
っていうのでHP3に行きますと。
はい。
HP3は結構複雑で、
まずさっきクイックって言ったんだけど、
もともとGoogleが作ったのはクイックって話をしたんだけど、
これは今はGoogleクイックって呼ばれていて、またクイックは別のクイックがあって。
別のクイック。
現在HP3は結構まず、自分も頭がやりこしくなってきたんだけど、
まずGoogleクイックっていうのはもう全部入りだったんですよね。
そのTLSのハンドシェイクの数も減らすし、
27:04
UDPの上、TCPじゃなくてUDPの上で全部実装するし、
もうなんか何でもやりますみたいなやつがクイックだったんですよ。
全部仕様ぶち込んだ。
全部仕様ぶち込んで、もう俺たちの考えた最高のプロトコルだぜみたいなやつやってたのがGoogleクイックなんですよね。
かっこいいですね。
それでじゃあちょっと一個一個分けましょうってなって、
まずTLSのハンドシェイクの数少なくなったやつはTLS1.3っていう仕様にしましょうってなったんですよ。
TLS1.3のほうはTCPでも使えるんですね、今。
じゃあTLS1.3で分けましょうと。
で、プロトコルのところ、トランスポートプロトコルのところは
ITFクイック、正式名称クイックなんですけど、標準化したのがITFなので
ITFクイックって呼ばれてるんだけど、Googleクイックと区別するために。
そのITFクイックって呼びましょう。
その上のHPヘッダーとかその辺のやつをHP3って呼びましょうみたいになったんですよ。
ただHP3って言ったら全部入りなんだけど、基本的に。
なんか分割していったんですね。
実際に。
仕様を細かく分割して、これはこういう呼び名みたいな形で全部分割して実装をしていくっていう。
実際に標準化していくにあたって、一個一個分解して一個一個実装していきましょう。
特にTLS1.3に関してはTCPのほうでも使いたかったんで、これは別でちゃんとやりましょうっていうふうになったんですよね。
なんか良さそうですね、それを聞く感じでは。
なので一個一個分けて実装されましたと。
なのでクイックっていうと、GoogleクイックとITFクイックってまた別の概念が二つあってややこしいことになってるのと、
あとHP3の設定するときもクイックって設定上呼ばれてることとかもあるんですよ。
ややこしいですね。
これ見たらプレイヤーとかソフトウェアによっても違うんだけど、基本的にはHP3とクイックは同じものだって思ってもらっても特に問題はない。
ただクイックって書いてあるときはこれHP3のことだなっていうふうに理解できるようにしておく必要はある。
そのときクイックって書いてあるときにそれはGoogleクイックなのかITFクイックなのかって若干違うってことですよね。
ただそれを区別する必要は実はなくて。
なんでかっていうと今のChromeはもうGoogleクイックを実装してないからです。
ITFクイックを実装してるってことですか。
今はITFクイックとかHP3しか実装されてなくて、今のブラウザーはGoogleクイックは使えないようになってるんですよ。
なるほど。
なのでGoogleクイックの実装があったとしてもその実装は動いてないはずなのであんまり気にする必要はない。
じゃあクイックって今新しい文章で出てきたら基本的にはHP3だし。
30:05
そもそもGoogleクイックはGoogle以外ではほとんど使われてなかったので、あんまり我々が目にするところでGoogleクイックは出てこないと思いますね。
なるほど。
FacebookとかGoogleクイックは一時期使ってたけど本当にそういう会社だけだと思いますね。
なるほど。
HP3じゃあどうするのっていうところで、さっき言った通りTCPだとTCPのパケットがドロップしたらどうしようもないのでUDP使うっていうのがHP3の特徴なんですよ。
UDPの上で全部やる。TCPがやってることも全部やるし、TLSハンドシェイクも全部UDPの上で自分たちで全部やる。
なのでアプリケーション側で全部一個一個やりましょうっていう風になってるんですよ。
なのでパケットが例えばドロップしましたって時にクライアント側でどのデータが足りないのかっていうのを見て、足りないデータだけサーバーに再送してくださいってお願いするんですね。
クライアントからお願いするんですね、サーバーに対して。
HP3の実装完全にやってるんで自分たちで。そこでここのデータが足りないってわかるんですよ、クライアント側は。
なのでサーバー側に聞けば要は再送処理っていうのが最低限できるっていうのがHP3なんですよ。
復帰ができるってことですね。
クライアントが自力で復帰できる。この時点で実装がヤバそうだなっていう匂いは感じ取ってほしいところなんだけど。
単純に何往復もしないといけなさそうだなと思うんですけど、単純にサーバーからクライアントがダウンロードするだけじゃないですか。
もうその時点で何回もやり取りしてるのかなというのがそのリクエストの中で。
パケットをドロップしなければ最低限のやり取りで進みますよ。
なるほど。失敗した時の。
失敗した時のやり取りが最小限になってる。
やっぱりRTTって言うんですけど、やり取りの回数、サーバーとクライアントの間のやり取りの数って0.4に直結するんですよ。
なのでそこの数をできる限り減らすっていうのがHP3の一番重要なところ。
HP2とかだとまずTCPのコネクションを作るためにTCPで3wayハンドシェイクしますと。
でTCPのコネクションできました。その後にもう一回TLSでまたハンドシェイクするんですよ。
なのでTCPでハンドシェイクした後またTLSでハンドシェイクするので、このハンドシェイクも全部一緒にやったらいいじゃんっていう。
TCPとTLSのハンドシェイク一緒に同時にやったら一番早いじゃん。
33:01
っていうのがHP3なんですよね。
なのでサーバーとクライアントのやり取りの回数を減らすっていうのもHP3のやってることなんですよ。
3の場合はできる限りやり取りを少なくするっていうところが大きく置かれてたってことなんですけど、
2の時はそのやり取りを少なくするっていうのは大きく置かれてなかったんですかね。
そっちは大きく置かれてなかったというか、大きく置かれてなかったんですけど、
そこを改善するじゃなくてHPの改善だったんですよHP2は。
なるほどね。レイヤーが違うってことね。
だからTCPとTLSは触んなかったんですよHP2は。
ここはやらないよ2ではみたいなことだったんですね。
今はTLS1.3が使えるのでTLS1.3とHP2の組み合わせが一番多いと思うんだけど、
TLS1.3とHP2の組み合わせであればTLSのハンドシェイクの数は減る。
うんうん。
だけどそれはHP2とは関係がない。
なるほど。
だけどこれって重要でTCPだったらLinux kernelの機能を使えば割と簡単にできるし、
TLSだったらOpenSSLとかそういうのを使えば割と処理丸投げできるんですよ。
うんうん。
なので自分で実装しようと思った時にまだ実装が想像できるじゃないですか。
なんとなくレベルですけどそれは。
だけどHP3だと同時にTCPでやっているようなハンドシェイクとTLSのハンドシェイク同時にやらないといけないんですよ。
はい。
なのでTCPのこともTLSのことも全部ちゃんと分かっている人じゃないとHP3は実装できないんですね。
複数レイヤーにまたがった知識を持っていないとその使用を満たす実装ができないってことですね。
そうです。
やっぱり我々プログラマーとしてクラス分けとかしてここの処理はここが全部やっているからこっちの関数では無視するとかやるじゃないですか。
やりますね。ここの責務はそちらさんが持っているからこっちの責務だけ頑張るよ、我らはみたいな感じですよね。
そうです。HP2は完全そういう感じなんですよね。TCPはTCPのやつに任せるしTLSはTLSに任せるしって感じなんですよ。
でもそっちの方がいいですよね。
どう考えてもそっちの方がいいじゃないですか。HP3はもう完全に逆なんですよ。
全部やってやる。
全部JWANがやったら一番早いっていう。
そりゃそうだけども。
そりゃそうだけどめっちゃ大変じゃんっていうのがHP3なんですよ。
なるほどなんか大変ですね。
HP3は実装が圧倒的に大変っていうのが特徴です。
なるほど。
HP2でも大変だったのにHP3はそれを遥かに上回る大変さです。
これエンジンXではどうなってるんですかね。
エンジンXも結構時間かかったんですよ実はHP3実装するのに。
正直各ソフトウェア結構HP3時間かかりました。やっぱりあまりにも複雑すぎるので。
実際実時間というかどのぐらいで3が提案されて、エンジンXで追いついたみたいなのってどのぐらいかかったとかって分かったりします?
36:11
パッと分からないしHP3そもそも策定もすっごい時間かかってるんですよ。
なるほど。
仕様が完全にフィックスするのにも相当時間かかったんですよ。
それがHP3で、しかもHP3ってすごいバージョンがたくさんあってやっぱりその仕様をどんどんどんどん変えていったので、
やっぱこれよくないわこうするわみたいなのがたくさんあったんで、だから実はバージョンがたくさんあるんですよね。
3といっても。
HP3の中にまたバージョンがある。マイナーバージョンみたいなのが内部にあって。
3.1とか3.2とか名前がついてるわけではないってことですよね。
ではないです。やっぱそれってHP2にはなかった概念なんですよ。
その内部のバージョン。
HP2には内部のバージョンという概念はない。
もうちょっとシンプルだったんですね。
そうですね。
あくまでも。
なのでHP3はそういうところもあるし、じゃあバージョン違ったらどうするのって話あるんだけど、
クライアント側はバージョン違ったらHP3使わないです。
それはクライアント側がサポートしている3の内部バージョン。
内部バージョンが対応しなかったら、じゃあHP2でやるからいいですってなる。
なんか潔く諦めるんですね。
諦める。だからHP3はサーバーの実装も頑張ってついていかないとすぐ使えなくなっちゃうんですよ、クライアント側で。
クライアント側の、例えば3のバージョンAとかがサポートしてますと。
バージョンAに対してサーバーもちゃんとサポートしてるから3でコネクションできるんだけど、
次、来週にはバージョンBがクライアントでしか対応してないから、
その次の週からHTTP2になっちゃったみたいな、そういうことが起きえるってことですね。
HP3はクライアント側も早いから実装が。
だからサーバー側もそれについていかないとどんどんどんどん使えなくなっちゃうんですよ。
クライアント側でこのバージョン、例えばAからCまで対応してますよみたいな、複数バージョン対応するみたいなことないんですか?
確かにいくつか対応してるはず。2、3個ぐらい常に対応してるはずですね。
そうじゃないといきなり全部使えなくなっちゃうから。
全部一気に消えるってことはないんだけど、やっぱり2、3個とかなんで実装放置してるの。
やっぱりHP3やるんだったら常に実装ついていく気でやらないといけない。
覚悟が必要ですね。
私、例えば結構勘違いしてる人いるなと思ってるのが、
AndroidアプリとかiOSアプリでHP3って今簡単に使えないんですよ。
YouTubeアプリとかHP3使ってるんだけど、それはYouTubeアプリがHP3のクライアントを自慢で実装してるんですね。
39:05
そういうので、たまにAndroidとかiOSアプリからHP3が使える便利な仕組みが今後出るといいですねみたいなこと言ってる人いるんですけど、
これって間違っていて、HP3は完全に逆なんですよ。
なんでHP3がTCP辞めてUDPに行ったかっていうと、TCPはOSレイヤーで全部やるんですよね。
例えばAndroidだったらAndroid OSがアップデートされたらアップデートされるよねっていう。
というかそのTCP自体が基本的にOSがやるものなんですよ。TCPレイヤーの処理って。
なのでTCPレイヤーの処理っていじれないんですよアプリケーションから。
触れる範囲外で。
触れる範囲外なんですね。それが嫌だって。HP3はOSにやらせたくないっていう。
OSのやる範囲をできる限り減らしたかったんですよ。
全部アプリケーション側でやるぞと。
全部アプリケーション側でやるぞっていうのがHP3なので、
だからAndroidとかAppleがいい感じの仕組みを出すって期待してること自体が間違ってるんですよHP3に関しては。
それでいうと便利なAPIを用意するは正しいかもしれないって感じなんですか?
AndroidとかIOSで。
Androidとかに用意しちゃうとAndroidのバージョンアップしないとそのHP3が更新できないってことになるじゃないですか。
これはHP3の概念としてダメなんですよね。
OSだとなかなか変わらないからちゃんとアプリケーションレイヤーで実装真面目にやりなさいっていうのがHP3なんですよ。
じゃあOSで提供されてるAPIで対応するんじゃなくてライブラリとして対応していくっていうのが基本的。
ライブラリを自分たちのアプリに組み込んで使用するっていうのが大前提なんですよHP3の。
アプリケーションごとにちゃんと対応してねっていう感じなんですね。
自分でやってねっていう。
OS側の仕組みは絶対頼らないでねっていう。
だってOS側だとバージョンアップできないでしょっていう。
すごい世界観が強いですね。
全然世界観違うから。
だから結構AndroidとかIOSの人でそういうこと言ってる人たまに見るんですけど、そもそも全然考え方が違いますHP3は。
なんとなく個人的な考えで言うとOSに任せられるところは任せたいですけどね。
ちょっと思想が違うという。
そこが違うところがHP3なんですよ。
逆にOSに任せたくない。
そういう人もいるんだって感じなんですけど。
だからHP3は本当にそういう感じなんですよ。考え方として。
なるほど。
じゃあHP3導入しますってなったとするじゃないですか。
まず最初にちゃんと知っておかないといけないのはHP2はTCPだけどHP3はUDPだったところです。
42:01
なので最初の通信でTCPで通信した時点でもう負けてるんですよね。
負けている。
だってHP3絶対通信できないじゃないですか。最初にTCPで通信しちゃったら。
けどそのドメインがHP3に対応してるかわかんないからいきなりUDPで通信するっていうのはありえないですよね。
そもそも確認取れてないですか。
確認取れないから。だからどうやるかっていうとまずTCPで通信しますと。
一発目は。
で、ALPNでHP2が返ってきましたってなったらHP2で通信開始するってさっき話したじゃないですか。
その後にHP2のレスポンスの中にAltSVCヘッダーっていうヘッダーが入っていて
ここでHP3使えますよっていうのが入ってたらブラウザーはこの人HP3使えるんだって判断するんですよ。
めちゃくちゃややこしいじゃないですか。
だから最初HP2で通信してヘッダー返ってきたらHP3使えるじゃんって言ってHP3で通信が走る。
それ1.1から3に行くことはないですか。
ありえるはありえるんだけどブラウザーがそれを実装してるかっていうのはまた別の問題なんだよね。
1回2挟まないといけないんですね。
HP2はALPNでTLSのレイヤーで判定できるんでHP1.1は挟まなくていいんですよ。
うん。なるほど。すごいややこしいんですけど。
すごいややこしいことになってるんだけどここはちゃんと理解しておかないといけないところでまず最初は絶対にHP2のリクエストが走りますと。
つまりサーバー側ではHP2とHP3どっちも対応しないといけない。
どっちも対応しないといけない。
なるほど。
ここがすごい特徴というか実際に有効にするんだったら絶対に知っておかないといけないところではありますね。
そもそも通信できませんよって。
そもそも最初から通信できない。
知っておかないとそもそもお話にならないよというお話な気がしますね。
そうですね。Chromeのネットワークタブとか見てもらうとHP3有効にしたとしても最初は絶対HP2で始まってリロードするとHP3になるみたいな感じの動きするのでこの辺は知ってないと動きがわからないですね。
オルトSVCヘッダーは有効期限みたいなのが設定できて指定しなかったら確か24時間有効になるんですよ。
なので一回通信してHP3使えるんだってなったらブラウザは24時間そのことを覚えていてくれる。
なんですけどもうこの時点で最初からHP3通信したいんだけどってなるじゃないですか。
シンプルじゃないんでやりたい。
けどそんな方法あるって話があって。
45:05
そもそも通信する方法ないよねっていう。
じゃあ最初にまずどう通信してるか紐解きましょうっていうところでまずドメインがありますと。
DNSでそのドメインのIPアドレスを教えてくださいって言ってIPアドレスを教えてもらうじゃないですか。
そのIPアドレスに対してまずTCP接続してTLSハンドシェイクしてHTTP2で通信するわけじゃないですか。
ってことは最初DNSでIPアドレスを教えてもらったじゃないですか。
これIPアドレスだけじゃなくてIPアドレスとHP3使えますよって情報両方をDNSの段階で教えてくれたらHP3でいきなり通信できるんですよ。
そこにメタデータ挟み込めるなら。
DNSしかないんですよ実はTCPの通信始まる前に通信してるのはDNSだけだから。
そんな方法あるのっていうと実はHTTPSリソースレコードっていうのがあってDNSにそういう仕様が追加されました割と最近。
じゃあDNSで教えることができるんですね。
DNSでHTTP3使えるよって情報が教えることができます。
すごい便利。
そうなんですよ。
HTTPSリソースレコードは結構使えるDNSサービスがまだ少なめです。
あとやっぱりブラウザーじゃないと基本的には使えないと思った方が良い。
もちろんCURLとかでは使えないし。
CURLはオプション有効にすれば使えるんですけど多分有効になってる環境あんまないと思いますね。
やっぱOSのデフォルトのDNS解決のAPIとかもあるんだけどそういうのってHTTPSリソースレコード基本対応してないので
そのシンプルにOS側でシンプルに作った仕組みっていうのは基本的に対応してない。
なので本当にブラウザ専用といっても過言ではないですね現状だと。
まあまあでもだいたいブラウザで使われるよねみたいなところでそこは妥協の範囲内みたいな感じなんですかね。
ただやっぱり今までってAレコードとかCDMとか設定したわけじゃないですか。
その設定は絶対消せないんですよ。
ブラウザ以外からの通信がそこを見てるはずなので。
それはそうですね。
だからHTTPSリソースレコードの設定してもいいんだけど
別に既存の設定が消せるわけではないっていうのは意識する必要がある。
それは確かにそう。
なのでHTTPSリソースレコードを使えば最初からHP3で通信するっていうのは一応できるようにはなっている。
仕様上は。
その言い方だと対応しているところがめちゃくちゃ少ないってことですよね。
その使えるDNSサービスが少ないっていうのと
あと実際に有効になるかどうかが
ブラウザによって今まちまちでこの設定をこうしないと使えないとか
そういう細かい条件が他にもいくつかあるので
48:02
設定しても動かないが全然あり得る。
フューチャーフラグをオンにしないといけないとか。
そのフェーズはもう抜けていて
例えばFirefoxだとまた話が変わるんですけど
DNS over HTTPSっていうやつを有効にしないと有効にならないとか
いくつか追加の設定しないと動かないんですよ実は。
普通に一般人の人が使える話ではないってことですね。
簡単に設定を有効にすれば簡単に使えるようになってるんだけど
一応そこをわざと有効にする人はそういう知識がある人だけだと思いますね。
開発者だけでしょ。
そうですね。
なのでこの辺りは結構まだ本格的に使えてる人はあんまりいないかなってところですね。
なるほど。
ちなみに岡田辻さん自分でVPSとか契約して
Nginxとか立ててるって何回か話してたんですけど
そこら辺では2とか3対応してるんですか?
めちゃくちゃやってますよ。
HPSリソースリコードってコロコロ使用変わるし
実際試さないとブラウザーが本当に使えるのかとかわかんないんで
なんで自分がSakuraのVPSを契約してやるかっていうと
このHPSリソースリコードの挙動確認と言っても過言ではないんですよね。
そこの確認のために契約してるんだ。
そこの確認のためにやってます。
なるほど。めちゃくちゃ面白いですね。
それぐらいキワというか最先端の仕様なんで
挙動がよくわかんないことになりますね。
なるほど。コロコロ変わるしコロコロバージョンアップもされるし
クライアント側の実装も変わるしってことですよね。
そうですね。あとHP3でやっぱ大事なのってUDPを使ってるので
UDPって結構企業のネットワークだと使えないことあるんですよ。
それはブロックされてるってことですか?
そもそも対応してない。ISOセキュリティだったりとか
単純に面倒くさいからかもしれないけど
対応してないってネットワークって実はUDPってあるんですね。
はい。
なのでその場合ってHP3ってもちろん使えないんですよ。
なのでブラウザー側はHP3で通信できるって言われても
HP3で実際通信してみてうまくいかなかったら
やっぱりHP2のままにしましょうみたいになるんですよね。
フォールバックしてくれるってことですよね。
それはブラウザーが自動でやってくれるんだけど
逆に言うとブラウザーはそういうのをちゃんと考えないといけないんですよ。
HP3が使えないかもしれないってことを
常に考えて動かないといけないんですよ。ブラウザー側は。
なるほど。それがブラウザーだったら良いけど
自分が実装してるアプリでHP3を使うコネクションを使いたかったら
そこまでサポートしないといけないってことですね。
そこまで考えないといけないってことです。自作しようとすると。
YouTubeアプリはそこまで考えているということですか?
YouTubeアプリはやってますね。
YouTubeアプリって結構大量に動画を流すから
結構大量に通信するんですよ。
そこがパケットをドロップしたら止まっちゃったら
51:00
今日ダメじゃないですか。動画って。
だからめっちゃ頑張ってるんですよ。YouTubeアプリは。
そこがコア機能だから頑張ってるってことですね。
そうなんですよ。
それは分かる。
なのでYouTubeアプリぐらいやる気がないと
結構難しいんじゃないかなとは思ってますね。
そもそも使用策定にGoogleが関わってるしねっていうのもあるんですかね。
GoogleがYouTubeで使いたいから頑張ってやってたといっても
過言かもしれないけどそういう要素もありますって感じですね。
なるほど。
それにUDPなのでHP2に関しては
正直今ブラウザーの利用率ってほぼ100%に近いというか
ブラウザーがHP1.1を積極的に使うことないんですよ今。
なのでHP2の普及率ってブラウザーに限ってだけど
ブラウザーに限って言うと超高いんですね。
けどHP3の普及率っていうのは正直HP2に比べると全然。
なんか今の話聞いてると全く使われてないんじゃないかなと若干思ったんですけど
そうでは全然ないですね。
HP3有効に最近できるCDNサービスも増えてきたし
全然有効にすればどんぐらいかな半分ぐらいですかね。
一応使えるは使えるしやっぱり日本国内だとあれかもしれないけど
やっぱ海外のネットワークが弱い国とかだったら
多分如実に変わると思うんですよパフォーマンス。
なるほど。
なので意味はあるし実際利用率もそこそこあるんだけど
ただHP2ってほぼ100%利用できるから
それに比べると利用率っていうのはそんなに高くないし
今後もHP2より高くなることは多分ないんじゃないかなって自分は思ってたりしますね。
なるほど。
ちなみに2の頃のデメリットだったインドだったりとかの
通信がちょっと弱いところで3を使うと結構快適なんですかね。
快適だって言われてますね。
そこの問題はかなり解決して。
先進国だとHP2とHP3のパフォーマンス差はあんまりないんだけど
やっぱりそういうネットワーク不安定な国だと
与実に変化が出るっていうのはGoogleが論文出してたと思いますね。
じゃあ実証実験もできてるんですね。
HP3はやっぱりそういう国にとってはすごく嬉しいっていうのは出ているけど
やっぱりUDPだから通信できない環境はたくさんあるし
今後も全部の環境で通るってことは多分ない。
使い所ってことですよね。
GoogleとしてもYouTubeをそういうインドとかネットワークが弱いところに対しても
ちゃんとサービス提供したかったからこそ
この3とかを作っていってっていうような背景がありそうですね。
そうですね。
それだけではないと思うんですけど結構そういうのが大きいと思いますね。
そう見ると確かに正当だなという気がしますね。
しかもアプリケーション側でちゃんとカバーできるようにするっていうのも
理にかなってるなという全てをコントロールしたいからね。
54:03
そういう細かい部分まで。
っていうのは確かにそうだなという気がしてきましたね。
ここまでの話でわかったと思うんですけど
HP3のほうが常にいいっていう
HP3はHP2の関連上位互換だっていうわけでは決してないんですよ。
やっぱり低遅延とか安定したネットワーク環境だと大差ない。
パフォーマンスとしては大差ないって言われてるし
サーバーサイド側の実装も大変。
TCPってOS側で実装してるから
そのCPUとかも使わないんですけど
UDPだとまだあんまり使われてないからUDPって
そのTCPほど最適化
Linux Kernel側での最適化もあんまり進んでなかったりもするし
あとUDPで
OS側UDPだけでそれをアプリケーション側にコピーして
これはどうなんだって解釈してるわけじゃないですか
アプリケーション側が
一回メモリーコピーが走れるわけですよ
OSからアプリケーションに
なのでそれに本来Linux Kernel上でやってたTCPの処理みたいなのも
全部アプリケーション上でやらないといけないから
やっぱり処理に時間がかかっちゃうわけですよ
サーバー側で
やっぱCPUをHP2より使っちゃう
なのでサーバー側のスペックもすごい使うので
HP3にしたほうが常に良いっていう感じでは決してない
保管関係ですよねやっぱり3と2に関しては
2だと遅くなっちゃう環境に対してHP3が出てきたので
やっぱりHP2が弱いところはHP3を使いたいし
別にHP3でもHP2であんま変わんないんだったらどっちでもいい
実際そのデータセンターとデータセンターの間の通信で
HP3が使われるってことはだからないんですよ基本的に
なるほど
実際そのCDNも結局対応してないんですね
CDNからHP3にプロクシスするっていう機能は
基本どこのDCNも出してない
HP2とかはできるんだけどHP3はないんですよ
あくまでも3はエンドユーザーのためのプロトコルだよね
エンドユーザーのためのプロトコルでデータセンター間の通信とかに
使われるプロトコルではないHP3は
そういう用途じゃねえよっていう
そういうのが意識しないといけないってなりますね
2とか3とか番号ついちゃってるから進化系って思っちゃうけど
そうじゃないですね
そうではないですね
本当に保管関係ですね
もうちょっとうまい感じで名前つけてくれよとなんとなく思うんですけど
しょうがないですね
HP3しかなかったんじゃないかな
一応いろいろ議論はしてたんですよ実はHP3って名前にするかどうか
一応議論いろいろして結局HP3って名前になったんですよね
57:00
なるほど
やっぱりそのTCPですらないからHP3って名前でいいのかみたいな議論は
確かあったと記憶はしてるんですけど
結局HP3って名前になりましたね
なるほど
ちなみにここまで来て若干気になるんですけど
4はあるんですか
今のところ4の予定は多分なくて自分の把握してる限りはなくて
HP3の中でどんどんバージョンアップしてるんですよ今
確かにそれが今活発に行われてるから4の議論にはいかない
まだHP3自体がまだ全然完成してなくて
例えば完成してない具体例で言うと
自分があんまりUDP好きじゃない理由なんですけどここが
例えば我々って今インターネットを使ってるわけじゃないですか
あれってインターネットのルーターを通って通信してるわけじゃないですか
なんでそのTCPだったら
例えばTCPをクローズしました
例えば通信終わったんでTCPクローズしますっていう処理があるんですけど
そしたらクライアントとサーバーはもちろん破棄していいじゃないですか
そのコネクションは
もう通信しないんでやめますみたいな感じで
けどクライアントとサーバーだけじゃないんですよね
ネットワークを解釈しないといけないのって
その間のルーターとかもTCP解釈しないといけないわけですよ
確かに
実際に我々のPCが通信してるのってそのルーターだから
はい確かに
ルーター側はTCPクローズされたらルーター側もTCP破棄できるわけじゃないですかコネクション
けどUDPにクローズってしようはないんですよ
ずっと保持しないといけない
UDPはずっと保持しないといけない
だからHP3にはクローズみたいな必要はあるので
HP3で通信終わりましたってなったら
サーバーとクライアントはコネクションもう殺すんですよ
捨てちゃう
けど間のルーターはUDPでなんか通信がーってして
なんか通信止まったけど
これ今後まだ通信来るかもしれないから保持しないといけないんですよ
めちゃくちゃ無駄ですね
ルーターはUDPタイムアウトまで待たないといけないですね
そのタイムアウトを具体的には
そのルーターによると思いますね
実際によるってことですね
ただUDPの使用上通信来るかもしれないから
本当あんまり切っちゃいけない頻繁に切っちゃいけないんですよ
切っちゃうとそこでコネクション切れて
結局次もっかい繋ぎ直しになっちゃいますもんね
だからあんまり頻繁に切っちゃいけないんで
結構長くなってるほど多いですね
ルーターのメモリもCPUもなんか使うしみたいな感じですね
実際結構弱いルーターだと一瞬で死にます
HP3の通信増やすと一瞬で死んじゃいます
CPUが上がっちゃって
CPUのメモリも足りなくて
それってルーターのメモリとかCPUとかめちゃくちゃ使って
エンドユーザー側の環境の問題なのでめちゃくちゃ難しいかなと思うんですけど
そうですね我々が見てないわけじゃないですか
我々ってサーバーとあとブラウザー側の実装しか見てないから
その間のルーターってわからないんですよね
けどそのユーザーのルーターが実は動かなくなってるかもしれない
1:00:05
ありますよね
全然あるんですよ
UDPはどうしても使用上そうなるし
あとこれってやっぱその思想の問題もあって
HP3はプライバシーもすごい気にしてるんですよ
なのでそのユーザーとサーバー以外に対して
どういう通信してるか一切見せたくないみたいな考えを持ってるんですよ
ルーターはあくまでもただのトンネルでそこに対して介入するなと
介入するなって言ってるから
だからクローズしたその通信が終わりましたって情報すら渡しないですよね今って
なるほど
それはいい
一応今RFCで動いてると思いますね
そのHP3がクローズしたらUDPもちゃんとクローズする
そのルーターにクローズしましたよって情報を伝えられませんかっていうのを
標準化で頑張ってる人とかはいるはず
なのでやっぱりそういうHP3はまだ発展途上ではあるんですよ
まだやらないといけないことたくさんある
普通にその感想として今聞いた話の感想として
例えばインドだったりとかそういうインターネットが弱い国
インフラがまだ整ってない国のルーターって弱いんじゃねと思っちゃったんですけど
と思いますよ
なので正直結構いろいろ問題起こってるんじゃないかなとは思ってますが
どうなんですかね分かりません
すごい難しいところですね
じゃあ本当に最善を尽くすならルーターも強いやつを買えということですね
そうなる今だと
あとインドとかそういう国以外でも日本人でも日本でいたとしても
携帯電話って移動してたらIPアドレス変わるわけじゃないですか
その基地局が変わって
コロコロ変わりますね
コロコロ変わるじゃないですか
HP3はそういうのもちゃんと対応してて
IPアドレスが変わっても接続維持できるみたいな機能があるんですよね
なのでそういうモバイル回線を前提にした機能とかもHP3はいろいろあったりする
やっぱ復帰に重きを置かれてますね
ネットワークがしづらかったりとか途切れるということを念頭に置いてます
そうなんですよ
なのでやっぱり現代に即したプロトコルではあるんですよね
そういうところすごい頑張ってるっていうのがHP3ですね
やっぱりHTTP3でやりたいこととして
すごいネットワークが弱かったりとか
ネットワークが寸断されてしまう
そもそも常時つながってるとは限らないみたいな
デバイス向けにちゃんと設計されているんですね
そうですね
将来的に今はまだこなれてないだけで
今後より良くなっていくんだろうなというのが
若干未来明るいなという気がしてきましたね
ただやっぱり家庭のルーターとかって更新が遅かったりするんですよ
1:03:00
なのでそういう仕様がもし出てきたとしても
じゃあ家庭のルーターはそのために買い替えるかっていうと難しいし
やっぱりここがインターネットの難しさなんですよね
ハードウェアのアップデートって言うと難しいよね
HP2とかHP3の文脈だとミドルボックスって呼ばれてるんですけど
クライアントとサーバーの間にもいくつかいろいろなレイヤーがあるよねっていう
家に置いてあるルーターもそうだし
その間のインターネットのプロバイダーの中の機器もそうだし
いろんなレイヤーが挟まってるので
それぞれでいろいろ困ってたりするんですよ
なのでそこをどうするかっていう議論もあるんですよ
例えばそのHP2だったらTCPで通信してるから
例えばそのTCPだと順番が決まってるんですよ
なのでその順番が狂ってたら絶対最早処理走っちゃうんで
インターネットプロバイダーの方で順番ちゃんと整えるみたいなことも実はやってたりするんですよね
けどHP3はもうミドルボックスの人たちは何もやるなっていう主張なので
そういうこともやられたくないんですよ
けどそうなるとそのインターネットプロバイダーの人たちからすると
これって本当に適切な実装されてんのっていう
HP3の人たちは最早最小限の最早に抑えてますよって言ってるけど
本当に全クライアントがそんな正しく実装されてるのみたいなのもあるんですよね
そりゃそうですよね
なので結構HP3は結構そのレイヤーによって結構対立があるというか
それは現在進行形であるんですよね
ブラウザーの人はこう言ってるとかCDNの人はこう言ってる
インターネットプロバイダーの人はこう言ってるみたいな感じで
結構いろいろ議論を呼び続けてるプロトコルでもあります
みんなやっぱポジションによって見方が違うんですよね
やっぱポジションによって見えるものって違うじゃないですか
なのでそれに見えるものによって結構いろいろ議論が出てきてるのがHP3だったりします
なるほど結構いい時間になってきたので
そろそろまとめていきたいなとは思うんですけど
3で3の話結構してきたかなと思うんですけど
なんかこう話してないところとかってあったりしますか
そうですねCDNとかだとHP3有効にすればもう使えますみたいな環境整ってきたんですけど
例えばエンジンXだとやっぱり割と新しいエンジンXとOpenSSL使わないと使えなかったりとかするので
やっぱり気軽に有効にできるかっていうとまたちょっと違う難しいんですよね
特に例えばAWSだったらセキュリティグループっていう設定あるじゃないですか
でファイアウォールの設定があってそこってUDPの443番ポートを明示的に開けないとHP3って使えないんですよ
だしあとやっぱLinux側もやっぱりそのUDPの運用とかってやっぱりまだ扱い慣れてない部分もあるし
1:06:04
そのLinuxだけじゃなくてさっきも言ったようにそのルーター
データセンター内のルーターもUDPちゃんと耐えられるのかっていうのはその辺からまず考えないといけないし
結構ねHP3は気軽に運用できるプロトコルじゃないんですよ実は
自分は趣味で今運用してるんだけどそれは趣味だからできるんだって
やっぱり法人って会社でちゃんとやろうとするとかなり大変
なのでHP3はもう今CDNで有効にする以外使う現実的に使う方法があんまりないっていうのが現実です
自分のところでホスティングするなっていう
そう自分のところでホスティングするのは多分もうHP3は無理じゃないかなって思ってたりします
もうその専門業者に頼めたというところですね
CDN使う専用でHP2まではエンジンXとかで自前で立てるっていうのは割と一般的だったんだけど
HP3は正直かなり難しいなのでそのインターネットがやっぱりどんどん複雑になって
気軽に各自のサーバーで気軽に立てられる時代じゃもうなくなってきてるっていうことを示してるのかなと思ってたりしますね
なるほどなんか昔だったら本当にVPSとかともすれば普通に昔のPCを自宅に置いてサーバー運用する自作サーバーみたいなのがありましたけど
そんな時代でもなくなってきてるよねこのプロトコルがどんどん進化していったらっていうところですね
HP3はもう無理だよねっていう感じですね
いい面でもあるけどちょっと寂しい部分でもあるなっていうところ
これはやっぱりインターネットの過線化していくんじゃないかなって自分は思っていて
やっぱりHP3はもう誰でも実装できるようなプロトコルじゃないし誰でも運用できるようなプロトコルじゃないから
やっぱり少数のCDNにインターネットが依存するっていう対戦になっていくんじゃないかなっていうのもあるので
それが本当にインターネットにとっていいのかっていうのはちょっと自分の中ではまだ答え出てないところではあります
クラウドフレアとかに依存しまくった結果クラウドフレアが落ちたら全部落ちるみたいな感じですもんね
クラウドフレアがなかったらもうインターネット自体使えないよねみたいな未来が結構HP3に関しては結構現実的にあり得る
結構現実的に3に関してはCDNの依存度っていうのがかなりでかいというところですね
そうですね
結構難しい問題だなと思いつつもただ2に関しては今日の話聞いた限りもかなり使いやすいというかほぼほぼ固まってきてるし
そもそもエンジンXでもパッと入れられるしっていうところで使いやすくはあるって感じなんですね
そうですね使うだけだったらHP2はそこまで難易度は高くないかなと思ってます
基本的には1.1と2を使いつつっていうようなサーバー運用がベストプラクティスかな今のところはって感じですね
1:09:03
サーバー運用は基本HP2で自前で立ててもいいんだけどやっぱりHP3やるんだったらCDN事業者にお願いするしかないですね現実的には
ありがとうございます
じゃあここまでにしたいかなと思うんですけど最後に何か一言ぐらいあったりします3と2のいいところ悪いところあったりしますか
そうですねHP2もHP3もプライバシー特にHP3はプライバシーをすごい意識して作られたプロトコルなんでプロトコルがどういう思想で作られてるのかとか
もっと深掘りすると結構いろいろ面白い情報出てくるんで今回あんまり話さなかったですけど
そういう情報もぜひ追ってみたらいいんじゃないかなと思ってます
ありがとうございますということで今回はここまでにしたいと思います
ヤオヨロズのOSSでは毎回一つのOSS今回みたいにちょっと一つではない可能性もあるんですけど
それを取り上げてそれについて片付いた返答後で技術的なところも深掘りしながら話をしていく番組になってます
今後もその名の通りヤオヨロズのOSSを取り上げていきたいなと思ってますので
ぜひお聞きのプラットフォームでフォローと高評価の方よろしくお願いします
またこの話題についても取り上げてほしいみたいなものがありましたらコメントとかで教えていただけると非常に嬉しいです
番組についての感想もお待ちしております
Xなどでつぶやく際にはハッシュタグ感じでヤオヨロズのOSSをつけてください
それでは今回もありがとうございました
ありがとうございました