Motywacja do Zmian: Ostatnie Wąskie Gardło

Ewolucja z HTTP/1.1 do HTTP/2 była monumentalnym krokiem naprzód w dziedzinie wydajności sieci. HTTP/2 wprowadził multipleksowanie, umożliwiając równoczesne wysyłanie wielu żądań i odpowiedzi przez jedno połączenie TCP, co doskonale rozwiązało problem blokowania na czele kolejki na poziomie aplikacji. Wolne żądanie o duży obrazek nie blokowało już szybkiego pobierania pliku CSS. Jednakże, naprawiając ten problem, społeczność internetowa wkrótce odkryła głębsze, bardziej fundamentalne wąskie gardło: blokowanie na czele kolejki w warstwie transportowej, nieodłącznie związane z architekturą protokołu TCP.

TCP gwarantuje niezawodne i uporządkowane dostarczanie pakietów danych. Jest to kluczowa cecha dla wielu aplikacji, zapewniająca, że pliki nie są uszkodzone, a dane docierają zgodnie z zamierzeniami. Aby to osiągnąć, TCP traktuje wszystkie dane w ramach jednego połączenia jako jeden uporządkowany strumień. Jeśli pojedynczy pakiet zostanie utracony w tranzycie, TCP wstrzyma dostarczanie wszystkich kolejnych pakietów, nawet tych należących do innych, niezależnych strumieni HTTP/2 do czasu, aż utracony pakiet zostanie retransmitowany i odebrany. Oznacza to, że pojedynczy utracony pakiet z pobieranego obrazu mógłby zamrozić renderowanie całkowicie oddzielnego pliku JavaScript na tym samym połączeniu.

To blokowanie HOL na poziomie TCP jest szczególnie szkodliwe w sieciach niestabilnych lub o wysokim opóźnieniu, takich jak sieci komórkowe. W miarę jak coraz więcej osób na świecie korzysta z internetu na urządzeniach mobilnych, to ograniczenie stawało się coraz bardziej znaczące. Stało się jasne, że aby uczynić sieć szybszą i bardziej odporną, sama podstawa jej transportu wymagała przeprojektowania. Ta konieczność była głównym motorem napędowym powstania HTTP/3.

Zmiana Paradygmatu: Budowa na UDP z wykorzystaniem QUIC

HTTP/3 stanowi radykalne odejście od swoich poprzedników. Nie działa on na protokole TCP. Zamiast tego jest zbudowany na nowym protokole transportowym o nazwie QUIC, co jest skrótem od Quick UDP Internet Connections.

Aby zrozumieć, dlaczego jest to tak znacząca zmiana, musimy najpierw zrozumieć protokół, na którym opiera się QUIC, czyli UDP. Protokół Datagramów Użytkownika (UDP) jest minimalistycznym, bezpołączeniowym protokołem. Pozwala aplikacjom wysyłać do siebie pakiety (zwane datagramami), ale nie oferuje żadnych gwarancji. Pakiety mogą zostać utracone, zduplikowane lub dotrzeć w innej kolejności. To jak wysyłanie serii pocztówek; niektóre mogą zaginąć, a te, które dotrą, niekoniecznie pojawią się w kolejności, w jakiej zostały wysłane.

QUIC bierze szybkość i prostotę UDP i buduje na nich warstwę niezawodności, w zasadzie reimplementując najlepsze cechy TCP, ale bez jego największych wad. Oferuje niezawodność, kontrolę przeciążenia i kontrolę przepływu, ale robi to w sposób zoptymalizowany dla nowoczesnej, zmultipleksowanej natury HTTP.

Główna Korzyść 1: Eliminacja Blokowania HOL w Warstwie Transportowej

Podstawową zaletą QUIC jest całkowita eliminacja blokowania na czele kolejki, które jest charakterystyczne dla TCP. QUIC osiąga to, ponieważ obsługuje strumienie natywnie, jako pierwszorzędny element samego protokołu transportowego.

W HTTP/2 nad TCP koncepcja strumieni istnieje tylko na poziomie aplikacji. Sam protokół TCP jest ich nieświadomy i widzi tylko pojedynczy, monolityczny strumień bajtów. W przeciwieństwie do tego, QUIC zarządza wieloma niezależnymi strumieniami logicznymi w ramach jednego połączenia. Pakiety danych przesyłane przez sieć są oznaczane identyfikatorem strumienia QUIC, do którego należą.

