Protokol QUIC je nesmierne zaujímavý a radi o ňom píšeme. Kým naše predchádzajúce príspevky o QUIC mali skôr historický (ak by ste chceli, aj regionálny) charakter a technické detaily, dnes s radosťou zverejňujeme preklad iného typu - pôjde o skutočné uplatnenie protokolu v roku 2019. Nejde však o malú infraštruktúru založenú v hypotetickej garáži, ale o Uber, ktorý pôsobí takmer na celom svete. Ako inžinieri spoločnosti prišli na rozhodnutie využiť QUIC v produkcii, ako prebiehali testy a čo videli po nasadení do produkcie - pokračujte nižšie.
Obrázky sú klikateľné. Prajeme príjemné čítanie!
Uber je globálna platforma, konkrétne v 600 mestách, v ktorých aplikácia úplne závisí od bezdrôtového internetu od viac ako 4500 mobilných operátorov. Používatelia očakávajú, že aplikácia bude fungovať nielen rýchlo, ale aj v reálnom čase - na to, aby sa to zabezpečilo, potrebujú aplikácie Uber nízke latencie a veľmi spoľahlivé pripojenie. Bohužiaľ, ale stack sa zle správa v dynamických a na straty náchylných bezdrôtových sieťach. Uvedomili sme si, že v tomto prípade je nízka výkonnosť priamo spojená s implementáciami TCP v jadre operačných systémov.
Aby sme vyriešili tento problém, aplikovali sme , moderný protokol s multiplexovaním kanálov, ktorý nám poskytuje väčšiu kontrolu nad výkonnosťou prenosového protokolu. V súčasnosti pracovná skupina štandardizuje QUIC ako .
Po podrobných testoch sme dospeli k záveru, že implementácia QUIC v našej aplikácii zníži "chvostové" latencie v porovnaní s TCP. Pozorovali sme pokles v rozmedzí 10-30% pre HTTPS prevádzku na príklade vodičskej a pasažierskej aplikácie. QUIC nám tiež poskytol komplexnú kontrolu nad používateľskými paketmi.
V tomto článku sa delíme o skúsenosti s optimalizáciou TCP pre aplikácie Uber pomocou stacku, ktorý podporuje QUIC.
Posledné slovo techniky: TCP
Dnes je TCP najpoužívanejší transportný protokol na doručovanie HTTPS prevádzky v sieti Internet. TCP zabezpečuje spoľahlivý prenos bytov, čím sa vyrovnáva s preťaženiami siete a stratami na úrovni kanála. Široké použitie TCP pre HTTPS prevádzku vysvetľuje jeho všadeprítomnosť (takmer každý operačný systém obsahuje TCP), dostupnosť na väčšine infraštruktúry (napríklad na vyvažovačoch záťaže, HTTPS proxy a CDN) a funkčnosť „z krabice“, ktorá je k dispozícii takmer na väčšine platforiem a sietí.
Väčšina používateľov používa našu aplikáciu na cestách a „chvostové“ oneskorenia TCP nielenže nevyhovovali požiadavkám našej HTTPS prevádzky v reálnom čase. Jednoducho povedané, s týmto sa stretávali používatelia po celom svete – na Obrázku 1 sú zobrazené oneskorenia vo veľkých mestách:
Obrázok 1. Veľkosť „chvostových“ oneskorení sa líši v hlavných mestách prítomnosti Uber.
Napriek tomu, že oneskorenia v indických a brazílskych sieťach boli vyššie ako v USA a Veľkej Británii, chvostové oneskorenia boli výrazne vyššie než priemerné oneskorenia. A to platí aj pre USA a Veľkú Britániu.
Výkon TCP vo vzduchu
TCP bol navrhnutý pre drôtové sieťe, teda so zameraním na dobre predvídateľné linky. Rôzne vlastnosti a problémy však existujú v bezdrôtových sieťach. Po prvé, bezdrôtové siete sú náchylné na straty spôsobené rušením a zhasínaním signálu. Napríklad Wi-Fi siete sú citlivé na mikrovlny, bluetooth a iné rádiové vlny. Mobilné siete trpia stratou signálu () spôsobenou odrazom/pohltením signálu predmetmi a stavbami, ako aj od od susedných To vedie k oveľa významnejším (4-10 krát) a rozmanitejším a stratám paketov v porovnaní s drôtovým pripojením.
Aby sa bojovalo s kolísaním šírky pásma a stratami, mobilné siete zvyčajne používajú veľké buffery pre nárazovú prevádzku. To môže viesť k nadmernému oneskoreniu, čo znamená väčšie oneskorenia. Veľmi často TCP interpretuje takéto oneskorenie ako stratu kvôli zvýšenému časovému intervalu, a preto je TCP naklonené k retransmisii a týmto spôsobom zapĺňa buffer. Problém nazývame (), a to je veľmi moderného internetu.
Nakoniec, výkon mobilnej siete sa mení v závislosti od poskytovateľa, regiónu a času. Na Obrázku 2 sme zhromaždili mediánové latencie HTTPS prevádzky po mobilných vežiach v rozsahu 2 kilometrov. Dáta boli zozbierané od dvoch najväčších mobilných operátorov v Dillí, India. Ako si môžete všimnúť, výkon sa líši od veže k veži. Taktiež sa výkon jedného operátora líši od výkonu druhého. Na to vplývajú faktory ako vzorce pripojenia k sieti s ohľadom na čas a lokalitu, mobilita používateľov a tiež sieťová infraštruktúra zohľadňujúca hustotu veží a pomer typov sietí (LTE, 3G a pod.).
Obrázok 2. Latencie na príklade 2-kilometrového rádiusu. Dillí, India.
Taktiež sa výkon mobilných sietí mení v priebehu času. Na Obrázku 3 je zobrazená mediánová latencia podľa dní v týždni. Sledovali sme aj rozdiely v menšom časovom rámci – v rámci jedného dňa a hodiny.
Obrázok 3. Chvostové latencie sa môžu výrazne meniť v rôzne dni, ale pri rovnakom operátorovi.
Všetko vyššie uvedené vedie k tomu, že výkon TCP nie je efektívny v bezdrôtových sieťach. Napriek tomu, predtým ako hľadáme alternatívy k TCP, sme chceli vypracovať presné pochopenie nasledujúcich bodov:
- je TCP hlavným vinníkom chvostových latencií v našich aplikáciách?
- majú moderné siete významné a rozmanité okruhové latencie (RTT)?
- aké je ovplyvnenie RTT a strát na výkon TCP?
Analýza výkonu TCP
Aby sme pochopili, ako sme analyzovali výkon TCP, si krátko pripomeňme, ako TCP prenáša dáta od odosielateľa k prijímateľovi. Na začiatku odosielateľ vytvorí TCP pripojenie prostredníctvom trojstupňového : odosielateľ posiela SYN paket, čaká na SYN-ACK paket od prijímateľa a potom posiela ACK paket. Ďalšie dva a tri prechody sa používajú na vytvorenie TCP pripojenia. Prijímateľ potvrdzuje prijatie každého paketu (ACK), aby zabezpečil spoľahlivé doručenie.
Ak je paket alebo ACK stratený, odosielateľ vykoná retransmisiu po uplynutí časového limitu (RTO, ). RTO sa vypočíta dynamicky na základe rôznych faktorov, ako napríklad na očakávanej latencii RTT medzi odosielateľom a prijímateľom.
Obrázok 4. Výmenné balíky cez TCP/TLS zahŕňajú mechanizmus retransmisie.
Aby sme určili, ako TCP fungovalo v našich aplikáciách, sledovali sme TCP pakety pomocou počas jedného týždňa v reálnom prevádzkovom prevádzke prichádzajúcej z indických okrajových serverov. Potom sme analyzovali TCP spojenia pomocou . Okrem toho sme vytvorili aplikáciu pre Android, ktorá posiela emulovaný prenos na testovací server, čo najpresnejšie napodobňujúc reálny prenos. Smartfóny s touto aplikáciou boli rozdané niekoľkým zamestnancom, ktorí zbierali logy počas niekoľkých dní.
Výsledky oboch experimentov boli navzájom zhodné. Pozorovali sme vysoké RTT oneskorenia; hodnoty v chvoste boli takmer 6-krát vyššie ako medián; priemerné oneskorenia presiahli 1 sekundu. Mnohé spojenia vykazovali straty, čo spôsobilo, že TCP retransmitoval 3,5% všetkých balíkov. V oblastiach s preťažením, ako sú letiská a nádražia, sme pozorovali 7% straty. Tieto výsledky spochybňujú rozšírené presvedčenie, že v mobilných sieťach výrazne znižujú straty na transportnej úrovni. Nižšie sú výsledky testov z aplikácie 'simulátor':
Sieťové metriky
Hodnoty
RTT, milisekundy [50%,75%, 95%,99%]
[350, 425, 725, 2300]
RTT odchýlka, sekundy
Priemerne ~1,2 s
Strata balíkov v nestabilných spojeniach
Priemerne ~3,5% (7% v oblastiach s preťažením)
Takmer v polovici týchto spojení bola aspoň jedna strata balíkov, prevažne to boli SYN a SYN-ACK pakety. Väčšina realizácií TCP používa hodnotu RTO 1 sekunda pre SYN pakety, ktorá sa exponenciálne zvyšuje pre následné straty. Čas načítania aplikácie sa môže zvýšiť kvôli tomu, že TCP potrebuje viac času na nadviazanie spojení.
V prípade prenosových balíkov vysoké hodnoty RTO výrazne znižujú efektívne využitie siete pri dočasných stratách v bezdrôtových sieťach. Zistili sme, že priemerný čas retransmisie je približne 1 sekunda s hodnotou oneskorenia v chvoste takmer 30 sekúnd. Také vysoké oneskorenia na úrovni TCP spôsobovali HTTPS časové prekročenia a opakované požiadavky, čo ďalej zvyšovalo oneskorenie a neefektivitu siete.
Zatiaľ čo 75. percentil meranej RTT bol okolo 425 ms, 75. percentil pre TCP bol takmer 3 sekundy. To naznačuje, že straty nútili TCP vykonať 7-10 pokusov, aby úspešne prenieslo dáta. Môže to byť dôsledkom neefektívneho výpočtu RTO, neschopnosti TCP rýchlo reagovať na stratu. v okne a neefektivity algoritmu riadenia preťaženia, ktorý nerozlišuje bezdrôtové straty a straty spôsobené sieťovým preťažením. Nižšie sú výsledky testov strát TCP:
Štatistika strát paketov TCP
Hodnota
Percento pripojení s minimálne 1 stratou paketu
45%
Percento pripojení so stratami počas nadväzovania pripojenia
30%
Percento pripojení so stratami počas prenosu údajov
76%
Rozdelenie latencií pri retransmisii, sekundy [50%, 75%, 95%, 99%]
[1, 2.8, 15, 28]
Rozdelenie počtu retransmisí pre jeden paket alebo TCP-segment
[1,3,6,7]
Aplikácia QUIC
Pôvodne navrhnutý spoločnosťou Google, QUIC je viacprúdový moderný prenosový protokol, ktorý funguje nad UDP. V súčasnosti je QUIC v (už sme písali, že existujú akoby dve verzie QUIC, zvedaví – pozn. prekladateľa). Ako je zobrazené na Obrázku 5, QUIC sa nachádza pod HTTP/3 (vlastne, HTTP/2 nad QUIC je HTTP/3, ktorý sa teraz intenzívne štandardizuje). Čiastočne nahrádza úrovne HTTPS a TCP, pričom využíva UDP na formovanie paketov. QUIC podporuje len bezpečný prenos údajov, keďže TLS je plne zabudované do QUIC.
Obrázok 5: QUIC funguje pod HTTP/3, nahrádza TLS, ktorý predtým fungoval pod HTTP/2.
Nižšie uvádzame dôvody, ktoré nás presvedčili použiť QUIC na posilnenie TCP:
- 0-RTT nadväzovanie pripojenia. QUIC umožňuje znovupoužitie autorizácií z predchádzajúcich pripojení, čím znižuje počet bezpečnostných hľadských procesov. V budúcnosti bude podporovať 0-RTT, avšak trojstranný TCP handshake stále zostane povinný.
- prekonanie HoL blokovania. HTTP/2 používa jedno TCP pripojenie pre každého klienta, aby zlepšilo výkon, ale to môže viesť k HoL (head-of-line) blokovaniu. QUIC zjednodušuje multiplexovanie a dodáva požiadavky aplikácii nezávisle jedna od druhej.
- správa preťaženia. QUIC je na úrovni aplikácií, čo umožňuje jednoduchšie aktualizovať hlavný algoritmus prenosu, ktorý riadi odosielanie na základe parametrov siete (počet strát alebo RTT). Väčšina realizácií TCP používa algoritmus , ktorý nie je optimálny pre oneskoreniu citlivý prenos. Nedávno vyvinuté algoritmy ako presnejšie modelujú sieť a optimalizujú oneskorenia. QUIC umožňuje používať BBR a aktualizovať tento algoritmus podľa jeho .
- na obnovenie strát. QUIC vykonáva dva TLP () predtým, ako sa spustí RTO – aj keď sú straty veľmi cítené. To sa líši od realizácií TCP. TLP opätovne odosiela predovšetkým posledný paket (alebo nový, ak nejaký existuje), aby spustil rýchle obnovenie. Spracovanie oneskorení na konci je obzvlášť užitočné pre to, ako Uber pracuje so sieťou, a to pre krátke, epizodické a na oneskorenia citlivé prenosy dát.
- optimalizovaný ACK. Keďže každý paket má jedinečné poradové číslo, nevzniká problém paketov pri ich opätovnom odoslaní. ACK pakety tiež obsahujú čas spracovania paketu a generovania ACK na strane klienta. Tieto vlastnosti zaručujú, že QUIC presnejšie vypočíta RTT. ACK v QUIC podporuje až 256 rozsahov , čo pomáha odosielateľovi byť odolnejším voči prestaveniu paketov a používať menej bajtov v procese. Výberové ACK () v TCP túto problematiku vo všetkých prípadoch nerieši.
- migrácia pripojenia. Pripojenia QUIC sú identifikované pomocou 64-bitového ID, takže ak klient mení IP adresy, je možné naďalej používať ID starého pripojenia na novej IP adrese, bez prerušenia. To je veľmi bežná prax pre mobilné aplikácie, keď používateľ prechádza medzi Wi-Fi a mobilnými pripojeniami.
Alternatívy k QUIC
Zvážili sme alternatívne prístupy k riešeniu problému pred tým, ako sme si vybrali QUIC.
Na začiatku sme sa pokúsili nasadiť TPC PoPs (Body prítomnosti), aby sme ukončili TCP spojenia bližšie k používateľom. V podstate, PoPs ukončuje TCP spojenie s mobilným zariadením bližšie k mobilnej sieti a proxyuje prevádzku do pôvodnej infraštruktúry. Ukončením TCP bližšie môžeme potenciálne znížiť RTT a byť si istí, že TCP bude aktívnejšie reagovať na dynamické bezdrôtové prostredie. Avšak naše experimenty ukázali, že väčšina RTT a strát pochádza z mobilných sietí a používanie PoPs neposkytuje významné zlepšenie výkonnosti.
Pozreli sme sa aj na ladění TCP parametrov. Nastavenie TCP stohu na našich heterogénnych okrajových serveroch bolo náročné, pretože TCP má neporovnateľné implementácie v rôznych verziách OS. Bolo ťažké to realizovať a otestovať rôzne sieťové konfigurácie. Priame nastavenie TCP na mobilných zariadeniach nebolo možné kvôli nedostatku oprávnení. Čo je ešte dôležitejšie, funkcie ako spojenia s 0-RTT a vylepšené predpovedanie RTT sú kriticky dôležité pre architektúru protokolu, a preto nie je možné dosiahnuť významné výhody iba ladením TCP.
Nakoniec sme posúdili niekoľko protokolov založených na UDP, ktoré odstraňujú problémy so streamovaním videa – chceli sme zistiť, či tieto protokoly pomôžu v našom prípade. Bohužiaľ, chýbalo im množstvo bezpečnostných nastavení a potrebovali ďalšie TCP pripojenie pre metadata a riadiace informácie.
Naše výskumy ukázali, že QUIC je takmer jediný protokol, ktorý môže pomôcť s problémom internetového prenosu, pričom zohľadňuje aj bezpečnosť, aj výkon.
Integrácia QUIC do platformy
Aby sme úspešne integrovali QUIC a zlepšili výkon aplikácie za podmienok zlého pripojenia, nahradili sme starý stack (HTTP/2 nad TLS/TCP) protokolom QUIC. Zapojili sme sieťovú knižnicu z , ktorá obsahuje pôvodnú, Googlovskú verziu protokolu – gQUIC. Táto implementácia sa neustále vylepšuje, aby sledovala najnovšiu špecifikáciu IETF.
Najprv sme integrovali Cronet do našich aplikácií pre Android, aby sme pridali podporu pre QUIC. Integrácia bola realizovaná tak, aby sa minimalizovali náklady na migráciu. Namiesto toho, aby sme úplne nahradili starý sieťový zásobník, ktorý používal knižnicu , sme integrovali Cronet POD rámcom OkHttp API. Takouto integráciou sme sa vyhli zmenám v našich sieťových volaniach (ktoré používajú ) na úrovni API.
Podobne ako pri prístupe k zariadeniam Android, sme implementovali Cronet do aplikácií Uber na iOS, zachytávajúc HTTP prevádzku zo sieťových , s použitím . Táto abstrakcia, poskytnutá iOS Foundation, spracováva protokoly špecifické URL dáta a zabezpečuje, že môžeme integrovať Cronet do našich aplikácií pre iOS bez podstatných nákladov na migráciu.
Ukončenie QUIC na vyvažovačoch Google Cloud
Na strane backendu je ukončenie QUIC zabezpečené infraštruktúrou Google Cloud Load balancing, ktorá používa hlavičky v odpovediach na podporu QUIC. Všeobecne platí, že k každému HTTP požiadavku pridáva vyvažovač hlavičku alt-svc a táto hlavička overuje podporu QUIC pre doménu. Keď klient Cronet dostane HTTP odpoveď s takouto hlavičkou, používa QUIC na nasledujúce HTTP požiadavky na túto doménu. Akonáhle vyvažovač ukončí QUIC, naša infraštruktúra výslovne odosiela túto akciu cez HTTP2/TCP do našich dátových centier.
Výkon: výsledky
Poháňaná výkonnosť je hlavný dôvod nášho hľadania lepšieho protokolu. Na začiatok sme vytvorili testovací stánok s , aby sme zistili, ako sa QUIC bude správať pri rôznych sieťových profiloch. Na to, aby sme otestovali výkon QUIC v reálnych sieťach, sme vykonali experimenty, jazdiac po Novom Dillí, pričom sme použili emulovaný sieťový prenos, veľmi podobný HTTP volaniam v aplikácii pre cestujúcich.
Experiment 1
Inventár pre experiment:
- testovacie zariadenia na Android so zásobníkmi OkHttp a Cronet, aby sme sa uistili, že posielame HTTPS prenos cez TCP a QUIC;
- Java-based emulačný server, ktorý zasiela rovnaké HTTPS hlavičky v odpovediach a zaťažuje klientské zariadenia, aby dostával od nich požiadavky;
- cloudové proxy, ktoré sa fyzicky nachádzajú blízko Indie, aby ukončili TCP a QUIC spojenia. Na ukončenie TCP sme použili reverznú proxy na , bolo ťažké nájsť open-source reverzný proxy pre QUIC. Vytvorili sme reverzný proxy pre QUIC sami, pomocou základného stacku QUIC z Chromium a zverejnili ho ako open-source v Chromiu.
Obrázok 6. Testovací set pre TCP vs QUIC sa skladal z Android zariadení s OkHttp a Cronet, cloudových proxy pre ukončenie spojení a emulačného servera.
Experiment 2
Keď Google sprístupnil QUIC prostredníctvom , použili sme rovnaký inventár, ale s jednou zmenou: namiesto NGINX sme vzali googleovské load balancery na ukončenie TCP a QUIC spojení z zariadení a na smerovanie HTTPS prevádzky k emulačnému serveru. Load balancery sú rozmiestnené po celom svete, ale používajú najbližší PoP server k zariadeniu (ďakujeme geolokácii).
Obrázok 7. V druhom experimente sme chceli porovnať latenciu ukončenia pre TCP a QUIC: pomocou Google Cloudu a nášho cloudového proxy.
Nakoniec nás čakalo niekoľko objavov:
- ukončenie cez PoP zlepšilo výkon TCP. Keďže load balancery ukončujú TCP spojenie bližšie k užívateľom a sú skvele optimalizované, to vedie k menším RTT, čo zlepšuje výkon TCP. A hoci to malo menší dopad na QUIC, predsa len prekonal TCP v znížení konečnej latencie (o 10-30 percent).
- na konečné latencie vplývajú . Aj keď náš QUIC proxy bol ďalej od zariadení (latencia približne o 50 ms vyššia), než googleovské load balancery, dosiahol podobný výkon – 15% zníženie latencií proti 20% zníženiu v 99. percentile pre TCP. To naznačuje, že prechod na poslednej míle je úzkym hrdlom (bottleneck) v prevádzke siete.
Obrázok 8. Výsledky dvoch experimentov ukazujú, že QUIC výrazne prekonáva TCP.
Aktuálna prevádzka
Inšpirovaní experimentami sme implementovali podporu QUIC do našich Android a iOS aplikácií. Urobili sme A/B testovanie, aby sme určili dopad QUIC v mestách, kde je Uber prítomný. Celkovo sme zaznamenali významné zníženie konečných latencií naprieč regiónmi, ako aj medzi mobilnými operátormi a typmi sietí.
Na grafoch nižšie sú zobrazené percentuálne zlepšenia latencií (95. a 99. percentil) podľa makroregionov a rôznych typov sietí – LTE, 3G, 2G.
Obrázok 9. V súťažných testoch QUIC prekonal TCP pokiaľ ide o latencie.
Len vpred
Tohoto máte pravdu, je to len začiatok – zavedenie QUIC do produkcie poskytlo neuveriteľné možnosti na zlepšenie výkonu aplikácií, ako v stabilných, tak aj v nestabilných sieťach, a to najmä:
Zvýšenie pokrytia
Analyzovaním výkonu protokolu na reálnom tráve sme zistili, že približne 80 % relácií úspešne využívalo QUIC na všetkých žiadosť, zatiaľ čo 15 % relácií používalo kombináciu QUIC a TCP. Predpokladáme, že kombinácia vznikla preto, že knižnica Cronet sa prepína späť na TCP pri časovom limite, pretože nedokáže rozlišovať medzi skutočnými zlyhaniami UDP a zlými sieťovými podmienkami. Momentálne hľadáme riešenie tohto problému, pretože pracujeme na ďalšom implementovaní QUIC.
Optimalizácia QUIC
Prevádzka z mobilných aplikácií je citlivá na oneskorenia, ale nie na šírku pásma. Naše aplikácie sa navyše prevažne používajú v mobilných sieťach. Na základe experimentov sú zaostávajúce oneskorenia stále vysoké, aj keď používame proxy na ukončenie TCP a QUIC blízko k používateľom. Aktívne hľadáme spôsoby, ako zlepšiť riadenie preťaženia a zvýšiť efektívnosť QUIC algoritmov na obnovu strát.
S týmito a niektorými ďalšími zlepšeniami plánujeme zlepšiť používateľskú skúsenosť bez ohľadu na sieť a región, čím sprístupníme pohodlnú a bezproblémovú prepravu paketov po celom svete.
Zdroj: habr.com
