Протокол КУИЦ у акцији: како га је Убер имплементирао да би оптимизовао перформансе

КУИЦ протокол је изузетно занимљив за гледање, због чега волимо да пишемо о њему. Али ако су претходне публикације о КУИЦ-у биле више историјске (локалне историје, ако желите) природе и хардвера, данас ћемо радо објавити превод друге врсте – о правој примени протокола ћемо говорити 2019. године. Штавише, не говоримо о малој инфраструктури која се налази у такозваној гаражи, већ о Уберу, који послује готово широм света. Како су инжењери компаније дошли до одлуке да користе КУИЦ у производњи, како су спровели тестове и шта су видели након што су га пустили у производњу - испод реза.

Слике се могу кликнути. Уживај у читању!

Убер има глобалну скалу, односно 600 градова присуства, у сваком од којих се апликација у потпуности ослања на бежични интернет од више од 4500 мобилних оператера. Корисници очекују да апликација не буде само брза, већ у реалном времену – да би се то постигло, Убер апликацији је потребна мала латенција и веома поуздана веза. Авај, али стог ХТТП / 2 не ради добро у динамичким бежичним мрежама које су склоне губицима. Схватили смо да су у овом случају ниске перформансе директно повезане са имплементацијом ТЦП-а у језгрима оперативног система.

Да бисмо решили проблем, пријавили смо се КУИЦ, модеран протокол за мултиплексирање канала који нам даје већу контролу над перформансама транспортног протокола. Тренутно радна група Радна група је стандардизује КУИЦ као ХТТП / 3.

Након опсежног тестирања, закључили смо да би имплементација КУИЦ-а у нашу апликацију резултирала мањим кашњењем репа у поређењу са ТЦП-ом. Приметили смо смањење у опсегу од 10-30% за ХТТПС саобраћај у апликацијама за возача и сувозача. КУИЦ нам је такође дао контролу од краја до краја над корисничким пакетима.

У овом чланку делимо наше искуство у оптимизацији ТЦП-а за Убер апликације користећи стек који подржава КУИЦ.

Најновија технологија: ТЦП

Данас је ТЦП најчешће коришћени транспортни протокол за испоруку ХТТПС саобраћаја на Интернету. ТЦП обезбеђује поуздан ток бајтова, чиме се носи са загушењем мреже и губицима слоја везе. Широко распрострањена употреба ТЦП-а за ХТТПС саобраћај је због свеприсутности првог (скоро сваки ОС садржи ТЦП), доступности на већини инфраструктуре (као што су балансери оптерећења, ХТТПС проксији и ЦДН-ови) и функционалности која је доступна ван кутије на скоро већини платформи и мрежа.

Већина корисника користи нашу апликацију у покрету, а кашњење ТЦП репа није било ни близу захтева нашег ХТТПС саобраћаја у реалном времену. Једноставно речено, корисници широм света су искусили ово - Слика 1 показује кашњења у великим градовима:

Слика 1: Кашњење репа варира у свим Уберовим главним градовима.

Иако је кашњење у индијским и бразилским мрежама било веће него у САД и Великој Британији, кашњење репа је знатно веће од просечног кашњења. И то важи чак и за САД и УК.

ТЦП овер тхе аир перформансе

ТЦП је креиран за ožičen мреже, односно са нагласком на високо предвидљиве везе. Међутим, бежични мреже имају своје карактеристике и потешкоће. Прво, бежичне мреже су подложне губицима због сметњи и слабљења сигнала. На пример, Ви-Фи мреже су осетљиве на микроталасне, блуетоотх и друге радио таласе. Ћелијске мреже пате од губитка сигнала (изгубљени пут) услед рефлексије/апсорпције сигнала од објеката и зграда, као и од сметње од суседних ћелијских торњева. То доводи до значајније (4-10 пута) и разноврсније Време повратног путовања (РТТ) и губитак пакета у поређењу са жичном везом.

За борбу против флуктуација и губитака пропусног опсега, ћелијске мреже обично користе велике бафере за рафале саобраћаја. То може довести до прекомерног чекања у реду, што значи дужа кашњења. Врло често ТЦП третира ово чекање као губитак због продуженог временског ограничења, тако да ТЦП тежи да пребацује и тиме попуњава бафер. Овај проблем је познат као буфферблоат (прекомерно баферовање мреже, надувавање бафера), а ово је веома озбиљан проблем савремени Интернет.

