Protokół QUIC

Wprowadzenie: Budowa Lepszego Samochodu na Internetową Superautostradę

Przez wiele lat TCP było niezawodnym rodzinnym sedanem internetu. Jest bezpieczne, godne zaufania i dostarcza Twoje dane tam, gdzie powinny trafić. Jednak w miarę jak internet przekształcał się z cichych wiejskich dróg w złożony globalny system superautostrad, ograniczenia tego klasycznego projektu stawały się coraz bardziej widoczne. Czas nawiązywania połączenia był zbyt długi, jeden zepsuty samochód mógł zablokować cały pas, a modernizacja silnika wymagała oczekiwania, aż każda fabryka samochodów (system operacyjny) na świecie przezbroi swoje linie produkcyjne.

To skłoniło inżynierów, na czele z innowatorami z Google, do zadania radykalnego pytania: Co by było, gdyby zamiast łatać stary sedan, zbudować zupełnie nowy, wysokowydajny pojazd od podstaw? Co by było, gdyby zacząć od lekkiej, minimalistycznej ramy gokarta (UDP) i zbudować na niej najnowocześniejszy system transportowy, ze wszystkimi funkcjami niezawodności, bezpieczeństwa i wydajności, jakich potrzebujemy we współczesnej sieci?

Odpowiedzią na to pytanie jest QUIC. Zgodnie z RFC 9000 jest to nazwa protokołu, a nie skrót od Quick UDP Internet Connections. QUIC działa nad UDP, lecz sam zapewnia niezawodność, kontrolę przeciążenia, wiele niezależnych strumieni i obowiązkowe mechanizmy kryptograficzne oparte na TLS 1.3. Implementacja w przestrzeni użytkownika ułatwia aktualizowanie protokołu bez oczekiwania na zmianę stosu TCP w systemie operacyjnym. QUIC stanowi warstwę transportową dla HTTP/3.

Problemy, Które QUIC Miał Rozwiązać: Stary Stos TCP+TLS

Aby w pełni docenić geniusz QUIC, musimy najpierw zrozumieć głęboko zakorzenione problemy, które miał on na celu naprawić. Tradycyjny stos dla bezpiecznego ruchu internetowego obejmuje działanie TCP, z oddzielną warstwą bezpieczeństwa, TLS (Transport Layer Security), na wierzchu. Ta kombinacja, choć bezpieczna, cierpi na kilka poważnych wąskich gardeł wydajnościowych.

1. Opóźnienie Nawiązywania Połączenia

Wczytanie bezpiecznej strony internetowej wymaga wieloetapowej konwersacji, która obejmuje wiele podróży w obie strony przez sieć.

• Uzgadnianie TCP: Po pierwsze, TCP musi nawiązać swoje połączenie. Wymaga to słynnego trójetapowego uzgadniania (SYN, SYN-ACK, ACK), które zużywa jeden pełny Czas Obiegu (RTT). W tym czasie nie można przesyłać żadnych danych.
• Uzgadnianie TLS: Po nawiązaniu połączenia TCP warstwa TLS musi przeprowadzić własne, oddzielne uzgadnianie w celu uwierzytelnienia serwera i negocjacji kluczy szyfrujących. W zależności od wersji i tego, czy używane jest wznowienie sesji, może to zająć od jednego do dwóch dodatkowych RTT.

W najlepszym przypadku potrzeba co najmniej dwóch pełnych podróży przez internet, zanim przeglądarka będzie mogła wysłać swoje pierwsze żądanie o stronę. W sieci mobilnej o dużym opóźnieniu może to oznaczać setki milisekund martwego czasu, sprawiając, że użytkownik postrzega sieć jako powolną.

2. Blokowanie na Czele Kolejki w TCP

Jak omówiliśmy przy SCTP, największą wadą wydajnościową TCP jest Blokowanie na Czele Kolejki (HOLB). TCP zapewnia pojedynczy, ściśle uporządkowany strumień bajtów. Nowoczesne strony internetowe nie są pojedynczymi obiektami; składają się z setek niezależnych zasobów (HTML, pliki CSS, JavaScript, dziesiątki obrazów). Dzięki HTTP/2 wszystkie te zasoby mogą być multipleksowane przez jedno połączenie TCP w celu poprawy wydajności.

