Jan T. Grusznic

HTTP/2 sprawi, że aplikacje webowe będą szybsze, prostsze i wydajniejsze – to rzadka kombinacja, która pozwoli również cofnąć wiele wcześniej wykonanych obejść ograniczeń protokołu HTTP/1.1 i rozwiązać problemy w samej warstwie transportowej. Co więcej, nowa wersja protokołu hipertekstowego otwiera również szereg zupełnie nowych możliwości optymalizacji aplikacji i poprawy wydajności, także w przypadku rozwiązań dla rynku security!

Protokół HTTP został pierwotnie zaproponowany przez Tima Bernersa-Lee, pioniera sieci World Wide Web, który zaprojektował protokół aplikacji z myślą o prostocie wykonywania funkcji przesyłania danych wysokiego poziomu między serwerami WWW a klientami. Pierwsza udokumentowana wersja HTTP została wydana w 1991 r. jako HTTP0.9, co później doprowadziło do oficjalnego wprowadzenia i uznania HTTP1.0 w 1996 r. HTTP1.1 pojawił się w 1997 r. i od tego czasu otrzymał niewiele iteracyjnych ulepszeń. Duża popularność i fakt, że protokół HTTP od lat 90. nie był modernizowany, nie wynika z jego wyjątkowych czy złożonych mechanizmów, ale właśnie z jego uniwersalności i prostoty działania – np. z bezstanowości¹.

Jednak obecna budowa stron internetowych i aplikacji webowych w erze dynamicznie aktualizowanych informacji, formatów treści multimedialnych wymagających dużej ilości zasobów i nadmiernie obciążających sieć zmusiła Internet Engineering Task Force (IETF) HTTP Working Group do wykonania przeglądu protokołu HTTP. Jako punkt wyjścia do zmian wykorzystano trwające już wtedy prace [2] firmy Google nad SPDY⁴, co w efekcie skutkowało standaryzacją HTTP/2 [3] w maju 2015 r. Szybkie wdrożenie było możliwe dzięki zachowaniu współdziałania i zgodności z protokołem http/1.1, HTTP/2 rozszerza bowiem poprzednie standardy HTTP, a nie zastępuje ich [4].

Czym jest protokół

Padło już wielokrotnie pojęcie protokołu, który stanowi zestaw reguł zarządzających mechanizmami przesyłania danych między klientami (np. przeglądarkami internetowymi żądającymi informacji) a serwerami (maszynami zawierającymi informacje).
Protokoły zwykle składają się z trzech głównych części: nagłówka, ładunku i stopki. Nagłówek umieszczony przed ładunkiem zawiera informacje, takie jak adresy źródłowe i docelowe, a także inne szczegóły (np. rozmiar i typ) dotyczące ładunku. Ładunek to rzeczywiste informacje przesyłane za pomocą protokołu. Stopka podąża za ładunkiem i działa jako pole kontrolne do kierowania żądań klient-serwer do zamierzonych odbiorców wraz z nagłówkiem, by zapewnić, że dane ładunku są przesyłane bez błędów [5].
Protokół HTTP pierwotnie składał się z podstawowych poleceń: GET do pobierania informacji z serwera i POST w celu dostarczania żądanych informacji do klienta. Ten prosty i pozornie nudny zestaw poleceń GET i POST stanowił podstawę do konstruowania również innych protokołów sieciowych.

Nowa wersji protokołu HTTP koncentruje się wokół cech trzech rzadko kojarzonych z pojedynczym protokołem sieciowym – prostym, wysokiej wydajności i niezawodności, bez konieczności stosowania dodatkowych technologii sieciowych. Cele te osiągnięto dzięki wprowadzeniu możliwości zmniejszających opóźnienia w przetwarzaniu żądań przeglądarki za pomocą takich technik, jak multipleksowanie (multiplexing), wypychanie serwera (server push), kompresja (compression) i binarny format przesyłu nagłówków (binary headers). W efekcie system pozwala serwerom efektywnie reagować przy większej ilości treści, niż pierwotnie żądali klienci, eliminując interwencje użytkownika w ciągłe żądanie informacji, aż do pełnego załadowania strony internetowej w przeglądarce internetowej.

Co jest nie tak z HTTP/1.1

Protokół HTTP1.1 ogranicza się do przetwarzania tylko jednego oczekującego żądania na połączenie TCP, zmuszając przeglądarki do używania wielu połączeń TCP do jednoczesnego przetwarzania wielu żądań. Wykorzystywanie równolegle zbyt wielu połączeń TCP prowadzi do przeciążenia TCP, co monopolizuje zasoby sieciowe (ze względu na limity jednoczesnych połączeń TCP dla maszyn) [6]. Przeglądarki internetowe wykorzystujące wiele połączeń do przetwarzania dodatkowych żądań mają większy udział w dostępnych zasobach sieciowych, co powoduje obniżenie wydajności sieci dla innych programów.

