IETF (Internet Engineering Task Force), która jest odpowiedzialna za rozwój protokołów i architektury internetowej, zakończyła tworzenie dokumentu RFC dla protokołu HTTP/3.0 i opublikowała powiązane specyfikacje pod identyfikatorami RFC 9114 (protokół) i RFC 9204 ( Technologia kompresji nagłówka QPACK dla HTTP/3). Specyfikacja HTTP/3.0 uzyskała status „Proponowanego Standardu”, po czym rozpoczną się prace nad nadaniem RFC statusu projektu standardu (Draft Standard), co w istocie oznacza pełną stabilizację protokołu i uwzględnienie wszystkich poczynione komentarze. Jednocześnie opublikowano zaktualizowane wersje specyfikacji protokołów HTTP/1.1 (RFC 9112) i HTTP/2.0 (RFC 9113), a także dokumenty definiujące semantykę żądań HTTP (RFC 9110) i nagłówki sterujące buforowaniem HTTP (RFC 9111).
Protokół HTTP/3 definiuje użycie protokołu QUIC (Quick UDP Internet Connections) jako środka transportu dla HTTP/2. QUIC jest rozszerzeniem protokołu UDP, które obsługuje multipleksowanie wielu połączeń i zapewnia metody szyfrowania równoważne TLS/SSL. Protokół został stworzony w 2013 roku przez Google jako alternatywa dla kombinacji TCP+TLS dla Internetu, rozwiązując problemy związane z długimi czasami konfiguracji połączenia i negocjacji w protokole TCP oraz eliminując opóźnienia w przypadku utraty pakietów podczas przesyłania danych.
Obecnie obsługa QUIC i HTTP/3.0 jest już zaimplementowana we wszystkich popularnych przeglądarkach internetowych (w Chrome, Firefox i Edge obsługa HTTP/3 jest domyślnie włączona, a w przeglądarce Safari wymaga ustawienia „Zaawansowane > Funkcje eksperymentalne > HTTP/3” zostać włączone). Po stronie serwera dostępne są implementacje HTTP/3 dla nginx (w osobnej gałęzi i w postaci osobnego modułu), Caddy, IIS i LiteSpeed. Obsługa protokołu HTTP/3 jest również zapewniana przez sieć dostarczania treści Cloudflare.
Kluczowe cechy QUIC:
- Wysokie bezpieczeństwo podobne do TLS (zasadniczo QUIC zapewnia możliwość korzystania z TLS przez UDP);
- Kontrola integralności przepływu, zapobiegająca utracie pakietów;
- Możliwość błyskawicznego nawiązania połączenia (0-RTT, w około 75% przypadków dane mogą zostać przesłane natychmiast po wysłaniu pakietu konfigurującego połączenie) i zapewnienia minimalnych opóźnień pomiędzy wysłaniem żądania a otrzymaniem odpowiedzi (RTT, Round Trip Time);
- Używanie innego numeru sekwencyjnego podczas retransmisji pakietu, co pozwala uniknąć niejednoznaczności w identyfikacji odebranych pakietów i pozbyć się przekroczeń limitu czasu;
- Utrata pakietu wpływa jedynie na dostarczanie powiązanego z nim strumienia i nie wstrzymuje dostarczania danych w równoległych strumieniach przesyłanych bieżącym połączeniem;
- Funkcje korekcji błędów minimalizujące opóźnienia spowodowane retransmisją utraconych pakietów. Zastosowanie specjalnych kodów korekcji błędów na poziomie pakietu w celu ograniczenia sytuacji wymagających retransmisji utraconych danych pakietowych.
- Granice bloków kryptograficznych są wyrównane z granicami pakietów QUIC, co zmniejsza wpływ utraty pakietów na dekodowanie zawartości kolejnych pakietów;
- Brak problemów z blokowaniem kolejek TCP;
- Obsługa identyfikatora połączenia, co skraca czas potrzebny na nawiązanie ponownego połączenia dla klientów mobilnych;
- Możliwość podłączenia zaawansowanych mechanizmów kontroli przeciążenia łączy;
- Wykorzystuje techniki prognozowania przepustowości w poszczególnych kierunkach, aby zapewnić, że pakiety są wysyłane z optymalną szybkością, zapobiegając ich przeciążeniu i powodując utratę pakietów;
- Znaczący wzrost wydajności i przepustowości w porównaniu do protokołu TCP. Wykazano, że w przypadku usług wideo, takich jak YouTube, QUIC zmniejsza liczbę operacji ponownego buforowania podczas oglądania filmów o 30%.
Wśród zmian w specyfikacji HTTP/1.1 można zwrócić uwagę na zakaz izolowanego stosowania znaku powrotu karetki (CR) poza treścią, czyli tzw. W elementach protokołu znak CR może być używany tylko w połączeniu ze znakiem nowego wiersza (CRLF). Algorytm układu żądania fragmentarycznego został ulepszony, aby uprościć oddzielanie dołączonych pól i sekcji za pomocą nagłówków. Dodano zalecenia dotyczące postępowania z niejednoznacznymi treściami w celu blokowania ataków „HTTP Request Smuggling”, które pozwalają nam wcisnąć się w treść żądań innych użytkowników w przepływie pomiędzy frontendem a backendem.
Aktualizacja specyfikacji HTTP/2.0 wyraźnie definiuje obsługę protokołu TLS 1.3. Przestarzały schemat ustalania priorytetów i powiązane pola nagłówka. Niewykorzystany mechanizm aktualizacji połączenia HTTP/1.1 został uznany za przestarzały. Zmniejszono wymagania dotyczące sprawdzania nazw i wartości pól. Zaproponowano do użycia niektóre wcześniej zarezerwowane typy ramek i parametry. Niedozwolone pola nagłówka związane z połączeniem są dokładniej zdefiniowane.
Źródło: opennet.ru