Mae protocol QUIC yn hynod ddiddorol i'w wylio, a dyna pam rydyn ni wrth ein bodd yn ysgrifennu amdano. Ond pe bai cyhoeddiadau blaenorol am QUIC yn fwy o natur a chaledwedd hanesyddol (hanes lleol, os mynnwch), heddiw rydym yn hapus i gyhoeddi cyfieithiad o fath gwahanol - byddwn yn siarad am gymhwysiad gwirioneddol y protocol yn 2019. Ar ben hynny, nid ydym yn sôn am seilwaith bach wedi'i leoli mewn garej fel y'i gelwir, ond am Uber, sy'n gweithredu bron ledled y byd. Sut y daeth peirianwyr y cwmni i'r penderfyniad i ddefnyddio QUIC wrth gynhyrchu, sut y gwnaethant gynnal y profion a'r hyn a welsant ar ôl ei gyflwyno wrth gynhyrchu - o dan y toriad.
Gellir clicio ar y lluniau. Mwynhewch ddarllen!
Mae gan Uber raddfa fyd-eang, sef 600 o ddinasoedd presenoldeb, ac ym mhob un mae'r cymhwysiad yn dibynnu'n llwyr ar Rhyngrwyd diwifr gan fwy na 4500 o weithredwyr cellog. Mae defnyddwyr yn disgwyl i'r app fod nid yn unig yn gyflym, ond mewn amser real - i gyflawni hyn, mae angen hwyrni isel a chysylltiad dibynadwy iawn ar yr app Uber. Ysywaeth, ond y pentwr nid yw'n gwneud yn dda mewn rhwydweithiau diwifr deinamig sy'n dueddol o golli. Sylweddolom fod perfformiad isel yn yr achos hwn yn uniongyrchol gysylltiedig â gweithrediadau TCP mewn cnewyllyn systemau gweithredu.
I ddatrys y broblem, gwnaethom gais , protocol amlblecsio sianeli modern sy'n rhoi mwy o reolaeth i ni dros berfformiad y protocol trafnidiaeth. Y gweithgor ar hyn o bryd yn safoni QUIC fel .
Ar ôl profion helaeth, daethom i'r casgliad y byddai gweithredu QUIC yn ein cais yn arwain at guddfannau cynffon is o gymharu â TCP. Gwelsom ostyngiad yn yr ystod o 10-30% ar gyfer traffig HTTPS yn y ceisiadau gyrwyr a theithwyr. Rhoddodd QUIC hefyd reolaeth pen-i-ben i ni dros becynnau defnyddwyr.
Yn yr erthygl hon, rydym yn rhannu ein profiad o optimeiddio TCP ar gyfer cymwysiadau Uber gan ddefnyddio pentwr sy'n cefnogi QUIC.
Y dechnoleg ddiweddaraf: TCP
Heddiw, TCP yw'r protocol trafnidiaeth a ddefnyddir fwyaf ar gyfer darparu traffig HTTPS ar y Rhyngrwyd. Mae TCP yn darparu llif dibynadwy o beit, gan felly ymdopi â thagfeydd rhwydwaith a cholledion haenau cyswllt. Mae'r defnydd eang o TCP ar gyfer traffig HTTPS oherwydd hollbresenoldeb y cyntaf (mae bron pob OS yn cynnwys TCP), argaeledd ar y rhan fwyaf o seilwaith (fel cydbwyswyr llwyth, dirprwy HTTPS a CDNs), ac ymarferoldeb y tu allan i'r bocs sydd ar gael ar bron y rhan fwyaf o lwyfannau a rhwydweithiau.
Mae'r rhan fwyaf o ddefnyddwyr yn defnyddio ein ap wrth fynd, ac nid oedd cuddni cynffon TCP yn agos at ofynion ein traffig HTTPS amser real. Yn syml, mae defnyddwyr ledled y byd wedi profi hyn - mae Ffigur 1 yn dangos oedi mewn dinasoedd mawr:
Ffigur 1: Mae hwyrni cynffon yn amrywio ar draws prif ddinasoedd Uber.
Er bod cuddni mewn rhwydweithiau Indiaidd a Brasil yn uwch nag yn yr UD a'r DU, mae hwyrni cynffon yn sylweddol uwch na'r hwyrni cyfartalog. Ac mae hyn yn wir hyd yn oed ar gyfer yr Unol Daleithiau a'r DU.
TCP dros y perfformiad aer
Crëwyd TCP ar gyfer gwifrau rhwydweithiau, hynny yw, gyda phwyslais ar gysylltiadau rhagweladwy iawn. Fodd bynnag, diwifr mae gan rwydweithiau eu nodweddion a'u hanawsterau eu hunain. Yn gyntaf, mae rhwydweithiau diwifr yn agored i golledion oherwydd ymyrraeth a gwanhau signal. Er enghraifft, mae rhwydweithiau Wi-Fi yn sensitif i ficrodonnau, bluetooth a thonnau radio eraill. Mae rhwydweithiau cellog yn dioddef o golli signal () o ganlyniad i adlewyrchiad/amsugno'r signal gan wrthrychau ac adeiladau, yn ogystal ag oddi wrth o gymdogol . Mae hyn yn arwain at fwy arwyddocaol (4-10 gwaith) a mwy amrywiol a cholli pecyn o'i gymharu â chysylltiad â gwifrau.
Er mwyn brwydro yn erbyn amrywiadau a cholledion lled band, mae rhwydweithiau cellog fel arfer yn defnyddio byfferau mawr ar gyfer ffrwydradau traffig. Gall hyn arwain at giwio gormodol, sy'n golygu oedi hirach. Yn aml iawn mae TCP yn trin y ciwio hwn fel gwastraff oherwydd goramser estynedig, felly mae TCP yn tueddu i gyfnewid a thrwy hynny lenwi'r byffer. Gelwir y broblem hon yn (), ac mae hyn yn iawn Rhyngrwyd modern.
Yn olaf, mae perfformiad rhwydwaith cellog yn amrywio yn ôl cludwr, rhanbarth ac amser. Yn Ffigur 2, casglwyd oedi canolrifol traffig HTTPS ar draws celloedd o fewn ystod 2-cilometr. Data a gasglwyd ar gyfer dau brif weithredwr cellog yn Delhi, India. Fel y gwelwch, mae perfformiad yn amrywio o gell i gell. Hefyd, mae cynhyrchiant un gweithredwr yn wahanol i gynhyrchiant yr ail. Mae hyn yn cael ei ddylanwadu gan ffactorau megis patrymau mynediad rhwydwaith gan ystyried amser a lleoliad, symudedd defnyddwyr, yn ogystal â seilwaith rhwydwaith gan ystyried dwysedd twr a chymhareb y mathau o rwydwaith (LTE, 3G, ac ati).
Ffigur 2. Oedi wrth ddefnyddio radiws 2 km fel enghraifft. Delhi, India.
Hefyd, mae perfformiad rhwydweithiau cellog yn amrywio dros amser. Mae Ffigur 3 yn dangos y hwyrni canolrif yn ôl diwrnod yr wythnos. Gwelsom hefyd wahaniaethau ar raddfa lai, o fewn un diwrnod ac awr.
Ffigur 3. Gall oedi cynffon amrywio'n sylweddol rhwng diwrnodau, ond ar gyfer yr un gweithredwr.
Mae pob un o'r uchod yn achosi perfformiad TCP i fod yn aneffeithiol mewn rhwydweithiau diwifr. Fodd bynnag, cyn chwilio am ddewisiadau amgen i TCP, roeddem am ddatblygu dealltwriaeth fanwl gywir ar y pwyntiau canlynol:
- ai TCP yw'r prif droseddwr y tu ôl i guddfannau cynffon yn ein ceisiadau?
- A oes oedi sylweddol ac amrywiol ar deithiau crwn (RTT) ar rwydweithiau modern?
- Beth yw effaith RTT a cholled ar berfformiad TCP?
Dadansoddiad Perfformiad TCP
Er mwyn deall sut y gwnaethom ddadansoddi perfformiad TCP, gadewch i ni edrych yn gyflym ar sut mae TCP yn trosglwyddo data o anfonwr i dderbynnydd. Yn gyntaf, mae'r anfonwr yn sefydlu cysylltiad TCP, gan berfformio tair ffordd : Mae'r anfonwr yn anfon pecyn SYN, yn aros am becyn SYN-ACK gan y derbynnydd, yna'n anfon pecyn ACK. Mae ail a thrydydd tocyn ychwanegol yn cael ei wario ar sefydlu'r cysylltiad TCP. Mae'r derbynnydd yn cydnabod derbyn pob pecyn (ACK) i sicrhau dosbarthiad dibynadwy.
Os bydd pecyn neu ACK yn cael ei golli, mae'r anfonwr yn ail-drosglwyddo ar ôl terfyn amser (RTO, ). Cyfrifir RTO yn ddeinamig ar sail amrywiol ffactorau, megis yr oedi RTT disgwyliedig rhwng yr anfonwr a'r derbynnydd.
Ffigur 4. Mae cyfnewid pecynnau dros TCP/TLS yn cynnwys mecanwaith ailddarlledu.
Er mwyn pennu sut y perfformiodd TCP yn ein cymwysiadau, fe wnaethom fonitro defnyddio pecynnau TCP am wythnos ar draffig ymladd yn dod o weinyddion ymyl Indiaidd. Yna fe wnaethom ddadansoddi'r cysylltiadau TCP gan ddefnyddio . Yn ogystal, rydym wedi creu cymhwysiad Android sy'n anfon traffig wedi'i efelychu i weinydd prawf, gan ddynwared traffig go iawn cymaint â phosib. Dosbarthwyd ffonau clyfar gyda'r cais hwn i sawl gweithiwr, a gasglodd logiau dros sawl diwrnod.
Roedd canlyniadau'r ddau arbrawf yn gyson â'i gilydd. Gwelsom hwyrni RTT uchel; roedd gwerthoedd cynffon bron 6 gwaith yn uwch na'r gwerth canolrifol; mae cyfartaledd rhifyddol yr oedi yn fwy nag 1 eiliad. Roedd llawer o gysylltiadau yn golledus, gan achosi i TCP ail-drosglwyddo 3,5% o'r holl becynnau. Mewn ardaloedd tagfeydd fel meysydd awyr a gorsafoedd trenau, gwelsom golledion o 7%. Mae'r canlyniadau hyn yn bwrw amheuaeth ar y doethineb confensiynol a ddefnyddir mewn rhwydweithiau cellog lleihau colledion ar lefel trafnidiaeth yn sylweddol. Isod mae canlyniadau profion y cymhwysiad “efelychydd”:
Metrigau rhwydwaith
Y gwerthoedd
RTT, milieiliadau [50%,75%, 95%,99%]
[350, 425, 725, 2300]
Gwahaniad RTT, eiliadau
Ar gyfartaledd ~1,2 s
Colli pecyn ar gysylltiadau ansefydlog
Cyfartaledd ~3.5% (7% mewn ardaloedd gorlwytho)
Roedd bron i hanner y cysylltiadau hyn wedi colli o leiaf un pecyn, y rhan fwyaf ohonynt yn becynnau SYN a SYN-ACK. Mae'r rhan fwyaf o weithrediadau TCP yn defnyddio gwerth RTO o 1 eiliad ar gyfer pecynnau SYN, sy'n cynyddu'n esbonyddol ar gyfer colledion dilynol. Gall amseroedd llwytho ceisiadau gynyddu oherwydd bod TCP yn cymryd mwy o amser i sefydlu cysylltiadau.
Yn achos pecynnau data, mae gwerthoedd RTO uchel yn lleihau'n fawr y defnydd defnyddiol o'r rhwydwaith ym mhresenoldeb colledion dros dro mewn rhwydweithiau diwifr. Canfuom fod yr amser ailddarlledu cyfartalog tua 1 eiliad gydag oedi cynffon o bron i 30 eiliad. Achosodd yr hwyrni uchel hyn ar lefel TCP seibiannau ac ail-geisiadau HTTPS, gan gynyddu ymhellach hwyrni ac aneffeithlonrwydd rhwydwaith.
Er bod y 75ain canradd o RTT a fesurwyd oddeutu 425 ms, roedd y 75ain ganradd ar gyfer TCP bron yn 3 eiliad. Mae hyn yn awgrymu bod y golled wedi achosi i TCP gymryd 7-10 tocyn i drosglwyddo data yn llwyddiannus. Gall hyn fod o ganlyniad i gyfrifo RTO aneffeithlon, anallu TCP i ymateb yn gyflym i golled yn y ffenestr ac aneffeithlonrwydd yr algorithm rheoli tagfeydd, nad yw'n gwahaniaethu rhwng colledion a cholledion di-wifr oherwydd tagfeydd rhwydwaith. Isod mae canlyniadau profion colli TCP:
Ystadegau colli pecynnau TCP
Gwerth
Canran y cysylltiadau sydd wedi colli o leiaf 1 pecyn
45%
Canran y cysylltiadau â cholledion yn ystod gosod y cysylltiad
30%
Canran y cysylltiadau â cholledion yn ystod cyfnewid data
76%
Dosbarthiad oedi wrth aildrosglwyddo, eiliadau [50%, 75%, 95%,99%] [1, 2.8, 15, 28]
Dosbarthiad nifer yr ailddarllediadau ar gyfer un pecyn neu segment TCP
[1,3,6,7]
Cymhwyso QUIC
Wedi'i ddatblygu'n wreiddiol gan Google, mae QUIC yn brotocol trafnidiaeth fodern aml-edau sy'n rhedeg ar ben y CDU. Ar hyn o bryd mae QUIC i mewn (ysgrifennon ni eisoes fod dwy fersiwn o QUIC, fel petai, yn chwilfrydig – tua. cyfieithydd). Fel y dangosir yn Ffigur 5, gosodir QUIC o dan HTTP/3 (mewn gwirionedd, HTTP/2 ar ben QUIC yw HTTP/3, sydd bellach yn cael ei safoni'n ddwys). Mae'n disodli'r haenau HTTPS a TCP yn rhannol trwy ddefnyddio CDU i ffurfio pecynnau. Dim ond trosglwyddo data diogel y mae QUIC yn ei gefnogi gan fod TLS wedi'i gynnwys yn llawn yn QUIC.
Ffigur 5: Mae QUIC yn rhedeg o dan HTTP/3, gan ddisodli TLS, a oedd yn rhedeg o dan HTTP/2 yn flaenorol.
Isod mae'r rhesymau a'n darbwyllodd i ddefnyddio QUIC ar gyfer ymhelaethu TCP:
- Sefydliad cysylltiad 0-RTT. Mae QUIC yn caniatáu ailddefnyddio awdurdodiadau o gysylltiadau blaenorol, gan leihau nifer yr ysgwyd llaw diogelwch. Yn y dyfodol yn cefnogi 0-RTT, ond bydd angen ysgwyd llaw TCP tair ffordd o hyd.
- goresgyn blocio HoL. Mae HTTP/2 yn defnyddio un cysylltiad TCP fesul cleient i wella perfformiad, ond gall hyn arwain at rwystro HoL (pennawd). Mae QUIC yn symleiddio amlblecsio ac yn cyflwyno ceisiadau i'r rhaglen yn annibynnol.
- rheoli tagfeydd. Mae QUIC yn gorwedd ar haen y cais, gan ei gwneud hi'n haws diweddaru'r prif algorithm trafnidiaeth sy'n rheoli anfon yn seiliedig ar baramedrau rhwydwaith (nifer y colledion neu RTT). Mae'r rhan fwyaf o weithrediadau TCP yn defnyddio'r algorithm , nad yw'n optimaidd ar gyfer traffig sy'n sensitif i hwyrni. algorithmau a ddatblygwyd yn ddiweddar fel , modelu'r rhwydwaith yn fwy cywir a gwneud y gorau o hwyrni. Mae QUIC yn caniatáu ichi ddefnyddio BBR a diweddaru'r algorithm hwn wrth iddo gael ei ddefnyddio. .
- ailgyflenwi colledion. Mae QUIC yn galw dau TLP () cyn i'r RTO gael ei sbarduno - hyd yn oed pan fo'r colledion yn amlwg iawn. Mae hyn yn wahanol i weithrediadau TCP. Mae TLP yn ail-drosglwyddo'r pecyn olaf yn bennaf (neu'r un newydd, os oes un) i sbarduno ailgyflenwi cyflym. Mae trin oedi cynffon yn arbennig o ddefnyddiol ar gyfer y ffordd y mae Uber yn gweithredu ei rwydwaith, sef ar gyfer trosglwyddiadau data byr, achlysurol, sy'n sensitif i hwyrni.
- ACK wedi'i optimeiddio. Gan fod gan bob pecyn rif dilyniant unigryw, nid oes problem pecynnau pan fyddant yn cael eu hail-drosglwyddo. Mae pecynnau ACK hefyd yn cynnwys amser i brosesu'r pecyn a chynhyrchu ACK ar ochr y cleient. Mae'r nodweddion hyn yn sicrhau bod QUIC yn cyfrifo RTT yn fwy cywir. Mae ACK in QUIC yn cefnogi hyd at 256 o fandiau , gan helpu'r anfonwr i fod yn fwy gwydn i siffrwd pecynnau a defnyddio llai o beit yn y broses. ACK dewisol () yn TCP ddim yn datrys y broblem hon ym mhob achos.
- mudo cysylltiad. Mae cysylltiadau QUIC yn cael eu nodi gan ID 64-bit, felly os yw cleient yn newid cyfeiriadau IP, gellir parhau i ddefnyddio'r hen ID cysylltiad ar y cyfeiriad IP newydd heb ymyrraeth. Mae hwn yn arfer cyffredin iawn ar gyfer cymwysiadau symudol lle mae'r defnyddiwr yn newid rhwng Wi-Fi a chysylltiadau cellog.
Dewisiadau eraill yn lle QUIC
Fe wnaethom ystyried dulliau amgen o ddatrys y broblem cyn dewis QUIC.
Y peth cyntaf i ni geisio oedd defnyddio TPC PoPs (Pwyntiau Presenoldeb) i derfynu cysylltiadau TCP yn nes at ddefnyddwyr. Yn y bôn, mae PoPs yn terfynu cysylltiad TCP â dyfais symudol yn agosach at y rhwydwaith cellog ac yn dirprwyo'r traffig yn ôl i'r seilwaith gwreiddiol. Trwy derfynu TCP yn agosach, gallwn o bosibl leihau'r RTT a sicrhau bod TCP yn fwy ymatebol i amgylchedd diwifr deinamig. Fodd bynnag, mae ein harbrofion wedi dangos bod y rhan fwyaf o'r RTT a'r golled yn dod o rwydweithiau cellog ac nid yw'r defnydd o PoPs yn darparu gwelliant sylweddol mewn perfformiad.
Edrychwyd hefyd ar diwnio paramedrau TCP. Roedd yn anodd sefydlu pentwr TCP ar ein gweinyddwyr ymyl heterogenaidd oherwydd bod gan TCP weithrediadau gwahanol ar draws gwahanol fersiynau OS. Roedd yn anodd gweithredu hyn a phrofi gwahanol ffurfweddiadau rhwydwaith. Nid oedd yn bosibl ffurfweddu TCP yn uniongyrchol ar ddyfeisiau symudol oherwydd diffyg caniatâd. Yn bwysicach fyth, mae nodweddion megis cysylltiadau 0-RTT a gwell rhagfynegiad RTT yn hanfodol i bensaernïaeth y protocol, ac felly mae'n amhosibl cyflawni buddion sylweddol trwy diwnio TCP yn unig.
Yn olaf, fe wnaethom werthuso nifer o brotocolau seiliedig ar CDU sy'n datrys problemau ffrydio fideo - roeddem am weld a fyddai'r protocolau hyn yn helpu yn ein hachos ni. Yn anffodus, roeddent yn ddiffygiol iawn mewn llawer o leoliadau diogelwch, ac roedd angen cysylltiad TCP ychwanegol arnynt hefyd ar gyfer metadata a gwybodaeth reoli.
Mae ein hymchwil wedi dangos efallai mai QUIC yw'r unig brotocol a all helpu gyda phroblem traffig Rhyngrwyd, tra'n ystyried diogelwch a pherfformiad.
Integreiddio QUIC i'r platfform
Er mwyn sefydlu QUIC yn llwyddiannus a gwella perfformiad cymhwysiad mewn amgylcheddau cysylltedd gwael, fe wnaethom ddisodli'r hen bentwr (HTTP/2 dros TLS/TCP) gyda'r protocol QUIC. Defnyddiasom lyfrgell y rhwydwaith o , sy'n cynnwys fersiwn wreiddiol, Google o'r protocol - gQUIC. Mae'r gweithrediad hwn hefyd yn cael ei wella'n gyson i ddilyn y fanyleb IETF ddiweddaraf.
Fe wnaethom integreiddio Cronet i'n apps Android yn gyntaf i ychwanegu cefnogaeth i QUIC. Cyflawnwyd integreiddio mewn ffordd a oedd yn lleihau costau mudo cymaint â phosibl. Yn hytrach na disodli'n llwyr yr hen stac rhwydweithio a ddefnyddiodd y llyfrgell , rydym wedi integreiddio Cronet UNDER y fframwaith API OkHttp. Trwy wneud yr integreiddio fel hyn, gwnaethom osgoi newidiadau i'n galwadau rhwydwaith (a ddefnyddir gan ) ar lefel API.
Yn debyg i'r dull ar gyfer dyfeisiau Android, fe wnaethom weithredu Cronet i apiau Uber ar iOS, gan ryng-gipio traffig HTTP o'r rhwydwaith gan ddefnyddio . Mae'r tyniad hwn, a ddarperir gan y iOS Foundation, yn trin data URL protocol-benodol ac yn sicrhau y gallwn integreiddio Cronet i'n cymwysiadau iOS heb gostau mudo sylweddol.
Cwblhau QUIC ar Google Cloud Balancers
Ar yr ochr gefn, darperir cwblhau QUIC gan seilwaith cydbwyso Llwyth Google Cloud, sy'n defnyddio penawdau mewn ymatebion i gefnogi QUIC. Yn gyffredinol, mae'r balancer yn ychwanegu pennawd alt-svc i bob cais HTTP, ac mae hyn eisoes yn dilysu cefnogaeth QUIC ar gyfer y parth. Pan fydd cleient Cronet yn derbyn ymateb HTTP gyda'r pennawd hwn, mae'n defnyddio QUIC ar gyfer ceisiadau HTTP dilynol i'r parth hwnnw. Unwaith y bydd y balanswr wedi cwblhau'r QUIC, mae ein seilwaith yn anfon y cam gweithredu hwn yn benodol dros HTTP2/TCP i'n canolfannau data.
Perfformiad: Canlyniadau
Perfformiad allbwn yw'r prif reswm dros ein chwiliad am well protocol. I ddechrau, fe wnaethon ni greu stondin gyda i ddarganfod sut bydd QUIC yn ymddwyn o dan wahanol broffiliau rhwydwaith. Er mwyn profi perfformiad QUIC ar rwydweithiau byd go iawn, cynhaliom arbrofion wrth yrru o amgylch New Delhi gan ddefnyddio traffig rhwydwaith efelychiedig yn debyg iawn i alwadau HTTP yn yr ap teithwyr.
Arbrawf 1
Offer ar gyfer yr arbrawf:
- profi dyfeisiau Android gyda staciau OkHttp a Cronet i sicrhau ein bod yn caniatáu traffig HTTPS dros TCP a QUIC yn y drefn honno;
- gweinydd efelychu seiliedig ar Java sy'n anfon yr un math o benawdau HTTPS mewn ymatebion ac yn llwytho dyfeisiau cleient i dderbyn ceisiadau ganddynt;
- dirprwyon cwmwl sydd wedi'u lleoli'n gorfforol yn agos at India i derfynu cysylltiadau TCP a QUIC. Tra ar gyfer terfynu TCP fe wnaethom ddefnyddio procsi gwrthdro ymlaen , roedd yn anodd dod o hyd i ddirprwy ffynhonnell agored wrthdroi ar gyfer QUIC. Fe wnaethom adeiladu dirprwy wrthdro ar gyfer QUIC ein hunain gan ddefnyddio'r pentwr QUIC sylfaenol o Chromium a mae'n gromiwm fel ffynhonnell agored.
Ffigur 6. Roedd y gyfres prawf ffordd TCP vs QUIC yn cynnwys dyfeisiau Android gyda OkHttp a Cronet, dirprwyon cwmwl ar gyfer terfynu cysylltiadau, a gweinydd efelychu.
Arbrawf 2
Pan wnaeth Google sicrhau bod QUIC ar gael gyda , fe wnaethom ddefnyddio'r un rhestr eiddo, ond gydag un addasiad: yn lle NGINX, fe wnaethom gymryd balanswyr llwyth Google i derfynu cysylltiadau TCP a QUIC o ddyfeisiau, yn ogystal â llwybr traffig HTTPS i'r gweinydd efelychu. Mae balanswyr yn cael eu dosbarthu ledled y byd, ond defnyddiwch y gweinydd PoP sydd agosaf at y ddyfais (diolch i geolocation).
Ffigur 7. Yn yr ail arbrawf, roeddem am gymharu hwyrni cwblhau TCP a QUIC: defnyddio Google Cloud a defnyddio ein dirprwy cwmwl.
O ganlyniad, roedd sawl datguddiad yn ein disgwyl:
- terfynu trwy PoP gwell perfformiad TCP. Gan fod balanswyr yn terfynu cysylltiadau TCP yn agosach at ddefnyddwyr a'u bod wedi'u optimeiddio'n fawr, mae hyn yn arwain at RTTs is, sy'n gwella perfformiad TCP. Ac er bod llai o effaith ar QUIC, roedd yn dal i berfformio'n well na TCP o ran lleihau hwyrni cynffon (o 10-30 y cant).
- cynffonnau yn cael eu heffeithio . Er bod ein dirprwy QUIC ymhellach o'r dyfeisiau (tua 50 ms yn hwyr yn uwch) na balanswyr llwyth Google, fe gyflawnodd berfformiad tebyg - gostyngiad o 15% mewn hwyrni yn erbyn gostyngiad o 20% yn y 99ain ganradd ar gyfer TCP. Mae hyn yn awgrymu bod y trawsnewidiad milltir olaf yn dagfa yn y rhwydwaith.
Ffigur 8: Mae canlyniadau dau arbrawf yn dangos bod QUIC yn perfformio'n sylweddol well na TCP.
Brwydro yn erbyn traffig
Wedi'n hysbrydoli gan arbrofi, rydym wedi rhoi cymorth QUIC ar waith yn ein cymwysiadau Android ac iOS. Fe wnaethom gynnal profion A/B i ganfod effaith QUIC yn y dinasoedd lle mae Uber yn gweithredu. Yn gyffredinol, gwelsom ostyngiad sylweddol mewn oedi cynffon ar draws y ddau ranbarth, gweithredwyr telathrebu a math o rwydwaith.
Mae'r graffiau isod yn dangos y gwelliannau canrannol mewn cynffonau (95 a 99 canradd) yn ôl macro-ranbarth a gwahanol fathau o rwydwaith - LTE, 3G, 2G.
Ffigur 9. Mewn profion brwydr, perfformiodd QUIC yn well na TCP o ran hwyrni.
Dim ond ymlaen
Efallai mai dim ond y dechrau yw hyn - mae rhyddhau QUIC i gynhyrchu wedi darparu cyfleoedd anhygoel i wella perfformiad cymhwysiad mewn rhwydweithiau sefydlog ac ansefydlog, sef:
Mwy o sylw
Ar ôl dadansoddi perfformiad y protocol ar draffig go iawn, gwelsom fod tua 80% o sesiynau wedi defnyddio QUIC yn llwyddiannus ar gyfer holl ceisiadau, tra bod 15% o sesiynau yn defnyddio cyfuniad o QUIC a TCP. Tybiwn mai'r rheswm am y cyfuniad yw bod terfyn amser llyfrgell Cronet yn dychwelyd i TCP, gan na all wahaniaethu rhwng gwir fethiannau CDU ac amodau rhwydwaith gwael. Ar hyn o bryd rydym yn edrych i mewn i ateb i'r broblem hon wrth i ni weithio tuag at weithredu QUIC wedi hynny.
Optimeiddio QUIC
Mae traffig o apiau symudol yn sensitif i hwyrni, ond nid yw'n sensitif i led band. Hefyd, defnyddir ein cymwysiadau yn bennaf ar rwydweithiau cellog. Yn seiliedig ar arbrofion, mae cuddni cynffon yn dal yn uchel er eu bod yn defnyddio dirprwy i derfynu TCP a QUIC yn agos at ddefnyddwyr. Rydym wrthi'n chwilio am ffyrdd o wella rheolaeth tagfeydd a gwella effeithlonrwydd algorithmau adfer colled QUIC.
Gyda'r rhain a nifer o welliannau eraill, rydym yn bwriadu gwella profiad y defnyddiwr waeth beth fo'r rhwydwaith a'r rhanbarth, gan wneud cludiant pecyn cyfleus a di-dor yn fwy hygyrch ledled y byd.
Ffynhonnell: hab.com