Коначно, перформансе мобилне мреже варирају у зависности од оператера, региона и времена. На слици 2, прикупили смо средња кашњења ХТТПС саобраћаја у ћелијама у опсегу од 2 километра. Подаци прикупљени за два главна мобилна оператера у Делхију, Индија. Као што видите, перформансе варирају од ћелије до ћелије. Такође, продуктивност једног оператера се разликује од продуктивности другог. На то утичу фактори као што су обрасци уласка у мрежу узимајући у обзир време и локацију, мобилност корисника, као и мрежну инфраструктуру узимајући у обзир густину торњева и однос типова мреже (ЛТЕ, 3Г, итд.).

Слика 2. Закашњења користећи радијус од 2 км као пример. Делхи, Индија.

Такође, перформансе ћелијских мрежа варирају током времена. Слика 3 приказује средње кашњење по данима у недељи. Такође смо приметили разлике у мањем обиму, у оквиру једног дана и сата.

Слика 3. Кашњења репа могу значајно да варирају између дана, али за истог оператера.

Све горе наведено доводи до тога да ТЦП перформансе буду неефикасне у бежичним мрежама. Међутим, пре него што смо тражили алтернативе ТЦП-у, желели смо да развијемо прецизно разумевање следећих тачака:

• да ли је ТЦП главни кривац за кашњење репа у нашим апликацијама?
• Да ли модерне мреже имају значајна и различита кашњења повратног пута (РТТ)?
• Какав је утицај РТТ-а и губитка на ТЦП перформансе?

Анализа перформанси ТЦП-а

Да бисмо разумели како смо анализирали ТЦП перформансе, хајде да на брзину погледамо како ТЦП преноси податке од пошиљаоца до примаоца. Прво, пошиљалац успоставља ТЦП везу, обављајући тросмерну руковање: Пошиљалац шаље СИН пакет, чека СИН-АЦК пакет од примаоца, а затим шаље АЦК пакет. Додатни други и трећи пролаз се троши на успостављање ТЦП везе. Прималац потврђује пријем сваког пакета (АЦК) како би осигурао поуздану испоруку.

Ако се пакет или АЦК изгубе, пошиљалац поново шаље после истека времена (РТО, временско ограничење ретрансмисије). РТО се израчунава динамички на основу различитих фактора, као што је очекивано РТТ кашњење између пошиљаоца и примаоца.

Слика 4. Размена пакета преко ТЦП/ТЛС-а укључује механизам ретрансмисије.

Да бисмо утврдили како се ТЦП показао у нашим апликацијама, пратили смо ТЦП пакете користећи тцпдумп недељу дана о борбеном саобраћају који долази са индијских ивичних сервера. Затим смо анализирали ТЦП везе користећи тцптраце. Поред тога, направили смо Андроид апликацију која шаље емулирани саобраћај на тест сервер, имитирајући стварни саобраћај што је више могуће. Паметни телефони са овом апликацијом подељени су неколицини запослених, који су прикупљали дневнике током неколико дана.

Резултати оба експеримента били су конзистентни један са другим. Видели смо велике РТТ латенције; реп вредности су биле скоро 6 пута веће од средње вредности; аритметички просек кашњења је већи од 1 секунде. Многе везе су биле са губицима, због чега је ТЦП поново пренео 3,5% свих пакета. У закрченим подручјима као што су аеродроми и железничке станице, видели смо губитак од 7%. Ови резултати бацају сумњу на конвенционалну мудрост коју користе у ћелијским мрежама напредна кола ретрансмисије значајно смањити губитке на нивоу транспорта. Испод су резултати теста из апликације „симулатор“:

Мрежни показатељи
Вредности

РТТ, милисекунде [50%, 75%, 95%, 99%]
[350, 425, 725, 2300]

РТТ дивергенција, секунде
У просеку ~1,2 с

Губитак пакета на нестабилним везама
Просечно ~3.5% (7% у преоптерећеним областима)

Скоро половина ових веза имала је најмање један губитак пакета, већина СИН и СИН-АЦК пакета. Већина ТЦП имплементација користи РТО вредност од 1 секунде за СИН пакете, која се експоненцијално повећава за наредне губитке. Време учитавања апликације може да се повећа због тога што ТЦП-у треба више времена да успостави везе.

У случају пакета података, високе вредности РТО у великој мери смањују корисно коришћење мреже у присуству пролазних губитака у бежичним мрежама. Открили смо да је просечно време ретрансмисије отприлике 1 секунда са кашњењем репа од скоро 30 секунди. Ове велике латенције на ТЦП нивоу су изазвале ХТТПС тајм-ауте и поновне захтеве, додатно повећавајући мрежно кашњење и неефикасност.

