3 Funkcjonalność i protokoły warstwy aplikacji
3.0 Wprowadzenie do rozdziału
3.0.1 Wprowadzenie do rozdziału
Strona 1:
Większość z nas swoje doświadczenia z siecią Internet kojarzy z przeglądaniem stron WWW, obsługą poczty elektronicznej oraz współdzieleniem plików. Te aplikacje (oraz wiele innych) stanowią interfejs sieci, dzięki któremu możemy stosunkowo łatwo wysyłać i otrzymywać informacje. Typowe aplikacje są na tyle intuicyjne, że możemy z nich korzystać nie znając ich budowy. Jednakże profesjonalista powinien wiedzieć, w jaki sposób aplikacje formatują, transmitują i interpretują komunikaty przesyłane przez sieć.
Zrozumienie mechanizmów umożliwiających komunikację poprzez sieć staje się łatwiejsze, jeśli użyjemy warstwowej struktury modelu OSI (Open System Interconnection). W tym rozdziale skupimy się na roli jednej z warstw - warstwie aplikacji - oraz jej komponentach: aplikacjach, usługach i protokołach. Zbadamy w jaki sposób te trzy elementy umożliwiają komunikację w sieci.
Po zakończeniu tego rozdziału będziesz potrafił:
Opisać w jaki sposób funkcje trzech wyższych warstw modelu OSI dostarczają usługi sieciowe aplikacjom użytkownika końcowego.
Opisać w jaki sposób protokoły warstwy aplikacji modelu TCP/IP zapewniają usługi określone przez wyższe warstwy modelu OSI.
Zdefiniować, w jaki sposób ludzie wykorzystują warstwę aplikacji do komunikacji w sieci.
Opisać funkcje dobrze znanych aplikacji TCP/IP (m.in. WWW, poczta elektroniczna) oraz związane z nimi usługi (HTTP, DNS, SMB, DHCP, SMTP/POP oraz Telnet).
Opisać proces współdzielenia plików za pomocą aplikacji peer-to-peer oraz protokołu Gnutella.
Wyjaśnić w jaki sposób protokoły umożliwiają aplikacjom uruchomionym na jednym urządzeniu wysyłanie i odbieranie danych do/z wielu różnych urządzeń sieciowych.
Używać narzędzi do analizy sieci w celu przedstawienia i wyjaśnienia, jak działają popularne aplikacje użytkownika.
3.1 Aplikacje - interfejs pomiędzy sieciami
3.1.1 Modele OSI i TCP/IP
Strona 1:
Model odniesienia OSI (ang. Open Systems Interconnection) to abstrakcyjny model zbudowany w oparciu o warstwy, który został opracowany celem ułatwienia projektowania protokołów sieciowych. Model OSI dzieli procesy sieciowe na siedem logicznych warstw, z których każda ma unikalną funkcjonalność oraz przypisane określone usługi i protokoły.
W ramach tego modelu informacje przechodzą z jednej warstwy do następnej. Proces rozpoczyna się na hoście źródłowym. Dane przetwarzane są najpierw przez warstwę aplikacji a następnie przechodzą w dół poprzez kolejne warstwy w hierarchii aż do warstwy fizycznej. Kolejnym etapem jest transmisja danych poprzez kanał komunikacyjny. Po dotarciu do hosta docelowego dane podlegają odwrotnemu procesowi, tj. rozpoczynają wędrówkę od warstwy fizycznej a kończą na warstwie aplikacji. Rysunek przedstawia kolejne etapy tego procesu.
Warstwa aplikacji jest najwyższą warstwą zarówno w modelu odniesienia OSI, jak i w modelu TCP/IP. Jest to warstwa zapewniająca interfejs pomiędzy aplikacjami, których używamy do komunikacji, a siecią poprzez którą nasze komunikaty są transmitowane. Protokoły warstwy aplikacji są używane do wymiany danych pomiędzy programami uruchomionymi na hoście źródłowym i hoście docelowym. Istnieje wiele protokołów warstwy aplikacji, przy czym ciągle pojawiają się nowe a stare są rozwijane i modyfikowane.
Strona 2:
Chociaż zestaw protokołów TCP/IP został opracowany przed zdefiniowaniem modelu OSI, to funkcjonalność protokołów warstwy aplikacji modelu TCP/IP z grubsza pasuje do struktury trzech górnych warstw modelu OSI: aplikacji, prezentacji oraz sesji.
Większość protokołów warstwy aplikacji modelu TCP/IP zostało stworzonych przed pojawieniem się komputerów osobistych, graficznych interfejsów użytkownika czy obiektów multimedialnych. W rezultacie protokoły te realizują niewiele funkcji określonych w warstwach prezentacji i sesji modelu OSI.
Warstwa prezentacji
Główne zadania warstwy prezentacji:
Kodowanie i konwersja danych warstwy aplikacji - dzięki temu dane pochodzące z urządzenia źródłowego mogą być interpretowane przez odpowiednie aplikacje na urządzeniu docelowym.
Kompresja/dekompresja danych.
Szyfrowanie danych na potrzeby transmisji oraz deszyfrowanie danych odebranych przez urządzenie docelowe.
Implementacje warstwy prezentacji nie są typowo związane ze szczególnym stosem protokołów. Wymienimy niektóre standardy video oraz grafiki. Dobrze znane standardy video to m.in. QuickTime oraz MPEG (ang. Motion Picture Experts Group). Stworzona przez firmę Apple specyfikacja QuickTime opisuje standard video oraz audio, natomiast MPEG jest standardem video opisującym sposób kompresji i kodowania.
Wśród dobrze znanych formatów plików graficznych można wyróżnić: GIF (ang. Graphics Interchange Format), JPEG (ang. Joint Photographic Experts Group) oraz TIFF (ang. Tagged Image File Format). GIF i JPEG są standardami kompresji i kodowania, natomiast TIFF jest klasycznym formatem zapisu plików graficznych.
Warstwa sesji
Warstwa sesji, jak sugeruje jej nazwa, jest odpowiedzialna za tworzenie i utrzymywanie sesji komunikacyjnych pomiędzy aplikacjami: źródłową i docelową. Warstwa sesji prowadzi wymianę informacji: rozpoczyna konwersacje, utrzymuje ich aktywność i wznawia je, jeśli zostały utracone lub są od dłuższego czasu bezczynne.
Większość aplikacji, jak np. przeglądarka WWW czy klient poczty elektronicznej, łączy funkcjonalność warstw: 5, 6 i 7 modelu OSI.
Strona 3:
Powszechnie używane protokoły warstwy aplikacji modelu TCP/IP zapewniają wymianę informacji między użytkownikami. Protokoły te określają format i informacje kontrolne konieczne dla typowej komunikacji w sieci Internet. Wśród tych protokołów wyróżniamy:
DNS (ang. Domain Name System) - protokół używany do odwzorowywania nazw w sieci Internet na adresy IP;
HTTP (ang. Hypertext Transfer Protocol) - protokół używany do przesyłania plików tworzących strony WWW;
SMTP (ang. Simple Mail Transfer Protocol) - protokół używany do przesyłania wiadomości poczty elektronicznej wraz z załącznikami;
Telnet (ang. Telecommunication Network) - protokół emulacji terminala umożliwiający komunikację ze zdalnym urządzeniem;
FTP (ang. File Transfer Protocol) - protokół używany do interaktywnego przesyłania plików pomiędzy systemami.
Protokoły TCP/IP są z reguły zdefiniowane w dokumentach RFC (ang. Request For Comments). Dokumenty RFC opisują standardy techniczne zestawu protokołów TCP/IP. Publikacją tych dokumentów zajmuje się organizacja IETF (ang. Internet Engineering Task Force).
3.1.2 Oprogramowanie warstwy aplikacji
Strona 1:
Protokoły warstwy aplikacji obsługują interfejs pomiędzy ludźmi a siecią danych. Kiedy otwieramy okno przeglądarki internetowej lub komunikatora, aplikacja uruchamia się. Program jest umieszczany w pamięci operacyjnej komputera a następnie wykonywany. Każdy program, który został uruchomiony na urządzeniu i aktualnie jest wykonywany, nazywamy procesem.
W warstwie aplikacji istnieją dwa typy oprogramowania (procesów), które umożliwiają dostęp do sieci. Są to aplikacje oraz usługi.
Aplikacje przystosowane do pracy w sieci
Aplikacje są oprogramowaniem (ang. software programs) używanym przez ludzi do komunikacji w sieci. Niektóre aplikacje użytkownika są aplikacjami przystosowanymi do pracy w sieci (ang. network-aware). Takie aplikacje obsługują protokoły warstwy aplikacji i potrafią komunikować się bezpośrednio z protokołami niższych warstw. Przykładami tego typu aplikacji są: klient poczty elektronicznej oraz przeglądarka WWW.
Usługi warstwy aplikacji
Niektóre programy będą potrzebowały pomocy ze strony usług warstwy aplikacji (np. przesyłanie plików czy drukowanie w sieci). Usługi te, pomimo że są transparentne dla użytkownika, łączą go z siecią i przygotowują dane do wysłania. Różne typy danych - tekst, grafika czy video - wymagają różnych usług sieciowych, aby zapewnić im właściwe przygotowanie do przetworzenia przez funkcje występujące w niższych warstwach modelu OSI.
Każda aplikacja lub usługa sieciowa wykorzystuje protokoły zdefiniowane przez standardy i formaty danych. Bez protokołów nie byłoby powszechnego sposobu formatowania i przekazywania danych w sieci. Aby zrozumieć funkcje różnych usług sieciowych, konieczne jest zapoznanie się z odpowiednimi protokołami, które kierują ich operacjami.
3.1.3 Aplikacje użytkownika, usługi i protokoły warstwy aplikacji
Strona 1:
Jak wspomniano poprzednio, warstwa aplikacji używa protokołów, które są implementowane w aplikacjach i usługach. Podczas gdy aplikacje umożliwiają użytkownikom tworzenie komunikatów, a usługi warstwy aplikacji obsługują interfejs sieci, to protokoły zapewniają reguły do obsługi danych. Wszystkie trzy komponenty mogą zostać użyte przez pojedynczy wykonywalny program i mogą one używać tej samej nazwy. Na przykład zwrot "Telnet" odnosi się zarówno do aplikacji, usługi, jak i protokołu.
W modelu OSI aplikacje komunikujące się bezpośrednio z użytkownikami umiejscowione są na szczycie stosu. Warstwa aplikacji działa w oparciu o funkcje niższych warstw (podobnie jak pozostałe warstwy) w celu sfinalizowania procesu komunikacji. W warstwie aplikacji protokoły określają komunikaty wymieniane pomiędzy hostem źródłowym i docelowym, składnię komend, typ i format transmitowanych danych oraz odpowiednie metody powiadamiania o błędach i odzyskiwania danych.
3.1.4 Funkcje protokołów warstwy aplikacji
Strona 1:
Protokoły warstwy aplikacji stosowane są przez urządzenia źródłowe oraz docelowe podczas sesji komunikacyjnej. Protokoły na obu hostach (źródłowym i docelowym) muszą do siebie pasować, aby komunikacja mogła zakończyć się sukcesem.
Protokoły ustalają zasady rządzące wymianą danych pomiędzy aplikacjami a usługami uruchomionymi na uczestniczących w komunikacji urządzeniach. Protokoły określają struktury danych oraz typy przesyłanych komunikatów. Komunikat może reprezentować żądanie usługi, potwierdzenie, dane, status lub błąd. Protokoły definiują również sposób konwersacji zapewniając, że wysłany komunikat spotka się z właściwą reakcją oraz że w czasie dotarcia danych zostaną uruchomione właściwe usługi.
W sieciach danych komunikuje się wiele różnych typów aplikacji. Dlatego usługi warstwy aplikacji muszą implementować złożone protokoły, aby zapewnić pożądany poziom komunikacji. Każdy protokół ma określone przeznaczenie i jest tak skonstruowany, aby je spełniać. Protokoły muszą być bezwzględnie implementowane zgodnie z ich specyfikacją, tak aby zapewnić ich zgodną pracę z niższymi warstwami.
Aplikacje i usługi mogą korzystać ze złożonych protokołów również w trakcie pojedynczej konwersacji. Jeden z protokołów może określać, w jaki sposób nawiązać połączenie, a inny - definiować procedurę transmisji danych w przypadku, gdy komunikat jest przesyłany do następnej niższej warstwy.
3.2 Ustalanie zasad dla aplikacji i usług
3.2.1 Model Klient-Serwer
Strona 1:
W czasie pracy na urządzeniu przyłączonym do sieci (np. PC, laptop, PDA, telefon komórkowy) możemy korzystać z danych przechowywanych na innym urządzeniu. W takim przypadku musimy uzyskać dostęp do zdalnego urządzenia, na którym te dane są fizycznie przechowywane.
Model Klient-Serwer
W modelu klient-serwer urządzenie żądające informacji nazywane jest klientem, natomiast urządzenie odpowiadające na żądanie - serwerem. Procesy komunikacji klienta i serwera zaliczane są do zadań warstwy aplikacji. Klient rozpoczyna wymianę danych wysyłając żądanie do serwera, który odpowiada poprzez wysłanie jednego lub więcej strumieni danych do klienta. Protokoły warstwy aplikacji opisują format żądań i odpowiedzi pomiędzy klientami i serwerami. Oprócz rzeczywistego przesyłania, wymiana danych może również wymagać przenoszenia informacji kontrolnych, takich jak uwierzytelnianie użytkownika czy informacje identyfikujące przesyłane dane.
Przykładem sieci klient-serwer jest środowisko korporacyjne, gdzie pracownicy korzystają z firmowego serwera poczty elektronicznej do wysyłania, odbierania i przechowywania korespondencji. Klient poczty elektronicznej, zainstalowany na komputerze pracownika, wysyła żądanie do serwera w celu sprawdzenia, czy na serwerze są nowe wiadomości. Serwer odpowiada wysyłając żądany e-mail do klienta.
Chociaż dane są zwykle opisywane jako przepływ informacji z serwera do klienta, to pewne dane przesyłane są również z klienta do serwera. Strumień danych może być równy w obu kierunkach, ale może być też większy w kierunku od klienta do serwera. Na przykład klient może przesyłać pliki do serwera w celu ich gromadzenia tam. Przesyłanie danych z klienta do serwera nazywane jest wysyłaniem (ang. upload), natomiast z serwera do klienta pobieraniem (ang. download).
3.2.2 Serwery
Strona 1:
W żargonie sieciowym: urządzenie, które odpowiada na żądania aplikacji klienta, nazywane jest serwerem. Serwer jest zwykle komputerem, który przechowuje dane w celu współdzielenia ich z systemami klienckimi. Na przykład strony WWW, dokumenty, bazy danych, zdjęcia, filmy czy pliki audio - mogą być przechowywane na serwerze i dostarczane na żądanie klienta. W przypadku drukarki sieciowej, serwer wydruku otrzymuje od klienta żądania wydruku na określonej drukarce.
Różne typy aplikacji serwera mogą mieć różne wymagania w stosunku do klienta. Niektóre serwery mogą wymagać uwierzytelnienia użytkownika w celu weryfikacji, czy użytkownik ma prawo dostępu do żądanych danych lub czy może wykonać konkretną operację. Takie serwery funkcjonują w oparciu o listę kont użytkowników oraz autoryzację lub prawa dostępu (do danych i operacji) przyznane dla każdego użytkownika. Np. jeśli używając klienta FTP chcemy przesłać dane do serwera FTP, możemy mieć prawo do zapisu tych danych w swoim katalogu, ale równocześnie możemy nie mieć praw do czytania innych plików na tym serwerze.
W architekturze klient-serwer serwer uruchamia usługę lub proces nazywany demonem. Jak większość usług, demony zwykle uruchamiane są w tle i nie są bezpośrednio kontrolowane przez użytkownika. Demony "nasłuchują" żądań napływających od klienta, tzn. są one zaprogramowane tak, aby odpowiadać na każde żądanie, które przybyło do serwera i które jest skierowane do usługi obsługiwanej przez demona. Kiedy demon "słyszy" żądanie klienta, to najpierw wymienia z nim wymagane przez protokół komunikaty, a następnie przesyła żądane dane (we właściwym formacie).
3.2.3 Usługi i protokoły warstwy aplikacji
Strona 1:
Pojedyncza aplikacja może używać wiele różnych usług wspierających warstwę aplikacji. W ten sposób na jedno żądanie użytkownika, np. żądanie strony WWW, w rzeczywistości może składać się wiele oddzielnych żądań. A dla każdego żądania może zostać wykonanych wiele procesów. Na przykład klient, do sformułowania jednego żądania, może wymagać kilku oddzielnych procesów.
Co więcej, serwery zwykle otrzymują wiele żądań od klientów w tym samym czasie. Na przykład serwer Telnet może mieć wiele połączeń równocześnie. Wtedy każde żądanie pochodzące od różnych klientów musi zostać rozpatrzone jednocześnie i niezależnie, aby komunikacja zakończyła się powodzeniem. Dzięki wsparciu funkcji niższych warstw, procesy i usługi warstwy aplikacji mogą skutecznie zarządzać wielokrotnymi konwersacjami.
3.2.4 Sieci i aplikacje Peer-to-Peer (P2P)
Strona 1:
Model Peer-to-Peer
W teorii sieci komputerowych oprócz modelu klient-serwer występuje również model peer-to-peer. Model ten dotyczy architektury sieci peer-to-peer oraz aplikacji peer-to-peer (P2P). Obie formy mają podobne cechy, jednak w praktyce działają inaczej.
Sieci Peer-to-Peer
W sieci peer-to-peer dwa komputery (lub więcej) są połączone ze sobą poprzez sieć i mogą one współdzielić zasoby (tj. drukarki czy pliki) bez pomocy dedykowanego serwera. Każde podłączone urządzenie końcowe (określane mianem peer) może działać jako serwer lub klient. Jeden komputer pełniący rolę serwera dla jednej transakcji może jednocześnie służyć jako klient dla innej. Role (klient i serwer) są ustalane na podstawie żądań.
Prosta sieć domowa z dwoma połączonymi komputerami, które współdzielą drukarkę, jest przykładem sieci peer-to-peer. Użytkownicy tej sieci mogą również przygotować swoje komputery do współdzielenia plików, uruchomienia gier sieciowych czy współdzielenia połączenia internetowego. Innym przykładem funkcjonalności sieci peer-to-peer są podłączone do dużej sieci dwa komputery, które używają oprogramowania w celu współdzielenia swoich zasobów poprzez sieć.
W przeciwieństwie do modelu klient-serwer, który wykorzystuje dedykowane serwery, sieci peer-to-peer swoje zasoby decentralizują. Dane nie muszą być przechowywane na dedykowanym serwerze, żeby mogły zostać udostępnione. Mogą być one ulokowane na dowolnym urządzeniu w sieci. Większość dzisiejszych systemów operacyjnych wspiera współdzielenie plików i drukarek bez konieczności instalacji dodatkowego oprogramowania serwera. Sieci peer-to-peer zwykle nie wymagają użycia kont użytkowników, praw dostępu czy monitoringu. Zatem sporym wyzwaniem byłoby tutaj narzucenie polityki bezpieczeństwa i dostępu do zasobów, tym bardziej że taka sieć łączy więcej niż kilka komputerów. Na każdym urządzeniu w sieci P2P konta użytkowników oraz prawa dostępu muszą być konfigurowane indywidualnie.
Strona 2:
Aplikacje Peer-to-Peer
Aplikacje peer-to-peer (P2P), w przeciwieństwie do sieci peer-to-peer, pozwalają urządzeniom działać jako klient i serwer w ramach tej samej komunikacji. W tym modelu każdy klient jest serwerem, a każdy serwer - klientem. Oba urządzenia mogą inicjować komunikację i oba w równym stopniu biorą udział w jej procesie. Jednakże aplikacja peer-to-peer wymaga, aby każde urządzenie dostarczało interfejsu użytkownikom, a usługi były uruchamiane w tle. Uruchomienie określonej aplikacji peer-to-peer uruchamia w tle wymagane usługi i równocześnie wywołuje interfejs użytkownika. Dopiero wówczas możliwa jest bezpośrednia komunikacja urządzeń.
Niektóre aplikacje P2P wykorzystują system hybrydowy, w którym współdzielone zasoby są zdecentralizowane, ale odsyłacze (indeksy) do ich lokalizacji są gromadzone w scentralizowanym katalogu. W systemie hybrydowym każde urządzenie ma dostęp do serwera przechowującego indeksy i w ten sposób może uzyskać informacje o lokalizacji poszukiwanego zasobu (zwykle jest to inne urządzenie). Rola serwera przechowującego indeksy kończy się w momencie połączenia dwóch urządzeń. Połączone urządzenia komunikują się dalej już z pominięciem serwera.
Aplikacje peer-to-peer mogą być stosowane w sieciach: peer-to-peer, klient-serwer oraz w sieci Internet.
3.3 Protokoły i usługi warstwy aplikacji - przykłady
3.3.1 Protokół i usługa DNS
Strona 1:
Teraz, kiedy już lepiej rozumiemy, w jaki sposób aplikacje dostarczają interfejs dla użytkownika oraz umożliwiają dostęp do sieci, przyjrzyjmy się powszechnie używanym protokołom.
Jak zobaczymy w dalszej części kursu, warstwa transportowa używa schematu adresowania opartego na numerach portów. Numery portów identyfikują aplikacje i usługi warstwy aplikacji, które są źródłem i celem danych. Programy serwera zazwyczaj używają uprzednio zdefiniowanych numerów portów, które są powszechnie znane przez klientów. Podczas analizy różnych protokołów i usług warstwy aplikacji modelu TCP/IP często będziemy odnosić się do numerów portów (TCP i UDP), które są związane z usługami. Niektóre z tych usług to:
DNS (ang. Domain Name System) - Port 53 TCP/UDP
HTTP (ang. Hypertext Transfer Protocol) - Port 80 TCP
SMTP (ang. Simple Mail Transfer Protocol) - Port 25 TCP
POP (ang. Post Office Protocol) - Port 110 UDP
Telnet - Port 23 TCP
DHCP (ang. Dynamic Host Configuration Protocol) - Port 67 UDP
FTP (ang. File Transfer Protocol) - Porty: 20 i 21 TCP
DNS
Urządzenia mogą brać udział w wysyłaniu i odbieraniu komunikatów dzięki numerycznym adresom IP, którymi są oznaczane. Jednakże większość ludzi ma problemy z zapamiętaniem coraz to większej liczby adresów numerycznych. W związku z tym powstał system nazw domenowych, umożliwiający przekształcić adres numeryczny na prostą o rozpoznawalną dla człowieka nazwę.
W Internecie takie nazwy domen jak np. www.cisco.com są dużo łatwiejsze do zapamiętania niż adres 198.133.219.25, który jest aktualnym numerycznym adresem serwera. Jeśli zatem Cisco podejmie decyzję o zmianie adresu IP, to będzie to niezauważalne dla użytkownika, dopóki nazwa domeny www.cisco.com nie zostanie zmieniona. Nowy adres numeryczny zostanie połączony z istniejącą nazwą domeny i łączność zostanie utrzymana. Kiedy sieci były niewielkich rozmiarów, utrzymywanie mapowania pomiędzy nazwami domenowi a adresami, które reprezentują, nie było trudnym zadaniem. Jednakże z czasem sieci rozpoczęły swoją ekspansję, a liczba urządzeń zaczęła rosnąć. W tych warunkach manualne uzupełnianie bazy stało się niewykonalne.
W celu automatycznego wiązania nazw domen z adresami utworzono tzw. system nazw domenowych - DNS. DNS wykorzystuje zbiór rozproszonych serwerów, które tłumaczą nazwy na związane z nimi numeryczne adresy.
Protokół DNS definiuje zautomatyzowaną usługę, która dopasowuje nazwy do wymaganych numerycznych adresów sieciowych. Opisuje format zapytań i odpowiedzi oraz formaty danych. Protokół DNS w procesie komunikacji używa pojedynczej struktury informacji zwanej komunikatem. Format ten używany jest do wszelkiego typu zapytań klienta i odpowiedzi serwera, informacji o błędach czy komunikatów RR (ang. Resource Record) przesyłanych pomiędzy serwerami.
Strona 2:
DNS jest usługą opartą na modelu klient-serwer. Jednak różni się ona od innych usług tego typu. Większość usług używa klienta, który jest aplikacją (np. przeglądarka stron WWW czy klient poczty elektronicznej), natomiast klient DNS działa jako usługa sama w sobie. Klient DNS, czasem określany mianem DNS resolver, wspiera rozwiązywanie nazw dla innych aplikacji sieciowych oraz usług, które tego potrzebują.
W czasie konfiguracji urządzenia sieciowego zwykle podajemy jeden lub więcej adresów serwerów DNS, które klient DNS może wykorzystać do odwzorowywania nazw. Zwykle dostawca usług internetowych przydziela adresy, które mogą być używane przez serwery DNS. Kiedy aplikacja użytkownika żąda połączenia ze zdalnym urządzeniem za pomocą nazwy, klient DNS wysyła zapytanie o odwzorowanie tej nazwy na adres numeryczny do jednego ze zdefiniowanych serwerów DNS.
Systemy operacyjne komputerów udostępniają użytkownikom narzędzie zwane nslookup, które umożliwia manualne wysłanie zapytania do serwera DNS w celu odwzorowania danej nazwy hosta. Narzędzie to może być również stosowane w celu rozwiązywania problemów związanych z odwzorowywaniem nazw lub do weryfikacji aktualnego stanu serwerów DNS.
Jak widzimy na rysunku, wydanie polecenia nslookup powoduje wyświetlenie domyślnego serwera DNS skonfigurowanego dla naszego hosta. W naszym przykładzie serwerem DNS jest dns-sjk.cisco.com, który ma adres 171.68.226.120.
Możemy również sprawdzić adres hosta lub domeny wpisując jej nazwę. Pierwsze zapytanie na rysunku dotyczy domeny www.cisco.com. Odpowiadający serwer zwrócił adres 198.133.219.25.
Zapytanie zaprezentowane na rysunku jest tylko prostym przykładem. Narzędzie nslookup posiada również wiele użytecznych opcji pozwalających na szczegółowe badanie i weryfikację procesu DNS.
Strona 3:
Serwer DNS zapewnia odwzorowywanie nazw poprzez demona, który często określany jest mianem named.
Serwer DNS opisuje domeny za pomocą tzw. rekordów zasobowych (ang. resource record, RR). Rekordy te zawierają nazwę, adres oraz typ rekordu.
Przykładowe typy rekordów:
A - adres urządzenia końcowego
NS - autorytatywny serwer nazw
CNAME - umowne nazwy serwerów wraz z ich pełnymi nazwami domenowymi (ang. canonical name lub Fully Qualified Domain Name); używane w sytuacji, gdy wiele usług ma ten sam adres sieciowy, ale każda usługa ma swój własny wpis w DNS
MX - rekord wymiany poczty; mapuje nazwę domenową do listy serwerów odbierających pocztę
Kiedy klient wykonuje zapytanie, proces serwera "named", w celu samodzielnego rozwiązania nazwy, najpierw przegląda własne rekordy. Jeżeli operacja ta zakończy się niepowodzeniem, kontaktuje się z innymi serwerami.
Żądanie może być przesyłane dalej do kilku serwerów, co wydłuża czas i zużywa przepustowość. Z chwilą gdy dopasowanie zostanie odnalezione, informacja zostaje zwrócona do serwera pytającego na początku. Serwer tymczasowo przechowuje adres numeryczny, który został dopasowany do nazwy, w pamięci podręcznej (ang. cache).
Jeśli ta sama nazwa jest żądana ponownie, już pierwszy serwer może zwrócić adres dzięki przechowywaniu wartości w pamięci podręcznej. Przechowywanie adresów w pamięci podręcznej redukuje ruch związany z zapytaniami DNS oraz obciążenie serwerów położonych wyżej w hierarchii. Usługa Klienta DNS, na komputerze PC z systemem operacyjnym Windows, optymalizuje wydajność procesu rozwiązywania nazw DNS poprzez przechowywanie poprzednio odwzorowanych nazw w pamięci. Polecenie ipconfig /displaydns w systemie Windows XP lub 2000 wyświetla wszystkie przechowywane wpisy.
Strona 4:
System nazw domenowych ma strukturę hierarchiczną. Hierarchia wygląda jak odwrócone drzewo z korzeniem (root) na szczycie i gałęziami poniżej.
Serwery root utrzymują rekordy z informacjami o tym, jak osiągnąć serwery domen najwyższego poziomu (ang. top-level domains). Te z kolei mają informacje o serwerach kolejnego poziomu, itd.
Domeny najwyższego poziomu reprezentują typ organizacji lub kraj pochodzenia. Przykładami domen najwyższego poziomu są:
.au - Australia
.co - Kolumbia
.com - działalność komercyjna lub przemysł
.jp - Japonia
.org - organizacja non-profit
Po domenach najwyższego poziomu występują domeny drugiego poziomu, a poniżej nich - domeny kolejnego niższego poziomu.
Każda nazwa domeny jest ścieżką tworzoną w dół odwróconego drzewa. Punktem startowym jest root.
Na przykład (jak pokazano na rysunku) serwer root DNS może nie wiedzieć dokładnie, gdzie serwer pocztowy mail.cisco.com jest umiejscowiony. Jednak analizując utrzymywane rekordy znajduje wpis "com" w domenie najwyższego poziomu. Podobnie, serwery w domenie "com" mogą nie posiadać rekordu dla mail.cisco.com, ale mają one wpis dla domeny cisco.com. Natomiast serwery w domenie cisco.com posiadają rekord (precyzyjniej: rekord MX) dla mail.cisco.com.
System nazw domenowych funkcjonuje w oparciu o hierarchię zdecentralizowanych serwerów, które przechowują i utrzymują rekordy zasobów. Rekordy zasobów rejestrują nazwy domen, które serwer może odwzorować oraz alternatywne serwery, które również mogą przetwarzać żądania. Jeśli dany serwer posiada rekordy zasobów odpowiadające jego poziomowi w hierarchii, to mówi się, że jest on autorytatywny dla tych rekordów.
Na przykład serwer nazw w domenie cisco.netacad.net nie byłby autorytatywny dla rekordu mail.cisco.com, ponieważ ten rekord jest utrzymywany na serwerze domeny wyższego poziomu (serwer nazw w domenie cisco.com).
3.3.2 Usługa WWW i protokół HTTP
Strona 1:
Kiedy w przeglądarce stron WWW wpisujemy adres strony (tzw. URL), przeglądarka nawiązuje połączenie z usługą uruchomioną na serwerze korzystając z protokołu HTTP. URL (ang. Uniform Resource Locator) oraz URI (ang. Uniform Resource Identifier) są terminami, które większość ludzi łączy z adresami WWW.
URL http://www.cisco.com/index.html jest przykładem adresu URL, który odnosi się do określonego zasobu - strony WWW nazwanej index.html, która umieszczona jest na serwerze cisco.com (kliknij kolejno przyciski na rysunku w celu zapoznania się z etapami protokołu HTTP).
Przeglądarki WWW są aplikacjami klienckimi, które są używane do połączeń z siecią WWW (ang. World Wide Web) oraz do dostępu do zasobów przechowywanych na serwerach WWW. Jak w przypadku większości procesów serwera, serwer WWW uruchamia usługę w tle i udostępnia różne typy plików.
W celu dostępu do treści, klient WWW ustanawia połączenie z serwerem i prosi o odpowiednie zasoby. Serwer odpowiada, a przeglądarka po odebraniu zasobów interpretuje dane i prezentuje je użytkownikowi.
Przeglądarki mogą interpretować i prezentować wiele typów danych, m.in. zwykły tekst (ang. plain text) i format HTML (ang. Hypertext Markup Language, język w którym są konstruowane strony WWW). Inne typy danych mogą wymagać odpowiednich usług i programów, które nazywane są wtyczkami (ang. plug-in) lub dodatkami (ang. add-on). Aby pomóc przeglądarce ustalić typ odebranego pliku, serwer określa rodzaj danych, które plik zawiera.
Aby lepiej zrozumieć, w jaki sposób przeglądarka komunikuje się z klientem, spójrzmy jak strona WWW jest otwierana w przeglądarce. W tym celu użyjemy adresu URL: http://www.cisco.com/web-server.htm.
Najpierw przeglądarka interpretuje trzy części adresu URL:
1. http (protokół lub schemat)
2. www.cisco.com (nazwa serwera)
3. web-server.htm (określony plik)
Przeglądarka komunikuje się z serwerem DNS w celu konwersji nazwy www.cisco.com na adres numeryczny, który jest używany do połączenia z serwerem. Przeglądarka, działając zgodnie z wymaganiami protokołu HTTP, wysyła żądanie GET do serwera i pyta o plik web-server.htm. Następnie serwer zwraca kod HTML żądanej strony WWW. W końcu przeglądarka odczytuje kod HTML i formatuje stronę w oknie przeglądarki.
Strona 2:
Protokół HTTP jest jednym z protokołów stosu TCP/IP. Powstał on pierwotnie w celu publikowania i pobierania stron HTML. Obecnie jest używany przez rozproszone kooperujące systemy informacyjne. HTTP jest stosowany do przesyłania danych w sieci WWW - jest jednym z najczęściej używanych protokołów aplikacji.
HTTP jest protokołem typu żądanie/odpowiedź (ang. request/response). Kiedy klient (zwykle przeglądarka WWW) wysyła komunikat z żądaniem strony WWW do serwera, protokół HTTP określa typ tego komunikatu. Podobna sytuacja ma miejsce, gdy serwer wysyła odpowiedź. Trzy najważniejsze typy komunikatów to: GET, POST oraz PUT.
GET jest prośbą klienta o dane. Przeglądarka wysyła żądanie GET w celu pobrania strony WWW z serwera. W momencie gdy serwer otrzymuje żądanie GET (co pokazano na rysunku), odpowiada wierszem opisującym stan (ang. status line), np. HTTP/1.1 200 OK, a następnie przesyła żądany plik, komunikat o błędzie lub inne informacje.
Komunikaty POST oraz PUT są używane w procesie przesyłania danych do serwera WWW. Na przykład, kiedy użytkownik wprowadzi dane do formularza umieszczonego na stronie WWW, POST włączy te dane do wiadomości przesyłanej do serwera.
PUT przesyła dane w postaci plików do serwera WWW.
HTTP nie jest bezpiecznym protokołem. Komunikaty POST wysyłane są do serwera jawnym tekstem, który może zostać przechwycony i przeczytany. Podobnie, odpowiedzi serwera (zwykle strony HTML) również nie są szyfrowane.
W sieci Internet, do bezpiecznej komunikacji z serwerem WWW, stosuje się protokół HTTP Secure (HTTPS). Do ochrony danych przesyłanych pomiędzy klientem i serwerem, HTTPS stosuje algorytmy uwierzytelniania i szyfrowania. HTTPS określa dodatkowe reguły dla przepływu danych pomiędzy warstwą aplikacji i warstwą transportową.
3.3.3 Usługi E-mail i protokoły SMTP/POP
Strona 1:
Poczta elektroniczna (e-mail) - najbardziej popularna usługa sieciowa - zrewolucjonizowała komunikację między ludźmi dzięki swojej prostocie i szybkości. Do poprawnego działania poczty elektronicznej na komputerze lub innym urządzeniu końcowym (PDA, telefon komórkowy) wymagane jest klika aplikacji i usług. Na rysunku obok zaprezentowano dwa przykładowe protokoły warstwy aplikacji: POP (ang. Post Office Protocol) oraz SMTP (ang. Simple Mail Transfer Protocol). Tak jak w przypadku HTTP, protokoły te definiują procesy klient-serwer.
Kiedy ludzie piszą wiadomości e-mail, zwykle używają aplikacji nazywanej klientem poczty elektronicznej lub MUA (ang. Mail User Agent). Agent pocztowy (MUA) pozwala na wysyłanie wiadomości i umieszczanie ich w skrzynkach pocztowych. Oba procesy są niezależne.
Do pobierania wiadomości z serwera pocztowego klient używa protokołu POP lub IMAP. Natomiast proces wysyłania wiadomości opisuje protokół SMTP. Zwykle klient e-mail dostarcza funkcjonalność obu protokołów w ramach jednej aplikacji.
Strona 2:
Procesy serwera e-mail: MTA i MDA
Serwer poczty elektronicznej obsługuje dwa niezależne procesy:
MTA (ang. Mail Transfer Agent)
MDA (ang. Mail Delivery Agent)
Proces MTA jest używany do przekazywania poczty elektronicznej. Jak pokazano na rysunku, agent MTA otrzymuje wiadomości od klienta e-mail (MUA) lub od innego agenta MTA, który działa na innym serwerze pocztowym. Agent MTA w oparciu o zawartość nagłówka wiadomości decyduje, jak wiadomość musi być przekazywana, aby osiągnęła swój cel. Jeśli list jest adresowany do użytkownika, który posiada skrzynkę pocztową na lokalnym serwerze, to list jest przekazywany do agenta MDA. Natomiast jeśli skrzynka pocztowa adresata znajduje się na innym serwerze, agent MTA przekazuje list do agenta MTA na odpowiednim serwerze.
Strona 3:
Na rysunku widzimy, że agent MDA przyjmuje od agenta MTA część poczty elektronicznej i dostarcza ją do adresata. Agent MDA otrzymuje od agenta MTA całą pocztę przychodzącą i umieszcza ją w skrzynkach pocztowych odpowiednich użytkowników. Agent MDA może również zajmować się problemami związanymi z końcową fazą dostarczania wiadomości, np. skanowanie w poszukiwaniu wirusów, filtrowanie spamu czy potwierdzenia odebrania wiadomości. Większość komunikacji w ramach poczty elektronicznej używa aplikacji MUA, MTA oraz MDA. Jednakże istnieją inne alternatywne metody dostarczania poczty.
Klient może być połączony z korporacyjnym systemem poczty elektronicznej, takim jak Lotus Notes firmy IBM, Groupwise firmy Novell czy Microsoft Exchange. Te systemy często mają własny wewnętrzny format poczty elektronicznej, a ich klienci zwykle komunikują się z serwerem przy użyciu zastrzeżonych protokołów.
W sieci Internet serwer wysyła lub otrzymuje wiadomości elektroniczne poprzez bramę pocztową, która wykonuje niezbędne ponowne formatowanie. Jeśli na przykład dwie osoby, które pracują w tej samej firmie, wymieniają się wiadomościami używając zastrzeżonego protokołu, to ich korespondencja może pozostawać w obrębie korporacyjnego systemu pocztowego.
Komputery, które nie posiadają klienta pocztowego (MUA), mogą korzystać z usługi poczty elektronicznej za pośrednictwem przeglądarki WWW. Niektóre komputery mogą uruchamiać własne procesy MTA i samodzielnie zarządzać pocztą między domenami.
Strona 4:
Jak wspomniano wcześniej, do obsługi poczty elektronicznej stosuje się m.in. dwa protokoły: POP oraz SMTP (spójrz na rysunek, aby zrozumieć jak działają). POP i POP3 (ang. Post Office Protocol, version 3) są protokołami dostarczania poczty przychodzącej typu klient-serwer. Protokoły te dostarczają pocztę z serwera pocztowego do klienta (MUA). Agent MDA nasłuchuje, kiedy klient łączy się z serwerem. Z chwilą gdy połączenie zostanie ustanowione, serwer może dostarczyć korespondencję do klienta.
Z drugiej strony, protokół SMTP (ang. Simple Mail Transfer Protocol) zarządza procesem przesyłania poczty wychodzącej od klienta do serwera pocztowego (MDA), jak również pomiędzy serwerami (MTA). SMTP umożliwia przesyłanie poczty elektronicznej pomiędzy różnymi typami serwerów i oprogramowania klienta oraz wymianę korespondencji w sieci Internet.
Format wiadomości protokołu SMTP oparty jest o sztywny zbiór komend i odpowiedzi. Te komendy wspierają procedury używane w SMTP, takie jak zainicjowanie sesji, transakcja poczty, weryfikacja nazw skrzynek pocztowych, powiększanie listy adresowej, otwieranie i zamykanie wymiany.
Przykładowe komendy protokołu SMTP:
HELO - identyfikuje proces klienta SMTP z procesem serwera SMTP,
EHLO - nowsza wersja komendy HELO zawierająca rozszerzone funkcje,
MAIL FROM - identyfikuje nadawcę,
RCPT TO - identyfikuje odbiorcę,
DATA - identyfikuje treść wiadomości.
3.3.4 FTP
Strona 1:
FTP (ang. File Transfer Protokol) jest kolejnym powszechnie używanym protokołem warstwy aplikacji. Protokół FTP został stworzony do obsługi przesyłania plików pomiędzy klientem i serwerem. Klient FTP jest uruchamianą na komputerze aplikacją, która jest używana do wysyłania i pobierania plików z serwera z uruchomionym demonem FTP (FTPd).
Aby przesyłanie plików zakończyło się powodzeniem, FTP wymaga dwóch połączeń pomiędzy klientem i serwerem: jednego - do przesyłania komend i odpowiedzi, a drugiego - do faktycznego przesyłania pliku.
Pierwsze połączenie z serwerem klient ustanawia na porcie 21 TCP. To połączenie jest używane do kontroli ruchu i przenosi komendy klienta oraz odpowiedzi serwera.
Drugie połączenie z serwerem klient ustanawia na porcie 20 TCP. To połączenie jest używane do faktycznego transferu pliku i tworzone każdorazowo, gdy plik jest przesyłany.
Przesyłanie pliku może być realizowane w jednym z dwóch kierunków. Klient może pobierać (ang. download) plik z serwera lub przesyłać (ang. upload) plik na serwer.
3.3.5 DHCP
Strona 1:
Usługa DHCP (ang. Dynamic Host Configuration Protocol) umożliwia urządzeniom w sieci otrzymywanie adresów IP i innych informacji z serwera DHCP. Ta usługa automatyzuje przypisywanie adresów IP, masek podsieci, bramy i innych parametrów sieciowych.
DHCP pozwala hostom otrzymać adres IP dynamicznie, kiedy tylko zostaną podłączone do sieci. Hosty kontaktują się z serwerem i proszą o adres. Serwer DHCP wybiera adres ze skonfigurowanego zakresu adresów, nazywanego pulą i przydziela ("dzierżawi") go hostowi na ustalony okres czasu.
Usługa DHCP jest preferowana w większych sieciach lokalnych lub tam, gdzie często zmieniają się użytkownicy. Użytkownicy mogą dysponować laptopami lub nowymi stacjami roboczymi, które trzeba podłączyć do sieci. Automatyczne przydzielanie adresów IP jest sprawniejsze niż ręczne ich przypisywanie do każdej stacji roboczej przez administratora sieci.
Adresy przydzielane przez DHCP nie są na stałe przypisywane do hostów - są one dzierżawione na określony czas. Jeżeli host zostanie wyłączony lub straci połączenie z siecią, jego adres zostanie zwrócony do puli dostępnych adresów. Jest to szczególnie przydatne dla mobilnych użytkowników, którzy mogą swobodnie przemieszczać się i ponownie nawiązywać połączenia z siecią. Host może otrzymać adres IP w chwili, gdy zostanie nawiązane sprzętowe połączenie z przewodową lub bezprzewodową siecią LAN.
DHCP umożliwia dostęp do sieci Internet za pomocą bezprzewodowych punktów dostępowych (ang. hotspot) na lotniskach czy w kawiarenkach. Jeżeli Twój laptop znajdzie się w zasięgu lokalnego serwera DHCP, klient DHCP automatycznie pobierze adres IP.
Jak pokazano na rysunku, serwerami DHCP mogą być różne urządzenia, o ile mają uruchomioną usługę DHCP. W większości średnich i dużych sieci serwer DHCP jest lokalnym dedykowanym komputerem PC z uruchomioną usługą serwera DHCP.
Serwer DHCP znajduje się zwykle po stronie dostawcy usług internetowych (ISP), a host w sieci domowej uzyskuje konfigurację IP bezpośrednio z tego serwera.
DHCP może powodować zagrożenie bezpieczeństwa, ponieważ dowolne urządzenie połączone z siecią może otrzymać adres IP. To ryzyko nakazuje poważnie rozważyć bezpieczeństwo fizyczne podczas podejmowania decyzji, gdzie użyć dynamicznego, a gdzie statycznego adresowania sieci.
Zarówno dynamiczne jak i statyczne adresowanie są ważnym aspektem projektowania sieci. W wielu sieciach stosuje się oba sposoby jednocześnie. DHCP przydziela adresy dla hostów ogólnego przeznaczenia (np. urządzenia użytkownika końcowego), zaś stałe adresy są przydzielane urządzeniom sieciowym takim jak bramki, przełączniki, serwery czy drukarki.
Strona 2:
Jeżeli w sieci nie ma uruchomionego serwera DHCP, użytkownicy muszą wprowadzić adres IP, maskę podsieci oraz inne ustawienia samodzielnie. Serwer DHCP zarządza pulą adresów IP i wydzierżawia adres IP każdemu uruchomionemu klientowi DHCP. Zwolnione adresy IP automatycznie wracają do puli, aby można było użyć ich ponownie. Gdy urządzenie jest uruchamiane lub podłączane do sieci, klient DHCP rozgłasza pakiet DHCP DISCOVER w celu zidentyfikowania dostępnych serwerów DHCP. Serwer DHCP odpowiada pakietem DHCP OFFER, który zawiera zaoferowany adres IP, maskę podsieci, adres serwera DNS oraz bramę domyślną, jak również czas trwania dzierżawy.
Jeśli w sieci jest więcej serwerów DHCP, klient może otrzymać wiele pakietów DHCP OFFER. Musi wtedy dokonać wyboru oraz rozgłosić pakiet DHCP REQUEST, który zawiera informację o wybranym serwerze oraz ofertę dzierżawy zaakceptowaną przez klienta. Klient może ponownie uzyskać adres poprzednio przydzielony przez serwer.
Przy założeniu, że adres IP żądany przez klienta (lub zaoferowany przez serwer) jest dostępny, serwer zwraca komunikat DHCP ACK potwierdzając tym samym, że dzierżawa doszła do skutku. Jeśli serwer stwierdzi, że klient nie może korzystać z adresu (np. w wyniku przekroczenia limitu czasu lub przydzielenia innemu klientowi), to wysyła pakiet DHCP NAK (ang. Negative Acknowledgement). Jeśli komunikat DHCP NAK zostanie zwrócony, to wysłanie pakietu DHCP DISCOVER spowoduje ponowne rozpoczęcie procesu wyboru serwera.
Dzierżawa adresu IP jest odnawiana komunikatem DHCP REQUEST, przed upłynięciem terminu jej ważności.
Serwer DHCP zapewnia unikalność wszystkich adresów IP. Oznacza to, że jeden adres IP nie może zostać przydzielony do dwóch urządzeń sieciowych jednocześnie. DHCP umożliwia administratorom sieci łatwą rekonfigurację adresów IP klientów, bez konieczności zmieniania ich ręcznie. Większość dostawców usług internetowych stosuje DHCP w celu przydzielania adresów swoim klientom.
Czwarty kurs CCNA Exploration dostarczy więcej szczegółów na temat funkcjonowania DHCP.
3.3.6 Usługi współdzielenia plików i protokół SMB
Strona 1:
SMB (ang. Server Message Block) jest protokołem typu klient-serwer, który stosowany jest do udostępniania plików. Protokół SMB został rozwinięty przez firmę IBM w późnych latach osiemdziesiątych. Opisuje on strukturę współdzielonych zasobów sieciowych, takich jak katalogi, pliki, drukarki czy porty szeregowe. Jest to protokół typu żądanie-odpowiedź. W przeciwieństwie do protokołu FTP, klienci nawiązują długoterminowe połączenia z serwerem. Po ustanowieniu połączenia, użytkownik klienta ma dostęp do zasobów na serwerze tak, jakby zasoby były lokalne dla hosta klienta.
Usługi drukowania oraz współdzielenie plików za pomocą SMB stanowią podstawę sieci Microsoft. Wraz z wprowadzeniem oprogramowania dla systemu operacyjnego Windows 2000, Microsoft zmienił strukturę systemu na potrzeby protokołu SMB. W poprzednich wersjach produktów Microsoft, usługi SMB nie używały protokołów TCP/IP do procesu odwzorowywania nazw. Poczynając od systemu Windows 2000, wszystkie kolejne produkty Microsoft używają usługi DNS. To pozwala protokołom TCP/IP na bezpośrednią obsługę współdzielenia zasobów SMB (jak pokazano na rysunku).
Systemy operacyjne LINUX oraz UNIX umożliwiają współdzielenie zasobów z sieciami Microsoft za pomocą oprogramowania SAMBA, którego budowa oparta jest na protokole SMB. Systemy operacyjne Apple Macintosh również obsługują współdzielenie zasobów używając protokołu SMB.
Strona 2:
Protokół SMB opisuje dostęp do systemu plików, sposób generowania żądań o pliki przez klientów oraz komunikację między procesami. Wszystkie komunikaty SMB mają wspólny format: nagłówki mają stały rozmiar, natomiast parametry i dane - zmienny.
Komunikaty SMB mogą:
rozpoczynać, uwierzytelniać i przerywać sesje;
kontrolować dostęp do plików i drukarek;
pozwolić aplikacji wysyłać i odbierać komunikaty do i z innych urządzeń.
Proces wymiany plików w oparciu o SMB został pokazany na rysunku.
3.3.7 Usługi P2P i protokół Gnutella
Strona 1:
Dotąd poznałeś dwa protokoły warstwy aplikacji: FTP oraz SMB, które umożliwiają dostęp do plików. Teraz poznasz kolejny. Współdzielenie plików przez Internet jest obecnie bardzo popularne. Aplikacje P2P - oparte na protokole Gnutella - umożliwiają ludziom udostępnianie swoich plików (zgromadzonych na twardych dyskach), w celu pobrania ich przez innych użytkowników. Oprogramowanie klienta zgodne z protokołem Gnutella pozwala użytkownikom połączyć się przez Internet z usługami protokołu Gnutella, zlokalizować i mieć dostęp do zasobów udostępnionych przez inne urządzenia.
Istnieje wiele aplikacji obsługujących protokół Gnutella, m.in. BearShare, Gnucleus, LimeWire (zaprezentowany na rysunku), Morpheus, WinMX oraz XoloX. Prace nad rozwojem protokołu prowadzi obecnie GDF (ang. Gnutella Developer Forum). Jednak wiele rozszerzeń jest tworzonych również przez producentów oprogramowania.
Strona 2:
Wiele aplikacji P2P nie zapisuje w centralnej bazie danych wszystkich plików dostępnych na urządzeniach uczestniczących w wymianie. Przeciwnie, to urządzenia te odpowiadają na zapytania o dostępność odpowiednich plików. Spójrz na rysunek.
Kiedy użytkownik jest połączony z usługą Gnutella, jego aplikacje poszukują innych węzłów Gnutella, z którymi mogłyby się połączyć. Węzły te obsługują zapytania o lokalizację zasobów i odpowiadają na żądania. Poza tym zarządzają komunikatami kontrolnymi, które pomagają usłudze odkrywać kolejne węzły. Zazwyczaj przesyłanie plików funkcjonuje w oparciu o usługi HTTP.
Protokół Gnutella definiuje pięć typów pakietów:
ping - do wyszukiwania urządzeń,
pong - odpowiedź na ping,
query - do lokalizacji pliku,
query hit - odpowiedź na zapytanie,
push - żądanie pobrania pliku.
3.3.8 Usługi i protokół Telnet
Strona 1:
Na długo przed pojawieniem się komputerów z wyszukanymi graficznymi interfejsami użytkownika, ludzie używali systemów tekstowych, które często były tylko terminalami fizycznie połączonymi z komputerem centralnym. Kiedy powstały sieci, ludzie potrzebowali metody, która pozwoli na zdalny dostęp do komputerów tak, jak to miało miejsce w przypadku połączonych terminali.
Protokół Telnet stworzony po to, aby sprostać wyżej wymienionym potrzebom. Pojawił się we wczesnych latach siedemdziesiątych. Jest jednym z najstarszych protokołów warstwy aplikacji w stosie TCP/IP. Telnet dostarcza standardową metodę emulacji terminala tekstowego dając w ten sposób możliwość pracy zdalnej na komputerach podłączonych do sieci. Zarówno sam protokół, jak i implementujące go oprogramowanie klienta, powszechnie nazywane jest Telnetem.
Połączenie realizowane za pośrednictwem protokołu Telnet nazywane jest sesją VTY (ang. Virtual Terminal). Do połączenia z interfejsem wiersza poleceń CLI (ang. command line interface) serwera Telnet używa oprogramowania, które zapewnia te same cechy sesji terminala, jak w przypadku sesji nawiązywanych z fizycznego urządzenia połączonego z serwerem.
W celu wspierania połączeń klienta Telnet, serwer uruchamia usługę nazywaną demonem Telnet. Połączenie wirtualnego terminala jest nawiązywane z urządzenia końcowego przy pomocy aplikacji klienta Telnet. Klient Telnet dostępny jest w większości systemów operacyjnych. W systemie Microsoft Windows aplikacja Telnet może zostać uruchomiona z wiersza poleceń. Inne powszechnie używane aplikacje terminala wspierające klienta Telnet to: HyperTerminal, Minicom czy TeraTerm.
Po nawiązaniu połączenia Telnet, użytkownicy mogą wykonywać autoryzowane operacje na serwerze tak, jakby wykonywali operacje poprzez CLI. Po autoryzacji mogą oni rozpoczynać i przerywać procesy, konfigurować czy nawet wyłączyć urządzenie.
Strona 2:
Telnet jest protokołem typu klient-serwer. Określa sposób nawiązywania i przerywania sesji VTY. Dostarcza składnię poleceń używanych do rozpoczynania sesji, jak i komendy kontrolne, które mogą być wydawane w czasie sesji. Każde polecenie składa się z przynajmniej dwóch bajtów. Pierwszy bajt jest znakiem specjalnym nazywanym znakiem IAC (ang. Interpret as Command). IAC sygnalizuje, że następny bajt jest poleceniem.
Przykłady poleceń protokołu Telnet:
AYT (ang. Are You There) - Prośba o potwierdzenie aktywności sesji VTY.
EL (ang. Erase Line) - Usuwa tekst z bieżącej linii.
IP (ang. Interrupt Process) - Polecenie zawiesza lub przerywa proces, z którym wirtualny terminal jest połączony. Na przykład, jeśli użytkownik uruchomi program na serwerze, to za pomocą polecenia IP może go zatrzymać.
Protokół Telnet wspiera uwierzytelnianie użytkowników, ale nie wspiera szyfrowania danych. W czasie sesji wszystkie dane przesyłane są jawnym tekstem. To oznacza, że dane mogą zostać przechwycone i przeczytane.
Protokół SSH (ang. Secure Shell) oferuje alternatywną i bezpieczną metodę dostępu do serwera. Struktura SSH zapewnia bezpieczne zdalne logowanie oraz inne bezpieczne usługi sieciowe. Poza tym zapewnia silniejsze niż Telnet uwierzytelnianie i wspiera szyfrowanie danych w czasie transportu przez sieć. Profesjonaliści powinni zawsze używać SSH (jeśli to tylko jest możliwe).
11