Këto 20 vitet e fundit, ne kemi eksploruar faqet e internetit përmes protokollit HTTP. Shumica e përdoruesve nuk mendojnë kurrë se çfarë është dhe si funksionon. Të tjerë e dinë se nën HTTP qëndron TLS, dhe nën të TCP, nën të IP, etj. Ndërsa të tretë - heretikët - mendojnë se TCP është një gjë e kaluar, ata synojnë diçka më të shpejtë, të besueshme dhe të sigurt. Por në përpjekjet e tyre për të shpikur një protokoll ideal të ri, ata janë rikthyer te teknologjitë e viteve '80 dhe përpiqen të ndërtojnë mbi to një botë të re, të mrekullueshme.
Pak histori: HTTP/1.1
Në vitin 1997, protokolli i shkëmbimit të informacionit tekstual HTTP versioni 1.1 mori RFC-në e tij. Në atë kohë, protokolli ishte përdorur nga shfletuesit për disa vite, dhe standardi i ri qëndroi për pesëmbëdhjetë vjet të tjera. Protokolli punonte vetëm mbi bazën e një modeli kërkesë-përgjigje dhe ishte kryesisht i dedikuar për transmetimin e informacionit tekstual.
HTTP ishte dizajnuar për të punuar mbi protokollin TCP, që garanton dorëzimin e besueshëm të paketave deri te destinacioni. Funksionimi i TCP bazuar në vendosjen dhe mbajtjen e një lidhjeje të besueshme midis pikave përfundimtare dhe ndarjes së trafikëve në segmente. Segmentet kanë numrin e tyre sekondar dhe një checksum. Nëse ndonjëherë ndonjë nga segmentet nuk mbërrin ose arrin me një checksum të gabuar, atëherë shkëmbimi do të ndalojë derisa të rikuperohet segmenti i humbur.
Në HTTP/1.0, lidhja TCP u mbyll pas çdo kërkese. Kjo ishte jashtëzakonisht e shpenzuar, pasi vendosja e lidhjes TCP (3-Way-Handshake) është një proces i ngadalshëm. Në HTTP/1.1 u prezantua mekanizmi keep-alive, i cili lejon rinovimin e një lidhje për disa kërkesa. Megjithatë, pasi mund të bëhet lehtësisht një ngushticë, në implementime të ndryshme të HTTP/1.1 lejohet hapja e disa lidhjeve TCP për një host të vetëm. Për shembull, në Chrome dhe në versionet e fundit të Firefox është e lejuar deri në gjashtë lidhje.
Kriptimi parashikohej gjithashtu të ishte lënë në duar të protokolleve të tjera, dhe për këtë arsye mbi TCP filloi përdorimi i protokollit TLS, i cili mbron me besueshmëri të dhënat, por gjithashtu rriti më tej kohën e nevojshme për vendosjen e lidhjes. Në përfundim, procesi i dorëzimit duket kështu:
Ilustrimi Cloudflare
Kështu, HTTP/1.1 kishte një sërë problemesh:
- Vendosje e ngadalshme e lidhjes.
- Të dhënat transmetohen në një format tekstual, që do të thotë se transmetimi i imazheve, videove dhe informacionit tjetër jo-tekstual nuk është efikas.
- Një lidhje TCP përdoret për një kërkesë, kështu që kërkesat e tjera duhet ose të gjejnë një lidhje tjetër ose të presin derisa kërkesa aktuale të lirohet.
- Mbështetet vetëm modeli pull. Në standard nuk ka asgjë për server-push.
- Header-at transmetohen si tekst.
Nëse server-push realizohet mjaft mirë përmes protokollit WebSocket, atëherë me problemet e tjera do të duhej të merreshim më radikalisht.
Pak modernitet: HTTP/2
Në vitin 2012, në brendësi të Google filloi puna mbi protokollin SPDY (shkruhet 'spidi'). Protokolli u krijua për të zgjidhur problemet kryesore të HTTP/1.1 dhe gjithashtu duhet të ruante prapavijën përkatëse. Në vitin 2015, grupi i punës IETF paraqiti specifikimin HTTP/2, i bazuar në protokollin SPDY. Këtu janë ndryshimet në HTTP/2:
- Serializimi binar.
- Multipleximi i disa kërkesave HTTP në një lidhje TCP.
- Server-push nga kutia (pa WebSocket).
Protokolli bëri një hap të madh përpara. Ai dhe nuk kërkon krijimin e disa lidhjeve TCP: të gjitha kërkesat për një host janë të multipluara në një. Pra, në një lidhje ka disa 'streams', secili me ID-në e tij. Si bonus, vjen server-push i kutisë.
Megjithatë, multipleximi shpien në një problem tjetër themelor. Imagjinoni se ne ekzekutojmë asinkronikisht 5 kërkesa për një server të vetëm. Kur përdorim HTTP/2, të gjitha këto kërkesa do të ekzekutohen në kuadër të një lidhje TCP, dhe kështu, nëse një nga segmentet e ndonjë kërkese humbet ose arrin gabim, transmetimi i të gjitha kërkesave dhe përgjigjeve do të ndalojë derisa të rikuperohet segmenti i humbur. Është evidente se sa më keq të jetë cilësia e lidhjes, aq më ngadalë funksionon HTTP/2. , në kushte ku paketat e humbura përbëjnë 2% të të gjitha, HTTP/1.1 në shfletues tregon më mirë se HTTP/2 duke hapur 6 lidhje, jo një.
Ky problem quhet 'blocking i head-of-line' dhe, fatkeqësisht, nuk duket se mund të zgjidhet duke përdorur TCP.
Ilustrimi Daniel Steinberg
Si përfundim, zhvilluesit e standardit HTTP/2 bënë një punë të jashtëzakonshme dhe bënë praktikisht gjithçka që mund të bëhej në nivelin aplikativ të modelit OSI. Ka ardhur koha të kalojmë në nivelin e transportit dhe të shpikim një protokoll të ri transporti.
Na nevoja një protokoll të ri: UDP vs TCP
Shpejt u bë e qartë se të implementosh një protokoll krejt të ri në nivelin e transportit është një detyrë e pa zgjidhshme në realitetet e sotme. Kjo për shkak se pajisjet e nivelit të transportit janë njohur me mekanizmat apo middle-boxes (routerat, firewall-et, serverat NAT…), dhe të mësojmë ato për diçka të re është një detyrë mjaft e vështirë. Përveç kësaj, mbështetje për protokollet e transportit është e inkorporuar në kernelët e sistemeve operative, dhe kernelët gjithashtu nuk ndryshojnë aq lehtë.
Dhe këtu mund të heqim dorë dhe të themi "Sigurisht, do ta shpikim një HTTP/3 me preferenca dhe kurtizana, por do të zbatohen për 10-15 vjet (afërsisht në atë kohë shumica e pajisjeve do të zëvendësohen)", por ka një opsion tjetër jo aq të dukshëm: të përdorim protokollin UDP. Po, ai protokoll mbi të cilin ne dërgonim skedarë në rrjetin lokal në fund të viteve '90 dhe fillim të viteve 2000. Praktikisht të gjitha pajisjet e sotme dinë të punojnë me të.
Cilat janë avantazhet e UDP në krahasim me TCP? Së pari, është se nuk kemi sesion në nivelin e transportit, për të cilin pajisjet janë të informuara. Kjo na lejon të përcaktojmë vetë sesionin në pikat përfundimtare dhe atje të zgjidhim konfliktet që lindin. Kështu, ne nuk jemi të kufizuar në një ose disa seanca (si në TCP), por mund të krijojmë sa më shumë sa na nevojitet. Së dyti, transferi i të dhënave përmes UDP ndodh më shpejt se përmes TCP. Prandaj, në teori, mund të kalojmë plafonin e shpejtësisë aktual të arritur në HTTP/2.
Megjithatë, UDP nuk garanton besueshmërinë e transferimit të të dhënave. Në thelb, ne thjesht dërgojmë paketa, duke shpresuar se do të marrin në anën tjetër. Nuk e morën? Fatkeqësisht... Kjo ishte e mjaftueshme për transmetimin e videove për të rritur, por për gjëra më serioze na nevojitet besueshmëria, dhe kjo do të thotë se do të duhet të shtojmë diçka të tjera mbi UDP.
Ashtu si në rastin e HTTP/2, puna për krijimin e një protokolli të ri filloi në Google në vitin 2012, pra rreth të njëjtës kohë me fillimin e punës mbi SPDY. Në vitin 2013, Jim Roskind e prezantoi për publikun e gjerë , dhe gjatë vitit 2015, u paraqit një Draft Interneti për standardizim në IETF. Në atë kohë, protokolli i zhvilluar nga Roskind në Google dallohej ndjeshëm nga ai që ishte propozuar për standardizim, prandaj versioni i Google u quajt gQUIC.
Çfarë është QUIC
Së pari, siç u tha më parë, është një mbështjellës mbi UDP. Pjesa mbi UDP ngjitet QUIC-connection, në të cilën, ngjashëm me HTTP/2, mund të ekzistojnë disa stream. Këto stream ekzistojnë vetëm në pikat përfundimtare dhe shërbehen në mënyrë të pavarur. Nëse ndodhi humbja e një pakete në një stream, të tjerët nuk preken fare.
Ilustrimi Daniel Steinberg
Së dyti, enkriptimi tani realizohet jo si një nivel të veçantë, por është i inkorporuar në protokoll. Kjo lejon të krijojmë një lidhje dhe të shkëmbejmë çelësat publikë me një dorëheqje, dhe gjithashtu lejon përdorimin e mekanizmit të mençur 0-RTT handshake dhe të shmangim vonesat gjatë dorëzimit. Për më tepër, tani mund të enkriptojmë paketa të veçanta të dhënash. Kjo lejon që të mos presim përfundimin e pranimit të të dhënave nga stream-i, por të deshifrojmë paketat e marra në mënyrë të pavarur. Ky mod për punë ishte krejtësisht i pamundur në TCP, sepse TLS dhe TCP punonin pavarësisht njëri-tjetrit, dhe TLS nuk mund të dinte se në cilat copa do të copëtoheshin të dhënat nga TCP. Prandaj, nuk mund të përgatitetin segmentet e tyre që të përputhen segmentet TCP një të njëjtë dhe të mund të deshifroheshin në mënyrë të pavarur. Të gjitha këto përmirësime lejojnë QUIC të zvogëlojë latency-n në krahasim me TCP.
Së treti, koncepti i stream-eve të lehta lejon që të çlirohet lidhja nga adresa IP e klientit. Kjo është e rëndësishme, për shembull, kur klienti kalon nga një pikë aksesi Wi-Fi në një tjetër, duke ndryshuar adresën e tij IP. Në këtë rast, përdorimi i TCP përfshin një proces të gjatë, gjatë të cilit lidhjet ekzistuese TCP ndalen për shkak të kohës së pritjes dhe krijohen lidhje të reja nga adresa IP e re. Në rastin e QUIC, klienti thjesht vazhdon të dërgojë paketa në server nga adresa IP e re me ID-në e vjetër të stream-it. Duke qenë se ID i stream-it tani është unik dhe nuk ripërdoret, serveri kupton se klienti ka ndërruar IP-në, dërgon paketat e humbura dhe vazhdon komunikimin në adresën e re.
Së katërtash, QUIC implementohet në nivelin e aplikacionit, jo në nivelin e sistemit operativ. Kjo, nga njëra anë, lejon që ndryshimet në protokoll të bëhen më shpejt, sepse për të marrë një përditësim mjafton të përditësosh bibliotekën, në vend që të presësh një version të ri të OS-së. Nga ana tjetër, kjo çon në rritjen e konsiderueshme të konsumit të procesorit.
Dhe për të përfunduar, titujt. Kompresimi i titujve është një nga aspektet që dallojnë në QUIC dhe gQUIC. Nuk e shoh të arsyeshme të kaloj shumë kohë mbi këtë, do të them vetëm se në versionin e dorëzuar për standardizim, kompresimi i titujve është bërë sa më i ngjashëm me kompresimin e titujve në HTTP/2. Më shumë mund të lexoni .
Sa më shpejt është?
Kjo është një pyetje komplekse. E vërteta është se tani nuk kemi një standard, ndaj nuk kemi shumë për të matur. Ndoshta, të dhënat e vetme statistikore që kemi janë statistikat e Google, i cili ka përdorur gQUIC që nga viti 2013 dhe në vitin 2016 , se rreth 90% e trafikut që i shkon serverëve të tyre nga shfletuesi Chrome tani përdor QUIC. Në këtë prezantim ata njoftojnë se përmes gQUIC, faqet ngarkohen rreth 5% më shpejt, dhe në video streaming ka 30% më pak ndërprerje krahasuar me TCP.
Në vitin 2017, një grup hulumtuesish i udhëhequr nga Arash Molavi Kakhki publikoi një studim mbi performancën e gQUIC krahasuar me TCP.
Studimi zbuloi disa dobësi të gQUIC, si paaftësia për të qëndruar e qëndrueshme ndaj shkëmbimit të paketave rrjetit, ngopjen (papërshtatshmërinë) ndaj kapacitetit të kanalit dhe dërgimin më të ngadaltë të objekteve të vogla (deri në 10 kB). Sidoqoftë, kjo e fundit mund të kompensohet duke përdorur 0-RTT. Në të gjitha rastet e tjera të shqyrtuara, gQUIC tregoi një rritje të shpejtësisë krahasuar me TCP. Për shifrat konkrete është e vështirë të flitet. Më së miri është të lexoni ose .
Këtu duhet thënë se këto të dhëna janë për gQUIC, dhe ato nuk janë të azhurnuara për standardin në zhvillim. Ajo që do të ndodhë për QUIC: për momentin është një mister i ruajtur mirë, por ka shpresë se dobësitë e identifikuara te gQUIC do të merren parasysh dhe do të korrigjohen.
Pak për të ardhmen: çfarë po ndodh me HTTP/3?
Këtu gjithçka është kristalisht e qartë: API nuk do të ndryshojë. Gjithçka do të mbetet ashtu siç ishte në HTTP/2. Nëse API mbetet i njëjtë, kalimi në HTTP/3 duhet të zgjidhet duke përdorur një version të ri të bibliotekës së pasmë, që mbështet transportin nëpërmjet QUIC. Megjithatë, ende do të duhet të mbajmë një fallback në versionet e vjetra të HTTP, sepse interneti aktualisht nuk është i gatshëm për një kalim të plotë në UDP.
Kush e mbështet tashmë
Këtu është implementimin ekzistues të QUIC. Pavarësisht mungesës së standardit, lista është e mirë.
Asnjë shfletues aktualisht nuk mbështet QUIC në versionin e prodhimit. Së fundmi, kishte informacione që në Chrome u aktivizua mbështetje për HTTP/3, por për momentin vetëm në Canary.
Nga backend-et, vetëm dhe , por për momentin eksperimentalisht. NGINX në fund të pranverës 2019 , që filluan punën për mbështetje të HTTP/3, por ende nuk e kanë përfunduar.
Cilat janë problemet
Ne jetojmë në një botë reale, ku asnjë teknologji e madhe nuk mund të kalojë në masë pa u përballur me rezistencë, dhe QUIC nuk është përjashtim.
Më e rëndësishmja, duhet në një mënyrë të qartë që t'i shpjegojmë shfletuesit se “https://” tani nuk është fakt që çon në portin 443 të TCP. Atje mund të mos ketë fare TCP. Për këtë përdoret titulli Alt-Svc. Ai lejon të informohet shfletuesi se ky website është gjithashtu i aksesueshëm në një protokoll të caktuar në një adresë të caktuar. Në teorinë, kjo duhet të funksionojë si ore, por në praktikë ndeshemi me faktin se UDP mund të jetë, për shembull, i ndaluar në firewall për të parandaluar sulmet DDoS.
Por edhe nëse UDP nuk është i ndaluar, klienti mund të jetë pas një router NAT, i cili është i konfiguruar për të mbajtur sesionet TCP përmes adresës IP, dhe pasi përdorim UDP që nuk ka një seancë fizike, NAT nuk do të mbajë lidhjen dhe seanca e QUIC .
Të gjitha këto probleme lidhen me faktin se UDP më parë nuk ishte përdorur për transmetimin e përmbajtjes së internetit dhe prodhuesit e pajisjeve nuk mund të parashikonin që diçka e tillë do të ndodhte një ditë. Po ashtu, administratorët ende nuk e kuptojnë mirë se si të konfigurojnë rrjetet e tyre për të punuar me QUIC. Kjo situatë do të ndryshojë ngadalë, dhe në çdo rast, një ndryshim i tillë do të marrë më pak kohë sesa për të futur një protokoll të ri në nivelin e transportit.
Për më tepër, siç është përshkruar më parë, QUIC rrit ndjeshëm përdorimin e procesorëve. Daniel Stenberg rritjen e procesorëve deri në tre herë.
Kur do të ndodhë HTTP/3
Standardi deri në maj 2020, por duke marrë parasysh se aktualisht dokumentet mbeten të papërfunduara, të planifikuara për korrik 2019, mund të themi se data përfundimisht do të shtyhet.
Por më shumë se 10 vjet, Google ka përdorur implementimin e tij të gQUIC që nga viti 2013. Nëse hedhim një Blick në kërkesën HTTP që i dërgohet motorit të kërkimit të Google, mund ta shohim këtë:
Përfundimet
QUIC aktualisht duket si një teknologji e papjekur, por shumë premtuese. Duke marrë parasysh se për 20 vitet e fundit, të gjitha optimizimet e protokolleve të nivelit të transportit kanë qenë kryesisht për TCP, QUIC, i cili në shumë raste fiton në performancë, duket tashmë mjaft mirë.
Megjithatë, ende ekzistojnë probleme të pazgjidhura me të cilat do të duhet të merremi në vitet në vijim. Procesi mund të zgjatet për shkak të pajisjeve, të cilat askush nuk i pëlqen t'i përditësojë, por megjithatë të gjitha problemet duken mjaft të zgjidhshme, dhe sooner apo later të gjithë ne do të kemi HTTP/3.
E ardhmja është afër!
Burimi: habr.com
