QUIC er en protokoll med opprinnelse fra Google som første gang så dagens lys i 2012. Navnet ble foreslått som et akronym for “Quick UDP Internet Connections”, men QUIC er i dag alene ansett som navnet på protokollen. Det er en ung protokoll sammenlignet med mange andre som benyttes på internett i dag. Eksempelvis er TCP, som i sin helhet erstattes av QUIC, opprinnelig fra 1974.
Protokollene som brukes på internett i dag er som regel bygget opp som i figuren under.
På bunnen har man et fysisk lag som kan være alt fra fiberkabler til radiobølger. På laget over har man datalink-laget som kobler to noder i umiddelbar nærhet sammen. Så kommer nettverkslaget, oftest kjent som IP-laget, som sørger for at pakkene kan transporteres ende-til-ende. Transportlaget, oftest TCP, ser til at pakkene faktisk kommer frem, og sender på nytt dersom pakker går tapt. Applikasjonslaget ligger på toppen og er de facto HTTP på web i dag. I tillegg har de fleste også et sikkerhetslag mellom transportlaget og applikasjonslaget som sørger for at dataene blir kryptert. Som oftest benyttes TLS til dette. Modellen er gjennomtestet og fungerer bra, men kan det forbedres?
¶Utfordringer ved dagens model
Noe av hensikten ved å dele opp lagene på denne måten er at man skal kunne bytte ut og gjøre endringer på et av lagene uten at det påvirker de andre lagene i nevneverdig grad. Transportlaget trenger eksempelvis ikke vite hvordan nettverkslaget fungerer for å gjøre jobben sin. Likevel har det vist seg svært vanskelig å oppdatere en protokoll i denne stacken. TCP har man eksempelvis forsøkt å gjøre endringer på i årevis, men en utvidelse i protokollen krever at alle boksene du treffer på veien fra A til Å gjennom nettet støtter denne endringen. Dersom boks Z ikke skjønner de nye tilleggene man har tatt i bruk i TCP-spesifikasjonen risikerer man at pakkene forkastes. TCP sørger da for at pakken sendes om igjen, men først etter at den opprinnelige pakken har timet ut. Og ikke bare det, men siden lagene over ikke selv har forutsetning for å skjønne hva laget under driver med, ender man i det som kalles “TCP Head-of-line-blocking”. Konsekvensen er at man må vente til pakken har blitt sendt på nytt og mottatt før man kan laste ned resten av innholdet. For protokollene over har dette ganske kjipe konsekvenser.
Enkelte tror at HTTP/2 som kom i 2015 løser problemet beskrevet over, men det gjør den altså ikke. Den store endringen fra HTTP/1.1 er at man multiplekser alle ressursene sammen slik at man bare får en TCP forbindelse, i motsetning til HTTP/1.1 hvor man bare kan laste en ressurs (html, css, js, bilder osv) av gangen pr forbindelse. Likevel har ikke HTTP/2 forutsetning for å skjønne noe dersom pakketapet oppstår på underliggende lag. Så selv om HTTP/2 løser problemet der en nettleser må ha mange parallelle forbindelser for å laste nettsider raskt med HTTP/1.1, vil ting likevel stoppe helt opp inntil den tapte pakken som mangler er hentet på nytt med HTTP/2. Det finnes flere utfordringer, men la oss i stedet se på hva QUIC gjør for å løse disse.
¶Hva gjør QUIC annerledes?
Svaret er i grunnen mange ting. Protokollen har bygget inn løsninger på flere av problemene man har sett etter mange år med bruk av eksisterende protokollstack. La oss starte med hva som er radikalt annerledes. Figuren under viser hvor QUIC passer inn i forhold til de andre protokollene.
Her ser du at QUIC sendes over UDP. For de av dere som kjenner UDP så vet dere at det knapt nok er en protokoll. Pakkene sendes ut på nettet uten noen som helst sjekk på om de kommer frem eller ikke. Den bruker i motsetning til TCP heller ikke noe tid på oppsett av forbindelse før den første pakken sendes ut. Protokollen har gjerne blitt brukt der man har behov for å sende ut data raskt, og der noen tapte pakker ikke er kritisk. Med andre ord kan man si at UDP er en perfekt protokoll dersom man ønsker å bygge alt over selv. Siden det også er bred støtte for UDP i nettet, og protokollen i seg selv ikke er spesielt kravstor er den ekstra godt egnet. Det er nettopp det man har gjort med QUIC. Oppsett av kobling (TCP), sikkerhet (TLS) og multipleksing (HTTP/2) ligger alt bakt inn i samme protokoll.
I motsetning til TCP som er en del av operativsystemet og kjører i kernel space, kjører applikasjoner som bruker QUIC i det som omtales som user space. Altså der du kjører dine vanlige applikasjoner. Et eksempel på dette er at nettlesere som har støtte for QUIC har dette som en del av browseren. Med andre ord betyr det at når du oppdaterer nettleseren så får du automatisk også støtte for det nyeste innenfor protokollen.
Videre er nå sikkerhet bygget inn i protokollen. Nærmere bestemt med TLS 1.3, som er det nyeste og flotteste om dagen. Dette gjør at man alltid bruker kryptering, og alle headere i QUIC-pakker er kryptert. Det gjør at man unngår problemer som man kan få med TCP der bokser i nettet endrer på headere underveis. Hver pakke er også kryptert uavhengig av hverandre, noe som står i sterk kontrast til TCP som transporterer en strøm av bytes med krypterte data den ikke har forutsetning for å vite noe om. Tap av en eneste pakke fører til at det stopper opp og den manglende pakken må som nevnt tidligere hentes på nytt før man kan fortsette.
Man sparer også en del tid på setup av forbindelse med QUIC. Den tradisjonelle protokollstacken krever som regel 3-RTT (Round Trip Time) før man i det hele tatt får sendt nyttedata. Først en TCP-handshake, så en TLS hello melding for å bli enig om formater, og tilslutt utveksling av nøkler. Med QUIC ender man opp med 0-RTT, eller i verste fall 1-RTT før man kan sende nyttedata. For å få 0-RTT krever det imidlertid at man har besøkt serveren tidligere og utvekslet nøkler. Disse nøklene caches til senere, og korter ned tiden man bruker på å hente data neste gang. Det skal dog nevnes at med nye TLS 1.3 så kan man komme ned i 2-RTT også med gammel protokollstack, men standarden er ikke så utbredt enda.
QUIC har bedre støtte for å bytte mellom nett. Eksempelvis dersom du er på WiFi og går over på mobilnettet. Med TCP vil det settes opp en ny TCP-forbindelse i det nye nettet, etter at den forrige har timet ut. Med QUIC vil du fortsette å bruke samme forbindelse. Det fungerer fordi hver forbindelse har sin egen unike id i QUIC, i motsetning til TCP som er knyttet opp mot portnummer. På den måten sørger protokollen for en mer sømløs opplevelse, og mindre banning når man forlater hjemmet på morgenkvisten.
Det er også bedre feilkorrigeringsalgoritmer innebygd, slik at protokollen selv kan utlede hva som er feil i en pakke og i en del tilfeller rette opp dette. Dermed slipper pakken å sendes på nytt på tross av feil. Dette omtales ofte som Forward Error Correction.
Siden transportlaget og applikasjonslaget nå samarbeider slipper man problemet beskrevet tidligere med TCP Head-of-line-blocking, og man kan fortsette å motta pakker samtidig som man ber om å få den tapte pakken på nytt. På den måten får brukeren en raskere og bedre opplevelse på nett.
Det bør også nevnes at siden QUIC lar seg oppdatere mye raskere og oftere enn eksisterende protokollstack, så kan man gjøre ting som å tilpasse trafikkstyringsmekanismer til applikasjonen i det nettet man er på. Dette behovet har garantert ikke gjennomsnittsapplikasjonen, men dersom man skal bygge applikasjoner på eksempelvis spesielt utstabile nett kan det i noen tilfeller være gunstig med en annen algoritme enn dersom den er laget for et dønn stabilt fibernett.
¶Hva betyr det for brukeren?
Sannsynligvis har du brukt QUIC i dag uten at du er klar over det selv, og det viktigste for de aller fleste sluttbrukere er jo at det går raskere uten at personen trenger å forholde seg til underliggende protokoller. Google bruker det internt mellom sine tjenester, og fra de fleste tjenester de har tilgjengelig til sluttbrukere i dag. Chrome støtter QUIC, og i Opera kan man skru på eksperimentell støtte for protokollen. Firefox Nightly kommer også med støtte om ikke lenge. Dersom du er usikker på om en tjeneste støtter QUIC kan du sjekke ved å bruke https://http3check.net/. Alternativt kan du ha nettverks-tabben oppe i Chrome, og da vil det stå hvilken protokoll du benytter slik som i bildet under. Dersom kolonnen med protokoll ikke vises hos deg er det fordi du må endre på standardoppsettet for hvilke kolonner som vises i Chrome.
QUIC er imidlertid ikke begrenset til bruk i nettlesere. Eksempelvis bruker YouTube appen protokollen i dag, og det gjelder etter hvert en god del andre også. Som en liten kuriositet kan det nevnes at det faktum at YouTube appen har tatt i bruk QUIC har gjort at datamengdene som transporteres via QUIC har skutt i været.
¶Serverstøtte
Det finnes i dag en håndfull webservere som støtter QUIC. De gode gamle som Apache HTTP server, Microsoft IIS og Nginx gjør ikke det enda, i alle fall ikke uten tillegg. Google sine tjenester støtter det ut av boksen, og det finnes et eget Open Source prosjekt i Go som heter quic-go. I tillegg har det kommet støtte i Lightspeed web server. Denne skal være kompatibel med de meste av konfigurasjonen av Apache HTTP server uten store endringer. Interessant nok har sistnevnte steget veldig i popularitet de seneste årene, og har en anslått markedsandel på 4,7% i august 2019.
I tillegg har tjenesteleverandører som Cloudflare implementert støtte for HTTP/3 og dermed QUIC (kommer tilbake til hva det betyr).
¶Tall og sånt
Verdens kanskje mest kjente tjeneste, altså Google søk, har blitt testet med QUIC versus en tradisjonell protokollstack. Tallene viste at QUIC er 8% mer effektivt på desktop og 3,6% på mobil. Dette høres kanskje litt lite ut, men tenk deg hvor mange milliarder Google har brukt på å optimalisere Google Search. Det å få flere prosent raskere svar ved å bytte protokoll er ingen liten detalj.
Tester på 4G nett har vist at QUIC i snitt er 14% raskere enn bruk av TCP med HTTP/1.1 og HTTP/2. Det har også blitt gjort tester på nett med høyt pakketap. Der fikk man et hastighetstap på rundt 20% sammenlignet med et nett uten pakketap med QUIC. Med HTTP/1.1 over TCP fikk man hele 100% dårligere ytelse og med HTTP/2 over TCP faktisk hele 200% dårligere ytelse. Bakgrunnen for at HTTP/2 har dårligere ytelse enn HTTP/1.1 er som nevnt tidligere alle ressurser lastes ned over samme forbindelse, mens man med HTTP/1.1 setter opp flere forbindelser i parallell. Ved pakketap vil man derfor oppleve at transportlaget må sende tapte pakker om igjen for å kunne gå videre (igjen TCP Head-of-line-blocking).
¶Utfordringer ved bruk av QUIC
Klient og serverstøtte er en åpenbar utfordring for QUIC, men det er viktig å være klar over at det alltid er en mulighet å falle tilbake på bruk av tradisjonell protokollstack i stedet.
Videre lever QUIC som tidligere nevnt i user space, i motsetning til andre transportprotokoller som lever i kernel space. Dette har selvsagt ikke bare fordeler, og man kan tenke seg at den kjørende prosessen i user space får en lavere prioritet i perioder med høy last. I tillegg viser ytelsestester at QUIC bruker nesten dobbelt så mye CPU som tradisjonell TCP og HTTP. Det er imidlertid ventet at dette gapet vil bli mindre over tid ettersom man får optimalisert protokollen ytterligere. Likevel er det trolig slik at QUIC i overskuelig fremtid vil bruke mer ressurser da protokollen rett og slett har mer funksjonalitet innebygd.
Noen brannmurer blokkerer i dag UDP trafikk på port 80 og 443, noe som selvsagt vil føre til at QUIC ikke fungerer. Igjen vil problemet løses ved at man faller tilbake på TCP, men du som sluttbruker får med andre ord ikke brukt den nye protokollen. I tillegg er det litt jobb som gjenstår i diverse loggeverktøy rundt nettverkstrafikk. Mange logger mye rundt TCP, mens alle UDP-pakker logges som generisk UDP-trafikk.
¶Veien videre
I november 2018 ble det klart at det som tidligere ble omtalt som HTTP over QUIC blir det nye HTTP/3. Her er det viktig å være klar over at HTTP over QUIC ikke omfatter hele QUIC-protokollen, men at HTTP/3 benytter QUIC som transportprotokoll og tar med seg forbedringene fra HTTP/2 inn i QUIC. Uansett, at QUIC blir et av fundamentene for HTTP/3 viser at teknologien er i ferd med å bli sentral i retningen internettarkitekturen er på vei.
Det er ingen endelig spesifikasjon på HTTP/3, og det er ikke klart når den skal være ferdig, men det er nok en stund frem i tid. Protokolldesign lider til en viss grad av dilemmaet rundt høna og egget. Hva må komme først av server- og klientstøtte? Mange av de tradisjonelle store webserverene har heller ikke uttalt at de skal støtte QUIC enda selv om det er sannsynlig at de vil få HTTP/3 støtte på sikt. Når det er sagt finnes det som nevnt allerede alternativer der ute.
