ProHoster > Blog > Administrim > Protokolli QUIC në veprim: si e implementoi Uber për të optimizuar performancën

Protokolli QUIC në veprim: si e implementoi Uber për të optimizuar performancën

Protokolli QUIC Ă«shtĂ« jashtĂ«zakonisht interesant pĂ«r t'u ndjekur, prandaj na pĂ«lqen ta shkruajmĂ« pĂ«r tĂ«. Por, nĂ«se publikimet e mĂ«parshme pĂ«r QUIC kishin njĂ« karakter mĂ« shumĂ« historik (mĂ« shumĂ« lokal, nĂ«se dĂ«shironi) dhe pĂ«rmbajtĂ«sor, sot ne jemi tĂ« lumtur tĂ« publikojmĂ« njĂ« pĂ«rkthim tĂ« njĂ« natyre tjetĂ«r – do tĂ« flasim pĂ«r aplikimin e vĂ«rtetĂ« tĂ« protokollit nĂ« vitin 2019. Dhe kjo nuk Ă«shtĂ« pĂ«r njĂ« infrastrukturĂ« tĂ« vogĂ«l, tĂ« bazuar nĂ« njĂ« garazh tĂ« supozuar, por pĂ«r Uber, qĂ« funksionon pothuajse nĂ« tĂ«rĂ« botĂ«n. Si arritĂ«n inxhinierĂ«t e kompanisĂ« nĂ« vendimin pĂ«r tĂ« pĂ«rdorur QUIC nĂ« prodhim, si bĂ«nĂ« testet dhe çfarĂ« panĂ« pas zbatimit nĂ« prodhim – nĂ«n kĂ«tĂ« kat.

Imazhet janë të klikueshme. Gëzuar leximin!

Protokolli QUIC në veprim: si e implementoi Uber për të optimizuar performancën

Uber – Ă«shtĂ« njĂ« pĂ«rmasĂ« globale, me 600 qytete tĂ« pranishme, nĂ« secilin prej tĂ« cilĂ«ve aplikacioni mbĂ«shtetet plotĂ«sisht te interneti wireless nga mĂ« shumĂ« se 4500 operatorĂ« celularĂ«. PĂ«rdoruesit presin qĂ« aplikacioni tĂ« funksionojĂ« jo thjesht shpejt, por nĂ« kohĂ« reale – pĂ«r ta siguruar kĂ«tĂ«, aplikacioni Uber ka nevojĂ« pĂ«r vonesa tĂ« ulĂ«ta dhe njĂ« lidhje shumĂ« tĂ« besueshme. FatkeqĂ«sisht, por staku HTTP/2 nuk ndjehet mirĂ« nĂ« nivelet wireless dinamike dhe tĂ« ndjeshme ndaj humbjeve. Kuptuam se nĂ« kĂ«tĂ« rast niveli i ulĂ«t i performancĂ«s Ă«shtĂ« drejtpĂ«rdrejt i lidhur me realizimet e TCP nĂ« bĂ«rthamat e sistemeve operative.

Për të zgjidhur problemin, ne aplikuam QUIC, një protokoll modern me multiplexim të kanaleve, i cili na jep më shumë kontroll mbi performancën e protokollit transportues. Në këtë moment grupi i punës IETF po standartizon QUIC si HTTP/3.

Pas testeve të detajuara, ne arritëm në përfundimin se zbatimi i QUIC në aplikacionin tonë do të ulte vonesat "dere" krahasuar me TCP. Vëzhguam një ulje në intervalin 10-30% për trafik HTTPS duke marrë për bazë aplikacionet e shoferëve dhe pasagjerëve. 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ë steku që mbështet QUIC.

Fjala e fundit e teknologjisë: TCP

Sot, TCP është protokolli më i përdorur për transportin e trafikut HTTPS në internet. TCP ofron një rrjedhë të besueshme të bytave, duke u përballur kështu me ngarkesën e rrjetit dhe humbjen në nivelin e kanalit. Përdorimi i gjerë i TCP për trafikun HTTPS shpjegohet nga gjithëpranishmëria e tij (pjesa më e madhe e sistemeve operative përmban TCP), disponueshmëria në shumicën e infrastrukturës (p.sh., në balancuesit e ngarkesës, HTTPS-proksit dhe CDN) dhe funksionaliteti

Shumica e pĂ«rdoruesve e pĂ«rdorin aplikacionin tonĂ« nĂ« lĂ«vizje, dhe "vonisat tail" tĂ« TCP kanĂ« qenĂ« shumĂ« larg kĂ«rkesave pĂ«r trafikun tonĂ« HTTPS nĂ« kohĂ« reale. Thjesht, pĂ«rdoruesit nga e gjithĂ« bota janĂ« pĂ«rballur me kĂ«tĂ« – nĂ« FigurĂ«n 1 janĂ« reflektuar vonisat nĂ« qytete tĂ« mĂ«dha:

Protokolli QUIC në veprim: si e implementoi Uber për të optimizuar performancën
Figura 1. Shuma e vonisave "tail" variaton në qytetet kryesore ku operon Uber.

Pavarësisht se vonisat në rrjetet indiane dhe braziliane ishin më të larta se në SHBA dhe Mbretërinë e Bashkuar, vonisat tail ishin ndjeshëm më të mëdha se mesatarja. Dhe kjo është e vërtetë edhe për SHBA-në dhe Mbretërinë e Bashkuar.

Performanca e TCP në ajër

TCP është krijuar për rrjetet me kabllo , që do të thotë fokusim në lidhje të parashikueshme. Megjithatë, rrjetet pa tela kanë karakteristika dhe vështirësi të vetat. Së pari, rrjetet pa tela janë të ndjeshme ndaj humbjeve për shkak të ndërhyrjeve dhe zbehjes së sinjalit. Për shembull, rrjetet Wi-Fi janë të ndjeshme ndaj mikrovalëve, Bluetooth dhe transmetimeve të tjera të radios. Rrjetet celulare përjetojnë humbje sinjali (humbje të rrugës) për shkak të reflektimit/absorbimit të sinjalit nga objektet dhe ndërtesat, si dhe nga ndërhyrjet nga të tjera kulla celulare. Kjo çon në vonesa më të mëdha (4-10 herë) dhe të ndryshme vonisa rrethore (RTT) dhe humbje paketash në krahasim me lidhjen e kabllit.

Për të përballuar ndryshimet në gjerësinë e brezit dhe humbjet, rrjetet celulare zakonisht përdorin bufferë të mëdha për shpërthimet e trafikut. Kjo mund të çojë në mbingarkesë, që do të thotë vonesa më të mëdha. Shpesh, TCP e interpreton këtë mbingarkesë si humbje për shkak të kohëzgjatjes së rritur, kështu që TCP ka tendencë të bëjë retransmetim, duke mbushur kështu bufferin. Kjo çështje njihet si bufferbloat (mbipërdorim i rrjetit, ënjtje e bufferit), dhe kjo është një çështje shumë serioze 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, ne kemi mbledhur vonesat mesatare të trafikut HTTPS në lidhje me celularët në një rreze prej 2 kilometrash. Të dhënat janë mbledhur për dy operatorët më të mëdhenj të celularëve në New Delhi, Indi. Siç mund të vëreni, performanca ndryshon nga një qelizë në tjetrën. Gjithashtu, performanca e një operatori ndryshon nga ajo e operatorit tjetër. Këto ndryshime ndikohen nga faktorë si modelet e hyrjes në rrjet duke marrë parasysh kohën dhe vendndodhjen, lëvizshmërinë e përdoruesve, si dhe infrastrukturën e rrjetit duke marrë parasysh dendësinë e kullave dhe raportin e llojeve të rrjetit (LTE, 3G, etj.).

Protokolli QUIC në veprim: si e implementoi Uber për të optimizuar performancën
Figura 2. Vonesat në shembullin e një rreze prej 2 kilometrash. New Delhi, Indi.

Gjithashtu, performanca e rrjeteve celulare ndryshon me kalimin e kohës. Në Figurën 3, është treguar vonesa mesatare sipas ditëve të javës. Ne gjithashtu kemi vëzhguar diferenca në një shkallë më të vogël - brenda një dite dhe ore.

