QUIC samskiptareglur eru afar áhugaverðar að horfa á, þess vegna elskum við að skrifa um hana. En ef fyrri útgáfur um QUIC voru meira af sögulegu (staðbundnar sögu, ef þú vilt) eðli og vélbúnað, í dag erum við ánægð að gefa út þýðingu af öðru tagi - við munum tala um raunverulega beitingu siðareglunnar árið 2019. Þar að auki erum við ekki að tala um litla innviði byggða í svokölluðum bílskúr heldur um Uber, sem starfar nánast um allan heim. Hvernig verkfræðingar fyrirtækisins komust að þeirri ákvörðun að nota QUIC í framleiðslu, hvernig þeir framkvæmdu prófin og hvað þeir sáu eftir að það var rúllað út í framleiðslu - fyrir neðan skurðinn.
Myndirnar eru smellanlegar. Njóttu þess að lesa!
Uber er á heimsvísu, þ.e. 600 viðveruborgir, í hverri þeirra treystir forritið algjörlega á þráðlaust internet frá meira en 4500 farsímafyrirtækjum. Notendur búast við að appið sé ekki bara hratt heldur í rauntíma - til að ná þessu þarf Uber appið litla leynd og mjög áreiðanlega tengingu. Því miður, en staflan gengur ekki vel í kraftmiklum og tapsárum þráðlausum netum. Við gerðum okkur grein fyrir því að í þessu tilfelli er lág afköst í beinu samhengi við TCP útfærslur í stýrikerfiskjarna.
Til að leysa vandamálið sóttum við um , nútíma rás margföldunarsamskiptareglur sem gefur okkur meiri stjórn á frammistöðu flutningssamskiptareglunnar. Núna er vinnuhópurinn staðlar QUIC as .
Eftir ítarlegar prófanir komumst við að þeirri niðurstöðu að innleiðing á QUIC í forritinu okkar myndi leiða til lægri hala töf samanborið við TCP. Við sáum minnkun á bilinu 10-30% fyrir HTTPS umferð í ökumanns- og farþegaforritum. QUIC gaf okkur líka endanlega stjórn á notendapakka.
Í þessari grein deilum við reynslu okkar af því að fínstilla TCP fyrir Uber forrit með því að nota stafla sem styður QUIC.
Nýjasta tækni: TCP
Í dag er TCP mest notaða flutningssamskiptareglan til að skila HTTPS umferð á internetinu. TCP veitir áreiðanlegan straum af bætum og tekst þar með á netþrengslum og tapi á hlekkjum. Hin útbreidda notkun TCP fyrir HTTPS umferð er vegna alls staðar þess fyrrnefnda (nánast hvert stýrikerfi inniheldur TCP), framboð á flestum innviðum (svo sem álagsjafnara, HTTPS umboð og CDN) og út-af-the-box virkni sem er í boði á næstum flestum kerfum og netkerfum.
Flestir notendur nota appið okkar á ferðinni og TCP hala leynd var hvergi nærri kröfum rauntíma HTTPS umferðar okkar. Einfaldlega sagt, notendur um allan heim hafa upplifað þetta - Mynd 1 sýnir tafir í stórborgum:
Mynd 1: Leiðin á hala er mismunandi eftir helstu borgum Uber.
Þrátt fyrir að leynd í indverskum og brasilískum netkerfum hafi verið meiri en í Bandaríkjunum og Bretlandi, þá er töf á hala marktækt hærri en meðaltöf. Og þetta á jafnvel við um Bandaríkin og Bretland.
TCP afköst í loftinu
TCP var búið til fyrir hlerunarbúnað netkerfi, það er að segja með áherslu á mjög fyrirsjáanlega tengla. Hins vegar, þráðlaust tengslanet hafa sín sérkenni og erfiðleika. Í fyrsta lagi eru þráðlaus net næm fyrir tapi vegna truflana og merkjadeyfingar. Til dæmis eru Wi-Fi net viðkvæm fyrir örbylgjuofnum, Bluetooth og öðrum útvarpsbylgjum. Farsímakerfi þjást af merkjatapi () vegna endurkasts/gleypingar merkisins af hlutum og byggingum, sem og frá frá nágrannalandinu . Þetta leiðir til marktækara (4-10 sinnum) og fjölbreyttara og pakkatap miðað við snúrutengingu.
Til að berjast gegn bandbreiddssveiflum og tapi nota farsímakerfi venjulega stóra biðminni fyrir umferðarsprengjur. Þetta getur leitt til of mikillar biðraðir, sem þýðir lengri tafir. Mjög oft meðhöndlar TCP þessa biðröð sem sóun vegna lengri tíma, þannig að TCP hefur tilhneigingu til að miðla og fylla þar með biðminni. Þetta vandamál er þekkt sem (), og þetta er mjög nútíma internet.
Að lokum er afköst farsímakerfisins mismunandi eftir símafyrirtæki, svæði og tíma. Á mynd 2 söfnuðum við miðgildi seinkana á HTTPS umferð yfir frumur innan tveggja kílómetra sviðs. Gögnum safnað fyrir tvo helstu farsímafyrirtæki í Delhi á Indlandi. Eins og þú sérð er frammistaða mismunandi eftir frumum. Einnig er framleiðni eins rekstraraðila frábrugðin framleiðni annars. Þetta er undir áhrifum af þáttum eins og netmynstri sem tekur tillit til tíma og staðsetningar, hreyfanleika notenda, sem og netuppbyggingar sem tekur tillit til þéttleika turns og hlutfalls nettegunda (LTE, 2G, osfrv.).
Mynd 2. Tafir með 2 km radíus sem dæmi. Delhi, Indlandi.
Einnig er frammistaða farsímakerfa breytileg með tímanum. Mynd 3 sýnir miðgildi leynd eftir vikudegi. Við sáum einnig mun á smærri mælikvarða, innan eins dags og klukkustundar.
Mynd 3. Tafir í hala geta verið mjög mismunandi milli daga, en fyrir sama rekstraraðila.
Allt ofangreint veldur því að TCP árangur er óvirkur í þráðlausum netum. Hins vegar, áður en við leituðum að valkostum við TCP, vildum við þróa nákvæman skilning á eftirfarandi atriðum:
- er TCP aðal sökudólgurinn á bak við töf á hala í forritum okkar?
- Eru nútíma netkerfi með verulegar og fjölbreyttar tafir fram og til baka (RTT)?
- Hver eru áhrif RTT og taps á TCP árangur?
TCP árangursgreining
Til að skilja hvernig við greindum TCP frammistöðu skulum við skoða fljótt hvernig TCP flytur gögn frá sendanda til móttakara. Í fyrsta lagi stofnar sendandinn TCP tengingu, framkvæmir þríhliða : Sendandi sendir SYN pakka, bíður eftir SYN-ACK pakka frá móttakara, sendir síðan ACK pakka. Önnur og þriðju umferð til viðbótar fer í að koma á TCP tengingunni. Viðtakandinn staðfestir móttöku hvers pakka (ACK) til að tryggja áreiðanlega afhendingu.
Ef pakki eða ACK týnist sendir sendandi aftur eftir tímamörk (RTO, ). RTO er reiknað á kraftmikinn hátt út frá ýmsum þáttum, svo sem væntanlegri RTT töf milli sendanda og viðtakanda.
Mynd 4. Pakkaskipti yfir TCP/TLS innihalda endursendingarkerfi.
Til að ákvarða hvernig TCP virkaði í forritunum okkar, fylgdumst við með TCP pökkum með því að nota í viku á bardagaumferð sem kemur frá indverskum brúnþjónum. Við greindum síðan TCP tengingarnar með því að nota . Að auki bjuggum við til Android forrit sem sendir eftirlíka umferð til prófunarþjóns og líkir eftir raunverulegri umferð eins mikið og mögulegt er. Snjallsímum með þessu forriti var dreift til nokkurra starfsmanna, sem söfnuðu annálum á nokkrum dögum.
Niðurstöður beggja tilrauna voru í samræmi við hvor aðra. Við sáum mikla RTT töf; halagildi voru næstum 6 sinnum hærri en miðgildi; reiknað meðaltal tafa er meira en 1 sekúnda. Margar tengingar voru tapaðar, sem olli því að TCP endursendi 3,5% allra pakka. Á þéttum svæðum eins og flugvöllum og lestarstöðvum sáum við 7% tap. Þessar niðurstöður draga í efa hina hefðbundnu visku sem þeir sem notaðir eru í farsímakerfum draga verulega úr tapi á flutningsstigi. Hér að neðan eru prófunarniðurstöður úr „hermi“ forritinu:
Netmælingar
Merkingar
RTT, millisekúndur [50%,75%, 95%,99%]
[350, 425, 725, 2300]
RTT frávik, sekúndur
Að meðaltali ~1,2 s
Pakkatap á óstöðugum tengingum
Að meðaltali ~3.5% (7% á ofhleðslusvæðum)
Tæplega helmingur þessara tenginga var með að minnsta kosti eitt pakkatap, flestir SYN og SYN-ACK pakkar. Flestar TCP útfærslur nota RTO gildi upp á 1 sekúndu fyrir SYN pakka, sem eykst veldishraða fyrir síðari tap. Hleðslutími forrita getur aukist vegna þess að TCP tekur lengri tíma að koma á tengingum.
Þegar um er að ræða gagnapakka draga há RTO gildi verulega úr gagnlegri nýtingu netsins þegar skammvinnt tap er í þráðlausum netum. Við komumst að því að meðalendurútsendingartími er um það bil 1 sekúnda með töf upp á næstum 30 sekúndur. Þessar háu töf á TCP-stigi ollu HTTPS tímamörkum og endurbeiðnum, sem jók enn frekar netleynd og óhagkvæmni.
Á meðan 75. hundraðshluti mælds RTT var um 425 ms, var 75. hundraðshluti fyrir TCP tæpar 3 sekúndur. Þetta gefur til kynna að tapið hafi valdið því að TCP tók 7-10 sendingar til að senda gögn með góðum árangri. Þetta getur verið afleiðing af óhagkvæmum RTO útreikningi, vanhæfni TCP til að bregðast fljótt við tapi í glugganum og óhagkvæmni reikniritsins til að stjórna þrengslum, sem gerir ekki greinarmun á þráðlausu tapi og tapi vegna netþrengslna. Hér að neðan eru niðurstöður TCP tapprófa:
TCP pakkatap tölfræði
Gildi
Hlutfall tenginga með að minnsta kosti 1 pakkatap
45%
Hlutfall tenginga sem tapast við uppsetningu tengingar
30%
Hlutfall tenginga sem tapast við gagnaskipti
76%
Dreifing tafa á endursendingu, sekúndur [50%, 75%, 95%,99%] [1, 2.8, 15, 28]
Dreifing fjölda endursendinga fyrir einn pakka eða TCP hluta
[1,3,6,7]
Notkun QUIC
Upphaflega þróað af Google, QUIC er fjölþráða nútíma flutningsaðferð sem keyrir ofan á UDP. Eins og er er QUIC inn (við skrifuðum þegar að það eru, eins og það var, tvær útgáfur af QUIC, forvitnilegt – ca. þýðandi). Eins og sést á mynd 5 er QUIC sett undir HTTP/3 (í raun er HTTP/2 ofan á QUIC HTTP/3, sem nú er verið að staðla mikið). Það kemur að hluta í stað HTTPS og TCP lög með því að nota UDP til að mynda pakka. QUIC styður aðeins öruggan gagnaflutning þar sem TLS er að fullu innbyggt í QUIC.
Mynd 5: QUIC keyrir undir HTTP/3, kemur í stað TLS, sem áður keyrði undir HTTP/2.
Hér að neðan eru ástæðurnar sem sannfærðu okkur um að nota QUIC fyrir TCP mögnun:
- 0-RTT tenging stofnun. QUIC gerir kleift að endurnýta heimildir frá fyrri tengingum, sem dregur úr fjölda öryggishandtaka. Í framtíðinni mun styðja 0-RTT, en þríhliða TCP handabandi verður samt krafist.
- sigrast á HoL blokkun. HTTP/2 notar eina TCP tengingu á hvern viðskiptavin til að bæta árangur, en þetta getur leitt til HoL (head-of-line) blokkunar. QUIC einfaldar margföldun og skilar beiðnum til forritsins sjálfstætt.
- eftirlit með þrengslum. QUIC er í forritalaginu, sem gerir það auðveldara að uppfæra aðalflutningsreikniritið sem stjórnar sendingu út frá netbreytum (fjöldi tapa eða RTT). Flestar TCP útfærslur nota reikniritið , sem er ekki ákjósanlegt fyrir umferð sem er viðkvæm fyrir biðtíma. Nýlega þróað reiknirit eins og , líkja betur netið og hámarka leynd. QUIC gerir þér kleift að nota BBR og uppfæra þetta reiknirit eins og það er notað. .
- endurbætur á tapi. QUIC kallar tvö TLP () áður en RTO er ræst - jafnvel þegar tapið er mjög áberandi. Þetta er frábrugðið TCP útfærslum. TLP endursendir aðallega síðasta pakkann (eða þann nýja, ef hann er til) til að koma af stað hraðri áfyllingu. Að meðhöndla tafir á hala er sérstaklega gagnlegt fyrir hvernig Uber rekur netkerfi sitt, nefnilega fyrir stuttar, óreglulegar og leyndarviðkvæmar gagnaflutningar.
- bjartsýni ACK. Þar sem hver pakki hefur einstakt raðnúmer er ekkert vandamál pakka þegar þeir eru endursendir. ACK pakkar innihalda einnig tíma til að vinna úr pakkanum og búa til ACK á viðskiptavininum. Þessir eiginleikar tryggja að QUIC reikni RTT nákvæmari. ACK í QUIC styður allt að 256 hljómsveitir , sem hjálpar sendandanum að vera þolnari við pakkastokkun og nota færri bæti í ferlinu. Sértækt ACK () í TCP leysir þetta vandamál ekki í öllum tilfellum.
- flutningur tenginga. QUIC tengingar eru auðkenndar með 64 bita auðkenni, þannig að ef viðskiptavinur breytir IP vistföngum er hægt að halda áfram að nota gamla tengi auðkennið á nýju IP tölunni án truflana. Þetta er mjög algengt fyrir farsímaforrit þar sem notandinn skiptir á milli Wi-Fi og farsímatenginga.
Valkostir við QUIC
Við skoðuðum aðrar leiðir til að leysa vandamálið áður en við völdum QUIC.
Það fyrsta sem við reyndum var að setja upp TPC PoPs (Points of Presence) til að slíta TCP tengingum nær notendum. Í meginatriðum, PoPs slíta TCP tengingu við farsíma nær farsímanetinu og senda umferðina aftur til upprunalegu innviðanna. Með því að slíta TCP nær getum við hugsanlega dregið úr RTT og tryggt að TCP svari betur fyrir kraftmiklu þráðlausu umhverfi. Hins vegar hafa tilraunir okkar sýnt að megnið af RTT og tapinu kemur frá farsímakerfum og notkun PoPs veitir ekki marktækan árangur.
Við skoðuðum líka að stilla TCP breytur. Það var erfitt að setja upp TCP stafla á ólíkum brúnþjónum okkar vegna þess að TCP er með ólíkar útfærslur á mismunandi stýrikerfisútgáfum. Það var erfitt að innleiða þetta og prófa mismunandi netstillingar. Ekki var hægt að stilla TCP beint á farsímum vegna skorts á heimildum. Meira um vert, eiginleikar eins og 0-RTT tengingar og endurbætt RTT spá eru mikilvæg fyrir arkitektúr samskiptareglunnar og þess vegna er ómögulegt að ná verulegum ávinningi með því að stilla TCP eingöngu.
Að lokum metum við nokkrar UDP-undirstaða samskiptareglur sem leysa úr vídeóstraumi - við vildum sjá hvort þessar samskiptareglur myndu hjálpa í okkar tilviki. Því miður vantaði þær verulega í margar öryggisstillingar og kröfðust einnig viðbótar TCP tengingar fyrir lýsigögn og stjórnunarupplýsingar.
Rannsóknir okkar hafa sýnt að QUIC er ef til vill eina samskiptareglan sem getur hjálpað til við vandamálið með netumferð, á meðan tekið er tillit til bæði öryggis og frammistöðu.
Samþætting QUIC í pallinn
Til að fella inn QUIC með góðum árangri og bæta árangur forrita í lélegu tengiumhverfi, skiptum við út gamla staflanum (HTTP/2 yfir TLS/TCP) fyrir QUIC siðareglur. Við notuðum netsafnið á , sem inniheldur upprunalegu Google útgáfu samskiptareglunnar - gQUIC. Þessi útfærsla er einnig stöðugt endurbætt til að fylgja nýjustu IETF forskriftinni.
Við samþættum Cronet fyrst í Android öppin okkar til að bæta við stuðningi við QUIC. Samþætting var framkvæmd með þeim hætti að flutningskostnaður yrði lækkaður eins og kostur var. Í stað þess að skipta algjörlega út gamla netstaflanum sem notaði bókasafnið , við höfum samþætt Cronet UNDIR OkHttp API ramma. Með því að gera samþættinguna á þennan hátt forðumst við breytingar á netsímtölum okkar (sem eru notuð af ) á API stigi.
Svipað og aðferðin fyrir Android tæki, innleiddum við Cronet í Uber öpp á iOS, stöðvuðum HTTP umferð frá netinu að nota . Þessi útdráttur, útvegaður af iOS Foundation, meðhöndlar samskiptasértæk vefslóð gögn og tryggir að við getum samþætt Cronet inn í iOS forritin okkar án verulegs flutningskostnaðar.
Að klára QUIC á Google Cloud Balancers
Á bakhliðinni er QUIC frágang veitt af Google Cloud Load jöfnunarinnviði, sem notar hausa í svörum til stuðnings QUIC. Almennt bætir jafnvægismaðurinn alt-svc haus við hverja HTTP beiðni og þetta staðfestir nú þegar QUIC stuðning fyrir lénið. Þegar Cronet viðskiptavinur fær HTTP svar með þessum haus notar hann QUIC fyrir síðari HTTP beiðnir á það lén. Þegar jafnvægismaðurinn hefur lokið QUIC, sendir innviðir okkar þessa aðgerð beinlínis yfir HTTP2/TCP til gagnavera okkar.
Frammistaða: Úrslit
Framleiðsluárangur er aðalástæðan fyrir leit okkar að betri samskiptareglum. Til að byrja með bjuggum við til stand með til að komast að því hvernig QUIC mun haga sér undir mismunandi netsniðum. Til að prófa frammistöðu QUIC á raunverulegum netkerfum gerðum við tilraunir á meðan við keyrðum um Nýju Delí með því að nota herma netumferð sem er mjög svipuð HTTP símtölum í farþegaforritinu.
Tilraun 1
Búnaður fyrir tilraunina:
- prófa Android tæki með OkHttp og Cronet stafla til að tryggja að við leyfum HTTPS umferð yfir TCP og QUIC í sömu röð;
- Java-undirstaða hermiþjónn sem sendir sömu tegund af HTTPS hausum í svörum og hleður biðlaratækjum til að taka á móti beiðnum frá þeim;
- skýjaumboð sem eru líkamlega staðsett nálægt Indlandi til að slíta TCP og QUIC tengingum. Þó að fyrir TCP uppsögn notuðum við öfugt umboð á , það var erfitt að finna opinn uppspretta öfugt umboð fyrir QUIC. Við byggðum sjálf öfugt umboð fyrir QUIC með því að nota grunn QUIC stafla frá Chromium og það í króm sem opinn uppspretta.
Mynd 6. TCP vs QUIC vegaprófunarsvítan samanstóð af Android tækjum með OkHttp og Cronet, skýjaumboðum til að slíta tengingum og hermiþjóni.
Tilraun 2
Þegar Google gerði QUIC aðgengilegt með , við notuðum sama birgðahald, en með einni breytingu: í stað NGINX, tókum við Google hleðslujafnara til að slíta TCP og QUIC tengingum úr tækjum, sem og til að beina HTTPS umferð á hermiþjóninn. Balancers eru dreift um allan heim, en nota PoP-þjóninn sem er næst tækinu (þökk sé landstaðsetningu).
Mynd 7. Í annarri tilrauninni vildum við bera saman töf á lokun TCP og QUIC: með því að nota Google Cloud og nota skýjaþjóninn okkar.
Fyrir vikið biðu okkar nokkrar opinberanir:
- uppsögn í gegnum PoP bætt TCP árangur. Þar sem jafnvægistæki slíta TCP tengingum nær notendum og eru mjög bjartsýni, leiðir þetta til lægri RTT, sem bætir TCP árangur. Og þó að QUIC hafi verið minna fyrir áhrifum, gekk það samt betur en TCP hvað varðar að draga úr hala leynd (um 10-30 prósent).
- halar verða fyrir áhrifum . Þrátt fyrir að QUIC umboðið okkar væri lengra frá tækjunum (um 50 ms hærri leynd) en álagsjafnarar Google, skilaði það svipuðum afköstum - 15% minnkun á leynd á móti 20% minnkun á 99. hundraðshluta fyrir TCP. Þetta bendir til þess að síðustu míluskiptin séu flöskuháls í netinu.
Mynd 8: Niðurstöður úr tveimur tilraunum sýna að QUIC er verulega betri en TCP.
Bardaga umferð
Innblásin af tilraunum höfum við innleitt QUIC stuðning í Android og iOS forritunum okkar. Við gerðum A/B próf til að ákvarða áhrif QUIC í borgunum þar sem Uber starfar. Almennt séð sáum við verulega minnkun á töfum á hala á báðum svæðum, fjarskiptafyrirtækjum og nettegundum.
Línuritin hér að neðan sýna hlutfallslegar endurbætur í hala (95 og 99 hundraðshlutar) eftir þjóðhagssvæðum og mismunandi netgerðum - LTE, 3G, 2G.
Mynd 9. Í bardagaprófum var QUIC betri en TCP hvað varðar leynd.
Aðeins áfram
Kannski er þetta bara byrjunin - útgáfa QUIC í framleiðslu hefur veitt ótrúleg tækifæri til að bæta árangur forrita í bæði stöðugum og óstöðugum netum, þ.e.
Aukin umfjöllun
Eftir að hafa greint frammistöðu samskiptareglunnar á raunverulegri umferð sáum við að um það bil 80% af fundum notuðu QUIC með góðum árangri fyrir allt beiðnir, en 15% af fundum notuðu blöndu af QUIC og TCP. Við gerum ráð fyrir að samsetningin sé vegna þess að Cronet bókasafnið tekur tíma aftur í TCP, þar sem það getur ekki greint á milli raunverulegra UDP bilana og lélegra netaðstæðna. Við erum núna að skoða lausn á þessu vandamáli þar sem við vinnum að síðari innleiðingu QUIC.
QUIC hagræðing
Umferð frá farsímaforritum er töf viðkvæm, en ekki bandbreiddarviðkvæm. Einnig eru forritin okkar fyrst og fremst notuð á farsímakerfum. Byggt á tilraunum er töf á hala enn há þó að umboð sé notað til að slíta TCP og QUIC nálægt notendum. Við erum virkir að leita leiða til að bæta stjórnun á þrengslum og bæta skilvirkni QUIC-reiknirita til að endurheimta tap.
Með þessum og nokkrum öðrum endurbótum ætlum við að bæta notendaupplifunina óháð netkerfi og svæði og gera þægilegan og hnökralausan pakkaflutning aðgengilegri um allan heim.
Heimild: www.habr.com