W jaki sposób HTTP staje się bezstanowy?

Mówi się, że HTTP jest bezstanowy. Oznacza to, że nie musi przechowywać informacji w celu transmisji danych.

Ale HTTP używa TCP, który jest zorientowany na stan.

W takim przypadku, w jaki sposób HTTP staje się bezstanowy?

HTTP nie przejmuje się - i jest niezależny - jakimkolwiek protokołem niższego poziomu używanym do transportu, nawet jeśli sam jest bezstanowy.

Technologią transportu może być TCP, stary SPX lub SCTP firmy Novell, lub cokolwiek innego, co można wymyślić, a HTTP nadal będzie działał tak samo. HTTP wymaga przesyłania strumieniowego lub protokołu zorientowanego na połączenie - i zależy od rozdzielczości adresów URL - ale nie obchodzi, jak to osiągnąć.

Jest to jeden z powodów istnienia modelu warstwowego lub stosu sieciowego: warstwa aplikacji nie musi zajmować się niższymi warstwami.

To, że protokół niższego poziomu jest stanowy, nie oznacza, że ​​nic nad nim automatycznie staje się stanowe lub wymaga stanu.

Sam HTTP jest bezstanowy. Oznacza to, że aplikacje muszą zaimplementować kolejną warstwę na HTTP, aby ustalić stan. Zazwyczaj odbywa się to za pomocą sesyjnych plików cookie.

„HTTP jest bezstanowy” oznacza, że ​​każda transakcja HTTP (para żądanie-odpowiedź) może być przetwarzana niezależnie od dowolnego stanu z poprzedniej pary żądanie-odpowiedź.

Aby przetransportować określoną parę żądanie-odpowiedź, potrzebujesz protokołu, który jest w stanie przenosić dowolnie duży blok i dowolnie duży blok z powrotem, a aby to zrobić na warstwie o ograniczonym rozmiarze pakietu, TCP musi być stanowy.

Ale poza granicami transakcji nie ma stanu. Klient może porzucić połączenie i ustanowić nowe dla następnego żądania. W rzeczywistości była to jedyna opcja we wczesnych wersjach i nadal tak działa, jeśli klient nie zawiera Connection: keep-alivenagłówka.

Kolejne żądanie może być łatwo obsłużone przez inny serwer, a klient nigdy się nie dowie, ponieważ serwer nie musi utrzymywać żadnego stanu (chyba że aplikacja doda własny stan do HTTP, zwykle w formie sesji; wynikające z tego komplikacje w równoważeniu obciążenia jest kara za budowanie stanowego protokołu na HTTP). Wykorzystuje się to w obciążonych serwerach równoważących obciążenie.

„Bezstanowy” charakter HTTP oznacza, że ​​na tej warstwie nie są tworzone ani wykorzystywane żadne informacje o stanie.

Możesz to zobaczyć w kilku przypadkach, na przykład w uwierzytelnianiu HTTP, poświadczenia są wysyłane przy każdym żądaniu, a trwałe połączenia są tak naprawdę tylko optymalizacją (tj. Jeśli wysyłam poświadczenia, serwer zapomina o nich po żądaniu, nawet jeśli opuszcza połączenie otwarte).

Natomiast mechanizmy logowania oparte na plikach cookie są stanowe, ale nie stanowią części protokołu HTTP.

Musisz zrozumieć to jako zestaw rosyjskich lalek (lub pudełek, jeśli chcesz), każda z nich niosąca kolejną w środku, tak rażąco to działa: TCP przenosi HTTP „wewnątrz”, ale nie obchodzi go to ani jego funkcje.

Aby uzyskać cały obraz, polecam przeczytać o modelu OSI, ponieważ jest on bardziej przejrzysty.

TCP znajduje się kilka warstw poniżej HTTP w modelu OSI, każda warstwa w rzeczywistości odpowiada innemu protokołowi.

W naszym przypadku HTTP znajduje się w warstwach prezentacji i aplikacji, a TCP w warstwie transportowej. Lub jeśli używasz modelu TCP / IP, protokoły TCP i IP znajdują się w warstwie łącza sieciowego, a HTTP w warstwie aplikacji i prezentacji.