Protokolli QUIC në veprim: si e implementoi Uber për të optimizuar performancën
Figura 3. Vonesat e bishtave mund të ndryshojnë ndjeshëm në ditë të ndryshme, por për të njëjtin operator.

Gjithçka e përmendur më sipër çon në përfundimin se performanca TCP është e papërgjegjshme në rrjete celularë. Megjithatë, përpara se të kërkojmë alternativa për TCP, ne dëshirojmë të zhvillojmë një kuptim të saktë rreth pikave të mëposhtme:

  • a Ă«shtĂ« TCP pĂ«rgjegjĂ«si kryesore pĂ«r vonesat e bishtave nĂ« aplikacionet tona?
  • A kanĂ« rrjetet moderne vonesa tĂ« konsiderueshme dhe tĂ« larmishme rreth trajtim (RTT)?
  • Cili Ă«shtĂ« ndikimi i RTT dhe humbjeve mbi performancĂ«n TCP?

Analiza e performancës TCP

Për të kuptuar se si analizuam performancën TCP, le të rikujtojmë shkurtimisht se si TCP transmeton të dhëna nga dërguesi te marrësi. Fillimisht, dërguesi vendos një lidhje TCP, duke iu nënshtruar një të tretë shkëmbimit: dërguesi dërgon një paketë SYN, pret një paketë SYN-ACK nga marrësi, pastaj dërgon një paketë ACK. Kalime të dyta dhe të treta shpenzohen për krijimin e lidhjes TCP. Marrësi konfirmon marrjen e çdo pakete (ACK) për të siguruar dorëzimin e besueshëm.

Nëse humbet një paketë ose ACK, dërguesi bënë rivendosjen pas skadimit të kohës (RTO, koha e rivendosjes). RTO llogaritet në mënyrë dinamike, në bazë të faktorëve të ndryshëm, siç është vonesa e pritur RTT mes dërguesit dhe marrësit.

Protokolli QUIC në veprim: si e implementoi Uber për të optimizuar performancën
Figura 4. Shkëmbimi i paketave përmes TCP/TLS përfshin mekanizma të ritrasmetimit.

Për të përcaktuar se si funksiononte TCP në aplikacionet tona, ne ndjekëm paketat TCP me anë të tcpdump gjatë një jave në trafik live që vinte nga serverat kufitarë indianë. Pas kësaj, ne analizuam lidhjet TCP me anë të tcptrace. Për më tepër, ne krijuam një aplikacion Android që dërgon trafik të simuluar në një server provë, duke imituar sa më saktë trafikun e vërtetë. Smartphone-et me këtë aplikacion iu dhanë disa punonjësve, të cilët mbledhën logjet për disa ditë.

Rezultatet e të dy eksperimentëve ishin në përputhje me njëra-tjetrën. Ne vërejta vonesa të larta RTT; vlerat ekstreme ishin pothuajse 6 herë më të larta se mesatarja; vlera mesatare e vonesave ishte më shumë se 1 sekondë. Shumë lidhje patën humbje, gjë që e detyroi TCP-në të ritrasmetojë 3.5% të të gjitha paketimeve. Në zona me ngarkesë, si aeroportet dhe stacionet, ne vërejta humbje prej 7%. Këto rezultate vënë në dyshim mendimin e zakonshëm se skemat e avancuara të ritrasmetimit që përdoren në rrjetet celulare redukojnë ndjeshëm humbjet në nivelin e transportit. Më poshtë janë rezultatet e testeve nga aplikacioni-simuluar: Metritë e rrjetit

RTT, milisekonda [50%, 75%, 95%, 99%]
Vlerat

Shkalla e RTT, sekonda
[350, 425, 725, 2300]

NĂ« mesatarisht ~1.2 s
Humbja e paketave në lidhje të paqëndrueshme

Në mesatarisht ~3.5% (7% në zona me ngarkesë)
Gati në gjysmën e këtyre lidhjeve kishte të paktën një humbje paketash, kryesisht këto ishin paketat SYN dhe SYN-ACK. Shumica e realizimeve të TCP përdorin vlerën RTO prej 1 sekondën për paketat SYN, e cila rritet në mënyrë eksponenciale për humbjet e mëpasshme. Koha e ngarkesës së aplikacionit mund të rritet për shkak se TCP i nevojitet më shumë kohë për të krijuar lidhjet.

