Sieci komputerowe i Internet cz. 6

W poprzednim odcinku (DR005) wstępnie omówiliśmy metodę GET protokołu HTTP. Jest on bardzo często wykorzystywana i trzeba zagadnienie poznać nieco głębiej.

Powiedzieliśmy też, że w starej prostej sieci LAN według rysunku 3, gdzie dodaliśmy prosty serwerek www obsługujący czujnik wilgotności, trzeba dodać jakieś informacje adresowe.

Na pewno trzeba wykorzystać adres IP (192.168.1.23), bo adresy IP są podstawą działania sieci komputerowych. Ale z tego co już wiemy, w sieciach lokalnych wykorzystywane są też sprzętowe adresy MAC i w danej sieci LAN mamy powiązania sprzętowego numeru MAC z logicznym numerem IP. Nawet w najmniejszych i najprostszych sieciach komputerowych wykorzystujemy wszystkie warstwy stosu TCP/IP, trzeba więc posługiwać się parami adresów IP + MAC.

Gdybyśmy chcieli za pomocą komputera A sprawdzić wilgotność, to oczywiście musiałby on wysłać zapytanie GET, ale trzeba byłoby też dodać informacje adresowe. Zapytanie mogłoby mieć postać:

GET  /wilg.htm  HTTP1.0

host: 192.168.0.23

 Znów podstawowa zasada jest oczywista: wystarczy dodać informację adresową. Ale na razie mówimy o zapytaniu przygotowanym w jednej warstwie stosu TCP/IP, warstwie aplikacji. W rzeczywistości w przekazywaniu informacji będą brać udział także niższe warstwy.

Wcześniej mówiliśmy, że te warstwy można utożsamiać z oddzielnymi programami, które realizują poszczególne protokoły. Z uwagi na wiele szczegółów, opcji i obsługę błędów generalnie takie programy są bardzo skomplikowane. Jednak można się domyślać, że w przypadku prostego serwera www mogłoby być inaczej. W sumie po otrzymaniu zapytania ma on tylko odesłać prostą informację. I tu wracamy do tytułowych matrioszek wkładanych jedna w drugą.

Jak już wiemy, w warstwie aplikacji korzystamy z protokołu HTTP i jego metody GET. W tej warstwie mamy jedynie omówione przed chwilą prościutkie komunikaty, wiadomości tekstowe. Są to najmniejsze laleczki-matrioszki, które będą zapakowane w kolejne, coraz większe.

Przy wysyłaniu omówione proste teksty zapytania i odpowiedzi mają zostać przekazane do zarządzającej transmisją warstwy TCP, gdzie odpowiedni program ma dodać do nich odpowiednie informacje „transportowe”, a konkretnie nagłówek warstwy TCP. Taka paczka, nazywana segmentem, ma zostać przekazana do adresowej warstwy internetowej/sieciowej. Tam znów  odpowiedni program ma dodać nagłówek tej warstwy IP, a tak powstały pakiet (nazywaną dość często datagramem) przekazać do niższej warstwy dostępu do sieci. Jak już wiemy, tam znów  dodane zostaną pewne informacje, przez co uzyskamy tak zwaną ramkę (ethernetową). Możemy to zobrazować na rysunku 4.

Na marginesie trzeba wspomnieć, że w literaturze występują różnice w nazewnictwie. W górnej warstwie aplikacji mówi się o komunikatach, wiadomościach, o danych lub o strumieniu. Na pewno w dolnej warstwie dostępu do sieci mamy ramki. Najczęściej ramki ethernetowe. W warstwie sieciowej (internetowej) mamy pakiety, które jednak bardzo często nazywane są datagramami. Nie byłoby w tym nic dziwnego, ale jest pewien problem z warstwą transportową. Otóż jeśli wykorzystywany jest protokół TCP, to bez wątpienia mówimy o segmentach. Jest jednak kłopot, jeśli wykorzystywany jest protokół UDP, czyli User Datagram Protocol, a więc protokół datagramów użytkownika. Zgodnie z nazwą powinniśmy wtedy mówić nie o segmentach, tylko o datagramach warstwy transportowej. Słowo datagram częściej jest używane jako synonim pakietów IP warstwy sieciowej, ale może być słusznie używane jako określenia „kawałków” w warstwie transportowej, ale tylko przy wykorzystaniu tam protokołu UDP.

Wracamy do głównego wątku. Przy wysyłaniu tekstowe zapytanie czy odpowiedź protokołu HTTP trzeba „obudować”, dodając kilka nagłówków. W komputerze nie widać problemu, bo wszystko to mogą zrealizować różne, dowolnie skomplikowane programy, których obecności i roli nie musimy ani dostrzegać, ani rozumieć.

