Protokół Transferu Hipertekstu (HTTP)

Protokół World Wide Web do żądania i serwowania stron internetowych.

Wprowadzenie do HTTP: Język Sieci Web

Wyobraź sobie, że jesteś w bibliotece. Podchodzisz do lady bibliotecznej (serwer) i składasz prośbę o konkretną książkę (zasób, taki jak strona internetowa). Ty, osoba składająca prośbę, jesteś klientem. Zestaw zasad, których używasz do poproszenia o książkę i które pozwalają bibliotekarzowi odpowiedzieć, to protokół. W internecie tym fundamentalnym protokołem jest , czyli Protokół Transferu Hipertekstu. Jest to fundament komunikacji danych w World Wide Web, umożliwiający przeglądarkom pobieranie dokumentów z serwerów.

W swej istocie HTTP to protokół typu żądanie-odpowiedź, który działa w oparciu o . Klient, zazwyczaj Twoja przeglądarka internetowa, inicjuje komunikację, wysyłając komunikat żądania do serwera. Serwer, potężny komputer hostujący pliki strony internetowej, przetwarza to żądanie i odsyła komunikat odpowiedzi. Ta odpowiedź może zawierać żądany dokument HTML, obraz lub po prostu informację o statusie żądania. Za każdym razem, gdy klikasz link, wpisujesz adres internetowy lub oglądasz obraz online, w tle odbywa się ta cicha, błyskawiczna rozmowa.

Analiza Adresu Internetowego: Uniform Resource Locator (URL)

Zanim klient będzie mógł złożyć żądanie, musi znać dokładny adres zasobu, którego potrzebuje. Ten adres jest znany jako (Uniform Resource Locator). URL to specyficzny typ URI (Uniform Resource Identifier), który nie tylko nazywa zasób, ale również określa, jak go zlokalizować. Przyjrzyjmy się budowie typowego adresu URL na podstawie przykładu z Twoich notatek: http://www.cisco.com/web-server.htm.

