r   e   k   l   a   m   a
r   e   k   l   a   m   a

HTTP/2 to triumf polityki, a nie techniki. Google może się cieszyć, użytkownicy niekoniecznie

Strona główna AktualnościINTERNET

Z godnym lepszej sprawy entuzjazmem popularne media IT doniosły w tym tygodniu o ukończeniu prac nad standardem Hypertext Transfer Protocol 2 (HTTP/2). Zastąpić on ma stosowany od ponad 16 lat standard HTTP w wersji 1.1, przynosząc użytkownikom przede wszystkim przyspieszenie komunikacji między serwerem a przeglądarką. Czy jednak faktycznie jest się z czego cieszyć? Programista Poul-Henning Kamp, znany głównie ze swoich prac nad FreeBSD i akceleratorem HTTP Varnish, przedstawia zupełnie inny obraz sytuacji, niż ten lansowany przez członków Internet Engineering Task Force (IETF) i przepisujące ich media.

Na początku wyjaśnijmy, czym HTTP/2 nie jest. Nie jest to żaden nowy protokół hipertekstowej komunikacji. Wszystkie dotychczas stosowane metody, kody i cała semantyka pozostają bez zmian. To oczywiście jest dobra wiadomość, gdyż zmiany w tej warstwie przyniosłyby tylko kłopoty całej Sieci, starsze aplikacje przestałyby działać.

Nowa wersja standardu skupia się na zmniejszeniu opóźnień w komunikacji, umożliwieniu przesyłania wielu zasobów jednocześnie bez otwierania wielu połączeń między serwerem a przeglądarką (multipleksing), dodaniu obsługi mechanizmu push dla serwera oraz umożliwieniu kompresji nagłówków. Jest to w zasadzie to samo, z czym mieliśmy do czynienia w protokole SPDY Google'a. Nic w tym dziwnego, podstawą do prac nad HTTP/2 był właśnie SPDY, protokół opracowany głównie po to, by przyspieszyć działanie aplikacji webowych w Chrome. Google wówczas publicznie oświadczyło, że celem jest uczynienie z własnościowego rozwiązania uniwersalnego standardu dla wszystkich – i IETF zgodziło się z tym, przyjmując SPDY za podstawę dalszych prac nad nową wersją standardu hipertekstowego protokołu. Różnic nie ma wiele, jedyną znaczącą jest to, że HTTP/2 umożliwia multipleksing z różnych hostów jednocześnie, podczas gdy SPDY obsługuje w ten sposób zasoby tylko z jednego hosta.

r   e   k   l   a   m   a

Jeszcze przed oficjalnym zakończeniem prac przez IETF, Poul-Henning Kamp opublikował surową krytykę tych wszystkich działań, sugerując, że prawdziwą przyczyną jego wprowadzenia jest polityka. Od czegoś oznaczonego numerkiem 2.0 powinniśmy oczekiwać znaczących zmian, ulepszeń usuwających znane bolączki Sieci. Tymczasem nic takiego nie ma miejsca. Czemu więc tak to się wszystko potoczyło? Deweloper FreeBSD uważa, że to ze strachu. IETF obawiało się, że już wkrótce przestanie mieć jakiekolwiek znaczenie, więc wzięło się nagle za „aktualizowanie” HTTP/1.1 w kompletnie nierealistycznym czasie. Teraz już może odtrąbić sukces i pogratulować sobie, jak ważną dla Sieci pracę wykonuje, mimo że to co powstało, jest po prostu mierne.

Czego tak naprawdę można było oczekiwać od drugiej wersji protokołu HTTP? A to już zależy od tego, kto oczekiwał, ale generalnie można powiedzieć, że spodziewano się lepszej architektury, większej ochrony prywatności, przyspieszenia i może także „zieloności”, czyli mniejszego obciążenia sprzętu, prowadzącego do mniejszego zużycia energii. Co z tego zrealizowano? Ano praktycznie nic. Kamp twierdzi, że od strony architektury, HTTP/2 wygląda kiepsko, jest niespójne, niepotrzebnie złożone, pełne złych kompromisów, naruszeń separacji warstw i niezrealizowanych okazji. Oblałbym studentów na moich (hipotetycznych) zajeciach z projektowania protokołów, gdyby mi coś takiego pokazali – mówi deweloper.

