Z_Wykład_16.03.2008.doc

Internet stał się przełomem technologicznym i społecznym ostatniego ćwierćwiecza. Dzisiejsze wykłady zaczniemy zatem od definicji Internetu. Medium, które zwie się internetem jest złożeniem takich trzech elementów. Po pierwsze są to sieci, które są ze sobą połączone protokołem TCP/IP (wymóg technologiczny). Po drugie mamy element społecznościowy, czyli społeczność, która uzywa i rozwija ta sieć. I każdy oprócz tego, że może przeglądać zasoby sieci, może ingerować, modyfikować zawartość elementów tej sieci. I trzeci element to oczywiście zbiór zasobów znajdujacych się w tej sieci (aspekt informacyjny). Użytkowanie internetu jest to nic innego, jak działanie społeczności przy pomocy sieci mające na celu odnalezienie i wykorzystanie znajdujacej się w niej zasobów informacyjnych. W ramach wytworzonego internetu powstało wiele typów sieci począwszy od LAN do WAN (technologii najszybciej rozwijającej się mającej największe zapotrzebowanie). Jeśli chodzi o LAN, czyli te sieci o małych rozmiarach, to warto powiedzieć, że zostały one rozbudowane o wykorzystanie sieci bezprzewodowych (Bluetooth). Zwykle jest tak, że jak mamy sieć WAN i LAN, to obydwie te sieci są rozgraniczone routerem. Sieć LAN składa się od kilku do kilkudziesięciu komputerów, natomiast WAN ze znacznie większej liczby. I ten WAN dzieli się na takie dwie specjalne podsieci – MAN (Metropolitan Area Network) i CAN (Campus Area Network). One się nie różnią niczym od sieci WAN jeśli chodzi o infrastrukturę, natomiast sa one wyodrębnione w taki sposób ze względu na swoją funkcjonalność i ze względu na główne zastosowanie. Sieć CAN jest dedykowana zawężonemu gronu użytkowników w ramach pewnego obszaru geograficznie spójnego i udostępniają one bardzo szybkie łącza dedykowane. Sieci WAN Zostały oparte w pełni o połączenia modemowe (o łącza telefoniczne) i między innymi o ISDN. Są to najnowsze technologie, które w ramach tej sieci zostały wyszególnione i własnie dziś ISDN jest rozwijany w celu zapewnienia jeszcze szybszych połączeń internetowych. Teraz powiedzmy sobie o pojęciu protokołu internetowego. Co to są te protokoły. Protokoły internetowe to podzbiór protokołów komunikacyjnych, mający zastosowanie w środowisku internetu. Protokoły internetowe to zbiór ścisłych reguł i kroków postępowania, które są automatycznie wykonywane przez urządzenia w celu nawiązania łączności i wymiany danych. Należy pamiętać, że wszystkie protokoły internetowe jako ogół definiują takie dwa podstawowe elementy -  nagłówek i wiadomość. Wiemy, że podstawą komunikacji w sieci WAN, czyli sieci internet jest protokół TCP/IP. Protokół TCP/IP dzieli się na dwa odrębne protokoły: IP – służący do adresowania i wymiany danych pomiędzy podsieciami (stąd się wzięło adresowanie) i TCP, który jest protokołem sterującym poprawnością danych. Jeśli chodzi o protokół IP, to obecnie wykorzystuje się protokół IP w wersji czwartej dzielącego się na 6 klas. Klasy służą do wyodrębnienia rodzaju sieci (czy jest to LAN – dla klasy A - 10.x.x.x., a dla klasy C – 192.168.x.x, czy WAN). Jednak w trakcie wdrażania jest wersja szósta tego protokołu, do którego stworzenia przyczynił się w głównej mierze problem małej, kończącej się ilości adresów IP w wersji czwartej. W wersji szóstej mamy znacznie więcej możliwości adresowania i na pewno na długo rozwiązany byłby problem przydzielenia adresów (choćby taki telefon komórkowy mógłby mieć własny adres IP, bo do tej pory był wyszukiwany pierwszy wolny i przydzielany). Drugim protokołem w sieci internet prócz TCP/IP jest UDP. Jest on bardzo szybki, nie zapewnia on jednak w pełni połączenia z portem. Natomiast jeżeli pakiet nie dotarł, to zawsze jest możliwość retransmisji tego pakietu. Kolejny protokół to HTTP – jest on najważniejszy spośród tych wszystkich tutaj podanych do tej pory. Po pierwsze jest najpowszechniejszym protokołem widocznym w sieci WWW. Stanowi podstawę kominikacyjną jeżeli chodzi o publikację danych w sieci WWW. http udostepnia znormalizowany sposób komunikowania się komputerów z sobą, okresla formę urzadzeń klienta, oraz formę odpowiedzi. Prócz tego jest zaliczany do protokołów nezstanowych z racji tego, że nie zachowuje żadnych informacji o poprzednich transakcjach z klientem (po zakończeniu transakcji wszystko przepada). Pozwala to znacznie zmniejszyć obciążenie serwera, jednak jest kłopotliwe w sytuacji, gdy 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 cookies. FTP to kolejny protokół. Służy on do wymiany plików, ale schodzi on już na dalszy plan choćby ze względu na torrenty. Standardowo protokół ten działa w dwóch trybach – pasywnym (działa na porcie 21 dla poleceń i na porcie większym niż 1024 do przesyłania danych) i aktywnym (działa na porcie 21 dla poleceń i na porcie 20 dla danych – połączenie jest nawiązywane tu przez serwer). Kolejne protokoły to protokoły związane z przesyłaniem wiadomości pocztą elektroniczną – SMTP, POP3 I IMAP. Wszystkie te protokoły sa protokołami tekstowymi (czytelnymi dla człowieka). SMTP jest protokołem zawodnym, gdyż nie pozwala on na pobieranie wiadomości ze zdalnego serwera. POP3 służy do odbioru poczty elektronicznej, jednakże:

·         Połączenie trwa tylko, jeżeli użytkownik pobiera pocztę i nie może pozostać uśpione.

·         Do jednej skrzynki może podłączyć się tylko jeden klient równocześnie.

·         Każdy list musi być pobierany razem z załącznikami i żadnej jego części nie można w łatwy sposób pominąć.

·         Wszystkie odbierane listy trafiają do jednej skrzynki, nie da się utworzyć ich kilku.

·         Serwer POP3 nie potrafi sam przeszukiwać czekających w kolejce listów.

Istnieje jednak bardziej zaawansowany protokół IMAP. W przeciwieństwie do POP3, który umożliwia jedynie pobieranie i kasowanie poczty, IMAP pozwala na zarządzanie wieloma folderami pocztowymi oraz pobieranie i operowanie na listach znajdujących się na zdalnym serwerze. IMAP pozwala na ściągnięcie nagłówków wiadomości i wybranie, które z wiadomości chcemy ściągnąć na komputer lokalny. Pozwala na wykonywanie wielu operacji, zarządzanie folderami i wiadomościami. I tak powiedzieliśmy sobie o podstawowych protokołach internetowych. Teraz natomiast skupimy się na anatomiii protokołu HTTP. Pamiętamy, że jest bezstanowy i nastepuje taka pojedyncza transakcja - wysyłamy wiadomość HTTP, dostajemy odpowiedź i koniec. I teraz mamy kilka takich metod HTTP, które obsługują operacje na serwerze. Jest ich dość sporo, natmiast my powiemy o dwóch najważniejszych – GET I POST. Obydwie te metody służą do komunikacji z serwerem i do interaktywnego pobierania danych. Metoda GET to nic innego, jak pobranie zasobu wskazanego przez URL. może mieć postać warunkową jeśli w nagłówku występują pola warunkowe takie jak If Modified Since. Z kolei metoda POST odpowiada za przyjęcie danych przesyłanych od klienta do serwera (przykładowo - wysyłanie zawartości formularzy). Można jeszcze ewentualnie powiedzieć o HEAD. Ta metoda pobiera informacje o zasobie i jest stosowana do sprawdzania dostępności zasobu. W przypadku formularzy na stronie WWW można wymiannie stosować metodę GET i POST. Różnica pomiędzy nimi jest taka, że w GET wszystkie parametry wywołania formularza idą otwartym kanałem (idą w URL) i jest tworzone wywołanie do serwera o postaci:

http://81.113.23.98:80/myapp/usluga?query_string

