HTTP/2 eller HTTP/3 – hva er forskjellen?

HTTP/2 og HTTP/3 leverer de samme nettadressene og den samme HTTP-semantikken. Forskjellen ligger først og fremst i transporten:

• HTTP/2 multiplekser forespørsler over en TCP-forbindelse.
• HTTP/3 bruker QUIC over UDP, med TLS integrert og separate QUIC-strømmer.

For brukeren skjer dette normalt automatisk. Nettleseren velger en støttet protokoll uten at URL-en eller innholdet endres. Gevinsten av HTTP/3 varierer med nettverk, avstand, pakketap, tilkoblingshistorikk og nettstedets arkitektur.

Kort sammenligning

HTTP/3 er ikke «HTTP/2 pluss høyere tall». QUIC flytter multipleksing og tapsbehandling til transportlaget, som gir andre egenskaper under varierende nettforhold.

Hva HTTP/2 løste

HTTP/1.1 brukte ofte flere parallelle TCP-forbindelser for å hente mange ressurser fra samme nettsted. HTTP/2 innførte binær framing, headerkomprimering og flere samtidige HTTP-strømmer på én forbindelse.

RFC 9113 beskriver at forespørsler og svar kan interleaves på uavhengige HTTP-strømmer. Det reduserer behovet for mange forbindelser og gjør nettverksressursene mer effektive.

Men HTTP/2 kjører fortsatt over en ordnet TCP-byteflyt. Hvis én TCP-pakke mangler, kan data etter hullet ikke leveres videre til HTTP/2-laget før tapet er reparert. Dermed kan flere aktive HTTP-strømmer oppleve venting selv om bare noe av dataen lå i den tapte pakken.

Dette kalles gjerne head-of-line blocking på transportlaget. HTTP/2 fjernet ikke denne TCP-egenskapen.

Hva HTTP/3 og QUIC endrer

RFC 9114 definerer HTTP over QUIC. Hver forespørsel og hvert svar bruker en QUIC-strøm. QUIC gir pålitelig levering i riktig rekkefølge per strøm, mens strømmer kan gjøre fremdrift uavhengig.

Hvis en pakke med data for én strøm går tapt, kan data på andre strømmer fortsatt behandles når de er komplette. Hele forbindelsen deler fortsatt blant annet congestion control og nettverkskapasitet, så HTTP/3 opphever ikke konsekvensene av et dårlig nett. Det reduserer en bestemt type unødvendig blokkering.

QUIC integrerer også:

• TLS 1.3-håndtrykk og protokollforhandling
• forbindelses-ID-er som kan støtte nettverksbytte
• strømstyring og flytkontroll
• tapsdeteksjon og retransmisjon i brukermiljøet

HTTP/3 bruker QPACK til headerkomprimering fordi HTTP/2s HPACK bygger på andre rekkefølgeegenskaper enn QUIC tilbyr mellom strømmer.

Når kan brukeren merke forskjell?

HTTP/3 har størst mulighet til å hjelpe når:

• mobil- eller trådløse nett har pakketap
• rundturstiden er høy
• siden henter mange ressurser samtidig
• brukeren bytter mellom nett, og forbindelsesmigrering faktisk kan brukes
• plattformen kan etablere eller gjenbruke QUIC effektivt

Gevinsten kan være liten når:

• siden allerede lastes raskt over HTTP/2
• brukeren er nær edge/serveren på et stabilt nett
• backend eller database står for mesteparten av ventetiden
• siden har få og små forespørsler
• tunge bilder, JavaScript eller tredjepartsskript dominerer
• UDP er blokkert eller kraftig begrenset

En protokolloppgradering reduserer ikke filstørrelsen på et bilde, antall kilobyte JavaScript eller tiden en databasespørring bruker.

HTTP/3 oppdages før det brukes

En klient må vite at et HTTP/3-endepunkt finnes. Vanlige signaler er:

• en tidligere respons med Alt-Svc
• en HTTPS DNS-post som annonserer et egnet endepunkt og ALPN
• klientens lagrede kunnskap om endepunktet

Et svar kan for eksempel annonsere:

Alt-Svc: h3=":443"; ma=86400

Dette sier at HTTP/3 er tilgjengelig på UDP-port 443 og hvor lenge opplysningen kan caches. Det beviser ikke at den aktuelle forespørselen brukte HTTP/3. Den første forbindelsen kan ha brukt HTTP/2 og lært om HTTP/3 til neste forsøk.

En HTTPS-post i DNS kan også annonsere h3, men signalet må stemme med tjenesten som faktisk svarer. Les guiden til HTTPS- og SVCB-poster før slike poster publiseres manuelt.

TLS og sikkerhet

HTTP/2 brukes normalt over TLS på offentlige nettsteder. HTTP/3 over QUIC er sikret som del av transporten og bruker TLS 1.3-mekanismene.

Det betyr ikke at HTTP/3 automatisk løser nettstedets sikkerhet. Dere trenger fortsatt:

• gyldig sertifikat og korrekt vertsnavn
• sikker applikasjon og tilgangsstyring
• oppdaterte komponenter
• beskyttelse mot misbruk og trafikkangrep
• riktige cache- og personvernregler
• logger og hendelseshåndtering

QUIC-trafikk er kryptert, som kan påvirke eldre nettverksutstyr og inspeksjonsløsninger. Oppdater sikkerhetsarkitekturen i stedet for å gjøre et ubeskyttet alternativ tilgjengelig ved siden av.

0-RTT er et eget valg

QUIC kan støtte 0-RTT ved gjenopptakelse, men tidlig data kan ha replay-risiko. Ikke aktiver eller markedsfør 0-RTT som en generell gratis hastighetsgevinst uten å avklare hvilke metoder og handlinger som er trygge å gjenta.

HTTP/3 kan brukes uten at applikasjonen tar imot 0-RTT-data.

UDP kan være blokkert

HTTP/3 bruker UDP, ofte på port 443. Enkelte brannmurer, bedriftsnett, VPN-er eller mellomledd kan blokkere eller svekke QUIC.

RFC 9114 sier at klienter bør forsøke TCP-baserte HTTP-versjoner når QUIC ikke kan etableres. Derfor bør en vanlig offentlig nettside tilby fungerende HTTP/2-fallback. HTTP/3 skal ikke være den eneste veien før målmiljøene er dokumentert.

Fallback kan likevel koste tid hvis klienten først forsøker QUIC og venter før TCP. Mål derfor feil og latenstid per nettverkstype, ikke bare total andel h3.

CDN og origin kan bruke ulike protokoller

Et CDN kan ta imot HTTP/3 fra besøkende og kontakte origin med HTTP/2 eller HTTP/1.1. Protokollen brukeren ser ved edge sier dermed ikke nødvendigvis noe om forbindelsen videre til webserveren.

Cloudflare dokumenterer for eksempel at deres HTTP/3-innstilling gjelder forbindelsen mellom bruker og Cloudflare, ikke HTTP/3 videre til origin.

Dette er ofte en fordel: HTTP/3 kan aktiveres på edge uten å bytte applikasjonsserver. Men den interne origin-forbindelsen må fortsatt måles og sikres. En treg eller overbelastet origin forblir en flaskehals ved cache miss og dynamiske svar.

Slik kontrollerer du hvilken protokoll som faktisk brukes

I nettleseren

I Chrome DevTools:

1. åpne Network
2. last siden på nytt
3. høyreklikk kolonneoverskriftene
4. vis kolonnen Protocol
5. se etter h2 og h3 per forespørsel

Chrome-dokumentasjonen beskriver kolonnen. Test flere laster og ikke anta at alle tredjepartsressurser bruker samme protokoll som hoveddokumentet.

Med kommandolinje

En curl-installasjon som er bygget med riktig støtte kan teste eksplisitt:

