W Chrome dodano eksperymentalne wsparcie dla protokołu HTTP/3

W wersjach eksperymentalnych Chrome Canary dodano wsparcie protokołu HTTP/3, który implementuje nakładkę umożliwiającą działanie HTTP na protokole QUIC. Protokół QUIC został dodany do przeglądarki pięć lat temu i od tego czasu jest używany do optymalizacji pracy z usługami Google. Wariant QUIC zastosowany w Chrome różnił się w niektórych szczegółach od wersji z specyfikacji IETF, ale teraz implementacje zostały zsynchronizowane.

HTTP/3 standaryzuje użycie QUIC jako transportu dla HTTP/2. Aby włączyć HTTP/3 oraz wariant QUIC z 23 roboczych wersji specyfikacji IETF, wymagany jest start Chrome z opcjami „—enable-quic —quic-version=h3-23”, po czym przy otwieraniu testowej strony quic.rocks:4433 w trybie inspekcji sieci w narzędziach dla programistów aktywność związana z HTTP/3 będzie wyświetlana jako „http/2+quic/99”.

Przypomnijmy, że protokół QUIC (Quick UDP Internet Connections) od 2013 roku rozwijany jest przez firmę Google jako alternatywa dla połączenia TCP+TLS dla Web, rozwiązujący problemy z długim czasem ustanawiania i negocjowania połączeń w TCP oraz eliminujący opóźnienia spowodowane utratą pakietów w trakcie przesyłania danych. QUIC stanowi nakładkę na protokół UDP, wspierającą multiplikację wielu połączeń oraz zapewniającą metody szyfrowania równoważne TLS/SSL. Rozważany protokół został już zintegrowany z infrastrukturą serwerową Google, jest częścią Chrome, jest zaplanowane ma być włączony w Firefoxie i aktywnie stosowany do obsługi zapytań klientów na serwerach Google.

Podstawowe 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);
  • Nie używanie tego samego numeru sekwencji podczas ponownej transmisji pakietu, co pozwala uniknąć dwuznaczności przy określaniu odebranych pakietów i wyeliminować opóźnienia;
  • 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 kryptograficzne bloków są wyrównane z granicami pakietów QUIC, co zmniejsza wpływ strat pakietów na dekodowanie zawartości kolejnych 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 z TCP. Dla serwisów wideo, takich jak YouTube, zastosowanie QUIC wykazało zmniejszenie operacji ponownego buforowania podczas oglądania wideo o 30%.

Źródło: opennet.ru

Kup solidny hosting stron z ochroną przed DDoS, serwery VPS VDS 🔥 Kup solidny hosting stron z ochroną przed DDoS, serwery VPS VDS | ProHoster