Lekce 3: Síové modely a architektury, RM ISO/OSI

Transkript

1 Poítaové sít, v. 3.0 Katedra softwarového inženýrství, Matematicko-fyzikální fakulta, Univerzita Karlova, Praha Lekce 3: Síové modely a architektury, RM ISO/OSI Jií Peterka, 200!"#$

2 Vrstevnatá filozofie implementovat funkní sí je hodn složité a nároné!"# stejná situace jako pi ešení velkých SW celk jde o jeden velký problém, který se vyplatí dekomponovat rozdlit na menší ásti, které je možné ešit samostatn zde: dekompozice se provede po hierarchicky uspoádaných vrstvách dobe to odpovídá povaze ešeného problému pináší to i další výhody možnost alternativních ešení na úrovni nižších vrstev vtší modulárnost. sí (jako celek) musí se vyešit otázky jako: kolik má být vrstev co má která dlat jak mají vrstvy spolupracovat.. vertikáln (v rámci uzlu) horizontáln (mezi uzly)

3 zpsob komunikace mezi mi v rámci uzlu: s bezprostedn vyšší vrstvou mezi uzly: jen se stejnolehlými mi (peers) nikdy ne mezi nesousedními mi!!! v rámci uzlu: s bezprostedn nižší vrstvou nikdy ne mezi mi na rzných úrovních!!!!"#

4 "horizontální" komunikace mezi mi PDU hlavika tlo vzájemná komunikace stejnolehlých vrstev rzných uzl se musí ídit pedem dohodnutými pravidly pravidla této vzájemné komunikace definuje tzv. protokol protokol definuje (mj.):!"#% co si komunikující strany posílají, jaký to má formát a význam, kódování atd. obecn: komunikující strany si pedávají tzv. PDU (Protocol Data Unit) každý PDU má dv ásti: hlaviku (header)) a tlo (náklad, payload) jak komunikace probíhá, jak mají strany reagovat na rzné situace atd. ošetuje nestandardní situace PDU se na úrovni rzných vrstev nazývá rzn: rámec, paket, segment,

5 upesnní: entity a protokoly vrstvy nejsou jednolité protokol definuje pravidla komunikace mezi entitami stejnolehlých vrstev v každé vrstv mže existovat a fungovat nkolik relativn samostatných vrstvy entit protokol entita mže být nap. proces, démon, uruje zpsob, jakým je realizována uritá služba úloha entity ve stejné vrstv mohou plnit rozdílné funkce (nekonkurovat si) plnit obdobné funkce (ale jiných zpsobem, tj. konkurovat si) entita entita entita protokol protokol protokol každý protokol vždy patí do urité konkrétní pro každou vrstvu mže existovat nkolik alternativních protokol jeden nap. pro spojovaný penos, druhý pro nespojovaný souasné použití rzných protokol (v rámci téže vrstvy) se nemusí vyluovat entita entita entita!"#&

6 "horizontální" komunikace mezi mi komunikace mezi stejnolehlými mi (entitami) rzných uzl má asynchronní charakter!"#' "pošlu své PDU a ekám na odpov" odpov pijde "kdykoli" (nezávisle na tom, co práv dlám) lze pirovnat k zasílání zpráv pošlu zprávu a ekám na odpov veškeré "režijní" informace, urené "protistran" (partnerské entit na druhé stran) musí být obsaženy v jednotce PDU tlo vše, co píjemce potebuje vdt, aby mohl zpracovat data v nákladové ásti (tle) PDU v její hlavice nap. druh zasílaných dat, poadové íslo PDU, adresa odesilatele e a píjemce, kontrolní souet, píznaky,.

