QUIC-protokoll tegutsemas: kuidas Uber seda rakendas jõudluse optimeerimiseks

QUIC-protokolli on äärmiselt huvitav teema, millest me armastame kirjutada. Kui varasemad QUIC-i postitused käsitlesid rohkem ajaloolisi aspekte ja matemaatikat, siis täna oleme rõõmsad, et saame avaldada teistsuguse tõlke – räägime protokolli reaalsest kasutamisest 2019. aastal. Ja juttu ei ole väikesest infrastruktuurist, mis asub kuskil garaažis, vaid Uberist, mis tegutseb peaaegu kogu maailmas. Kuidas ettevõtte insenerid otsustasid QUIC-i kasutada tootmises, kuidas nad teste viisid läbi ja mida nad pärast kasutusele võtmist täheldasid – loe edasi.

Pildid on klikkitavad. Head lugemist!

Uber on maailma mastaabis, olles kohal 600 linnas, kus rakendus sõltub täielikult üle 4500 mobiilioperaatori traadita internetist. Kasutajad ootavad, et rakendus töötab mitte lihtsalt kiiresti, vaid reaalajas – selle tagamiseks vajab Uberi rakendus madalaid latentsusaegu ja väga usaldusväärset ühendust. Kahjuks aga TCP-stack HTTP/2 ei suuda toimida dünaamilistes ja paketikaotusele kalduvates traadita võrkudes. Me mõistsime, et madal tulemuslikkus on otseselt seotud TCP rakendustega operatsioonisüsteemi kernides.

Probleemi lahendamiseks rakendasime QUIC, kaasaegse protokolli, millel on kanalite mulitplekseerimine, mis annab meile rohkem kontrolle transportprotokolli jõudluse üle. Praegu on töögrupp Uue juhi peamisteks eesmärkideks on luua tingimusi, et inimesed naudiksid oma aega Debianis osalemiseks. Selle eesmärgi saavutamiseks kavatsetakse muuta protsessid ja suhtlemine lihtsaks, tõhusaks ja arusaadavaks, suurendada projekti atraktiivsust uutele osalejatele ning tagada sõbraliku atmosfääri ja vastastikuse arusaamise hoidmine kogukonnas, olenemata lõplikest otsustest ja teatud ideede kinnitamisest või tagasilükkamisest. standardiseerimas QUIC-i kui standardiseerib.

Pärast põhjalikke teste jõudsime järeldusele, et QUIC-i kasutuselevõtt meie rakenduses vähendab "sabade" latentsusaegu, võrreldes TCP-ga. Vaatasime HTTPS-i liikluses ja nägime 10-30% vähenemist juhi- ja reisija-rakendustes. QUIC andis meile ka täieliku kontrolli kasutaja paketid üle.

Selles artiklis jagame kogemusi TCP optimeerimisest Uberi rakenduste jaoks QUIC-i toega stack'i abil.

Tehnika viimane sõna: TCP

Täna on TCP kõige kasutatavam transportprotokoll HTTPS-i liikluse edastamiseks internetis. TCP tagab usaldusväärse baitide voolu, mistõttu suudab see toime tulla võrgu ülekoormuse ja kaotanud kanalitaseme. TCP laialdane rakendamine HTTPS-i liikluses on seletatav selle laialdase olemasoluga (peaaegu iga opsüsteem sisaldab TCP-d), kergesti kättesaadavusega enamus infrastruktuurist (näiteks koormuse tasakaalustajad, HTTPS-proxyd ja CDN-id) ning „kastist välja“ funktsionaalsusega, mis on kergesti ligipääsetav enamikes platvormides ja võrkudes.

Enamik kasutajatest kasutab meie rakendust liikvel olles ning TCP „sabavirgestused“ jäävad olulistele nõudmistele meie reaalaja HTTPS-i liikluses vastupidiseks. Lihtsalt öeldes on sellega silmitsi seisnud kasutajad üle kogu maailma – Joonisel 1 on kujutatud viivitusi suurtes linnades:

Joonis 1. „Sabavirgestuste“ suurus varieerub Uberi kohaloleku peamistes linnades.

Kuigi Indias ja Brasiilias olid viivitused suuremad kui USA-s ja Suurbritannias, on sabavirgestused märkimisväärselt kõrgemad kui keskmised viivitused. Ja see kehtib ka USA ja Suurbritannia kohta.

TCP jõudlus üle õhu

