(Wykl6)ARCHITEKTURA SIECI
ustaliliśmy (patrz wyżej) solidny zbiór wymagań dla projektu sieci, która powinna zapewnić uniwersalne, wydajne, sprawiedliwe, trwałe i wysoko efektywne połączenie między dużą liczbą komputerów projektując sieć trzeba dodatkowo uwzględnić fakt, że sieci nie pozostają niezmienne, ale muszą rozwijać sie (nowe techniki, nowe aplikacje) dlatego stworzono ogólne ramy dla projektów, zwane zwykle architekturą sieci (network architecture), które sterują projektowaniem i implementacją sieci Dwie najszerzej opisywane architektury: architektura OSI, architektura Internetu.
PODZIAŁ NA WARSTWY I PROTOKOŁY
jezeli system jest skomplikowany, ma wiele różnorodnych cech to istnieje ogólny sposób postępowania z takim systemem, który polega na wydzieleniu w systemie części posiadających określone cechy, a dalej stworzenie abstrakcyjnego modelu takiej części taki abstrakcyjny model danej części ujmuje tylko niektóre ważne aspekty całego systemu (np. sieć jest sprowadzona do kanału logicznego między aplikacjami, patrz wyżej) jezeli jest więcej takich poziomów abstrakcji w systemie (w modelu systemu) to trzeba zapewnić jakiś interfejs między poziomami modelu wydzielony poziom abstrakcji ukrywa detale implementacji tego poziomu przed innymi poziomami i jest to bardzo użyteczne
zastosowanie takiego postępowania do sieci prowadzi do pojawienia się warstw w systemach sieciowych pomysł polega na rozpoczęciu od usług świadczonych przez istniejący sprzęt, a następnie na dodawaniu kolejnych warstw, z których każda świadczy wyższy (bardziej atrakcyjny) poziom usług usługi świadczone przez wyższe warstwy są realizowane za pomocą usług świadczonych przez niższe warstwy np. można sobie wyobrazić (patrz, rysunek) sieć jako dwie warstwy umieszczone między programem aplikacyjnym a sprzętem warstwa ponad sprzetem może w tym przypadku zapewniać łączność między komputerami, abstrahować istnienie złożonej topologii sieci warstwa wyżej korzysta ze wspomnianej łączności i zapewnia kanały między procesami, abstrahując, że np. sieć może czasami tracić komunikaty
podział na warstwy ma dwie zalety budowanie sieci rozkłada sie na elementy - zamiast realizować jeden monolityczny program, możemy realizować kilka warstw, z których każda rozwiązuje część problemu projekt będzie miał charakter modularny - gdy zechcemy dodać nową usługę, to zmodyfikujemy tylko funkcje w jednej warstwie, z usług innych warstw korzystamy w niezmienionej postaci
liniowa sekwencja wartw może być jednak nadmiernym uproszczeniem systemu na danym poziomie systemu może istnieć wiele abstrakcji, świadczących odmienne usługi wyższym warstwom, ale zbudowanym na tej samej abstrakcji niższego poziomu np. (patrz rysunek) dwa typy kanałów mogą być alternatywnymi propozycjami na pewnym poziomie wielopoziomowego systemu sieciowego
obiekty abstrakcyjne, o których do tej pory rozmawialiśmy i które tworzą warstwy systemu sieciowego, są nazywane protokołami (protocol) protokół wyświadzcza usługę komunikacyjną, którą obiekty na wyższym poziomie stosują do wymiany komunikatów tak więc sieć z poprzedniego rysunku obsługuje protokół żądanie / odpowiedź i protokół strumienia komunikatów, protokoły te odpowiadają wcześniej omówionym kanałom każdy protokół definiuje dwa różne interfejsy (patrz rysunek wyżej): interfejs usługi (service interface) do innych obiektów w tym samym komputerze, które chcą skorzystać z jego usług komunikacyjnych, definiuje operacje, które które lokalne obiekty mogą wykonać na protokole, np. protokół żądanie / odpowiedź będzie wspomagał operacje, za pomocą których aplikacja może nadawać i odbierać komunikaty , protokół definiuje interfejs stacji protokołu (peer interface) do swojego odpowiednika (stacji protokołu) w innym komputerze; definiuje on postać i znaczenie komunikatów wymienianych między stacjami protokołu w celu implementacji usług komunikacyjnych (w jaki sposób np. protokół żądanie / odpowiedź w jednym komputerze komunikuje sie ze swoim odpowiednikiem w drugim komputerze)
z wyjątkiem poziomu sprzętowego (stacje protokołu komunikują się bezpośrednio), komunikacja między stacjami protokołu jest pośrednia; każda stacja protokołu komunikuje się ze swoim odpowiednikiem po drugiej stronie za pomocą przesyłania komunikatów do pewnego protokołu na niższym poziomie, który z kolei przesyła ten komunikat do swojej stacji protokołu potencjalnie istnieje wiele protokołów na dolnym poziomie, z których każdy wyświadcza inną usługę komunikacyjną dlatego możemy przedstawić zestaw protokołów, z których każdy wyświadcza inną usługę komunikacyjną, za pomocą grafu protokołów (protocol graph) węzły grafu odpowiadają protokołom, a krawędzie, reprezentują relację zależy od na rysunku przedstawiono graf protokołu dla hipotetycznego systemu warstwowego, o którym rozmawialiśmy protokół RRP, czyli protokół żądanie / odpowiedź (Request / Replay Protocol) i protokół MSP, czyli protokół strumienia komunikatów (Message Steam Protocol) implementują dwa odmienne typy kanałów między procesami oba protokoły zależą od protokołu HHP czyli protokołu między komputerami (host - to - host protocol) , który wyświadcza usługę połączenia między komputerami załóżmy, że program dostępu do pliku w komputerze 1 zamierza nadać komunikat do swojego odpowiednika w komputerze 2, korzystając z usługi komunikacyjnej oferowanej przez protokół RRP aplikacja prosi protokół RRP , aby w jej imieniu wysłał komunikat stacja protokołu RRP porozumiewa się ze swoim odpowiednikiem w komputerze 2 w tym celu wywołuje usługę protokołu HHP , który z kolei nadaje komunikat do swojego odpowiednika we wspomnianym komputerze kiedy komunikat dociera do protokołu HHP w komputerze 2, HHP , przekazuje komunikat w góre do RRP , który z kolei dostarcza komunikat do aplikacji dostępu do pliku w ropatrywanym przykładzie mieliśmy do czynienia z aplikacją, która korzysta z usług stosu protokołów (protocol stack) RRP/HHP pojęciecie protokół jest stosowane na dwa różne sposoby może odnosić sie do interfejsów abstrakcyjnych, tzn. do operacji zdefiniowanych przez interfejs usługi oraz do postaci i znaczenia komunikatów wymienionych między stacjami czasem odnosi się do modułu, który w rzeczywistości implementuje te dwa interfejsy
w celu rozróżnienia pomiędzy interfejsami a modułem implementującym te interfejsy, odwołujemy się do tych pierwszych, jako do specyfikacji protokołu (protocol specification) specyfikacje wyrażone są za pomocą kombinacji tekstu, pseudokodu, diagramów przejść stanów, rysunków formatów pakietów oraz innych abstrakcyjnych notacji dany protokół może być implementowany na różne sposoby przez różnych programistów, pod warunkiem, że każdy z nich stosuje się do specyfikacji wyzwaniem jest zapewnienie aby dwie odmienne implementacje tej samej specyfikacji mogły z powodzeniem wymieniać komunikaty o dwóch lub więcej modułach protokołu, które ściśle implementują specyfikację protokołu, mówimy, że ze sobą współpracują można sobie wyobrazić wiele różnych protokołów oraz grafów protokołów, które spełniają wymagania komunikacyjne pewnego zbioru aplikacji organizacje normalizacyjne, które ustalają określoną politykę dla danego grafu protokołów to
International Standards Organization (ISO)
Internet Engineering Task Force (IETF)
organizacje te ustanowiły procedury wprowadzenia, weryfikacji i zatwierdzenia każdego protokołu w architekturze sieci architektura sieci to zbiór reguł rządzących postacią i zawartością grafu protokołów
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
KAPSUŁKOWANIE KOMUNIKATÓW
załóżmy, że program aplikacyjny nadaje komunikat do swojego odpowiednika (patrz, rysunek), przekazując ten komunikat do RRP z punktu widzenia RRP ten komunikat jest nieinterpretowanym strumieniem bajtów RRP jest jedynie zobowiązany do wysłania komunikatu do swojego odpowiednika; musi w tym celu przekazać informację sterującą do swojego odpowiednika RRP dokonuje tego przez dołączenie nagłówka (header) do komunikatu (mała struktura danych), do jego początku, a w pewnych przypadkach na końcu i wtedy jest nazywany ogonem (trailer) mowimy, że dane do przesłania, nazywane treśćią (body) sa kapsułkowane(encapsulated) wewnątrz nowego komunikatu, stworzonego przez protokół RRP proces kapsułkowania (encapsulation) jest nastepnie powtarzany na każdym poziomie grafu protokołów, a wiec ptotokół HHP dokonuje kapsulkowania komunikatu protokolu RRP dołączjąc do niego wlasny nagłowek HHP nadaje komunikat do swojego odpowiednika poprzez pewna siec HHP w węzle docelowym pobiera swój naglowek z początku komunikatu, interpretuje go (podejmuje akcją zgodnie z zawartoscia naglowka), a samą treść komunikatu przekazuje w górę do protokołu RRP RRP usuwa nagłówek dołączony wczesniej przez swojego odpowiednika, podejmuje akcję wskazaną przez swojego odpowiednika i przekazuje treść komunikatu w góre do programu aplikacyjnego chociaż protokół na niższym poziomie nie interpretuje komunikatu przekazanego przez protokół z wyższego poziomu, to czasami stosuje prostą transformacje danych, np. kompresje lub szyfrowanie
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
MULTIPLEKSACJA I DEMULTIPLEKSACJA
zasadnicza ideą komutatcji pakietów, jak widzieliśmy, jest zwielokrotnienie wielu przwpływów danych na jednym łączu fizycznym ta idea ma również zastosowanie przy przechodzeniu w górę i w dół grafu protokołow mozna sobie wyobrazić (patrz, przykład grafu protokołów) ptotokół RRP realizujący logiczny kanal komunikacyjny. z komunikatami z dwóch różnych aplikacji multipleksowanych w komputerze nadawczym, a następnie demultipleksowanych do właściwej aplikacji komputerze odbiorczym oznacza to, że RRP dolącza do swoich komunikatów nagłówek zawierający identyfikator aplikacji, do korej dany komunikat nalezy, tzw. klucz demultipleksacji(demultiplexing key) protokołu RRP w komputerze odbiorczym RRP odłącza ten nagłówek, bada klucz i dokonuje demultipeksacji komunikatów do właściwej aplikacji prawie każdy protokół implementuje ten mechanizm, jednak nie istnieje jednolita umowa między protokołami, co tak naprawdę stanowi klucz demultipleksacji (pola 8 - bitowe mogące obsłużyc jedynie 256 protokołów wyższego poziomu, pola 16 - i 32 - bitowe ...)