Protokół HTTP. Omówienie standardu z analizą ruchu sieciowego

Protokół HTTP Omówienie standardu z analizą ruchu sieciowego Spis treści: 1. Zagadnienia teoretyczne... 2 1.1. Informacje ogólne.... 2 1.2. Format zapytań i odpowiedzi, metody.... 2 1.3. Kody stanu.... 4 1.4. Nagłówek.... 7 1.5. Treść wiadomości.... 9 1.6. Klienci HTTP 1.1.... 9 1.7. Serwery HTTP 1.1... 11 2. Analiza ruchu sieciowego... 13 2.1. Wstęp... 13 2.2. Zapytania ARP... 14 2.3. Zapytania DNS... 15 2.4. Połączenia TCP.... 16 2.5. Żądanie i odpowiedź HTTP.... 17 3. Bibliografia.... 19

1. Zagadnienia teoretyczne 1.1. Informacje ogólne. HTTP (Hyper Transfer Protocol) jest protokołem odpowiedzialnym za przesyłanie w Internecie stron WWW. Portem zarezerwowanym dla HTTP jest 80 port TCP oraz rzadziej używane porty 8008 i 8080. Główną organizacją zajmującą się rozwojem i standaryzacją protokołu HTTP praz technologii związanych z WWW jest W3C (The World Wide Web Consortium). Aktualną wersją tego protokołu jest HTTP/1.1. HTTP jest wykorzystywany do przekazywania różnych zasobów, a nie tylko plików. Zasób jest jakimś fragmentem informacji, która może być zidentyfikowana przez adres URL. Najczęstszym rodzajem zasobów jest plik, ale może być to także dynamicznie generowany wynik kwerendy, wyjście skryptu CGI, dokument, który jest dostępny w kilku językach, czy coś innego. Podobnie jak większość protokołów sieciowych, HTTP używa modelu klientserwer: klient HTTP otwiera połączenie i wysyła komunikat żądania do serwera HTTP, serwer następnie zwraca komunikat odpowiedzi, zwykle zawierający zasób, o który został poproszony. Po dostarczeniu odpowiedzi, serwer zamyka połączenie i co najważniejsze nie przechowuje żadnych informacji o połączeniu między transakcjami. Pozwala to znacznie zmniejszyć obciążenie serwera, jednak jest kłopotliwe w sytuacji, gdy np. trzeba zapamiętać konkretny stan dla użytkownika, który wcześniej łączył się już z serwerem. Najczęstszym rozwiązaniem tego problemu jest wprowadzenie mechanizmu ciasteczek. Inne podejścia to m.in. sesje po stronie serwera, ukryte parametry (gdy aktualna strona zawiera formularz) oraz parametry umieszczone w URL-u (jak np. /index.php?userid=3). 1.2. Format zapytań i odpowiedzi, metody. Format zapytania i odpowiedzi są podobne. Oba rodzaje komunikatów składają się z: linia początkowa, zera lub większej liczby linii nagłówka, pustej linii (tj. samo CRLF), i opcjonalnie treści wiadomości (np. plik lub zapytanie o dane, czy o wyjście). Linia początkowa i nagłówki powinny się kończyć parą znaków CRLF. Protokół HTTP definiuje kilka metod (rodzajów działań), które zostaną wykonane na wywoływanym zasobie. Wyróżnia się następujące usługi (metody) protokołu HTTP: Metoda Opis DELETE Żądanie usunięcia zasobu (dokumentu) z serwera GET Żądanie zasobu od serwera w formie nagłówka i treści HEAD Żądanie zasobu od serwera w formie nagłówka LINK Żądanie ustanowienia relacji między istniejącymi zasobami OPTIONS Żądanie od serwera identyfikacji obsługiwanych metod POST Żądanie odebrania przez serwer danych od klienta PUT Żądanie odebrania przez serwer od klienta pliku TRACE Żądanie zwrócenia przez serwer nagłówków wiadomości wysłanej od klienta (w celach testowania) UNLINK Żądanie usunięcia relacji między istniejącymi zasobami