Док је 75. перцентил измереног РТТ био око 425 мс, 75. перцентил за ТЦП је био скоро 3 секунде. Ово наговештава да је губитак довео до тога да је ТЦП-у требало 7-10 пролаза за успешан пренос података. Ово може бити последица неефикасног прорачуна РТО-а, неспособности ТЦП-а да брзо реагује на губитак најновији пакети у прозору и неефикасност алгоритма за контролу загушења, који не прави разлику између бежичних губитака и губитака услед загушења мреже. Испод су резултати тестова ТЦП губитка:

Статистика губитка ТЦП пакета
Вредност

Проценат веза са најмање 1 губитком пакета
100%

Проценат веза са губицима током подешавања везе
100%

Проценат веза са губицима током размене података
100%

Дистрибуција кашњења у поновном преносу, секунде [50%, 75%, 95%,99%] [1, 2.8, 15, 28]

Дистрибуција броја поновних преноса за један пакет или ТЦП сегмент
[КСНУМКС]

Примена КУИЦ-а

Првобитно развијен од стране Гоогле-а, КУИЦ је модеран транспортни протокол са више нити који ради на врху УДП-а. Тренутно је КУИЦ ин процес стандардизације (већ смо писали да постоје, такорећи, две верзије КУИЦ-а, радознало можете пратити везу – прибл. преводилац). Као што је приказано на слици 5, КУИЦ је смештен под ХТТП/3 (у ствари, ХТТП/2 изнад КУИЦ-а је ХТТП/3, који се сада интензивно стандардизује). Делимично замењује ХТТПС и ТЦП слојеве користећи УДП за формирање пакета. КУИЦ подржава само сигуран пренос података пошто је ТЛС у потпуности уграђен у КУИЦ.

Слика 5: КУИЦ ради под ХТТП/3, замењујући ТЛС, који је раније радио под ХТТП/2.

У наставку су разлози који су нас убедили да користимо КУИЦ за ТЦП појачање:

• Успостављање 0-РТТ везе. КУИЦ дозвољава поновну употребу ауторизација из претходних веза, смањујући број безбедносних руковања. У будућности ТЛС1.3 подржаваће 0-РТТ, али ће и даље бити потребно тросмерно ТЦП руковање.
• превазилажење ХоЛ блокирања. ХТТП/2 користи једну ТЦП везу по клијенту за побољшање перформанси, али то може довести до блокирања ХоЛ-а (хеад-оф-лине). КУИЦ поједностављује мултиплексирање и независно испоручује захтеве апликацији.
• контрола загушења. КУИЦ се налази на слоју апликације, што олакшава ажурирање главног транспортног алгоритма који контролише слање на основу мрежних параметара (број губитака или РТТ). Већина ТЦП имплементација користи алгоритам ЦУБИЦ, што није оптимално за саобраћај осетљив на кашњење. Недавно развијени алгоритми попут ББР, прецизније моделује мрежу и оптимизује кашњење. КУИЦ вам омогућава да користите ББР и ажурирате овај алгоритам како се користи. побољшање.
• попуњавање губитака. КУИЦ позива два ТЛП-а (сонда за губитак репа) пре него што се РТО активира - чак и када су губици веома приметни. Ово се разликује од ТЦП имплементације. ТЛП поново преноси углавном последњи пакет (или нови, ако постоји) да би покренуо брзо допуњавање. Руковање кашњењима у репу је посебно корисно за начин на који Убер управља својом мрежом, наиме за кратке, спорадичне и преносе података који су осетљиви на кашњење.
• оптимизован АЦК. Пошто сваки пакет има јединствени редни број, нема проблема разлике пакете када се поново преносе. АЦК пакети такође садрже време за обраду пакета и генерисање АЦК на страни клијента. Ове карактеристике обезбеђују да КУИЦ прецизније израчунава РТТ. АЦК у КУИЦ-у подржава до 256 опсега НАЦК, помажући пошиљаоцу да буде отпорнији на мешање пакета и да користи мање бајтова у процесу. Селективни АЦК (САЦК) у ТЦП-у не решава овај проблем у свим случајевима.
• миграција везе. КУИЦ везе се идентификују помоћу 64-битног ИД-а, тако да ако клијент промени ИП адресе, стари ИД везе може наставити да се користи на новој ИП адреси без прекида. Ово је врло уобичајена пракса за мобилне апликације где се корисник пребацује између Ви-Фи и мобилних веза.

Алтернативе КУИЦ-у