Deweloperzy w celu rozwoju aplikacji webowych byli poniekąd zmuszeni do łamania tych ograniczeń za pomocą praktyk, takich jak dzielenie domen (domain sharding)⁵, konkatenacja⁶, wstawianie danych (data inlining)⁷, spriting⁸ i inne [7]. Takie nieefektywne wykorzystanie podstawowych połączeń TCP z HTTP/1.1 prowadzi również do słabego ustalania priorytetów zasobów, powodując wykładnicze obniżenie wydajności w miarę wzrostu złożoności, funkcjonalności i zakresu aplikacji internetowych. A taka jest sytuacja w przypadku aplikacji web dla elektronicznych systemów zabezpieczeń.
Powyższe problemy wyjaśniają, dlaczego część producentów systemów w naszej branży kurczowo trzyma się cały czas dodatków Active-X⁹, chociaż te z końcem sierpnia 2020 r. pozostaną bez wsparcia [8]. Uruchomienie jednej aplikacji web, która zapewnia dwukierunkową wymianę informacji między serwerem (rejestratorem, kamerą, serwerem VMS, PSIM itp. lub każdym innym urządzeniem aktualizującym dane w czasie rzeczywistym) jest na pewno prostsze. Ale czy bezpieczne? [9]

HTTP/2

W standardowym modelu HTTP serwer nie może inicjować połączenia z klientem ani wysyłać do niego odpowiedzi HTTP bez zapytania; zatem serwer nie może wysyłać asynchronicznych zdarzeń do klientów. Dlatego, aby otrzymywać zdarzenia asynchroniczne, gdy tylko to możliwe, klient musi okresowo odpytywać serwer o nowe dane. Takie ciągłe odpytywanie obciąża i łącze, i serwer, zwłaszcza jeśli nie ma żadnych nowych danych do pobrania. Jest też nieefektywne, ponieważ ogranicza szybkość reakcji aplikacji oczekującej na dane z serwera, które otrzyma przy kolejnym okresowym zapytaniu wysłanym do serwera [10].

HTTP/2 zmniejsza opóźnienia, wprowadzając multipleksowanie – czyli możliwość równoległego pobierania wielu zasobów za pomocą jednego połączenia TCP. W protokole HTTP/1.1 wysyłanie wielu równoległych żądań wymaga nawiązania wielu połączeń TCP, co jest bezpośrednią konsekwencją modelu dostarczania HTTP/1.1, który zapewnia jedną odpowiedź na jedno połączenie – to tzw. kolejkowanie odpowiedzi. Skutkuje to również blokowaniem na początku linii i nieefektywnym wykorzystaniem bazowego połączenia TCP [11].

HTTP/2 usuwa te ograniczenia i umożliwia pełne multipleksowanie żądań i odpowiedzi, pozwalając klientowi i serwerowi na rozbicie wiadomości HTTP na niezależne ramki, przeplatanie ich, a następnie ponowne złożenie z drugiej strony. Jest to obok tzw. server push bodaj najważniejsze ulepszenie wprowadzane przez nową wersję HTTP. Zapewnia to masę korzyści wydajnościowych na całym „stosie” wszystkich technologii sieciowych, co w efekcie zapewnia niższe czasy ładowania stron, eliminując opóźnienia.

Server push, o którym wspomniałem, umożliwia serwerowi wysyłanie dodatkowych informacji, które można zapisać w pamięci podręcznej przeglądarki do klienta, a które nie są wymagane, ale przewidywane w przyszłych żądaniach. Załóżmy, że mamy stronę www index.html z trzema zasobami: styles.css, scripts.js i image.png. W HTTP/1.1, gdy użytkownik łączy się z danym adresem www, przeglądarka automatycznie pobiera plik index.html. Analizując kod HTML, znajduje odwołania do kolejnych zasobów:
styles.css, scripts.js, obrazka image.png i wysyła kolejne żądania, jedno po drugim, co znacznie opóźnia wczytywanie się strony w przeglądarce.

Server push pomaga serwerowi „przejąć inicjatywę” dzięki regułom, które wysyłają do przeglądarki treści, zanim przeglądarka o nie zapyta. W przykładowym scenariuszu serwer „wie”, że każdy klient, który zażąda pliku index.html, będzie potrzebował jeszcze
styles.css, scripts.js i image.png – może zatem natychmiast przekazać je klientowi, nie czekając na żądanie od niego. Zanim przeglądarka zakończy wczytywanie pliku index.html, transfer wspomnianych plików styles.css, scripts.js i obrazka image.png będzie już w toku, a może nawet się zakończy, eliminując opóźnienie, które towarzyszy sposobowi działania stron internetowych od HTTP/0.9 [12].

