La QUIC-protokolo estas ege interesa spekti, tial ni amas skribi pri ĝi. Sed se antaŭaj publikaĵoj pri QUIC estis pli historia (loka historio, se vi ŝatas) naturo kaj aparataro, hodiaŭ ni volonte publikigas tradukon de alispeca - ni parolos pri la reala apliko de la protokolo en 2019. Cetere, ni ne parolas pri malgranda infrastrukturo bazita en tiel nomata garaĝo, sed pri Uber, kiu funkcias preskaŭ en la tuta mondo. Kiel la inĝenieroj de la kompanio venis al la decido uzi QUIC en produktado, kiel ili faris la testojn kaj kion ili vidis post la disvolvado de ĝi en produktado - sub la tranĉo.
La bildoj estas klakeblaj. Ĝuu legadon!
Uber havas tutmondan skalon, nome 600 urbojn de ĉeesto, en ĉiu el kiuj la aplikaĵo dependas tute de sendrata Interreto de pli ol 4500 XNUMX ĉelaj telefonistoj. Uzantoj atendas, ke la apo estu ne nur rapida, sed en reala tempo - por atingi tion, la Uber-apo bezonas malaltan latentecon kaj tre fidindan konekton. Ve, sed la stako ne funkcias bone en dinamikaj kaj perd-emaj sendrataj retoj. Ni rimarkis, ke en ĉi tiu kazo, malalta rendimento rekte rilatas al TCP-efektivigoj en operaciumaj kernoj.
Por solvi la problemon, ni aplikis , moderna kanala multipleksprotokolo kiu donas al ni pli da kontrolo super la agado de la transportprotokolo. Nuntempe la laborgrupo normigas QUIC kiel .
Post ampleksa testado, ni konkludis, ke efektivigi QUIC en nia aplikaĵo rezultigus pli malaltajn vostajn latentecojn kompare kun TCP. Ni observis redukton en la gamo de 10-30% por HTTPS-trafiko en la aplikaĵoj de ŝoforo kaj pasaĝero. QUIC ankaŭ donis al ni fin-al-finan kontrolon pri uzantpakaĵoj.
En ĉi tiu artikolo, ni dividas nian sperton pri optimumigo de TCP por Uber-aplikoj uzante stakon, kiu subtenas QUIC.
La plej nova teknologio: TCP
Hodiaŭ, TCP estas la plej uzata transportprotokolo por liveri HTTPS-trafikon en la Interreto. TCP disponigas fidindan fluon de bajtoj, tiel alfrontante retŝtopiĝon kaj ligtavolperdojn. La ĝeneraligita uzo de TCP por HTTPS-trafiko ŝuldiĝas al la ĉieeco de la unua (preskaŭ ĉiu OS enhavas TCP), haveblecon sur la plej multaj infrastrukturoj (kiel ekzemple ŝarĝbalanciloj, HTTPS-prokuriloj kaj CDN-oj), kaj eksterordinara funkcieco kiu estas havebla. sur preskaŭ plej multaj platformoj kaj retoj.
Plej multaj uzantoj uzas nian apon survoje, kaj TCP-vostaj latentecoj estis nenie proksime de la postuloj de nia realtempa HTTPS-trafiko. Simple dirite, uzantoj ĉie en la mondo spertis tion - Figuro 1 montras prokrastojn en ĉefaj urboj:
Figuro 1: Vosto latenteco varias tra la ĉefaj urboj de Uber.
Kvankam latencia en hindaj kaj brazilaj retoj estis pli alta ol en Usono kaj UK, vosta latenco estas signife pli alta ol meza latenco. Kaj tio validas eĉ por Usono kaj UK.
TCP super la aera agado
TCP estis kreita por kabligita retoj, tio estas, kun emfazo de tre antaŭvideblaj ligiloj. Tamen, sendrata retoj havas siajn proprajn trajtojn kaj malfacilaĵojn. Unue, sendrataj retoj estas sentemaj al perdoj pro interfero kaj signalmalfortiĝo. Ekzemple, Wifi-retoj estas sentemaj al mikroondoj, bluetooth kaj aliaj radiondoj. Ĉelaj retoj suferas signalperdon () pro reflektado/sorbado de la signalo per objektoj kaj konstruaĵoj, same kiel de de najbaro . Ĉi tio kondukas al pli signifa (4-10 fojojn) kaj pli diversa kaj paka perdo kompare kun kablita konekto.
Por kontraŭbatali bendolarĝfluktuojn kaj perdojn, ĉelaj retoj tipe uzas grandajn bufrojn por trafikeksplodoj. Ĉi tio povas konduki al troa vico, kio signifas pli longajn prokrastojn. Tre ofte TCP traktas ĉi tiun vicon kiel malŝparon pro plilongigita tempo-tempo, do TCP emas relaji kaj tiel plenigi la bufron. Ĉi tiu problemo estas konata kiel (), kaj ĉi tio estas tre moderna Interreto.
Fine, la rendimento de la ĉela reto varias laŭ portanto, regiono kaj tempo. En Figuro 2, ni kolektis la mezajn prokrastojn de HTTPS-trafiko tra ĉeloj ene de 2-kilometra gamo. Datenoj kolektitaj por du gravaj ĉelaj funkciigistoj en Delhio, Hindio. Kiel vi povas vidi, rendimento varias de ĉelo al ĉelo. Ankaŭ, la produktiveco de unu funkciigisto diferencas de la produktiveco de la dua. Ĉi tio estas influita de faktoroj kiel retaj enirpadronoj konsiderante tempon kaj lokon, uzantan moveblecon, same kiel retan infrastrukturon konsiderante turdensecon kaj la rilatumon de retaj tipoj (LTE, 3G, ktp.).
Figuro 2. Prokrastoj uzante 2 km radiuson kiel ekzemplon. Delhio, Barato.
Ankaŭ, la agado de ĉelaj retoj varias laŭlonge de la tempo. Figuro 3 montras la mezan latentecon laŭ tago de la semajno. Ni ankaŭ observis diferencojn en pli malgranda skalo, ene de ununura tago kaj horo.
Figuro 3. Vostoprokrastoj povas varii signife inter tagoj, sed por la sama funkciigisto.
Ĉio ĉi-supra igas TCP-agadon esti neefika en sendrataj retoj. Tamen, antaŭ ol serĉi alternativojn al TCP, ni volis evoluigi precizan komprenon pri la sekvaj punktoj:
- ĉu TCP estas la ĉefa kulpulo malantaŭ vostaj latentecoj en niaj aplikoj?
- Ĉu modernaj retoj havas signifajn kaj diversajn rondveturajn prokrastojn (RTT)?
- Kio estas la efiko de RTT kaj perdo sur TCP-agado?
TCP-Efikeco-Analizo
Por kompreni kiel ni analizis TCP-agadon, ni rapide rigardu kiel TCP transdonas datumojn de sendinto al ricevilo. Unue, la sendinto establas TCP-konekton, farante tridirektan : La sendinto sendas SYN-pakaĵon, atendas SYN-ACK-pakaĵon de la ricevilo, poste sendas ACK-pakaĵon. Plia dua kaj tria enirpermesilo estas elspezitaj establante la TCP-konekton. La ricevanto agnoskas la ricevon de ĉiu pako (ACK) por certigi fidindan liveron.
Se pakaĵeto aŭ ACK estas perdita, la sendinto retransdonas post tempodaŭro (RTO, ). RTO estas kalkulita dinamike surbaze de diversaj faktoroj, kiel ekzemple la atendata RTT-prokrasto inter la sendinto kaj ricevanto.
Figuro 4. Pakaĵeto super TCP/TLS inkluzivas retransmision mekanismon.
Por determini kiel TCP agadis en niaj aplikoj, ni monitoris TCP-pakojn uzante dum semajno pri bataltrafiko venanta de hindaj randserviloj. Ni tiam analizis la TCP-konektoj uzante . Aldone, ni kreis Android-aplikaĵon kiu sendas kopiitan trafikon al testa servilo, imitante realan trafikon kiel eble plej multe. Smartphones kun ĉi tiu aplikaĵo estis distribuitaj al pluraj dungitoj, kiuj kolektis protokolojn dum pluraj tagoj.
La rezultoj de ambaŭ eksperimentoj estis kongruaj unu kun la alia. Ni vidis altajn latentecojn de RTT; vostaj valoroj estis preskaŭ 6 fojojn pli altaj ol la meza valoro; la aritmetika mezumo de prokrastoj estas pli ol 1 sekundo. Multaj ligoj estis perdaj, igante TCP retranssendi 3,5% de ĉiuj pakaĵetoj. En ŝtopitaj lokoj kiel flughavenoj kaj fervojaj stacidomoj, ni vidis 7% perdojn. Ĉi tiuj rezultoj dubas pri la konvencia saĝo, kiun tiuj uzataj en ĉelaj retoj signife redukti perdojn ĉe la transportnivelo. Malsupre estas la testrezultoj de la aplikaĵo "simulilo":
Retaj metrikoj
Valoroj
RTT, milisekundoj [50%, 75%, 95%, 99%]
[350, 425, 725, 2300]
RTT-diverĝo, sekundoj
Averaĝe ~1,2 s
Paka perdo sur malstabilaj konektoj
Meza ~3.5% (7% en troŝarĝitaj lokoj)
Preskaŭ duono de tiuj ligoj havis almenaŭ unu pakaĵetperdon, la plej multaj el ili SYN kaj SYN-ACK pakaĵetoj. La plej multaj TCP-efektivigoj uzas RTO-valoron de 1 sekundo por SYN-pakaĵetoj, kiu pliiĝas eksponente por postaj perdoj. La tempoj de ŝarĝo de aplikaĵoj povas pliiĝi pro tio, ke TCP daŭras pli longe por establi konektojn.
En la kazo de datumpakaĵoj, altaj RTO-valoroj multe reduktas la utilan uzadon de la reto en ĉeesto de pasemaj perdoj en sendrataj retoj. Ni trovis, ke la meza retransdona tempo estas proksimume 1 sekundo kun vosta prokrasto de preskaŭ 30 sekundoj. Ĉi tiuj altaj latentecoj ĉe la TCP-nivelo kaŭzis HTTPS-tempon kaj re-petojn, pliigante retan latentecon kaj neefikecon.
Dum la 75-a percentilo de mezurita RTT estis proksimume 425 ms, la 75-a percentilo por TCP estis preskaŭ 3 sekundoj. Ĉi tio sugestas, ke la perdo igis TCP preni 7-10 enirpermesilojn por sukcese transdoni datumojn. Tio povas esti sekvo de malefika RTO-kalkulo, la malkapablo de TCP rapide respondi al perdo. en la fenestro kaj la neefikeco de la algoritmo de kontrolo de obstrukciĝo, kiu ne distingas inter sendrataj perdoj kaj perdoj pro retŝtopiĝo. Malsupre estas la rezultoj de TCP-perdotestoj:
TCP-paka perdo-statistiko
valoro
Procento de konektoj kun almenaŭ 1 paka perdo
45%
Procento de konektoj kun perdoj dum konekto-aranĝo
30%
Procento de konektoj kun perdoj dum interŝanĝo de datumoj
76%
Distribuo de prokrastoj en retranssendo, sekundoj [50%, 75%, 95%,99%] [1, 2.8, 15, 28]
Distribuado de la nombro da redissendoj por unu pakaĵeto aŭ TCP-segmento
[1,3,6,7]
Apliko de QUIC
Origine evoluigita de Google, QUIC estas plurfadena moderna transporta protokolo, kiu funkcias super UDP. Nuntempe QUIC estas en (ni jam skribis, ke ekzistas kvazaŭ du versioj de QUIC, kuriozaj – ĉ. tradukisto). Kiel montrite en Figuro 5, QUIC estas metita sub HTTP/3 (fakte, HTTP/2 supre de QUIC estas HTTP/3, kiu nun estas intense normigita). Ĝi parte anstataŭigas la HTTPS kaj TCP-tavolojn uzante UDP por formi pakaĵetojn. QUIC nur subtenas sekuran transdonon de datumoj ĉar TLS estas plene konstruita en QUIC.
Figuro 5: QUIC funkcias sub HTTP/3, anstataŭigante TLS, kiu antaŭe funkciis sub HTTP/2.
Malsupre estas la kialoj, kiuj konvinkis nin uzi QUIC por TCP-plifortigo:
- 0-RTT-konektoestablado. QUIC permesas la reuzon de rajtigoj de antaŭaj ligoj, reduktante la nombron da sekurecaj manpremoj. Estontece subtenos 0-RTT, sed tridirekta TCP-manpremo ankoraŭ estos postulata.
- venkante HoL-blokado. HTTP/2 uzas unu TCP-konekton per kliento por plibonigi rendimenton, sed ĉi tio povas konduki al blokado de HoL (ĉefo de linio). QUIC simpligas multipleksadon kaj liveras petojn al la aplikaĵo sendepende.
- kontrolo de obstrukciĝo. QUIC loĝas ĉe la aplikaĵotavolo, faciligante ĝisdatigi la ĉefan transportalgoritmon kiu kontrolas sendadon surbaze de retaj parametroj (nombro da perdoj aŭ RTT). Plej multaj TCP-efektivigoj uzas la algoritmon , kiu ne estas optimuma por latencia-sentema trafiko. Lastatempe evoluigitaj algoritmoj kiel , pli precize modeligi la reton kaj optimumigi latencia. QUIC permesas vin uzi BBR kaj ĝisdatigi ĉi tiun algoritmon kiel ĝi estas uzata. .
- replenigo de perdoj. QUIC vokas du TLP-ojn () antaŭ ol la RTO estas ekigita - eĉ kiam la perdoj estas tre videblaj. Ĉi tio diferencas de TCP-efektivigoj. TLP retransdonas ĉefe la lastan paketon (aŭ la novan, se ekzistas) por ekigi rapidan replenigon. Pritraktado de vostaj prokrastoj estas precipe utila por la maniero kiel Uber funkciigas sian reton, nome por mallongaj, sporadaj kaj latentec-sentemaj datumtranslokigoj.
- optimumigita ACK. Ĉar ĉiu pakaĵeto havas unikan sinsekvon, ne estas problemo pakaĵoj kiam ili estas retranssenditaj. ACK-pakaĵoj ankaŭ enhavas tempon por prilabori la pakaĵeton kaj generi ACK ĉe la klientflanko. Ĉi tiuj funkcioj certigas, ke QUIC kalkulas RTT pli precize. ACK en QUIC subtenas ĝis 256 bandojn , helpante al la sendinto esti pli rezistema al pakaĵeto kaj uzi malpli da bajtoj en la procezo. Selektema ACK () en TCP ne solvas ĉi tiun problemon en ĉiuj kazoj.
- konektomigrado. QUIC-konektoj estas identigitaj per 64-bita ID, do se kliento ŝanĝas IP-adresojn, la malnova konekto ID povas daŭre esti uzata sur la nova IP-adreso sen interrompo. Ĉi tio estas tre ofta praktiko por moveblaj aplikoj kie la uzanto ŝanĝas inter Wi-Fi kaj ĉelaj konektoj.
Alternativoj al QUIC
Ni pripensis alternativajn alirojn por solvi la problemon antaŭ ol elekti QUIC.
La unua afero, kiun ni provis estis deploji TPC-PoP-ojn (Punktoj de Ĉeesto) por ĉesigi TCP-konektojn pli proksime al uzantoj. Esence, PoPs finas TCP-konekton kun movebla aparato pli proksime al la ĉela reto kaj prokuras la trafikon reen al la origina infrastrukturo. Finigante TCP pli proksime, ni povas eble redukti la RTT kaj certigi, ke TCP estas pli respondema al dinamika sendrata medio. Tamen, niaj eksperimentoj montris, ke la plej granda parto de la RTT kaj perdo venas de ĉelaj retoj kaj la uzo de PoPs ne provizas signifan rendimentan plibonigon.
Ni ankaŭ rigardis agordi TCP-parametrojn. Agordi TCP-stakon sur niaj heterogenaj randserviloj estis malfacila ĉar TCP havas malsimilajn efektivigojn tra malsamaj OS-versioj. Estis malfacile efektivigi ĉi tion kaj testi malsamajn retajn agordojn. Agordi TCP rekte sur porteblaj aparatoj ne eblis pro manko de permesoj. Pli grave, funkcioj kiel ekzemple 0-RTT-konektoj kaj plibonigita RTT-prognozo estas kritikaj al la arkitekturo de la protokolo, kaj tial estas neeble atingi signifajn avantaĝojn agordante TCP sole.
Fine, ni taksis plurajn UDP-bazitajn protokolojn, kiuj solvis problemojn de video-fluado - ni volis vidi ĉu ĉi tiuj protokoloj helpos en nia kazo. Bedaŭrinde, ili grave mankis pri multaj sekurecaj agordoj, kaj ankaŭ postulis plian TCP-konekton por metadatenoj kaj kontrolinformoj.
Nia esplorado montris, ke QUIC estas eble la sola protokolo, kiu povas helpi pri la problemo de interreta trafiko, konsiderante kaj sekurecon kaj rendimenton.
Integriĝo de QUIC en la platformon
Por sukcese enkonstrui QUIC kaj plibonigi aplikaĵon en malbonaj konekteblecaj medioj, ni anstataŭigis la malnovan stakon (HTTP/2 super TLS/TCP) per la QUIC-protokolo. Ni uzis la retbibliotekon el , kiu enhavas la originalan, Guglo-version de la protokolo - gQUIC. Ĉi tiu efektivigo ankaŭ estas konstante plibonigata por sekvi la plej novan specifon de IETF.
Ni unue integris Cronet en niajn Android-aplikaĵojn por aldoni subtenon por QUIC. Integriĝo estis farita tiel, ke kiel eble plej multe redukti la migrajn kostojn. Anstataŭ tute anstataŭigi la malnovan interkonektan stakon, kiu uzis la bibliotekon , ni integris Cronet SUB la OkHttp API-kadro. Farante la integriĝon tiel, ni evitis ŝanĝojn al niaj retaj vokoj (kiuj estas uzataj de ) ĉe la API-nivelo.
Simile al la aliro por Android-aparatoj, ni efektivigis Cronet en Uber-aplikaĵojn en iOS, kaptante HTTP-trafikon de reto. uzante . Ĉi tiu abstraktado, provizita de la iOS-Fondaĵo, pritraktas protokolan specifajn URL-datumojn kaj certigas, ke ni povas integri Cronet en niajn iOS-aplikaĵojn sen signifaj migraj kostoj.
Kompletigante QUIC ĉe Google Cloud Balancers
Sur la malantaŭa flanko, QUIC-kompletigo estas provizita de la ekvilibra infrastrukturo de Google Cloud Load, kiu uzas kaplinioj en respondoj por subteni QUIC. Ĝenerale, la ekvilibristo aldonas alt-svc-kapon al ĉiu HTTP-peto, kaj ĉi tio jam validas QUIC-subtenon por la domajno. Kiam Cronet-kliento ricevas HTTP-respondon kun ĉi tiu kaplinio, ĝi uzas QUIC por postaj HTTP-petoj al tiu domajno. Post kiam la ekvilibristo kompletigas la QUIC, nia infrastrukturo eksplicite sendas ĉi tiun agon per HTTP2/TCP al niaj datumcentroj.
Agado: Rezultoj
Eliga rendimento estas la ĉefa kialo por nia serĉo de pli bona protokolo. Por komenci, ni kreis standon kun por ekscii kiel QUIC kondutos sub malsamaj retaj profiloj. Por testi la agadon de QUIC en realaj retoj, ni faris eksperimentojn dum veturado ĉirkaŭ Nov-Delhio uzante kopiitan retan trafikon tre similan al HTTP-vokoj en la pasaĝera aplikaĵo.
Eksperimento 1
Ekipaĵo por la eksperimento:
- testi Android-aparatojn kun OkHttp kaj Cronet-stakoj por certigi, ke ni permesas HTTPS-trafikon super TCP kaj QUIC respektive;
- Java-bazita emuladservilo kiu sendas la saman specon de HTTPS-kapoj en respondoj kaj ŝarĝas klientajn aparatojn por ricevi petojn de ili;
- nubaj prokuriloj, kiuj fizike situas proksime al Barato por ĉesigi TCP kaj QUIC-konektojn. Dum por TCP-fino ni uzis inversan prokurilon , estis malfacile trovi malfermfontan inversan prokurilon por QUIC. Ni mem konstruis inversan prokurilon por QUIC uzante la bazan QUIC-stakon de Chromium kaj ĝin en kromion kiel malferma fonto.
Figuro 6. La TCP vs QUIC-voja testaro konsistis el Android-aparatoj kun OkHttp kaj Cronet, nubaj prokuriloj por ĉesigi konektojn, kaj emula servilo.
Eksperimento 2
Kiam Google disponigis QUIC kun , ni uzis la saman inventaron, sed kun unu modifo: anstataŭ NGINX, ni prenis Google-ŝarĝbalancilojn por ĉesigi TCP kaj QUIC-konektojn de aparatoj, same kiel por direkti HTTPS-trafikon al la emula servilo. Balanciloj estas distribuitaj tra la tuta mondo, sed uzu la PoP-servilon plej proksiman al la aparato (danke al geolokigo).
Figuro 7. En la dua eksperimento, ni volis kompari la kompletigan latencian de TCP kaj QUIC: uzante Google Cloud kaj uzante nian nuban prokurilon.
Kiel rezulto, pluraj revelacioj atendis nin:
- ĉesigo per PoP plibonigis TCP-efikecon. Ĉar ekvilibristoj finas TCP-ligojn pli proksime al uzantoj kaj estas tre optimumigitaj, tio rezultigas pli malaltajn RTT-ojn, kiuj plibonigas TCP-efikecon. Kaj kvankam QUIC estis malpli tuŝita, ĝi ankoraŭ superis TCP koncerne redukton de vosta latenco (per 10-30 procentoj).
- vostoj estas tuŝitaj . Kvankam nia QUIC-prokurilo estis pli for de la aparatoj (ĉirkaŭ 50 ms pli alta latenteco) ol la ŝarĝbalanciloj de Google, ĝi liveris similan efikecon - 15% redukto en latencia kontraŭ 20% redukto en la 99-a percentilo por TCP. Ĉi tio sugestas, ke la lasta mejla transiro estas proplemkolo en la reto.
Figuro 8: Rezultoj de du eksperimentoj montras, ke QUIC signife superas TCP.
Batala trafiko
Inspirite de eksperimentado, ni efektivigis QUIC-subtenon en niaj Android kaj iOS-aplikoj. Ni faris A/B-testadon por determini la efikon de QUIC en la urboj, kie Uber funkcias. Ĝenerale, ni vidis signifan redukton de vostaj prokrastoj tra ambaŭ regionoj, telekomunikaj telefonistoj kaj reto-tipo.
La malsupraj grafikaĵoj montras la procentajn plibonigojn en vostoj (95 kaj 99 procentoj) laŭ makroregiono kaj malsamaj retaj tipoj - LTE, 3G, 2G.
Figuro 9. En bataltestoj, QUIC superis TCP laŭ latencia.
Nur antaŭen
Eble ĉi tio estas nur la komenco - la liberigo de QUIC en produktadon donis mirindajn ŝancojn plibonigi aplikaĵon en ambaŭ stabilaj kaj malstabilaj retoj, nome:
Pliigita kovrado
Analizinte la agadon de la protokolo pri reala trafiko, ni vidis, ke proksimume 80% de sesioj sukcese uzis QUIC por всех petoj, dum 15% de sesioj uzis kombinaĵon de QUIC kaj TCP. Ni supozas, ke la kombinaĵo ŝuldiĝas al la cronet-biblioteko-tempiĝo reen al TCP, ĉar ĝi ne povas distingi inter realaj UDP-fiaskoj kaj malbonaj retaj kondiĉoj. Ni nuntempe serĉas solvon al ĉi tiu problemo dum ni laboras al la posta efektivigo de QUIC.
QUIC-optimumigo
Trafiko de poŝtelefonaj programoj estas sentema al latenteco, sed ne al bendolarĝo. Ankaŭ niaj aplikoj estas ĉefe uzataj en ĉelaj retoj. Surbaze de eksperimentoj, vostaj latentecoj ankoraŭ estas altaj kvankam uzante prokurilon por ĉesigi TCP kaj QUIC proksime al uzantoj. Ni aktive serĉas manierojn plibonigi obstrukcadministradon kaj plibonigi la efikecon de algoritmoj de reakiro de QUIC.
Kun ĉi tiuj kaj pluraj aliaj plibonigoj, ni planas plibonigi la uzantan sperton sendepende de reto kaj regiono, farante oportunan kaj senjuntan pakaĵtransporton pli alirebla tra la mondo.
fonto: www.habr.com