Dokładniejsze omówienie ważniejszych metod: Metoda HEAD Żądanie HEAD jest podobne do GET, z wyjątkiem tego że serwer jest proszony by zwrócić tylko nagłówki odpowiedzi, a nie rzeczywiste źródło (nie ma treści wiadomości). Jest to przydatne aby sprawdzić charakterystykę zasobu bez konieczności jego pobierania, oszczędzając w ten sposób przepustowość. Żądanie POST służy do wysyłania danych do serwera, aby następnie były przetwarzane w inny sposób np. przez skrypt CGI. Żądanie POST różni się od żądania GET tym, że wysyłany jest blok danych z parametrami w treści wiadomości. Zwykle są jeszcze dodatkowe nagłówki opisujące treść wiadomości, jak Content-Type: i Content-Length:. Żądanie URI nie jest zasobem do pobrania, jest to zazwyczaj program do obsługi wysyłanych danych. Odpowiedzią HTTP jest zwykle wyjście programu, a nie plik. Najczęstszym zastosowaniem procedury POST, jest przedstawienie danych HTML do skryptów CGI. W tym przypadku, Content-Type:, nagłówek jest zwykle w postaci: application/x-www-form-urlencoded i Content-Length:, nagłówek podaje długość zakodowanego adresu URL. Skrypt CGI otrzymuje treść wiadomości poprzez standardowe wejście i dekoduje. Oto typowe przesłanie formularzy, za pomocą POST: POST /path/script.cgi HTTP/1.0 From: frog@jmarshall.com User-Agent: HTTPTool/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 32 home=cosby&favorite+flavor=flies Początkowa linia żądania. Początkowa linia różni się od zwykłej prośby na odpowiedź. Ma ona trzy części oddzielone spacjami: nazwa metody, lokalna ścieżka do żądanego zasobu, używana wersja protokołu HTTP. Typowa linia żądania: GET / ścieżka / do / plik/ index.html/ 1.0 Początkowa linia odpowiedzi. Początkowa linia odpowiedzi, zwana linią statusu, również ma trzy części oddzielone spacjami: wersja HTTP, kod statusu odpowiedzi, który podaje wynik żądania i fraza opisująca kod statusu. Typowa linia statusu: HTTP/1.0 200 OK lub HTTP/1.0 404 Not Found Kod stanu odczytuje oprogramowanie, powód ma być czytelny dla człowieka.

1.3. Kody stanu. Ogólny podział kodów stanu w zależności od ich wartości. Wartość Rodzaj Rodzaj ang. Znaczenie 1xx Informacje Informational Żądanie odebrane, proces w trakcie wykonywania 2xx Sukces Success Akcja została poprawnie odebrana, zrozumiana i zaakceptowana 3xx Przekierowanie Redirection Dalsze akcje muszą zostać podjęte, aby zakończyć żądanie 4xx Błąd po stronie klienta Client Error Żądanie ma złą składnię lub nie może zostać spełnione 5xx Błąd serwera Server Error Serwer najprawdopodobniej nie może wykonać poprawnego żądania Opis kodów: Kody informacyjne kod opis słowny znaczenie/zwrócony zasób 100 Continue Kontynuuj - prośba o dalsze wysyłanie zapytania 101 Switching Protocols Zmiana protokołu 110 Connection Timed Out Kody powodzenia kod opis słowny 200 OK znaczenie/zwrócony zasób Zawartość żądanego dokumentu (najczęściej zwracany nagłówek odpowiedzi w komunikacji WWW Internetu) 201 Created Utworzono - wysłany dokument został zapisany na serwerze 202 Accepted 203 Non-Authoritative Information 204 No content 205 Reset Content 206 Partial Content Przyjęto - zapytanie zostało przyjęte do obsłużenia, lecz jego zrealizowanie jeszcze się nie skończyło Informacja nieautorytatywna - zwrócona informacja nie odpowiada dokładnie odpowiedzi pierwotnego serwera, lecz została utworzona z lokalnych bądź zewnętrznych kopii Brak zawartości - serwer zrealizował zapytanie klienta i nie potrzebuje zwracać żadnej treści Przywróć zawartość - serwer zrealizował zapytanie i klient powinien przywrócić pierwotny wygląd dokumentu Część zawartości - serwer zrealizował tylko część zapytania typu GET, odpowiedź musi zawierać nagłówek Range informujący o zakresie bajtowym zwróconego elementu

