Firma Cloudflare aby zapewnić obsługę protokołu HTTP/3 w NGINX. Moduł zaprojektowany jako dodatek do biblioteki opracowanej przez firmę Cloudflare z implementacją protokołu transportowego QUIC i HTTP/3. Kod quiche jest napisany w Rust, ale sam moduł NGINX jest napisany w C i uzyskuje dostęp do biblioteki za pomocą dynamicznego łączenia. Rozwój na licencji BSD.
Aby złożyć, wystarczy pobrać do Nginx 1.16 i quiche, a następnie odbuduj nginx z opcjami „—with-http_v3_module —with-quiche=../quiche”. Podczas budowania obsługa TLS powinna opierać się na bibliotece BoringSSL („—with-openssl=../quiche/deps/boringssl”), użycie OpenSSL nie jest jeszcze obsługiwane. Aby akceptować połączenia, musisz dodać do ustawień dyrektywę Listen z flagą „quic” (na przykład „listen 443 quic reuseport”).
W oprogramowaniu klienckim dodano już obsługę protokołu HTTP/3 do eksperymentalnych wersji przeglądarki Chrome Canary i narzędzia curl. Po stronie serwera do tej pory konieczne było użycie oddzielnego, ograniczonego . Możliwość przetwarzania HTTP/3 w nginxie znacznie uprości wdrażanie serwerów z obsługą HTTP/3 i sprawi, że testowe wdrożenie nowego protokołu stanie się bardziej dostępne. Pojawienie się standardowej obsługi HTTP/3 w Nginx w gałęzi 1.17.x przez 6-12 miesięcy.
Przypomnijmy, że HTTP/3 standaryzuje użycie protokołu QUIC jako środka transportu dla HTTP/2. Protokół (Szybkie połączenia internetowe UDP) są rozwijane przez Google od 2013 roku jako alternatywa dla kombinacji TCP+TLS w Internecie, rozwiązując problemy związane z długim czasem konfiguracji i negocjacji połączeń w protokole TCP oraz eliminując opóźnienia w przypadku utraty pakietów 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.
Głównym SZYBKO:
- 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);
- Nieużywanie tego samego 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;
- Wyczuwalny wydajność i przepustowość 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