Protokolli QUIC Ă«shtĂ« jashtĂ«zakonisht interesant pĂ«r t'u ndjekur, prandaj na pĂ«lqen tĂ« shkruajmĂ« pĂ«r tĂ«. Por nĂ«se publikimet e mĂ«parshme pĂ«r QUIC kishin njĂ« karakter mĂ« shumĂ« historik (regional, nĂ«se doni) dhe pĂ«rmbajtje teknike, sot jemi tĂ« lumtur tĂ« publikojmĂ« njĂ« pĂ«rkthim tjetĂ«r â do tĂ« flasim pĂ«r aplikimin e vĂ«rtetĂ« tĂ« protokollit nĂ« vitin 2019. Dhe nuk flasim pĂ«r njĂ« infrastrukturĂ« tĂ« vogĂ«l, tĂ« bazuar nĂ« njĂ« garazh tĂ« zakonshĂ«m, por pĂ«r Uber, i cili operon nĂ« pothuajse tĂ« gjithĂ« botĂ«n. Si arritĂ«n inxhinierĂ«t e kompanisĂ« tĂ« vendosin tĂ« pĂ«rdorin QUIC nĂ« prodhim, si e realizuan testimin dhe çfarĂ« panĂ« pas fillimit nĂ« prodhim â mĂ« poshtĂ«.
Imazhet janë të klikueshme. Lexim të këndshëm!
Uber Ă«shtĂ« nĂ« njĂ« shkallĂ« globale, pĂ«rkatĂ«sisht nĂ« 600 qytete, nĂ« secilin prej tĂ« cilave aplikacioni mbĂ«shtetet plotĂ«sisht nĂ« internetin pa tel nga mĂ« shumĂ« se 4500 operatorĂ« celularĂ«. PĂ«rdoruesit presin qĂ« aplikacioni tĂ« funksionojĂ« jo vetĂ«m shpejt, por nĂ« realitet â pĂ«r ta siguruar kĂ«tĂ«, aplikacioni Uber ka nevojĂ« pĂ«r vonesa tĂ« ulta dhe njĂ« lidhje shumĂ« tĂ« besueshme. FatkeqĂ«sisht, por staku ndihen se ndihen keq nĂ« rrjetet wireless dinamike dhe me tendencĂ« nĂ« humbje. Ne kuptuam se nĂ« kĂ«tĂ« rast performanca e ulĂ«t Ă«shtĂ« drejtpĂ«rdrejt e lidhur me implementimet e TCP nĂ« bĂ«rthamat e sistemeve operative.
Për të zgjidhur problemin, ne zbatuam , një protokoll modern me shumëkanalizim, i cili na jep më shumë kontroll mbi performancën e protokollit të transportit. Momentalisht, grupi i punës po standardizon QUIC si .
Pas testeve të hollësishme, arritëm në përfundimin se implementimi i QUIC në aplikacionin tonë do të zvogëlojë vonesat "e bishtit" në krahasim me TCP. Vërejtëm një ulje në përmasën 10-30% për trafikun HTTPS në shembujt e aplikacioneve të shoferit dhe pasagjerit. Gjithashtu, QUIC na dha kontroll të plotë mbi paketat e përdoruesve.
Në këtë artikull ne ndajmë përvojën tonë në optimizimin e TCP për aplikacionet Uber me ndihmën e një staku që mbështet QUIC.
Fjala e fundit e teknikës: TCP
Sot, TCP Ă«shtĂ« protokolli mĂ« i pĂ«rdorur pĂ«r transportin e trafikut HTTPS nĂ« internet. TCP siguron njĂ« flux tĂ« besueshĂ«m byte, duke u pĂ«rballur kĂ«shtu me ngarkesat nĂ« rrjet dhe humbjet nĂ« nivelin e kanalit. PĂ«rdorimi i gjerĂ« i TCP pĂ«r trafikun HTTPS shpjegohet nga pĂ«rhapja e tij (gati çdo OS pĂ«rmban TCP), pĂ«rshkueshmĂ«ria nĂ« shumicĂ«n e infrastrukturĂ«s (pĂ«r shembull, nĂ« balancuesit e ngarkesĂ«s, HTTPS-proxyt dhe CDN) dhe funksionaliteti âout of the boxâ, i cili Ă«shtĂ« i disponueshĂ«m nĂ« shumicĂ«n e platformave dhe rrjeteve.
PĂ«r shumicĂ«n e pĂ«rdoruesve, aplikacioni ynĂ« pĂ«rdoret nĂ« lĂ«vizje, dhe vonesat âtailâ tĂ« TCP ishin shumĂ« larg kĂ«rkesave tĂ« trafikut tonĂ« HTTPS nĂ« kohĂ« reale. ThĂ«nĂ« thjesht, kĂ«tĂ« e pĂ«rjetonin pĂ«rdoruesit nĂ« tĂ« gjithĂ« botĂ«n - nĂ« Figurin 1 pasqyrohen vonesat nĂ« qytete tĂ« mĂ«dha:
Figura 1. Shkalla e vonesave âtailâ ndryshon nĂ« qytetet kryesore tĂ« pranishme nga Uber.
MegjithĂ«se vonesat nĂ« rrjetet indiane dhe braziliane ishin mĂ« tĂ« larta se ato nĂ« SHBA dhe Britani, vonesat âtailâ ishin ndjeshĂ«m mĂ« tĂ« larta se mesatarja. Dhe kjo Ă«shtĂ« e vĂ«rtetĂ« edhe pĂ«r SHBA-nĂ« dhe BritaninĂ«.
Performanca e TCP në ajër
TCP është krijuar për rrjetet kabllore, domethënë me theks në lidhjet e parashikueshme. Megjithatë, rrjetet pa tela kanë veçoritë dhe sfidat e tyre. Së pari, rrjetet pa tela janë të ndjeshme ndaj humbjeve për shkak të ndërhyrjeve dhe zbehtësisë së sinjalit. Për shembull, rrjetet Wi-Fi janë të ndjeshme ndaj mikrovaleve, bluetooth-it dhe valëve të tjera radio. Rrjetet celulare vuajnë nga humbja e sinjalit ( humbje rrugës ) për shkak të reflektimit/absorbimit të sinjalit nga objektet dhe ndërtimet, si dhe nganga . Kjo çon në vonesa më të mëdha (4-10 herë) dhe më të ndryshme dhe humbjeve të paketave në krahasim me lidhjen kabllore. teprica e buffering në rrjet, fryrja e buferit
), dhe kjo është një (), dhe kjo është shumë internetit modern.
Më në fund, performanca e rrjetit celular ndryshon në varësi të operatorit të lidhjes, rajonit dhe kohës. Në Figurën 2 kemi mbledhur vonesat mesatare të trafikut HTTPS për qelizat në një distancë prej 2 kilometrash. Të dhënat janë mbledhur për dy operatorët më të mëdhenj celularë në Delhi, Indi. Siç mund të vëreni, performanca ndryshon nga qeliza në qelizë. Gjithashtu, performanca e një operatori ndryshon nga performanca e operatorit tjetër. Kjo ndikohet nga faktorë të tillë si modelet e hyrjes në rrjet duke marrë parasysh kohën dhe lokacionin, lëvizshmërinë e përdoruesve, si dhe infrastrukturën rrjetore duke marrë parasysh dendësinë e kullave dhe raportin e llojeve të rrjetit (LTE, 3G, etj.).
Figura 2. Vonësi mbi një rreth prej 2 kilometrash. Delhi, Indi.
Po ashtu, performanca e rrjeteve celulare ndryshon me kalimin e kohĂ«s. NĂ« FigurĂ«n 3 tregohet vonesa mesatare sipas ditĂ«ve tĂ« javĂ«s. Ne gjithashtu vĂ«zhguam ndryshime nĂ« njĂ« shkallĂ« mĂ« tĂ« vogĂ«l â brenda njĂ« dite dhe njĂ« ore.
Figura 3. Vonësit përfundimtare mund të ndryshojnë ndjeshëm në ditë të ndryshme, por për të njëjtin operator.
Të gjitha të përmendurat më sipër çojnë në atë që performanca e TCP-së është e parregullt në rrjetet pa tel. Megjithatë, përpara se të kërkojmë alternativa për TCP, ne do të donim të zhvillonim një kuptim të saktë në lidhje me piketat e mëposhtme:
- a është TCP përgjegjës kryesor për vonesat në tail në aplikacionet tona?
- a kanë rrjetet moderne vonesa të dukshme dhe të diversifikuara (RTT)?
- çfarë ndikimi kanë RTT dhe humbjet në performancën e TCP-së?
Analiza e performancës së TCP-së
Për të kuptuar se si ne analizuam performancën e TCP-së, le të kujtojmë shkurtimisht se si TCP transmeton të dhëna nga dërguesi te marresi. Fillimisht, dërguesi krijon një lidhje TCP, duke realizuar një tre-anëtarësh: : dërguesi dërgon një paketë SYN, pret një paketë SYN-ACK nga marresi, pastaj dërgon një paketë ACK. Dy kalime të tjera janë të nevojshme për të krijuar lidhjen TCP. Marrësi konfirmon marrjen e çdo pakete (ACK) për të siguruar një dorëzim të sigurt.
Nëse një paketë ose ACK humbet, dërguesi bën një retransmit pas kohëmatësit (RTO, ). RTO llogaritet dinamikisht, mbi bazën e faktorëve të ndryshëm, për shembull, mbi vonesën e parashikuar RTT midis dërguesit dhe marrësit.
Figura 4. Këmbimi i paketave përmes TCP/TLS përfshin mekanizmat e retransmitimit.
Për të përcaktuar se si funksiononte TCP në aplikacionet tona, ne ndoqëm paketat TCP nëpërmjet për një javë mbi trafikun në prodhim që vjen nga serverët kufitarë indianë. Më pas analizuam lidhjet TCP përmes . Për më tepër, ne krijuam një aplikacion Android, i cili dërgon trafik të emuluar në serverin testues, duke imituar sa më afër që të jetë e mundur trafikun real. Smartphone-t me këtë aplikacion u shpërndanë disa punonjësve që mbledhën log-et për disa ditë.
Rezultatet e tĂ« dy eksperimenteve ishin tĂ« lidhura me njĂ«ra-tjetrĂ«n. VĂ«rejtĂ«m vonesa tĂ« larta RTT; vlerat ekstreme ishin pothuajse 6 herĂ« mĂ« tĂ« larta se mesatarja; vlera mesatare e vonesave â mĂ« shumĂ« se 1 sekondĂ«. ShumĂ« lidhje kishin humbje, duke detyruar TCP tĂ« rivendoste 3.5% tĂ« tĂ« gjitha paketave. NĂ« zona me ngarkesĂ«, si aeroportet dhe stacionet, vĂ«rejtĂ«m humbje prej 7%. KĂ«to rezultate vĂ«nĂ« nĂ« dyshim mendimin e zakonshĂ«m se pĂ«rdorimi nĂ« rrjetet celulare redukojnĂ« ndjeshĂ«m humbjet nĂ« nivelin e transportit. MĂ« poshtĂ« â rezultatet nga testet e aplikacionit-simulues:
Metrikat e rrjetit
Vlerat
RTT, milisekonda [50%, 75%, 95%, 99%]
[350, 425, 725, 2300]
Shkëputja RTT, sekonda
NĂ« mesatare ~1.2 s
Humbja e paketave në lidhjet e paqëndrueshme
Në mesatare ~3.5% (7% në zona me ngarkesë)
Gati në gjysmën e këtyre lidhjeve kishte të paktën një humbje paketi, kryesisht këto ishin paketa SYN dhe SYN-ACK. Shumica e realizimeve të TCP përdorin një vlerë RTO prej 1 sekonde për paketat SYN, e cila rritet eksponencial për humbjet e mëvonshme. Koha e ngarkesës së aplikacioneve mund të rritet sepse TCP do të kërkojë më shumë kohë për të vendosur lidhjet.
Në rastin e paketa të dhënash, vlerat e larta të RTO zvogëlojnë ndjeshëm shfrytëzimin e dobishëm të rrjetit në prani të humbjeve përkohësore në rrjetet wireless. Ne zbuluam se koha mesatare e ritransmetimit është rreth 1 sekondë me një vonesë të fundit prej gati 30 sekondash. Këto vonesa të larta në nivelin TCP shkaktuan kohëzgjatje HTTPS dhe përsëritje kërkesash, duke rritur edhe më tej vonesën dhe papërfitueshmërinë e rrjetit.
Ndërsa 75-ta përqindje e RTT e matur ishte rreth 425 ms, 75-ta përqindje për TCP ishte gati 3 sekonda. Kjo sugjeron se humbjet detyruan TCP të bënte 7-10 kalime për të transmetuar me sukses të dhënat. Kjo mund të jetë një pasojë e llogaritjes joefektive të RTO-së, dhe incapaciteteve të TCP për të reaguar shpejt ndaj humbjes. në dritare dhe efektivitetin e algoritmit të menaxhimit të ngarkesës, i cili nuk dallon humbjet pa tel dhe humbjet nga ngarkesa e rrjetit. Më poshtë janë rezultatet e testeve të humbjeve TCP:
Statistika e humbjeve të paketave TCP
Vlera
Përqindja e lidhjeve me të paktën 1 humbje pakete
45%
Përqindja e lidhjeve me humbje gjatë vendosjes së lidhjes
30%
Përqindja e lidhjeve me humbje gjatë shkëmbimit të të dhënave
76%
Shpërndarja e vonesave në ri-transmetim, sekonda [50%, 75%, 95%, 99%]
[1, 2.8, 15, 28]
Shpërndarja e numrit të ri-transmetimeve për një paketë ose segment TCP
[1,3,6,7]
Zbatimi i QUIC
Fillimisht i projektuar nga kompania Google, QUIC Ă«shtĂ« njĂ« protokoll modern transporti me shumĂ« rrjedha, i cili punon mbi UDP. Aktualisht, QUIC Ă«shtĂ« nĂ« (ne kemi raportuar se ekzistojnĂ« si dy versione tĂ« QUIC, ata qĂ« janĂ« kuriozĂ« â shĂ«n. pĂ«rkthyesi). Asht siç tregohet nĂ« FigurĂ«n 5, QUIC ka zĂ«nĂ« vend nĂ«n HTTP/3 (nĂ« tĂ« vĂ«rtetĂ«, HTTP/2 mbi QUIC Ă«shtĂ« HTTP/3, i cili tani po standardizohet me intensitet). Ai pjesĂ«risht zĂ«vendĂ«son nivelet HTTPS dhe TCP, duke pĂ«rdorur UDP pĂ«r tĂ« formuar paketa. QUIC mbĂ«shtet vetĂ«m transferimin e sigurt tĂ« tĂ« dhĂ«nave, pasi TLS Ă«shtĂ« plotĂ«sisht i integruar nĂ« QUIC.
Figura 5: QUIC funksionon nën HTTP/3, duke zëvendësuar TLS, i cili më parë funksiononte nën HTTP/2.
Më poshtë përmendim arsyet që na bindën të përdorim QUIC për të forcuar TCP:
- 0-RTT krijimi i lidhjes. QUIC lejon ri-shfrytëzimin e autorizimeve nga lidhjet e mëparshme, duke ulur numrin e dorëzimeve të sigurisë. Në të ardhmen do të mbështesë 0-RTT, megjithatë dorëzimi i TCP me tre palë ende do të jetë i domosdoshëm.
- kapërcimi i bllokimit HoL. HTTP/2 përdor një lidhje TCP për çdo klient për të përmirësuar performancën, por kjo mund të çojë në bllokimin HoL (head-of-line). QUIC e thjeshton shumëpjesëshen dhe dërgon kërkesat në aplikacion në mënyrë të pavarur nga njëra-tjetra.
- menaxhimi i ngarkesës. QUIC është në nivelin e aplikacioneve, duke lejuar që të përditësohet më lehtë algoritmi i transportit kryesor që menaxhon dërgesat, duke u bazuar në parametrat e rrjetit (numri i humbjeve ose RTT). Shumica e realizimeve TCP përdorin algoritmin , i cili nuk është optimal për trafikun e ndjeshëm ndaj vonesave. Algoritmet e zhvilluara kohët e fundit si , modelojnë më saktë rrjetin dhe optimizojnë vonesat. QUIC lejon përdorimin e BBR dhe përditësimin e këtij algoritmi ndërsa ai .
- pĂ«rmbushja e humbjeve. QUIC shkakton dy TLP () pĂ«rpara se tĂ« aktivizohet RTO â edhe kur humbjet janĂ« shumĂ« tĂ« ndjeshme. Kjo diferencĂ« nga realizimet TCP. TLP ripĂ«rsĂ«rit kryesisht paketĂ«n e fundit (apo njĂ« tĂ« re, nĂ«se ka) pĂ«r tĂ« nisur njĂ« pĂ«rmbushje tĂ« shpejtĂ«. Trajtimi i vonesave tĂ« fundit Ă«shtĂ« veçanĂ«risht i dobishĂ«m pĂ«r mĂ«nyrĂ«n se si Uber punon me rrjetin, sidomos pĂ«r dĂ«rgesat e shkurtra, episodike dhe tĂ« ndjeshme ndaj vonesave.
- ACK i optimizuar. Duke qenë se çdo paketë ka një numër unik radhës, nuk ka problem paketëve gjatë retransmetimit të tyre. Paketat ACK gjithashtu përmbajnë kohën për përpunimin e paketës dhe gjenerimin e ACK nga ana e klientit. Këto karakteristika sigurojnë që QUIC llogarit më saktë RTT. ACK në QUIC mbështet deri në 256 gama , duke ndihmuar dërguesin të jetë më i qëndrueshëm ndaj rregullimit të paketave dhe të përdorë më pak byte gjatë procesit. ACK selektive () në TCP nuk e zgjidh këtë problem në të gjitha rastet.
- migrimi i lidhjes. Lidhjet QUIC identificohen me anë të një ID-je 64-bit, në mënyrë që nëse klienti ndërron adresat IP, mund të vazhdohet me përdorimin e ID-së së vjetër të lidhjes në adresën IP të re, pa ndërprerje. Kjo është një praktikë shumë e zakonshme për aplikacionet mobile, kur përdoruesi kalon midis lidhjeve Wi-Fi dhe celularëve.
Alternativat e QUIC
Ne shqyrtuam qasje alternative për zgjidhjen e problemit para se të zgjidhnim QUIC.
Së pari, përpoqëm të vendosim TPC PoPs (Pikat e Pranishmës), për të përfunduar lidhjet TCP më afër përdoruesve. Në thelb, PoPs përfundojnë lidhjen TCP me pajisjen celulare më afër rrjetit celular dhe proksyjnë trafikun deri në infrastrukturën origjinale. Duke përfunduar TCP më afër, potencialisht mund të reduktojmë RTT-në dhe të jemi të sigurt se TCP do të përgjigjet më aktivisht ndaj ambientit dinamik wireless. Megjithatë, eksperimentet tona treguan se kryesisht RTT dhe humbjet vijnë nga rrjetet celulare dhe përdorimi i PoPs nuk siguron një përmirësim të konsiderueshëm në performancë.
Ne kemi shqyrtuar gjithashtu optimizimin e parametrave TCP. Konfigurimi i TCP-stack nĂ« serverĂ«t tanĂ« tĂ« kufirit heterogjenĂ« ishte i vĂ«shtirĂ«, pasi TCP ka implementime tĂ« paparashikueshme nĂ« versione tĂ« ndryshme tĂ« OS. Ishte e vĂ«shtirĂ« ta realizonim dhe tĂ« verifikonim konfigurimet e ndryshme tĂ« rrjetit. Konfigurimi i TCP direkt nĂ« pajisjet mobile ishte i pamundur pĂ«r shkak tĂ« mungesĂ«s sĂ« autoritetit. Ăka Ă«shtĂ« mĂ« e rĂ«ndĂ«sishme, karakteristika si lidhjet me 0-RTT dhe parashikimi i pĂ«rmirĂ«suar i RTT janĂ« kritikisht tĂ« rĂ«ndĂ«sishme pĂ«r arkitekturĂ«n e protokollit dhe, prandaj, nuk Ă«shtĂ« e mundur tĂ« arrihet njĂ« pĂ«rfitim domethĂ«nĂ«s duke konfiguruar vetĂ«m TCP.
Më në fund, ne vlerësuam disa protokolle të bazuara në UDP, të cilat adresojnë problemet në transmetimin e videove - dëshironim të dinim nëse këto protokolle do të ndihmonin në rastin tonë. Fatkeqësisht, kishte një mungesë të madhe të shumë cilësimeve të sigurisë, dhe gjithashtu kërkonin një lidhje të mëtejshme TCP për metadatate dhe informacionin e menaxhimit.
Hulumtimet tona treguan se QUIC është gati protokolli i vetëm që mund të ndihmojë me problemin e trafikut në Internet, duke marrë parasysh si sigurinë, ashtu edhe performancën.
Integrimi i QUIC në platformë
PĂ«r tĂ« integruar me sukses QUIC dhe pĂ«r tĂ« pĂ«rmirĂ«suar performancĂ«n e aplikacionit nĂ« kushte tĂ« kĂ«qija lidhjeje, ne zĂ«vendĂ«suam stekĂ«n e vjetĂ«r (HTTP/2 mbi TLS/TCP) me protokollin QUIC. Ne angazhuam bibliotekĂ«n rrjetore nga , e cila pĂ«rmban versionin origjinal, tĂ« Google-it tĂ« protokollit â gQUIC. Kjo implementim gjithashtu pĂ«rmirĂ«sohet vazhdimisht, pĂ«r tĂ« ndjekur specifikimin mĂ« tĂ« fundit tĂ« IETF.
Fillimisht, ne integrojmë Cronet në aplikacionet tona Android, për të shtuar mbështetje për QUIC. Integrimi u realizua në mënyrë që të ulin sa më shumë kostot e migrimit. Në vend që të zëvendësonim plotësisht stekën e vjetër rrjetore, e cila përdorte bibliotekën , ne integrojmë Cronet Nà kornizën e API-së OkHttp. Duke kryer integrimin në këtë mënyrë, shmangëm ndryshimet në thirrjet tona rrjetore (të cilat përdorin ) në nivelin API.
Në përputhje me qasjen për pajisjet Android, ne implantuam Cronet në aplikacionet Uber për iOS, duke kapur trafikun HTTP nga rrjeti , duke përdorur . Kjo abstraksion, e ofruar nga iOS Foundation, përpunon të dhënat URL specifike për protokollin dhe garanton që ne mund të integrojmë Cronet në aplikacionet tona iOS pa kosto të konsiderueshme migrimi.
Përfundimi QUIC në balancuesit e Google Cloud
Në anën e backend-it, përfundimi QUIC sigurohet nga infrastruktura e Google Cloud Load balancing, e cila përdor kryesorë në përgjigjet, për të mbështetur QUIC. Në përgjithësi, çdo kërkesë HTTP merr një kryesor alt-svc nga balancuesi dhe ai e validon mbështetje për QUIC për domainin. Kur klienti Cronet merr përgjigjen HTTP me një kryesor të tillë, ai përdor QUIC për kërkesat e ardhshme HTTP në këtë domain. Sapoky balancuesi përfundon QUIC, infrastruktura jonë e dërgon qartë këtë veprim përmes HTTP2/TCP në qendrat tona të të dhënave.
Performanca: rezultatet
Performanca e ofruar është arsyeja kryesore e kërkimit tonë për protokollin më të mirë. Në fillim, ne krijuam një skenë me , për të kuptuar se si do të sillet QUIC nën profile të ndryshme rrjetesh. Për të provuar funksionimin e QUIC në rrjete reale, ne kemi kryer eksperimente duke vozitur në New Delhi, duke përdorur trafik rrjeti të emuluar, të ngjashëm me thirrjet HTTP në aplikacionin e udhëtarit.
Eksperimenti 1
Inventari për eksperimentin:
- aparate testuese Android me steka OkHttp dhe Cronet, për të siguruar se po lëshojmë trafik HTTPS përkatësisht për TCP dhe QUIC;
- server emulimi të bazuar në Java, i cili dërgon tituj HTTPS të njëjtë në përgjigje dhe ngarkon pajisjet klientike për të marrë kërkesat nga ato;
- proksi në cloud, të cilat janë fizikisht të vendosura afër Indisë, për të përfunduar lidhjet TCP dhe QUIC. Ndërsa për përfundimin e TCP ne përdorëm një proksi të kthyer në , ishte e vështirë të gjenim një proksi të kthyer open-source për QUIC. Ne e ndërtuam vetë proksinë e kthyer për QUIC, duke përdorur stekën themelore të QUIC nga Chromium dhe e kemi bërë atë open-source në Chromium.
Figura 6. Grupi i testit për TCP vs QUIC përbëhej nga pajisje Android me OkHttp dhe Cronet, proksi në cloud për përfundimin e lidhjeve dhe serverin e emulimit.
Eksperimenti 2
Kur Google e bëri QUIC të disponueshëm me , ne kemi përdorur të njëjtin inventar, por me një modifikim: në vend të NGINX-it, morëm balancuesit e Google për të përfunduar lidhjet TCP dhe QUIC nga pajisjet, si dhe për të drejtuar trafikun HTTPS në serverin e simulimit. Balancuesit janë të shpërndarë në të gjithë botën, por përdorin serverin më të afërt PoP me pajisjen (falë gjeolokacionit).
Figurë 7. Në eksperimentin e dytë, dëshiruam të krahasojmë vonesën e përfundimit TCP dhe QUIC: me Google Cloud dhe me proxy-in tonë në përputhje.
Si rezultat, na prisnin disa zbulime:
- përfundimi përmes PoP përmirësoi performancën TCP. Pasi balancuesit përfundojnë lidhjen TCP më afër përdoruesve dhe janë optimizuar mirë, kjo ofron RTT më të vogla, çka përmirëson performancën TCP. Edhe pse ndikon më pak në QUIC, ai gjithsesi e kaloi TCP në aspektin e uljes së vonesave të bishtave (nga 10-30 për qind).
- vonesa e bishtave ndikohet nga . MegjithĂ«se proxy QUIC tonĂ« ishte mĂ« i largĂ«t nga pajisjet (me njĂ« vonesĂ« prej rreth 50 ms mĂ« tĂ« lartĂ«) se balancuesit e Google, ai ofroi performancĂ« tĂ« ngjashme â njĂ« reduktim prej 15% nĂ« vonesa krahasuar me njĂ« reduktim prej 20% nĂ« percentilin 99 tĂ« TCP. Kjo tregon se kalimi nĂ« milinĂ« e fundit Ă«shtĂ« njĂ« ngushticĂ« (bottleneck) nĂ« funksionimin e rrjetit.
Figura 8. Rezultatet e dy eksperimentëve tregojnë se QUIC tejkalon ndjeshëm TCP.
Traffiku operacional
Të frymëzuar nga eksperimentet, implementuam mbështetje për QUIC në aplikacionet tona për Android dhe iOS. Kryem testimin A/B për të përcaktuar ndikimin e QUIC në qytetet ku operon Uber. Në përgjithësi, vëmë re një reduktim të ndjeshëm të vonesave tail në rajone dhe operatorë të ndryshëm komunikimi dhe lloje rrjetesh.
NĂ« grafiket mĂ« poshtĂ« janĂ« treguar pĂ«rqindjet e pĂ«rmirĂ«simeve tĂ« tail (95 dhe 99 percentilet) sipas makroregioneve dhe llojeve tĂ« ndryshme tĂ« rrjetit â LTE, 3G, 2G.
Figura 9. Në testet operative, QUIC tejkaloi TCP në vonesa.
Vetëm përpara
Mund tĂ« themi se kjo Ă«shtĂ« vetĂ«m fillimi â nxjerrja e QUIC nĂ« prodhim ka ofruar mundĂ«si tĂ« jashtĂ«zakonshme pĂ«r tĂ« pĂ«rmirĂ«suar performancĂ«n e aplikacioneve si nĂ« rrjete stabilĂ« ashtu edhe nĂ« ato tĂ« paqĂ«ndrueshme, nĂ« veçanti:
Rritja e mbulimit
Pasi analizuam performancën e protokollit në trafik të vërtetë, ne vëmë re se rreth 80% e seancave përdorën me sukses QUIC për të gjitha kërkesat, ndërsa 15% e seancave përdorën një kombinim të QUIC dhe TCP. Ne supozojmë se ky kombinim ka ndodhur për shkak se biblioteka Cronet kthehet përsëri në TCP për shkak të skadimit, pasi nuk mund të dallojë ndërprerjet reale të UDP nga kushtet e këqija të rrjetit. Tani jemi në kërkim të një zgjidhjeje për këtë problem, ndërsa punojmë për implementimin e mëtejshëm të QUIC.
Optimizimi i QUIC
Trafiku nga aplikacionet mobile është i ndjeshëm ndaj vonesave, por jo ndaj gjerësisë së brezit. Gjithashtu, aplikacionet tona përdoren kryesisht në rrjetet celulare. Bazuar në eksperimente, vonesat e fundit janë ende të mëdha, edhe pse po përdoren proxy për të përfunduar TCP dhe QUIC afër përdoruesve. Ne po kërkojmë aktivisht mënyra për të përmirësuar menaxhimin e ngarkesës dhe për të rritur efikasitetin e algoritmeve të QUIC për rikuperimin e humbjeve.
Me këto dhe disa përmirësime të tjera, ne planifikojmë të përmirësojmë përvojën e përdoruesit pavarësisht nga rrjeti dhe rajoni, duke bërë transportin e pakove më të lehtë dhe të shumtë për të gjithë botën.
Burimi: habr.com
