Protokol QUIC iznimno je zanimljiv za promatranje, zato volimo pisati o njemu. Ali ako su dosadašnje publikacije o QUIC-u bile više povijesne (lokalne povijesti, ako želite) prirode i hardvera, danas sa zadovoljstvom objavljujemo prijevod drugačije vrste - govorit ćemo o stvarnoj primjeni protokola u 2019. godini. Štoviše, ne govorimo o maloj infrastrukturi baziranoj u tzv. garaži, već o Uberu koji posluje gotovo u cijelom svijetu. Kako su inženjeri tvrtke došli do odluke da koriste QUIC u proizvodnji, kako su proveli testove i što su vidjeli nakon što su ga pustili u proizvodnju - u nastavku.
Na slike se može kliknuti. Uživaj čitajući!
Uber ima globalnu razmjeru, odnosno 600 gradova prisutnosti, u svakom od kojih se aplikacija u potpunosti oslanja na bežični internet više od 4500 mobilnih operatera. Korisnici očekuju da aplikacija ne bude samo brza, već i u stvarnom vremenu - da bi se to postiglo, aplikaciji Uber potrebna je mala latencija i vrlo pouzdana veza. Jao, ali stog ne radi dobro u dinamičnim bežičnim mrežama sklonim gubicima. Shvatili smo da je u ovom slučaju niska izvedba izravno povezana s TCP implementacijama u jezgri operativnog sustava.
Kako bismo riješili problem, prijavili smo se , moderan protokol za multipleksiranje kanala koji nam daje veću kontrolu nad izvedbom transportnog protokola. Trenutno radna grupa standardizira QUIC kao .
Nakon opsežnog testiranja zaključili smo da bi implementacija QUIC-a u našu aplikaciju rezultirala nižim latencijama repa u usporedbi s TCP-om. Uočili smo smanjenje u rasponu od 10-30% za HTTPS promet u aplikacijama za vozača i putnika. QUIC nam je također dao end-to-end kontrolu nad korisničkim paketima.
U ovom članku dijelimo naše iskustvo u optimizaciji TCP-a za Uberove aplikacije pomoću skupa koji podržava QUIC.
Najnovija tehnologija: TCP
Danas je TCP najkorišteniji transportni protokol za isporuku HTTPS prometa na Internetu. TCP pruža pouzdan tok bajtova, čime se nosi sa zagušenjem mreže i gubicima na sloju veze. Široko rasprostranjena upotreba TCP-a za HTTPS promet posljedica je njegove sveprisutnosti (gotovo svaki OS sadrži TCP), dostupnosti na većini infrastrukture (kao što su balanseri opterećenja, HTTPS proxyji i CDN-ovi) i dostupne funkcije izvan okvira na gotovo većini platformi i mreža.
Većina korisnika koristi našu aplikaciju dok su u pokretu, a latencije TCP repa nisu bile ni blizu zahtjevima našeg HTTPS prometa u stvarnom vremenu. Jednostavno rečeno, korisnici diljem svijeta su to iskusili - Slika 1 prikazuje kašnjenja u većim gradovima:
Slika 1: Zadnje kašnjenje varira u glavnim Uberovim gradovima.
Iako je kašnjenje u indijskim i brazilskim mrežama bilo veće nego u SAD-u i Ujedinjenom Kraljevstvu, kašnjenje u repu znatno je veće od prosječnog kašnjenja. A to vrijedi čak i za SAD i UK.
TCP over the air performanse
TCP je stvoren za ožičen mrežama, odnosno s naglaskom na vrlo predvidljivim poveznicama. Međutim, bežični mreže imaju svoje karakteristike i poteškoće. Prvo, bežične mreže su osjetljive na gubitke zbog smetnji i slabljenja signala. Na primjer, Wi-Fi mreže osjetljive su na mikrovalove, bluetooth i druge radiovalove. Mobilne mreže pate od gubitka signala () zbog refleksije/apsorpcije signala od objekata i zgrada, kao i od iz susjednih . To dovodi do značajnijeg (4-10 puta) i raznovrsnijeg i gubitak paketa u usporedbi sa žičnom vezom.
Za borbu protiv fluktuacija širine pojasa i gubitaka, mobilne mreže obično koriste velike međuspremnike za prometne udare. To može dovesti do prekomjernog čekanja u redu, što znači duža kašnjenja. Vrlo često TCP ovo čekanje u redu tretira kao gubitak zbog produljenog vremenskog ograničenja, tako da TCP teži releju i time puni međuspremnik. Ovaj problem je poznat kao (), a ovo je vrlo modernog interneta.
Konačno, izvedba mobilne mreže ovisi o operateru, regiji i vremenu. Na slici 2 prikupili smo srednja kašnjenja HTTPS prometa kroz ćelije unutar raspona od 2 kilometra. Podaci prikupljeni za dva glavna mobilna operatera u Delhiju, Indija. Kao što vidite, performanse se razlikuju od ćelije do ćelije. Također, produktivnost jednog operatera razlikuje se od produktivnosti drugog. Na to utječu čimbenici kao što su obrasci ulaska u mrežu uzimajući u obzir vrijeme i lokaciju, mobilnost korisnika, kao i mrežna infrastruktura uzimajući u obzir gustoću tornjeva i omjer vrsta mreža (LTE, 3G, itd.).
Slika 2. Kašnjenja na primjeru radijusa od 2 km. Delhi, Indija.
Također, performanse mobilnih mreža variraju tijekom vremena. Slika 3 prikazuje srednju latenciju po danima u tjednu. Također smo uočili razlike u manjem opsegu, unutar jednog dana i sata.
Slika 3. Zadnje kašnjenja mogu značajno varirati između dana, ali za istog operatera.
Sve gore navedeno uzrokuje neučinkovitost TCP performansi u bežičnim mrežama. Međutim, prije traženja alternativa TCP-u, htjeli smo razviti precizno razumijevanje sljedećih točaka:
- je li TCP glavni krivac za repne latencije u našim aplikacijama?
- Imaju li moderne mreže značajna i različita povratna kašnjenja (RTT)?
- Kakav je utjecaj RTT-a i gubitka na performanse TCP-a?
TCP analiza izvedbe
Da bismo razumjeli kako smo analizirali performanse TCP-a, pogledajmo na brzinu kako TCP prenosi podatke od pošiljatelja do primatelja. Prvo, pošiljatelj uspostavlja TCP vezu, obavljajući trosmjernu vezu : Pošiljatelj šalje SYN paket, čeka SYN-ACK paket od primatelja, zatim šalje ACK paket. Dodatni drugi i treći prolaz troše se na uspostavljanje TCP veze. Primatelj potvrđuje primitak svakog paketa (ACK) kako bi osigurao pouzdanu isporuku.
Ako se paket ili ACK izgubi, pošiljatelj ponovno šalje nakon isteka vremena (RTO, ). RTO se izračunava dinamički na temelju različitih čimbenika, kao što je očekivano kašnjenje RTT-a između pošiljatelja i primatelja.
Slika 4. Razmjena paketa preko TCP/TLS-a uključuje mehanizam ponovnog slanja.
Kako bismo utvrdili kakav je učinak TCP-a u našim aplikacijama, pratili smo TCP pakete pomoću tjedan dana o borbenom prometu koji dolazi s indijskih rubnih poslužitelja. Zatim smo analizirali TCP veze pomoću . Osim toga, izradili smo Android aplikaciju koja šalje emulirani promet na testni poslužitelj, oponašajući stvarni promet što je više moguće. Pametni telefoni s ovom aplikacijom podijeljeni su nekolicini zaposlenika koji su nekoliko dana prikupljali logove.
Rezultati oba eksperimenta bili su međusobno usklađeni. Vidjeli smo visoke RTT latencije; vrijednosti repa bile su gotovo 6 puta veće od srednje vrijednosti; aritmetički prosjek kašnjenja je veći od 1 sekunde. Mnoge su veze bile s gubitkom, zbog čega je TCP ponovno poslao 3,5% svih paketa. U zakrčenim područjima kao što su zračne luke i željeznički kolodvori, vidjeli smo gubitke od 7%. Ovi rezultati bacaju sumnju na konvencionalno mišljenje da se oni koji se koriste u mobilnim mrežama značajno smanjiti gubitke na razini transporta. Ispod su rezultati testa iz aplikacije “simulator”:
Mrežna metrika
značenje
RTT, milisekunde [50%,75%, 95%,99%]
[350, 425, 725, 2300]
RTT divergencija, sekunde
U prosjeku ~1,2 s
Gubitak paketa na nestabilnim vezama
Prosječno ~3.5% (7% u preopterećenim područjima)
Gotovo polovica ovih veza imala je barem jedan gubitak paketa, od čega su većina bili SYN i SYN-ACK paketi. Većina TCP implementacija koristi RTO vrijednost od 1 sekunde za SYN pakete, koja se eksponencijalno povećava za naknadne gubitke. Vrijeme učitavanja aplikacije može se povećati jer TCP-u treba više vremena za uspostavljanje veze.
U slučaju podatkovnih paketa, visoke RTO vrijednosti uvelike smanjuju korisnu iskoristivost mreže u prisutnosti prolaznih gubitaka u bežičnim mrežama. Otkrili smo da je prosječno vrijeme ponovnog slanja približno 1 sekunda s repom odgode od gotovo 30 sekundi. Ove visoke latencije na TCP razini uzrokovale su istek vremena HTTPS-a i ponovne zahtjeve, dodatno povećavajući latenciju i neučinkovitost mreže.
Dok je 75. percentil izmjerenog RTT-a bio oko 425 ms, 75. percentil za TCP bio je gotovo 3 sekunde. Ovo upućuje na to da je gubitak uzrokovao da TCP treba 7-10 prolaza za uspješan prijenos podataka. To može biti posljedica neučinkovitog RTO izračuna, TCP-ove nesposobnosti da brzo odgovori na gubitak u prozoru i neučinkovitost algoritma za kontrolu zagušenja, koji ne razlikuje bežične gubitke od gubitaka zbog zagušenja mreže. Ispod su rezultati testova gubitka TCP-a:
TCP statistika gubitka paketa
Vrijednost
Postotak veza s najmanje 1 gubitkom paketa
45%
Postotak veza s gubicima tijekom postavljanja veze
30%
Postotak veza s gubicima tijekom razmjene podataka
76%
Distribucija kašnjenja u ponovnom prijenosu, sekunde [50%, 75%, 95%, 99%] [1, 2.8, 15, 28]
Distribucija broja ponovnih prijenosa za jedan paket ili TCP segment
[1,3,6,7]
Primjena QUIC-a
Izvorno razvijen od strane Googlea, QUIC je moderni transportni protokol s više niti koji radi povrh UDP-a. Trenutno je QUIC in (već smo napisali da postoje, takoreći, dvije verzije QUIC-a, zanimljivo - cca. prevoditelj). Kao što je prikazano na slici 5, QUIC je smješten pod HTTP/3 (zapravo, HTTP/2 iznad QUIC-a je HTTP/3, koji se sada intenzivno standardizira). Djelomično zamjenjuje HTTPS i TCP slojeve korištenjem UDP-a za formiranje paketa. QUIC podržava samo siguran prijenos podataka jer je TLS u potpunosti ugrađen u QUIC.
Slika 5: QUIC radi pod HTTP/3, zamjenjujući TLS, koji je prethodno radio pod HTTP/2.
Ispod su razlozi koji su nas uvjerili da koristimo QUIC za TCP pojačanje:
- 0-RTT uspostava veze. QUIC omogućuje ponovnu upotrebu autorizacija iz prethodnih veza, smanjujući broj sigurnosnih rukovanja. U budućnosti podržavat će 0-RTT, ali će i dalje biti potrebno trosmjerno TCP rukovanje.
- prevladavanje blokade HoL. HTTP/2 koristi jednu TCP vezu po klijentu za poboljšanje performansi, ali to može dovesti do blokiranja HoL (head-of-line). QUIC pojednostavljuje multipleksiranje i neovisno dostavlja zahtjeve aplikaciji.
- kontrola zagušenja. QUIC se nalazi na aplikacijskom sloju, što olakšava ažuriranje glavnog transportnog algoritma koji kontrolira slanje na temelju mrežnih parametara (broj gubitaka ili RTT). Većina TCP implementacija koristi algoritam , što nije optimalno za promet osjetljiv na kašnjenje. Nedavno razvijeni algoritmi poput , točnije modelirajte mrežu i optimizirajte kašnjenje. QUIC vam omogućuje korištenje BBR-a i ažuriranje ovog algoritma kako se koristi. .
- nadopunjavanje gubitaka. QUIC poziva dva TLP-a () prije nego što se aktivira RTO - čak i kada su gubici vrlo primjetni. Ovo se razlikuje od TCP implementacija. TLP ponovno šalje uglavnom zadnji paket (ili novi, ako postoji) kako bi pokrenuo brzo nadopunjavanje. Rukovanje repnim kašnjenjima posebno je korisno za način na koji Uber upravlja svojom mrežom, naime za kratke, sporadične prijenose podataka koji su osjetljivi na latenciju.
- optimizirani ACK. Budući da svaki paket ima jedinstveni redni broj, nema problema pakete kada se ponovno šalju. ACK paketi također sadrže vrijeme za obradu paketa i generiranje ACK-a na strani klijenta. Ove značajke osiguravaju da QUIC točnije izračunava RTT. ACK u QUIC-u podržava do 256 opsega , pomažući pošiljatelju da bude otporniji na miješanje paketa i koristi manje bajtova u procesu. Selektivni ACK () u TCP-u ne rješava ovaj problem u svim slučajevima.
- migracija veze. QUIC veze identificirane su 64-bitnim ID-om, tako da ako klijent promijeni IP adrese, stari ID veze može se nastaviti koristiti na novoj IP adresi bez prekida. Ovo je vrlo uobičajena praksa za mobilne aplikacije gdje se korisnik prebacuje između Wi-Fi i mobilnih veza.
Alternative za QUIC
Razmotrili smo alternativne pristupe rješavanju problema prije nego što smo odabrali QUIC.
Prvo što smo pokušali bilo je implementirati TPC PoP (točke prisutnosti) kako bismo prekinuli TCP veze bliže korisnicima. U suštini, PoP-ovi prekidaju TCP vezu s mobilnim uređajem koji je bliži mobilnoj mreži i proxy promet vraća na izvornu infrastrukturu. Bližim prekidanjem TCP-a potencijalno možemo smanjiti RTT i osigurati da TCP bolje reagira na dinamičko bežično okruženje. Međutim, naši eksperimenti su pokazali da većina RTT-a i gubitaka dolazi iz mobilnih mreža, a upotreba PoP-ova ne daje značajno poboljšanje performansi.
Također smo pogledali podešavanje TCP parametara. Postavljanje TCP stoga na našim heterogenim rubnim poslužiteljima bilo je teško jer TCP ima različite implementacije u različitim verzijama OS-a. Bilo je teško implementirati ovo i testirati različite mrežne konfiguracije. Konfiguriranje TCP-a izravno na mobilnim uređajima nije bilo moguće zbog nedostatka dozvola. Što je još važnije, značajke kao što su 0-RTT veze i poboljšano RTT predviđanje kritične su za arhitekturu protokola i stoga je nemoguće postići značajne prednosti samo podešavanjem TCP-a.
Konačno, procijenili smo nekoliko protokola temeljenih na UDP-u koji rješavaju probleme sa strujanjem videa - htjeli smo vidjeti hoće li ti protokoli pomoći u našem slučaju. Nažalost, imali su ozbiljan nedostatak u mnogim sigurnosnim postavkama, a također su zahtijevali dodatnu TCP vezu za metapodatke i kontrolne informacije.
Naše istraživanje je pokazalo da je QUIC možda jedini protokol koji može pomoći kod problema internetskog prometa, a pritom uzevši u obzir i sigurnost i performanse.
Integracija QUIC-a u platformu
Kako bismo uspješno ugradili QUIC i poboljšali izvedbu aplikacije u okruženjima s lošom povezanošću, zamijenili smo stari stog (HTTP/2 preko TLS/TCP) s QUIC protokolom. Koristili smo mrežnu knjižnicu od , koji sadrži originalnu, Google verziju protokola - gQUIC. Ova implementacija se također stalno poboljšava kako bi slijedila najnoviju IETF specifikaciju.
Prvo smo integrirali Cronet u naše Android aplikacije kako bismo dodali podršku za QUIC. Integracija je provedena na način da se maksimalno smanje troškovi migracije. Umjesto potpune zamjene starog mrežnog stoga koji je koristio knjižnicu , integrirali smo Cronet POD OKHttp API framework. Izvodeći integraciju na ovaj način, izbjegli smo promjene u našim mrežnim pozivima (koje koriste ) na razini API-ja.
Slično pristupu za Android uređaje, implementirali smo Cronet u Uberove aplikacije na iOS-u, presrećući HTTP promet s mreže koristeći . Ova apstrakcija, koju pruža iOS Foundation, obrađuje URL podatke specifične za protokol i osigurava da možemo integrirati Cronet u naše iOS aplikacije bez značajnih troškova migracije.
Dovršavanje QUIC-a na usluzi Google Cloud Balancers
Na pozadinskoj strani, QUIC dovršetak osigurava Google Cloud Load infrastruktura za uravnoteženje opterećenja, koja koristi zaglavlja u odgovorima za podršku QUIC. Općenito, balanser dodaje alt-svc zaglavlje svakom HTTP zahtjevu, a to već potvrđuje QUIC podršku za domenu. Kada Cronet klijent primi HTTP odgovor s ovim zaglavljem, koristi QUIC za sljedeće HTTP zahtjeve toj domeni. Nakon što balanser dovrši QUIC, naša infrastruktura izričito šalje ovu radnju preko HTTP2/TCP-a našim podatkovnim centrima.
Izvedba: Rezultati
Izlazna izvedba je glavni razlog naše potrage za boljim protokolom. Za početak smo napravili stalak sa kako biste saznali kako će se QUIC ponašati pod različitim mrežnim profilima. Kako bismo testirali izvedbu QUIC-a na mrežama u stvarnom svijetu, proveli smo eksperimente dok smo se vozili oko New Delhija koristeći emulirani mrežni promet vrlo sličan HTTP pozivima u putničkoj aplikaciji.
Eksperiment 1
Oprema za eksperiment:
- testirajte Android uređaje s OkHttp i Cronet skupovima kako biste osigurali da dopuštamo HTTPS promet preko TCP-a odnosno QUIC-a;
- emulacijski poslužitelj temeljen na Javi koji šalje istu vrstu HTTPS zaglavlja u odgovorima i učitava klijentske uređaje kako bi od njih primio zahtjeve;
- cloud proxy koji se fizički nalaze u blizini Indije za prekid TCP i QUIC veza. Dok smo za TCP završetak koristili obrnuti proxy na , bilo je teško pronaći obrnuti proxy otvorenog koda za QUIC. Sami smo izgradili obrnuti proxy za QUIC koristeći osnovni QUIC stack iz Chromiuma i u Chromium kao open source.
Slika 6. TCP u usporedbi s QUIC cestovnim testnim paketom sastojao se od Android uređaja s OkHttp i Cronet, cloud proxyjima za prekidanje veza i emulacijskim poslužiteljem.
Eksperiment 2
Kada je Google učinio QUIC dostupnim uz , upotrijebili smo isti inventar, ali s jednom preinakom: umjesto NGINX-a, uzeli smo Googleove balansere opterećenja za prekid TCP i QUIC veza s uređaja, kao i za usmjeravanje HTTPS prometa na emulacijski poslužitelj. Balanseri su distribuirani po cijelom svijetu, ali koriste PoP poslužitelj najbliži uređaju (zahvaljujući geolokaciji).
Slika 7. U drugom eksperimentu željeli smo usporediti kašnjenje završetka TCP-a i QUIC-a: korištenjem Google Clouda i korištenjem našeg proxyja u oblaku.
Kao rezultat toga, čekalo nas je nekoliko otkrića:
- terminacija putem PoP poboljšane TCP performanse. Budući da balanseri prekidaju TCP veze bliže korisnicima i visoko su optimizirani, to rezultira nižim RTT-ovima, što poboljšava TCP performanse. I premda je QUIC bio manje pogođen, ipak je nadmašio TCP u smislu smanjenja latencije repa (za 10-30 posto).
- zahvaćeni su repovi . Iako je naš QUIC proxy bio dalje od uređaja (oko 50 ms veća latencija) od Googleovih balansera opterećenja, isporučio je sličnu izvedbu - 15% smanjenja latencije u odnosu na 20% smanjenja u 99. percentilu za TCP. To sugerira da je prijelaz zadnje milje usko grlo u mreži.
Slika 8: Rezultati iz dva eksperimenta pokazuju da QUIC značajno nadmašuje TCP.
Borba protiv prometa
Inspirirani eksperimentiranjem, implementirali smo QUIC podršku u naše Android i iOS aplikacije. Proveli smo A/B testiranje kako bismo utvrdili utjecaj QUIC-a u gradovima u kojima Uber posluje. Općenito, primijetili smo značajno smanjenje repnih kašnjenja u obje regije, telekom operatere i vrstu mreže.
Grafikoni u nastavku prikazuju postotna poboljšanja u repovima (95 i 99 percentila) po makroregiji i različitim vrstama mreža - LTE, 3G, 2G.
Slika 9. U testovima borbe, QUIC je nadmašio TCP u smislu latencije.
Samo naprijed
Možda je ovo tek početak - puštanje QUIC-a u proizvodnju pružilo je nevjerojatne prilike za poboljšanje performansi aplikacija u stabilnim i nestabilnim mrežama, naime:
Povećana pokrivenost
Nakon analize izvedbe protokola u stvarnom prometu, vidjeli smo da je približno 80% sesija uspješno koristilo QUIC za Sve zahtjeva, dok je 15% sesija koristilo kombinaciju QUIC-a i TCP-a. Pretpostavljamo da je kombinacija nastala zbog isteka vremena Cronet knjižnice natrag na TCP, budući da ne može razlikovati stvarne kvarove UDP-a i loše mrežne uvjete. Trenutno tražimo rješenje za ovaj problem dok radimo na kasnijoj implementaciji QUIC-a.
QUIC optimizacija
Promet iz mobilnih aplikacija osjetljiv je na kašnjenje, ali nije osjetljiv na propusnost. Također, naše se aplikacije prvenstveno koriste na mobilnim mrežama. Na temelju eksperimenata, zadnje latencije su još uvijek visoke iako se koristi proxy za prekid TCP-a i QUIC-a blizu korisnika. Aktivno tražimo načine da poboljšamo upravljanje zagušenjem i poboljšamo učinkovitost QUIC algoritama za oporavak od gubitka.
S ovim i nekoliko drugih poboljšanja, planiramo poboljšati korisničko iskustvo bez obzira na mrežu i regiju, čineći praktičan i besprijekoran prijenos paketa dostupnijim diljem svijeta.
Izvor: www.habr.com