I mer enn 20 år har vi sett på nettsider ved hjelp av HTTP-protokollen. De fleste brukere tenker ikke engang på hva det er og hvordan det fungerer. Andre vet at et sted under HTTP er det TLS, og under det er TCP, som er IP, og så videre. Og atter andre - kjettere - tror at TCP hører fortiden til; de vil ha noe raskere, mer pålitelig og sikkert. Men i sine forsøk på å finne opp en ny ideell protokoll, har de vendt tilbake til teknologien fra 80-tallet og prøver å bygge sin modige nye verden på den.
En liten historie: HTTP/1.1
I 1997 skaffet tekstinformasjonsutvekslingsprotokollen HTTP versjon 1.1 sin egen RFC. På den tiden hadde protokollen blitt brukt av nettlesere i flere år, og den nye standarden varte i ytterligere femten. Protokollen fungerte kun etter forespørsel-svar-prinsippet og var hovedsakelig ment for overføring av tekstinformasjon.
HTTP ble designet for å kjøre på toppen av TCP-protokollen, for å sikre at pakker leveres pålitelig til destinasjonen. TCP fungerer ved å etablere og vedlikeholde en pålitelig forbindelse mellom endepunkter og dele trafikk inn i segmenter. Segmenter har sitt eget serienummer og kontrollsum. Hvis plutselig et av segmentene ikke kommer eller kommer med feil kontrollsum, vil overføringen stoppe til det tapte segmentet er gjenopprettet.
I HTTP/1.0 ble TCP-tilkoblingen stengt etter hver forespørsel. Dette var ekstremt bortkastet, fordi... å etablere en TCP-forbindelse (3-veis-håndtrykk) er en langsom prosess. HTTP/1.1 introduserte keep-alive-mekanismen, som lar deg gjenbruke én tilkobling for flere forespørsler. Men siden det lett kan bli en flaskehals, tillater ulike implementeringer av HTTP/1.1 flere TCP-tilkoblinger å åpnes til samme vert. For eksempel tillater Chrome og nyere versjoner av Firefox opptil seks tilkoblinger.
Kryptering skulle også overlates til andre protokoller, og til dette ble TLS-protokollen brukt over TCP, som pålitelig beskyttet dataene, men ytterligere økte tiden det tok å etablere en forbindelse. Som et resultat begynte håndtrykkprosessen å se slik ut:
Cloudflare illustrasjon
Derfor hadde HTTP/1.1 en rekke problemer:
- Sakte tilkoblingsoppsett.
- Data overføres i tekstform, noe som betyr at overføring av bilder, videoer og annen ikke-tekstlig informasjon er ineffektiv.
- Én TCP-tilkobling brukes for én forespørsel, noe som betyr at andre forespørsler enten må finne en annen tilkobling eller vente til gjeldende forespørsel frigir den.
- Kun pull-modellen støttes. Det er ingenting i standarden om server-push.
- Overskrifter overføres i tekst.
Hvis server-push i det minste implementeres ved hjelp av WebSocket-protokollen, måtte de resterende problemene håndteres mer radikalt.
Litt modernitet: HTTP/2
I 2012 begynte Google å jobbe med SPDY (uttales "speedy")-protokollen. Protokollen ble designet for å løse hovedproblemene til HTTP/1.1 og skulle samtidig opprettholde bakoverkompatibilitet. I 2015 introduserte IETF-arbeidsgruppen HTTP/2-spesifikasjonen basert på SPDY-protokollen. Her er forskjellene i HTTP/2:
- Binær serialisering.
- Multipleksing av flere HTTP-forespørsler til en enkelt TCP-tilkobling.
- Server-push ut av esken (uten WebSocket).
Protokollen var et stort skritt fremover. Han sterkt og krever ikke opprettelse av flere TCP-tilkoblinger: alle forespørsler til én vert multiplekses til én. Det vil si at det i en forbindelse er flere såkalte streams, som hver har sin egen ID. Bonusen er en server-push i boks.
Imidlertid fører multipleksing til et annet nøkkelproblem. Tenk deg at vi kjører asynkront 5 forespørsler til én server. Når du bruker HTTP/2, vil alle disse forespørslene utføres innenfor samme TCP-forbindelse, noe som betyr at hvis et av segmentene i en forespørsel går tapt eller mottas feil, vil overføringen av alle forespørsler og svar stoppe til det tapte segmentet er restaurert. Jo dårligere tilkoblingskvaliteten er, jo tregere fungerer HTTP/2. , under forhold der tapte pakker utgjør 2 % av alle pakker, fungerer HTTP/1.1 i nettleseren bedre enn HTTP/2 på grunn av det faktum at den åpner 6 tilkoblinger i stedet for én.
Dette problemet kalles "head-of-line blocking", og det er dessverre ikke mulig å løse det når du bruker TCP.
Illustrasjon av Daniel Steinberg
Som et resultat gjorde utviklerne av HTTP/2-standarden en god jobb og gjorde nesten alt som kunne gjøres på applikasjonslaget til OSI-modellen. Det er på tide å gå ned til transportlaget og finne opp en ny transportprotokoll.
Vi trenger en ny protokoll: UDP vs TCP
Ganske raskt ble det klart at implementering av en helt ny transportlagsprotokoll er en umulig oppgave i dagens realiteter. Faktum er at maskinvare eller mellombokser (rutere, brannmurer, NAT-servere...) kjenner til transportlaget, og å lære dem noe nytt er en ekstremt vanskelig oppgave. I tillegg er støtte for transportprotokoller innebygd i kjernen til operativsystemer, og kjerner er heller ikke særlig villige til å endre seg.
Og her kan man kaste opp hendene og si «Vi vil selvfølgelig finne opp en ny HTTP/3 med preferanse og kurtisaner, men det vil ta 10-15 år å bli implementert (etter omtrent denne tiden vil det meste av maskinvaren være erstattet), men det er en til som ikke er det. Det åpenbare alternativet er å bruke UDP-protokollen. Ja, ja, den samme protokollen som vi brukte til å kaste filer over LAN på slutten av nittitallet og begynnelsen av XNUMX-tallet. Nesten all dagens maskinvare kan fungere med den.
Hva er fordelene med UDP fremfor TCP? For det første har vi ikke en transportlagsøkt som maskinvaren vet om. Dette lar oss bestemme økten på endepunktene selv og løse konflikter der. Det vil si at vi ikke er begrenset til én eller flere økter (som i TCP), men kan lage så mange av dem vi trenger. For det andre er dataoverføring via UDP raskere enn via TCP. Dermed kan vi i teorien bryte gjennom det nåværende hastighetstaket oppnådd i HTTP/2.
UDP garanterer imidlertid ikke pålitelig dataoverføring. Faktisk sender vi bare pakker i håp om at den andre enden vil motta dem. Har ikke mottatt? Vel, uten hell... Dette var nok til å overføre videoer for voksne, men for mer seriøse ting trenger du pålitelighet, noe som betyr at du må pakke noe annet på toppen av UDP.
Som med HTTP/2 startet arbeidet med å lage en ny protokoll hos Google i 2012, det vil si omtrent samtidig som arbeidet med SPDY startet. I 2013 presenterte Jim Roskind for allmennheten , og allerede i 2015 ble Internet Draft introdusert for standardisering i IETF. Selv på den tiden var protokollen utviklet av Roskind hos Google veldig forskjellig fra standarden, så Google-versjonen begynte å bli kalt gQUIC.
Hva er QUIC
For det første, som allerede nevnt, er dette en innpakning over UDP. En QUIC-forbindelse stiger på toppen av UDP, der det, analogt med HTTP/2, kan eksistere flere strømmer. Disse strømmene eksisterer bare på endepunktene og serveres uavhengig. Hvis det oppstår et pakketap i én strøm, vil det ikke påvirke andre.
Illustrasjon av Daniel Steinberg
For det andre er kryptering ikke lenger implementert på et eget nivå, men er inkludert i protokollen. Dette lar deg opprette en forbindelse og utveksle offentlige nøkler i et enkelt håndtrykk, og lar deg også bruke den smarte 0-RTT-håndtrykkmekanismen og unngå håndtrykkforsinkelser helt. I tillegg er det nå mulig å kryptere individuelle datapakker. Dette lar deg ikke vente på fullføringen av å motta data fra strømmen, men å dekryptere de mottatte pakkene uavhengig. Denne driftsmåten var generelt umulig i TCP, fordi TLS og TCP fungerte uavhengig av hverandre, og TLS kunne ikke vite i hvilke deler TCP-data ville bli kuttet. Og derfor kunne han ikke forberede segmentene sine slik at de passet inn i TCP-segmentene én til én og kunne dekrypteres uavhengig. Alle disse forbedringene lar QUIC redusere ventetiden sammenlignet med TCP.
For det tredje lar konseptet med lysstrømning deg koble fra tilkoblingen fra klientens IP-adresse. Dette er viktig, for eksempel når en klient bytter fra ett Wi-Fi-tilgangspunkt til et annet, og endrer IP-adressen. I dette tilfellet, når du bruker TCP, oppstår det en langvarig prosess der eksisterende TCP-tilkoblinger blir tidsavbrutt og nye tilkoblinger opprettes fra en ny IP. Når det gjelder QUIC, fortsetter klienten ganske enkelt å sende pakker til serveren fra en ny IP med den gamle strøm-IDen. Fordi Strøm-ID-en er nå unik og blir ikke gjenbrukt; serveren forstår at klienten har endret IP, sender tapte pakker på nytt og fortsetter kommunikasjonen på den nye adressen.
For det fjerde implementeres QUIC på applikasjonsnivå, ikke operativsystemnivå. Dette lar deg på den ene siden raskt gjøre endringer i protokollen, fordi For å få en oppdatering trenger du bare å oppdatere biblioteket, i stedet for å vente på en ny OS-versjon. På den annen side fører dette til en sterk økning i prosessorforbruket.
Og til slutt, overskriftene. Header-komprimering er en av tingene som er forskjellig mellom QUIC og gQUIC. Jeg ser ikke poenget med å bruke mye tid på dette, jeg vil bare si at i versjonen som ble sendt inn for standardisering, ble header-komprimering gjort så likt som mulig med header-komprimering i HTTP/2. Du kan lese mer .
Hvor mye raskere er det?
Det er et vanskelig spørsmål. Faktum er at inntil vi har en standard er det ikke noe spesielt å måle. Kanskje den eneste statistikken vi har er statistikk fra Google, som har brukt gQUIC siden 2013 og i 2016 at omtrent 90 % av trafikken som går til deres servere fra Chrome-nettleseren nå bruker QUIC. I samme presentasjon rapporterer de at sider lastes inn omtrent 5 % raskere gjennom gQUIC og det er 30 % færre hakking i videostrømming sammenlignet med TCP.
I 2017 publiserte en gruppe forskere ledet av Arash Molavi Kakhki å studere ytelsen til gQUIC sammenlignet med TCP.
Studien avdekket flere svakheter ved gQUIC, som ustabilitet ved blanding av nettverkspakker, grådighet (urettferdighet) for å kanalisere båndbredde og langsommere overføring av små (opptil 10 kb) objekter. Sistnevnte kan imidlertid kompenseres for ved å bruke 0-RTT. I alle andre studerte tilfeller viste gQUIC en økning i hastighet sammenlignet med TCP. Det er vanskelig å snakke om spesifikke tall her. Bedre å lese eller .
Her skal det sies at disse dataene spesifikt handler om gQUIC, og det er ikke relevant for standarden som utvikles. Hva vil skje for QUIC: det er fortsatt en hemmelighet, men det er håp om at svakhetene identifisert i gQUIC vil bli tatt i betraktning og korrigert.
Litt om fremtiden: hva med HTTP/3?
Men her er alt krystallklart: API-en vil ikke endre seg på noen måte. Alt vil forbli nøyaktig det samme som det var i HTTP/2. Vel, hvis API-en forblir den samme, må overgangen til HTTP/3 løses ved å bruke en fersk versjon av biblioteket på backend som støtter QUIC-transport. Riktignok må du beholde tilbakeslaget på gamle versjoner av HTTP i ganske lang tid, fordi Internett er foreløpig ikke klart for en fullstendig overgang til UDP.
Som allerede støtter
Her eksisterende QUIC-implementeringer. Til tross for mangelen på en standard, er ikke listen dårlig.
Ingen nettleser støtter for øyeblikket QUIC i en produksjonsutgivelse. Nylig kom det informasjon om at støtte for HTTP/3 var inkludert i Chrome, men foreløpig bare på Canary.
Av backends støtter HTTP/3 bare и , men fortsatt eksperimentell. NGINX på slutten av våren 2019 , at de begynte å jobbe med HTTP/3-støtte, men ikke har fullført det ennå.
Hva er problemene?
Du og jeg lever i den virkelige verden, hvor ingen stor teknologi kan nå massene uten å møte motstand, og QUIC er intet unntak.
Det viktigste er at du på en eller annen måte må forklare nettleseren at "https://" ikke lenger er et faktum at det fører til TCP-port 443. Det er kanskje ikke TCP i det hele tatt. Alt-Svc-overskriften brukes til dette. Den lar deg fortelle nettleseren at denne nettsiden også er tilgjengelig på en slik og en slik protokoll på en slik og en adresse. I teorien skal dette fungere som en sjarm, men i praksis vil vi komme over at UDP for eksempel kan forbys på en brannmur for å unngå DDoS-angrep.
Men selv om UDP ikke er forbudt, kan klienten stå bak en NAT-ruter som er konfigurert til å holde en TCP-sesjon etter IP-adresse, og siden vi bruker UDP, som ikke har noen maskinvareøkt, NAT vil ikke holde tilkoblingen, og en QUIC-økt .
Alle disse problemene skyldes det faktum at UDP tidligere ikke hadde blitt brukt til å overføre Internett-innhold, og maskinvareprodusenter kunne ikke forutse at dette noen gang ville skje. På samme måte forstår administratorer ennå ikke hvordan de skal konfigurere nettverkene sine riktig for at QUIC skal fungere. Denne situasjonen vil gradvis endre seg, og i alle fall vil slike endringer ta kortere tid enn implementeringen av en ny transportlagsprotokoll.
I tillegg, som allerede beskrevet, øker QUIC CPU-bruken betraktelig. Daniel Stenberg prosessorvekst opptil tre ganger.
Når kommer HTTP/3?
Standard innen mai 2020, men gitt at dokumenter som er planlagt til juli 2019 forblir uferdige for øyeblikket, kan vi si at datoen mest sannsynlig vil bli skjøvet tilbake.
Vel, Google har brukt sin gQUIC-implementering siden 2013. Hvis du ser på HTTP-forespørselen som sendes til Googles søkemotor, vil du se dette:
Funn
QUIC ser nå ut som en ganske grov, men veldig lovende teknologi. Tatt i betraktning at i løpet av de siste 20 årene har alle optimaliseringer av transportlagsprotokoller hovedsakelig dreid seg om TCP, QUIC, som i de fleste tilfeller har best ytelse, ser allerede ekstremt bra ut.
Det er imidlertid fortsatt uløste problemer som må håndteres i løpet av de neste årene. Prosessen kan bli forsinket på grunn av det faktum at det er maskinvare involvert, som ingen liker å oppdatere, men likevel ser alle problemene ganske løses ut, og før eller siden vil vi alle ha HTTP/3.
Fremtiden er rett rundt hjørnet!
Kilde: www.habr.com