Jednakże wszystkie one wciąż podróżują tą samą jednopasmową autostradą TCP. Jeśli jeden pakiet przenoszący część pliku obrazu zostanie utracony, TCP zatrzymuje całą linię montażową. Nie dostarczy CSS ani JavaScript, nawet jeśli te pakiety dotarły już bezpiecznie. Wszystko staje w miejscu, czekając na retransmisję tego jednego utraconego pakietu z obrazem. To sprawia, że TCP słabo nadaje się do zmultipleksowanej natury współczesnej sieci WWW.

3. Implementacja w Przestrzeni Jądra i Usztywnienie Protokołu

TCP jest kluczową częścią prawie każdego systemu operacyjnego na świecie, zaimplementowaną głęboko w jądrze systemu operacyjnego. To czyni go wysoce zoptymalizowanym i stabilnym, ale także niezwykle trudnym i powolnym w ewolucji.

Aby wdrożyć nową funkcję dla TCP, trzeba by było, aby wszyscy główni dostawcy systemów operacyjnych (Microsoft, Apple, społeczność Linuksa) zgodzili się na nią, zaimplementowali ją, a następnie trzeba by czekać, aż miliardy użytkowników zaktualizują swoje systemy operacyjne. Ten proces może trwać lata, jeśli nie dekady. To powolne tempo innowacji oznacza, że TCP często tkwi w przestarzałych zachowaniach. Ponadto wiele pośrednich urządzeń sieciowych (firewalle, urządzenia NAT) jest zaprogramowanych tak, aby oczekiwać, że ruch TCP będzie wyglądał w określony sposób, i mogą blokować lub zakłócać wszelkie nowe rozszerzenia TCP, co jest problemem znanym jako usztywnienie protokołu (ang. protocol ossification).

Architektura QUIC: Niezawodność w Warstwie Aplikacji

Rozwiązanie QUIC na te problemy jest radykalne i eleganckie: przenosi większość logiki warstwy transportowej z jądra i buduje ją bezpośrednio na UDP.

Używając UDP jako fundamentu, QUIC zyskuje kilka kluczowych przewag:

• Omijanie Jądra: QUIC jest implementowany jako biblioteka w aplikacjach, takich jak przeglądarki internetowe i serwery. Oznacza to, że może być aktualizowany i ulepszany tak szybko, jak sama aplikacja. Google mogło przetestować i wdrożyć nowy algorytm kontroli przeciążenia dla miliardów użytkowników Chrome w ciągu kilku tygodni, bez czekania na aktualizacje systemu operacyjnego.
• Unikanie Pośredników: Ponieważ z perspektywy sieci jest to po prostu ruch UDP, jest mniej prawdopodobne, że zostanie zablokowany lub zmodyfikowany przez starszy sprzęt sieciowy, który go nie rozumie.

QUIC implementuje w przestrzeni użytkownika funkcje transportowe znane z TCP oraz mechanizmy specyficzne dla własnej architektury. Ułatwia to rozwijanie protokołu niezależnie od cyklu aktualizacji jądra systemu operacyjnego.

Dogłębne Spojrzenie na Innowacje QUIC

1. Zmniejszone Opóźnienie Nawiązywania Połączenia: Uzgadnianie 0-RTT i 1-RTT

QUIC łączy uzgadnianie transportowe i kryptograficzne w jeden proces, dramatycznie skracając czas nawiązywania połączenia.

• Pierwsze Połączenie (1-RTT): Za pierwszym razem, gdy klient łączy się z serwerem, uzgadnianie QUIC zajmuje jeden RTT. W tej wymianie klient i serwer negocjują klucze kryptograficzne i parametry połączenia.
• Kolejne połączenia (0-RTT): klient, który zachował parametry poprzedniej sesji, może wysłać wczesne dane aplikacji w pierwszym pakiecie. Dane 0-RTT nie są chronione przed powtórzeniem przez napastnika. Serwer może je odrzucić, a aplikacja powinna używać tego trybu tylko dla operacji bezpiecznych przy ponownym wykonaniu. Mechanizm skraca oczekiwanie przed wysłaniem danych, ale nie usuwa opóźnienia sieci ani czasu obsługi żądania.

2. Strumienie i ograniczenie blokowania czoła kolejki

QUIC adaptuje genialną koncepcję wielostrumieniowości z SCTP i czyni ją swoją podstawową cechą. Jedno połączenie QUIC to kontener dla wielu niezależnych, lekkich strumieni danych.

Gdy przeglądarka używa HTTP/3, może mapować zasoby na osobne strumienie QUIC. Utrata pakietu zawierającego dane strumienia 3 wstrzymuje uporządkowane dostarczenie brakujących bajtów tego strumienia, ale nie blokuje danych gotowych do dostarczenia w innych strumieniach. QUIC usuwa więc blokowanie między strumieniami charakterystyczne dla multipleksowania HTTP/2 nad jednym strumieniem TCP, lecz nie usuwa blokowania wewnątrz strumienia dotkniętego utratą.