Në rastin e paketave të dhënash, vlerat e larta RTO ulin ndjeshëm shfrytëzimin e dobishëm të rrjetit në praninë e humbjeve të përkohshme në rrjetet wireless. Ne zbuluam se koha mesatare e ritrasmetimit është rreth 1 sekondë me një vonesë ekstreme prej pothuajse 30 sekondash. Këto vonesa të larta në nivelin TCP shkaktonin kohëzgjatje HTTPS dhe kërkesa të përsëritura, gjë që akoma e aumentonte vonesën dhe paaftësinë e rrjetit.

Në rastin e paketave të dhënash, vlerat e larta RTO ulin ndjeshëm shfrytëzimin e dobishëm të rrjetit në praninë e humbjeve të përkohshme në rrjetet wireless. Ne zbuluam se koha mesatare e ritrasmetimit është rreth 1 sekondë me një vonesë ekstreme prej pothuajse 30 sekondash. Këto vonesa të larta në nivelin TCP shkaktonin kohëzgjatje HTTPS dhe kërkesa të përsëritura, gjë që akoma e aumentonte vonesën dhe paaftësinë e rrjetit.

Ndërsa percentili i 75-të i RTT-së së matur ishte rreth 425 ms, percentili i 75-të për TCP ishte pothuajse 3 sekonda. Kjo sugjeron se humbjet e detyruan TCP-në të bënte 7-10 kalime për të transferuar të dhënat me sukses. Kjo mund të jetë një pasojë e llogaritjes joefikase të RTO-së, duke e bërë TCP-në të pamundur për të reaguar shpejt ndaj humbjeve. paketave të fundit në dritare dhe joefikasitetit të algoritmit të menaxhimit të ngarkesës, i cili nuk e dallon humbjen e paushme dhe humbjen për shkak të ngarkesës në rrjet. Më poshtë janë rezultatet e testeve të humbjeve TCP:

Statistika e humbjeve të paketave TCP
Vlera

Përqindja e lidhjeve me të paktën një 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%

Distribucioni i vonesave në rinovim, sekonda [50%, 75%, 95%, 99%]
[1, 2.8, 15, 28]

Distribucioni i numrit të rinovimeve për një paketë ose segment TCP
[1,3,6,7]

Zbatimi i QUIC

Fillimisht i projektuar nga Google, QUIC Ă«shtĂ« njĂ« protokoll transporti modern me shumĂ« rrjedha qĂ« funksionon mbi UDP. Deri mĂ« tani, QUIC Ă«shtĂ« nĂ« procesin e standardizimit (ne tashmĂ« kemi shkruar se ekzistojnĂ« dy versione tĂ« QUIC, ata qĂ« janĂ« kuriozĂ« mund tĂ« kalojnĂ« nĂ« lidhjen – shĂ«n. pĂ«rkthyesit). Siç tregohet nĂ« FigurĂ«n 5, QUIC Ă«shtĂ« pozicionuar nĂ«n HTTP/3 (nĂ« thelb, HTTP/2 mbi QUIC Ă«shtĂ« HTTP/3, i cili tani po standardizohet me intensivitet). Ai zĂ«vendĂ«son pjesĂ«risht nivelet HTTPS dhe TCP, duke pĂ«rdorur UDP pĂ«r tĂ« formuar paketat. QUIC mbĂ«shtet vetĂ«m transferimin e sigurt tĂ« tĂ« dhĂ«nave, pasi TLS Ă«shtĂ« plotĂ«sisht i integruar nĂ« QUIC.

Protokolli QUIC në veprim: si e implementoi Uber për të optimizuar performancën
Figura 5: QUIC funksionon nën HTTP/3, duke zëvendësuar TLS, i cili më parë funksiononte nën HTTP/2.

