Протоколът QUIC в действие: как Uber го внедри, за да оптимизира производителността

Протоколът QUIC е изключително интересен за гледане, поради което обичаме да пишем за него. Но ако предишните публикации за QUIC бяха по-скоро от историческо (местоисторически, ако желаете) естество и хардуер, днес сме щастливи да публикуваме превод от различен вид - ще говорим за реалното приложение на протокола през 2019 г. Освен това не говорим за малка инфраструктура, базирана в така наречения гараж, а за Uber, който оперира почти в целия свят. Как инженерите на компанията са стигнали до решението да използват QUIC в производството, как са извършили тестовете и какво са видели след пускането му в производство - под разрез.

Снимките могат да се кликват. Наслади се на четенето!

Uber има глобален мащаб, а именно 600 града на присъствие, във всеки от които приложението разчита изцяло на безжичен интернет от повече от 4500 клетъчни оператора. Потребителите очакват приложението да бъде не просто бързо, но и в реално време - за да постигне това, приложението Uber се нуждае от ниска латентност и много надеждна връзка. Уви, но стека HTTP / 2 не се справя добре в динамични и склонни към загуби безжични мрежи. Разбрахме, че в този случай ниската производителност е пряко свързана с внедряването на TCP в ядрата на операционната система.

За да разрешим проблема, ние кандидатствахме QUIC, модерен протокол за мултиплексиране на канали, който ни дава повече контрол върху работата на транспортния протокол. В момента работната група IETF стандартизира QUIC като HTTP / 3.

След задълбочени тестове стигнахме до заключението, че внедряването на QUIC в нашето приложение ще доведе до по-ниски крайни закъснения в сравнение с TCP. Наблюдавахме намаление в диапазона от 10-30% за HTTPS трафик в приложенията за шофьори и пътници. QUIC също ни даде пълен контрол върху потребителските пакети.

В тази статия споделяме нашия опит в оптимизирането на TCP за приложения на Uber с помощта на стек, който поддържа QUIC.

Най-новата технология: TCP

Днес TCP е най-използваният транспортен протокол за доставяне на HTTPS трафик в Интернет. TCP осигурява надежден поток от байтове, като по този начин се справя с претоварването на мрежата и загубите на ниво връзка. Широкото използване на TCP за HTTPS трафик се дължи на повсеместното разпространение на първия (почти всяка ОС съдържа TCP), наличността на повечето инфраструктури (като балансиращи натоварването, HTTPS прокси сървъри и CDN) и функционалността извън кутията, която е налична в почти повечето платформи и мрежи.

Повечето потребители използват нашето приложение в движение и закъсненията на TCP опашките не бяха близо до изискванията на нашия HTTPS трафик в реално време. Казано по-просто, потребители по целия свят са изпитали това - Фигура 1 показва закъснения в големите градове:

Фигура 1: Латентността на опашката варира в основните градове на Uber.

Въпреки че латентността в индийските и бразилските мрежи е по-висока, отколкото в САЩ и Обединеното кралство, латентността на опашката е значително по-висока от средната латентност. И това важи дори за САЩ и Великобритания.

Ефективност на TCP по въздуха

TCP е създаден за кабелен мрежи, тоест с акцент върху силно предвидимите връзки. Въпреки това, безжичен мрежите имат свои собствени характеристики и трудности. Първо, безжичните мрежи са податливи на загуби поради смущения и затихване на сигнала. Например Wi-Fi мрежите са чувствителни към микровълни, bluetooth и други радиовълни. Клетъчните мрежи страдат от загуба на сигнал (изгубен път) поради отразяване/поглъщане на сигнала от предмети и сгради, както и от намеса от съседните клетъчни кули. Това води до по-значими (4-10 пъти) и по-разнообразни закъснение при двупосочно пътуване (RTT) и загуба на пакети в сравнение с кабелна връзка.

За да се борят с колебанията в честотната лента и загубите, клетъчните мрежи обикновено използват големи буфери за изблици на трафик. Това може да доведе до прекомерни опашки, което означава по-дълги закъснения. Много често TCP третира тази опашка като загуба поради удължен таймаут, така че TCP има тенденция да препредава и по този начин да запълва буфера. Този проблем е известен като буферно подуване (прекомерно мрежово буфериране, раздуване на буфера), и това е много сериозен проблем модерен интернет.

И накрая, производителността на клетъчната мрежа варира според оператора, региона и времето. На фигура 2 събрахме средните закъснения на HTTPS трафика между клетките в обхват от 2 километра. Данни, събрани за два големи клетъчни оператора в Делхи, Индия. Както можете да видите, производителността варира от клетка до клетка. Освен това производителността на един оператор се различава от производителността на втория. Това се влияе от фактори като модели на влизане в мрежата, като се вземат предвид времето и местоположението, мобилността на потребителите, както и мрежовата инфраструктура, като се вземе предвид гъстотата на кулите и съотношението на типовете мрежи (LTE, 3G и др.).

