Det Ă€r mycket intressant att följa protokollet QUIC, vilket gör att vi gĂ€rna skriver om det. Men medan tidigare publikationer om QUIC har haft en mer historisk (lokalhistorisk, om du sĂ„ vill) karaktĂ€r och handlat om Ă€mnet, Ă€r vi idag glada att publicera en översĂ€ttning av ett annat slag â vi kommer att tala om den verkliga tillĂ€mpningen av protokoll i 2019. Detta handlar inte om en liten infrastruktur baserad i ett hypotetiskt garage, utan om Uber, som opererar nĂ€stan över hela vĂ€rlden. Hur företagsingenjörerna kom fram till beslutet att anvĂ€nda QUIC i produktion, hur tester utfördes och vad de sĂ„g efter utrullningen i produktion â lĂ€s vidare.
Bilderna Àr klickbara. Trevlig lÀsning!
Uber representerar en global skala, med nĂ€rvaro i 600 stĂ€der, dĂ€r varje applikation helt litar pĂ„ trĂ„dlöst internet frĂ„n mer Ă€n 4500 mobiloperatörer. AnvĂ€ndarna förvĂ€ntar sig att applikationen fungerar inte bara snabbt, utan i realtid â för att möjliggöra detta behöver Uber-applikationen lĂ„ga fördröjningar och en mycket pĂ„litlig anslutning. TyvĂ€rr fungerar inte bra i dynamiska och förlustbenĂ€gna trĂ„dlösa nĂ€tverk. Vi har insett att i detta fall Ă€r den lĂ„ga prestandan direkt relaterad till TCP-implementationerna i operativsystemens kĂ€rnor.
För att lösa problemet anvÀnde vi , ett modernt protokoll med kanalmultiplexering, vilket ger oss mer kontroll över prestandan hos transportprotokollet. För nÀrvarande standardiserar arbetsgruppen QUIC som .
Efter detaljerade tester kom vi fram till slutsatsen att implementeringen av QUIC i vĂ„r applikation minskar "tail"-fördröjningar jĂ€mfört med TCP. Vi observerade en minskning pĂ„ 10â30% för HTTPS-trafik i exempelvis förar- och passagerarapplikationer. Dessutom gav QUIC oss fullstĂ€ndig kontroll över anvĂ€ndarpaketen.
I denna artikel delar vi erfarenheter av att optimera TCP för Uber-applikationer med hjÀlp av ett stack som stöder QUIC.
Den senaste tekniken: TCP
Idag Àr TCP den mest anvÀnda transportprotokollet för att leverera HTTPS-trafik pÄ internet. TCP sÀkerstÀller en pÄlitlig ström av bytes och hanterar dÀrmed nÀtverksöverbelastning och förluster pÄ kanallagret. Den omfattande anvÀndningen av TCP för HTTPS-trafik kan förklaras av dess allestÀdes nÀrvaro (nÀstan varje operativsystem innehÄller TCP), tillgÀngligheten pÄ större delen av infrastrukturen (t.ex. pÄ belastningsfördelare, HTTPS-proxi och CDN) samt dess funktionalitet "ur lÄdan", som Àr tillgÀnglig nÀstan pÄ alla plattformar och nÀtverk.
De flesta anvĂ€ndare anvĂ€nder vĂ„r app i farten, och de "svansförseningar" som TCP har har varit lĂ„ngt ifrĂ„n kraven för vĂ„r realtids HTTPS-trafik. Enkelt uttryckt, detta har drabbat anvĂ€ndare över hela vĂ€rlden â Daigram 1 visar fördröjningar i stora stĂ€der:
Diagram 1. Storleken pÄ "svansförseningar" varierar i de viktigaste stÀder dÀr Uber Àr nÀrvarande.
Trots att fördröjningarna i indiska och brasilianska nÀtverk var högre Àn i USA och Storbritannien, var svansfördröjningarna avsevÀrt större Àn de genomsnittliga fördröjningarna. Och sÄ Àr det Àven för USA och Storbritannien.
TCP-prestanda över luft.
TCP skapades för trÄdbundna nÀtverk, dvs. med fokus pÄ vÀl förutsÀgbara lÀnkar. Men trÄdlösa nÀtverk har sina egna sÀrdrag och svÄrigheter. För det första Àr trÄdlösa nÀtverk kÀnsliga för förluster pÄ grund av störningar och signaldÀmpning. Till exempel Àr Wi-Fi-nÀtverk kÀnsliga för mikrovÄgor, bluetooth och andra radiovÄgor. MobilnÀt lider av signalförlust () pÄ grund av reflexion/absorption av signaler frÄn föremÄl och byggnader samt av frÄn nÀrliggande Detta leder till betydligt större (4-10 gÄnger) och mer varierade och paketförluster jÀmfört med trÄdbundna anslutningar.
För att hantera fluktuationer i bandbredd och förluster anvÀnder mobilnÀt vanligtvis stora buffrar för trafiktoppar. Detta kan leda till överdriven köbildning, vilket innebÀr större fördröjningar. Mycket ofta tolkar TCP sÄdan köbildning som förlust pÄ grund av en ökad timeout, vilket gör att TCP tenderar att omförsÀnda och dÀrmed fylla buffern. Detta problem Àr kÀnt som (), och detta Àr ett mycket den moderna internet.
Ăntligen varierar prestandan för mobilnĂ€t beroende pĂ„ operatör, region och tidpunkt. I Figur 2 har vi samlat medianfördröjningar för HTTPS-trafik över celler inom ett avstĂ„nd av 2 kilometer. Data har samlats in för tvĂ„ av de största mobiloperatörerna i Delhi, Indien. Som kan noteras varierar prestandan mellan cell till cell. Dessutom skiljer sig en operatörs prestanda frĂ„n den andra. Detta pĂ„verkas av faktorer som nĂ€tverksinloggningsmönster med hĂ€nsyn till tid och plats, anvĂ€ndarnas rörlighet samt nĂ€tverksinfrastruktur med avseende pĂ„ masttĂ€thet och förhĂ„llandet mellan nĂ€tverkstyper (LTE, 3G etc.).
Figur 2. Fördröjningar med exempel frÄn ett 2-kilometers radiushÄll. Delhi, Indien.
Prestandan för mobilnÀt varierar ocksÄ över tid. I Figur 3 visas medianfördröjningen per veckodag. Vi noterade ocksÄ skillnader i mindre skala - inom samma dag och timme.
Figur 3. Svansfördröjningar kan variera avsevÀrt mellan olika dagar, Àven för samma operatör.
Allt ovanstÄende leder till att TCP-prestanda Àr ineffektiv i trÄdlösa nÀtverk. Innan vi söker alternativ till TCP ville vi dock utveckla en exakt förstÄelse för följande punkter:
- Àr TCP den huvudsakliga orsaken till svansfördröjningar i vÄra applikationer?
- Har moderna nÀt verk betydande och varierande rundresor (RTT)?
- Vad Àr pÄverkan av RTT och förluster pÄ TCP-prestanda?
Analys av TCP-prestanda
För att förstÄ hur vi analyserade TCP-prestanda, lÄt oss kort pÄminna oss om hur TCP överför data frÄn avsÀndaren till mottagaren. Först upprÀttar avsÀndaren en TCP-anslutning genom att utföra en trevÀgs : avsÀndaren skickar en SYN-paket, vÀntar pÄ SYN-ACK-paket frÄn mottagaren och skickar sedan ett ACK-paket. Ytterligare andra och tredje genomgÄngar krÀvs för att skapa en TCP-anslutning. Mottagaren bekrÀftar mottagandet av varje paket (ACK) för att sÀkerstÀlla pÄlitlig leverans.
Om ett paket eller en ACK gÄr förlorad gör avsÀndaren en retransmission efter en tidsutgÄng (RTO, ). RTO berÀknas dynamiskt baserat pÄ olika faktorer, exempelvis pÄ den förvÀntade RTT-fördröjningen mellan avsÀndaren och mottagaren.
Figur 4. Paketutbyte över TCP/TLS inkluderar retransmissionsmekanismer.
För att avgöra hur TCP fungerade i vÄra applikationer spÄrade vi TCP-paket med hjÀlp av under en vecka pÄ verklig trafik som kom frÄn indiska grÀnsservrar. DÀrefter analyserade vi TCP-anslutningarna med hjÀlp av . Dessutom skapade vi en Android-app som skickade emulerad trafik till en testserver, maximalt efterliknande verklig trafik. Smartphones med denna app delades ut till flera anstÀllda, som samlade loggar under flera dagar.
Resultaten frÄn bÄda experimenten stÀmde överens med varandra. Vi sÄg höga RTT-fördröjningar; tail-vÀrdena var nÀstan 6 gÄnger högre Àn medianvÀrdet; det aritmetiska medelvÀrdet för fördröjningar var över 1 sekund. MÄnga anslutningar hade paketförluster, vilket fick TCP att retransmittera 3,5% av alla paket. I omrÄden med överbelastning, som flygplatser och jÀrnvÀgsstationer, övervakade vi 7%-iga förluster. Dessa resultat ifrÄgasÀtter den utbredda uppfattningen att de avancerade retransmissionsscheman som anvÀnds i mobilnÀt Nedan följer testresultat frÄn simulering-appen:
NĂ€tverksmetrik
VĂ€rden
RTT, millisekunder [50%, 75%, 95%, 99%]
[350, 425, 725, 2300]
RTT-varians, sekunder
I genomsnitt ~1,2 s
Paketförlust vid instabila anslutningar
I genomsnitt ~3,5% (7% i omrÄden med överbelastning)
NÀstan hÀlften av dessa anslutningar hade minst en paketförlust, frÀmst SYN- och SYN-ACK-paket. De flesta TCP-implementationer anvÀnder ett RTO-vÀrde pÄ 1 sekund för SYN-paket, vilket ökar exponentiellt för efterföljande förluster. Laddningstiden för applikationen kan öka pÄ grund av att TCP behöver mer tid för att etablera anslutningar.
I fallet med datapaket, minskar höga RTO-vÀrden starkt den nyttiga utnyttjandegraden av nÀtverket vid temporÀra förluster i trÄdlösa nÀtverk. Vi fann att det genomsnittliga retransmissionstiden Àr cirka 1 sekund med en tail-fördröjning pÄ nÀstan 30 sekunder. Dessa höga fördröjningar pÄ TCP-nivÄ orsakade HTTPS-timeouts och Äterkommande förfrÄgningar, vilket ytterligare ökade fördröjningen och ineffektiviteten i nÀtverket.
Medan 75:e percentilen av de uppmÀtta RTT var omkring 425 ms, var 75:e percentilen för TCP nÀstan 3 sekunder. Detta antyder att förluster tvingade TCP att göra 7-10 försök för att framgÄngsrikt överföra data. Detta kan bero pÄ en ineffektiv RTO-berÀkning och TCP:s oförmÄga att snabbt reagera pÄ förluster. i fönstret och ineffektiviteten i algoritmen för överbelastningskontroll, som inte sÀrskiljer mellan trÄdlösa förluster och förluster pÄ grund av nÀtverksöverbelastning. Nedan presenteras resultaten av TCP-förlusttester:
Statistik över TCP-förluster
VĂ€rde
Andel anslutningar med minst 1 paketförlust
45%
Andel anslutningar med förluster under anslutningsetableringen
30%
Andel anslutningar med förluster under datacommunication
76%
Fördelning av fördröjningar vid retransmission, sekunder [50%, 75%, 95%, 99%]
[1, 2.8, 15, 28]
Fördelning av antalet retransmissioner för ett paket eller TCP-segment
[1,3,6,7]
AnvÀndning av QUIC
Ursprungligen designad av Google, Ă€r QUIC ett flödande modernt transportprotokoll som fungerar över UDP. För tillfĂ€llet Ă€r QUIC i (vi har redan skrivit att det finns i princip tvĂ„ versioner av QUIC, nyfikna â anm. översĂ€ttaren). Som visas i Figur 5, Ă€r QUIC placerad under HTTP/3 (i sjĂ€lva verket Ă€r HTTP/2 över QUIC vad som utgör HTTP/3, som nu genomgĂ„r intensiv standardisering). Den delvis ersĂ€tter HTTPS- och TCP-nivĂ„erna genom att anvĂ€nda UDP för paketstruktur. QUIC stödjer endast sĂ€ker dataöverföring, eftersom TLS Ă€r helt integrerat i QUIC.
Figur 5: QUIC fungerar under HTTP/3, vilket ersÀtter TLS som tidigare fungerade under HTTP/2.
Nedan listar vi anledningarna som övertygade oss om att anvÀnda QUIC för att stÀrka TCP:
- 0-RTT för att upprÀtta anslutning. QUIC möjliggör ÄteranvÀndning av auktoriseringar frÄn tidigare anslutningar, vilket minskar antalet sÀkerhets-handskaks. I framtiden att stödja 0-RTT, men den trevÀgs TCP-handshaken kommer fortfarande att vara obligatorisk.
- överbrygga HoL-blockering. HTTP/2 anvÀnder en enda TCP-anslutning för varje klient för att förbÀttra prestandan, men detta kan leda till HoL (head-of-line) blockering. QUIC förenklar multiplexering och levererar begÀrningar till applikationen oberoende av varandra.
- överbelastningskontroll. QUIC fungerar pÄ applikationsnivÄ, vilket möjliggör enklare uppdateringar av den huvudsakliga transportalgoritmen som hanterar sÀndningen baserat pÄ nÀtverksparametrar (antal paketförluster eller RTT). De flesta TCP-implementationer anvÀnder algoritmen , som inte Àr optimal för trafik som Àr kÀnslig för fördröjningar. Nyutvecklade algoritmer som , modellerar nÀtet mer exakt och optimerar fördröjningar. QUIC möjliggör anvÀndning av BBR och uppdatering av denna algoritm i takt med att den .
- förluster. QUIC Ă„beropar tvĂ„ TLP () innan RTO aktiveras â Ă€ven nĂ€r förluster Ă€r mycket mĂ€rkbara. Detta skiljer sig frĂ„n TCP-implementationer. TLP retransmitterar huvudsakligen det senaste paketet (eller ett nytt, om det finns) för att initiera snabb Ă„tervinning. Hantering av svansfördröjningar Ă€r sĂ€rskilt nyttig för hur Uber arbetar med nĂ€tverket, sĂ€rskilt för korta, episodiska och fördröjningskĂ€nsliga datatransmissioner.
- optimerad ACK. Eftersom varje paket har ett unikt sekvensnummer uppstÄr inget problem med av paket vid deras retransmission. ACK-paket innehÄller ocksÄ tidsstÀmplar för processering av paketet och generering av ACK pÄ klientsidan. Dessa funktioner sÀkerstÀller att QUIC noggrant berÀknar RTT. ACK i QUIC stöder upp till 256 omrÄden , vilket hjÀlper avsÀndaren att vara mer motstÄndskraftig mot paketomkastning och anvÀnda fÀrre byte i processen. Selective ACK () i TCP löser inte detta problem i alla fall.
- anslutningsmigrering. QUIC-anslutningar identifieras med hjÀlp av ett 64-bits ID, vilket gör att om klienten byter IP-adresser kan ID för den gamla anslutningen anvÀndas vidare pÄ den nya IP-adressen utan avbrott. Detta Àr en mycket vanlig praxis för mobilapplikationer nÀr anvÀndaren vÀxlar mellan Wi-Fi och mobila anslutningar.
Alternativ till QUIC
Vi övervÀgde alternativa tillvÀgagÄngssÀtt för att lösa problemet innan vi valde QUIC.
Först försökte vi implementera TPC PoPs (Points of Presence) för att avsluta TCP-anslutningar nÀrmare anvÀndarna. I grunden avslutar PoPs TCP-anslutningen med den mobila enheten nÀrmare mobilnÀtet och mellanlagrar trafiken till den ursprungliga infrastrukturen. Genom att avsluta TCP nÀrmare kan vi potentiellt minska RTT och vara sÀkra pÄ att TCP kommer att reagera mer aktivt pÄ den dynamiska trÄdlösa miljön. VÄra experiment visade dock att mestadels RTT och förluster kommer frÄn mobilnÀten, och anvÀndningen av PoPs ger inte en betydande prestandaförbÀttring.
Vi har ocksĂ„ tittat pĂ„ att justera TCP-parametrarna. Att konfigurera TCP-stacken pĂ„ vĂ„ra heterogena grĂ€nsservrar var svĂ„rt, eftersom TCP har oöverensstĂ€mmande implementationer i olika versioner av operativsystemet. Det var svĂ„rt att implementera och testa olika nĂ€tverkskonfigurationer. Att justera TCP direkt pĂ„ mobila enheter var omöjligt pĂ„ grund av bristande behörighet. Ănnu viktigare Ă€r att funktioner som 0-RTT-anslutningar och förbĂ€ttrad RTT-prediktion Ă€r kritiska för protokollarkitekturen och dĂ€rför Ă€r det omöjligt att uppnĂ„ betydande fördelar enbart genom att justera TCP.
Till slut utvĂ€rderade vi nĂ„gra UDP-baserade protokoll som Ă„tgĂ€rdar problem i videoströmning â vi ville ta reda pĂ„ om dessa protokoll skulle hjĂ€lpa i vĂ„rt fall. TyvĂ€rr saknades dessa avsevĂ€rt mĂ„nga sĂ€kerhetsinstĂ€llningar, och det krĂ€vdes ocksĂ„ en extra TCP-anslutning för metadata och styrinformation.
VÄra undersökningar visade att QUIC Àr det enda protokollet som kan hjÀlpa med problemet med internettrafik, samtidigt som det tar hÀnsyn till bÄde sÀkerhet och prestanda.
Integrering av QUIC i plattformen
För att framgĂ„ngsrikt integrera QUIC och förbĂ€ttra applikationens prestanda under dĂ„liga anslutningar, bytte vi ut den gamla stacken (HTTP/2 över TLS/TCP) mot protokollet QUIC. Vi anvĂ€nde det nĂ€tverksbiblioteket frĂ„n , som innehĂ„ller den ursprungliga Google-versionen av protokollet â gQUIC. Denna implementation förbĂ€ttras ocksĂ„ stĂ€ndigt för att följa den senaste IETF-specifikationen.
Först integrerade vi Cronet i vÄra Android-appar för att lÀgga till stöd för QUIC. Integrationen genomfördes pÄ ett sÀtt som minimerade migrationskostnaderna. IstÀllet för att helt ersÀtta den gamla nÀtverksstacken, som anvÀnde biblioteket , integrerade vi Cronet UNDER OkHttp API-ramverket. Genom att utföra integrationen pÄ detta sÀtt undvek vi förÀndringar i vÄra nÀtverksanrop (som anvÀnder ) pÄ API-nivÄ.
PÄ liknande sÀtt som för Android-enheter implementerade vi Cronet i Uber-apparna pÄ iOS, genom att avlyssna HTTP-trafiken frÄn nÀtverks , med hjÀlp av . Denna abstraktion, som tillhandahÄlls av iOS Foundation, hanterar protokollspecifika URL-data och sÀkerstÀller att vi kan integrera Cronet i vÄra iOS-appar utan betydande migrationskostnader.
QUIC-avslutning pÄ Google Cloud Load balancers
PÄ backsidan möjliggör Google Cloud Load balancing-infrastrukturen QUIC-avslutning, som anvÀnder rubriker i svaren för att stödja QUIC. I allmÀnhet lÀgger lastbalanseraren till en alt-svc-rubrik i varje HTTP-förfrÄgan och validerar dÀrmed stöd för QUIC för domÀnen. NÀr klienten Cronet fÄr ett HTTP-svar med en sÄdan rubrik, anvÀnder den QUIC för efterföljande HTTP-förfrÄgningar till denna domÀn. SÄ snart lastbalanseraren avslutar QUIC, skickar vÄr infrastruktur detta ÄtgÀrd tydligt via HTTP2/TCP till vÄra datacenter.
Prestanda: resultat
Den uppnÄdda prestandan Àr den frÀmsta anledningen till vÄr strÀvan efter den bÀsta protokollen. För att börja skapade vi en uppstÀllning med , för att ta reda pÄ hur QUIC skulle fungera under olika nÀtverksprofiler. För att testa QUIC:s prestanda i verkliga nÀtverk genomförde vi experiment genom att Äka runt i New Delhi, dÀr vi anvÀnde emulerad nÀtverkstrafik som liknade HTTP-anrop i passagerarapplikationen.
Experiment 1
Inventarielista för experimentet:
- testenheter pÄ Android med OkHttp- och Cronet-stacken, för att sÀkerstÀlla att vi skickar HTTPS-trafik över TCP och QUIC respektive;
- Java-baserad emuleringsserver som skickar identiska HTTPS-rubriker i svaren och belastar klientenheter för att ta emot deras förfrÄgningar;
- molnbaserade proxyer som fysiskt ligger nÀra Indien för att avsluta TCP- och QUIC-anslutningar. Medan vi anvÀnde en omvÀnd proxy för att avsluta TCP , det var svÄrt att hitta en öppen kÀllkod omvÀnd proxy för QUIC. Vi byggde en omvÀnd proxy för QUIC sjÀlva, med hjÀlp av den grundlÀggande QUIC-stacken frÄn Chromium och den i Chromium som öppen kÀllkod.
Figur 6. TestuppsÀttningen för TCP vs QUIC bestod av Android-enheter med OkHttp och Cronet, molnproxyer för att avsluta anslutningar och en emulatorserver.
Experiment 2
NÀr Google gjorde QUIC tillgÀngligt via , anvÀnde vi samma inventarie, men med en modifiering: istÀllet för NGINX, tog vi Googles lastbalanserare för att avsluta TCP- och QUIC-anslutningar frÄn enheterna samt för att dirigera HTTPS-trafik till emulatorservern. Lastbalanserarna Àr spridda över hela vÀrlden, men anvÀnder den nÀrmaste PoP-servern (tack vare geolokalisering).
Figur 7. I det andra experimentet ville vi jÀmföra latensen i avslutningen av TCP och QUIC: med hjÀlp av Google Cloud och med vÄrt molnproxy.
I slutet hade vi flera avslöjanden:
- avslutningen genom PoP förbÀttrade prestandan för TCP. Eftersom lastbalanserarna avslutar TCP-anslutningen nÀrmare anvÀndarna och Àr utmÀrkt optimerade ger detta lÀgre RTT, vilket förbÀttrar TCP: s prestanda. Och Àven om QUIC pÄverkades mindre, övertrÀffade det fortfarande TCP nÀr det gÀllde att minska svanslatensen (med 10-30 procent).
- svansarna pĂ„verkas av . Ăven om vĂ„r QUIC-proxy var lĂ€ngre bort frĂ„n enheterna (latens ungefĂ€r 50 ms högre) Ă€n Googles lastbalanserare, uppvisade den liknande prestanda â 15% minskning av latens jĂ€mfört med 20% minskning i 99:e percentilen för TCP. Detta tyder pĂ„ att övergĂ„ngen pĂ„ sista milen Ă€r flaskhalsen i nĂ€tverkets funktion.
Figur 8. Resultaten frÄn de tvÄ experimenten visar att QUIC överlÀgset övertrÀffar TCP.
Stridstrafik
Inspirerade av experimenten införde vi stöd för QUIC i vÄra Android- och iOS-appar. Vi genomförde A/B-testning för att bestÀmma effekten av QUIC i stÀder dÀr Uber Àr verksam. Generellt sett sÄg vi en betydande minskning av svanslatensen över bÄde regioner och operatörer samt nÀtverkstyper.
I graferna nedan visas procentuella förbĂ€ttringar av svansarna (95 och 99 percentiler) över makroregioner och olika nĂ€tverkstyper â LTE, 3G, 2G.
Figur 9. I stridstestade QUIC övertrÀffade TCP avseende latens.
Endast framÄt
Det hĂ€r Ă€r förmodligen bara början â införandet av QUIC i produktion har gett fantastiska möjligheter att förbĂ€ttra applikationsprestanda bĂ„de i stabila och instabila nĂ€tverk, nĂ€mligen:
Ăkad tĂ€ckning
Genom att analysera protokollets prestanda pÄ verklig trafik sÄg vi att ungefÀr 80% av sessionerna framgÄngsrikt anvÀnde QUIC för alla förfrÄgningar, medan 15% av sessionerna anvÀnde en kombination av QUIC och TCP. Vi misstÀnker att denna kombination uppstod eftersom Cronet-biblioteket vÀxlar tillbaka till TCP vid time-out, eftersom det inte kan sÀrskilja verkliga UDP-fel frÄn dÄliga nÀtverksförhÄllanden. Vi söker nu en lösning pÄ detta problem, eftersom vi arbetar med nÀsta implementering av QUIC.
Optimering av QUIC
Trafiken frÄn mobilapplikationer Àr kÀnslig för fördröjningar men inte för bandbredd. VÄra applikationer anvÀnds frÀmst i mobilnÀt. Baserat pÄ experiment visar det sig att svansfördröjningar fortfarande Àr stora, Àven med hjÀlp av proxies som avslutar TCP och QUIC nÀra anvÀndarna. Vi letar aktivt efter sÀtt att förbÀttra överbelastningshanteringen och öka effektiviteten hos QUIC-algoritmer för förlustkompensering.
Med dessa och nÄgra andra förbÀttringar planerar vi att förbÀttra anvÀndarupplevelsen oavsett nÀtverk och region, genom att göra en smidig och anvÀndarvÀnlig pakettransport mer tillgÀnglig över hela vÀrlden.
KĂ€lla: habr.com