curl --http2 -I https://example.no/
curl --http3-only -I https://example.no/

Hvis --http3-only ikke finnes, mangler den lokale curl-bygningen støtte; det sier ikke at nettstedet mangler HTTP/3. Testen må også utføres fra et nett som tillater UDP.

Kontroller signalene separat:

curl -I https://example.no/
dig HTTPS example.no +short

Alt-Svc eller h3 i DNS er en annonse. DevTools-protokollen eller en eksplisitt vellykket h3-klient viser den faktiske forbindelsen.

Mål uten å lure deg selv

En enkel før/etter-test fra kontoret kan være tilfeldig påvirket av cache, nett og bakgrunnsaktivitet. Bruk en plan:

Endre ikke CDN, bildeoptimalisering, JavaScript og HTTP-protokoll samtidig hvis målet er å isolere effekten av HTTP/3.

Bruk feltdatasett over en representativ periode. Laboratorietest med simulert pakketap kan forklare mekanismen, men kan ikke alene forutsi alle brukernes gevinst.

Utrullingsplan

1. Bekreft at HTTP/2, HTTPS og sertifikater fungerer stabilt.
2. Mål dagens protokollfordeling, feil, TTFB og Core Web Vitals.
3. Aktiver HTTP/3 på støttet edge/server uten å fjerne HTTP/2.
4. Kontroller UDP-port og brannmur på det faktiske endepunktet.
5. Verifiser Alt-Svc og eventuell HTTPS-post.
6. Test faktisk h3, ikke bare annonseringen.
7. Test nett der UDP er blokkert og bekreft rask fallback.
8. Mål mobil, desktop og viktige markeder.
9. Følg QUIC-/HTTP3-feil og origin-belastning.
10. Dokumenter hvordan HTTP/3 deaktiveres uten å ta ned siden.

Vær oppmerksom på at nettlesere kan cache alternative tjenester. En endring i Alt-Svc slår derfor ikke nødvendigvis gjennom umiddelbart i en allerede brukt profil.

Vanlige feil

• anta at Alt-Svc beviser at siden lastet over HTTP/3
• teste bare fra ett raskt kontornett
• fjerne HTTP/2-fallback
• glemme UDP-regler i brannmur eller lastbalanserer
• publisere HTTPS DNS-post som ikke matcher edge-tjenesten
• tro at HTTP/3 også brukes mellom CDN og origin
• aktivere 0-RTT for tilstandsendrende handlinger uten replay-vurdering
• domenesharde ressurser slik gamle HTTP/1-råd anbefalte
• tilskrive all endring til protokollen etter en større deploy
• la tunge bilder og treg backend stå urørt

Hva betyr dette for SEO?

Google rangerer ikke en side fordi den har etiketten HTTP/3. Protokollen kan indirekte hjelpe brukeropplevelsen hvis den forbedrer reelle ytelsesmål for målgruppen. Innhold, crawling, renderarbeid, serverrespons og Core Web Vitals må fortsatt fungere.

Prioriter først de største dokumenterte flaskehalsene. Guiden til en raskere nettside viser rekkefølgen, mens Core Web Vitals-guiden forklarer feltsignalene.

HTTP/3 hos Vymo

Vymos enkle nettsider leveres gjennom Cloudflare. Den publiserte standardleveransen lover ikke en bestemt HTTP-versjon, protokollfordeling, QUIC-SLA eller kundestyrt CDN-panel. Nettleser, nettverk og plattform velger forbindelsen som faktisk brukes.

Har virksomheten dokumenterte krav til HTTP/3, UDP, bestemte regioner eller protokollmåling, send krav og målmarkeder til Vymo før bestilling . For en vanlig presentasjonsside er det viktigere at siden er lett, stabil og tilgjengelig enn at kunden administrerer protokollen selv.

Se hva Vymos gratis nettside inkluderer hvis en enkel side uten eget serveransvar er nok.