Kody przekierowania kod opis słowny 300 Multiple Choices 301 Moved Permanently 302 Found 303 See Other 304 Not Modified 305 Use Proxy znaczenie/zwrócony zasób Wiele możliwości - istnieje więcej niż jeden sposób obsłużenia danego zapytania, serwer może podać adres zasobu, który pozwala na wybór jednoznacznego zapytania spośród możliwych Trwale przeniesiony - żądany zasób zmienił swój URI i w przyszłości zasób powinien być szukany pod wskazanym nowym adresem Znaleziono - żądany zasób jest chwilowo dostępny pod innym adresem a przyszłe odwołania do zasobu powinny być kierowane pod adres pierwotny Zobacz inne - odpowiedź na żądanie znajduje się pod innym URI i tam klient powinien się skierować. To jest właściwy sposób przekierowywania w odpowiedzi na żądanie metodą POST. Nie zmieniono - zawartość zasobu nie podległa zmianie według warunku przekazanego przez klienta (np. data ostatniej wersji zasobu pobranej przez klienta - cache przeglądarki) Użyj serwera proxy - do żądanego zasobu trzeba odwołać się przez serwer proxy podany w nagłówku Location odpowiedzi 306 Kod nieużywany, aczkolwiek zastrzeżony dla starszych wersji protokołu 307 Temporary Redirect Tymczasowe przekierowanie - żądany zasób znajduje się chwilowo pod innym adresem URI, odpowiedź powinna zawierać zmieniony adres zasobu, na który klient zobowiązany jest się przenieść Opis poszczególnych kodów błędów: kod opis słowny 400 Bad Request 401 Unauthorized 402 Payment Required 403 Forbidden 404 Not Found 405 Method Not Allowed 406 Not Acceptable 407 Proxy Authentication znaczenie/zwrócony zasób Nieprawidłowe zapytanie - żądanie nie może być obsłużone przez serwer z powodu błędnej składni zapytania Nieautoryzowany dostęp - żądanie zasobu, który wymaga uwierzytelnienia Wymagana opłata - odpowiedź zarezerwowana na przyszłość Zabroniony - serwer zrozumiał zapytanie lecz konfiguracja bezpieczeństwa zabrania mu zwrócić żądany zasób Nie znaleziono - serwer nie odnalazł zasobu według podanego URI ani niczego co by wskazywało na istnienie takiego zasobu w przeszłości Niedozwolona metoda - metoda zawarta w żądaniu nie jest dozwolona dla wskazanego zasobu, odpowiedź zawiera też listę dozwolonych metod Niedozwolone - zażądany zasób nie jest w stanie zwrócić odpowiedzi mogącej być obsłużonej przez klienta według informacji podanych w zapytaniu Wymagane uwierzytelnienie do serwera proxy - analogicznie do kodu 401, dotyczy dostępu do serwera proxy

kod opis słowny Required 408 Request Timeout 409 Conflict 410 Gone 411 Length required 412 Precondition Failed 413 414 Request Entity Too Large Request-URI Too Long 415 Unsupported Media Type 416 Requested Range Not Satisfiable 417 Expectation Failed znaczenie/zwrócony zasób Koniec czasu oczekiwania na żądanie - klient nie przesłał zapytania do serwera w określonym czasie Konflikt - żądanie nie może być zrealizowane, ponieważ występuje konflikt z obecnym statusem zasobu, ten kod odpowiedzi jest zwracany tylko w przypadku podejrzewania przez serwer, że klient może nie znaleźć przyczyny błędu i przesłać prawidłowego zapytania Zniknął (usunięto) - zażądany zasób nie jest dłużej dostępny i nie znany jest jego ewentualny nowy adres URI; klient powinien już więcej nie odwoływać się do tego zasobu Wymagana długość - serwer odmawia zrealizowania zapytania ze względu na brak nagłówka Content-Length w zapytaniu; klient może powtórzyć zapytanie dodając doń poprawny nagłówek długości Warunek wstępny nie może być spełniony - serwer nie może spełnić przynajmniej jednego z warunków zawartych w zapytaniu Encja zapytania zbyt długa - całkowita długość zapytania jest zbyt długa dla serwera Adres URI zapytania zbyt długi - długość zażądanego URI jest większa niż maksymalna oczekiwana przez serwer Nieznany sposób żądania - serwer odmawia przyjęcia zapytania, ponieważ jego składnia jest niezrozumiała dla serwera Zakres bajtowy podany w zapytaniu nie do obsłużenia - klient podał w zapytaniu zakres, który nie może być zastosowany do wskazanego zasobu Oczekiwana wartość nie do zwrócenia - oczekiwanie podane w nagłówku Expect żądania nie może być spełnione przez serwer lub - jeśli zapytanie realizuje serwer proxy - serwer ma dowód, że oczekiwanie nie będzie spełnione przez następny w łańcuchu serwer realizujący zapytanie Kody błędu wewnętrznego kod opis słowny 500 Internal Server Error 501 Not Implemented 502 Bad Gateway 503 Service Unavailable znaczenie/zwrócony zasób Wewnętrzny błąd serwera - serwer napotkał niespodziewane trudności, które uniemożliwiły zrealizowanie żądania Nie zaimplementowano - serwer nie dysponuje funkcjonalnością wymaganą w zapytaniu; ten kod jest zwracany gdy serwer otrzymał nieznany typ zapytania Błąd bramy - serwer - spełniający rolę bramy lub proxy - otrzymał niepoprawną odpowiedź od serwera nadrzędnego i nie jest w stanie zrealizować żądania klienta Usługa niedostępna - serwer nie jest w stanie w danej chwili zrealizować zapytania klienta ze względu na przeciążenie 504 Gateway Przekroczony czas bramy - serwer - spełniający rolę bramy lub proxy -

