Wydajność i wydajność: praca z HTTP/3

HTTP/3 jest na horyzoncie, podążając po piętach HTTP/2 — który sam prawdopodobnie jest wciąż bardzo młody. Biorąc pod uwagę, że przejście z HTTP/1.1 na HTTP/2 zajęło 16 lat, czy ktoś powinien naprawdę interesować się HTTP/3?

Krótka odpowiedź: Tak, to ważne i powinieneś być na bieżąco. To tak, jak HTTP/2 dokonał znaczących zmian w stosunku do HTTP/1.1, przełączając się z ASCII na binarny. HTTP/3 ponownie wprowadza znaczące zmiany, tym razem przełączając bazowy transport z TCP na UDP.

Chociaż HTTP/3 jest wciąż na etapie projektowania, a oficjalna specyfikacja jest szkicem, jest już wdrażana i istnieje duża szansa, że ​​dziś znajdziesz jego wersję działającą w swojej sieci.

Istnieją jednak nowe dylematy związane z działaniem HTTP/3. Jaka jest korzyść? A co powinni wiedzieć inżynierowie sieci, administratorzy systemów i programiści?

Główny problem: wydajność i efektywność

Twórcy witryn i aplikacji zazwyczaj tworzą z zamiarem faktycznego wykorzystania ich dzieł. Czasami baza odbiorców jest ograniczona, ale często chodzi o to, aby pozyskać jak najwięcej użytkowników. Oczywiście im bardziej popularna staje się strona internetowa, tym większe mogą być jej przychody.

100-milisekundowe opóźnienie w ładowaniu witryny może obniżyć współczynniki konwersji o 7 procent.

Raport wydajności sprzedaży internetowej Akamai: kluczowe znaczenie mają milisekundy (2017)

Innymi słowy, witryna eCommerce ze sprzedażą 40 000 USD dziennie straciłaby milion dolarów rocznie z powodu takiego opóźnienia.

Nie jest również tajemnicą, że wydajność witryny jest absolutnie kluczowa, aby witryna stała się bardziej popularna. Badania dotyczące zakupów online wciąż znajdują powiązania między zwiększonymi współczynnikami odrzuceń i dłuższym czasem ładowania, a także między lojalnością kupujących a wydajnością witryny podczas zakupów.

Badania wykazały również, że:

• 47% konsumentów oczekuje, że strona internetowa załaduje się w ciągu 2 sekund lub mniej.
• 40% osób opuszcza witrynę, której ładowanie trwa dłużej niż 3 sekundy.

I to był stan cierpliwości kupujących online ponad dekadę temu . Wydajność ma więc kluczowe znaczenie, a HTTP/2 i HTTP/3 oznaczają lepszą wydajność witryny.

HTTP/2? …Co to jest?

Dobre zrozumienie protokołu HTTP/2 ma kluczowe znaczenie dla zrozumienia protokołu HTTP/3. Przede wszystkim, dlaczego istniała potrzeba HTTP/2?

HTTP/2 rozpoczął się jako projekt Google o nazwie SPDY, wynik badania, które wykazało, że największym problemem z wydajnością w sieci było opóźnienie . Autor doszedł do wniosku, że „większa przepustowość nie ma (duże) znaczenia”:

Jeśli zrobimy analogię między hydrauliką a Internetem, możemy uznać przepustowość Internetu za średnicę rury wodociągowej. Większa rura przenosi większą objętość wody, dzięki czemu możesz dostarczyć więcej wody między dwoma punktami.

Jednocześnie, bez względu na to, jak duża jest twoja rura, jeśli rura jest pusta i chcesz przenosić wodę z jednego punktu do drugiego, potrzeba czasu, aby woda przepłynęła przez rurę. W żargonie internetowym czas potrzebny na przepłynięcie wody z jednego końca rury do drugiego iz powrotem nazywany jest czasem podróży w obie strony lub RTT .

Mike Belshe

W badaniu celem było skrócenie czasu ładowania strony. Okazało się, że zwiększenie przepustowości początkowo pomaga, ponieważ przejście z 1 Mb/s do 2 Mb/s skraca o połowę czas ładowania strony. Jednak korzyści bardzo szybko się ustabilizują.

