Ang QUIC protocol ay lubhang kawili-wiling panoorin, kaya naman gustung-gusto naming magsulat tungkol dito. Ngunit kung ang mga nakaraang publikasyon tungkol sa QUIC ay higit pa sa isang makasaysayang (lokal na kasaysayan, kung gusto mo) ng kalikasan at hardware, ngayon kami ay masaya na mag-publish ng isang pagsasalin ng ibang uri - pag-uusapan natin ang tunay na aplikasyon ng protocol sa 2019. Bukod dito, hindi namin pinag-uusapan ang tungkol sa maliit na imprastraktura na nakabase sa isang tinatawag na garahe, ngunit tungkol sa Uber, na nagpapatakbo halos sa buong mundo. Paano napagdesisyunan ng mga inhinyero ng kumpanya na gamitin ang QUIC sa produksyon, kung paano nila isinagawa ang mga pagsubok at kung ano ang nakita nila matapos itong ilunsad sa produksyon - sa ilalim ng hiwa.
Ang mga larawan ay naki-click. Enjoy reading!
Ang Uber ay may pandaigdigang saklaw, lalo na ang 600 lungsod ng presensya, sa bawat isa kung saan ang application ay ganap na umaasa sa wireless Internet mula sa higit sa 4500 cellular operator. Inaasahan ng mga user na ang app ay hindi lamang mabilis, ngunit sa real time - upang makamit ito, ang Uber app ay nangangailangan ng mababang latency at isang napaka-maaasahang koneksyon. Sayang, pero ang salansan ay hindi maganda sa dynamic at loss-prone na mga wireless network. Napagtanto namin na sa kasong ito, ang mahinang pagganap ay direktang nauugnay sa mga pagpapatupad ng TCP sa mga kernel ng operating system.
Upang malutas ang problema, nag-apply kami , isang modernong channel multiplexing protocol na nagbibigay sa amin ng higit na kontrol sa pagganap ng transport protocol. Kasalukuyang nagtatrabaho grupo nilagyan ng pamantayan ang QUIC bilang .
Pagkatapos ng malawak na pagsubok, napagpasyahan namin na ang pagpapatupad ng QUIC sa aming aplikasyon ay magreresulta sa mas mababang tail latency kumpara sa TCP. Naobserbahan namin ang mga pagbawas sa hanay na 10-30% para sa trapiko ng HTTPS sa mga application ng driver at pasahero. Binigyan din kami ng QUIC ng end-to-end na kontrol sa mga package ng user.
Sa artikulong ito, ibinabahagi namin ang aming karanasan sa pag-optimize ng TCP para sa mga Uber application gamit ang isang stack na sumusuporta sa QUIC.
Ang pinakabagong teknolohiya: TCP
Ngayon, ang TCP ay ang pinaka ginagamit na transport protocol para sa paghahatid ng trapiko ng HTTPS sa Internet. Nagbibigay ang TCP ng maaasahang stream ng mga byte, sa gayon ay nakakayanan ang pagsisikip ng network at pagkawala ng mga layer ng link. Ang malawakang paggamit ng TCP para sa trapiko ng HTTPS ay dahil sa ubiquity ng dating (halos lahat ng OS ay naglalaman ng TCP), availability sa karamihan ng imprastraktura (tulad ng mga load balancer, HTTPS proxies at CDN), at out-of-the-box na functionality na available. sa halos karamihan sa mga platform at network.
Karamihan sa mga user ay gumagamit ng aming app on the go, at ang TCP tail latency ay hindi malapit sa mga hinihingi ng aming real-time na trapiko sa HTTPS. Sa madaling salita, naranasan ito ng mga user sa buong mundo - Ipinapakita ng Figure 1 ang mga pagkaantala sa mga pangunahing lungsod:
Figure 1: Nag-iiba-iba ang tail latency sa mga pangunahing lungsod ng Uber.
Bagama't mas mataas ang latency sa mga Indian at Brazilian network kaysa sa US at UK, mas mataas ang tail latency kaysa sa average na latency. At totoo ito kahit para sa US at UK.
TCP over the air performance
Ang TCP ay nilikha para sa naka-wire network, ibig sabihin, na may diin sa mga link na lubos na mahuhulaan. gayunpaman, wireless Ang mga network ay may sariling katangian at kahirapan. Una, ang mga wireless network ay madaling kapitan ng pagkalugi dahil sa interference at signal attenuation. Halimbawa, ang mga Wi-Fi network ay sensitibo sa mga microwave, bluetooth at iba pang radio wave. Ang mga cellular network ay dumaranas ng pagkawala ng signal () dahil sa pagmuni-muni/pagsipsip ng signal ng mga bagay at gusali, gayundin mula sa mula sa kapitbahay . Ito ay humahantong sa mas makabuluhan (4-10 beses) at mas magkakaibang at pagkawala ng packet kumpara sa isang wired na koneksyon.
Upang labanan ang pagbabagu-bago at pagkawala ng bandwidth, ang mga cellular network ay karaniwang gumagamit ng malalaking buffer para sa mga pagsabog ng trapiko. Maaari itong humantong sa labis na pagpila, na nangangahulugan ng mas mahabang pagkaantala. Kadalasan ay tinatrato ng TCP ang pagpila na ito bilang isang basura dahil sa isang pinahabang timeout, kaya malamang na mag-relay ang TCP at sa gayon ay punan ang buffer. Ang problemang ito ay kilala bilang (), at ito ay napaka modernong Internet.
Panghuli, nag-iiba-iba ang pagganap ng cellular network ayon sa carrier, rehiyon, at oras. Sa Figure 2, kinolekta namin ang median na pagkaantala ng trapiko ng HTTPS sa mga cell sa loob ng 2 kilometrong hanay. Nakolektang data para sa dalawang pangunahing cellular operator sa Delhi, India. Gaya ng nakikita mo, nag-iiba ang pagganap sa bawat cell. Gayundin, ang pagiging produktibo ng isang operator ay naiiba sa pagiging produktibo ng pangalawa. Ito ay naiimpluwensyahan ng mga salik tulad ng mga pattern ng pagpasok ng network na isinasaalang-alang ang oras at lokasyon, kadaliang mapakilos ng gumagamit, pati na rin ang imprastraktura ng network na isinasaalang-alang ang density ng tower at ang ratio ng mga uri ng network (LTE, 3G, atbp.).
Figure 2. Mga pagkaantala gamit ang isang 2 km radius bilang isang halimbawa. Delhi, India.
Gayundin, ang pagganap ng mga cellular network ay nag-iiba sa paglipas ng panahon. Ipinapakita ng Figure 3 ang median latency ayon sa araw ng linggo. Naobserbahan din namin ang mga pagkakaiba sa mas maliit na sukat, sa loob ng isang araw at oras.
Figure 3. Ang mga pagkaantala sa buntot ay maaaring mag-iba nang malaki sa pagitan ng mga araw, ngunit para sa parehong operator.
Ang lahat ng nasa itaas ay nagiging sanhi ng pagiging hindi epektibo ng pagganap ng TCP sa mga wireless network. Gayunpaman, bago maghanap ng mga alternatibo sa TCP, nais naming bumuo ng isang tumpak na pag-unawa sa mga sumusunod na punto:
- TCP ba ang pangunahing salarin sa likod ng tail latencies sa aming mga application?
- Ang mga modernong network ba ay may makabuluhan at iba't ibang round-trip delay (RTT)?
- Ano ang epekto ng RTT at pagkawala sa pagganap ng TCP?
Pagsusuri sa Pagganap ng TCP
Upang maunawaan kung paano namin sinuri ang pagganap ng TCP, tingnan natin kung paano inililipat ng TCP ang data mula sa isang nagpadala patungo sa isang tatanggap. Una, ang nagpadala ay nagtatatag ng isang koneksyon sa TCP, na gumaganap ng isang three-way : Nagpapadala ang nagpadala ng SYN packet, naghihintay ng SYN-ACK packet mula sa receiver, pagkatapos ay nagpapadala ng ACK packet. Ang karagdagang pangalawa at pangatlong pass ay ginugol sa paggawa ng koneksyon sa TCP. Kinikilala ng tatanggap ang resibo ng bawat packet (ACK) upang matiyak ang maaasahang paghahatid.
Kung nawala ang isang packet o ACK, muling magpapadala ang nagpadala pagkatapos ng timeout (RTO, ). Ang RTO ay dynamic na kinakalkula batay sa iba't ibang salik, tulad ng inaasahang pagkaantala ng RTT sa pagitan ng nagpadala at tatanggap.
Figure 4. Ang palitan ng packet sa TCP/TLS ay may kasamang mekanismo ng muling pagpapadala.
Upang matukoy kung paano gumanap ang TCP sa aming mga application, sinusubaybayan namin ang paggamit ng mga TCP packet para sa isang linggo sa trapiko ng labanan na nagmumula sa mga server ng gilid ng India. Pagkatapos ay sinuri namin ang mga koneksyon sa TCP gamit . Bukod pa rito, gumawa kami ng Android application na nagpapadala ng emulated na trapiko sa isang test server, na ginagaya ang totoong trapiko hangga't maaari. Ang mga smartphone na may ganitong application ay ipinamahagi sa ilang empleyado, na nangolekta ng mga log sa loob ng ilang araw.
Ang mga resulta ng parehong mga eksperimento ay pare-pareho sa bawat isa. Nakita namin ang mataas na latency ng RTT; ang mga halaga ng buntot ay halos 6 na beses na mas mataas kaysa sa median na halaga; ang arithmetic average ng mga pagkaantala ay higit sa 1 segundo. Maraming koneksyon ang nawalan, na nagdulot ng TCP na muling magpadala ng 3,5% ng lahat ng mga packet. Sa mga masikip na lugar tulad ng mga paliparan at istasyon ng tren, nakita namin ang 7% na pagkalugi. Ang mga resultang ito ay nagdududa sa kumbensyonal na karunungan na ginagamit sa mga cellular network makabuluhang bawasan ang mga pagkalugi sa antas ng transportasyon. Nasa ibaba ang mga resulta ng pagsubok mula sa application na "simulator":
Mga sukatan ng network
Mga kahulugan
RTT, millisecond [50%,75%, 95%,99%]
[350, 425, 725, 2300]
RTT divergence, segundo
Sa karaniwan ~1,2 s
Packet loss sa hindi matatag na koneksyon
Average ~3.5% (7% sa mga overloaded na lugar)
Halos kalahati ng mga koneksyon na ito ay nagkaroon ng hindi bababa sa isang packet loss, karamihan sa kanila ay SYN at SYN-ACK packet. Karamihan sa mga pagpapatupad ng TCP ay gumagamit ng halaga ng RTO na 1 segundo para sa mga SYN packet, na tumataas nang husto para sa mga kasunod na pagkalugi. Maaaring tumaas ang mga oras ng paglo-load ng application dahil sa pagtagal ng TCP upang makapagtatag ng mga koneksyon.
Sa kaso ng mga packet ng data, ang mataas na mga halaga ng RTO ay lubos na binabawasan ang kapaki-pakinabang na paggamit ng network sa pagkakaroon ng mga lumilipas na pagkalugi sa mga wireless network. Nalaman namin na ang average na retransmission time ay humigit-kumulang 1 segundo na may tail delay na halos 30 segundo. Ang mga matataas na latency na ito sa antas ng TCP ay nagdulot ng mga pag-timeout at muling kahilingan ng HTTPS, na lalong nagpapataas ng latency at kawalan ng kahusayan ng network.
Habang ang 75th percentile ng sinusukat na RTT ay humigit-kumulang 425 ms, ang 75th percentile para sa TCP ay halos 3 segundo. Ipinahihiwatig nito na ang pagkawala ay naging sanhi ng TCP na kumuha ng 7-10 pass upang matagumpay na magpadala ng data. Ito ay maaaring resulta ng hindi mahusay na pagkalkula ng RTO, ang kawalan ng kakayahan ng TCP na mabilis na tumugon sa pagkawala sa window at ang inefficiency ng congestion control algorithm, na hindi nakikilala sa pagitan ng wireless na pagkalugi at pagkalugi dahil sa network congestion. Nasa ibaba ang mga resulta ng mga pagsubok sa pagkawala ng TCP:
Mga istatistika ng pagkawala ng packet ng TCP
Halaga
Porsiyento ng mga koneksyon na may hindi bababa sa 1 packet loss
45%
Porsiyento ng mga koneksyon na may mga pagkalugi sa panahon ng pag-setup ng koneksyon
30%
Porsiyento ng mga koneksyon na may mga pagkalugi sa panahon ng pagpapalitan ng data
76%
Pamamahagi ng mga pagkaantala sa muling pagpapadala, segundo [50%, 75%, 95%,99%] [1, 2.8, 15, 28]
Pamamahagi ng bilang ng mga muling pagpapadala para sa isang packet o TCP segment
[1,3,6,7]
Application ng QUIC
Orihinal na binuo ng Google, ang QUIC ay isang multi-threaded na modernong transport protocol na tumatakbo sa itaas ng UDP. Kasalukuyang nasa QUIC (isinulat na namin na mayroong, kumbaga, dalawang bersyon ng QUIC, kakaiba β tinatayang. tagasalin). Gaya ng ipinapakita sa Figure 5, ang QUIC ay inilalagay sa ilalim ng HTTP/3 (sa katunayan, ang HTTP/2 sa ibabaw ng QUIC ay HTTP/3, na ngayon ay masinsinang ginagawang pamantayan). Bahagyang pinapalitan nito ang mga layer ng HTTPS at TCP sa pamamagitan ng paggamit ng UDP upang bumuo ng mga packet. Sinusuportahan lamang ng QUIC ang secure na paglipat ng data dahil ang TLS ay ganap na binuo sa QUIC.
Figure 5: Ang QUIC ay tumatakbo sa ilalim ng HTTP/3, na pinapalitan ang TLS, na dating tumakbo sa ilalim ng HTTP/2.
Nasa ibaba ang mga dahilan na nakakumbinsi sa amin na gumamit ng QUIC para sa TCP amplification:
- 0-RTT na pagtatatag ng koneksyon. Pinapayagan ng QUIC ang muling paggamit ng mga pahintulot mula sa mga nakaraang koneksyon, na binabawasan ang bilang ng mga pakikipagkamay sa seguridad. Sa hinaharap ay susuportahan ang 0-RTT, ngunit kailangan pa rin ng three-way TCP handshake.
- pagtagumpayan ang pagharang ng HoL. Gumagamit ang HTTP/2 ng isang koneksyon sa TCP bawat kliyente para pahusayin ang performance, ngunit maaari itong humantong sa pag-block ng HoL (head-of-line). Pinapasimple ng QUIC ang multiplexing at naghahatid ng mga kahilingan sa application nang nakapag-iisa.
- pagkontrol ng kasikipan. Ang QUIC ay naninirahan sa layer ng application, na ginagawang mas madaling i-update ang pangunahing algorithm ng transportasyon na kumokontrol sa pagpapadala batay sa mga parameter ng network (bilang ng mga pagkalugi o RTT). Karamihan sa mga pagpapatupad ng TCP ay gumagamit ng algorithm , na hindi pinakamainam para sa latency-sensitive na trapiko. Kamakailang binuo algorithm tulad ng , mas tumpak na imodelo ang network at i-optimize ang latency. Binibigyang-daan ka ng QUIC na gamitin ang BBR at i-update ang algorithm na ito habang ginagamit ito. .
- muling pagdadagdag ng mga pagkalugi. Ang QUIC ay tumatawag sa dalawang TLP () bago ma-trigger ang RTO - kahit na ang mga pagkalugi ay kapansin-pansin. Iba ito sa mga pagpapatupad ng TCP. Pangunahing ipinapadala ng TLP ang huling packet (o ang bago, kung mayroon) upang mag-trigger ng mabilis na muling pagdadagdag. Ang pangangasiwa sa mga pagkaantala ng buntot ay partikular na kapaki-pakinabang para sa paraan ng pagpapatakbo ng Uber sa network nito, lalo na para sa maikli, sporadic, at latency-sensitive na paglilipat ng data.
- na-optimize na ACK. Dahil ang bawat packet ay may natatanging sequence number, walang problema packet kapag sila ay muling ipinadala. Ang mga ACK packet ay naglalaman din ng oras upang iproseso ang packet at bumuo ng isang ACK sa panig ng kliyente. Tinitiyak ng mga feature na ito na mas tumpak na kinakalkula ng QUIC ang RTT. Sinusuportahan ng ACK sa QUIC ang hanggang 256 na banda , na tumutulong sa nagpadala na maging mas matatag sa packet shuffling at gumamit ng mas kaunting byte sa proseso. Selective ACK () sa TCP ay hindi nilulutas ang problemang ito sa lahat ng kaso.
- paglipat ng koneksyon. Ang mga QUIC na koneksyon ay natutukoy sa pamamagitan ng isang 64-bit ID, kaya kung ang isang kliyente ay nagbabago ng mga IP address, ang lumang ID ng koneksyon ay maaaring patuloy na gamitin sa bagong IP address nang walang pagkaantala. Ito ay isang napaka-karaniwang kasanayan para sa mga mobile application kung saan ang user ay nagpapalipat-lipat sa pagitan ng Wi-Fi at mga cellular na koneksyon.
Mga alternatibo sa QUIC
Isinasaalang-alang namin ang mga alternatibong diskarte sa paglutas ng problema bago pumili ng QUIC.
Ang unang bagay na sinubukan namin ay ang pag-deploy ng mga TPC PoP (Points of Presence) upang wakasan ang mga koneksyon sa TCP na mas malapit sa mga user. Sa esensya, tinatapos ng mga PoP ang isang koneksyon sa TCP sa isang mobile device na mas malapit sa cellular network at i-proxy ang trapiko pabalik sa orihinal na imprastraktura. Sa pamamagitan ng pagwawakas ng TCP nang mas malapit, maaari nating bawasan ang RTT at matiyak na mas tumutugon ang TCP sa isang dynamic na wireless na kapaligiran. Gayunpaman, ipinakita ng aming mga eksperimento na ang karamihan sa RTT at pagkawala ay nagmumula sa mga cellular network at ang paggamit ng mga PoP ay hindi nagbibigay ng makabuluhang pagpapabuti sa pagganap.
Tiningnan din namin ang pag-tune ng mga parameter ng TCP. Ang pag-set up ng TCP stack sa aming magkakaibang mga edge server ay mahirap dahil ang TCP ay may magkakaibang pagpapatupad sa iba't ibang bersyon ng OS. Mahirap ipatupad ito at subukan ang iba't ibang mga configuration ng network. Ang direktang pag-configure ng TCP sa mga mobile device ay hindi posible dahil sa kakulangan ng mga pahintulot. Higit sa lahat, ang mga tampok tulad ng 0-RTT na koneksyon at pinahusay na hula sa RTT ay kritikal sa arkitektura ng protocol, at samakatuwid ay imposibleng makamit ang mga makabuluhang benepisyo sa pamamagitan ng pag-tune ng TCP lamang.
Sa wakas, sinuri namin ang ilang protocol na nakabatay sa UDP na nag-troubleshoot ng video streamingβgusto naming makita kung makakatulong ang mga protocol na ito sa aming kaso. Sa kasamaang palad, ang mga ito ay lubhang kulang sa maraming mga setting ng seguridad, at nangangailangan din ng karagdagang koneksyon sa TCP para sa metadata at impormasyon ng kontrol.
Ipinakita ng aming pananaliksik na ang QUIC ay marahil ang tanging protocol na makakatulong sa problema ng trapiko sa Internet, habang isinasaalang-alang ang parehong seguridad at pagganap.
Pagsasama ng QUIC sa platform
Upang matagumpay na i-embed ang QUIC at pagbutihin ang performance ng application sa mahihirap na kapaligiran ng koneksyon, pinalitan namin ang lumang stack (HTTP/2 sa TLS/TCP) ng QUIC protocol. Ginamit namin ang library ng network ng , na naglalaman ng orihinal, bersyon ng Google ng protocol - gQUIC. Ang pagpapatupad na ito ay patuloy ding pinapabuti upang sundin ang pinakabagong detalye ng IETF.
Una naming isinama ang Cronet sa aming mga Android app upang magdagdag ng suporta para sa QUIC. Ang pagsasama ay isinagawa sa paraang mabawasan ang mga gastos sa paglilipat hangga't maaari. Sa halip na ganap na palitan ang lumang networking stack na ginamit ang library , isinama namin ang Cronet SA ILALIM ng balangkas ng OkHttp API. Sa pamamagitan ng paggawa ng pagsasama sa ganitong paraan, naiwasan namin ang mga pagbabago sa aming mga tawag sa network (na ginagamit ng ) sa antas ng API.
Katulad ng diskarte para sa mga Android device, ipinatupad namin ang Cronet sa mga Uber app sa iOS, na humahadlang sa trapiko ng HTTP mula sa network gamit . Ang abstraction na ito, na ibinigay ng iOS Foundation, ay humahawak sa data ng URL na tukoy sa protocol at tinitiyak na maaari naming isama ang Cronet sa aming mga iOS application nang walang makabuluhang gastos sa paglipat.
Pagkumpleto ng QUIC sa Google Cloud Balancers
Sa backend side, ang QUIC na pagkumpleto ay ibinibigay ng Google Cloud Load balancing infrastructure, na gumagamit mga header bilang mga tugon upang suportahan ang QUIC. Sa pangkalahatan, nagdaragdag ang balancer ng alt-svc header sa bawat kahilingan sa HTTP, at pinapatunayan na nito ang QUIC na suporta para sa domain. Kapag nakatanggap ang isang Cronet client ng HTTP na tugon kasama ang header na ito, gumagamit ito ng QUIC para sa mga kasunod na kahilingan sa HTTP sa domain na iyon. Kapag nakumpleto na ng balancer ang QUIC, tahasang ipinapadala ng aming imprastraktura ang pagkilos na ito sa HTTP2/TCP sa aming mga data center.
Pagganap: Mga Resulta
Ang pagganap ng output ay ang pangunahing dahilan para sa aming paghahanap para sa isang mas mahusay na protocol. Upang magsimula sa, lumikha kami ng isang paninindigan sa upang malaman kung paano kikilos ang QUIC sa ilalim ng iba't ibang profile ng network. Upang subukan ang pagganap ng QUIC sa mga totoong network, nagpatakbo kami ng mga eksperimento habang nagmamaneho sa paligid ng New Delhi gamit ang emulated na trapiko sa network na halos kapareho sa mga HTTP na tawag sa pampasaherong app.
Eksperimento 1
Kagamitan para sa eksperimento:
- subukan ang mga Android device na may OkHttp at Cronet stack upang matiyak na pinapayagan namin ang trapiko ng HTTPS sa TCP at QUIC ayon sa pagkakabanggit;
- isang server ng emulation na nakabatay sa Java na nagpapadala ng parehong uri ng mga header ng HTTPS sa mga tugon at naglo-load ng mga device ng kliyente upang makatanggap ng mga kahilingan mula sa kanila;
- cloud proxy na pisikal na matatagpuan malapit sa India upang wakasan ang TCP at QUIC na mga koneksyon. Habang para sa pagwawakas ng TCP ay gumamit kami ng reverse proxy sa , mahirap maghanap ng open source reverse proxy para sa QUIC. Bumuo kami ng reverse proxy para sa QUIC gamit ang pangunahing QUIC stack mula sa Chromium at ito sa chromium bilang open source.
Figure 6. Ang TCP vs QUIC road test suite ay binubuo ng mga Android device na may OkHttp at Cronet, cloud proxy para sa pagwawakas ng mga koneksyon, at isang emulation server.
Eksperimento 2
Noong ginawang available ng Google ang QUIC sa , ginamit namin ang parehong imbentaryo, ngunit may isang pagbabago: sa halip na NGINX, kinuha namin ang mga load balancer ng Google upang wakasan ang mga TCP at QUIC na koneksyon mula sa mga device, gayundin ang pagruta ng trapiko ng HTTPS sa emulation server. Ang mga balanse ay ipinamamahagi sa buong mundo, ngunit gamitin ang PoP server na pinakamalapit sa device (salamat sa geolocation).
Figure 7. Sa pangalawang eksperimento, gusto naming ikumpara ang latency ng pagkumpleto ng TCP at QUIC: gamit ang Google Cloud at gamit ang aming cloud proxy.
Bilang resulta, maraming paghahayag ang naghihintay sa amin:
- pagwawakas sa pamamagitan ng PoP pinahusay na pagganap ng TCP. Dahil ang mga balancer ay nagwawakas ng mga koneksyon sa TCP nang mas malapit sa mga user at lubos na na-optimize, nagreresulta ito sa mas mababang mga RTT, na nagpapahusay sa pagganap ng TCP. At kahit na hindi gaanong naapektuhan ang QUIC, nalampasan pa rin nito ang TCP sa mga tuntunin ng pagbabawas ng tail latency (ng 10-30 porsyento).
- ang mga buntot ay apektado . Bagama't ang aming QUIC proxy ay mas malayo sa mga device (mga 50 ms na mas mataas na latency) kaysa sa mga load balancer ng Google, naghatid ito ng katulad na performance - isang 15% na pagbawas sa latency kumpara sa isang 20% ββna pagbawas sa 99th percentile para sa TCP. Iminumungkahi nito na ang huling paglipat ng milya ay isang bottleneck sa network.
Figure 8: Ang mga resulta mula sa dalawang eksperimento ay nagpapakita na ang QUIC ay higit na lumalampas sa TCP.
Labanan ang trapiko
Dahil sa inspirasyon ng eksperimento, nagpatupad kami ng QUIC na suporta sa aming mga Android at iOS application. Nagsagawa kami ng A/B testing para matukoy ang epekto ng QUIC sa mga lungsod kung saan nagpapatakbo ang Uber. Sa pangkalahatan, nakita namin ang isang makabuluhang pagbawas sa mga pagkaantala ng buntot sa parehong mga rehiyon, mga operator ng telecom at uri ng network.
Ipinapakita ng mga graph sa ibaba ang porsyento ng mga pagpapabuti sa mga buntot (95 at 99 na porsyento) ayon sa macro-rehiyon at iba't ibang uri ng network - LTE, 3G, 2G.
Figure 9. Sa mga pagsubok sa labanan, nalampasan ng QUIC ang TCP sa mga tuntunin ng latency.
Ipasa lang
Marahil ito ay simula pa lamang - ang paglabas ng QUIC sa produksyon ay nagbigay ng mga kamangha-manghang pagkakataon upang mapabuti ang pagganap ng aplikasyon sa parehong matatag at hindi matatag na mga network, lalo na:
Tumaas na saklaw
Nang masuri ang pagganap ng protocol sa totoong trapiko, nakita namin na humigit-kumulang 80% ng mga session ang matagumpay na gumamit ng QUIC para sa lahat mga kahilingan, habang 15% ng mga session ang gumamit ng kumbinasyon ng QUIC at TCP. Ipinapalagay namin na ang kumbinasyon ay dahil sa pag-timeout ng Cronet library pabalik sa TCP, dahil hindi nito matukoy ang pagkakaiba sa pagitan ng mga tunay na pagkabigo ng UDP at hindi magandang kundisyon ng network. Kasalukuyan kaming naghahanap ng solusyon sa problemang ito habang nagtatrabaho kami patungo sa kasunod na pagpapatupad ng QUIC.
QUIC optimization
Ang trapiko mula sa mga mobile app ay sensitibo sa latency, ngunit hindi sensitibo sa bandwidth. Gayundin, ang aming mga application ay pangunahing ginagamit sa mga cellular network. Batay sa mga eksperimento, mataas pa rin ang tail latency kahit na gumagamit ng proxy para wakasan ang TCP at QUIC malapit sa mga user. Kami ay aktibong naghahanap ng mga paraan upang mapabuti ang pamamahala ng kasikipan at pagbutihin ang kahusayan ng mga QUIC loss recovery algorithm.
Sa mga ito at ilang iba pang mga pagpapahusay, plano naming pahusayin ang karanasan ng user anuman ang network at rehiyon, na ginagawang mas madaling ma-access ang maginhawa at tuluy-tuloy na packet transport sa buong mundo.
Pinagmulan: www.habr.com