Strony konfiguracyjne kamer IP, rejestratorów, serwerów VMS, NVR, systemów PSIM, KD, central SSWiN, SSP i wielu, wielu innych zawierają mnóstwo treści, grafik i obiektów multimedialnych. Protokół aplikacji HTTP jest bezstanowy, co oznacza, że każde żądanie klienta musi zawierać tyle informacji, ile serwer potrzebuje do wykonania żądanej operacji. Mechanizm ten sprawia, że strumienie danych przenoszą wiele powtarzających się ramek informacji, aby nie wymagać od serwera przechowywania informacji z poprzednich żądań klientów.

W przypadku witryn udostępniających treści multimedialne klienci przesyłają wiele prawie identycznych ramek nagłówka, co prowadzi do opóźnień i niepotrzebnego zużycia ograniczonych zasobów sieciowych. Implementacja HTTP/2 rozwiązuje te problemy dzięki możliwości kompresji dużej liczby nadmiarowych ramek nagłówka. Używa specyfikacji HPACK¹⁰ jako prostego i bezpiecznego podejścia do jego kompresji. Zarówno klient, jak i serwer utrzymują listę nagłówków stosowanych w poprzednich żądaniach klient-serwer, co przekłada się na efektywne ustalanie priorytetów strumieni danych i wykorzystanie mechanizmów multipleksowania.

Fundamentem wszystkich tych ulepszeń (mających wpływ na wydajność komunikacji w ramach protokołu HTTP/2) jest nowa binarna warstwa ramkowania, która określa sposób enkapsulacji i przesyłania wiadomości HTTP między klientem a serwerem. W przeciwieństwie do protokołu HTTP/1.1, który do komunikacji używa formatu tekstowego, cała komunikacja HTTP/2 jest podzielona 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ą korzystać z nowego mechanizmu kodowania binarnego, aby się zrozumieć. Przeglądarki korzystające z implementacji HTTP/2 konwertują te same polecenia tekstowe na binarne przed przesłaniem ich przez sieć.

HTTP/2 a elektroniczne systemy zabezpieczeń

Powyższe zalety wynikające z wdrożenia HTTP/2 mogą stanowić wyzwanie dla administratorów sieciowych systemów zabezpieczeń. Binarna warstwa ramek nie jest bowiem wstecznie kompatybilna z klientami i serwerami HTTP/1.0 i HTTP/1.1. Oznacza to, że stosowane zapory ogniowe w sieciach, w których pracują urządzenia elektronicznych systemów zabezpieczeń wspierające protokół HTTP/2, mogą blokować lub spowalniać ruch między urządzeniem (serwerem) a przeglądarką (klientem). Żeby temu zapobiec, konieczne jest przełożenie formatu binarnego na tekstowy (tzw. parser), by firewalle czy systemy antywirusowe działały poprawnie. Bez takiego przełożenia analiza sygnatur antywirusowych lub aplikacji najprawdopodobniej nie wykryje zbyt wiele. Potwierdzają to wpisy choćby na stronach Kasperskiego – jego wybrane aplikacje nie przetwarzają ruchu HTTP/2 dla formatu binarnego [13].

Zalety HTTP/2

Uwagi końcowe

Współczesne przeglądarki oferują ogromne możliwości. Rynek tzw. mobilnych aplikacji przeglądarkowych rozwija się dynamicznie. Możliwe jest, że wkrótce użytkownicy systemów bezpieczeństwa będą korzystać wyłącznie z aplikacji dostępnych przez przeglądarkę lub z poziomu aplikacji mobilnych i powoli zapomną, jak wyglądają klasyczne aplikacje desktopowe lub jak się je instaluje [14]. Protokół HTTP/2 ma się do tego przyczynić, już dziś rozwiązując bolączki poprzednich wersji protokołu. Świat nie stoi w miejscu – trwają już prace nad trzecią wersją protokołu http [15], która zapewni jeszcze większe możliwości aplikacji opartych na rozwiązaniach webowych.

Literatura

