Allerede før halvparten av alle spørringer på weben gjøres med HTTP/2, har arbeidet med neste versjon av protokollen startet i standardiseringsorganisasjonen Internet Engineering Task Force (IETF).
Dagens versjoner av HTTP bygger på TCP (Transmission Control Protocol) i transportlaget.
TCP sørger for en datastrøm som er pålitelig, feilsjekket og hvor datapakkene kommer i riktig rekkefølge. Dersom en pakke uteblir eller er korrupt, bes avsenderen om å sende denne på nytt. I mellomtiden, fordi pakkene må komme i riktig rekkefølge, stoppes datastrømmen inntil den manglende pakken har ankommet.
Siden signalene over internett tross alt beveger seg med en begrenset hastighet, vil det kunne ta betydelig tid fra det oppdages at en pakke må sende på nytt, til pakken faktisk kommer fram. Dette gjelder ikke minst hvis avsender og mottaker befinner seg på hver sin side av kloden.
Fra SPDY til QUIC
Google har i mange år jobbet med å erstatte de etter hvert ganske gamle protokollene med nyere og mer effektive utgaver. Et resultat av dette finner man i HTTP/2, som er delvis basert på Googles SPDY-teknologi, som digi.no omtalte første gang i 2009.
Senere kom Google med QUIC (Quick UDP Internet Connections), en UDP-basert (User Datagram Protocol) protokoll som siden rundt 2015 har blitt brukt av Google til å levere mye av innholdet på selskapets egne nettsteder – vel å merke til nettlesere som støtter QUIC, noe som fortsatt ser ut til å være begrenset til Chrome og andre Chromium-baserte nettlesere. På serversiden er støtten også temmelig sparsommelig.
Den største fordelen med QUIC er redusert forsinkelse, sammenlignet med TCP. Blant annet skal går det mye raskere å opprette forbindelser over QUIC enn over TCP. I praksis kan dataoverføringen starte uten noen form for forhandlinger («handshake») i forkant.
UDP
UDP, som QUIC bygger på, er en flott transportprotokoll for å pøse ut masse data, uten at det er helt avgjørende om alt kommer fram i riktig rekkefølge. Dette kan fungerer greit med mye strømmet innhold, hvor det ikke er så farlig om det mangler en byte her og der. Men det fungerer dårlig dersom for eksempel websider mangler tekst eller HTML-tagger.
_logo.svg.png){kind=logo}
Derfor må slike problemer håndteres av QUIC. For å redusere pakketap, vil pakkene sendes ut med jevn takt.
QUIC avhenger ikke av at pakkene mottas i riktig rekkefølge. Det benyttes feilkorreksjonskoder (ECC) for å redusere behovet for å ettersende tapte pakkedata. QUIC er dessuten designet for å tilby sikkerhet med TLS 1.3 (Transport Layer Security) til enhver tid. De kryptografiske blokkene er tilpasset pakkestørrelsen, noe som ytterligere skal begrense effekten av pakketap.
Mye mer informasjon om QUIC er tilgjengelig på denne siden.
IETF-standardisering
Google foreslo allerede i 2015 at QUIC burde gjøres til en internettstandard i IETF. QUIC-utgaven som IETF er i ferd med å standardisere, er dog ikke identisk med Googles. Derfor har disse litt uformelt blitt kalt for henholdsvis «iQUIC» og «gQUIC».
Blant annet skiller IEFT mellom transportlaget og applikasjonslaget i QUIC. «iQUIC» består derfor bare av transportlaget. Tanken er at QUIC også kan brukes til andre formål enn HTTP.
Derfor finnes det en egen spesifikasjon som heter Hypertext Transfer Protocol (HTTP) over QUIC. Denne beskriver hvordan HTTP-semantikk kan brukes over QUIC-protokollen, da i stor grad basert på designen til HTTP/2.
Døpes om til HTTP/3
I oktober foreslo Mark Nottingham, som leder IETF-arbeidsgruppene for HTTP og QUIC, å døpe om HTTP over QUIC-spesifikasjonen til HTTP/3. Forslaget skal ha blitt møtt med bred enighet i epostlisten hvor det ble publisert.
En nærmere gjennomgang blir gjort i denne videoen.
Det er flere som er kritiske til QUIC, blant annet fordi teknologien i hovedsak er utviklet av ett selskap.
Cloudflare beskriver i dette blogginnlegget et annet problem, nemlig at ingen vanlige rutere har støtte for QUIC, og at de dermed vil måtte behandle QUIC-basert trafikk som UDP i forbindelse med NAT-ing (Network Address Translation). Dette kan få en negativ effekt på langvarige forbindelser,fordi håndteringen UDP-strømmer, gjerne bruker korte timeout-perioder.
NAT gjør det mulig for at flere nettverkstilknyttede enheter i lokalnettet kan motta riktige data fra internett, selv om alle enhetene bruker den samme IP-adressen på internett.
Leste du denne? D-dagen for HTTP har kommet
