Të paktën 20 vjet tani, ne shikojmë faqe web-i nëpërmjet protokollit HTTP. Shumica e përdoruesve nuk mendojnë fare se çfarë është dhe si funksionon. Të tjerët e dinë se diku nën HTTP ekziston TLS, që nën të ka TCP, nën të IP dhe kështu me radhë. Dhe të tretët – heretikët – mendojnë se TCP është një gjë e kaluar, ata duan diçka më të shpejtë, më të besueshme dhe më të mbrojtur. Por në përpjekjet e tyre për të shpikur një protokoll të ri ideal, ata janë kthyer tek teknologjitë e viteve '80 dhe përpiqen të ndërtosh një botë të re të mrekullueshme mbi to.
Pak histori: HTTP/1.1
Në vitin 1997, protokolli i shkëmbimit të informacionit tekstual HTTP versioni 1.1 fitoi RFC-në e tij. Në atë kohë, protokolli ishte përdorur nga shfletuesit për disa vjet, dhe standardi i ri zgjati edhe pesëmbëdhjetë vjet. Protokolli punonte vetëm në parimin kërkesë- përgjigje dhe ishte kryesisht i destinuar për shkëmbimin e informacionit tekstual.
HTTP u projektua për të funksionuar mbi protokollin TCP, i cili garanton dorëzimin e besueshëm të paketeve deri te destinacioni. Funksionimi i TCP bazohet në krijimin dhe mbajtjen e një lidhjeje të besueshme midis pikave përfundimtare dhe ndarjen e trafikut në segmente. Segmentet kanë numrin e tyre të rendit dhe një kontrollsumë. Nëse ndonjë nga segmentet nuk mbërrin ose mbërrin me një kontrollsumë të gabuar, atëherë transmetimi do të ndalet derisa të rikuperohet segmenti i humbur.
Në HTTP/1.0, lidhja TCP mbyllej pas çdo kërkese. Kjo ishte jashtëzakonisht shpenzuese, sepse krijimi i lidhjes TCP (3-Way-Handshake) është një proces i ngadaltë. Në HTTP/1.1 u prezantua mekanizmi keep-alive, i cili lejon ripërdorimin e një lidhjeje për disa kërkesa. Megjithatë, pasi ajo mund të bëhet shishe qelqi, në implementimet e ndryshme HTTP/1.1 lejohet hapja e disa lidhjeve TCP me një host të vetëm. Për shembull, në Chrome dhe në versionet e fundit të Firefox, lejohet deri në gjashtë lidhje.
Enkriptimi gjithashtu supozohej të lihej në dorë protokollëve të tjerë, dhe për këtë, mbi TCP filloi të përdorej protokolli TLS, i cili siguronte të dhënat mjaft besueshëm, por gjithashtu rriti edhe më shumë kohën e nevojshme për krijimin e lidhjes. Si rezultat, procesi i dorëzim-it u duk kështu:
Ilustrimi i Cloudflare
Kështu HTTP/1.1 kishte disa probleme:
- Instalim i ngadaltë i lidhjes.
- Të dhënat transmetohen në formë tekstuale, që do të thotë se transmetimi i imazheve, videove dhe informacionit tjetër jo tekstual është joefikas.
- Një lidhje TCP përdoret për një kërkesë, që do të thotë se kërkesat e tjera ose duhet të gjejnë një lidhje tjetër ose të presin derisa kërkesa aktuale ta lirojë atë.
- Mbështetet vetëm modeli pull. Në standart nuk ka asgjë për server-push.
- Kryesit transmetohen si tekst.
Nëse server-push realizohet me ndihmën e protokollit WebSocket, atëherë për problemet e tjera duhej të merreshin masa më radikale.
Pak modernizim: HTTP/2
Në vitin 2012, në rrjedhat e Google nisi puna për protokollin SPDY (të cilin e shqiptojmë "spidi"). Protokolli ishte krijuar për të zgjidhur problemet kryesore të HTTP/1.1 dhe në të njëjtën kohë duhej të ruante përputhshmërinë me versionin e mëparshëm. Në vitin 2015, grupi punues i IETF paraqiti specifikimin HTTP/2, të bazuar në protokollin SPDY. Ja çfarë dallimesh kishte në HTTP/2:
- Serializimi binar.
- Multipleximi i kërkesave të shumta HTTP në një lidhje TCP.
- Server-push nga kutia (pa WebSocket).
Protokolli bëri një hap të madh përpara. Ai ndjeshëm dhe nuk kërkon krijimin e disa lidhjeve TCP: të gjitha kërkesat ndaj një host-i janë të mnohuara në një. Pra, në një lidhje janë disa rrjedha të quajtura, secila prej të cilave ka ID-në e saj. Një bonus është server-push i paketuar.
Megjithatë, multipleximi sjell një tjetër problem themelor. Imagjinoni se ne ekzekutojmë asinkronisht 5 kërkesa ndaj një serveri. Përdorimi i HTTP/2 do të thotë se të gjitha këto kërkesa do të ekzekutohen brenda një lidhjeje TCP, që do të thotë se nëse një nga segmentet e çdo kërkese humbet ose vjen gabim, transmetimi i të gjitha kërkesave dhe përgjigjeve do të ndalet derisa të rikuperohet segmenti i humbur. Ose, 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ë gjithëve, HTTP/1.1 në shfletues tregon performancë më të mirë se HTTP/2, për shkak se hap 6 lidhje, dhe jo një.
Ky problem quhet "head-of-line blocking" dhe, fatkeqësisht, zgjidhja e tij duke përdorur TCP nuk duket e mundshme.
Ilustrimi Daniel Steinberg
Si përfundim, zhvilluesit e standardit HTTP/2 bënë një punë të madhe dhe bllokuan pothuajse gjithçka që mund të shkonte bërë në nivelin aplikativ të modelit OSI. Është koha të zbresim në nivelin e transportit dhe të shpikim një protokoll të ri transporti.
Na nevojitet një protokoll i ri: UDP vs TCP
Shpejt u bë e qartë se implementimi i një protokolli krejtësisht të ri në nivelin e transportit është një detyrë që nuk zgjidhet në realitetet e sotme. Problemi është se pajisjet e nivelit të transportit e dinë këtë nivel ose kutitë e mesme (router-at, firewall-et, serverat NAT…), dhe të mësosh ato për diçka të re është një detyrë shumë e vështirë. Përveç kësaj, mbështetje për protokollet e transportit është e integrohet në bërthamat e sistemeve operative, dhe bërthamat gjithashtu nuk ndryshojnë me shumë gatishmëri.
Dhe këtu do të mund të dorëzohej dhe të thuhej "Ne, sigurisht, do të shpikim HTTP/3 me preferencë dhe kurtezana, por ai do të implementohet pas 10-15 vitesh (për rreth një kohë të tillë shumica e pajisjeve do të zëvendësohen)", por ka një mundësi tjetër, jo aq të dukshme: të përdorim protokollin UDP. Po, po, ai protokoll, me të cilin ne dërgonim skedarë në LAN në fund të viteve '90 dhe fillim të viteve 2000. Pothuajse të gjitha pajisjet e sotme dinë ta përdorin atë.
Cilat janë avantazhet e UDP krahasuar me TCP? Në radhë të parë, se ne nuk kemi një sesion të nivelit të transportit, për të cilin pajisjet e dinë. Kjo na lejon të përcaktojmë vetë sesionin në pikët e fundit dhe të zgjidhim konfliktet që lindin aty. Pra, ne nuk jemi të kufizuar në një ose disa seanca (siç është në TCP), por mund të krijojmë sa më shumë seanca sa na nevojitet. Në të dytën, transferimi i të dhënave përmes UDP ndodh më shpejt se në TCP. Kështu, në teori, ne mund të kalojmë kufirin e shpejtësisë sot, të arritur në HTTP/2.
Megjithatë, UDP nuk garanton besueshmërinë e transferimit të të dhënave. Në fakt, ne thjesht dërgojmë paketa, duke shpresuar që ato do të priten në anën tjetër. Nuk u priten? Epo, nuk patëm fat... Kjo ishte e mjaftueshme për transmetimin e videove për të rritur, por për gjëra më serioze nevojitet besueshmëri, dhe kështu që do të duhet të shtojmë diçka tjetër mbi UDP.
Si dhe 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 paraqiti atë për publikun. , dhe në vitin 2015 u paraqit një Draft Interneti për standardizimin në IETF. Në atë kohë, protokolli i zhvilluar nga Roskind në Google ishte shumë ndryshe nga ai i propozuar për standard, kështu që versioni i Google u quajt gQUIC.
Çfarë është QUIC
Së pari, siç u tha tashmë, është një mbështetje mbi UDP. Përsipër UDP krijohet një lidhje QUIC, në të cilën, sipas analogjisë me HTTP/2, mund të ekzistojnë disa rrjedha. Këto rrjedha ekzistojnë vetëm në pikët përfundimtare dhe shërbehen në mënyrë të pavarur. Nëse ndodh humbja e një pakete në një rrjedhë, të tjerat nuk preken aspak.
Ilustrimi Daniel Steinberg
Së dyti, enkriptimi tani implementohet jo si një nivel i veçantë, por është i përfshirë në protokoll. Kjo mundëson vendosjen e lidhjes dhe shkëmbimin e çel save publike në një dorëheqje, si dhe përdorimin e mekanizmit të veçantë 0-RTT handshake, duke shmangur vonesat gjatë dorëheqjes. Për më tepër, tani është e mundur të enkriptohen paketa të veçanta të dhënash. Kjo lejon që të mos pritet përfundimi i marrjes së të dhënave nga rrjedha, por të dekriptohen paketat e marra në mënyrë të pavarur. Ky mënyrë funksionimi ishte krejtësisht e pamundur në TCP, pasi TLS dhe TCP punonin në mënyrë të pavarur nga njëri-tjetri, dhe TLS nuk mund të dinte se në cilat copa do të copëzoheshin të dhënat nga TCP. Prandaj, nuk mund të përgatitej segmentet e tij në mënyrë që ato të përputheshin segmentet TCP një për një dhe të ishin për t'u dekriptuar në mënyrë të pavarur. Të gjitha këto përmirësime lejojnë QUIC të ulë vonesën krahasuar me TCP.
Së treti, koncepti i rrjedhave të lehta lejon ndarjen e lidhjes nga adresa IP e klientit. Kjo është e rëndësishme, për shembull, kur klienti kalon nga një pikë qasjeje Wi-Fi në një tjetër, duke ndryshuar IP-në e tij. Në këtë rast, duke përdorur TCP ndodh një proces i gjatë, gjatë të cilit lidhjet ekzistuese TCP bien për shkak të kohës së pritjes dhe krijohen lidhje të reja me IP-në e re. Në rastin e QUIC, klienti vazhdon thjesht të dërgojë paketa serverit me IP-në e re dhe ID-në e vjetër të rrjedhës. Duke qenë se ID-ja e rrjedhës tani është unike dhe nuk ri-përdoret, serveri kupton se klienti ka ndryshuar IP-në, dërgon paketat e humbura dhe vazhdon komunikimin me adresën e re.
Së fundmi, QUIC implementohet në nivelin e aplikacionit dhe jo në nivelin e sistemit operative. Kjo, nga njëra anë, lejon të bëhen ndryshime më shpejta në protokoll, sepse për të marrë një përditësim mjafton të azhurnosh bibliotekën, dhe jo të presësh një version të ri të OS-së. Nga ana tjetër, kjo çon në një rritje të konsiderueshme të përdorimit të procesorit.
Dhe si përfundim, titujt. Kompresimi i titujve është pikërisht një nga ato elemente që ndryshojnë në QUIC dhe gQUIC. Nuk e shoh të arsyeshme të kushtoj shumë kohë kësaj, do të thosha vetëm se në versionin e paraqitur për standardizim, kompresimi i titujve u bë maksimalisht i ngjashëm me kompresimin e titujve në HTTP/2. Më shumë mund të lexoni .
Sa më shpejt është?
Ky është një pyetje e komplikuar. Problemi është se deri tani nuk kemi një standard, prandaj nuk ka shumë për të matur. Ndoshta, të dhënat statistikore të vetme që kemi – statistikat e Google që nga viti 2013 e deri më 2016 , se rreth 90% e trafikut që shkon në serverat e tyre nga shfletuesi Chrome tani përdor QUIC. Në të njëjtën prezantim ata njoftojnë se përmes gQUIC, faqet e internetit ngarkohen rreth 5% më shpejt, ndërsa në video streaming ka 30% më pak ngecje krahasuar me TCP.
Në vitin 2017, një grup hulumtuesish nën drejtimin e Arash Molavi Kakhki publikoi për studimin e performancës së gQUIC krahasuar me TCP.
Studimi zbuloi disa dobësi të gQUIC, siç janë pasiguria ndaj përzierjes së paketave të rrjetit, lakmia (në mënyrë të padrejtë) ndaj bantës së kanalit dhe transmetimi më i ngadaltë i 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ë hulumtuara, gQUIC tregoi një rritje të shpejtësisë krahasuar me TCP. Për numra konkretë këtu është e vështirë të flasim. Më mirë të lexoni или .
Këtu duhet thënë se këto janë të dhëna pikërisht për gQUIC, dhe ato nuk janë aktuale për standardin në zhvillim. Çfarë do të ndodhë me QUIC: për momentin mbetet një mister, por ka shpresë që dobësitë e zbuluara te gQUIC do të merreshin parasysh dhe do të rregulloheshin.
Pak për të ardhmen: çfarë do të ndodhë me HTTP/3?
Dhe, këtu është gjithçka e qartë: API nuk do të ndryshojë. Të gjitha do të mbeten ashtu siç ishin në HTTP/2. Nëse API mbetet e njëjtë, kalimi në HTTP/3 do të duhet të realizohet duke përdorur një version të ri të bibliotekës në backend që mbështet transportin përmes QUIC. Megjithatë, do të jetë shumë kohë deri sa të kemi një kalim të plotë në UDP, sepse interneti aktualisht nuk është i gatshëm për këtë.
Kush mbështet tashmë
Ja implementime ekzistuese të QUIC. Megjithëse nuk ka një standard, lista është e mirë.
Asnjë shfletues aktualisht nuk mbështet QUIC në versionin prodhues. Kohët e fundit kishte informacione se Chrome kishte aktivizuar mbështetje për HTTP/3, por për momentin vetëm në Canary.
Nga backend-et, HTTP/3 mbështetet vetëm и , por për momentin eksperimental. NGINX në fund të pranverës 2019 , që filluan punën për të mbështetur 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ë masat pa u përballur me rezistencë, dhe QUIC nuk është përjashtim.
Më e rëndësishmja, duhet ndonjëherë të shpjegohet shfletuesit se “https://” tani nuk është e sigurt që çon në portin TCP 443. Atje mund të mos ketë fare TCP. Për këtë përdoret titulli Alt-Svc. Ai lejon të njoftosh shfletuesin se ky uebsajt është gjithashtu i aksesueshëm në një protokoll të tillë në një adresë të tillë. Në teori, kjo duhet të funksionojë si orë, por praktikisht do të hasim në atë që UDP mund të jetë, për shembull, i ndaluar në firewall për të shmangur sulmet DDoS.
Por edhe nëse UDP nuk është i ndaluar, klienti mund të jetë nën një router NAT i cili është konfiguruar për të mbajtur sesionin TCP mbi adresën IP, dhe pasi ne përdorim UDP, në të cilin nuk ka një sesion të pajisjeve, NAT nuk do të mbajë lidhjen, dhe seanca QUIC .
Të gjitha këto probleme lidhen me faktin se UDP nuk është përdorur më parë për transmetimin e përmbajtjes në internet, dhe prodhuesit e pajisjeve nuk mund të parashikonin se kjo do të ndodhte një ditë. Po ashtu, administratorët nuk e kuptojnë ende mirë se si të konfirmojnë rrjetet e tyre për të punuar me QUIC. Ky situatë do të ndryshojë gradualisht, dhe në çdo rast, këto ndryshime do të marrin më pak kohë se sa implementimi i një protokolli të ri të nivelit të transportit.
Përveç kësaj, siç është përshkruar më parë, QUIC ndjeshëm rrit përdorimin e procesorit. Daniel Stenberg rritjen në procesor deri në tre herë.
Kur do të vijë HTTP/3
Standarti Në maj të vitit 2020, por duke marrë parasysh që deri tani dokumentet e planifikuara për korrik 2019 janë ende të papërfunduara, mund të thuhet se data për këtë ka shumë të ngjarë të shtyhet.
Ndërsa Google përdor realizimin e tij të gQUIC që nga viti 2013. Nëse shikoni kërkesën HTTP që dërgohet në motorin e kërkimit të Google, mund të shihni këtë:
Përfundimet
QUIC tani duket si një teknologji mjaft e papjekur, por me shumë potencial. Duke pasur parasysh se gjatë 20 viteve të fundit të gjitha optimizimet e protokolleve të nivelit të transportit kanë pasur si fokus kryesor TCP, QUIC, që në shumicën e rasteve fiton në performancë, duket tashmë shumë mirë.
Megjithatë, ende ka disa probleme të pa zgjidhura që do të duhet të trajtohen në vitet e ardhshme. Procesi mund të zgjatet për shkak të harduerit që askush nuk e do të azhurnojë, megjithatë, të gjitha problemet duken mjaft të zgjidhshme dhe vonë a herët të gjithëve do të kemi HTTP/3.
Të ardhmen nuk është larg!
Burimi: habr.com
