QUIC protokolą labai įdomu žiūrėti, todėl mums patinka apie jį rašyti. Bet jei ankstesnės publikacijos apie QUIC buvo daugiau istorinės (jei norite vietinės istorijos) pobūdžio ir aparatinės įrangos, tai šiandien džiaugiamės galėdami publikuoti kitokio pobūdžio vertimą – apie realų protokolo taikymą kalbėsime 2019 m. Be to, kalbame ne apie nedidelę infrastruktūrą, įsikūrusią vadinamajame garaže, o apie Uber, kuris veikia beveik visame pasaulyje. Kaip įmonės inžinieriai priėmė sprendimą naudoti QUIC gamyboje, kaip atliko bandymus ir ką pamatė jį išleidę gamyboje – žemiau pjūvio.
Nuotraukas galima spustelėti. Mėgaukitės skaitymu!
„Uber“ veikia pasauliniu mastu, ty 600 buvimo miestų, kurių kiekviename programa visiškai priklauso nuo belaidžio interneto iš daugiau nei 4500 korinio ryšio operatorių. Vartotojai tikisi, kad programėlė bus ne tik greita, bet ir realiu laiku – norint tai pasiekti, Uber programėlei reikalingas mažas delsimas ir labai patikimas ryšys. Deja, bet kamino neveikia dinamiškuose ir nuostolinguose belaidžiuose tinkluose. Supratome, kad šiuo atveju mažas našumas yra tiesiogiai susijęs su TCP diegimu operacinės sistemos branduoliuose.
Norėdami išspręsti problemą, kreipėmės , modernus kanalų tankinimo protokolas, suteikiantis mums daugiau galimybių kontroliuoti transportavimo protokolo veikimą. Šiuo metu darbo grupė standartizuoja QUIC kaip .
Po išsamaus bandymo padarėme išvadą, kad įdiegus QUIC mūsų programoje sumažės uodegos delsa, palyginti su TCP. Pastebėjome, kad vairuotojo ir keleivių programose HTTPS srautas sumažėjo 10–30 %. QUIC taip pat suteikė mums visišką vartotojų paketų valdymą.
Šiame straipsnyje mes dalijamės savo patirtimi optimizuojant TCP Uber programoms naudojant steką, palaikantį QUIC.
Naujausia technologija: TCP
Šiandien TCP yra dažniausiai naudojamas perdavimo protokolas HTTPS srautui perduoti internete. TCP suteikia patikimą baitų srautą, todėl susidoroja su tinklo perkrova ir ryšio sluoksnio praradimu. Plačiai paplitęs TCP naudojimas HTTPS srautui yra dėl to, kad pirmasis TCP yra visur (beveik kiekvienoje OS yra TCP), prieinamumo daugumoje infrastruktūrų (pvz., apkrovos balansavimo priemonėms, HTTPS tarpiniams serveriams ir CDN) ir prieinamų funkcionalumo. beveik daugumoje platformų ir tinklų.
Dauguma vartotojų naudojasi mūsų programa keliaudami, o TCP uodegos delsos nė iš tolo neprilygo mūsų realiojo laiko HTTPS srauto poreikiams. Paprasčiau tariant, vartotojai visame pasaulyje tai patyrė – 1 paveiksle parodytas vėlavimas didžiuosiuose miestuose:
1 pav. Uodegos delsa skiriasi pagrindiniuose Uber miestuose.
Nors delsa Indijos ir Brazilijos tinkluose buvo didesnė nei JAV ir JK, uodegos delsa yra žymiai didesnė nei vidutinė delsa. Ir tai galioja net JAV ir JK.
TCP per oro našumas
TCP buvo sukurtas laidinis tinklai, ty pabrėžiant labai nuspėjamus ryšius. Tačiau bevielis tinklai turi savo ypatybių ir sunkumų. Pirma, belaidžiai tinklai yra jautrūs nuostoliams dėl trukdžių ir signalo slopinimo. Pavyzdžiui, „Wi-Fi“ tinklai jautrūs mikrobangoms, „Bluetooth“ ir kitoms radijo bangoms. Korinio ryšio tinklai kenčia nuo signalo praradimo () dėl signalo atspindžio/sugerimo objektuose ir pastatuose, taip pat nuo iš kaimynų . Tai lemia reikšmingesnį (4-10 kartų) ir įvairesnį ir paketų praradimas, palyginti su laidiniu ryšiu.
Norėdami kovoti su pralaidumo svyravimais ir praradimais, koriniai tinklai paprastai naudoja didelius buferius srauto srautams. Dėl to gali susidaryti pernelyg didelės eilės, o tai reiškia ilgesnį vėlavimą. Labai dažnai TCP traktuoja šią eilę kaip švaistymą dėl pailginto skirtojo laiko, todėl TCP linkęs perduoti ir taip užpildyti buferį. Ši problema žinoma kaip (), ir tai labai modernus internetas.
Galiausiai, korinio tinklo našumas skiriasi priklausomai nuo operatoriaus, regiono ir laiko. 2 paveiksle surinkome vidutinius HTTPS srauto vėlavimus ląstelėse 2 kilometrų diapazone. Duomenys surinkti iš dviejų pagrindinių korinio ryšio operatorių Delyje, Indijoje. Kaip matote, kiekvienos ląstelės našumas skiriasi. Taip pat vieno operatoriaus produktyvumas skiriasi nuo antrojo. Tam įtakos turi tokie veiksniai kaip įėjimo į tinklą modeliai, atsižvelgiant į laiką ir vietą, vartotojų mobilumas, taip pat tinklo infrastruktūra, atsižvelgiant į bokšto tankį ir tinklų tipų santykį (LTE, 3G ir kt.).
2 pav. Vėlavimai, kaip pavyzdys 2 km spinduliu. Delis, Indija.
Be to, korinio ryšio tinklų našumas kinta laikui bėgant. 3 paveiksle parodyta vidutinė delsa pagal savaitės dieną. Mes taip pat stebėjome skirtumus mažesniu mastu, per vieną dieną ir valandą.
3 pav. Uodegos delsimas gali labai skirtis skirtingomis dienomis, tačiau tam pačiam operatoriui.
Dėl visų aukščiau išvardytų priežasčių TCP našumas yra neveiksmingas belaidžiuose tinkluose. Tačiau prieš ieškodami alternatyvų TCP, norėjome tiksliai suprasti šiuos dalykus:
- ar TCP yra pagrindinis mūsų programų uodegos delsos kaltininkas?
- Ar šiuolaikiniai tinklai turi reikšmingų ir įvairių vėlavimų pirmyn ir atgal (RTT)?
- Kokią įtaką RTT ir praradimas turi TCP veikimui?
TCP našumo analizė
Norėdami suprasti, kaip analizavome TCP našumą, trumpai pažvelkime, kaip TCP perduoda duomenis iš siuntėjo į imtuvą. Pirmiausia siuntėjas užmezga TCP ryšį, atlikdamas trijų krypčių ryšį : Siuntėjas siunčia SYN paketą, laukia SYN-ACK paketo iš imtuvo, tada siunčia ACK paketą. Papildomas antrasis ir trečiasis praėjimas išleidžiamas kuriant TCP ryšį. Gavėjas patvirtina kiekvieno paketo gavimą (ACK), kad būtų užtikrintas patikimas pristatymas.
Jei paketas arba ACK prarandamas, siuntėjas pakartotinai persiunčia po skirtojo laiko (RTO, ). RTO apskaičiuojamas dinamiškai, atsižvelgiant į įvairius veiksnius, pvz., numatomą RTT delsą tarp siuntėjo ir gavėjo.
4 pav. Keitimasis paketais per TCP/TLS apima pakartotinio perdavimo mechanizmą.
Norėdami nustatyti, kaip TCP veikė mūsų programose, stebėjome TCP paketus naudodami savaitę apie kovinį srautą, gaunamą iš Indijos krašto serverių. Tada mes analizavome TCP ryšius naudodami . Be to, sukūrėme „Android“ programą, kuri siunčia emuliuotą srautą į bandomąjį serverį, kiek įmanoma imituodama tikrą srautą. Išmanieji telefonai su šia programa buvo išdalinti keliems darbuotojams, kurie per kelias dienas rinko žurnalus.
Abiejų eksperimentų rezultatai atitiko vienas kitą. Pastebėjome dideles RTT delsas; uodegos vertės buvo beveik 6 kartus didesnės už vidutinę vertę; vėlavimų aritmetinis vidurkis yra daugiau nei 1 sekundė. Daugelis ryšių buvo prarasti, todėl TCP pakartotinai perdavė 3,5% visų paketų. Perpildytose vietose, pavyzdžiui, oro uostuose ir traukinių stotyse, patyrėme 7 % nuostolių. Šie rezultatai kelia abejonių dėl įprastinės išminties, kuri naudojama korinio ryšio tinkluose žymiai sumažinti nuostolius transporto lygmenyje. Žemiau pateikiami „treniruoklio“ programos bandymo rezultatai:
Tinklo metrika
Vertybės
RTT, milisekundės [50%, 75%, 95%, 99%]
[350, 425, 725, 2300]
RTT divergencija, sekundės
Vidutiniškai ~1,2 s
Paketų praradimas esant nestabiliems ryšiams
Vidutiniškai ~3.5% (7% perkrautose vietose)
Beveik pusė šių jungčių turėjo bent vieną paketų praradimą, dauguma jų buvo SYN ir SYN-ACK paketai. Dauguma TCP diegimų naudoja 1 sekundės RTO reikšmę SYN paketams, kuri eksponentiškai didėja dėl vėlesnių nuostolių. Programos įkėlimo laikas gali pailgėti, nes TCP užtrunka ilgiau užmegzti ryšius.
Duomenų paketų atveju didelės RTO reikšmės labai sumažina naudingą tinklo panaudojimą, kai belaidžiuose tinkluose atsiranda trumpalaikių nuostolių. Mes nustatėme, kad vidutinis pakartotinio siuntimo laikas yra maždaug 1 sekundė, o uodegos vėlavimas yra beveik 30 sekundžių. Dėl šios didelės delsos TCP lygiu baigėsi HTTPS skirtasis laikas ir pakartotinės užklausos, o tai dar labiau padidino tinklo delsą ir neveiksmingumą.
Nors 75-asis išmatuoto RTT procentilis buvo maždaug 425 ms, 75-asis TCP procentilis buvo beveik 3 sekundės. Tai rodo, kad dėl praradimo TCP prireikė 7–10 kartų, kad sėkmingai perduotų duomenis. Tai gali būti neveiksmingo RTO skaičiavimo, TCP nesugebėjimo greitai reaguoti į nuostolius pasekmė lange ir perkrovos valdymo algoritmo, kuris neskiria belaidžio ryšio nuostolių ir nuostolių dėl tinklo perkrovos, neefektyvumas. Toliau pateikiami TCP praradimo testų rezultatai:
TCP paketų praradimo statistika
Vertė
Ryšių su bent 1 paketo praradimu procentas
45%
Ryšių su nuostoliais per ryšio sąranką procentas
30%
Ryšių su nuostoliais keičiantis duomenimis procentas
76%
Retransliavimo vėlavimų pasiskirstymas, sekundės [50%, 75%, 95%, 99%] [1, 2.8, 15, 28]
Vieno paketo arba TCP segmento pakartotinių siuntimų skaičiaus pasiskirstymas
[1,3,6,7]
QUIC taikymas
Iš pradžių „Google“ sukurtas QUIC yra kelių gijų modernus transportavimo protokolas, veikiantis UDP. Šiuo metu yra QUIC (jau rašėme, kad yra tarsi dvi QUIC versijos, įdomu – apytiksliai vertėjas). Kaip parodyta 5 paveiksle, QUIC yra HTTP/3 (iš tikrųjų HTTP/2 virš QUIC yra HTTP/3, kuris dabar intensyviai standartizuojamas). Jis iš dalies pakeičia HTTPS ir TCP sluoksnius, naudodamas UDP paketams formuoti. QUIC palaiko tik saugų duomenų perdavimą, nes TLS yra visiškai integruotas į QUIC.
5 paveikslas: QUIC veikia naudojant HTTP/3, pakeičiant TLS, kuris anksčiau veikė HTTP/2.
Toliau pateikiamos priežastys, dėl kurių mus įtikino naudoti QUIC TCP stiprinimui:
- 0-RTT ryšio užmezgimas. QUIC leidžia pakartotinai naudoti ankstesnių jungčių autorizacijas ir sumažina saugos rankų paspaudimų skaičių. Ateityje palaikys 0-RTT, bet vis tiek reikės trijų krypčių TCP rankos paspaudimo.
- HoL blokavimo įveikimas. HTTP/2 kiekvienam klientui naudoja vieną TCP ryšį, kad pagerintų našumą, tačiau dėl to gali būti blokuojamas HoL (head-of-line). QUIC supaprastina multipleksavimą ir savarankiškai pateikia užklausas programai.
- spūsčių kontrolė. QUIC yra taikomųjų programų lygmenyje, todėl lengviau atnaujinti pagrindinį transportavimo algoritmą, kuris valdo siuntimą pagal tinklo parametrus (praradimų skaičių arba RTT). Dauguma TCP diegimų naudoja algoritmą , kuris nėra optimalus delsai jautriam srautui. Neseniai sukurti algoritmai, pvz , tiksliau modeliuoti tinklą ir optimizuoti delsą. QUIC leidžia naudoti BBR ir atnaujinti šį algoritmą, kai jis naudojamas. .
- nuostolių papildymas. QUIC iškviečia du TLP () prieš įsijungiant RTO – net kai nuostoliai labai pastebimi. Tai skiriasi nuo TCP diegimo. TLP daugiausia persiunčia paskutinį paketą (arba naują, jei toks yra), kad suaktyvintų greitą papildymą. Uodegos vėlavimų tvarkymas yra ypač naudingas „Uber“ valdant savo tinklą, ty trumpam, atsitiktiniam ir delsiniam duomenų perdavimui.
- optimizuotas ACK. Kadangi kiekvienas paketas turi unikalų eilės numerį, problemų nėra paketus, kai jie pakartotinai perduodami. ACK paketuose taip pat yra laiko apdoroti paketą ir sugeneruoti ACK kliento pusėje. Šios funkcijos užtikrina, kad QUIC tiksliau apskaičiuoja RTT. ACK in QUIC palaiko iki 256 juostų , padeda siuntėjui būti atsparesniam paketų maišymui ir procese naudoti mažiau baitų. Atrankinis ACK () TCP ne visais atvejais išsprendžia šią problemą.
- ryšio migracija. QUIC ryšiai identifikuojami pagal 64 bitų ID, todėl klientui pakeitus IP adresus, senasis ryšio ID gali būti toliau naudojamas naujame IP adresu be pertrūkių. Tai labai įprasta mobiliųjų programų praktika, kai vartotojas perjungia „Wi-Fi“ ir korinio ryšio ryšį.
QUIC alternatyvos
Prieš pasirinkdami QUIC, apsvarstėme alternatyvius problemos sprendimo būdus.
Pirmas dalykas, kurį bandėme, buvo įdiegti TPC PoP (buvimo taškus), kad nutrauktume TCP ryšius arčiau vartotojų. Iš esmės PoP nutraukia TCP ryšį su mobiliuoju įrenginiu, esančiu arčiau korinio tinklo, ir perduoda srautą atgal į pradinę infrastruktūrą. Nutraukę TCP arčiau, galime sumažinti RTT ir užtikrinti, kad TCP geriau reaguotų į dinaminę belaidę aplinką. Tačiau mūsų eksperimentai parodė, kad didžioji dalis RTT ir nuostolių atsiranda iš korinio ryšio tinklų, o PoP naudojimas nepagerina našumo.
Taip pat pažvelgėme į TCP parametrų derinimą. Nustatyti TCP krūvą mūsų nevienalyčiuose krašto serveriuose buvo sunku, nes TCP skirtingose OS versijose įdiegtas skirtingai. Buvo sunku tai įgyvendinti ir išbandyti skirtingas tinklo konfigūracijas. TCP konfigūruoti tiesiogiai mobiliuosiuose įrenginiuose nebuvo įmanoma, nes trūko leidimų. Dar svarbiau, kad tokios funkcijos kaip 0-RTT ryšiai ir patobulintas RTT numatymas yra labai svarbūs protokolo architektūrai, todėl neįmanoma pasiekti reikšmingos naudos derinant vien TCP.
Galiausiai įvertinome kelis UDP pagrindu veikiančius protokolus, šalinančius vaizdo transliacijos triktis – norėjome sužinoti, ar šie protokolai padėtų mūsų atveju. Deja, jiems labai trūko daugelio saugos nustatymų, be to, reikėjo papildomo TCP ryšio metaduomenims ir valdymo informacijai gauti.
Mūsų tyrimai parodė, kad QUIC yra bene vienintelis protokolas, galintis padėti išspręsti interneto srauto problemą, kartu atsižvelgiant ir į saugumą, ir į našumą.
QUIC integravimas į platformą
Siekdami sėkmingai įterpti QUIC ir pagerinti programos našumą prasto ryšio aplinkoje, seną paketą (HTTP/2 per TLS/TCP) pakeitėme QUIC protokolu. Naudojome tinklo biblioteką iš , kuriame yra originali, „Google“ protokolo versija – gQUIC. Šis diegimas taip pat nuolat tobulinamas, kad atitiktų naujausią IETF specifikaciją.
Pirmiausia „Cronet“ integravome į „Android“ programas, kad pridėtume QUIC palaikymą. Integracija buvo vykdoma taip, kad būtų kuo mažesnės migracijos išlaidos. Užuot visiškai pakeitus seną tinklo krūvą, kuri naudojo biblioteką , mes integravome Cronet PAGAL OkHttp API sistemą. Taip integruodami išvengėme savo tinklo skambučių pakeitimų (kuriuos naudoja ) API lygiu.
Panašiai kaip ir „Android“ įrenginiams, „Cronet“ įdiegėme „iOS“ skirtose „Uber“ programose, perimdami HTTP srautą iš tinklo Naudojant . Ši „iOS Foundation“ pateikta abstrakcija tvarko su protokolu susijusius URL duomenis ir užtikrina, kad „Cronet“ galėtume integruoti į „iOS“ programas be didelių perkėlimo išlaidų.
QUIC užbaigimas „Google Cloud Balancers“.
Užpakalinėje pusėje QUIC užbaigimą užtikrina Google Cloud Load balansavimo infrastruktūra, kuri naudoja atsakymų antraštės, skirtos palaikyti QUIC. Apskritai, balansavimo priemonė prideda alt-svc antraštę prie kiekvienos HTTP užklausos ir tai jau patvirtina QUIC palaikymą domenui. Kai Cronet klientas gauna HTTP atsakymą su šia antrašte, jis naudoja QUIC vėlesnėms HTTP užklausoms į tą domeną. Kai balansavimo priemonė užbaigia QUIC, mūsų infrastruktūra aiškiai siunčia šį veiksmą per HTTP2/TCP į mūsų duomenų centrus.
Našumas: rezultatai
Išvesties našumas yra pagrindinė priežastis, kodėl mes ieškome geresnio protokolo. Pirmiausia sukūrėme stendą su norėdami sužinoti, kaip QUIC veiks esant skirtingiems tinklo profiliams. Norėdami išbandyti QUIC našumą realaus pasaulio tinkluose, atlikome eksperimentus važinėdami po Naująjį Delį, naudodami emuliuotą tinklo srautą, labai panašų į HTTP skambučius keleivių programoje.
1 eksperimentas
Eksperimento įranga:
- išbandyti „Android“ įrenginius su „OkHttp“ ir „Cronet“ krūvomis, kad įsitikintumėte, jog leidžiame HTTPS srautą atitinkamai per TCP ir QUIC;
- Java pagrindu sukurtas emuliacijos serveris, kuris atsakymuose siunčia to paties tipo HTTPS antraštes ir įkelia kliento įrenginius, kad gautų iš jų užklausas;
- debesies tarpiniai serveriai, kurie fiziškai yra netoli Indijos, kad nutrauktų TCP ir QUIC ryšius. TCP nutraukimui naudojome atvirkštinį tarpinį serverį , buvo sunku rasti atvirojo kodo atvirkštinį QUIC tarpinį serverį. Patys sukūrėme atvirkštinį QUIC tarpinį serverį, naudodami pagrindinį QUIC rinkinį iš Chromium and jį į chromą kaip atvirą kodą.
6 pav. TCP vs QUIC kelių bandymų rinkinį sudarė „Android“ įrenginiai su „OkHttp“ ir „Cronet“, tarpiniai debesies serveriai ryšiams nutraukti ir emuliacijos serveris.
2 eksperimentas
Kai „Google“ padarė QUIC pasiekiamą su , naudojome tą patį inventorių, bet su vienu modifikavimu: vietoj NGINX paėmėme Google apkrovos balansavimo priemones, kad nutrauktume TCP ir QUIC ryšius iš įrenginių, taip pat nukreiptume HTTPS srautą į emuliacijos serverį. Balansuotojai yra platinami visame pasaulyje, tačiau naudoja arčiausiai įrenginio esantį PoP serverį (dėl geografinės vietos).
7 pav. Antrajame eksperimente norėjome palyginti TCP ir QUIC užbaigimo delsą: naudojant Google Cloud ir mūsų debesies tarpinį serverį.
Dėl to mūsų laukė keli apreiškimai:
- nutraukimas per PoP pagerino TCP našumą. Kadangi balansuotojai nutraukia TCP ryšius arčiau vartotojų ir yra labai optimizuoti, dėl to sumažėja RTT, o tai pagerina TCP našumą. Ir nors QUIC buvo paveiktas mažiau, jis vis tiek pranoko TCP, sumažindamas uodegos delsą (10–30 proc.).
- pažeidžiamos uodegos . Nors mūsų QUIC tarpinis serveris buvo toliau nuo įrenginių (apie 50 ms didesnė delsa) nei „Google“ apkrovos balansavimo priemonės, jis veikė panašų našumą – 15 % sumažėjo delsa, palyginti su 20 % TCP 99 procentiliu. Tai rodo, kad paskutinės mylios perėjimas yra tinklo kliūtis.
8 pav. Dviejų eksperimentų rezultatai rodo, kad QUIC gerokai lenkia TCP.
Kovoti su eismu
Įkvėpti eksperimentų, įdiegėme QUIC palaikymą savo Android ir iOS programose. Atlikome A/B testavimą, siekdami nustatyti QUIC poveikį miestuose, kuriuose veikia „Uber“. Apskritai pastebėjome, kad abiejuose regionuose, telekomunikacijų operatorių ir tinklo tipuose, žymiai sumažėjo vėlavimai.
Toliau pateiktose diagramose parodytas procentinis uodegos patobulinimas (95 ir 99 procentiliai) pagal makroregioną ir skirtingus tinklo tipus – LTE, 3G, 2G.
9 pav. Mūšio testuose QUIC pranoko TCP delsos atžvilgiu.
Tik persiųsti
Galbūt tai tik pradžia – QUIC išleidimas į gamybą suteikė nuostabių galimybių pagerinti programų našumą tiek stabiliuose, tiek nestabiliuose tinkluose, būtent:
Padidėjęs aprėptis
Išanalizavę protokolo veikimą realiame sraute, pamatėme, kad maždaug 80 % seansų sėkmingai naudojo QUIC visi užklausų, o 15 % seansų buvo naudojamas QUIC ir TCP derinys. Manome, kad šis derinys atsirado dėl to, kad Cronet bibliotekos skirtasis laikas grįžta į TCP, nes jis negali atskirti tikrų UDP gedimų ir prastų tinklo sąlygų. Šiuo metu ieškome šios problemos sprendimo, nes stengiamės vėliau įdiegti QUIC.
QUIC optimizavimas
Srautas iš programų mobiliesiems yra jautrus delsai, bet ne pralaidumui. Be to, mūsų programos daugiausia naudojamos korinio ryšio tinkluose. Remiantis eksperimentais, uodegos delsa vis dar yra didelė, net jei naudojamas tarpinis serveris TCP ir QUIC nutraukti arti vartotojų. Aktyviai ieškome būdų, kaip pagerinti spūsčių valdymą ir pagerinti QUIC nuostolių atkūrimo algoritmų efektyvumą.
Šiais ir keletu kitų patobulinimų planuojame pagerinti naudotojų patirtį, nepaisant tinklo ir regiono, todėl patogus ir sklandus paketų gabenimas visame pasaulyje tampa prieinamesnis.
Šaltinis: www.habr.com