A HTTP/3 felfedezési probléma, amiről senki nem beszél

Van egy jelenet, ami mostantól millió weboldalon játszódik le: a látogató begépeli a domain nevet a böngészőjébe. A böngésző feloldja a DNS-t, megnyit egy TCP kapcsolatot, lebonyolít egy TLS kézfogást, elküld egy HTTP kérést... és csak ekkor tudja meg, hogy "hé, nekem van HTTP/3 támogatásom is!"

A protokoll, ami mindent gyorsabbá tehetne? Túl későn érkezik.

A probléma gyökere

Ez nem böngészőhiba — ez egy alapvető architekturális korlát. A hagyományos módszer a HTTP/3 hirdetésére az Alt-Svc HTTP header, ami viszont csak azután érheti el a klienseket, miután már létrehozták a kapcsolatot. Addigra viszont már elköteleztük magunkat az HTTP/1.1 vagy HTTP/2 mellett.

Belép: a HTTPS DNS rekord (RFC 9460)

Itt jön a lényeg. A 2023 novemberében szabványosított HTTPS erőforrás rekord valami nagyszerűt tesz: lehetővé teszi, hogy a HTTP/3 támogatást mielőtt a böngésző egyáltalán kapcsolatot nyitna.

Amikor a kliens elvégzi a DNS feloldást — amit amúgy is meg kell tennie — egyszerre megtudhatja:

• Milyen ALPN protokollokat támogatsz (h3, h2, http/1.1)
• Az ECH (Encrypted Client Hello) publikus kulcsait
• IP cím tippeket a korai kapcsolatindításhoz

Ez azt jelenti, hogy az első kapcsolat a weboldaladdal máris QUIC és HTTP/3 lehet. Nincs felesleges kézfogás. Nincs felesleges kör a protokoll felfedezésére.

Miért fontos ez jobban, mint gondolnád

Gondolj minden új látogatóra a weboldaladon. Nincs gyorsítótáras kapcsolatuk. Még nem tudják a HTTP/3 támogatásodról a korábbi látogatásokból. Hideg indításból kezdenek, és az öreg Alt-Svc megközelítéssel fizetik a késleltetési büntetést csak azért, hogy kiderítsék, mit támogatsz.

HTTPS rekorddal ez a felfedezés a DNS keresés során történik, amit amúgy is végeznek. A protokoll egyeztetés a kapcsolat létrehozása előtt történik, nem utána.

De van még valami: Encrypted Client Hello

A HTTPS rekord egy másik kritikus problémát is megold, amit a HTTP headerek egyszerűen nem tudnak kezelni. Az Encrypted Client Hello (ECH) magát a TLS ClientHello-t titkosítja, beleértve az SNI szervernevet. Ez megakadályozza, hogy a hálózati megfigyelők lássák, melyik konkrét oldalt látogatod.

Van egy bökkenő: az ECH publikus kulcsát mielőtt elküldenéd az első ClientHello-t kell megkapnod. De nincs még kapcsolat, amin keresztül megkapnád azt a kulcsot. Ez egy tyúk-tojás probléma, amit csak egy sávon kívüli csatorna oldhat meg — és a HTTPS DNS rekord pont az.

A HTTP headerek soha nem tudják majd kézbesíteni az ECH-t. A DNS igen.

A HTTPS rekord publikálása

Kíváncsi vagy, hogy néz ez ki? Íme egy teljes ServiceMode HTTPS rekord:

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

Szétszedve:

• pelda.hu. — A domain neved (teljesen minősítve, lezáró ponttal)
• 3600 — TTL másodpercben (meddig gyorsítótárazhatják a feloldók)
• HTTPS — A rekord típus
• 1 — Az 1 vagy magasabb prioritás ServiceMode-ot jelent (paramétereket hordoz)
• . — Célgép; pont azt jelenti, hogy "használd magát a nevet"
• alpn="h3,h2" — Támogatott protokollok, a legjobbtól kezdve
• ipv4hint / ipv6hint — Cím tippek a korai kapcsolatindításhoz

A NameOcean-nál egyre egyszerűbbé tesszük ezeknek a rekordoknak a kezelését a többi DNS konfigurációddal együtt. Ez egy további jel, hogy figyeljük, merre tart a webes teljesítmény.

Mi a helyzet a régi kliensekkel?

A HTTPS rekord publikálása szigorúan adalék. Azok a kliensek, amelyek nem értik, egyszerűen figyelmen kívül hagyják, és visszaesnek a normál A/AAAA keresésekre. Lehet, hogy lemaradnak a HTTP/3 optimalizálásról, de semmi nem romlik el.

Ez azt jelenti, hogy ma publikálhatod a HTTPS rekordot anélkül, hogy a kompatibilitás miatt aggódnod kellene. Ez egy progresszív fejlesztés — a modern böngészők olvassák, az öregebbek nem veszik észre.

Töröljem az Alt-Svc headert?

Nem. Küldgesd továbbra is.

Gondolj az Alt-Svc headerre úgy, mint tartalék megoldásra mindenre, ami nem kapja meg a HTTPS rekordodat: régi böngészők, bizonyos feloldó beállítások, vagy hálózatok, amelyek szűrik a DNS válaszokat. Ha mindkettő megvan, minden szögből fedezve vagy:

• Modern böngészők + HTTPS-t ismerő feloldók → HTTP/3 felfedezése DNS-ből, azonnali QUIC kapcsolat
• Régebbi kliensek vagy szűrt DNS → Visszaesés az Alt-Svc headerre az első kapcsolat után
• Következő látogatások → Még jobb; a HTTP/3 kapcsolatok 0-RTT-val folytatódhatnak, az első kérés már handshake nélkül a vonalon

Az összefoglaló

A HTTPS DNS rekord azok közé a ritka optimalizálások közé tartozik, amelyek szinte semmibe nem kerülnek implementálni, de értelmesen javíthatják a kapcsolat teljesítményét minden új látogató számára. Ez egy kis konfigurációs változtatás, ami a HTTP/3 felfedezést pontosan oda teszi, ahova kell: az első bájt elküldése előtt, nem utána.

Ha CDN-t használsz, nézd meg, publikálják-e már neked — a Cloudflare automatikusan megteszi a proxyzott zónákhoz. Ha saját DNS-t kezeled, a HTTPS rekord hozzáadása tizenöt perces feladat, amit a látogatóid értékelni fognak minden hideg kapcsolatnál.

A web a HTTP/3 felé halad. Győződj meg róla, hogy a DNS-ed is ott van mellette.

Szeretnéd optimalizálni a DNS konfigurációdat? A NameOcean-nál eszközöket és útmutatást adunk, hogy az infrastruktúrád a csúcson maradjon. A látogatóid első kapcsolatainak nem kell várniuk.