lab1.md

Laboratorium 1

Z tego laboratorium przygotowujesz sprawozdanie. Może mieć ono dowolną formę, byleby treść się zgadzała.

Rzeczy oznaczone cytatami blokowymi oznaczają to, co masz zawrzeć w sprawozdaniu. Na przykład:

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

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

Mogą być to też pytania, na które w sprawozdaniu udzielisz odpowiedzi.

Każde ćwiczenie poprzedzał będzie wstęp teoretyczny. Nie jest on długi i męczący, więc możesz go przeczytać.
Doskonale. Zaczynamy!

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 implementującymi nieco inne usługi.

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 nowsze dane, nie mając starszych, 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 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ą w takich częściach w jakich zostały wysłane. Po prostu są to ciągi bajtów.

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 (chyba że jest się ekspertem z danego protokołu).

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 taki plik), 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 nawiązać) serwer czeka na żądanie klienta, a po jego otrzymaniu wysyła odpowiedź i kod statusu.

Najbardziej znany kod statusu to HTTP 404. Poprawne odpowiedzi to kody 2xx, a "przeniesiono" 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. W końcu czytając książkę też ciężko o nich mówić - są tam wyrazy, zdania, ale nie pakiety.

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

Zapisz tą przykładową parę, wraz z źródłem.

W pierwszej linii zawarto tzw. metodę HTTP oraz wersję protokołu. Następnie występuje seria nagłówków żądania, czyli par nazwa nagłówka - wartość, które klient decyduje się podać serwerowi.

Czy przy użyciu PuTTY mógłbyś użyć protokołu HTTP/2.0? Dlaczego?

Gdy to zrobisz, uruchom PuTTY. Istotne są trzy pola:

• Host Name - nazwa docelowej strony. W twoim przypadku wpisz tu http_hostname
• Port - port, z którym będziemy się łączyć. Wpisz odpowiedni
• Connection type - w niektórych protokołach maszyna musi nam pomóc (np. bo są szyfrowane). HTTP takim nie jest, więc wybierz Raw

Jeśli połączenie zostanie poprawnie nawiązane, wyświetli się czarne okno. Wpisz kompletne zapytanie HTTP o Twoją stronę, sugerując się znalezionym przykładem.

Zapytaj o zasób główny (/) strony $http_hostname$. Wzoruj się
na znaleziony przykładzie. Wynikiem zapytania musi być kod 2xx
lub 3xx.

Zapisz całość sesji. Abyś miał na to czas, przydatne może być 
użycie nagłówka Keep-Alive.
     
Najprawdopodobniej nie zadziała to bez użycia nagłówka Host. 
Pamiętając, że adres strony, który wpisałeś, został zamieniony
na adres IP przed połączeniem (a nie przesłany do serwera),
spróbuj uzasadnić dlaczego.

Zaobserwuj odpowiedź. Składa się ona również z dwóch części - z listy nagłówków, oraz tzw. ciała. Tutaj odpowiedź była tekstem - kodem HTML. Był on zrozumiały dla człowieka. To, czym odpowiada serwer, znajduje się w nagłówku jego odpowiedzi jako Content-Type.

Kto przydziela typy MIME? Jakie typy MIME mogą mieć
dokumenty Microsoft Word?

Spróbujmy otrzymać kod błędu. Kody błędów z winy klienta (czyli nas) to 4xx, a z winy serwera to 5xx. Dużo łatwiej spowodować ten pierwszy, niż drugi. Nie każdy serwer HTTP na te same klasy błędów odpowiada w ten sam sposób. Kodom błędów (lub sukcesu) towarzyszy zazwyczaj krótki opis, np. 200 OK, albo 404 Not Found.

Sprowokuj serwer, z którym się łączysz, do zwrócenia
błędu 404. Zapisz przebieg sesji.

Spróbujmy teraz pobrać zasób binarny. Ponownie za pomocą PuTTY połącz się ze stroną, ale tym razem pobierz zasób /favicon.ico.

/favicon.ico to nazwa zasobu, który reprezentuje małą ikonkę stony. Zazwyczaj ikonka ta widoczna jest na pasku, obok nazwy karty. Jest to nazwa zwyczajowa, czyli jeśli przeglądarka stwierdzi istnienie takiego zasobu, to użyje go (chyba że twórca strony zażyczył sobie inaczej).

Pobierz favicon.ico z $http_hostname$.
Zanotuj typ MIME odpowiedzi, oraz całą sesję HTTP.

Jaki kod odpowiedzi otrzymałeś? Znajdź kolegę/koleżankę
z innym kodem. Zanotuj jego/jej numer zadania.

Serwer HTTP może więc przesyłać różne typy plików. Klient również może to zrobić. Musi on skorzystać jedynie z metody umożliwiającej przesłanie tzw. ciała. Wykorzystywane jego to do wysyłania formularzy, plików, itp.

Ustal jakie metody HTTP pozwalają na przesłanie ciała
poprzez klienta.

Istnieją również inne protokoły tekstowe. Z nich również można - w pewnym stopniu - korzystać za pomocą PuTTY. Jak zobaczyliśmy nie jest to wygodne, ale pozwala nam dobrze zrozumieć protokół.

Przypomnij sobie definicję przeglądarki internetowej.
Z jakiej właśnie skorzystałeś?

Wymień 3 rzeczy, które również można zrobić za pomocą
PuTTY, oraz nazwę protokołu, który tą rzecz umożliwi.

DNS jako protokół binarny UDP

