Co to jest HTTP/2?

HTTP/2 sprawi, że nasze strony internetowe będą działały szybciej. Będą szybsze, prostsze i niezawodne, Umożliwiają nam ominięcie wielu problemów związanych z protokołem HTTP/1.1. Co więcej, otwiera nam również szereg zupełnie nowych możliwości optymalizacji naszych aplikacji i stron WWW i poprawia ich wydajności!

Cele HTTP/2

Głównym celem protokołu HTTP/2 jest zmniejszenie opóźnień. Dzieje się to poprzez umożliwienie pełnego multipleksowania żądań i odpowiedzi. Dodatkowo minimalizuje obciążenia protokołu poprzez wydajną kompresję pól nagłówka HTTP. Ponadto dodaje obsługi priorytetyzacji żądań serwera. Kolejne udogodnienia to duża liczba ulepszeń protokołów, takich jak kontrola przepływu, obsługa błędów i mechanizmy aktualizacji.

Cele główne HTTP/2 to optymalizacja, przyspieszenie i większa kontrola pracy serwera.

HTTP/2 w żaden sposób nie modyfikuje semantyki aplikacji HTTP. Wszystkie podstawowe koncepcje, takie jak metody HTTP, kody stanu, identyfikatory URI i pola nagłówka, pozostają niezmienione. Zamiast tego HTTP/2 modyfikuje sposób formatowania (ramkowania) danych i transportu między klientem a serwerami, które zarządzają całym procesem i ukrywa całą złożoność naszych aplikacji w nowej warstwie ramek. Tak zaprojektowana zmiana zagwarantowała nam to, że wszystkie istniejące aplikacje nie wymagają modyfikacji.

Cele techniczne HTTP/2

Wcześniejsze wersje protokołu HTTP zostały celowo zaprojektowane z myślą o uproszczeniu implementacji: HTTP/0.9 był jednowierszowym protokołem do ładowania sieci WWW. HTTP/1.0 udokumentował popularne rozszerzenia HTTP/0.9 w standardzie informacyjnym; HTTP/1.1 wprowadził oficjalny standard IETF. W związku z tym protokół HTTP/0.9-1.x zapewnił dokładnie to, co zamierzał: HTTP jest jednym z najczęściej stosowanych protokołów aplikacji w Internecie.

Niestety, prostota implementacji obarczona jest kosztem związanym z niską wydajnością aplikacji. Klienci HTTP/1.x muszą korzystać z wielu połączeń, aby osiągnąć współbieżność i zmniejszyć opóźnienia w działaniu stron. HTTP/1.x nie kompresuje nagłówków żądań i odpowiedzi, powodując niepotrzebny ruch sieciowy. HTTP/1.x nie pozwala na efektywne ustalanie priorytetów zasobów, co skutkuje słabym wykorzystaniem podstawowego połączenia TCP.

Ograniczenia te generowały nadmiar w obciążenia serwerów, jak również serwerów Google. Wraz ze wzrostem zakresu, złożoności i znaczenia aplikacji internetowych w naszym codziennym życiu, nakładały one coraz większe obciążenie zarówno na deweloperów, jak i użytkowników sieci.

Zwróćcie uwagę na to, że HTTP/2 rozszerza, a nie zastępuje poprzednie standardy HTTP. Semantyka aplikacji HTTP jest taka sama i nie wprowadzono żadnych zmian w poprzedniej funkcjonalności lub podstawowych koncepcjach.

Binarna warstwa kadrowania

Podstawą wszystkich ulepszeń wydajności HTTP/2 jest nowa warstwa ramek binarnych, która określa sposób enkapsulacji i przesyłania wiadomości HTTP między klientem a serwerem.

HTTP/2 wprowadza nową warstwę pomiędzy interfejsem gniazda a wyższym interfejsem HTTP API

Semantyka HTTP, czyli zmienne, metody i nagłówki, pozostaje niezmieniona, ale sposób, w jaki są zakodowane, jest inny bardziej optymalny. W przeciwieństwie do protokołu HTTP/1.x gdzie tekst rozdzielanym znakami nowej linii w HTTP/2 jest dzielony na mniejsze wiadomości i ramki, z których każda jest zakodowana w formacie binarnym.