[1] https://w3techs.com/technologies/details/ce-http2
[2] Introduction to HTTP/2, Ilya Grigorik, Surma, https://developers.google.com/web/fundamentals/performance/http2
[3] Hypertext Transfer Protocol Version 2 (HTTP/2), https://tools.ietf.org/html/rfc7540
[4] HHTP 2.0, Why now?, What is it? Ilya Grigorik, https://www.slideshare.net/heavybit/heavybit-presents-ilya-grigorik-on
[5] What is HTTP/2 – The Ultimate Guide, 2019-12-05, https://kinsta.com/learn/what-is-http2/
[6] https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc758980(v=ws.10)
[7] Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP, Internet Engineering Task Force (IETF), https://tools.ietf.org/html/rfc6202
[8] End of Life – Internet Explorer and ActiveX Support, https://support.netdocuments.com/hc/en-us/articles/360025874251-End-of-Life-Internet-Explorer-and-ActiveX-Support19)
[9] https://support.microsoft.com/en-us/help/17469/windows-internet-explorer-use-activex-controls
[10] Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP, Internet Engineering Task Force (IETF), https://tools.ietf.org/html/rfc6202
[11] Hypertext Transfer Protocol — HTTP/1.1, https://tools.ietf.org/html/rfc2616
[12] HTTP/2 czy warto włączyć, jak zainstalować? https://mansfeld.pl/webdesign/http2-zalety-czy-warto-zainstalowac/
[13] https://forum.mikrotik.com/viewtopic.php?t=142326
[14] Integracja systemów bezpieczeństwa przyszłością branży security, https://aspolska.pl/integracja-systemow-bezpieczenstwa-przyszloscia-branzy-security/
[15] Hypertext Transfer Protocol Version 3 (HTTP/3) draft-ietf-quic-http-23, https://tools.ietf.org/html/draft-ietf-quic-http-23

Jan T. Grusznic Z-ca red. naczelnego „a&s Polska”. Z branżą wizyjnych systemów zabezpieczeń związany od 2004 r. Ma bogate doświadczenie w zakresie projektowania i wdrażania rozwiązań dozoru wizyjnego w aplikacjach o rozproszonej strukturze i skomplikowanej dystrybucji sygnałów. Ceniony diagnosta zintegrowanych systemów wspomagających bezpieczeństwo.

1) Oznacza to, że serwer WWW rozpatruje każde żądanie niezależnie od innych, nie szukając żadnych powiązań.
2) W protokole stanowym (ang. stateful) informacje zawarte w jednym żądaniu wysłanym od nadawcy do adresata mogą posłużyć do modyfikacji kolejnych żądań, w odróżnieniu od bezstanowej natury protokołu HTTP (informacje w konkretnym żądaniu nie mogą być wiązane z innymi, więc nie można ich dalej stosować).
3) O sieci 5G pisaliśmy w numerze 3/2020 https://aspolska.pl/5g-ultraszybka-infostrada-szerokopasmowa/.
4) SPDY jest bazowanym na TCP protokołem warstwy aplikacji do transmisji treści Web. Został zaproponowany przez Google i był rozwijany jako jeden z projektów Chromium. Prace nad nim zostały zaniechane po wprowadzenie HTTP/2 jako standardu.
5) Domyślnie przeglądarki internetowe ograniczają liczbę aktywnych połączeń dla każdej domeny. Gdy liczba zasobów do pobrania przekracza ten limit, użytkownicy wolniej ładują się strony, ponieważ pobrania są umieszczane w kolejce. Aby obejść to ograniczenie, programiści dzielili zawartość na wiele subdomen. Ponieważ przeglądarki resetują limit połączeń dla każdej domeny, każda dodatkowa domena zezwala na dodatkową liczbę aktywnych połączeń. Pozwala to użytkownikowi na pobieranie plików z tego samego źródła z większą przepustowością.
6) W programowaniu oznacza łączenie dwóch wyrażeń (np. tekstowych) w jedno (ustawienie jednego za drugim), np. to+jest+tekst+powiązany.
7) Wprowadzanie danych w tekście (na ogół w zapytaniach GET).
8) Technika przechowywania wielu obrazów w jednym większym obrazie, dzięki czemu szybciej ładują się one na stronie internetowej.
9) Formanty ActiveX to małe aplikacje, które umożliwiają witrynom internetowym udostępnianie treści, takich jak np. obrazu wideo. Umożliwiają także interakcję z zawartością, taką jak paski narzędzi i wskaźniki, podczas przeglądania. Jednak te aplikacje mogą czasami działać nieprawidłowo lub dostarczać treści, których nie chcesz. W niektórych przypadkach te aplikacje mogą zbierać dane z twojego komputera, niszczyć zapisane dane w twoim komputerze, instalować obce oprogramowanie na komputerze bez twojej zgody lub zezwolić komuś innemu zdalnie sterować twoim komputerem.
10) HPACK nowy kompresor nagłówka, który eliminuje zbędne pola nagłówka, ogranicza podatność na znane ataki bezpieczeństwa i posiada ograniczone wymagania dotyczące pamięci w ograniczonych środowiskach.