W przeciwieństwie do tego zmniejszanie latencji przynosi stałą korzyść i pozwala osiągnąć najlepsze rezultaty.

HTTP HOL: problem blokowania nagłówków

Główną przyczyną opóźnień w protokole HTTP/1 jest problem blokowania nagłówka linii. Strony internetowe (prawie zawsze) wymagają wielu zasobów: CSS, JavaScript, czcionek, obrazów, AJAX/XMR itp. Oznacza to, że przeglądarka internetowa musi wysyłać wiele żądań do serwera. Jednak nie wszystkie zasoby są wymagane, aby strona stała się użyteczna.

W przypadku HTTP/1.0 konieczne było, aby przeglądarka w pełni zrealizowała żądanie, w tym w pełni otrzymała odpowiedź, przed rozpoczęciem kolejnego żądania. Wszystko trzeba było zrobić po kolei. Każde żądanie zablokowałoby linię żądań, stąd nazwa.

Próbując zrekompensować problem blokowania HOL, przeglądarki internetowe nawiązują wiele jednoczesnych połączeń z jednym serwerem. Musieli jednak arbitralnie ograniczyć to zachowanie: serwery, stacje robocze i sieci mogą zostać przeciążone zbyt dużą liczbą połączeń.

Protokół HTTP/1.1 wprowadził kilka ulepszeń, które pomogą rozwiązać ten problem. Głównym z nich jest potokowanie , umożliwiające przeglądarkom internetowym uruchamianie nowych żądań bez konieczności czekania na zakończenie poprzednich żądań. To znacznie skróciło czas ładowania w środowiskach o niskich opóźnieniach.

Ale nadal wymaga, aby wszystkie odpowiedzi docierały sekwencyjnie w kolejności, w jakiej zostały wykonane, więc początek linii jest nadal zablokowany. Co zaskakujące, wiele serwerów nadal nie korzysta z tej funkcji.

Co ciekawe, protokół HTTP/1.1 wprowadził również funkcję utrzymywania aktywności, która pozwalała przeglądarkom uniknąć narzutu związanego z tworzeniem nowego połączenia TCP dla każdego żądania HTTP. Była to wczesna próba rozwiązania problemu z wydajnością pochodzącego z protokołu TCP. Był tak nieefektywny, że większość ekspertów od wydajności faktycznie go odradza, ponieważ powoduje to ugrzęźnięcie serwera ze zbyt dużą liczbą nieaktywnych połączeń. Poniżej przyjrzymy się bliżej TCP, a także temu, jak ten problem został rozwiązany przez HTTP/2.

Rozwiązanie blokowania HOL HTTP/2 w HTTP

Protokół HTTP/2 wprowadził multipleksowanie żądanie-odpowiedź w ramach jednego połączenia. Przeglądarka może nie tylko rozpocząć nowe żądanie w dowolnym momencie, ale także otrzymywać odpowiedzi w dowolnej kolejności — blokowanie jest całkowicie wyeliminowane na poziomie aplikacji.

W rezultacie oznacza to, że serwery internetowe obsługujące protokół HTTP/2 mogą zmaksymalizować wydajność — więcej o tym później.

Chociaż multipleksowanie żądanie-odpowiedź jest główną funkcją protokołu HTTP/2, zawiera kilka innych istotnych funkcji. Czytelnicy mogą zauważyć, że wszystkie są nieco spokrewnione.

Ramki binarne HTTP/2

HTTP/2 zmienia standard protokołu HTTP z nieefektywnego, czytelnego dla człowieka modelu żądanie-odpowiedź ASCII na wydajne ramkowanie binarne . To już nie tylko prośba i odpowiedź:

W przypadku protokołu HTTP/2 przeglądarki komunikują się z serwerami za pośrednictwem dwukierunkowych strumieni z wieloma wiadomościami, z których każdy składa się z wielu ramek.

HTTP/2 HPACK (kompresja nagłówka)

Nowa kompresja nagłówków HTTP/2, wykorzystująca format HPACK, pozwala zaoszczędzić mnóstwo przepustowości w przypadku większości witryn. Dzieje się tak, ponieważ większość nagłówków jest taka sama dla żądań wysyłanych w ramach połączenia.

Cloudflare zgłasza znaczne oszczędności przepustowości dzięki samemu HPACK:

• Kompresja 76% dla nagłówków wejściowych
• 53% redukcja całkowitego ruchu przychodzącego
• Kompresja 69% dla nagłówków wychodzących
• Zmniejszenie całkowitego ruchu wychodzącego o 1,4% do 15%

Oczywiście użycie mniejszej przepustowości zazwyczaj oznacza szybszą stronę internetową.

Priorytetyzacja strumienia HTTP/2 i push serwera

W tym miejscu multipleksowanie HTTP/2 naprawdę pozwala serwerowi na maksymalizację wydajności. Multipleksowanie pomaga obsługiwać szybsze zasoby (np. JavaScript buforowany w pamięci) przed wolniejszymi (np. duże obrazy, JSON generowany przez bazę danych itp.). Ale pozwala również na dodatkowy wzrost wydajności dzięki priorytetyzacji strumieni HTTP/2 .

Priorytetyzacja strumienia pomaga zapewnić, że prawie gotowe aspekty strony zostaną w pełni ukończone bez konieczności czekania na zakończenie innych żądań wymagających dużej ilości zasobów. Odbywa się to za pomocą ważonego drzewa zależności. To drzewo służy do informowania serwera, w jakich odpowiedziach powinien przydzielać najwięcej zasobów systemowych do obsługi.

Jest to szczególnie ważne w przypadku progresywnych aplikacji internetowych (PWA). Załóżmy na przykład, że strona zawiera cztery pliki JavaScript. Dwa dotyczą funkcjonalności strony, a dwa reklam. Najgorszym scenariuszem jest załadowanie połowy funkcjonalnego JS i połowy reklamowego JS, a następnie ładowanie dużych obrazów przed załadowaniem pozostałych JS. W takim przypadku początkowo nic na stronie nie działa, ponieważ wszystko musi czekać na najwolniejszy zasób.

Dzięki priorytetyzacji strumieni przeglądarki internetowe mogą poinstruować serwer, aby wysłał oba pliki JS dotyczące funkcji strony przed wysłaniem któregokolwiek z reklamowych plików JavaScript. Dzięki temu użytkownicy nie muszą czekać na pełne załadowanie reklam przed skorzystaniem z funkcjonalności strony. Chociaż ogólny czas ładowania nie uległ poprawie, postrzegana wydajność została znacznie zwiększona. Niestety, to zachowanie w przeglądarce internetowej nadal jest głównie kwestią algorytmów, a nie jest czymś określonym przez twórców stron internetowych.

W ten sam sposób, funkcja serwera push HTTP/2 umożliwia serwerowi wysyłanie odpowiedzi do przeglądarki na żądania, których jeszcze nie wysłał! Serwer może wykorzystać luki w transmisji, efektywnie wykorzystując przepustowość poprzez wstępne ładowanie do zasobów przeglądarki, o których wie, że serwer wkrótce zażąda. Częścią nadziei tutaj jest wyeliminowanie praktyki inliningu zasobów, która po prostu powiększa zasoby i sprawia, że ​​ładowanie trwa dłużej.

Niestety, aby naprawdę odnieść sukces, obie te funkcje wymagają bardzo starannej konfiguracji przez twórców stron internetowych. Samo ich włączenie nie wystarczy.

HTTP/2 niesie ze sobą wiele potencjalnych zalet — niektóre z nich są tańsze w użyciu niż inne. Jak radzą sobie w prawdziwym świecie?

Przyjęcie HTTP a HTTP/2

SPDY powstało w 2009 roku. HTTP/2 został ujednolicony w 2015 roku. SPDY stał się nazwą niestabilnej gałęzi rozwojowej kodu, a HTTP/2 stał się jego ostateczną wersją. W rezultacie SPDY stał się przestarzały, a HTTP/2 jest powszechnie stosowanym standardem.

Po standaryzacji, przyjęcie HTTP/2 (lub „h2”) szybko wzrosło do około 40% z 1000 najlepszych stron internetowych. Było to spowodowane głównie przez dużych dostawców hostingu i chmury wdrażających wsparcie w imieniu swoich klientów. Niestety, kilka lat później, adopcja HTTP/2 zwolniła i większość internetu nadal korzysta z HTTP/1.

Brak obsługi przeglądarki dla trybu zwykłego tekstu HTTP/2