Фигура 2. Закъснения с радиус от 2 km като пример. Делхи, Индия.

Освен това производителността на клетъчните мрежи варира с времето. Фигура 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 пакети, използвайки tcpdump за една седмица върху боен трафик, идващ от крайни индийски сървъри. След това анализирахме TCP връзките, използвайки tcptrace. Освен това създадохме приложение за Android, което изпраща емулиран трафик към тестов сървър, имитирайки максимално реалния трафик. Смартфони с това приложение бяха раздадени на няколко служители, които събираха логове в продължение на няколко дни.

Резултатите от двата експеримента са в съответствие един с друг. Видяхме високи латентности на RTT; стойностите на опашката бяха почти 6 пъти по-високи от средната стойност; средноаритметичната стойност на закъсненията е повече от 1 секунда. Много връзки бяха със загуба, което накара TCP да препредаде 3,5% от всички пакети. В претоварени зони като летища и гари видяхме 7% загуби. Тези резултати поставят под съмнение общоприетото мнение, че тези, използвани в клетъчните мрежи усъвършенствани схеми за препредаване значително намаляване на загубите на транспортно ниво. По-долу са резултатите от теста на приложението „симулатор“:

Мрежови показатели
значение

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

Разминаване на RTT, секунди
Средно ~1,2 s

Загуба на пакети при нестабилни връзки
Средно ~3.5% (7% в претоварени зони)

Почти половината от тези връзки са имали поне една загуба на пакет, повечето от тях SYN и SYN-ACK пакети. Повечето TCP реализации използват RTO стойност от 1 секунда за SYN пакети, която се увеличава експоненциално за последващи загуби. Времената за зареждане на приложението може да се увеличат поради това, че TCP отнема повече време за установяване на връзки.

В случай на пакети с данни високите стойности на RTO значително намаляват полезното използване на мрежата при наличие на преходни загуби в безжичните мрежи. Установихме, че средното време за повторно предаване е приблизително 1 секунда с крайно забавяне от почти 30 секунди. Тези големи закъснения на TCP ниво причиниха изчакване на HTTPS и повторни заявки, което допълнително увеличи латентността и неефективността на мрежата.

Докато 75-ият персентил на измереното RTT беше около 425 ms, 75-ият персентил за TCP беше почти 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 (всъщност HTTP/2 върху QUIC е HTTP/3, който сега се стандартизира интензивно). Той частично замества HTTPS и TCP слоевете, като използва UDP за формиране на пакети. QUIC поддържа само защитен трансфер на данни, тъй като TLS е напълно вграден в QUIC.

Фигура 5: QUIC работи под HTTP/3, заменяйки TLS, който преди това работеше под HTTP/2.

По-долу са изброени причините, които ни убедиха да използваме QUIC за усилване на TCP:

• 0-RTT установяване на връзка. QUIC позволява повторно използване на разрешения от предишни връзки, намалявайки броя на ръкостисканията за сигурност. В бъдеще TLS1.3 ще поддържа 0-RTT, но все пак ще се изисква тристранно TCP ръкостискане.
• преодоляване на блокирането на HoL. HTTP/2 използва една TCP връзка на клиент за подобряване на производителността, но това може да доведе до блокиране на HoL (head-of-line). QUIC опростява мултиплексирането и доставя заявки към приложението независимо.
• контрол на задръстванията. QUIC се намира на приложния слой, което улеснява актуализирането на основния транспортен алгоритъм, който контролира изпращането въз основа на мрежови параметри (брой загуби или RTT). Повечето TCP реализации използват алгоритъма КУБИЧЕН, което не е оптимално за трафик, чувствителен към латентност. Наскоро разработени алгоритми като ББР, по-точно моделира мрежата и оптимизира латентността. QUIC ви позволява да използвате BBR и да актуализирате този алгоритъм, докато се използва. подобряване.
• попълване на загубите. QUIC извиква два TLP (сонда за загуба на опашка) преди да се задейства RTO - дори когато загубите са много забележими. Това е различно от TCP имплементациите. TLP препредава главно последния пакет (или новия, ако има такъв), за да задейства бързо попълване. Боравенето със закъсненията на опашката е особено полезно за начина, по който Uber управлява своята мрежа, а именно за кратки, спорадични и чувствителни към забавяне трансфери на данни.
• оптимизиран ACK. Тъй като всеки пакет има уникален пореден номер, няма проблем отличия пакети, когато се препредават. ACK пакетите също съдържат време за обработка на пакета и генериране на ACK от страна на клиента. Тези функции гарантират, че QUIC изчислява RTT по-точно. ACK в QUIC поддържа до 256 ленти НАК, помагайки на подателя да бъде по-устойчив на разбъркване на пакети и да използва по-малко байтове в процеса. Селективен ACK (ЧУБЛ) в TCP не решава този проблем във всички случаи.
• миграция на връзката. QUIC връзките се идентифицират с 64-битов идентификатор, така че ако клиент промени IP адресите, старият идентификатор на връзката може да продължи да се използва на новия IP адрес без прекъсване. Това е много често срещана практика за мобилни приложения, при които потребителят превключва между Wi-Fi и клетъчни връзки.

