lab1.md

Laboratorium 1

HTTP i DNS jako przykłady użycia TCP i UDP

---

Z tego laboratorium przygotowujesz sprawozdanie. Przygotowujesz je na zajęciach, a przy ich zakończeniu wysyłasz na adres podany na końcu tej instrukcji. Będziesz musiał wkleić przynajmniej jeden obrazek, więc odpowiednio wybierz edytor.

Rzeczy oznaczone tak, jak poniżej, dotyczą tego, co masz zawrzeć w sprawozdaniu. Na przykład:

Zapisz swoje imię, nazwisko, adres e-mail, kierunek i rok studiów
oraz grupę laboratoryjną i numer albumu.

Podaj również numer zajęć laboratoryjnych (nr 1) oraz numer
zadania (to zadanie ma nr $lp$).

Mogą być to też pytania, na które w sprawozdaniu udzielisz odpowiedzi. Możesz pomagać sobie wyszukiwarką internetową, oraz zabrać głos w dyskusji, jeśli się jakaś wywiąże.

Teoria jest wpleciona w zadania. Po prostu czytaj, wykonuj polecenia i zadawaj sobie dużo pytań. Jeśli zupełnie utkniesz, a Google nie będzie Ci w stanie pomóc, zapytaj się prowadzącego. Chętnie wyjaśni Ci on również, dlaczego coś zrobiono tak, a nie inaczej.

HTTP jako protokół tekstowy TCP

Jedną z rzeczy, którą początkującym informatykom trudno jest zrozumieć, jest różnica w protokołach TCP i UDP. Oba są protokołami warstwy transportowej OSI działającymi na podstawie protokołu IP (czyli do komunikacji należy mieć adres IP), jednak o nieco innych charakterystykach i zakresach użycia.

TCP, czyli Transmission Control Protocol, to połączeniowy, niezawodny i strumieniowy protokół.

• połączeniowy - zanim dojdzie do transmisji danych, należy zestawić połączenie. Obie maszyny muszą więc uzgodnić, że będą ze sobą rozmawiać. Nie można wysłać pakietu TCP tak po prostu (no, chyba że to pakiet nawiąż połączenie).
• niezawodny - jeśli programista powie "wyślij bajty A B C D", to albo dojdą one kompletne, w całości, oraz tylko raz (słowem, tak jak zostały wysłane), albo nie dojdą wcale (awaria połączenia). Mimo, że pakiety IP mogą być po drodze gubione, a nawet duplikowane, TCP zapewnia że dane dojdą tak, jak zostały wysłane.
• strumieniowy - do TCP wysyłamy ciąg bajtów i otrzymujemy po drugiej stronie ciąg bajtów. Ze względu na jego niezawodność, te bajty mogą być dzielone, łączone, ogólnie mogą dziać się z nimi po drodze różne rzeczy. Jeśli wyślemy pakiet TCP o treści Ala ma kota, to niekoniecznie właśnie taki pakiet dojdzie do nadawcy. Mogą dojść do niego na przykład dwa pakiety - Ala m, oraz po jakimś czasie dopiero a kota. Nie mniej jednak, wszystko, czego wysłanie zostało zlecone, dojdzie w takiej kolejności. Jeśli TCP odbierze późniejsze dane przed wcześniejszymi, będzie "udawał" że ich nie ma, dopóki nie odbierze tych starszych. Nie nadaje się więc do zastosowań, gdzie stare pakiety po prostu nie są nam już potrzebne (np. wideokonferencje).

Z jednej strony więc rozpatrując TCP dostajemy pewne gwarancje, których sama warstwa sieciowa (w której działa tu IP), nam nigdy nie da, ale w pewnym sensie tracimy kontrolę nad swoimi pakietami. Pakiety mogą być gubione i przychodzić nie po kolei - TCP ułoży je oraz ponowi transmisję za nas. Pisząc programy korzystające z TCP nie wolno zakładać że dane dojdą podzielone tak, jak zostały wysłane. Po prostu są to ciągi bajtów. Odbiorca musi odesłać potwierdzenie odebrania danych, tak więc jest on mniej wydajny od UDP, pozwala jednak budować bardziej złożone protokoły nie martwiąc się o to, że pakiety nam zginą.

