Ka'idar QUIC tana da ban sha'awa sosai don kallo, wanda shine dalilin da ya sa muke son yin rubutu game da shi. Amma idan wallafe-wallafen da suka gabata game da QUIC sun kasance mafi tarihi (tarihin gida, idan kuna so) yanayi da kayan aiki, a yau muna farin cikin buga fassarar wani nau'in dabam - za mu yi magana game da ainihin aikace-aikacen yarjejeniya a cikin 2019. Bugu da ƙari, ba muna magana ne game da ƙananan kayan aikin da aka gina a cikin abin da ake kira gareji ba, amma game da Uber, wanda ke aiki kusan a duk faɗin duniya. Yadda injiniyoyin kamfanin suka yanke shawarar yin amfani da QUIC wajen samarwa, yadda suka gudanar da gwaje-gwajen da abin da suka gani bayan mirgine shi a samarwa - a ƙasa da yanke.
Hotunan ana iya dannawa. Ji daɗin karatu!
Uber yana da ma'auni na duniya, wato biranen kasancewar 600, a cikin kowannensu aikace-aikacen ya dogara kacokan akan Intanet mara waya daga fiye da 4500 masu amfani da wayar hannu. Masu amfani suna tsammanin app ɗin zai kasance ba sauri kawai ba, amma a cikin ainihin lokaci - don cimma wannan, ƙa'idar Uber tana buƙatar ƙarancin latency da ingantaccen haɗin gwiwa. Alas, amma tari ba ya yin kyau a cikin cibiyoyin sadarwa mara waya mai ƙarfi da asara. Mun gane cewa a wannan yanayin, ƙananan aikin yana da alaƙa kai tsaye da aiwatar da TCP a cikin kernels na tsarin aiki.
Don magance matsalar, mun nema , Ka'idar multixing ta zamani ta zamani wacce ke ba mu ƙarin iko akan aikin ƙa'idar sufuri. A halin yanzu ƙungiyar aiki yana daidaita QUIC azaman .
Bayan gwaji mai yawa, mun kammala cewa aiwatar da QUIC a cikin aikace-aikacen mu zai haifar da ƙarancin latency na wutsiya idan aka kwatanta da TCP. Mun lura da raguwa a cikin kewayon 10-30% don zirga-zirgar HTTPS a cikin direba da aikace-aikacen fasinja. QUIC kuma ta ba mu iko daga ƙarshen zuwa-ƙarshe akan fakitin masu amfani.
A cikin wannan labarin, muna raba gwanintar mu wajen inganta TCP don aikace-aikacen Uber ta amfani da tari mai goyan bayan QUIC.
Sabuwar fasaha: TCP
A yau, TCP ita ce ka'idar sufuri da aka fi amfani da ita don isar da zirga-zirgar HTTPS akan Intanet. TCP yana ba da ingantaccen rafi na bytes, ta yadda zai magance cunkoso na hanyar sadarwa da kuma asarar haɗin haɗin gwiwa. Yaɗuwar amfani da TCP don zirga-zirgar HTTPS ya faru ne saboda kasancewar tsohon (kusan kowane OS ya ƙunshi TCP), samuwa akan yawancin abubuwan more rayuwa (kamar ma'aunin nauyi, proxies HTTPS da CDNs), da ayyukan waje-na-akwatin da ke akwai. akan kusan yawancin dandamali da cibiyoyin sadarwa.
Yawancin masu amfani suna amfani da app ɗin mu yayin tafiya, kuma latencies wutsiya na TCP ba su kusa da buƙatun zirga-zirgar HTTPS na ainihin lokaci ba. A taƙaice, masu amfani a duk faɗin duniya sun fuskanci wannan - Hoto na 1 yana nuna jinkiri a manyan biranen:
Hoto 1: Latency wutsiya ya bambanta a cikin manyan biranen Uber.
Kodayake jinkiri a cikin hanyoyin sadarwar Indiya da Brazil ya fi na Amurka da Burtaniya, lat ɗin wutsiya yana da girma fiye da matsakaicin latency. Kuma wannan gaskiya ne har ga Amurka da Burtaniya.
TCP akan aikin iska
An halicci TCP don mai waya cibiyoyin sadarwa, wato, tare da mai da hankali kan hanyoyin da ake iya tsinkaya sosai. Duk da haka, mara waya cibiyoyin sadarwa suna da nasu halaye da wahalhalu. Na farko, cibiyoyin sadarwa mara waya suna da saukin kamuwa ga asara saboda tsangwama da rage sigina. Misali, cibiyoyin sadarwar Wi-Fi suna kula da microwaves, bluetooth da sauran igiyoyin rediyo. Hanyoyin sadarwar salula suna fama da asarar sigina () saboda tunani / shayar da siginar ta abubuwa da gine-gine, da kuma daga daga makwabta . Wannan yana haifar da ƙarin mahimmanci (sau 4-10) kuma ƙari daban-daban da asarar fakiti idan aka kwatanta da haɗin waya.
Don magance sauyin yanayin bandwidth da asara, cibiyoyin sadarwar salula galibi suna amfani da manyan buffers don fashewar zirga-zirga. Wannan na iya haifar da yawan yin layi, wanda ke nufin tsawaita jinkiri. Sau da yawa TCP yana ɗaukar wannan jerin gwano a matsayin sharar gida saboda tsawaita lokacin ƙarewa, don haka TCP yana kula da relay kuma ta haka ya cika buffer. Wannan matsalar da aka sani da (), kuma wannan sosai Intanet na zamani.
A ƙarshe, aikin hanyar sadarwar salula ya bambanta ta mai ɗauka, yanki, da lokaci. A cikin Hoto 2, mun tattara matsakaicin jinkirin zirga-zirgar HTTPS a cikin sel a cikin kewayon kilomita 2. Bayanan da aka tattara don manyan ma'aikatan salula guda biyu a Delhi, Indiya. Kamar yadda kake gani, aikin ya bambanta daga tantanin halitta zuwa tantanin halitta. Hakanan, aikin mai aiki ɗaya ya bambanta da yawan aiki na na biyu. Wannan yana tasiri da abubuwa kamar tsarin shigar da hanyar sadarwa ta la'akari da lokaci da wuri, motsin mai amfani, da kuma abubuwan more rayuwa na cibiyar sadarwa suna la'akari da yawan hasumiya da rabon nau'ikan cibiyar sadarwa (LTE, 3G, da sauransu).
Hoto 2. Jinkirta ta yin amfani da radius na kilomita 2 a matsayin misali. Delhi, India.
Hakanan, ayyukan cibiyoyin sadarwar salula sun bambanta akan lokaci. Hoto na 3 yana nuna jinkirin tsaka-tsaki ta rana ta mako. Mun kuma lura da bambance-bambance a kan ƙaramin ma'auni, a cikin yini ɗaya da sa'a guda.
Hoto 3. Jinkirin wutsiya na iya bambanta sosai tsakanin kwanaki, amma ga ma'aikaci ɗaya.
Duk abubuwan da ke sama suna haifar da aikin TCP baya tasiri a cikin cibiyoyin sadarwa mara waya. Koyaya, kafin neman mafita ga TCP, muna son haɓaka madaidaicin fahimta akan abubuwa masu zuwa:
- Shin TCP shine babban mai laifi a baya latencies wutsiya a cikin aikace-aikacen mu?
- Shin cibiyoyin sadarwa na zamani suna da mahimmanci da bambance-bambancen jinkirin tafiya zagaye (RTT)?
- Menene tasirin RTT da asara akan aikin TCP?
Binciken Ayyukan TCP
Don fahimtar yadda muka yi nazarin ayyukan TCP, bari mu yi saurin duba yadda TCP ke canja wurin bayanai daga mai aikawa zuwa mai karɓa. Na farko, mai aikawa ya kafa haɗin TCP, yana yin hanya uku : Mai aikawa ya aiko da fakitin SYN, ya jira fakitin SYN-ACK daga mai karɓa, sannan ya aika fakitin ACK. Ana kashe ƙarin wucewa na biyu da na uku don kafa haɗin TCP. Mai karɓa ya yarda da karɓar kowane fakiti (ACK) don tabbatar da ingantaccen bayarwa.
Idan fakiti ko ACK ya ɓace, mai aikawa yana sake aikawa bayan an ƙare (RTO, ). Ana ƙididdige RTO da ƙarfi bisa dalilai daban-daban, kamar jinkirin RTT tsakanin mai aikawa da mai karɓa.
Hoto 4. Musanya fakiti akan TCP/TLS ya haɗa da tsarin sake aikawa.
Don sanin yadda TCP ya yi a cikin aikace-aikacenmu, mun sanya ido kan fakitin TCP ta amfani da su tsawon mako guda akan zirga-zirgar zirga-zirgar da ke fitowa daga sabar gefen Indiya. Sannan mun bincika haɗin TCP ta amfani da . Bugu da ƙari, mun ƙirƙiri wani aikace-aikacen Android wanda ke aika da kwaikwayi zirga-zirga zuwa uwar garken gwaji, yana kwaikwayon zirga-zirga na gaske gwargwadon iko. An rarraba wayoyi masu amfani da wannan aikace-aikacen ga ma'aikata da yawa, waɗanda suka tattara logins a cikin kwanaki da yawa.
Sakamakon gwaje-gwajen biyu sun yi daidai da juna. Mun ga manyan latencies na RTT; dabi'un wutsiya sun kasance kusan sau 6 sama da matsakaicin darajar; Matsakaicin jinkirin lissafin lissafi ya fi daƙiƙa 1. Haɗi da yawa sun yi hasara, yana haifar da TCP don sake watsa 3,5% na duk fakiti. A wurare masu cunkoso kamar filayen jirgin sama da tashoshin jirgin kasa, mun ga asarar kashi 7%. Waɗannan sakamakon suna jefa shakku kan hikimar al'ada da waɗanda aka yi amfani da su a cibiyoyin sadarwar salula rage asara sosai a matakin sufuri. A ƙasa akwai sakamakon gwajin daga aikace-aikacen "simulator":
Ma'aunin hanyar sadarwa
Ma'ana
RTT, millise seconds [50%,75%, 95%,99%]
[350, 425, 725, 2300]
Bambancin RTT, daƙiƙa
A matsakaita ~ 1,2 s
Asarar fakiti akan haɗin da ba su da tabbas
Matsakaicin ~ 3.5% (7% a wuraren da aka yi yawa)
Kusan rabin waɗannan haɗin suna da aƙalla asarar fakiti ɗaya, yawancin su fakitin SYN da SYN-ACK. Yawancin aiwatarwa na TCP suna amfani da ƙimar RTO na daƙiƙa 1 don fakitin SYN, wanda ke ƙaruwa da yawa don asarar da ke gaba. Lokacin loda aikace-aikacen na iya ƙaruwa saboda TCP ɗin yana ɗaukar tsayi don kafa haɗin gwiwa.
A cikin yanayin fakitin bayanai, manyan ƙimar RTO suna rage amfani da hanyar sadarwa sosai a gaban hasarar ɗan lokaci a cikin cibiyoyin sadarwar mara waya. Mun gano cewa matsakaicin lokacin sake aikawa yana da kusan daƙiƙa 1 tare da jinkirin wutsiya na kusan daƙiƙa 30. Wadannan manyan latencies a matakin TCP sun haifar da lokutan HTTPS da sake buƙatun, ƙara haɓaka latency na cibiyar sadarwa da rashin aiki.
Yayin da kashi 75 na ma'aunin RTT ke kusa da 425 ms, kashi 75 na TCP ya kusan daƙiƙa 3. Wannan yana nuna cewa asarar ya sa TCP ya ɗauki 7-10 wucewa don samun nasarar watsa bayanai. Wannan na iya zama sakamakon rashin ingantaccen lissafin RTO, rashin iyawar TCP da sauri don amsa asara a cikin taga da rashin inganci na algorithm mai sarrafa cunkoso, wanda ba ya bambanta tsakanin asarar mara waya da asara saboda cunkoson hanyar sadarwa. A ƙasa akwai sakamakon gwajin asarar TCP:
Kididdigar asarar fakitin TCP
Ma'ana
Kashi na haɗin haɗin gwiwa tare da aƙalla asarar fakiti 1
45%
Kashi na haɗin haɗi tare da asara yayin saitin haɗin
30%
Kashi na haɗin kai tare da asara yayin musayar bayanai
76%
Rarraba jinkiri a cikin sakewa, daƙiƙa [50%, 75%, 95%,99%] [1, 2.8, 15, 28]
Rarraba adadin sake aikawa don fakiti ɗaya ko ɓangaren TCP
[1,3,6,7]
Aikace-aikacen QUIC
Asalin Google ne ya haɓaka, QUIC ƙa'idar sufuri ta zamani ce mai zaren zaren da ke gudana akan UDP. A halin yanzu QUIC yana ciki (Mun riga mun rubuta cewa akwai, kamar dai, nau'ikan QUIC guda biyu, masu ban sha'awa - kimanin. fassara). Kamar yadda aka nuna a hoto na 5, QUIC ana sanya shi ƙarƙashin HTTP/3 (a zahiri, HTTP/2 akan QUIC shine HTTP/3, wanda yanzu ana daidaita shi sosai). Yana maye gurbin HTTPS da yadudduka TCP ta amfani da UDP don samar da fakiti. QUIC kawai yana goyan bayan amintaccen canja wurin bayanai kamar yadda aka gina TLS a cikin QUIC.
Hoto 5: QUIC yana gudana ƙarƙashin HTTP/3, yana maye gurbin TLS, wanda a baya yana gudana ƙarƙashin HTTP/2.
Da ke ƙasa akwai dalilan da suka gamsar da mu don amfani da QUIC don ƙarawa TCP:
- 0-RTT haɗin kafa. QUIC yana ba da damar sake amfani da izini daga haɗin da suka gabata, yana rage adadin musafaha na tsaro. Nan gaba zai goyi bayan 0-RTT, amma har yanzu ana buƙatar musafin TCP ta hanyoyi uku.
- shawo kan toshewar HoL. HTTP/2 yana amfani da haɗin TCP ɗaya ga kowane abokin ciniki don haɓaka aiki, amma wannan na iya haifar da toshe HoL (shugaban-layi). QUIC yana sauƙaƙa ɗimbin yawa kuma yana isar da buƙatun ga aikace-aikacen da kansa.
- sarrafa cunkoso. QUIC yana zaune a layin aikace-aikacen, yana sauƙaƙa sabunta babban algorithm na sufuri wanda ke sarrafa aikawa dangane da sigogin cibiyar sadarwa (yawan asara ko RTT). Yawancin aiwatarwa na TCP suna amfani da algorithm , wanda ba shi da kyau ga zirga-zirgar latency-m. Algorithms da aka haɓaka kwanan nan kamar , mafi daidai ƙirar hanyar sadarwar da haɓaka latency. QUIC yana ba ku damar amfani da BBR da sabunta wannan algorithm kamar yadda ake amfani da shi. .
- sake cika asara. QUIC ya kira TLP guda biyu () kafin a kunna RTO - ko da asara ta zama sananne sosai. Wannan ya bambanta da aiwatar da TCP. TLP yana sake watsawa galibi fakiti na ƙarshe (ko sabon, idan akwai ɗaya) don haifar da cikawa cikin sauri. Gudanar da jinkirin wutsiya yana da amfani musamman ga yadda Uber ke tafiyar da hanyar sadarwar ta, wato ga gajere, kai tsaye, da canja wurin bayanai masu lanƙwasa.
- Mafi kyawun ACK. Tunda kowane fakiti yana da lambar jeri na musamman, babu matsala fakiti lokacin da aka sake tura su. Fakitin ACK kuma sun ƙunshi lokaci don sarrafa fakitin da samar da ACK a gefen abokin ciniki. Waɗannan fasalulluka suna tabbatar da cewa QUIC yana ƙididdige RTT daidai. ACK a cikin QUIC yana tallafawa har zuwa makada 256 , Taimakawa mai aikawa ya kasance mai juriya ga jujjuyawar fakiti da kuma amfani da ƙananan bytes a cikin tsari. Zaɓaɓɓen ACK () a cikin TCP baya magance wannan matsala a duk lokuta.
- haɗin kai hijira. Ana gano haɗin QUIC ta ID na 64-bit, don haka idan abokin ciniki ya canza adiresoshin IP, ana iya ci gaba da amfani da tsohon haɗin ID akan sabon adireshin IP ba tare da katsewa ba. Wannan al'ada ce ta gama gari don aikace-aikacen hannu inda mai amfani ke musanya tsakanin Wi-Fi da haɗin wayar salula.
Madadin zuwa QUIC
Mun yi la'akari da wasu hanyoyi don magance matsalar kafin zabar QUIC.
Abu na farko da muka gwada shi ne tura TPC PoPs (Points of Presence) don dakatar da haɗin TCP kusa da masu amfani. Mahimmanci, PoPs suna ƙare haɗin TCP tare da na'urar tafi da gidanka kusa da cibiyar sadarwar salula kuma suna wakiltar zirga-zirga zuwa ainihin ababen more rayuwa. Ta hanyar dakatar da TCP kusa, za mu iya yuwuwar rage RTT kuma mu tabbatar da cewa TCP ya fi dacewa da yanayin mara waya mai ƙarfi. Duk da haka, gwaje-gwajenmu sun nuna cewa mafi yawan RTT da asarar sun fito ne daga cibiyoyin sadarwar salula kuma amfani da PoPs ba ya samar da ingantaccen ingantaccen aiki.
Mun kuma duba daidaita sigogin TCP. Ƙirƙirar tarin TCP akan sabobin gefen mu yana da wahala saboda TCP yana da aiwatarwa daban-daban a cikin nau'ikan OS daban-daban. Yana da wuya a aiwatar da wannan kuma gwada saitunan cibiyar sadarwa daban-daban. Sanya TCP kai tsaye akan na'urorin hannu bai yiwu ba saboda rashin izini. Mafi mahimmanci, fasali irin su haɗin 0-RTT da ingantattun hasashen RTT suna da mahimmanci ga tsarin gine-ginen yarjejeniya, sabili da haka ba shi yiwuwa a sami fa'idodi masu mahimmanci ta hanyar daidaita TCP kadai.
A ƙarshe, mun ƙididdige ƙa'idodin tushen UDP da yawa waɗanda ke warware matsalar yawo na bidiyo-muna son ganin ko waɗannan ƙa'idodin za su taimaka a yanayinmu. Abin takaici, sun yi rashin ƙarfi a yawancin saitunan tsaro, kuma suna buƙatar ƙarin haɗin TCP don metadata da bayanin sarrafawa.
Bincikenmu ya nuna cewa QUIC ita ce watakila ƙa'idar da za ta iya taimakawa tare da matsalar zirga-zirgar Intanet, tare da la'akari da tsaro da aiki.
Haɗin QUIC cikin dandamali
Don samun nasarar shigar da QUIC da haɓaka aikin aikace-aikacen a cikin mahallin haɗin kai mara kyau, mun maye gurbin tsohuwar tari (HTTP/2 akan TLS/TCP) tare da ƙa'idar QUIC. Mun yi amfani da ɗakin karatu na cibiyar sadarwa daga , wanda ya ƙunshi asali, sigar Google na yarjejeniya - gQUIC. Hakanan ana inganta wannan aiwatarwa koyaushe don bin ƙayyadaddun ƙayyadaddun IETF.
Mun fara haɗa Cronet cikin ƙa'idodinmu na Android don ƙara tallafi ga QUIC. An gudanar da haɗin kai ta hanyar da za a rage farashin ƙaura gwargwadon yiwuwar. Maimakon gaba daya maye gurbin tsohon tarihin sadarwar da ke amfani da ɗakin karatu , mun haɗa Cronet A ƙarƙashin tsarin OkHttp API. Ta hanyar yin haɗin kai ta wannan hanya, mun guje wa canje-canje ga kiran cibiyar sadarwar mu (wanda ke amfani da su ) a matakin API.
Kama da tsarin na'urorin Android, mun aiwatar da Cronet cikin aikace-aikacen Uber akan iOS, tare da hana zirga-zirgar HTTP daga hanyar sadarwa. amfani da . Wannan abstraction, wanda Gidauniyar iOS ta bayar, yana sarrafa takamaiman bayanan URL na yarjejeniya kuma yana tabbatar da cewa zamu iya haɗa Cronet cikin aikace-aikacen mu na iOS ba tare da ƙimar ƙaura ba.
Ana kammala QUIC akan Ma'auni na Google Cloud
A gefen baya, ƙaddamarwar QUIC ana samar da ita ta hanyar daidaita kayan aikin Google Cloud Load, wanda ke amfani masu kai a cikin martani don tallafawa QUIC. Gabaɗaya, mai daidaitawa yana ƙara maɓallin alt-svc ga kowane buƙatun HTTP, kuma wannan ya riga ya tabbatar da tallafin QUIC don yankin. Lokacin da abokin ciniki na Cronet ya sami amsa HTTP tare da wannan taken, yana amfani da QUIC don buƙatun HTTP na gaba zuwa wannan yanki. Da zarar ma'auni ya kammala QUIC, kayan aikin mu suna aika wannan aikin a sarari akan HTTP2/TCP zuwa cibiyoyin bayanan mu.
Performance: Sakamako
Ayyukan fitarwa shine babban dalilin bincikenmu don ingantacciyar yarjejeniya. Da farko, mun ƙirƙiri tsayawa da don gano yadda QUIC za ta yi aiki a ƙarƙashin bayanan martaba na cibiyar sadarwa daban-daban. Don gwada aikin QUIC akan hanyoyin sadarwa na duniya, mun gudanar da gwaje-gwaje yayin tuki a kusa da New Delhi ta hanyar amfani da zirga-zirgar hanyar sadarwa da aka kwaikwayi daidai da kiran HTTP a cikin app ɗin fasinja.
Gwaji 1
Kayan aikin gwaji:
- gwada na'urorin Android tare da tarin OkHttp da Cronet don tabbatar da cewa mun ba da izinin zirga-zirgar HTTPS akan TCP da QUIC bi da bi;
- uwar garken kwaikwayo na tushen Java wanda ke aika nau'in rubutun HTTPS iri ɗaya a cikin martani da lodin na'urorin abokin ciniki don karɓar buƙatun daga gare su;
- Cloud proxies waɗanda suke a jiki kusa da Indiya don ƙare haɗin TCP da QUIC. Duk da yake don ƙarewar TCP mun yi amfani da wakili na baya akan , yana da wahala a sami buɗaɗɗen wakili na baya na QUIC. Mun gina wa kanmu wakili na baya ga QUIC ta amfani da ainihin tarin QUIC daga Chromium da shi a cikin chromium a matsayin tushen budewa.
Hoto 6. Rukunin gwajin titin TCP vs QUIC ya ƙunshi na'urorin Android tare da OkHttp da Cronet, alamun girgije don ƙare haɗin gwiwa, da uwar garken kwaikwayo.
Gwaji 2
Lokacin da Google ya samar da QUIC tare da , Mun yi amfani da kaya iri ɗaya, amma tare da gyare-gyare guda ɗaya: maimakon NGINX, mun ɗauki ma'auni na nauyin Google don dakatar da haɗin TCP da QUIC daga na'urori, da kuma hanyar zirga-zirgar HTTPS zuwa uwar garken kwaikwayo. Ana rarraba ma'auni a duk faɗin duniya, amma amfani da uwar garken PoP mafi kusa da na'urar (godiya ga yanayin ƙasa).
Hoto 7. A cikin gwaji na biyu, muna so mu kwatanta ƙarshen ƙarewar TCP da QUIC: ta amfani da Google Cloud da kuma amfani da wakili na girgije.
Sakamakon haka, wahayi da dama sun jira mu:
- ƙarewa ta hanyar PoP inganta aikin TCP. Tun da masu daidaitawa sun ƙare haɗin TCP kusa da masu amfani kuma an inganta su sosai, wannan yana haifar da ƙananan RTTs, wanda ke inganta aikin TCP. Kuma ko da yake QUIC ba ta da tasiri, har yanzu ta fi TCP ta fuskar rage jinkirin wutsiya (da kashi 10-30).
- wutsiyoyi suna shafar . Kodayake wakilinmu na QUIC ya fi na na'urorin (kimanin 50 ms mafi girma latency) fiye da ma'aunin ma'auni na Google, ya ba da irin wannan aikin - raguwar 15% a latency tare da raguwar 20% a cikin kashi 99 na TCP. Wannan yana nuna cewa canjin mil na ƙarshe shine ƙulli a cikin hanyar sadarwa.
Hoto 8: Sakamako daga gwaje-gwaje biyu sun nuna cewa QUIC ta fi TCP sosai.
Yaƙi zirga-zirga
An yi wahayi ta hanyar gwaji, mun aiwatar da tallafin QUIC a cikin aikace-aikacen mu na Android da iOS. Mun gudanar da gwajin A/B don tantance tasirin QUIC a cikin garuruwan da Uber ke aiki. Gabaɗaya, mun ga raguwar jinkirin wutsiya a duk yankuna biyu, masu aikin sadarwa da nau'in cibiyar sadarwa.
Hotunan da ke ƙasa suna nuna haɓakar kashi na wutsiyoyi (kashi 95 da 99) ta yankin macro da nau'ikan cibiyar sadarwa daban-daban - LTE, 3G, 2G.
Hoto 9. A cikin gwaje-gwajen yaƙi, QUIC ya fi TCP a cikin latency.
Ci gaba kawai
Wataƙila wannan shine farkon kawai - sakin QUIC a cikin samarwa ya ba da dama mai ban mamaki don inganta aikin aikace-aikacen a cikin cibiyoyin sadarwa masu ƙarfi da marasa ƙarfi, wato:
Ƙara ɗaukar hoto
Bayan nazarin aikin ƙa'idar akan zirga-zirga na gaske, mun ga cewa kusan kashi 80% na zaman sun yi nasarar amfani da QUIC don всех buƙatun, yayin da 15% na zaman suka yi amfani da haɗin QUIC da TCP. Muna ɗauka cewa haɗin ya kasance saboda lokacin ɗakin karatu na Cronet yana dawowa zuwa TCP, tun da ba zai iya bambanta tsakanin gazawar UDP na ainihi da yanayin cibiyar sadarwa mara kyau ba. A halin yanzu muna neman mafita ga wannan matsalar yayin da muke aiki don aiwatar da QUIC na gaba.
QUIC ingantawa
Traffic daga aikace-aikacen hannu yana da latency, amma ba mai saurin bandwidth ba. Hakanan, ana amfani da aikace-aikacen mu da farko akan cibiyoyin sadarwar salula. Dangane da gwaje-gwaje, jinkirin wutsiya har yanzu yana da girma duk da cewa ana amfani da wakili don ƙare TCP da QUIC kusa da masu amfani. Muna neman hanyoyin da za a inganta sarrafa cunkoso da inganta ingantaccen algorithms na dawo da asarar QUIC.
Tare da waɗannan da sauran haɓakawa da yawa, muna shirin haɓaka ƙwarewar mai amfani ba tare da la'akari da hanyar sadarwa da yanki ba, yin jigilar fakitin fakiti masu dacewa da sumul mafi dacewa a duk duniya.
source: www.habr.com