kod opis słowny 505 Timeout HTTP Version Not Supported znaczenie/zwrócony zasób nie otrzymał w ustalonym czasie odpowiedzi od wskazanego serwera HTTP, FTP, LDAP itp. lub serwer DNS jest potrzebny do obsłużenia zapytania Wersja HTTP nie obsługiwana - serwer nie obsługuje bądź odmawia obsługi wskazanej przez klienta wersji HTTP 1.4. Nagłówek. Linie nagłówka Linie nagłówka dostarczają informacji na temat żądania lub odpowiedzi, albo o obiekcie wysłanym w treści wiadomości. Linie nagłówka są w zwykłym formacie tekstowym, takim samym jak te używane do wiadomości e-mail. Forma: nagłówek-nazwa: wartość, zakończone parą znaków CRLF. Szczegóły o RFC 822 linii nagłówka: Jak wspomniano wcześniej, powinny one zakończyć przez CRLF, ale powinny również poprawnie poradzić sobie z LF. W nazwie nagłówka nie jest rozróżniana wielkość liter Pomiędzy znakiem : i wartością może być dowolna liczba spacji i tabulacji. Linie nagłówka rozpoczynające się od spacji lub tabulacji są w rzeczywistości częścią poprzedniej linii nagłówka, przenoszone do następnej linii w celu łatwiejszego odczytywania. Zatem, poniższe nagłówki są równoważne: Header1: jakaś-wartość1a. jakaś-wartość1b Header2: jakaś-wartość1a, jakaś-wartość1b HTTP 1.0 definiuje 16 nagłówków, choć żaden nie jest wymagany. HTTP 1.1 definiuje 46 nagłówków, i jeden (Host: ) jest wymagany w żądaniach. Biorąc pod uwagę NET etykietę należy rozważyć włączenie tych nagłówków do swoich żądań: From: Nagłówek zawiera adres e-mail, tego kto wysłał żądanie lub uruchomił program. (Musi zostać skonfigurowany przez użytkownika, na rzecz ochrony prywatności). User-Agent: nagłówek identyfikuje program, który wykonał żądanie w formie Programname/x.xx, gdzie xxx jest alfanumeryczną wersją programu. Te nagłówki mogą pomóc webmasterom rozwiązywać problemy. One również ujawniają informację na temat użytkownika. Kiedy się zdecydujemy na załączenie któregoś nagłówka, trzeba zastanowić się czy ważniejsza jest potrzeba rejestrowania informacji przez webmasterów, czy własna prywatność. W przypadku serwerów, można rozważyć włączanie tych nagłówków do odpowiedzi: Server: Nagłówek jest analogiczny do User-agent: nagłówek identyfikuje oprogramowanie serwera w postaci Program-name/x.xx. Np. pewna wersja serwera Apache zwraca Server: Apache/1.2b3-dev. Last-Modified: nagłówek zawiera datę modyfikacji zasobu, który jest zwracany. Ma zastosowanie w buforowaniu i innych działań zmierzających do energooszczędności. Pole to powinno mieć postać: Last-Modified: Fri, 31 Dec 1999 23:59:59 GMT

Najczęściej używane nagłówki ze strony hosta: Host: host.com (wymagany w HTTP 1.1 nagłówek Host służący do rozpoznania hosta, jeśli serwer na jednym IP obsługuje kilka VirtualHostów) User-Agent: Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 (nazwa aplikacji klienckiej) Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8 (akceptowane (bądź nieakceptowane dla q=0) przez klienta typy plików) Accept-Language: pl,en-us;q=0.7,en;q=0.3 (preferowany język strony nagłówek przydatny przy Language negotiation) Accept-Charset: ISO-8859-2,utf-8;q=0.7,*;q=0.7 (preferowane kodowanie znaków) Keep-Alive: 300 (czas, jaki klient chce zarezerwować do następnego zapytania w przypadku połączenia Keep-Alive) Connection: keep-alive (chęć nawiązania połączenia stałego Keep-Alive z serwerem HTTP/1.0) HTTP/1.1 dopuszcza wysłanie kilku żądań naraz (pipelining). HTTP/1.0 zakłada jedno żądanie i jedną odpowiedź. Najczęściej używane nagłówki ze strony serwera: Date: Thu, 20 Dec 2001 12:04:30 GMT (czas serwera) Server: Apache/2.0.50 (Unix) DAV/2 (opis aplikacji serwera) Set-Cookie: PSID=d6dd02e9957fb162d2385ca6f2829a73; path=/ (nakazanie klientowi zapisania ciasteczka) Expires: Thu, 19 Nov 1981 08:52:00 GMT (czas wygaśnięcia zawartości zwróconego dokumentu. Data w przeszłości zabrania umieszczenie dokumentu w pamięci podręcznej. Jest to stara metoda zastąpiona przez Cache-Control) Cache-Control: no-store, no-cache, must-revalidate (no-store zabrania przechowywania dokumentu na dysku, nawet gdy nie jest to pamięć podręczna. must-revalidate nakazuje bezwzględnie stosować się do wytycznych i sprawdzić świeżość dokumentu za każdym razem) Pragma: no-cache (informacje dotyczące zapisywania zawartości w pamięci podręcznej. Stara, niestandardowa metoda.) Keep-Alive: timeout=15, max=100 Connection: Keep-Alive (akceptacja połączenia Keep-Alive dla klientów HTTP/1.0) Transfer-Encoding: chunked (typ kodowania zawartości stosowanej przez serwer) Content-Type: application/xhtml+xml; charset=utf-8 (typ MIME i strona kodowa zwróconego dokumentu) HTTP do obsługi połączeń Keep-Alive wymaga, aby odpowiedź od serwera miała znaną długość (przez podanie Content-Length lub użycie Transfer-Encoding: chunked). W przeciwnym wypadku koniec odpowiedzi sygnalizuje zerwanie połączenia i Keep-Alive nie może działać. Nagłówek Keep-Alive jest rozszerzeniem HTTP/1.0. W HTTP/1.1 ten nagłówek nie jest potrzebny, gdyż połączenia Keep-Alive są domyślne (zachowanie zmienia Connection: close).

