HTTP/3（次世代Webカンファレンス2019）
プロトコル愛好家
W3Cのスペックとかを読んだりしている
fastlyでHTTP/3
標準化活動に参加
NTT communication R&D
NetworkからみたHTTP/3を話せる
今：PFNでロボット
それまではWebSocketなどをやっていた
HTTP/3の概説
突然HTTP/3というなまえが出たときにIETFでの印象は？
ysnysnysn つけたくなる気分はわかる。違う命名体型なきもするけどいいんじゃないか？ kazuho GoogleがQUICを運用していて、IETFがQUICを作っている。gQUICとiQUICの違いがユーザに分かりづらい。IETFにつくってるのをQUIC2にしようという話があった。それだとユーザに対するメッセージがずれる。HTTP/*でバージョン番号が変わらないとログの履き分けができない。HTTP/2.1みたいなのは2のときに小数点が使えないことは決まっていたのですんなり決まった。 HTTP3の印象
kaname ミドルボックス系のサービスと相性が悪い。NWの作りが変わる。gQUICはすでにインターネットの5-10%ぐらいは流れてる。無視できない流れ。 kazuho サーバ・クライアントを持っているエンドポイント屋からすると、TCPはがたが来ている。ネットの速度はバンド幅は増えたが光の速度で律速されるレイテンシが変わらない。HTTP/2で複数流れるようにしたが、がHead Of Line blockingがあるので困難になっていた。2点目は平文前提なので切断攻撃が容易なので、トランスポート層からつくりなおせるのは面白い機会 flano_yuki 受け取ったけどデータが使えない、というのはブラウザの中の人として実感があるか？ ysnysnysn パケロスがよく起きる環境でビジネスしようとすると問題がある。このプロトコルに限らない ysnysnysn 問題はいろいろある。中間でUDPがどれ位使いやすいのか？Googleで2009年にhand shake通ったけどbinary入れたら止まる、みたいなTLSだとOK,TLSじゃないと通らない。QUICってこの変動なんですか？ UDPフィルタされてるか問題について
UDP443 通らないところが数%あった。数年間実験したら1/3ぐらいになった。ただ0ではない
NAT
国単位でNATが入っているような場所がある。日本だとモバイルではNATが入っている。いつ切って良いのかわからない。keep-aliveとNATのタイムアウト値のほうが小さいとキレてしまう。これは避けるようにがんばるが、国単位で切断が起きることもある。
ファイアウォール
QUICで暗号化しているのは意図的。ファイアウォールがパケットの挙動を前提にする。syn syn-ackをNATを作る人がそれを前提にしていなかったので困った。TLSでも同じようなことが会った。一部のFWがTLS1.2前提で、1.3が通らなかった。TLS側で対応した。これからはFWや中継装置によって拡張性が阻害されないように暗号化をする、できないところはグリーシング（？）をして特定のバージョンに依存させない。エンドポイントがそういうことをやらない場合、ミドルボックスは特定のバージョンに依存した実装をすることが経験的にわかっている。このためにNATの対応は大変になってくる。HTTP/3ではNATでrebiningをしても通信を担保するようになっているので積極的にrebiningをしても動く。
QUICの特性とLBはどうやっているのか？
QUICはコネクションIDというパケットをつけることができる。LBはこのコネクションIDをみてどこにデータを振り分けか、ということになる。
ただし、いつ通信を始めたとかがわからないように、連番で発行しないようになっている
IP変わっても追跡するので、connection IDが使い回されると、ユーザトラッキングができる
共通鍵暗号をつかてconnection IDを解読すると、裏のIPが書いてあるのでそれを
F5 NetworksとRFCを作ろうと準備している
LBがQUICに対応しないと自分でやるのは難しいか？
できなくはない。
QUICは0 RTTもOK、これならRebiningに引っかかる可能性も低いので使えるのでは
ちょいちょいrebiningされるとキャリアグレードNAT側はつらい。設定によるが3-5 m.のマッピングを持つ。数千万セッションとかに成るのでかなり厳しい サーバサイドの難しさ
QUICでサービスの適用を始めた
TCPならnetstatで見られるが、QUICはmigrationのタイミングを使いづらい
NATのタイムアウトの問題は、LRUでやってくれればあとはなんとかなるんじゃない？ぐらいの考え。複数のQUICを1つのポート番号に割り振れるが、プライバシー上の問題が出る。（接続が同じ人がやっているとばれる）。サーバ側の割り振りは問題。OSがTCP接続ごとに
QUICはプロセス自体が、自分なのか子プロセスなのか判定しないといけない。プロセス間でforwardingしたりする必要がある
別のリクエストが同じコネクションに載って良いのか定義している
スロースタートから始まる問題はあるにせよ…
HTTP/3が同接続を始めるのかの補足
HTTP/2で問い合わせて、QUIC喋れることがわかったらつぎからQUICになる
（とぶ）
pass mtu
ネットのパケットのMTC1500とかは通らない
Spec上は1200になっている
1280 gQUCは1350byte
ネット屋はパケット数が減ったほうが良い
アプリ屋はパケット数がすこしふえても手間が減るならこっちを選ぶ
HTTP/2のプライオリティは未だにみんなが正しく実装しているわけではない。Chromeは最近良くなった。サーバのテストスイートも最近公開されたので全体として良くなると期待。
QUICでトラブルシュートが難しくなる（RTTが測定できない）とか。NW屋
RTT値で経路制御を入れるかというと考えにくい
kazuho パケットがロス下とかしてないとかをNW屋がみたいのか？たいていみない。特に問題が起こるようなNW屋はみない。 相手からackが帰ってこないとか見ればわかるので、平文でcontent IDを送らなくても良いという認識
暗号化しようと主張した側なのでバイアスはあるかも
IPv6を有効にすると特定の客が遊べなく成る、というとdisableにせざるを得ない
どうすればいいのか実際に使う側としては気になるけど、誰も答えを持っていない
HTTP/3とWeb
日本でパケロスがおきているところはモバイルネットワーク。新しいプロトコルが出たとき、輻輳制御のアルゴリズムが新しいのが効いて有利、同じ輻輳制御だと公平に帯域がわりあてられる（？）が、混ざるとgQUICがかっちゃう QUICで個人的にはローミングができるのが嬉しい。家を出るときにWiFiから公衆回線に切り替わる際に、通信できないタイミングができるのがなくなる。
flano_yuki Webコンテンツやゲームを作っていると、山手線とかで実地検証したりするので、そのあたりが改善されるのがよさそう GoogleはChromeベースの実装をOpenにしている。BBRとか入る。falstlyの場合はBBRはないが、CUBIC-TCPとかいろいろ選べるようになっている。NW間の公平性については面白いことになると思う。 ビデオカンファレンスはconjection controlしてもしょうがない
ちょっと乱暴でもみんなのUXがあがるならいいんじゃないか
partial reliability
パケロスが発生したらリクエスト/レスポンスがなかったことにしたい需要がある
ネットワークゲームで、3秒後に次のパケットが届いても困ったりする
HTTP/3の拡張として焦点になると思う
HTTP/3が向かない分野
DC内の通信
QUICはパケットが届いてからカーネルがアプリケーションに届けて、アプリケーションが起動するまでの時間がかかる
DC内はパケロスがほぼ発生しないので、TCPを使うのがCPUコスト的にも安い
HTTP/2に関しても同様
QUICがカーネルに入る遠い未来までは、HTTP/2とHTTP/3は共存するもの
Webの進化とプロトコルはこれからどうなるのか
kaname 低レイヤー。NWは土管化されるという話があるが、実際やってみると協力しないと動かないことがいろいろある。HTTP/3で気になるのは、CDN事業者が対応するのか、一つ一つの企業が対応するのか？ kazuho そこの分野で寡占を狙っているわけではない。そのうえでどういう機能を提供するか（fastlyならvirnish）は隠していろいろやっている HTTPの意味論（リクエストを送ってレスポンスが変える）というのは今後数十年変わらないだろう
HTTP-NGというものがあったがうまくいかず、SPDYがHTTP/2ができて…となった。通信方法だけをかえて進化されてきている。その上でpartial reliabiltyが機能追加として入ってくると面白いのかなと思う flano_yuki HTTP/3難しいとみんな思ったと思う。仲間を増やしていかないといけない。どうかかわっていけばいいか？ これから確実に使われるので勉強しておくと良いと思う
プロトコルを使うという話になるともっと多くの人（実装者以外）が関わる。固まりつつある今だから重要になる。どうやって運用するか？どうやってログを取るか？クライアントのIPアドレスを保存するのか？「使う立場になったときにどういう問題があるのか」をフィードバックがもらえると嬉しい
昔はメーリスだが今はGitHubでやっているので気軽に見てほしい