QUIC (wymawiane jako „szybki”) to protokół warstwy transportowej (TL) opracowany na bazie UDP (User Datagram Protocol). Typowe protokoły TL obejmują TCP i UDP. TCP jest najpowszechniejszym protokołem używanym w komunikacji sieciowej, z którym można spotkać się na co dzień.
HTTP – protokół przeglądania sieci Web (protokół warstwy aplikacji) jest protokołem zorientowanym na połączenie. HTTP działa na szczycie TCP, który jest protokołem warstwy transportowej dla sieci. Takie rozwiązanie umożliwia stabilną łączność, która jest często wymagana do niezawodnej transmisji wiadomości. W przeciwieństwie do UDP, TCP zapewnia niezawodne dostarczanie danych, kolejność dostarczania i wspiera kontrolę przepływu. Kontrola przepływu zapewnia przede wszystkim zgodność szybkości transmisji danych.
UPD w przeciwieństwie do TCP, stosuje podejście „fire and forget”, w którym nie ma gwarancji, ani opieki, jeśli dane są odbierane z drugiej strony. Jednym z przykładów jest DHT (rozproszona tablica skrótów) BitTorrent. Być może widzieliście UDP trackers w aplikacji uTorrent. Jeśli jesteście zainteresowani, zachęcam do przeczytania następującej dyskusji na Quora.
Istniejący protokół HTTP
Istniejący Internet działa na szczycie stosu TCP / IP.
TCP/IP Model
W stosie TCP / IP, HTTP znajduje się w najwyższej warstwie aplikacji. W związku z tym, aby zainicjować każde żądanie HTTP, należy zainicjować połączenie TCP. W protokole HTTP2 wprowadzono ulepszenia w tej warstwie aplikacji, takich jak Multiplexing i Server push.
HTTP-1 Several TCP connections for different resources
Downloading multiple resources from through a single connection
W HTTP-1 było wiele oddzielnych połączeń dla różnych zasobów. Narzut był znaczący ze względu na zorientowany na połączenie charakter protokołu TCP. W HTTP-2 połączenia zostały zachowane i używały tego samego połączenia z Multiplexing do pobierania większej ilości danych. W związku z tym narzuty inicjacji połączenia zostały zmniejszone. Zobaczmy teraz, jak internet oparty na technologii QUIC jeszcze bardziej ulepsza korzystanie z sieci.
Internet TCP + TLS
Tradycyjny Internet wykorzystywał połączenia TCP, które wymagały mechanizmu 3-way handshake.
TCP 3-way handshake
SYN – klient chce zainicjować połączenie z serwerem. Zatem maszyna klienta wysyła segment danych z SYN (Synchronize Sequence Number). Jest to pakiet danych z flagą bitową w nagłówku TCP.
SYN / ACK – serwer odpowiada klientowi z ustawionymi bitami sygnału SYN-ACK. ACK oznacza potwierdzenie. Teraz nagłówek TCP ma aktywne dwa bity. W TPC połączenia są dwukierunkowe ze względu na jego niezawodność.
ACK – w końcu klient potwierdza serwerowi, że komunikacja jest dobra.
Rozszerzenie TLS
TLS oznacza bezpieczeństwo warstwy transportowej, która zapewnia szyfrowanie sieci. Gwarantuje to, że nikt nie sprawdzający pakietów danych nie będzie w stanie odczytać ich zawartości. Poniższy diagram pokazuje, jak działa protokół TLS w protokole TCP.
TCP+TLS Handshake
Przed każdym żądaniem należy wykonać wszystkie powyższe kroki uzgadniania. To sprawia, że proces inicjowania połączenia jest ciężki i czasochłonny.
Sytuacja pogarsza się w przypadku TCP slow start process. Jest to algorytm TCP, który szacuje przeciążenie sieci i prędkości, które mogą być uzgodnione przez obie strony. Z tego powodu połączenia nigdy nie mogą wykorzystywać całej przepustowości sieci od początku.
W protokole HTTP-1.1 wprowadzono funkcję utrzymywania aktywności, aby ograniczyć ryzyko tego scenariusza, utrzymując połączenia bez kończenia ich po każdym żądaniu. Jednak Multiplexing nie był wtedy dostępny i żądania musiały być wykonywane seryjnie.
Chociaż HTTP-2 wykorzystywał Multiplexing do tunelowania wielu żądań przez to samo połączenie TCP, to utrata pakietów w TCP utrudnia oczekiwane zyski. Dzieje się tak, ponieważ uporządkowany charakter protokołu TCP wymusza kolejność dostarczania pakietów. TCP widzi tylko strumień danych między dwoma źródłami. Jednak wewnątrz może znajdować się wiele zasobów, których kolejność dostaw nie stanowi dużego problemu. Ten problem powoduje niepotrzebne opóźnianie danych w przypadku utraty pakietów (co jest dość powszechne w przeciążonych i złożonych sieciach). Nazywa się to również problemem HOL blocking (Head of Line Blocking).
Internet QUIC
Tutaj do gry wchodzi właśnie QUIC, aby zaatakować problem HOL blocking (Head of Line Blocking). QUIC zastępuje TCP i próbuje rozwiązać ograniczenia spowodowane przez protokół TCP.
„Strumienie QUIC współużytkują to samo połączenie QUIC, więc do tworzenia nowych nie są wymagane żadne dodatkowe uzgadnianie i powolne uruchamianie, ale strumienie QUIC są dostarczane niezależnie, także w większości przypadków utrata pakietów wpływająca na jeden strumień nie wpływa na inne. Jest to możliwe, ponieważ pakiety QUIC są hermetyzowane na szczycie datagramów UDP”. – Cytat z CloudFlare
Można zauważyć, że wracamy do UDP, gdzie inicjacje połączeń są znacznie szybsze kosztem niezawodności. W przyszłości strumienie HTTP będą mapowane na strumienie oparte na QUIC w celu dostarczania danych. Stąd HTTP-2 będzie w stanie uwolnić pełną pojemność swojej specyfikacji.
QUIC włącza również uzgadnianie TLS do uzgadniania inicjacji połączenia. Oznacza to, że protokół QUIC ma domyślnie ochronę TLS z połową opóźnienia inicjacji połączenia.
QUIC handshake in HTTP-3
Dlaczego HTTP-3?
Chociaż HTTP-2 może działać na szczycie QUIC, w strumieniach QUIC jest kilka haczyków. QUIC nie gwarantuje kolejności obsługiwanych żądań w przeciwieństwie do protokołu TCP. Poprzednia kompresja nagłówka HTTP (HPACK) w dużym stopniu zależy od kolejności w TCP. To sprawia, że HTTP-2 nie nadaje się do użytku poza QUIC. Ponadto protokół HTTP-3 będzie znacznie prostszy pod względem funkcjonalności, ponieważ wiele jego funkcji zostało przeniesionych do warstwy QUIC.
Kilka zrzutów ekranu z narzędzi Chrom Dev działających w systemie OSX.
SPDY indicator plugin
Wniosek
W tym artykule chciałem wyjaśnić, jak zachowuje się warstwa transportowa i warstwa aplikacji w HTTP-3. Mam nadzieję, że lektura tego artykułu sprawiła Ci taką samą przyjemność, jak mi pisanie.
Anuradha Wickramarachchi – Pochodzę ze Sri Lanki, obecnie przygotowuję się do doktoratu na Australian National University studiując informatykę (sp. Bioinformatyka).