Protokol QUIC je izjemno zanimiv za opazovanje, zato radi pišemo o njem. A če so bile prejšnje objave o QUIC bolj zgodovinske (lokalne zgodovine, če želite) narave in strojne opreme, danes z veseljem objavljamo prevod drugačne vrste - o resnični uporabi protokola bomo govorili v letu 2019. Poleg tega ne govorimo o majhni infrastrukturi v tako imenovani garaži, ampak o Uberju, ki deluje skoraj po vsem svetu. Kako so inženirji podjetja prišli do odločitve za uporabo QUIC v proizvodnji, kako so izvedli teste in kaj so videli po uvedbi v proizvodnjo - spodaj.
Slike so klikljive. Uživajte v branju!
Uber je globalno razsežen, in sicer je prisoten v 600 mestih, v vsakem od njih pa se aplikacija v celoti opira na brezžični internet več kot 4500 mobilnih operaterjev. Uporabniki pričakujejo, da aplikacija ne bo samo hitra, ampak tudi v realnem času – da bi to dosegla, aplikacija Uber potrebuje nizko zakasnitev in zelo zanesljivo povezavo. Žal, ampak sklad ne deluje dobro v dinamičnih brezžičnih omrežjih, ki so nagnjena k izgubam. Ugotovili smo, da je v tem primeru nizka zmogljivost neposredno povezana z implementacijami TCP v jedrih operacijskega sistema.
Za rešitev problema smo se prijavili , sodoben protokol za multipleksiranje kanalov, ki nam omogoča večji nadzor nad delovanjem transportnega protokola. Trenutno delovna skupina standardizira QUIC kot .
Po obsežnem testiranju smo ugotovili, da bi implementacija QUIC v naši aplikaciji povzročila nižje zakasnitve repa v primerjavi s TCP. Opazili smo zmanjšanja v razponu od 10 do 30 % za promet HTTPS v aplikacijah za voznika in potnika. QUIC nam je omogočil tudi nadzor nad uporabniškimi paketi od konca do konca.
V tem članku delimo naše izkušnje pri optimizaciji TCP za aplikacije Uber z uporabo sklada, ki podpira QUIC.
Najnovejša tehnologija: TCP
Danes je TCP najpogosteje uporabljen transportni protokol za dostavo prometa HTTPS na internetu. TCP zagotavlja zanesljiv tok bajtov, s čimer se spopada z zastoji omrežja in izgubami na povezovalnem sloju. Široka uporaba TCP za promet HTTPS je posledica vseprisotnosti prvega (skoraj vsak operacijski sistem vsebuje TCP), razpoložljivosti na večini infrastrukture (kot so izravnalniki obremenitve, strežniki proxy HTTPS in CDN) in funkcionalnosti, ki je na voljo takoj po namestitvi. na skoraj večini platform in omrežij.
Večina uporabnikov uporablja našo aplikacijo na poti, zadnje zakasnitve TCP pa niso bile niti blizu zahtevam našega prometa HTTPS v realnem času. Preprosto povedano, uporabniki po vsem svetu so to izkusili – Slika 1 prikazuje zamude v večjih mestih:
Slika 1: Zakasnitev repa se razlikuje po glavnih Uberjevih mestih.
Čeprav je bila zakasnitev v indijskih in brazilskih omrežjih višja kot v ZDA in Združenem kraljestvu, je zakasnitev repa znatno višja od povprečne zakasnitve. In to velja celo za ZDA in Veliko Britanijo.
Zmogljivost TCP po zraku
TCP je bil ustvarjen za ožičen omrežjih, torej s poudarkom na zelo predvidljivih povezavah. vendar brezžično omrežja imajo svoje značilnosti in težave. Prvič, brezžična omrežja so dovzetna za izgube zaradi motenj in oslabitve signala. Omrežja Wi-Fi so na primer občutljiva na mikrovalovne pečice, bluetooth in druge radijske valove. Mobilna omrežja trpijo zaradi izgube signala () zaradi odboja/absorpcije signala od predmetov in zgradb ter od iz sosednjih . To vodi do pomembnejšega (4-10-krat) in bolj raznolikega in izguba paketov v primerjavi z žično povezavo.
Za boj proti nihanjem in izgubam pasovne širine mobilna omrežja običajno uporabljajo velike medpomnilnike za izbruhe prometa. To lahko privede do predolgih čakalnih vrst, kar pomeni daljše zamude. Zelo pogosto TCP obravnava to čakalno vrsto kot odpadek zaradi podaljšane časovne omejitve, zato TCP teži k posredovanju in s tem polni medpomnilnik. Ta težava je znana kot (), in to je zelo sodobni internet.
Nazadnje, zmogljivost mobilnega omrežja se razlikuje glede na operaterja, regijo in čas. Na sliki 2 smo zbrali povprečne zakasnitve prometa HTTPS med celicami v območju 2 kilometra. Podatki, zbrani za dva velika mobilna operaterja v Delhiju v Indiji. Kot lahko vidite, se zmogljivost razlikuje od celice do celice. Prav tako se produktivnost enega operaterja razlikuje od produktivnosti drugega. Na to vplivajo dejavniki, kot so vzorci vstopa v omrežje ob upoštevanju časa in lokacije, mobilnost uporabnikov, pa tudi omrežna infrastruktura ob upoštevanju gostote stolpov in razmerja med vrstami omrežij (LTE, 3G itd.).
Slika 2. Zamude na primeru radija 2 km. Delhi, Indija.
Poleg tega se zmogljivost mobilnih omrežij s časom spreminja. Slika 3 prikazuje mediano zakasnitev glede na dan v tednu. Opazovali smo tudi razlike v manjšem obsegu, znotraj enega dneva in ure.
Slika 3. Zakasnitve repa se lahko med dnevi močno razlikujejo, vendar za istega operaterja.
Vse našteto povzroča, da je delovanje TCP v brezžičnih omrežjih neučinkovito. Preden pa smo iskali alternative za TCP, smo želeli razviti natančno razumevanje naslednjih točk:
- ali je TCP glavni krivec za repne zakasnitve v naših aplikacijah?
- Ali imajo sodobna omrežja precejšnje in raznolike povratne zakasnitve (RTT)?
- Kakšen je vpliv RTT in izgube na zmogljivost TCP?
Analiza zmogljivosti TCP
Da bi razumeli, kako smo analizirali zmogljivost TCP, si na hitro oglejmo, kako TCP prenaša podatke od pošiljatelja do prejemnika. Najprej pošiljatelj vzpostavi povezavo TCP, ki izvaja trosmerno povezavo : Pošiljatelj pošlje paket SYN, počaka na paket SYN-ACK od prejemnika in nato pošlje paket ACK. Dodaten drugi in tretji prehod se porabita za ustvarjanje povezave TCP. Prejemnik potrdi prejem vsakega paketa (ACK), da zagotovi zanesljivo dostavo.
Če se paket ali ACK izgubi, pošlje pošiljatelj po časovni omejitvi (RTO, ). RTO se izračuna dinamično na podlagi različnih dejavnikov, kot je pričakovana zakasnitev RTT med pošiljateljem in prejemnikom.
Slika 4. Izmenjava paketov prek TCP/TLS vključuje mehanizem za ponovno pošiljanje.
Da bi ugotovili, kako deluje TCP v naših aplikacijah, smo spremljali pakete TCP z uporabo za en teden o bojnem prometu, ki prihaja iz indijskih robnih strežnikov. Nato smo analizirali povezave TCP z uporabo . Poleg tega smo izdelali aplikacijo za Android, ki pošilja emuliran promet na testni strežnik in čim bolj posnema resnični promet. Pametne telefone s to aplikacijo smo razdelili več zaposlenim, ki so več dni zbirali dnevnike.
Rezultati obeh poskusov so bili med seboj skladni. Videli smo visoke zakasnitve RTT; vrednosti repa so bile skoraj 6-krat višje od mediane vrednosti; aritmetično povprečje zamud je več kot 1 sekundo. Veliko povezav je bilo izgubljenih, zaradi česar je TCP ponovno poslal 3,5 % vseh paketov. Na preobremenjenih območjih, kot so letališča in železniške postaje, smo opazili 7-odstotne izgube. Ti rezultati dvomijo o konvencionalni modrosti, da se tisti, ki se uporabljajo v celičnih omrežjih občutno zmanjšati izgube na transportni ravni. Spodaj so rezultati testa iz aplikacije “simulator”:
Meritve omrežja
Vrednote
RTT, milisekunde [50 %, 75 %, 95 %, 99 %]
[350, 425, 725, 2300]
Razhajanje RTT, sekunde
V povprečju ~1,2 s
Izguba paketov pri nestabilnih povezavah
Povprečje ~3.5 % (7 % na preobremenjenih območjih)
Pri skoraj polovici teh povezav je prišlo do izgube vsaj enega paketa, večina paketov SYN in SYN-ACK. Večina izvedb TCP uporablja vrednost RTO 1 sekunde za pakete SYN, ki se eksponentno poveča za poznejše izgube. Časi nalaganja aplikacij se lahko podaljšajo, ker TCP vzpostavljanje povezav traja dlje.
V primeru podatkovnih paketov visoke vrednosti RTO močno zmanjšajo koristno uporabo omrežja ob prisotnosti prehodnih izgub v brezžičnih omrežjih. Ugotovili smo, da je povprečni čas ponovnega prenosa približno 1 sekunda z zakasnitvijo repa skoraj 30 sekund. Te visoke zakasnitve na ravni TCP so povzročile časovne omejitve HTTPS in ponovne zahteve, kar je dodatno povečalo zakasnitev in neučinkovitost omrežja.
Medtem ko je bil 75. percentil izmerjenega RTT okoli 425 ms, je bil 75. percentil za TCP skoraj 3 sekunde. To namiguje, da je izguba povzročila, da je TCP potreboval 7-10 prehodov za uspešen prenos podatkov. To je lahko posledica neučinkovitega izračuna RTO, TCP-jeve nezmožnosti hitrega odziva na izgubo v oknu in neučinkovitost algoritma za nadzor prezasedenosti, ki ne razlikuje med izgubami brezžičnega omrežja in izgubami zaradi prezasedenosti omrežja. Spodaj so rezultati testov izgube TCP:
Statistika izgube paketov TCP
Vrednost
Odstotek povezav z vsaj 1 izgubo paketa
45%
Odstotek povezav z izgubami med nastavitvijo povezave
30%
Odstotek povezav z izgubami med izmenjavo podatkov
76%
Porazdelitev zakasnitev pri ponovnem prenosu, sekunde [50 %, 75 %, 95 %, 99 %] [1, 2.8, 15, 28]
Porazdelitev števila ponovnih prenosov za en paket ali TCP segment
[1,3,6,7]
Uporaba QUIC
QUIC, ki ga je prvotno razvil Google, je večniten sodoben transportni protokol, ki deluje poleg UDP. Trenutno je QUIC noter (napisali smo že, da obstajata tako rekoč dve različici QUIC, radovedno – pribl. prevajalec). Kot je prikazano na sliki 5, je QUIC postavljen pod HTTP/3 (dejansko je HTTP/2 na vrhu QUIC HTTP/3, ki se zdaj intenzivno standardizira). Delno nadomešča ravni HTTPS in TCP z uporabo UDP za oblikovanje paketov. QUIC podpira samo varen prenos podatkov, saj je TLS v celoti vgrajen v QUIC.
Slika 5: QUIC deluje pod HTTP/3 in nadomešča TLS, ki je prej deloval pod HTTP/2.
Spodaj so razlogi, ki so nas prepričali v uporabo QUIC za ojačanje TCP:
- Vzpostavitev povezave 0-RTT. QUIC omogoča ponovno uporabo avtorizacij iz prejšnjih povezav, kar zmanjša število varnostnih rokovanj. V prihodnosti bo podpiral 0-RTT, vendar bo še vedno potrebno tristransko rokovanje TCP.
- premagovanje blokade HoL. HTTP/2 uporablja eno povezavo TCP na odjemalca za izboljšanje zmogljivosti, vendar lahko to povzroči blokiranje HoL (head-of-line). QUIC poenostavlja multipleksiranje in neodvisno dostavlja zahteve aplikaciji.
- nadzor zastojev. QUIC se nahaja na aplikacijski ravni, kar olajša posodabljanje glavnega transportnega algoritma, ki nadzoruje pošiljanje na podlagi omrežnih parametrov (število izgub ali RTT). Večina implementacij TCP uporablja algoritem , kar ni optimalno za promet, občutljiv na zakasnitev. Nedavno razviti algoritmi, kot je , natančneje modelirajte omrežje in optimizirajte zakasnitev. QUIC vam omogoča uporabo BBR in posodabljanje tega algoritma, ko se uporablja. .
- dopolnjevanje izgub. QUIC kliče dva TLP-ja (), preden se sproži RTO – tudi ko so izgube zelo opazne. To se razlikuje od implementacij TCP. TLP ponovno odda predvsem zadnji paket (ali novega, če obstaja), da sproži hitro dopolnitev. Obravnava repnih zamud je še posebej uporabna za način, kako Uber upravlja svoje omrežje, in sicer za kratke, občasne in na zakasnitve občutljive prenose podatkov.
- optimiziran ACK. Ker ima vsak paket edinstveno zaporedno številko, ni težav pakete, ko so ti ponovno poslani. Paketi ACK vsebujejo tudi čas za obdelavo paketa in ustvarjanje ACK na strani odjemalca. Te funkcije zagotavljajo, da QUIC natančneje izračuna RTT. ACK v QUIC podpira do 256 pasov , ki pomaga pošiljatelju, da je bolj odporen na mešanje paketov in porabi manj bajtov v procesu. Selektivni ACK () v TCP ne reši te težave v vseh primerih.
- selitev povezave. Povezave QUIC so identificirane s 64-bitnim ID-jem, tako da če odjemalec spremeni naslove IP, se lahko stari ID povezave še naprej uporablja na novem naslovu IP brez prekinitev. To je zelo pogosta praksa za mobilne aplikacije, kjer uporabnik preklaplja med Wi-Fi in mobilnimi povezavami.
Alternative za QUIC
Preden smo izbrali QUIC, smo razmislili o alternativnih pristopih k reševanju problema.
Prva stvar, ki smo jo poskusili, je bila uvesti TPC PoPs (točke prisotnosti), da bi prekinili povezave TCP bližje uporabnikom. V bistvu PoP-ji prekinejo povezavo TCP z mobilno napravo, ki je bližje mobilnemu omrežju, in preusmerijo promet nazaj v prvotno infrastrukturo. Če prekinemo TCP bližje, lahko potencialno zmanjšamo RTT in zagotovimo, da se TCP bolj odziva na dinamično brezžično okolje. Vendar pa so naši poskusi pokazali, da večina RTT in izgube izvira iz mobilnih omrežij, uporaba PoPs pa ne zagotavlja bistvenega izboljšanja zmogljivosti.
Ogledali smo si tudi nastavitev parametrov TCP. Nastavitev sklada TCP na naših heterogenih robnih strežnikih je bila težavna, ker ima TCP različne izvedbe v različnih različicah OS. To je bilo težko implementirati in preizkusiti različne konfiguracije omrežja. Konfiguracija TCP neposredno na mobilnih napravah ni bila mogoča zaradi pomanjkanja dovoljenj. Še pomembneje pa je, da so funkcije, kot so povezave 0-RTT in izboljšana napoved RTT, ključnega pomena za arhitekturo protokola, zato je nemogoče doseči bistvene koristi samo s prilagajanjem TCP.
Na koncu smo ovrednotili več protokolov, ki temeljijo na UDP in odpravljajo težave pri pretakanju videa – želeli smo videti, ali bi ti protokoli pomagali v našem primeru. Na žalost so imeli veliko pomanjkljivosti v številnih varnostnih nastavitvah, poleg tega pa so zahtevali dodatno povezavo TCP za metapodatke in nadzorne informacije.
Naše raziskave so pokazale, da je QUIC morda edini protokol, ki lahko pomaga pri problemu internetnega prometa, pri tem pa upošteva tako varnost kot zmogljivost.
Integracija QUIC-a v platformo
Za uspešno vgradnjo QUIC in izboljšanje delovanja aplikacij v okoljih s slabo povezljivostjo smo zamenjali stari sklad (HTTP/2 prek TLS/TCP) s protokolom QUIC. Uporabili smo mrežno knjižnico z dne , ki vsebuje izvirno, Googlovo različico protokola – gQUIC. Ta izvedba se tudi nenehno izboljšuje, da bi sledila najnovejši specifikaciji IETF.
Cronet smo najprej integrirali v naše aplikacije za Android, da smo dodali podporo za QUIC. Integracijo smo izvedli tako, da smo čim bolj znižali stroške migracije. Namesto popolne zamenjave starega omrežnega sklada, ki je uporabljal knjižnico , smo Cronet integrirali POD okvir OkHttp API. S takšno integracijo smo se izognili spremembam naših omrežnih klicev (ki jih uporablja ) na ravni API-ja.
Podobno kot pri napravah s sistemom Android smo Cronet implementirali v aplikacije Uber v sistemu iOS in prestregli promet HTTP iz omrežja. z uporabo . Ta abstrakcija, ki jo zagotavlja iOS Foundation, obravnava podatke URL-jev, specifične za protokol, in zagotavlja, da lahko integriramo Cronet v naše aplikacije iOS brez znatnih stroškov selitve.
Dokončanje QUIC na Google Cloud Balancers
Na zaledni strani dokončanje QUIC zagotavlja infrastruktura za uravnoteženje obremenitve Google Cloud, ki uporablja glave v odgovorih za podporo QUIC. Na splošno uravnoteženje vsaki zahtevi HTTP doda glavo alt-svc in to že potrdi podporo QUIC za domeno. Ko odjemalec Cronet prejme odgovor HTTP s to glavo, uporabi QUIC za nadaljnje zahteve HTTP do te domene. Ko izravnalnik dokonča QUIC, naša infrastruktura izrecno pošlje to dejanje prek HTTP2/TCP v naše podatkovne centre.
Učinkovitost: Rezultati
Izhodna zmogljivost je glavni razlog za naše iskanje boljšega protokola. Za začetek smo izdelali stojalo z da ugotovite, kako se bo QUIC obnašal pod različnimi omrežnimi profili. Da bi preizkusili delovanje QUIC v omrežjih v resničnem svetu, smo izvajali poskuse med vožnjo po New Delhiju z uporabo emuliranega omrežnega prometa, ki je zelo podoben klicem HTTP v potniški aplikaciji.
Poskus 1
Oprema za poskus:
- preizkusite naprave Android s skladi OkHttp in Cronet, da zagotovite, da dovolimo promet HTTPS prek TCP oziroma QUIC;
- emulacijski strežnik, ki temelji na Javi, ki pošilja isto vrsto glav HTTPS v odgovorih in nalaga odjemalske naprave, da od njih prejme zahteve;
- posredniki v oblaku, ki so fizično locirani blizu Indije, za prekinitev povezav TCP in QUIC. Medtem ko smo za zaključek TCP uporabili obratni proxy na , je bilo težko najti odprtokodni obratni proxy za QUIC. Sami smo zgradili obratni proxy za QUIC z uporabo osnovnega sklada QUIC iz Chromiuma in v krom kot odprtokodno.
Slika 6. Nabor cestnih preskusov TCP v primerjavi s QUIC je bil sestavljen iz naprav Android z OkHttp in Cronet, posrednikov v oblaku za prekinitev povezav in emulacijskega strežnika.
Poskus 2
Ko je Google dal na voljo QUIC z , smo uporabili isti inventar, vendar z eno spremembo: namesto NGINX smo vzeli Googlove uravnoteženje obremenitve za prekinitev povezav TCP in QUIC iz naprav ter za usmerjanje prometa HTTPS na emulacijski strežnik. Izravnalniki so razdeljeni po vsem svetu, vendar uporabljajo strežnik PoP, ki je najbližji napravi (zahvaljujoč geolokaciji).
Slika 7. V drugem poskusu smo želeli primerjati zakasnitev dokončanja TCP in QUIC: z uporabo Google Cloud in z uporabo našega posrednika v oblaku.
Posledično nas je čakalo več razodetij:
- prekinitev prek PoP izboljšana zmogljivost TCP. Ker izravnalniki prekinejo povezave TCP bližje uporabnikom in so zelo optimizirani, ima to za posledico nižje RTT-je, kar izboljša zmogljivost TCP. In čeprav je bil QUIC manj prizadet, je še vedno presegel TCP v smislu zmanjšanja zakasnitve repa (za 10–30 odstotkov).
- repi so prizadeti . Čeprav je bil naš proxy QUIC dlje od naprav (približno 50 ms večja zakasnitev) kot Googlovi izravnalniki obremenitve, je zagotovil podobno zmogljivost – 15-odstotno zmanjšanje zakasnitve v primerjavi z 20-odstotnim zmanjšanjem v 99. percentilu za TCP. To nakazuje, da je prehod zadnje milje ozko grlo v omrežju.
Slika 8: Rezultati dveh poskusov kažejo, da je QUIC bistveno boljši od TCP.
Boj proti prometu
Po navdihu eksperimentiranja smo implementirali podporo QUIC v naše aplikacije za Android in iOS. Izvedli smo A/B testiranje, da bi ugotovili vpliv QUIC v mestih, kjer deluje Uber. Na splošno smo opazili znatno zmanjšanje zakasnitev v obeh regijah, telekomunikacijskih operaterjih in vrsti omrežja.
Spodnji grafi prikazujejo odstotke izboljšav v repih (95 in 99 percentilov) po makroregijah in različnih vrstah omrežij – LTE, 3G, 2G.
Slika 9. V bojnih testih je QUIC prekašal TCP v smislu zakasnitve.
Samo naprej
Morda je to šele začetek – izdaja QUIC-a v produkcijo je ponudila neverjetne priložnosti za izboljšanje zmogljivosti aplikacij v stabilnih in nestabilnih omrežjih, in sicer:
Povečana pokritost
Po analizi delovanja protokola v realnem prometu smo ugotovili, da je približno 80 % sej uspešno uporabilo QUIC za Vse zahtev, medtem ko je 15 % sej uporabljalo kombinacijo QUIC in TCP. Predvidevamo, da je kombinacija posledica časovne omejitve knjižnice Cronet nazaj na TCP, saj ne more razlikovati med resničnimi napakami UDP in slabimi omrežnimi pogoji. Trenutno iščemo rešitev za to težavo, medtem ko si prizadevamo za kasnejšo implementacijo QUIC.
QUIC optimizacija
Promet iz mobilnih aplikacij je občutljiv na zakasnitev, ni pa občutljiv na pasovno širino. Prav tako se naše aplikacije uporabljajo predvsem v mobilnih omrežjih. Na podlagi poskusov so zadnje zakasnitve še vedno visoke, čeprav se za prekinitev TCP in QUIC uporablja proxy blizu uporabnikov. Aktivno iščemo načine za izboljšanje upravljanja zastojev in izboljšanje učinkovitosti algoritmov QUIC za povrnitev izgube.
S temi in številnimi drugimi izboljšavami nameravamo izboljšati uporabniško izkušnjo ne glede na omrežje in regijo, s čimer bo udoben in brezhiben paketni prenos bolj dostopen po vsem svetu.
Vir: www.habr.com