QUIC protokoloa oso interesgarria da ikusteko, eta horregatik gustatzen zaigu horri buruz idaztea. Baina QUICri buruzko aurreko argitalpenak izaera eta hardware historikoa (tokiko historia, nahi baduzu) gehiago baziren, gaur pozik gaude beste mota bateko itzulpena argitaratzeaz - 2019an protokoloaren benetako aplikazioaz hitz egingo dugu. Gainera, ez gara garaje deituriko batean oinarritutako azpiegitura txikiez ari, ia mundu osoan funtzionatzen duen Uberaz baizik. Nola hartu zuten konpainiako ingeniariek QUIC ekoizpenean erabiltzeko erabakia, nola egin zituzten probak eta zer ikusi zuten produkzioan zabaldu ondoren - ebakiaren azpian.
Irudiak klika daitezke. Gozatu irakurtzen!
Uber-ek eskala globala du, hots, 600 presentzia-hiri, eta horietako bakoitzean aplikazioa haririk gabeko Interneten oinarritzen da erabat 4500 operadore zelular baino gehiagorengandik. Erabiltzaileek aplikazioa azkarra ez ezik, denbora errealean izatea espero dute; hori lortzeko, Uber aplikazioak latentzia txikia eta konexio oso fidagarria behar ditu. Ai, baina pila ez du ondo funtzionatzen haririk gabeko sare dinamiko eta galeretarako. Konturatu ginen kasu honetan errendimendu baxua sistema eragilearen nukleoetan TCP inplementazioekin zuzenean lotuta dagoela.
Arazoa konpontzeko, aplikatu dugu , garraio-protokoloaren errendimenduaren gaineko kontrol gehiago ematen digun kanalen multiplexazio-protokolo modernoa. Gaur egun lan taldea QUIC gisa estandarizatzen du .
Proba ugari egin ondoren, gure aplikazioan QUIC ezartzeak TCP-rekin alderatuta buztan latentzia txikiagoak eragingo lituzkeela ondorioztatu genuen. Gidariaren eta bidaiarien aplikazioetan HTTPS trafikoaren % 10-30eko tartean murrizketa ikusi dugu. QUIC-ek erabiltzailearen paketeen amaierako kontrola ere eman zigun.
Artikulu honetan, Uber aplikazioetarako TCP optimizatzeko esperientzia partekatzen dugu QUIC onartzen duen pila bat erabiliz.
Azken teknologia: TCP
Gaur egun, TCP da Interneten HTTPS trafikoa emateko gehien erabiltzen den garraio-protokoloa. TCP-k byte-korronte fidagarria eskaintzen du, sarearen pilaketari eta esteka-geruzen galerari aurre egiteko. HTTPS trafikorako TCPren erabilera hedatua lehenaren nonahikotasunari dagokio (ia OS guztiek dute TCP), azpiegitura gehienetan erabilgarritasunagatik (adibidez, karga-orekatzaileak, HTTPS proxyak eta CDNak) eta erabilgarri dauden erabilgarri dauden funtzionalitate arruntengatik. ia plataforma eta sare gehienetan.
Erabiltzaile gehienek gure aplikazioa edonoiz erabiltzen dute, eta TCP buztan latentzia ez zegoen gure denbora errealeko HTTPS trafikoaren eskakizunetatik gertu. Besterik gabe, mundu osoko erabiltzaileek hau bizi izan dute - 1. irudiak hiri nagusietako atzerapenak erakusten ditu:
1. irudia: buztanaren latentzia aldatu egiten da Uber-eko hiri nagusietan.
Indiako eta Brasilgo sareetan latentzia AEBetakoa eta Erresuma Batukoa baino handiagoa izan bazen ere, isatseko latentzia batez besteko latentzia baino nabarmen handiagoa da. Eta hori egia da AEBetan eta Erresuma Batuan ere.
TCP aireko errendimendua
TCPrako sortu zen kableatua sareak, hau da, oso aurreikus daitezkeen loturak azpimarratuz. Hala ere, haririk gabea sareek bere ezaugarriak eta zailtasunak dituzte. Lehenik eta behin, haririk gabeko sareek galerak jasan ditzakete interferentziaren eta seinalearen murriztapenaren ondorioz. Adibidez, Wi-Fi sareak mikrouhin, bluetooth eta beste irrati-uhinekiko sentikorrak dira. Sare zelularrek seinalea galtzen dute () objektuek eta eraikinek seinalea islatzeagatik/xurgatzeagatik, baita horietatik ere aldamenetik . Horrek esanguratsuagoa (4-10 aldiz) eta anitzagoa dakar eta pakete-galera kable bidezko konexio batekin alderatuta.
Banda zabaleraren gorabeherei eta galerei aurre egiteko, sare zelularrek normalean buffer handiak erabiltzen dituzte trafiko-leherketarako. Horrek gehiegizko ilarak ekar ditzake, hau da, atzerapen luzeagoak. Askotan TCP-k ilara hori hondakintzat hartzen du denbora-muga luze baten ondorioz, beraz, TCP-k erreproduzitzeko joera du eta, ondorioz, buffera betetzeko. Arazo hau izenez ezagutzen da (), eta hau oso Internet modernoa.
Azkenik, sare zelularren errendimendua eramailearen, eskualdearen eta orduaren arabera aldatzen da. 2. irudian, 2 kilometroko barrutian zelulen arteko HTTPS trafikoaren mediana atzerapenak bildu ditugu. Delhiko (India) bi zelulen operadore nagusientzat bildutako datuak. Ikus dezakezunez, errendimendua aldatu egiten da gelaxka batetik bestera. Era berean, operadore baten produktibitatea bigarrenaren produktibitatea desberdina da. Sarearen sarrera ereduak denbora eta kokapena kontuan hartuta, erabiltzaileen mugikortasuna, baita sarearen azpiegiturak dorre dentsitatea eta sare moten ratioa kontuan hartuta (LTE, 3G, etab.) faktoreek eragiten dute.
2. Irudia. Atzerapenak adibide gisa 2 km-ko erradioa erabiliz. Delhi, India.
Gainera, sare zelularren errendimendua aldatu egiten da denboran zehar. 3. irudiak asteko egunaren araberako latentziaren mediana erakusten du. Eskala txikiagoan ere ikusi ditugu aldeak, egun eta ordu bakarrean.
3. irudia. Buztana atzerapenak nabarmen alda daitezke egunen artean, baina operadore berarentzat.
Aurreko guztiak TCP errendimendua eraginkorra ez izatea eragiten du hari gabeko sareetan. Hala ere, TCPren alternatibak bilatu aurretik, ondoko puntuei buruzko ulermen zehatza garatu nahi izan dugu:
- TCP al da gure aplikazioetako buztan latentziaren errudun nagusia?
- Sare modernoek joan-etorriko atzerapen (RTT) nabarmen eta askotarikoak al dituzte?
- Zein da RTT-k eta galerak TCPren errendimenduan duen eragina?
TCP errendimenduaren analisia
TCPren errendimendua nola aztertu dugun ulertzeko, ikus dezagun nola transferitzen dituen TCPk datuak igorle batetik hartzaile batera. Lehenik eta behin, igorleak TCP konexio bat ezartzen du, hiru noranzko bat eginez : Igorleak SYN pakete bat bidaltzen du, hargailuaren SYN-ACK pakete baten zain dago, eta ACK pakete bat bidaltzen du. Bigarren eta hirugarren pase gehigarri bat TCP konexioa ezartzen gastatzen da. Hartzaileak pakete bakoitza (ACK) jaso duela aitortzen du, entrega fidagarria bermatzeko.
Pakete edo ACK bat galtzen bada, igorleak berriro bidaltzen du denbora-muga baten ondoren (RTO, ). RTO dinamikoki kalkulatzen da hainbat faktoretan oinarrituta, hala nola, igorlearen eta hartzailearen artean espero den RTT atzerapena.
4. Irudia. TCP/TLS bidezko pakete-trukeak birtransmisio-mekanismo bat dauka.
TCP gure aplikazioetan nola funtzionatzen duen zehazteko, TCP paketeen jarraipena egin dugu astebetez Indiako ertzeko zerbitzarietatik datorren borroka-trafikoan. Ondoren, TCP konexioak erabiliz aztertu ditugu . Gainera, emulatutako trafikoa probako zerbitzari batera bidaltzen duen Android aplikazio bat sortu dugu, benetako trafikoa ahalik eta gehien imitatuz. Aplikazio hau duten telefono adimendunak hainbat langileri banatu zitzaizkien, eta hainbat egunetan erregistroak biltzen zituzten.
Bi esperimentuen emaitzak bata bestearekin bat etorri ziren. RTT latentzia handiak ikusi genituen; buztanaren balioak mediana balioa baino ia 6 aldiz handiagoak ziren; atzerapenen batez besteko aritmetikoa segundo 1etik gorakoa da. Konexio asko galtzen ziren, eta TCPk pakete guztien % 3,5 birtransmititu zuen. Pilatutako guneetan, hala nola aireportuetan eta tren geltokietan, %7ko galerak izan ditugu. Emaitza hauek sare zelularretan erabiltzen duten ohiko jakinduria zalantzan jartzen dute garraio mailan galerak nabarmen murriztea. Jarraian, "simulatzailea" aplikazioaren proben emaitzak daude:
Sare-neurriak
esanahia
RTT, milisegundoak [%50,%75,%95,%99]
[350, 425, 725, 2300]
RTT dibergentzia, segundo
Batez beste ~1,2 s
Pakete-galera konexio ezegonkorretan
Batez besteko %3.5 ~ (%7 gainkargatutako eremuetan)
Konexio horien ia erdiek gutxienez pakete bat galdu zuten, gehienak SYN eta SYN-ACK paketeak. TCP inplementazio gehienek segundo 1eko RTO balioa erabiltzen dute SYN paketeetarako, eta hori esponentzialki handitzen da ondorengo galeretarako. Aplikazioak kargatzeko denborak handitu egin daitezke, TCP-k konexioak ezartzeko denbora gehiago behar duelako.
Datu-paketeen kasuan, RTO balio handiek sarearen erabilera erabilgarria asko murrizten dute hari gabeko sareetan galera iragankorren aurrean. Batez besteko birtransmisio-denbora segundo 1ekoa dela ikusi genuen, ia 30 segundoko atzerapenarekin. TCP mailan latentzia handi hauek HTTPS denbora-muga eta berriro eskaerak eragin zituzten, sarearen latentzia eta eraginkortasun eza areagotuz.
Neurtutako RTTren 75. pertzentilea 425 ms ingurukoa zen bitartean, TCPren 75. pertzentilea ia 3 segundokoa izan zen. Honek iradokitzen du galerak TCP-k 7-10 pase hartu zituela datuak arrakastaz transmititzeko. Hau RTO kalkulu ez-eraginkor baten ondorioa izan daiteke, TCP-k galerari azkar erantzuteko ezintasuna. leihoan eta pilaketak kontrolatzeko algoritmoaren eraginkortasunik eza, haririk gabeko galerak eta sarearen pilaketen ondoriozko galerak bereizten ez dituena. Jarraian, TCP galera proben emaitzak daude:
TCP pakete-galeren estatistikak
Balio
Gutxienez pakete bat galdu duten konexioen ehunekoa
45%
Konexioa konfiguratzean galerak dituzten konexioen ehunekoa
30%
Datuen trukean galerak dituzten konexioen ehunekoa
76%
Retransmisioko atzerapenen banaketa, segundoak [% 50, % 75, % 95, % 99] [1, 2.8, 15, 28]
Pakete edo TCP segmentu baterako birtransmisio kopuruaren banaketa
[1,3,6,7]
QUIC aplikazioa
Jatorriz Googlek garatua, QUIC hari anitzeko garraio protokolo moderno bat da, UDPren gainean exekutatzen dena. Une honetan QUIC sartuta dago (dagoeneko idatzi dugu badirela, nolabait, QUIC-en bi bertsio, bitxia β gutxi gorabehera. itzultzailea). 5. irudian ikusten den bezala, QUIC HTTP/3 azpian kokatzen da (hain zuzen ere, HTTP/2 QUIC-en gainean HTTP/3 da, gaur egun intentsiboki estandarizatzen ari dena). Partzialki HTTPS eta TCP geruzak ordezkatzen ditu UDP erabiliz paketeak osatzeko. QUIC-ek datu-transferentzia segurua soilik onartzen du, TLS QUIC-en guztiz integratuta baitago.
5. Irudia: QUIC HTTP/3 pean exekutatzen da, lehen HTTP/2 pean exekutatzen zen TLS ordezkatuz.
Jarraian, TCP anplifikaziorako QUIC erabiltzera konbentzitu gaituzten arrazoiak daude:
- 0-RTT konexioa ezartzea. QUIC-ek aurreko konexioetako baimenak berrerabiltzeko aukera ematen du, segurtasun-eskubideen kopurua murriztuz. Etorkizunean 0-RTT onartzen du, baina hiru norabideko TCP esku-ematea beharrezkoa izango da oraindik.
- HoL blokeoa gainditzea. HTTP/2-k TCP konexio bat erabiltzen du bezero bakoitzeko errendimendua hobetzeko, baina honek HoL (lerro-burua) blokeatzea ekar dezake. QUIC-ek multiplexazioa errazten du eta eskaerak aplikazioari modu independentean ematen dizkio.
- pilaketak kontrolatzea. QUIC aplikazio-geruzan dago, sareko parametroetan (galera kopurua edo RTT) oinarrituta bidalketa kontrolatzen duen garraio-algoritmo nagusia eguneratzea erraztuz. TCP inplementazio gehienek algoritmoa erabiltzen dute , latentzia-sentikorra den trafikorako egokiena ez dena. Hala nola, duela gutxi garatu diren algoritmoak , sarea zehatzago modelatu eta latentzia optimizatu. QUIC-ek BBR erabiltzeko eta algoritmo hau erabiltzen den heinean eguneratzeko aukera ematen du. .
- galerak berritzea. QUIC-ek bi TLP deitzen ditu () RTO abiarazi baino lehen, nahiz eta galerak oso nabariak diren. Hau TCP inplementazioetatik desberdina da. TLP-k batez ere azken paketea (edo berria, baldin badago) birbidaltzen du, berritze azkarra abiarazteko. Buztan-atzerapenak kudeatzea bereziki erabilgarria da Uber-ek bere sarea funtzionatzen duen moduan, hots, datu-transferentzia laburrak, esporadikoak eta latentzia-sentikorrak direnetarako.
- ACK optimizatua. Pakete bakoitzak sekuentzia-zenbaki bakarra duenez, ez dago arazorik paketeak berriro igortzen direnean. ACK paketeek paketea prozesatzeko eta bezero aldean ACK bat sortzeko denbora ere badute. Ezaugarri hauek bermatzen dute QUIC-ek RTT zehatzago kalkulatzen duela. ACK-ek QUIC-en 256 banda onartzen ditu , igorlea paketeen nahasteari erresistenteagoa izaten eta prozesuan byte gutxiago erabiltzen lagunduz. ACK selektiboa () TCPn ez du arazo hau konpontzen kasu guztietan.
- konexio migrazioa. QUIC konexioak 64 biteko ID baten bidez identifikatzen dira, beraz, bezero batek IP helbideak aldatzen baditu, konexio ID zaharra IP helbide berrian erabiltzen jarraitu ahal izango du etenik gabe. Hau oso ohikoa da aplikazio mugikorretarako, non erabiltzailea Wi-Fi eta zelula-konexioetatik aldatzen den.
QUIC-en alternatibak
Arazoa konpontzeko planteamendu alternatiboak kontuan hartu ditugu QUIC aukeratu aurretik.
Saiatu ginen lehen gauza TPC PoPak (Presentzia Puntuak) zabaltzea izan zen, TCP konexioak erabiltzaileengandik hurbilago amaitzeko. Funtsean, PoP-ek TCP konexioa amaitzen dute gailu mugikor batekin sare zelularretik hurbilago dagoen eta trafikoa jatorrizko azpiegiturara itzultzen dute. TCP hurbilago amaituz gero, RTT murriztu dezakegu eta TCPk haririk gabeko ingurune dinamiko bati erantzun handiagoa emango diola ziurtatu. Hala ere, gure esperimentuek erakutsi dute RTT eta galera gehienak sare zelularretatik datozela eta PoPak erabiltzeak ez duela errendimendu hobekuntza nabarmenik ematen.
TCP parametroak sintonizatzea ere aztertu dugu. Gure ertz zerbitzari heterogeneoetan TCP pila bat konfiguratzea zaila izan zen, TCPk inplementazio desberdinak dituelako OS bertsio ezberdinetan. Zaila izan zen hau ezartzea eta sarearen konfigurazio desberdinak probatzea. TCP zuzenean konfiguratu gailu mugikorretan ezin izan da baimen faltagatik. Are garrantzitsuagoa dena, 0-RTT konexioak eta RTT iragarpen hobetua bezalako ezaugarriak funtsezkoak dira protokoloaren arkitekturarako, eta, beraz, ezinezkoa da onura handiak lortzea TCP bakarrik sintonizatuz.
Azkenik, UDPn oinarritutako hainbat protokolo ebaluatu ditugu bideoaren streaming arazoak konpontzen dituztenak, protokolo hauek gure kasuan lagunduko ote zuten ikusi nahi genuen. Zoritxarrez, segurtasun-ezarpen asko falta zitzaizkien, eta TCP konexio gehigarri bat ere behar zuten metadatuetarako eta kontrol-informaziorako.
Gure ikerketek erakutsi dute QUIC dela agian Interneteko trafikoaren arazoarekin lagun dezakeen protokolo bakarra, segurtasuna eta errendimendua kontuan hartuta.
QUIC plataforman integratzea
QUIC ongi txertatzeko eta aplikazioen errendimendua hobetzeko konektagarritasun-ingurune eskasetan, pila zaharra (HTTP/2 TLS/TCP bidez) QUIC protokoloarekin ordezkatu dugu. Sareko liburutegia erabili dugu - , protokoloaren jatorrizko Google bertsioa duena - gQUIC. Inplementazio hau ere etengabe hobetzen ari da IETFren azken zehaztapena jarraitzeko.
Lehenik Cronet gure Android aplikazioetan integratu genuen QUIC-en laguntza gehitzeko. Integrazioa migrazio kostuak ahalik eta gehien murrizteko moduan egin zen. Liburutegia erabiltzen zuen sareko pila zaharra guztiz ordezkatu beharrean , Cronet integratu dugu OkHttp API markoaren PEAN. Integrazioa horrela eginez, gure sareko deien aldaketak saihestu ditugu (horrek erabiltzen dituzte ) API mailan.
Android gailuetarako planteamenduaren antzera, Cronet inplementatu genuen iOS-eko Uber aplikazioetan, sareko HTTP trafikoa atzematen. erabiliz . IOS Fundazioak emandako abstrakzio honek protokoloaren URL datuak kudeatzen ditu eta Cronet gure iOS aplikazioetan txerta dezakegula ziurtatzen du migrazio kostu handirik gabe.
QUIC osatzea Google Cloud Balancers-en
Atzeko aldean, QUIC osatzea Google Cloud Load orekatzeko azpiegiturak eskaintzen du, eta horrek erabiltzen du. goiburuak QUIC laguntza emateko erantzunetan. Oro har, orekatzaileak alt-svc goiburu bat gehitzen dio HTTP eskaera bakoitzari, eta honek dagoeneko balioztatzen du domeinurako QUIC laguntza. Cronet bezero batek goiburu honekin HTTP erantzun bat jasotzen duenean, QUIC erabiltzen du domeinu horri hurrengo HTTP eskaerak egiteko. Balantzaileak QUIC-a osatzen duenean, gure azpiegiturak ekintza hau espresuki bidaltzen du HTTP2/TCP bidez gure datu-zentroetara.
Errendimendua: Emaitzak
Irteeraren errendimendua da protokolo hobea bilatzeko gure arrazoi nagusia. Hasteko, stand bat sortu genuen sareko profil ezberdinetan QUIC-ek nola jokatuko duen jakiteko. QUIC-en errendimendua mundu errealeko sareetan probatzeko, esperimentuak egin genituen New Delhi-n zehar gidatzen ari ginen bitartean, bidaiarientzako aplikazioko HTTP deien antzeko sare-trafikoa emulatua erabiliz.
1. esperimentua
Esperimenturako ekipamendua:
- probatu Android gailuak OkHttp eta Cronet pilarekin HTTPS trafikoa onartzen dugula ziurtatzeko, hurrenez hurren, TCP eta QUIC bidez;
- Javan oinarritutako emulazio zerbitzari bat, erantzunetan HTTPS goiburu mota berdinak bidaltzen dituena eta bezeroen gailuak kargatzen dituena, haien eskaerak jasotzeko;
- Indiatik gertu fisikoki kokatuta dauden hodeiko proxyak TCP eta QUIC konexioak amaitzeko. TCP amaierarako, berriz, alderantzizko proxy bat erabili dugu , zaila izan zen QUICentzako kode irekiko alderantzizko proxy bat aurkitzea. QUIC-rako alderantzizko proxy bat eraiki dugu Chromium-en oinarrizko QUIC pila erabiliz eta kromo bihurtu kode ireki gisa.
6. Irudia. TCP vs QUIC errepideko proba multzoa OkHttp eta Cronet duten Android gailuek, konexioak amaitzeko hodeiko proxyek eta emulazio zerbitzari batek osatzen zuten.
2. esperimentua
Google-k QUIC erabilgarri jarri zuenean , inbentario bera erabili dugu, baina aldaketa batekin: NGINX-en ordez, Google karga-orekatzaileak hartu ditugu gailuetatik TCP eta QUIC konexioak amaitzeko, baita HTTPS trafikoa emulazio zerbitzarira bideratzeko ere. Balancers mundu osoan banatuta daude, baina gailutik gertuen dagoen PoP zerbitzaria erabiltzen dute (geokokapenari esker).
7. Irudia. Bigarren esperimentuan, TCP eta QUIC-en osatzeko latentzia alderatu nahi izan dugu: Google Cloud erabiliz eta gure hodeiko proxy erabiliz.
Ondorioz, hainbat errebelazio itxaroten zitzaizkigun:
- PoP bidez amaitzeak TCP errendimendua hobetu du. Balantzaileek TCP konexioak erabiltzaileengandik hurbilago amaitzen dituztenez eta oso optimizatuta daudenez, horrek RTT txikiagoak eragiten ditu, eta horrek TCP errendimendua hobetzen du. Eta QUIC-ek gutxiago kaltetu bazuen ere, oraindik ere TCP gainditu zuen buztanaren latentzia murrizteko (ehuneko 10-30).
- isatsak kaltetuta daude . Gure QUIC proxy gailuetatik (50 ms inguru latentzia handiagoa) Google-ren karga-orekatzaileak baino urrunago zegoen arren, antzeko errendimendua eman zuen: latentzia % 15 murriztu zen TCPren 20. pertzentilaren % 99ko murrizketa. Horrek iradokitzen du azken kilometroko trantsizioa sarean botila-lepoa dela.
8. Irudia: Bi esperimentutako emaitzek erakusten dute QUIC-ek TCP nabarmen gainditzen duela.
Trafikoari aurre egitea
Esperimentazioan inspiratuta, QUIC euskarria ezarri dugu gure Android eta iOS aplikazioetan. A/B probak egin ditugu QUIC-en eragina zehazteko Uber-ek lan egiten duen hirietan. Oro har, buztanen atzerapenen murrizketa nabarmena ikusi dugu bi eskualdeetan, telekomunikazio operadoreetan eta sare motan.
Beheko grafikoek buztanen ehuneko hobekuntzak (95 eta 99 pertzentilak) erakusten dituzte makroeskualdearen eta sare mota ezberdinen arabera: LTE, 3G, 2G.
9. irudia. Borroka-probetan, QUIC-k TCP-k gainditu zuen latentziari dagokionez.
Aurrera bakarrik
Beharbada, hau hasiera besterik ez da - QUIC ekoizpenean kaleratzeak aukera harrigarriak eman ditu aplikazioen errendimendua hobetzeko sare egonkorretan zein ezegonkorretan, hots:
Estaldura handitu
Trafiko errealean protokoloaren errendimendua aztertuta, ikusi genuen gutxi gorabehera saioen % 80ak arrakastaz erabiltzen zuela QUIC guztiak eskaerak, eta saioen % 15ek QUIC eta TCP konbinazioa erabiltzen zuten. Konbinazioa Cronet liburutegiaren denbora-muga TCPra itzultzearen ondoriozkoa dela suposatzen dugu, ezin baititu UDP benetako akatsak eta sareko baldintza kaskarrak bereizi. Momentu honetan, arazo honen konponbidea bilatzen ari gara, QUIC-a geroko inplementazioa lortzeko lanean ari garen heinean.
QUIC optimizazioa
Mugikorretarako aplikazioetako trafikoa latentziaren araberakoa da, baina ez banda-zabaleraren araberakoa. Gainera, gure aplikazioak sare mugikorretan erabiltzen dira batez ere. Esperimentuetan oinarrituta, isats-latentziak handiak dira oraindik, nahiz eta proxy bat erabili TCP eta QUIC erabiltzaileengandik gertu amaitzeko. Pilaketen kudeaketa hobetzeko eta QUIC galerak berreskuratzeko algoritmoen eraginkortasuna hobetzeko moduak bilatzen ari gara aktiboki.
Hobekuntza hauekin eta beste hainbatekin, erabiltzailearen esperientzia hobetzeko asmoa dugu sarea eta eskualdea edozein izanda ere, paketeen garraio erosoa eta bateratu gabea mundu osoan eskuragarriago bihurtuz.
Iturria: www.habr.com