Më poshtë japim arsyet që na bënë të përdorim QUIC për forcuar TCP:

  • 0-RTT e vendosjes sĂ« lidhjes. QUIC lejon ripĂ«rdorimin e autorizimeve nga lidhjet e mĂ«parshme, duke e ulur numrin e dorĂ«zimeve tĂ« sigurisĂ«. NĂ« tĂ« ardhmen TLS1.3 do tĂ« mbĂ«shtesĂ« 0-RTT, megjithatĂ«, dorĂ«zimi tridimensional i TCP ende do tĂ« jetĂ« i detyrueshĂ«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 thjeshton shumĂ«kĂ«tĂ«sinĂ« dhe dorĂ«zon kĂ«rkesat nĂ« aplikacion nĂ« mĂ«nyrĂ« tĂ« pavarur nga njĂ«ra-tjetra.
  • menaxhimi i ngarkesĂ«s. QUIC Ă«shtĂ« nĂ« nivelin e aplikacioneve, duke lehtĂ«suar pĂ«rditĂ«simin e algoritmit kryesor tĂ« transportit, i cili menaxhon dĂ«rgesat, duke u bazuar nĂ« parametrat e rrjetit (numri i humbjeve ose RTT). Shumica e realizimeve TCP pĂ«rdorin algoritmin CUBIC, i cili nuk Ă«shtĂ« optimal pĂ«r trafikun, tĂ« ndjeshĂ«m ndaj vonesave. Algoritmet e zhvilluara sĂ« fundmi si BBR, modelojnĂ« mĂ« saktĂ«sisht rrjetin dhe optimizojnĂ« vonesat. QUIC lejon pĂ«rdorimin e BBR dhe pĂ«rditĂ«simin e kĂ«tij algoritmi ndĂ«rsa ai pĂ«rmirĂ«sohet.
  • pĂ«r tĂ« rikuperuar humbjet. QUIC aktivizon dy TLP (tail loss probe) para se tĂ« funksionojĂ« RTO – edhe kur humbjet janĂ« shumĂ« tĂ« ndjeshme. Kjo Ă«shtĂ« njĂ« ndryshim nga realizimet TCP. TLP pĂ«rsĂ«rit kryesisht paketĂ«n e fundit (ose njĂ« tĂ« re, nĂ«se ekziston), pĂ«r tĂ« aktivizuar rikuperimin e shpejtĂ«. Trajtimi i vonesave tĂ« fundit Ă«shtĂ« veçanĂ«risht i dobishĂ«m pĂ«r mĂ«nyrĂ«n se si funksionon Uber me rrjetin, tĂ« cilat janĂ« tĂ« shkurtra, episodike dhe tĂ« ndjeshme ndaj vonesave.
  • ACK tĂ« optimizuar. Duke pasur parasysh se çdo paketĂ« ka njĂ« numĂ«r unik rendor, nuk ka problem dallimi i paketimeve gjatĂ« pĂ«rsĂ«ritjes sĂ« tyre. Paketat ACK gjithashtu pĂ«rmbajnĂ« kohĂ«n pĂ«r tĂ« procesuar paketĂ«n dhe pĂ«r tĂ« gjeneruar ACK nga ana e klientit. KĂ«to veçori garantojnĂ« se QUIC llogarit mĂ« saktĂ«sisht RTT. ACK nĂ« QUIC mbĂ«shtet deri nĂ« 256 intervale NACK, duke ndihmuar dĂ«rguesin tĂ« jetĂ« mĂ« i qĂ«ndrueshĂ«m ndaj ri-renditjes sĂ« paketimeve dhe tĂ« pĂ«rdorĂ« mĂ« pak byte nĂ« proces. ACK selektive (SACK) nĂ« TCP nuk zgjidh kĂ«tĂ« problem nĂ« tĂ« gjitha rastet.
  • migrimi i lidhjes. Lidhjet QUIC identifikohen me njĂ« ID 64-bit, nĂ« mĂ«nyrĂ« qĂ« nĂ«se klienti ndryshon adresat IP, mund tĂ« vazhdojĂ« tĂ« pĂ«rdorĂ« ID-nĂ« e lidhjes sĂ« vjetĂ«r nĂ« adresĂ«n e re IP, pa ndĂ«rprerje. Kjo Ă«shtĂ« njĂ« praktikĂ« shumĂ« e zakonshme pĂ«r aplikacionet mobile, kur pĂ«rdoruesi kalon midis lidhjeve Wi-Fi dhe celulare.