3. Migracja Połączeń: Przetrwanie Zmian w Sieci

To kolejna przełomowa funkcja. Połączenia TCP są definiowane przez ich 4-krotkę adresów IP i portów. Jeśli oglądasz wideo na telefonie przez Wi-Fi, a następnie wyjdziesz z domu, telefon przełączy się na sieć komórkową. Twój adres IP się zmieni, a połączenie TCP zostanie zerwane, powodując zatrzymanie i buforowanie wideo.

Połączenia QUIC nie są identyfikowane przez adresy IP i porty. Zamiast tego każde połączenie QUIC jest identyfikowane przez unikalny 64-bitowy Identyfikator Połączenia. Jeśli przełączysz się z Wi-Fi na sieć komórkową, Twój adres IP się zmieni, ale Identyfikator Połączenia pozostanie taki sam. Klient może po prostu wznowić wysyłanie pakietów ze swojego nowego adresu IP, zawierając ten sam Identyfikator Połączenia. Serwer widzi ID, rozpoznaje je jako istniejące połączenie i płynnie kontynuuje sesję. Zapewnia to nieprzerwane doświadczenie użytkownika, co jest niezwykle ważne w dzisiejszym, mobilnym świecie.

4. Bezpieczeństwo Domyślne: Wbudowane Szyfrowanie

W przypadku TCP, bezpieczeństwo (TLS) jest opcjonalną, oddzielną warstwą dodawaną na wierzch. W QUIC bezpieczeństwo jest wbudowane w jego DNA. Praktycznie cały pakiet QUIC jest uwierzytelniony, a ładunek jest zawsze zaszyfrowany. Nawet części nagłówka, które nie są szyfrowane, są wciąż uwierzytelniane, aby zapobiec manipulacji przez pośredników.

To domyślne podejście do bezpieczeństwa nie tylko chroni dane i prywatność użytkowników, ale także pomaga w walce z usztywnieniem protokołu. Ponieważ pośrednicy nie mogą łatwo sprawdzać ani modyfikować zawartości pakietu QUIC, jest mniej prawdopodobne, że będą zakłócać jego działanie, co pozwala na swobodniejszą ewolucję protokołu w przyszłości.

5. Wymienna Kontrola Przeciążenia

Ponieważ logika kontroli przeciążenia QUIC znajduje się w przestrzeni aplikacji, a nie w jądrze systemu operacyjnego, znacznie łatwiej jest eksperymentować i wdrażać nowe algorytmy. Początkowa implementacja QUIC od Google używała wersji TCP CUBIC, ale od tego czasu została zaktualizowana o nowoczesny algorytm BBR (Bottleneck Bandwidth and Round-trip). Ta zdolność do szybkiej iteracji i ulepszania sposobu, w jaki protokół reaguje na przeciążenie sieci, jest ogromną przewagą nad powolną ewolucją TCP.

Miejsce QUIC w Świecie: HTTP/3 i Poza Nim

Najbardziej natychmiastowym i znaczącym zastosowaniem QUIC jest nowa podstawa dla protokołu WWW. HTTP/3 jest zaprojektowany wyłącznie do działania na QUIC. Ta synergia uwalnia pełny potencjał obu technologii. HTTP/3 wykorzystuje wielostrumieniowość QUIC do zapewnienia znacznie szybszego, bardziej responsywnego i odporniejszego przeglądania stron internetowych, zwłaszcza w zawodnych sieciach mobilnych.

Chociaż początkowo napędzany przez Google, QUIC został od tego czasu ustandaryzowany przez IETF (Internet Engineering Task Force), zapewniając, że jest to otwarty i interoperacyjny standard globalny. Główne firmy technologiczne, w tym Google, Meta i Cloudflare, już szeroko wdrożyły HTTP/3 i QUIC, i obsługuje on teraz znaczący odsetek globalnego ruchu internetowego.

QUIC reprezentuje fundamentalną zmianę w architekturze warstwy transportowej internetu. Przenosząc kontrolę z sztywnego, wolno poruszającego się jądra systemu operacyjnego do elastycznej i szybko ewoluującej warstwy aplikacji, QUIC utorował drogę dla nowej generacji protokołów sieciowych, które są szybsze, bezpieczniejsze i lepiej przystosowane do wyzwań współczesnego internetu.