7 "horizontální" komunikace mezi mi PDU iluze skutenost pedstava, že si stejnolehlé vrstvy skuten pedávají (pímo) mezi sebou jednotky PDU (rámce,( pakety, segmenty, ) je POUZE ILUZÍ ve skutenosti je pedávají bezprostedn nižší vrstv k doruení druhé stran!!! nižší je vloží do svého PDU!"#(

8 "horizontální" komunikace mezi mi pedávání PDU (bezprostedn) nižší vrstv k doruení pokrauje až k nejnižší vrstv (fyzické vrstv) pouze nejnižší (fyzická ) skuten penáší njaká datad po jednotlivých bitech!!! !"#)

9 "vertikální" komunikace mezi mi má charakter:!"#* poskytování služeb poskytuje své služby bezprostedn vyšší vrstv využívání služeb využívá služeb, poskytovaných bezprostedn nižší vrstvou využívá je k plnní svých úkol píklad: nejnižší (fyzická) penáší jednotlivé bity bezprostedn vyšší (linková) využívá penosu jednotlivých bit k tomu, aby penášela celé bloky dat» tzv. rámce (své PDU) poskytování služby využívání služby rozhraní rozhraní mezi mi je definované rozhraní je implementan závislé, není "vidt" mimo daný uzel!!! komunikace mezi mi probíhá skrze "pechodové body" v tomto rozhraní ISO/OSI: body SAP (Service Access Points) TCP/IP: porty identifikace pechodových bod je viditelná i "z vn"!!! nezávisí na platform nap. ísla port

10 "vertikální" komunikace mezi mi neprobíhá po 2 samostatných kanálech!"#$ požadavek 1x pro požadavek (píkaz, operace) 1x pro data data dvod: byly by nutné 2 pechodové body nebo njaké zdvojení pechodových bod místo toho: požadavek (píkaz) se "zabalí" spolu s daty do jednoho "balíku" (IDU) a ten se pedá skrze pechodový bod IDU (Interface Data Unit) ICI (Interface Control Info) SDU (Service( Data Unit) píkaz ICI ICI IDU IDU data SDU SDU rozhraní

11 entita píkaz: pošli druhé stran pedstava "vertikální"&"horizont horizontální" komunikace PDU entita vrstvy n+1 chce pedat PDU své partnerské entit entita ICI SDU ve skutenosti pedá k doruení bezprostedn nižší vrstv n+1 n IDU IDU pipojí píkaz (pošli druhé stran) pedá skrze pechodový bod entita ICI píkaz: pošli druhé stran "vzkaz" SDU entita vrstvy n interpretuje píkaz (vloží data do svého PDU a pipojí "vzkaz" pro svou partnerskou entitu "pošli nahoru") data entita!"#$$ "vzkaz"

12 "vertikální" komunikace - obecn n+1 entita "nco chce" entita request indication n entita confirmation entita response request (žádost) generuje entita vrstvy n+1, která žádá o poskytnutí služby (žadatel) indication (indikace, oznámení) generuje "protilehlá" entita vrstvy n, upozoruje svou "nadazenou" entitu vrstvy n+1 na požadavek response (odpov) generuje "protilehlá" entita vrstvy n+1, v odpov na požadavek confirmation (potvrzení) generuje entita vrstvy n, potvrzuje tím vyízení pvodního požadavku avku entity vrstvy n+1 obecná primitiva, v terminologii "svta spoj" (umožují pístup ke službám)!"#$

13 asový prbh komunikace - obecn n+1 n n n+1 request nespojovaný zpsob komunikace "žadatel" vyšle žádost indication žádost pijme entita "žadatele" na vrstv n a pedá své partnerské entit u "poskytovatele" "poskytovatel" je upozornn na žádost entita vrstvy n u "poskytovatele" pijme požadavek a upozorní na nj nadazenou entitu (na vrstv n+1) spojovaný zpsob komunikace "žadatel" vyšle žádost "poskytovatel" je upozornn na žádost "poskytovatel" vygeneruje odpov "žadatel" obdrží potvrzení o vyízení svého požadavku n+1 n n n+1 request confirmation indication response!"#$

14 konkrétní píklad komunikace klient/server primitiva (operace): listen (pro server) ekání na píchod žádosti o navázání spojení connect (pro klienta) vyšle žádost o navázání spojení receive (pro server) ekání na píchod zprávy/požadavku send (pro klienta) odeslání dat disconnect (pro klienta) ukonení spojení klient connect() send() disconnect() connect request request ack data ack disconnect request disconnect request server listen() receive()!"#$% primitiva mají charakter volání procedur

15 shrnutí služby (angl.: services) týkají se vertikální komunikace mezi mi jsou poskytovány "skrze" rozhraní mezi mi služby ani rozhraní nejsou "vidt" z vn daného uzlu jediná výjimka: identifikace pechodových bod, slouží k identifikaci entit v rámci vrstvy rozhraní mezi mi nemusí být standardizováno mže být (a bývá) na rzných uzlech/platformách rzné nemusí být (a nejsou) standardizovány ani služby není poteba, aby byly na všech uzlech stejné služby služby protokoly (angl.: protocols) týkají se "horizontální" komunikace mezi stejnolehlými mi rzných uzl protokoly jsou "vidt" z vn daného uzlu jejich implementace mže zstat skryta protokoly musí být standardizovány musí být dopedu a všem známo, jaké jsou pravidla, formáty, postupy atd. protokol služby služby!"#$&

16 síový model a síová architektura síový model je ucelená pedstava o tom, jak mají být sít ešeny!"#$' zahrnuje: pedstavu o potu vrstev pedstavu o tom, co má mít která na starosti nezahrnuje: konkrétní pedstavu o tom, jak má která své úkoly plnit tedy konkrétní protokoly píklad síového modelu: referenní model ISO/OSI síová architektura obsahuje navíc také: konkrétní protokoly tj. obsahuje i konkrétní protokoly píklad síové architektury: rodina protokol TCP/IP konkrétní protokoly vznikaly samostatn a dodaten

17 referenní model ISO/OSI byl pokusem vytvoit univerzální síovou architekturu,!"#$( skonil jako síový model bez protokol, ty se dodlávaly postupn pochází ze svta spoj od organizace ISO (International( Standards Organization,, správn: International Organization for Standardization) v eštin: Mezinárodní organizace pro normalizaci leny ISO jsou národní normalizaní instituce za R organizace SNI byl oficiálním ešením ešením, které prosazovaly "orgány státu" a chtly jej nasadit do praxe dnes je prakticky odepsaný, prohrál v souboji s TCP/IP

18 geneze referenního modelu ISO/OSI reagoval na vznik proprietárních a uzavených sítí IBM SNA,... prvotní zámr: definovat, jak mají vypadat otevené systémy odsud: Open Systems Architecture tj. i chování uvnit, nejen mezi sebou ukázalo se jako píliš nároné, dochází k redukci ambic druhé piblížení: bude se týkat jen vzájemného propojení otevených systém zmna názvu: Open Systems Interconnection Architecture opt se ukázalo jako píliš nároné tetí piblížení: nebude to obsahovat konkrétní protokoly ale jen pedstavu o potu vrstev a o tom, co má která dlat Co je referenní model ISO/OSI? poslední iterace názvu Open Systems Interconnection když byly odstranny protokoly, zbyl jen síový model jde o obecný rámec, do které jsou zasazována konkrétní ešení konkrétní protokoly pro RM ISO/OSI byly vyvíjeny samostatn a teprve dodaten zaazovány do rámce ISO/OSI!"#$)

19 Filosofie RM ISO/OSI vznikal od zeleného stolu!"#$* a pak byl nadiktován uživatelm vznikal maximalistickým zpsobem autoi se snažili zahrnout vše, co by nkdy nkomu mohlo hodit výsledek byl dosti odtažitý od reálné praxe celá ešení se asto ukázala jako nerealizovatelná, a hledala se implementovatelná podmnožina vznikaly rzné implementovatelné podmnožiny, které nebyly vzájemn kompatibilní mnohé výchozí pedpoklady se ukázaly jako chybné profily GOSIP když si státní (veejné) instituce kupovaly síové vybavení, trvaly na tom, aby vycházelo z ISO/OSI ale RM ISO/OSI je píliš široký, a pro praktické použití je nutné jej zúžit (vybrat implementovatelnou podmnožinu) státní (veejné) instituce musely takovouto podmnožinu pesn vyspecifikovat tím vznikly profily GOSIP (Government( OSI Profile) pro srovnání: rodina protokol TCP/IP vznikala postupným obohacováním nejprve se navrhlo jednoduché ešení teprve postupn se "obohacovalo" až na základ skutené poteby nové ešení muselo nejprve prokázat svou životaschopnost (možnost implementace, provozní zkušenosti)

20 sedm vrstev ISO/OSI autoi ISO/OSI se dosti dlouho peli o potu vrstev kritéria pro volbu vrstev:!"# innosti na stejném stupni abstrakce mají patit do stejné vrstvy odlišné funkce by mly patit do odlišných vrstev aby bylo možné pevzít již existující standardy aby datové toky mezi mi byly co nejmenší aby vrstvy byly rovnomrn vytíženy... nakonec zvítzil návrh na 7 vrstev dnes se 7 vrstev zdá být zbyten mnoho nap. rodina protokol TCP/IP má jen vrstvy nkteré vrstvy ISO/OSI jsou "málo vytížené" nap. relaní a prezentaní jedna ISO/OSI (linková) je naopak "petížená" a rozpadla se na dv podvrstvy podvrstvu LLC podvrstvu MAC zde šlo hlavn o již existující standard X.25

21 sedm vrstev ISO/OSI aplikaní prezentaní vrstvy orientované na podporu aplikací relaní transportní síová linková (spojová, datového spoje) fyzická pizpsobovací vrstvy orientované na penos dat (šito na míru filosofii veejných datových sítí dle X.25)!"#$

22 fyzická zabývá se výhradn penosem bit!"# a v rámci toho otázkami typu: kódování, modulace, asování, synchronizace, el. parametry signál, konektory, ídící signály rozhraní,... nabízí služby typu pijmi bit, odešli bit nijak neinterpretuje to, co penáší jednotlivých bitm nepisuzuje žádný specifický význam každý bit penáší stejn datový, režijní, na úrovni fyzické vrstvy se rozlišuje: paralelní a sériový penos synchronní, asynchronní a arytmický penos penos v základním a peloženém pásmu pro penos bit mohou být využívána rzná penosová média drátová bezdrátová na úrovni fyzické vrstvy se pracuje s veliinami jako je: šíka pásma (bandwidth( bandwidth) modulaní rychlost penosová rychlost

23 linková (spojová ) penáší celé bloky dat tzv. rámce (frames) využívá k tomu služby fyzické vrstvy!"# pijmi/odešli bit penos rámc zajišuje pouze k pímým sousedm pouze v dosahu pímého spojení, bez "pestupu" pes mezilehlé uzly mže fungovat spolehliv i nespolehliv spojovani nespojovan mže využívat rzné penosové technologie na úrovni fyzické vrstvy linková úkoly linkové vrstvy: synchronizace na úrovni rámc správné rozpoznání zaátku a konce rámce, i všech jeho ástí zajištní spolehlivosti (pokud je požadováno) detekce chyb a jejich náprava ízení toku zajištní toho, aby vysílající nezahltil píjemce pístup ke sdílenému médiu eší konflikty pi vícenásobném pístupu ke sdílenému médiu tento úkol nebyl mezi pvodn uvažovanými následn zpsobil rozpad linkové vrstvy na dv podvrstvy pod LLC pod MAC ostatní úkoly pístup ke sdílenému médiu

24 Pedstava fungování linkové vrstvy blok dat (rámec, angl. frame) hlavika tlo patika blok dat linková fyzická linková fyzická!"#%

25 Pedstava fungování linkové vrstvy každý uzel uzel "vidí" jen jen své své pímé sousedy!"#&

26 Síová penáší bloky dat oznaované jako pakety (packets)!"#' fakticky: vkládá je do linkových rámc pedává linkové vrstv k doruení zajišuje doruení paket až ke konenému adresátovi tj. pes rzné mezilehlé uzly tzv. smrovae hledá vhodnou cestu až k cíli zajišuje tzv. smrování (routing) mže používat rzné algoritmy smrování: adaptivní, neadaptivní izolované, distribuované, centralizované,.. je poslední vrstvou, kterou musí mít i "pestupní" uzly tzv. smrovae (zajišující smrování) aplik. v. transp. v. aplik. v. transp. v. síová v. síová v. síová v. linková v. fyzická v. linková v. fyzická v. linková v. fyzická v. sí

27 Pedstava fungování síové vrstvy hlavika tlo síová linková fyzická hlavika paket tlo tlo patika rámec síová linková fyzická!"#(

28 Hlavní úkol síové vrstvy doruovat data od jejich zdroje až k jejich koncovým adresátm což mže obnášet peskok pes rzné mezilehlé uzly linková se stará jen o doruováním k pímým sousedm (v dosahu pímého spojení) a nezabývá se peskoky peskok vyžaduje: routing (smrování) - rozhodnutí o dalším smru penosu, volba trasy forwarding faktické vykonání "peskoku"!"#)

29 Pedstava fungování síové vrstvy každý uzel uzel "zná" celou topologii sít sít!"#*

30 Transportní teze:!"# nelze hýbat s vlastnostmi a funkcemi nižších vrstev teba proto že patí nkomu jinému vyšší vrstvy mohou chtít nco jiného, než co nabízí nižší vrstvy je úkolem transportní vrstvy zajistit potebné pizpsobení! zajišuje: komunikaci mezi koncovými úastníky (end-to-end komunikaci) mže mnit nespolehlivý charakter penosu na spolehlivý mén spolehlivý penos na více spolehlivý nespojovaný penos na spojovaný orientace na služby orientace na penos aplikaní prezentaní relaní transportní síová linková (spojová, datového spoje) fyzická

31 Pedstava transportní vrstvy!"#$ aplikaní v.... transportní v. síová v. linková v. fyzická v. Píklad: TCP TCP spojovaný a spolehlivý penos UDP UDP --nespojovaný a nespolehlivý penos end-to-end komunikace Píklad: IP (nespolehlivý a nespojovaný penos) aplikaní v.... transportní v. síová v. linková v. fyzická v.

32 Další úkol transportní vrstvy do vrstvy síové (vetn) se uzly chápou jako nedlitelné celky síové adresy reprezentují celé uzly napíklad: IP adresy v TCP/IP transportní již rozlišuje konkrétní entity v rámci každého uzlu jednotlivé procesy, démony, úlohy. rozlišuje je obvykle nepímo, skrze pechodové body (body( SAP, porty) ) ke kterým jsou tyto entity asociovány nap. ísla port v TCP/IP vyšší transportní entita port? entita port!"#

33 Relaní zajišuje vedení relací a co jsou relace? mže zajišovat: synchronizaci šifrování podporu transakcí má toho pomrn málo na práci existence relaní vrstvy v RM ISO/OSI je nejvíce kritizována v TCP/IP relaní zcela chybí!"#

34 Pedstava relací relaní transportní jeden dialog (relace) po po výpadku je je spojení spojení vytoeno znovu znovu v rámci rámci jednoho jednoho spojení spojení probíhají (postupn) dva dva dialogy dialogy!"#%

35 Prezentaní nižší vrstvy se snaží doruit každý bit pesn tak, jak byl odeslán stejná posloupnost bit mže mít pro píjemce jiný význam než pro odesilatele, nap. kvli kódování znak (ASCII, EBCDIC,...) formátu ísel formátu struktur, polí ukazatelm (pointerm) prezentaní má na starosti potebné konverze, tak aby ob strany interpretovaly penášená data stejn nap. u reálných ísel, text prezentaní má na starosti pevod penášených dat z/do takového tvaru, v jakém je možné je penášet nap. je nutné "zlinearizovat" zlinearizovat" vícerozmrná pole, vícerozmrné datové struktury týká se to nap. i zpsobu ukládání vícebytových položek do pamti která je posloupností byt penosový kanál je je 1-rozmrný!"#&

36 týká se ukládání vícebytových položek do pamti píklad: konvence Little Endian vs. Big Endian Big Endian (vyšší byte je na nižší adrese) Little Endian (nižší byte je na nižší adrese) !"#' 3H 12H nap. mikroprocesory Motorola, mainframy IBM, Internet 123H H 3H nap. mikroprocesory Intel, Ethernet

37 Pedstava: linearizace struktur a 11 a 12 a 13 a 21 a 22 a 23 a 31 a 32 a 33 pro poteby penosu musí být vícerozmrné datové struktury linearizovány a 11 a 12 a 13 a 21 a 22 a 23 a 31 a 32 a 33 a 11 a 12 a 13 a 21 a 22 a 23 a 31 a 32 a 33 penosový kanál je lineární!"#(

38 Aplikaní pvodní pedstava:!"#) bude obsahovat aplikace problém: aplikací je moc, musely by být všechny standardizovány pozdji: to nejde stihnout nemlo by to ani smysl aplikaní bude obsahovat pouze jádro aplikací, které má smysl standardizovat napíklad penosové mechanismy el. pošty ostatní ásti aplikací (typicky: uživatelská rozhraní) byly vysunuty nad aplikaní vrstvu aplikace aplikaní transportní ásti aplikace nevyžadující standardizaci ásti aplikace vyžadující standardizaci aplikaní transportní

39 Kritika RM ISO/OSI je píliš prodchnut svtonázorem lidí od spoj, ale ml sloužit lidem od poíta je píliš složitý, tžkopádný a obtížn implementovatelný je píliš maximalistický!"#* chce nejprve všechno, a pak se musí uskrovovat vzniká od zeleného stolu, nerespektuje požadavky a realitu bžné praxe poítal spíše s rozlehlými sítmi než se sítmi lokálními nkteré innosti (funkce) zbyten opakuje na každé vrstv jednoznan upednostuje spolehlivé a spojované penosové služb nkteré pedpoklady, uinné pi vzniku RM ISO/OSI, se nenaplnily napíklad: autoi pedpokládali, že v každé zemi bude jedna velká sí vlastnná a provozovaná státem dsledek: nebyl žádný draz na tzv. internetworking,, neboli na vzájemné propojování sítí v TCP/IP byl od zaátku velký draz práv na internetworking autoi pedpokládali propojení uzl výhradn pomocí dvoubodových spojení linková pvodn neešila sdílený pístup (když jde o sdílený spoj) dsledek: došlo k rozdvojení linkové vrstvy na dv podvrstvy

40 RM ISO/OSI, spolehlivost a spojovanost spolehlivost: RM ISO/OSI poítá primárn se spolehlivými penosovými službami pedstava lidí od spoj: nespolehlivou penosovou službu (která mže ztrácet data) by si nikdo nekoupil!! proto i penosová infrastruktura (do síové vrstvy) musí fungovat spolehliv pedstava lidí od poíta: zajištní spolehlivosti je spojeno s velkou režií spolehlivost si efektivnji zajistí koncové uzly nespolehlivé penosové služby se do RM ISO/OSI dostaly až dodaten na nátlak lidí od poíta RM ISO/OSI poítal jen se spojovanými penosovými službami odpovídá to zpsobu fungování telekomunikaních sítí, nap. telefonní sít pro menší a mén pravidelné penosy mže být výhodnjší nespojovaný charakter penosu možnost nespojovaného penosu se do RM ISO/OSI dostala až dodaten!"#%

41 RM ISO/OSI dnes RM ISO/OSI byl dlouhou dobu "oficiálním ešením" státní správa chtla ešit všechny sít ve své kompetenci na RM ISO/OSI nutné profily GOSIP a "zúžení" nakonec se ukázalo jako neschdné dnes je RM ISO/OSI "na hlavu poražen" rodinou protokol TCP/IP lze jej považovat za "odepsaný" dodnes je dobrým "uebnicovým píkladem" toho jak se vci mají dlat rozdlení do vrstev, rozdíl mezi službami, protokoly a rozhraními toho, jak se vci nemají dlat návrhy od zeleného stolu, velikášství, nepraktinost,. nkteré protokoly, vyvinuté v rámci RM ISO/OSI, však byly rzn pevzaty a používají se i dnes pevzaty píklady: X.00 (ešení el. pošty) velmi univerzální, je základem MS Exchange (uvnit, nikoli navenek) X.500 (adresáové služby) "odlehením" (zjednodušením) vznikl úspšný protokol LDAP (Lightweight Directory Access Protocol)!"#%$