Protokół QUIC

Wprowadzenie: QUIC jako Protokół Transportowy

TCP zapewnia uporządkowany i niezawodny transport, lecz jego sposób ustanawiania połączeń oraz obsługi jednego strumienia ma koszty widoczne w aplikacjach internetowych. Zestawienie połączenia wymaga osobnego uzgadniania TCP, a TLS dodaje kolejną fazę. Utrata segmentu wstrzymuje dostarczanie późniejszych bajtów strumienia, a zmiana implementacji TCP zwykle zależy od stosu systemu operacyjnego.

Projekt QUIC, rozwijany początkowo między innymi przez Google, wykorzystał UDP jako prosty substrat datagramowy. Na tej podstawie zbudowano transport dodający niezawodność, kontrolę przeciążenia, wielostrumieniowość i ochronę kryptograficzną. Takie rozmieszczenie funkcji pozwala rozwijać część transportową razem z aplikacją, bez oczekiwania na zmianę systemowego stosu TCP.

Tym protokołem jest QUIC. RFC 9000 używa tej nazwy protokołu i nie rozwija jej jako wyrażenia Quick UDP Internet Connections. QUIC działa nad UDP, lecz sam zapewnia niezawodność, kontrolę przeciążenia, wiele niezależnych strumieni oraz obowiązkową ochronę kryptograficzną opartą na TLS 1.3. UDP nie zapewnia samodzielnie retransmisji, kolejności ani kontroli przeciążenia, dlatego te funkcje realizuje warstwa QUIC. Implementacja w przestrzeni użytkownika ułatwia aktualizowanie protokołu bez oczekiwania na zmianę systemowego stosu TCP. QUIC jest transportem używanym przez HTTP/3.

Problemy Stosu TCP i TLS, Które QUIC Adresuje

Aby ocenić architekturę QUIC, trzeba rozdzielić funkcje tradycyjnego stosu. Bezpieczny ruch internetowy często korzysta z TCP oraz osobnej warstwy TLS (Transport Layer Security). Połączenie TCP z oddzielnym TLS wymaga osobnych etapów ustanawiania sesji i pozostawia multipleksowanie wielu zasobów wewnątrz jednego strumienia TCP.

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: TCP najpierw ustanawia połączenie przez trójetapowe uzgadnianie (SYN, SYN-ACK, ACK), które obejmuje jeden pełny Czas Obiegu (RTT). W typowym scenariuszu dane aplikacji są wysyłane po zakończeniu tego etapu. Konkretna implementacja może korzystać z dodatkowych rozszerzeń.
• Uzgadnianie TLS: Po ustanowieniu TCP warstwa TLS wykonuje własne uzgadnianie w celu uwierzytelnienia serwera i negocjacji kluczy szyfrujących. W przypadku pełnego TLS 1.3 zwykle oznacza to jedną dodatkową RTT, a starsze wersje lub inne scenariusze mogą wymagać od jednej do dwóch RTT. Wznowienie sesji może ograniczyć tę wymianę.

W typowym połączeniu TCP z pełnym TLS 1.3 potrzeba co najmniej dwóch RTT, zanim przeglądarka wyśle pierwsze żądanie. Przy dużym opóźnieniu sieci suma tych etapów może wynosić setki milisekund. Wznowienie TLS i inne mechanizmy mogą zmienić ten wynik.

Pakiety uzgadniania QUIC przenoszą jednocześnie informacje transportowe i komunikaty TLS. Przy braku strat klient może rozpocząć chronioną wymianę danych po zakończeniu uzgadniania mieszczącego się zwykle w jednej RTT, choć czas odpowiedzi aplikacji nadal zależy od sieci i serwera.

2. Blokowanie Czoła Kolejki w TCP

Jednym z ograniczeń TCP jest Blokowanie Czoła Kolejki (HOLB). TCP zapewnia pojedynczy, ściśle uporządkowany strumień bajtów. Strona internetowa składa się z wielu zasobów, takich jak HTML, arkusze CSS, JavaScript i obrazy. HTTP/2 multipleksuje te zasoby przez jedno połączenie TCP, lecz wszystkie nadal korzystają z tego samego strumienia bajtów.

