Tá prótacal QUIC thar a bheith suimiúil féachaint air, agus sin an fáth gur breá linn bheith ag scríobh faoi. Ach má bhí foilseacháin roimhe seo faoi QUIC níos mó de nádúr agus crua-earraí stairiúla (stair áitiúil, más maith leat), inniu táimid sásta aistriúchán de chineál eile a fhoilsiú - labhróimid faoi chur i bhfeidhm fíor an phrótacail in 2019. Thairis sin, nílimid ag caint faoi bhonneagar beag atá bunaithe i gharáiste mar a thugtar air, ach faoi Uber, a fheidhmíonn beagnach ar fud an domhain. Conas a tháinig innealtóirí na cuideachta ar an gcinneadh QUIC a úsáid i dtáirgeadh, conas a rinne siad na tástálacha agus an méid a chonaic siad tar éis é a rolladh amach i dtáirgeadh - faoi bhun an ghearrtha.
Is féidir cliceáil ar na pictiúir. Bain sult as léamh!
Tá scála domhanda ag Uber, is é sin 600 cathair láithreachta, agus braitheann an feidhmchlár go hiomlán ar an Idirlíon gan sreang ó níos mó ná 4500 oibreoir ceallacha i ngach ceann acu. Tá úsáideoirí ag súil go mbeidh an app ní hamháin go tapa, ach i bhfíor-am - chun é seo a bhaint amach, ní mór don app Uber latency íseal agus nasc an-iontaofa. Faraoir, ach an chairn nach n-éiríonn go maith leis i líonraí gan sreang dinimiciúla agus seans maith do chaillteanais. Thuigeamar sa chás seo go bhfuil baint dhíreach ag feidhmíocht íseal le feidhmiú TCP in eithne an chórais oibriúcháin.
Chun an fhadhb a réiteach, rinneamar iarratas , prótacal ilphléacsála cainéal nua-aimseartha a thugann níos mó smacht dúinn ar fheidhmíocht an phrótacail iompair. An grúpa oibre faoi láthair caighdeánaíonn QUIC mar .
Tar éis tástáil fhairsing, tháinig muid ar an gconclúid go mbeadh latencies eireaball níos ísle i gcomparáid le TCP mar thoradh ar QUIC a chur i bhfeidhm inár bhfeidhmchlár. Thugamar faoi deara laghdú sa raon 10-30% do thrácht HTTPS sna feidhmeanna tiománaithe agus paisinéirí. Thug QUIC rialú ceann go ceann dúinn ar phacáistí úsáideoirí freisin.
San Airteagal seo, roinnimid ár dtaithí maidir le TCP a bharrfheabhsú le haghaidh feidhmchláir Uber ag baint úsáide as stack a thacaíonn le QUIC.
An teicneolaíocht is déanaí: TCP
Inniu, is é TCP an prótacal iompair is mó a úsáidtear chun trácht HTTPS a sheachadadh ar an Idirlíon. Soláthraíonn TCP sruth iontaofa beart, rud a dhéileálann le plódú líonra agus le caillteanais sraitheanna nasc. Tá úsáid fhorleathan TCP do thrácht HTTPS mar gheall ar uileláithreacht an chéad cheann (tá TCP i mbeagnach gach OS), infhaighteacht ar fhormhór an bhonneagair (cosúil le comhardaitheoirí ualaigh, seachvótálaithe HTTPS agus CDNanna), agus feidhmiúlacht lasmuigh den bhosca atá ar fáil. ar an gcuid is mó de na hardáin agus na líonraí.
Úsáideann formhór na n-úsáideoirí ár n-aip agus iad ag dul, agus ní raibh folaigh eireaball TCP in aice le héilimh ár dtrácht HTTPS fíor-ama. Go simplí, tá taithí ag úsáideoirí ar fud an domhain air seo - léiríonn Fíor 1 moilleanna sna cathracha móra:
Figiúr 1: Athraíonn latency eireaball ar fud phríomhchathracha Uber.
Cé go raibh an fhoighne i líonraí Indiacha agus Brasaíle níos airde ná mar a bhí sna SA agus sa Ríocht Aontaithe, tá latency eireaball i bhfad níos airde ná an meánfhanachta. Agus tá sé seo fíor fiú do na Stáit Aontaithe agus an Ríocht Aontaithe.
TCP thar an fheidhmíocht aeir
Cruthaíodh TCP le haghaidh sreangaithe líonraí, is é sin, le béim ar naisc an-intuartha. Ach, Gan sreang tá a saintréithe agus a gcuid deacrachtaí féin ag líonraí. Ar an gcéad dul síos, tá líonraí gan sreang so-ghabhálach i leith caillteanais de bharr cur isteach agus maolú comharthaí. Mar shampla, tá líonraí Wi-Fi íogair do mhicreathonnta, bluetooth agus tonnta raidió eile. Fulaingíonn líonraí ceallacha caillteanas comhartha ((e) mar gheall ar fhrithchaitheamh/ionsú na comhartha ag réada agus foirgnimh, chomh maith le ó ó chomharsanacht . Mar thoradh air seo tá níos suntasaí (4-10 uair) agus níos éagsúla agus caillteanas paicéad i gcomparáid le nasc sreangaithe.
Chun luaineachtaí agus caillteanais bandaleithead a chomhrac, is gnách go n-úsáideann líonraí ceallacha maoláin mhóra le haghaidh pléasctha tráchta. D'fhéadfadh scuaine iomarcach a bheith mar thoradh air seo, rud a chiallaíonn moill níos faide. Go minic déileálann TCP leis an scuaine seo mar dhramhaíl mar gheall ar am istigh sínte, agus mar sin bíonn claonadh ag TCP an maolán a athsheoladh agus mar sin a líonadh. Tugtar an fhadhb seo ar (), agus tá sé seo an- Idirlíon nua-aimseartha.
Ar deireadh, athraíonn feidhmíocht líonra cheallacha de réir iompróra, réigiúin agus ama. I bhFíor 2, bhailigh muid moilleanna airmheánacha tráchta HTTPS thar chealla laistigh de raon 2 chiliméadar. Sonraí a bailíodh le haghaidh dhá oibreoir ceallacha móra i Deilí, India.... Mar a fheiceann tú, athraíonn an fheidhmíocht ó chill go cill. Chomh maith leis sin, tá táirgiúlacht oibreora amháin difriúil ó tháirgiúlacht an dara ceann. Tá tionchar aige seo ag fachtóirí ar nós patrúin iontrála líonra ag cur san áireamh am agus suíomh, soghluaisteacht úsáideoirí, chomh maith le bonneagar líonra ag cur san áireamh dlús túr agus cóimheas na gcineálacha líonra (LTE, 3G, etc.).
Fíor 2. Moill ar úsáid ga 2 km mar shampla. Deilí, an India.
Chomh maith leis sin, athraíonn feidhmíocht líonraí ceallacha le himeacht ama. Léiríonn Fíor 3 an fhoighne airmheánach de réir lá na seachtaine. Thugamar faoi deara freisin difríochtaí ar scála níos lú, laistigh de lá agus uair an chloig amháin.
Fíor 3. Is féidir le moilleanna eireaball athrú go mór idir laethanta, ach don oibreoir céanna.
Is cúis le gach ceann díobh thuas go bhfuil feidhmíocht TCP neamhéifeachtach i líonraí gan sreang. Sula bhíomar ag lorg roghanna eile seachas TCP, bhíomar ag iarraidh tuiscint bheacht a fhorbairt ar na pointí seo a leanas:
- An é TCP an príomh culprit taobh thiar de latencies eireaball inár n-iarratas?
- An mbíonn moilleanna suntasacha agus ilchineálacha ar thurais bhabhta (RTT) ag líonraí nua-aimseartha?
- Cén tionchar atá ag RTT agus ag caillteanas ar fheidhmíocht TCP?
Anailís Feidhmíochta TCP
Chun tuiscint a fháil ar an gcaoi a ndearnamar anailís ar fheidhmíocht TCP, déanaimis féachaint go tapa ar conas a aistríonn TCP sonraí ó sheoltóir go glacadóir. Ar dtús, bunaíonn an seoltóir nasc TCP, ag feidhmiú trí-bhealach : Seolann an seoltóir paicéad SYN, fanann sé ar phaicéad SYN-ACK ón nglacadóir, ansin cuireann sé paicéad ACK. Caitear an dara agus an tríú pas breise ag bunú an nasc TCP. Admhaíonn an faighteoir go bhfuarthas gach paicéad (ACK) chun seachadadh iontaofa a chinntiú.
Má chailltear paicéad nó ACK, athchuireann an seoltóir tar éis am istigh (RTO, ). Ríomhtar RTO go dinimiciúil bunaithe ar fhachtóirí éagsúla, amhail an mhoill RTT ionchais idir an seoltóir agus an faighteoir.
Fíor 4. Áiríonn malartú paicéid thar TCP/TLS meicníocht ath-tarchurtha.
Chun a chinneadh conas a d'fheidhmigh TCP inár bhfeidhmchláir, rinneamar monatóireacht ar phaicéid TCP ag baint úsáide as ar feadh seachtaine ar thrácht chomhrac ag teacht ó fhreastalaithe imeall Indiach. Ansin rinneamar anailís ar na naisc TCP ag baint úsáide as . Ina theannta sin, chruthaíomar feidhmchlár Android a sheolann trácht aithrise chuig freastalaí tástála, rud a dhéanann aithris ar fhíorthrácht a oiread agus is féidir. Dáileadh fóin chliste leis an bhfeidhmchlár seo ar roinnt fostaithe, a bhailigh logaí thar roinnt laethanta.
Bhí torthaí an dá thurgnamh comhsheasmhach lena chéile. Chonaiceamar latencies RTT ard; bhí luachanna eireaball beagnach 6 huaire níos airde ná an luach airmheán; tá meán uimhríochtúil na moilleanna níos mó ná 1 soicind. Bhí go leor nasc caillte, rud a chuir ar TCP 3,5% de na paicéid go léir a ath-tharchur. I limistéir phlódaithe mar aerfoirt agus stáisiúin traenach, chonaiceamar caillteanais 7%. Cuireann na torthaí seo amhras ar an eagna traidisiúnta a úsáidtear i líonraí ceallacha laghdú suntasach a dhéanamh ar chaillteanais ar an leibhéal iompair. Seo thíos na torthaí tástála ón bhfeidhmchlár “insamhlóir”:
Méadracht líonra
Luachanna
RTT, milleasoicindí [50%,75%, 95%,99%]
[350, 425, 725, 2300]
Éagsúlacht RTT, soicind
Ar an meán ~1,2 s
Caillteanas paicéad ar naisc éagobhsaí
Meán ~3.5% (7% i limistéir ró-ualaithe)
Bhí caillteanas paicéid amháin ar a laghad ag beagnach leath de na naisc seo, agus an chuid is mó acu paicéid SYN agus SYN-ACK. Úsáideann an chuid is mó d'fheidhmiúcháin TCP luach RTO 1 soicind do phaicéid SYN, rud a mhéadaíonn go heaspónantúil le haghaidh caillteanais ina dhiaidh sin. D’fhéadfadh go n-ardóidh amanna lódála feidhmchlár toisc go nglacfaidh TCP níos faide chun naisc a bhunú.
I gcás paicéid sonraí, laghdaítear go mór le luachanna arda RTO úsáid úsáideach an líonra i gcás caillteanais neamhbhuan i líonraí gan sreang. Fuaireamar amach gurb é an meán-am atarchuir thart ar 1 soicind le moill eireaball beagnach 30 soicind. Ba iad na folaigh arda seo ag an leibhéal TCP ba chúis le tréimhsí ama agus athiarratais HTTPS, rud a mhéadaigh foighne líonra agus neamhéifeachtúlacht.
Cé go raibh an 75ú peircintíl de RTT tomhaiste thart ar 425 ms, bhí an 75ú peircintíl do TCP beagnach 3 shoicind. Tugann sé seo le tuiscint gur ghlac TCP 7-10 pas chun sonraí a tharchur go rathúil mar gheall ar an gcaillteanas. D’fhéadfadh sé seo a bheith mar thoradh ar ríomh neamhéifeachtúil RTO, ar neamhábaltacht TCP freagairt go tapa ar chaillteanas sa fhuinneog agus neamhéifeachtúlacht an algartam rialaithe plódaithe, nach ndéanann idirdhealú idir caillteanais agus caillteanais gan sreang de bharr brú tráchta líonra. Seo thíos torthaí na dtástálacha caillteanais TCP:
staitisticí caillteanas paicéad TCP
Luach
Céatadán na nasc a raibh caillteanas 1 paicéad ar a laghad ann
45%
Céatadán na nasc ar cailleadh iad le linn socrú an naisc
30%
Céatadán na nasc le caillteanais le linn malartú sonraí
76%
Dáileadh moilleanna ar atarchur, soicind [50%, 75%, 95%,99%] [1, 2.8, 15, 28]
Dáileadh líon na n-ath-tarchurtha do phaicéad amháin nó do mhír TCP
[1,3,6,7]
Feidhm QUIC
Ar dtús forbartha ag Google, is prótacal iompair nua-aimseartha il-snáithe é QUIC a ritheann ar bharr an UDP. Tá QUIC istigh faoi láthair (scríobhamar cheana go bhfuil, mar a bhí, dhá leagan de QUIC, aisteach – thart. aistritheoir). Mar a léirítear i bhFíor 5, cuirtear QUIC faoi HTTP/3 (go deimhin, is é HTTP/2 ar bharr QUIC ná HTTP/3, atá á chaighdeánú go dian anois). Tagann sé in ionad na sraitheanna HTTPS agus TCP go páirteach trí UDP a úsáid chun paicéid a fhoirmiú. Ní thacaíonn QUIC ach le haistriú sonraí slán toisc go bhfuil TLS ionsuite go hiomlán i QUIC.
Fíor 5: Ritheann QUIC faoi HTTP/3, in ionad TLS, a rith faoi HTTP/2 roimhe seo.
Seo thíos na cúiseanna a chuir ina luí orainn QUIC a úsáid le haghaidh aimpliú TCP:
- Bunú nasc 0-RTT. Ligeann QUIC údaruithe ó naisc roimhe seo a athúsáid, rud a laghdóidh líon na croitheadh láimhe slándála. Amach anseo tacóidh sé le 0-RTT, ach beidh croitheadh láimhe TCP trí bhealach fós ag teastáil.
- blocáil HoL a shárú. Úsáideann HTTP/2 nasc TCP amháin in aghaidh an chliaint chun feidhmíocht a fheabhsú, ach d’fhéadfadh blocáil HoL (ceann líne) a bheith mar thoradh air seo. Déanann QUIC ilphléacsáil a shimpliú agus seachadann sé iarratais chuig an bhfeidhmchlár go neamhspleách.
- rialú brú tráchta. Cónaíonn QUIC ag an gciseal feidhmchláir, rud a fhágann go bhfuil sé níos éasca an príomh-algartam iompair a rialaíonn seoladh bunaithe ar pharaiméadair líonra (líon na gcaillteanas nó RTT) a nuashonrú. Úsáideann formhór na bhfeidhmiúchán TCP an algartam , nach bhfuil optamach do thrácht atá íogair ó thaobh latency. Is maith le halgartaim a forbraíodh le déanaí , múnla níos cruinne a dhéanamh ar an líonra agus latency a bharrfheabhsú. Ligeann QUIC duit BBR a úsáid agus an algartam seo a nuashonrú de réir mar a úsáidtear é. .
- athsholáthar na gcaillteanas. Glaonn QUIC ar dhá TLP () sula gcuirtear tús leis an RTO - fiú nuair a bhíonn na caillteanais an-suntasach. Tá sé seo difriúil ó chur i bhfeidhm TCP. Ath-tarchuireann TLP an paicéad deireanach go príomha (nó an ceann nua, má tá ceann ann) chun athsholáthar tapa a spreagadh. Tá sé an-úsáideach déileáil le moilleanna eireaball don chaoi a n-oibríonn Uber a líonra, eadhon le haghaidh aistrithe sonraí gearra, treallacha agus latency-íogair.
- ACK optamaithe. Ós rud é go bhfuil seicheamh uimhir uathúil ag gach paicéad, níl aon fhadhb ann paicéid nuair a ath-tarchuirtear iad. Bíonn am i bpacáistí ACK freisin chun an paicéad a phróiseáil agus ACK a ghiniúint ar thaobh an chliaint. Cinntíonn na gnéithe seo go ríomhann QUIC RTT ar bhealach níos cruinne. Tacaíonn ACK in QUIC le suas le 256 banna , ag cabhrú leis an seoltóir a bheith níos athléimní maidir le suaitheadh paicéad agus níos lú beart a úsáid sa phróiseas. Roghnach ACK () i TCP nach réitíonn an fhadhb seo i ngach cás.
- imirce nasc. Aithnítear naisc QUIC le haitheantas 64-giotán, mar sin má athraíonn cliant seoltaí IP, is féidir an sean-aitheantas naisc a úsáid ar an seoladh IP nua gan aon bhriseadh. Is cleachtas an-choitianta é seo le haghaidh feidhmchláir shoghluaiste ina n-aistríonn an t-úsáideoir idir Wi-Fi agus naisc cheallacha.
Roghanna eile seachas QUIC
Rinneamar machnamh ar chur chuige eile chun an fhadhb a réiteach sular roghnaigh muid QUIC.
Ba é an chéad rud a rinneamar iarracht ná TPC PoPs (Pointeanna Láithreachta) a imscaradh chun naisc TCP a fhoirceannadh níos gaire d'úsáideoirí. Go bunúsach, cuireann PoPanna deireadh le nasc TCP le gléas soghluaiste níos gaire don líonra ceallacha agus seachfhreastalaíonn siad an trácht ar ais go dtí an bonneagar bunaidh. Trí deireadh a chur le TCP níos dlúithe, is féidir linn an RTT a laghdú agus a chinntiú go bhfuil TCP níos freagraí do thimpeallacht dinimiciúil gan sreang. Mar sin féin, léirigh ár dturgnaimh go dtagann an chuid is mó den RTT agus den chaillteanas ó líonraí ceallacha agus ní sholáthraíonn úsáid PoPanna feabhas suntasach ar fheidhmíocht.
D'fhéachamar freisin ar pharaiméadair TCP a thiúnadh. Bhí sé deacair stack TCP a bhunú ar ár bhfreastalaithe imeall ilchineálach toisc go bhfuil feidhmiúcháin dhifriúla ag TCP thar leaganacha éagsúla OS. Bhí sé deacair é seo a chur i bhfeidhm agus cumraíochtaí líonra éagsúla a thástáil. Níorbh fhéidir TCP a chumrú go díreach ar ghléasanna soghluaiste mar gheall ar easpa ceadanna. Níos tábhachtaí fós, tá gnéithe ar nós naisc 0-RTT agus réamh-mheastachán feabhsaithe RTT ríthábhachtach d’ailtireacht an phrótacail, agus dá bhrí sin ní féidir tairbhí suntasacha a bhaint amach trí TCP a oiriúnú amháin.
Ar deireadh, rinneamar measúnú ar roinnt prótacail UDP-bhunaithe a dhéanann fabhtcheartú ar shruthú físeáin - theastaigh uainn féachaint an gcabhródh na prótacail seo lenár gcás. Ar an drochuair, bhí siad in easnamh go mór i go leor socruithe slándála, agus bhí gá le nasc TCP breise le haghaidh meiteashonraí agus faisnéis rialaithe.
Tá sé léirithe ag ár dtaighde gurb é QUIC, b'fhéidir, an t-aon phrótacal amháin a d'fhéadfadh cabhrú le fadhb na tráchta Idirlín, agus slándáil agus feidhmíocht á gcur san áireamh.
Comhtháthú QUIC isteach san ardán
Chun QUIC a leabú go rathúil agus feidhmíocht feidhmchláir a fheabhsú i dtimpeallachtaí laga nascachta, chuireamar prótacal QUIC in ionad an tseanstack (HTTP/2 thar TLS/TCP). Bhaineamar úsáid as an leabharlann líonra de , ina bhfuil an bunleagan, Google den phrótacal - gQUIC. Tá an cur chun feidhme seo á fheabhsú i gcónaí freisin chun an tsonraíocht IETF is déanaí a leanúint.
Rinneamar Cronet a chomhtháthú lenár n-aipeanna Android ar dtús chun tacaíocht a chur leis do QUIC. Rinneadh an comhtháthú ar bhealach a laghdódh costais imirce a oiread agus ab fhéidir. In ionad an tseanstack líonraithe a d'úsáid an leabharlann a athsholáthar go hiomlán , ní mór dúinn Cronet a chomhtháthú FAOI chreat OkHttp API. Tríd an gcomhtháthú a dhéanamh ar an mbealach seo, sheachaineamar athruithe ar ár nglaonna líonra (a úsáideann ) ag an leibhéal API.
Cosúil leis an gcur chuige maidir le feistí Android, chuireamar Cronet i bhfeidhm ar apps Uber ar iOS, ag idircheapadh trácht HTTP ón líonra ag baint úsáide as . Láimhseálann an t-astarraingt seo, arna sholáthar ag Fondúireacht iOS, sonraí URL prótacail-shonracha agus cinntíonn sé gur féidir linn Cronet a chomhtháthú inár bhfeidhmchláir iOS gan costais imirce suntasacha.
QUIC a chomhlánú ar Google Cloud Balancers
Ar an taobh inneall, soláthraíonn bonneagar cothromaithe Google Cloud Load, a úsáideann ceanntásca i bhfreagraí chun tacú le QUIC. Go ginearálta, cuireann an cothromóir ceanntásc alt-svc le gach iarratas HTTP, agus bailíochtaíonn sé seo tacaíocht QUIC don fhearann cheana féin. Nuair a fhaigheann cliant Cronet freagra HTTP leis an gceanntásc seo, úsáideann sé QUIC le haghaidh iarratais HTTP ina dhiaidh sin chuig an bhfearann sin. Nuair a chríochnaíonn an comhardóir an QUIC, seolann ár mbonneagar an gníomh seo go sainráite thar HTTP2/TCP chuig ár n-ionaid sonraí.
Feidhmíocht: Torthaí
Is é feidhmíocht aschuir an phríomhchúis lenár gcuardach ar phrótacal níos fearr. Ar dtús, chruthaigh muid seastán le le fáil amach conas a iompróidh QUIC faoi phróifílí éagsúla líonra. Chun feidhmíocht QUIC ar líonraí fíordhomhanda a thástáil, rinneamar turgnaimh agus muid ag tiomáint timpeall New Delhi ag baint úsáide as trácht líonra aithrise atá an-chosúil le glaonna HTTP san aip paisinéirí.
Turgnamh 1
Trealamh don turgnamh:
- feistí Android a thástáil le stoic OkHttp agus Cronet chun a chinntiú go gceadóimid trácht HTTPS thar TCP agus QUIC faoi seach;
- freastalaí aithrise bunaithe ar Java a sheolann an cineál céanna ceanntásca HTTPS i bhfreagraí agus a lódálann gléasanna cliant chun iarratais a fháil uathu;
- seachfhreastalaí scamall atá suite go fisiciúil gar don India chun naisc TCP agus QUIC a fhoirceannadh. Le haghaidh foirceannadh TCP úsáideamar seachfhreastalaí droim ar ais , bhí sé deacair seachfhreastalaí droim ar ais foinse oscailte a aimsiú do QUIC. Thógamar seachfhreastalaí droim ar ais do QUIC sinn féin ag baint úsáide as an mbunstack QUIC ó Chromium agus Cróimiam é mar fhoinse oscailte.
Fíor 6. Bhí gléasanna Android le OkHttp agus Cronet, seachvótálaithe néil chun naisc a fhoirceannadh, agus freastalaí aithrise i sraith tástála bóthair TCP vs QUIC.
Turgnamh 2
Nuair a chuir Google QUIC ar fáil le , d'úsáideamar an fardal céanna, ach le modhnú amháin: in ionad NGINX, ghlacamar cothromóirí ualach Google chun naisc TCP agus QUIC a fhoirceannadh ó fheistí, chomh maith le trácht HTTPS a threorú chuig an bhfreastalaí aithrise. Déantar cothromóirí a dháileadh ar fud an domhain, ach bain úsáid as an bhfreastalaí PoP is gaire don fheiste (a bhuíochas le geolocation).
Fíor 7. Sa dara turgnamh, bhíomar ag iarraidh comparáid a dhéanamh idir latency críochnaithe TCP agus QUIC: ag baint úsáide as Google Cloud agus ag baint úsáide as ár seachfhreastalaí scamall.
Mar thoradh air sin, bhí roinnt nochtadh ag fanacht linn:
- foirceannadh trí PoP feidhmíocht TCP feabhsaithe. Ós rud é go gcuireann cothromóirí deireadh le naisc TCP níos gaire d'úsáideoirí agus go bhfuil siad optamaithe go mór, bíonn RTTanna níos ísle mar thoradh air seo, rud a fheabhsaíonn feidhmíocht TCP. Agus cé gur lú an tionchar a bhí ar QUIC, d’fheidhmigh sé níos fearr fós le TCP i dtéarmaí latency eireaball a laghdú (de 10-30 faoin gcéad).
- eireabaill bhfuil tionchar . Cé go raibh ár seachfhreastalaí QUIC níos faide ó na gléasanna (thart ar latency 50 ms níos airde) ná cothromóirí ualaigh Google, sheachaid sé feidhmíocht den chineál céanna - laghdú 15% ar latency i gcomparáid le laghdú 20% ar an 99ú peircintíl do TCP. Tugann sé seo le tuiscint go bhfuil an t-aistriú míle deiridh ina bhac sa líonra.
Fíor 8: Léiríonn torthaí ó dhá thurgnamh go sáraíonn QUIC TCP go suntasach.
Trácht a chomhrac
Spreagtha ag turgnamh, tá tacaíocht QUIC curtha i bhfeidhm againn inár bhfeidhmchláir Android agus iOS. Rinneamar tástáil A/B chun tionchar QUIC ar na cathracha ina bhfeidhmíonn Uber a chinneadh. Go ginearálta, chonaiceamar laghdú suntasach ar mhoilleanna eireaball ar fud an dá réigiún, oibreoirí teileachumarsáide agus cineál líonra.
Léiríonn na graif thíos na feabhsuithe céatadáin ar eireabaill (95 agus 99 peircintíl) de réir macra-réigiúin agus cineálacha éagsúla líonra - LTE, 3G, 2G.
Fíor 9. I dtástálacha catha, d'fheidhmigh QUIC níos fearr ná TCP i dtéarmaí latency.
Ar aghaidh amháin
B’fhéidir nach bhfuil anseo ach an tús – chuir scaoileadh QUIC isteach sa táirgeadh deiseanna iontacha chun feidhmíocht feidhmchláir a fheabhsú i líonraí cobhsaí agus éagobhsaí araon, eadhon:
Clúdach méadaithe
Tar éis dúinn anailís a dhéanamh ar fheidhmíocht an phrótacail ar fhíorthrácht, chonaiceamar gur éirigh le thart ar 80% de na seisiúin úsáid as QUIC le haghaidh Gach iarratais, agus bhain 15% de na seisiúin úsáid as meascán de QUIC agus TCP. Glacaimid leis gurb é is cúis leis an gcomhcheangal ná gur tháinig teorainn ama leabharlainne Cronet siar go TCP, ós rud é nach féidir idirdhealú a dhéanamh idir fíor-theipeanna an CDU agus drochchoinníollacha líonra. Táimid ag féachaint ar réiteach ar an bhfadhb seo faoi láthair agus muid ag obair i dtreo QUIC a chur i bhfeidhm ina dhiaidh sin.
leas iomlán a bhaint QUIC
Tá trácht ó aipeanna móibíleacha íogair ó thaobh na haise de, ach níl sé íogair ó thaobh bandaleithead. Chomh maith leis sin, úsáidtear ár bhfeidhmchláir go príomha ar líonraí ceallacha. Bunaithe ar thurgnaimh, tá latencies eireaball ard fós cé go n-úsáidtear seachfhreastalaí chun deireadh a chur le TCP agus QUIC gar d'úsáideoirí. Táimid gníomhach ag lorg bealaí chun feabhas a chur ar bhainistíocht ar phlódú agus feabhas a chur ar éifeachtúlacht halgartaim aisghabhála caillteanais QUIC.
Leis na feabhsuithe seo agus roinnt feabhsuithe eile, tá sé beartaithe againn eispéireas an úsáideora a fheabhsú beag beann ar líonra agus ar réigiún, rud a fhágann go mbeidh iompar paicéad áisiúil agus gan uaim níos inrochtana ar fud an domhain.
Foinse: will.com