U protokollu QUIC hè assai interessante per fighjà, chì hè per quessa chì ci piace scrive nantu à questu. Ma se e publicazioni precedenti nantu à QUIC eranu più di una storia storica (storia lucale, se vulete) natura è hardware, oghje simu felici di publicà una traduzzione di un altru tipu - parlemu di a vera applicazione di u protocolu in 2019. Inoltre, ùn parlemu micca di una piccula infrastruttura basatu in un garage chjamatu, ma di Uber, chì opera quasi in tuttu u mondu. Cumu l'ingegneri di a cumpagnia sò ghjunti à a decisione d'utilizà QUIC in a produzzione, cumu anu realizatu e teste è ciò chì anu vistu dopu à u rollu in a produzzione - sottu à u cut.
I ritratti sò clicate. Prufittate a lettura!
Uber hà una scala glubale, vale à dì 600 cità di prisenza, in ognuna di quali l'applicazione si basa interamente in Internet wireless da più di 4500 operatori cellulari. L'utilizatori aspettanu chì l'app ùn sia micca solu veloce, ma in tempu reale - per ottene questu, l'app Uber hà bisognu di bassa latenza è una cunnessione assai affidabile. Ahimè, ma a pila ùn faci micca bè in rete wireless dinamica è persa. Avemu capitu chì in questu casu, u rendiment bassu hè direttamente ligatu à implementazioni TCP in i kernels di u sistema operatore.
Per risolve u prublema, avemu applicatu , un protokollu di multiplexing di canali mudernu chì ci dà più cuntrollu di u funziunamentu di u protocolu di trasportu. Attualmente u gruppu di travagliu standardizes QUIC cum'è .
Dopu una prova estensiva, avemu cunclusu chì l'implementazione di QUIC in a nostra applicazione hà da risultatu in latenze di coda più bassu cumparatu cù TCP. Avemu osservatu una riduzzione in a gamma di 10-30% per u trafficu HTTPS in l'applicazioni di cunduttori è passageri. QUIC ci hà ancu datu un cuntrollu end-to-end nantu à i pacchetti d'utilizatori.
In questu articulu, spartemu a nostra sperienza in ottimisazione di TCP per l'applicazioni Uber cù una pila chì sustene QUIC.
L'ultima tecnulugia: TCP
Oghje, TCP hè u protocolu di trasportu più utilizatu per furnisce u trafficu HTTPS in Internet. TCP furnisce un flussu affidabile di byte, facendu cusì cù a congestione di a rete è a perdita di strati di ligame. L'usu generalizatu di TCP per u trafficu HTTPS hè dovutu à l'ubiquità di l'anzianu (quasi tutti i SO cuntenenu TCP), a dispunibilità nantu à a maiò parte di l'infrastruttura (cum'è equilibratrici di carica, proxy HTTPS è CDN), è a funziunalità fora di a scatula chì hè dispunibule. in quasi a maiò parte di e piattaforme è rete.
A maiò parte di l'utilizatori utilizanu a nostra app in viaghju, è a latenza di coda TCP ùn era micca vicinu à e richieste di u nostru trafficu HTTPS in tempu reale. Bastamente, l'utilizatori in u mondu sanu anu sperimentatu questu - a Figura 1 mostra i ritardi in e cità maiò:
Figura 1: A latenza di a coda varia in e cità principali di Uber.
Ancu se a latenza in e rete indiana è brasiliana era più altu ch'è in i Stati Uniti è in u Regnu Unitu, a latenza di a cuda hè significativamente più alta di a latenza media. È questu hè veru ancu per i Stati Uniti è u Regnu Unitu.
TCP over the air performance
TCP hè statu creatu per cablatu rete, vale à dì, cù un enfasi in ligami assai prevedibili. Tuttavia, wireless e rete anu e so caratteristiche è difficultà. Prima, e rete wireless sò suscettibili à pèrdite per l'interferenza è l'attenuazione di u signale. Per esempiu, e rete Wi-Fi sò sensittivi à i microonde, bluetooth è altre onde radio. E rete cellulare soffrenu di perdita di signale () per via di riflessione / assorbimentu di u segnu da l'uggetti è l'edifizii, è ancu da da vicinu . Questu porta à più significativa (4-10 volte) è più diversa è a perdita di pacchetti paragunatu à una cunnessione cablata.
Per cumbatte i fluttuazioni è e perdite di larghezza di banda, e rete cellulari generalmente utilizanu grandi buffers per u trafficu. Questu pò purtà à una fila eccessiva, chì significa ritardi più longu. Moltu spessu TCP tratta sta fila cum'è un perdu per via di un timeout allargatu, cusì TCP tende à trasmette è cusì riempie u buffer. Stu prublema hè cunnisciutu cum'è (), è questu hè assai Internet mudernu.
Infine, u rendiment di a rete cellulare varia da u trasportatore, a regione è u tempu. In a Figura 2, avemu cullatu i ritardi mediani di u trafficu HTTPS attraversu e cellule in un intervallu di 2 chilometri. Dati raccolti per dui principali operatori cellulari in Delhi, India. Comu pudete vede, u rendiment varieghja da cellula à cellula. Inoltre, a produtividade di un operatore difiere da a produtividade di u sicondu. Questu hè influinzatu da fatturi, cum'è i mudelli di ingressu di a rete chì tenenu in cunsiderà u tempu è u locu, a mobilità di l'utilizatori, è l'infrastruttura di a rete in cunsiderà a densità di a torre è a ratio di tipi di rete (LTE, 3G, etc.).
Figura 2. Ritardi cù un raghju di 2 km per esempiu. Delhi, India.
Inoltre, u rendiment di e rete cellulari varieghja cù u tempu. A Figura 3 mostra a latenza mediana per ghjornu di a settimana. Avemu ancu osservatu differenze in una scala più chjuca, in un solu ghjornu è ora.
Figura 3. I ritardi di a cuda pò varià significativamente trà i ghjorni, ma per u stessu operatore.
Tuttu ciò chì sopra causa u rendiment TCP per esse inefficace in e rete wireless. Tuttavia, prima di circà alternative à TCP, avemu vulsutu sviluppà una cunniscenza precisa nantu à i seguenti punti:
- TCP hè u principale culpritu daretu à i latenzi di coda in e nostre applicazioni?
- E rete muderne anu ritardi di andata e ritorno significativi è variati (RTT) ?
- Chì ghjè l'impattu di RTT è a perdita nantu à u rendiment TCP?
Analisi di u rendiment TCP
Per capisce cumu avemu analizatu u rendiment di TCP, fighjemu un rapidu sguardu à cumu TCP trasferisce dati da un mittente à un receptore. Prima, u mittente stabilisce una cunnessione TCP, eseguendu un tridirezzione : U mittente manda un pacchettu SYN, aspetta un pacchettu SYN-ACK da u ricevitore, poi manda un pacchettu ACK. Un secondu è terzu passatu supplementu hè passatu per stabilisce a cunnessione TCP. U destinatariu ricunnosce a ricezione di ogni pacchettu (ACK) per assicurà una consegna affidabile.
Se un pacchettu o ACK hè persu, u mittente ritrasmette dopu un timeout (RTO, ). RTO hè calculatu dinamicamente basatu annantu à diversi fatturi, cum'è u ritardu RTT previstu trà u mittente è u destinatariu.
Figura 4. U scambiu di pacchetti nantu à TCP / TLS include un mecanismu di retransmission.
Per determinà cumu TCP hà fattu in e nostre applicazioni, avemu monitoratu i pacchetti TCP utilizendu per una settimana nantu à u trafficu di cummattimentu chì vene da i servitori indiani. Dopu avemu analizatu e cunnessione TCP utilizendu . Inoltre, avemu creatu una applicazione Android chì manda u trafficu emulatu à un servitore di prova, imitandu u trafficu reale quant'è pussibule. Smartphones cù questa applicazione sò stati distribuiti à parechji impiegati, chì cullighjanu logs in parechji ghjorni.
I risultati di i dui esperimenti eranu coherenti cù l'altri. Avemu vistu alta latenza RTT; i valori di a cuda eranu quasi 6 volte più altu ch'è u valore medianu; a media aritmetica di i ritardi hè più di 1 secondu. Parechje cunnessioni eranu perdite, facendu chì TCP ritrasmette u 3,5% di tutti i pacchetti. In i zoni congestionati cum'è l'aeroporti è e stazioni di treni, avemu vistu 7% perdite. Questi risultati ponenu dubbitu nantu à a saviezza convenzionale chì quelli utilizati in e rete cellulare riduce significativamente e perdite à u livellu di u trasportu. Quì sottu sò i risultati di teste da l'applicazione "simulatore":
Metri di rete
I valori
RTT, millisecondi [50%, 75%, 95%, 99%]
[350, 425, 725, 2300]
Divergenza RTT, seconde
In media ~ 1,2 s
Perdita di pacchetti in cunnessione instabili
Media ~ 3.5% (7% in i zoni sovraccarichi)
Quasi a mità di sti cunnessioni anu avutu almenu una perdita di pacchettu, a maiò parte di i pacchetti SYN è SYN-ACK. A maiò parte di l'implementazioni TCP utilizanu un valore RTO di 1 segundu per i pacchetti SYN, chì aumenta in modu esponenziale per perdite successive. I tempi di carica di l'applicazioni ponu aumentà per via chì TCP pigghia più tempu per stabilisce e cunnessione.
In u casu di i pacchetti di dati, i valori RTO elevati riducenu assai l'utilizazione utile di a rete in presenza di perdite transitori in e rete wireless. Avemu trovu chì u tempu mediu di retransmission hè di circa 1 secondu cù un ritardu di cuda di quasi 30 seconde. Queste alte latenzi à u nivellu TCP anu causatu timeout HTTPS è richieste di novu, aumentendu ancu a latenza di a rete è l'inefficienza.
Mentre u percentile 75 di RTT misuratu era di circa 425 ms, u percentile 75 per TCP era quasi 3 seconde. Stu suggerenu chì a perdita causatu TCP à piglià 7-10 passa à trasmette successu dati. Questu pò esse una cunsequenza di un calculu RTO inefficace, l'incapacità di TCP di risponde rapidamente à a perdita. in a finestra è l'inefficienza di l'algoritmu di cuntrollu di congestioni, chì ùn distingue micca perditi wireless è pèrdite per via di a congestion di a rete. Eccu i risultati di e teste di perdita TCP:
Statistiche di perdita di pacchetti TCP
valore
Percentuale di cunnessione cù almenu 1 perdita di pacchettu
45%
Percentuali di cunnessione cù pèrdite durante a stallazione di cunnessione
30%
Percentuale di cunnessione cù perdite durante u scambiu di dati
76%
Distribuzione di ritardi in retransmission, seconde [50%, 75%, 95%,99%] [1, 2.8, 15, 28]
Distribuzione di u numeru di retrasmissioni per un pacchettu o segmentu TCP
[1,3,6,7]
Applicazione di QUIC
Originariamente sviluppatu da Google, QUIC hè un protokollu di trasportu mudernu multi-threaded chì corre nantu à UDP. Attualmente QUIC hè in (avemu digià scrittu chì ci sò, per esse, duie versioni di QUIC, curiose - ca. traduttore). Cum'è mostra in a Figura 5, QUIC hè situatu sottu HTTP/3 (in fattu, HTTP/2 in cima à QUIC hè HTTP/3, chì hè oghji intensivamente standardizatu). Sustituisce parzialmente i strati HTTPS è TCP utilizendu UDP per furmà pacchetti. QUIC supporta solu u trasferimentu di dati sicuru postu chì TLS hè cumplettamente integratu in QUIC.
Figura 5: QUIC funziona sottu HTTP/3, rimpiazzà TLS, chì prima era in HTTP/2.
Eccu i mutivi chì ci anu cunvintu à utilizà QUIC per l'amplificazione TCP:
- Stabbilimentu di cunnessione 0-RTT. QUIC permette a reutilizazione di l'autorizazioni da e cunnessione precedente, riducendu u numeru di handshakes di sicurezza. In u futuru supporterà 0-RTT, ma sarà sempre necessaria una stretta di mano TCP a tre vie.
- superà u bloccu HoL. HTTP/2 usa una cunnessione TCP per cliente per migliurà u rendiment, ma questu pò guidà à u bloccu HoL (head-of-line). QUIC simplifica a multiplexazione è furnisce e richieste à l'applicazione in modu indipendenti.
- cuntrollu di congestion. QUIC risiede à a strata di l'applicazione, facendu più faciule per aghjurnà l'algoritmu di trasportu principale chì cuntrolla l'invio basatu nantu à i paràmetri di a rete (numeru di perdite o RTT). A maiò parte di l'implementazioni TCP utilizanu l'algoritmu , chì ùn hè micca ottimali per u trafficu sensitivu di latenza. Algoritmi sviluppati recentemente cum'è , modella più precisamente a reta è ottimisimu a latenza. QUIC permette di utilizà BBR è aghjurnà stu algoritmu cum'è hè adupratu. .
- ricuperazione di perdite. QUIC chjama dui TLP () prima chì u RTO hè attivatu - ancu quandu e perdite sò assai notevuli. Questu hè sfarente da implementazioni TCP. TLP ritrasmette principarmenti l'ultimu pacchettu (o u novu, s'ellu ci hè unu) per attivà un rifornimentu veloce. A gestione di i ritardi di a coda hè particularmente utile per a manera chì Uber opera a so rete, à dì per trasferimenti di dati brevi, sporadici è sensibili à a latenza.
- ACK ottimizzatu. Siccomu ogni pacchettu hà un numeru di sequenza unicu, ùn ci hè micca prublema pacchetti quandu sò ritrasmessi. I pacchetti ACK cuntenenu ancu tempu per processà u pacchettu è generà un ACK da u cliente. Queste caratteristiche assicuranu chì QUIC calcule RTT più precisamente. ACK in QUIC supporta finu à 256 bande , aiutendu u mittente à esse più resistente à u mischju di pacchetti è aduprà menu byte in u prucessu. ACK selettivu () in TCP ùn risolve micca stu prublema in tutti i casi.
- migrazione di cunnessione. I cunnessione QUIC sò identificati da un ID 64-bit, cusì se un cliente cambia l'indirizzi IP, l'ID di cunnessione antica pò cuntinuà à esse utilizatu in u novu indirizzu IP senza interruzzione. Questa hè una pratica assai cumuna per l'applicazioni mobili induve l'utilizatore cambia trà Wi-Fi è cunnessione cellulare.
Alternative à QUIC
Avemu cunsideratu avvicinamenti alternativu per risolve u prublema prima di sceglie QUIC.
U primu chì avemu pruvatu hè di implementà TPC PoPs (Punti di Presenza) per finisce e cunnessione TCP più vicinu à l'utilizatori. Essenzialmente, i PoP terminanu una cunnessione TCP cù un dispositivu mobile più vicinu à a rete cellulare è proxy u trafficu torna à l'infrastruttura originale. Finendu TCP più vicinu, pudemu potenzialmente riduce l'RTT è assicurà chì TCP hè più responsive à un ambiente wireless dinamicu. In ogni casu, i nostri esperimenti anu dimustratu chì a maiò parte di l'RTT è a perdita venenu da e rete cellulare è l'usu di PoP ùn furnisce micca una mellura significativa di rendiment.
Avemu ancu guardatu à tuning i paràmetri TCP. L'installazione di una pila TCP in i nostri servitori di punta eterogenei era difficiule perchè TCP hà implementazioni disparate in diverse versioni di u SO. Hè statu difficiule di implementà questu è pruvà diverse cunfigurazioni di rete. A cunfigurazione TCP direttamente nantu à i dispositi mobili ùn era micca pussibule per mancanza di permessi. A più impurtante, e funzioni cum'è e cunnessione 0-RTT è a prediczione RTT mejorata sò critichi per l'architettura di u protokollu, è per quessa hè impussibile di ottene benefici significati sintonizzandu solu TCP.
Infine, avemu evaluatu parechji protokolli basati in UDP chì risolve u video streaming - vulemu vede se sti protokolli aiutanu in u nostru casu. Sfurtunatamente, anu mancatu assai in parechje paràmetri di sicurità, è ancu bisognu di una cunnessione TCP addiziale per metadata è infurmazione di cuntrollu.
A nostra ricerca hà dimustratu chì QUIC hè forsi l'unicu protokollu chì pò aiutà cù u prublema di u trafficu di Internet, mentre chì pigliate in contu a sicurità è u rendiment.
Integrazione di QUIC in a piattaforma
Per incrustà cù successu QUIC è migliurà u rendiment di l'applicazioni in ambienti di cunnessione poveri, avemu rimpiazzatu a vechja pila (HTTP/2 sopra TLS/TCP) cù u protocolu QUIC. Avemu usatu a biblioteca di a rete из , chì cuntene l'uriginale, versione Google di u protocolu - gQUIC. Questa implementazione hè ancu constantemente migliurata per seguità l'ultime specificazioni IETF.
Prima avemu integratu Cronet in e nostre app Android per aghjunghje supportu per QUIC. L'integrazione hè stata realizata in modu di riduce u costu di migrazione quantu pussibule. Invece di rimpiazzà cumplettamente l'antica pila di rete chì usava a biblioteca , avemu integratu Cronet SOTTU u framework API OkHttp. Facendu l'integrazione in questu modu, avemu evitatu cambiamenti à e nostre chjama di rete (chì sò aduprate da ) à u livellu API.
Simile à l'approcciu per i dispositi Android, avemu implementatu Cronet in app Uber in iOS, interceptendu u trafficu HTTP da a rete. aduprendu . Questa astrazione, furnita da a Fundazione iOS, gestisce i dati URL specifichi di u protokollu è assicura chì pudemu integrà Cronet in e nostre applicazioni iOS senza costi di migrazione significativu.
Cumpiendu QUIC nantu à Google Cloud Balancers
Da u latu backend, u cumpletu QUIC hè furnitu da l'infrastruttura di bilanciamentu di carica di Google Cloud, chì usa intestazioni in risposti à sustegnu QUIC. In generale, u balancer aghjusta un intestazione alt-svc à ogni dumanda HTTP, è questu validate digià u supportu QUIC per u duminiu. Quandu un cliente Cronet riceve una risposta HTTP cù questa intestazione, usa QUIC per e richieste HTTP successive à quellu duminiu. Una volta chì u balancer cumpleta u QUIC, a nostra infrastruttura manda in modu esplicitu sta azione nantu à HTTP2 / TCP à i nostri centri di dati.
Prestazione: risultati
U rendiment di output hè u mutivu principale per a nostra ricerca di un protokollu megliu. Per principià, avemu creatu un stand cun per sapè cumu si cumportanu QUIC sottu diversi profili di rete. Per pruvà a prestazione di QUIC nantu à e rete di u mondu reale, avemu realizatu esperimenti mentre guidamu intornu à New Delhi utilizendu un trafficu di rete emulatu assai simili à e chjama HTTP in l'app di passageri.
Esperimentu 1
Equipamentu per l'esperimentu:
- pruvà i dispositi Android cù stacks OkHttp è Cronet per assicurà chì permettemu u trafficu HTTPS sopra TCP è QUIC rispettivamente;
- un servitore di emulazione basatu in Java chì manda u listessu tipu di intestazioni HTTPS in risposti è carica i dispositi client per riceve richieste da elli;
- proxy nuvola chì sò fisicamente situati vicinu à l'India per finisce e cunnessione TCP è QUIC. Mentre per a terminazione TCP avemu usatu un proxy inversu , era difficiule di truvà un proxy inversu open source per QUIC. Avemu custruitu un proxy inversu per QUIC noi stessi utilizendu a pila QUIC di basa da Chromium è in u cromu cum'è fonte aperta.
Figura 6. A suite di prova di strada TCP vs QUIC consistia di i dispositi Android cù OkHttp è Cronet, proxies di nuvola per terminating connections, è un servitore di emulazione.
Esperimentu 2
Quandu Google hà fattu QUIC dispunibule cù , avemu usatu u stessu inventariu, ma cù una mudificazione: invece di NGINX, avemu pigliatu Google load balancers per finisce e cunnessione TCP è QUIC da i dispositi, è ancu per indirizzà u trafficu HTTPS à u servitore di emulazione. I equilibratori sò distribuiti in u mondu sanu, ma utilizate u servitore PoP più vicinu à u dispusitivu (grazie à a geolocalizzazione).
Figura 7. In u sicondu esperimentu, avemu vulutu paragunà a latenza di cumplimentu di TCP è QUIC: utilizendu Google Cloud è utilizendu u nostru proxy cloud.
In u risultatu, parechje revelazioni ci aspittàvanu:
- a terminazione via PoP hà migliuratu u rendiment TCP. Siccomu i balancers terminanu e cunnessione TCP più vicinu à l'utilizatori è sò assai ottimizzati, questu risultatu in RTT più bassi, chì migliurà u rendiment TCP. È ancu QUIC hè statu menu affettatu, hà ancu superatu TCP in quantu à riduce a latenza di a cuda (da 10-30 per centu).
- a coda hè affettata . Ancu se u nostru proxy QUIC era più luntanu da i dispositi (circa 50 ms di latenza più altu) cà i bilanci di carica di Google, hà furnitu prestazioni simili - una riduzione di 15% in latenza versus una riduzione di 20% in u percentile 99 per TCP. Questu suggerisce chì a transizione di l'ultima milla hè un collu di buttiglia in a reta.
Figura 8: I risultati di dui esperimenti mostranu chì QUIC supera significativamente TCP.
U trafficu di cumbattimentu
Ispirati da a sperimentazione, avemu implementatu u supportu QUIC in e nostre applicazioni Android è iOS. Avemu realizatu teste A/B per determinà l'impattu di QUIC in e cità induve Uber opera. In generale, avemu vistu una riduzione significativa di i ritardi di coda in e duie regioni, l'operatori di telecomunicazioni è u tipu di rete.
I grafici quì sottu mostranu e migliure percentuali in coda (95 è 99 percentiles) per macro-regione è sfarenti tippi di rete - LTE, 3G, 2G.
Figura 9. In i testi di battaglia, QUIC superò TCP in termini di latenza.
Solu avanti
Forse questu hè solu u principiu - a liberazione di QUIC in a pruduzzione hà furnitu opportunità incredibili per migliurà u rendiment di l'applicazioni sia in rete stabili sia instabili, vale à dì:
Copertura aumentata
Dopu avè analizatu u funziunamentu di u protocolu nantu à u trafficu reale, avemu vistu chì circa 80% di e sessioni anu utilizatu bè QUIC per всех richieste, mentre chì 15% di e sessioni anu utilizatu una cumminazione di QUIC è TCP. Assumimu chì a cumminazione hè dovuta à u timeout di a biblioteca di Cronet torna à TCP, postu chì ùn pò micca distingue trà i fallimenti UDP reali è e cundizioni di rete poveri. Attualmente cerchemu una suluzione à stu prublema mentre travagliemu versu l'implementazione successiva di QUIC.
Ottimisazione QUIC
U trafficu da l'applicazioni mobili hè sensibile à a latenza, ma micca à a larghezza di banda. Inoltre, e nostre applicazioni sò principalmente aduprate in e rete cellulare. Basatu nantu à l'esperimenti, i latenzi di a coda sò sempre alti ancu s'ellu si usa un proxy per finisce TCP è QUIC vicinu à l'utilizatori. Cerchemu attivamente modi per migliurà a gestione di a congestione è migliurà l'efficienza di l'algoritmi di ricuperazione di perdita QUIC.
Cù queste è parechje altre migliure, avemu pensatu à migliurà l'esperienza di l'utilizatori indipendentemente da a rete è a regione, rendendu u trasportu di pacchetti convenientu è senza saldatura più accessibile in u mondu.
Source: www.habr.com