Wyprzedzając zastrzeżenia - DNS może również działać za pomocą TCP. Jest jednak pewien problem - do samego zestawienia połączenia TCP wymaga 3 pakietów, do przesłania odpowiedzi i zapytania 4 (1 na dane, 1 na potwierdzenie odbioru), a do rozłączenia się aż 4. Ze względów wydajności najczęściej stosuje się do niego więc UDP.

UDP to drugi najczęściej wykorzystywany protokół warstwy transportowej korzystający z IP. Jest on protokołem bezpołączeniowym - czyli możemy do każdego wysłać pakiet UDP i nie musi się on go spodziewać. Pakiety UDP mogą jednak być:

• dostarczane nie po kolei
• duplikowane (wysyłasz jeden, dostajesz dwa)
• gubione

Podobnie jak TCP wykorzystuje on porty. Tutaj jednak programista wysyła całe pakiety (czyli ciąg bajtów o ustalonej długości), a po drugiej stronie odbiera również te same pakiety. Nie są one modyfikowane, jak w TCP, ale mogą podlegać wcześniej wymienionym zjawiskom. Programista musi o tym pamiętać.

Ponieważ nie wymaga on pamiętania zestawionych połączeń, jest bardziej wydajny od TCP. Dlatego też zastosowano go w protokole DNS, służącym zasadniczo do zamiany nazw domen postaci wp.pl na adresy postaci 212.77.98.9. Ma on jeszcze kilka innych zastosowań, o tym później.

DNS przypisuje nazwie domeny listę par typ rekordu + wartość. Jedna domena może mieć kilka różnych rekordów. Zazwyczaj będzie zawierać adres serwera DNS, który jest odpowiedzialny za jej obsługę, adres IP, adres serwera e-mail, oraz dodatkowe informacje.

Jest to protokół binarny, nie możemy więc wpisywać go ręcznie. Musimy użyć klienta DNS. System Windows ma wbudowanego klienta o nazwie nslookup.

Otwórz linię poleceń Windows. Wywołaj narzędzie nslookup. W jego linii poleceń wydaj polecenie help. Przeczytaj uważnie i zrozum je.

Ustaw nslookup, aby udzielał wyczerpujących (exhaustive) informacji
o debugowaniu.

Ustal adres IP $http_hostname$. Zanotuj odpowiedź nslookup.

Czy odpowiedź była autorytatywna? Co to oznacza? Jaki
adres miał serwer DNS, który rozpatrzył Twoje zapytanie?

Serwery DNS zazwyczaj pracują w trybie rekursywnym, tj. jeśli nie wiedzą, to się dowiedzą, i dopiero odeślą zapytanie. Wymaga to od nich większej pracy, ale klient ma swoją odpowiedź. nslookup pozwala wyłączyć ten tryb.

Wyłącz tryb rekursywny w nslookup. Zapisz polecenie.
Wymyśl jakąś nazwę domeny, z której ten komputer nie korzystał
od uruchomienia. Zapisz przebieg sesji (exhaustive debug). 

Z jakim serwerem/serwerami DNS skontaktował się nslookup? Dlaczego?
Co to za serwery? Kto za nie odpowiada?

DNS może również przechowywać inne informacje na temat tej domeny. Służą do tego po prostu inne typy rekordów. Wykaz takich typów można znaleźć w sieci Internet.

 Jaki typ rekordu odpowiada za to, który serwer DNS odpowiada za daną
 domenę?
 
 Wykonaj takie zapytanie, aby otrzymać odpowiedź autorytatywną. Zanotuj
 wydane polecenia i odpowiedź.
 
 Dlaczego ta odpowiedź jest autorytatywna?

Rekord MX służy do ustalenia, gdzie nadać pocztę, zaadresowaną pod konkretny adres. Mając adres stefan@example.com zapytamy się o MX domeny example.com, a później serwer obsługujący nasze konto pocztowe spróbuje tam dostarczyć korespondencję.

Domeny można kupować. Służą do tego specjalne agencje, tzw. registrarzy. Po uiszczeniu opłaty rejestracyjnej, oraz dorocznej abonamentowej, domena jest nasza. Możemy wtedy decydować, co znajdzie się w wpisach DNS tej domeny. Na przykład, kupując example.org możemy zadecydować, co będzie w wpisach inna.example.org.

Jeśli chcemy domenę od kogoś kupić, musimy poznać jego tożsamość. Zazwyczaj możemy dokonać tego za pomocą usługi WHOIS.

Do kogo należy domena $http_hostname$?
Podaj adres strony WHOIS z której korzystałeś, oraz całość odpowiedzi. 

Niekiedy dane te nie są dostępne. Wtedy można skontaktować się z registrarem, i poprosić o kontakt do tej osoby, lub przekazanie jej naszego kontaktu.

Dlaczego przy domenach .pl do umieszczenia danych osoby fizycznej
wymagana jest jej zgoda, a jeśli właścicielem jest firma, to już nie?

Zadania dodatkowe

Wykonaj je, jeśli masz czas. Odpowiedzi zamieść w sprawozdaniu.

1. Najnowszym kodem błędu HTTP jest 451. Co on oznacza? Skąd taka wartość (i dlaczego)?
2. HTTP w szyfrowanym wydaniu to HTTPS. Co zmieniono w protokole w stosunku do HTTP? Jak ułatwiono sobie tu życie za pomocą enkapsulacji i model ISO OSI?
3. Czy oprócz TCP i UDP istnieją jakieś inne protokoły warstwy transportowej korzystające z IP? Jakie? Co robią?
4. W jaki sposób botnety i złośliwe oprogramowanie wykorzystują DNS? Po co im to?
5. Co to jest Sender Policy Framework? Z jakiego mechanizmu DNS korzysta?
6. Co to jest NASK? Jaką rolę spełnia w administracji domenami .pl?