plik


ÿþCISCO Accessible Theme Strona 1 ZmieD jzyk na English | Szukaj | SBownik Indeks kursu: 3 Funkcjonalno[ i protokoBy warstwy aplikacji Wybierz CCNA Exploration - Podstawy sieci komputerowych 3 Funkcjonalno[ i protokoBy warstwy aplikacji 3.0 Wprowadzenie do rozdziaBu 3.0.1 Wprowadzenie do rozdziaBu Strona 1: Wikszo[ z nas swoje do[wiadczenia z sieci Internet kojarzy z przegldaniem stron WWW, obsBug poczty elektronicznej oraz wspóBdzieleniem plików. Te aplikacje (oraz wiele innych) stanowi interfejs sieci, dziki któremu mo|emy stosunkowo Batwo wysyBa i otrzymywa informacje. Typowe aplikacje s na tyle intuicyjne, |e mo|emy z nich korzysta nie znajc ich budowy. Jednak|e profesjonalista powinien wiedzie, w jaki sposób aplikacje formatuj, transmituj i interpretuj komunikaty przesyBane przez sie. Zrozumienie mechanizmów umo|liwiajcych komunikacj poprzez sie staje si Batwiejsze, 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 , usBugach i protokoBach. Zbadamy w jaki sposób te trzy elementy umo|liwiaj komunikacj w sieci. Po zakoDczeniu tego rozdziaBu bdziesz potrafiB: Opisa w jaki sposób funkcje trzech wy|szych warstw modelu OSI dostarczaj usBugi sieciowe aplikacjom u|ytkownika koDcowego. Opisa w jaki sposób protokoBy warstwy aplikacji modelu TCP /IP zapewniaj usBugi 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 zwizane z nimi usBugi (HTTP, DNS, SMB, DHCP, SMTP/POP oraz Telnet). Opisa proces wspóBdzielenia plików za pomoc aplikacji peer-to-peer oraz protokoBu Gnutella. Wyja[ni w jaki sposób protokoBy umo|liwiaj aplikacjom uruchomionym na jednym urzdzeniu wysyBanie i odbieranie danych do/z wielu ró|nych urzdzeD sieciowych. U|ywa narzdzi do analizy sieci w celu przedstawienia i wyja[nienia, jak dziaBaj popularne aplikacje u|ytkownika. Wy[wietl multimedia. 3.1 Aplikacje - interfejs pomidzy 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 zostaB opracowany celem uBatwienia projektowania protokoBów sieciowych. Model OSI dzieli procesy sieciowe na siedem logicznych warstw, z których ka|da ma unikaln funkcjonalno[ oraz przypisane okre[lone usBugi i protokoBy. W ramach tego modelu informacje przechodz z jednej warstwy do nastpnej. Proces rozpoczyna si na ho[cie zródBowym . Dane przetwarzane s najpierw przez warstw aplikacji a nastpnie przechodz w dóB poprzez kolejne warstwy w hierarchii a| do warstwy fizycznej. Kolejnym etapem jest transmisja danych poprzez kanaB komunikacyjny. Po dotarciu do hosta docelowego dane podlegaj odwrotnemu procesowi, tj. rozpoczynaj wdrówk od warstwy fizycznej a koDcz 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 zapewniajca interfejs pomidzy aplikacjami, których u|ywamy do komunikacji, a sieci poprzez któr nasze komunikaty s transmitowane. ProtokoBy warstwy aplikacji s u|ywane do wymiany danych pomidzy programami uruchomionymi na ho[cie zródBowym i ho[cie docelowym. Istnieje wiele protokoBów warstwy aplikacji, przy czym cigle pojawiaj si nowe a stare s rozwijane i modyfikowane. Wy[wietl multimedia. Strona 2: Chocia| zestaw protokoBów TCP/IP zostaB opracowany przed zdefiniowaniem modelu OSI, to funkcjonalno[ protokoBów warstwy aplikacji modelu TCP/IP z grubsza pasuje do struktury trzech górnych warstw modelu OSI: aplikacji, prezentacji oraz sesji. Wikszo[ protokoBów warstwy aplikacji modelu TCP/IP zostaBo stworzonych przed pojawieniem si komputerów osobistych, graficznych interfejsów u|ytkownika czy obiektów multimedialnych. W rezultacie protokoBy te realizuj niewiele funkcji okre[lonych w warstwach prezentacji i sesji modelu OSI. Warstwa prezentacji GBówne zadania warstwy prezentacji: Kodowanie i konwersja danych warstwy aplikacji - dziki temu dane pochodzce z urzdzenia zródBowego mog by interpretowane przez http://ev-iip.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCServlet/LMS_ID=CNAMS,Theme=508theme,Style=508,La... 2010-01-18 22:49:16 CISCO Accessible Theme Strona 2 Kodowanie i konwersja danych warstwy aplikacji - dziki temu dane pochodzce z urzdzenia zródBowego mog by interpretowane przez odpowiednie aplikacje na urzdzeniu docelowym. Kompresja/dekompresja danych. Szyfrowanie danych na potrzeby transmisji oraz deszyfrowanie danych odebranych przez urzdzenie docelowe. Implementacje warstwy prezentacji nie s typowo zwizane ze szczególnym stosem protokoBó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 opisujcym 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 pomidzy aplikacjami: zródBow i docelow. Warstwa sesji prowadzi wymian informacji: rozpoczyna konwersacje, utrzymuje ich aktywno[ i wznawia je, je[li zostaBy utracone lub s od dBu|szego czasu bezczynne. Wikszo[ aplikacji, jak np . przegldarka WWW czy klient poczty elektronicznej, Bczy funkcjonalno[ warstw: 5, 6 i 7 modelu OSI. Wy[wietl multimedia. Strona 3: Powszechnie u|ywane protokoBy warstwy aplikacji modelu TCP/IP zapewniaj wymian informacji midzy u|ytkownikami. ProtokoBy te okre[laj format i informacje kontrolne konieczne dla typowej komunikacji w sieci Internet. W[ród tych protokoBów wyró|niamy: DNS (ang. Domain Name System) - protokóB u|ywany do odwzorowywania nazw w sieci Internet na adresy IP; HTTP (ang. Hypertext Transfer Protocol) - protokóB u|ywany do przesyBania plików tworzcych strony WWW; SMTP (ang. Simple Mail Transfer Protocol) - protokóB u|ywany do przesyBania wiadomo[ci poczty elektronicznej wraz z zaBcznikami; Telnet (ang. Telecommunication Network) - protokóB emulacji terminala umo|liwiajcy komunikacj ze zdalnym urzdzeniem; FTP (ang. File Transfer Protocol) - protokóB u|ywany do interaktywnego przesyBania plików pomidzy systemami. ProtokoBy TCP/IP s z reguBy zdefiniowane w dokumentach RFC (ang. Request For Comments). Dokumenty RFC opisuj standardy techniczne zestawu protokoBów TCP/IP. Publikacj tych dokumentów zajmuje si organizacja IETF (ang. Internet Engineering Task Force). Wy[wietl multimedia. 3.1.2 Oprogramowanie warstwy aplikacji Strona 1: ProtokoBy warstwy aplikacji obsBuguj interfejs pomidzy ludzmi a sieci danych. Kiedy otwieramy okno przegldarki internetowej lub komunikatora, aplikacja uruchamia si. Program jest umieszczany w pamici operacyjnej komputera a nastpnie wykonywany. Ka|dy program, który zostaB uruchomiony na urzdzeniu i aktualnie jest wykonywany, nazywamy procesem . W warstwie aplikacji istniej dwa typy oprogramowania (procesów), które umo|liwiaj dostp do sieci. S to aplikacje oraz usBugi. 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 obsBuguj protokoBy warstwy aplikacji i potrafi komunikowa si bezpo[rednio z protokoBami ni|szych warstw. PrzykBadami tego typu aplikacji s: klient poczty elektronicznej oraz przegldarka WWW. UsBugi warstwy aplikacji Niektóre programy bd potrzebowaBy pomocy ze strony usBug warstwy aplikacji (np . przesyBanie plików czy drukowanie w sieci). UsBugi te, pomimo |e s transparentne dla u|ytkownika, Bcz go z sieci i przygotowuj dane do wysBania. Ró|ne typy danych - tekst, grafika czy video - wymagaj ró|nych usBug sieciowych , aby zapewni im wBa[ciwe przygotowanie do przetworzenia przez funkcje wystpujce w ni|szych warstwach modelu OSI. Ka|da aplikacja lub usBuga sieciowa wykorzystuje protokoBy zdefiniowane przez standardy i formaty danych. Bez protokoBów nie byBoby powszechnego sposobu formatowania i przekazywania danych w sieci. Aby zrozumie funkcje ró|nych usBug sieciowych , konieczne jest zapoznanie si z odpowiednimi protokoBami, które kieruj ich operacjami. Aby zobaczy przykBady, umie[ kursor myszy na poszczególnych przyciskach na rysunku. Wy[wietl multimedia. 3.1.3 Aplikacje u|ytkownika, usBugi i protokoBy warstwy aplikacji http://ev-iip.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCServlet/LMS_ID=CNAMS,Theme=508theme,Style=508,La... 2010-01-18 22:49:16 CISCO Accessible Theme Strona 3 Strona 1: Jak wspomniano poprzednio, warstwa aplikacji u|ywa protokoBów, które s implementowane w aplikacjach i usBugach. Podczas gdy aplikacje umo|liwiaj u|ytkownikom tworzenie komunikatów, a usBugi warstwy aplikacji obsBuguj interfejs sieci, to protokoBy zapewniaj reguBy do obsBugi danych. Wszystkie trzy komponenty mog zosta u|yte przez pojedynczy wykonywalny program i mog one u|ywa tej samej nazwy. Na przykBad zwrot "Telnet" odnosi si zarówno do aplikacji, usBugi, jak i protokoBu. W modelu OSI aplikacje komunikujce si bezpo[rednio z u|ytkownikami umiejscowione s na szczycie stosu. Warstwa aplikacji dziaBa w oparciu o funkcje ni|szych warstw (podobnie jak pozostaBe warstwy) w celu sfinalizowania procesu komunikacji. W warstwie aplikacji protokoBy okre[laj komunikaty wymieniane pomidzy hostem zródBowym i docelowym, skBadni komend, typ i format transmitowanych danych oraz odpowiednie metody powiadamiania o bBdach i odzyskiwania danych. Uruchom animacj, aby zobaczy interakcj pomidzy aplikacjami, usBugami oraz protokoBami. Wy[wietl multimedia. 3.1.4 Funkcje protokoBów warstwy aplikacji Strona 1: ProtokoBy warstwy aplikacji stosowane s przez urzdzenia zródBowe oraz docelowe podczas sesji komunikacyjnej. ProtokoBy na obu hostach (zródBowym i docelowym) musz do siebie pasowa, aby komunikacja mogBa zakoDczy si sukcesem. ProtokoBy ustalaj zasady rzdzce wymian danych pomidzy aplikacjami a usBugami uruchomionymi na uczestniczcych w komunikacji urzdzeniach. ProtokoBy okre[laj struktury danych oraz typy przesyBanych komunikatów. Komunikat mo|e reprezentowa |danie usBugi, potwierdzenie, dane, status lub bBd. ProtokoBy definiuj równie| sposób konwersacji zapewniajc, |e wysBany komunikat spotka si z wBa[ciw reakcj oraz |e w czasie dotarcia danych zostan uruchomione wBa[ciwe usBugi. W sieciach danych komunikuje si wiele ró|nych typów aplikacji. Dlatego usBugi warstwy aplikacji musz implementowa zBo|one protokoBy, aby zapewni po|dany poziom komunikacji. Ka|dy protokóB ma okre[lone przeznaczenie i jest tak skonstruowany, aby je speBnia. ProtokoBy musz by bezwzgldnie implementowane zgodnie z ich specyfikacj, tak aby zapewni ich zgodn prac z ni|szymi warstwami. Aplikacje i usBugi mog korzysta ze zBo|onych protokoBów równie| w trakcie pojedynczej konwersacji. Jeden z protokoBów mo|e okre[la, w jaki sposób nawiza poBczenie, a inny - definiowa procedur transmisji danych w przypadku, gdy komunikat jest przesyBany do nastpnej ni|szej warstwy. Wy[wietl multimedia. 3.2 Ustalanie zasad dla aplikacji i usBug 3.2.1 Model Klient-Serwer Strona 1: W czasie pracy na urzdzeniu przyBczonym do sieci (np . PC, laptop, PDA, telefon komórkowy) mo|emy korzysta z danych przechowywanych na innym urzdzeniu . W takim przypadku musimy uzyska dostp do zdalnego urzdzenia, na którym te dane s fizycznie przechowywane. Model Klient-Serwer W modelu klient-serwer urzdzenie |dajce informacji nazywane jest klientem , natomiast urzdzenie odpowiadajce na |danie - serwerem. Procesy komunikacji klienta i serwera zaliczane s do zadaD warstwy aplikacji. Klient rozpoczyna wymian danych wysyBajc |danie do serwera, który odpowiada poprzez wysBanie jednego lub wicej strumieni danych do klienta. ProtokoBy warstwy aplikacji opisuj format |daD i odpowiedzi pomidzy klientami i serwerami. Oprócz rzeczywistego przesyBania, wymiana danych mo|e równie| wymaga przenoszenia informacji kontrolnych, takich jak uwierzytelnianie u|ytkownika czy informacje identyfikujce przesyBane dane. PrzykBadem sieci klient-serwer jest [rodowisko korporacyjne, gdzie pracownicy korzystaj z firmowego serwera poczty elektronicznej do wysyBania, odbierania i przechowywania korespondencji. Klient poczty elektronicznej, zainstalowany na komputerze pracownika, wysyBa |danie do serwera w celu sprawdzenia, czy na serwerze s nowe wiadomo[ci. Serwer odpowiada wysyBajc |dany e-mail do klienta. Chocia| dane s zwykle opisywane jako przepByw informacji z serwera do klienta, to pewne dane przesyBane s równie| z klienta do serwera. StrumieD danych mo|e by równy w obu kierunkach, ale mo|e by te| wikszy w kierunku od klienta do serwera. Na przykBad klient mo|e przesyBa pliki do serwera w celu ich gromadzenia tam. PrzesyBanie danych z klienta do serwera nazywane jest wysyBaniem (ang. upload), natomiast z serwera do klienta pobieraniem (ang. download). Aby obejrze przesyBanie plików, najedz kursorem myszki na odpowiednie pole na rysunku obok. Wy[wietl multimedia. 3.2.2 Serwery Strona 1: W |argonie sieciowym: urzdzenie, które odpowiada na |dania aplikacji klienta, nazywane jest serwerem . Serwer jest zwykle komputerem, który przechowuje dane w celu wspóBdzielenia ich z systemami klienckimi. Na przykBad strony WWW, dokumenty, bazy danych, http://ev-iip.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCServlet/LMS_ID=CNAMS,Theme=508theme,Style=508,La... 2010-01-18 22:49:16 CISCO Accessible Theme Strona 4 W |argonie sieciowym: urzdzenie, które odpowiada na |dania aplikacji klienta, nazywane jest serwerem . Serwer jest zwykle komputerem, który przechowuje dane w celu wspóBdzielenia ich z systemami klienckimi. Na przykBad strony WWW, dokumenty, bazy danych, zdjcia, 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 dostpu 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 dostpu (do danych i operacji) przyznane dla ka|dego u|ytkownika. Np. je[li u|ywajc klienta FTP chcemy przesBa 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 usBug lub proces nazywany demonem . Jak wikszo[ usBug, demony zwykle uruchamiane s w tle i nie s bezpo[rednio kontrolowane przez u|ytkownika. Demony "nasBuchuj" |daD napBywajcych od klienta, tzn. s one zaprogramowane tak, aby odpowiada na ka|de |danie, które przybyBo do serwera i które jest skierowane do usBugi obsBugiwanej przez demona. Kiedy demon "sByszy" |danie klienta, to najpierw wymienia z nim wymagane przez protokóB komunikaty, a nastpnie przesyBa |dane dane (we wBa[ciwym formacie). Wy[wietl multimedia. 3.2.3 UsBugi i protokoBy warstwy aplikacji Strona 1: Pojedyncza aplikacja mo|e u|ywa wiele ró|nych usBug wspierajcych warstw aplikacji. W ten sposób na jedno |danie u|ytkownika, np . |danie strony WWW, w rzeczywisto[ci mo|e skBada si wiele oddzielnych |daD. A dla ka|dego |dania mo|e zosta wykonanych wiele procesów. Na przykBad klient, do sformuBowania jednego |dania, mo|e wymaga kilku oddzielnych procesów. Co wicej, serwery zwykle otrzymuj wiele |daD od klientów w tym samym czasie. Na przykBad serwer Telnet mo|e mie wiele poBczeD równocze[nie. Wtedy ka|de |danie pochodzce od ró|nych klientów musi zosta rozpatrzone jednocze[nie i niezale|nie, aby komunikacja zakoDczyBa si powodzeniem. Dziki wsparciu funkcji ni|szych warstw, procesy i usBugi warstwy aplikacji mog skutecznie zarzdza wielokrotnymi konwersacjami. Wy[wietl multimedia. Strona 2: W tym wiczeniu zapoznasz si z prostym przykBadem interakcji klient-serwer, który mo|e sBu|y jako model dla bardziej zBo|onych przypadków omawianych w dalszej cz[ci materiaBu. Kliknij ikon Packet Tracer, aby uzyska wicej szczegóBów . Wy[wietl multimedia. 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 wystpuje 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 dziaBaj inaczej. Sieci Peer-to-Peer W sieci peer-to-peer dwa komputery (lub wicej) s poBczone ze sob poprzez sie i mog one wspóBdzieli zasoby (tj . drukarki czy pliki) bez pomocy dedykowanego serwera. Ka|de podBczone urzdzenie koDcowe (okre[lane mianem peer) mo|e dziaBa jako serwer lub klient. Jeden komputer peBnicy rol serwera dla jednej transakcji mo|e jednocze[nie sBu|y jako klient dla innej. Role (klient i serwer) s ustalane na podstawie |daD. Prosta sie domowa z dwoma poBczonymi komputerami, które wspóBdziel drukark, jest przykBadem sieci peer-to-peer. U|ytkownicy tej sieci mog równie| przygotowa swoje komputery do wspóBdzielenia plików, uruchomienia gier sieciowych czy wspóBdzielenia poBczenia internetowego. Innym przykBadem funkcjonalno[ci sieci peer-to-peer s podBczone do du|ej sieci dwa komputery, które u|ywaj oprogramowania w celu wspóBdzielenia swoich zasobów poprzez sie. W przeciwieDstwie 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 mogBy zosta udostpnione. Mog by one ulokowane na dowolnym urzdzeniu w sieci. Wikszo[ dzisiejszych systemów operacyjnych wspiera wspóBdzielenie 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 dostpu czy monitoringu . Zatem sporym wyzwaniem byBoby tutaj narzucenie polityki bezpieczeDstwa i dostpu do zasobów, tym bardziej |e taka sie Bczy wicej ni| kilka komputerów. Na ka|dym urzdzeniu w sieci P2P konta u|ytkowników oraz prawa dostpu musz by konfigurowane indywidualnie. Wy[wietl multimedia. http://ev-iip.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCServlet/LMS_ID=CNAMS,Theme=508theme,Style=508,La... 2010-01-18 22:49:16 CISCO Accessible Theme Strona 5 Strona 2: Aplikacje Peer-to-Peer Aplikacje peer-to-peer (P2P), w przeciwieDstwie do sieci peer-to-peer, pozwalaj urzdzeniom dziaBa jako klient i serwer w ramach tej samej komunikacji. W tym modelu ka|dy klient jest serwerem, a ka|dy serwer - klientem. Oba urzdzenia mog inicjowa komunikacj i oba w równym stopniu bior udziaB w jej procesie . Jednak|e aplikacja peer-to-peer wymaga, aby ka|de urzdzenie dostarczaBo interfejsu u|ytkownikom , a usBugi byBy uruchamiane w tle. Uruchomienie okre[lonej aplikacji peer-to-peer uruchamia w tle wymagane usBugi i równocze[nie wywoBuje interfejs u|ytkownika. Dopiero wówczas mo|liwa jest bezpo[rednia komunikacja urzdzeD. Niektóre aplikacje P2P wykorzystuj system hybrydowy, w którym wspóBdzielone zasoby s zdecentralizowane, ale odsyBacze (indeksy) do ich lokalizacji s gromadzone w scentralizowanym katalogu. W systemie hybrydowym ka|de urzdzenie ma dostp do serwera przechowujcego indeksy i w ten sposób mo|e uzyska informacje o lokalizacji poszukiwanego zasobu (zwykle jest to inne urzdzenie). Rola serwera przechowujcego indeksy koDczy si w momencie poBczenia dwóch urzdzeD . PoBczone urzdzenia komunikuj si dalej ju| z pominiciem serwera. Aplikacje peer-to-peer mog by stosowane w sieciach: peer-to-peer, klient-serwer oraz w sieci Internet. Wy[wietl multimedia. 3.3 ProtokoBy i usBugi warstwy aplikacji - przykBady 3.3.1 ProtokóB i usBuga DNS Strona 1: Teraz, kiedy ju| lepiej rozumiemy, w jaki sposób aplikacje dostarczaj interfejs dla u|ytkownika oraz umo|liwiaj dostp do sieci, przyjrzyjmy si powszechnie u|ywanym protokoBom. Jak zobaczymy w dalszej cz[ci kursu, warstwa transportowa u|ywa schematu adresowania opartego na numerach portów. Numery portów identyfikuj aplikacje i usBugi warstwy aplikacji, które s zródBem 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 protokoBów i usBug warstwy aplikacji modelu TCP/IP czsto bdziemy odnosi si do numerów portów (TCP i UDP), które s zwizane z usBugami. Niektóre z tych usBug 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 Urzdzenia mog bra udziaB w wysyBaniu i odbieraniu komunikatów dziki numerycznym adresom IP, którymi s oznaczane. Jednak|e wikszo[ ludzi ma problemy z zapamitaniem coraz to wikszej liczby adresów numerycznych. W zwizku z tym powstaB system nazw domenowych, umo|liwiajcy przeksztaBci adres numeryczny na prost o rozpoznawaln dla czBowieka nazw. W Internecie takie nazwy domen jak np. www.cisco.com s du|o Batwiejsze do zapamitania ni| adres 198.133.219.25, który jest aktualnym numerycznym adresem serwera. Je[li zatem Cisco podejmie decyzj o zmianie adresu IP, to bdzie to niezauwa|alne dla u|ytkownika, dopóki nazwa domeny www.cisco.com nie zostanie zmieniona. Nowy adres numeryczny zostanie poBczony z istniejc nazw domeny i Bczno[ zostanie utrzymana. Kiedy sieci byBy niewielkich rozmiarów, utrzymywanie mapowania pomidzy nazwami domenowi a adresami, które reprezentuj, nie byBo trudnym zadaniem. Jednak|e z czasem sieci rozpoczBy swoj ekspansj, a liczba urzdzeD zaczBa rosn. W tych warunkach manualne uzupeBnianie bazy staBo si niewykonalne. W celu automatycznego wizania nazw domen z adresami utworzono tzw. system nazw domenowych - DNS. DNS wykorzystuje zbiór rozproszonych serwerów, które tBumacz nazwy na zwizane z nimi numeryczne adresy. ProtokóB DNS definiuje zautomatyzowan usBug, która dopasowuje nazwy do wymaganych numerycznych adresów sieciowych . Opisuje format zapytaD i odpowiedzi oraz formaty danych. ProtokóB DNS w procesie komunikacji u|ywa pojedynczej struktury informacji zwanej komunikatem. Format ten u|ywany jest do wszelkiego typu zapytaD klienta i odpowiedzi serwera, informacji o bBdach czy komunikatów RR (ang. Resource Record) przesyBanych pomidzy serwerami. Wy[wietl multimedia. Strona 2: DNS jest usBug opart na modelu klient-serwer. Jednak ró|ni si ona od innych usBug tego typu. Wikszo[ usBug u|ywa klienta, który jest aplikacj (np . przegldarka stron WWW czy klient poczty elektronicznej), natomiast klient DNS dziaBa jako usBuga sama w sobie. Klient DNS, czasem okre[lany mianem DNS resolver, wspiera rozwizywanie nazw dla innych aplikacji sieciowych oraz usBug, które tego potrzebuj. W czasie konfiguracji urzdzenia sieciowego zwykle podajemy jeden lub wicej adresów serwerów DNS, które klient DNS mo|e wykorzysta do odwzorowywania nazw. Zwykle dostawca usBug internetowych przydziela adresy, które mog by u|ywane przez serwery DNS. Kiedy aplikacja http://ev-iip.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCServlet/LMS_ID=CNAMS,Theme=508theme,Style=508,La... 2010-01-18 22:49:16 CISCO Accessible Theme Strona 6 W czasie konfiguracji urzdzenia sieciowego zwykle podajemy jeden lub wicej adresów serwerów DNS, które klient DNS mo|e wykorzysta do odwzorowywania nazw. Zwykle dostawca usBug internetowych przydziela adresy, które mog by u|ywane przez serwery DNS. Kiedy aplikacja u|ytkownika |da poBczenia ze zdalnym urzdzeniem za pomoc nazwy, klient DNS wysyBa zapytanie o odwzorowanie tej nazwy na adres numeryczny do jednego ze zdefiniowanych serwerów DNS. Systemy operacyjne komputerów udostpniaj u|ytkownikom narzdzie zwane nslookup, które umo|liwia manualne wysBanie zapytania do serwera DNS w celu odwzorowania danej nazwy hosta. Narzdzie to mo|e by równie| stosowane w celu rozwizywania problemów zwizanych 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 przykBadzie serwerem DNS jest dns-sjk.cisco.com, który ma adres 171.68.226.120. Mo|emy równie| sprawdzi adres hosta lub domeny wpisujc jej nazw. Pierwsze zapytanie na rysunku dotyczy domeny www.cisco.com. Odpowiadajcy serwer zwróciB adres 198.133.219.25 . Zapytanie zaprezentowane na rysunku jest tylko prostym przykBadem. Narzdzie nslookup posiada równie| wiele u|ytecznych opcji pozwalajcych na szczegóBowe badanie i weryfikacj procesu DNS. Wy[wietl multimedia. Strona 3: Serwer DNS zapewnia odwzorowywanie nazw poprzez demona, który czsto 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. PrzykBadowe typy rekordów: A - adres urzdzenia koDcowego NS - autorytatywny serwer nazw CNAME - umowne nazwy serwerów wraz z ich peBnymi nazwami domenowymi (ang. canonical name lub Fully Qualified Domain Name); u|ywane w sytuacji, gdy wiele usBug ma ten sam adres sieciowy, ale ka|da usBuga ma swój wBasny wpis w DNS MX - rekord wymiany poczty; mapuje nazw domenow do listy serwerów odbierajcych poczt Kiedy klient wykonuje zapytanie, proces serwera "named", w celu samodzielnego rozwizania nazwy, najpierw przeglda wBasne rekordy. Je|eli operacja ta zakoDczy si niepowodzeniem, kontaktuje si z innymi serwerami. {danie mo|e by przesyBane dalej do kilku serwerów, co wydBu|a czas i zu|ywa przepustowo[. Z chwil gdy dopasowanie zostanie odnalezione, informacja zostaje zwrócona do serwera pytajcego na pocztku. Serwer tymczasowo przechowuje adres numeryczny, który zostaB dopasowany do nazwy, w pamici podrcznej (ang. cache ). Je[li ta sama nazwa jest |dana ponownie, ju| pierwszy serwer mo|e zwróci adres dziki przechowywaniu warto[ci w pamici podrcznej. Przechowywanie adresów w pamici podrcznej redukuje ruch zwizany z zapytaniami DNS oraz obci|enie serwerów poBo|onych wy|ej w hierarchii. UsBuga Klienta DNS, na komputerze PC z systemem operacyjnym Windows, optymalizuje wydajno[ procesu rozwizywania nazw DNS poprzez przechowywanie poprzednio odwzorowanych nazw w pamici. Polecenie ipconfig /displaydns w systemie Windows XP lub 2000 wy[wietla wszystkie przechowywane wpisy. Wy[wietl multimedia. Strona 4: System nazw domenowych ma struktur hierarchiczn. Hierarchia wyglda jak odwrócone drzewo z korzeniem (root) na szczycie i gaBziami poni|ej. Serwery root utrzymuj rekordy z informacjami o tym, jak osign 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. PrzykBadami domen najwy|szego poziomu s: .au - Australia .co - Kolumbia .com - dziaBalno[ komercyjna lub przemysB .jp - Japonia .org - organizacja non-profit Po domenach najwy|szego poziomu wystpuj domeny drugiego poziomu, a poni|ej nich - domeny kolejnego ni|szego poziomu. Ka|da nazwa domeny jest [cie|k tworzon w dóB odwróconego drzewa. Punktem startowym jest root. Na przykBad (jak pokazano na rysunku) serwer root DNS mo|e nie wiedzie dokBadnie, gdzie serwer pocztowy mail.cisco.com jest umiejscowiony. Jednak analizujc 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. http://ev-iip.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCServlet/LMS_ID=CNAMS,Theme=508theme,Style=508,La... 2010-01-18 22:49:16 CISCO Accessible Theme Strona 7 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 odpowiadajce jego poziomowi w hierarchii, to mówi si, |e jest on autorytatywny dla tych rekordów. Na przykBad serwer nazw w domenie cisco.netacad.net nie byBby autorytatywny dla rekordu mail.cisco.com, poniewa| ten rekord jest utrzymywany na serwerze domeny wy|szego poziomu (serwer nazw w domenie cisco.com). Acza http://www.ietf.org//rfc/rfc1034.txt http://www.ietf.org/rfc/rfc1035.txt Wy[wietl multimedia. 3.3.2 UsBuga WWW i protokóB HTTP Strona 1: Kiedy w przegldarce stron WWW wpisujemy adres strony (tzw. URL), przegldarka nawizuje poBczenie z usBug uruchomion na serwerze korzystajc z protokoBu HTTP. URL (ang. Uniform Resource Locator) oraz URI (ang. Uniform Resource Identifier) s terminami, które wikszo[ ludzi Bczy z adresami WWW. URL http://www.cisco.com/index.html jest przykBadem 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 protokoBu HTTP). Przegldarki WWW s aplikacjami klienckimi, które s u|ywane do poBczeD z sieci WWW (ang. World Wide Web) oraz do dostpu do zasobów przechowywanych na serwerach WWW . Jak w przypadku wikszo[ci procesów serwera, serwer WWW uruchamia usBug w tle i udostpnia ró|ne typy plików. W celu dostpu do tre[ci, klient WWW ustanawia poBczenie z serwerem i prosi o odpowiednie zasoby. Serwer odpowiada, a przegldarka po odebraniu zasobów interpretuje dane i prezentuje je u|ytkownikowi. Przegldarki mog interpretowa i prezentowa wiele typów danych, m.in . zwykBy tekst (ang. plain text ) i format HTML (ang. Hypertext Markup Language, jzyk w którym s konstruowane strony WWW). Inne typy danych mog wymaga odpowiednich usBug i programów, które nazywane s wtyczkami (ang. plug-in ) lub dodatkami (ang. add-on). Aby pomóc przegldarce ustali typ odebranego pliku, serwer okre[la rodzaj danych, które plik zawiera. Aby lepiej zrozumie, w jaki sposób przegldarka komunikuje si z klientem, spójrzmy jak strona WWW jest otwierana w przegldarce. W tym celu u|yjemy adresu URL: http://www.cisco.com/web-server.htm. Najpierw przegldarka interpretuje trzy cz[ci adresu URL: 1. http (protokóB lub schemat) 2. www.cisco.com (nazwa serwera) 3. web-server.htm (okre[lony plik) Przegldarka komunikuje si z serwerem DNS w celu konwersji nazwy www.cisco.com na adres numeryczny, który jest u|ywany do poBczenia z serwerem. Przegldarka, dziaBajc zgodnie z wymaganiami protokoBu HTTP, wysyBa |danie GET do serwera i pyta o plik web-server.htm . Nastpnie serwer zwraca kod HTML |danej strony WWW . W koDcu przegldarka odczytuje kod HTML i formatuje stron w oknie przegldarki. Wy[wietl multimedia. Strona 2: ProtokóB HTTP jest jednym z protokoBów stosu TCP /IP. PowstaB on pierwotnie w celu publikowania i pobierania stron HTML. Obecnie jest u|ywany przez rozproszone kooperujce systemy informacyjne. HTTP jest stosowany do przesyBania danych w sieci WWW - jest jednym z najcz[ciej u|ywanych protokoBów aplikacji. HTTP jest protokoBem typu |danie/odpowiedz (ang. request/response ). Kiedy klient (zwykle przegldarka WWW ) wysyBa komunikat z |daniem strony WWW do serwera, protokóB HTTP okre[la typ tego komunikatu. Podobna sytuacja ma miejsce, gdy serwer wysyBa odpowiedz. Trzy najwa|niejsze typy komunikatów to: GET, POST oraz PUT. GET jest pro[b klienta o dane. Przegldarka wysyBa |danie GET w celu pobrania strony WWW z serwera. W momencie gdy serwer otrzymuje |danie GET (co pokazano na rysunku), odpowiada wierszem opisujcym stan (ang. status line), np. HTTP/1.1 200 OK, a nastpnie przesyBa |dany plik, komunikat o bBdzie lub inne informacje. http://ev-iip.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCServlet/LMS_ID=CNAMS,Theme=508theme,Style=508,La... 2010-01-18 22:49:16 CISCO Accessible Theme Strona 8 GET jest pro[b klienta o dane. Przegldarka wysyBa |danie GET w celu pobrania strony WWW z serwera. W momencie gdy serwer otrzymuje |danie GET (co pokazano na rysunku), odpowiada wierszem opisujcym stan (ang. status line), np. HTTP/1.1 200 OK, a nastpnie przesyBa |dany plik, komunikat o bBdzie lub inne informacje. Komunikaty POST oraz PUT s u|ywane w procesie przesyBania danych do serwera WWW. Na przykBad, kiedy u|ytkownik wprowadzi dane do formularza umieszczonego na stronie WWW , POST wBczy te dane do wiadomo[ci przesyBanej do serwera. PUT przesyBa dane w postaci plików do serwera WWW. HTTP nie jest bezpiecznym protokoBem. Komunikaty POST wysyBane 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óB HTTP Secure (HTTPS). Do ochrony danych przesyBanych pomidzy klientem i serwerem, HTTPS stosuje algorytmy uwierzytelniania i szyfrowania. HTTPS okre[la dodatkowe reguBy dla przepBywu danych pomidzy warstw aplikacji i warstw transportow. Wy[wietl multimedia. Strona 3: W tym wiczeniu skonfigurujesz usBugi DNS i HTTP. Nastpnie dokonasz analizy pakietów generowanych po wprowadzeniu adresu URL |danej strony WWW . Kliknij ikon Packet Tracer, aby uzyska wicej szczegóBów . Wy[wietl multimedia. 3.3.3 UsBugi E-mail i protokoBy SMTP/POP Strona 1: Poczta elektroniczna (e-mail) - najbardziej popularna usBuga sieciowa - zrewolucjonizowaBa komunikacj midzy ludzmi dziki swojej prostocie i szybko[ci. Do poprawnego dziaBania poczty elektronicznej na komputerze lub innym urzdzeniu koDcowym (PDA, telefon komórkowy) wymagane jest klika aplikacji i usBug. Na rysunku obok zaprezentowano dwa przykBadowe protokoBy warstwy aplikacji: POP (ang. Post Office Protocol) oraz SMTP (ang. Simple Mail Transfer Protocol). Tak jak w przypadku HTTP, protokoBy 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 wysyBanie wiadomo[ci i umieszczanie ich w skrzynkach pocztowych. Oba procesy s niezale|ne. Do pobierania wiadomo[ci z serwera pocztowego klient u|ywa protokoBu POP lub IMAP. Natomiast proces wysyBania wiadomo[ci opisuje protokóB SMTP. Zwykle klient e-mail dostarcza funkcjonalno[ obu protokoBów w ramach jednej aplikacji. Wy[wietl multimedia. Strona 2: Procesy serwera e-mail: MTA i MDA Serwer poczty elektronicznej obsBuguje 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 dziaBa na innym serwerze pocztowym. Agent MTA w oparciu o zawarto[ nagBówka wiadomo[ci decyduje, jak wiadomo[ musi by przekazywana, aby osignBa 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. Wy[wietl multimedia. 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 caB poczt przychodzc i umieszcza j w skrzynkach pocztowych odpowiednich u|ytkowników. Agent MDA mo|e równie| zajmowa si problemami zwizanymi z koDcow faz dostarczania wiadomo[ci, np. skanowanie w poszukiwaniu wirusów, filtrowanie spamu czy potwierdzenia odebrania wiadomo[ci. Wikszo[ komunikacji w ramach poczty elektronicznej u|ywa aplikacji MUA, MTA oraz MDA . Jednak|e istniej inne alternatywne metody dostarczania poczty. Klient mo|e by poBczony z korporacyjnym systemem poczty elektronicznej, takim jak Lotus Notes firmy IBM, Groupwise firmy Novell czy Microsoft Exchange. Te systemy czsto maj wBasny wewntrzny format poczty elektronicznej, a ich klienci zwykle komunikuj si z serwerem przy u|yciu zastrze|onych protokoBów. W sieci Internet serwer wysyBa lub otrzymuje wiadomo[ci elektroniczne poprzez bram pocztow, która wykonuje niezbdne ponowne http://ev-iip.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCServlet/LMS_ID=CNAMS,Theme=508theme,Style=508,La... 2010-01-18 22:49:16 CISCO Accessible Theme Strona 9 W sieci Internet serwer wysyBa lub otrzymuje wiadomo[ci elektroniczne poprzez bram pocztow, która wykonuje niezbdne ponowne formatowanie. Je[li na przykBad dwie osoby, które pracuj w tej samej firmie, wymieniaj si wiadomo[ciami u|ywajc zastrze|onego protokoBu, to ich korespondencja mo|e pozostawa w obrbie korporacyjnego systemu pocztowego. Komputery, które nie posiadaj klienta pocztowego (MUA), mog korzysta z usBugi poczty elektronicznej za po[rednictwem przegldarki WWW. Niektóre komputery mog uruchamia wBasne procesy MTA i samodzielnie zarzdza poczt midzy domenami. Wy[wietl multimedia. Strona 4: Jak wspomniano wcze[niej, do obsBugi poczty elektronicznej stosuje si m .in. dwa protokoBy: POP oraz SMTP (spójrz na rysunek, aby zrozumie jak dziaBaj). POP i POP3 (ang. Post Office Protocol, version 3) s protokoBami dostarczania poczty przychodzcej typu klient-serwer. ProtokoBy te dostarczaj poczt z serwera pocztowego do klienta (MUA ). Agent MDA nasBuchuje, kiedy klient Bczy si z serwerem. Z chwil gdy poBczenie zostanie ustanowione, serwer mo|e dostarczy korespondencj do klienta. Z drugiej strony, protokóB SMTP (ang. Simple Mail Transfer Protocol) zarzdza procesem przesyBania poczty wychodzcej od klienta do serwera pocztowego (MDA ), jak równie| pomidzy serwerami (MTA). SMTP umo|liwia przesyBanie poczty elektronicznej pomidzy ró|nymi typami serwerów i oprogramowania klienta oraz wymian korespondencji w sieci Internet. Format wiadomo[ci protokoBu 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 , powikszanie listy adresowej, otwieranie i zamykanie wymiany. PrzykBadowe komendy protokoBu SMTP: HELO - identyfikuje proces klienta SMTP z procesem serwera SMTP, EHLO - nowsza wersja komendy HELO zawierajca rozszerzone funkcje, MAIL FROM - identyfikuje nadawc, RCPT TO - identyfikuje odbiorc, DATA - identyfikuje tre[ wiadomo[ci. Wy[wietl multimedia. 3.3.4 FTP Strona 1: FTP (ang. File Transfer Protokol) jest kolejnym powszechnie u|ywanym protokoBem warstwy aplikacji. ProtokóB FTP zostaB stworzony do obsBugi przesyBania plików pomidzy klientem i serwerem. Klient FTP jest uruchamian na komputerze aplikacj, która jest u|ywana do wysyBania i pobierania plików z serwera z uruchomionym demonem FTP (FTPd). Aby przesyBanie plików zakoDczyBo si powodzeniem, FTP wymaga dwóch poBczeD pomidzy klientem i serwerem: jednego - do przesyBania komend i odpowiedzi, a drugiego - do faktycznego przesyBania pliku. Pierwsze poBczenie z serwerem klient ustanawia na porcie 21 TCP. To poBczenie jest u|ywane do kontroli ruchu i przenosi komendy klienta oraz odpowiedzi serwera. Drugie poBczenie z serwerem klient ustanawia na porcie 20 TCP. To poBczenie jest u|ywane do faktycznego transferu pliku i tworzone ka|dorazowo, gdy plik jest przesyBany. PrzesyBanie pliku mo|e by realizowane w jednym z dwóch kierunków. Klient mo|e pobiera (ang. download) plik z serwera lub przesyBa (ang. upload) plik na serwer. Wy[wietl multimedia. 3.3.5 DHCP Strona 1: UsBuga DHCP (ang. Dynamic Host Configuration Protocol) umo|liwia urzdzeniom w sieci otrzymywanie adresów IP i innych informacji z serwera DHCP. Ta usBuga automatyzuje przypisywanie adresów IP, masek podsieci, bramy i innych parametrów sieciowych . DHCP pozwala hostom otrzyma adres IP dynamicznie, kiedy tylko zostan podBczone 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. UsBuga DHCP jest preferowana w wikszych sieciach lokalnych lub tam, gdzie czsto zmieniaj si u|ytkownicy. U|ytkownicy mog dysponowa laptopami lub nowymi stacjami roboczymi, które trzeba podBczy do sieci. Automatyczne przydzielanie adresów IP jest sprawniejsze ni| rczne ich przypisywanie do ka|dej stacji roboczej przez administratora sieci. Adresy przydzielane przez DHCP nie s na staBe przypisywane do hostów - s one dzier|awione na okre[lony czas. Je|eli host zostanie wyBczony lub straci poBczenie z sieci, jego adres zostanie zwrócony do puli dostpnych adresów. Jest to szczególnie przydatne dla mobilnych http://ev-iip.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCServlet/LMS_ID=CNAMS,Theme=508theme,Style=508,La... 2010-01-18 22:49:16 CISCO Accessible Theme Strona 10 Adresy przydzielane przez DHCP nie s na staBe przypisywane do hostów - s one dzier|awione na okre[lony czas. Je|eli host zostanie wyBczony lub straci poBczenie z sieci, jego adres zostanie zwrócony do puli dostpnych adresów. Jest to szczególnie przydatne dla mobilnych u|ytkowników, którzy mog swobodnie przemieszcza si i ponownie nawizywa poBczenia z sieci. Host mo|e otrzyma adres IP w chwili, gdy zostanie nawizane sprztowe poBczenie z przewodow lub bezprzewodow sieci LAN. DHCP umo|liwia dostp do sieci Internet za pomoc bezprzewodowych punktów dostpowych (ang. hotspot) na lotniskach czy w kawiarenkach. Je|eli Twój laptop znajdzie si w zasigu lokalnego serwera DHCP, klient DHCP automatycznie pobierze adres IP. Jak pokazano na rysunku, serwerami DHCP mog by ró|ne urzdzenia, o ile maj uruchomion usBug DHCP. W wikszo[ci [rednich i du|ych sieci serwer DHCP jest lokalnym dedykowanym komputerem PC z uruchomion usBug serwera DHCP. Serwer DHCP znajduje si zwykle po stronie dostawcy usBug internetowych (ISP), a host w sieci domowej uzyskuje konfiguracj IP bezpo[rednio z tego serwera. DHCP mo|e powodowa zagro|enie bezpieczeDstwa, poniewa| dowolne urzdzenie poBczone z sieci mo|e otrzyma adres IP. To ryzyko nakazuje powa|nie rozwa|y bezpieczeDstwo 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. urzdzenia u|ytkownika koDcowego), za[ staBe adresy s przydzielane urzdzeniom sieciowym takim jak bramki, przeBczniki, serwery czy drukarki. Wy[wietl multimedia. 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 zarzdza pul adresów IP i wydzier|awia adres IP ka|demu uruchomionemu klientowi DHCP. Zwolnione adresy IP automatycznie wracaj do puli, aby mo|na byBo u|y ich ponownie. Gdy urzdzenie jest uruchamiane lub podBczane do sieci, klient DHCP rozgBasza pakiet DHCP DISCOVER w celu zidentyfikowania dostpnych 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 wicej serwerów DHCP, klient mo|e otrzyma wiele pakietów DHCP OFFER. Musi wtedy dokona wyboru oraz rozgBosi 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 zaBo|eniu, |e adres IP |dany przez klienta (lub zaoferowany przez serwer) jest dostpny, serwer zwraca komunikat DHCP ACK potwierdzajc tym samym, |e dzier|awa doszBa 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 wysyBa pakiet DHCP NAK (ang. Negative Acknowledgement). Je[li komunikat DHCP NAK zostanie zwrócony, to wysBanie pakietu DHCP DISCOVER spowoduje ponowne rozpoczcie procesu wyboru serwera. Dzier|awa adresu IP jest odnawiana komunikatem DHCP REQUEST, przed upByniciem 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 urzdzeD sieciowych jednocze[nie. DHCP umo|liwia administratorom sieci Batw rekonfiguracj adresów IP klientów, bez konieczno[ci zmieniania ich rcznie. Wikszo[ dostawców usBug internetowych stosuje DHCP w celu przydzielania adresów swoim klientom. Czwarty kurs CCNA Exploration dostarczy wicej szczegóBów na temat funkcjonowania DHCP. Wy[wietl multimedia. 3.3.6 UsBugi wspóBdzielenia plików i protokóB SMB Strona 1: SMB (ang. Server Message Block) jest protokoBem typu klient-serwer, który stosowany jest do udostpniania plików. ProtokóB SMB zostaB rozwinity przez firm IBM w póznych latach osiemdziesitych. Opisuje on struktur wspóBdzielonych zasobów sieciowych , takich jak katalogi, pliki, drukarki czy porty szeregowe. Jest to protokóB typu |danie-odpowiedz. W przeciwieDstwie do protokoBu FTP , klienci nawizuj dBugoterminowe poBczenia z serwerem. Po ustanowieniu poBczenia, u|ytkownik klienta ma dostp do zasobów na serwerze tak, jakby zasoby byBy lokalne dla hosta klienta. UsBugi drukowania oraz wspóBdzielenie plików za pomoc SMB stanowi podstaw sieci Microsoft. Wraz z wprowadzeniem oprogramowania dla systemu operacyjnego Windows 2000 , Microsoft zmieniB struktur systemu na potrzeby protokoBu SMB. W poprzednich wersjach produktów Microsoft, usBugi SMB nie u|ywaBy protokoBów TCP/IP do procesu odwzorowywania nazw. Poczynajc od systemu Windows 2000, wszystkie kolejne produkty Microsoft u|ywaj usBugi DNS. To pozwala protokoBom TCP/IP na bezpo[redni obsBug wspóBdzielenia zasobów SMB (jak pokazano na rysunku). Systemy operacyjne LINUX oraz UNIX umo|liwiaj wspóBdzielenie zasobów z sieciami Microsoft za pomoc oprogramowania SAMBA, którego budowa oparta jest na protokole SMB. Systemy operacyjne Apple Macintosh równie| obsBuguj wspóBdzielenie zasobów u|ywajc protokoBu SMB. Wy[wietl multimedia. http://ev-iip.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCServlet/LMS_ID=CNAMS,Theme=508theme,Style=508,La... 2010-01-18 22:49:16 CISCO Accessible Theme Strona 11 Strona 2: ProtokóB SMB opisuje dostp do systemu plików, sposób generowania |daD o pliki przez klientów oraz komunikacj midzy procesami. Wszystkie komunikaty SMB maj wspólny format: nagBówki maj staBy rozmiar, natomiast parametry i dane - zmienny. Komunikaty SMB mog: rozpoczyna, uwierzytelnia i przerywa sesje ; kontrolowa dostp do plików i drukarek; pozwoli aplikacji wysyBa i odbiera komunikaty do i z innych urzdzeD. Proces wymiany plików w oparciu o SMB zostaB pokazany na rysunku. Wy[wietl multimedia. 3.3.7 UsBugi P2P i protokóB Gnutella Strona 1: Dotd poznaBe[ dwa protokoBy warstwy aplikacji: FTP oraz SMB, które umo|liwiaj dostp do plików. Teraz poznasz kolejny. WspóBdzielenie plików przez Internet jest obecnie bardzo popularne. Aplikacje P2P - oparte na protokole Gnutella - umo|liwiaj ludziom udostpnianie swoich plików (zgromadzonych na twardych dyskach), w celu pobrania ich przez innych u|ytkowników. Oprogramowanie klienta zgodne z protokoBem Gnutella pozwala u|ytkownikom poBczy si przez Internet z usBugami protokoBu Gnutella, zlokalizowa i mie dostp do zasobów udostpnionych przez inne urzdzenia. Istnieje wiele aplikacji obsBugujcych protokóB Gnutella, m.in. BearShare, Gnucleus, LimeWire (zaprezentowany na rysunku), Morpheus, WinMX oraz XoloX . Prace nad rozwojem protokoBu prowadzi obecnie GDF (ang. Gnutella Developer Forum). Jednak wiele rozszerzeD jest tworzonych równie| przez producentów oprogramowania. Wy[wietl multimedia. Strona 2: Wiele aplikacji P2P nie zapisuje w centralnej bazie danych wszystkich plików dostpnych na urzdzeniach uczestniczcych w wymianie. Przeciwnie, to urzdzenia te odpowiadaj na zapytania o dostpno[ odpowiednich plików. Spójrz na rysunek. Kiedy u|ytkownik jest poBczony z usBug Gnutella, jego aplikacje poszukuj innych wzBów Gnutella, z którymi mogByby si poBczy. WzBy te obsBuguj zapytania o lokalizacj zasobów i odpowiadaj na |dania. Poza tym zarzdzaj komunikatami kontrolnymi, które pomagaj usBudze odkrywa kolejne wzBy. Zazwyczaj przesyBanie plików funkcjonuje w oparciu o usBugi HTTP. ProtokóB Gnutella definiuje pi typów pakietów: ping - do wyszukiwania urzdzeD, pong - odpowiedz na ping, query - do lokalizacji pliku, query hit - odpowiedz na zapytanie, push - |danie pobrania pliku. Wy[wietl multimedia. 3.3.8 UsBugi i protokóB Telnet Strona 1: Na dBugo przed pojawieniem si komputerów z wyszukanymi graficznymi interfejsami u|ytkownika, ludzie u|ywali systemów tekstowych, które czsto byBy tylko terminalami fizycznie poBczonymi z komputerem centralnym. Kiedy powstaBy sieci, ludzie potrzebowali metody, która pozwoli na zdalny dostp do komputerów tak, jak to miaBo miejsce w przypadku poBczonych terminali. ProtokóB Telnet stworzony po to, aby sprosta wy|ej wymienionym potrzebom . PojawiB si we wczesnych latach siedemdziesitych. Jest jednym z najstarszych protokoBów warstwy aplikacji w stosie TCP /IP. Telnet dostarcza standardow metod emulacji terminala tekstowego dajc w ten sposób mo|liwo[ pracy zdalnej na komputerach podBczonych do sieci. Zarówno sam protokóB, jak i implementujce go oprogramowanie klienta, powszechnie nazywane jest Telnetem . PoBczenie realizowane za po[rednictwem protokoBu Telnet nazywane jest sesj VTY (ang. Virtual Terminal). Do poBczenia z interfejsem wiersza poleceD CLI (ang. command line interface) serwera Telnet u|ywa oprogramowania, które zapewnia te same cechy sesji terminala, jak w przypadku sesji nawizywanych z fizycznego urzdzenia poBczonego z serwerem. W celu wspierania poBczeD klienta Telnet, serwer uruchamia usBug nazywan demonem Telnet. PoBczenie wirtualnego terminala jest nawizywane z urzdzenia koDcowego przy pomocy aplikacji klienta Telnet. Klient Telnet dostpny jest w wikszo[ci systemów operacyjnych . W systemie Microsoft Windows aplikacja Telnet mo|e zosta uruchomiona z wiersza poleceD. Inne powszechnie u|ywane aplikacje terminala wspierajce klienta Telnet to: HyperTerminal, Minicom czy TeraTerm. http://ev-iip.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCServlet/LMS_ID=CNAMS,Theme=508theme,Style=508,La... 2010-01-18 22:49:16 CISCO Accessible Theme Strona 12 systemie Microsoft Windows aplikacja Telnet mo|e zosta uruchomiona z wiersza poleceD. Inne powszechnie u|ywane aplikacje terminala wspierajce klienta Telnet to: HyperTerminal, Minicom czy TeraTerm. Po nawizaniu poBczenia 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 wyBczy urzdzenie. Kliknij kolejno przyciski na rysunku, aby zobaczy przykBad dziaBania protokoBu Telnet. Wy[wietl multimedia. Strona 2: Telnet jest protokoBem typu klient-serwer. Okre[la sposób nawizywania i przerywania sesji VTY. Dostarcza skBadni poleceD u|ywanych do rozpoczynania sesji, jak i komendy kontrolne, które mog by wydawane w czasie sesji. Ka|de polecenie skBada si z przynajmniej dwóch bajtów. Pierwszy bajt jest znakiem specjalnym nazywanym znakiem IAC (ang. Interpret as Command). IAC sygnalizuje, |e nastpny bajt jest poleceniem. PrzykBady poleceD protokoBu 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 poBczony. Na przykBad, je[li u|ytkownik uruchomi program na serwerze, to za pomoc polecenia IP mo|e go zatrzyma. ProtokóB Telnet wspiera uwierzytelnianie u|ytkowników, ale nie wspiera szyfrowania danych. W czasie sesji wszystkie dane przesyBane s jawnym tekstem. To oznacza, |e dane mog zosta przechwycone i przeczytane. ProtokóB SSH (ang. Secure Shell) oferuje alternatywn i bezpieczn metod dostpu do serwera. Struktura SSH zapewnia bezpieczne zdalne logowanie oraz inne bezpieczne usBugi 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 ). W dalszej cz[ci kursu Telnet i SSH bd u|ywane w celu uzyskania dostpu i konfiguracji urzdzeD sieciowych w ramach laboratoriów. Wy[wietl multimedia. 3.4 Zajcia w laboratorium 3.4.1 Przechwytywanie strumieni danych Strona 1: W tym wiczeniu wykorzystamy komputer wyposa|ony w mikrofon i aplikacj Microsoft Sound Recorder. Plik audio mo|emy równie| pobra z Internetu. Kliknij ikon , aby uzyska wicej szczegóBów. Wy[wietl multimedia. 3.4.2 Laboratorium: Zarzdzanie serwerem WWW Strona 1: Podczas tego wiczenia pobierzesz, zainstalujesz oraz skonfigurujesz popularny serwer WWW - Apache. Przegldarka WWW bdzie u|ywana do poBczenia z serwerem, natomiast do przechwycenia komunikacji u|yjemy oprogramowania Wireshark. Analiza przechwyconego ruchu pomo|e uczestnikom zrozumie sposób dziaBania protokoBu HTTP. Kliknij ikon , aby uzyska wicej szczegóBów. Wy[wietl multimedia. 3.4.3 Laboratorium: UsBugi i protokoBy E-mail Strona 1: Podczas tego wiczenia skonfigurujesz i u|yjesz aplikacji klienta poczty elektronicznej do poBczenia z serwerem Eagle. Nastpnie bdziesz monitorowaB komunikacj i analizowaB przechwycone pakiety za pomoc oprogramowania Wireshark. Kliknij ikon , aby uzyska wicej szczegóBów. Wy[wietl multimedia. http://ev-iip.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCServlet/LMS_ID=CNAMS,Theme=508theme,Style=508,La... 2010-01-18 22:49:16 CISCO Accessible Theme Strona 13 3.5 Podsumowanie rozdziaBu 3.5.1 Przegld i podsumowanie Strona 1: Warstwa aplikacji jest odpowiedzialna za bezpo[redni dostp do procesów, które zarzdzaj komunikacj w sieci. SBu|y jako zródBo i cel komunikacji w sieciach danych. Aplikacje, protokoBy i usBugi warstwy aplikacji umo|liwiaj u|ytkownikom sensowne i efektywne wspóBdziaBanie. Aplikacje s programami komputerowymi, które komunikuj sie z u|ytkownikiem i które inicjuj proces przesyBania danych na |danie u|ytkownika. UsBugi s programami uruchamianymi w tle, które zapewniaj poBczenie pomidzy warstw aplikacji a ni|szymi warstwami modelu sieciowego. ProtokoBy dostarczaj struktur uzgodnionych reguB i procesów, które pozwalaj okre[lonemu urzdzeniu wysyBa i otrzymywa dane z ró|nych urzdzeD sieciowych . Dostarczanie danych z serwera mo|e by realizowane na |danie klienta lub pomidzy urzdzeniami, które dziaBaj w sieci peer-to-peer, gdzie relacja klient-serwer jest nawizywana w sposób zale|ny od tego , które urzdzenie w danym czasie jest zródBem, a które celem . Komunikaty s wymieniane pomidzy usBugami warstwy aplikacji na ka|dym urzdzeniu koDcowym zgodnie ze specyfikacjami protokoBów. ProtokoBy, takie jak np. HTTP , umo|liwiaj dostarczanie stron WWW na urzdzenia koDcowe. ProtokoBy SMTP/POP wspieraj wysyBanie i otrzymywanie poczty elektronicznej. SMB umo|liwia u|ytkownikom wspóBdzielenie plików. DNS tBumaczy nazwy zrozumiaBe dla czBowieka na numeryczne adresy - zrozumiaBe dla urzdzenia. Wy[wietl multimedia. Strona 2: Wy[wietl multimedia. Strona 3: W tym wiczeniu stworzysz i przeanalizujesz bardziej zBo|ony model sieci. Instrukcje do wiczenia podsumowujcego w symulatorze Packet Tracer (PDF) Wy[wietl multimedia. Strona 4: Aby nauczy si wicej Pytania do przemy[lenia Dlaczego tak wa|ne jest odró|nienie aplikacji od zwizanej z ni usBugi czy protokoBu? Dyskusj nale|y przeprowadzi w kontek[cie modeli sieciowych. Co staBoby si, gdyby wszystkie usBugi warstwy aplikacji wBczy do jednego wspólnego protokoBu? Nale|y zastanowi si nad zaletami i wadami istnienia jednego protokoBu. Jak zaprojektowaBby[ nowy protokóB dla nowej usBugi warstwy aplikacji? O czym nale|aBoby szczególnie pamita? Kto musiaBby uczestniczy w tym procesie i w jaki sposób informacja mogBaby by rozprzestrzeniana? Linki http://www.ietf.org/ http://www.protocols.com/ Wy[wietl multimedia. 3.6 Quiz do rozdziaBu 3.6.1 Quiz do rozdziaBu Strona 1: Wy[wietl multimedia. http://ev-iip.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCServlet/LMS_ID=CNAMS,Theme=508theme,Style=508,La... 2010-01-18 22:49:16 CISCO Accessible Theme Strona 14 Nastpny Poprzedni Do góry All contents are Copyright © 2007-2008 Cisco Systems, Inc. All rights reserved. | Proces tBumaczenia wspierany przez NextiraOne. O kursie Element obsBugiwany przez wtyczk http://ev-iip.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCServlet/LMS_ID=CNAMS,Theme=508theme,Style=508,La... 2010-01-18 22:49:16

Wyszukiwarka

Podobne podstrony:
CISCO Accessible Theme6
CISCO Accessible Theme8
CISCO Accessible Theme11
CISCO Accessible Theme1
CISCO Accessible Theme2
Cisco Access Servers
CISCO Accessible Theme9
CISCO Accessible Theme10
CISCO Accessible Theme7
CISCO Accessible Theme5
CISCO Accessible Theme4
ImageIcon AccessibleImageIcon
Cisco 1
cisco?na
CISCO CCNA Certifications CCNA 2 Module 6
JCheckBoxMenuItem AccessibleJCheckBoxMenuItem
AccessibleStreamable

więcej podobnych podstron