Ale w przypadku naszego małego serwera mocno niepokoi fakt, że mówimy o kilku programach realizujących skomplikowane reguły i wymagania kilku protokołów. Wygląda na to, że nasz mały serwerek www, odsyłając odpowiedź (Response), musi uruchomić te wszystkie skomplikowane programy, żeby komunikat tekstowy z warstwy aplikacji inteligentnie uzupełnić o kolejne nagłówki według reguł poszczególnych protokółów.

A to sugeruje, że nawet w najmniejszym serwerku www musi pracować potężny mikrokontroler z dużą ilością pamięci, by te skomplikowane programy zawierać i realizować.

A my się tego obawiamy, bo chcielibyśmy serwer www zrealizować jak najprościej i najtaniej, z wykorzystaniem jak „najmniejszego” procesora i przy minimalnej znajomości informatyki.

I tu mam kilka dobrych wiadomości.

Po pierwsze, poszczególne protokoły są obszerne, rozbudowane, ponieważ dotyczą wszystkich możliwych przypadków jakie mogą się zdarzyć w sieci komputerowej. My pracujemy z małej sieci lokalnej. Dlatego w naszym prostym serwerze www moglibyśmy spokojnie pominąć „trudniejsze przypadki” i zrealizować tylko niezbędne elementarne funkcje.

Po drugie, powszechnie dostępne są „gotowe kawałki kodu”, biblioteki, więc pisząc program serwera www, nie musimy rozumieć szczegółów, bo możemy skorzystać z licznych „gotowców”.

Szablon?

Aby maksymalnie uprościć obraz i pokazać w przystępny sposób istotę sprawy, moglibyśmy też sobie wstępnie wyobrazić, że odsyłając informację, w serwerze wykorzystamy nie tyle programy (procedury) dla poszczególnych warstw, tylko jeden wstępnie przygotowany… szablon. Wróć do rysunku 4 .

Nasz serwer www ma do sieci komputerowej wysłać ramkę ethernetową w postaci bajtów/bitów, a finalnie w postaci ciągu zer i jedynek. Ta ramka będzie zestawieniem „matrioszek”, a konkretnie nagłówków poszczególnych warstw według uproszczonego rysunku 4.

Nasuwa się przypuszczenie, że program w naszym małym serwerze www wcale „nie musi znać się na protokołach”. W skrajnym przypadku można sobie wyobrazić, że po odebraniu żądania (celowo pomijamy związane z tym szczegóły) program mikrokontrolera ma tylko wziąć przygotowany szablon i odpowiednio go wypełnić. Przede wszystkim do szablonu ma zapakować tekstową odpowiedź (Response) z warstwy aplikacji, dotyczącą wilgotności, która będzie mieć postać kodu HTML. I na pewno do odpowiednich nagłówków ma wpisać odpowiednie numery IP oraz odpowiednie numery MAC.

Szablon jest mocno skomplikowany, jak pokazuje to rysunek 5, ale mimo to cała taka operacja mogłaby być zaskakująco prosta. Wcześniej stwierdziliśmy, że przygotowanie kodu HTML mogłoby polegać na dodaniu dwóch cyfr wyniku pomiaru do gotowego tekstu przygotowanego w pamięci. A teraz prawie cały taki szablon byłby gotowy, zapisany w pamięci procesora, a program serwera www musiałby w sumie wstawić tylko trzy „lokalne” informacje: aktualną wilgotność odczytaną z sensora oraz swoje adresy IP i MAC, co ilustruje rysunek 6.

Proste?  Znów zaskakująco proste!

W rzeczywistości aż tak proste nie jest, bo z kilku względów nie uda się wytworzyć potrzebnej ramki ethernetowej jedynie przez wypełnienie „pustych kratek” szablonu.

To nie jest dobra wiadomość!

Przykład z szablonem nie jest wprawdzie do końca trafny, ale z punktu widzenia elektronika-praktyka realizującego i programującego serwer www może to wyglądać dokładnie tak, jakby wykorzystywał jakiś szablon. Skorzysta on nie z szablonu, tylko z „procedur-gotowców”, które wprawdzie robią o wiele więcej niż tylko wypełnianie szablonu, ale o szczegółach nie musi on wiedzieć. Finalnym efektem będzie ramka ethernetowa, przygotowana zgodnie z wymaganiami protokołów.

Elektronik, wykorzystujący „procedury-gotowce” związane z transmisją w sieci komputerowej, nie musi rozumieć ich działania, musi tylko do nich „włożyć” według rysunku 6 właśnie te trzy podstawowe składniki: informację o wilgotności, adres IP i adres MAC serwera www.

Jak widać, omawiane podstawowe zasady są naprawdę proste. Jednak wnikliwym Czytelnikom zapewne już teraz nasuwają się liczne pytania i wątpliwości. Niektóre wyjaśnimy już w następnym odcinku DR007.

 Piotr Górecki