HTTPS DNS レコードのalpn情報からHTTP/3に繋げに行くchromiumのUseDnsHttpsSvcbAlpn feature

Current status: We are partway through a gradual rollout of the feature, to be complete in approximately one month. So Chrome will currently request HTTPS records and perform scheme upgrades accordingly for some but not all users.

commit: Support HTTP/3 protocol upgrade for HTTPS DNS records

commit:

https://chromium.googlesource.com/chromium/src.git/+/d81149603836e06f5a3aa0ba048eb376f81fa92c

コミット文より

Support HTTP/3 protocol upgrade for HTTPS DNS records

This CL introduces UseDnsHttpsSvcbAlpn feature which can be enabled at chrome://flags#use-dns-https-svcb-alpn. When this feature is enabled, Chrome will connect to the server using the HTTP/3 protocol if Chrome receives a HTTPS DNS record indicating HTTP/3 support.

This CL changes the behavior of HttpStreamFactory::JobController as follows:

Currently, if Chrome has received an Alt-Svc header from the origin, JobController creates two Jobs to compete for connection establishment. [1] Main job for HTTP/1 or HTTP/2 [2] Alternative job for HTTP/3 (Note: This job can use HTTP/2 when the enable_http2_alternative_service parameter is enabled. But this parameter is not enabled in Chrome.) The main job waits for a while before starting the race if Chrome knows that QUIC works on the current network. The waiting time is determined based on recent QUIC connection performance in QuicStreamFactory::GetTimeDelayForWaitingJob().

This CL introduces a new Job. [3] DNS alpn job: This job tries to use HTTP/3 noly if Chrome receives a HTTPS DNS record indicating HTTP/3 support. Otherwise it fails with ERR_DNS _NO_MACHING_SUPPORTED_ALPN. This DNS alpn job is created only when the new UseDnsHttpsAlpn feature is enabled, and the URL scheme is HTTPS, and QUIC is enabled, and proxy is not used, and the alternative job can’t use an existing Quic session, and Chrome has not recognised that the QUIC connection to the server is broken. If the DNS alpn job can use an existing QUIC session, other jobs are canceled. Additionally, if the destination of both the alternate job and the DNS alpn job are the same, the DNS alpn job is canceled to avoid redundant jobs. The main job waits for a while before starting, just like its current behavior.

いままでchromeには

HTTP/1 か HTTP/2 で繋げに行くメインジョブ
Alt-Svc headerを以前受け取り相手がQUIC対応していると知っている場合に繋ぎに行くHTTP/3ジョブ

の二つが競争をしていました。

今回の変更により

DNS alpn job

が追加されました。DNS alpn job は HTTPS レコード情報よりHTTP/3が使用可能であることを知っているので初めからQUICで繋ぎにいきます。

HTTP/1 か HTTP/2 で繋げに行くメインジョブ
Alt-Svc headerを以前受け取り相手がQUIC対応していると知っている場合に繋ぎに行くHTTP/3ジョブ
DNS alpn job

の三つのjobが存在しますが、実際に繋ぎに行くときは以下のようになるかと思います。

1. 初めてのサイトでHTTP/3 へ繋げられることをHTTPSレコードによって広告していない場合

HTTP/1 か HTTP/2 で繋げに行くメインジョブのみ

2. 初めてのサイトでHTTP/3 へ繋げられることをHTTPSレコードから得られる場合

HTTP/1 か HTTP/2 で繋げに行くメインジョブ
DNS alpn job

の2つのジョブが競争。

3. 以前繋ぎに行ったサイトに繋ぎに行くとき

HTTP/1 か HTTP/2 で繋げに行くメインジョブ
Alt-Svc headerを以前受け取り相手がQUIC対応していると知っている場合に繋ぎに行くHTTP/3ジョブ

の2つのジョブが競争。(DNS alpn jobは余分なjobを減らすためキャンセルされる)

2. 3. 二つの場合において、HTTP/1 か HTTP/2 で繋げに行くメインジョブはHTTP/3 を優先させるために少し待ちます。この待ち時間はQuicStreamFactory::GetTimeDelayForWaitingJob() から得られる直近のQUICコネクションパフォーマンスによって決められます。

せっかくなので３つのジョブが作られる場所のコードを見てみましょう。

この3つのジョブは chromium の net/http/http_stream_factory_job_controller.cc というファイルの HttpStreamFactory::JobController::DoCreateJobs() という関数内でそれぞれ作られています。

https://source.chromium.org/chromium/chromium/src/+/main:net/http/http_stream_factory_job_controller.cc;l=793

main_job_ = job_factory_->CreateJob(
alternative_job_ = job_factory_->CreateJob(
dns_alpn_h3_job_ = job_factory_->CreateJob(

と書いてある部分でjobが作成されているのが確認できます。

commit: Support HTTPS records aliased by CNAME records

上記のcommitのみでは CNAME レコードによってaliaseされたHTTPSレコードには対応できていなかったので対応させたというコミット。(まだきちんと理解できていないのでまた読み直したい)

コミット文

Support HTTPS records aliased by CNAME records

Currently Chrome can't use the alpn information of HTTPS records which
are aliased by CNAME records. This is because ExtractHttpsResults() is
ignoring the aliased HTTPS records.

To support such case, this CL do the followings:
1. Change ExtractHttpsResults() to allow the HTTPS record which
service name is the canonical name of the record.
2. Introduce ConnectionEndpointMetadata.target_name which keeps the
target of the metadata.
3. Introduce HostCache.Entry.canonical_names which keeps the canonical
names of A/AAAA records.
4. Change HostCache::Entry::GetEndpoints() to return the metadata only
when A and AAAA records are at the same canonical name and that
matches the metadata target name.