Протокол 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 мс, 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 основно retransmit-ва последния пакет (или нов, ако има такъв), за да започне бързо възстановяване. Обработката на крайни закъснения е особено полезна за начина, по който Uber работи с мрежата, особено за кратки, епизодични и чувствителни към закъснения предавания на данни.оптимизиран ACK.
• Тъй като всеки пакет има уникален последователен номер, не възниква проблем с различаването. различения пратки при техния ретрансмит. ACK-пратките също съдържат време за обработка на пакета и генериране на ACK от клиентската страна. Тези особености гарантират, че QUIC по-точно изчислява RTT. ACK в QUIC поддържа до 256 диапазона NACK, помагайки на изпращача да бъде по-устойчив на пренареждане на пакети и да използва по-малко байтове в процеса. Изборният ACK (SACK) в TCP не решава този проблем във всички случай.
• миграция на връзката. Връзките QUIC се идентифицират с помощта на 64-битен ID, така че ако клиентът смени IP адресите, може да продължи да използва ID на старата връзка на новия IP адрес, без прекъсвания. Това е много честа практика за мобилни приложения, когато потребителят превключва между Wi-Fi и клетъчни връзки.

Алтернативи на 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 Projects, която съдържа оригиналната, версионната версия на протокола - 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 срещу QUIC се състоеше от Android устройства с OkHttp и Cronet, облачни проксита за завършване на връзки и сървър за емулатор.

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

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

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

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

• завършването чрез PoP подобри производителността на TCP. Тъй като балансировките завършват TCP връзката по-близо до потребителите и са отлично оптимизирани, това води до по-малки RTT, което подобрява производителността на TCP. И макар че ефектът върху QUIC е по-малък, той пак изпревари TCP по отношение на намаляване на закъснението на опашките (с 10-30 процента).
• на опашките влияят мрежовите преходи (hops). Въпреки че нашият QUIC прокси беше по-далеч от устройствата (забавянето беше с около 50 ms по-високо), отколкото при балансировките на 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