Alternativat e QUIC

Ne shqyrtuam qasje alternative për të zgjidhur problemin para se të zgjidhnim QUIC.

E para, ne fillim provuam të vendosim TPC PoPs (Pikat e PrPresence) për të përfunduar lidhjet TCP më afër përdoruesve. Në thelb, PoPs përfundon lidhjen TCP me pajisjen mobile më afër rrjetit celular dhe e proksionon trafikun deri te infrastruktura origjinale. Duke e përfunduar TCP më afër, potencialisht mund të zvogëlojmë RTT-në dhe të jemi të sigurt se TCP do të reagojë më aktivisht ndaj mjedisit dinamik pa tel. Megjithatë, eksperimentet tona treguan se në shumicën e rasteve RTT dhe humbjet vijnë nga rrjetet celulare dhe përdorimi i PoPs nuk ofron përmirësime të rëndësishme në performancë.

Ne gjithashtu shqyrtuam optimizimin e parametrave të TCP. Cilësimi i stekëve TCP në serverat tanë të kufizuar ishte i vështirë, pasi TCP ka implementime të pa krahasueshme në versione të ndryshme të OS. Ishte e vështirë ta zbatonim dhe të testonim konfigurata të ndryshme rrjetesh. Cilësimi i TCP direkt në pajisjet mobile ishte i pamundur për shkak të mungesës së autorizimeve. Më e rëndësishmja, 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, është e pamundur të arrihet një avantazh të konsiderueshëm vetëm duke cilësuar TCP.

Në fund, ne vlerësuam disa protokolle të bazuara në UDP që adresojnë defektet në transmetimin e videove - doja të dija nëse këto protokolle do të ndihmonin në rastin tonë. Fatkeqësisht, këto kishin mungesë të madhe të shumë parametrave të sigurisë dhe gjithashtu kërkonin një lidhje të shtuar TCP për të dhënat dhe informacionin e menaxhimit.

Hulumtimet tona treguan se QUIC është pothuajse protokolli i vetëm që mund të ndihmojë me problemin e trafikut të Internetit, 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 stekun e vjeter (HTTP/2 mbi TLS/TCP) me protokollin QUIC. Ne përfshiu bibliotekën e rrjetit Cronet nga Projektet Chromium, e cila përmban versionin origjinal të protokollit të Google, gQUIC. Kjo implementim gjithashtu përmirësohet vazhdimisht për t'u përputhur me specifikimin më të fundit të IETF.

SĂ« pari, ne integuam Cronet nĂ« aplikacionet tona Android pĂ«r tĂ« shtuar mbĂ«shtetje pĂ«r QUIC. Integrimi u realizua nĂ« njĂ« mĂ«nyrĂ« qĂ« reduktonte sa mĂ« shumĂ« shpenzimet e migrimit. NĂ« vend qĂ« tĂ« zĂ«vendĂ«sonim tĂ«rĂ«sisht stekĂ«n e vjetĂ«r tĂ« rrjetit qĂ« pĂ«rdorte bibliotekĂ«n OkHttp, ne integuam Cronet NË kuadĂ«r tĂ« API-sĂ« sĂ« OkHttp. Duke e realizuar integrimin nĂ« kĂ«tĂ« mĂ«nyrĂ«, ne shmanguam ndryshime nĂ« thirrjet tona rrjetore (tĂ« cilat pĂ«rdorin Retrofit) nĂ« nivelin e API-sĂ«.

Në mënyrë të ngjashme me qasjen tonë për pajisjet Android, ne implementuam Cronet në aplikacionet Uber për iOS, duke kapur trafik HTTP nga API, duke përdorur NSURLProtocol. Kjo abstraksion, e ofruar nga iOS Foundation, trajton të dhënat e URL-ve specifike për protokollin dhe garanton që mund të integrojmë Cronet në aplikacionet tona për iOS pa shpenzime të mëdha migrimi.

Përfundimi i QUIC në balancuesit e Google Cloud