HTTP:// oznacza tu specyfikację protokołu. Nastepnie podajemy adres domenowy lub IP sewera. Później możemy podac port. Domyślny dla http jest port 80 i jeśli jest port 80, to :80 możemy pominąć. Następnie jest ścieżka, która mówi, że odwołujemy się do zasobu w ramach pewnej aplikacji WEB. I od znaku zapytania włącznie będzie widoczna deklaracja parametrów. Przy metodzie POST nie ma czegoś takiego. Będzie widoczny adres, ale już bez widocznej deklaracji parametrów, ponieważ parametry sa przesyłane kanałem ukrytym. Wracając jednak do tego adresu URL należy podkreslic dwie rzeczy – ma on ograniczoną długość, a ponadto nie możemy użyć spacji w adresie. Spacja bowiem rozdziela adres. Jeśli chcielibyśmy użyć spacji, to spację zastepuje bowiem znaczek %20 (to odnosi się do parametrów rzecz jasna). Jednak w większości przeglądarek już wprowadzono taki dekoder, który to rozwiązuje zamieniając automatycznie znak spacji na %20. Stąd dla formularzy bezpieczniejasza jest metoda GET. Teraz jak wygląda taka podstawowa sesja związana z protokołem HTTP. Na początek popatrzmy, jak wygląda zapytanie http, które przesyłane jest od klienta do serwera:

1.      GET / HTTP/1.1 (prośba o zwrócenie dokumentu o URL / zgodnie z protokołem HTTP 1.1)

2.      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)

3.      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)

4.      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)

5.      Accept-Language: pl,en-us;q=0.7,en;q=0.3 (preferowany język strony - nagłówek przydatny przy Language negotiation)

6.      Accept-Charset: ISO-8859-2,utf-8;q=0.7,*;q=0.7 (preferowane kodowanie znaków)

7.      Keep-Alive: 300 (czas, jaki klient chce zarezerwować do następnego zapytania w przypadku połączenia Keep-Alive)

8.      Connection: keep-alive (chęć nawiązania połączenia stałego Keep-Alive z serwerem HTTP/1.0)

9.      znak powrotu karetki i nowej linii (CRLF)

No i teraz jak wygląda odpowiedź  serwera WWW na takie zapytanie:

1.      HTTP/1.1 200 OK (kod odpowiedzi HTTP, w tym wypadku zakceptowanie i zwrócenie zawartości)

2.      Date: Sun, 11 Jul 2004 12:04:30 GMT (czas serwera)

3.      Server: Apache/2.0.50 (Unix) DAV/2 (opis aplikacji serwera)

4.      Set-Cookie: PSID=d6dd02e9957fb162d2385ca6f2829a73; path=/ (nakazanie klientowi zapisania Cookie)

5.      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 cache. Jest to stara metoda zastąpiona przez Cache-Control)

6.      Cache-Control: no-store, no-cache, must-revalidate (no-store zabrania przechowywania dokumentu na dysku, nawet gdy nie jest to cache. must-revalidate nakazuje bezwzględnie stosować się do wytycznych i sprawdzić swieżość dokumentu za każdym razem)

7.      Pragma: no-cache (informacje dotyczące Cache'owania zawartości. Stara, niestandardowa metoda.)

8.      Keep-Alive: timeout=15, max=100

9.      Connection: Keep-Alive (akceptacja połączenia Keep-Alive dla klientów HTTP/1.0)

10.  Transfer-Encoding: chunked (typ kodowania zawartości stosowanej przez serwer)

11.  Content-Type: text/html; charset=iso-8859-2 (typ MIME i strona kodowa zwróconego dokumetu)

12.  znak powrotu karetki i nowej linii (CRLF)

13.  tutaj zawartość dokumentu

HTTP/1.1 dopuszcza wysłanie kilku żądań naraz (pipelining). HTTP/1.0 zakłada jedno żądanie i jedną odpowiedź. 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). Jeśli wpisujemy adres strony, lub piszemy jakąś stronę i próbujemy ją wywołać, to jeśli cos jest nie tak, to informują nas o tym kody informacyjne. Kod odpowiedzi HTTP to numeryczna dana wysyłana przez serwer HTTP do aplikacji klienta. Informuje o sposobie realizacji (bądź jej braku) zapytania klienckiego. Znajduje się na początku odpowiedzi, tuż za wersją protokołu HTTP i przed słownym opisem kodu odpowiedzi przykładowo: HTTP/1.1 400 Bad Request. Oto, jakimi kodami może odpowiedzieć przeglądarka i co one oznaczają:

Kody informacyjne

Kody powodzenia

Kody przekierowania