Co to jest protokół HTTP i jak działa? Wersje HTTP/1.1, HTTP/2 i HTTP/3

Protokół HTTP (Hypertext Transfer Protocol) to zbiór reguł komunikacyjnych pozwalających na przesyłanie dokumentów, takich jak strony HTML, pomiędzy przeglądarką użytkownika a serwerem docelowym. Działa on w oparciu o architekturę klient-serwer, gdzie przeglądarka wysyła żądanie pobrania zasobów, a maszyna hostująca odpowiada, dostarczając odpowiednie pakiety danych. Odpowiedź na pytanie, co to jest protokół HTTP i jak działa, sprowadza się do zrozumienia, że jest to absolutna podstawa wymiany informacji w internecie. Wersje HTTP/1.1, HTTP/2 i HTTP/3 różnią się od siebie sposobem pakowania danych, zarządzaniem połączeniami oraz radzeniem sobie z opóźnieniami sieciowymi.

Zrozumienie mechaniki sieci to nie jest wiedza tajemna, zarezerwowana dla administratorów systemów. Przeciętny użytkownik ładuje dziennie tysiące zasobów. Obrazki. Skrypty. Style CSS. Każdy z tych elementów wymaga osobnego zapytania. To generuje gigantyczny ruch. Kiedyś ten ruch zapychał łącza. Dzisiaj protokoły radzą sobie z tym znacznie sprawniej.

Co to jest protokół HTTP i do czego dokładnie służy w internecie?

Protokół HTTP to język, w którym dogadują się maszyny. Definiuje on format zapytań i odpowiedzi. Kiedy wpisujesz w pasku przeglądarki adres strony, twój komputer nie wie magicznie, jak ta strona wygląda. Musi o nią poprosić. Wysyła więc tekstowe żądanie. Serwer odbiera ten tekst, analizuje go i odsyła paczkę z danymi. Cała ta wymiana odbywa się w warstwie aplikacji modelu OSI.

Prawda jest zresztą absolutnie taka, że bez HTTP internet, jaki znamy, byłby zbiorem odizolowanych komputerów. Nie mielibyśmy hiperłączy. Nie mielibyśmy łatwego przechodzenia z jednego dokumentu do drugiego. Protokół ten określa metody operowania na danych. Najbardziej znane to GET i POST. Metoda GET po prostu prosi o odczytanie danych z serwera. Wpisujesz adres i pobierasz treść. Z kolei POST służy do wysyłania twoich danych na serwer. Robisz to za każdym razem, gdy logujesz się do banku albo wysyłasz formularz kontaktowy. To proste. Mechaniczne. Niezawodne.

Do poprawnego działania komunikacji potrzebne są tak zwane nagłówki. To metadane dołączane do każdego zapytania. Przeglądarka mówi serwerowi: „jestem Chrome na Windowsie, akceptuję język polski, a to są moje ciasteczka sesyjne”. Serwer czyta te nagłówki i wie, jak sformatować odpowiedź. Jeśli zażądasz pliku wideo, serwer ustawi nagłówek informujący o typie MIME wideo i wyśle strumień bitów.

Jak działa komunikacja klient-serwer w praktyce?

Architektura klient-serwer opiera się na ciągłym ping-pongu zapytań. Klient inicjuje akcję. Serwer pasywnie nasłuchuje na określonym porcie. Zazwyczaj jest to port 80 dla zwykłego połączenia i 443 dla połączenia szyfrowanego z użyciem certyfikatów SSL/TLS. Kiedy klient puka do tych drzwi, serwer otwiera połączenie. Rozpoczyna się proces wymiany danych.

Wymiana ta opiera się na żelaznych regułach. Żądanie musi zawierać metodę, ścieżkę do zasobu i wersję protokołu. Odpowiedź serwera zawsze zaczyna się od statusu. Dopiero potem lecą nagłówki, a na samym końcu puste pole i właściwe ciało odpowiedzi, czyli kod strony. To działa wyśmienicie. Pakiety danych wędrują przez dziesiątki routerów na całym świecie i w ułamku sekundy trafiają na twój ekran.

Dlaczego kody odpowiedzi HTTP mają takie znaczenie?

Kody odpowiedzi to system wczesnego ostrzegania w sieci. Trzycyfrowe liczby mówią przeglądarce, co poszło dobrze, a co totalnie się posypało. Kod 200 oznacza, że wszystko jest w porządku. Zasób został znaleziony i wysłany. Kody zaczynające się od trójki to przekierowania. Serwer informuje klienta, że plik zmienił adres i trzeba poszukać go gdzie indziej.

