QUIC протоколын қарау өте қызықты, сондықтан біз бұл туралы жазғанды жақсы көреміз. Бірақ егер QUIC туралы бұрынғы жарияланымдар тарихи (жергілікті тарих, қаласаңыз) табиғат пен аппараттық құрал болса, бүгін біз басқа түрдегі аударманы жариялауға қуаныштымыз - біз 2019 жылы хаттаманың нақты қолданылуы туралы айтатын боламыз. Оның үстіне, біз гараж деп аталатын шағын инфрақұрылым туралы емес, бүкіл әлемде жұмыс істейтін Uber туралы айтып отырмыз. Компанияның инженерлері QUIC-ті өндірісте қолдану туралы шешімге қалай келді, олар сынақтарды қалай жүргізді және оны өндіріске шығарғаннан кейін не көрді - кесіндіден төмен.
Суреттер басуға болады. Оқудан ләззат алыңыз!
Uber-тің жаһандық ауқымы бар, атап айтқанда 600 қала бар, олардың әрқайсысында қолданба толығымен 4500-ден астам ұялы байланыс операторларының сымсыз Интернетіне сүйенеді. Пайдаланушылар қолданбаның жай ғана жылдам емес, нақты уақыт режимінде болуын күтеді – бұған қол жеткізу үшін Uber қолданбасына аз кідіріс және өте сенімді байланыс қажет. Өкінішке орай, стек динамикалық және жоғалуға бейім сымсыз желілерде жақсы жұмыс істемейді. Бұл жағдайда нашар өнімділік операциялық жүйе ядроларындағы TCP іске асырумен тікелей байланысты екенін түсіндік.
Мәселені шешу үшін біз өтініш жасадық , тасымалдау протоколының өнімділігін көбірек бақылауға мүмкіндік беретін заманауи арна мультиплексирлеу протоколы. Қазіргі уақытта жұмыс тобы ретінде QUIC стандарттайды .
Кең ауқымды тестілеуден кейін біз QUIC-ті қолданбамызға енгізу TCP-мен салыстырғанда кідірістердің төмендеуіне әкеледі деген қорытындыға келдік. Біз жүргізуші мен жолаушы қолданбаларында HTTPS трафигі үшін 10-30% диапазонында қысқаруды байқадық. QUIC сонымен қатар бізге пайдаланушы пакеттерін бақылауды қамтамасыз етті.
Бұл мақалада біз QUIC қолдайтын стек арқылы Uber қолданбалары үшін TCP оңтайландыру тәжірибесімен бөлісеміз.
Соңғы технология: TCP
Бүгінгі таңда TCP Интернетте HTTPS трафигін жеткізу үшін ең көп қолданылатын тасымалдау протоколы болып табылады. TCP сенімді байттар ағынын қамтамасыз етеді, осылайша желінің кептелісін және байланыс деңгейінің жоғалуын жеңеді. TCP протоколының HTTPS трафигі үшін кеңінен қолданылуы біріншісінің барлық жерде болуымен (әрбір ОЖ-да дерлік TCP бар), көптеген инфрақұрылымдарда (жүктеме теңестірушілер, HTTPS проксилері және CDNs сияқты) қолжетімділігімен және қол жетімді қордан тыс функционалдылықпен байланысты. платформалар мен желілердің көпшілігінде дерлік.
Көптеген пайдаланушылар біздің қолданбаны жолда пайдаланады және TCP кідірістері біздің нақты уақыттағы HTTPS трафигіміздің талаптарына еш жақын болмады. Қарапайым тілмен айтқанда, бүкіл әлемдегі пайдаланушылар мұны бастан кешірді - 1-суретте ірі қалалардағы кешігулер көрсетілген:
1-сурет: Uber-тің негізгі қалаларында кідіріс уақыты өзгереді.
Үнді және Бразилия желілеріндегі кідіріс АҚШ пен Ұлыбританияға қарағанда жоғары болғанымен, кідіріс орташа кідірістен айтарлықтай жоғары. Бұл тіпті АҚШ пен Ұлыбританияға да қатысты.
Ауа арқылы TCP өнімділігі
TCP үшін жасалған сымды желілер, яғни жоғары болжамды сілтемелерге баса назар аудара отырып. Дегенмен, сымсыз желілердің өзіндік ерекшеліктері мен қиындықтары бар. Біріншіден, сымсыз желілер кедергілер мен сигналдың әлсіреуі салдарынан жоғалтуларға бейім. Мысалы, Wi-Fi желілері микротолқындарға, bluetooth және басқа радиотолқындарға сезімтал. Ұялы желілер сигнал жоғалуынан зардап шегеді () сигналдың объектілер мен ғимараттардың шағылысуына/жұтылуына байланысты, сондай-ақ көршіден . Бұл маңыздырақ (4-10 есе) және әртүрлілікке әкеледі және сымды қосылыммен салыстырғанда пакеттердің жоғалуы.
Өткізу қабілеттілігінің ауытқуларымен және жоғалтуларымен күресу үшін ұялы желілер әдетте трафик жарылыстары үшін үлкен буферлерді пайдаланады. Бұл шамадан тыс кезекке әкелуі мүмкін, бұл ұзағырақ кідірістерді білдіреді. Көбінесе TCP бұл кезекті ұзартылған күту уақытына байланысты ысырап ретінде қарастырады, сондықтан TCP жіберуге бейім және осылайша буферді толтырады. Бұл мәселе ретінде белгілі (), және бұл өте заманауи интернет.
Соңында, ұялы желі өнімділігі тасымалдаушыға, аймаққа және уақытқа байланысты өзгереді. 2-суретте біз 2 километрлік диапазондағы ұяшықтар арасындағы HTTPS трафигінің медианалық кідірістерін жинадық. Деректер Делидегі, Үндістандағы екі негізгі ұялы байланыс операторлары үшін жиналды. Көріп отырғаныңыздай, өнімділік ұяшықтан ұяшыққа өзгереді. Сондай-ақ бір оператордың өнімділігі екіншісінің өнімділігінен ерекшеленеді. Бұған уақыт пен орынды ескере отырып желіге кіру үлгілері, пайдаланушының ұтқырлығы, сондай-ақ мұнара тығыздығы мен желі түрлерінің арақатынасы (LTE, 3G және т.б.) ескерілетін желілік инфрақұрылым сияқты факторлар әсер етеді.
Сурет 2. Мысал ретінде 2 км радиусты пайдаланатын кідіріс. Дели, Үндістан.
Сондай-ақ, ұялы желілердің өнімділігі уақыт бойынша өзгеріп отырады. 3-суретте аптаның күні бойынша орташа кідіріс көрсетілген. Біз сондай-ақ бір күн мен сағат ішінде кішірек ауқымда айырмашылықтарды байқадық.
Сурет 3. Құйрық кідірістері күндер арасында айтарлықтай өзгеруі мүмкін, бірақ бір оператор үшін.
Жоғарыда айтылғандардың барлығы сымсыз желілерде TCP өнімділігінің тиімсіз болуына әкеледі. Дегенмен, TCP баламаларын іздемес бұрын, біз келесі тармақтар бойынша нақты түсінікті дамытқымыз келді:
- TCP біздің қолданбалардағы кешігулердің негізгі кінәсі ме?
- Заманауи желілерде айтарлықтай және әр түрлі айналу кешігулері (RTT) бар ма?
- RTT және жоғалтудың TCP өнімділігіне әсері қандай?
TCP өнімділігін талдау
TCP өнімділігін қалай талдағанымызды түсіну үшін TCP деректерді жіберушіден қабылдаушыға қалай тасымалдайтынын жылдам қарастырайық. Біріншіден, жіберуші үш жақты орындай отырып, TCP қосылымын орнатады : Жіберуші SYN пакетін жібереді, қабылдаушыдан SYN-ACK пакетін күтеді, содан кейін ACK пакетін жібереді. Қосымша екінші және үшінші өту TCP қосылымын орнатуға жұмсалады. Сенімді жеткізуді қамтамасыз ету үшін алушы әрбір пакетті (ACK) алғанын растайды.
Егер пакет немесе ACK жоғалса, жіберуші күту уақытынан кейін қайта жібереді (RTO, ). RTO жіберуші мен алушы арасындағы күтілетін RTT кідірісі сияқты әртүрлі факторларға негізделген динамикалық түрде есептеледі.
Сурет 4. TCP/TLS арқылы пакеттік алмасу қайта жіберу механизмін қамтиды.
TCP қолданбаларымызда қалай жұмыс істейтінін анықтау үшін біз TCP пакеттерін пайдаланып бақыладық Үндістанның шеткі серверлерінен келетін жауынгерлік трафик бойынша бір апта бойы. Содан кейін біз TCP қосылымдарын қолданып талдадық . Сонымен қатар, біз нақты трафикті мүмкіндігінше имитациялай отырып, сынақ серверіне эмуляцияланған трафикті жіберетін Android қолданбасын жасадық. Бұл қосымшасы бар смартфондар бірнеше күн бойы журналдарды жинаған бірнеше қызметкерге таратылды.
Екі эксперименттің нәтижелері бір-бірімен сәйкес болды. Біз жоғары RTT кідірістерін көрдік; соңғы мәндер орташа мәннен шамамен 6 есе жоғары болды; кідірістердің арифметикалық орташа мәні 1 секундтан асады. Көптеген қосылымдар жоғалып кетті, бұл TCP барлық пакеттердің 3,5% қайта жіберуіне себеп болды. Әуежайлар мен вокзалдар сияқты кептеліс аймақтарында біз 7% шығын көрдік. Бұл нәтижелер ұялы желілерде қолданылатын кәдімгі даналыққа күмән келтіреді тасымалдау деңгейінде жоғалтуларды айтарлықтай азайтады. Төменде «симулятор» қолданбасының сынақ нәтижелері берілген:
Желілік көрсеткіштер
Мәндер
RTT, миллисекундтар [50%,75%, 95%,99%]
[350, 425, 725, 2300]
RTT дивергенциясы, секунд
Орташа алғанда ~1,2 с
Тұрақсыз қосылымдарда пакет жоғалуы
Орташа ~3.5% (шамадан тыс жүктелген аймақтарда 7%)
Бұл қосылымдардың жартысына жуығында кем дегенде бір пакет жоғалуы болды, олардың көпшілігі SYN және SYN-ACK пакеттері. Көптеген TCP іске асырулары SYN пакеттері үшін 1 секундтық RTO мәнін пайдаланады, ол кейінгі жоғалтулар үшін экспоненциалды түрде артады. Қолданбаны жүктеу уақыттары TCP қосылымдарын орнату ұзағырақ болуына байланысты артуы мүмкін.
Деректер пакеттері жағдайында жоғары RTO мәндері сымсыз желілерде өтпелі жоғалтулар болған кезде желіні пайдалы пайдалануды айтарлықтай төмендетеді. Біз орташа ретрансляция уақыты шамамен 1 секунд, ал 30 секундқа жуық кешіктірілгенін анықтадық. TCP деңгейіндегі бұл жоғары кідіріс HTTPS күту уақытын және қайта сұрауларды тудырып, желінің кідірісі мен тиімсіздігін одан әрі арттырды.
Өлшенген RTT-нің 75-процентильі 425 мс шамасында болғанымен, TCP үшін 75-процентиль шамамен 3 секунд болды. Бұл жоғалту TCP деректерді сәтті жіберу үшін 7-10 өтуді қажет ететінін көрсетеді. Бұл тиімсіз RTO есептеуінің салдары болуы мүмкін, TCP жоғалтуға тез жауап бере алмауы терезеде және сымсыз жоғалтулар мен желінің кептелуіне байланысты жоғалтуларды ажыратпайтын кептелістерді басқару алгоритмінің тиімсіздігі. Төменде TCP жоғалту сынақтарының нәтижелері берілген:
TCP пакетін жоғалту статистикасы
құн
Кемінде 1 пакет жоғалуы бар қосылымдардың пайызы
45%
Қосылымды орнату кезінде жоғалған қосылымдардың пайызы
30%
Деректер алмасу кезіндегі жоғалулары бар қосылыстардың пайызы
76%
Ретрансляциядағы кідірістерді бөлу, секундтар [50%, 75%, 95%,99%] [1, 2.8, 15, 28]
Бір пакет немесе TCP сегменті үшін қайта жіберулер санын бөлу
[1,3,6,7]
QUIC қолданбасы
Бастапқыда Google әзірлеген, QUIC - UDP үстінде жұмыс істейтін көп ағынды заманауи тасымалдау протоколы. Қазіргі уақытта QUIC жұмыс істейді (біз QUIC-тің қызықты екі нұсқасы бар екенін жазғанбыз – шамамен. аудармашы). 5-суретте көрсетілгендей, QUIC HTTP/3 астында орналастырылған (шын мәнінде, QUIC үстіндегі HTTP/2 HTTP/3 болып табылады, ол қазір қарқынды түрде стандартталады). Ол пакеттерді қалыптастыру үшін UDP пайдалану арқылы HTTPS және TCP қабаттарын ішінара ауыстырады. QUIC тек қауіпсіз деректерді тасымалдауды қолдайды, өйткені TLS QUIC ішіне толығымен енгізілген.
5-сурет: QUIC HTTP/3 астында жұмыс істейді, бұрын HTTP/2 астында жұмыс істейтін TLS ауыстырады.
Төменде TCP күшейту үшін QUIC қолдануға бізді сендірген себептер келтірілген:
- 0-RTT қосылымын орнату. QUIC қауіпсіздік қол алысуларының санын азайта отырып, алдыңғы қосылымдардағы рұқсаттарды қайта пайдалануға мүмкіндік береді. Болашақта 0-RTT қолдайды, бірақ үш жақты TCP қол алысу әлі де қажет болады.
- HoL бұғаттауын жеңу. HTTP/2 өнімділікті жақсарту үшін әр клиентке бір TCP қосылымын пайдаланады, бірақ бұл HoL (жолдың басты) блоктауына әкелуі мүмкін. QUIC мультиплекстеуді жеңілдетеді және қолданбаға сұрауларды дербес жеткізеді.
- кептелісті бақылау. QUIC қолданбалы деңгейде орналасады, бұл желі параметрлері (шығындар саны немесе RTT) негізінде жіберуді басқаратын негізгі тасымалдау алгоритмін жаңартуды жеңілдетеді. Көптеген TCP іске асыру алгоритмді пайдаланады , бұл кешігуге сезімтал трафик үшін оңтайлы емес. сияқты жақында жасалған алгоритмдер , желіні дәлірек модельдеңіз және күту уақытын оңтайландырыңыз. QUIC BBR-ді пайдалануға және осы алгоритмді қолданылған сайын жаңартуға мүмкіндік береді. .
- жоғалтуларды толықтыру. QUIC екі TLP шақырады () RTO іске қосылғанға дейін - тіпті жоғалтулар айтарлықтай байқалса да. Бұл TCP енгізулерінен ерекшеленеді. TLP жылдам толтыруды бастау үшін негізінен соңғы пакетті (немесе бар болса, жаңасын) қайта жібереді. Ұзақ мерзімді кешігулерді өңдеу әсіресе Uber желісін басқару әдісі үшін пайдалы, атап айтқанда қысқа, кездейсоқ және кідіріске сезімтал деректерді тасымалдау үшін.
- оңтайландырылған ACK. Әрбір пакетте бірегей реттік нөмірі болғандықтан, ешқандай проблема жоқ пакеттер қайта жіберілген кезде. ACK пакеттерінде пакетті өңдеуге және клиент жағында ACK құруға да уақыт бар. Бұл мүмкіндіктер QUIC RTT дәлірек есептеуін қамтамасыз етеді. QUIC ішіндегі ACK 256 жолақты қолдайды , жіберушіге пакеттерді араластыруға икемді болуға және процесте аз байтты пайдалануға көмектесу. Таңдамалы ACK () TCP-де бұл мәселені барлық жағдайда шешпейді.
- қосылымды тасымалдау. QUIC қосылымдары 64-бит идентификаторымен анықталады, сондықтан клиент IP мекенжайларын өзгертсе, ескі қосылым идентификаторы үзіліссіз жаңа IP мекенжайында қолданылуын жалғастыра алады. Бұл пайдаланушы Wi-Fi және ұялы байланыс арасында ауысатын мобильді қосымшалар үшін өте кең таралған тәжірибе.
QUIC баламалары
Біз QUIC таңдамас бұрын мәселені шешудің балама тәсілдерін қарастырдық.
Біз тырысқан бірінші нәрсе TCP қосылымдарын пайдаланушыларға жақынырақ тоқтату үшін TPC PoPs (болу нүктелері) орналастыру болды. Негізінде, PoP ұялы желіге жақын мобильді құрылғымен TCP қосылымын тоқтатады және трафикті бастапқы инфрақұрылымға қайта прокси арқылы береді. TCP мүмкіндігін жақынырақ тоқтату арқылы біз RTT мүмкіндігін азайта аламыз және TCP динамикалық сымсыз ортаға көбірек жауап беретініне көз жеткізе аламыз. Дегенмен, біздің эксперименттер RTT және жоғалтулардың көпшілігі ұялы желілерден келетінін және PoP пайдалану өнімділікті айтарлықтай жақсартуды қамтамасыз етпейтінін көрсетті.
Біз сондай-ақ TCP параметрлерін реттеуді қарастырдық. Біртекті емес шеткі серверлерімізде TCP стекін орнату қиын болды, себебі TCP операциялық жүйенің әртүрлі нұсқаларында әр түрлі іске асыруға ие. Мұны жүзеге асыру және әртүрлі желі конфигурацияларын тексеру қиын болды. Тікелей мобильді құрылғыларда TCP конфигурациялау рұқсаттардың болмауына байланысты мүмкін болмады. Ең бастысы, 0-RTT қосылымдары және жақсартылған RTT болжамы сияқты мүмкіндіктер хаттаманың архитектурасы үшін өте маңызды, сондықтан тек TCP баптау арқылы айтарлықтай артықшылықтарға қол жеткізу мүмкін емес.
Соңында, біз бейне ағынының ақауларын жойатын UDP негізіндегі бірнеше хаттамаларды бағаладық — біз бұл протоколдар біздің жағдайда көмектесетінін білгіміз келді. Өкінішке орай, олар көптеген қауіпсіздік параметрлерінде айтарлықтай жетіспеді, сонымен қатар метадеректер мен басқару ақпараты үшін қосымша TCP қосылымын қажет етті.
Біздің зерттеуіміз QUIC қауіпсіздік пен өнімділікті ескере отырып, Интернет-трафик мәселесін шешуге көмектесетін жалғыз протокол екенін көрсетті.
Платформаға QUIC интеграциясы
QUIC-ті сәтті енгізу және нашар байланыс орталарында қолданба өнімділігін жақсарту үшін біз ескі стекті (TLS/TCP арқылы HTTP/2) QUIC протоколымен ауыстырдық. Біз желілік кітапхананы қолдандық -дан , онда протоколдың түпнұсқасы, Google нұсқасы бар - gQUIC. Бұл енгізу сонымен қатар соңғы IETF спецификациясына сәйкес үнемі жетілдіріліп отырады.
QUIC қолдауын қосу үшін алдымен Cronet қолданбасын Android қолданбаларына біріктірдік. Интеграция көші-қон шығындарын барынша азайтатындай етіп жүзеге асырылды. Кітапхананы пайдаланған ескі желілік стекті толығымен ауыстырудың орнына , біз Cronet-ті OkHttp API құрылымының астына біріктірдік. Интеграцияны осылай жасау арқылы біз желілік қоңырауларымызға өзгерістер енгізуден аулақ болдық (оларды ) API деңгейінде.
Android құрылғыларына арналған тәсілге ұқсас, біз желіден HTTP трафигін ұстай отырып, iOS жүйесіндегі Uber қолданбаларына Cronet енгіздік. қолдану арқылы . iOS Foundation ұсынған бұл абстракция протоколға тән URL деректерін өңдейді және Cronet қолданбасын біздің iOS қолданбаларымызға айтарлықтай тасымалдау шығындарынсыз біріктіруімізге кепілдік береді.
Google Cloud Balancers қолданбасында QUIC аяқталуда
Артқы жағында QUIC аяқталуын пайдаланатын Google Cloud Load теңдестіру инфрақұрылымы қамтамасыз етеді. QUIC қолдауына жауаптардағы тақырыптар. Жалпы, теңгерімші әрбір HTTP сұрауына alt-svc тақырыбын қосады және бұл домен үшін QUIC қолдауын растайды. Cronet клиенті осы тақырыппен HTTP жауабын алғанда, сол доменге келесі HTTP сұраулары үшін QUIC пайдаланады. Баланстауыш QUIC-ті аяқтағаннан кейін, біздің инфрақұрылым бұл әрекетті HTTP2/TCP арқылы деректер орталықтарымызға нақты жібереді.
Өнімділік: Нәтижелер
Шығару өнімділігі - жақсырақ хаттаманы іздеуіміздің басты себебі. Бастау үшін біз стенд жасадық түрлі желі профильдерінде QUIC қалай әрекет ететінін білу үшін. QUIC өнімділігін нақты әлемдік желілерде сынау үшін жолаушылар қолданбасындағы HTTP қоңырауларына өте ұқсас эмуляцияланған желі трафигін пайдаланып, Нью-Делиді аралап жүріп эксперименттер жүргіздік.
Тәжірибе 1
Экспериментке арналған құрал-жабдықтар:
- сәйкесінше TCP және QUIC арқылы HTTPS трафикіне рұқсат беру үшін OkHttp және Cronet стектері бар Android құрылғыларын сынаңыз;
- жауаптарда HTTPS тақырыптарының бірдей түрін жіберетін және олардан сұрауларды алу үшін клиенттік құрылғыларды жүктейтін Java негізіндегі эмуляция сервері;
- TCP және QUIC қосылымдарын тоқтату үшін физикалық түрде Үндістанға жақын орналасқан бұлт проксилері. TCP тоқтату үшін біз кері проксиді қолдандық , QUIC үшін ашық бастапқы кері проксиді табу қиын болды. Біз Chromium және ұсынған негізгі QUIC стегі арқылы QUIC үшін кері прокси құрастырдық оны ашық көз ретінде хромға енгізіңіз.
Сурет 6. TCP vs QUIC жол сынақ жинағы OkHttp және Cronet бар Android құрылғыларынан, қосылымдарды тоқтатуға арналған бұлттық прокси-серверлерден және эмуляция серверінен тұрды.
Тәжірибе 2
Google QUIC көмегімен қол жетімді болған кезде , біз бірдей инвентаризацияны қолдандық, бірақ бір модификациямен: NGINX орнына құрылғылардан TCP және QUIC қосылымдарын тоқтату, сондай-ақ HTTPS трафигін эмуляция серверіне бағыттау үшін Google жүктеме теңестірушілерін алдық. Балансерлер бүкіл әлем бойынша таратылады, бірақ құрылғыға ең жақын PoP серверін пайдаланыңыз (геолокацияның арқасында).
Сурет 7. Екінші экспериментте біз TCP және QUIC аяқталу кідірісін салыстырғымыз келді: Google Cloud және бұлттық проксиді пайдалану.
Нәтижесінде бізді бірнеше ашулар күтіп тұрды:
- PoP арқылы тоқтату TCP өнімділігін жақсартты. Баланстағыштар TCP қосылымдарын пайдаланушыларға жақынырақ тоқтататындықтан және жоғары оңтайландырылғандықтан, бұл TCP өнімділігін жақсартатын RTT көрсеткіштерінің төмендеуіне әкеледі. QUIC азырақ әсер еткенімен, ол кідірісті азайту (10-30 пайызға) бойынша TCP-ден асып түсті.
- құйрықтар әсер етеді . Біздің QUIC прокси-сервері Google жүк теңдестірушілеріне қарағанда құрылғылардан алыс (шамамен 50 мс жоғары кідіріс) болғанымен, ол ұқсас өнімділікті қамтамасыз етті – TCP үшін 15-шы пайыздық көрсеткіштің 20%-ға төмендеуімен салыстырғанда кідірістің 99%-ға төмендеуі. Бұл соңғы мильге өту желідегі тығырық екенін көрсетеді.
8-сурет: Екі эксперименттің нәтижелері QUIC TCP-ден айтарлықтай асып түсетінін көрсетеді.
Жол қозғалысымен күресу
Эксперименттен шабыттана отырып, біз Android және iOS қолданбаларымызда QUIC қолдауын енгіздік. Біз Uber жұмыс істейтін қалаларда QUIC әсерін анықтау үшін A/B тестілеуін жүргіздік. Жалпы, біз екі аймақта да, байланыс операторлары мен желі түрі бойынша да кешігулердің айтарлықтай азайғанын көрдік.
Төмендегі графиктер макроөңір және әртүрлі желі түрлері бойынша (LTE, 95G, 99G) құйрықтардағы (3 және 2 процентиль) пайыздық жақсартуларды көрсетеді.
Сурет 9. Жауынгерлік сынақтарда QUIC күту уақыты бойынша TCP-тен асып түсті.
Тек қана алға
Мүмкін бұл тек бастамасы шығар - QUIC-тің өндіріске шығарылуы тұрақты және тұрақсыз желілерде қолданбалардың өнімділігін жақсарту үшін керемет мүмкіндіктер берді, атап айтқанда:
Қамтуды арттыру
Нақты трафик бойынша хаттаманың өнімділігін талдай отырып, біз сеанстардың шамамен 80%-ы QUIC-ті сәтті пайдаланғанын көрдік. всех сұраулар, ал сеанстардың 15% QUIC және TCP комбинациясын пайдаланды. Бұл комбинация Cronet кітапханасының TCP-ге қайта оралуына байланысты деп есептейміз, себебі ол нақты UDP қателері мен нашар желі жағдайларын ажырата алмайды. Қазіргі уақытта біз QUIC-ті кейіннен енгізу жолында жұмыс істеп жатқандықтан, бұл мәселенің шешімін іздеп жатырмыз.
QUIC оңтайландыру
Мобильді қолданбалардан келетін трафик кешігуге сезімтал, бірақ өткізу қабілеттілігіне сезімтал емес. Сондай-ақ, біздің қолданбалар негізінен ұялы желілерде қолданылады. Тәжірибелерге сүйенсек, пайдаланушыларға жақын TCP және QUIC протоколдарын тоқтату үшін прокси пайдаланылса да, күту уақыттары әлі де жоғары. Біз кептелістерді басқаруды жақсарту және QUIC жоғалуын қалпына келтіру алгоритмдерінің тиімділігін арттыру жолдарын белсенді түрде іздейміз.
Осы және бірнеше басқа жақсартулар арқылы біз желіге және аймаққа қарамастан пайдаланушы тәжірибесін жақсартуды жоспарлап отырмыз, бұл ыңғайлы және үздіксіз пакеттік тасымалдауды бүкіл әлем бойынша қолжетімді етеді.
Ақпарат көзі: www.habr.com