Jeśli pakiet zawierający dane dla strumienia 3 zostanie utracony, mechanizm niezawodności QUIC wie, że ma wstrzymać dostarczanie danych tylko dla strumienia 3, do czasu retransmisji tego pakietu. Strumienie 1 i 5, których pakiety zostały pomyślnie odebrane, mogą być nadal dostarczane do warstwy aplikacji i natychmiast przetwarzane. To niezależne obsługiwanie strumieni sprawia, że połączenie jest znacznie bardziej odporne na utratę pakietów, zapewniając znacznie płynniejsze i szybsze doświadczenie użytkownika, zwłaszcza w sieciach mobilnych i o dużej stratności.

Główna Korzyść 2: Szybsze Ustanawianie Połączenia

Kolejną znaczącą poprawą wydajności w HTTP/3 jest radykalnie skrócony czas nawiązywania połączenia, co również jest zasługą QUIC. W świecie HTTP/2 nad TCP, ustanowienie bezpiecznego połączenia wymagało dwóch oddzielnych, sekwencyjnych uzgodnień (handshakes):

1. Uzgadnianie TCP: Wymaga jednego pełnego obiegu (round-trip) między klientem a serwerem (SYN -> SYN-ACK -> ACK).
2. Uzgadnianie TLS: Wymaga jednego do dwóch dodatkowych obiegów w celu negocjacji kluczy szyfrujących.

W rezultacie, zanim pierwszy bajt rzeczywistych danych aplikacji może zostać wysłany, mijają dwa do trzech obiegów. W sieciach mobilnych o wysokich opóźnieniach, to początkowe opóźnienie może być znaczące.

Uzgadnianie 1-RTT i 0-RTT w QUIC

QUIC usprawnia ten proces, łącząc uzgadnianie transportowe i kryptograficzne w jedną procedurę.

• Połączenie 1-RTT: Dla nowego połączenia, klient wysyła komunikat `ClientHello`, a serwer może odpowiedzieć komunikatem zawierającym swój certyfikat TLS i wszystkie niezbędne parametry do ustanowienia bezpiecznej sesji. Klient może to następnie zweryfikować i rozpocząć wysyłanie zaszyfrowanych danych. Cały proces zajmuje zazwyczaj tylko jeden czas obiegu (RTT).
• Wznowienie połączenia 0-RTT: Co jeszcze bardziej imponujące, dla klientów, którzy już wcześniej łączyli się z danym serwerem, QUIC obsługuje wznowienie połączenia w zerowym czasie obiegu (0-RTT). Klient może natychmiast zacząć wysyłać zaszyfrowane dane aplikacji wraz ze swoim pierwszym komunikatem uzgadniającym, używając wcześniej wynegocjowanych parametrów zapisanych z ostatniej sesji. Eliminuje to prawie całe opóźnienie związane z nawiązywaniem połączenia, sprawiając, że powtórne wizyty na stronach internetowych wydają się niemal natychmiastowe.

Główna Korzyść 3: Migracja Połączenia dla Świata Mobilnego

Jedną z najbardziej zauważalnych dla użytkownika innowacji QUIC jest jego odporność na zmiany sieciowe, funkcja znana jako migracja połączenia. Tradycyjne połączenie TCP jest ściśle zdefiniowane przez 4-krotkę: źródłowy adres IP, port źródłowy, docelowy adres IP i port docelowy. Jeśli którakolwiek z tych czterech wartości się zmieni, połączenie zostaje przerwane.

Tworzy to frustrujące doświadczenie użytkownika w świecie zdominowanym przez urządzenia mobilne. Wyobraź sobie, że oglądasz film na telefonie w domu, połączony z siecią Wi-Fi. Wychodząc z domu i tracąc zasięg, Twój telefon płynnie przełącza się z Wi-Fi na sieć komórkową. Kiedy to się dzieje, zmienia się adres IP Twojego telefonu. Z perspektywy TCP, narusza to 4-krotkę, a istniejące połączenie z serwerem wideo zostaje natychmiast zakończone. Odtwarzacz wideo musi buforować, ustanowić całkowicie nowe połączenie TCP i TLS przez sieć komórkową i wznowić strumień, co powoduje zauważalne zacięcie lub przerwę.