W rezultacie zarówno klient, jak i serwer muszą używać nowego mechanizmu kodowania binarnego, aby zrozumieć się nawzajem: klient HTTP/1.x nie zrozumie serwera tylko HTTP/2 i na odwrót. Nasze aplikacje nie muszą o tym wiedzieć, ponieważ klient i serwer wykonują za nie wszystkie niezbędne operacje związane z ramkami.

Strumienie, wiadomości i ramki w HTTP/2

Wprowadzenie nowego mechanizmu ramek binarnych zmienia sposób wymiany danych między klientem a serwerem. Aby opisać ten proces, zapoznajmy się z nazwami dochodzącymi do naszego słownika wraz z HTTP/2.

• Strumień: dwukierunkowy przepływ bajtów w ramach ustanowionego połączenia, który może przenosić jeden lub więcej komunikatów.
• Komunikat: pełna sekwencja ramek, które są mapowane na logiczny komunikat żądania lub odpowiedzi.
• Ramka: najmniejsza jednostka komunikacji w HTTP/2, z których każda zawiera nagłówek ramki, który co najmniej identyfikuje strumień, do którego należy ramka.

Relację tych terminów można podsumować w następujący sposób:

• Cała komunikacja odbywa się za pośrednictwem jednego połączenia TCP, które może przenosić dowolną liczbę strumieni dwukierunkowych.
• Każdy strumień ma unikalny identyfikator i opcjonalną informację o priorytecie, która jest używana do przesyłania wiadomości dwukierunkowych.
• Każda wiadomość jest logiczną wiadomością HTTP, taką jak żądanie lub odpowiedź, która składa się z jednej lub więcej ramek.
• Ramka to najmniejsza jednostka komunikacji, która przenosi dane określonego typu — np. nagłówki HTTP, ładunek wiadomości itd. Ramki z różnych strumieni mogą być przeplatane, a następnie ponownie składane za pomocą identyfikatora strumienia osadzonego w nagłówku każdej ramki.

Krótko mówiąc, HTTP/2 dzieli komunikację protokołu HTTP na wymianę ramek zakodowanych binarnie, które są następnie mapowane na wiadomości należące do określonego strumienia, z których wszystkie są multipleksowane w ramach jednego połączenia TCP. Jest to podstawa, która umożliwia wszystkie inne funkcje i optymalizacje wydajności zapewniane przez protokół HTTP/2.

Multipleksowanie żądań i odpowiedzi

W przypadku protokołu HTTP/1.x, jeśli klient chce wykonywać wiele równoległych żądań w celu poprawy wydajności, musi użyć wielu połączeń TCP. To zachowanie jest bezpośrednią konsekwencją modelu HTTP/1.x, który zapewnia, że ​​tylko jedna odpowiedź może zostać dostarczona w na jedno połączenie. Co gorsza, powoduje to również blokowanie nagłówka linii i nieefektywne korzystanie z bazowego połączenia TCP.

Nowa warstwa ramek binarnych w HTTP/2 usuwa te ograniczenia i umożliwia pełne multipleksowanie żądań i odpowiedzi, umożliwiając klientowi i serwerowi podział wiadomości HTTP na niezależne ramki, przeplatanie ich, a następnie ponowne ich składanie na drugim końcu.

Priorytetyzacja strumienia w HTTP/2

Gdy wiadomość HTTP może zostać podzielona na wiele pojedynczych ramek i zezwolimy na multipleksowanie ramek z wielu strumieni ,to ułatwimy ich optymalizację. Kolejność, w której ramki są przeplatane i dostarczane zarówno przez klienta, jak i serwer, umożliwia to szeroko zakrojoną optymalizację i prioretyzację. Aby to ułatwić, standard HTTP/2 umożliwia każdemu strumieniowi powiązanie wagi i zależności:

• Każdemu strumieniowi można przypisać wagę całkowitą od 1 do 256.
• Każdemu strumieniowi można nadać jawną zależność od innego strumienia.