Anës së backend-it, përfundimi i QUIC sigurohet nga infrastruktura e Google Cloud Load balancing, e cila përdor alt-svc këto krye të përgjigjeve për të mbështetur QUIC. Në përgjithësi, balancuesi shton një krye alt-svc në çdo kërkesë HTTP dhe verifikon mbështetje për QUIC për domain-in. Kur klienti Cronet merr një përgjigje HTTP me këtë krye, ai përdor QUIC për kërkesat e ardhshme HTTP për këtë domain. Pasi balancuesi përfundon QUIC, infrastruktura jonë e dërgon shprehimisht këtë veprim përmes HTTP2/TCP në qendrat tona të të dhënave.

Performanca: rezultatet

Performanca e dhënë është arsyeja kryesore për kërkimin tonë të protokollit më të mirë. Për fillim, ne krijuam një skenë me emulimin e rrjetit, për të kuptuar se si do të sillet QUIC nën profile të ndryshme rrjeti. Për të testuar funcionimin e QUIC në rrjetet reale, ne kryem eksperimente duke u lëvizur në New Delhi, duke përdorur trafik të emuluar rrjeti, shumë të ngjashëm me thirrjet HTTP në aplikacionin e pasagjerit.

Eksperimenti 1

Inventari për eksperimentin:

  • pajisje testuese Android me steka OkHttp dhe Cronet, pĂ«r tĂ« siguruar qĂ« ne drejtojmĂ« trafikun HTTPS pĂ«rmes TCP dhe QUIC pĂ«rkatĂ«sisht;
  • njĂ« server emulimi i ndĂ«rtuar nĂ« Java, i cili dĂ«rgon krye tĂ« njĂ«jta HTTPS nĂ« pĂ«rgjigje dhe ngarkon pajisjet klient, pĂ«r tĂ« marrĂ« kĂ«rkesat nga ato;
  • proxy 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Ă« proxy tĂ« prapme mbi NGINX, ishte e vĂ«shtirĂ« tĂ« gjejmĂ« njĂ« proxy tĂ« hapur pĂ«r QUIC. Ne e zhvilluam vetĂ« njĂ« proxy pĂ«r QUIC, duke pĂ«rdorur stakun bazĂ« QUIC nga Chromium dhe publikuan e tij nĂ« Chromium si softuer tĂ« hapur.

Protokolli QUIC në veprim: si e implementoi Uber për të optimizuar performancënProtokolli QUIC në veprim: si e implementoi Uber për të optimizuar performancën
Figura 6. Seti i testeve për TCP vs QUIC përfshinte pajisje Android me OkHttp dhe Cronet, proxy në re për përfundimin e lidhjeve dhe një server simulimi.

Eksperimenti 2

Kur Google e bëri QUIC të disponueshëm përmes Google Cloud Load Balancing, ne përdorëm të njëjtin inventar, por me një modifikim: në vend të NGINX, morëm balancuesit e Google për përfundimin e lidhjeve TCP dhe QUIC nga pajisjet, si dhe për dirigjimin e trafikut HTTPS në serverin simulues. Balancuesit janë të shpërndarë në të gjithë botën, por përdorin një server PoP të afërt me pajisjen (falë gjeolokacionit).

Protokolli QUIC në veprim: si e implementoi Uber për të optimizuar performancën
Figura 7. Në eksperimentin e dytë, donim të krahasonim vonesën e përfundimit të TCP dhe QUIC: duke përdorur Google Cloud dhe duke përdorur proxy-në tonë në re.