QUIC rozwiązuje ten problem w elegancki sposób. Zamiast identyfikować połączenie za pomocą adresów IP i portów, QUIC używa Identyfikatora Połączenia (Connection ID). Jest to unikalny identyfikator dołączany do nagłówka każdego pakietu QUIC. Kiedy Twój telefon przełącza się z Wi-Fi na sieć komórkową, zmienia się Twój adres IP, ale Identyfikator Połączenia pozostaje taki sam. Możesz kontynuować wysyłanie pakietów z tym samym Identyfikatorem Połączenia ze swojego nowego adresu IP. Serwer, widząc ten znajomy identyfikator, wie, że to to samo, trwające połączenie i płynnie kontynuuje transfer danych. Dla użytkownika, strumień wideo jest kontynuowany bez przerw, zapewniając prawdziwie płynne doświadczenie mobilne.

Warstwa Aplikacji w HTTP/3

Chociaż warstwa transportowa została całkowicie wymieniona, warstwa aplikacji w HTTP/3 zachowuje te same semantyki i funkcje wysokiego poziomu wprowadzone w HTTP/2. Koncepcje żądania/odpowiedzi, nagłówków, metod (GET, POST, itp.) i kodów statusu pozostają niezmienione. Funkcje takie jak Server Push i priorytetyzacja strumieni również są obecne w HTTP/3, ponieważ są one implementowane na poziomie HTTP.

Mapowanie HTTP na Strumienie QUIC

Kluczową różnicą jest sposób mapowania tych koncepcji na podstawowy transport. QUIC zapewnia natywną abstrakcję strumienia, więc każda para żądanie-odpowiedź HTTP/3 jest mapowana na dedykowany strumień QUIC. Jest to znacznie czystsze i bardziej wydajne mapowanie niż implementacja strumieni na poziomie aplikacji, która była nakładana na TCP w HTTP/2.

QPACK: Kompresja Nagłówków dla QUIC

Kompresja nagłówków pozostaje kluczową funkcją. Jednak schemat kompresji HPACK z HTTP/2 opierał się na ścisłym, uporządkowanym dostarczaniu danych przez TCP. Ponieważ strumienie QUIC mogą dostarczać dane w innej kolejności, potrzebny był nowy schemat kompresji. HTTP/3 używa QPACK, który jest podobny w założeniach do HPACK, ale został zaprojektowany do pracy z bardziej elastycznym modelem dostarczania QUIC. Używa on oddzielnych, jednokierunkowych strumieni do zarządzania dynamicznymi tabelami nagłówków, co zapobiega blokowaniu HOL w samym mechanizmie kompresji nagłówków.

Wdrożenie i Przyszłość

HTTP/3 to przyszłość protokołu internetowego, oferująca namacalne korzyści w zakresie wydajności i niezawodności. Główne przeglądarki, takie jak Chrome, Firefox i Safari, a także główni dostawcy treści i sieci CDN, jak Google i Cloudflare, już szeroko go wspierają.

Największym wyzwaniem dla jego powszechnej adaptacji jest infrastruktura sieciowa. Ponieważ QUIC działa na protokole UDP, czasami może być blokowany przez źle skonfigurowane lub przestarzałe firmowe zapory sieciowe i inne urządzenia pośredniczące, które są skonfigurowane tak, aby przepuszczać tylko ruch TCP na porcie $443$ (standardowy port dla HTTPS). Systemy są jednak projektowane z myślą o tym problemie. Przeglądarki najpierw próbują nawiązać połączenie za pomocą HTTP/3, a jeśli ruch UDP jest blokowany, płynnie wracają do ustanowienia połączenia HTTP/2 przez TCP, zapewniając, że strony internetowe pozostają dostępne dla wszystkich użytkowników. W miarę modernizacji infrastruktury sieciowej, adopcja HTTP/3 będzie tylko rosła, czyniąc sieć szybszą, bardziej odporną i lepiej przystosowaną do naszego mobilnego świata.