Protokół QUIC jest niezwykle ciekawy do oglądania, dlatego uwielbiamy o nim pisać. Jeśli jednak poprzednie publikacje na temat QUIC miały charakter bardziej historyczny (lokalna historia, jeśli wolicie) i sprzętowy, dziś z radością publikujemy tłumaczenie innego rodzaju – porozmawiamy o rzeczywistym zastosowaniu protokołu w 2019 roku. Co więcej, nie mówimy tu o małej infrastrukturze opartej na tzw. garażu, ale o Uberze, który działa niemal na całym świecie. Jak inżynierowie firmy podjęli decyzję o zastosowaniu QUIC w produkcji, jak przeprowadzili testy i co zobaczyli po wdrożeniu go do produkcji – poniżej nacięcia.
Zdjęcia można kliknąć. Miłego czytania!
Uber ma skalę globalną, czyli jest obecny w 600 miastach, w każdym z których aplikacja w całości opiera się na bezprzewodowym Internecie od ponad 4500 operatorów komórkowych. Użytkownicy oczekują, że aplikacja będzie działać nie tylko szybko, ale także w czasie rzeczywistym – aby to osiągnąć, aplikacja Ubera potrzebuje małych opóźnień i bardzo niezawodnego połączenia. Niestety, ale stos nie radzi sobie dobrze w dynamicznych i podatnych na straty sieciach bezprzewodowych. Zdaliśmy sobie sprawę, że w tym przypadku niska wydajność jest bezpośrednio związana z implementacją protokołu TCP w jądrach systemu operacyjnego.
Aby rozwiązać problem, złożyliśmy wniosek , nowoczesny protokół multipleksowania kanałów, który daje nam większą kontrolę nad wydajnością protokołu transportowego. Obecnie grupa robocza standaryzuje QUIC as .
Po szeroko zakrojonych testach doszliśmy do wniosku, że wdrożenie QUIC w naszej aplikacji spowoduje mniejsze opóźnienia końcowe w porównaniu z protokołem TCP. Zaobserwowaliśmy redukcję w zakresie 10-30% dla ruchu HTTPS w aplikacjach kierowcy i pasażera. QUIC zapewnił nam także kompleksową kontrolę nad pakietami użytkowników.
W tym artykule dzielimy się naszym doświadczeniem w optymalizacji protokołu TCP dla aplikacji Ubera przy użyciu stosu obsługującego QUIC.
Najnowsza technologia: TCP
Obecnie TCP jest najczęściej używanym protokołem transportowym do dostarczania ruchu HTTPS w Internecie. TCP zapewnia niezawodny strumień bajtów, radząc sobie w ten sposób z przeciążeniem sieci i stratami w warstwie łącza. Powszechne wykorzystanie protokołu TCP dla ruchu HTTPS wynika z jego wszechobecności (prawie każdy system operacyjny zawiera protokół TCP), dostępności w większości infrastruktury (takiej jak moduły równoważenia obciążenia, serwery proxy HTTPS i sieci CDN) oraz dostępnej od razu po wyjęciu z pudełka funkcjonalności na prawie większości platform i sieci.
Większość użytkowników korzysta z naszej aplikacji w drodze, a opóźnienia końcowe protokołu TCP nie były nawet zbliżone do wymagań naszego ruchu HTTPS w czasie rzeczywistym. Mówiąc najprościej, doświadczyli tego użytkownicy na całym świecie – rysunek 1 pokazuje opóźnienia w największych miastach:
Rysunek 1: Opóźnienie końcowe różni się w zależności od głównych miast Ubera.
Chociaż opóźnienie w sieciach indyjskich i brazylijskich było wyższe niż w USA i Wielkiej Brytanii, opóźnienie końcowe jest znacznie wyższe niż średnie opóźnienie. Dotyczy to nawet Stanów Zjednoczonych i Wielkiej Brytanii.
Wydajność protokołu TCP w trybie bezprzewodowym
TCP został stworzony dla przewodowy sieci, czyli z naciskiem na wysoce przewidywalne łącza. Jednakże, bezprzewodowy sieci mają swoją własną charakterystykę i trudności. Po pierwsze, sieci bezprzewodowe są podatne na straty spowodowane zakłóceniami i tłumieniem sygnału. Na przykład sieci Wi-Fi są wrażliwe na mikrofale, Bluetooth i inne fale radiowe. Sieci komórkowe cierpią z powodu utraty sygnału () na skutek odbicia/absorpcji sygnału przez przedmioty i budynki, a także od od sąsiada . Prowadzi to do bardziej znaczących (4-10 razy) i bardziej zróżnicowanych i utratę pakietów w porównaniu z połączeniem przewodowym.
Aby zapobiec wahaniom i stratom przepustowości, sieci komórkowe zazwyczaj korzystają z dużych buforów dla impulsów ruchu. Może to prowadzić do nadmiernych kolejek, co oznacza większe opóźnienia. Bardzo często protokół TCP traktuje kolejkowanie jako marnotrawstwo ze względu na wydłużony limit czasu, więc TCP ma tendencję do przekazywania i w ten sposób wypełniania bufora. Problem ten znany jest jako () i to bardzo nowoczesnego Internetu.
Wreszcie wydajność sieci komórkowej różni się w zależności od operatora, regionu i czasu. Na rysunku 2 zebraliśmy medianę opóźnień ruchu HTTPS pomiędzy komórkami w promieniu 2 km. Dane zebrane dla dwóch głównych operatorów komórkowych w Delhi w Indiach. Jak widać, wydajność różni się w zależności od komórki. Ponadto produktywność jednego operatora różni się od produktywności drugiego. Wpływ na to mają takie czynniki, jak wzorce wejścia do sieci uwzględniające czas i lokalizację, mobilność użytkowników, a także infrastruktura sieciowa uwzględniająca gęstość wież i stosunek typów sieci (LTE, 3G itp.).
Rysunek 2. Opóźnienia na przykładzie promienia 2 km. Delhi, Indie.
Ponadto wydajność sieci komórkowych zmienia się w czasie. Rysunek 3 przedstawia medianę opóźnienia według dnia tygodnia. Zaobserwowaliśmy także różnice w mniejszej skali, w obrębie jednego dnia i godziny.
Rysunek 3. Opóźnienia końcowe mogą znacznie się różnić w zależności od dnia, ale w przypadku tego samego operatora.
Wszystko to powoduje, że wydajność protokołu TCP jest nieefektywna w sieciach bezprzewodowych. Zanim jednak zaczniemy szukać alternatyw dla protokołu TCP, chcieliśmy dokładnie poznać następujące punkty:
- czy protokół TCP jest głównym winowajcą opóźnień końcowych w naszych aplikacjach?
- Czy nowoczesne sieci charakteryzują się znacznymi i zróżnicowanymi opóźnieniami w obie strony (RTT)?
- Jaki jest wpływ czasu RTT i strat na wydajność protokołu TCP?
Analiza wydajności protokołu TCP
Aby zrozumieć, w jaki sposób analizowaliśmy wydajność protokołu TCP, rzućmy okiem na to, jak protokół TCP przesyła dane od nadawcy do odbiorcy. Najpierw nadawca ustanawia połączenie TCP, wykonując połączenie trójstronne : Nadawca wysyła pakiet SYN, czeka na pakiet SYN-ACK od odbiorcy, a następnie wysyła pakiet ACK. Na ustanowienie połączenia TCP potrzebny jest dodatkowy drugi i trzeci przebieg. Odbiorca potwierdza odbiór każdego pakietu (ACK), aby zapewnić niezawodną dostawę.
Jeżeli pakiet lub potwierdzenie zostanie utracone, nadawca ponowi transmisję po upływie limitu czasu (RTO, ). RTO jest obliczane dynamicznie na podstawie różnych czynników, takich jak oczekiwane opóźnienie RTT między nadawcą a odbiorcą.
Rysunek 4. Wymiana pakietów przez protokół TCP/TLS obejmuje mechanizm retransmisji.
Aby określić, jak protokół TCP działał w naszych aplikacjach, monitorowaliśmy pakiety TCP za pomocą przez tydzień na ruchu bojowym pochodzącym z indyjskich serwerów brzegowych. Następnie przeanalizowaliśmy połączenia TCP za pomocą . Dodatkowo stworzyliśmy aplikację na Androida, która wysyła emulowany ruch na serwer testowy, maksymalnie imitując ruch rzeczywisty. Smartfony z tą aplikacją zostały rozdane kilku pracownikom, którzy przez kilka dni zbierali logi.
Wyniki obu eksperymentów były ze sobą spójne. Zaobserwowaliśmy duże opóźnienia RTT; wartości końcowe były prawie 6 razy wyższe od wartości mediany; średnia arytmetyczna opóźnień jest większa niż 1 sekunda. Wiele połączeń było stratnych, co spowodowało, że protokół TCP retransmitował 3,5% wszystkich pakietów. W zatłoczonych obszarach, takich jak lotniska i dworce kolejowe, zaobserwowaliśmy straty na poziomie 7%. Wyniki te podają w wątpliwość konwencjonalną wiedzę stosowaną w sieciach komórkowych znacząco ograniczają straty na poziomie transportu. Poniżej wyniki testów aplikacji „symulator”:
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 na niestabilnych połączeniach
Średnio ~3.5% (7% w obszarach przeciążonych)
Prawie połowa tych połączeń utraciła co najmniej jeden pakiet, większość z nich to pakiety SYN i SYN-ACK. Większość implementacji protokołu TCP wykorzystuje wartość RTO wynoszącą 1 sekundę dla pakietów SYN, która wzrasta wykładniczo w przypadku kolejnych strat. Czas ładowania aplikacji może się wydłużyć, ponieważ protokół TCP potrzebuje więcej czasu na nawiązanie połączeń.
W przypadku pakietów danych wysokie wartości RTO znacznie zmniejszają użyteczne wykorzystanie sieci w przypadku przejściowych strat w sieciach bezprzewodowych. Ustaliliśmy, że średni czas retransmisji wynosi około 1 sekundy, a opóźnienie końcowe wynosi prawie 30 sekund. Te duże opóźnienia na poziomie protokołu TCP powodowały przekroczenia limitu czasu protokołu HTTPS i ponowne żądania, co jeszcze bardziej zwiększyło opóźnienia i nieefektywność sieci.
Podczas gdy 75. percentyl zmierzonego RTT wynosił około 425 ms, 75. percentyl dla TCP wynosił prawie 3 sekundy. Wskazuje to, że strata spowodowała, że protokół TCP potrzebował 7–10 przebiegów, aby pomyślnie przesłać dane. Może to być konsekwencją nieefektywnego obliczania RTO, niemożności szybkiego reagowania protokołu TCP na stratę w oknie oraz nieefektywność algorytmu kontroli przeciążenia, który nie rozróżnia strat w sieci bezprzewodowej od strat spowodowanych przeciążeniem sieci. Poniżej znajdują się wyniki testów utraty protokołu TCP:
Statystyki utraty pakietów TCP
Wartość
Procent połączeń, w przypadku których utracono co najmniej 1 pakiet
45%
Procent połączeń ze stratami podczas konfiguracji połączenia
30%
Procent połączeń ze stratami 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
QUIC, pierwotnie opracowany przez Google, to wielowątkowy nowoczesny protokół transportowy działający w oparciu o protokół UDP. Obecnie QUIC jest dostępny (pisaliśmy już, że istnieją jakby dwie wersje QUIC-a, ciekawe - około. tłumacz). Jak pokazano na rysunku 5, QUIC należy do protokołu HTTP/3 (w rzeczywistości HTTP/2 nad QUIC to HTTP/3, który jest obecnie intensywnie standaryzowany). Częściowo zastępuje warstwy HTTPS i TCP, używając protokołu UDP do tworzenia pakietów. QUIC obsługuje tylko bezpieczny transfer danych, ponieważ protokół TLS jest w pełni wbudowany w QUIC.
Rysunek 5: QUIC działa pod protokołem HTTP/3, zastępując protokół TLS, który wcześniej działał pod protokołem HTTP/2.
Poniżej znajdują się powody, które przekonały nas do użycia QUIC do wzmacniania TCP:
- Nawiązanie połączenia 0-RTT. QUIC umożliwia ponowne wykorzystanie autoryzacji z poprzednich połączeń, redukując liczbę uzgadniań bezpieczeństwa. W przyszłości będzie obsługiwać 0-RTT, ale nadal wymagane będzie trójstronne uzgadnianie protokołu TCP.
- przezwyciężenie blokady HoL. HTTP/2 wykorzystuje jedno połączenie TCP na klienta w celu poprawy wydajności, ale może to prowadzić do blokowania HoL (head-of-line). QUIC upraszcza multipleksowanie i niezależnie dostarcza żądania do aplikacji.
- kontrola zatorów. QUIC znajduje się w warstwie aplikacji, ułatwiając aktualizację głównego algorytmu transportu, który kontroluje wysyłanie w oparciu o parametry sieci (liczba strat lub RTT). Większość implementacji protokołu TCP korzysta z algorytmu , co nie jest optymalne w przypadku ruchu wrażliwego na opóźnienia. Ostatnio opracowane algorytmy, takie jak , dokładniej modeluj sieć i optymalizuj opóźnienia. QUIC pozwala na użycie BBR i aktualizację tego algorytmu w miarę jego używania. .
- uzupełnienie strat. QUIC wywołuje dwa TLP () przed uruchomieniem RTO – nawet jeśli straty są bardzo zauważalne. Różni się to od implementacji protokołu TCP. TLP retransmituje głównie ostatni pakiet (lub nowy, jeśli taki istnieje), aby wywołać szybkie uzupełnienie. Obsługa opóźnień końcowych jest szczególnie przydatna w przypadku sposobu, w jaki Uber obsługuje swoją sieć, a mianowicie w przypadku krótkich, sporadycznych i wrażliwych na opóźnienia transferów danych.
- zoptymalizowane potwierdzenie. Ponieważ każdy pakiet ma unikalny numer kolejny, nie ma problemu pakietów podczas ich retransmisji. Pakiety ACK zawierają również czas na przetworzenie pakietu i wygenerowanie potwierdzenia po stronie klienta. Dzięki tym funkcjom QUIC dokładniej oblicza RTT. ACK w QUIC obsługuje do 256 pasm , dzięki czemu nadawca może być bardziej odporny na tasowanie pakietów i zużywać w tym procesie mniej bajtów. Selektywne potwierdzenie () w protokole TCP nie rozwiązuje tego problemu we wszystkich przypadkach.
- migracja połączenia. Połączenia QUIC są identyfikowane za pomocą 64-bitowego identyfikatora, więc jeśli klient zmieni adres IP, stary identyfikator połączenia może być nadal używany z nowym adresem IP bez zakłóceń. Jest to bardzo powszechna praktyka w aplikacjach mobilnych, w których użytkownik przełącza się między połączeniami Wi-Fi i komórkowymi.
Alternatywa dla QUIC
Przed wybraniem QUIC rozważyliśmy alternatywne podejścia do rozwiązania problemu.
Pierwszą rzeczą, którą próbowaliśmy, było wdrożenie TPC PoP (punktów obecności), aby zakończyć połączenia TCP bliżej użytkowników. Zasadniczo punkty PoP kończą połączenie TCP z urządzeniem mobilnym bliżej sieci komórkowej i przekazują ruch z powrotem do pierwotnej infrastruktury. Zakończając bliżej protokół TCP, możemy potencjalnie zmniejszyć czas RTT i zapewnić, że protokół TCP będzie lepiej reagował na dynamiczne środowisko bezprzewodowe. Jednak nasze eksperymenty wykazały, że większość czasu RTT i strat pochodzi z sieci komórkowych, a użycie PoP nie zapewnia znaczącej poprawy wydajności.
Przyjrzeliśmy się także dostrajaniu parametrów protokołu TCP. Konfigurowanie stosu TCP na naszych heterogenicznych serwerach brzegowych było trudne, ponieważ protokół TCP ma różne implementacje w różnych wersjach systemów operacyjnych. Trudno było to wdrożyć i przetestować różne konfiguracje sieci. Konfiguracja protokołu TCP bezpośrednio na urządzeniach mobilnych nie była możliwa ze względu na brak uprawnień. Co ważniejsze, funkcje takie jak połączenia 0-RTT i ulepszone przewidywanie RTT mają kluczowe znaczenie dla architektury protokołu i dlatego niemożliwe jest osiągnięcie znaczących korzyści poprzez dostrajanie samego protokołu TCP.
Na koniec oceniliśmy kilka protokołów opartych na UDP, które rozwiązują problemy ze strumieniowaniem wideo — chcieliśmy sprawdzić, 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 dla metadanych i informacji kontrolnych.
Nasze badania wykazały, że QUIC jest być może jedynym protokołem, który może pomóc w rozwiązaniu problemu ruchu internetowego, biorąc pod uwagę zarówno bezpieczeństwo, jak i wydajność.
Integracja QUIC z platformą
Aby pomyślnie osadzić QUIC i poprawić wydajność aplikacji w środowiskach o słabej łączności, zastąpiliśmy stary stos (HTTP/2 przez TLS/TCP) protokołem QUIC. Korzystaliśmy z biblioteki sieciowej z , który zawiera oryginalną, Google wersję protokołu - gQUIC. Ta implementacja jest również stale udoskonalana, aby była zgodna z najnowszą specyfikacją IETF.
Najpierw zintegrowaliśmy Cronet z naszymi aplikacjami na Androida, aby dodać obsługę QUIC. Integracja została przeprowadzona w taki sposób, aby w jak największym stopniu obniżyć koszty migracji. Zamiast całkowicie zastąpić stary stos sieciowy, który korzystał z biblioteki , zintegrowaliśmy Cronet W RAMACH frameworku OkHttp API. Wykonując integrację w ten sposób, uniknęliśmy zmian w naszych połączeniach sieciowych (z których korzystają ) na poziomie API.
Podobnie jak w przypadku urządzeń z systemem Android, zaimplementowaliśmy Cronet w aplikacjach Ubera na iOS, przechwytując ruch HTTP z sieci Korzystanie . Ta abstrakcja, dostarczona przez iOS Foundation, obsługuje dane URL specyficzne dla protokołu i zapewnia, że możemy zintegrować Cronet z naszymi aplikacjami iOS bez znacznych kosztów migracji.
Ukończenie testu QUIC w Google Cloud Balancers
Po stronie backendu realizację QUIC zapewnia infrastruktura równoważenia obciążenia Google Cloud, która wykorzystuje nagłówki w odpowiedziach obsługujących QUIC. Ogólnie rzecz biorąc, moduł równoważący dodaje nagłówek alt-svc do każdego żądania HTTP, co już sprawdza obsługę QUIC dla domeny. Kiedy klient Cronet otrzymuje odpowiedź HTTP z tym nagłówkiem, używa QUIC do kolejnych żądań HTTP kierowanych do tej domeny. Gdy moduł równoważący zakończy QUIC, nasza infrastruktura jawnie wysyła tę akcję za pośrednictwem protokołu HTTP2/TCP do naszych centrów danych.
Wydajność: Wyniki
Wydajność wyjściowa jest głównym powodem naszych poszukiwań lepszego protokołu. Na początek stworzyliśmy stoisko z aby dowiedzieć się, jak QUIC będzie się zachowywał w różnych profilach sieciowych. Aby przetestować działanie QUIC w rzeczywistych sieciach, przeprowadziliśmy eksperymenty podczas jazdy po New Delhi, korzystając z emulowanego ruchu sieciowego, bardzo podobnego do wywołań HTTP w aplikacji dla pasażerów.
Eksperyment 1
Sprzęt do eksperymentu:
- przetestuj urządzenia z Androidem za pomocą stosów OkHttp i Cronet, aby upewnić się, że zezwalamy na ruch HTTPS odpowiednio przez TCP i QUIC;
- serwer emulacji oparty na Javie, który wysyła w odpowiedziach ten sam typ nagłówków HTTPS i ładuje urządzenia klienckie w celu odbierania od nich żądań;
- serwery proxy w chmurze, które są fizycznie zlokalizowane w pobliżu Indii w celu kończenia połączeń TCP i QUIC. Podczas gdy do zakończenia protokołu TCP użyliśmy odwrotnego proxy , trudno było znaleźć odwrotne proxy typu open source dla QUIC. Sami zbudowaliśmy odwrotne proxy dla QUIC, używając podstawowego stosu QUIC z Chromium i go do chromu jako open source.
Rysunek 6. Zestaw testów drogowych TCP i QUIC składał się z urządzeń z systemem Android z OkHttp i Cronet, serwerów proxy w chmurze do kończenia połączeń oraz serwera emulacji.
Eksperyment 2
Kiedy Google udostępnił QUIC w , użyliśmy tego samego inwentarza, ale z jedną modyfikacją: zamiast NGINX wzięliśmy moduły równoważenia obciążenia Google, aby zakończyć połączenia TCP i QUIC z urządzeń, a także skierować ruch HTTPS do serwera emulacji. Balancery są dystrybuowane na całym świecie, ale korzystają z serwera PoP znajdującego się najbliżej urządzenia (dzięki geolokalizacji).
Rysunek 7. W drugim eksperymencie chcieliśmy porównać opóźnienie zakończenia TCP i QUIC: przy użyciu Google Cloud i naszego serwera proxy w chmurze.
W rezultacie czekało na nas kilka rewelacji:
- zakończenie poprzez PoP poprawiło wydajność protokołu TCP. Ponieważ moduły równoważące kończą połączenia TCP bliżej użytkowników i są wysoce zoptymalizowane, skutkuje to niższymi czasami RTT, co poprawia wydajność protokołu TCP. I chociaż QUIC był mniej dotknięty, nadal działał lepiej niż TCP pod względem zmniejszania opóźnień ogona (o 10–30 procent).
- ogony są dotknięte . Chociaż nasz serwer proxy QUIC znajdował się dalej od urządzeń (opóźnienie większe o około 50 ms) niż moduły równoważenia obciążenia Google, zapewniał podobną wydajność — zmniejszenie opóźnień o 15% w porównaniu z redukcją 20% w 99. percentylu w przypadku protokołu TCP. Sugeruje to, że przejście ostatniej mili stanowi wąskie gardło w sieci.
Rysunek 8: Wyniki dwóch eksperymentów pokazują, że QUIC znacznie przewyższa TCP.
Ruch bojowy
Zainspirowani eksperymentami wdrożyliśmy obsługę QUIC w naszych aplikacjach na Androida i iOS. Przeprowadziliśmy testy A/B, aby określić wpływ QUIC w miastach, w których działa Uber. Ogólnie rzecz biorąc, zaobserwowaliśmy znaczną redukcję opóźnień końcowych w obu regionach, operatorach telekomunikacyjnych i typie sieci.
Poniższe wykresy pokazują procentową poprawę ogonów (95 i 99 percentyli) według makroregionu i różnych typów sieci - LTE, 3G, 2G.
Rysunek 9. W testach bojowych QUIC uzyskał lepsze wyniki niż TCP pod względem opóźnień.
Tylko naprzód
Być może to dopiero początek – wypuszczenie QUICa do produkcji dało niesamowite możliwości poprawy wydajności aplikacji zarówno w sieciach stabilnych, jak i niestabilnych, a mianowicie:
Zwiększony zasięg
Po przeanalizowaniu wydajności protokołu w rzeczywistym ruchu zauważyliśmy, że około 80% sesji z powodzeniem korzystało z QUIC wszystko żądań, podczas gdy 15% sesji korzystało z kombinacji QUIC i TCP. Zakładamy, że przyczyną tej kombinacji jest przekroczenie limitu czasu biblioteki Cronet z powrotem do protokołu TCP, ponieważ nie jest ona w stanie rozróżnić pomiędzy rzeczywistymi awariami protokołu UDP a złymi warunkami sieci. Obecnie szukamy rozwiązania tego problemu, pracując nad późniejszym wdrożeniem QUIC.
Optymalizacja QUIC
Ruch z aplikacji mobilnych jest wrażliwy na opóźnienia, ale nie wrażliwy na przepustowość. Ponadto nasze aplikacje są używane głównie w sieciach komórkowych. Z eksperymentów wynika, że opóźnienia w ogonie są nadal wysokie, nawet w przypadku używania serwera proxy do kończenia protokołów TCP i QUIC w pobliżu użytkowników. Aktywnie poszukujemy sposobów na usprawnienie zarządzania przeciążeniami i poprawę efektywności algorytmów odzyskiwania strat QUIC.
Dzięki tym i kilku innym ulepszeniom planujemy poprawić komfort użytkownika niezależnie od sieci i regionu, czyniąc wygodny i płynny transport pakietów bardziej dostępnym na całym świecie.
Źródło: www.habr.com