W tę większą szybkość HTTP/2 też nie ma co wierzyć. To znaczy można, jeśli korzystamy przede wszystkim ze stron działającego na skalę globalną dostawcy treści, wtedy jego strony faktycznie mogą ładować się szybciej. O ile szybciej? Rok temu badacze z Wielkiej Brytanii i Norwegii opublikowali pracę poświęconą wydajności google'owego SPDY. Wynika z niej, że wcale tak różowo nie jest, w najlepszym razie uzyskano przyspieszenia na poziomie 7-10%, w najgorszym okazywało się, że SPDY działa wolniej nie tylko od HTTP, ale też od HTTPS. Nie ma powodów by sądzić, że bazujący na SPDY protokół HTTP/2 będzie pod tym względem lepszy.

Co więcej, uczestniczące w transferze danych maszyny będą znacznie bardziej obciążone, szczególnie przy dużych zbiorach danych. Za tym idzie oczywiście kwestia zużycia energii. Wymagający znacznie większej mocy obliczeniowej HTTP/2 prowadzić ma do większego zanieczyszczenia środowiska. IETF nad tą kwestią najwyraźniej się nigdy nie zastanowiło.

A co z prywatnością? Tu jest pies pogrzebany. Samo obowiązkowe szyfrowanie komunikacji po HTTP/2 za pomocą SSL/TLS nie daje nic ponad to, co daje zastosowanie SSL/TLS w HTTP/1.1. W szczególności nie zlikwidowano nawet tych okropnych ciasteczek, zastępując je np. kontrolowanym przez klienta identyfikatorem sesji, tak by użytkownik mógł samodzielnie kontrolować to, czy chce być śledzony, czy nie – i jego decyzja w tej sprawie byłaby tu finalna. Kamp uważa, że to kwestia zadbania o interesy (niewymienionych z nazwy) korporacyjnych sponsorów, którzy cały swój biznes zbudowali na bazie pogwałcenia prywatności użytkowników. Nie podoba im się oczywiście, że NSA szpieguje cały świat, ale nie chcą zarazem, by cokolwiek uniemożliwiło im robienie tego samego.

To obowiązkowe szyfrowanie korporacyjnym sponsorom wcale bowiem nie przeszkadza, a prowadzi jedynie do sporych kłopotów dla innych. Programista zauważa, że w wielu wypadkach szyfrowanie nie jest potrzebne (np. dostawcom multimediów), a może tylko utrudnić komunikację, szczególnie w sytuacjach krytycznych, np. klęskach żywiołowych. Co więcej, są sytuacje, w których szyfrowana komunikacja jest nielegalna – niektórzy ludzie, np. więźniowie, nie mają prawa do prywatności. Nie wiadomo, jak nowa wersja protokołu miałaby rozwiązać te problemy.

Jeśli zatem faktycznie jest tak nieciekawie, to czego należy się spodziewać w przyszłości? Być może niczego nowego. Samo wydanie dokumentu RFC nie sprawi, że w ciągu jednej nocy wszyscy wymienią swoje serwery WWW. HTTP/2 może podzielić los IPv6, wdrażanego od tylu już lat, że powinno być wszędzie, a jednak wciąż odpowiedzialnego za w najlepszym razie kilka procent ruchu sieciowego.

© dobreprogramy
r   e   k   l   a   m   a
r   e   k   l   a   m   a

Komentarze

r   e   k   l   a   m   a
r   e   k   l   a   m   a
Czy wiesz, że używamy cookies (ciasteczek)? Dowiedz się więcej o celu ich używania i zmianach ustawień.
Korzystając ze strony i asystenta pobierania wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.