Protokół HTTP - przegląd protokół warstwy aplikacyjnej będący mechanizmem komunikacji w sieci WWW. program klienta (którym jest tzw. przeglądarka np. Microsoft Explorer lub Netscape Navigator) i proces serwera (np. serwer Apache, serwer Netscape, IIS) uruchomione na różnych systemach końcowych wzajemnie się komunikują wymieniając komunikaty HTTP. transfer danych odbywa się w postaci stron WWW w większości sytuacji będących plikami w języku HTML. HTTP definiuje jak klienci Web żądają stron WWW stron od serwerów oraz jak serwery dokonują transferu tych stron do klientów.
Protokół HTTP Odwołanie się klienta do zasobu odbywa się przez podanie tzw. URL (Uniform Resource Locator), który identyfikuje żądany zasób. URL składa się ze schematu definiującego protokół używany w żądaniu oraz położenia tego zasobu wyrażonego poprzez nazwę (lub adres IP) komputera, na którym znajduje się ten zasób i port na którym proces reprezentujący dany protokół nadsłuchuje na serwerze. Ponadto mamy ścieżkę identyfikująca położenie zasobu w systemie plikowym. Opcjonalnie URL może zawierać parametry. http://www.firma.com:8080/katalog1/katalog2/plik schemat nazwa hosta port ścieżka do pliku
Protokół HTTP
Trwałe i nietrwałe połączenia HTTP może używać zarówno nietrwałych (non-persistent) jak i trwałych (persistent) polączeń. Non-persistent połączenia są domyślne dla HTTP/1.0 (HTTP w wersji 1.0). Persistent połączenia są domyślnym ustawieniem dla HTTP/1.1.
Połączenia non-persistent Działają według następującego schematu: 2. Klient HTTP inicjuje połączenie TCP do serwera np. www.firma.com. 3. Klient HTTP wysyła HTTP request message w ramach tego połączenia. Żądanie zawiera cały URL lub tylko ścieżkę wskazującą na żądany plik /katalog1/katalog2/plik.html 4. Serwer HTTP odbiera żądanie i pobiera wskazany obiekt /katalog1/katalog2/plik.html z systemu składowania danych (RAM lub dysk), umieszcza obiekt w HTTP response message, którą wysyła poprzez połączenie TCP.
Połączenia non-persistent 4. Serwer HTTP wysyła pakiet żądający zamknięcia sesji TCP. (TCP nie przerywa jednak połączenia dopóki klient nie otrzyma komunikatu.) 5. Klient HTTP odbiera odpowiedź. Połączenie TCP zostaje zamknięte. Klient wydobywa plik z komunikatu odpowiedzi, parsuje plik HTML i wyszukuje odwołania do innych obiektów. 6. Pierwsze cztery kroki są powtarzane dla każdego obiektu umieszczonego na stronie.
Połączenia non-persistent
Połączenia non-persistent nowe połączenie musi być ustanowione i utrzymywane dla każdego żądanego obiektu (np. elementu strony) każdy obiekt powoduje dwa RTTs -- jedno RTT dla ustanowienia połączenia TCP i jedno dla żądania i otrzymania obiektu każdy obiekt wywołuje powolną procedurę startu połączenia TCP
Połączenia persistent przy trwałych połączeniach, serwer utrzymuje sesję TCP otwartą po wysłaniu odpowiedzi. Kolejne żądania i odpowiedzi pomiędzy tym samym klientem i serwerem mogą być wysyłane w ramach tej sesji cała strona WWW może być wysłana w ramache jednej sesji TCP, nawet wiele stron znajdujących się na tym samym serwerze może być przesłanych w ciągu takiej sesji. serwer HTTP zamyka połączenie kiedy nie pojawiają się żadne odwołania przez pewien czas (timeout), zwykle konfigurowalny..
Połączenia persistent bez użycia pipelining -u klient wysyła nowe żądanie gdy poprzednie zostało zrealizowane w tym przypadku występuje jedno RTT dla wysłania żądania i otrzymania obiektu. Chociaż daje to oszczędności w stosunku do dwóch RTT dla połączeń typu non-persistent nie jest to optymalne rozwiązanie po wysłaniu obiektu przez serwer nie robi on nic - oczekując na kolejne żądanie.
Połączenia persistent
Połączenia persistent z użyciem pipelining -u Klient HTTP może wykonać wiele żądań backto-back dla obiektów. kiedy serwer otrzymuje żądania może wysłać dane obiekty back-to-back. Jeżeli wszystkie żądania są wysłane back-to-back i wszystkie odpowiedzi są wysłane back-to-back wtedy tylko jedno RTT potrzebne dla wszystkich obiektów.
Połączenia persistent
Komunikaty HTTP Komunikaty HTTP są podstawową formą komunikacji pomiędzy klientem i serwerem. Wyróżniamy dwa typy komunikatów: komunikaty żądania komunikaty odpowiedzi Komunikaty te służą do transferu danych i zasobów (zwanych jednostkami) między klientem i serwerem.
HTTP - komunikat żądania Program klienta wysyła komunikat żądania w celu uzgodnienia parametrów komunikacyjnych oraz aby rozpocząć transfer i przetwarzanie zasobu. Komunikat zasobu może zawierać różne metody-działania, o które klient pyta czy mogą być wykonane na serwerze lub zastosowane do jednostki zasobu. Najczęstsze metody to: OPTIONS - żąda informacji związanych z możliwościami serwera lub rodzajem akcji możliwych do wykonania na zasobie. GET - żądanie wydobywa określone informacje. HEAD - identycznie jak GET, tylko serwer w odpowiedzi nie pozwala na przesłanie zasobu, a tylko informacji o nim POST - klient stosuje tę metodę wcelu wysłania bloku danych do serwera np. dostarczenie danych do skryptu metody PUT i DELETE - pozwalają zażądać odpowiednio wysłania lub usunięcia pliku na serwerze.
HTTP Request Message
HTTP - komunikat żądania Przykładowy HTTP Request Message GET /somedir/page.html HTTP/1.1 Connection: close User-agent: Mozilla/4.0 Accept: text/html, image/gif, image/jpeg Accept-language:fr
HTTP - komunikat odpowiedzi Po odebraniu przez serwer komunikatu żądania od klienta, serwer ocenia metodę żądania i w rezultacie może wykonać określone działanie na żądanym zasobie, a następnie odpowiada klientowi komunikatem odpowiedzi. Odpowiedź zawiera kod zawierający informacje o tym czy żądanie zostało zrealizowane poprawnie oraz w przypadku błędu informujące o jego charakterze np. błąd klienta (4xx), błąd serwera (5xx) itp. Jeżeli żądanie dotyczyło transferu danych to odpowiedź zawiera te dane.
HTTP Response Message
HTTP Message Format Przykładowy HTTP Response Message HTTP/1.1 200 OK Connection: close Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 09:23:24 GMT Content-Length: 6821 Content-Type: text/html data data data...
Negocjowanie opcji i zawartości Ponieważ nie wszyscy użytkownicy są w stanie zinterpretować wszystkie składniki dokumentów istnieją mechanizmy negocjowania zawartości. Mamy dwa rodzaje negocjowania zawartości: server-driven agent-driven Te dwa rodzaje mogą być użyte osobno lub w kombinacji.
Negocjacje przy użyciu sterownika serwera ( server-driven ) Wybór najlepszej odpowiedzi na żądanie jest dokonywane na podstawie algorytmu serwera Wybór jest oparty na: dostępnych reprezentacjach odpowiedzi tj. na własnych możliwościach zawartości odpowiednich pól nagłówka żądania innej informacji zawartej w żądaniu (np. adresie klienta) HTTP 1.1 używa następujących pól nagłówka dla negocjacji zawartości: Accept: Accept-Charset: Accept-Encoding: Accept-Language: User-Agent:
Negocjacje przy użyciu sterownika serwera ( server-driven ) Accept: - używane do określenia, które typy nośników akceptują odpowiedź;można ograniczyć się do grupy (np. Image/*, */* ) lub poszczególnych typów (np. image/gif, image/jpeg, itp.);brak pola Accept w nagłówku oznacza,że wszystkie typy są akceptowane; Accept-Charset: - wskazuje akceptowany zestaw znaków np. iso- 8859-5 Accept-Encoding: - używany do wyznaczenia sposobu kodowania, takiego jak compress lub gzip Accept-Language: - określa akceptowane języki np. en-us, fr User-Agent: - używany do przekazywania informacji o oprogramowaniu klienta np. Mozilla/4.0 dla MSIE 5.0
Negocjacje przy użyciu sterownika klienta ( client-driven ) W procesie tym oprogramowanie klienta wysyła komunikat żądania do serwera, w którym określa swoje możliwości. Określenia znajdują się w polu nagłówka. Po odebraniu żądania serwer wysyła w odpowiedzi komunikat określający jego możliwości. Następnie agent użytkownika wysyła informacje, jakiego dokonał wyboru.
Żądania warunkowe Http pozwala na żądania warunkowe tj. przeglądarka umieszcza warunek w nagłówku w oparciu, o który generowana będzie odpowiedź. Przykładowe nagłówki HTTP używane dla żądań warunkowych: If-Match: używany dla sprawdzenia czy zasób serweraj est bieżącym zasobem If-Modified-Since: jeżeli żądany zasób nie był modyfikowany po podanej dacie nie będzie pobierany If-Range: używany dla sprawdzenia czy zasób ma częściową kopię dokonanych zmian
Buforowanie ( caching ) The goal is to reduce network traffic by eliminating unnecessary transfers. Requirements for performance, availability and disconnected operation require the ability to relax the goal of semantic transparency. The protocol requires that transparency be relaxed Only by an explicit protocol-level request Only with an explicit warning to the end-user when relaxed by cache or client There are various issues involved: Cache correctness Warnings Cache-control mechanism Explicit user agent warnings Exceptions Client controlled behavior
Caching Expiration Model Server-Specified Expiration Origin server provides an explicit expiration time in the future, indicating that the response may be used to satisfy subsequent requests. If the origin server wishes to force semantically transparent cache to validate every request it may assign an expiration time in the past. Heuristic expiration HTTP cache typically assign heuristic expiration times, employing algorithms that use other header values to estimate a plausible expiration time. Age Calculations
Caching.Validation Model When cache has a stale entry it would like to use as a response, it first has to check with the origin server to see if its cache entry is still usable. To prevent the overhead of retransmission the protocol supports the use of conditional methods concerned with cache validators Validators: Last-modified dates. Entity Tag Cache validators. Weak and strong validators.
Caching.Response Cacheability Unless specifically constrained by the cache control directive a caching system: May always store a successful response as a cache entry May return it without validation if it is fresh May return it after successful validation A response received with a status code of 200, 203, 206, 300, 301 or 410 may be stored by the cache and used in the reply to a subsequent request. User agents often have a history mechanism which is different from caches. History mechanism is meant to show exactly what the user saw at the time when the resource was retrieved. Expiration times don t apply to history mechanisms.
Authentication HTTP 1.1 provides the specification for authentication framework, the original Basic Authentication scheme and a scheme based on cryptographic hashes referred to as Digest Authentication Basic Authentication is based on the model that a client must authenticate itself with user-id and password for each realm. Digest Authentication like Basic is based on a simple challengeresponse paradigm, however the scheme challenges using a nonce value. Valid response contains a checksum (MD5 by default) of user-name, password, nonce value, HTTP method and requested URI
Authentication Digest nonce is a server specified data string which should be uniquely generated each time a 401(Authentication required) response is made. Recommended to use a base64 or hexadecimal data. Contents of the nonce are purely implementation dependent. Implementation might choose not to accept a previously used nonce or a previously used digest, in order to protect itself from a reply attack. Implementation might also choose to use one-time nonce or digest for POST or PUT requests and a time stamp for GET requests.
Authentication.Limitations Digest Authentication is a password based system and suffers from all the limitations of a password system. There is no secure way between the server and user to establish user s password. Only positive is that it is better than Basic Authentication scheme which sends the user-name and password in clear text.