Powrót

HTTP, wszystko co musisz wiedzieć

Czym jest HTTP?

To protokół umożliwiający przesyłanie informacji tekstowych po sieci. Początkowo to był dosłownie tylko surowy tekst (wersja 0.9, która powstała w 1991). Od razu pojawia się pytanie - to po co w ogóle jakiś nowy protokół? Przecież za pomocą samego TCP/IP też się da wysłać coś takiego.

Odpowiedź brzmi: trzeba było czegoś co ustandaryzuje komunikację na potrzeby działania WWW. Co prawda początkowo był to faktycznie tylko tekst, ale wraz z wersją HTTP/1.0 (1996 rok) pojawiło się dodatkowe pole dla nagłówków (Headers), które były czymś w rodzaju metadanych dla wiadomości.

Wersje HTTP

Wraz z każdą kolejną wersją możliwości standardu rosły i już następna (1.1, która powstała rok później) wprowadziła cały szereg nowości, takich jak:

• Podtrzymywanie połączenie. Już nie było potrzeby tworzyć nowego połączenia za każdym razem kiedy chciało się wysłać jakieś żądanie do serwera. To pozwoliło odciążyć serwery, które dotychczas musiały za każdym razem wykonywać więcej operacji (o tym jak działa trzyetapowy handshake przeczytasz w artykule o działaniu TCP).
• Pipeling zapytań. Można było wysłać kilka żądań do serwera, bez konieczności czekania na ukończenie poprzedniego. Druga rzecz, która znacząco wpłynęła na wydajność działań stron WWW.
• Nowe metody (OPTIONS oraz TRACE), o których więcej napiszę niżej.
• Chunked Transfer Encoding czyli wsparcie wysyłania danych w mniejszych kawałkach (podobnie jak się to ma w przypadku pakietów w TCP). Można to było jednak wykorzystać także w sytuacji kiedy nie wiemy z góry jaka jest wielkość przesyłanych treści. Na przykład streamując dźwięk lub wideo na żywo. Po prostu nie trzeba było czekać na całość, tylko można było ją konsumować częściowo w trakcie oczekiwania na resztę.
• Skalowalność Hostów. Przed HTTP/1.1 każda domena musiała kierować na unikalny adres IP. Wraz z dodaniem nagłówka “Host”, umożliwiono przypisywanie wielu domen dla jednego adresu. Po co? Pula adresów IP jest ograniczona i szczególnie biorąc pod uwagę fakt, że wtedy nie znano jest IPv6, był to pewien problem. Dzięki tej nowej opcji, firmy hostingowe mogły wykorzystywać pojedyncze serwery do obsługi wielu klientów, korzystajcych z wielu domen.
• Negocjacje treści. Dzięki innemu nowemu nagłówkowi (Accept-*), przeglądarka (lub inny klient) może wraz z zapytaniem do serwera, określić w jakim formacie (’application/json’), języku (’en-us’) lub kodowaniu (np UTF-8) odpowiedź chce otrzymać.
• Możliwe przesyłane nowych typów treści takie jak obrazy, dźwięk, wideo lub aplikacje. W parze do tego pojawiła się opcja ustawienia nagłówków, które dostosowywały otrzymywaną treść (dość popularne Content-Type)
• Wiele nowych kodów odpowiedzi serwera.

HTTP/2

W 2015 roku, po wielu latach obowiązywania standardu 1.1, w końcu pojawił się godny następca. Ponownie duży nacisk położono na poprawę wydajności, ale to nie wszystko.

• Wielokrotne strumieniowanie na jednym połączeniu (Multiplexing). Zaraz, ale czy tego już nie było? Już w HTTP/1.1 można było przecież utrzymywać jedno połączenie TCP. Różnica polega na tym, że od nowej wersji możliwe jest wykonywanie wielu zapytań, w ramach jednego połączenia równocześnie. Nie tylko pomijamy ponowne handshake’i, ale też pozwalamy na pobieranie wielu materiałów (np CSS, JS, obrazy) równocześnie.
• Kompresja nagłówków. Sprytny sposób na zoptymalizowanie czasu ładowania strony. Nagłówki często zawierają powtarzające się informacje co sprawia, że kompresja jest bardzo efektywna i zauważalnie zmniejsza ich wagę. Jest do tego wykorzystywany specjalnie zaprojektowany pod to algorytm HPACK.
• Priorytetyzacja strumieni, czyli możliwość wskazania priorytetowych zasobów, które pobierane będą szybciej - na przykład JS, bez którego strona nie zadziała albo zdjęcia, które powinny wczytać się pierwsze.
• Wszystkie komunikaty w ramach HTTP/2 są pakowane w binarne “ramki”. Zamiast strumienia tekstowego jak to miało miejsce w poprzedniej wersji. Przetwarzanie takich treści w formacie binarnym jest znacznie szybsze. W dodatku pomaga to w multiplexingu.
• Szyfrowanie jest niejako w standardzie. Większość popularnych przeglądarek obsługuje HTTP/2 tylko w połączeniu z szyfrowaniem TLS. Więcej o tym w artykule o SSL oraz TLS.

HTTP/3

Najnowsza, zatwierdzona dopiero co w maju 2021 roku wersja protokołu wprowadza dość znaczącą zmianę. Żegna się z wysłużonym TCP i zaczyna korzystać z QUIC. Z czym to się wiąże?

• Szybciej nawiązuje połączenia, bo potrzebuje do tego mniejszego zestawu danych. Trzyetapowy handshake w TCP trwa dłużej.
• Pozwala jeszcze optymalnie pracować z Multiplexingiem znanym z HTTP/2
• Posiada wbudowane szyfrowanie już na własnym poziomie (podobne do TLS)
• Lepiej radzi sobie ze stabilnością podczas zmian w połączeniu z internetem - na przykład gdy przełączamy się między internetem mobilnym, a WiFi.

QUIC to jednak znacznie więcej i zdecydowanie warto poznać jego możliwości. Piszę o tym w osobnym artykule.

HTTPS

Jak już dobrze wiesz, od drugiej wersji protokołu szyfrowanie jest niejako w standardzie w formie TLS. W najnowszej z kolei jest wbudowane w warstwę niżej, protokół transportowy - QUIC. W przypadku jego pierwszej wersji nie było to jednak w żaden sposób automatycznie robione i rozróżnienie HTTP od HTTPS odgrywało większą rolę.

Hypertext Transfer Protocol Secure to po prostu HTTP (w dowolnej wersji), które ma uruchomione szyfrowanie danych. Kiedy jest to ważne?

• Kiedy strona/aplikacja używa formularzy, których treść może trafić w niepowołane ręce.
• Kiedy odbywają się transakcje finansowe i wyciec mogą dane kart płatniczych.
• Podczas przesyłania poufnych konwersacji jak np treść chatów, maili.
• …i zawsze tam gdzie jakieś dane nie są przeznaczone dla postronnych oczu.

Obecnie szyfrowanie połączeń HTTP jest już powszechnie stosowanym standardem, a strony niespełniające tego wymogu są często automatycznie blokowane przez nowoczesne przeglądarki.

Powrót