HTTP3study のまとめ

HTTP3study の仕様策定のコアメンバーも来た HTTP3study の自分用まとめ
1
Kaoru Maeda 前田 薫 @mad_p

まずはMark Nottingham (mnot)さんのHTTP/3トークから #http3study

2019-01-29 19:33:32
Kaoru Maeda 前田 薫 @mad_p

mnot: ここは最初のHTTP/2 WG Interimをやった部屋なので、帰ってきたのは不思議な気がするw #http3study

2019-01-29 19:34:40
Kaoru Maeda 前田 薫 @mad_p

* mnot: 1991のHTTP 0.9はシンプルだった。まだ使われているかも * mt: QUICでつながったか確認するのに使ってるね #http3study

2019-01-29 19:36:13
Kazuho Oku @kazuho

「HTTP/0.9は今でも使われている。組み込み機器とか... そしてQUICの相互接続試験でも」 #http3study

2019-01-29 19:36:45
Kaoru Maeda 前田 薫 @mad_p

mnot: CERNでの研究ですぐにHTTP/1.0になった。プロトコルが定式化され、メタデータが加えられた #http3study

2019-01-29 19:37:35
Kaoru Maeda 前田 薫 @mad_p

mnot: 1993年~95年、スケーラビリティーの問題が出てきた。Hostヘッダを使ってサーバーをマルチホームホスティングできるようになった #http3study

2019-01-29 19:38:55
Kaoru Maeda 前田 薫 @mad_p

mnot: HTTP/1.1になるとTransfer-Encodingが追加された。chunk形式。Compression: deflateも使おうとしたが、あまり使われなかった。人々が使っているものに新しいレイヤを加えるのは難しかった。Pipelineも特にそうだった #http3study

2019-01-29 19:40:32
Kaoru Maeda 前田 薫 @mad_p

mnot: 問題はその当時のサーバーアーキテクチャに合わないことだった。パイプラインで2つのリクエストを送ったときに、レスポンスが逆順で届くことがあり、LBで困った。そのため、パイプラインはあきらめざるを得なかった #http3study

2019-01-29 19:41:43
Kaoru Maeda 前田 薫 @mad_p

mnot: 1997~1999か2000まで、W3CでHTTP-NGというグループが作られた。ほぼほぼIETF HTTP WGと同様の集まりだった。実装というよりは理論的なエクササイズで、完璧なプロトコルを作ろうとしたものだった。しかしfirewallの後ろに引っこんでしまう世界には合わなかった #http3study

2019-01-29 19:43:20
Kaoru Maeda 前田 薫 @mad_p

mnot: 10年以上もHTTP/1.1が使われている。これはあまりよいことではない。ベストプラクティスをまとめるなどの努力が続けられた #http3study

2019-01-29 19:44:04
Kaoru Maeda 前田 薫 @mad_p

mnot: SPDY → HTTP/2 。SPDYはマルチプレクス、バイナリプロトコルで、ひとつのストリームが他をブロックしないものだった。Googleが開発して使い始め、2008年のトークで将来のHTTPという話をした #http3study

2019-01-29 19:45:15
Kaoru Maeda 前田 薫 @mad_p

mnot: HTTP/2: バイナリフレーミングはうまく動いた。マルチプレクスもよい。HPACKによるヘッダ圧縮も効果が高かった #http3study

2019-01-29 19:47:10
Kaoru Maeda 前田 薫 @mad_p

mnot: プライオリィー、これはイエロー。クライアントとサーバーでどのストリームを優先するかをネゴするものだった。うまく活用する方法はまだ検討している #http3study

2019-01-29 19:47:19
Kaoru Maeda 前田 薫 @mad_p

mnot: サーバープッシュ: うわあ。いまはうまく使えていないけど、まだ終わってないよ。続くよ #http3study

2019-01-29 19:47:52
Kaoru Maeda 前田 薫 @mad_p

mnot: レイヤをいじるインクリメンタルな変更はまあ動く。根本的なモデルを変更するのはうまくいかない。オーバーエンジニアリングしたくなる誘惑が常にある #http3study

2019-01-29 19:49:04
Kaoru Maeda 前田 薫 @mad_p

mnot: そしてHTTP/3。一番重要な違いは、HTTP/2はストリームレイヤをTCPの上に作ったのに対して、HTTP/3はQUICのマルチプレクス機能を使うこと #http3study

2019-01-29 19:50:00
Kaoru Maeda 前田 薫 @mad_p

mnot: HTTP/2でストリーム間のHead-of-line Blockingは解消できた。しかし、トランスポートレイヤのHoL Blockingが問題になってきた。HTTP/3の利点の多くはここから来る #http3study

2019-01-29 19:51:05
Kaoru Maeda 前田 薫 @mad_p

mnot: データセンターの中にいるとわからないかもしれないが、ネットの弱い国に行くと良さがわかる #http3study

2019-01-29 19:51:41
Kaoru Maeda 前田 薫 @mad_p

mnot: ストリーム間の順序は保証されない。(mt: それはHTTP/2でもそう) #http3study

2019-01-29 19:52:13
Kaoru Maeda 前田 薫 @mad_p

mnot: するとSETTINGSフレームの順番が問題になってくる。SETTINGSの後に届いたフレームが、SETTINGSの前に送信されたかもしれない。HTTP/3では、多くの設定はQUICで扱われるようになった。そして一度設定したら後から変えられないようにした #http3study

2019-01-29 19:53:34
Kaoru Maeda 前田 薫 @mad_p

mnot: プライオリティーも変更された。HTTP/2では依存ツリーを両方のピアでメンテすることによって行われていた。HTTP/3ではすべての優先度設定をひとつのcontrolストリームで送るようにした。exclusive prioritisationは不可能 #http3study

2019-01-29 19:55:08
Kaoru Maeda 前田 薫 @mad_p

mnot: ヘッダ圧縮。HPACKはコマンド列である。インデックスへの追加し使用が逆順になると困ってしまう。そこでQPACKが提案された。ダイナミックテーブルは特別の単方向ストリームで更新される。エンコーダーはreferencesをackされるまで保持する。insert countを使って展開側は管理する #http3study

2019-01-29 19:57:38
Kaoru Maeda 前田 薫 @mad_p

mnot: そろそろQUICを始めて1年半か2年になるがまだできあがっていない mt: そういえばTwitterにHTTP/2をデプロイしたのはこの部屋からだったね #http3study

2019-01-29 19:58:53
Kaoru Maeda 前田 薫 @mad_p

mnot: じゃあHTTPの次は何か? HTTPの歴史はトランスポートの使い方だった。それは続くのか。 #http3study

2019-01-29 20:00:07
Kaoru Maeda 前田 薫 @mad_p

mnot: connection coalescing(相乗り)。structured headers。semantic evolution。CDN標準化。その他にもたくさん #http3study

2019-01-29 20:00:55
1 ・・ 4 次へ