Алтернативи на QUIC

Разгледахме алтернативни подходи за решаване на проблема, преди да изберем QUIC.

Първото нещо, което опитахме, беше да внедрим TPC PoPs (точки на присъствие), за да прекратим TCP връзките по-близо до потребителите. По същество PoP прекратяват TCP връзка с мобилно устройство, което е по-близо до клетъчната мрежа, и пренасочват трафика обратно към оригиналната инфраструктура. Като прекратим TCP по-близо, можем потенциално да намалим RTT и да гарантираме, че TCP реагира по-добре на динамична безжична среда. Нашите експерименти обаче показаха, че по-голямата част от RTT и загубите идват от клетъчни мрежи и използването на PoPs не осигурява значително подобрение на производителността.

Разгледахме и настройката на TCP параметрите. Настройването на TCP стек на нашите разнородни периферни сървъри беше трудно, тъй като TCP има различни реализации в различни версии на ОС. Беше трудно да се приложи това и да се тестват различни мрежови конфигурации. Конфигурирането на TCP директно на мобилни устройства не беше възможно поради липса на разрешения. По-важното е, че характеристики като 0-RTT връзки и подобрено RTT предсказване са критични за архитектурата на протокола и следователно е невъзможно да се постигнат значителни ползи само чрез настройка на TCP.

И накрая, ние оценихме няколко протокола, базирани на UDP, които отстраняват неизправности при стрийминг на видео – искахме да видим дали тези протоколи ще помогнат в нашия случай. За съжаление, много от настройките за сигурност им липсваха, а освен това изискваха допълнителна TCP връзка за метаданни и контролна информация.

Нашето изследване показа, че QUIC е може би единственият протокол, който може да помогне с проблема с интернет трафика, като същевременно взема предвид както сигурността, така и производителността.

Интегриране на QUIC в платформата

За да вградим успешно QUIC и да подобрим производителността на приложенията в среди с лоша свързаност, заменихме стария стек (HTTP/2 през TLS/TCP) с протокола QUIC. Използвахме мрежовата библиотека Cronet на Chromium проекти, който съдържа оригиналната, Google версия на протокола – gQUIC. Това изпълнение също непрекъснато се подобрява, за да следва най-новата IETF спецификация.

Първо интегрирахме Cronet в нашите приложения за Android, за да добавим поддръжка за QUIC. Интеграцията беше извършена по такъв начин, че да се намалят максимално разходите за миграция. Вместо напълно да замени стария мрежов стек, който използва библиотеката OkHttp, интегрирахме Cronet ПОД рамката на OkHttp API. Правейки интеграцията по този начин, ние избегнахме промени в нашите мрежови повиквания (които се използват от Ретрофит) на ниво API.

Подобно на подхода за устройства с Android, внедрихме Cronet в приложения на Uber на iOS, прихващайки HTTP трафик от мрежата APIИзползване NSURLПротокол. Тази абстракция, предоставена от iOS Foundation, обработва специфични за протокол URL данни и гарантира, че можем да интегрираме Cronet в нашите iOS приложения без значителни разходи за миграция.

Завършване на QUIC на Google Cloud Balancers

От страна на бекенда, QUIC завършването се осигурява от инфраструктурата за балансиране на Google Cloud Load, която използва alt-svc заглавки в отговорите за поддръжка на QUIC. По принцип балансиращият добавя alt-svc хедър към всяка HTTP заявка и това вече потвърждава поддръжката на QUIC за домейна. Когато клиент на Cronet получи HTTP отговор с тази заглавка, той използва QUIC за последващи HTTP заявки към този домейн. След като балансьорът завърши QUIC, нашата инфраструктура изрично изпраща това действие през HTTP2/TCP към нашите центрове за данни.

Изпълнение: Резултати

