Itifaki ya QUIC inavutia sana kutazama, ndiyo maana tunapenda kuandika kuihusu. Lakini ikiwa machapisho ya awali kuhusu QUIC yalikuwa zaidi ya historia (historia ya eneo, ikiwa ungependa) asili na maunzi, leo tunafurahi kuchapisha tafsiri ya aina tofauti - tutazungumza juu ya matumizi halisi ya itifaki mnamo 2019. Zaidi ya hayo, hatuzungumzii juu ya miundombinu ndogo iliyo kwenye karakana inayoitwa, lakini kuhusu Uber, ambayo inafanya kazi karibu duniani kote. Jinsi wahandisi wa kampuni hiyo walivyofikia uamuzi wa kutumia QUIC katika uzalishaji, jinsi walivyofanya vipimo na walichokiona baada ya kuizindua katika uzalishaji - chini ya kata.
Picha zinaweza kubofya. Furahia kusoma!
Uber ina kiwango cha kimataifa, ambacho ni miji 600 ya uwepo, katika kila moja ambayo programu inategemea kabisa Mtandao usio na waya kutoka kwa zaidi ya waendeshaji 4500 wa simu za mkononi. Watumiaji wanatarajia programu kuwa sio tu ya haraka, lakini kwa wakati halisi - ili kufikia hili, programu ya Uber inahitaji muda wa chini wa kusubiri na muunganisho wa kuaminika sana. Ole, lakini stack haifanyi vyema katika mitandao isiyotumia waya inayobadilika na kukabiliwa na hasara. Tuligundua kuwa katika kesi hii, utendaji wa chini unahusiana moja kwa moja na utekelezaji wa TCP katika kernels za mfumo wa uendeshaji.
Ili kutatua tatizo, tulituma maombi , itifaki ya kisasa ya kuzidisha njia ambayo hutupatia udhibiti zaidi wa utendakazi wa itifaki ya usafiri. Hivi sasa kikundi cha kazi inasawazisha QUIC kama .
Baada ya majaribio ya kina, tulihitimisha kuwa kutekeleza QUIC katika maombi yetu kungesababisha ucheleweshaji mdogo ikilinganishwa na TCP. Tuliona kupungua kwa anuwai ya 10-30% kwa trafiki ya HTTPS katika programu za dereva na abiria. QUIC pia ilitupa udhibiti wa mwisho hadi mwisho juu ya vifurushi vya watumiaji.
Katika makala haya, tunashiriki uzoefu wetu katika kuboresha TCP kwa programu za Uber kwa kutumia mkusanyiko unaoauni QUIC.
Teknolojia ya hivi karibuni: TCP
Leo, TCP ndiyo itifaki ya usafiri inayotumika zaidi kuwasilisha trafiki ya HTTPS kwenye Mtandao. TCP hutoa mkondo wa kuaminika wa baiti, na hivyo kukabiliana na msongamano wa mtandao na upotezaji wa safu ya kiungo. Kuenea kwa matumizi ya TCP kwa trafiki ya HTTPS kunatokana na ueneaji wa zamani (karibu kila OS ina TCP), upatikanaji wa miundombinu mingi (kama vile visawazisha mizigo, proksi za HTTPS na CDN), na utendakazi wa nje ya kisanduku unaopatikana. kwenye karibu majukwaa na mitandao mingi.
Watumiaji wengi hutumia programu yetu popote pale, na muda wa kusubiri wa TCP haukuwa karibu na mahitaji ya trafiki yetu ya HTTPS ya wakati halisi. Kwa ufupi, watumiaji kote ulimwenguni wamepitia hili - Kielelezo cha 1 kinaonyesha ucheleweshaji katika miji mikuu:
Kielelezo cha 1: Muda wa kusubiri unatofautiana katika miji mikuu ya Uber.
Ingawa muda wa kusubiri katika mitandao ya India na Brazili ulikuwa wa juu zaidi kuliko Marekani na Uingereza, muda wa kusubiri wa mkia ni wa juu zaidi kuliko wastani wa kusubiri. Na hii ni kweli hata kwa Marekani na Uingereza.
TCP juu ya utendaji wa hewa
TCP iliundwa kwa ajili ya yenye waya mitandao, yaani, kwa msisitizo juu ya viungo vinavyotabirika sana. Hata hivyo, isiyo na waya mitandao ina sifa na matatizo yao wenyewe. Kwanza, mitandao isiyo na waya inakabiliwa na hasara kutokana na kuingiliwa na kupunguza ishara. Kwa mfano, mitandao ya Wi-Fi ni nyeti kwa microwaves, bluetooth na mawimbi mengine ya redio. Mitandao ya rununu inakabiliwa na upotezaji wa mawimbi () kwa sababu ya kutafakari / kunyonya kwa ishara na vitu na majengo, na vile vile kutoka kutoka jirani . Hii inasababisha muhimu zaidi (mara 4-10) na tofauti zaidi na upotezaji wa pakiti ikilinganishwa na muunganisho wa waya.
Ili kukabiliana na mabadiliko na hasara ya kipimo data, mitandao ya simu kwa kawaida hutumia vihifadhi vikubwa kwa milipuko ya trafiki. Hii inaweza kusababisha foleni nyingi, ambayo inamaanisha kucheleweshwa kwa muda mrefu. Mara nyingi sana TCP huchukulia foleni hii kama upotevu kwa sababu ya kuisha kwa muda kwa muda, kwa hivyo TCP huwa na usambazaji na hivyo kujaza bafa. Tatizo hili linajulikana kama (), na hii ni sana mtandao wa kisasa.
Hatimaye, utendakazi wa mtandao wa simu za mkononi hutofautiana kulingana na mtoa huduma, eneo na saa. Katika Mchoro wa 2, tulikusanya ucheleweshaji wa wastani wa trafiki ya HTTPS kwenye seli zote ndani ya masafa ya kilomita 2. Data iliyokusanywa kwa waendeshaji wakuu wawili wa simu za rununu huko Delhi, India. Kama unaweza kuona, utendaji hutofautiana kutoka seli hadi seli. Pia, tija ya operator mmoja hutofautiana na tija ya pili. Hii inathiriwa na vipengele kama vile mifumo ya kuingia kwa mtandao ikizingatia muda na eneo, uhamaji wa watumiaji, pamoja na miundombinu ya mtandao kwa kuzingatia msongamano wa minara na uwiano wa aina za mtandao (LTE, 3G, n.k.).
Mchoro 2. Ucheleweshaji kwa kutumia eneo la kilomita 2 kama mfano. Delhi, India.
Pia, utendaji wa mitandao ya simu hutofautiana kwa wakati. Kielelezo cha 3 kinaonyesha muda wa kusubiri wa wastani kwa siku ya juma. Pia tuliona tofauti kwa kiwango kidogo, ndani ya siku moja na saa moja.
Kielelezo 3. Ucheleweshaji wa mkia unaweza kutofautiana kwa kiasi kikubwa kati ya siku, lakini kwa operator sawa.
Yote haya hapo juu husababisha utendaji wa TCP kutofanya kazi katika mitandao isiyo na waya. Walakini, kabla ya kutafuta njia mbadala za TCP, tulitaka kukuza uelewa sahihi juu ya mambo yafuatayo:
- TCP ndio mhusika mkuu nyuma ya kucheleweshwa kwa maombi yetu?
- Je, mitandao ya kisasa ina ucheleweshaji mkubwa na tofauti wa kwenda na kurudi (RTT)?
- Je, ni nini athari za RTT na hasara kwenye utendaji wa TCP?
Uchambuzi wa Utendaji wa TCP
Ili kuelewa jinsi tulivyochanganua utendaji wa TCP, hebu tuangalie kwa haraka jinsi TCP inavyohamisha data kutoka kwa mtumaji hadi kwa mpokeaji. Kwanza, mtumaji huanzisha uunganisho wa TCP, akifanya njia tatu : Mtumaji hutuma pakiti ya SYN, husubiri pakiti ya SYN-ACK kutoka kwa mpokeaji, kisha kutuma pakiti ya ACK. Pasi ya ziada ya pili na ya tatu hutumiwa kuanzisha uunganisho wa TCP. Mpokeaji anakubali kupokea kila pakiti (ACK) ili kuhakikisha utoaji unaotegemewa.
Ikiwa pakiti au ACK itapotea, mtumaji hutuma tena baada ya muda kuisha (RTO, ) RTO hukokotolewa kwa ubadilikaji kulingana na vipengele mbalimbali, kama vile ucheleweshaji wa RTT unaotarajiwa kati ya mtumaji na mpokeaji.
Kielelezo 4. Ubadilishanaji wa pakiti juu ya TCP/TLS inajumuisha utaratibu wa kutuma tena.
Ili kubainisha jinsi TCP ilivyofanya kazi katika programu zetu, tulifuatilia pakiti za TCP kwa kutumia kwa wiki juu ya trafiki ya mapigano inayotoka kwa seva za makali za India. Kisha tukachambua miunganisho ya TCP kwa kutumia . Zaidi ya hayo, tumeunda programu ya Android ambayo hutuma trafiki iliyoigwa kwa seva ya majaribio, kuiga trafiki halisi iwezekanavyo. Simu mahiri zilizo na programu hii zilisambazwa kwa wafanyikazi kadhaa, ambao walikusanya kumbukumbu kwa siku kadhaa.
Matokeo ya majaribio yote mawili yalikuwa sawa na kila mmoja. Tuliona muda wa juu wa RTT; maadili ya mkia yalikuwa karibu mara 6 kuliko thamani ya wastani; wastani wa ucheleweshaji wa hesabu ni zaidi ya sekunde 1. Miunganisho mingi ilipotea, na kusababisha TCP kutuma tena 3,5% ya pakiti zote. Katika maeneo yenye msongamano kama vile viwanja vya ndege na vituo vya treni, tuliona hasara ya 7%. Matokeo haya yalitia shaka juu ya hekima ya kawaida ambayo yale yaliyotumiwa katika mitandao ya simu za mkononi kupunguza kwa kiasi kikubwa hasara katika ngazi ya usafiri. Yafuatayo ni matokeo ya majaribio kutoka kwa programu ya "simulator":
Vipimo vya mtandao
Maadili
RTT, milisekunde [50%,75%, 95%,99%]
[350, 425, 725, 2300]
Tofauti ya RTT, sekunde
Kwa wastani ~1,2 s
Upotezaji wa pakiti kwenye miunganisho isiyo thabiti
Wastani ~ 3.5% (7% katika maeneo yaliyojaa)
Takriban nusu ya viunganisho hivi vilikuwa na upotezaji wa pakiti moja, nyingi zikiwa SYN na SYN-ACK. Utekelezaji mwingi wa TCP hutumia thamani ya RTO ya sekunde 1 kwa pakiti za SYN, ambayo huongezeka kwa kasi kwa hasara zinazofuata. Nyakati za kupakia programu zinaweza kuongezeka kutokana na TCP kuchukua muda mrefu kuanzisha miunganisho.
Kwa upande wa pakiti za data, maadili ya juu ya RTO hupunguza sana utumiaji muhimu wa mtandao mbele ya upotezaji wa muda mfupi katika mitandao isiyo na waya. Tuligundua kuwa muda wa wastani wa kutuma tena ni takriban sekunde 1 na kucheleweshwa kwa mkia kwa karibu sekunde 30. Ucheleweshaji huu wa juu katika kiwango cha TCP ulisababisha kuisha kwa muda na maombi ya HTTPS, na hivyo kuongeza muda wa kusubiri na uzembe wa mtandao.
Ingawa asilimia 75 ya RTT iliyopimwa ilikuwa karibu 425 ms, asilimia 75 ya TCP ilikuwa karibu sekunde 3. Hii inadokeza kuwa hasara ilisababisha TCP kuchukua pasi 7-10 ili kusambaza data kwa mafanikio. Hii inaweza kuwa ni matokeo ya hesabu ya RTO isiyofaa, kutokuwa na uwezo wa TCP kujibu haraka hasara. katika dirisha na ufanisi wa algorithm ya kudhibiti msongamano, ambayo haitofautishi kati ya hasara na hasara zisizo na waya kutokana na msongamano wa mtandao. Yafuatayo ni matokeo ya vipimo vya kupoteza TCP:
Takwimu za upotezaji wa pakiti za TCP
Thamani
Asilimia ya miunganisho iliyo na upotezaji wa pakiti 1
45%
Asilimia ya miunganisho na hasara wakati wa kusanidi muunganisho
30%
Asilimia ya miunganisho na hasara wakati wa kubadilishana data
76%
Usambazaji wa ucheleweshaji wa uhamishaji tena, sekunde [50%, 75%, 95%,99%] [1, 2.8, 15, 28]
Usambazaji wa idadi ya uhamishaji tena kwa pakiti moja au sehemu ya TCP
[1,3,6,7]
Utumiaji wa QUIC
Iliyoundwa awali na Google, QUIC ni itifaki ya usafiri ya kisasa yenye nyuzi nyingi ambayo inaendesha juu ya UDP. Kwa sasa QUIC imeingia (tayari tuliandika kwamba kuna, kama ilivyokuwa, matoleo mawili ya QUIC, ya kutaka kujua - takriban. mtafsiri). Kama inavyoonyeshwa kwenye Kielelezo 5, QUIC imewekwa chini ya HTTP/3 (kwa hakika, HTTP/2 juu ya QUIC ni HTTP/3, ambayo sasa inasawazishwa sana). Inachukua nafasi ya safu za HTTPS na TCP kwa kutumia UDP kuunda pakiti. QUIC inaauni uhamishaji salama wa data pekee kwani TLS imeundwa kikamilifu ndani ya QUIC.
Kielelezo cha 5: QUIC inaendeshwa chini ya HTTP/3, ikichukua nafasi ya TLS, ambayo awali ilikuwa chini ya HTTP/2.
Zifuatazo ni sababu zilizotushawishi kutumia QUIC kwa ukuzaji wa TCP:
- Uanzishaji wa muunganisho wa 0-RTT. QUIC inaruhusu utumiaji tena wa uidhinishaji kutoka kwa miunganisho ya awali, na kupunguza idadi ya kupeana mikono kwa usalama. Katika siku zijazo itasaidia 0-RTT, lakini kupeana mkono kwa TCP kwa njia tatu bado kutahitajika.
- kushinda kuzuia HoL. HTTP/2 hutumia muunganisho mmoja wa TCP kwa kila mteja ili kuboresha utendakazi, lakini hii inaweza kusababisha kizuizi cha HoL (kichwa cha mstari). QUIC hurahisisha kuzidisha na kuwasilisha maombi kwa programu kivyake.
- kudhibiti msongamano. QUIC hukaa kwenye safu ya programu, hivyo kurahisisha kusasisha algoriti kuu ya usafiri ambayo inadhibiti utumaji kulingana na vigezo vya mtandao (idadi ya hasara au RTT). Utekelezaji mwingi wa TCP hutumia algorithm , ambayo si bora kwa trafiki nyeti kwa muda. Algorithms zilizotengenezwa hivi karibuni kama , tengeneza muundo wa mtandao kwa usahihi zaidi na uboresha muda wa kusubiri. QUIC hukuruhusu kutumia BBR na kusasisha algoriti hii jinsi inavyotumika. .
- kujazwa tena kwa hasara. QUIC inaita TLP mbili () kabla ya RTO kuanzishwa - hata wakati hasara inaonekana sana. Hii ni tofauti na utekelezaji wa TCP. TLP hutuma tena pakiti ya mwisho (au mpya, ikiwa ipo) ili kuanzisha ujazaji haraka. Kushughulikia ucheleweshaji wa mkia ni muhimu sana kwa jinsi Uber inavyoendesha mtandao wake, yaani, kwa uhamishaji wa data mfupi, wa hapa na pale na ambao ni nyeti kwa muda.
- ACK iliyoboreshwa. Kwa kuwa kila pakiti ina nambari ya mlolongo wa kipekee, hakuna shida pakiti zinapotumwa tena. Pakiti za ACK pia zina wakati wa kuchakata pakiti na kutoa ACK kwa upande wa mteja. Vipengele hivi huhakikisha kuwa QUIC hukokotoa RTT kwa usahihi zaidi. ACK katika QUIC inaweza kutumia hadi bendi 256 , kumsaidia mtumaji kuwa mvumilivu zaidi katika kuchanganya pakiti na kutumia baiti chache katika mchakato. ACK ya kuchagua () katika TCP haisuluhishi tatizo hili katika visa vyote.
- uhamiaji wa uunganisho. Miunganisho ya QUIC inatambuliwa na kitambulisho cha biti 64, kwa hivyo mteja akibadilisha anwani za IP, kitambulisho cha zamani cha muunganisho kinaweza kuendelea kutumika kwenye anwani mpya ya IP bila kukatizwa. Hili ni jambo la kawaida sana kwa programu za rununu ambapo mtumiaji hubadilisha kati ya miunganisho ya Wi-Fi na simu za rununu.
Njia mbadala za QUIC
Tulizingatia mbinu mbadala za kutatua tatizo kabla ya kuchagua QUIC.
Jambo la kwanza tulilojaribu ni kupeleka TPC PoPs (Points of Presence) ili kukomesha miunganisho ya TCP karibu na watumiaji. Kimsingi, PoPs hukatisha muunganisho wa TCP kwa kutumia kifaa cha mkononi karibu na mtandao wa simu za mkononi na kutoa seva mbadala kwa miundombinu asili. Kwa kusimamisha TCP karibu, tunaweza kupunguza uwezekano wa RTT na kuhakikisha kuwa TCP inaitikia zaidi mazingira yanayobadilika ya pasiwaya. Hata hivyo, majaribio yetu yameonyesha kuwa RTT nyingi na hasara hutoka kwa mitandao ya simu za mkononi na matumizi ya PoPs hayatoi uboreshaji mkubwa wa utendaji.
Tuliangalia pia kurekebisha vigezo vya TCP. Kuweka mrundikano wa TCP kwenye seva zetu za ukingo tofauti ilikuwa ngumu kwa sababu TCP ina utekelezwaji tofauti katika matoleo tofauti ya Mfumo wa Uendeshaji. Ilikuwa ngumu kutekeleza hili na kujaribu usanidi tofauti wa mtandao. Kusanidi TCP moja kwa moja kwenye vifaa vya rununu haikuwezekana kwa sababu ya ukosefu wa ruhusa. Muhimu zaidi, vipengele kama vile miunganisho ya 0-RTT na utabiri ulioboreshwa wa RTT ni muhimu kwa usanifu wa itifaki, na kwa hivyo haiwezekani kufikia manufaa makubwa kwa kurekebisha TCP pekee.
Hatimaye, tulitathmini itifaki kadhaa za UDP ambazo hutatua utiririshaji wa videoβtulitaka kuona ikiwa itifaki hizi zingetusaidia. Kwa bahati mbaya, walikosa sana katika mipangilio mingi ya usalama, na pia walihitaji muunganisho wa ziada wa TCP kwa metadata na maelezo ya udhibiti.
Utafiti wetu umeonyesha kuwa QUIC labda ndiyo itifaki pekee inayoweza kusaidia kwa tatizo la trafiki ya mtandao, huku ikizingatia usalama na utendakazi.
Ujumuishaji wa QUIC kwenye jukwaa
Ili kupachika QUIC kwa ufanisi na kuboresha utendaji wa programu katika mazingira duni ya muunganisho, tulibadilisha rafu ya zamani (HTTP/2 juu ya TLS/TCP) na itifaki ya QUIC. Tulitumia maktaba ya mtandao ya , ambayo ina asili, toleo la Google la itifaki - gQUIC. Utekelezaji huu pia unaboreshwa kila mara ili kufuata vipimo vya hivi punde zaidi vya IETF.
Kwanza tuliunganisha Cronet kwenye programu zetu za Android ili kuongeza usaidizi kwa QUIC. Ujumuishaji ulifanyika kwa njia ya kupunguza gharama za uhamiaji iwezekanavyo. Badala ya kubadilisha kabisa safu ya zamani ya mtandao ambayo ilitumia maktaba , tumeunganisha Cronet CHINI ya mfumo wa API ya OkHttp. Kwa kufanya ujumuishaji kwa njia hii, tuliepuka mabadiliko kwenye simu zetu za mtandao (ambazo hutumiwa na ) katika kiwango cha API.
Sawa na mbinu ya vifaa vya Android, tulitekeleza Cronet kwenye programu za Uber kwenye iOS, na kuzuia trafiki ya HTTP kutoka kwa mtandao. kutumia . Muhtasari huu, unaotolewa na iOS Foundation, hushughulikia data ya URL mahususi ya itifaki na huhakikisha kwamba tunaweza kujumuisha Cronet kwenye programu zetu za iOS bila gharama kubwa za uhamiaji.
Inakamilisha QUIC kwenye Mizani ya Wingu la Google
Kwa upande wa nyuma, ukamilishaji wa QUIC hutolewa na miundombinu ya kusawazisha ya Mzigo wa Wingu wa Google, ambayo hutumia vichwa katika majibu ya kusaidia QUIC. Kwa ujumla, sawazisha huongeza kichwa cha alt-svc kwa kila ombi la HTTP, na hii tayari inathibitisha usaidizi wa QUIC kwa kikoa. Wakati mteja wa Cronet anapokea jibu la HTTP kwa kichwa hiki, hutumia QUIC kwa maombi ya HTTP yanayofuata kwa kikoa hicho. Mara tu msawazishaji anapokamilisha QUIC, miundombinu yetu hutuma kitendo hiki kwa njia ya HTTP2/TCP kwa vituo vyetu vya data.
Utendaji: Matokeo
Utendaji wa pato ndiyo sababu kuu ya utafutaji wetu wa itifaki bora zaidi. Kuanza, tuliunda msimamo na ili kujua jinsi QUIC itafanya chini ya wasifu tofauti wa mtandao. Ili kujaribu utendakazi wa QUIC kwenye mitandao ya ulimwengu halisi, tulifanya majaribio tukiwa tunaendesha gari karibu na New Delhi kwa kutumia trafiki ya mtandao iliyoigwa sawa na simu za HTTP katika programu ya abiria.
Jaribio 1
Vifaa kwa ajili ya majaribio:
- jaribu vifaa vya Android ukitumia rafu za OkHttp na Cronet ili kuhakikisha kwamba tunaruhusu trafiki ya HTTPS juu ya TCP na QUIC mtawalia;
- seva ya uigaji inayotokana na Java ambayo hutuma aina sawa za vichwa vya HTTPS katika majibu na kupakia vifaa vya mteja ili kupokea maombi kutoka kwao;
- proksi za wingu ambazo ziko karibu na India ili kuzima miunganisho ya TCP na QUIC. Wakati kwa usitishaji wa TCP tulitumia seva mbadala ya kurudi nyuma , ilikuwa vigumu kupata seva mbadala ya chanzo huria ya QUIC. Tulitengeneza seva mbadala ya QUIC wenyewe kwa kutumia rafu ya msingi ya QUIC kutoka Chromium na ndani ya chromium kama chanzo wazi.
Mchoro 6. Kitengo cha majaribio ya barabarani cha TCP dhidi ya QUIC kilijumuisha vifaa vya Android vilivyo na OkHttp na Cronet, proksi za wingu za kusimamisha miunganisho na seva ya mwigo.
Jaribio 2
Google ilipofanya QUIC ipatikane na , tulitumia hesabu sawa, lakini kwa urekebishaji mmoja: badala ya NGINX, tulichukua visawazishi vya upakiaji vya Google ili kukomesha miunganisho ya TCP na QUIC kutoka kwa vifaa, na pia kuelekeza trafiki ya HTTPS kwa seva ya kuiga. Visawazisho vinasambazwa duniani kote, lakini tumia seva ya PoP iliyo karibu na kifaa (shukrani kwa eneo la kijiografia).
Mchoro wa 7. Katika jaribio la pili, tulitaka kulinganisha muda wa kusubiri kukamilika kwa TCP na QUIC: kutumia Wingu la Google na kutumia seva mbadala ya wingu.
Kama matokeo, mafunuo kadhaa yalitungojea:
- kukomesha kupitia PoP kumeboresha utendakazi wa TCP. Kwa kuwa visawazishaji hukatisha miunganisho ya TCP karibu na watumiaji na kuboreshwa kwa kiwango cha juu, hii inasababisha kupungua kwa RTT, ambayo huboresha utendaji wa TCP. Na ingawa QUIC haikuathiriwa kidogo, bado ilifanya vyema TCP katika suala la kupunguza kasi ya mkia (kwa asilimia 10-30).
- mikia huathiriwa . Ingawa proksi yetu ya QUIC ilitoka zaidi kwenye vifaa (muda wa kusubiri wa takriban ms 50 zaidi) kuliko visawazishi vya upakiaji vya Google, ilitoa utendaji sawa - punguzo la 15% la muda dhidi ya punguzo la 20% la asilimia 99 ya TCP. Hii inaonyesha kuwa mpito wa maili ya mwisho ni kizuizi katika mtandao.
Kielelezo cha 8: Matokeo kutoka kwa majaribio mawili yanaonyesha kuwa QUIC ina utendaji bora zaidi wa TCP.
Kupambana na trafiki
Kwa msukumo wa majaribio, tumetekeleza usaidizi wa QUIC katika programu zetu za Android na iOS. Tulifanya majaribio ya A/B ili kubaini athari ya QUIC katika miji ambako Uber hufanya kazi. Kwa ujumla, tuliona upungufu mkubwa wa ucheleweshaji wa mkia katika maeneo yote mawili, waendeshaji wa mawasiliano ya simu na aina ya mtandao.
Grafu zilizo hapa chini zinaonyesha uboreshaji wa asilimia katika mikia (asilimia 95 na 99) kulingana na eneo kubwa na aina tofauti za mtandao - LTE, 3G, 2G.
Mchoro 9. Katika majaribio ya vita, QUIC ilifanya vyema TCP katika suala la muda wa kusubiri.
Mbele tu
Labda huu ni mwanzo tu - kutolewa kwa QUIC katika toleo la umma kumetoa fursa nzuri za kuboresha utendaji wa programu katika mitandao thabiti na isiyo thabiti, ambayo ni:
Kuongezeka kwa chanjo
Baada ya kuchanganua utendakazi wa itifaki kwenye trafiki halisi, tuliona kuwa takriban 80% ya vipindi vilitumia QUIC kwa ufanisi. Kila maombi, wakati 15% ya vipindi vilitumia mchanganyiko wa QUIC na TCP. Tunadhania kuwa mchanganyiko huo unatokana na muda wa maktaba ya Cronet kurejea TCP, kwa kuwa haiwezi kutofautisha kati ya hitilafu halisi za UDP na hali duni za mtandao. Kwa sasa tunatafuta suluhu la tatizo hili tunaposhughulikia utekelezaji wa baadaye wa QUIC.
Uboreshaji wa QUIC
Trafiki kutoka kwa programu za simu ni nyeti kwa muda, lakini si nyeti kwa kipimo data. Pia, programu tumizi zetu hutumika hasa kwenye mitandao ya simu za mkononi. Kulingana na majaribio, muda wa kusubiri wa mkia bado uko juu ingawa kutumia seva mbadala kuzima TCP na QUIC karibu na watumiaji. Tunatafuta kwa dhati njia za kuboresha udhibiti wa msongamano na kuboresha ufanisi wa kanuni za kurejesha upotezaji wa QUIC.
Kwa maboresho haya na mengine kadhaa, tunapanga kuboresha matumizi bila kujali mtandao na eneo, kufanya usafiri wa pakiti rahisi na usio na mshono kufikiwa zaidi duniani kote.
Chanzo: mapenzi.com