Było wiele wywołań protokołu HTTP/2, aby szyfrowanie stało się wymaganą częścią standardu. Zamiast tego standard zdefiniował zarówno tryby szyfrowany (h2), jak i czysty tekst (h2c). W związku z tym HTTP/2 może całkowicie zastąpić HTTP/1.

Pomimo standardu, wszystkie obecne przeglądarki internetowe obsługują tylko protokół HTTP/2 w połączeniach szyfrowanych i celowo nie implementują trybu zwykłego tekstu. Zamiast tego przeglądarki korzystają z trybu kompatybilności wstecznej HTTP/1, aby uzyskać dostęp do niezabezpieczonych serwerów. Jest to bezpośredni wynik ideologicznego dążenia do domyślnego zabezpieczenia sieci.

Dlaczego HTTP/3? A jak to się różni?

Ponieważ problem blokowania nagłówka linii HTTP został naprawiony przez HTTP/2, twórcy protokołów zwrócili swoją uwagę na kolejny największy sterownik opóźnień: problem blokowania nagłówka linii TCP .

Protokół kontroli transmisji (TCP)

Sieci IP (protokół internetowy) opierają się na idei komputerów wysyłających sobie nawzajem pakiety. Pakiet to po prostu dane z dołączoną na górze informacją adresową.

Ale aplikacje zwykle muszą radzić sobie ze strumieniami danych. Aby osiągnąć tę iluzję, protokół kontroli transmisji (TCP) przedstawia aplikacjom potok, przez który może przepływać strumień danych. Podobnie jak w przypadku większości potoków, istnieje gwarancja, że ​​dane wyjdą z potoku w tej samej kolejności, w jakiej wchodzą, znanej również jako „pierwsze weszło, pierwsze wyszło” (FIFO). Te cechy sprawiły, że protokół TCP jest bardzo użyteczny i szeroko stosowany.

Jako część gwarancji dostarczania danych, które zapewnia TCP, musi być w stanie obsłużyć wiele różnych sytuacji. Jednym z najbardziej złożonych problemów jest dostarczanie wszystkich danych, gdy sieć jest przeciążona, bez pogarszania sytuacji dla wszystkich. Algorytm służący do tego nazywa się kontrolą przeciążenia i jest stale rozwijającą się częścią specyfikacji internetowych. Bez wystarczającej kontroli przeciążenia internet staje w miejscu.

W październiku 1986 r. w Internecie nastąpił pierwszy z serii „załamań przeciążenia”. W tym okresie przepustowość danych z LBL do UC Berkeley (miejsca oddalone o 400 jardów i trzy przeskoki IMP) spadła z 32 Kb/s do 40 b/s.

V. Jacobsona (1988)

W tym miejscu pojawia się problem blokowania nagłówka linii TCP.

Problem blokowania TCP HOL

Kontrola przeciążenia TCP działa poprzez implementację mechanizmów wycofywania i retransmisji dla pakietów, używanych w przypadku wykrycia utraty pakietów. Backoff ma pomóc uspokoić sieć. Retransmisja zapewnia, że ​​dane zostaną ostatecznie dostarczone.

Oznacza to, że dane TCP mogą dotrzeć do miejsca docelowego w złej kolejności, a strona odbierająca jest odpowiedzialna za zmianę kolejności pakietów przed ponownym połączeniem ich w strumień. Niestety oznacza to, że pojedynczy utracony pakiet może spowodować wstrzymanie całego strumienia TCP na czas oczekiwania serwera na jego retransmisję. W związku z tym głowica linii jest zablokowana.

Inny projekt Google miał na celu rozwiązanie tego problemu poprzez wprowadzenie protokołu o nazwie QUIC.

Protokół QUIC jest zbudowany na bazie UDP zamiast TCP, a QUIC stanowi podstawę dla HTTP/3.

Co to jest UDP?

Protokół datagramów użytkownika (UDP) jest alternatywą dla TCP. Nie zapewnia iluzji strumienia ani tych samych gwarancji, które oferuje TCP. Zamiast tego zapewnia łatwy sposób umieszczania danych w pakiecie, adresowania go do innego komputera i wysyłania. Jest zawodny , nieuporządkowany i nie jest wyposażony w żadną formę kontroli przeciążenia.

