Ang QUIC protocol hilabihan ka makapaikag nga tan-awon, mao nga ganahan kami sa pagsulat bahin niini. Apan kung ang nangaging mga publikasyon bahin sa QUIC labi pa sa usa ka makasaysayanon (lokal nga kasaysayan, kung gusto nimo) kinaiyahan ug hardware, karon nalipay kami nga imantala ang usa ka lahi nga paghubad - maghisgot kami bahin sa tinuud nga aplikasyon sa protocol sa 2019. Dugang pa, wala kami maghisgot bahin sa gamay nga imprastraktura nga nakabase sa usa ka gitawag nga garahe, apan bahin sa Uber, nga naglihok hapit sa tibuuk kalibutan. Giunsa ang desisyon sa mga inhenyero sa kompanya nga gamiton ang QUIC sa produksiyon, kung giunsa nila gihimo ang mga pagsulay ug kung unsa ang ilang nakita pagkahuman sa paglansad niini sa produksiyon - ubos sa pagputol.
Ang mga hulagway ma-click. Malingaw sa pagbasa!
Ang Uber adunay usa ka global nga sukod, nga mao ang 600 ka mga lungsod sa presensya, sa matag usa diin ang aplikasyon hingpit nga nagsalig sa wireless Internet gikan sa labaw sa 4500 nga mga cellular operator. Gilauman sa mga tiggamit nga ang app dili lang paspas, apan sa tinuud nga oras - aron makab-ot kini, ang Uber app nanginahanglan gamay nga latency ug kasaligan kaayo nga koneksyon. Alaut, apan ang stack dili maayo sa dinamiko ug dali nga mawala nga mga wireless network. Among naamgohan nga sa niini nga kaso, ang ubos nga performance direktang nalangkit sa mga pagpatuman sa TCP sa mga kernel sa operating system.
Aron masulbad ang problema, mi-apply kami , usa ka modernong channel multiplexing protocol nga naghatag kanato og dugang nga kontrol sa performance sa transport protocol. Sa pagkakaron ang working group nag-standardize sa QUIC isip .
Pagkahuman sa daghang pagsulay, nakahinapos kami nga ang pagpatuman sa QUIC sa among aplikasyon magresulta sa mas ubos nga mga latency sa ikog kumpara sa TCP. Naobserbahan namon ang pagkunhod sa sakup nga 10-30% alang sa trapiko sa HTTPS sa mga aplikasyon sa drayber ug pasahero. Gihatagan usab kami sa QUIC nga end-to-end nga kontrol sa mga pakete sa tiggamit.
Niini nga artikulo, gipaambit namo ang among kasinatian sa pag-optimize sa TCP para sa mga aplikasyon sa Uber gamit ang stack nga nagsuporta sa QUIC.
Ang pinakabag-o nga teknolohiya: TCP
Karon, ang TCP mao ang labing gigamit nga transport protocol alang sa paghatud sa trapiko sa HTTPS sa Internet. Naghatag ang TCP og kasaligang sapa sa mga byte, sa ingon makasagubang sa paghuot sa network ug pagkawala sa layer sa link. Ang kaylap nga paggamit sa TCP para sa trapiko sa HTTPS tungod sa nauna nga ubiquity (halos matag OS adunay TCP), pagkaanaa sa kadaghanan nga imprastraktura (sama sa mga balanse sa load, HTTPS proxy ug CDN), ug out-of-the-box nga gamit nga magamit. sa halos kadaghanan sa mga plataporma ug mga network.
Kadaghanan sa mga tiggamit naggamit sa among app samtang naglakaw, ug ang TCP tail latencies dili duol sa gipangayo sa among real-time nga trapiko sa HTTPS. Sa yanong pagkasulti, ang mga tiggamit sa tibuok kalibutan nakasinati niini - Ang Figure 1 nagpakita sa mga paglangan sa dagkong mga siyudad:
Hulagway 1: Ang latency sa ikog nagkalainlain sa mga nag-unang siyudad sa Uber.
Bisan kung ang latency sa mga network sa India ug Brazil mas taas kaysa sa US ug UK, ang latency sa ikog labi ka taas kaysa kasagaran nga latency. Ug kini tinuod bisan alang sa US ug UK.
TCP sa ibabaw sa performance sa hangin
Ang TCP gihimo para sa wired networks, nga mao, uban sa usa ka empasis sa kaayo predictable links. Apan, wireless Ang mga network adunay kaugalingon nga mga kinaiya ug kalisud. Una, ang mga wireless network dali nga mapildi tungod sa interference ug signal attenuation. Pananglitan, ang mga Wi-Fi network sensitibo sa mga microwave, bluetooth ug uban pang mga radio wave. Ang mga cellular network nag-antus sa pagkawala sa signal () tungod sa pagpamalandong / pagsuyup sa signal sa mga butang ug mga bilding, ingon man gikan sa gikan sa silingan . Kini modala ngadto sa mas mahinungdanon (4-10 ka beses) ug mas lainlain ug pagkawala sa packet itandi sa usa ka wired nga koneksyon.
Aron mabatukan ang pag-usab-usab sa bandwidth ug pagkawala, ang mga cellular network kasagarang mogamit ug dagkong mga buffer para sa mga pagbuto sa trapiko. Kini mahimong mosangpot sa sobra nga pagpila, nga nagpasabut nga mas taas nga mga paglangan. Kanunay nga gitratar sa TCP kini nga pagpila ingon usa ka basura tungod sa usa ka taas nga timeout, mao nga ang TCP lagmit nga mag-relay ug sa ingon mapuno ang buffer. Kini nga problema nailhan nga (), ug kini kaayo modernong internet.
Sa katapusan, ang pasundayag sa cellular network magkalainlain sa carrier, rehiyon, ug oras. Sa Figure 2, among gikolekta ang median nga mga paglangan sa trapiko sa HTTPS sa mga cell sulod sa 2 ka kilometro nga gilay-on. Ang datos nga nakolekta para sa duha ka dagkong cellular operators sa Delhi, India. Sama sa imong makita, ang pasundayag managlahi gikan sa cell ngadto sa cell. Usab, ang pagka-produktibo sa usa ka operator lahi sa pagka-produktibo sa ikaduha. Naimpluwensyahan kini sa mga hinungdan sama sa mga pattern sa pagsulod sa network nga gikonsiderar ang oras ug lokasyon, paglihok sa tiggamit, ingon man ang imprastraktura sa network nga gikonsiderar ang density sa tower ug ang ratio sa mga tipo sa network (LTE, 3G, ug uban pa).
Figure 2. Mga paglangan gamit ang 2 km radius isip pananglitan. Delhi, India.
Usab, ang pasundayag sa mga cellular network magkalainlain sa paglabay sa panahon. Ang Figure 3 nagpakita sa median latency sa adlaw sa semana. Naobserbahan usab namo ang mga kalainan sa mas gamay nga sukod, sulod sa usa ka adlaw ug oras.
Figure 3. Ang mga paglangan sa ikog mahimong magkalainlain kaayo tali sa mga adlaw, apan alang sa parehas nga operator.
Ang tanan sa ibabaw hinungdan nga ang TCP performance dili epektibo sa mga wireless network. Bisan pa, sa wala pa mangita alang sa mga alternatibo sa TCP, gusto namon nga maghimo usa ka tukma nga pagsabut sa mga musunud nga punto:
- Ang TCP ba ang panguna nga hinungdan sa luyo sa mga latency sa ikog sa among mga aplikasyon?
- Ang mga modernong network ba adunay mahinungdanon ug lain-laing mga round-trip delays (RTT)?
- Unsa ang epekto sa RTT ug pagkawala sa performance sa TCP?
Pagtuki sa Pagganap sa TCP
Aron masabtan kung giunsa namo pag-analisar ang performance sa TCP, atong tan-awon dayon kung giunsa pagbalhin sa TCP ang data gikan sa nagpadala ngadto sa tigdawat. Una, ang nagpadala nagtukod og koneksyon sa TCP, nga naghimo sa tulo ka paagi : Ang nagpadala nagpadala ug SYN packet, naghulat sa SYN-ACK packet gikan sa receiver, unya nagpadala ug ACK packet. Usa ka dugang nga ikaduha ug ikatulo nga pass ang gigasto sa pagtukod sa koneksyon sa TCP. Giila sa nakadawat ang resibo sa matag pakete (ACK) aron masiguro ang kasaligan nga pagpadala.
Kung nawala ang usa ka pakete o ACK, ang nagpadala mag-usab pagkahuman sa usa ka oras (RTO, ). Ang RTO dinamikong kalkulado base sa lain-laing mga hinungdan, sama sa gipaabot nga paglangan sa RTT tali sa nagpadala ug nakadawat.
Figure 4. Packet exchange sa TCP/TLS naglakip sa retransmission nga mekanismo.
Aron mahibal-an kung giunsa ang paglihok sa TCP sa among mga aplikasyon, among gimonitor ang paggamit sa mga pakete sa TCP sulod sa usa ka semana sa combat traffic nga gikan sa Indian edge servers. Gisusi dayon namo ang mga koneksyon sa TCP gamit . Dugang pa, naghimo kami usa ka aplikasyon sa Android nga nagpadala sa gisundog nga trapiko sa usa ka server sa pagsulay, nga nagsundog sa tinuud nga trapiko kutob sa mahimo. Ang mga smartphone nga adunay kini nga aplikasyon giapod-apod sa daghang mga empleyado, nga nangolekta mga troso sa daghang mga adlaw.
Ang mga resulta sa duha ka mga eksperimento nahiuyon sa usag usa. Nakita namon ang taas nga mga latency sa RTT; ang mga kantidad sa ikog hapit 6 ka beses nga mas taas kaysa sa median nga kantidad; ang aritmetika nga aberids sa mga paglangan labaw pa sa 1 segundos. Daghang mga koneksyon ang nawala, hinungdan nga ang TCP nagpadala pag-usab sa 3,5% sa tanan nga mga pakete. Sa mga lugar nga naghuot sama sa mga tugpahanan ug mga estasyon sa tren, nakita namon ang 7% nga pagkawala. Kini nga mga resulta nagduhaduha sa naandan nga kaalam nga gigamit sa mga cellular network kamahinungdanon pagpakunhod sa pagkawala sa lebel sa transportasyon. Sa ubos mao ang mga resulta sa pagsulay gikan sa "simulator" nga aplikasyon:
Mga sukatan sa network
Mga kantidad
RTT, millisecond [50%,75%, 95%,99%]
[350, 425, 725, 2300]
RTT divergence, segundos
Sa kasagaran ~1,2 s
Ang pagkawala sa pakete sa dili lig-on nga mga koneksyon
Average ~3.5% (7% sa mga lugar nga sobra ang karga)
Hapit katunga niini nga mga koneksyon adunay labing menos usa ka packet loss, kadaghanan kanila SYN ug SYN-ACK packets. Kadaghanan sa mga pagpatuman sa TCP naggamit sa usa ka RTO nga kantidad nga 1 segundo alang sa mga pakete sa SYN, nga labi nga nagdugang alang sa sunod nga mga pagkawala. Ang mga oras sa pagkarga sa aplikasyon mahimong motaas tungod sa pagdugay sa TCP sa paghimo og mga koneksyon.
Sa kaso sa mga packet sa datos, ang taas nga mga kantidad sa RTO labi nga nakunhuran ang mapuslanon nga paggamit sa network kung adunay mga lumalabay nga pagkawala sa mga wireless network. Nahibal-an namon nga ang kasagaran nga oras sa pag-retransmission gibana-bana nga 1 segundo nga adunay paglangan sa ikog nga hapit 30 segundos. Kining taas nga mga latency sa lebel sa TCP maoy hinungdan sa HTTPS timeouts ug re-requests, dugang nga pagdugang sa network latency ug inefficiency.
Samtang ang ika-75 nga porsyento sa gisukod nga RTT mga 425 ms, ang ika-75 nga porsyento alang sa TCP hapit 3 segundos. Kini nagpakita nga ang pagkawala hinungdan sa TCP sa pagkuha sa 7-10 pass sa malampuson nga pagpadala data. Mahimong usa kini ka sangputanan sa dili maayo nga pagkalkula sa RTO, ang kawalay katakus sa TCP sa dali nga pagtubag sa pagkawala sa bintana ug ang inefficiency sa congestion control algorithm, nga wala makaila tali sa wireless pagkawala ug pagkawala tungod sa network congestion. Sa ubos mao ang mga resulta sa mga pagsulay sa pagkawala sa TCP:
Mga istatistika sa pagkawala sa packet sa TCP
bili
Porsiyento sa mga koneksyon nga adunay labing menos 1 nga pagkawala sa pakete
45%
Porsiyento sa mga koneksyon nga adunay mga pagkawala sa panahon sa pag-setup sa koneksyon
30%
Porsiyento sa mga koneksyon uban sa mga pagkawala sa panahon sa data exchange
76%
Pag-apod-apod sa mga paglangan sa retransmission, segundo [50%, 75%, 95%,99%] [1, 2.8, 15, 28]
Pag-apod-apod sa gidaghanon sa retransmissions alang sa usa ka pakete o TCP nga bahin
[1,3,6,7]
Aplikasyon sa QUIC
Orihinal nga gimugna sa Google, ang QUIC usa ka multi-threaded nga modernong transport protocol nga nagdagan sa ibabaw sa UDP. Sa pagkakaron anaa ang QUIC (nagsulat na kami nga adunay, ingon nga kini, duha ka bersyon sa QUIC, talagsaon β gibanabana. tighubad). Sama sa gipakita sa Figure 5, ang QUIC gibutang sa ilawom sa HTTP/3 (sa tinuud, ang HTTP/2 sa ibabaw sa QUIC mao ang HTTP/3, nga karon gi-standardize kaayo). Kini partially mopuli sa HTTPS ug TCP layers pinaagi sa paggamit sa UDP sa pagporma packets. Gisuportahan lang sa QUIC ang luwas nga pagbalhin sa datos tungod kay ang TLS hingpit nga natukod sa QUIC.
Figure 5: Ang QUIC midagan ubos sa HTTP/3, gipuli ang TLS, nga kaniadto midagan ubos sa HTTP/2.
Sa ubos mao ang mga rason nga nakapakombinsir kanamo sa paggamit sa QUIC alang sa TCP amplification:
- Pagtukod sa koneksyon sa 0-RTT. Gitugotan sa QUIC ang paggamit pag-usab sa mga pagtugot gikan sa nangaging mga koneksyon, nga nagpamenos sa gidaghanon sa mga paglamano sa seguridad. Sa umaabot mosuporta sa 0-RTT, apan gikinahanglan gihapon ang three-way TCP handshake.
- pagbuntog sa HoL blocking. Gigamit sa HTTP/2 ang usa ka koneksyon sa TCP matag kliyente aron mapauswag ang pasundayag, apan kini mahimong mosangput sa pag-block sa HoL (head-of-line). Gipasimple sa QUIC ang multiplexing ug naghatud sa mga hangyo sa aplikasyon nga independente.
- pagkontrol sa kahuot. Ang QUIC nagpuyo sa layer sa aplikasyon, nga nagpadali sa pag-update sa panguna nga algorithm sa transportasyon nga nagkontrol sa pagpadala base sa mga parameter sa network (gidaghanon sa pagkawala o RTT). Kadaghanan sa mga pagpatuman sa TCP naggamit sa algorithm , nga dili maayo alang sa latency-sensitive nga trapiko. Bag-o lang naugmad nga mga algorithm sama sa , mas tukma nga modelo sa network ug i-optimize ang latency. Ang QUIC nagtugot kanimo sa paggamit sa BBR ug pag-update niini nga algorithm samtang kini gigamit. .
- pagpuno sa mga pagkawala. Ang QUIC nagtawag sa duha ka TLP () sa wala pa ma-trigger ang RTO - bisan kung ang mga pagkawala mamatikdan kaayo. Lahi kini sa mga pagpatuman sa TCP. Ang TLP nag-usab sa kadaghanan sa katapusang pakete (o ang bag-o, kung adunay usa) aron mapukaw ang paspas nga pagpuno. Ang pagdumala sa mga paglangan sa ikog ilabinang mapuslanon alang sa paagi sa Uber sa pagpadagan sa iyang network, nga mao alang sa mubo, sporadic, ug latency-sensitive nga pagbalhin sa datos.
- gi-optimize nga ACK. Tungod kay ang matag pakete adunay usa ka talagsaon nga sequence number, walaβy problema packet sa diha nga sila gi-retransmit. Ang mga pakete sa ACK usab adunay panahon sa pagproseso sa pakete ug pagmugna og ACK sa bahin sa kliyente. Kini nga mga bahin nagsiguro nga ang QUIC nagkalkula sa RTT nga mas tukma. Ang ACK sa QUIC nagsuporta hangtod sa 256 ka banda , nagtabang sa nagpadala nga mas lig-on sa packet shuffling ug mogamit ug mas diyutay nga byte sa proseso. Pinili nga ACK () sa TCP dili makasulbad niini nga problema sa tanang kaso.
- koneksyon migration. Ang QUIC nga mga koneksyon giila sa usa ka 64-bit ID, mao nga kung ang usa ka kliyente mag-usab sa mga IP address, ang daan nga koneksyon ID mahimong magpadayon nga gamiton sa bag-ong IP address nga walay pagkabalda. Kini usa ka kasagaran nga praktis alang sa mga mobile application diin ang tiggamit nagbalhin-balhin tali sa Wi-Fi ug mga koneksyon sa cellular.
Mga alternatibo sa QUIC
Among gikonsiderar ang mga alternatibong pamaagi sa pagsulbad sa problema sa dili pa mopili sa QUIC.
Ang unang butang nga among gisulayan mao ang pag-deploy sa TPC PoPs (Points of Presence) aron tapuson ang mga koneksyon sa TCP nga mas duol sa mga tiggamit. Sa esensya, ang mga PoP nagtapos sa usa ka koneksyon sa TCP sa usa ka mobile device nga mas duol sa cellular network ug i-proxy ang trapiko balik sa orihinal nga imprastraktura. Pinaagi sa pagtapos sa TCP nga mas duol, mahimo natong makunhuran ang RTT ug masiguro nga ang TCP mas mosanong sa usa ka dinamikong wireless nga palibot. Bisan pa, gipakita sa among mga eksperimento nga kadaghanan sa RTT ug pagkawala gikan sa mga cellular network ug ang paggamit sa mga PoP wala maghatag hinungdanon nga pag-uswag sa pasundayag.
Gitan-aw usab namo ang pag-tune sa mga parameter sa TCP. Ang pag-set up og TCP stack sa among heterogeneous edge nga mga server lisud tungod kay ang TCP adunay managlahi nga pagpatuman sa lain-laing mga bersyon sa OS. Lisud ang pagpatuman niini ug pagsulay sa lainlaing mga pag-configure sa network. Ang pag-configure sa TCP direkta sa mga mobile device dili mahimo tungod sa kakulang sa mga pagtugot. Labaw sa tanan, ang mga bahin sama sa 0-RTT nga mga koneksyon ug gipaayo nga pagtagna sa RTT kritikal sa arkitektura sa protocol, ug busa imposible nga makab-ot ang hinungdanon nga mga benepisyo pinaagi sa pag-tune lamang sa TCP.
Sa katapusan, among gisusi ang daghang UDP-based nga mga protocol nga nag-troubleshoot sa video streamingβgusto namong tan-awon kon kini nga mga protocol makatabang ba sa among kaso. Ikasubo, kulang sila sa daghang mga setting sa seguridad, ug nanginahanglan usab usa ka dugang nga koneksyon sa TCP alang sa metadata ug impormasyon sa pagkontrol.
Gipakita sa among panukiduki nga ang QUIC tingali ang bugtong protocol nga makatabang sa problema sa trapiko sa Internet, samtang gikonsiderar ang seguridad ug pasundayag.
Paghiusa sa QUIC sa plataporma
Aron malampuson nga ma-embed ang QUIC ug mapauswag ang performance sa aplikasyon sa dili maayo nga koneksyon nga palibot, among giilisan ang daan nga stack (HTTP/2 sa TLS/TCP) sa QUIC protocol. Gigamit namon ang librarya sa network gikan sa , nga naglangkob sa orihinal, Google nga bersyon sa protocol - gQUIC. Kini nga pagpatuman padayon usab nga gipauswag aron masunod ang pinakabag-o nga detalye sa IETF.
Una namon nga gisagol ang Cronet sa among mga Android apps aron makadugang suporta para sa QUIC. Ang paghiusa gihimo sa paagi nga makunhuran ang gasto sa paglalin kutob sa mahimo. Imbis nga hingpit nga ilisan ang daan nga networking stack nga gigamit ang librarya , gisagol namo ang Cronet UBOS sa OkHttp API framework. Pinaagi sa paghimo sa panagsama niining paagiha, among gilikayan ang mga pagbag-o sa among mga tawag sa network (nga gigamit sa ) sa lebel sa API.
Sama sa pamaagi alang sa mga Android device, gipatuman namo ang Cronet sa Uber apps sa iOS, nga nagpugong sa trapiko sa HTTP gikan sa network. naggamit . Kini nga abstraction, nga gihatag sa iOS Foundation, nagdumala sa datos sa URL nga piho sa protocol ug nagsiguro nga mahimo namon nga i-integrate ang Cronet sa among mga aplikasyon sa iOS nga walaβy daghang gasto sa paglalin.
Pagkompleto sa QUIC sa Google Cloud Balancers
Sa luyo nga bahin, ang QUIC nga pagkompleto gihatag sa Google Cloud Load nga imprastraktura sa pagbalanse, nga gigamit mga ulohan sa mga tubag sa pagsuporta sa QUIC. Sa kinatibuk-an, ang balancer nagdugang ug alt-svc header sa matag HTTP nga hangyo, ug kini nagpamatuod na sa QUIC nga suporta para sa domain. Kung ang usa ka kliyente sa Cronet makadawat usa ka tubag sa HTTP nga adunay kini nga ulohan, gigamit niini ang QUIC alang sa sunod nga mga hangyo sa HTTP sa kana nga domain. Kung makompleto na sa balancer ang QUIC, ang among imprastraktura klaro nga nagpadala niini nga aksyon sa HTTP2/TCP sa among mga data center.
Pagpasundayag: Mga Resulta
Ang performance sa output mao ang nag-unang rason sa among pagpangita og mas maayong protocol. Sa pagsugod, naghimo kami usa ka baruganan aron mahibal-an kung giunsa ang paggawi sa QUIC ubos sa lainlaing mga profile sa network. Aron masulayan ang performance sa QUIC sa tinuod nga kalibutan nga mga network, nagpahigayon kami og mga eksperimento samtang nagdrayb libot sa New Delhi gamit ang gisunod nga trapiko sa network nga susama kaayo sa HTTP nga mga tawag sa app sa pasahero.
Eksperimento 1
Kagamitan alang sa eksperimento:
- sulayi ang mga Android device nga adunay OkHttp ug Cronet stacks aron masiguro nga among gitugotan ang HTTPS nga trapiko sa TCP ug QUIC matag usa;
- usa ka server sa emulation nga nakabase sa Java nga nagpadala sa parehas nga tipo sa mga header sa HTTPS sa mga tubag ug nagkarga sa mga aparato sa kliyente aron makadawat mga hangyo gikan kanila;
- cloud proxy nga pisikal nga nahimutang duol sa India aron tapuson ang TCP ug QUIC nga mga koneksyon. Samtang alang sa pagtapos sa TCP migamit kami og reverse proxy sa , lisud ang pagpangita og open source reverse proxy para sa QUIC. Nagtukod kami og reverse proxy alang sa QUIC sa among kaugalingon gamit ang batakang QUIC stack gikan sa Chromium ug kini ngadto sa chromium isip open source.
Figure 6. Ang TCP vs QUIC road test suite naglangkob sa mga Android device nga adunay OkHttp ug Cronet, cloud proxy alang sa pagtapos sa mga koneksyon, ug usa ka emulation server.
Eksperimento 2
Sa dihang gihimo sa Google ang QUIC nga magamit sa , gigamit namo ang parehas nga imbentaryo, apan adunay usa ka pagbag-o: imbes nga NGINX, gikuha namon ang mga balanse sa load sa Google aron tapuson ang mga koneksyon sa TCP ug QUIC gikan sa mga aparato, ingon man sa pag-ruta sa trapiko sa HTTPS sa server sa emulation. Ang mga balanse giapod-apod sa tibuuk kalibutan, apan gamita ang PoP server nga labing duol sa aparato (salamat sa geolocation).
Figure 7. Sa ikaduhang eksperimento, gusto namong itandi ang pagkompleto sa latency sa TCP ug QUIC: gamit ang Google Cloud ug gamit ang among cloud proxy.
Isip resulta, daghang mga pagpadayag ang naghulat kanamo:
- ang pagtapos pinaagi sa PoP nagpauswag sa performance sa TCP. Tungod kay ang mga balancer nagtapos sa mga koneksyon sa TCP nga mas duol sa mga tiggamit ug labi nga na-optimize, kini nagresulta sa mas ubos nga mga RTT, nga nagpauswag sa performance sa TCP. Ug bisan kung ang QUIC dili kaayo apektado, mas maayo gihapon ang TCP sa mga termino sa pagkunhod sa latency sa ikog (sa 10-30 porsyento).
- apektado ang mga ikog . Bisan kung ang among QUIC proxy mas layo sa mga aparato (mga 50 ms nga mas taas nga latency) kaysa sa mga balanse sa load sa Google, naghatag kini parehas nga pasundayag - usa ka 15% nga pagkunhod sa latency kumpara sa usa ka 20% nga pagkunhod sa ika-99 nga porsyento alang sa TCP. Kini nagsugyot nga ang katapusang milya nga pagbalhin usa ka bottleneck sa network.
Figure 8: Ang mga resulta gikan sa duha ka eksperimento nagpakita nga ang QUIC mas labaw sa TCP.
Pakigsangka sa trapiko
Nadasig sa eksperimento, gipatuman namo ang QUIC nga suporta sa among mga aplikasyon sa Android ug iOS. Nagpahigayon kami og A/B testing aron mahibal-an ang epekto sa QUIC sa mga siyudad diin naglihok ang Uber. Sa kinatibuk-an, nakita namon ang usa ka hinungdanon nga pagkunhod sa mga paglangan sa ikog sa parehas nga mga rehiyon, mga operator sa telecom ug tipo sa network.
Ang mga graph sa ubos nagpakita sa porsyento nga pag-uswag sa mga ikog (95 ug 99 nga porsyento) pinaagi sa macro-rehiyon ug lain-laing matang sa network - LTE, 3G, 2G.
Figure 9. Sa mga pagsulay sa gubat, ang QUIC milabaw sa TCP sa termino sa latency.
Sa unahan ra
Tingali kini pa lang ang sinugdanan - ang pagpagawas sa QUIC sa produksiyon naghatag katingad-an nga mga oportunidad aron mapaayo ang pasundayag sa aplikasyon sa parehas nga lig-on ug dili lig-on nga mga network, nga mao:
Dugang nga coverage
Sa pag-analisar sa pasundayag sa protocol sa tinuod nga trapiko, among nakita nga gibana-bana nga 80% sa mga sesyon ang malampusong migamit sa QUIC alang sa sa tanan hangyo, samtang 15% sa mga sesyon migamit sa kombinasyon sa QUIC ug TCP. Nagtuo kami nga ang kombinasyon tungod sa Cronet library timeouting balik sa TCP, tungod kay dili kini makaila tali sa tinuod nga mga kapakyasan sa UDP ug dili maayo nga mga kondisyon sa network. Sa pagkakaron kami nagtan-aw sa usa ka solusyon niini nga problema samtang kami nagtrabaho padulong sa sunod nga pagpatuman sa QUIC.
QUIC optimization
Ang trapiko gikan sa mga mobile app sensitibo sa latency, apan dili sensitibo sa bandwidth. Usab, ang among mga aplikasyon panguna nga gigamit sa mga cellular network. Base sa mga eksperimento, taas gihapon ang mga latency sa ikog bisag naggamit ug proxy para tapuson ang TCP ug QUIC duol sa mga tiggamit. Aktibo kami nga nangita mga paagi aron mapaayo ang pagdumala sa paghuot ug mapaayo ang kahusayan sa mga algorithm sa pagbawi sa pagkawala sa QUIC.
Uban niini ug uban pang mga pag-uswag, nagplano kami nga pauswagon ang kasinatian sa gumagamit bisan unsa pa ang network ug rehiyon, nga naghimo nga dali ug hapsay nga transportasyon sa packet nga mas dali ma-access sa tibuuk kalibutan.
Source: www.habr.com