Problemy zaczynają się przy kodach błędów. Kody 4xx to wina klienta. Najsłynniejszy z nich, kod 404, oznacza, że wpisano zły adres albo plik fizycznie usunięto z dysku. Masz też błąd 403, gdy nie masz uprawnień do przeglądania danego katalogu. Z kolei kody 5xx to awarie po stronie infrastruktury. Kod 500 to wewnętrzny błąd serwera. Skrypt PHP mógł się zawiesić. Baza danych mogła odmówić posłuszeństwa. Widząc kod 500, wiesz, że po twojej stronie wszystko jest poprawnie, a to administratorzy maszyny docelowej mają problem do rozwiązania.

Jak działa HTTP/1.1 i dlaczego wciąż go używamy?

Wersja HTTP/1.1 została ustandaryzowana pod koniec lat 90. To niesamowite, że technologia z tamtego okresu nadal trzyma w ryzach ogromną część sieci. Wprowadziła ona mechanizm „keep-alive”. Wcześniej, przy wersji 1.0, każde pobranie pojedynczego obrazka wymagało zestawienia zupełnie nowego połączenia TCP. Kosztowało to mnóstwo czasu i zasobów sprzętowych procesora. HTTP/1.1 pozwoliło na utrzymanie otwartego połączenia po pobraniu pierwszego zasobu. Tym samym kablem można było przesłać kolejne pliki.

Mimo tych ulepszeń, protokół opiera się na czystym tekście. Zapytania i nagłówki nie są kompresowane. Jeśli wysyłasz duże ciasteczka, marnujesz cenną przepustowość na przesyłanie tych samych tekstowych ciągów znaków przy każdym odświeżeniu strony. Dodatkowo przeglądarki narzuciły twardy limit. Zazwyczaj mogły otworzyć maksymalnie sześć równoległych połączeń do jednej domeny. Jeśli strona miała sto obrazków, reszta musiała grzecznie czekać w kolejce.

Co to jest problem head-of-line blocking w HTTP/1.1?

To największa wada starszej architektury. Wyobraź sobie kasę w supermarkecie. Stoisz w kolejce z jedną butelką wody, ale przed tobą klient wyciąga setki drobnych monet, by zapłacić za pełen wózek zakupów. Kasjer jest zablokowany. Dokładnie to samo działo się w połączeniach TCP przy protokole HTTP/1.1. Przeglądarka wysyłała zapytanie o duży plik JavaScript, a następnie o mały plik CSS. Plik CSS nie mógł zostać odebrany, dopóki ciężki skrypt nie zablokował całej rury transmisyjnej.

Pamiętam doskonale wdrażanie dużego portalu informacyjnego na serwerach w małej serwerowni w poznańskich Jeżycach koło 2014 roku. Mieliśmy ogromne problemy z czasem ładowania. Testy pokazywały, że serwer odpowiada błyskawicznie, ale przeglądarka dławi się własną kolejką zapytań. Musieliśmy sztucznie obchodzić ten problem, stosując tak zwany domain sharding. Rozrzucaliśmy statyczne zasoby na cztery różne subdomeny, żeby oszukać limit sześciu połączeń narzucony przez przeglądarkę i wymusić asynchroniczne pobieranie. To była łatanina. Brzydki hack, który ratował wyniki, ale obciążał infrastrukturę DNS.

Czym różni się HTTP/2 od starszej wersji i jak przyspieszył sieć?

Wejście HTTP/2 to było mocne uderzenie w stół. Protokół ten oparł się na pracach inżynierów z Google nad projektem SPDY. Główna zmiana dotyczyła formatu danych. Wyrzucono przesyłanie zapytań czystym tekstem. Wprowadzono format binarny. Maszyny uwielbiają system binarny. Parsowanie zer i jedynek jest ułamkiem sekundy szybsze niż analizowanie tekstowych nagłówków. Dodano również mechanizm HPACK. Zajmuje się on kompresją nagłówków. Jeżeli wysyłasz to samo ciasteczko w dziesięciu zapytaniach, HTTP/2 przesyła je w całości tylko raz, a potem odwołuje się do niego za pomocą krótkiego indeksu.

Oprócz tego wprowadzono wymóg szyfrowania na poziomie przeglądarek. Choć sam standard technicznie pozwala na działanie bez certyfikatów, producenci Chrome i Firefoxa twardo zapowiedzieli, że HTTP/2 będzie obsługiwane tylko po bezpiecznym połączeniu TLS. To zmusiło masowo właścicieli stron do instalacji certyfikatów SSL, co mocno poprawiło bezpieczeństwo całego internetu.

Na czym polega multipleksowanie w HTTP/2?

To jest odpowiedź na problem kasjera w supermarkecie. Multipleksowanie pozwala na przesyłanie wielu żądań i odpowiedzi jednocześnie tym samym, pojedynczym kanałem TCP. Informacje są szatkowane na małe ramki danych. Ramka z obrazkiem przeplata się z ramką ze skryptem. Wszystko leci w jednym czasie.