Si rezultat, na pritën disa zbulime:

  • pĂ«rfundimi pĂ«rmes PoP pĂ«rmirĂ«soi performancĂ«n e TCP. Sikurse balancuesit pĂ«rfundojnĂ« lidhjen TCP mĂ« afĂ«r pĂ«rdoruesve dhe janĂ« tĂ« optimizuar shkĂ«lqyeshĂ«m, kjo ofron RTT mĂ« tĂ« ulĂ«t, çka pĂ«rmirĂ«son performancĂ«n e TCP. Edhe pse ndikimi mbi QUIC ishte mĂ« i vogĂ«l, prapĂ« ai e kaloi TCP nĂ« aspektin e zvogĂ«limit tĂ« vonesave tail (nga 10-30 pĂ«r qind).
  • vonesa do tĂ« ndikohen nga kalimet rrjetĂ«sore. Edhe pse proxy-ja jonĂ« QUIC ishte mĂ« larg nga pajisjet (me njĂ« vonesĂ« rreth 50 ms mĂ« tĂ« lartĂ«), ajo ofronte performancĂ« tĂ« ngjashme – njĂ« zvogĂ«lues prej 15% nĂ« vonesa nĂ« krahasim me 20% nĂ« percentilin 99 tĂ« TCP. Kjo tregon se kalimi nĂ« milen e fundit Ă«shtĂ« pika e ngushtĂ« nĂ« funksionimin e rrjetit.

Protokolli QUIC në veprim: si e implementoi Uber për të optimizuar performancënProtokolli QUIC në veprim: si e implementoi Uber për të optimizuar performancën
Figura 8. Rezultatet e dy eksperimenteve tregojnë se QUIC tejkalon ndjeshëm TCP.

Trafiku në luftë

Të frymëzuar nga eksperimentet, ne implementuam mbështetje për QUIC në aplikacionet tona Android dhe iOS. Ne kryem testimin A/B për të përcaktuar ndikimin e QUIC në qytetet e pranishme të Uber. Në përgjithësi, pamë një zvogëlues të rëndësishëm të vonesave tail në raport me rajonet, operatorët e komunikimit dhe llojin e rrjetit.

NĂ« grafiket mĂ« poshtĂ«, shihen pĂ«rqindjet e pĂ«rmirĂ«simit tĂ« vonesave (95 dhe 99 percentilet) sipas makroregjioneve dhe llojeve tĂ« ndryshme tĂ« rrjetit – LTE, 3G, 2G.
Protokolli QUIC në veprim: si e implementoi Uber për të optimizuar performancënProtokolli QUIC në veprim: si e implementoi Uber për të optimizuar performancën
Figura 9. Në testet e luftës, QUIC tejkaloi TCP në vonesa.

Vetëm përpara

Padysh, kjo Ă«shtĂ« vetĂ«m fillimi – implementimi i QUIC nĂ« prodhim ofroi mundĂ«si tĂ« jashtĂ«zakonshme pĂ«r tĂ« pĂ«rmirĂ«suar performancĂ«n e aplikacioneve si nĂ« rrjete stabile ashtu edhe nĂ« ato jo stabile, veçanĂ«risht:

Rritja e mbulimit

Pas analizës së performancës së protokollit në trafik real, ne pamë se rreth 80% e sesioneve e përdorën me sukses QUIC për të gjitha kërkesa, ndërsa 15% e sesioneve përdorën kombinimin e QUIC dhe TCP. Ne supozojmë se ky kombinim ka ndodhur sepse biblioteka Cronet kalon përsëri në TCP për shkak të skadimit të kohës, pasi nuk mund të dallojë ndërprerjet reale të UDP-së nga kushtet e dobëta të rrjetit. Tani jemi duke kërkuar një zgjidhje për këtë problem, ndërsa punojmë për implementimin e mëtejshëm të QUIC.

Optimizimi i QUIC

Trafiku nga aplikacionet celulare është i ndjeshëm ndaj vonesave, por jo ndaj gjerësisë së brezit. Gjithashtu, aplikacionet tona përdoren kryesisht në rrjete celulare. Bazuar në eksperimente, vonesat ende janë të mëdha, edhe pse përdorim proxy për të përfunduar TCP dhe QUIC afër përdoruesve. Ne jemi në kërkim aktiv të mënyrave për të përmirësuar menaxhimin e ngarkesës dhe për të rritur efikasitetin e algoritmeve të QUIC për mbushjen e humbjeve.

Me këto dhe disa përmirësime të tjera, ne planifikojmë të përmirësojmë përvojën e përdoruesve pa marrë parasysh rrjetin dhe rajonin, duke bërë transportin e pakove më të rehatshëm dhe pa ndërprerje më të aksesueshëm në mbarë botën.

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster