QUIC protokol je izuzetno zanimljiv za gledanje, zbog čega volimo pisati o njemu. Ali ako su prethodne publikacije o QUIC-u bile više historijske (lokalne, ako želite) prirode i hardvera, danas ćemo rado objaviti prijevod drugačije vrste – o pravoj primjeni protokola ćemo govoriti 2019. godine. Štaviše, ne govorimo o maloj infrastrukturi koja se nalazi u takozvanoj garaži, već o Uberu, koji posluje gotovo u cijelom svijetu. Kako su inženjeri kompanije došli do odluke da koriste QUIC u proizvodnji, kako su proveli testove i šta su vidjeli nakon što su ga pustili u proizvodnju - ispod reza.
Slike se mogu kliknuti. Uživajte u čitanju!
Uber ima globalnu skalu, odnosno 600 gradova prisutnosti, u svakom od kojih se aplikacija u potpunosti oslanja na bežični internet od više od 4500 mobilnih operatera. Korisnici očekuju da aplikacija ne bude samo brza, već u realnom vremenu – da bi se to postiglo, Uber aplikaciji je potrebna mala latencija i vrlo pouzdana veza. Jao, ali stog ne radi dobro u dinamičkim bežičnim mrežama sklonim gubicima. Shvatili smo da su u ovom slučaju niske performanse direktno povezane sa TCP implementacijama u jezgrima operativnog sistema.
Da bismo riješili problem, prijavili smo se , moderan protokol za multipleksiranje kanala koji nam daje veću kontrolu nad performansama 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 manjim kašnjenjem repa u odnosu na TCP. Primetili smo smanjenje u rasponu od 10-30% za HTTPS saobraćaj u aplikacijama za vozača i suvozača. QUIC nam je također dao kontrolu s kraja na kraj nad korisničkim paketima.
U ovom članku dijelimo naše iskustvo u optimizaciji TCP-a za Uber aplikacije koristeći stek koji podržava QUIC.
Najnovija tehnologija: TCP
Danas je TCP najčešće korišten transportni protokol za isporuku HTTPS prometa na Internetu. TCP obezbeđuje pouzdan tok bajtova, čime se nosi sa zagušenjem mreže i gubicima sloja veze. Široko rasprostranjena upotreba TCP-a za HTTPS promet je posljedica sveprisutnosti prvog (skoro svaki OS sadrži TCP), dostupnosti na većini infrastrukture (kao što su balanseri opterećenja, HTTPS proksiji i CDN-ovi) i gotove funkcionalnosti koja je dostupna na gotovo većini platformi i mreža.
Većina korisnika koristi našu aplikaciju u pokretu, a latencije TCP repa nisu bile ni blizu zahtjevima našeg HTTPS prometa u realnom vremenu. Jednostavno rečeno, korisnici širom svijeta su to iskusili - Slika 1 prikazuje kašnjenja u velikim gradovima:
Slika 1: Kašnjenje repa varira u svim Uberovim glavnim gradovima.
Iako je latencija u indijskim i brazilskim mrežama bila veća nego u SAD-u i Velikoj Britaniji, latencija repa je znatno veća od prosječne latencije. I to važi čak i za SAD i UK.
TCP over the air performanse
TCP je kreiran za žičan mreže, odnosno sa naglaskom na vrlo predvidljive veze. Kako god, bežični mreže imaju svoje karakteristike i poteškoće. Prvo, bežične mreže su podložne gubicima zbog smetnji i slabljenja signala. Na primjer, Wi-Fi mreže su osjetljive na mikrovalne, bluetooth i druge radio valove. Ćelijske mreže pate od gubitka signala () zbog refleksije/apsorpcije signala od objekata i zgrada, kao i od od susednih . To dovodi do značajnije (4-10 puta) i raznovrsnije i gubitak paketa u poređenju sa žičnom vezom.
Za borbu protiv fluktuacija i gubitaka propusnog opsega, ćelijske mreže obično koriste velike bafere za rafale saobraćaja. To može dovesti do prevelikog čekanja, što znači duža kašnjenja. Vrlo često TCP tretira ovo čekanje kao gubitak zbog produženog vremena čekanja, tako da TCP teži da releji i time popuni bafer. Ovaj problem je poznat kao (), a ovo je veoma savremeni internet.
Konačno, performanse mobilne mreže variraju u zavisnosti od operatera, regiona i vremena. Na slici 2, prikupili smo srednja kašnjenja HTTPS saobraćaja preko ćelija unutar raspona od 2 kilometra. Podaci prikupljeni za dva glavna mobilna operatera u Delhiju, Indija. Kao što vidite, performanse variraju od ćelije do ćelije. Takođe, produktivnost jednog operatera se razlikuje od produktivnosti drugog. Na to utječu faktori 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 gustinu tornjeva i omjer tipova mreža (LTE, 3G, itd.).
Slika 2. Kašnjenja na primjeru radijusa od 2 km. Delhi, Indija.
Takođe, performanse ćelijskih mreža variraju tokom vremena. Slika 3 prikazuje medijanu latencije po danu u sedmici. Također smo uočili razlike u manjem obimu, unutar jednog dana i sata.
Slika 3. Kašnjenja repa mogu značajno varirati između dana, ali za istog operatera.
Sve gore navedeno uzrokuje neefikasnost TCP performansi u bežičnim mrežama. Međutim, prije nego što smo tražili alternative TCP-u, željeli smo razviti precizno razumijevanje sljedećih tačaka:
- da li je TCP glavni krivac za kašnjenje repa u našim aplikacijama?
- Imaju li moderne mreže značajna i različita povratna kašnjenja (RTT)?
- Kakav je uticaj RTT-a i gubitka na TCP performanse?
Analiza performansi TCP
Da bismo razumjeli kako smo analizirali TCP performanse, pogledajmo na brzinu kako TCP prenosi podatke od pošiljaoca do primaoca. Prvo, pošiljalac uspostavlja TCP vezu, izvodeći trosmjernu : Pošiljalac šalje SYN paket, čeka SYN-ACK paket od primaoca, a zatim šalje ACK paket. Dodatni drugi i treći prolaz se troši na uspostavljanje TCP veze. Primalac potvrđuje prijem svakog paketa (ACK) kako bi osigurao pouzdanu isporuku.
Ako se izgubi paket ili ACK, pošiljalac ponovo šalje nakon isteka vremena (RTO, ). RTO se izračunava dinamički na osnovu različitih faktora, kao što je očekivano RTT kašnjenje između pošiljaoca i primaoca.
Slika 4. Razmjena paketa preko TCP/TLS-a uključuje mehanizam ponovnog prijenosa.
Da bismo utvrdili kako se TCP izvodi u našim aplikacijama, pratili smo TCP pakete koristeći sedmicu dana o borbenom prometu koji dolazi sa indijskih rubnih servera. Zatim smo analizirali TCP veze koristeći . Osim toga, kreirali smo Android aplikaciju koja šalje emulirani promet na test server, imitirajući stvarni promet što je više moguće. Pametni telefoni sa ovom aplikacijom podijeljeni su nekolicini zaposlenih, koji su prikupljali dnevnike tokom nekoliko dana.
Rezultati oba eksperimenta bili su konzistentni jedan s drugim. Vidjeli smo velike RTT latencije; rep vrijednosti su bile skoro 6 puta veće od srednje vrijednosti; aritmetički prosjek kašnjenja je veći od 1 sekunde. Mnoge veze su bile sa gubitkom, što je uzrokovalo da TCP ponovo pošalje 3,5% svih paketa. U zakrčenim područjima kao što su aerodromi i željezničke stanice, vidjeli smo 7% gubitaka. Ovi rezultati bacaju sumnju na konvencionalnu mudrost koju koriste u ćelijskim mrežama značajno smanjiti gubitke na nivou transporta. Ispod su rezultati testiranja iz aplikacije "simulator":
Mrežna metrika
Vrednosti
RTT, milisekunde [50%,75%, 95%,99%]
[350, 425, 725, 2300]
RTT divergencija, sekunde
U prosjeku ~1,2 s
Gubitak paketa na nestabilnim vezama
Prosjek ~3.5% (7% u preopterećenim područjima)
Gotovo polovina ovih veza imala je barem jedan gubitak paketa, većina SYN i SYN-ACK paketa. 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 da uspostavi veze.
U slučaju paketa podataka, visoke RTO vrijednosti uvelike smanjuju korisno korištenje mreže u prisustvu prolaznih gubitaka u bežičnim mrežama. Otkrili smo da je prosječno vrijeme retransmisije otprilike 1 sekunda sa kašnjenjem repa od skoro 30 sekundi. Ove velike latencije na TCP nivou uzrokovale su HTTPS timeoute i ponovne zahtjeve, dodatno povećavajući mrežno kašnjenje i neefikasnost.
Dok je 75. percentil izmjerenog RTT bio oko 425 ms, 75. percentil za TCP je bio skoro 3 sekunde. Ovo nagovještava da je gubitak uzrokovao da TCP treba 7-10 prolaza za uspješan prijenos podataka. Ovo može biti posljedica neefikasnog proračuna RTO-a, nesposobnosti TCP-a da brzo odgovori na gubitak u prozoru i neefikasnost algoritma za kontrolu zagušenja, koji ne pravi razliku između bežičnih gubitaka i gubitaka zbog zagušenja mreže. Ispod su rezultati testova gubitka TCP-a:
Statistika gubitka TCP paketa
vrijednost
Postotak veza s najmanje 1 gubitkom paketa
45%
Procenat veza sa gubicima tokom postavljanja veze
30%
Procenat veza sa gubicima tokom razmjene podataka
76%
Distribucija kašnjenja u retransmisiji, sekunde [50%, 75%, 95%,99%] [1, 2.8, 15, 28]
Distribucija broja retransmisija za jedan paket ili TCP segment
[1,3,6,7]
Primjena QUIC-a
Prvobitno razvijen od strane Google-a, QUIC je moderni transportni protokol sa više niti koji radi na vrhu UDP-a. Trenutno je QUIC in (već smo pisali da postoje, takoreći, dvije verzije QUIC-a, znatiželjno – cca. prevodilac). Kao što je prikazano na slici 5, QUIC je postavljen pod HTTP/3 (u stvari, HTTP/2 iznad QUIC-a je HTTP/3, koji se sada intenzivno standardizuje). Djelomično zamjenjuje HTTPS i TCP slojeve koristeći UDP 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 ranije radio pod HTTP/2.
U nastavku su razlozi koji su nas uvjerili da koristimo QUIC za TCP pojačanje:
- Uspostavljanje 0-RTT veze. QUIC dozvoljava ponovnu upotrebu autorizacija iz prethodnih veza, smanjujući broj sigurnosnih rukovanja. U budućnosti će podržavati 0-RTT, ali će i dalje biti potrebno trosmjerno TCP rukovanje.
- prevazilaženje HoL blokade. HTTP/2 koristi jednu TCP vezu po klijentu za poboljšanje performansi, ali to može dovesti do blokiranja HoL-a (head-of-line). QUIC pojednostavljuje multipleksiranje i samostalno dostavlja zahtjeve aplikaciji.
- kontrola zagušenja. QUIC se nalazi na sloju aplikacije, što olakšava ažuriranje glavnog transportnog algoritma koji kontrolira slanje na osnovu mrežnih parametara (broj gubitaka ili RTT). Većina TCP implementacija koristi algoritam , što nije optimalno za saobraćaj osetljiv na kašnjenje. Nedavno razvijeni algoritmi poput , preciznije modelira mrežu i optimizira kašnjenje. QUIC vam omogućava da koristite BBR i ažurirate ovaj algoritam kako se koristi. .
- nadoknadu gubitaka. QUIC poziva dva TLP-a () prije nego što se RTO aktivira - čak i kada su gubici vrlo primjetni. Ovo se razlikuje od TCP implementacije. TLP reemituje uglavnom poslednji paket (ili novi, ako postoji) da bi pokrenuo brzo dopunjavanje. Rukovanje kašnjenjima u repu posebno je korisno za način na koji Uber upravlja svojom mrežom, naime za kratke, sporadične i prijenose podataka osjetljive na kašnjenje.
- optimiziran ACK. Pošto svaki paket ima jedinstveni redni broj, nema problema pakete kada se ponovo prenose. ACK paketi također sadrže vrijeme za obradu paketa i generiranje ACK na strani klijenta. Ove karakteristike osiguravaju da QUIC preciznije izračunava RTT. ACK u QUIC-u podržava do 256 opsega , pomažući pošiljaocu da bude otporniji na miješanje paketa i da koristi manje bajtova u procesu. Selektivni ACK () u TCP-u ne rješava ovaj problem u svim slučajevima.
- migracija veze. QUIC veze se identificiraju 64-bitnim ID-om, tako da ako klijent promijeni IP adrese, stari ID veze može nastaviti da se koristi 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 QUIC-u
Razmotrili smo alternativne pristupe rješavanju problema prije nego što smo odabrali QUIC.
Prva stvar koju smo pokušali je da implementiramo TPC PoPs (Points of Presence) da prekinemo TCP veze bliže korisnicima. U suštini, PoP-ovi prekidaju TCP vezu s mobilnim uređajem koji je bliži ćelijskoj mreži i proksira promet natrag u originalnu infrastrukturu. Ukidanjem TCP bliže, možemo potencijalno 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 ćelijskih mreža, a korištenje PoP-a ne pruža značajno poboljšanje performansi.
Takođe smo pogledali podešavanje TCP parametara. Postavljanje TCP steka na našim heterogenim rubnim serverima bilo je teško jer TCP ima različite implementacije u različitim verzijama OS-a. Bilo je teško ovo implementirati i testirati različite mrežne konfiguracije. Konfiguriranje TCP-a direktno na mobilnim uređajima nije bilo moguće zbog nedostatka dozvola. Što je još važnije, karakteristike kao što su 0-RTT veze i poboljšano RTT predviđanje su kritične za arhitekturu protokola, i stoga je nemoguće postići značajne prednosti samo podešavanjem TCP-a.
Konačno, procijenili smo nekoliko protokola zasnovanih na UDP-u koji rješavaju probleme sa video streamingom — htjeli smo vidjeti da li će ti protokoli pomoći u našem slučaju. Nažalost, mnogo im je nedostajalo u mnogim sigurnosnim postavkama, a također je bila potrebna dodatna TCP veza za metapodatke i kontrolne informacije.
Naše istraživanje je pokazalo da je QUIC možda jedini protokol koji može pomoći u rješavanju problema internetskog prometa, uzimajući u obzir i sigurnost i performanse.
Integracija QUIC-a u platformu
Da bismo uspješno ugradili QUIC i poboljšali performanse aplikacije u okruženjima sa lošom konektivnošću, zamijenili smo stari stek (HTTP/2 preko TLS/TCP) s QUIC protokolom. Koristili smo mrežnu biblioteku из , koji sadrži originalnu, Google verziju protokola - gQUIC. Ova implementacija se također stalno poboljšava kako bi pratila najnoviju IETF specifikaciju.
Prvo smo integrirali Cronet u naše Android aplikacije kako bismo dodali podršku za QUIC. Integracija je obavljena na način da se što više smanje troškovi migracije. Umjesto da u potpunosti zamijenite stari mrežni stog koji je koristio biblioteku , integrirali smo Cronet ISPOD OkHttp API okvira. Izvodeći integraciju na ovaj način, izbjegli smo promjene u našim mrežnim pozivima (koje koriste ) na nivou API-ja.
Slično pristupu za Android uređaje, implementirali smo Cronet u Uber aplikacije na iOS-u, presrećući HTTP promet s mreže koristeći . Ova apstrakcija, koju je obezbijedila 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 Google Cloud Balancerima
Sa pozadinske strane, QUIC dovršenje je omogućeno pomoću Google Cloud infrastrukture za balansiranje opterećenja, koja koristi zaglavlja u odgovorima za podršku QUIC-u. Općenito, balanser dodaje alt-svc zaglavlje svakom HTTP zahtjevu i to već potvrđuje QUIC podršku za domen. Kada Cronet klijent primi HTTP odgovor s ovim zaglavljem, koristi QUIC za naknadne HTTP zahtjeve za tu domenu. Kada balanser završi QUIC, naša infrastruktura eksplicitno šalje ovu radnju preko HTTP2/TCP u naše centre podataka.
Performanse: Rezultati
Izlazne performanse su glavni razlog naše potrage za boljim protokolom. Za početak smo kreirali štand sa da saznate kako će se QUIC ponašati pod različitim mrežnim profilima. Da bismo testirali performanse QUIC-a na mrežama u stvarnom svijetu, izvodili smo eksperimente dok smo se vozili po New Delhiju koristeći emulirani mrežni promet vrlo sličan HTTP pozivima u aplikaciji za putnike.
Eksperiment 1
Oprema za eksperiment:
- testirajte Android uređaje sa OkHttp i Cronet stekovima kako biste bili sigurni da dozvoljavamo HTTPS promet preko TCP-a i QUIC-a;
- emulacijski server baziran na Javi koji šalje isti tip HTTPS zaglavlja u odgovorima i učitava klijentske uređaje da prima zahtjeve od njih;
- cloud proksije koji se fizički nalaze u blizini Indije kako bi prekinuli TCP i QUIC veze. Dok smo za TCP terminaciju koristili reverse proxy on , bilo je teško pronaći obrnuti proxy otvorenog koda za QUIC. Sami smo napravili reverzni proxy za QUIC koristeći osnovni QUIC stack iz Chromiuma i to u krom kao open source.
Slika 6. TCP vs QUIC paket za cestovni test sastojao se od Android uređaja sa OkHttp i Cronet, proxy servera u oblaku za prekid veze i servera za emulaciju.
Eksperiment 2
Kada je Google učinio QUIC dostupnim sa , koristili smo isti inventar, ali sa jednom modifikacijom: umjesto NGINX-a, uzeli smo Google balansatore opterećenja da prekinemo TCP i QUIC veze sa uređaja, kao i da usmjerimo HTTPS promet na emulacijski server. Balanseri su distribuirani po cijelom svijetu, ali koriste PoP server koji je najbliži uređaju (zahvaljujući geolokaciji).
Slika 7. U drugom eksperimentu, željeli smo uporediti kašnjenje završetka TCP-a i QUIC-a: korištenjem Google Cloud-a i korištenjem našeg proxyja u oblaku.
Kao rezultat toga, čekalo nas je nekoliko otkrića:
- završetak preko PoP-a poboljšane TCP performanse. Pošto balanseri prekidaju TCP veze bliže korisnicima i veoma su optimizovani, to rezultira nižim RTT-ovima, što poboljšava TCP performanse. Iako je QUIC bio manje pogođen, ipak je nadmašio TCP u smislu smanjenja kašnjenja repa (za 10-30 posto).
- repovi su zahvaćeni . 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čne performanse - 15% smanjenje kašnjenja u odnosu na 20% smanjenje u 99. percentilu za TCP. Ovo sugerira da je tranzicija zadnje milje usko grlo u mreži.
Slika 8: Rezultati dva eksperimenta pokazuju da QUIC značajno nadmašuje TCP.
Borbeni saobraćaj
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, vidjeli smo značajno smanjenje kašnjenja repa u oba regiona, telekom operaterima i vrsti mreže.
Grafikoni ispod pokazuju procentualna poboljšanja u repovima (95 i 99 percentila) po makroregiji i različitim tipovima mreža - LTE, 3G, 2G.
Slika 9. U borbenim testovima, QUIC je nadmašio TCP u smislu kašnjenja.
Samo napred
Možda je ovo samo početak - puštanje QUIC-a u proizvodnju pružilo je nevjerovatne mogućnosti za poboljšanje performansi aplikacija u stabilnim i nestabilnim mrežama, naime:
Povećana pokrivenost
Analizirajući performanse protokola u stvarnom saobraćaju, vidjeli smo da je otprilike 80% sesija uspješno koristilo QUIC za всех zahtjeva, dok je 15% sesija koristilo kombinaciju QUIC-a i TCP-a. Pretpostavljamo da je kombinacija uzrokovana timeoutom Cronet biblioteke na TCP, budući da ne može napraviti razliku između stvarnih kvarova UDP-a i loših mrežnih uvjeta. Trenutno tražimo rješenje za ovaj problem dok radimo na naknadnoj implementaciji QUIC-a.
QUIC optimizacija
Promet iz mobilnih aplikacija je osjetljiv na kašnjenje, ali ne i na propusni opseg. Također, naše aplikacije se prvenstveno koriste na mobilnim mrežama. Na osnovu eksperimenata, latencije repa su i dalje velike iako se koristi proxy za ukidanje TCP-a i QUIC-a blizu korisnika. Aktivno tražimo načine da poboljšamo upravljanje zagušenjima i poboljšamo efikasnost QUIC algoritama za vraćanje gubitaka.
Sa 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 transport paketa dostupnijim širom svijeta.
izvor: www.habr.com