Po stronie przeglądarki te binarne kawałki układanki są z powrotem składane w całe pliki. Nie ma już blokowania na poziomie warstwy HTTP. Mały plik CSS może zostać złożony i wyrenderowany, zanim ciężki obrazek w ogóle dotrze do połowy pobierania. Zużycie procesora na serwerach spadło. Zniknęła potrzeba stosowania domain shardingu. Po prostu podpinasz jeden adres, a serwer pompuje dane równolegle.

Jak server push miał zmienić reguły, a dlaczego ostatecznie upadł?

Inżynierowie wymyślili funkcję Server Push. Miała ona pozwalać serwerowi na wpychanie zasobów do pamięci podręcznej klienta, zanim ten o nie poprosi. Skoro przeglądarka prosi o plik index.html, to wiadomo, że za chwilę poprosi o plik style.css. Serwer mógł wysłać oba pliki od razu w jednej odpowiedzi.

Zrobiliśmy na wdrożeniu sklepu e-commerce test Server Push w środowisku produkcyjnym. Wyniki były tragiczne. Okazało się, że przeglądarka zazwyczaj miała już te pliki CSS w swoim lokalnym cache z poprzedniej wizyty. Serwer o tym nie wiedział i pchał pakiety na siłę, marnując przepustowość łącza i opóźniając wyświetlanie głównego dokumentu HTML. Zamiast przyspieszyć stronę, zepsuliśmy wskaźniki ładowania. Rynek szybko zorientował się w tej wadzie. Chrome ostatecznie usunął wsparcie dla HTTP/2 Server Push, uznając tę technologię za ślepą uliczkę. Przeglądarka po prostu wie lepiej, czego brakuje na dysku lokalnym.

Co to jest protokół HTTP/3 i dlaczego porzucono w nim TCP na rzecz QUIC?

Mimo sukcesu drugiej wersji, problem zablokowanych pakietów przeniósł się po prostu piętro niżej. Multipleksowanie rozwiązało blokowanie w warstwie HTTP, ale bazowało na protokole transportowym TCP. Protokół TCP ma wbudowany mechanizm gwarancji dostarczenia pakietu. Jeśli jeden mały pakiet danych zgubi się gdzieś na węźle w Niemczech, cały strumień TCP zostaje wstrzymany. System czeka na retransmisję zagubionego bitu. Wszystkie zmultipleksowane pliki stają w miejscu. To zjawisko niszczyło płynność ładowania stron na urządzeniach mobilnych, gdzie utrata zasięgu na ułamek sekundy jest normą.

Dlatego narodził się protokół HTTP/3. Całkowicie wyrzucono z niego TCP. Zastąpiono go nowym protokołem transportowym o nazwie QUIC (Quick UDP Internet Connections). QUIC opiera się na warstwie UDP. UDP z natury nie gwarantuje dostarczenia paczki. Jest szybki, ale rzuca dane w ciemno. Inżynierowie obudowali więc UDP własnymi mechanizmami kontroli błędów bezpośrednio w QUIC.

Zysk jest potężny. Jeśli zgubi się pakiet należący do obrazka A, obrazek B i skrypt C ładują się dalej bez żadnej przerwy. Nie ma pauzy na poziomie transportowym. Strony ładują się zauważalnie szybciej na gorszych łączach komórkowych.

Jak protokół QUIC oparty na UDP rozwiązuje problemy opóźnień?

Opóźnienia sieciowe (latency) to fizyczny czas potrzebny na przejście sygnału z punktu A do punktu B. W tradycyjnym TCP nawiązanie bezpiecznego połączenia wymagało kilku rund wymiany komunikatów. Klient wita się z serwerem. Serwer odpowiada. Potem klient wysyła klucze TLS. Serwer je potwierdza. Dopiero wtedy leci żądanie o stronę. To zajmuje cenne milisekundy.

QUIC łączy proces nawiązywania połączenia transportowego i negocjacji szyfrowania (TLS 1.3) w jeden krok. W optymalnym scenariuszu, jeśli klient odwiedzał już wcześniej dany serwer, może wysłać żądanie o dane od razu w pierwszym pakiecie (tzw. 0-RTT). Połączenie wstaje niemal natychmiastowo.

Podczas zeszłomiesięcznej migracji sklepu u klienta na serwerach w małym centrum danych na wrocławskich Krzykach, walczyliśmy z wdrożeniem QUIC przez bite dwa dni. Firewall sprzętowy uparcie wycinał ruch UDP na porcie 443, traktując go jako atak DDoS. Dokumentacja dostawcy twierdziła swoje, a logi serwera pokazywały zupełnie co innego. Dopiero ręczna rekonfiguracja tablic routingu i reguł zapory przepuściła pakiety. To pokazuje, że choć HTTP/3 daje świetne wyniki, infrastruktura sieciowa na świecie wciąż uczy się obsługi tego standardu i potrafi stawiać twardy opór podczas wdrożeń.

