first

build.py

@@ -27,12 +27,12 @@ if __name__ == '__main__':
         d['lp'] = unicode(ex_no)
 
         for k, v in d.iteritems():
-            print k, v
             plab = plab.replace(u'$%s$' % (k, ), v)
 
         with open('dist/lab1/%s.md' % (ex_no, ), 'wb') as labout:
             labout.write(plab.encode('utf8'))
 
         os.system('pandoc dist/lab1/%s.md -s -o dist/lab1/%s.pdf' % (ex_no, ex_no))
+        os.unlink('dist/lab1/%s.md' % (ex_no, ))
 
 

src/lab1.json

 [
   {
-
+    "http_hostname": "onet.pl"
   }
 ]
\ No newline at end of file

src/lab1.md

-# Nr $lp$
-Zażółć gęślą jaźń
+Informatyka II
+==============
+EE-DI, WEiI PRz
+---------------
+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
+    
+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**.
+
+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](http://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html). 
+PuTTY jest 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?
+
+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.
+   
+sds