Протокол 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 е склонен да прави повторни предавания и по този начин запълва буфера. Този проблем е известен като bufferbloat (излишна мрежова буферизация, раздуване на буфера), и това е много сериозен проблем съвременния интернет.

Накрая, производителността на мобилната мрежа варира в зависимост от оператора, региона и времето. На Фигура 2 сме събрали медианните закъснения на HTTPS трафика в клетките в обхвата от 2 километра. Данните са събрани за двамата най-големи оператори на мобилни услуги в Делхи, Индия. Както можете да забележите, производителността се променя от клетка на клетка. Освен това производителността на един оператор се различава от производителността на другия. Това се влияе от фактори като модели на достъп до мрежата с оглед на времето и местоположението, мобилността на потребителите, както и мрежовата инфраструктура, отчитайки плътността на антените и съотношението на типове мрежи (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 пакети с помощта на tcpdump през седмица на реалния трафик, идващ от индийски гранични сървъри. След това анализирахме TCP връзките с помощта на tcptrace. Освен това създадохме 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 използват стойност 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 използват алгоритъма CUBIC, който не е оптимален за трафик, чувствителен към забавяния. Наскоро разработени алгоритми като BBR, по-точно моделират мрежата и оптимизират забавянията. QUIC позволява използването на BBR и актуализиране на този алгоритъм с напредването му възстановяване на загуби..
• QUIC предизвиква два TLP ( tail loss probe) преди да активира RTO – дори когато загубите са много осезаеми. Това се различава от реализациите на TCP. TLP предава главно последния пакет (или нов, ако такъв съществува), за да стартира бързо възстановяване. Обработката на опашни забавяния е особено полезна за начина, по който Uber работи с мрежата, а именно за кратки, епизодични и чувствителни на забавяне предавания на данни.оптимизирано ACK.
• Тъй като всеки пакет има уникален последователен номер, не възниква проблем с различаването на пакетите при тяхното повторно изпращане. ACK-пакетите също така съдържат време за обработка на пакета и генериране на ACK от страна на клиента. Тези характеристики гарантират, че QUIC по-точно изчислява RTT. ACK в QUIC поддържа до 256 диапазона NACK , помагайки на изпращача да бъде по-устойчив на пренареждане на пакети и да използва по-малко байтове в процеса. Изборното ACK () в TCP не решава този проблем във всички случаи.SACKмиграция на връзки.
• Връзките QUIC се идентифицират с помощта на 64-битов ID, така че ако клиентът променя IP адреси, може да се използва ID на старата връзка на новия IP адрес без прекъсвания. Това е много обичайна практика за мобилни приложения, когато потребителят превключва между Wi-Fi и клетъчни връзки. Алтернативи на QUIC

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

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

Първо опитахме да внедрим TPC PoPs (Точки на присъствие), за да приключваме TCP връзки по-близо до потребителите. По същество, PoPs завършва 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. Чрез този подход избегнахме промени в нашите мрежови извиквания (които използват Retrofit) на ниво API.

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

Приключване на QUIC на балансиращите натоварването на Google Cloud

На страната на бекенда приключването на QUIC се осигурява от инфраструктурата на Google Cloud Load balancing, която използва alt-svc заглавия в отговорите, за да поддържат QUIC. В общия случай, към всяко HTTP запитване, балансировчикът добавя заглавие alt-svc и по него валидира поддръжката на 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 и публикуваха го в хромиум като опенсорс.

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

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

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

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

В крайна сметка, ни чакаха няколко открития:

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

Илюстрация 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 алгоритмите за възстановяване на загуби.

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

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