Informatyka i programowanieInternet i sieci komputerowe — jak dane naprawdę docierają do celu

QUIC może stracić dane jednego strumienia bez zatrzymywania pozostałych

HTTP/2 potrafi prowadzić wiele równoległych strumieni logicznych w jednym połączeniu TCP, ale TCP widzi je jako jeden uporządkowany strumień bajtów. Jeśli na poziomie TCP zabraknie wcześniejszych danych, późniejsze bajty nie mogą zostać przekazane aplikacji, nawet gdy należą do innego żądania. RFC 9114 wskazuje ten transportowy head-of-line blocking jako problem HTTP/2 nad TCP. QUIC rozdziela niezawodność między własne strumienie: utrata pakietu zawierającego dane jednego strumienia może zatrzymać ten strumień, podczas gdy dane innych, które dotarły kompletnie, nadal mogą być dostarczane. Jedna strata nie musi więc blokować całego zestawu równoległych żądań.

HTTP/2 multipleksuje nad jednym TCP

HTTP/2 wprowadził wiele logicznych strumieni w pojedynczym połączeniu, co pozwala mieszać fragmenty różnych żądań i odpowiedzi bez otwierania osobnego TCP dla każdego zasobu. Warstwa TCP nic jednak nie wie o tych granicach. Dla niej wszystko jest jednym ciągiem bajtów, który musi zostać dostarczony aplikacji w dokładnej kolejności.

Jedna luka może zasłonić późniejsze bajty

Jeśli segment TCP zawierający wcześniejsze bajty zginie, późniejsze segmenty mogą fizycznie dotrzeć do komputera, ale uporządkowany interfejs TCP nie może przekazać ich aplikacji przed uzupełnieniem luki. Jeżeli w tych późniejszych bajtach znajdują się dane całkiem innego strumienia HTTP/2, on również czeka. To właśnie transportowy head-of-line blocking opisany w RFC 9114.

QUIC zna granice strumieni

QUIC nie ukrywa wszystkich danych w jednym globalnym uporządkowanym strumieniu. RFC 9000 definiuje wiele niezależnych strumieni, każdy z własną kolejnością bajtów. Odbiorca może buforować lukę w strumieniu A, a jednocześnie przekazywać aplikacji kompletne dane strumienia B. Niezawodność nadal obowiązuje, ale jej jednostka jest drobniejsza.

Pakiet może zawierać dane kilku strumieni

Utrata pojedynczego pakietu QUIC może oczywiście dotknąć więcej niż jednego strumienia, jeśli zawierał ramki z ich danymi. Ważne jest jednak to, że brak danych strumienia A nie tworzy automatycznie globalnej bariery dla wszystkich późniejszych danych połączenia. Każdy strumień czeka tylko na własne brakujące fragmenty.

To nie usuwa każdego rodzaju blokowania

Jeśli sama aplikacja potrzebuje wyniku A, zanim wykorzysta B, zależność pozostaje. HTTP/3 ma też własne elementy współdzielone, których utrata lub brak może wpływać na przetwarzanie. QUIC rozwiązuje konkretny problem transportowy wynikający z jednej globalnej kolejności TCP; nie sprawia, że wszystkie żądania stają się logicznie niezależne w każdej sytuacji.

Mała zmiana warstwy transportowej zmienia zachowanie całej strony

Użytkownik widzi tylko szybciej lub wolniej ładującą się stronę, ale pod spodem architektura strumieni decyduje, czy utrata jednego pakietu zatrzyma wiele równoległych transferów. QUIC pokazuje, że wydajność sieci nie zależy wyłącznie od przepustowości: znaczenie ma również to, jak protokół organizuje zależności pomiędzy brakującymi a już odebranymi danymi.

Utracony pakiet nie jest tym samym co utracony strumień

QUIC oddziela numerowanie pakietów od numerowania danych w strumieniach. Gdy pakiet znika, informacje, które zawierał, mogą zostać ponownie umieszczone w późniejszych pakietach, ale sam numer utraconego pakietu nie jest ponownie używany. Odbiorca składa każdy strumień na podstawie jego offsetów. Ta konstrukcja pomaga rozdzielić dwie kwestie: co wydarzyło się z datagramami na trasie oraz które fragmenty logicznych strumieni nadal są potrzebne aplikacji. W TCP te warstwy są silniej związane z jednym globalnym ciągiem bajtów. QUIC dzięki bogatszemu modelowi może dokładniej określić skutki konkretnej straty. Nie usuwa fizycznej konieczności retransmisji brakujących danych, ale ogranicza obszar, który musi czekać na uzupełnienie luki. Ta separacja jest szczególnie cenna na łączach, gdzie sporadyczne straty są nieuniknione. Jeśli przeglądarka równolegle pobiera kilka niezależnych zasobów, utrata fragmentu jednego z nich nie powinna z definicji odbierać aplikacji dostępu do kompletnych danych pozostałych. QUIC przenosi tę wiedzę o niezależności bliżej warstwy transportowej zamiast ukrywać wszystkie strumienie w jednej kolejce TCP.

#head-of-line blocking#HTTP/2#HTTP/3#QUIC#TCP
Źródła i weryfikacja
Otrzymuj codzienne losowe ciekawostki