1.5. Treść wiadomości. Wiadomość HTTP może mieć treść wysyłanych danych po liniach nagłówka. W odpowiedzi zwracany jest żądany zasób do klienta (najczęściej użycie treści wiadomości), albo tekst wyjaśniający czy jest błąd. W żądaniu znajdują się wprowadzone dane przez użytkownika lub pliki przesyłane do serwera. Jeśli komunikat HTTP zawiera treść, to w wiadomości znajdują się zazwyczaj linie nagłówka opisującej treść. W szczególności: Content-Type: nagłówek dostarcza typ danych MIME w wiadomości takich jak text/html lub image/gif. Content-Length: nagłówek podaje liczbę bajtów w treści. Przykładowa wymiana HTTP Aby pobrać plik w adresie URL http://www.somehost.com/path/file.html Najpierw należy otworzyć gniazdo (socked) do hosta www.somehost.com, port 80 (w tym przypadku należy użyć domyślnego portu 80, ponieważ nie został podany w adresie URL). Następnie wysyłamy do gniazda następującą treść: GET /path/file.html HTTP/1.0 From: someuser@jmarshall.com User-Agent: HTTPTool/1.0 [pusta linia] Serwer powinien odpowiedzieć za pośrednictwem tego samego gniazda, coś takiego: HTTP/1.0 200 OK Date: Fri, 31 Dec 1999 23:59:59 GMT Content-Type: text/html Content-Length: 1354 <html> <body> <h1>napis html</h1> (więcej zawartości pliku)... </body> </html> Po wysłaniu odpowiedzi, serwer zamyka gniazdo. 1.6. Klienci HTTP 1.1. HOST: nagłówek Począwszy od HTTP 1.1, jeden serwer na jeden adres IP może być wieloadresowym, czyli na jednym serwerze może być kilka domen. Np. www.host1.pl i www.host2.pl może znajdować się na tym samym serwerze.

Kilka domen znajdujących się na tym samym serwerze jest jak kilka osób dzielących ten sam telefon: dzwoniący wie do kogo dzwoni, ale nie wiadomo kto odpowie. Dlatego każde żądanie HTTP musi określać nazwę hosta (i ewentualnie port) do którego jest przeznaczone. Kompletne żądanie HTTP musi wyglądać tak: GET /ścieżka/plik.html HTTP/1.1 Host: www.host1.com:80 [Pusta linia tutaj] Z wyjątkiem : 80 - nie jest wymagane, ponieważ jest to domyślny port HTTP. Host: - jest wymagane tylko w nagłówku HTTP 1.1. Jest to także najbardziej potrzebna nowa funkcja HTTP 1.1. Bez niej każda nazwa hosta wymagałaby unikalnego adresu IP, a nam szybko by zabrakło adresów IP z powodu eksplozji nowych domen. Fragmentacja kodowanego transferu. Jeśli serwer chce zacząć wysyłać odpowiedź nie znając wcześniej jej długości całkowitej (jak w długim wyjściu skryptu), to może użyć prostego pakietowego kodowanego transferu, który rozbija całkowitą odpowiedź na mniejsze kawałki i wysyła je szeregowo. Można zidentyfikować taką reakcję, ponieważ zawiera nagłówek Transfer-Encoding: chunked. Wszyscy klienci HTTP 1.1 muszą mieć możliwość odbierania pofragmentowanej wiadomości. Pofragmentowana treść wiadomości zawiera szereg kawałków, po tym linię z zerem, a następnie opcjonalne stopki i linię pustą. Każdy fragment składa się z dwóch części: Linia z rozmiarem fragmentu danych (szesnastkowo) po nim średnik i dodatkowe parametry które można zignorować (żaden nie jest obecnie standardem), a kończąc na CRLF. Dane, a następnie CRLF Tak pofragmentowana odpowiedź może wyglądać następująco: HTTP/1.1 200 OK Date: Fri, 31 Dec 1999 23:59:59 GMT Content-Type: text/plain Transfer-Encoding: chunked 1a; ignore-stuff-here abcdefghijklmnopqrstuvwxyz 10 1234567890abcdef 0 some-footer: some-value another-footer: another-value [pusta linia] Fragmenty mogą zawierać dowolne dane binarne i mogą być znacznie większe niż powyższy przykład. Parametr określający rozmiar linii jest rzadko używany, ale trzeba przynajmniej wiedzieć jak go poprawnie ignorować. Stopki są również rzadko używane, ale mogą być przydatne do takich rzeczy jak sumy kontrolne czy podpisy cyfrowe.