Размотрили смо алтернативне приступе решавању проблема пре него што смо изабрали КУИЦ.

Прва ствар коју смо покушали је да применимо ТПЦ ПоП (тачке присутности) да прекинемо ТЦП везе ближе корисницима. У суштини, ПоП-ови прекидају ТЦП везу са мобилним уређајем ближим ћелијској мрежи и проксију саобраћај назад у оригиналну инфраструктуру. Приближавањем ТЦП-а можемо потенцијално смањити РТТ и осигурати да ТЦП боље реагује на динамичко бежично окружење. Међутим, наши експерименти су показали да већина РТТ-а и губитака долази из ћелијских мрежа и да употреба ПоП-а не обезбеђује значајно побољшање перформанси.

Такође смо погледали подешавање ТЦП параметара. Постављање ТЦП стека на нашим хетерогеним рубним серверима је било тешко јер ТЦП има различите имплементације у различитим верзијама ОС-а. Било је тешко ово имплементирати и тестирати различите мрежне конфигурације. Конфигурисање ТЦП-а директно на мобилним уређајима није било могуће због недостатка дозвола. Што је још важније, карактеристике као што су 0-РТТ везе и побољшано предвиђање РТТ-а су критичне за архитектуру протокола, и стога је немогуће постићи значајне предности само подешавањем ТЦП-а.

Коначно, проценили смо неколико протокола заснованих на УДП-у који решавају проблеме са видео стримингом — желели смо да видимо да ли ће ови протоколи помоћи у нашем случају. Нажалост, много им је недостајало у многим безбедносним подешавањима, а такође је била потребна додатна ТЦП веза за метаподатке и контролне информације.

Наше истраживање је показало да је КУИЦ можда једини протокол који може помоћи у решавању проблема интернет саобраћаја, узимајући у обзир и безбедност и перформансе.

Интеграција КУИЦ-а у платформу

Да бисмо успешно уградили КУИЦ и побољшали перформансе апликације у окружењима са лошом конективношћу, заменили смо стари стек (ХТТП/2 преко ТЛС/ТЦП) са КУИЦ протоколом. Користили смо мрежну библиотеку Цронет од Цхромиум Пројецтс, који садржи оригиналну, Гугл верзију протокола - гКУИЦ. Ова имплементација се такође стално побољшава како би пратила најновију ИЕТФ спецификацију.

Прво смо интегрисали Цронет у наше Андроид апликације да бисмо додали подршку за КУИЦ. Интеграција је спроведена на начин да се што више смање трошкови миграције. Уместо да у потпуности замените стари мрежни стек који је користио библиотеку ОкХттп, интегрисали смо Цронет ИСПОД ОкХттп АПИ оквира. Изводећи интеграцију на овај начин, избегли смо промене у нашим мрежним позивима (које користе Ретрофит) на нивоу АПИ-ја.

Слично приступу за Андроид уређаје, имплементирали смо Цронет у Убер апликације на иОС-у, пресрећући ХТТП саобраћај са мреже АПИ заКористећи НСУРЛПротоцол. Ова апстракција, коју је обезбедила иОС Фоундатион, обрађује УРЛ податке специфичне за протокол и обезбеђује да можемо да интегришемо Цронет у наше иОС апликације без значајних трошкова миграције.

Довршавање КУИЦ-а на Гоогле Цлоуд Баланцерима

Са позадинске стране, КУИЦ довршење обезбеђује Гоогле инфраструктура за балансирање оптерећења у облаку, која користи алт-свц заглавља у одговорима за подршку КУИЦ-у. Генерално, балансатор додаје алт-свц заглавље сваком ХТТП захтеву и то већ потврђује КУИЦ подршку за домен. Када Цронет клијент прими ХТТП одговор са овим заглављем, користи КУИЦ за накнадне ХТТП захтеве за тај домен. Када балансер заврши КУИЦ, наша инфраструктура експлицитно шаље ову радњу преко ХТТП2/ТЦП у наше центре података.

Учинак: Резултати

Излазне перформансе су главни разлог наше потраге за бољим протоколом. За почетак смо направили штанд са емулација мрежеда сазнате како ће се КУИЦ понашати под различитим мрежним профилима. Да бисмо тестирали перформансе КУИЦ-а на мрежама у стварном свету, изводили смо експерименте док смо се возили по Њу Делхију користећи емулирани мрежни саобраћај веома сличан ХТТП позивима у апликацији за путнике.

Експеримент 1

Опрема за експеримент:

