HTTP

    Dla wielu z nas nie ma żadnego znaczenia, w jaki sposób przeglądarka WWW porozumiewa się z serwerem - najważniejsze, że na ekranie pojawiają się kolorowe strony. Jednak odrobina wiedzy na temat procesów zachodzących za kulisami może okazać się interesująca nie tylko dla programistów.

Jedną z podstaw światowej pajęczyny World Wide Web jest Hypertext Transfer Protocol (w skrócie HTTP). Protokół HTTP definiuje sposób komunikacji pomiędzy przeglądarkami i serwerami WWW oraz troszczy się o to, by dokumenty HTML, grafiki, aplety Javy, kontrolki ActiveX i inne elementy WWW zostały poprawnie przedstawione na ekranie. Proces wymiany danych zawsze inicjowany jest przez przeglądarkę, która zestawia połączenie z wybranym serwerem, a następnie wysyła do niego tzw. zapytanie HTTP. Serwer analizuje zapytanie i przez zestawione uprzednio połączenie wysyła odpowiedź HTTP. Odpowiedzią taką może być dokument HTML żądany przez przeglądarkę lub na przykład plik graficzny.

HTTP korzysta z portu nr 80.

Wszystko zaczyna się od URL-a
Aby nawiązać połączenie z serwerem, przeglądarka musi znać URL (Uniform Resource Locator), który jednoznacznie określa lokalizację interesującego nas zasobu w Internecie. Zasobem takim może być dokument HTML udostępniany przez serwer HTTP, jak i plik na serwerze FTP czy artykuł przechowywany na serwerze grup dyskusyjnych.
Po otrzymaniu URL-a o postaci http://www.hakier.com/index.htm przeglądarka dzieli go na części składowe (patrz ramka Elementy URL-a): po oznaczeniu protokołu http:// znajduje się nazwa serwera, a następnie ścieżka i nazwa dokumentu do pobrania.
W pierwszej kolejności przeglądarka analizuje część URL-a zawierającą nazwę serwera, ponieważ na jej podstawie musi ona określić adres IP, niezbędny do nawiązania połączenia z serwerem. Do tego celu przeglądarka wykorzystuje "Domain Name System" - rozproszoną bazę danych zawierającą nazwy wszystkich serwerów pracujących w Internecie wraz z ich adresami IP (patrz artykuł). Jeśli adres serwera od razu podany jest w postaci IP, tak jak na przykład w przypadku niektórych mało eleganckich ofert (np.http://192.221.125.213/doitnow.htm), przeglądarka nie musi tracić czasu na konwersję nazwy serwera na jego adres IP. Po ustaleniu adresu i skontaktowaniu się z serwerem przeglądarka tworzy tzw. połączenie TCP. Połączenie to działa jak bezpieczny kanał transmisyjny, który sam dba o integralność przesyłanych informacji i w razie wątpliwości co do poprawności transmisji zleca powtórzenie pojedynczych pakietów. Dzięki temu przeglądarka nie musi kontrolować transmisji danych.

Zapytania i odpowiedzi
Zaraz po utworzeniu połączenia TCP pomiędzy przeglądarką i serwerem rozpoczyna się komunikacja oparta na protokole HTTP. Przeglądarka jako klient wysyła tak zwane zapytania HTTP (request), na które serwer reaguje odpowiedziami (response). Przykład takiej wymiany zapytań i odpowiedzi został przedstawiony na rysunku poniżej.

"Rozmowa" pomiędzy przeglądarką i serwerem nie ogranicza się jedynie do zwrotów "wyślij mi stronę" i "już wysyłam". Serwer WWW dowiaduje się między innymi, jak nazywa się Twój komputer i jakiej przeglądarki używasz.

Podobnie jak typowy list biznesowy ma nagłówek z adresem i tematem, zapytania i odpowiedzi HTTP rozpoczynają się nagłówkiem (ang. header). Nagłówek określa rodzaj przesyłanych informacji, a dopiero po nim następują właściwe dane, np. treść dokumentu HTML.
W nagłówku zapytania i odpowiedzi dozwolone są jedynie znaki ASCII z przedziału od 32 do 127, co oznacza, że nie mogą się tam znaleźć litery charakterystyczne dla polskiego alfabetu. Ograniczenie to nie dotyczy jednak danych użytecznych, co znacznie upraszcza przesyłanie zbiorów binarnych, takich jak grafiki i aplety Javy. Dzięki temu przeglądarka i serwer nie muszą przeprowadzać czasochłonnej konwersji z 8 do 6 bitów, tak jak to się dzieje w przypadku protokołów pocztowych POP3 i SMTP. Ponadto konwersja taka niepotrzebnie zwiększałaby objętość danych.
Ponieważ nagłówek zapytania i odpowiedzi HTTP bazuje na tekstowych znakach ASCII, możliwe jest ręczne sterowanie serwerem HTTP. Do tego celu możemy zastosować klasyczne narzędzie internetowe, jakim jest klient telnetowy standardowo dostępny w Windows 95, pozwalający wydawać komendy z linii poleceń. Osoba dobrze znająca budowę nagłówków zapytań i odpowiedzi HTTP może z powodzeniem zasymulować pracę przeglądarki, co często wykorzystywane jest przez webmasterów podczas wykrywania błędów i diagnostyki pracy serwera WWW.
Aby połączyć się z serwerem HTTP, musimy znać nie tylko jego adres IP, ale również numer portu, na którym serwer oczekuje na zapytania HTTP. Porty pozwalają rozróżnić poszczególne protokoły działające na jednym komputerze (pod jednym adresem IP), na przykład FTP służący do przesyłania plików i HTTP do surfowania po sieci. HTTP standardowo zajmuje port 80, jednak numer wykorzystywanego portu może zostać zmieniony. Zmiana numeru portu jest powszechnie stosowanym zabezpieczeniem przed nieproszonymi gośćmi, ponieważ przeglądarka (lub użytkownik) musi wiedzieć, na który port należy kierować zapytania do serwera.

Zapytanie HTTP
W zapytaniu HTTP decydującą rolę odgrywa pierwsza linia. W niej klient HTTP określa, jakie działania ma wykonać serwer. Najczęściej chodzi tutaj o załadowanie dokumentu HTML - działanie uruchamiane poleceniem GET. Następnie podawana jest ścieżka dostępu i nazwa dokumentu do pobrania z danej lokalizacji. Aby mieć pewność, że przeglądarka i serwer będą "rozmawiać" w tym samym języku, do pierwszej linii zapytania dodawane jest jeszcze oznaczenie wersji używanego protokołu. Przykładowy nagłówek może rozpoczynać się linią GET /default.htm HTTP/1.0 Oprócz poznanej już komendy GET protokół HTTP zawiera inne polecenia, które nie są jednak tak często używane i obsługiwane przez wszystkie serwery WWW. Poniżej podajemy krótki przegląd poleceń HTTP:

POST wysyła zawartość formularza HTML do serwera. Stanowi to podstawę interaktywnych aplikacji WWW.

PUT wysyła do serwera dokument, który serwer zapisuje na swoim dysku lokalnym. Ponieważ niewłaściwe użycie tego rozkazu może zakłócić poprawną pracę serwera, najczęściej nie jest on obsługiwany przez serwery.

DELETE kasuje dokument na serwerze. Również to polecenie ze względów bezpieczeństwa ignorowane jest przez większość serwerów lub kwitowane komunikatem o błędzie.

Odpowiedź HTTP
Serwer, po przyjęciu i przeanalizowaniu zapytania, generuje odpowiedź, której struktura jest podobna do struktury zapytania. W pierwszej linii serwer podaje, w której wersji protokołu HTTP została utworzona odpowiedź, aby klient mógł ją poprawnie odczytać. Po tej informacji następuje trzycyfrowy kod statusu odpowiedzi (patrz tabela "Kody odpowiedzi serwera WWW"). Dla łatwiejszego zrozumienia kod statusu opatrzony jest opisem tekstowym, np. "403 Access denied", który ujrzymy po nieudanej próbie zalogowania się za pomocą nazwy użytkownika i hasła. Jeśli nie zostały stwierdzone żadne błędy, zobaczymy komunikat "HTTP/1.0 200 OK.".
Podobnie jak w zapytaniu HTTP, również w odpowiedzi po pierwszej linii mogą występować pola opcjonalne. Ich zastosowanie przedstawia rysunek. Lista pól wraz z opisami podaje tabela poniżej.

Autoryzacja
Wprawdzie większość zasobów World Wide Web dostępna jest dla wszystkich, jednak pojawia się coraz więcej serwisów, do których dostęp wymaga podania hasła. Hasło takie otrzymuje się zazwyczaj po wcześniejszej rejestracji. Autoryzacja przebiega na podstawie pól protokołu HTTP, który specjalnie do tego celu wyposażono w procedury pozwalające na rozpoznanie użytkownika i przyznanie mu praw dostępu do określonych zasobów WWW.
Jeśli na życzenie użytkownika przeglądarka żąda zastrzeżonej strony WWW, serwer wysyła odpowiedź o kodzie "401", który oznacza, że użytkownik musi zostać jednoznacznie zidentyfikowany, zanim uzyska dostęp do zasobu. Ponieważ protokół HTTP dopuszcza wiele różnych metod autoryzacji, w polu WWW Authenticate serwer określa, z jakiego algorytmu korzysta i dla jakiej grupy zasobów wymagana jest autoryzacja. Przeglądarka po przyjęciu żądania autoryzacji zmusza użytkownika do wpisania identyfikatora i hasła w odpowiednim okienku dialogowym.
Po wprowadzeniu hasła przeglądarka wysyła do serwera nowe zapytanie, przesyłając tym razem w polu Authenticate hasło użytkownika. Aby przy następnej próbie otwarcia strony WWW nie trzeba było podawać tego samego hasła, przeglądarka zapamiętuje hasła odpowiadające poszczególnym serwerom i później, w razie potrzeby, automatycznie przesyła je do serwera.

Rozszerzenia protokołu HTTP

Jeden protokół - trzy wersje
W swojej pierwszej, dość ubogiej wersji 0.9 protokół HTTP nie przewidywał żadnych pól w zapytaniach i odpowiedziach. Przeglądarka wydawała jedynie polecenie (GET i POST), a serwer wysyłał kod odpowiedzi i dane dokumentu.
Dopiero z wersją HTTP/1.0 zaczęto powszechnie używać pól w zapytaniach i odpowiedziach. W HTTP/1.0 przeglądarka musi tworzyć osobne połączenia TCP z serwerem dla pobrania każdego dokumentu. Również każda grafika pobierana jest przez osobne połączenie, tak samo jak wszystkie inne elementy budujące stronę WWW. Otwieranie i zamykanie połączeń TCP znacznie wydłuża czas pobierania stron i zwiększa
objętość przesyłanych danych - w najgorszym przypadku aż o 20 procent. Z tego względu w HTTP/1.1 wprowadzono połączenia nazywane Persistent
Conecctions, które są rodzajem stałego kanału komunikacyjnego pomiędzy przeglądarką i serwerem. Zamiast przesyłać dokument HTML i wszystkie jego elementy osobnymi połączeniami, HTTP/1.1 ogranicza się do jednego połączenia TCP, którym kolejno transmitowane są wszystkie dokumenty.

Digest Authentification
Już HTTP/1.0 zapewnia ochronę przed nieupoważnionym dostępem do stron WWW. Wykorzystywany do tego celu mechanizm o nazwie BASIC-Authentification ma jednak bardzo istotną wadę: hasła przesyłane są otwartym tekstem, przez co łatwo mogą zostać przechwycone i odczytane przez hakera.
W protokole HTTP/1.1 wprowadzono nowy mechanizm identyfikacji użytkowników o nazwie DIGEST-Authentification. Zapewnia on znacznie większy stopień
bezpieczeństwa, ponieważ niezaszyfrowane hasło w ogóle nie jest przesyłane. Aby użytkownik mógł się "przedstawić", serwer wysyła do przeglądarki tzw. Challenge w postaci ciągu znakowego. Do tego ciągu przeglądarka dokleja hasło, po czym całość szyfruje za pomocą algorytmu DIGEST. Dopiero tak przygotowany ciąg znaków wysyłany jest do serwera. Serwer po swojej stronie łączy posiadane hasło z wysłanym wezwaniem, szyfruje je, a następnie sprawdza, czy to, co uzyskał, zgodne jest z ciągiem przysłanym przez przeglądarkę.

Autoryzacja z wykorzystaniem mechanizmu Challenge/Response (wyzwanie/odpowiedź) została opracowana po to, aby umożliwić identyfikację użytkownika bez konieczności przesyłania hasła otwartym tekstem.

Słabym punktem tej metody jest dobór algorytmu DIGEST, który w niepowtarzalny sposób łączy ciąg Challenge z hasłem. Obecnie do tego celu wykorzystywany jest algorytm MD-5, który zdaniem ekspertów może być złamany przez dobrego matematyka dysponującego odpowiednio dużą ilością czasu.