Grupa zadaniowa ds. inżynierii internetowej (IETF), która jest odpowiedzialna za rozwój protokołów i architektury internetowej, sfinalizowała dokument RFC dla protokołu QUIC i opublikowała powiązane specyfikacje pod identyfikatorami RFC 8999 (właściwości protokołu niezależne od wersji), RFC 9000 (transport przez UDP), RFC 9001 (szyfrowanie TLS kanału komunikacyjnego QUIC) i RFC 9002 (kontrola przeciążenia i wykrywanie utraty pakietów podczas transmisji danych).
Dokumenty RFC uzyskały status „Proponowanego Standardu”, po czym rozpoczną się prace nad nadaniem RFC statusu projektu standardu (Draft Standard), co w rzeczywistości oznacza pełną stabilizację protokołu i uwzględnienie wszystkich zgłoszonych uwag. Protokół HTTP/3, który definiuje wykorzystanie protokołu QUIC jako środka transportu dla HTTP/2, znajduje się wciąż na etapie projektu specyfikacji, ale wkrótce zostanie ostatecznie ujednolicony przez IETF.
Oczekuje się, że standaryzacja QUIC da impuls do szerszego zastosowania tego protokołu, a także do rozwoju opartych na nim rozszerzeń, takich jak WebTransport (technologia wysyłania i odbierania danych pomiędzy przeglądarką a serwerem) oraz MASQUE (technologia proxy połączeń, która rozszerza możliwości SOCKS i HTTP CONNECT oraz wykorzystuje HTTPS przez QUIC jako transport).
Przypomnijmy, że protokół QUIC (Quick UDP Internet Connections) jest rozwijany przez Google od 2013 roku jako alternatywa dla kombinacji TCP+TLS dla Internetu, rozwiązując problemy związane z długim czasem konfiguracji i negocjacji połączeń w protokole TCP oraz eliminując opóźnienia podczas pakiety giną podczas przesyłania danych. QUIC jest rozszerzeniem protokołu UDP, które obsługuje multipleksowanie wielu połączeń i zapewnia metody szyfrowania równoważne TLS/SSL. Podczas opracowywania standardu IETF wprowadzono zmiany w protokole, co doprowadziło do powstania dwóch równoległych gałęzi, jednej dla HTTP/3 i drugiej obsługiwanej przez Google (Chrome obsługuje obie opcje, a Firefox obsługuje wersję IETF) .
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%.
Źródło: opennet.ru