konfiguracji sieci w Linuks. Jednak to nie koniec tematów
sieciowych ponieważ następne dwa rozdziały będą na niej bazować.
</p>
+ <h1 id="10.applicationlayer">10. Warstwa aplikacji - usługi sieciowe</h1>
+ <p>
+ W poprzednim rozdziale dowiedzieliśmy się czym są sieci komputerowe
+ i jak wygląda ich konfiguracja w dystrybucjach Linuksa. Sieci służą
+ do przesyłania danych, a te musimy dostsować za pomocą uzupełnienia
+ formularza na stronie internetowej lub w postaci zwykłego pliku
+ tekstowego. Za obie te formy odpowiadają różne ustandaryzowane zbiory
+ programów składające się na jeden konkrent <strong>protokół</strong>.
+ Protokołów nie należy stawiać obok programów, które możemy kojarzyć
+ z daną formą sposóbu przesyłania informacji przez sieć. Te programy
+ najczęściej zajmują się ich obsługą, zawierają tym samym ich
+ implementacje oraz dostosowanie aby korzystanie z protokołu było
+ najcześciej niezauważalne a końcowy użytkownik utrzymał tylko
+ i wyłącznie żądaną stronę internetową lub dostęp do zasobu dyskowego
+ udostępnionego gdzieś na serwerze.
+ </p>
+ <p>
+ Aby pomiędzy dwoma <em>stronami</em> mogła zajść komunikacji
+ potrzebny jest nadawca i odbiorca. Z punktu widzenia sieci
+ komputerowej, każdy host jest jednocześnie jednym i drugim. Jednak
+ patrząc na to ze strony obecnie omiawianego tematu, różnica między
+ stronami jest już dużo bardziej podkreślona. Mamy sztywny podział
+ między aplikacji klienckimi danego protokołu, które żądają dostępu
+ do konkretnego zasobu a serwera, które te dane udostępniają.
+ Wiele serwerów określa się mianem <strong>usług sieciowych</strong>.
+ Często mówiąc o jakiś serwerze do słowa <em>serwer</em> dodaje się
+ protokół, który obsługuje. Jak możemy pamiętać np. z rozdziału 7,
+ nie które serwery domyślnie nie są usługami sieciowymi (chociaż mogą,
+ wystarczy odpowienio jes skonfigurować).
+ </p>
+ <p>
+ Usługi sieciowe mają za zadanie udostępniać dane poprzez wybrane
+ protokoły. Na przykład coś co nazywamy przeglądarką internetową
+ opiera swoje działanie na protokole HTTP bądź jego bezpieczeniejszej
+ wersji w postacji protokołu HTTPS. Programy pocztowe wykorzystują
+ protokoły SMTPS oraz POP3S lub IMAPS. Wiele różnych aplikacji
+ sieciowych może wykorzystywać różne protokoły lub samodzielnie
+ implementować format danych przesyłanych przez sieć. Nie mniej jednak
+ wszystkie te protokoły rezydują w <strong>warstwie aplikacji</strong>
+ czwartej warstwie modelu TCP/IP.
+ </p>
+ <p>
+ W tym rozdziale nadal pozostaniemy w sieciach. Przeanalizujemy
+ działanie protokołu HTTP. Omówimy sobie usługę sieciową na podstawie
+ SSH. Dowiemy się jak uruchamiane były, nie które specyficzne usługi
+ i jak są uruchamiane teraz. Sprawdzimy sobie narzędzia diagnostyczne,
+ które pozwolą nam na sprawdzenie dostępności usługi ale również
+ monitorowanie przesłanych przez nia i do niej danych. Na koniec
+ zajmiemy się zdalnym wywołaniem procedur (RPC) oraz omówimy sobie
+ podstawowe zagadnienia związane z bezpieczeństwem.
+ Tematem zaawansowamym będą gniazda.
+ </p>
+ <h2 id="10.1.httpanalysis">10.1. Analiza HTTP</h2>
+ <p>
+ Na wstępie omówilśmy sobie co tak naprawdę znajduje się w warstwie
+ aplikacji. Aby była możliwość zapewnienia bezbłędnego działania
+ wielu znanych protokołów, które no men omen są podstawą komunikacji
+ w internecie, zespoły odpowiedzialne za implementacje tych standardów
+ często umieszczają w swoich programach klienckich możliwośc analizy
+ przesyłanych danych. W tym podrozdziale skupimy się głównie na jednym
+ protokole i jednym narzędziu umożliwiającym śledzenie danych
+ przesyłanych za pomocą protokołu. Jednak w podrozdziale poświęconym
+ narzędziom dianostycznym dowiemy się, że możemy sprawdzić większość
+ usług, za pomocą kilku narzędzi.
+ </p>
+ <p>
+ W większości dystrybucji dostępne jest narzędzie
+ <strong>curl</strong> jest ono nagminnie wykorzystywane do pobierania
+ plików za pomocą protokołu HTTP w terminalu. Program ten jako, że
+ wykorzystuje protokół HTTP/S posiada również możliwość prześledzenia
+ transmisji. Jako przykład wykorzystamy serwis pogodowy, który
+ przesyła obecną sytuację pogodową (lub dwu-dniową prognozę) za ASCII.
+ Dla przykładu:
+ </p>
+<pre class="code-block">
+xf0r3m@immudex:~$ curl wttr.in/Warszawa?0\&lang=pl
+Pogoda w: Warszawa
+
+ \ / Słonecznie
+ .-. 21 °C
+ ― ( ) ― → 9 km/h
+ `-’ 10 km
+ / \ 0.0 mm
+</pre>
+ <p>
+ Na podstawie wyścia tego polecenia, ciężko jest na prierwszy rzzut
+ oka dostrzec, że jest to strona internetowa, ale tak właśnie jest.
+ Chcąc przeanalizować jak wygląda komunikacja za pomocą protokołu
+ HTTP należy wydać następujące polecenie:
+ </p>
+<pre class="code-block">
+xf0r3m@immudex:~$ curl --trace-ascii curl.log wttr.in/Warszawa?0\&lang=pl
+</pre>
+ <p>
+ Opcja <code class="code-inline">--trace-ascii</code> mówi programowi
+ <em>curl</em> aby zapisywał on komunikaty diagnostyczne. Dodatkowo
+ ta opcja wymaga podania pliku przeznaczonego na dane wyjściowe. W
+ moim przypadku jest <em>curl.log</em>. Poniżej znajduje się jego
+ zawartość, pominąłem na poniższym przykładzie dane zwracane przez
+ polecenie (są one normalnie dostępne w terminalu po wydaniu
+ polecenia).
+ </p>
+<pre class="code-block">
+== Info: Trying 5.9.243.187:80...
+== Info: Connected to wttr.in (5.9.243.187) port 80 (#0)
+=> Send header, 89 bytes (0x59)
+0000: GET /Warszawa?0&lang=pl HTTP/1.1
+0022: Host: wttr.in
+0031: User-Agent: curl/7.74.0
+004a: Accept: */*
+0057:
+== Info: Mark bundle as not supporting multiuse
+<= Recv header, 17 bytes (0x11)
+0000: HTTP/1.1 200 OK
+<= Recv header, 32 bytes (0x20)
+0000: Access-Control-Allow-Origin: *
+<= Recv header, 21 bytes (0x15)
+0000: Content-Length: 314
+<= Recv header, 41 bytes (0x29)
+0000: Content-Type: text/plain; charset=utf-8
+<= Recv header, 37 bytes (0x25)
+0000: Date: Wed, 23 Aug 2023 08:23:51 GMT
+<= Recv header, 2 bytes (0x2)
+0000:
+<= Recv data, 314 bytes (0x13a)
+0080: . .[38;5;226m ... ( ) ... .[0m .[1m....[0m .[38;5;154m9.[0
+00c0: m km/h.[0m . .[38;5;226m `-... .[0m 10 km.[0m
+0100: . .[38;5;226m / \ .[0m 0.0 mm.[0m .
+== Info: Connection #0 to host wttr.in left intact
+</pre>
+ <p>
+ Pierwsze dwie linie, są to linie informujące nas o uzyskanym adresie
+ IP oraz o tym czy połącznie powiodło się. Jeśli tak jest, to wówczas
+ wysyłany jest <strong>nagłówek</strong>, - w nagłówkach HTTP
+ przeważnie znajdują się informacje kontrolne dla programów, które
+ będą zajmować się interpretowaniem treści przesłanej przez serwer.
+ No właśnie. Można by na logikę rzecz ująć, że to przeglądarka powinna
+ pobrać żądaną stronę WWW. W rzeczywistości to klient przesyła
+ jedynie nagłówek z żądaniem. Przyglądając się pierwszej linii
+ nagłówka
+ rozpoczynajcego się liczbą: <code class="code-inline">0000</code>
+ (Ta liczba to bajt rozpoczęcią tych danych w ładunku/bloku danych
+ przesyłanych w pakietach sieciowych). Zawiera ona słowo kluczowe
+ <code class="code-inline">GET</code> Następnie występuje wartość
+ żądania (czego sobie życzysz), na podstawie tych informacji skrypt
+ jest wstanie zwrócić odpowiedni stan pogodowy, w przypadku kiedy
+ poprostu odwiedzamy jakąś witrynę to najczęściej po słowie
+ <em>GET</em> występuje ukośnik (<strong>/</strong>). Serwery wówczas
+ interpretują to, że żądanie dotyczy głównie pliku <em>index.html</em>
+ zapisanego w katalogu przypisanym na serwerze do danej witryny.
+ </p>
+ <p>
+ Uwaga! Jeden serwer WWW, może utrzymać kilka jak nie kilkanaście lub
+ kilkadziesiąt różnych stron internetowych. Wszystko zależy od jego
+ ustawień oraz wydajności sprzętowej, która go utrzymuje. Dlatego też
+ wiele stron może kierowanych pod jeden adres IP. Taka funkcjonalność
+ nazywa się <strong>hostingiem</strong>.
+ </p>
+ <p>
+ W naszym przypadku również żądamy głównego pliku tego hostingu, w
+ nagłówku natomiast przekazujemy dane, które pomogą w uzyskaniu
+ żądanych przez nas danych. Jest to jedna z cech protokołu HTTP. Dane
+ (głównie do aplikacji, ponieważ statyczne strony rzadko interpretują
+ jakieś dane) mogą być przekazywane jako rozwinięcie adresów jest to
+ tak zwana <em>metoda GET</em> lub w postaci odrębnego pakietu danych
+ poza widocznością dla zwykłego użytkownika - <em>metoda POST</em>.
+ Przy użyciu <em>metody POST</em> najczęściej przesyłane są dane
+ uzupełnionych formularzy na stronach WWW. Po danych przekazywanych
+ aplikacji (w tym przypadku) wstepują już informacje kontrolne dla
+ samego protokołu HTTP w linii <em>0022</em> (będę używał takich
+ oznaczeń) występuje pole nagłówka
+ <code class="code-inline">Host:</code> zawiera ono nazwę hosta do,
+ którego kierujemy nasze żądanie. Następne pole nagłówka to
+ <code class="code-inline">User Agent:</code>, to pole zawiera
+ informacje jakiego programu klienckiego WWW używamy. Ta informacja
+ jest zapisywana w plikach dziennika serwera wraz z adresem IP.
+ Narzędzia takie jak <em>curl</em> lub podobny mu i bardziej
+ powszechny <em>wget</em> pozwalają na zmianę tej wartości, za pomocą
+ jednej opcji możemy podać się za np. program indeksujący jednej z
+ wyszukiwarek. Trzecim polem jest rodzaje danych jakie może
+ zinterpretować, polecenie to służy głównie pobieraniu treści więc
+ rzadko kiedy je interpretuje. Wyjątkiem może być omawiany przez nas
+ przykład. Ostatnim pole jest znak nowego wiersza, który kończy
+ nagłówek żądania. Teraz następuje jego przesłanie i oczekiwnaie na
+ odpowiedź serwera.
+ </p>
+ <p>
+ W przypadku odpowiedzi jak możemy zauważyć przesyłanych jest wiele
+ nagłówków przedstawiających pojedyńcze pola. Nie będe ich tutaj
+ wszystkich opisywał, jednak na uwagę zasługuję jedna informacja,
+ która została wcześniej pominięta. Otóż, w polu metody żądania lub
+ w pierwszym naglówku odpowiedzi znajduje się wykorzystywana w
+ transmisjii wersja protokołu HTTP. Wersja 1.1 jest obecnie
+ standardem, jednak obecnie w stanie proponowanych standardów są
+ wersje 2 i 3. Seria nagłówków odpowiedzi kończy się w taki sam
+ sposób jak w przypadku nagłówka żądania, znakiem nowego wiersza.
+ Następnie odebrany zostaje pakiet danych a dane w nim zawarte
+ trafiają do użytkownika.
+ </p>
+ <p>
+ Tak moglibyś to wywnioskować na podstawie danych diagnostycznych
+ zwróconych przez program <em>curl</em>. Wygląda to nieco inaczej, ale
+ różnice występują tylko w przedstawieniu danych. Otóż otrzymując
+ pakiet protokołu HTTP, nie ma w nim podziału na sekcje nagłówka i
+ danych. Nie ma także dwóch odrębnych pakietów. Wszystko spakowane
+ jest w jednej paczce, a <em>curl</em> na podstawie znaku nowego
+ wiersza jest jedynie oddzielić te dane.
+ </p>
+ <p>
+ Innym sposobem na wejście interakcje np. z protokołem HTTP jest
+ wykorzystanie zapomnianego już programu <strong>Telnet</strong>.
+ <em>Telnet</em> kiedyś służył do tego do czego służy teraz
+ protokół SSH. Do zdalnego połączenia się z powłoką.
+ Telnet sam w sobie również jest protokołem. Obecnie telnet rzadko
+ jest spotykany w swojej pierwotnej formie, chyba że w postaci
+ lokalnej konsoli w systemach wbudowanych.
+ </p>
+<pre class="code-block">
+xf0r3m@immudex:~$ telnet example.org 80 > telnet.log
+Trying 93.184.216.34...
+Connected to example.org.
+Escape character is '^]'
+GET / HTTP/1.1
+Host: example.org
+
+HTTP/1.1 200 OK
+Age: 126394
+Cache-Control: max-age=604800
+Content-Type: text/html; charset=UTF-8
+Date: Wed, 23 Aug 2023 11:28:50 GMT
+Etag: "3147526947+ident"
+Expires: Wed, 30 Aug 2023 11:28:50 GMT
+Last-Modified: Thu, 17 Oct 2019 07:18:26 GMT
+Server: ECS (dcb/7F7F)
+Vary: Accept-Encoding
+X-Cache: HIT
+Content-Length: 1256
+...
+</pre>
+ <p>
+ Po wielokropku występuje już tylko kod HTML strony. Polecenie
+ <code class="code-inline">telnet</code> wymaga aby port, pod który
+ należy się podłączyć. Aby otrzymać odpowiedź musimy metodę
+ (<code class="code-inline">GET</code>), ewentualne dane/żądany plik
+ (<code class="code-inline">/</code>), wersje protokołu
+ (<code class="code-inline">HTTP/1.1</code>) w drugiej lini nagłówka
+ należy podać nazwę hosta
+ (<code class="code-inline">Host: example.org</code>), ze względu na
+ to aby serwer WWW wiedział z jakiej witry przesłać odpowiedź.
+ </p>
+ <p>
+ Protokół jest może trochę mało interaktwny przy takim połączeniu, ale
+ np. usługi pocztowe są już bardziej skore do <em>rozmowy</em>.
+ </p>
+ <h2 id="10.2.networkservers">10.2. Serwery sieciowe</h2>
</div>
<p style="margin: 15px; padding: 0; outline: 0;">
2022; COPYLEFT; ALL RIGHTS REVERSED;
projects / mmdev.git / commitdiff