• тестирајте Андроид уређаје са ОкХттп и Цронет стековима да бисте били сигурни да дозвољавамо ХТТПС саобраћај преко ТЦП-а и КУИЦ-а;
• сервер за емулацију заснован на Јави који шаље исту врсту ХТТПС заглавља у одговорима и учитава клијентске уређаје да би примио захтеве од њих;
• прокси сервери у облаку који се физички налазе у близини Индије да би прекинули ТЦП и КУИЦ везе. Док смо за ТЦП терминацију користили обрнути прокси на НГИНКС, било је тешко пронаћи обрнути проки отвореног кода за КУИЦ. Ми смо сами направили обрнути прокси за КУИЦ користећи основни КУИЦ стек из Цхромиум-а и објављено то у хром као отворени извор.

Слика 6. ТЦП вс КУИЦ пакет за тестирање на путу се састојао од Андроид уређаја са ОкХттп и Цронет, проксија у облаку за прекидање веза и сервера за емулацију.

Експеримент 2

Када је Гоогле учинио КУИЦ доступним са Google Cloud balansiranje opterećenja, користили смо исти инвентар, али са једном модификацијом: уместо НГИНКС-а, узели смо Гоогле балансаторе оптерећења да прекинемо ТЦП и КУИЦ везе са уређаја, као и да усмеримо ХТТПС саобраћај на сервер за емулацију. Балансери су дистрибуирани широм света, али користе ПоП сервер који је најближи уређају (захваљујући геолокацији).

Слика 7. У другом експерименту, желели смо да упоредимо латенцију завршетка ТЦП-а и КУИЦ-а: коришћењем Гоогле Цлоуд-а и коришћењем нашег проксија у облаку.

Као резултат тога, чекало нас је неколико открића:

• завршетак преко ПоП побољшане ТЦП перформансе. Пошто балансери прекидају ТЦП везе ближе корисницима и веома су оптимизовани, ово резултира нижим РТТ-овима, што побољшава ТЦП перформансе. И иако је КУИЦ био мање погођен, ипак је надмашио ТЦП у смислу смањења кашњења репа (за 10-30 процената).
• репови су захваћени мрежни скокови. Иако је наш КУИЦ прокси био даље од уређаја (око 50 мс веће кашњење) од Гоогле-ових балансера оптерећења, испоручио је сличне перформансе – 15% смањење кашњења у односу на 20% смањење 99. перцентила за ТЦП. Ово сугерише да је транзиција последње миље уско грло у мрежи.

Слика 8: Резултати два експеримента показују да КУИЦ значајно надмашује ТЦП.

Борбени саобраћај

Инспирисани експериментисањем, имплементирали смо КУИЦ подршку у наше Андроид и иОС апликације. Спровели смо А/Б тестирање да бисмо утврдили утицај КУИЦ-а у градовима у којима Убер послује. Генерално, приметили смо значајно смањење кашњења у репу у оба региона, телеком оператерима и типу мреже.

Графикони испод показују процентуална побољшања у реповима (95 и 99 перцентила) по макро-регионима и различитим типовима мрежа - ЛТЕ, 3Г, 2Г.

Слика 9. У борбеним тестовима, КУИЦ је надмашио ТЦП у погледу кашњења.

Само напред

Можда је ово само почетак - пуштање КУИЦ-а у производњу пружило је невероватне могућности за побољшање перформанси апликација и у стабилним и у нестабилним мрежама, наиме:

Повећана покривеност

Анализирајући перформансе протокола у стварном саобраћају, видели смо да је приближно 80% сесија успешно користило КУИЦ за све захтева, док је 15% сесија користило комбинацију КУИЦ-а и ТЦП-а. Претпостављамо да је комбинација настала због тога што се Цронет библиотека враћа на ТЦП, пошто не може да разликује стварне грешке у УДП-у и лоше услове мреже. Тренутно тражимо решење за овај проблем док радимо на накнадној имплементацији КУИЦ-а.

КУИЦ оптимизација

Саобраћај из мобилних апликација је осетљив на кашњење, али не и на пропусни опсег. Такође, наше апликације се првенствено користе на мобилним мрежама. На основу експеримената, кашњење у репу је и даље велико иако се користи прокси за укидање ТЦП-а и КУИЦ-а близу корисника. Активно тражимо начине да побољшамо управљање загушењима и побољшамо ефикасност КУИЦ алгоритама за враћање губитака.

Са овим и неколико других побољшања, планирамо да побољшамо корисничко искуство без обзира на мрежу и регион, чинећи практичан и беспрекоран транспорт пакета доступнијим широм света.

Извор: ввв.хабр.цом