Protokolli QUIC është jashtëzakonisht interesant për t'u parë, prandaj na pëlqen të shkruajmë për të. Por nëse botimet e mëparshme rreth QUIC ishin më shumë të një natyre dhe harduerike historike (historia lokale, nëse dëshironi), sot ne jemi të lumtur të botojmë një përkthim të një lloji tjetër - do të flasim për zbatimin e vërtetë të protokollit në 2019. Për më tepër, nuk po flasim për infrastrukturë të vogël të bazuar në një të ashtuquajtur garazh, por për Uber, i cili operon pothuajse në të gjithë botën. Si inxhinierët e kompanisë erdhën në vendimin për të përdorur QUIC në prodhim, si i kryen testet dhe çfarë panë pasi e nxorrën atë në prodhim - poshtë prerjes.
Fotografitë janë të klikueshme. Kënaquni duke lexuar!
Uber ka një shkallë globale, përkatësisht 600 qytete prezence, në secilin prej të cilave aplikacioni mbështetet tërësisht në internet pa tel nga më shumë se 4500 operatorë celularë. Përdoruesit presin që aplikacioni të jetë jo vetëm i shpejtë, por në kohë reale - për ta arritur këtë, aplikacioni Uber ka nevojë për vonesë të ulët dhe një lidhje shumë të besueshme. Mjerisht, por pirg nuk funksionon mirë në rrjetet wireless dinamike dhe të prirura për humbje. Kuptuam se në këtë rast, performanca e ulët lidhet drejtpërdrejt me implementimet e TCP në kernelet e sistemit operativ.
Për të zgjidhur problemin, ne aplikuam , një protokoll modern i multipleksimit të kanaleve që na jep më shumë kontroll mbi performancën e protokollit të transportit. Aktualisht grupi i punës standardizon QUIC si .
Pas testimit të gjerë, ne arritëm në përfundimin se zbatimi i QUIC në aplikacionin tonë do të rezultonte në vonesa më të ulëta në krahasim me TCP. Ne kemi vërejtur një ulje në intervalin prej 10-30% për trafikun HTTPS në aplikacionet e shoferit dhe pasagjerëve. QUIC na dha gjithashtu kontroll nga fundi në fund mbi paketat e përdoruesve.
Në këtë artikull, ne ndajmë përvojën tonë në optimizimin e TCP për aplikacionet Uber duke përdorur një pirg që mbështet QUIC.
Teknologjia më e fundit: TCP
Sot, TCP është protokolli më i përdorur i transportit për dërgimin e trafikut HTTPS në internet. TCP siguron një rrjedhë të besueshme bajt, duke përballuar kështu mbingarkesën e rrjetit dhe humbjet e shtresave të lidhjes. Përdorimi i gjerë i TCP për trafikun HTTPS është për shkak të përhapjes së të parës (pothuajse çdo OS përmban TCP), disponueshmërisë në shumicën e infrastrukturës (siç janë balancuesit e ngarkesës, përfaqësuesit HTTPS dhe CDN-të) dhe funksionalitetit jashtë kutisë që është i disponueshëm. pothuajse në shumicën e platformave dhe rrjeteve.
Shumica e përdoruesve përdorin aplikacionin tonë në lëvizje dhe vonesat në fund të TCP nuk ishin aspak afër kërkesave të trafikut tonë HTTPS në kohë reale. E thënë thjesht, përdoruesit në të gjithë botën e kanë përjetuar këtë - Figura 1 tregon vonesat në qytetet kryesore:
Figura 1: Vonesa e bishtit ndryshon në qytetet kryesore të Uber.
Megjithëse vonesa në rrjetet indiane dhe braziliane ishte më e lartë se në SHBA dhe MB, vonesa e bishtit është dukshëm më e lartë se vonesa mesatare. Dhe kjo është e vërtetë edhe për SHBA dhe MB.
TCP mbi performancën e ajrit
TCP u krijua për me tela rrjete, domethënë me theks në lidhje shumë të parashikueshme. Megjithatë, pa tel rrjetet kanë karakteristikat dhe vështirësitë e tyre. Së pari, rrjetet me valë janë të ndjeshme ndaj humbjeve për shkak të ndërhyrjeve dhe dobësimit të sinjalit. Për shembull, rrjetet Wi-Fi janë të ndjeshme ndaj mikrovalëve, Bluetooth dhe valëve të tjera të radios. Rrjetet celulare vuajnë nga humbja e sinjalit () për shkak të reflektimit/përthithjes së sinjalit nga objektet dhe ndërtesat, si dhe nga nga fqinjët . Kjo çon në më të rëndësishme (4-10 herë) dhe më të larmishme dhe humbja e paketës në krahasim me një lidhje me tel.
Për të luftuar luhatjet dhe humbjet e gjerësisë së brezit, rrjetet celulare zakonisht përdorin buferë të mëdhenj për shpërthimet e trafikut. Kjo mund të çojë në radhë të tepërta, që do të thotë vonesa më të gjata. Shumë shpesh TCP e trajton këtë radhë si humbje për shkak të një afati kohor të zgjatur, kështu që TCP tenton të transmetojë dhe në këtë mënyrë të mbushë bufferin. Ky problem njihet si (), dhe kjo është shumë internet modern.
Së fundi, performanca e rrjetit celular ndryshon sipas operatorit, rajonit dhe kohës. Në figurën 2, ne mblodhëm vonesat mesatare të trafikut HTTPS nëpër qeliza brenda një intervali prej 2 kilometrash. Të dhënat e mbledhura për dy operatorë kryesorë celularë në Delhi, Indi. Siç mund ta shihni, performanca ndryshon nga qeliza në qelizë. Gjithashtu, produktiviteti i një operatori ndryshon nga produktiviteti i të dytit. Kjo ndikohet nga faktorë të tillë si modelet e hyrjes në rrjet duke marrë parasysh kohën dhe vendndodhjen, lëvizshmërinë e përdoruesit, si dhe infrastrukturën e rrjetit duke marrë parasysh densitetin e kullave dhe raportin e llojeve të rrjetit (LTE, 3G, etj.).
Figura 2. Vonesat duke përdorur një rreze prej 2 km si shembull. Delhi, Indi.
Gjithashtu, performanca e rrjeteve celulare ndryshon me kalimin e kohës. Figura 3 tregon vonesën mesatare sipas ditës së javës. Ne gjithashtu vëzhguam ndryshime në një shkallë më të vogël, brenda një dite dhe ore të vetme.
Figura 3. Vonesat e bishtit mund të ndryshojnë ndjeshëm ndërmjet ditëve, por për të njëjtin operator.
Të gjitha sa më sipër bëjnë që performanca e TCP të jetë joefektive në rrjetet pa tel. Sidoqoftë, përpara se të kërkonim alternativa për TCP, ne donim të zhvillonim një kuptim të saktë mbi pikat e mëposhtme:
- a është TCP fajtori kryesor pas vonesave të fundit në aplikacionet tona?
- A kanë rrjetet moderne vonesa të rëndësishme dhe të ndryshme vajtje-ardhje (RTT)?
- Cili është ndikimi i RTT dhe humbja në performancën e TCP?
Analiza e Performancës TCP
Për të kuptuar se si kemi analizuar performancën e TCP, le të hedhim një vështrim të shpejtë se si TCP transferon të dhënat nga një dërgues te një marrës. Së pari, dërguesi krijon një lidhje TCP, duke kryer një lidhje me tre drejtime : Dërguesi dërgon një paketë SYN, pret për një paketë SYN-ACK nga marrësi dhe më pas dërgon një paketë ACK. Një kalim shtesë i dytë dhe i tretë shpenzohet për krijimin e lidhjes TCP. Marrësi pranon marrjen e secilës paketë (ACK) për të siguruar dorëzim të besueshëm.
Nëse një paketë ose ACK humbet, dërguesi ritransmeton pas një afati kohor (RTO, ). RTO llogaritet në mënyrë dinamike bazuar në faktorë të ndryshëm, siç është vonesa e pritshme e RTT midis dërguesit dhe marrësit.
Figura 4. Shkëmbimi i paketave mbi TCP/TLS përfshin një mekanizëm ritransmetimi.
Për të përcaktuar se si funksiononte TCP në aplikacionet tona, ne monitoruam paketat TCP duke përdorur për një javë në trafikun luftarak që vjen nga serverët indian edge. Më pas kemi analizuar lidhjet TCP duke përdorur . Për më tepër, ne krijuam një aplikacion Android që dërgon trafikun e emuluar në një server testimi, duke imituar sa më shumë trafikun real. Telefonat inteligjentë me këtë aplikacion iu shpërndanë disa punonjësve, të cilët mblodhën regjistrat për disa ditë.
Rezultatet e të dy eksperimenteve ishin në përputhje me njëri-tjetrin. Ne pamë vonesa të larta RTT; vlerat e bishtit ishin pothuajse 6 herë më të larta se vlera mesatare; mesatarja aritmetike e vonesave është më shumë se 1 sekondë. Shumë lidhje ishin me humbje, duke bërë që TCP të ritransmetonte 3,5% të të gjitha paketave. Në zonat e mbipopulluara si aeroportet dhe stacionet e trenave, pamë 7% humbje. Këto rezultate hedhin dyshime mbi mençurinë konvencionale që ato përdoren në rrjetet celulare reduktojnë ndjeshëm humbjet në nivel transporti. Më poshtë janë rezultatet e testimit nga aplikacioni "simulator":
Metrikat e rrjetit
kuptimi
RTT, milisekonda [50%,75%, 95%,99%]
[350, 425, 725, 2300]
Divergjenca RTT, sekonda
Mesatarisht ~ 1,2 s
Humbja e paketës në lidhje të paqëndrueshme
Mesatarisht ~3.5% (7% në zonat e mbingarkuara)
Pothuajse gjysma e këtyre lidhjeve kishin të paktën një humbje pakete, shumica prej tyre pako SYN dhe SYN-ACK. Shumica e implementimeve TCP përdorin një vlerë RTO prej 1 sekonde për paketat SYN, e cila rritet në mënyrë eksponenciale për humbjet e mëvonshme. Kohët e ngarkimit të aplikacionit mund të rriten për shkak se TCP kërkon më shumë kohë për të krijuar lidhje.
Në rastin e paketave të të dhënave, vlerat e larta RTO zvogëlojnë ndjeshëm përdorimin e dobishëm të rrjetit në prani të humbjeve kalimtare në rrjetet pa tel. Ne zbuluam se koha mesatare e ritransmetimit është afërsisht 1 sekondë me një vonesë të bishtit prej gati 30 sekondash. Këto vonesa të larta në nivelin TCP shkaktuan ndërprerje kohore dhe rikërkesa të HTTPS, duke rritur më tej vonesën dhe joefikasitetin e rrjetit.
Ndërsa përqindja e 75-të e RTT-së së matur ishte rreth 425 ms, përqindja e 75-të për TCP ishte pothuajse 3 sekonda. Kjo lë të kuptohet se humbja bëri që TCP të merrte 7-10 kalime për të transmetuar me sukses të dhënat. Kjo mund të jetë pasojë e llogaritjes joefikase të RTO, paaftësisë së TCP për t'iu përgjigjur shpejt humbjes në dritare dhe joefikasiteti i algoritmit të kontrollit të kongjestionit, i cili nuk bën dallimin midis humbjeve me valë dhe humbjeve për shkak të mbingarkesës së rrjetit. Më poshtë janë rezultatet e testeve të humbjes së TCP:
Statistikat e humbjes së paketave TCP
Vlerë
Përqindja e lidhjeve me të paktën 1 humbje pakete
45%
Përqindja e lidhjeve me humbje gjatë konfigurimit të lidhjes
30%
Përqindja e lidhjeve me humbje gjatë shkëmbimit të të dhënave
76%
Shpërndarja e vonesave në ritransmetim, sekonda [50%, 75%, 95%,99%] [1, 2.8, 15, 28]
Shpërndarja e numrit të ritransmetimeve për një paketë ose segment TCP
[1,3,6,7]
Aplikimi i QUIC
I zhvilluar fillimisht nga Google, QUIC është një protokoll transporti modern me shumë fije që funksionon në krye të UDP. Aktualisht QUIC është në (ne kemi shkruar tashmë se ka, si të thuash, dy versione të QUIC, kurioze - përafërsisht. përkthyes). Siç tregohet në figurën 5, QUIC vendoset nën HTTP/3 (në fakt, HTTP/2 në krye të QUIC është HTTP/3, i cili tani po standardizohet intensivisht). Ai zëvendëson pjesërisht shtresat 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 ekzekutohet nën HTTP/3, duke zëvendësuar TLS, i cili më parë funksiononte nën HTTP/2.
Më poshtë janë arsyet që na bindën të përdorim QUIC për amplifikimin TCP:
- Vendosja e lidhjes 0-RTT. QUIC lejon ripërdorimin e autorizimeve nga lidhjet e mëparshme, duke reduktuar numrin e shtrëngimeve duarsh të sigurisë. Në të ardhmen do të mbështesë 0-RTT, por do të kërkohet ende një shtrëngim duarsh TCP me tre drejtime.
- tejkalimi i bllokimit të HoL. HTTP/2 përdor një lidhje TCP për klient për të përmirësuar performancën, por kjo mund të çojë në bllokimin e HoL (head-of-line). QUIC thjeshton multipleksimin dhe i dorëzon kërkesat aplikacionit në mënyrë të pavarur.
- kontrollin e mbingarkesës. QUIC qëndron në shtresën e aplikacionit, duke e bërë më të lehtë përditësimin e algoritmit kryesor të transportit që kontrollon dërgimin bazuar në parametrat e rrjetit (numri i humbjeve ose RTT). Shumica e implementimeve TCP përdorin algoritmin , e cila nuk është optimale për trafikun e ndjeshëm ndaj vonesës. Algoritmet e zhvilluara së fundmi si , modeloni rrjetin më saktë dhe optimizoni vonesën. QUIC ju lejon të përdorni BBR dhe të përditësoni këtë algoritëm ashtu siç përdoret. .
- rimbushja e humbjeve. QUIC thërret dy TLP () përpara se të aktivizohet RTO - edhe kur humbjet janë shumë të dukshme. Kjo është e ndryshme nga zbatimet TCP. TLP ritransmeton kryesisht paketën e fundit (ose të renë, nëse ka) për të shkaktuar rimbushje të shpejtë. Trajtimi i vonesave të bishtit është veçanërisht i dobishëm për mënyrën se si Uber operon rrjetin e tij, përkatësisht për transferimet e të dhënave të shkurtra, sporadike dhe të ndjeshme ndaj vonesës.
- ACK e optimizuar. Meqenëse çdo paketë ka një numër unik të sekuencës, nuk ka asnjë problem paketat kur ato ritransmetohen. Paketat ACK përmbajnë gjithashtu kohë për të përpunuar paketën dhe për të gjeneruar një ACK në anën e klientit. Këto veçori sigurojnë që QUIC të llogarisë RTT më saktë. ACK në QUIC mbështet deri në 256 breza , duke e ndihmuar dërguesin të jetë më elastik ndaj përzierjes së paketave dhe të përdorë më pak bajt në proces. ACK selektive () në TCP nuk e zgjidh këtë problem në të gjitha rastet.
- migrimi i lidhjes. Lidhjet QUIC identifikohen nga një ID 64-bit, kështu që nëse një klient ndryshon adresat IP, ID-ja e vjetër e lidhjes mund të vazhdojë të përdoret në adresën e re IP pa ndërprerje. Kjo është një praktikë shumë e zakonshme për aplikacionet celulare ku përdoruesi kalon midis lidhjeve Wi-Fi dhe celularit.
Alternativat e QUIC
Ne shqyrtuam qasje alternative për zgjidhjen e problemit përpara se të zgjidhnim QUIC.
Gjëja e parë që ne u përpoqëm ishte të vendosnim TPC PoP (Pikat e Prezencës) për të përfunduar lidhjet TCP më afër përdoruesve. Në thelb, PoP-të ndërpresin një lidhje TCP me një pajisje celulare më afër rrjetit celular dhe transferojnë trafikun përsëri në infrastrukturën origjinale. Duke përfunduar TCP më afër, ne mund të zvogëlojmë RTT dhe të sigurojmë që TCP të përgjigjet më shumë ndaj një mjedisi dinamik me valë. Sidoqoftë, eksperimentet tona kanë treguar se pjesa më e madhe e RTT dhe humbjes vijnë nga rrjetet celulare dhe përdorimi i PoP-ve nuk ofron përmirësim të ndjeshëm të performancës.
Ne shikuam gjithashtu akordimin e parametrave TCP. Vendosja e një grupi TCP në serverët tanë heterogjenë të skajeve ishte i vështirë sepse TCP ka zbatime të ndryshme në versione të ndryshme të OS. Ishte e vështirë për ta zbatuar këtë dhe për të testuar konfigurime të ndryshme të rrjetit. Konfigurimi i TCP direkt në pajisjet celulare nuk ishte i mundur për shkak të mungesës së lejeve. Më e rëndësishmja, veçori të tilla si lidhjet 0-RTT dhe parashikimi i përmirësuar RTT janë kritike për arkitekturën e protokollit, dhe për këtë arsye është e pamundur të arrihen përfitime të rëndësishme duke akorduar vetëm TCP.
Më në fund, ne vlerësuam disa protokolle të bazuara në UDP që zgjidhin problemet e transmetimit të videos - donim të shihnim nëse këto protokolle do të ndihmonin në rastin tonë. Fatkeqësisht, atyre u mungonin shumë në shumë cilësime sigurie, dhe gjithashtu kërkonin një lidhje shtesë TCP për metadatat dhe informacionin e kontrollit.
Hulumtimi ynë ka treguar se QUIC është ndoshta i vetmi protokoll që mund të ndihmojë me problemin e trafikut të internetit, duke marrë parasysh sigurinë dhe 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ë mjedise me lidhje të dobët, ne zëvendësuam grupin e vjetër (HTTP/2 mbi TLS/TCP) me protokollin QUIC. Ne përdorëm bibliotekën e rrjetit nga , i cili përmban versionin origjinal, Google të protokollit - gQUIC. Ky implementim po përmirësohet gjithashtu vazhdimisht për të ndjekur specifikimet më të fundit të IETF.
Ne fillimisht integruam Cronet në aplikacionet tona Android për të shtuar mbështetje për QUIC. Integrimi u krye në atë mënyrë që të reduktonte sa më shumë kostot e migracionit. Në vend që të zëvendësohet plotësisht grupi i vjetër i rrjetit që përdorte bibliotekën , ne kemi integruar Cronet NËN kuadrin OkHttp API. Duke bërë integrimin në këtë mënyrë, ne shmangëm ndryshimet në thirrjet tona të rrjetit (të cilat përdoren nga ) në nivel API.
Ngjashëm me qasjen për pajisjet Android, ne kemi implementuar Cronet në aplikacionet Uber në iOS, duke përgjuar trafikun HTTP nga rrjeti duke përdorur . Ky abstraksion, i ofruar nga Fondacioni iOS, trajton të dhënat URL specifike të protokollit dhe siguron që ne mund të integrojmë Cronet në aplikacionet tona iOS pa kosto të konsiderueshme migrimi.
Përfundimi i QUIC në balancuesit e resë kompjuterike të Google
Në anën e pasme, përfundimi QUIC ofrohet nga infrastruktura e balancimit të ngarkesës në renë kompjuterike të Google, e cila përdor headers në përgjigje për të mbështetur QUIC. Në përgjithësi, balancuesi shton një kokë alt-svc në çdo kërkesë HTTP, dhe kjo tashmë vërteton mbështetjen QUIC për domenin. Kur një klient Cronet merr një përgjigje HTTP me këtë kokë, ai përdor QUIC për kërkesat e mëvonshme HTTP në atë domen. Pasi balancuesi të përfundojë QUIC, infrastruktura jonë e dërgon në mënyrë të qartë këtë veprim mbi HTTP2/TCP në qendrat tona të të dhënave.
Performanca: Rezultatet
Performanca e daljes është arsyeja kryesore për kërkimin tonë për një protokoll më të mirë. Për të filluar, ne krijuam një stendë me për të zbuluar se si do të sillet QUIC në profile të ndryshme të rrjetit. Për të testuar performancën e QUIC në rrjetet reale, ne kryem eksperimente gjatë vozitjes nëpër Nju Delhi duke përdorur trafikun e emuluar të rrjetit shumë të ngjashëm me thirrjet HTTP në aplikacionin e pasagjerëve.
Eksperimenti 1
Pajisjet për eksperimentin:
- testoni pajisjet Android me rafte OkHttp dhe Cronet për t'u siguruar që ne lejojmë trafikun HTTPS mbi TCP dhe QUIC përkatësisht;
- një server emulimi të bazuar në Java që dërgon të njëjtin lloj titujsh HTTPS në përgjigje dhe ngarkon pajisjet e klientit për të marrë kërkesa prej tyre;
- proxies cloud që ndodhen fizikisht afër Indisë për të përfunduar lidhjet TCP dhe QUIC. Ndërsa për përfundimin e TCP kemi përdorur një përfaqësues të kundërt në , ishte e vështirë për të gjetur një përfaqësues të kundërt me burim të hapur për QUIC. Ne ndërtuam vetë një përfaqësues të kundërt për QUIC duke përdorur grupin bazë QUIC nga Chromium dhe atë në krom si burim i hapur.
Figura 6. Kompleti i testimit rrugor TCP vs QUIC përbëhej nga pajisje Android me OkHttp dhe Cronet, proxies cloud për përfundimin e lidhjeve dhe një server emulimi.
Eksperimenti 2
Kur Google e vuri në dispozicion QUIC me , ne përdorëm të njëjtin inventar, por me një modifikim: në vend të NGINX, morëm balancuesit e ngarkesës së Google për të përfunduar lidhjet TCP dhe QUIC nga pajisjet, si dhe për të drejtuar trafikun HTTPS në serverin emulues. Balancuesit shpërndahen në të gjithë botën, por përdorin serverin PoP më të afërt me pajisjen (në sajë të vendndodhjes gjeografike).
Figura 7. Në eksperimentin e dytë, ne donim të krahasonim vonesën e përfundimit të TCP dhe QUIC: duke përdorur Google Cloud dhe duke përdorur përfaqësuesin tonë të cloud.
Si rezultat, disa zbulime na prisnin:
- përfundimi nëpërmjet PoP përmirësoi performancën TCP. Meqenëse balancuesit ndërpresin lidhjet TCP më afër përdoruesve dhe janë shumë të optimizuar, kjo rezulton në RTT më të ulëta, gjë që përmirëson performancën TCP. Dhe megjithëse QUIC u ndikua më pak, ai përsëri e tejkaloi TCP-në për sa i përket reduktimit të vonesës së bishtit (me 10-30 përqind).
- preken bishtat . Megjithëse përfaqësuesi ynë QUIC ishte më larg nga pajisjet (rreth 50 ms vonesë më e lartë) sesa balancuesit e ngarkesës së Google, ai dha performancë të ngjashme - një reduktim 15% në vonesë kundrejt një reduktimi 20% në përqindjen e 99-të për TCP. Kjo sugjeron që tranzicioni i miljes së fundit është një pengesë në rrjet.
Figura 8: Rezultatet nga dy eksperimente tregojnë se QUIC tejkalon ndjeshëm TCP-në.
Trafiku luftarak
Të frymëzuar nga eksperimentet, ne kemi implementuar mbështetjen QUIC në aplikacionet tona Android dhe iOS. Kemi kryer testimin A/B për të përcaktuar ndikimin e QUIC në qytetet ku operon Uber. Në përgjithësi, pamë një ulje të ndjeshme të vonesave në të dy rajonet, operatorët e telekomit dhe llojin e rrjetit.
Grafikët e mëposhtëm tregojnë përmirësimet në përqindje të bishtave (95 dhe 99 përqindje) sipas makro-rajoneve dhe llojeve të ndryshme të rrjeteve - LTE, 3G, 2G.
Figura 9. Në testet e betejës, QUIC ia kaloi TCP-së për sa i përket vonesës.
Vetëm përpara
Ndoshta ky është vetëm fillimi - lëshimi i QUIC në prodhim ka ofruar mundësi të mahnitshme për të përmirësuar performancën e aplikacionit si në rrjetet e qëndrueshme ashtu edhe në ato të paqëndrueshme, përkatësisht:
Mbulim i rritur
Pasi analizuam performancën e protokollit në trafikun real, pamë se afërsisht 80% e seancave përdorën me sukses QUIC për Të gjithë kërkesat, ndërsa 15% e seancave përdorën një kombinim të QUIC dhe TCP. Supozojmë se kombinimi është për shkak të kthimit të kohës së bibliotekës Cronet në TCP, pasi nuk mund të bëjë dallimin midis dështimeve reale të UDP dhe kushteve të këqija të rrjetit. Aktualisht jemi duke kërkuar një zgjidhje për këtë problem ndërsa punojmë drejt zbatimit të mëvonshëm të QUIC.
Optimizimi QUIC
Trafiku nga aplikacionet celulare është i ndjeshëm ndaj vonesës, por jo i ndjeshëm ndaj gjerësisë së brezit. Gjithashtu, aplikacionet tona përdoren kryesisht në rrjetet celulare. Bazuar në eksperimentet, vonesat e bishtit janë ende të larta edhe pse përdoret një përfaqësues për të përfunduar TCP dhe QUIC afër përdoruesve. Ne jemi duke kërkuar në mënyrë aktive mënyra për të përmirësuar menaxhimin e mbipopullimit dhe për të përmirësuar efikasitetin e algoritmeve të rikuperimit të humbjeve QUIC.
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 e bërë transportin e përshtatshëm dhe pa probleme të paketave më të aksesueshëm në mbarë botën.
Burimi: www.habr.com