Komitet IETF (Internet Engineering Task Force), zajmujący się rozwojem protokołów i architektury internetu, zakończył prace nad RFC dla protokołu HTTP/3.0 i opublikował związane z nim specyfikacje pod identyfikatorami RFC 9114 (protokół) oraz RFC 9204 (technologia kompresji nagłówków QPACK dla HTTP/3). Specyfikacja HTTP/3.0 uzyskała status „Proponowanego standardu”, po czym rozpocznie się praca nad nadaniem RFC statusu standardu roboczego (Draft Standard), co faktycznie oznacza pełną stabilizację protokołu i uwzględnienie wszystkich zgłoszonych uwag. Jednocześnie opublikowano zaktualizowane wersje specyfikacji dla protokołów HTTP/1.1 (RFC 9112) oraz HTTP/2.0 (RFC 9113), a także dokumenty definiujące semantykę zapytań HTTP (RFC 9110) oraz nagłówki HTTP kontrolujące cachowanie (RFC 9111).
Protokół HTTP/3 definiuje wykorzystanie protokołu QUIC (Quick UDP Internet Connections) jako transportu dla HTTP/2. QUIC jest nadbudową nad protokołem UDP, wspierającą multiplexing wielu połączeń i zapewniającą metody szyfrowania, równoważne TLS/SSL. Protokół został stworzony w 2013 roku przez firmę Google jako alternatywa dla połączenia TCP+TLS w sieci, rozwiązująca problemy z długim czasem nawiązywania i negocjacji połączeń w TCP oraz eliminująca opóźnienia związane z utratą pakietów podczas przesyłania danych.
Obecnie wsparcie dla QUIC i HTTP/3.0 zostało już zrealizowane we wszystkich popularnych przeglądarkach internetowych (w Chrome, Firefox i Edge wsparcie dla HTTP/3 jest włączone domyślnie, a w Safari wymaga włączenia ustawienia „Advanced > Experimental Features > HTTP/3”). Po stronie serwera, implementacje HTTP/3 są dostępne dla nginx (w oddzielnej gałęzi i w formie osobnego modułu), Caddy, IIS oraz LiteSpeed. Wsparcie dla HTTP/3 zapewnia również sieć dystrybucji treści Cloudflare.
Kluczowe cechy QUIC:
- Wysokie bezpieczeństwo, podobne do TLS (w zasadzie QUIC zapewnia możliwość użycia TLS nad UDP);
- Kontrola integralności strumienia, zapobiegająca utracie pakietów;
- Możliwość natychmiastowego nawiązania połączenia (0-RTT, w około 75% przypadków dane mogą być przesyłane zaraz po wysłaniu pakietu nawiązania połączenia) oraz zapewnienie minimalnych opóźnień między wysyłaniem żądania a otrzymywaniem odpowiedzi (RTT, Round Trip Time);
- Użycie innego numeru sekwencji przy retransmisji pakietu, co pozwala uniknąć niejednoznaczności w określaniu otrzymanych pakietów i eliminować timeouty;
- Utrata pakietu wpływa na dostarczanie tylko powiązanego z nim strumienia i nie zatrzymuje dostarczania danych w równolegle przesyłanych strumieniach przez bieżące połączenie;
- Środki korekcji błędów, minimalizujące opóźnienia spowodowane ponowną transmisją zagubionych pakietów. Wykorzystanie specjalnych kodów korekcji błędów na poziomie pakietów w celu zmniejszenia liczby sytuacji wymagających ponownej transmisji danych zagubionego pakietu.
- Granice bloków kryptograficznych są wyrównane z granicami pakietów QUIC, co zmniejsza wpływ utraty pakietów na dekodowanie zawartości następnych pakietów;
- Brak problemów z blokowaniem kolejek TCP;
- Wsparcie dla identyfikatora połączenia, co pozwala skrócić czas na ponowne nawiązanie połączenia dla klientów mobilnych;
- Możliwość podłączenia rozszerzonych mechanizmów kontroli przeciążenia połączenia;
- Wykorzystanie techniki prognozowania przepustowości w każdym kierunku, aby zapewnić optymalną intensywność wysyłania pakietów, zapobiegając wpadnięciu w stan przeciążenia, w którym występuje utrata pakietów;
- Wyraźny wzrost wydajności i przepustowości w porównaniu do TCP. W przypadku serwisów wideo, takich jak YouTube, zastosowanie QUIC wykazało 30% zmniejszenie liczby operacji buforowania podczas odtwarzania wideo.
Wśród zmian w specyfikacji HTTP/1.1 należy zauważyć zakaz stosowania symbolu powrotu karetki (CR) poza treścią, tzn. w elementach protokołu symbol CR może być stosowany tylko w połączeniu z symbolem nowej linii (CRLF). Algorytm kompozycji chunked zapytań został udoskonalony w celu uproszczenia podziału załączonych pól i sekcji z nagłówkami. Dodano zalecenia dotyczące obsługi niejednoznacznej zawartości w celu blokowania ataków klasy „HTTP Request Smuggling”, pozwalających na wtrącanie się do zawartości zapytań innych użytkowników w strumieniu pomiędzy frontendem a backendem.
W aktualizacji specyfikacji HTTP/2.0 wyraźnie zdefiniowano wsparcie dla TLS 1.3. Przeniesiono do kategorii przestarzałych schemat określania priorytetów i związane z nimi pola w nagłówkach. Ogłoszono przestarzałym mechanizm aktualizacji połączenia z HTTP/1.1, który nie zyskał popularności. Skrócono wymagania dotyczące sprawdzania nazw pól i wartości. Zaproponowano do użycia niektóre wcześniej zarezerwowane typy ramek i parametry. Dokładniej zdefiniowano zabronione pola nagłówków odnoszące się do połączenia.
Źródło: opennet.ru
