HTTP/3-oppdagelsesproblemet ingen snakker om

Her er en situasjon som utspiller seg på millioner av nettsider akkurat nå: En besøkende skriver inn ditt domenenavn i nettleseren. Nettleseren slår opp DNS, åpner en TCP-tilkobling, fullfører et TLS-handshake, sender en HTTP-forespørsel... og først da får beskjeden "forresten, jeg støtter også HTTP/3!" Den protokollen som ville gjort alt raskere? Den kommer for sent.

Dette er ingen nettleserbegrensning—det er en grunnleggende arkitektonisk utfordring. Den tradisjonelle måten å markedsføre HTTP/3-støtte på er gjennom Alt-Svc HTTP-headeren, som bare kan nå klienter etter at de allerede har etablert en tilkobling. Da har du allerede forpliktet deg til HTTP/1.1 eller HTTP/2.

HTTPS DNS-recorden (RFC 9460)

Her blir det interessant. HTTPS resource record, standardisert i november 2023, gjør noe bemerkelsesverdig: den lar deg annonsere HTTP/3-støtte før nettleseren åpner noen tilkobling i det hele tatt.

Når en klient utfører DNS-oppslag—som den uansett skulle gjøre—kan den samtidig lære:

• Hvilke ALPN-protokoller du støtter (h3, h2, http/1.1)
• Dine ECH (Encrypted Client Hello) offentlige nøkler
• IP-adressehint for umiddelbar tilkoblingsstart

Dette betyr at selve den første tilkoblingen til nettsiden din kan bruke QUIC og HTTP/3. Ingen bortkastet handshake. Ingen runde-tur brukt på å oppdage en protokoll du kunne brukt fra starten av.

Hvorfor dette betyr mer enn du tror

Tenk på hver nye besøkende til nettsiden din. De har ingen hurtigbufret tilkobling. De har ikke lært om HTTP/3-støtten din fra tidligere besøk. De starter kaldt, og med den gamle Alt-Svc-tilnærmingen betaler de en latensstraff bare for å oppdage hva du støtter.

Med en HTTPS-record skjer oppdagelsen under DNS-oppslaget de allerede utfører. Protokollforhandlingen skjer før tilkoblingsetablering, ikke etter.

Men vent, det er mer: Encrypted Client Hello

HTTPS-recorden løser et annet kritisk problem som HTTP-headere rett og slett ikke kan berøre. Encrypted Client Hello (ECH) krypterer selve TLS ClientHello, inkludert SNI-servernavnet. Dette forhindrer nettverksobservatører fra å se hvilken spesifikk side du besøker.

Her er catchen: du trenger ECH-offentlig nøkkel før du sender den første ClientHello. Men det finnes ingen tilkobling ennå til å motta den nøkkelen gjennom. Dette er et høne-og-egg-problem som bare en out-of-band-kanal kan løse—og HTTPS DNS-recorden er den kanalen.

HTTP-headere vil aldri kunne levere ECH. DNS kan.

Publisere HTTPS-recorden din

Nysgjerrig på hvordan dette ser ut? Her er en komplett ServiceMode HTTPS-record:

example.com.  3600  IN  HTTPS  1  .  alpn="h3,h2"  ipv4hint=203.0.113.10  ipv6hint=2001:db8::10

La oss bryte dette ned:

• example.com. — Ditt domenenavn (fullstendig kvalifisert med punktumet på slutten)
• 3600 — TTL i sekunder (hvor lenge resolvere kan bufre dette)
• HTTPS — Posttypen
• 1 — Prioritet 1 eller høyere betyr ServiceMode (bærer parametere)
• . — Målvert; et punktum betyr "bruk selve eiernavnet"
• alpn="h3,h2" — Støttede protokoller, beste først
• ipv4hint / ipv6hint — Adressehint for tidlig tilkoblingsstart

Hos NameOcean gjør vi det stadig enklere å administrere disse postene sammen med din andre DNS-konfigurasjon. Det er nok et signal på at vi følger med på hvor webytelse er på vei.

Hva med gamle klienter?

Å publisere en HTTPS-record er strengt tatt additivt. Klienter som ikke forstår den, ignorerer den ganske enkelt og faller tilbake til vanlige A/AAAA-oppslag. De kan gå glipp av HTTP/3-optimalisering, men ingenting slutter å fungere.

Dette betyr at du kan publisere HTTPS-recorden din i dag uten å bekymre deg for kompatibilitet. Det er en progressiv forbedring—moderne nettlesere leser den, eldre merker den ikke.

Bør du fjerne Alt-Svc-headeren?

Nei. Fortsett å sende den.

Tenk på Alt-Svc-headeren som en fallback for alt som ikke mottar HTTPS-recorden din: eldre nettlesere, visse resolverkonfigurasjoner, eller nettverk som filtrerer DNS-responser. Med begge på plass er du dekket fra alle vinkler:

• Moderne nettlesere + HTTPS-bevisste resolvere → Oppdag HTTP/3 fra DNS, koble til umiddelbart med QUIC
• Eldre klienter eller filtrert DNS → Fall tilbake til Alt-Svc-header etter første tilkobling
• Etterfølgende besøk → Enda bedre; HTTP/3-tilkoblinger kan gjenopptas med 0-RTT, og setter første forespørsel på ledningen uten handshake i det hele tatt

Bunnlinjen

HTTPS DNS-recorden er en av de sjeldne optimaliseringene som koster nesten ingenting å implementere, men som meningsfylt kan forbedre tilkoblingsytelsen for hver nye besøkende til nettsiden din. Det er en liten konfigurasjonsendring som plasserer HTTP/3-oppdagelsen akkurat der den trenger å være: før den første byten sendes, ikke etter.

Hvis du kjører en CDN, sjekk om de allerede publiserer dette for deg—Cloudflare gjør det automatisk for proxysoner. Hvis du administrerer din egen DNS, er det en femten minutters oppgave å legge til en HTTPS-record som dine besøkende vil sette pris på ved hver kalde tilkobling.

Nettet beveger seg mot HTTP/3. Sørg for at DNS-en din er med på reisen.

Klar til å optimalisere DNS-konfigurasjonen din? Hos NameOcean gir vi verktøyene og veiledningen for å holde infrastrukturen din på forkant. De første tilkoblingene til dine besøkende trenger ikke å vente.