Jego celem jest bycie lekkim i zapewnienie minimum funkcji niezbędnych do umożliwienia komunikacji. W ten sposób aplikacja może realizować własne gwarancje. Jest to często bardzo przydatne w aplikacjach czasu rzeczywistego. Na przykład w rozmowach telefonicznych użytkownicy zazwyczaj wolą otrzymywać 90% danych natychmiast, a nie ostatecznie 100% danych.

Rozwiązanie TCP HOL HTTP/3

Rozwiązanie problemu blokowania TCP HOL wymagało czegoś więcej niż tylko przejścia na UDP, ponieważ nadal konieczne jest zagwarantowanie dostarczania wszystkich danych i uniknięcie przeciążenia sieci. Protokół QUIC został zaprojektowany w celu wykonania tego wszystkiego, zapewniając zoptymalizowane środowisko HTTP przez UDP.

Ponieważ QUIC przejmuje kontrolę nad zarządzaniem strumieniem, ramkami binarnymi itp., niewiele pozostaje do zrobienia dla HTTP/2, gdy działa na QUIC. Jest to część czynnika napędzającego tę nową kombinację QUIC + HTTP, która jest standaryzowana jako HTTP/3.

Uwaga: istnieje wiele wersji QUIC, ponieważ protokół był rozwijany i wdrażany w środowiskach produkcyjnych od lat. Istnieje nawet wersja specyficzna dla Google o nazwie GQUIC. W związku z tym ważne jest, aby odróżnić stare protokoły QUIC od nowego standardu HTTP/3.

Zawsze szyfrowane

HTTP/3 zawiera szyfrowanie, które w dużej mierze zapożycza od TLS, ale nie używa go bezpośrednio. Jednym z głównych wyzwań implementacyjnych dla HTTP/3 jest konieczność modyfikacji bibliotek TLS/SSL w celu dodania nowej wymaganej funkcjonalności.

Ta zmiana jest spowodowana tym, że HTTP/3 różni się od HTTPS pod względem sposobu szyfrowania. W przypadku starszego protokołu HTTPS tylko same dane są chronione przez TLS, pozostawiając widocznych wiele metadanych transportu. W HTTP/3 chronione są zarówno dane, jak i protokół transportowy. Może to brzmieć jak funkcja bezpieczeństwa i tak jest. Ale robi się to w ten sposób, aby uniknąć wielu narzutów obecnych w HTTP/2. W związku z tym szyfrowanie protokołu transportowego, a także danych, w rzeczywistości zwiększa wydajność protokołu.

Wpływ HTTP/3 na infrastrukturę sieciową

HTTP/3 nie jest pozbawiony kontrowersji. Główne obawy dotyczą infrastruktury sieciowej.

HTTP/3 po stronie klienta

Po stronie klienta dość często zdarza się, że ruch UDP jest mocno ograniczony i/lub blokowany. Stosowanie tych ograniczeń do protokołu HTTP/3 jest sprzeczne z celem protokołu.

Po drugie, dość często zdarza się, że HTTP jest monitorowany i/lub przechwytywany. Nawet w przypadku ruchu HTTPS sieci regularnie obserwują elementy transportowe protokołu w postaci zwykłego tekstu, aby określić, czy powinny zerwać połączenie w celu uniemożliwienia dostępu do niektórych witryn z określonych sieci lub w określonych regionach. W niektórych krajach jest to nawet wymagane przez prawo dla niektórych usługodawców. Obowiązkowe szyfrowanie w HTTP/3 uniemożliwia to.

To nie tylko filtrowanie na poziomie rządowym. Wiele uniwersytetów, bibliotek publicznych, szkół i domów z zaniepokojonymi rodzicami aktywnie decyduje się na blokowanie dostępu do niektórych stron internetowych lub przynajmniej prowadzenie dziennika odwiedzonych stron. Obowiązkowe szyfrowanie w HTTP/3 uniemożliwia to.

Warto zauważyć, że obecnie możliwe jest ograniczone filtrowanie. Dzieje się tak, ponieważ pole wskazujące nazwę serwera (SNI) — które zawiera nazwę hosta witryny, ale nie zawiera ścieżki, parametrów zapytania itp. — nadal nie jest zaszyfrowane. Ale to ma się zmienić w najbliższej przyszłości wraz z wprowadzeniem ESNI (szyfrowanego SNI), który został niedawno dodany do standardu TLS.

