Internet, jaki znamy, się kończy... nowe HTTP, czyli jedna z cichych rewolucji 2020

Dzisiaj dwa słówka o tym, jak wywołać sobie taki piękny obrazek:

Zacznijmy od tego, że dawno, dawno temu strony WWW były oczywiście bardzo proste, nienowoczesne, i w ogóle okropne.

Jak wszyscy wiemy, powstawały kolejne wersje protokołu HTML, które opisywały treść dokumentów tekstowych do interpretacji i porządkowały to, co chociażby wyrabiał Netscape i Microsoft.

W ten oto piękny sposób doszliśmy do HTML 5 (a nawet, jeśli spojrzeć na https://www.w3.org/TR/, do HTML 5.3) i sytuacji, gdzie zamiast samych dokumentów z treścią mamy też arkusze stylów, pliki z JavaScript i różne inne elementy.

Problemem jest w tym momencie fakt, że cały ten system nie zawsze pięknie pozwala opisać wygląd (coś, czego wielu użytkowników potrzebuje w pierwszej kolejności), natomiast niesie za sobą coraz większy bagaż kompatybilności wstecznej.

Do tego dochodzą wszelkiego rodzaju reklamy, dodatkowe niewidoczne znaczniki, i nagle okazuje się, że wymieniamy znacznie więcej bajtów niż kiedyś (o wideo i Internecie Rzeczy nie trzeba chyba wspominać?)

Rosnąca ilość urządzeń spowodowała, że IPv4 powoli zaczęto zastępować przez IPv6 (w bólach i w sposób widoczny dla użytkowników).

Żeby nadążyć za rosnącymi potrzebami, trzeba było jeszcze pomajstrować przy kolejnej warstwie.

Po opartym na TCP protokole HTTP/1.0 przyszła kolej na HTTP/1.1 (tu rozwój zatrzymał się w 2014, jeśli dobrze widzę na https://www.w3.org/Protocols/).

Jedną z głównych zmian było dodanie tzw. pipelingu - zamiast sekwencji "pytanie o plik w połączeniu TCP‑odpowiedź" (ułożonych jedna za drugą), pozwolono tam na równoczesne nawiązanie kilku połączeń TCP i wysyłanie zapytań o kilka plików bez czekania na odpowiedź (przy czym odpowiedzi z serwera musiały przyjść w tej samej kolejności co zapytania). Nie wszystkie przeglądarki to wspierały z uwagi na problemy techniczne (więcej).

W 2015 pojawiło się HTTP/2.0 będące niejako odpowiedzią na protokół SDPY Google, w którym dodano możliwość pobierania wielu plików przez jedno połączenie TCP, czyli tzw. multiplexing (co ważne, nie liczyła się już kolejność wysyłania odpowiedzi przez serwer)

Inną zmianą było chociażby możliwość nadawania priorytetu plików, powiadomienia typu push (po rejestracji to serwer wysyła informację), kompresja nagłówków i kodowanie binarne przesyłanych plików HTML.

To w wielu przypadkach przyspieszyło wczytywanie stron internetowych, teraz jednak postanowiono pójść dalej i zdefiniowano HTTP/3 bazujący na protokole QUIC od Google.

Główną zmianą jest używanie połączeń UDP zamiast TCP, co w wielu uproszczeniu oznacza komunikację typu "wysyłamy coś i nie martwimy się, czy doszło - odbiorca najwyżej poprosi jeszcze raz" zamiast "nawiązujemy połączenie z upewnieniem się, że połączenie jest nawiązane".

Dzięki tej zmianie utrata chociażby jednego pakietu w połączeniu TCP nie blokuje na pewien czas całej transmisji.

Kolejną nowością są nowe standardy szyfrowania - przeglądarki w HTTP/2 miały do wyboru wersję "z" i "bez" szyfrowania (i co trzeba zaznaczyć, implementowały HTTP/2 przez TLS), tutaj zakłada się generalnie zawsze używanie szyfrowania (choć w pewnych wypadkach mogłoby być wyłączone).

Na każdej platformie mamy już eksperymentalną obsługę nowego protokołu. Apple zdaje się włącza go na stałe w Big Siur i iPhone, można go też mieć w Firefox i Chromie (w pierwszej przeglądarce w about:config włączamy parametr z końcówką http3, w drugiej w chrome://flags eksperyment z nazwą QUIC).

Działa? Działa.

Żeby jednak nie było wątpliwości - błąd 400 pochodzi z desktopowego Firefoxa i widzę go dosyć często po włączeniu HTTP/3 na YouTube.

Nowość wymaga jeszcze doszlifowania i pewnie dlatego nie jest domyślnie włączana. Na różnych stronach można znaleźć informacje, że przyspiesza ładowanie stron do ok. 10% za cenę większego zużycia RAM i CPU na serwerach (co nieco może zabrać też po stronie klienta).

Czy warto?

Google mówi, że tak... i ja akurat w to wierzę. Myślę przy tym jedno - jest to rewolucja, ale... większą rewolucją jest używanie przeglądarki z porządnym ad‑blockerem, który pewnie zmniejszy ruch znacznie bardziej niż HTTP/3 (do tego warto myśleć o prywatności i włączyć HTTPS dla DNS i własnego User-Agent, co np. na Androidzie jest możliwe w Bromite).

I jeszcze jakieś linki (a co sobie żałować):

https://blog.cloudflare.com/introducing-http2/

https://ma.ttias.be/googles-quic-protocol-moving-web-tcp-udp/

https://blog.cloudflare.com/http-3-vs-http-2/

https://en.wikipedia.org/wiki/HTTP/2

https://en.wikipedia.org/wiki/HTTP/3

https://en.wikipedia.org/wiki/QUIC

https://www.fastvue.co/fastvue/blog/googles-quic-protocols-security-an...

i mój ulubiony https://nodejs.org/api/quic.html