Połączenie zależności strumienia i wag umożliwia klientowi konstruowanie i przekazywanie „drzewa priorytetów”, które wyraża preferowany sposób otrzymywania odpowiedzi. Z kolei serwer może wykorzystać te informacje do nadania priorytetu przetwarzanego strumienia. Da to możliwość kontrolowania alokacji procesora, pamięci i innych zasobów. Gdy dane odpowiedzi są dostępne, alokacji przepustowości w celu zapewnienia optymalnego dostarczania odpowiedzi o wysokim priorytecie do klienta.

Zależność strumienia w ramach protokołu HTTP/2 jest deklarowana przez odwołanie się do unikalnego identyfikatora innego strumienia jako jego rodzica. Jeśli identyfikator zostanie pominięty, mówi się, że strumień jest zależny od „strumienia głównego”. Deklarowanie zależności strumienia wskazuje, że jeśli to możliwe, strumień nadrzędny powinien mieć przydzielone zasoby przed jego zależnościami. Innymi słowy, „Proszę przetworzyć i dostarczyć odpowiedź D przed odpowiedzią C”.

Jedno połączenie na początek

Dzięki nowemu mechanizmowi ramek binarnych protokół HTTP/2 nie potrzebuje już wielu połączeń TCP do równoległych strumieni multipleksowych. Każdy strumień jest podzielony na wiele ramek, które można przeplatać i ustalać priorytety. W rezultacie wszystkie połączenia HTTP/2 są trwałe i wymagane jest tylko jedno połączenie na źródło. To zapewnia liczne korzyści w zakresie wydajności.

Kontrola przepływu w HTTP/2

Kontrola przepływu to mechanizm zapobiegający przytłoczeniu odbiorcy danymi, których może nie chcieć lub nie być w stanie przetworzyć. Odbiorca może być zajęty, pod dużym obciążeniem lub może chcieć przydzielić ustaloną ilość zasobów dla konkretnego strumienia. Na przykład klient mógł zażądać dużego strumienia wideo o wysokim priorytecie. Użytkownik wstrzymał wideo, a klient chce teraz wstrzymać lub ograniczyć dostarczanie danych z serwera. Chce uniknąć pobierania i buforowania niepotrzebnych danych. Alternatywnie, serwer proxy może mieć szybkie połączenia downstream i wolne połączenia upstream . Dodatkowo chce regulować szybkość dostarczania danych w celu dopasowania do prędkości upstream.

Kompresja nagłówka

Kolejnym elementem wartym naszej uwagi jest kompresja nagłówków. Każdy transfer HTTP zawiera zestaw nagłówków opisujących przesyłany zasób i jego właściwości. W HTTP/1.x te metadane wysyła jako zwykły tekst i dodaje od 500 do 800 bajtów narzutu na transfer. Czasem osiągają one nawet rozmiary w kilobajtach, jeśli używane są pliki cookie HTTP. Aby zmniejszyć ten narzut i poprawić wydajność, protokół HTTP/2 kompresuje metadane nagłówka żądania i odpowiedzi przy użyciu formatu kompresji HPACK, który wykorzystuje dwie proste, ale wydajne techniki:

• Umożliwia kodowanie przesyłanych pól nagłówka za pomocą statycznego kodu Huffmana, co zmniejsza ich indywidualny rozmiar transferu.
• Wymaga, aby zarówno klient, jak i serwer utrzymywali i aktualizowali zindeksowaną listę wcześniej widzianych pól nagłówka, który jest następnie używany jako odniesienie do wydajnego kodowania wcześniej przesłanych wartości.

Kodowanie Huffmana umożliwia kompresję poszczególnych wartości podczas przesyłania. Zindeksowana lista przesłanych wartości umożliwia nam kodowanie duplikowanych wartości. Dzieje się tak dzięki przesyłaniu wartości indeksów, które można wykorzystać do wydajnego wyszukiwania i rekonstrukcji kluczy i wartości pełnego nagłówka.

Podsumowanie

Zastosowanie HTTP/2 umożliwiło optymalizację pracy serwerów. Dzięki temu dedykowane serwery dla WordPress mogą wygenerować oszczędności i przyspieszyć działanie naszych stron i aplikacji.

Artykuł uaktualniony 5 miesięcy