Porównanie wersji HTTP/1.1, HTTP/2 i HTTP/3 w praktyce

Aby szybko ocenić, jak ewoluowały mechanizmy i reguły przesyłania danych, przygotowaliśmy twarde zestawienie parametrów. Zwróć uwagę na zmianę warstwy transportowej i rosnące wymogi dotyczące szyfrowania w nowszych edycjach.

Wynika z tego jasno. Starsza wersja nadaje się do prostych zapytań z terminala albo wewnętrznych mikrousług. Nowsze standardy to absolutny mus dla publicznych portali, które walczą o ułamki sekund w wynikach pozycjonowania i dbają o odbiór użytkowników na smartfonach.

Jak sprawdzić, z której wersji HTTP korzysta moja strona internetowa?

Nie musisz instalować skomplikowanego oprogramowania, by prześwietlić własną domenę. Prawie połowa właścicieli witryn nawet nie wie, że ich hosting domyślnie uruchomił już nowsze protokoły. Wystarczy do tego przeglądarka internetowa, na przykład Chrome lub Edge.

• Otwórz swoją stronę internetową, wciśnij klawisz F12 i przejdź do zakładki „Network” (Sieć).
• Odśwież stronę. Zobaczysz kaskadę ładujących się plików.
• Kliknij prawym przyciskiem myszy na nagłówki kolumn nad listą plików (tam, gdzie jest Nazwa, Status, Typ) i zaznacz opcję „Protocol” (Protokół).
• Pojawi się nowa kolumna. Jeśli zobaczysz w niej wartości „h2”, oznacza to HTTP/2. Jeśli widnieje tam „h3”, serwer pomyślnie używa QUIC. Z kolei „http/1.1” oznacza, że korzystasz z przestarzałej technologii i tracisz na czasie ładowania.

Warto też używać narzędzi zewnętrznych typu cURL w konsoli, wpisując proste polecenie z flagą pokazującą nagłówki. Zwróci to czarno na białym informację o wynegocjowanym połączeniu. Zmiana protokołu zazwyczaj wymaga jednego kliknięcia w panelu Cloudflare lub edycji kilku linijek w konfiguracji Nginx. Nie ma wymówek, by tego nie zrobić.

Skoro wiesz już, co to jest protokół HTTP i jak działa na przestrzeni swoich kolejnych wersji, sprawdź teraz logi własnego serwera. Zaloguj się do panelu i zweryfikuj, czy twoja infrastruktura nie utknęła w latach dziewięćdziesiątych, wymuszając na klientach sekwencyjne pobieranie każdego megabajta danych.

FAQ – Często zadawane pytania o protokoły sieciowe

• Co to jest protokół HTTP w prostych słowach?
  To zbiór reguł pozwalający przeglądarce internetowej poprosić serwer o stronę www i ją pobrać. Bez niego nie moglibyśmy przeglądać internetu w formie graficznych dokumentów i linków.
• Czy HTTP i HTTPS to to samo?
  Nie. HTTPS to bezpieczna wersja protokołu HTTP. Wykorzystuje szyfrowanie TLS, dzięki czemu nikt nie może podsłuchać przesyłanych danych, na przykład haseł czy numerów kart kredytowych.
• Czy HTTP/3 jest lepsze od HTTP/2?
  Tak. HTTP/3 naprawia problem blokowania pakietów na poziomie transportowym, używając UDP zamiast TCP. Działa znacznie szybciej na słabych połączeniach komórkowych.
• Jak naprawić błąd HTTP 404?
  Błąd 404 oznacza, że strona nie istnieje. Jako użytkownik możesz sprawdzić poprawność wpisanego adresu URL. Jako administrator musisz ustawić odpowiednie przekierowanie 301 na nowy adres podstrony.
• Czy mogę wymusić użycie HTTP/3 na moim serwerze?
  Musisz zainstalować i skonfigurować serwer WWW (np. Nginx w nowej wersji lub LiteSpeed) obsługujący protokół QUIC, a także otworzyć port 443 dla ruchu UDP w zaporze sieciowej (firewall).
• Dlaczego API nadal często używają HTTP/1.1?
  Wiele wewnętrznych systemów komunikuje się poprzez małe, pojedyncze zapytania w bezpiecznych sieciach LAN. W takich warunkach narzut sprzętowy na szyfrowanie i multipleksowanie w nowszych wersjach jest zbędny.

Bibliografia

1. Internet Engineering Task Force (IETF) – https://ietf.org
2. Mozilla Developer Network (MDN Web Docs) – https://developer.mozilla.org
3. World Wide Web Consortium (W3C) – https://www.w3.org
4. NGINX – https://nginx.org
5. Cloudflare – https://www.cloudflare.com