TCP loodi juhttasandi võrkude jaoks, keskendudes hästi ennustatavatele linkidele. Kuid traadita võrkudel on oma eripärad ja väljakutsed. Esiteks on traadita võrgud tundlikud signaali kadumise suhtes, mis tuleneb häiretest ja signaali nõrgenemisest. Näiteks Wi-Fi võrgud on tundlikud mikrolainete, bluetooth'i ja muude raadiolainete suhtes. Mobiilivõrgud kannatavad signaali kaotuse all (tee kadu) signaali peegelduse / neelamise tõttu esemetest ja hoonetest, samuti häirete tõttu naabervõrkudest mobiilitornidest.See toob kaasa märkimisväärseid (4-10 korda) ja varieeruvaid ümaraid viivitusi (RTT) ja pakettide kaotusi võrreldes juhttasandi ühendusega.

Kuna mobiilivõrgud püüavad võidelda ribalaiuse kõikumiste ja kaotustega, kasutatakse tavaliselt suuri puhverdamise mälusid liikluse tippude jaoks. See võib viia liigse järjekorra loomisele, mis tähendab pikemaid viivitusi. Very sageli tõlgendab TCP sellist järjekorra ettevalmistamist kui kaotust pikendatud aja tõttu, seetõttu kalduvad TCP tegema uuesti edastamist ja täitma puhvrit. Seda probleemi tuntakse kui bufferbloat (liigset võrgu puhverdamist, puhverdamise paisumist), ja see on väga tõsine probleem kaasaegse interneti.

Lõpuks sõltub mobiilivõrgu jõudlus operaatorist, piirkonnast ja ajast. Joonisel 2 oleme kogunud HTTPS-liiklusest mõõdetud keskmised latentsused 2-kilomeetrises raadiuses. Andmed on kogutud kahe suurima mobiilsideoperaatori kohta Delhis, Indias. Nagu näha, varieerub jõudlus võrgu ja operaatori lõikes. Lisaks erineb ühe operaatori jõudlus teise oma jõudlusest. Sellele mõjutavad tegurid, nagu võrku sisenemise mustrid ajas ja asukohas, kasutajate liikuvus ning võrgu infrastruktuur, sealhulgas masti tihedus ja võrgu tüüpide (LTE, 3G jne) suhe.

Joonis 2. Latentsused 2-kilomeetrise raadiuse näitel. Delhi, India.

Samuti varieerub mobiilivõrkude jõudlus ajas. Joonisel 3 on näidatud keskmine latentsus nädalapäevade lõikes. Me oleme samuti märganud erinevusi veelgi väiksemas mastaabis – sama päeva ja tunni jooksul.

Joonis 3. Häiresignaalid võivad oluliselt varieeruda erinevate päevade lõikes, kuid samal operaatoril.

Kõik eelnevalt mainitu toob kaasa selle, et TCP jõudlus on traadita võrkudes ebaefektiivne. Siiski, enne kui otsime TCP alternatiive, soovime saavutada täpset arusaama järgmistes punktides:

• kas TCP on peamine süüdlane meie rakenduste hilinenud vastuses?
• Kas kaasaegsetes võrkudes on märkimisväärsed ja mitmekesised ringlatentsused (RTT)?
• Milline on RTT ja kadude mõju TCP jõudlusele?

TCP jõudluse analüüs

Et mõista, kuidas me analüüsisime TCP jõudlust, vaatame lühidalt üle, kuidas TCP edastab andmeid saatjast saajani. Alguses loob saatja TCP-ühenduse, tehes kolmnurga kätlemise: saatja saadab SYN-paketi, ootab saajalt SYN-ACK-paketti, seejärel saadab ta ACK-paketi. Teised kaks protsessi, teine ja kolmas, kuluvad TCP-ühenduse loomiseks. Saaja kinnitab, et on saanud iga paketi (ACK), et tagada usaldusväärne edastamine.

Kui pakett või ACK kaob, kordab saatja edastamist pärast ajavaru (RTO, edastamise ajavaru). RTO arvutatakse dünaamiliselt, tuginedes erinevatele teguritele, näiteks oodatavale latentsusele RTT saatja ja saaja vahel.

Joonis 4. TCP/TLS-i pakettide vahetus sisaldab retranmismehhanisme.

