pipelining

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.
5.
6.
Serwer HTTP wysyła pakiet żądający zamknięcia sesji
TCP. (TCP nie przerywa jednak połączenia dopóki klient
nie otrzyma komunikatu.)
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.
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. iso8859-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.