A QUIC protokollal rendkívül érdekes foglalkozni, ezért szívesen írunk róla. De míg a korábbi publikációk a QUIC-ről inkább történelmi (helyismereti, ha úgy tetszik) jellegűek voltak, ma örömmel tesszük közzé egy másfajta fordítást - a protokoll 2019-es valódi alkalmazásáról fogunk beszélni. Ráadásul nem egy kis infrastruktúráról van szó, amely egy képzeletbeli garázsban működik, hanem az Uberről, amely szinte az egész világban jelen van. Hogyan döntöttek a cég mérnökei a QUIC használata mellett a termelésben, hogyan végezték a teszteket, és mit tapasztaltak a bevezetés után - mindez a cikk további részében.
A képek kattinthatók. Kellemes olvasást!
Az Uber egy globális szint, amely pontosan 600 városban van jelen, ahol az alkalmazás teljes mértékben a több mint 4500 mobilszolgáltató vezeték nélküli internetére támaszkodik. A felhasználók elvárják, hogy az alkalmazás ne csak gyorsan működjön, hanem valós időben, és ennek biztosításához az Uber alkalmazásának alacsony késleltetésre és nagyon megbízható kapcsolatra van szüksége. Sajnos a TCP megvalósításai nem teljesítettek jól a dinamikus és veszteséges vezeték nélküli hálózatokban. Megértettük, hogy ebben az esetben az alacsony teljesítmény közvetlenül összefügg a TCP megvalósításaival az operációs rendszerek magjában.
A probléma megoldására , modern protokollt alkalmaztunk, amely csatornák multiplexelését teszi lehetővé, és nagyobb ellenőrzést biztosít a szállító protokoll teljesítménye felett. Jelenleg a munkacsoport standardizálja a QUIC-ot mint .
Részletes tesztelés után arra a következtetésre jutottunk, hogy a QUIC bevezetése az alkalmazásunkban csökkenti a "finom" késleltetéseket a TCP-hez képest. 10-30%-os csökkenést tapasztaltunk az HTTPS-forgalomban a sofőr- és az utasalkalmazások példáján. A QUIC emellett teljes ellenőrzést adott számunkra a felhasználói csomagok felett.
Ebben a cikkben megosztjuk tapasztalatainkat a TCP optimalizálásáról az Uber alkalmazások számára a QUIC-ot támogató stack segítségével.
Legújabb technológia: TCP
Ma a TCP a legelterjedtebb szállítási protokoll az HTTPS-forgalom internetes szállításához. A TCP megbízható bájtáramlást biztosít, így kezeli a hálózati túlterhelést és a csatorna szintű veszteségeket. A TCP széles körű használatát az HTTPS-forgalomhoz az magyarázza, hogy szinte minden operációs rendszer rendelkezik TCP-vel, a legtöbb infrastruktúrában elérhető (például terheléselosztók, HTTPS-proxyk és CDN-ek esetén), és az „alapból” funkciói szinte a legtöbb platformon és hálózaton elérhetők.
A felhasználók többsége útközben használja az alkalmazásunkat, és a TCP „farok” késedelmei messze voltak a valós idejű HTTPS-forgalom követelményeitől. Egyszerűen fogalmazva, ezzel világszerte találkoztak a felhasználók – az 1. ábrán az átlagos késedelmek láthatók nagy városokban:
1. ábra. A „farok” késedelmek mértéke változik az Uber jelenlétének fő városaiban.
Annak ellenére, hogy az indiai és brazil hálózatok késedelmei magasabbak voltak, mint az Egyesült Államokban és az Egyesült Királyságban, a farok késedelmek lényegesen nagyobbak, mint az átlagos késedelmek. Ez így van az Egyesült Államokban és az Egyesült Királyságban is.
TCP teljesítménye vezeték nélküli kapcsolaton
A TCP-t arra tervezték, hogy vezetékes hálózatok, azaz jól előrejelezhető hivatkozásokra helyezve a hangsúlyt. A vezeték nélküli hálózatoknak azonban megvannak a saját sajátosságaik és nehézségeik. Először is, a vezeték nélküli hálózatok érzékenyek a jelek elvesztésére a zavarok és a jel csillapítása miatt. Például a Wi-Fi hálózatokat érzékenyen érinti a mikrohullámú sütő, a bluetooth és más rádióhullámok. A mobilhálózatok jelveszteségtől szenvednek () a jelek visszaverődése / elnyelése miatt tárgyak és épületek által, valamint a szomszédos . Ez lényeges (4-10-szeres) és változatosabb és csomagvesztésekkel jár, mint a vezetékes kapcsolatok.
A sávszélesség ingadozásainak és a veszteségeknek a leküzdése érdekében a mobilhálózatok általában nagyobb puffereket használnak a forgalmi csúcsokhoz. Ez túlzott sorbaállításhoz vezethet, ami nagyobb késedelmeket jelent. Nagyon gyakran a TCP ilyen sorbaállítást veszteségként értelmez a megnövekedett időtúllépés miatt, ezért a TCP hajlamos retranszmissziót végezni, így kitöltve a puffert. Ez a probléma ismert mint (), és ez egy nagyon a modern internetről.
Végre a mobilhálózat teljesítménye az szolgáltatótól, régiótól és időtől függően változik. A 2. ábrán az HTTPS-forgalom medián késéseit gyűjtöttük össze mobilállomások esetén 2 kilométeres távolságra. Az adatok a legnagyobb két mobilszolgáltatótól származnak Delhiben, Indiában. Ahogy látható, a teljesítmény állomásról állomásra változik. Továbbá az egyes szolgáltatók teljesítménye is eltér egymástól. Ezt befolyásolják a hálózati belépési minták az idő és hely függvényében, a felhasználók mobilitása, valamint a hálózati infrastruktúra a tornyok sűrűsége és a hálózattípusok (LTE, 3G stb.) aránya tekintetében.
2. ábra. Késések 2 kilométeres körzet példáján. Delhi, India.
A mobilhálózatok teljesítménye az időben is változik. A 3. ábra a heti napok közötti medián késleltetést mutatja. Korábban kisebb skálán is megfigyeltük a különbségeket – egy napon és egy órán belül.
3. ábra. A végső késések jelentősen változhatnak a különböző napokon, de ugyanazon szolgáltató esetében.
Mindez oda vezet, hogy a TCP teljesítménye nem hatékony vezeték nélküli hálózatokban. Mielőtt alternatívákat keresnénk a TCP-vel szemben, pontos megértést akartunk kialakítani a következő pontokban:
- a TCP a fő okozója a végső késéseknek alkalmazásainkban?
- Van-e a modern hálózatoknak jelentős és változatos körtartamú késleltetése (RTT)?
- Miképpen hat a RTT és a veszteségek a TCP teljesítményére?
A TCP teljesítményének elemzése
Ahhoz, hogy megértsük, miként elemezzük a TCP teljesítményét, emlékezzünk vissza röviden arra, hogyan továbbítja a TCP az adatokat a küldőtől a címzettig. Először a küldő TCP kapcsolatot létesít, elvégezve a háromlépcsős : a küldő SYN-csomagot küld, várja a SYN-ACK-csomagot a címzettől, majd elküldi az ACK-csomagot. A további második és harmadik átjárók a TCP kapcsolat létrehozására mennek el. A címzett megerősíti az egyes csomagok megérkezését (ACK) a megbízható kézbesítés érdekében.
Ha egy csomag vagy az ACK elveszik, a küldő újraküldi azt a beállított időtúllépés után (RTO, ). Az RTO dinamikusan, különböző tényezők alapján számítódik ki, például a küldő és a címzett közötti várt RTT késlekedés alapján.
4. ábra. A TCP/TLS csomagok cseréje retranszmissziós mechanizmusokat tartalmaz.
Annak megértésére, hogy a TCP hogyan működött alkalmazásainkban, nyomon követtük a TCP-csomagokat egy héten át a valós forgalomban, amely az indiai határos szerverekről érkezett. Ezután elemeztük a TCP-kapcsolatokat . Emellett létrehoztunk egy Android-alkalmazást, amely szimulált forgalmat küld a tesztszerverre, a valós forgalmat maximálisan utánzó módon. Ezt az alkalmazást néhány munkatársnak osztottuk ki, akik napokig gyűjtötték a naplókat.
A két kísérlet eredményei összhangban voltak egymással. Magas RTT késleltetéseket tapasztaltunk; a tail értékek majdnem 6-szorosan felülmúlták a mediánt; az átlagos késleltetés több mint 1 másodperc volt. Sok kapcsolatnál csomagvesztés lépett fel, ami a TCP-t arra kényszerítette, hogy a csomagok 3,5%-át retranszmittálja. A zsúfolt területeken, mint például a repülőterek és pályaudvarok, 7%-os csomagvesztést tapasztaltunk. Ezek az eredmények megkérdőjelezik azt a széles körben elterjedt véleményt, hogy a mobilhálózatokban használt jelentősen csökkentik a szállítási szintű veszteségeket. Az alábbiakban a szimulátor alkalmazás teszteredményei láthatók:
Hálózati metrikák
Értékek
RTT, milliszekundum [50%, 75%, 95%, 99%]
[350, 425, 725, 2300]
RTT eltérés, másodperc
Átlagosan ~1,2 s
Csomagvesztés instabil kapcsolatokban
Átlagosan ~3,5% (7% zsúfolt területeken)
Ezeknek a kapcsolatoknak majdnem felében legalább egy csomagvesztés történt, leggyakrabban SYN és SYN-ACK csomagok voltak. A TCP legtöbb megvalósítása 1 másodperces RTO értéket használ a SYN csomagokhoz, amely exponenciálisan növekszik a későbbi veszteségekhez. Az alkalmazás betöltési ideje megnőhet, mivel a TCP-nak több időre van szüksége a kapcsolatok létrehozásához.
Adatcsomagok esetén a magas RTO értékek jelentősen csökkentik a hálózat hasznos kihasználtságát ideiglenes veszteségek esetén vezeték nélküli hálózatokban. Megállapítottuk, hogy az átlagos retranszmitálási idő körülbelül 1 másodperc volt, a tail késleltetéssel majdnem 30 másodperccel. Ezek a magas TCP szintű késleltetések HTTPS időtúllépéseket és újrakéréseket okoztak, ami tovább növelte a késleltetést és a hálózat hatékonyságát.
Miközben a mért RTT 75. percentilje körülbelül 425 ms volt, a TCP 75. percentilje majdnem 3 másodperc. Ez arra utal, hogy a csomagveszteségek miatt a TCP 7-10 átvitelre volt szükség a sikeres adatátvitelhez. Ez a RTO nem hatékony kiszámításának következménye lehet, amely megnehezíti a TCP gyors reakcióját a veszteségekre. az ablakban és a túlterhelés-vezérlő algoritmus hatékonyságának hiánya, amely nem különbözteti meg a vezeték nélküli veszteségeket a hálózati túlterhelésből adódóktól. Az alábbiakban a TCP csomagveszteségekkel kapcsolatos tesztelési eredmények találhatók:
A TCP csomagveszteség statisztikái
Value
A kapcsolatok százaléka, ahol legalább 1 csomagveszteség történt
45%
A kapcsolatok százaléka, ahol veszteség történt a kapcsolódási folyamat során
30%
A kapcsolatok százaléka, ahol veszteség történt az adatok átvitele közben
76%
A késések eloszlása az újraküldések során, másodperc [50%, 75%, 95%, 99%]
[1, 2.8, 15, 28]
Az újraküldések számának eloszlása egy csomag vagy TCP szegmens számára
[1,3,6,7]
A QUIC alkalmazása
Eredetileg a Google által tervezett QUIC egy modern, мультипоточный szállítási protokoll, amely az UDP fölött működik. Jelenleg a QUIC (már írtunk arról, hogy kvázi két verzió létezik a QUIC-ből, a kíváncsiak – a szerkesztő megjegyzése). Ahogy az 5. ábrán látható, a QUIC az HTTP/3 alatt helyezkedik el (gyakorlatilag a HTTP/2 a QUIC alatt – ez a HTTP/3, ami most intenzíven standardizálva van). Részben felváltja a HTTPS és TCP szinteket, és az UDP-t használja a csomagok formázására. A QUIC csak biztonságos adatátvitelt támogat, mivel a TLS teljesen be van építve a QUIC-be.
5. ábra: A QUIC az HTTP/3 alatt működik, felváltva a TLS-t, amely korábban az HTTP/2 alatt működött.
Az alábbiakban felsoroljuk azokat az okokat, amelyek meggyőztek minket arról, hogy a QUIC-ot a TCP megerősítésére használjuk:
- 0-RTT kapcsolatfelvétel. A QUIC lehetővé teszi a korábbi kapcsolatokból származó hitelesítések újbóli felhasználását, csökkentve a biztonsági kézfogások számát. A jövőben támogatni fogja a 0-RTT-t, azonban a háromoldalú TCP kézfogás továbbra is kötelező lesz.
- a HoL blokád leküzdése. A HTTP/2 egyetlen TCP kapcsolatot használ minden egyes kliens számára a teljesítmény javítása érdekében, de ez HoL (head-of-line) blokádhoz vezethet. A QUIC leegyszerűsíti a multiplexelést, és lehetővé teszi, hogy a kérések függetlenül érkezzenek az alkalmazásba.
- túlterhelés-vezérlés. A QUIC az alkalmazási szinten működik, lehetővé téve a fő szállítási algoritmus egyszerűbb frissítését, amely a hálózati paraméterek (csomagveszteség vagy RTT) alapján irányítja a küldést. A legtöbb TCP-implementáció a CUBIC algoritmust használja, , amely nem optimális a késleltetésre érzékeny forgalom számára. A közelmúltban kifejlesztett algoritmusok, mint például , pontosabban modellezik a hálózatot és optimalizálják a késleltetéseket. A QUIC lehetővé teszi a BBR használatát és ennek az algoritmusnak a folyamatos frissítését, ahogy az .
- a csomagveszteség pótlása érdekében. A QUIC két TLP-t () indít, mielőtt az RTO aktiválódna – még akkor is, ha a veszteség nagyon érzékelhető. Ez eltér a TCP-implementációktól. A TLP jellemzően az utolsó csomagot (vagy egy új csomagot, ha van) küldi újra, hogy elindítsa a gyors pótlást. A tail loss kezelés különösen hasznos, ahogyan az Uber dolgozik a hálózattal, nevezetesen a rövid, epizodikus és késleltetésérzékeny adatátvitel során.
- optimalizált ACK. Mivel minden csomaghoz egyedi sorrendi szám tartozik, nem merül fel a probléma a csomagok megkülönböztetésével a küldéskor. Az ACK-csomagok tartalmazzák a csomag feldolgozásához szükséges időt és az ACK generálását az ügyfél oldalán. Ezek a funkciók biztosítják, hogy a QUIC pontosabban számítsa ki az RTT-t. Az ACK a QUIC-ben akár 256 tartományt is támogat, , ami segít a küldőnek jobban ellenállni a csomagok átrendeződésének, és kevesebb bájt felhasználását lehetővé teszi a folyamat során. A részleges ACK ( ) a TCP-ben nem oldja meg ezt a problémát minden esetben.A QUIC kapcsolatokat egy 64 bites azonosítóval azonosítják, így ha az ügyfél IP-címet vált, továbbra is használható a régi kapcsolat az új IP-címen, megszakítások nélkül. Ez nagyon gyakori gyakorlat mobilalkalmazásokban, amikor a felhasználó Wi-Fi-ről mobil kapcsolatra vált.
- A QUIC alternatívái Alternatív megoldásokat vizsgáltunk, mielőtt a QUIC választása mellett döntöttünk.
Mi alternatív megközelítéseket vizsgáltunk, mielőtt a QUIC-ot választottuk.
Мы рассматривали альтернативные подходы к решению проблемы до того, как выбрать QUIC.
Első lépésként megpróbáltuk telepíteni a TPC PoPs (Jelenlét Pontok) szolgáltatást, hogy a TCP kapcsolatokat közelebb zárhassuk a felhasználókhoz. Alapvetően a PoPs a TCP kapcsolatot zárja le a mobil eszközzel közelebb a celluláris hálózathoz, és proxizálja a forgalmat az eredeti infrastruktúrához. A TCP zárása közelebb potenciálisan csökkentheti az RTT-t, és biztosíthatjuk, hogy a TCP aktívan reagáljon a dinamikus vezeték nélküli környezetre. Kísérleteink azonban azt mutatták, hogy nagyrészt az RTT és a veszteségek a celluláris hálózatokból adódnak, és a PoPs használata nem biztosít jelentős teljesítményjavulást.
Megvizsgáltuk a TCP paraméterek finomhangolását is. A TCP verem konfigurálása a vegyes határoló szervereinken nehezen kivitelezhető volt, mivel a TCP eltérő megvalósításai vannak a különböző operációs rendszerek verzióiban. Nehéz volt ezt megvalósítani és tesztelni a különböző hálózati konfigurációkat. A TCP közvetlen beállítása mobil eszközökön lehetetlen volt a jogok hiánya miatt. Ami még fontosabb, olyan funkciók, mint a 0-RTT kapcsolatok és a javított RTT előrejelzés kritikus fontosságúak a protokoll architektúrája szempontjából, így lényeges előnyök nem érhetők el csupán a TCP konfigurálásával.
Végül számos UDP-alapú protokollt értékeltünk, amelyek megoldásokat kínálnak a videostreaming problémáira – kíváncsiak voltunk, segítenek-e ezek a protokollok az esetünkben. Sajnos jelentős biztonsági beállítások hiányoztak belőlük, és további TCP kapcsolatot igényeltek a metaadatok és irányító információk számára.
Kutatásaink során kiderült, hogy a QUIC szinte az egyetlen protokoll, amely képes kezelni az internetes forgalom problémáit, figyelembe véve mind a biztonságot, mind a teljesítményt.
A QUIC integrációja a platformba
Ahhoz, hogy a QUIC-ot sikeresen beépíthessük és javíthassuk az alkalmazás teljesítményét gyenge kapcsolat esetén, a régi stack-et (HTTP/2 TLS/TCP felett) a QUIC protokollra cseréltük. Felhasználtuk a hálózati könyvtárat a , amely tartalmazza a protokoll eredeti, Google-os verzióját – gQUIC. Ez a megvalósítás folyamatosan fejlesztve van, hogy kövesse az IETF legfrissebb specifikációját.
Először integráltuk a Cronet-et Android-alkalmazásainkba, hogy támogassuk a QUIC-ot. Az integrációs folyamatot úgy hajtottuk végre, hogy minimalizáljuk a migrációs költségeket. Ahelyett, hogy teljes mértékben kicseréltük volna a régi hálózati stack-et, amely az könyvtárat használta, a Cronet-et az OkHttp API keretrendszer ALATT integráltuk. Ezzel az integrációval elkerültük a hálózati hívásaink (amelyeket a ) szintjén végzett változtatásokat.
Hasonlóan az Android-eszközökhöz, a Cronet-et az Uber iOS alkalmazásaiban is beépítettük, megfigyelve a HTTP forgalmat a hálózati , használva a . Ez az iOS Foundation által biztosított absztrakció kezeli a protokollspecifikus URL-adatokat, és biztosítja, hogy a Cronet-et jelentős migrációs költségek nélkül tudjuk integrálni iOS-alkalmazásainkba.
A QUIC befejezése a Google Cloud terheléselosztóin
A háttérszerver oldalon a QUIC befejezését a Google Cloud Load Balancing infrastruktúra biztosítja, amely A válaszokban található fejlécek a QUIC támogatásának megőrzésére szolgálnak. Általánosan elmondható, hogy minden HTTP-kéréshez a terheléselosztó egy alt-svc fejlécet ad hozzá, amely már validálja a QUIC támogatását a domain számára. Amikor a Cronet kliens HTTP-választ kap ilyen fejléccel, QUIC-ot használ a következő HTTP-kérésekhez e domain felé. Amint a terheléselosztó befejezi a QUIC-ot, az infrastruktúránk ezt az akciót kifejezetten HTTP2/TCP-n keresztül küldi el adatközpontjainkba.
Teljesítmény: eredmények
A kibocsátott teljesítmény a legfőbb oka a legjobb protokoll keresésének. Először is, létrehoztunk egy tesztet, , hogy kiderítsük, hogyan viselkedik a QUIC különböző hálózati profilok mellett. A QUIC valódi hálózatokban való működését azért teszteltük, mert kísérleteztünk, miközben New Delhi utcáin jártunk, emulált hálózati forgalmat használva, amely nagyon hasonlít a példautas alkalmazás HTTP-hívásaira.
1. kísérlet
Kísérleti készlet:
- Android tesztkészülékek OkHttp és Cronet stackekkel, hogy megbizonyosodjunk róla, hogy a HTTPS-forgalmat TCP-n és QUIC-on adjuk át megfelelően;
- Java alapú emulációs szerver, amely egységes HTTPS-fejléceket küld a válaszokban és terheli a kliens eszközöket, hogy kérdéseket kapjon róluk;
- Felhőalapú proxyk, amelyek fizikailag közel találhatók Indiához, hogy befejezzék a TCP és QUIC kapcsolatokat. Miközben a TCP befejezéséhez visszafelé haladó proxykat használtunk, , nehéz volt open source visszafelé haladó proxykat találni a QUIC számára. Saját magunk készítettük el a QUIC visszafelé haladó proxyját, amely a Chromium alapú QUIC stacket használja, és nyílt forráskódúként a Chromiumban.
6. ábra. A TCP vs QUIC tesztekhez szükséges terheléskészlet Android-eszközökből OkHttp és Cronet, felhőalapú proxykból a kapcsolatok befejezésére és az emulációs szerverből állt.
2. kísérlet
Amikor a Google elérhetővé tette a QUIC-ot a , ugyanazt a készletet használtuk, egy módosítással: az NGINX helyett a Google terheléselosztóit használtuk a TCP és QUIC kapcsolatok befejezésére az eszközökről, valamint a HTTPS-forgalom az emulációs szerverhez való irányítására. A terheléselosztók világszerte elosztva vannak, de a legközelebb eső PoP szervert használják az eszközhöz (köszönjük a geolokációnak).
7. ábra. A második kísérletben össze akartuk hasonlítani a TCP és QUIC befejezésének késleltetését: a Google Cloud segítségével és a saját felhő proxy-nkkal.
Végül több felfedezés várt ránk:
- a PoP-on keresztüli befejezés javította a TCP teljesítményét. Mivel a terheléselosztók közelebb hozzák a felhasználókhoz a TCP-kapcsolatokat, és kiválóan optimalizáltak, ez rövidebb RTT-t eredményez, ami javítja a TCP teljesítményét. Bár a QUIC-ra ez kisebb hatással volt, mégis 10-30% csökkentést ért el a késések csökkentésében a TCP-hez képest.
- a késésekre hatnak . Bár a QUIC-proxink távolabb volt az eszközöktől (körülbelül 50 ms várakozási idővel magasabb), mint a Google terheléselosztói, hasonló teljesítményt nyújtott – 15%-os késleltetéscsökkentéssel a 20%-os csökkentéshez képest a TCP 99. percentilisénél. Ez arra utal, hogy az utolsó mérföld (bottleneck) a hálózat működésének gyenge pontja.
8. ábra. Két kísérlet eredményei azt mutatják, hogy a QUIC jelentősen felülmúlja a TCP-t.
Éles forgalom
A kísérletek ihletésére bevezettük a QUIC támogatását Android és iOS alkalmazásainkba. A QUIC hatását A/B teszteléssel határoztuk meg az Uber jelenlétével rendelkező városokban. Összességében jelentős késleltetéscsökkenést tapasztaltunk régiók, szolgáltatók és hálózattípusok mentén.
Az alábbi grafikonok a késleltetés százalékos javulását mutatják (95 és 99 percentilis) a makrorégiókban és különböző hálózattípusokkal – LTE, 3G, 2G.
9. ábra. Az éles tesztekben a QUIC felülmúlta a TCP-t a késleltetések vonatkozásában.
Csak előre
Valószínűleg ez csak a kezdet – a QUIC élesbe való bevezetése lenyűgöző lehetőségeket teremtett az alkalmazások teljesítményének javítására mind stabil, mind instabil hálózatok esetében, nevezetesen:
A lefedettség növelése
A protokoll teljesítményének valós forgalomban végzett elemzése során láttuk, hogy körülbelül 80% sessions sikeresen használta a QUIC-ot a adattal, tehát csak a TXE jelző nem lesz elegendő. kérésekhez, míg 15% sessions kombinálta a QUIC-ot és a TCP-t. Feltételezzük, hogy ez a kombináció abból adódik, hogy a Cronet könyvtár időtúllépés miatt visszakapcsol a TCP-ra, mivel nem tudja megkülönböztetni a valódi UDP-hibákat és a rossz hálózati körülményeket. Jelenleg a megoldás keresésén dolgozunk, mivel a QUIC további bevezetésén dolgozunk.
QUIC optimalizálása
A mobilalkalmazások forgalma érzékeny a késésekre, de nem a sávszélességre. Emellett alkalmazásaink túlnyomórészt mobil hálózatokban működnek. Kísérleteink alapján a t尾késések még mindig jelentősek, annak ellenére, hogy proxyt használunk a TCP és QUIC lezárására a felhasználókhoz közel. Aktívan keresünk olyan módokat, amelyekkel javíthatjuk a túlterhelés kezelését és növelhetjük a QUIC veszteséghelyreállító algoritmusok hatékonyságát.
Ezekkel és néhány más fejlesztéssel célunk, hogy javítsuk a felhasználói élményt függetlenül a hálózattól és a régiótól, lehetővé téve a kényelmes és zökkenőmentes csomagátvitelt világszerte.
Forrás: habr.com
