W nocnych wersjach Firefox oraz w wersji beta domyślnie włączone jest wsparcie dla protokołu HTTP/3. W stabilnej wersji włączenie HTTP/3 planowane jest na wydanie Firefox 88, zaplanowane na 20 kwietnia. W Chrome selektywne uruchamianie HTTP/3 rozpoczęło się w październiku 2020 roku.
Wsparcie HTTP/3 w Firefox opiera się na rozwijanym przez firmę Mozilla projekcie neqo, który dostarcza implementację klienta i serwera protokołu QUIC. Kod komponentów do wsparcia HTTP/3 i QUIC został napisany w języku Rust. Do zarządzania włączeniem HTTP/3 w about:config przewidziano opcję „network.http.http3.enabled”. W klientach eksperymentalne wsparcie HTTP/3 zostało również dodane do Chrome i curl, a dla serwerów jest dostępne w nginx, a także w formie modułu nginx i testowego serwera od firmy Cloudflare. W celu sprawdzenia działania klientów HTTP/3 uruchomiono kilka testowych stron.
Protokół HTTP/3 jest wciąż na etapie roboczej specyfikacji i nie został ostatecznie znormalizowany w IETF. HTTP/3 definiuje użycie protokołu QUIC jako transportu dla HTTP/2. Protokół QUIC (Quick UDP Internet Connections) jest rozwijany przez firmę Google od 2013 roku jako alternatywa dla zestawu TCP+TLS, rozwiązującego problemy związane z długim czasem nawiązywania i ustalania połączeń w TCP oraz eliminującego opóźnienia związane z utratą pakietów podczas przesyłania danych. QUIC stanowi nakładkę na protokół UDP, wspierającą multiplexowanie wielu połączeń i oferującą metody szyfrowania, odpowiadające TLS/SSL. W trakcie prac nad standardem w IETF w protokole wprowadzono zmiany, co doprowadziło do powstania dwóch równolegle istniejących gałęzi, jedna dla HTTP/3, a druga wspierana przez Google (Chrome wspiera obie wersje).
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 ustanowienia połączenia (0-RTT, w około 75% przypadków dane można przesyłać natychmiast po wysłaniu pakietu ustanowienia połączenia) oraz zapewnienie minimalnych opóźnień między wysłaniem żądania a otrzymaniem 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. Dla serwisów wideo, takich jak YouTube, zastosowanie QUIC wykazało 30% redukcję operacji ponownego buforowania podczas oglądania wideo.
Źródło: opennet.ru
