Komitet IETF (Internet Engineering Task Force), zajmujący się rozwojem protokołów i architektury internetu, zakończył tworzenie RFC dla protokołu QUIC i opublikował związane z nim specyfikacje pod identyfikatorami RFC 8999 (właściwości protokołu niezależne od wersji), RFC 9000 (transport na UDP), RFC 9001 (szyfrowanie komunikacji QUIC za pomocą TLS) oraz RFC 9002 (zarządzanie przeciążeniem i określanie utraty pakietów podczas transmisji danych).
RFC uzyskały status „Proponowanego standardu”, po czym rozpocznie się praca nad nadaniem RFC statusu standardu roboczego (Draft Standard), co w praktyce oznacza pełną stabilizację protokołu i uwzględnienie wszystkich zgłoszonych uwag. Protokół HTTP/3, który określa wykorzystanie protokołu QUIC jako transportu dla HTTP/2, wciąż znajduje się na etapie roboczej specyfikacji, jednak wkrótce również on zostanie ostatecznie sformalizowany w IETF.
Oczekuje się, że standaryzacja QUIC przyspieszy szersze wdrożenie tego protokołu, a także rozwój opartych na nim rozszerzeń, takich jak WebTransport (technologia do wysyłania i odbierania danych między przeglądarką a serwerem) i MASQUE (technologia proxy, rozszerzająca możliwości SOCKS i HTTP CONNECT, wykorzystująca HTTPS na QUIC jako transport).
Przypomnijmy, że protokół QUIC (Quick UDP Internet Connections) jest rozwijany przez firmę Google od 2013 roku jako alternatywa dla połączenia TCP+TLS w sieci Web, rozwiązująca problemy z długim czasem nawiązywania i negocjacji połączeń w TCP oraz eliminując opóźnienia związane z utratą pakietów podczas transmisji danych. QUIC jest nadbudową nad protokołem UDP, wspierającą multiplexing wielu połączeń i zapewniającą metody szyfrowania równoważne TLS/SSL. W trakcie opracowywania standardu w IETF do protokołu wprowadzono zmiany, co doprowadziło do powstania dwóch równolegle istniejących gałęzi, z których jedna jest przeznaczona dla HTTP/3, a druga wspierana przez Google (Chrome obsługuje oba warianty, a Firefox wariant IETF).
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.
Źródło: opennet.ru
