QUIC通信を優先する Happy Eyeballs Version 3 の提案

HTTP QUIC 雑 internet-draft

IPv4とIPv6デュアルスタック環境において、早く通信確立できた方を使用する『Happy Eyeballs』という仕組みがあります。

「RFC 8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency」においては、次のようにAAAAレコードとAレコードの名前解決を行い早く通信確立できたものを使用するようになっています。

今回、そのVersion 3となる『Happy Eyeballs Version 3: Better Connectivity Using Concurrency』という提案仕様が提出されています。著者はAppleやGoogleの方々で、QUIC WGやTLS WGで精力的に活動されている方々です。

Happy Eyeballs Version 3

『Happy Eyeballs Version 3』の大きな特徴は、DNSのHTTPSレコードも考慮に入れて接続試行順を決めるというものです。

HTTPSレコード

まずは今回の大きなコンセプトである、HTTPSレコードの説明です。RFCにはなっていませんが「Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)」で定義されており、すでにブラウザやCDNで利用が開始されています。

HTTPSレコードにはHTTPSで接続するときに有用な情報が含まれています

たとえば、cloudflare.com のHTTPSレコードは次のようなデータが入っています。

"1 . alpn=h3,h2 ipv4hint=104.16.132.229,104.16.133.229 ipv6hint=2606:4700::6810:84e5,2606:4700::6810:85e5"
  • alpn: HTTP3対応情報など
  • ipv4hint: ipv4の接続先情報
  • ipv6hint: ipv6の接続先情報
  • ech: TLS Encrypted Client Helloの仕様で要求されるコンフィグ情報
大まかな流れ

Happy Eyeballsは次のような流れで行われます

  • 非同期 DNS クエリの開始
  • 解決された宛先アドレスのソート
  • 非同期接続試行の開始
  • 1 つの接続を確立し、他のすべての試行をキャンセルする
非同期 DNS クエリの開始

HTTPSレコード (SVCB / ) を送信するケースでは、次の順番で送信します

いずれかのDNSレスポンスを受け取った場合、「AAAAとHTTPS両方うけとる」「ipv6hintをもつHTTPSを受け取る」まで一定時間待ち、次のステップに進みます

解決された宛先アドレスのソート

試行する順番として、HTTPSレコードから得られた ECHやQUICサポート情報を優先的に並べることが推奨(SHOULD)されています。

その後、IPファミリとプロトコルをインタリーブさせて、リストを作成します。

接続の試行

リストに従って、順番に接続を試行していきます。（それぞれ「接続試行遅延」は通常250msecですが、最小でも100msecにするように書かれている）

コネクションの確立とは次のタイミングを指す

  • TCPであれば、TCPハンドシェイクの完了
    • なお、TLSハンドシェイク完了までをコネクション確立としてもよい
  • QUICであれば、QUICハンドシェイク完了

その他

今回のdraftには「Supporting IPv6-Only Networks with NAT64 and DNS64」といった項目も書かれているが、、、詳しい人に解説を譲ります、、、

また、個人的には「QUIC IPv6」「QUIC IPv4」の順番のがよさそうだけど、どういう順番でTCP/QUICをソートするのが良いんだろう....

今回はまだdraftが出てきたところで来月のIETF118で議論されることを楽しみにしてます。