Производителността на изхода е основната причина за нашето търсене на по-добър протокол. Като начало създадохме щанд с мрежова емулацияза да разберете как ще се държи QUIC под различни мрежови профили. За да тестваме производителността на QUIC в мрежи от реалния свят, проведохме експерименти, докато шофирахме из Ню Делхи, използвайки емулиран мрежов трафик, много подобен на HTTP повикванията в приложението за пътници.

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

Оборудване за експеримента:

• тествайте устройства с Android със стекове OkHttp и Cronet, за да се уверите, че разрешаваме HTTPS трафик съответно през TCP и QUIC;
• базиран на Java сървър за емулация, който изпраща същия тип HTTPS хедъри в отговорите и зарежда клиентските устройства, за да получава заявки от тях;
• облачни проксита, които са физически разположени близо до Индия, за да прекратят TCP и QUIC връзки. Докато за TCP терминиране използвахме обратен прокси на Nginx, беше трудно да се намери обратен прокси с отворен код за QUIC. Сами създадохме обратен прокси за QUIC, използвайки основния QUIC стек от Chromium и публикувано го в chromium като отворен код.

Фигура 6. Пакетът за пътни тестове TCP срещу QUIC се състоеше от Android устройства с OkHttp и Cronet, облачни прокси сървъри за прекратяване на връзки и сървър за емулация.

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

Когато Google направи QUIC достъпен с Балансиране на натоварването в облака на Google, използвахме същия инвентар, но с една модификация: вместо NGINX, взехме Google load balancers за прекратяване на TCP и QUIC връзки от устройства, както и за насочване на HTTPS трафик към сървъра за емулация. Балансьорите са разпространени по целия свят, но използват PoP сървъра, който е най-близо до устройството (благодарение на геолокацията).

Фигура 7. Във втория експеримент искахме да сравним латентността на завършване на TCP и QUIC: използвайки Google Cloud и използвайки нашия облачен прокси.

В резултат на това ни очакваха няколко разкрития:

• терминиране чрез PoP подобрена TCP производителност. Тъй като балансьорите прекратяват TCP връзките по-близо до потребителите и са силно оптимизирани, това води до по-ниски RTT, което подобрява TCP производителността. И въпреки че QUIC беше по-малко засегнат, той все още превъзхождаше TCP по отношение на намаляване на латентността на опашката (с 10-30 процента).
• опашките са засегнати мрежови скокове. Въпреки че нашият QUIC прокси беше по-далеч от устройствата (около 50 ms по-висока латентност) от балансиращите на натоварването на Google, той осигури подобна производителност – 15% намаление на латентността спрямо 20% намаление в 99-ия персентил за TCP. Това предполага, че преходът на последната миля е тясно място в мрежата.

Фигура 8: Резултатите от два експеримента показват, че QUIC значително превъзхожда TCP.

Борба с трафика

Вдъхновени от експериментирането, внедрихме QUIC поддръжка в нашите приложения за Android и iOS. Проведохме A/B тестове, за да определим въздействието на QUIC в градовете, в които Uber работи. Като цяло видяхме значително намаляване на закъсненията в опашката в двата региона, телеком оператори и тип мрежа.

Графиките по-долу показват процентните подобрения в опашките (95 и 99 процентили) по макрорегион и различни типове мрежи - LTE, 3G, 2G.

Фигура 9. В бойни тестове QUIC превъзхожда TCP по отношение на латентност.

Само напред

Може би това е само началото - пускането на QUIC в производство предостави невероятни възможности за подобряване на производителността на приложенията както в стабилни, така и в нестабилни мрежи, а именно:

Повишено покритие

След като анализирахме ефективността на протокола при реален трафик, видяхме, че приблизително 80% от сесиите успешно използват QUIC за всички заявки, докато 15% от сесиите използват комбинация от QUIC и TCP. Предполагаме, че комбинацията се дължи на таймаута на библиотеката Cronet обратно към TCP, тъй като тя не може да направи разлика между реални грешки на UDP и лоши мрежови условия. В момента търсим решение на този проблем, докато работим за последващото внедряване на QUIC.

QUIC оптимизация

Трафикът от мобилни приложения е чувствителен към забавяне, но не и към честотна лента. Освен това нашите приложения се използват предимно в клетъчни мрежи. Въз основа на експерименти латентностите на опашката все още са високи, въпреки че се използва прокси за прекратяване на TCP и QUIC близо до потребителите. Ние активно търсим начини за подобряване на управлението на задръстванията и ефективността на QUIC алгоритмите за възстановяване на загуби.

С тези и няколко други подобрения планираме да подобрим потребителското изживяване независимо от мрежата и региона, като направим удобния и безпроблемен пакетен транспорт по-достъпен по целия свят.

Източник: www.habr.com