Schemat (Protokół): http:
To pierwsza część adresu URL, kończąca się dwukropkiem. Informuje przeglądarkę, jakiego protokołu należy użyć do komunikacji. W tym przypadku jest to $http$ . Innym bardzo popularnym schematem jest $https$ , który wskazuje na bezpieczne połączenie. Po schemacie następują dwukropek i dwa ukośniki (://).
Host (Nazwa serwera): www.cisco.com
Ten komponent identyfikuje serwer, na którym znajduje się zasób. Jest to przyjazna dla użytkownika nazwa domenowa, która odpowiada numerycznemu serwera (np. $198.133.219.25$ ). Twój komputer używa systemu zwanego (Domain Name System), aby przetłumaczyć tę czytelną dla człowieka nazwę na adres IP zrozumiały dla maszyn.
Ścieżka: /web-server.htm
Ścieżka wskazuje na konkretny plik lub zasób żądany na serwerze. To jak podawanie ścieżki do folderu i pliku na własnym komputerze. Ścieżka zawsze zaczyna się od pojedynczego ukośnika. W tym przykładzie żądamy pliku o nazwie web-server.htm z głównego katalogu serwera.
Komponenty opcjonalne (nie w tym przykładzie):
- Port: Specyficzna "brama" na serwerze dla połączenia. HTTP domyślnie używa portu $80$ , a HTTPS portu $443$ . Jeśli używany jest inny port, jest on podawany po hoście, oddzielony dwukropkiem, np. :8080.
- Ciąg zapytania (Query String): Zaczyna się od znaku zapytania (?) i służy do przesyłania dodatkowych danych do serwera, często w postaci par klucz-wartość (np. ?szukaj=sieci&strona=2).
- Fragment: Zaczyna się od symbolu krzyżyka (#) i wskazuje na konkretną sekcję wewnątrz żądanego zasobu (np. #sekcja2), do której przeglądarka może przeskoczyć po załadowaniu strony.

Szczegółowy Cykl Żądanie-Odpowiedź HTTP

Komunikacja między klientem a serwerem zawsze odbywa się w ścisłym cyklu żądanie-odpowiedź. Klient wysyła żądanie, a serwer odsyła odpowiedź. Nie mogą mówić w tym samym czasie. Przeanalizujmy strukturę tych komunikatów.

Komunikat Żądania HTTP

Komunikat żądania HTTP składa się z linii żądania, serii nagłówków, pustej linii i opcjonalnego ciała komunikatu.

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 ...
Accept-Language: pl-PL
Accept-Encoding: gzip, deflate
Connection: keep-alive

Linia żądania: Pierwsza linia określa (np. GET), ścieżkę do zasobu i wersję protokołu HTTP.
Nagłówki: Są to pary klucz-wartość, które dostarczają dodatkowych informacji o żądaniu, takich jak host, typ przeglądarki (User-Agent) oraz akceptowalne języki.
Ciało: Nieobecne w żądaniach GET, ale w metodach takich jak POST zawiera dane wysyłane do serwera (np. dane z formularza).

Komunikat Odpowiedzi HTTP

Odpowiedź serwera ma podobną strukturę, z linią statusu, nagłówkami, pustą linią i ciałem komunikatu zawierającym żądany zasób.

HTTP/1.1 200 OK
Date: Mon, 23 May 2025 22:38:34 GMT
Server: Apache/2.4.1 (Unix)
Content-Type: text/html; charset=UTF-8
Content-Length: 122

<!DOCTYPE html>
<html>
...
</html>

Linia statusu: Pierwsza linia zawiera wersję HTTP, numeryczny (np. 200) i tekstowy opis statusu (np. OK).
Nagłówki: Pary klucz-wartość opisujące odpowiedź, takie jak data, typ serwera i typ zawartości w ciele (Content-Type).
Ciało: Rzeczywisty zasób żądany przez klienta, w tym przypadku kod HTML strony internetowej.

Metody HTTP: Czasowniki Sieci

Metody HTTP, czasem nazywane czasownikami HTTP, określają działanie, które klient chce, aby serwer wykonał na danym zasobie. Choć istnieje kilka metod, najpopularniejsze z nich są fundamentalne dla niemal wszystkich interakcji w sieci.

GET: To najczęściej używana metoda. Żądanie $GET$ służy do pobierania danych z serwera. Kiedy wpisujesz adres URL w przeglądarce, inicjujesz żądanie GET. Żądania te powinny jedynie pobierać dane i nie powinny mieć żadnego innego wpływu na serwer (właściwość zwana bezpieczeństwem). Wszelkie dane wysyłane z żądaniem GET są dołączane do adresu URL jako ciąg zapytania, co czyni je widocznymi i ogranicza ich długość.
POST: Żądanie $POST$ służy do wysyłania danych na serwer w celu utworzenia nowego zasobu. Kiedy wypełniasz formularz kontaktowy lub podajesz dane logowania, Twoja przeglądarka wysyła żądanie POST. Dane są zawarte w ciele żądania, a nie w adresie URL, co czyni je bardziej bezpiecznymi dla poufnych informacji i pozwala na przesyłanie znacznie większej ilości danych. Żądania POST nie są bezpieczne, ponieważ modyfikują dane na serwerze, i nie są , co oznacza, że powtarzające się identyczne żądania utworzą wiele zasobów.
PUT: Metoda $PUT$ służy do aktualizacji istniejącego zasobu lub jego utworzenia, jeśli nie istnieje. Zastępuje cały docelowy zasób danymi dostarczonymi w ciele żądania. Kluczową różnicą między POST a PUT jest to, że PUT jest idempotentne. Wielokrotne wysyłanie tego samego żądania PUT zawsze doprowadzi do tego samego stanu na serwerze.
DELETE: Jak sama nazwa wskazuje, metoda $DELETE$ żąda usunięcia określonego zasobu z serwera. Podobnie jak PUT, operacje DELETE są idempotentne; wielokrotne usuwanie zasobu ma taki sam efekt jak jednokrotne.
HEAD: Metoda $HEAD$ jest identyczna z żądaniem GET, ale serwer nie wysyła ciała komunikatu w odpowiedzi. Służy do pobierania samych nagłówków dla zasobu, co może być przydatne do sprawdzenia, czy zasób istnieje, jaki ma rozmiar lub kiedy był ostatnio modyfikowany, bez konieczności pobierania całej zawartości.

Kody Statusu HTTP: Odpowiedź Serwera

Każda odpowiedź HTTP zawiera trzycyfrowy kod statusu, który informuje klienta o wyniku jego żądania. Kody te są pogrupowane w pięć klas, oznaczonych pierwszą cyfrą. Ich zrozumienie jest kluczowe do rozwiązywania problemów.

1xx (Informacyjne): Żądanie zostało odebrane, proces jest kontynuowany. Rzadko widoczne dla użytkowników końcowych. Przykład: $100 Continue$ .
2xx (Sukces): Żądanie zostało pomyślnie odebrane, zrozumiane i zaakceptowane.
- $\text{200 OK}$ : Standardowa odpowiedź dla pomyślnego żądania. Ciało odpowiedzi będzie zawierało żądany zasób.
- $\text{201 Created}$ : Żądanie zakończyło się sukcesem, a w jego wyniku utworzono nowy zasób (np. po żądaniu POST).
3xx (Przekierowanie): Wymagane jest dalsze działanie ze strony klienta, aby zakończyć żądanie. Klient musi udać się pod inny adres URL.
- $\text{301 Moved Permanently}$ : Żądany zasób został trwale przeniesiony pod nowy adres URL. Przeglądarka powinna zaktualizować swoje zakładki.
- $\text{302 Found}$ : Zasób został tymczasowo przeniesiony pod inny adres URL. Przeglądarka powinna nadal używać oryginalnego adresu URL w przyszłych żądaniach.
4xx (Błąd Klienta): Żądanie zawiera błędną składnię lub nie może zostać spełnione. Błąd leży po stronie klienta.
- $\text{400 Bad Request}$ : Serwer nie może lub nie będzie przetwarzał żądania z powodu błędu postrzeganego jako błąd klienta (np. zniekształcona składnia żądania).
- $\text{403 Forbidden}$ : Klient nie ma uprawnień dostępu do zawartości. Jest uwierzytelniony, ale nieautoryzowany.
- $\text{404 Not Found}$ : Serwer nie może znaleźć żądanego zasobu. To jeden z najsłynniejszych kodów statusu w sieci.
5xx (Błąd Serwera): Serwer nie zdołał zrealizować pozornie prawidłowego żądania. Błąd leży po stronie serwera.
- $\text{500 Internal Server Error}$ : Ogólny komunikat o błędzie, zwracany, gdy wystąpił nieoczekiwany problem i żaden bardziej szczegółowy komunikat nie jest odpowiedni.
- $\text{503 Service Unavailable}$ : Serwer nie jest gotowy do obsługi żądania, często z powodu konserwacji lub przeciążenia.

Ewolucja HTTP

HTTP nie powstał jednego dnia. Znacząco ewoluował od swoich początków, aby sprostać rosnącym wymaganiom sieci, skupiając się na poprawie wydajności i efektywności.

HTTP/0.9 - Protokół Jednoliniowy (1991): Pierwsza wersja. Była niezwykle prosta: żądanie składało się z jednej linii, metody $GET$ i ścieżki do zasobu. Odpowiedzią był sam plik HTML, bez nagłówków, kodów statusu czy innych metadanych.
HTTP/1.0 - Budowanie Rozszerzalności (1996): Ta wersja wprowadziła kluczowe funkcje, których używamy do dziś: nagłówki dla żądań i odpowiedzi, kody statusu w odpowiedziach oraz możliwość przesyłania plików innych niż HTML (jak obrazy i wideo). Głównym ograniczeniem było to, że dla każdego zasobu musiało być nawiązywane nowe połączenie , co było nieefektywne dla stron z wieloma obrazami.
HTTP/1.1 - Standard Internetowy (1997): Przez ponad 15 lat HTTP/1.1 stanowił fundament sieci. Wprowadził kluczowe optymalizacje wydajności. Najważniejszą były (za pomocą nagłówka `Keep-Alive`, później domyślne), które pozwalały przeglądarce na pobranie wielu zasobów przez jedno połączenie TCP, drastycznie redukując opóźnienia. Wprowadził również potokowość żądań (request pipelining), transfery porcjowane (chunked transfers) i obowiązkowy nagłówek `Host`.

Zabezpieczanie Sieci: Co oznacza 'S' w HTTPS?

Na początku istnienia sieci WWW cały ruch HTTP był przesyłany otwartym tekstem. Oznaczało to, że każdy, kto podsłuchiwał sieć, mógł z łatwością odczytać wszystkie dane wymieniane między przeglądarką a serwerem, w tym hasła i numery kart kredytowych. Aby załatać tę ogromną dziurę bezpieczeństwa, opracowano (Hypertext Transfer Protocol Secure).

HTTPS nie jest oddzielnym protokołem; to po prostu HTTP działający przez szyfrowane połączenie. Szyfrowanie to jest obsługiwane przez protokół o nazwie (Transport Layer Security), dawniej znany jako SSL (Secure Sockets Layer).

Oto jak to działa w uproszczeniu:

Weryfikacja Certyfikatu: Kiedy Twoja przeglądarka łączy się ze stroną przez HTTPS, serwer najpierw przedstawia swój certyfikat SSL/TLS. Ten cyfrowy certyfikat działa jak dowód osobisty, potwierdzając tożsamość serwera Twojej przeglądarce. Jest on wydawany i weryfikowany przez zaufaną stronę trzecią zwaną Urzędem Certyfikacji (CA).
Uzgadnianie (Handshake): Następnie klient i serwer przeprowadzają proces zwany uzgadnianiem TLS. W trakcie tego procesu używają informacji z certyfikatu (w szczególności klucza publicznego), aby bezpiecznie uzgodnić wspólny, tajny klucz sesji.
Szyfrowana Komunikacja: Po zakończeniu uzgadniania cały późniejszy ruch HTTP między klientem a serwerem jest szyfrowany przy użyciu tego klucza sesji. Każdy, kto przechwyci te dane, zobaczy jedynie zaszyfrowany, nieczytelny strumień znaków. Zapewnia to poufność, integralność i uwierzytelnienie Twojej komunikacji internetowej.

Nowoczesne przeglądarki, takie jak Chrome, oznaczają teraz każdą stronę niekorzystającą z HTTPS jako "Niezabezpieczoną", a bezpieczną witrynę można rozpoznać po ikonie kłódki na pasku adresu obok adresu URL, który zawsze zaczyna się od https://.

Wyzwanie Stanu w Protokole Bezstanowym

Jedną z podstawowych zasad projektowych HTTP jest to, że jest to . Oznacza to, że każdy cykl żądanie-odpowiedź jest całkowicie niezależny. Kiedy serwer otrzymuje żądanie, nie pamięta żadnych poprzednich żądań od tego samego klienta.

Ta prostota jest potężna pod względem skalowalności, ale stwarza problem przy tworzeniu interaktywnych doświadczeń internetowych. Jak sklep internetowy pamięta produkty w Twoim koszyku? Jak strona utrzymuje Cię zalogowanym, gdy przechodzisz z jednej podstrony na drugą?

Rozwiązaniem jest użycie (cookies). Ciasteczko to mały fragment danych, który serwer wysyła do przeglądarki w nagłówku odpowiedzi (Set-Cookie). Przeglądarka przechowuje to ciasteczko, a następnie odsyła je z powrotem do serwera przy każdym kolejnym żądaniu w nagłówku żądania (Cookie). To ciasteczko może zawierać unikalny identyfikator sesji, pozwalając serwerowi na odnalezienie stanu użytkownika (takiego jak jego koszyk zakupów lub status logowania) i zapewnienie ciągłego, stanowego doświadczenia w ramach wielu bezstanowych żądań.