Protokół QUIC jest niezwykle interesujący do obserwacji, dlatego lubimy o nim pisać. Jeśli wcześniejsze publikacje na temat QUIC miały bardziej historyczny (jeśli chcesz, regionalny) charakter i zajmowały się teorią, to dziś z przyjemnością publikujemy tłumaczenie innego rodzaju – mowa będzie o rzeczywistym zastosowaniu protokołu w 2019 roku. A mowa nie będzie o małej infrastrukturze, zlokalizowanej w hipotetycznym garażu, lecz o Uberze, który działa prawie na całym świecie. Jak inżynierowie firmy doszli do decyzji o wykorzystaniu QUIC w produkcji, jak przeprowadzano testy i co zobaczyli po wdrożeniu – szczegóły poniżej.
Obrazki są klikalne. Życzymy miłej lektury!
Uber to zasięg globalny, a konkretnie obecność w 600 miastach, w każdym z których aplikacja w pełni polega na bezprzewodowym internecie od ponad 4500 operatorów komórkowych. Użytkownicy oczekują, że aplikacja będzie działać nie tylko szybko, ale w czasie rzeczywistym – aby to zapewnić, aplikacja Uber potrzebuje niskich opóźnień i bardzo niezawodnego połączenia. Niestety, stos słabo radzi sobie w dynamicznych i podatnych na utratę bezprzewodowych sieciach. Zrozumieliśmy, że w tym przypadku niska wydajność jest bezpośrednio związana z realizacjami TCP w jądrze systemów operacyjnych.
Aby rozwiązać problem, zastosowaliśmy , nowoczesny protokół z multiplexingiem kanałów, który daje nam większą kontrolę nad wydajnością protokołu transportowego. Obecnie grupa robocza standaryzuje QUIC jako .
Po szczegółowych testach doszliśmy do wniosku, że wdrożenie QUIC w naszej aplikacji zmniejszy "opóźnienia ogonowe" w porównaniu do TCP. Obserwowaliśmy spadek w zakresie 10-30% dla ruchu HTTPS na przykładzie aplikacji dla kierowców i pasażerów. QUIC zapewnił nam także pełną kontrolę nad pakietami użytkowników.
W tym artykule dzielimy się doświadczeniem optymalizacji TCP dla aplikacji Uber przy użyciu stosu, który wspiera QUIC.
Ostatnie słowo techniki: TCP
Dziś TCP jest najczęściej stosowanym protokołem transportowym do dostarczania ruchu HTTPS w sieci Internet. TCP zapewnia niezawodny transfer bajtów, dzięki czemu radzi sobie z przeciążeniem sieci i stratami na poziomie kanału. Szerokie zastosowanie TCP dla ruchu HTTPS wynika z powszechności tego protokołu (niemal każdy system operacyjny obsługuje TCP), dostępności w większości infrastruktury (np. na serwerach równoważących obciążenie, proxy HTTPS i CDN) oraz funkcjonalności „z pudełka”, dostępnej niemal w większości platform i sieci.
Większość użytkowników korzysta z naszej aplikacji w ruchu, a „ogonowe” opóźnienia TCP były dalekie od wymagań naszego ruchu HTTPS w czasie rzeczywistym. Mówiąc prosto, użytkownicy z całego świata borykali się z tym problemem – na Rysunku 1 przedstawiono opóźnienia w dużych miastach:
Rysunek 1. Wartość „ogonowych” opóźnień różni się w głównych miastach, w których obecna jest Uber.
Mimo że opóźnienia w sieciach indyjskich i brazylijskich były wyższe niż w USA i Wielkiej Brytanii, ogonowe opóźnienia były znacznie większe niż średnie opóźnienia. Tak jest nawet w przypadku USA i Wielkiej Brytanii.
Wydajność TCP w powietrzu
TCP został zaprojektowany dla sieci przewodowych, co oznacza, że skoncentrowano się na dobrze przewidywalnych łączach. Jednak sieci bezprzewodowe mają swoje specyfiki i trudności. Po pierwsze, sieci bezprzewodowe są podatne na straty spowodowane zakłóceniami i osłabieniem sygnału. Na przykład, sieci Wi-Fi są wrażliwe na fale mikrofalowe, Bluetooth i inne fale radiowe. Sieci komórkowe cierpią na stratę sygnału () z powodu odbicia/chłonięcia sygnału przez obiekty i budynki, a także z powodu z sąsiednich opóźnień okrężnych (RTT) Aby radzić sobie z fluktuacjami w przepustowości i stratach, sieci komórkowe zazwyczaj stosują duże bufory dla skoków ruchu. Może to prowadzić do nadmiernego kolejkowania, co oznacza większe opóźnienia. Bardzo często TCP interpretuje takie kolejkowanie jako stratę z powodu wydłużonego czasu oczekiwania, dlatego TCP ma tendencję do retransmisji, co skutkuje wypełnianiem bufora. Problem ten znany jest jako
nadmierne buforowanie sieciowe, rozrośnięcie bufora (poważny problem. nowoczesnego internetu.
Ostatecznie wydajność sieci komórkowej zmienia się w zależności od operatora, regionu oraz pory dnia. Na Rysunku 2 przedstawiliśmy mediany opóźnień ruchu HTTPS po stacjach w promieniu 2 kilometrów. Dane zebrano dla dwóch największych operatorów sieci komórkowych w Delhi, Indiach. Jak można zauważyć, wydajność różni się w zależności od stacji. Ponadto wydajność jednego operatora różni się od wydajności drugiego. Na to wpływ mają takie czynniki jak wzorce łączenia z siecią uwzględniające czas i lokalizację, mobilność użytkowników oraz infrastruktura sieciowa, biorąc pod uwagę gęstość wież i proporcje typów sieci (LTE, 3G itp.).
Rysunek 2. Opóźnienia na przykładzie 2-kilometrowego promienia. Delhi, Indie.
Wydajność sieci komórkowych zmienia się również w czasie. Na Rysunku 3 przedstawiono medianę opóźnień w ciągu tygodnia. Zauważyliśmy również różnice w mniejszej skali – w ramach jednego dnia i godziny.
Rysunek 3. Opóźnienia mogą znacznie się zmieniać w różne dni, ale u tego samego operatora.
Wszystkie powyższe prowadzi do tego, że wydajność TCP jest nieskuteczna w sieciach bezprzewodowych. Niemniej jednak, zanim zaczniemy szukać alternatyw dla TCP, chcielibyśmy wypracować dokładne zrozumienie następujących punktów:
- czy TCP jest głównym winowajcą opóźnień w naszych aplikacjach?
- czy nowoczesne sieci mają znaczące i różnorodne okrągłe opóźnienia (RTT)?
- jakie jest wpływ RTT i utrat na wydajność TCP?
Analiza wydajności TCP
Aby zrozumieć, jak analizowaliśmy wydajność TCP, przypomnijmy krótko, jak TCP przesyła dane od nadawcy do odbiorcy. Na początku nadawca nawiązuje połączenie TCP, wykonując trójstronny : nadawca wysyła pakiet SYN, czeka na pakiet SYN-ACK od odbiorcy, a następnie wysyła pakiet ACK. Dodatkowe drugie i trzecie przejścia są poświęcone na utworzenie połączenia TCP. Odbiorca potwierdza odbiór każdego pakietu (ACK), aby zapewnić niezawodną dostawę.
Jeśli pakiet lub ACK zostanie zgubiony, nadawca retransmituje po czasie oczekiwania (RTO, ). RTO jest obliczane dynamicznie na podstawie różnych czynników, takich jak oczekiwana latencja RTT między nadawcą a odbiorcą.
Rysunek 4. Wymiana pakietów przez TCP/TLS obejmuje mechanizm retransmisji.
Aby określić, jak TCP działał w naszych aplikacjach, śledziliśmy pakiety TCP za pomocą przez tydzień na ruchu produkcyjnym z indyjskich serwerów brzegowych. Następnie przeanalizowaliśmy połączenia TCP za pomocą . Dodatkowo stworzyliśmy aplikację na Androida, która emituje z emulowanym ruchem do serwera testowego, maksymalnie naśladując rzeczywisty ruch. Smartfony z tą aplikacją zostały przekazane kilku pracownikom, którzy zbierali logi przez kilka dni.
Wyniki obu eksperymentów były ze sobą zgodne. Obserwowaliśmy wysokie opóźnienia RTT; wartości skrajne były prawie 6 razy wyższe od wartości mediany; średnia wartość opóźnień wynosiła ponad 1 sekundę. Wiele połączeń miało straty, co zmuszało TCP do retransmisji 3,5% wszystkich pakietów. W obszarach z przeciążeniem, takich jak lotniska i dworce, zaobserwowaliśmy 7% strat. Takie wyniki podważają powszechną opinię, że stosowane w sieciach komórkowych znacząco zmniejszają straty na poziomie transportowym. Poniżej przedstawiamy wyniki testów z aplikacji «symulującej»:
Metryki sieciowe
Wartości
RTT, milisekundy [50%, 75%, 95%, 99%]
[350, 425, 725, 2300]
Rozbieżność RTT, sekundy
Średnio ~1,2 s
Utrata pakietów w niestabilnych połączeniach
Średnio ~3,5% (7% w obszarach z przeciążeniem)
Prawie w połowie tych połączeń wystąpiła przynajmniej jedna utrata pakietów, głównie były to pakiety SYN i SYN-ACK. Większość implementacji TCP używa wartości RTO na poziomie 1 sekundy dla pakietów SYN, która zostaje eksponencjalnie zwiększona dla kolejnych strat. Czas ładowania aplikacji może się wydłużyć, ponieważ TCP potrzebuje więcej czasu na nawiązanie połączeń.
W przypadku pakietów danych, wysokie wartości RTO znacznie zmniejszają skuteczność wykorzystania sieci w przypadku tymczasowych strat w sieciach bezprzewodowych. Ustaliliśmy, że średni czas retransmisji wynosi około 1 sekundy, a opóźnienie skrajne prawie 30 sekund. Tak wysokie opóźnienia na poziomie TCP powodowały timeouty HTTPS i ponowne zapytania, co jeszcze bardziej zwiększało opóźnienie i nieefektywność sieci.
Podczas gdy 75. percentyl mierzonego RTT wynosił około 425 ms, 75. percentyl dla TCP był niemal 3 sekundy. Sugeruje to, że utraty pakietów zmuszały TCP do wykonania 7-10 prób, aby pomyślnie przesłać dane. Może to być wynikiem nieefektywnego obliczania RTO i niemożności TCP do szybkiej reakcji na utraty pakietów. w oknie i nieefektywności algorytmu zarządzania przeciążeniem, który nie rozróżnia utrat z powodu sieci bezprzewodowych i utrat z powodu przeciążenia sieci. Poniżej przedstawiamy wyniki testów strat TCP:
Statystyka utraty pakietów TCP
Wartość
Procent połączeń z co najmniej 1 utratą pakietu
45%
Procent połączeń z utratami podczas nawiązywania połączenia
30%
Procent połączeń z utratami podczas wymiany danych
76%
Rozkład opóźnień w retransmisji, sekundy [50%, 75%, 95%, 99%]
[1, 2.8, 15, 28]
Rozkład liczby retransmisji dla jednego pakietu lub segmentu TCP
[1,3,6,7]
Zastosowanie QUIC
Początkowo zaprojektowany przez Google, QUIC to nowoczesny, wielowątkowy protokół transportowy, który działa na wierzchu UDP. Obecnie QUIC jest (już pisaliśmy, że istnieją jakby dwie wersje QUIC, ciekawe osoby – przyp. tłumacza). Jak pokazano na Rysunku 5, QUIC znajduje się poniżej HTTP/3 (de facto, HTTP/2 nad QUIC to w zasadzie HTTP/3, które obecnie intensywnie się standaryzuje). Częściowo zastępuje warstwy HTTPS i TCP, używając UDP do formowania pakietów. QUIC obsługuje wyłącznie bezpieczny transfer danych, ponieważ TLS jest w pełni zintegrowany z QUIC.
Rysunek 5: QUIC działa pod HTTP/3, zastępując TLS, który wcześniej działał pod HTTP/2.
Poniżej przedstawiamy powody, które przekonały nas do użycia QUIC w celu wzmocnienia TCP:
- 0-RTT nawiązanie połączenia. QUIC umożliwia ponowne wykorzystanie autoryzacji z wcześniejszych połączeń, zmniejszając liczbę handshaków bezpieczeństwa. W przyszłości będzie wspierać 0-RTT, jednak trójstronny handshak TCP nadal będzie obowiązkowy.
- przezwyciężenie blokady HoL. HTTP/2 używa jednego połączenia TCP dla każdego klienta, aby poprawić wydajność, ale może to prowadzić do blokady HoL (head-of-line). QUIC upraszcza mnożenie i dostarcza zapytania do aplikacji niezależnie od siebie.
- zarządzanie przeciążeniem. QUIC działa na poziomie aplikacji, co pozwala na prostsze aktualizacje głównego algorytmu transportowego zarządzającego przesyłaniem danych, bazując na parametrach sieci (liczba strat lub RTT). Większość implementacji TCP korzysta z algorytmu , który nie jest optymalny dla ruchu wrażliwego na opóźnienia. Nowo opracowane algorytmy, takie jak , dokładniej modelują sieć i optymalizują opóźnienia. QUIC umożliwia wykorzystanie BBR i aktualizowanie tego algorytmu w miarę jego .
- w zakresie uzupełniania strat. QUIC wywołuje dwa TLP () zanim zadziała RTO – nawet gdy straty są bardzo odczuwalne. Różni się to od implementacji TCP. TLP retransmituje głównie ostatni pakiet (lub nowy, jeśli taki istnieje), aby uruchomić szybkie uzupełnienie. Obsługa opóźnień końcowych jest szczególnie przydatna dla działania Ubera w sieci, szczególnie przy krótkich, epizodycznych i wrażliwych na opóźnienia transferach danych.
- optymalizowany ACK. Ponieważ każdy pakiet ma unikalny numer sekwencyjny, nie pojawia się problem pakietów podczas ich retransmisji. Pakiety ACK zawierają również czas przetwarzania pakietu i generowania ACK po stronie klienta. Te cechy zapewniają, że QUIC dokładniej oblicza RTT. ACK w QUIC obsługuje do 256 zakresów , pomagając nadawcy być bardziej odpornym na przemieszanie pakietów i zużywać mniej bajtów w procesie. Selektywny ACK () w TCP nie rozwiązuje tego problemu we wszystkich przypadkach.
- migracja połączenia. Połączenia QUIC identyfikowane są za pomocą 64-bitowego ID, dzięki czemu jeśli klient zmienia adresy IP, można kontynuować użycie ID starego połączenia na nowym adresie IP bez przerwy. To bardzo powszechna praktyka w aplikacjach mobilnych, gdy użytkownik przełącza się między połączeniami Wi-Fi a komórkowymi.
Alternatywy dla QUIC
Rozważaliśmy alternatywne podejścia do rozwiązania problemu, zanim zdecydowaliśmy się na QUIC.
Na początku spróbowaliśmy uruchomić TPC PoPs (punkty obecności), aby kończyć połączenia TCP bliżej użytkowników. W zasadzie PoPs kończy połączenie TCP z urządzeniem mobilnym bliżej sieci komórkowej i przekazuje ruch do pierwotnej infrastruktury. Kończąc TCP bliżej, możemy potencjalnie zmniejszyć RTT i mieć pewność, że TCP będzie bardziej aktywnie reagować na dynamiczne otoczenie bezprzewodowe. Jednak nasze eksperymenty pokazały, że w dużej mierze RTT i straty pochodzą z sieci komórkowych, a wykorzystanie PoPs nie zapewnia znaczącej poprawy wydajności.
Przyjrzeliśmy się również tuningowi parametrów TCP. Dostosowanie stosu TCP na naszych heterogenicznych serwerach brzegowych było trudne, ponieważ TCP ma nieporównywalne implementacje w różnych wersjach systemów operacyjnych. Trudno było to zrealizować i przetestować różne konfiguracje sieciowe. Dostosowanie TCP bezpośrednio na urządzeniach mobilnych było niemożliwe z powodu braku uprawnień. Co ważniejsze, takie funkcje jak połączenia z 0-RTT i ulepszone przewidywanie RTT są krytyczne dla architektury protokołu, dlatego nie można osiągnąć znaczącej przewagi, jedynie dostosowując TCP.
W końcu oceniliśmy kilka protokołów opartych na UDP, które eliminują problemy z przesyłaniem wideo – chcieliśmy się dowiedzieć, czy te protokoły pomogą w naszym przypadku. Niestety, brakowało im wielu ustawień bezpieczeństwa, a także wymagały dodatkowego połączenia TCP do metadanych i informacji sterujących.
Nasze badania pokazały, że QUIC jest prawdopodobnie jedynym protokołem, który może pomóc w problemie ruchu internetowego, uwzględniając zarówno bezpieczeństwo, jak i wydajność.
Integracja QUIC z platformą
Aby pomyślnie zaimplementować QUIC i poprawić wydajność aplikacji w warunkach słabego połączenia, zastąpiliśmy stary stos (HTTP/2 nad TLS/TCP) protokołem QUIC. Skorzystaliśmy z biblioteki sieciowej z , która zawiera oryginalną, google'owską wersję protokołu – gQUIC. Ta implementacja jest również stale ulepszana, aby przestrzegać najnowszej specyfikacji IETF.
Najpierw zintegrowaliśmy Cronet w naszych aplikacjach na Androida, aby dodać wsparcie dla QUIC. Integracja została przeprowadzona w sposób, aby maksymalnie ograniczyć koszty migracji. Zamiast całkowicie zastąpić stary stos sieciowy, który korzystał z biblioteki , zintegrowaliśmy Cronet POD frameworkiem OkHttp API. Przeprowadzając integrację w ten sposób, uniknęliśmy zmian w naszych wywołaniach sieciowych (które używają ) na poziomie API.
Podobnie jak w przypadku urządzeń z Androidem, wdrożyliśmy Cronet w aplikacjach Uber na iOS, przechwytując ruch HTTP z , używając . Ta abstrakcja, dostarczana przez iOS Foundation, obsługuje specyficzne dla protokołu dane URL i zapewnia, że możemy zintegrować Cronet w naszych aplikacjach na iOS bez znacznych kosztów migracji.
Kończenie QUIC na zrównoważonych obciążeniach Google Cloud
Po stronie zaplecza, zakończenie QUIC jest zapewnione przez infrastrukturę zrównoważonego obciążenia Google Cloud, która wykorzystuje Nagłówki w odpowiedziach do wsparcia QUIC. Generalnie, do każdego żądania HTTP, load balancer dodaje nagłówek alt-svc, który weryfikuje wsparcie QUIC dla domeny. Gdy klient Cronet otrzymuje odpowiedź HTTP z takim nagłówkiem, korzysta z QUIC dla kolejnych żądań HTTP do tej domeny. Gdy tylko load balancer kończy QUIC, nasza infrastruktura wyraźnie przekazuje to działanie przez HTTP2/TCP do naszych centrów danych.
Wydajność: wyniki
Wydawana wydajność jest głównym powodem naszego poszukiwania lepszego protokołu. Na początek stworzyliśmy stanowisko z , aby sprawdzić, jak zachowa się QUIC przy różnych profilach sieciowych. Aby przetestować działanie QUIC w rzeczywistych sieciach, przeprowadziliśmy eksperymenty jeżdżąc po New Delhi, wykorzystując przy tym emulowany ruch sieciowy, bardzo podobny do wywołań HTTP w aplikacji pasażera.
Eksperyment 1
Inwentarz do eksperymentu:
- testowe urządzenia na Androidzie ze stosami OkHttp i Cronet, aby upewnić się, że przekazujemy ruch HTTPS przez TCP i QUIC odpowiednio;
- serwer emulacji oparty na Javie, który wysyła jednolite nagłówki HTTPS w odpowiedziach i obciąża urządzenia klienckie, aby otrzymać od nich zapytania;
- chmurowe proxy, które fizycznie znajdują się blisko Indii, aby kończyć połączenia TCP i QUIC. Podczas gdy do kończenia TCP używaliśmy odwrotnego proxy na , trudnością było znalezienie otwartoźródłowego odwrotnego proxy dla QUIC. Samodzielnie stworzyliśmy odwrotne proxy dla QUIC, wykorzystując podstawowy stos QUIC z Chromium i udostępniliśmy go w Chromium jako otwartoźródłowe.
Rysunek 6. Zestaw testowy dla TCP vs QUIC składał się z urządzeń z Androidem z OkHttp i Cronet, chmurowych proxy do kończenia połączeń oraz serwera emulacji.
Eksperyment 2
Gdy Google udostępnił QUIC przez , użyliśmy tego samego inwentarza, ale z jedną modyfikacją: zamiast NGINX, użyliśmy load balancerów Google do kończenia połączeń TCP i QUIC z urządzeń oraz do kierowania ruchu HTTPS do serwera emulacji. Load balancery są rozproszone po całym świecie, ale wykorzystują najbliższy do urządzenia serwer PoP (dzięki geolokalizacji).
Rysunek 7. W drugim eksperymencie chcieliśmy porównać opóźnienia kończenia TCP i QUIC: z pomocą Google Cloud i z pomocą naszego chmurowego proxy.
W rezultacie przyniosło to kilka odkryć:
- kończenie przez PoP poprawiło wydajność TCP. Ponieważ load balancery kończą połączenie TCP bliżej użytkowników i są doskonale zoptymalizowane, prowadzi to do mniejszych RTT, co poprawia wydajność TCP. Chociaż na QUIC miało to mniejszy wpływ, wciąż przewyższa TCP pod względem redukcji opóźnień ogonowych (o 10-30 procent).
- na ogony wpływają . Chociaż nasz proxy QUIC był dalej od urządzeń (opóźnienie około 50 ms wyższe) niż load balancery Google'a, osiągnął zbliżoną wydajność – 15% redukcji opóźnień w porównaniu do 20% redukcji w 99. percentylu w przypadku TCP. To sugeruje, że przejście na ostatniej mili jest wąskim gardłem (bottleneck) w pracy sieci.
Rysunek 8. Wyniki dwóch eksperymentów pokazują, że QUIC znacznie przewyższa TCP.
Ruch operacyjny
Zainspirowani eksperymentami, wdrożyliśmy obsługę QUIC w naszych aplikacjach na Androida i iOS. Przeprowadziliśmy testy A/B, aby ocenić wpływ QUIC w miastach, w których działa Uber. Ogólnie zauważyliśmy znaczną redukcję opóźnień ogonowych zarówno w regionach, jak i u operatorów oraz typów sieci.
Na poniższych wykresach pokazane są procentowe poprawy ogonów (95 i 99 percentyl) w makroregionach oraz różnych typach sieci – LTE, 3G, 2G.
Rysunek 9. W testach operacyjnych QUIC przewyższył TCP pod względem opóźnień.
Tylko naprzód
To dopiero początek – wdrożenie QUIC w produkcji dało niesamowite możliwości poprawy wydajności aplikacji zarówno w stabilnych, jak i niestabilnych sieciach, a mianowicie:
Zwiększenie zasięgu
Analizując wydajność protokołu w rzeczywistym ruchu, zauważyliśmy, że około 80% sesji skutecznie korzystało z QUIC dla wszystkich żądań, podczas gdy 15% sesji korzystało z połączenia QUIC i TCP. Zakładamy, że połączenie to powstało, ponieważ biblioteka Cronet przełącza się ponownie na TCP po upływie czasu, ponieważ nie może rozróżnić rzeczywistych awarii UDP i złych warunków sieciowych. Obecnie szukamy rozwiązania tego problemu, pracując nad dalszym wdrażaniem QUIC.
Optymalizacja QUIC
Ruch z aplikacji mobilnych jest wrażliwy na opóźnienia, ale nie na przepustowość. Również nasze aplikacje są głównie używane w sieciach komórkowych. Na podstawie eksperymentów, opóźnienia długiego ogona są nadal duże, nawet mimo używania serwerów proxy do finalizacji TCP i QUIC blisko użytkowników. Aktywnie poszukujemy sposobów na poprawę zarządzania przeciążeniami i zwiększenie efektywności algorytmów rekonstrukcji strat w QUIC.
Dzięki tym i kilku innym ulepszeniom planujemy poprawić doświadczenia użytkowników niezależnie od sieci i regionu, czyniąc wygodny i bezproblemowy transport pakietów bardziej dostępnym na całym świecie.
Źródło: habr.com