Kuna me tahtsime mõista, kuidas TCP meie rakendustes toimis, jälgisime TCP-pakette tcpdump ühe nädala jooksul tootmisliikluses, mis tuli Indiast piiriserveritelt. Seejärel analüüsisime TCP-ühendusi kasutades tcptrace. Lisaks lõime Android-rakenduse, mis saadab emuleeritud liiklust testserverile, püüdes maksimaalselt jäljendada reaalset liiklust. Need rakendusega nutitelefonid jagati mitmele töötajale, kes kogusid logisid mitme päeva jooksul.

Mõlema katse tulemused olid omavahel kooskõlas. Nägime kõrgeid RTT-viivitusi; sabakeskmed olid peaaegu 6 korda kõrgemad mediansest; viivituste aritmeetiline keskmine oli üle 1 sekundi. Paljudel ühendustel olid paketikaotused, mis sundisid TCP-d retransmoteerima 3,5% kõigist pakettidest. Ülerahvastatud piirkondades, näiteks lennujaamades ja jaamades, täheldasime 7% kaotusi. Sellised tulemused panevad kahtluse alla üldlevinud arvamuse, et mobiilsides kasutatavad täiustatud retranmisjad vähemalt oluliselt vähendavad kaotusi transporditasandil. Allpool on tulemused simulaatorrakenduse testidest:

Võrgumetris
Väärtused

RTT, millisekundites [50%, 75%, 95%, 99%]
[350, 425, 725, 2300]

RTT-lõhe, sekundites
Keskmiselt ~1,2 s

Pakettide kaotus ebastabiilsetes ühendustes
Keskmiselt ~3.5% (7% ülerahvastatud piirkondades)

Peaaegu poolel neist ühendustest oli vähemalt üks pakett kaotsis, enamik neist olid SYN ja SYN-ACK paketid. Enamik TCP teostusi kasutab RTO väärtuse 1 sekundi SYN-pakettide jaoks, mis eksponetsiaalselt suureneb edasiste kaotuste korral. Rakenduse laadimisaeg võib suureneda, kuna TCP vajab rohkem aega ühenduste loomiseks.

Andmepakettide puhul vähendavad kõrged RTO väärtused oluliselt võrgu kasulikku kasutust ajutiste kaotuste korral traadita võrkudes. Me selgitasime välja, et retranmisaja keskmine on umbes 1 sekund, kusjuures sabaviivitus on peaaegu 30 sekundit. Sellised kõrged viivitused TCP tasemel põhjustasid HTTPS-i aegumise ja kordusnõudmisi, mis suurendasid veelgi viivitust ja võrgu ebatõhusust.

Kuigi 75. protsenti mõõdetud RTT-st oli umbes 425 ms, oli TCP 75. protsent peaaegu 3 sekundit. See viitab sellele, et kaotused sundisid TCP-d tegema andmete edastamiseks 7-10 korda katsetusi. Selle põhjuseks võib olla ebaefektiivne RTO arvutamine või TCP võimetus kaotustele kiiresti reageerida. viimaste paketid aknas ja ülekoormuse juhtimisalgoritmi ebaefektiivsus, mis ei erista traadita kaotusi ja võrguülevaid kaotusi. Allpool on TCP kaotuste testitulemused:

TCP pakettide kaotusstatistika
Tähendus

Protsent ühendustest, kus on vähemalt 1 paketti kadunud
45%

Protsent ühendustest, kus kaotused esinesid ühenduse loomise ajal
30%

Protsent ühendustest, kus kaotused esinesid andmevahetuse ajal
76%

Viivituste jaotumine uuesti edastamises, sekundid [50%, 75%, 95%, 99%]
[1, 2.8, 15, 28]

Ühe paketi või TCP-segmendi jaoks uuesti edastamiste arvu jaotumine
[1,3,6,7]

QUIC rakendamine

Algse disaini tegi Google, QUIC on mitme lõimega kaasaegne transportprotokoll, mis töötab UDP peal. Praegu on QUIC standardeerimise protsessis (oleme juba kirjutanud, et QUIC-l on justkui kaks versiooni, uudishimulikud võivad minna lingile – tõlkija märkus). Nagu näidatud joonisel 5, asub QUIC HTTP/3 all (tegelikult on HTTP/2 QUIC-i peal HTTP/3, mida praegu aktiivselt standardiseeritakse). See osaliselt asendab HTTPS-i ja TCP tasemeid, kasutades pakettide koostamiseks UDP-d. QUIC toetab ainult turvalist andmeedastust, kuna TLS on täielikult integreeritud QUIC-i.

