Protokol QUIC je mimoriadne zaujímavé sledovať, a preto o ňom radi píšeme. No ak predchádzajúce publikácie o QUIC boli skôr historického (ak chcete lokálneho) charakteru a hardvéru, dnes radi zverejníme preklad iného druhu – o reálnej aplikácii protokolu sa budeme baviť v roku 2019. Navyše nehovoríme o malej infraštruktúre založenej v takzvanej garáži, ale o Uberi, ktorý funguje takmer po celom svete. Ako inžinieri spoločnosti dospeli k rozhodnutiu použiť QUIC vo výrobe, ako vykonali testy a čo videli po zavedení do výroby - pod rezom.
Obrázky sú klikateľné. Užívať si čítanie!
Uber má globálny rozsah, konkrétne 600 miest, z ktorých sa v každom z nich aplikácia spolieha výlučne na bezdrôtový internet od viac ako 4500 XNUMX mobilných operátorov. Používatelia očakávajú, že aplikácia bude nielen rýchla, ale aj v reálnom čase – na dosiahnutie tohto cieľa potrebuje aplikácia Uber nízku latenciu a veľmi spoľahlivé pripojenie. Bohužiaľ, ale hromada nefunguje dobre v dynamických a stratových bezdrôtových sieťach. Uvedomili sme si, že v tomto prípade nízky výkon priamo súvisí s implementáciami TCP v jadrách operačných systémov.
Aby sme problém vyriešili, podali sme žiadosť , moderný protokol multiplexovania kanálov, ktorý nám poskytuje väčšiu kontrolu nad výkonom prenosového protokolu. V súčasnosti pracovná skupina štandardizuje QUIC as .
Po rozsiahlom testovaní sme dospeli k záveru, že implementácia QUIC v našej aplikácii by viedla k nižším oneskoreniam v porovnaní s TCP. V aplikáciách pre vodiča a spolujazdca sme zaznamenali zníženie v rozsahu 10 – 30 % pre prenos HTTPS. QUIC nám tiež poskytol úplnú kontrolu nad používateľskými balíkmi.
V tomto článku zdieľame naše skúsenosti s optimalizáciou TCP pre aplikácie Uber pomocou zásobníka, ktorý podporuje QUIC.
Najnovšia technológia: TCP
V súčasnosti je TCP najpoužívanejším transportným protokolom na doručovanie prenosu HTTPS na internete. TCP poskytuje spoľahlivý tok bajtov, čím sa vyrovnáva s preťažením siete a stratami spojovacej vrstvy. Široké používanie TCP pre prenos HTTPS je spôsobené jeho všadeprítomnosťou (takmer každý OS obsahuje TCP), dostupnosťou na väčšine infraštruktúry (ako sú vyrovnávače zaťaženia, HTTPS proxy a CDN) a predpripravenou funkcionalitou, ktorá je k dispozícii. na takmer väčšine platforiem a sietí.
Väčšina používateľov používa našu aplikáciu na cestách a latencie TCP sa ani zďaleka nepribližovali požiadavkám našej premávky HTTPS v reálnom čase. Jednoducho povedané, používatelia na celom svete to zažili – Obrázok 1 ukazuje oneskorenia vo veľkých mestách:
Obrázok 1: Latencia chvosta sa v hlavných mestách Uberu líši.
Hoci latencia v indických a brazílskych sieťach bola vyššia ako v USA a Spojenom kráľovstve, latencia na konci je výrazne vyššia ako priemerná latencia. A to platí dokonca aj pre USA a Spojené kráľovstvo.
Výkon TCP cez vzduch
TCP bol vytvorený pre káblové sietí, teda s dôrazom na vysoko predvídateľné prepojenia. však bezdrôtový siete majú svoje vlastné charakteristiky a ťažkosti. Po prvé, bezdrôtové siete sú náchylné na straty v dôsledku rušenia a útlmu signálu. Napríklad siete Wi-Fi sú citlivé na mikrovlny, bluetooth a iné rádiové vlny. Mobilné siete trpia stratou signálu () v dôsledku odrazu/absorpcie signálu predmetmi a budovami, ako aj od zo susedných . To vedie k významnejším (4-10-krát) a rôznorodejším a stratu paketov v porovnaní s káblovým pripojením.
Na boj proti kolísaniu šírky pásma a stratám mobilné siete zvyčajne používajú veľké vyrovnávacie pamäte pre zhluky prevádzky. To môže viesť k nadmernému čakaniu v rade, čo znamená dlhšie oneskorenia. TCP veľmi často považuje toto radenie za plytvanie v dôsledku predĺženého časového limitu, takže TCP má tendenciu odovzdávať a tým zapĺňať vyrovnávaciu pamäť. Tento problém je známy ako (), a to je veľmi moderný internet.
Výkon mobilnej siete sa napokon líši podľa operátora, regiónu a času. Na obrázku 2 sme zhromaždili stredné oneskorenia prenosu HTTPS naprieč bunkami v rozsahu 2 km. Údaje zhromaždené pre dvoch hlavných mobilných operátorov v Dillí v Indii. Ako vidíte, výkon sa líši od bunky k bunke. Taktiež produktivita jedného operátora sa líši od produktivity druhého. To je ovplyvnené faktormi, ako sú vzorce vstupu do siete zohľadňujúce čas a miesto, mobilita používateľov, ako aj sieťová infraštruktúra zohľadňujúca hustotu veží a pomer typov sietí (LTE, 3G atď.).
Obrázok 2. Oneskorenia s použitím príkladu s polomerom 2 km. Dillí, India.
Výkon celulárnych sietí sa tiež v priebehu času mení. Obrázok 3 zobrazuje strednú latenciu podľa dňa v týždni. Rozdiely sme pozorovali aj v menšom meradle, v rámci jedného dňa a hodiny.
Obrázok 3. Oneskorenie chvosta sa môže medzi dňami výrazne líšiť, ale pre toho istého operátora.
Všetky vyššie uvedené spôsobujú, že výkon TCP je v bezdrôtových sieťach neúčinný. Pred hľadaním alternatív k TCP sme však chceli presne pochopiť nasledujúce body:
- je TCP hlavným vinníkom za oneskorením v našich aplikáciách?
- Majú moderné siete významné a rôzne spiatočné oneskorenia (RTT)?
- Aký je vplyv RTT a straty na výkon TCP?
Analýza výkonu TCP
Aby sme pochopili, ako sme analyzovali výkon TCP, pozrime sa rýchlo na to, ako TCP prenáša údaje od odosielateľa k príjemcovi. Najprv odosielateľ vytvorí spojenie TCP, pričom vykoná trojcestné spojenie : Odosielateľ odošle paket SYN, čaká na paket SYN-ACK od príjemcu a potom odošle paket ACK. Ďalší druhý a tretí prechod sa strávi nadviazaním spojenia TCP. Príjemca potvrdí prijatie každého paketu (ACK), aby sa zabezpečilo spoľahlivé doručenie.
Ak dôjde k strate paketu alebo ACK, odosielateľ po uplynutí časového limitu znova odošle (RTO, ). RTO sa vypočítava dynamicky na základe rôznych faktorov, ako je napríklad očakávané oneskorenie RTT medzi odosielateľom a príjemcom.
Obrázok 4. Výmena paketov cez TCP/TLS zahŕňa mechanizmus opakovaného prenosu.
Aby sme zistili, ako TCP fungoval v našich aplikáciách, monitorovali sme TCP pakety pomocou týždeň o bojovej prevádzke prichádzajúcej z indických okrajových serverov. Potom sme analyzovali pripojenia TCP pomocou . Okrem toho sme vytvorili aplikáciu pre Android, ktorá odosiela emulovanú návštevnosť na testovací server a čo najviac napodobňuje skutočnú premávku. Smartfóny s touto aplikáciou boli distribuované niekoľkým zamestnancom, ktorí zbierali logy počas niekoľkých dní.
Výsledky oboch experimentov boli navzájom konzistentné. Videli sme vysoké latencie RTT; chvostové hodnoty boli takmer 6-krát vyššie ako stredná hodnota; aritmetický priemer oneskorení je viac ako 1 sekunda. Mnoho pripojení bolo stratových, čo spôsobilo, že TCP znova prenieslo 3,5 % všetkých paketov. V preplnených oblastiach, ako sú letiská a železničné stanice, sme zaznamenali 7 % straty. Tieto výsledky spochybňujú konvenčnú múdrosť, ktorá sa používa v celulárnych sieťach výrazne znížiť straty na úrovni dopravy. Nižšie sú uvedené výsledky testov z aplikácie „simulátor“:
Sieťové metriky
zmysel
RTT, milisekundy [50%,75%, 95%,99%]
[350, 425, 725, 2300]
RTT divergencia, sekundy
V priemere ~1,2 s
Strata paketov pri nestabilných spojeniach
Priemer ~3.5 % (7 % v preťažených oblastiach)
Takmer polovica týchto spojení mala aspoň jednu stratu paketu, väčšinou pakety SYN a SYN-ACK. Väčšina implementácií TCP používa pre pakety SYN hodnotu RTO 1 sekundu, ktorá sa exponenciálne zvyšuje pre následné straty. Časy načítania aplikácií sa môžu predĺžiť, pretože TCP trvá dlhšie, kým nadviaže spojenie.
V prípade dátových paketov vysoké hodnoty RTO výrazne znižujú užitočné využitie siete v prítomnosti prechodných strát v bezdrôtových sieťach. Zistili sme, že priemerný čas opätovného prenosu je približne 1 sekunda s oneskorením takmer 30 sekúnd. Tieto vysoké latencie na úrovni TCP spôsobovali časové limity HTTPS a opakované požiadavky, čím ďalej zvyšovali latenciu a neefektívnosť siete.
Kým 75. percentil nameraného RTT bol okolo 425 ms, 75. percentil pre TCP bol takmer 3 sekundy. To naznačuje, že strata spôsobila, že protokol TCP potreboval 7 až 10 prechodov na úspešný prenos údajov. Môže to byť dôsledok neefektívneho výpočtu RTO, neschopnosti TCP rýchlo reagovať na stratu v okne a neefektívnosť algoritmu riadenia preťaženia, ktorý nerozlišuje medzi stratami bezdrôtového pripojenia a stratami v dôsledku preťaženia siete. Nižšie sú uvedené výsledky testov straty TCP:
Štatistika straty paketov TCP
Hodnota
Percento pripojení s aspoň 1 stratou paketu
45%
Percento pripojení so stratami počas nastavovania pripojenia
30%
Percento spojení so stratami počas výmeny údajov
76%
Rozdelenie oneskorení pri opakovanom prenose, sekundy [50 %, 75 %, 95 %, 99 %] [1, 2.8, 15, 28]
Rozdelenie počtu opakovaných prenosov pre jeden paket alebo TCP segment
[1,3,6,7]
Aplikácia QUIC
QUIC, pôvodne vyvinutý spoločnosťou Google, je viacvláknový moderný transportný protokol, ktorý beží nad protokolom UDP. Momentálne je tu QUIC (Už sme písali, že existujú dve verzie QUIC, zaujímavé - približne. prekladateľ). Ako je znázornené na obrázku 5, QUIC je umiestnený pod HTTP/3 (v skutočnosti HTTP/2 nad QUIC je HTTP/3, ktorý sa teraz intenzívne štandardizuje). Čiastočne nahrádza vrstvy HTTPS a TCP pomocou UDP na vytváranie paketov. QUIC podporuje iba bezpečný prenos údajov, keďže TLS je plne zabudovaný do QUIC.
Obrázok 5: QUIC beží pod HTTP/3 a nahrádza TLS, ktorý predtým bežal pod HTTP/2.
Nižšie sú uvedené dôvody, ktoré nás presvedčili použiť QUIC na zosilnenie TCP:
- 0-RTT nadviazanie spojenia. QUIC umožňuje opätovné použitie autorizácií z predchádzajúcich pripojení, čím sa znižuje počet bezpečnostných handshake. Nabudúce bude podporovať 0-RTT, ale trojsmerný TCP handshake bude stále potrebný.
- prekonanie blokovania HoL. HTTP/2 používa jedno pripojenie TCP na klienta na zlepšenie výkonu, ale to môže viesť k blokovaniu HoL (head-of-line). QUIC zjednodušuje multiplexovanie a doručuje požiadavky do aplikácie nezávisle.
- kontrola preťaženia. QUIC sa nachádza na aplikačnej vrstve, čo uľahčuje aktualizáciu hlavného transportného algoritmu, ktorý riadi odosielanie na základe sieťových parametrov (počet strát alebo RTT). Väčšina implementácií TCP používa tento algoritmus , čo nie je optimálne pre prevádzku citlivú na latenciu. Nedávno vyvinuté algoritmy ako napr , presnejšie modelovať sieť a optimalizovať latenciu. QUIC vám umožňuje používať BBR a aktualizovať tento algoritmus tak, ako sa používa. .
- doplnenie strát. QUIC volá dvoch TLP () pred spustením RTO – aj keď sú straty veľmi citeľné. Toto sa líši od implementácií TCP. TLP preposiela hlavne posledný paket (alebo nový, ak nejaký existuje), aby sa spustilo rýchle doplnenie. Spracovanie oneskorení je obzvlášť užitočné pre spôsob, akým Uber prevádzkuje svoju sieť, konkrétne pre krátke, sporadické a na latenciu citlivé dátové prenosy.
- optimalizované ACK. Keďže každý paket má jedinečné poradové číslo, nie je problém pakety pri ich opätovnom odoslaní. Pakety ACK obsahujú aj čas na spracovanie paketu a vygenerovanie ACK na strane klienta. Tieto funkcie zabezpečujú, že QUIC vypočítava RTT presnejšie. ACK v QUIC podporuje až 256 pásiem , čo pomáha odosielateľovi byť odolnejším voči miešaniu paketov a používať v tomto procese menej bajtov. Selektívne ACK () v TCP nerieši tento problém vo všetkých prípadoch.
- migrácia pripojenia. Pripojenia QUIC sú identifikované 64-bitovým ID, takže ak klient zmení adresy IP, staré ID pripojenia sa môže bez prerušenia naďalej používať na novej adrese IP. Toto je veľmi bežná prax pre mobilné aplikácie, kde používateľ prepína medzi Wi-Fi a mobilným pripojením.
Alternatívy k QUIC
Pred výberom QUIC sme zvážili alternatívne prístupy k riešeniu problému.
Prvá vec, ktorú sme vyskúšali, bolo nasadenie TPC PoP (Points of Presence) na ukončenie TCP spojení bližšie k používateľom. PoPs v podstate ukončujú TCP spojenie s mobilným zariadením bližšie k mobilnej sieti a proxy prenos späť do pôvodnej infraštruktúry. Bližším ukončením TCP môžeme potenciálne znížiť RTT a zabezpečiť, aby TCP lepšie reagovalo na dynamické bezdrôtové prostredie. Naše experimenty však ukázali, že väčšina RTT a strát pochádza z celulárnych sietí a použitie PoP neposkytuje výrazné zlepšenie výkonu.
Pozreli sme sa aj na ladenie parametrov TCP. Nastavenie zásobníka TCP na našich heterogénnych okrajových serveroch bolo ťažké, pretože TCP má rôzne implementácie v rôznych verziách OS. Bolo ťažké to implementovať a testovať rôzne konfigurácie siete. Konfigurácia TCP priamo na mobilných zariadeniach nebola možná kvôli chýbajúcim povoleniam. Čo je dôležitejšie, funkcie, ako sú pripojenia 0-RTT a vylepšená predikcia RTT, sú kritické pre architektúru protokolu, a preto nie je možné dosiahnuť významné výhody vyladením samotného TCP.
Nakoniec sme vyhodnotili niekoľko protokolov založených na UDP, ktoré riešia problémy so streamovaním videa – chceli sme zistiť, či by tieto protokoly v našom prípade pomohli. Žiaľ, veľmi im chýbali mnohé bezpečnostné nastavenia a tiež vyžadovali dodatočné pripojenie TCP pre metadáta a riadiace informácie.
Náš výskum ukázal, že QUIC je snáď jediný protokol, ktorý dokáže pomôcť s problémom internetovej prevádzky, pričom berie do úvahy bezpečnosť aj výkon.
Integrácia QUIC do platformy
Aby sme úspešne vložili QUIC a zlepšili výkon aplikácií v prostrediach so zlou konektivitou, nahradili sme starý zásobník (HTTP/2 cez TLS/TCP) protokolom QUIC. Použili sme sieťovú knižnicu z , ktorý obsahuje pôvodnú, Google verziu protokolu – gQUIC. Táto implementácia sa tiež neustále vylepšuje, aby vyhovovala najnovšej špecifikácii IETF.
Najprv sme integrovali Cronet do našich aplikácií pre Android, aby sme pridali podporu pre QUIC. Integrácia prebiehala tak, aby sa čo najviac znížili náklady na migráciu. Namiesto úplnej výmeny starého sieťového zásobníka, ktorý používal knižnicu , integrovali sme Cronet POD rámec API OkHttp. Integráciou týmto spôsobom sme sa vyhli zmenám v našich sieťových hovoroch (ktoré používajú ) na úrovni API.
Podobne ako v prípade zariadení s Androidom sme implementovali Cronet do aplikácií Uber na iOS, čím sme zachytili HTTP prevádzku zo siete Použitie . Táto abstrakcia, ktorú poskytuje iOS Foundation, spracováva údaje o adresách URL špecifické pre protokol a zabezpečuje, že môžeme integrovať Cronet do našich aplikácií pre iOS bez výrazných nákladov na migráciu.
Dokončenie QUIC v službe Google Cloud Balancers
Na strane backendu dokončenie QUIC zabezpečuje infraštruktúra na vyvažovanie záťaže Google Cloud, ktorú využíva hlavičky v odpovediach na podporu QUIC. Balancér vo všeobecnosti pridáva hlavičku alt-svc ku každej požiadavke HTTP, čo už overuje podporu QUIC pre doménu. Keď klient Cronet prijme HTTP odpoveď s touto hlavičkou, použije QUIC pre následné HTTP požiadavky na túto doménu. Keď balancér dokončí QUIC, naša infraštruktúra explicitne odošle túto akciu cez HTTP2/TCP do našich dátových centier.
Výkon: Výsledky
Výstupný výkon je hlavným dôvodom nášho hľadania lepšieho protokolu. Na začiatok sme vytvorili stánok s zistiť, ako sa bude QUIC správať pod rôznymi sieťovými profilmi. Aby sme otestovali výkon QUIC v reálnych sieťach, spustili sme experimenty počas jazdy po New Delhi s použitím emulovanej sieťovej prevádzky veľmi podobnej HTTP hovorom v aplikácii pre cestujúcich.
Experiment 1
Vybavenie na experiment:
- testovať zariadenia so systémom Android pomocou zásobníkov OkHttp a Cronet, aby sme sa uistili, že povolíme prenos HTTPS cez TCP a QUIC;
- emulačný server na báze Java, ktorý v odpovediach odosiela rovnaký typ hlavičiek HTTPS a načítava klientske zariadenia, aby od nich prijímali požiadavky;
- cloud proxy, ktoré sa fyzicky nachádzajú v blízkosti Indie, aby ukončili pripojenia TCP a QUIC. Zatiaľ čo na ukončenie TCP sme použili reverzný proxy server , bolo ťažké nájsť open source reverzný proxy server pre QUIC. Sami sme vytvorili reverzný proxy pre QUIC pomocou základného zásobníka QUIC od Chromium a do chrómu ako open source.
Obrázok 6. Súprava cestných testov TCP vs QUIC pozostávala zo zariadení Android s OkHttp a Cronet, cloudových proxy na ukončenie pripojení a emulačného servera.
Experiment 2
Keď Google sprístupnil QUIC s , použili sme rovnaký inventár, ale s jednou úpravou: namiesto NGINX sme použili nástroje na vyrovnávanie zaťaženia Google na ukončenie pripojení TCP a QUIC zo zariadení, ako aj na smerovanie prenosu HTTPS na emulačný server. Balancery sú distribuované po celom svete, ale používajte PoP server najbližšie k zariadeniu (vďaka geolokácii).
Obrázok 7. V druhom experimente sme chceli porovnať latenciu dokončenia TCP a QUIC: pomocou Google Cloud a pomocou nášho cloudového proxy.
V dôsledku toho nás čakalo niekoľko odhalení:
- ukončenie cez PoP zlepšilo výkon TCP. Keďže balancery ukončujú pripojenia TCP bližšie k používateľom a sú vysoko optimalizované, výsledkom sú nižšie RTT, čo zlepšuje výkon TCP. A hoci QUIC bol ovplyvnený menej, stále prekonal TCP z hľadiska zníženia latencie chvosta (o 10-30 percent).
- sú ovplyvnené chvosty . Hoci bol náš proxy server QUIC ďalej od zariadení (asi o 50 ms vyššia latencia) ako nástroje na vyrovnávanie záťaže od spoločnosti Google, poskytoval podobný výkon – 15 % zníženie latencie oproti 20 % zníženiu 99. percentilu pre TCP. To naznačuje, že prechod poslednej míle je prekážkou v sieti.
Obrázok 8: Výsledky z dvoch experimentov ukazujú, že QUIC výrazne prevyšuje TCP.
Bojová premávka
Inšpirovaní experimentovaním sme implementovali podporu QUIC do našich aplikácií pre Android a iOS. Vykonali sme A/B testovanie, aby sme určili vplyv QUIC v mestách, kde Uber pôsobí. Vo všeobecnosti sme zaznamenali výrazné zníženie oneskorení na konci v oboch regiónoch, telekomunikačných operátoroch a type siete.
Nižšie uvedené grafy ukazujú percentuálne zlepšenia koncových bodov (95 a 99 percentilov) podľa makroregiónu a rôznych typov sietí – LTE, 3G, 2G.
Obrázok 9. V bojových testoch QUIC prekonal TCP z hľadiska latencie.
Iba vpred
Možno je to len začiatok – uvoľnenie QUIC do produkcie poskytlo úžasné príležitosti na zlepšenie výkonu aplikácií v stabilných aj nestabilných sieťach, konkrétne:
Zvýšené pokrytie
Po analýze výkonu protokolu na reálnej prevádzke sme zistili, že približne 80 % relácií úspešne použilo QUIC na všetko žiadostí, zatiaľ čo 15 % relácií využívalo kombináciu QUIC a TCP. Predpokladáme, že kombinácia je spôsobená časovým limitom knižnice Cronet späť na TCP, pretože nedokáže rozlíšiť medzi skutočnými zlyhaniami UDP a zlými sieťovými podmienkami. V súčasnosti hľadáme riešenie tohto problému, keďže pracujeme na následnej implementácii QUIC.
QUIC optimalizácia
Návštevnosť z mobilných aplikácií je citlivá na latenciu, ale nie na šírku pásma. Naše aplikácie sa tiež primárne používajú v mobilných sieťach. Na základe experimentov sú latencie chvosta stále vysoké, aj keď používate proxy na ukončenie TCP a QUIC v blízkosti používateľov. Aktívne hľadáme spôsoby, ako zlepšiť riadenie preťaženia a zlepšiť efektivitu algoritmov obnovy strát QUIC.
S týmito a niekoľkými ďalšími vylepšeniami plánujeme zlepšiť používateľskú skúsenosť bez ohľadu na sieť a región, vďaka čomu bude pohodlný a bezproblémový prenos paketov dostupnejší po celom svete.
Zdroj: hab.com