Die QUIC-protokol is uiters interessant om na te kyk, en daarom hou ons daarvan om daaroor te skryf. Maar as vorige publikasies oor QUIC meer van 'n historiese (plaaslike oorlewering, as jy wil) aard en materiaal was, publiseer ons vandag graag 'n vertaling van 'n ander soort - ons sal in 2019 oor die werklike toepassing van die protokol praat. En dit gaan nie oor klein infrastruktuur wat in 'n voorwaardelike motorhuis gebaseer is nie, maar oor Uber, wat feitlik oor die hele wêreld werk. Hoe die maatskappy se ingenieurs tot die besluit gekom het om QUIC in produksie te gebruik, hoe hulle die toetse uitgevoer het en wat hulle gesien het nadat hulle dit in produksie gerol het - onder die sny.
Prente is klikbaar. Lekker lees!
Uber is 'n globale skaal, naamlik 600 stede van teenwoordigheid, in elkeen waarvan die toepassing ten volle staatmaak op draadlose internet van meer as 4500 XNUMX selfoonoperateurs. Gebruikers verwag dat die toepassing nie net vinnig sal wees nie, maar intyds – om dit te lewer, benodig die Uber-toepassing 'n lae vertraging en 'n baie betroubare verbinding. Helaas, maar die stapel presteer nie goed in dinamiese en verlieslose draadlose netwerke nie. Ons het gevind dat swak werkverrigting in hierdie geval direk verband hou met die implementering van TCP in die kerns van bedryfstelsels.
Om die probleem op te los, het ons aansoek gedoen , 'n moderne kanaalvermenigvuldigingsprotokol wat ons meer beheer gee oor die werkverrigting van die vervoerprotokol. Die werkgroep is tans standaardiseer QUIC as .
Na uitgebreide toetsing het ons tot die gevolgtrekking gekom dat die bekendstelling van QUIC in ons toepassing die stertvertragings kleiner sou maak in vergelyking met TCP. Ons het afnames in die 10-30%-reeks vir HTTPS-verkeer in die Bestuurder- en Passasierstoepassings gesien. QUIC het ons ook end-tot-end beheer oor gebruikerspakkette gegee.
In hierdie artikel deel ons ons ervaring van die optimalisering van TCP vir Uber-toepassings met behulp van 'n stapel wat QUIC ondersteun.
Stand van die kuns: TCP
Vandag is TCP die mees gebruikte vervoerprotokol vir die lewering van HTTPS-verkeer op die internet. TCP bied 'n betroubare stroom grepe, en hanteer sodoende netwerkopeenhoping en skakellaagverliese. Die wydverspreide gebruik van TCP vir HTTPS-verkeer is te danke aan die alomteenwoordigheid van eersgenoemde (byna elke bedryfstelsel bevat TCP), beskikbaarheid op die meeste infrastruktuur (byvoorbeeld lasbalanseerders, HTTPS-gevolmagtigdes en CDN'e), en buite-die-boks-funksionaliteit wat op byna die meeste platforms en netwerke beskikbaar is.
Die meeste gebruikers gebruik ons toepassing op pad, en TCP-stertvertragings was ver van die vereistes van ons intydse HTTPS-verkeer. Om dit eenvoudig te stel, gebruikers oor die hele wêreld het dit ervaar - Figuur 1 toon vertragings in groot stede:
Figuur 1. Stertvertragings verskil oor groot stede waar Uber bedrywig is.
Alhoewel vertragings in die Indiese en Brasiliaanse netwerke groter was as in die VSA en die Verenigde Koninkryk, is die stertvertragings aansienlik groter as die gemiddelde vertragings. En dit geld selfs vir die VSA en die Verenigde Koninkryk.
TCP-prestasie oor die lug
TCP is geskep vir bedraad netwerke, dit wil sê met die klem op goed voorspelbare skakels. Maar draadloos netwerke het hul eie kenmerke en probleme. Eerstens is draadlose netwerke vatbaar vir verlies as gevolg van interferensie en seinverswakking. Wi-Fi-netwerke is byvoorbeeld sensitief vir mikrogolwe, bluetooth en ander radiogolwe. Sellulêre netwerke ly aan seinverlies () as gevolg van refleksie / absorpsie van die sein deur voorwerpe en geboue, sowel as van van naburige . Dit lei tot meer betekenisvol (4-10 keer) en meer divers en pakkieverlies in vergelyking met 'n bedrade verbinding.
Om bandwydte-skommeling en verlies te bekamp, gebruik sellulêre netwerke tipies groot buffers vir sarsies van verkeer. Dit kan lei tot oormatige toustaan, wat meer vertragings beteken. Baie dikwels behandel TCP sulke toustaan as 'n verlies as gevolg van 'n verlengde tydsduur, so TCP is geneig om 'n aflos te doen en sodoende die buffer te vul. Hierdie probleem staan bekend as () en dit is baie moderne internet.
Laastens verskil sellulêre netwerkwerkverrigting volgens diensverskaffer, streek en tyd. In Figuur 2 het ons die mediaan vertragings van HTTPS-verkeer oor selle oor 'n reeks van 2 kilometer ingesamel. Die data word ingesamel vir die twee grootste selfoonoperateurs in Delhi, Indië. Soos jy kan sien, verskil prestasie van sel tot sel. Die prestasie van een operateur verskil ook van die prestasie van die tweede een. Dit word beïnvloed deur faktore soos netwerktoegangspatrone, met inagneming van tyd en ligging, gebruikersmobiliteit, sowel as netwerkinfrastruktuur, met inagneming van die digtheid van torings en die verhouding van netwerktipes (LTE, 3G, ens.).
Figuur 2. Vertragings met 'n radius van 2 km as 'n voorbeeld. Delhi, Indië.
Die werkverrigting van sellulêre netwerke wissel ook oor tyd. Figuur 3 toon die mediaan vertraging volgens dag van die week. Ons het ook die verskil op kleiner skaal waargeneem – binne een dag en uur.
Figuur 3. Stertvertragings kan aansienlik verskil op verskillende dae, maar vir dieselfde operateur.
Al die bogenoemde lei daartoe dat TCP-werkverrigting ondoeltreffend is op draadlose netwerke. Voordat ons egter na alternatiewe vir TCP soek, wou ons 'n duidelike begrip oor die volgende punte ontwikkel:
- Is TCP die grootste skuldige in stertvertragings in ons toepassings?
- Het moderne netwerke aansienlike en gevarieerde retoervertragings (RTT)?
- Wat is die impak van RTT en verlies op TCP-prestasie?
TCP prestasie analise
Om te verstaan hoe ons die werkverrigting van TCP ontleed het, laat ons kortliks onthou hoe TCP data van 'n sender na 'n ontvanger oordra. Die sender vestig eers 'n TCP-verbinding deur 'n drierigting uit te voer : Die sender stuur 'n SYN-pakkie, wag vir 'n SYN-ACK-pakkie vanaf die ontvanger, stuur dan 'n ACK-pakkie. Die bykomende tweede en derde pas gaan in om 'n TCP-verbinding te maak. Die ontvanger erken ontvangs van elke pakkie (ACK) om betroubare aflewering te verseker.
As 'n pakkie of ACK verlore gaan, stuur die sender weer na 'n time-out (RTO, ). Die RTO word dinamies bereken op grond van verskeie faktore soos die verwagte RTT latency tussen sender en ontvanger.
Figuur 4. Pakkieuitruiling oor TCP/TLS sluit 'n herversendingmeganisme in.
Om te bepaal hoe TCP in ons toepassings gewerk het, het ons TCP-pakkies gemonitor deur gebruik te maak van vir 'n week op gevegsverkeer wat van die Indiese randbedieners af kom. Ons het toe die TCP-verbindings ontleed . Boonop het ons 'n Android-toepassing geskep wat nagebootsde verkeer na 'n toetsbediener stuur, wat werklike verkeer soveel as moontlik naboots. Slimfone met hierdie toepassing is aan verskeie werknemers versprei wat logs oor 'n paar dae versamel het.
Die resultate van beide eksperimente was in ooreenstemming met mekaar. Ons het hoë RTT latency gesien; stertwaardes was byna 6 keer die mediaanwaarde; die rekenkundige gemiddelde van vertragings is meer as 1 sekonde. Baie verbindings was verliesloos, wat veroorsaak het dat TCP 3,5% van alle pakkies herversend het. In gebiede met opeenhoping, soos lughawens en treinstasies, het ons 'n verlies van 7% waargeneem. Hierdie resultate skep twyfel oor die konvensionele wysheid wat dié wat in sellulêre netwerke gebruik word verminder die verliese by die vervoerlaag aansienlik. Hieronder is die toetsresultate van die "simulator"-toepassing:
Netwerk statistieke
wat beteken
RTT, millisekondes [50%,75%, 95%,99%]
[350, 425, 725, 2300]
RTT-teenstrydigheid, sekondes
Gemiddeld ~1,2 s
Pakkieverlies op intermitterende skakels
Gemiddeld ~3.5% (7% in oorbelaste gebiede)
Byna die helfte van hierdie verbindings het ten minste een pakkieverlies gehad, meestal SYN's en SYN-ACK'e. Die meeste TCP-implementerings gebruik 'n RTO van 1 sekonde vir SYN-pakkies, wat eksponensieel toeneem vir daaropvolgende verliese. Toepassing se laai tye kan toeneem omdat TCP langer neem om verbindings te vestig.
In die geval van datapakkies verminder hoë RTO-waardes die nuttige benutting van die netwerk aansienlik in die teenwoordigheid van tydverliese in draadlose netwerke. Ons het gevind dat die gemiddelde heruitsendingstyd ongeveer 1 sekonde is met 'n stertvertraging van byna 30 sekondes. Sulke hoë latency by die TCP-laag het HTTPS-time-outs en herprobeerversoeke veroorsaak, wat netwerkvertraging en ondoeltreffendheid verder verhoog het.
Terwyl die 75ste persentiel van die gemete RTT's in die omgewing van 425ms was, was die 75ste persentiel vir TCP amper 3 sekondes. Dit dui daarop dat die verlies veroorsaak het dat TCP 7-10 passe gemaak het om data suksesvol oor te dra. Dit kan wees as gevolg van ondoeltreffende RTO berekening, TCP se onvermoë om vinnig te reageer op verlies van in die venster en die ondoeltreffendheid van die opeenhopingsbeheeralgoritme, wat nie onderskei tussen draadlose verlies en verlies as gevolg van netwerkopeenhoping nie. Hieronder is die resultate van TCP-verliestoetse:
TCP Pakkie Verlies Statistiek
Waarde
Persentasie verbindings met ten minste 1 pakkieverlies
45%
Persentasie verbindings met verliese tydens verbindingsvestiging
30%
Persentasie van verbindings met verlies tydens kommunikasie
76%
Verspreiding van vertragings in heruitsending, sekondes [50%, 75%, 95%, 99%] [1, 2.8, 15, 28]
Verspreiding van die aantal heruitsendings vir een pakkie of TCP-segment
[1,3,6,7]
Toepassing van QUIC
Oorspronklik ontwerp deur Google, QUIC is 'n multi-threaded moderne vervoer protokol wat loop op die top van UDP. QUIC is tans (Ons het reeds geskryf dat daar as 't ware twee weergawes van QUIC is, nuuskierig - ongeveer. vertaler). Soos getoon in Figuur 5, is QUIC onder HTTP/3 geplaas (trouens, HTTP/2 bo-op QUIC is HTTP/3, wat nou sterk gestandaardiseer is). Dit vervang die HTTPS- en TCP-lae gedeeltelik deur UDP te gebruik om pakkies te vorm. QUIC ondersteun slegs veilige data-oordrag aangesien TLS volledig in QUIC ingebou is.
Figuur 5: QUIC loop onder HTTP/3, en vervang TLS wat vroeër onder HTTP/2 geloop het.
Hier is die redes wat ons oortuig het om QUIC vir TCP-verharding te gebruik:
- 0-RTT verbinding vestiging. QUIC laat die hergebruik van magtigings van vorige verbindings toe, wat die aantal sekuriteitshanddrukke verminder. In die toekoms sal 0-RTT ondersteun, maar die XNUMX-rigting TCP-handdruk sal steeds vereis word.
- HoL-blokkering te oorkom. HTTP/2 gebruik een TCP-verbinding per kliënt om werkverrigting te verbeter, maar dit kan lei tot HoL (head-of-line) blokkering. QUIC vereenvoudig multipleksing en lewer versoeke onafhanklik aan die toepassing.
- oorlading beheer. QUIC is in die toepassingslaag geleë, wat dit makliker maak om die hoofvervoeralgoritme op te dateer wat aanstuur bestuur op grond van netwerkparameters (verlieskoers of RTT). Die meeste TCP-implementasies gebruik die algoritme , wat nie optimaal is vir latensie-sensitiewe verkeer nie. Onlangs ontwikkelde algoritmes soos , modelleer die netwerk meer akkuraat en optimaliseer vertragings. QUIC laat jou toe om BBR te gebruik en hierdie algoritme soos dit op te dateer .
- aanvulling van verliese. QUIC roep twee TLP's () voor die RTO inskop – selfs wanneer die verliese baie opvallend is. Dit verskil van TCP-implementerings. TLP herversend meestal die laaste pakkie (of die nuwe een as daar een is) om 'n vinnige aanvulling te begin. Die hantering van stertvertragings is veral nuttig vir hoe Uber met die netwerk werk, naamlik vir kort, episodiese en vertragingsensitiewe data-oordragte.
- geoptimaliseerde ACK. Aangesien elke pakkie 'n unieke reeksnommer het, is daar geen probleem nie pakkies terwyl hulle dit weer versend. ACK-pakkies bevat ook tyd om die pakkie te verwerk en 'n ACK aan die kliëntkant te genereer. Hierdie kenmerke verseker dat QUIC RTT meer akkuraat bereken. ACK in QUIC ondersteun tot 256 bands , wat die sender help om meer veerkragtig te wees teen pakkie herskuif en minder grepe in die proses te gebruik. Selektiewe ACK () in TCP los nie hierdie probleem in alle gevalle op nie.
- verbinding migrasie. QUIC-verbindings word met 'n 64-bis-ID geïdentifiseer sodat as 'n kliënt IP-adresse verander, die ou verbindings-ID sonder onderbreking op die nuwe IP-adres gebruik kan word. Dit is 'n baie algemene praktyk vir mobiele toepassings wanneer 'n gebruiker tussen Wi-Fi en sellulêre verbindings wissel.
Alternatiewe vir QUIC
Ons het alternatiewe benaderings oorweeg om die probleem op te los voordat ons QUIC gekies het.
Eerstens het ons probeer om TPC PoPs (Points of Presence) te ontplooi om TCP-verbindings nader aan gebruikers te beëindig. In wese beëindig PoP's die TCP-verbinding met die mobiele toestel nader aan die sellulêre netwerk en stuur die verkeer terug na die oorspronklike infrastruktuur. Deur TCP nader te beëindig, kan ons moontlik die RTT verminder en verseker dat TCP meer reageer op dinamiese draadlose omgewings. Ons eksperimente het egter getoon dat die meeste van die RTT en verlies van sellulêre netwerke afkomstig is en die gebruik van PoP's bied nie 'n beduidende prestasieverbetering nie.
Ons het ook gekyk na die instel van TCP-parameters. Dit was moeilik om die TCP-stapel op ons heterogene randbedieners op te stel, aangesien TCP uiteenlopende implementerings oor OS-weergawes het. Dit was moeilik om verskeie netwerkkonfigurasies te implementeer en te toets. Die konfigurasie van TCP direk op mobiele toestelle was nie moontlik nie weens 'n gebrek aan toestemmings. Belangriker nog, kenmerke soos 0-RTT-verbindings en verbeterde RTT-voorspelling is van kritieke belang vir die protokol-argitektuur en daarom is dit nie moontlik om 'n beduidende voordeel te behaal deur TCP alleen op te stel nie.
Laastens het ons verskeie UDP-gebaseerde protokolle geëvalueer wat videostroming probleem oplos - ons wou sien of hierdie protokolle in ons geval sou help. Helaas, hulle het 'n ernstige gebrek aan baie sekuriteitsinstellings gehad, en hulle het ook 'n bykomende TCP-verbinding nodig vir metadata en beheerinligting.
Ons navorsing het getoon dat QUIC miskien die enigste protokol is wat kan help met die probleem van internetverkeer, terwyl beide sekuriteit en werkverrigting in ag geneem word.
Integrasie van QUIC in die platform
Om QUIC suksesvol in te sluit en toepassingsprestasie te verbeter in swak konneksie, het ons die ou stapel (HTTP/2 oor TLS/TCP) met die QUIC-protokol vervang. Ons het die netwerkbiblioteek gebruik van , wat die oorspronklike Google-weergawe van die protokol bevat - gQUIC. Hierdie implementering word ook voortdurend verbeter om die nuutste IETF-spesifikasie te volg.
Ons het Cronet eers in ons Android-toepassings geïntegreer om QUIC-ondersteuning by te voeg. Die integrasie is op so 'n manier uitgevoer dat die koste van migrasie tot die minimum beperk is. In plaas daarvan om die ou netwerkstapel wat die biblioteek gebruik het, heeltemal te vervang , Ons het Cronet ONDER die OkHttp API-raamwerk geïntegreer. Deur op hierdie manier te integreer, het ons veranderinge aan ons netwerkoproepe (wat gebruik ) op die API-vlak.
Soortgelyk aan die Android-benadering, het ons Cronet in Uber iOS-toepassings geïmplementeer deur HTTP-verkeer vanaf die netwerk te onderskep gebruik . Hierdie abstraksie, verskaf deur die iOS-stigting, hanteer protokol-spesifieke URL-data en verseker dat ons Cronet in ons iOS-toepassings kan integreer sonder aansienlike migrasiekoste.
Voltooiing van QUIC op Google Cloud-balanseerders
Aan die agterkant word QUIC-voltooiing verskaf deur die Google Wolk-lasbalansering-infrastruktuur, wat gebruik maak van kopskrifte in antwoorde om QUIC te ondersteun. Oor die algemeen voeg die balanseerder die alt-svc-kopskrif by elke HTTP-versoek en dit bevestig reeds QUIC-ondersteuning vir die domein. Wanneer 'n Cronet-kliënt 'n HTTP-antwoord met hierdie kopskrif ontvang, gebruik dit QUIC vir daaropvolgende HTTP-versoeke na daardie domein. Sodra die balanseerder QUIC voltooi, stuur ons infrastruktuur hierdie aksie uitdruklik oor HTTP2/TCP na ons datasentrums.
Prestasie: Resultate
Die uitsetprestasie is die hoofrede vir ons soeke na die beste protokol. Om mee te begin, het ons 'n stand geskep met om uit te vind hoe QUIC met verskillende netwerkprofiele sal optree. Om te toets hoe QUIC in regte netwerke werk, het ons eksperimente rondom Nieu-Delhi uitgevoer met gebruik van nagebootste netwerkverkeer, baie soos HTTP-oproepe in 'n passasierstoepassing.
Eksperiment 1
Toerusting vir die eksperiment:
- Android-toetstoestelle met OkHttp- en Cronet-stapels om seker te maak ons laat HTTPS-verkeer oor onderskeidelik TCP en QUIC toe;
- 'n Java-gebaseerde emulasiebediener wat HTTPS-opskrifte van dieselfde tipe in antwoorde stuur en kliënttoestelle laai om versoeke van hulle te ontvang;
- wolk gevolmagtigdes wat fisies naby Indië geleë is om TCP- en QUIC-verbindings te beëindig. Terwyl ons vir TCP-beëindiging 'n omgekeerde instaanbediener gebruik het , was dit moeilik om 'n oopbron-omgekeerde instaanbediener vir QUIC te vind. Ons het self 'n omgekeerde instaanbediener vir QUIC gebou deur die basis QUIC-stapel van Chromium en dit is in chroom as oopbron.
Figuur 6. Die TCP vs QUIC padtoetsstel het bestaan uit Android-toestelle met OkHttp en Cronet, wolkgevolmagtigdes om verbindings te beëindig, en 'n emulasiebediener.
Eksperiment 2
Toe Google QUIC beskikbaar gestel het met , het ons dieselfde voorraad gebruik, maar met een wysiging: in plaas van NGINX, het ons Google se balanseerders geneem om TCP- en QUIC-verbindings vanaf toestelle te beëindig, asook om HTTPS-verkeer na die emulasiebediener te lei. Balanseerders word oor die hele wêreld versprei, maar gebruik die naaste PoP-bediener aan die toestel (danksy geoligging).
Figuur 7. In die tweede eksperiment wou ons TCP en QUIC voltooiing latency vergelyk: die gebruik van Google Cloud en die gebruik van ons wolk proxy.
Gevolglik het verskeie onthullings op ons gewag:
- beëindiging via PoP verbeterde TCP-prestasie. Aangesien balanseerders TCP-verbindings nader aan gebruikers beëindig en hoogs geoptimaliseer is, lei dit tot laer RTT's, wat TCP-werkverrigting verbeter. En hoewel QUIC minder geraak is, het dit steeds TCP omseil in terme van die vermindering van stertvertragings (met 10-30 persent).
- sterte aangetas word . Alhoewel ons QUIC-instaanbediener verder weg was van die toestelle (ongeveer 50 ms hoër latency) as Google se balanseerders, het dit soortgelyke werkverrigting gelewer - 'n 15% vermindering in latensie teenoor 'n 20% vermindering in die 99ste persentiel vir TCP. Dit dui daarop dat die laaste myl-oorgang 'n bottelnek in die netwerk is.
Figuur 8. Die resultate van twee eksperimente toon dat QUIC aansienlik beter is as TCP.
Bestry verkeer
Geïnspireer deur eksperimente, het ons QUIC-ondersteuning in ons Android- en iOS-toepassings geïmplementeer. Ons het A/B-toetse uitgevoer om die impak van QUIC in stede waar Uber bedrywig is, te bepaal. Oor die algemeen het ons 'n aansienlike vermindering in stertvertragings gesien in die konteks van beide streke en telekommunikasie-operateurs en netwerktipe.
Die grafieke hieronder toon die persentasie verbeterings in die sterte (95ste en 99ste persentiele) volgens makrostreke en verskillende netwerktipes - LTE, 3G, 2G.
Figuur 9. QUIC het beter as TCP gevaar in latensie in gevegstoetse.
Slegs vorentoe
Miskien is dit net die begin - die uitrol van QUIC na produksie het wonderlike geleenthede gebied om toepassingsprestasie in beide stabiele en onstabiele netwerke te verbeter, naamlik:
Dekking verhoog
Nadat ons die werkverrigting van die protokol op werklike verkeer ontleed het, het ons gesien dat ongeveer 80% van sessies QUIC suksesvol gebruik het om alle versoeke, terwyl 15% van sessies 'n kombinasie van QUIC en TCP gebruik het. Ons neem aan dat die kombinasie te wyte is aan die Cronet-biblioteek wat met 'n uitteltyd terugskakel na TCP, aangesien dit nie kan onderskei tussen werklike UDP-foute en slegte netwerktoestande nie. Ons soek tans 'n oplossing vir hierdie probleem terwyl ons werk aan die daaropvolgende implementering van QUIC.
VINNIGE optimering
Verkeer vanaf mobiele toepassings is latensiesensitief, maar nie bandwydtesensitief nie. Ons toepassings word ook hoofsaaklik in sellulêre netwerke gebruik. Op grond van eksperimentering is die agterstande steeds groot, al word gevolmagtigdes gebruik om TCP en QUIC naby gebruikers te beëindig. Ons is aktief op soek na maniere om opeenhopingsbestuur te verbeter en die doeltreffendheid van QUIC verliesherstelalgoritmes te verhoog.
Met hierdie en verskeie ander verbeterings beplan ons om die gebruikerservaring te verbeter, ongeag die netwerk en streek, en maak gerieflike en naatlose pakkievervoer meer toeganklik regoor die wêreld.
Bron: will.com