Joonis 5: QUIC töötab HTTP/3 all, asendades TLS-i, mis töötas varem HTTP/2 all.

Allpool toome välja põhjused, mis veenisid meid kasutama QUIC-i TCP tugevdamiseks:

• 0-RTT ühenduse loomine. QUIC võimaldab varasemate ühenduste autoriseerimiste taaskasutamist, vähendades turvatehingute arvu. Tulevikus TLS1.3 toetab 0-RTT, kuid kolmesuunaline TCP-tehing jääb endiselt kohustuslikuks.
• HoL-blokeeringu ületamine. HTTP/2 kasutab iga kliendi jaoks ühte TCP-ühendust, et parandada jõudlust, kuid see võib viia HoL (head-of-line) blokeeringuni. QUIC lihtsustab multipleximist ja edastab päringud rakendusele üksteisest sõltumatult.
• ületamine ülekoormuse juhtimisest. QUIC toimib rakenduskihtidel, võimaldades peamist transportalgoritmi kergemini uuendada, mis haldab saatmist, tuginedes võrgutingimustele (kaotuste arv või RTT). Enamik TCP-implementatsioone kasutab algoritmi CUBIC, mis ei ole optimaalne viivitusest sõltuva liikluse jaoks. Hiljuti välja töötatud algoritmid nagu BBRmodelleerivad võrku täpsemalt ja optimeerivad viivitusi. QUIC võimaldab kasutada BBR-i ja uuendada seda algoritmi selle parandamise.
• kaotuste taastamiseks. QUIC kutsub esile kaks TLP (tail loss probe) enne RTO aktiveerimist – isegi kui kaotused on väga ulatuslikud. See erineb TCP-implementatsioonidest. TLP edastab peamiselt viimase paketi (või uue, kui see on olemas), et alustada kiiret taastamist. Haldamine, mis käsitleb saba viivitusi, on eriti kasulik Uberi tööviisi tõttu võrgu osas, nimelt lühikeste, episoodiliste ja viivitustundlike andmeedastuste puhul.
• optimeeritud ACK. Kuna igal pakendil on ainulaadne järjestuse number, ei teki probleemi eristamisega pakettide edastamisel. ACK-paketid sisaldavad samuti aega paketi töötlemiseks ja ACK-i genereerimiseks kliendi poolel. Need omadused tagavad, et QUIC arvutab RTT-d täpsemalt. QUIC-i ACK toetab kuni 256 vahemikku NACK, aidates saatjal olla pakettide muutumisele vastupidavam ja kasutada protsessi käigus vähem baite. Valikuline ACK (SACK) TCP-s ei lahenda see probleem kõigis juhtudes.
• ühenduse migreerimine. QUIC-i ühendused identifitseeritakse 64-bitise ID abil, nii et kui klient vahetab IP-aadresse, saab vana ühenduse ID-d uuel IP-aadressil edasi kasutada, ilma katkestusteta. See on väga levinud praktika mobiilirakendustes, kui kasutaja vahetab Wi-Fi ja mobiilsete ühenduste vahel.

QUIC-i alternatiivid

Oleme kaalunud alternatiivseid lähenemisviise probleemi lahendamiseks enne QUIC-i valimist.

Esiteks proovisime tõsta TPC PoP-sid (Presence Points), et lõpetada TCP-ühendused lähemal kasutajatele. Tegelikult lõpetab PoP TCP-ühenduse mobiilseadmega lähemal mobiilivõrgule ja suunab liikluse algsele infrastruktuurile. TCP lõpetades lähemal, saame potentsiaalselt vähendada RTT-d ja olla kindlad, et TCP reageerib dünaamilises traadita keskkonnas aktiivsemalt. Siiski, meie katsetused näitasid, et enamasti tulenevad RTT ja kaod mobiilivõrkudest ning PoP-ide kasutamine ei too olulist jõudluse parandust.

Vaatasime ka TCP parameetrite seadmist. TCP-steigi seadmine meie heterogeensetes piiriserverites oli keeruline, kuna TCP-l on erinevates OSimedes võrreldamatud teostused. Erinevate võrgukonfiguratsioonide rakendamine ja testimine oli keeruline. TCP-seadistus mobiilseadmetes oli volituste puudumise tõttu võimatu. Veelgi olulisem on see, et sellised funktsioonid nagu 0-RTT ühendused ja paranenud RTT ennustus on protokolli arhitektuuri jaoks kriitilise tähtsusega ning seetõttu ei saa TCP-seadistusega oluliselt kasu saavutada.

