QUIC (Quick UDP Internet Connections) to protokół działający na bazie UDP, który wspiera wszystkie możliwości TCP, TLS i HTTP/2 oraz rozwiązuje wiele ich problemów. Często nazywany jest nowym lub „eksperymentalnym” protokołem, ale od dawna przeszedł fazę eksperymentu: rozwijany jest od ponad 7 lat. W tym czasie protokół nie stał się standardem, ale mimo to zyskał szerokie zastosowanie. Na przykład QUIC jest wykorzystywany do przyspieszania ruchu i redukcji opóźnień w sieciach mobilnych przez takich gigantów jak Google i Facebook, a IETF ogłosiła jego forka podstawą dla standardu HTTP/3 (przy czym HTTP/2 wykorzystuje stron).
Koncepcja
QUIC został stworzony jako zamiennik przestarzałego TCP, które pierwotnie było dostosowane do przewodowych sieci o niskim procencie strat. TCP dostarcza pakiety w kolejności, więc w przypadku utraty jednego pakietu cała kolejka staje w miejscu (), co negatywnie wpływa na jakość i stabilność połączenia. Aby uniknąć masowych strat, sieci komórkowe stosują duże bufory, co z kolei prowadzi do nadmiarowości i fałszywie negatywnej reakcji protokołu (). Ponadto TCP marnuje dużo czasu na nawiązywanie połączenia: zapytania SYN/ACK i TLS idą osobno, wymagając trzech rund zamiast jednej, jak w przypadku QUIC.
Ponieważ QUIC łączy w sobie zamianę TCP i implementację TLS 1.3, wszystkie połączenia są zawsze szyfrowane, a deszyfrowanie takiego ruchu nie jest łatwiejsze niż w przypadku HTTPS. Co więcej, QUIC jest zaimplementowany na poziomie aplikacji, ponieważ pełna zamiana stosu TCP zajęłaby wieczność..
Mimo wsparcia dla multiplexingu w HTTP/2, problem head-of-line blocking pozostał z uwagi na konieczność dostarczania pakietów w kolejności. QUIC działa na bazie UDP, dlatego nie występują w nim blokady, a aby pakiety nie ginęły bezpowrotnie, są numerowane i mogą zawierać części „sąsiadów”, zapewniając nadmiarowość. Dodatkowo QUIC dzieli monolityczną kolejkę na kilka strumieni dla różnych typów żądań w ramach jednego połączenia. W ten sposób, przy utracie pakietu, problemy mogą wystąpić tylko w jednej kolejce (na przykład przy przesyłaniu konkretnego pliku):
Użycie
Pierwotnie QUIC był rozwijany w Google i był głównie dostosowany do użytku wewnętrznego w firmie. W 2013 roku przekazano go do IETF w celu standaryzacji (która trwa do dziś), a teraz każdy może wziąć udział w rozwoju protokołu, proponując to, czego mu brakuje. Grupa robocza IETF organizuje coroczne spotkania, na których zatwierdzany jest nowy standard i omawiane są innowacje. Ta implementacja QUIC jest uważana za podstawową i na jej podstawie certyfikowany jest standard HTTP/3.
Na razie nie mówi się o włączeniu HTTP/3 jako głównego protokołu, ponieważ nie jest on jeszcze ukończony i prawie nie jest wspierany:
Jednak QUIC można zrealizować jako transport między aplikacją a serwerem, co z powodzeniem zrobili w Uber:
Komentarz Ubera na temat implementacji QUIC
Aby pomyślnie zaimplementować QUIC i poprawić wydajność aplikacji w warunkach słabego połączenia, zastąpiliśmy stary stos (HTTP/2 nad TLS/TCP) protokołem QUIC. Skorzystaliśmy z biblioteki sieciowej z , która zawiera oryginalną, google'owską wersję protokołu – gQUIC. Ta implementacja jest również stale ulepszana, aby przestrzegać najnowszej specyfikacji IETF.
Najpierw zintegrowaliśmy Cronet w naszych aplikacjach na Androida, aby dodać wsparcie dla QUIC. Integracja została przeprowadzona w sposób, aby maksymalnie ograniczyć koszty migracji. Zamiast całkowicie zastąpić stary stos sieciowy, który korzystał z biblioteki , zintegrowaliśmy Cronet POD frameworkiem OkHttp API. Przeprowadzając integrację w ten sposób, uniknęliśmy zmian w naszych wywołaniach sieciowych (które używają ) na poziomie API.
Podobnie jak w przypadku urządzeń z Androidem, wdrożyliśmy Cronet w aplikacjach Uber na iOS, przechwytując ruch HTTP z , używając . Ta abstrakcja, dostarczana przez iOS Foundation, obsługuje specyficzne dla protokołu dane URL i zapewnia, że możemy zintegrować Cronet w naszych aplikacjach na iOS bez znacznych kosztów migracji.
pochodzi z artykułu Uber
Na backendzie przechwytywali połączenia QUIC przez Google Cloud lb, który od połowy 2018 roku.
Nie dziwi fakt, że Google Cloud doskonale współpracuje z protokołem stworzonym przez Google, ale jakie są alternatywy?
Nginx
Niedawno CloudFlare nginx (który domyślnie nie obsługuje HTTP/3) z własnym narzędziem Quiche. Realizacja jest dostępna w postaci jednego pliku .patch, do którego dołączono tutorial instalacyjny:
curl -O https://nginx.org/download/nginx-1.16.1.tar.gz
tar xvzf nginx-1.16.1.tar.gz
git clone --recursive https://github.com/cloudflare/quiche
cd nginx-1.16.1
patch -p01 < ../quiche/extras/nginx/nginx-1.16.patchTutaj można podłączyć własne moduły w razie potrzeby
./configure
--prefix=$PWD
--with-http_ssl_module
--with-http_v2_module
--with-http_v3_module
--with-openssl=../quiche/deps/boringssl
--with-quiche=../quiche
makePozostaje tylko włączyć wsparcie dla HTTP/3
events {
worker_connections 1024;
}
http {
server {
# Włącz QUIC i HTTP/3.
listen 443 quic reuseport;
# Włącz HTTP/2 (opcjonalnie).
listen 443 ssl http2;
ssl_certificate cert.crt;
ssl_certificate_key cert.key;
# Włącz wszystkie wersje TLS (TLSv1.3 jest wymagany dla QUIC).
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
# Buforowanie żądań proxy nie jest aktualnie obsługiwane dla HTTP/3.
proxy_request_buffering off;
# Dodaj nagłówek Alt-Svc do negocjacji HTTP/3.
add_header alt-svc 'h3-27=":443"; ma=86400';
}
} W zwykłych przeglądarkach połączenie przez HTTP/3 jest w tej chwili niemożliwe, ale można użyć i uruchomić go z flagą --enable-quic, połączyć się ze swoim serwerem lub np. z witryną quic.rocks i sprawdzić typ połączenia w Narzędziach Deweloperskich:
Zamiast HTTP/3 pisze się http2+quic/99, ale jest to w zasadzie to samo.
Inne technologie
- QUIC wspiera również (które z wielką pompą łączyły się z Facebookiem przez HTTP/3) oraz nowoczesny . Apache na razie nie obsługuje, ale prace trwają .
- 21 stycznia zaktualizowano
- Dosłownie kilka dni temu Microsoft udostępnił , w której na razie nie dostępne są wszystkie funkcje ze standardu IETF, ale to już duży postęp.
Podsumowanie
Zainteresowanie QUIC jest niestabilne, ale rośnie, trwają prace nad jego standaryzacją. Nowe implementacje protokołu pojawiają się niemal co miesiąc, a z każdym rokiem coraz więcej deweloperów przekonuje się, że przyszłość należy do QUIC. Dopuszcza się nawet włączenie protokołu do przyszłych wersji stosu TCP, co oznacza, że prędzej czy później cały internet przejdzie na bardziej stabilne i szybsze połączenia.
Już teraz możesz skonfigurować interakcję QUIC dla swojej infrastruktury lub nawet udostępniać ją przeglądarkom — wszystkie planują dodać wsparcie dla protokołu, a smutna statystyka z caniuse stanie się bardziej optymistyczna.
Źródło: habr.com