HTTP/3 po stronie serwera

Po stronie serwera najlepszą praktyką jest blokowanie wszelkich portów i protokołów, które nie oczekują ruchu, co oznacza, że ​​administratorzy serwerów muszą teraz otworzyć UDP 443 dla HTTP/3, zamiast polegać na istniejących regułach TCP 443.

Po drugie, infrastruktura sieciowa może sprawić, że sesje TCP będą lepkie , co oznacza, że ​​zawsze będą kierowane do tego samego serwera, nawet jeśli zmienią się priorytety routingu. Ponieważ HTTP/3 działa przez UDP — który jest bezsesyjny — infrastruktura sieci musi zostać zaktualizowana, aby śledzić identyfikatory połączeń specyficzne dla HTTP/3, które zostały niezaszyfrowane, aby pomóc w routingu stałym.

Po trzecie, dość często zdarza się, że protokół HTTP jest sprawdzany w celu wykrycia nadużyć, monitorowania typowych problemów z bezpieczeństwem, wykrywania i zapobiegania rozprzestrzenianiu się złośliwego oprogramowania i wirusów itp. Nie jest to możliwe w przypadku protokołu HTTP/3 ze względu na jego szyfrowanie. Mimo to opcje, w których urządzenie przechwytujące ma kopię kluczy bezpieczeństwa, są nadal możliwe, zakładając, że urządzenia implementują obsługę protokołu HTTP/3.

Wreszcie, wielu administratorów sprzeciwia się konieczności zarządzania jeszcze większą liczbą certyfikatów SSL, chociaż obecnie jest to mniejszy problem, gdy dostępne są usługi takie jak Let's Encrypt.

Dopóki nie pojawią się powszechnie akceptowane, dobrze znane rozwiązania, które rozwiążą te problemy, myślę, że prawdopodobnie wiele dużych sieci po prostu zablokuje HTTP/3.

Wpływ HTTP/3 na tworzenie stron internetowych

Na tym froncie nie ma się czym martwić. Priorytetyzacja strumieni HTTP/2 i funkcje serwera push są nadal obecne w HTTP/3. Deweloperzy stron internetowych powinni zapoznać się z tymi funkcjami, jeśli chcą naprawdę zoptymalizować wydajność swojej witryny.

Korzystanie z HTTP/3 już teraz

Użytkownicy Google Chrome lub przeglądarki Chromium o otwartym kodzie źródłowym są już skonfigurowani do korzystania z protokołu HTTP/3. Wersje produkcyjne serwerów HTTP/3 są jeszcze trochę odległe — specyfikacja nie jest jeszcze do końca sfinalizowana. Ale tymczasem istnieje wiele narzędzi do zabawy, a zarówno Google, jak i Cloudflare już wdrożyły wsparcie dla swoich środowisk produkcyjnych.

Najprostszym sposobem na wypróbowanie tego jest użycie Caddy w Dockerze. Potrzebny jest do tego certyfikat SSL, więc publicznie dostępny adres IP ułatwia sprawę. Kroki to:

1. Konfiguracja DNS. Uzyskaj działającą nazwę hosta, która jest dostępna w Internecie, np. yourhostname.example.com IN A 192.0.2.1 .
2. Tworzenie pliku Caddy. Powinien zawierać te wiersze:

 yourhostname.example.com log stdout errors stdout ext .html .htm .md .txt browse gzip tls [email protected]

1. Uruchamianie Caddy: docker run -v Caddyfile:/etc/Caddyfile -p 80:80 -p 443:443 abiosoft/caddy --quic —lub poza caddy --quic .
2. Uruchamianie chromu z włączoną funkcją QUIC: chromium --enable-quic
3. (Opcjonalnie) Instalowanie rozszerzenia wskaźnika protokołu.
4. Przejście do serwera obsługującego QUIC , na którym powinna być widoczna przeglądarka plików.

Deweloperzy mogą również testować swoje serwery za pomocą następujących przydatnych narzędzi:

• Test HTTP/2 Keycdn
• HTTP3Check LiteSpeed
• Test serwera SSL Qualys

Dziękuje za przeczytanie!