Stałe połączenia i nagłówek Connection: close. W HTTP 1.0 i wcześniej połączenia TCP są zamykane po każdym żądaniu i odpowiedzi, więc każdy zasób do pobrania wymaga własnego połączenia. Otwieranie i zamykanie połączeń TCP zajmuje znaczną ilość czasu procesora, przepustowości i pamięci. W praktyce większość stron internetowych składa się z kilku plików na tym serwerze, zatem można dużo zaoszczędzić wysyłając kilka zapytań i odpowiedzi za pomocą jednego trwałego połączenia. Stałe połączenia są domyślnie w HTTP 1.1. Wystarczy otworzyć połączenie i wysłać kilka żądań szeregowo (potokowo) i przeczytać odpowiedzi w tej samej kolejności, co zostały wysłane. Jeśli nagłówek klienta zawiera Connection: close, to połączenie zostanie zamknięte po odpowiedniej odpowiedzi. Należy tego użyć jeżeli nie obsługujemy stałego połączenia, albo jeśli odpowiedź będzie ostatnią w trakcie połączenia. Podobnie, jeśli odpowiedź zawiera ten nagłówek, serwer zamyka połączenie po tej odpowiedzi, a klient nie powinien wysyłać więcej żadnych żądań za pośrednictwem tego połączenia. Odpowiedź 100 continue W trakcie, gdy klient HTTP 1.1 wysyła żądanie do serwera, serwer może odpowiadać tymczasowo 100 Continue. Oznacza to, że serwer otrzymał pierwszą część żądania i może być to wykorzystane do wspomagania komunikacji na powolnych łączach. Odpowiedź 100 continue jest skonstruowana jak każda odpowiedź w HTTP, tzn. składa się z linii statusu, nagłówków opcjonalnych i linii pustej. W przeciwieństwie do innych odpowiedzi, występuje ona zawsze po innej kompletnej, ostatniej odpowiedzi. W przykładzie pełne dane, które pochodzą z serwera mogą składać się z dwóch odpowiedzi w serii, jak: HTTP/1.1 100 Continue HTTP/1.1 200 OK Date: Fri, 31 Dec 1999 23:59:59 GMT Content-Type: text/plain Content-Length: 42 some-footer: some-value another-footer: another-value abcdefghijklmnoprstuvwxyz1234567890abcdef Aby sobie z tym poradzić, prosty klient HTTP 1.1 może odczytać jedną odpowiedź z gniazda, jeśli kod stanu jest 100 odrzucić pierwszą odpowiedź i przeczytać następną 1.7. Serwery HTTP 1.1 Wymaganie nagłówka Host:. Ze względu na pilność realizacji nowego nagłówka Host:, serwerom nie wolno tolerować żądań HTTP 1.1 bez niego. Jeśli serwer otrzyma takie żądanie, musi zwrócić odpowiedź 400 Bad Request, jak w przykładzie: HTTP/1.1 400 Bad Request Content-Type: text/html Content-Length: 111

