I över 20 Ă„r har vi tittat pĂ„ webbsidor via protokollet HTTP. De flesta anvĂ€ndare tĂ€nker överhuvudtaget inte pĂ„ vad det Ă€r och hur det fungerar. Andra vet att TLS ligger nĂ„gonstans under HTTP, och under det TCP, under vilket ligger IP och sĂ„ vidare. Och de tredje â heretikerna â anser att TCP Ă€r förĂ„ldrat, de vill ha nĂ„got snabbare, mer pĂ„litligt och sĂ€krare. Men i sina försök att uppfinna ett nytt perfekt protokoll har de Ă„tergĂ„tt till teknologier frĂ„n 80-talet och försöker bygga sin underbara nya vĂ€rld pĂ„ dem.
Lite historia: HTTP/1.1
à r 1997 fick protokollet för överföring av textinformation HTTP version 1.1 sitt RFC. Vid den tidpunkten hade protokollet anvÀnts av webblÀsare i flera Är, och den nya standarden höll i ytterligare femton. Protokollet fungerade enbart enligt principen för begÀran-svar och var huvudsakligen avsett för överföring av textinformation.
HTTP designades för att fungera ovanpÄ protokollet TCP, som garanterar pÄlitlig leverans av paket till mottagaren. TCP:s funktion bygger pÄ att etablera och upprÀtthÄlla en pÄlitlig anslutning mellan slutpunkter och dela upp trafik i segment. Segmenten har ett sekventiellt nummer och en kontrollsumma. Om nÄgot av segmenten inte kommer fram eller kommer med en felaktig kontrollsumma, stoppas överföringen tills det förlorade segmentet har ÄterstÀllts.
I HTTP/1.0 stÀngdes TCP-anslutningen efter varje begÀran. Det var oerhört slösaktigt, eftersom etableringen av en TCP-anslutning (3-vÀgs handskakning) Àr en lÄngsam process. I HTTP/1.1 introducerades mekanismen keep-alive, som gör det möjligt att ÄteranvÀnda en och samma anslutning för flera begÀrningar. Men eftersom det kan bli en flaskhals, tillÄts i olika implementationer av HTTP/1.1 att öppna flera TCP-anslutningar till samma vÀrd. Till exempel tillÄter Chrome och de senaste versionerna av Firefox upp till sex anslutningar.
Kryptering skulle ocksÄ överlÄtas till andra protokoll, och för det började protokollet TLS att anvÀndas över TCP, vilket skyddade data pÄ ett tillfredsstÀllande sÀtt, men som ytterligare ökade den tid som behövdes för att etablera en anslutning. I slutÀndan blev processen för handskakning sÄ hÀr:
Cloudflare-illustration
SĂ„ledes hade HTTP/1.1 flera problem:
- LĂ„ngsam anslutningstid.
- Data skickas i textformat, vilket innebÀr att överföring av bilder, videor och annan icke-textlig information Àr ineffektiv.
- En TCP-anslutning anvÀnds för en förfrÄgan, vilket betyder att andra förfrÄgningar antingen mÄste hitta en annan anslutning eller vÀnta tills den aktuella förfrÄgan slÀpper den.
- Endast pull-modellen stöds. Standarden innehÄller inget om server-push.
- Rubriker överförs som text.
Om server-push nÄgonlunde implementeras med hjÀlp av WebSocket-protokollet, mÄste övriga problem lösas mer radikalt.
Lite modernitet: HTTP/2
à r 2012 inleddes arbetet med protokollet SPDY (uttalas "spidi") inuti Google. Protokollet syftade till att lösa de största problemen med HTTP/1.1 och skulle samtidigt bevara bakÄtkompatibiliteten. à r 2015 presenterade IETFs arbetsgrupp specifikationen HTTP/2, baserad pÄ protokollet SPDY. HÀr Àr vilka skillnader som fanns i HTTP/2:
- BinÀr serialisering.
- Multiplexering av flera HTTP-förfrÄgningar i en enda TCP-anslutning.
- Server-push out-of-the-box (utan WebSocket).
Protokollet var ett stort framsteg. Det Àr avsevÀrt och krÀver inga flera TCP-anslutningar: alla förfrÄgningar till en vÀrd multiplexeras i en. Det vill sÀga, i en anslutning finns flera sÄ kallade strömmar, var och en med sitt ID. Som bonus ingÄr server-push.
Men multiplexering medför ett annat centralt problem. TÀnk dig att vi asynkront gör 5 förfrÄgningar till en server. Med HTTP/2 kommer alla dessa förfrÄgningar att utföras inom ramen för en enda TCP-anslutning, vilket betyder att om en av segmenten av nÄgon förfrÄgan gÄr förlorad eller kommer fel, kommer överföringen av alla förfrÄgningar och svar att stoppas tills det förlorade segmentet Äterskapas. Det Àr uppenbart att ju sÀmre anslutningskvaliteten Àr, desto lÄngsammare fungerar HTTP/2. , under förhÄllanden dÀr förlorade paket utgör 2 % av alla, presterar HTTP/1.1 bÀttre i webblÀsaren Àn HTTP/2 eftersom det öppnar 6 anslutningar istÀllet för en.
Detta problem kallas "head-of-line blocking" och tyvÀrr Àr det inte möjligt att lösa detta med hjÀlp av TCP.
Illustration av Daniel Steinberg
Som ett resultat har utvecklarna av HTTP/2-standarden gjort ett enormt arbete och genomfört praktiskt taget allt som kunde göras pÄ applikationsnivÄn inom OSI-modellen. Det Àr nu dags att gÄ ned till transportnivÄn och uppfinna ett nytt transportprotokoll.
Vi behöver ett nytt protokoll: UDP vs TCP
Det blev snabbt tydligt att införandet av ett helt nytt transportprotokoll Àr en olöslig uppgift i dagens verklighet. Anledningen Àr att hÄrdvaran, eller mellanstationerna (routrar, brandvÀggar, NAT-servrar...), Àr medvetna om transportnivÄn, och att lÀra dem nÄgot nytt Àr en mycket besvÀrlig uppgift. Dessutom Àr stödet för transportprotokoll inbyggt i operativsystemens kÀrna, och kÀrnor förÀndras inte gÀrna.
Vid det hĂ€r laget skulle man kunna ge upp och sĂ€ga "SjĂ€lvklart kommer vi att uppfinna en ny HTTP/3 med preferenser och kurtisaner, men det kommer att ta 10â15 Ă„r innan den verkligen implementeras (ungefĂ€r sĂ„ lĂ„ng tid tar det att byta ut de flesta av hĂ„rdvarorna)", men det finns en annan, kanske inte sĂ„ uppenbar, möjlighet: att anvĂ€nda UDP-protokollet. Ja, just det protokollet som vi anvĂ€nde för att skicka filer lokalt i slutet av 90-talet och början av 00-talet. NĂ€stan all nuvarande hĂ„rdvara klarar det.
Vad Àr fördelarna med UDP jÀmfört med TCP? För det första, vi har ingen session pÄ transportnivÄn som hÄrdvaran kÀnner till. Detta gör att vi sjÀlva kan definiera sessionen pÄ slutpunkterna och hantera eventuella konflikter dÀr. Det betyder att vi inte Àr begrÀnsade till en eller flera sessioner (som med TCP), utan kan skapa sÄ mÄnga vi behöver. För det andra sker dataöverföringen via UDP snabbare Àn via TCP. PÄ sÄ sÀtt kan vi teoretiskt övervinna dagens hastighetsgrÀns, som nÄddes i HTTP/2.
Men UDP garanterar inte pÄlitlighet i dataöverföringen. Faktum Àr att vi bara skickar paket och hoppas att de tas emot i andra Ànden. Fick vi inte dem? Ja, trist... Detta var tillrÀckligt för att överföra videor för vuxna, men för mer seriösa saker behövs pÄlitlighet, vilket innebÀr att vi mÄste bygga nÄgot annat ovanpÄ UDP.
Precis som i fallet med HTTP/2 började arbetet med att skapa ett nytt protokoll pÄ Google Är 2012, vilket var ungefÀr samtidigt som arbetet med SPDY inleddes. à r 2013 presenterade Jim Roskind protokollet för allmÀnheten. , och redan 2015 infördes ett Internet Draft för standardisering inom IETF. Vid den tidpunkten skilde sig protokollet som utvecklades av Roskind pÄ Google kraftigt frÄn det som lades fram för standardisering, dÀrför började man kalla Googles version för gQUIC.
Vad Àr QUIC
För det första, som redan nÀmnts, Àr detta en omslag över UDP. OvanpÄ UDP byggs en QUIC-anslutning, dÀr flera strömmar kan existera pÄ samma sÀtt som med HTTP/2. Dessa strömmar finns endast pÄ Àndpunkterna och hanteras oberoende. Om ett paket gÄr förlorat i en ström pÄverkar det inte de andra.
Illustration av Daniel Steinberg
För det andra Àr kryptering nu inte enskild nivÄ, utan inkluderad i protokollet. Detta möjliggör att upprÀtta en anslutning och utbyta publika nycklar i ett enda handslag, samt att anvÀnda den smarta mekanismen 0-RTT handslag för att helt undvika fördröjningar vid handskakningar. Dessutom kan man nu kryptera enskilda datapaket. Detta möjliggör att inte behöva vÀnta pÄ att datamottagningen frÄn strömmen ska avslutas, utan att avkoda de mottagna paketen oberoende. Denna arbetsmetod var överhuvudtaget inte möjlig i TCP, eftersom TLS och TCP arbetade oberoende av varandra, och TLS kunde inte veta hur TCP skulle dela upp datan. DÀrmed kunde den inte förbereda sina segment sÄ att de passade in i TCP-segment ett till ett och kunde avkodas oberoende. Alla dessa förbÀttringar gör att QUIC kan minska latensen jÀmfört med TCP.
För det tredje möjliggör konceptet med lÀtta strömmar att koppla bort anslutningen frÄn klientens IP-adress. Detta Àr viktigt, exempelvis nÀr en klient vÀxlar mellan olika Wi-Fi-Ätkomstpunkter och Àndrar sin IP. I sÄdana fall, nÀr TCP anvÀnds, sker en lÄng process dÀr befintliga TCP-anslutningar kopplas bort pÄ grund av timeout och nya anslutningar skapas med den nya IP:n. Vid QUIC, fortsÀtter klienten bara att skicka paket till servern med den nya IP:n och den gamla ströms ID. Eftersom ström-ID nu Àr unikt och inte ÄteranvÀnds, förstÄr servern att klienten har bytt IP, skickar de förlorade paketen och fortsÀtter kommunikationen pÄ den nya adressen.
För det fjÀrde implementeras QUIC pÄ applikationsnivÄ snarare Àn operativsystemsnivÄ. à ena sidan möjliggör detta snabbare förÀndringar i protokollet, eftersom man bara behöver uppdatera biblioteket för att fÄ en uppgradering, istÀllet för att vÀnta pÄ en ny version av operativsystemet. à andra sidan leder detta till en kraftig ökning av processoranvÀndningen.
Och slutligen, rubriker. Komprimering av rubriker hör definivt till de saker som skiljer sig mellan QUIC och gQUIC. Jag ser ingen mening med att Àgna mycket tid Ät detta, jag kan bara sÀga att i versionen som presenterades för standardisering gjordes komprimeringen av rubriker sÄ lik som möjligt komprimeringen av rubriker i HTTP/2. Mer information kan lÀsas .
Hur mycket snabbare Àr det?
Det Àr en komplex frÄga. Faktum Àr att vi Ànnu inte har nÄgot standard, sÄ vi har inte mycket att mÀta. De enda statistikuppgifter vi har Àr frÄn Google, som har anvÀnt gQUIC sedan 2013 och Är 2016 , att cirka 90% av trafiken som gÄr till deras servrar frÄn webblÀsaren Chrome nu anvÀnder QUIC. I samma presentation rapporterar de att sidor laddas ungefÀr 5% snabbare genom gQUIC, och att strömmande video har 30% fÀrre avbrott jÀmfört med TCP.
Ă
r 2017 publicerade en grupp forskare ledd av Arash Molavi Kakhki om att studera prestandan av gQUIC jÀmfört med TCP.
Studien avslöjade flera svagheter i gQUIC, sÄsom oförmÄga att hantera blandade nÀtverkspaket, girighet (orÀttvisa) mot bandbredd och lÄngsammare överföring av smÄ (upp till 10 kB) objekt. Det senare kan dock kompenseras med anvÀndning av 0-RTT. I alla andra fall som studerades visade gQUIC en ökning i hastighet jÀmfört med TCP. Det Àr svÄrt att tala om specifika siffror hÀr. Det Àr bÀttre att lÀsa eller .
HÀr bör det nÀmnas att dessa data handlar om gQUIC och att de inte Àr aktuella för den utvecklade standarden. Vad som kommer att gÀlla för QUIC Àr fortfarande en hemlighet, men det finns hopp om att svagheterna som identifierades i gQUIC kommer att beaktas och ÄtgÀrdas.
Lite framtidsperspektiv: vad hÀnder med HTTP/3?
HĂ€r Ă€r det kristallklart: API:t kommer inte att förĂ€ndras. Allt förblir precis som det var i HTTP/2. Om API:t förblir detsamma, bör övergĂ„ngen till HTTP/3 avgöras genom att anvĂ€nda den senaste versionen av biblioteken pĂ„ backend, som stöder transport via QUIC. Ăven om internet just nu inte Ă€r redo för en fullstĂ€ndig övergĂ„ng till UDP, mĂ„ste vi tyvĂ€rr fortsĂ€tta att hĂ„lla fallback till Ă€ldre versioner av HTTP.
Vem stöder redan
HÀr Àr existerande QUIC-implementationer. Trots avsaknaden av en standard, Àr listan ganska bra.
Ingen webblÀsare stöder för nÀrvarande QUIC i produktionsversion. Nyligen kom det fram information om att Chrome aktiverade stöd för HTTP/3, men bara i Canary.
Av backend-lösningarna stöder endast och , men fortfarande pÄ experimentell nivÄ. NGINX meddelade i slutet av vÄren 2019 , att de hade börjat arbeta pÄ stöd för HTTP/3, men de har Ànnu inte slutfört det.
Vilka problem finns det
Vi lever i en verklig vÀrld dÀr ingen stor teknik kan nÄ massorna utan att möta motstÄnd, och QUIC Àr inget undantag.
Det viktigaste Àr att pÄ nÄgot sÀtt förklara för webblÀsaren att "https://" nu inte nödvÀndigtvis leder till TCP-port 443. DÀr kan faktiskt ingen TCP finnas. För detta anvÀnds Alt-Svc-headern. Den lÄter informera webblÀsaren om att denna webbplats ocksÄ Àr tillgÀnglig pÄ ett visst protokoll pÄ en viss adress. I teorin borde detta fungera perfekt, men i praktiken kan vi stöta pÄ problem, dÀr UDP kan vara blockerad av brandvÀggen för att förhindra DDoS-attacker.
Men Àven om UDP inte Àr blockerad kan klienten befinna sig bakom en NAT-router som Àr instÀlld för att upprÀtthÄlla TCP-sessioner baserat pÄ IP-adressen, och eftersom vi anvÀnder UDP, som inte har nÄgon hÄrdvarusession, kommer NAT inte att hÄlla anslutningen, och QUIC-sessionen .
Alla dessa problem beror pÄ att UDP tidigare inte anvÀndes för att överföra internetinnehÄll, och hÄrdvarutillverkare kunde inte förutse att detta skulle ske nÄgon gÄng. PÄ samma sÀtt förstÄr administratörer fortfarande inte helt hur de ska konfigurera sina nÀtverk för att stödja QUIC. Denna situation kommer gradvis att förÀndras, och i vilket fall som helst kommer sÄdana förÀndringar att ta mindre tid Àn att implementera ett nytt transportprotokoll.
Dessutom, som redan har beskrivits, ökar QUIC kraftigt anvÀndningen av CPU. Daniel Stenberg ökningen av CPU-anvÀndning till tre gÄnger.
NĂ€r kommer HTTP/3
Standard I maj 2020, men med tanke pÄ att dokumenten som var planerade till juli 2019 fortfarande inte Àr klara, kan man sÀga att datumet troligen skjuts upp.
Google har anvÀnt sin implementation av gQUIC sedan 2013. Om man tittar pÄ HTTP-förfrÄgan som skickas till Google-sökningen kan man se detta:
Slutsatser
QUIC ser nu ut som en ganska rÄ, men mycket lovande teknik. Med tanke pÄ att de senaste 20 Ären har all optimering av transportprotokoll frÀmst rört TCP, verkar QUIC, som i de flesta fall vinner pÄ prestandan, redan nu vara ganska bra.
Dock finns det fortfarande olösta problem som mÄste hanteras under de kommande Ären. Processen kan dra ut pÄ tiden eftersom det handlar om hÄrdvara som ingen gillar att uppdatera, men alla problem verkar ÀndÄ vara ganska lösbara, och förr eller senare kommer vi alla att ha HTTP/3.
Framtiden Àr nÀra!
KĂ€lla: habr.com
