🧊

HTTP3Study に行ってきたメモ #http3study

HTTP3Study (new) - connpass

まったく詳しくない分野で脳内補完が効かないのと英語なのとで、まったく自信のないメモに仕上がりました。

間違ってたらむしろ教えてほしいです！

HTTP/3 (英語セッション) from Mark Nottingham

はじめに

  • ここは最初にWGのMtgをした部屋なので不思議な感じ
  • 仕様の解説というより、経緯とか周辺について話すよ
  • 仕様について議論してるけど、全ての実装・ユースケースを把握してるわけではない

いままで

  • HTTP/0.9
    • 今でも使われてるかも
    • `GET /`だけみたいにシンプル
  • HTTP/1.0
    • いくつかヘッダがついたりした
    • まだシンプルだったあの頃
  • 1993年とかそのへんからユースケースが混んできた
    • なのでみんな拡張をはじめた
    • UAとかHostとか
  • HTTP/1.1
    • Transfer-Encoding: chunk
    • gzip, deflate
    • うまいことやるのが難しくなってきた
    • Pipelineも思ったとおりに動かなかったり
  • どうすればよいプロトコルが作れるか
    • HTTP-NGとか揶揄されたり
    • 実装者たちは互いにコミュケーションしない
    • WGを作ってみた

SPDY -> HTTP/2

  • Googleがつくりはじめた
  • Binary Framing
    • すばらしい
  • Multiplexing
    • 多重化
  • Header Compression
    • RTT節約にも
  • Prirorisation
  • Server Push
    • あのときのPipelineと同じ
    • まだうまく利用できてない

学んだこと

  • 少しずつ拡張する作戦はよさそう
  • ぶっ飛んだ発想はうまくいかない
  • オーバーエンジニアリングだめ絶対
  • アイデアはもっと膨らませたいが実装リソースは有限

Transport HoL Blocking

  • HTTP/2はTCPの上でマルチストリームのレイヤーを作った
  • HTTP/3はQUICの上でやる
  • HTTP/2で解決できないトランスポートレイヤーの問題を解決したいHTTP/3

HTTP/3

  • ストリーム間のOrderは保証されない
  • Setting
    • 1度送られると変えられない
    • なので届く順序が問題
    • QUICの設定で代用される
  • Prioritisation
    • HTTP/2ではそれぞれが依存ツリーを持ってた
    • HTTP/3ではそれ用のControlストリーム上でやるようになった
  • Header Compression
  • HTTP/3はまだWIPの状態
    • かれこれ2年くらい取り組んでるけど
  • これからのキーワード
    • Connection Coalescing
    • Structured Headers
    • Semantic Evolution
    • CDN Standardization

HTTP/4？

  • 新しいプロトコルを作るにはそれを試さないといけない
  • それができるようにツールができてる（ALPNとか
  • ただ新しいのを作るにしても、今までできてたことができないといけない
  • HTTPは変わらない

QUIC Security (英語セッション) from Martin Thomson

QUIC

  • UDPの上のレイヤーで、一部TLSを・・みたいな図見たことあるよね
    • わかりやすいけど嘘やでアレ
    • 嘘というかもっと複雑な
  • TCPとTLSがやってるコネクションの設定をQUICがやる
  • TLSを使ってTLSのやってることをやる

Handshake

  • TLS 1.3
    • optimistic handshake
    • だいたい3way
  • QUIC
    • TLSのkeyのtypeに応じたパケットのtypeを送る
    • Initial, Handshake, それぞれACKする
  • TCP handshake
    • 3way(SYN, SYN+ACK, ACK)
    • TLS/TCPだと1RT増える
    • CryptoにCPUを使う前に確認したいから
    • QUICはそうせずただリトライする
  • DoS対策
    • ClientからのHandshakeパケットを見れば、サーバーから送ったものかがわかる
    • Retryパケットは暗号化してないそのまま返す
  • RTTが増えるパターン
    • QUIC versionが違うとき
    • クライアントを検証したいとき
    • Clientの暗号鍵が違うとき

Pakcet Protection

  • 基本的に全てだが、以下を除く
    • Version Negotiation
    • Retry
    • Initial
    • 0-RTT
    • Handshake（not fully
  • AEAD
    • Packet番号を使ってNonceをユニークにする
  • Header
    • linkableなフィールドがある
    • connID, key phrase, packet number
    • 異なるNWからなる1つのコネクションでも、それぞれをマッチできる
  • Block Cipher
    • payloadの一部を使って保護する

Unprotectedな部分

  • first 2 bits
  • version, type, length
  • Source/Destination Conn ID, length
  • Spin bit
  • Token, length(Initialパケット)
  • Retry, Negotiationパケット

コネクションの終了

  • サーバー再起動とか
  • TCPはRSTパケットがあった
    • ただしどこからでも送れてしまう
  • QUICではより安全でステートレスなやり方がある
    • connIDごとにそれようのトークンがある
    • なので送れる場所が限られるし、途中の経路からは他のパケットと一緒に見える
    • 同一クラスタ内の全サーバーが同じsecretを共有する
    • resetトークンはKDFで
    • connIDは重複・再利用しないように
    • 再起動したサーバーはconnIDでもってトークンを再計算するだけ

おまけ

QUICのここが気になる from Kaname Nishizuka

はじめに

CGN

  • Career Grade NAT
  • IPv4枯渇の対策のために
  • RFC 6888 - Common Requirements for Carrier-Grade NATs (CGNs)
  • 内部アドレスと外部ポートのマッピングテーブルが性能を決める
    • なので定期的にいらないのを消す
    • UDPなら3-5min
    • QUICはUDPとTCPの両方のセッションが発生
    • GoogleCloudMessagingは特別に10分待つ

FW

  • 95%で問題なく使える
  • UDP:443がブロックされていることも
    • 社員の通信を可視化したい企業もあるらしい

LB

  • connIDで管理
  • QICKを解釈できるLBが必要かも

既存プロトコルとの共存

識者への質問

  • 通信事業者によるトラフィックの管理は必要悪？
  • QUICが既存プロトコルを脅かさないように共存するためにはどうすれば？
    • CUBICやBBRが出てきたように、状況は今とそんなに変わらないのでは
  • HappyEyeballsはQUICでどうなる？もっと複雑になる？
    • なんらかの仕組みは必要になりそう
  • TCP MSS clampingのようにMTUを知る方法がなさそう？
    • うまくいかなそう
  • QUICライクなDDosパケットの判別方法はある？
    • ないかも