Lõpuks hindasime mitmeid UDP-põhiseid protokolle, mis lahendavad videostreamingu tõrkeid - soovisime teada, kas need protokollid saavad meie olukorras abiks olla. Kahjuks puudusid neis paljuski vajalikud turvaseaded, samuti oli vajalik täiendav TCP-ühendus metaandmete ja haldusinformatsiooni jaoks.

Meie uuringud näitasid, et QUIC on peaaegu ainus protokoll, mis suudab Interneti-liikluse probleemiga tegeleda, arvestades nii turvalisust kui ka jõudlust.

QUICi integreerimine platvormi

QUIC-i edukaks integreerimiseks ja rakenduse jõudluse parandamiseks nõrkades ühendustes asendasime vana steki (HTTP/2 üle TLS/TCP) QUIC-protokolliga. Kasutasime võrgu teeki Cronet API-s Chromium Projects, mis sisaldab originaali, Google'i versioon protokollist – gQUIC. Seda teostust täiustatakse pidevalt, et järgida viimast IETF-i spetsifikatsiooni.

Esmalt integreerisime Croneti oma Android-rakendustesse, et lisada QUIC-i tugi. Integreerimine toimus nii, et migratsioonikulusid oleks võimalikult vähe. Selle asemel, et täielikult asendada vana võrgu steki, mis kasutas teeki OkHttp, integreerisime Croneti OkHttp API raames. Sellise integreerimisega vältisime muudatusi meie võrgu kutsumistes (mida kasutavad Retrofit) API tasemel.

Sarnaselt lähenemisele Android-seadmetele rakendasime Croneti Uberi rakendustes iOS-is, peatades HTTP liikluse võrgu API, kasutades NSURLProtocol. See abstraktsioon, mis on saadud iOS Foundationist, haldab protokollispetsiifilisi URL-andmeid ja tagab, et saame Croneti integreerida oma iOS-rakendustes oluliste migratsioonikuludeta.

QUICi lõpetamine Google Cloudi tasakaalustajates

Tagaküljel tagab QUICi lõpetamise Google Cloudi Load balancing infrastruktuur, mis kasutab alt-svc pealkirjad vastustes QUICi toe toetamiseks. Üldiselt lisab koormuse jagaja iga HTTP-päringule alt-svc pealkirja, mis valideerib QUICi toe domeeni jaoks. Kui Cronet klient saab sellise pealkirjaga HTTP-vastuse, kasutab ta järgmiste HTTP-päringute jaoks QUICi sellele domeenile. Kui koormuse jagaja lõpetab QUICi, edastab meie infrastruktuur selle tegevuse tõeliselt HTTP2/TCP kaudu meie andmekeskustesse.

Toime: tulemused

Välja antud toime on peamine põhjus, miks me otsime parimat protokolli. Alustuseks lõime keskkonna, võrgu simuleerimise, et selgitada välja, kuidas QUIC erinevates võrguprofiilides käitub. QUICi töö kontrollimiseks reaalsetes võrkudes tegime eksperimente, sõitmine New Delhis, kasutades samal ajal simuleeritud võrgu liiklust, mis sarnanes väga rakenduse reisija HTTP-päringutele.

Eksperiment 1

Eksperimendi inventar:

• testseadmed Androidil OkHttp ja Cronet stackidega, et veenduda, et meie HTTPS-liiklus liigub juba vastavalt TCP ja QUIC kaudu;
• Java-põhine simuleerimise server, mis saadab sama tüüpi HTTPS-pealkirjad vastustes ja koormab kliendiseadmeid, et saada neilt päringud;
• pilveproksid, mis on füüsiliselt India lähedal, et lõpetada TCP ja QUIC ühendused. Kõrge TCP lõpetamiseks kasutasime tagasipöörde proksi NGINX, kuid oli keeruline leida avatud lähtekoodiga tagasipöörde proksi QUICile. Me kogusime ise QUICi tagasipöörde proksi, kasutades aluse QUICi steki Chromiumist ja avalikustasid selle Chromiumis kui avatud lähtekoodine.

