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

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

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

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

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ś oznaczonegonumerkiem 2.0 powinniśmy oczekiwać znaczących zmian, ulepszeńusuwających znane bolączki Sieci. Tymczasem nic takiego nie mamiejsca. Czemu więc tak to się wszystko potoczyło? Deweloper FreeBSDuważa, że to ze strachu. IETF obawiało się, że już wkrótce przestaniemieć jakiekolwiek znaczenie, więc wzięło się nagle za„aktualizowanie” HTTP/1.1 w kompletnie nierealistycznymczasie. Teraz już może odtrąbić sukces i pogratulować sobie, jakważną dla Sieci pracę wykonuje, mimo że to co powstało, jest poprostu mierne.

Czego tak naprawdę można było oczekiwać od drugiej wersjiprotokołu HTTP? A to już zależy od tego, kto oczekiwał, alegeneralnie 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/2wygląda kiepsko, jest niespójne, niepotrzebnie złożone, pełne złychkompromisów, naruszeń separacji warstw i niezrealizowanych okazji.*Oblałbym studentów na moich (hipotetycznych) zajeciach zprojektowania 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 wszystkimze stron działającego na skalę globalną dostawcy treści, wtedy jegostrony faktycznie mogą ładować się szybciej. O ile szybciej? Rok temubadacze z Wielkiej Brytanii i Norwegii opublikowalipracę poświęconą wydajności google'owego SPDY. Wynika z niej, żewcale tak różowo nie jest, w najlepszym razie uzyskano przyspieszeniana poziomie 7-10%, w najgorszym okazywało się, że SPDY działa wolniejnie tylko od HTTP, ale też od HTTPS. Nie ma powodów by sądzić, żebazujący na SPDY protokół HTTP/2 będzie pod tym względem lepszy.

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

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

To obowiązkowe szyfrowaniekorporacyjnym sponsorom wcale bowiem nie przeszkadza, a prowadzijedynie do sporych kłopotów dla innych. Programista zauważa, że wwielu wypadkach szyfrowanie nie jest potrzebne (np. dostawcommultimediów), a może tylko utrudnić komunikację, szczególnie wsytuacjach 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. Niewiadomo, jak nowa wersja protokołu miałaby rozwiązać te problemy.

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