Utrata segmentu zawierającego część obrazu tworzy lukę w strumieniu. TCP nie przekazuje aplikacji bajtów znajdujących się za tą luką, także gdy dotyczą CSS lub JavaScript i dotarły już do odbiorcy. Dostarczenie zostaje wznowione po retransmisji brakujących danych. Jest to ograniczenie multipleksowania HTTP/2 nad jednym strumieniem TCP.

3. Implementacja TCP w Jądrze i Usztywnienie Protokołu

TCP jest powszechnie implementowany w jądrze systemu operacyjnego. Umieszczenie stosu w jądrze pozwala korzystać z optymalizacji systemowych, lecz zmiany wymagają aktualizacji komponentów systemowych.

Wdrożenie nowej funkcji TCP wymaga zgodności specyfikacji, implementacji systemowych i wdrożenia na hostach. Aktualizacje mogą więc rozchodzić się wolniej niż zmiana biblioteki aplikacji. Pośrednie urządzenia sieciowe, takie jak firewalle i urządzenia NAT, rozpoznają utrwalone wzorce ruchu TCP i mogą blokować nieznane rozszerzenia. Zjawisko to nazywa się usztywnieniem protokołu (ang. protocol ossification).

Architektura QUIC: Funkcje Transportowe w Przestrzeni Użytkownika

QUIC przenosi wiele funkcji transportowych do implementacji działającej nad UDP. UDP dostarcza datagramy, a QUIC dodaje mechanizmy niezawodności, kontroli przeciążenia, przepływu i szyfrowania.

Protokół nie wymaga konkretnego modelu wdrożenia biblioteki. Implementacja może działać jako część biblioteki aplikacji, osobny moduł lub element innego stosu, o ile zachowuje wymagane formaty pakietów i reguły transportu.

Wykorzystanie UDP pozwala QUIC pozostawić obsługę datagramów pośrednim warstwom i zdefiniować własne funkcje transportowe:

• Aktualizacja Implementacji: Wiele implementacji QUIC działa jako biblioteka w aplikacji, na przykład w przeglądarce lub serwerze. Wdrożenie QUIC jako biblioteki pozwala aktualizować transport razem z aplikacją, bez oczekiwania na zmianę systemowego stosu TCP.
• Obsługa przez Pośredników: Dla sieci QUIC wygląda jak ruch UDP, więc nie wymaga od urządzeń pośrednich implementacji funkcji TCP. Sieci ograniczające UDP mogą jednak ograniczać także QUIC, a ochrona kryptograficzna pozwala wykryć modyfikację danych.

Typowa implementacja QUIC w przestrzeni użytkownika realizuje niezawodność, kontrolę przepływu, kontrolę przeciążenia i mechanizmy właściwe dla wielostrumieniowego transportu. Uruchomienie tych funkcji poza jądrem ułatwia rozwijanie protokołu niezależnie od cyklu aktualizacji systemu operacyjnego.

Najważniejsze Mechanizmy QUIC

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

QUIC łączy uzgadnianie transportowe i kryptograficzne w jeden proces, co ogranicza liczbę etapów potrzebnych do rozpoczęcia wymiany danych.

• Pierwsze Połączenie (1-RTT): Przy pierwszym połączeniu pełne uzgadnianie QUIC pozwala rozpocząć ochronioną wymianę danych po jednym RTT, przy braku strat pakietów. W tej wymianie klient i serwer negocjują klucze kryptograficzne oraz parametry połączenia.
• Kolejne Połączenia (0-RTT): Klient, który zachował parametry poprzedniej sesji, może wysłać wczesne dane aplikacji w pierwszej serii pakietów. Dane 0-RTT nie zapewniają ochrony przed powtórzeniem przez napastnika. Serwer może je odrzucić, a aplikacja powinna używać tego trybu tylko dla operacji bezpiecznych przy ponownym wykonaniu, takich jak odczyt lub żądanie idempotentne. Mechanizm skraca oczekiwanie przed wysłaniem danych, lecz nie usuwa opóźnienia sieci ani czasu obsługi żądania.

2. Strumienie i Ograniczenie Blokowania Czoła Kolejki

Jedno połączenie QUIC obejmuje wiele niezależnych strumieni danych. Każdy strumień zachowuje własną kolejność i mechanizmy kontroli, a połączenie współdzieli parametry transportowe.