<html><body> <h2>no Host: header received</h2> HTTP 1.1 requests must include the Host: header. </body></html> Wymóg ten odnosi się tylko do klientów korzystających z protokołu HTTP 1.1, a nie każdej przyszłej wersji. Jeśli żądanie HTTP używa wersji późniejszej niż 1.1, serwer może przyjąć bezwzględną ścieżkę URL zamiast nagłówka Host:. Jeżeli żądanie korzysta z HTTP 1.0, serwer może przyjąć żądanie bez identyfikacji hosta. Akceptowanie absolutnych URL Host: Nagłówek jest rzeczywiście tymczasowym rozwiązaniem problemu identyfikacji hosta. W przyszłych wersjach HTTP, żądania będą używać bezwzględnych adresów URL zamiast ścieżki, jak: GET http://www.somehost.com/path/file.html HTTP/1.2 Aby umożliwić to przejście protokołu, serwery HTTP 1.1 muszą zaakceptować tą formę żądań, choć klienci HTTP 1.1 nie będą ich wysyłać. Serwer musi jeszcze zgłosić błąd jeśli klient HTTP 1.1 opuści nagłówek Host:. Fragmentacja kodowanego transferu. Podobnie jak w HTTP 1.1 klienci muszą akceptować fragmentowanie pakietowe odpowiedzi, serwery muszą przyjąć żądania. Serwery nie są potrzebne do wygenerowania pofragmentowanej wiadomości, po prostu muszą być w stanie je przyjąć. Stałe połączenia i nagłówek Connection: close. Jeśli klient HTTP 1.1 wysyła wiele żądań za pośrednictwem jednego połączenia, serwer powinien wysyłać odpowiedzi z powrotem w tej samej kolejności, co żądania to wszystko na serwerze ma na celu wspieranie stałych połączeń. Jeżeli żądanie zawiera nagłówek Connection: close, to wtedy żądanie jest ostanie w połączeniu i serwer powinien zakończyć połączenie po wysłaniu odpowiedzi. Ponadto serwer powinien zamknąć bezczynne połączenie po pewnym zadanym czasie (np. 10 sekund). Jeśli nie chcemy wspierać stałych połączeń, należy dołączyć nagłówek Connection: close w odpowiedzi. Używa się tego nagłówka, gdy chcemy zamknąć połączenie, nawet jeśli nie wszystkie żądania zostały spełnione. Nagłówek mówi, że połączenie zostanie zamknięte po bieżącej odpowiedzi, a ważny klient HTTP 1.1 będzie obsługiwać ją prawidłowo. Korzystanie z odpowiedzi 100 continue Jak opisano w rozdziale 1.6, ta odpowiedź istnieje, aby uporać się z problemem powolnych łączy. Kiedy serwer HTTP 1.1 otrzyma pierwszą linię HTTP 1.1 żądania, musi odpowiedzieć albo 100 continue lub błędem. Jeśli wysyła odpowiedź 100 continue należy również wysłać kolejną, ostateczną odpowiedź, że żądanie zostało raz przetworzone. Odpowiedź 100 continue nie wymaga nagłówków, ale zwykle musi być po nich linia pusta. Przykład: HTTP/1.1 100 Continue [pusta linia] [tutaj trafi inna odpowiedź HTTP] Nagłówek Date:. Pamięć podręczna jest znaczącym osiągnięciem w HTTP 1.1, i nie może pracować bez odpowiedzi Date. Serwery muszą odpowiadać nagłówkiem Date: zawierającym aktualny czas w formie:

Date: Fri, 31 Dec 1999 23:59:59 GMT Wszystkie odpowiedzi z wyjątkiem tych z 100 poziomu statusu (ale łącznie z błędem) muszą zawierać nagłówek Date:. Wszystkie wartości czasu w HTTP wykorzystują czas Greenwich. Rozpatrywanie żądań o nagłówki If-modified-Since: lub If-Unmodified-Since:. Aby uniknąć wysyłania zasobów, które nie muszą być wysłane, HTTP 1.1 definiuje nagłówki żądań If-modified-Since: i If-Unmodified-Since:. Pierwszy mówi żeby wysyłać tylko te zasoby, u których nastąpiła zmiana od określonego czasu, drugi mówi na odwrót. Klienci nie są zobowiązani do ich używania, ale serwery HTTP 1.1 wymagają honorowania żądań, które używają tych nagłówków ze znacznikami czasu. Niestety, z powodu wcześniejszych wersji HTTP, wartość daty może być w jednym z trzech formatów: If-Modified-Since: Fri, 31 Dec 1999 23:59:59 GMT If-Modified-Since: Friday, 31-Dec-99 23:59:59 GMT If-Modified-Since: Fri Dec 31 23:59:59 1999 Chociaż serwery muszą zaakceptować wszystkie trzy formaty daty protokołu HTTP 1.1, klienci i serwery muszą generować tylko pierwszy rodzaj. If-Modified-Since: nagłówek jest używany przez metodę GET. Jeżeli żądany zasób został zmodyfikowany od podanej daty to nagłówek zostaje zignorowany następuje powrót do zasobów. W przeciwnym razie zwróci 304 Not Modified włączając nagłówek Date: bez treści wiadomości, jak w przykładzie: HTTP/1.1 304 Not Modified Date: Fri, 31 Dec 1999 23:59:59 GMT [pusta linia] If-Unmodified-Since: Nagłówek jest podobny, ale może być używany z dowolną metodą. Jeśli żądany zasób nie został zmodyfikowany od danej daty, ignoruje nagłówek i powraca do zasobu tak jak zwykle. W przeciwnym razie zwróci odpowiedź 412 Precondition Failed, jak w przykładzie: HTTP/1.1 412 Precondition Failed [pusta linia] 2. Analiza ruchu sieciowego 2.1. Wstęp W pierwszym etapie przeanalizowaliśmy ruch sieciowy wykonując połączenie z serwerem www.openbsd.org przez omawiany protokół HTTP na domyślny port 80 korzystając z programu telnet: [root@virtuallinux Adrian]# telnet www.openbsd.org 80 Trying 142.244.12.42... Connected to www.openbsd.org. Escape character is '^]'.

