Protokół przesyłania hipertekstu
Funkcjonować | Transmisja hipertekstowa |
---|---|
Akronim | HTTP |
Data utworzenia | 1990 |
Port | 80 |
RFC |
1996 : RFC 1945 1997 : RFC 2068 1999 : RFC 2616 2014 : RFC 7230 do 7237 2015 : RFC 7540 |
" Hypertext Transfer Protocol (HTTP, dosłownie "Transfer Protocolhipertekstu ") toprotokół komunikacji klient-serweropracowany do sieci World Wide Web . HTTPS(z S dla zabezpieczone , czyli „bezpieczny”) jest bezpieczny wariant pomocą Transport Layer Security (TLS) protokołów.
HTTP to protokół warstwy aplikacji . Może pracować na dowolnym niezawodnym połączeniu, w rzeczywistości protokół TCP jest używany jako warstwa transportowa. Serwer HTTP następnie używa portu 80 domyślnie (443 dla protokołu HTTPS).
Do najbardziej znanych klientów HTTP są przeglądarek internetowych, które pozwalają użytkownikowi na dostęp do serwera zawierającego dane. Istnieją również systemy do automatycznego pobierania treści z witryny, takie jak odkurzacze witryn internetowych lub roboty indeksujące .
Protokół HTTP został wymyślony przez Tima Bernersa-Lee z adresami internetowymi i kodem HTML, aby stworzyć sieć WWW . W tym czasie protokół FTP ( File Transfer Protocol ) był już dostępny do przesyłania plików, ale nie obsługiwał pojęcia formatu danych wprowadzonego przez uniwersalne rozszerzenia poczty internetowej (MIME). Pierwsza wersja HTTP była bardzo prosta, ale zawierała już obsługę nagłówków MIME do opisywania przesyłanych danych. Ta pierwsza wersja jest nadal częściowo dostępna do dziś, znana jako HTTP / 0.9.
W maj 1996, HTTP / 1.0 został wydany i jest opisany w RFC 1945. Ta wersja obsługuje wirtualne serwery HTTP, zarządzanie pamięcią podręczną i identyfikację.
W styczeń 1997HTTP/1.1 staje się ostatecznie standardem IETF . Jest to opisane w RFC 2068 IETF, a następnie w RFC 2616 wCzerwiec 1999. W tej wersji dodano obsługę potokowania (lub potokowania) i negocjacji typu zawartości (format danych, język).
W marzec 2012, prace nad HTTP / 2.0 rozpoczynają się w IETF przyjmując SPDY jako materiał wyjściowy.
W luty 2014, ponownie opublikowano specyfikację protokołu HTTP 1.1. Został podzielony na kilka specyfikacji RFC i poprawiony pod kątem wszystkich nieścisłości, RFC 7230 do RFC 7237.
W protokole HTTP metoda jest poleceniem określającym typ żądania, to znaczy żąda od serwera wykonania akcji. Ogólnie rzecz biorąc, akcja dotyczy zasobu identyfikowanego przez adres URL następujący po nazwie metody.
Na ilustracji obok wysyłane jest żądanie GET w celu pobrania strony głównej witryny www.perdu.com:
GET / HTTP/1.1 Host: www.perdu.comIstnieje wiele metod, z których najczęstsze to GET, HEAD i POST:
GET Jest to najczęstsza metoda żądania zasobu. Żądanie GET nie ma wpływu na zasób, musi być możliwe powtórzenie żądania bez skutku. HEAD Ta metoda żąda tylko informacji o zasobie, bez pytania o sam zasób. POST Ta metoda służy do przesyłania danych do przetworzenia do zasobu (najczęściej z formularza HTML). Podany identyfikator URI to identyfikator URI zasobu, do którego będą miały zastosowanie wysyłane dane. Rezultatem może być tworzenie nowych zasobów lub modyfikacja istniejących zasobów. Ze względu na słabą implementację metod HTTP (dla Ajax ) przez niektóre przeglądarki (oraz standard HTML, który obsługuje tylko metody GET i POST dla formularzy), metoda ta jest często używana jako zamiennik dla żądania PUT, które należy wykorzystać do aktualizacji zasoby. OPTIONS Ta metoda służy do uzyskiwania opcji komunikacyjnych zasobu lub ogólnie serwera. CONNECT Ta metoda umożliwia wykorzystanie serwera proxy jako tunelu komunikacyjnego. TRACE Ta metoda prosi serwer o zwrócenie tego, co otrzymał, w celu przetestowania i zdiagnozowania połączenia. PUT Ta metoda umożliwia zastąpienie lub dodanie zasobu na serwerze. Podany identyfikator URI jest identyfikatorem danego zasobu. PATCH Ta metoda pozwala, w przeciwieństwie do PUT, dokonać częściowej modyfikacji zasobu. DELETE Ta metoda umożliwia usunięcie zasobu z serwera.Te ostatnie 3 metody zazwyczaj wymagają dostępu uprzywilejowanego.
Niektóre serwery umożliwiają inne metody zarządzania swoimi zasobami (na przykład WebDAV ).
Połączenie między klientem a serwerem nie zawsze jest bezpośrednie, mogą występować komputery pośredniczące pełniące rolę przekaźników:
HTTP umożliwia identyfikację odwiedzającego poprzez przesłanie nazwy i hasła . Istnieją 2 tryby identyfikacji: Basic i Digest ( RFC 2617). W pierwszym trybie hasło jest przesyłane w sposób jawny, dlatego powinien być używany tylko z protokołem HTTPS. Drugi tryb pozwala na identyfikację bez przekazywania hasła w sposób jawny. Identyfikacja jest jednak często przeprowadzana przez warstwę aplikacji wyższą niż HTTP.
Na początku World Wide Web planowano dodanie możliwości negocjowania treści do protokołu HTTP, czerpiąc inspirację w szczególności z MIME . Do tego czasu protokół HTTP 0.9 był niezwykle prosty.
Żądanie:
GET /page.htmlMetoda GETjest jedyna możliwa. Serwer rozpoznaje, że ma do czynienia z żądaniem HTTP 0.9, ponieważ wersja nie jest określona po identyfikatorze URI.
Odpowiadać :
<html> <head> <title>Exemple</title> </head> <body> <p>Ceci est une page d'exemple.</p> </body> </html>Aby odpowiedzieć na żądanie HTTP 0.9, serwer wysyła treść odpowiedzi bezpośrednio, bez metadanych. Nigdy nie powinien zachowywać się w ten sposób w przypadku żądań HTTP wyższej wersji.
Nie trzeba szukać wersji niższych niż 0.9 protokołu HTTP: nie istnieją, ponieważ HTTP 0.9 początkowo nie miał numeru wersji. Musiał zostać przypisany, gdy przybył HTTP 1.0.
HTTP 1.0Protokół HTTP 1.0, opisany w RFC 1945, przewiduje wykorzystanie nagłówków określonych w RFC 822. Zarządzanie połączeniami pozostaje identyczne jak HTTP 0.9: klient nawiązuje połączenie, wysyła żądanie, serwer odpowiada i natychmiast zamyka połączenie.
Żądanie HTTP ma następujący format:
Ligne de commande (Commande, URL, Version de protocole) En-tête de requête [Ligne vide] Corps de requêteOdpowiedzi HTTP mają następujący format:
Ligne de statut (Version, Code-réponse, Texte-réponse) En-tête de réponse [Ligne vide] Corps de réponseŻądanie:
GET /page.html HTTP/1.0 Host: example.com Referer: http://example.com/ User-Agent: CERN-LineMode/2.15 libwww/2.17b3Wersja protokołu HTTP jest określana po identyfikatorze URI. Żądanie musi być zakończone podwójnym znakiem nowej linii ( CRLFCRLF ). HTTP 1.0 obsługuje również metody HEAD i POST. Widzimy użycie nagłówków inspirowanych MIME do przesyłania metadanych:
Host Służy do określenia strony internetowej , której dotyczy żądanie, co jest niezbędne dla serwera obsługującego kilka stron pod tym samym adresem IP ( wirtualny host oparty na nazwie ). To jedyny naprawdę ważny nagłówek. Referer Wskazuje identyfikator URI dokumentu, który podał link do żądanego zasobu. Ten nagłówek pozwala webmasterom zobaczyć, skąd pochodzą użytkownicy. User-Agent Wskazuje oprogramowanie używane do połączenia. Zwykle jest to przeglądarka internetowa lub robot sieciowy .Odpowiadać :
HTTP/1.0 200 OK Date: Fri, 31 Dec 1999 23:59:59 GMT Server: Apache/0.8.4 Content-Type: text/html Content-Length: 59 Expires: Sat, 01 Jan 2000 00:59:59 GMT Last-modified: Fri, 09 Aug 1996 14:21:40 GMT <TITLE>Exemple</TITLE> <P>Ceci est une page d'exemple.</P>Pierwsza linia zawiera kod statusu HTTP (w tym przypadku 200).
Date Czas wygenerowania wiadomości. Server Wskazuje, który model serwera HTTP odpowiada na żądanie. Content-Type Wskazuje typ MIME zasobu. Content-Length Wskazuje rozmiar zasobu w bajtach . Expires Wskazuje, kiedy zasób należy uznać za przestarzały; umożliwia przeglądarkom internetowym określenie czasu buforowania zasobu . Last-Modified Wskazuje datę ostatniej modyfikacji żądanego zasobu. HTTP 1.1Protokół HTTP 1.1 jest opisany w RFC 2616, co czyni RFC 2068 przestarzałym. Różnica w stosunku do HTTP 1.0 polega na lepszym zarządzaniu pamięcią podręczną. Nagłówek Host staje się obowiązkowy w żądaniach.
Główne obawy pierwszych dwóch wersji protokołu HTTP to z jednej strony duża liczba połączeń podczas ładowania złożonej strony (zawierającej dużo obrazów lub animacji), a z drugiej strony czas otwarcia połączenia między klientem i serwer ( ustanowienie połączenia TCP zajmuje trzy razy więcej czasu między klientem a serwerem). Eksperymenty z trwałymi połączeniami zostały jednak przeprowadzone z HTTP 1.0 (zwłaszcza przy użyciu nagłówka Connection: Keep-Alive ), ale zostało to ostatecznie rozwinięte dopiero w HTTP 1.1.
Domyślnie HTTP 1.1 używa trwałych połączeń, co oznacza, że połączenie nie jest zamykane natychmiast po żądaniu, ale pozostaje dostępne dla nowego żądania. Ta funkcja jest często nazywana utrzymywaniem aktywności . Dozwolone jest również, aby klient HTTP wysyłał wiele żądań w tym samym połączeniu bez oczekiwania na odpowiedzi. Ta funkcja nazywa się potokiem . Trwałość połączeń umożliwia przyspieszenie ładowania stron zawierających kilka zasobów przy jednoczesnym zmniejszeniu obciążenia sieci.
Zarządzanie trwałością połączenia jest obsługiwane przez nagłówek Connection .
HTTP 1.1 obsługuje negocjację treści. Klient HTTP 1.1 może towarzyszyć żądaniu zasobu nagłówków wskazujących preferowane języki i formaty danych . Są to nagłówki, których nazwy zaczynają się od Accept- .
Dodatkowe nagłówki obsługiwane przez HTTP 1.1 to:
Connection Ten nagłówek może być wysłany przez klienta lub serwer i zawiera listę nazw określającą opcje do użycia z bieżącym połączeniem. Jeśli opcja ma parametry, są one określone przez nagłówek o tej samej nazwie co opcja ( na przykład Keep-Alive , aby określić maksymalną liczbę żądań na połączenie). Nazwa close jest zarezerwowana, aby określić, że połączenie powinno zostać zamknięte po przetworzeniu bieżącego żądania. Accept Ten nagłówek zawiera listę typów zawartości MIME akceptowanych przez klienta. Znak gwiazdki * może być użyty do określenia wszystkich typów/podtypów. Accept-Charset Określa akceptowane kodowania znaków. Accept-Language Określa akceptowane języki.Kolejność preferencji każdej opcji (typ, kodowanie lub język) jest określona przez opcjonalny parametr q zawierający wartość dziesiętną od 0 ( niedopuszczalne ) do 1 ( dopuszczalne ) włącznie (maksymalnie 3 miejsca po przecinku), równą 1 domyślnie .
Obsługa połączeń trwałych musi działać również w przypadkach, gdy wielkość zasobu nie jest z góry znana (zasób generowany dynamicznie przez serwer, przepływ zewnętrzny do serwera itp.).
W tym celu kodowanie transferu o nazwie chunked umożliwia przesyłanie zasobu w kolejnych częściach, z których każdy poprzedza wiersz tekstu podający jego rozmiar w systemie szesnastkowym. Następnie transfer kończy się fragmentem o zerowym rozmiarze, do którego można wysłać końcowe nagłówki.
Dodatkowe nagłówki związane z tym kodowaniem transferu to:
Transfer-Encoding Określa kodowanie transferu. Jedyna wartość zdefiniowana w specyfikacji RFC 2616 jest podzielona na części . Trailer Wyświetla listę wszystkich nagłówków pojawiających się po ostatnim przesłanym utworze. TE Wysłane przez klienta, aby określić obsługiwane kodowanie zawartości ( Content-Encoding , nie należy mylić z Transfer-Encoding ponieważ pofragmentowane jest obowiązkowo obsługiwany przez klientów i serwerów realizujących standard HTTP / 1.1) i określa, czy podpór klienckich to. - Trailer udaj się, dodając przyczepy do listy. HTTP 1.1 bisRFC 2616 zawierał wiele nieścisłości. Grupa robocza HTTP zajęła kilka lat, aby wyjaśnić specyfikację bez modyfikowania semantyki zgodnie z zaleceniami w statucie operacyjnym grupy dla tej pracy. Wczerwiec 2014opublikowano 8 nowych dokumentów, które są przestarzałe RFC 2616:
Nowa wersja protokołu HTTP, HTTP/2, została opracowana w ramach grupy roboczej Hypertext Transfer Protocol Bis (httpbis) grupy zadaniowej ds. inżynierii internetowej i zatwierdzona jako standard RFC.18 lutego 2015. Rozwój HTTP/2 rozpoczął się po stworzeniu protokołu SPDY zaproponowanego przez Google w celu skrócenia czasu ładowania stron internetowych. Grupa robocza httpbis początkowo powstrzymywała się od proponowania nowej wersji HTTP, koncentrując swoje działania na doprecyzowaniu specyfikacji HTTP 1.1. Biorąc pod uwagę pojawienie się SPDY i jego szybkie przyjęcie w sieci, ze szczególnym uwzględnieniem implementacji w dwóch głównych przeglądarkach internetowych , Google Chrome i Mozilla Firefox , Mark Nottingham, „przewodniczący” httpbis, wyraził opinię, że nadszedł czas, aby rozważyć HTTP/ 2 i zaproponował zmianę statutu httpbis w tym kierunku, inicjując tym samym opracowanie nowego protokołu.
SPDY był naturalną opcją, aby służyć jako podstawa dla HTTP/2. Dwie inne konkurencyjne propozycje zostały następnie przesłane do IETF: protokół „HTTP Speed + Mobility” firmy Microsoft oraz propozycja aktualizacji HTTP („Network-Friendly HTTP Upgrade”). WLipiec 2012, httpbis opublikował zaproszenie do wyrażenia zainteresowania („Zaproszenie do wyrażenia zainteresowania”) w celu zebrania opinii graczy internetowych na temat propozycji. Wśród uzyskanych odpowiedzi znalazła się odpowiedź Facebooka, który wskazał, że preferuje SPDY. Wlistopad 2012IETF wydała pierwszą wersję roboczą HTTP/2, która jest bezpośrednią kopią SPDY.
Po ponad 2 latach dyskusji RFC zostaje zatwierdzony w luty 2015 przez Grupę Sterującą IETF i jest publikowany w: maj 2015.
Moduł do obsługi protokołu HTTP/2 jest dostępny od wersji 2.4.17 serwera WWW Apache oraz od wersji 1.9.5 Nginx.
HTTP / 3Nowa wersja HTTP, HTTP/3, to trzecia i kolejna główna wersja protokołu przesyłania hipertekstu używanego do wymiany informacji w sieci WWW. Jest to oparte na protokole QUIC, opracowanym przez Google w 2012 roku.
Semantyka HTTP jest spójna w zależności od wersji. Dzieje się tak, ponieważ te same metody kwerend, kody stanu i pola komunikatów mają zasadniczo zastosowanie do wszystkich wersji.
Podczas gdy HTTP / 1 i HTTP / 2 używają TCP jako protokołu transportowego, HTTP / 3 używa QUIC, protokołu warstwy transportowej, który jest bardziej odpowiedni dla Internetu. Przejście na QUIC ma na celu rozwiązanie głównego problemu HTTP / 2 zwanego "blokowaniem nagłówka linii" dzięki enkapsulacji pakietów w UDP. Rzeczywiście, w przypadku protokołu HTTP/2 opartego na TCP połączenie składa się z kilku strumieni. To połączenie nazywa się multipleksem. Jednak w przypadku utraty pakietów w strumieniu całe połączenie jest spowolnione. Dzięki HTTP/3 opartemu na protokole QUIC nie mamy już tego problemu, ponieważ wszystkie przepływy są niezależne i są enkapsulowane w UDP, protokole transportowym, który nie wymaga połączenia.