Kontrola przepływu działa na poziomie strumienia oraz całego połączenia. Odbiorca może więc ograniczyć dane dla jednego strumienia lub łączną liczbę buforowanych bajtów, niezależnie od wykrywania strat i kontroli przeciążenia.

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

Połączenie TCP jest związane z 4-krotką adresów IP i portów. Gdy telefon przełącza się z Wi-Fi na sieć komórkową, adres IP może się zmienić, dlatego połączenie TCP zwykle wymaga ponownego ustanowienia. W aplikacji przesyłającej wideo może to spowodować zatrzymanie lub buforowanie.

QUIC używa identyfikatorów połączenia, co pozwala zachować połączenie mimo zmiany ścieżki. W wersji 1 identyfikator ma zmienną długość do 20 bajtów, a w pewnych przypadkach może mieć długość zero. Po zmianie sieci endpoint wybiera aktywny identyfikator i wykonuje walidację nowej ścieżki, aby ograniczyć ryzyko przekierowania ruchu do nieuprawnionego odbiorcy. Mechanizm może obsłużyć także zmianę mapowania przez NAT, jeśli endpointy zaakceptują nową ścieżkę. Serwer może rozpoznać pakiet jako należący do istniejącego połączenia, dlatego sesja może być kontynuowana mimo zmiany adresu IP. Endpointy mogą także otrzymywać i wycofywać kolejne identyfikatory podczas trwania połączenia.

4. Bezpieczeństwo Domyślne: Wbudowane Szyfrowanie

W TCP TLS jest oddzielną warstwą dodawaną nad transportem. W QUIC TLS 1.3 uczestniczy w uzgadnianiu, a pakiety danych są chronione uwierzytelnionym szyfrowaniem AEAD. Ładunek chronionego pakietu jest szyfrowany, a modyfikacja chronionych pól powoduje błąd weryfikacji. Numery pakietów wspierają wykrywanie strat i potwierdzanie postępu. Niektóre pola nagłówka pozostają jawne. Ochrona nagłówka maskuje wybrane bity, a AEAD uwierzytelnia ładunek oraz pola nagłówka użyte jako dane dodatkowe. Pakiety Version Negotiation i Retry podlegają osobnym regułom.

Ochrona domyślna zabezpiecza dane i utrudnia pośrednikom analizę lub modyfikację zawartości pakietów. Ogranicza to część przyczyn usztywnienia protokołu, lecz urządzenia filtrujące UDP nadal mogą wpływać na dostępność QUIC.

5. Konfigurowalna Kontrola Przeciążenia

W typowej implementacji logika kontroli przeciążenia QUIC działa w przestrzeni użytkownika, co ułatwia testowanie i wdrażanie algorytmów razem z aplikacją. RFC 9002 definiuje kontroler nadawcy podobny do TCP NewReno i dopuszcza inny algorytm, jeśli spełnia właściwe zalecenia dotyczące kontroli przeciążenia. Implementacja może stosować CUBIC, BBR lub inny odpowiedni algorytm, reagując na potwierdzenia i obserwowane straty.

QUIC w HTTP/3 i Innych Zastosowaniach

Jednym z głównych zastosowań QUIC jest transport protokołu WWW. HTTP/3 definiuje mapowanie semantyki HTTP na QUIC. Niezależne strumienie QUIC pozwalają HTTP/3 przekazywać zasoby bez blokowania strumieni, których dane są gotowe, co może ograniczyć skutki utraty pakietów na ścieżkach mobilnych.

QUIC został ustandaryzowany przez IETF (Internet Engineering Task Force) jako otwarty standard. Implementacje przeglądarek, serwerów i usług mogą wdrażać HTTP/3 oraz QUIC, a skala użycia zależy od dostępności obsługi po obu stronach i od właściwości sieci.

QUIC zmienia sposób rozmieszczenia funkcji transportowych w stosie internetowym. Przeniesienie części kontroli do warstwy implementowanej razem z aplikacją pozwala szybciej aktualizować transport, przy zachowaniu niezawodności, kontroli przeciążenia, wielostrumieniowości i ochrony kryptograficznej.