Z tego też powodu należało wymyślić sposób, jak zaznaczyć że jeden pakiet protokołu wyższej warstwy (np. takie zdanie) się kończy, a drugi zaczyna. Możliwe rozwiązania są trzy:

1. Będziemy na początku wysyłać jak długi jest pakiet, a dopiero potem pakiet.
2. Umówimy się, że jakiś znak (bajt) będzie rozdzielał pakiety.
3. Umówimy się, że każdy pakiet będzie miał identyczną, z góry znaną długość.

Możliwość 3 ogranicza nam pole manewru, więc odrzucimy ją. W praktyce wykorzystywane są pierwsze dwie opcje.

Protokoły binarne, czyli zrozumiałe przez maszyny, wykorzystują pierwszą możliwość, gdyż łatwo jest pisać programy korzystające z takich programów, jest to również bardziej wydajne. Niestety, protokoły binarne w czystej formie są bardzo trudne do zrozumienia dla człowieka bez użycia specjalnych narzędzi.

Na szczęście HTTP jest protokołem tekstowym. Oznacza to, że człowiek mógłby podejrzeć komunikację i bez większego problemu zrozumieć, o co chodzi. Nie zobaczy on krzaków (chyba że właśnie ściągamy za pomocą HTTP plik binarny), a czytelny tekst. Zastosowano w nim możliwość 2 - tym znakiem jest znak końca linii.

HTTP jest protokołem synchronicznym. Oznacza to, że przy nawiązanym połączeniu to klient wysyła zapytanie, a serwer odpowiada. Serwer sam z siebie nie może zacząć "mówić" (chyba że w bardzo szczególnych przypadkach). Po nawiązaniu połączenia (HTTP korzysta z TCP, więc musi najpierw je nawiązać) serwer czeka na żądanie klienta, a po jego otrzymaniu wysyła kod statusu, oraz odpowiedź. Żądanie takie zawiera metodę oraz adres zasobu.

Najbardziej znany kod statusu to HTTP 404. Pierwsza cyfra (setek) określa kategorię odpowiedzi. Poprawne odpowiedzi to kody 2xx, a informacje o przeniesieniu zasobu to 3xx. Błędy strony serwera (czyli nie z winy klienta) to 5xx.

Co to znaczy HTTP 404?

Wspominając o protokołach tekstowych raczej nie mówimy o pakietach, preferując raczej termin linia (czyli tekst do znaku końca linii).

Wadą protokołu tekstowego jest fakt, że maszyna musi się nieco bardziej wysilić, aby skorzystać z tego protokołu. Są one również wolniejsze. Zaletą jest ich zrozumiałość bez wyspecjalizowanego oprogramowania, co w początkach Internetu było bardzo ważne. Łatwiej też pisać bardzo proste programy, które mają z nich korzystać.

Z którego roku jest obecnie wykorzystywana wersja HTTP - HTTP/1.1?

Pobierz PuTTY. PuTTY jest terminalem, czyli uniwersalnym klientem protokołów tekstowych. Możemy więc nim obsłużyć wiele różnych protokołów. Zazwyczaj korzystają z niego administratorzy do logowania się na serwery, ale możemy nim również obsłużyć HTTP (choć nie jest to wygodne).

Zarówno TCP, jak i UDP do wysłania danych wymagają podania (oprócz adres IP) tzw. portu. Port to liczba od 0 do 65536.

Ilu bitów wymaga zapisanie jednego portu TCP/UDP?

Port służy do określenia czego dokładnie chcemy od docelowej maszyny. Może mieć ona bowiem wiele usług - np. WWW, poczta elektroniczna czy serwer plików. Port pozwala na określenie tej usługi. Znane protokoły mają również znane numery portów. Nadawaniem ich zajmuje się IANA - Internet Assigned Numbers Authority - jedna z organizacji zarządzających Internetem. Aby połączyć się za pomocą HTTP, musimy znać jego port.

Ustal, na którym porcie łączy się HTTP

Znajdź w sieci Internet, jak wygląda przykładowe żądanie i odpowiedź HTTP. Słowa kluczowe: GET, HTTP/1.1.