Connection closed by foreign host. Jak widać połączenie zostało zakończone z powodu zbyt długiego czasu bezczynności. Sprawdźmy, zatem jaki wygenerowało ono ruch sieciowy. 2.2. Zapytania ARP Na powyższym screenie z programu o nazwie Wireshark, widzimy, że pierwszą czynnością było ustalenie adresu MAC routera za pomocą zapytania ARP na rozgłoszeniowy adres MAC. Przy okazji zauważamy, że w naszej sieci wysyłane są ramki typu DIX i odczytujemy producentów kart sieciowych. Gdy już obie maszyny znają swoje wzajemne adresy fizyczne przechodzimy do kolejnego etapu.

2.3. Zapytania DNS Na powyższym obrazie zauważamy, że adres IP serwera, z którym próbujemy się połączyć nie jest znany w systemie, gdyż nie ma go w pliku host. Dlatego resolver wysłał zapytanie DNS o adres IP v4 do serwera nazw o adresie IP 195.13.38.3. Usługa DNS korzysta z protokołu transportowego UDP. Zapytanie wysyłane jest na port 53.

Otrzymujemy odpowiedź, że nazwie www.openbsd.org przypisany jest adres IPv4: 142.244.12.42. Przy okazji widzimy serwery autorytatywne dla tej domeny. Teraz będziemy mogli już wymieniać informacje z serwerem. 2.4. Połączenia TCP. Zauważamy, że pierwszą wymienioną informacją przez protokół TCP jest wysłany pakiet z flagą SYN synchronizującą na port 80. Serwer odebrał połączenie wysyłając pakiet z ustawionymi flagami SYN i ACK - potwierdzenie. Nasz komputer wysłał następnie pakiet potwierdzający z jedna flagą ACK. Po nim rozpoczyna się właściwa transmisja. Z powodu naszej bezczynności serwer zainicjował zakończenie połączenia wysyłając pakiet z flagą FIN. Klient i serwer uzgadniają wtedy przed zamknięciem wysyłając sobie komunikaty ustawiając flagi ACK i FIN. Kiedy połączenie TCP ma być zamknięte, przesyłany jest znacznik FIN, nie powoduje to natychmiastowego rozłączenia. Znacznik przesłany przez obie strony, jako sygnał zgody na zakończenie komunikacji. Gdyby jeden z uczestników komunikacji zakończył połączenie nie informując drugiego, tamten mógłby w nieskończoność podejmować próby retransmisji danych, które nigdy nie zostałby odebrane. Zamykanie sesji zostało zrealizowane poprzez wysłanie czterech takich pakietów.

2.5. Żądanie i odpowiedź HTTP. W celu przeprowadzenia transmisji pliku z serwera HTTP, wpisaliśmy w programie telnet: [root@virtuallinux Adrian]# telnet www.openbsd.org 80 Trying 142.244.12.42... Connected to www.openbsd.org. Escape character is '^]'. GET / HTTP/1.1 Host: www.openbsd.org HTTP/1.1 200 OK Date: Wed, 06 Jun 2012 01:12:35 GMT Server: Apache Last-Modified: Tue, 05 Jun 2012 22:52:37 GMT ETag: "470a222b7ea294186a53c01e4bf23026313ffebf" Accept-Ranges: bytes Content-Length: 5707 Content-Type: text/html <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title>openbsd</title> <meta name="resource-type" content="document"> <meta http-equiv="content-type" content="text/html; charset=iso-8859-1"> <meta name="description" content="the main OpenBSD page"> <meta name="keywords" content="openbsd,main"> <meta name="distribution" content="global"> <meta name="copyright" content="this document copyright 1999-2012 by OpenBSD."> <link rel="shortcut icon" HREF="/favicon.ico" TYPE="image/x-icon"> </head> <body text="#000000" bgcolor="#ffffff" topmargin=0 leftmargin=0 marginheight=0 marginwidth=0> (...) Otrzymaliśmy w ten sposób zawartość strony internetowej.

W Wiresharku z kolei widzimy wysłane przez nas żądanie HTTP, zgadza się z tym, co wpisaliśmy do programu telnet. Żądaliśmy głównego zasobu protokołem HTTP w wersji 1.1, podając nazwę hosta i pustą linię na koniec. W odpowiedzi dostaliśmy potwierdzenie z komunikatem nr 200. Co oznacza że wszystko przebiegło pomyślnie. Cały transfer zmieścił się w 5 pakietach. Widzimy nagłówek

wiadomości, możemy z niego odczytać np. że połączyliśmy się z serwerem Apache. W treści wiadomości mamy widoczną całą zawartość trony internetowej. Co świadczy o jawności przesyłanych danych, bez jakiegokolwiek szyfrowania. 3. Bibliografia. [1] RFC 2616 http://www.w3.org/protocols/rfc2616/rfc2616.txt [2] http://jmarshall.com/easy/http/ [3] Krysiak Karol, Sieci komputerowe. Kompendium., Helion, wydanie II. [4] http://pl.wikipedia.org/wiki/hypertext_transfer_protocol