Joonis 6. TCP vs QUIC testimiseks mõeldud tee komplekt koosnes Android-seadmest OkHttp ja Cronet, pilveproksidest ühenduste lõpetamiseks ja simuleerimise serverist.

Eksperiment 2

Kui Google tegi QUICi kergesti kätte saadavaks, Google Cloud Load Balancing, kasutasime sama inventari, kuid ühe modifikatsiooniga: NGINXi asemel võtsime Google'i koormuse jagajad TCP ja QUIC ühenduste lõpetamiseks seadmetelt ning HTTPS-liikluse suunamiseks simuleerimise serverisse. Koormuse jagajad on jaotatud üle kogu maailma, kuid kasutavad seadmele lähimat PoP serverit (tänu geolokatsioonile).

Joonis 7. Teises eksperimendis soovisime võrrelda TCP ja QUICi lõpetamise viivitust: Google Cloudi ja meie pilveproksi abil.

Kokkuvõttes ootas meid mitu avastust:

• PoP-i kaudu lõpetamine parandas TCP suutlikkust. Kuna tasakaalustajad lõpetavad TCP-ühenduse lähemal kasutajatele ja on suurepäraselt optimeeritud, toob see kaasa väiksemaid RTT-sid, mis parandab TCP jõudlust. Ja kuigi see mõjutas QUIC-i vähem, ületas see ikkagi TCP-d pehmete viivituste vähendamise osas (10–30 protsenti).
• pehmetele viivitustele mõjutavad võrgupunktid (hops). Kuigi meie QUIC-proksi oli seadmetest kaugemal (ligikaudu 50 ms suurem latentsus) kui Google'i tasakaalustajad, näitas see sarnast jõudlust – 15% langus latentsuses võrreldes TCP 99. protsentiili 20% langusega. See näitab, et viimase miili vahetus on võrgu töötluse kitsaskohaks (bottleneck).

Joonis 8. Kahe eksperimendi tulemused näitavad, et QUIC ületab TCP-d märkimisväärselt.

Sõjaline liiklus

Katsed inspireerisid meid rakendama QUIC-i toetust meie Androidi ja iOS-i rakendustes. Viisime läbi A/B testimise, et määrata QUIC-i mõju Uberi kohalikes linnades. Üldiselt nägime märkimisväärset vähenemist pehmetes viivitustes nii piirkondade kui ka telecom operaatorite ning võrgu tüüpide lõikes.

Allpool toodud graafikutel on näidatud protsentuaalsed parandused pehmetes viivitustes (95. ja 99. protsentiil) makrorikides ja erinevates võrgutüüpides – LTE, 3G, 2G.

Joonis 9. Sõjalistes testides ületas QUIC TCP-d latentsuse osas.

Ainult edasi

Tõenäoliselt on see ainult algus – QUIC-i väljatootmine tootmises on andnud hämmastavaid võimalusi rakenduste jõudluse parandamiseks nii stabiilsetes kui ka ebastabiilsetes võrkudes, nimelt:

Katvuse suurenemine

Analüüsides protokolli jõudlust reaalsetes liiklustingimustes, nägime, et ligikaudu 80% sessioonidest kasutasid QUIC-i edukalt kõigi päringute jaoks, samal ajal kui 15% sessioonidest kasutasid nii QUIC-i kui TCP-d. Eeldame, et kombinatsioon tekkis seetõttu, et Croneti teek lülitub ajaülevaate tõttu tagasi TCP-le, kuna ta ei suuda eristada tegelikke UDP-rikkeid ja halbu võrguolusid. Hetkel otsime sellele probleemile lahendust, kuna töötame QUIC-i edasise rakendamise kallal.

QUIC-i optimeerimine

Mobiilirakendustest pärinev liiklus on viivitusolukordadele tundlik, kuid mitte ribalaiusele. Samuti kasutatakse meie rakendusi peamiselt mobiilivõrkudes. Eksperimentide põhjal on sabaviivitused endiselt suured, isegi kui kasutatakse proksit TCP ja QUIC lõpetamiseks lähedal kasutajatele. Otsime aktiivselt viise koormuse juhtimise parandamiseks ja QUIC-i kadu tagasiarvutamise algoritmide efektiivsuse tõstmiseks.

Nende ja teiste täiendustega kavatseme parandada kasutajakogemust sõltumata võrgust ja piirkonnast, muutes pakettide sujuva ja mugava transportimise kergemini kättesaadavaks maailmas.

Allikas: habr.com