Protokół HTTP 3.0 został zaprojektowany przez inżynierów Google w 2018. Jednak wdrożenie go jako standard przez Internet Engineering Task Force miało miejsce miesiąc temu. Przeglądarki Chrome i Firefox obsługują już ten standard, na pozostałe przeglądarki czekamy. Status postępu w innych przeglądarkach możesz śledzić na stronie caniuse.
W tym artykule przedstawię Ci kluczowe zmiany jakie niesie protokół HTTP 3.0 z punktu widzenia programisty.
Wersje protokołu HTTP
Dla głębszego zrozumienia tematu przedstawiam szybkie przypomnienie zmian niesionych przez poprzednie wersje tego prodokołu.
Protokół HTTP 0.9
- rok 1991
- wykorzystywany protokół: TCP
- praca w trybie: żądanie-odpowiedź
- obsługiwana tylko metoda GET
- typ odpowiedzi: Hipertekst
- bez nagłówków HTTP
- bez kodów odpowiedzi
Protokół HTTP 1.0
- rok 1996
- wykorzystywany protokół: TCP
- praca w trybie: żądanie-odpowiedź
- obsługiwana metody: GET, HEAD, POST
- typ odpowiedzi: Hipertekst, Skrypty
- możliwość dodawania nagłówków
Protokół HTTP 1.1
- rok 1997
- wykorzystywany protokół: TCP
- praca w trybie: żądanie-odpowiedź
- dodatkowo obsługiwane metody: OPTIONS, PUT, DELETE, TRACE, CONNECT
- typ odpowiedzi: Hipertekst, Skrypty
- możliwość dodawania nagłówków
- wprowadzono przetwarzanie potokowe, które umożliwia wysyłanie następnego żądania zanim zostanie wysłana pełna odpowiedź na pierwsze rządzenia. Aktualnie najpopularniejszy standard komunikacji przeglądarek z serwerami WWW.
Protokół HTTP 2.0
- rok 2015
- wykorzystywany protokół: SPDY – protokół, opracowany przez Google, który bazuje na TCP i jest ukierunkowany na prędkość działania komunizacji przeglądarki z serwerem wykorzystując kompresje i manipulacje pakietami.
- praca w trybie: trwałego połączenia, które jest aktywne do zamknięcia strony
- umożliwia na wykonywanie wielu zapytań do serwera na raz (w przypadku poprzednich wersji protokołu HTTP zapytania były kolejkowanie)
Protokół HTTP 3.0
- rok 2018
- wykorzystywany protokół: QUIC – nowy protokół, również opracowany przez Google, który bazuje na protokole UDP. Motywacja do zmiany protokołu był problem związany z blokadą żądania HTTP, aż do czasu uzyskania odpowiedzi. UDP jest szybszy i ma mniejsze opóźnienie od TCP.
Do tej pory powodem do wykorzystywania TCP było zapewnienie poprawności przesyłanych danych. Dlaczego, więc protokół QUIC bazuje na UDP, który nie weryfikuje poprawności przesyłanych parkietów?
SPDY (TCP) vs QUIC (UDP)
TCP w przypadku zagubienia jednego z pakietów powoduje, że nie może obsłużyć żądania dopóki nie nastąpi retransmisja zagubionego pakietu. Do tego czasu dane te są blokowane lub nawet usuwane, gdy błąd jest korygowany.
W przypadku QUIC zgubienie jednego z wielu pakietów nie powoduje blokady innych pakietów, gdyż każdy pakiet posiada swój niezależny strumień. Jest to zwłaszcza bardzo przydatne w poprawianiu wydajności łączy podatnych na błędy.
Porównanie czasów oczekiwania
Inną ze zmian wprowadzonych przez QUIC jest zmniejszenie wymaganej konfiguracji do nawiązania połączenia. Ponieważ większość połączeń HTTP wykorzystuje TLS, to QUIC sprawia, że wymiana kluczy i obsługiwanych protokołów jest częścią handshake. Gdy klient nawiązuje połączenie, to pakiet odpowiedzi zawiera już dane potrzebne klientowi do korzystania z szyfrowania. Eliminuje to konieczność konfigurowania połączenia TCP, a następnie ustalania protokołu bezpieczeństwa za pomocą dodatkowych pakietów.
Jednak opisując kwestie związane z bezpieczeństwem warto się zastanowić czy wykorzystanie protokołu bazującego na UTP, nie sprawi, że serwisy go wykorzystujące są bardziej podane na ataki DDOS.
Przyszłość HTTP – wnioski
Podsumowując zmiany idące w najnowszej wersji protokołu HTTP, to najistotniejsza jest zmiana protokołu transportowego. Wiele popularnych serwisów takich jak FB, Netflix wykorzystuje już HTTP 3.0. A jako YouTuber mogę Ci powiedzieć, że szybkość buferowania wideo wraz z wprowadzeniem nowego protokołu wzrosła o około 30% 🙂
Poniżej dziele się z Tobą ciekawymi statystykami pochodzącą z w3techs.com na temat popularności HTTP/3:
