QUIC protokolu ir ÄrkÄrtÄ«gi interesanti skatÄ«ties, tÄpÄc mums patÄ«k par to rakstÄ«t. Bet, ja iepriekÅ”ÄjÄs publikÄcijas par QUIC bija vairÄk vÄsturiska (ja vÄlaties, novadpÄtniecÄ«bas) daba un aparatÅ«ra, tad Å”odien ar prieku publicÄjam cita veida tulkojumu - runÄsim par protokola reÄlo pielietojumu 2019. gadÄ. TurklÄt runa nav par mazu infrastruktÅ«ru, kas bÄzÄta tÄ dÄvÄtajÄ garÄžÄ, bet gan par Uber, kas darbojas gandrÄ«z visÄ pasaulÄ. KÄ uzÅÄmuma inženieri pieÅÄma lÄmumu izmantot QUIC ražoÅ”anÄ, kÄ viÅi veica testus un ko viÅi redzÄja pÄc tÄ ievieÅ”anas ražoÅ”anÄ - zem griezuma.
AttÄli ir klikŔķinÄmi. Izbaudi lasÄ«Å”anu!
Uber ir globÄls mÄrogs, proti, 600 klÄtbÅ«tnes pilsÄtas, un katrÄ no tÄm lietojumprogramma pilnÄ«bÄ balstÄs uz bezvadu internetu no vairÄk nekÄ 4500 mobilo sakaru operatoriem. LietotÄji sagaida, ka lietotne bÅ«s ne tikai Ätra, bet arÄ« reÄllaikÄ ā lai to panÄktu, Uber lietotnei ir nepiecieÅ”ams zems latentums un ļoti uzticams savienojums. Ak, bet kaudze nedarbojas dinamiskos un ar zaudÄjumiem pakļautos bezvadu tÄ«klos. MÄs sapratÄm, ka Å”ajÄ gadÄ«jumÄ zemÄ veiktspÄja ir tieÅ”i saistÄ«ta ar TCP ievieÅ”anu operÄtÄjsistÄmu kodolos.
Lai atrisinÄtu problÄmu, mÄs pieteicÄmies , moderns kanÄlu multipleksÄÅ”anas protokols, kas sniedz mums lielÄku kontroli pÄr transporta protokola veiktspÄju. Å obrÄ«d darba grupa standartizÄ QUIC kÄ .
PÄc plaÅ”Äs testÄÅ”anas mÄs secinÄjÄm, ka QUIC ievieÅ”ana mÅ«su lietojumprogrammÄ samazinÄtu astes latentumus salÄ«dzinÄjumÄ ar TCP. MÄs novÄrojÄm HTTPS trafika samazinÄjumu par 10ā30% vadÄ«tÄja un pasažieru lietojumprogrammÄs. QUIC arÄ« sniedza mums pilnÄ«gu kontroli pÄr lietotÄju pakotnÄm.
Å ajÄ rakstÄ mÄs dalÄmies pieredzÄ par TCP optimizÄÅ”anu Uber lietojumprogrammÄm, izmantojot steku, kas atbalsta QUIC.
JaunÄkÄ tehnoloÄ£ija: TCP
MÅ«sdienÄs TCP ir visbiežÄk izmantotais transporta protokols HTTPS trafika nodroÅ”inÄÅ”anai internetÄ. TCP nodroÅ”ina uzticamu baitu plÅ«smu, tÄdÄjÄdi novÄrÅ”ot tÄ«kla pÄrslodzes un saites slÄÅa zudumus. TCP plaÅ”Ä izmantoÅ”ana HTTPS trafikam ir saistÄ«ta ar pirmÄs pieejamo funkcionalitÄti (gandrÄ«z katrÄ operÄtÄjsistÄmÄ ir TCP), pieejamÄ«bu lielÄkajÄ daÄ¼Ä infrastruktÅ«ru (piemÄram, slodzes balansÄtÄjiem, HTTPS starpniekserveriem un CDN) un pieejamo funkcionalitÄti. gandrÄ«z lielÄkajÄ daÄ¼Ä platformu un tÄ«klu.
LielÄkÄ daļa lietotÄju izmanto mÅ«su lietotni, atrodoties ceļÄ, un TCP gala latentums ne tuvu neatbilda mÅ«su reÄllaika HTTPS trafika prasÄ«bÄm. VienkÄrÅ”i sakot, lietotÄji visÄ pasaulÄ to ir piedzÄ«vojuÅ”i ā 1. attÄlÄ parÄdÄ«ti kavÄjumi lielÄkajÄs pilsÄtÄs:
1. attÄls. Astes latentums dažÄdÄs Uber galvenajÄs pilsÄtÄs ir atŔķirÄ«gs.
Lai gan Indijas un BrazÄ«lijas tÄ«klos latentums bija lielÄks nekÄ ASV un ApvienotajÄ KaralistÄ, astes latentums ir ievÄrojami lielÄks par vidÄjo latentumu. Un tas attiecas pat uz ASV un LielbritÄniju.
TCP veiktspÄja pa gaisu
TCP tika izveidots priekÅ” vadu tÄ«kliem, tas ir, ar uzsvaru uz ļoti paredzamÄm saitÄm. tomÄr bezvadu tÄ«kliem ir savas Ä«patnÄ«bas un grÅ«tÄ«bas. PirmkÄrt, bezvadu tÄ«kli ir jutÄ«gi pret zudumiem traucÄjumu un signÄla vÄjinÄÅ”anÄs dÄļ. PiemÄram, Wi-Fi tÄ«kli ir jutÄ«gi pret mikroviļÅiem, Bluetooth un citiem radioviļÅiem. Mobilie tÄ«kli cieÅ” no signÄla zuduma () signÄla atstaroÅ”anas/absorbcijas dÄļ objektos un ÄkÄs, kÄ arÄ« no no kaimiÅiem . Tas noved pie nozÄ«mÄ«gÄka (4-10 reizes) un daudzveidÄ«gÄka un pakeÅ”u zudums salÄ«dzinÄjumÄ ar vadu savienojumu.
Lai cÄ«nÄ«tos pret joslas platuma svÄrstÄ«bÄm un zudumiem, mobilie tÄ«kli parasti izmanto lielus buferus trafika pÄrrÄvumiem. Tas var novest pie pÄrmÄrÄ«gas rindas, kas nozÄ«mÄ ilgÄku kavÄÅ”anos. Ä»oti bieži TCP uzskata Å”o rindu par izŔķÄrdÄ«bu pagarinÄtÄ taimauta dÄļ, tÄpÄc TCP mÄdz pÄrsÅ«tÄ«t un tÄdÄjÄdi aizpildÄ«t buferi. Å Ä« problÄma ir pazÄ«stama kÄ (), un tas ir ļoti moderns internets.
Visbeidzot, mobilÄ tÄ«kla veiktspÄja atŔķiras atkarÄ«bÄ no operatora, reÄ£iona un laika. 2. attÄlÄ mÄs apkopojÄm HTTPS trafika vidÄjo aizkavi ŔūnÄs 2 kilometru diapazonÄ. Dati savÄkti par diviem galvenajiem mobilo sakaru operatoriem Deli, IndijÄ. KÄ redzat, veiktspÄja dažÄdÄs ŔūnÄs atŔķiras. TÄpat viena operatora produktivitÄte atŔķiras no otrÄ. To ietekmÄ tÄdi faktori kÄ tÄ«kla ievades modeļi, Åemot vÄrÄ laiku un atraÅ”anÄs vietu, lietotÄju mobilitÄte, kÄ arÄ« tÄ«kla infrastruktÅ«ra, Åemot vÄrÄ torÅu blÄ«vumu un tÄ«kla veidu attiecÄ«bu (LTE, 3G utt.).
2. attÄls. KavÄÅ”anÄs, kÄ piemÄru izmantojot 2 km rÄdiusu. Deli, Indija.
ArÄ« mobilo tÄ«klu veiktspÄja laika gaitÄ mainÄs. 3. attÄlÄ parÄdÄ«ts vidÄjais latentums pÄc nedÄļas dienÄm. MÄs novÄrojÄm atŔķirÄ«bas arÄ« mazÄkÄ mÄrogÄ vienas dienas un stundas laikÄ.
3. attÄls. Astes aizkave var ievÄrojami atŔķirties dažÄdÄs dienÄs, bet vienam un tam paÅ”am operatoram.
Visu iepriekÅ” minÄto iemeslu dÄļ TCP veiktspÄja ir neefektÄ«va bezvadu tÄ«klos. TomÄr, pirms meklÄjÄm alternatÄ«vas TCP, mÄs vÄlÄjÄmies izstrÄdÄt precÄ«zu izpratni par Å”Ädiem jautÄjumiem:
- vai TCP ir galvenais vaininieks aiz astes latentuma mÅ«su lietojumprogrammÄs?
- Vai mÅ«sdienu tÄ«klos ir ievÄrojamas un dažÄdas turp un atpakaļ aizkaves (RTT)?
- KÄda ir RTT un zaudÄjumu ietekme uz TCP veiktspÄju?
TCP veiktspÄjas analÄ«ze
Lai saprastu, kÄ mÄs analizÄjÄm TCP veiktspÄju, Ä«si apskatÄ«sim, kÄ TCP pÄrsÅ«ta datus no sÅ«tÄ«tÄja uz saÅÄmÄju. PirmkÄrt, sÅ«tÄ«tÄjs izveido TCP savienojumu, veicot trÄ«svirzienu savienojumu : SÅ«tÄ«tÄjs nosÅ«ta SYN paketi, gaida SYN-ACK paketi no saÅÄmÄja un pÄc tam nosÅ«ta ACK paketi. TCP savienojuma izveidei tiek pavadÄ«ta papildu otrÄ un treÅ”Ä caurlaide. SaÅÄmÄjs apstiprina katras paketes saÅemÅ”anu (ACK), lai nodroÅ”inÄtu uzticamu piegÄdi.
Ja tiek pazaudÄta pakete vai ACK, sÅ«tÄ«tÄjs pÄc taimauta pÄrsÅ«ta to atkÄrtoti (RTO, ). RTO tiek aprÄÄ·inÄts dinamiski, pamatojoties uz dažÄdiem faktoriem, piemÄram, paredzamo RTT aizkavi starp sÅ«tÄ«tÄju un saÅÄmÄju.
4. attÄls. PakeÅ”u apmaiÅa, izmantojot TCP/TLS, ietver atkÄrtotas pÄrraides mehÄnismu.
Lai noteiktu, kÄ TCP darbojas mÅ«su lietojumprogrammÄs, mÄs uzraudzÄ«jÄm TCP paketes, izmantojot nedÄļu par kaujas trafiku, kas nÄk no Indijas malas serveriem. PÄc tam mÄs analizÄjÄm TCP savienojumus, izmantojot . TurklÄt mÄs izveidojÄm Android lietojumprogrammu, kas nosÅ«ta emulÄtu trafiku uz testa serveri, pÄc iespÄjas imitÄjot reÄlo trafiku. ViedtÄlruÅi ar Å”o aplikÄciju tika izdalÄ«ti vairÄkiem darbiniekiem, kuri vÄca žurnÄlus vairÄku dienu laikÄ.
Abu eksperimentu rezultÄti saskanÄja viens ar otru. MÄs redzÄjÄm lielus RTT latentumus; astes vÄrtÄ«bas bija gandrÄ«z 6 reizes lielÄkas par vidÄjo vÄrtÄ«bu; kavÄjumu vidÄjais aritmÄtiskais ir lielÄks par 1 sekundi. Daudzi savienojumi bija ar zaudÄjumiem, kÄ rezultÄtÄ TCP atkÄrtoti pÄrsÅ«tÄ«ja 3,5% no visÄm paketÄm. PÄrslogotÄs vietÄs, piemÄram, lidostÄs un dzelzceļa stacijÄs, mÄs piedzÄ«vojÄm 7% zaudÄjumus. Å ie rezultÄti liek apÅ”aubÄ«t parasto gudrÄ«bu, ko izmanto mobilajos tÄ«klos ievÄrojami samazinÄt zaudÄjumus transporta lÄ«menÄ«. TÄlÄk ir parÄdÄ«ti lietojumprogrammas āsimulatorsā testa rezultÄti:
TÄ«kla rÄdÄ«tÄji
VÄrtÄ«bas
RTT, milisekundes [50%, 75%, 95%, 99%]
[350, 425, 725, 2300]
RTT novirze, sekundes
VidÄji ~1,2 s
PakeŔu zudums nestabilos savienojumos
VidÄji ~3.5% (7% pÄrslogotÄs vietÄs)
GandrÄ«z pusei no Å”iem savienojumiem bija vismaz viens pakeÅ”u zudums, lielÄkÄ daļa no tiem bija SYN un SYN-ACK paketes. LielÄkÄ daļa TCP ievieÅ”anu izmanto RTO vÄrtÄ«bu 1 sekunde SYN paketÄm, kas eksponenciÄli palielinÄs turpmÄko zaudÄjumu gadÄ«jumÄ. Lietojumprogrammu ielÄdes laiks var palielinÄties, jo TCP savienojuma izveide prasa ilgÄku laiku.
Datu pakeÅ”u gadÄ«jumÄ augstas RTO vÄrtÄ«bas ievÄrojami samazina tÄ«kla lietderÄ«go izmantoÅ”anu, ja bezvadu tÄ«klos ir Ä«slaicÄ«gi zudumi. MÄs noskaidrojÄm, ka vidÄjais atkÄrtotas pÄrraides laiks ir aptuveni 1 sekunde ar gandrÄ«z 30 sekunžu aizkavi. Å ie augstie latentumi TCP lÄ«menÄ« izraisÄ«ja HTTPS taimautu un atkÄrtotus pieprasÄ«jumus, vÄl vairÄk palielinot tÄ«kla latentumu un neefektivitÄti.
KamÄr izmÄrÄ«tÄs RTT 75. procentile bija aptuveni 425 ms, TCP 75. procentile bija gandrÄ«z 3 sekundes. Tas norÄda, ka zaudÄjuma dÄļ TCP bija jÄveic 7ā10 pÄrejas, lai veiksmÄ«gi pÄrsÅ«tÄ«tu datus. Tas var bÅ«t neefektÄ«va RTO aprÄÄ·ina sekas, TCP nespÄja Ätri reaÄ£Ät uz zaudÄjumiem logÄ un pÄrslodzes kontroles algoritma neefektivitÄte, kas nenoŔķir bezvadu sakaru zudumus no tÄ«kla pÄrslodzes izraisÄ«tiem zaudÄjumiem. TÄlÄk ir sniegti TCP zudumu testu rezultÄti:
TCP pakeŔu zudumu statistika
VÄrtÄ«ba
Savienojumu procentuÄlÄ daļa ar vismaz 1 pakeÅ”u zudumu
45%
Savienojumu procentuÄlÄ daļa ar zudumiem savienojuma iestatÄ«Å”anas laikÄ
30%
Savienojumu procentuÄlÄ daļa ar zudumiem datu apmaiÅas laikÄ
76%
RetranslÄcijas aizkaves sadalÄ«jums, sekundes [50%, 75%, 95%, 99%] [1, 2.8, 15, 28]
RetranslÄciju skaita sadalÄ«jums vienai paketei vai TCP segmentam
[1,3,6,7]
QUIC pielietojums
SÄkotnÄji Google izstrÄdÄtais QUIC ir daudzpavedienu moderns transporta protokols, kas darbojas papildus UDP. PaÅ”laik ir pieejams QUIC (mÄs jau rakstÄ«jÄm, ka ir it kÄ divas QUIC versijas, ziÅkÄrÄ«gs ā apm. tulks). KÄ parÄdÄ«ts 5. attÄlÄ, QUIC atrodas zem HTTP/3 (faktiski HTTP/2 virs QUIC ir HTTP/3, kas tagad tiek intensÄ«vi standartizÄts). Tas daļÄji aizstÄj HTTPS un TCP slÄÅus, pakeÅ”u veidoÅ”anai izmantojot UDP. QUIC atbalsta tikai droÅ”u datu pÄrsÅ«tÄ«Å”anu, jo TLS ir pilnÄ«bÄ iebÅ«vÄts QUIC.
5. attÄls. QUIC darbojas, izmantojot HTTP/3, aizstÄjot TLS, kas iepriekÅ” darbojÄs ar HTTP/2.
TÄlÄk ir norÄdÄ«ti iemesli, kas mÅ«s pÄrliecinÄja izmantot QUIC TCP pastiprinÄÅ”anai:
- 0-RTT savienojuma izveide. QUIC ļauj atkÄrtoti izmantot autorizÄcijas no iepriekÅ”Äjiem savienojumiem, samazinot droŔības rokasspiedienu skaitu. NÄkotnÄ atbalstÄ«s 0-RTT, taÄu joprojÄm bÅ«s nepiecieÅ”ams trÄ«svirzienu TCP rokasspiediens.
- HoL bloÄ·ÄÅ”anas pÄrvarÄÅ”ana. HTTP/2 izmanto vienu TCP savienojumu katram klientam, lai uzlabotu veiktspÄju, taÄu tas var izraisÄ«t HoL (head-of-line) bloÄ·ÄÅ”anu. QUIC vienkÄrÅ”o multipleksÄÅ”anu un piegÄdÄ pieprasÄ«jumus lietojumprogrammai neatkarÄ«gi.
- sastrÄgumu kontrole. QUIC atrodas lietojumprogrammas slÄnÄ«, atvieglojot galvenÄ transporta algoritma atjauninÄÅ”anu, kas kontrolÄ sÅ«tÄ«Å”anu, pamatojoties uz tÄ«kla parametriem (zaudÄjumu skaitu vai RTT). LielÄkÄ daļa TCP implementÄciju izmanto algoritmu , kas nav optimÄla latentuma jutÄ«gai datplÅ«smai. Nesen izstrÄdÄti algoritmi, piemÄram , precÄ«zÄk modelÄt tÄ«klu un optimizÄt latentumu. QUIC ļauj izmantot BBR un atjauninÄt Å”o algoritmu, kÄ tas tiek izmantots. .
- zaudÄjumu papildinÄÅ”ana. QUIC izsauc divus TLP () pirms RTO iedarbinÄÅ”anas ā pat tad, ja zaudÄjumi ir ļoti pamanÄmi. Tas atŔķiras no TCP ievieÅ”anas. TLP pÄrsÅ«ta galvenokÄrt pÄdÄjo paketi (vai jauno, ja tÄda ir), lai aktivizÄtu Ätru papildinÄÅ”anu. Astes aizkaves apstrÄde ir Ä«paÅ”i noderÄ«ga tam, kÄ Uber darbojas savÄ tÄ«klÄ, proti, Ä«sai, sporÄdiskai un latentuma jutÄ«gai datu pÄrsÅ«tÄ«Å”anai.
- optimizÄta ACK. TÄ kÄ katrai paketei ir unikÄls kÄrtas numurs, problÄmu nav paketes, kad tÄs tiek atkÄrtoti pÄrsÅ«tÄ«tas. ACK paketÄs ir arÄ« laiks, lai apstrÄdÄtu paketi un Ä£enerÄtu ACK klienta pusÄ. Å Ä«s funkcijas nodroÅ”ina, ka QUIC precÄ«zÄk aprÄÄ·ina RTT. ACK in QUIC atbalsta lÄ«dz 256 joslÄm , palÄ«dzot sÅ«tÄ«tÄjam bÅ«t noturÄ«gÄkam pret pakeÅ”u jaukÅ”anu un Å”ajÄ procesÄ izmantot mazÄk baitu. SelektÄ«vÄ ACK () TCP neatrisina Å”o problÄmu visos gadÄ«jumos.
- savienojuma migrÄcija. QUIC savienojumus identificÄ ar 64 bitu ID, tÄdÄļ, ja klients maina IP adreses, veco savienojuma ID var turpinÄt bez pÄrtraukuma izmantot jaunajÄ IP adresÄ. TÄ ir ļoti izplatÄ«ta prakse mobilajÄm lietojumprogrammÄm, kurÄs lietotÄjs pÄrslÄdzas starp Wi-Fi un mobilo sakaru savienojumiem.
Alternatīvas QUIC
Pirms QUIC izvÄles mÄs apsvÄrÄm alternatÄ«vas problÄmas risinÄÅ”anas pieejas.
PirmÄ lieta, ko mÄÄ£inÄjÄm, bija izvietot TPC PoP (klÄtbÅ«tnes punktus), lai pÄrtrauktu TCP savienojumus tuvÄk lietotÄjiem. BÅ«tÄ«bÄ PoP pÄrtrauc TCP savienojumu ar mobilo ierÄ«ci, kas atrodas tuvÄk mobilajam tÄ«klam, un pÄrsÅ«ta trafiku atpakaļ uz sÄkotnÄjo infrastruktÅ«ru. TuvÄk pÄrtraucot TCP, mÄs potenciÄli varam samazinÄt RTT un nodroÅ”inÄt, ka TCP vairÄk reaÄ£Ä uz dinamisku bezvadu vidi. TomÄr mÅ«su eksperimenti ir parÄdÄ«juÅ”i, ka lielÄkÄ daļa RTT un zudumu rodas no mobilajiem tÄ«kliem, un PoP izmantoÅ”ana nenodroÅ”ina bÅ«tisku veiktspÄjas uzlaboÅ”anos.
MÄs arÄ« apskatÄ«jÄm TCP parametru regulÄÅ”anu. TCP steka iestatÄ«Å”ana mÅ«su neviendabÄ«gajos malas serveros bija sarežģīta, jo TCP dažÄdÄs OS versijÄs ir ieviestas atŔķirÄ«gi. Bija grÅ«ti to ieviest un pÄrbaudÄ«t dažÄdas tÄ«kla konfigurÄcijas. TCP konfigurÄÅ”ana tieÅ”i mobilajÄs ierÄ«cÄs nebija iespÄjama atļauju trÅ«kuma dÄļ. VÄl svarÄ«gÄk ir tas, ka tÄdas funkcijas kÄ 0-RTT savienojumi un uzlabota RTT prognozÄÅ”ana ir bÅ«tiskas protokola arhitektÅ«rai, un tÄpÄc nav iespÄjams sasniegt ievÄrojamas priekÅ”rocÄ«bas, noregulÄjot tikai TCP.
Visbeidzot, mÄs novÄrtÄjÄm vairÄkus UDP protokolus, kas novÄrÅ” video straumÄÅ”anas problÄmas ā mÄs vÄlÄjÄmies noskaidrot, vai Å”ie protokoli varÄtu palÄ«dzÄt mÅ«su gadÄ«jumÄ. DiemžÄl tiem ļoti trÅ«ka daudzu droŔības iestatÄ«jumu, kÄ arÄ« bija nepiecieÅ”ams papildu TCP savienojums metadatiem un vadÄ«bas informÄcijai.
MÅ«su pÄtÄ«jumi ir parÄdÄ«juÅ”i, ka QUIC, iespÄjams, ir vienÄ«gais protokols, kas var palÄ«dzÄt atrisinÄt interneta trafika problÄmu, vienlaikus Åemot vÄrÄ gan droŔību, gan veiktspÄju.
QUIC integrÄcija platformÄ
Lai veiksmÄ«gi iegultu QUIC un uzlabotu lietojumprogrammu veiktspÄju vÄjÄs savienojamÄ«bas vidÄs, mÄs nomainÄ«jÄm veco steku (HTTP/2, izmantojot TLS/TCP) ar QUIC protokolu. MÄs izmantojÄm tÄ«kla bibliotÄku no , kurÄ ir oriÄ£inÄlÄ, Google protokola versija - gQUIC. Å Ä« ievieÅ”ana arÄ« tiek pastÄvÄ«gi uzlabota, lai atbilstu jaunÄkajai IETF specifikÄcijai.
Vispirms mÄs integrÄjÄm Cronet savÄs Android lietotnÄs, lai pievienotu QUIC atbalstu. IntegrÄcija tika veikta tÄ, lai pÄc iespÄjas samazinÄtu migrÄcijas izmaksas. TÄ vietÄ, lai pilnÄ«bÄ aizstÄtu veco tÄ«kla steku, kas izmantoja bibliotÄku , esam integrÄjuÅ”i Cronet UZ OkHttp API ietvaru. Veicot integrÄciju Å”ÄdÄ veidÄ, mÄs izvairÄ«jÄmies no izmaiÅÄm mÅ«su tÄ«kla zvanos (kurus izmanto ) API lÄ«menÄ«.
LÄ«dzÄ«gi kÄ Android ierÄ«cÄm, mÄs ieviesÄm Cronet Uber lietotnÄs operÄtÄjsistÄmÄ iOS, pÄrtverot HTTP trafiku no tÄ«kla. izmantojot . Å Ä« abstrakcija, ko nodroÅ”ina iOS fonds, apstrÄdÄ protokolam specifiskus URL datus un nodroÅ”ina, ka mÄs varam integrÄt Cronet mÅ«su iOS lietojumprogrammÄs bez ievÄrojamÄm migrÄcijas izmaksÄm.
QUIC pabeigÅ”ana pakalpojumÄ Google Cloud Balancers
AizmugurÄjÄ pusÄ QUIC pabeigÅ”anu nodroÅ”ina Google mÄkoÅa slodzes lÄ«dzsvaroÅ”anas infrastruktÅ«ra, kas izmanto galvenes atbildÄs, lai atbalstÄ«tu QUIC. Parasti balansÄtÄjs pievieno alt-svc galveni katram HTTP pieprasÄ«jumam, un tas jau apstiprina QUIC atbalstu domÄnam. Kad Cronet klients saÅem HTTP atbildi ar Å”o galveni, tas izmanto QUIC turpmÄkajiem HTTP pieprasÄ«jumiem Å”im domÄnam. Kad balansÄtÄjs pabeidz QUIC, mÅ«su infrastruktÅ«ra skaidri nosÅ«ta Å”o darbÄ«bu mÅ«su datu centriem, izmantojot HTTP2/TCP.
VeiktspÄja: RezultÄti
Izvades veiktspÄja ir galvenais iemesls, kÄpÄc mÄs meklÄjam labÄku protokolu. SÄkumÄ mÄs izveidojÄm stendu ar lai uzzinÄtu, kÄ QUIC darbosies dažÄdos tÄ«kla profilos. Lai pÄrbaudÄ«tu QUIC veiktspÄju reÄlos tÄ«klos, mÄs veicÄm eksperimentus, braucot pa Å Å«deli, izmantojot emulÄtu tÄ«kla trafiku, kas ir ļoti lÄ«dzÄ«gs HTTP zvaniem pasažieru lietotnÄ.
1. eksperiments
Eksperimenta aprīkojums:
- pÄrbaudÄ«t Android ierÄ«ces ar OkHttp un Cronet skursteÅiem, lai nodroÅ”inÄtu, ka mÄs atļaujam HTTPS trafiku, izmantojot attiecÄ«gi TCP un QUIC;
- uz Java balstÄ«tu emulÄcijas serveri, kas atbildÄs nosÅ«ta tÄda paÅ”a veida HTTPS galvenes un ielÄdÄ klienta ierÄ«ces, lai saÅemtu no tÄm pieprasÄ«jumus;
- mÄkoÅa starpniekserveri, kas fiziski atrodas tuvu Indijai, lai pÄrtrauktu TCP un QUIC savienojumus. Lai gan TCP pÄrtraukÅ”anai mÄs izmantojÄm reverso starpniekserveri , bija grÅ«ti atrast QUIC atvÄrtÄ koda reverso starpniekserveri. MÄs paÅ”i izveidojÄm QUIC apgriezto starpniekserveri, izmantojot pamata QUIC steku no Chromium un to hromÄ kÄ atvÄrtÄ koda.
6. attÄls. TCP vs QUIC ceļa testu komplekts sastÄvÄja no Android ierÄ«cÄm ar OkHttp un Cronet, mÄkoÅa starpniekserveriem savienojumu pÄrtraukÅ”anai un emulÄcijas servera.
2. eksperiments
Kad Google padarÄ«ja QUIC pieejamu ar , mÄs izmantojÄm tos paÅ”us krÄjumus, taÄu ar vienu modifikÄciju: NGINX vietÄ izmantojÄm Google slodzes balansÄtÄjus, lai pÄrtrauktu TCP un QUIC savienojumus no ierÄ«cÄm, kÄ arÄ« lai marÅ”rutÄtu HTTPS trafiku uz emulÄcijas serveri. Balansieri ir izplatÄ«ti visÄ pasaulÄ, bet izmanto ierÄ«cei vistuvÄk esoÅ”o PoP serveri (pateicoties Ä£eogrÄfiskajai atraÅ”anÄs vietai).
7. attÄls. OtrajÄ eksperimentÄ mÄs vÄlÄjÄmies salÄ«dzinÄt TCP un QUIC pabeigÅ”anas latentumu: izmantojot Google Cloud un mÅ«su mÄkoÅa starpniekserveri.
RezultÄtÄ mÅ«s gaidÄ«ja vairÄkas atklÄsmes:
- pÄrtraukÅ”ana, izmantojot PoP, uzlaboja TCP veiktspÄju. TÄ kÄ balansÄtÄji pÄrtrauc TCP savienojumus tuvÄk lietotÄjiem un ir ļoti optimizÄti, tas rada zemÄkus RTT, kas uzlabo TCP veiktspÄju. Un, lai gan QUIC tika ietekmÄts mazÄk, tas joprojÄm pÄrspÄja TCP, samazinot astes latentumu (par 10ā30 procentiem).
- tiek ietekmÄtas astes . Lai gan mÅ«su QUIC starpniekserveris atradÄs tÄlÄk no ierÄ«cÄm (par aptuveni 50 ms lielÄks latentums) nekÄ Google slodzes balansÄtÄji, tas nodroÅ”inÄja lÄ«dzÄ«gu veiktspÄju ā latentuma samazinÄjums par 15%, salÄ«dzinot ar 20% samazinÄjumu TCP 99. procentilei. Tas liek domÄt, ka pÄdÄjÄ jÅ«dzes pÄreja ir tÄ«kla saÅ”aurinÄjums.
8. attÄls. Divu eksperimentu rezultÄti liecina, ka QUIC ievÄrojami pÄrspÄj TCP.
Apkarot satiksmi
Iedvesmojoties no eksperimentiem, esam ieviesuÅ”i QUIC atbalstu savÄs Android un iOS lietojumprogrammÄs. MÄs veicÄm A/B testÄÅ”anu, lai noteiktu QUIC ietekmi pilsÄtÄs, kurÄs darbojas Uber. KopumÄ mÄs novÄrojÄm ievÄrojamu kavÄÅ”anÄs gadÄ«jumu samazinÄÅ”anos abos reÄ£ionos, telekomunikÄciju operatoros un tÄ«kla veidos.
TÄlÄk redzamajÄs diagrammÄs ir parÄdÄ«ti procentuÄlie uzlabojumi astÄs (95 un 99 procentiles) pa makroreÄ£ioniem un dažÄdiem tÄ«kla veidiem ā LTE, 3G, 2G.
9. attÄls. Kaujas testos QUIC pÄrspÄja TCP latentuma ziÅÄ.
Tikai uz priekŔu
VarbÅ«t tas ir tikai sÄkums - QUIC izlaiÅ”ana ražoÅ”anÄ ir nodroÅ”inÄjusi pÄrsteidzoÅ”as iespÄjas uzlabot lietojumprogrammu veiktspÄju gan stabilos, gan nestabilos tÄ«klos, proti:
PalielinÄts pÄrklÄjums
AnalizÄjot protokola veiktspÄju reÄlajÄ datplÅ«smÄ, mÄs redzÄjÄm, ka aptuveni 80% sesiju veiksmÄ«gi izmantoja QUIC viss pieprasÄ«jumus, savukÄrt 15% sesiju izmantoja QUIC un TCP kombinÄciju. MÄs pieÅemam, ka kombinÄcija ir saistÄ«ta ar Cronet bibliotÄkas taimautu atpakaļ uz TCP, jo tÄ nevar atŔķirt reÄlas UDP kļūmes no sliktiem tÄ«kla apstÄkļiem. PaÅ”laik mÄs meklÄjam Ŕīs problÄmas risinÄjumu, strÄdÄjot pie turpmÄkas QUIC ievieÅ”anas.
QUIC optimizÄcija
DatplÅ«sma no mobilajÄm lietotnÄm ir jutÄ«ga pret latentumu, bet nav jutÄ«ga pret joslas platumu. TurklÄt mÅ«su lietojumprogrammas galvenokÄrt tiek izmantotas mobilajos tÄ«klos. Pamatojoties uz eksperimentiem, gala latentums joprojÄm ir augsts, lai gan tiek izmantots starpniekserveris, lai pÄrtrauktu TCP un QUIC lietotÄju tuvumÄ. MÄs aktÄ«vi meklÄjam veidus, kÄ uzlabot sastrÄgumu pÄrvaldÄ«bu un uzlabot QUIC zaudÄjumu atgÅ«Å”anas algoritmu efektivitÄti.
Ar Å”iem un vairÄkiem citiem uzlabojumiem mÄs plÄnojam uzlabot lietotÄju pieredzi neatkarÄ«gi no tÄ«kla un reÄ£iona, padarot Ärtu un netraucÄtu pakeÅ”u transportÄÅ”anu pieejamÄku visÄ pasaulÄ.
Avots: www.habr.com