Poítaové sít, v. 3.0 Srovnání RM ISO/OSI % Katedra softwarového inženýrství, Matematicko-fyzikální fakulta, Univerzita Karlova, Praha Lekce : Rodina protokol TCP/IP Jií Peterka, 200 Motto: Víš-li, jak na to, tyi vrstvy ti pln postaí. Nevíš-li, ani sedm ti jich nepomže. též: IP IP vrstva TCP/IP transportní síová vrstva síového rozhraní RM ISO/OSI prezentaní relaní transportní síová linková fyzická Co je TCP/IP? V em se liší TCP/IP a ISO/OSI? síová architektura: dnes: obsahuje ucelenou pedstavu o potu a nejpoužívanjší síová technologie úloze vrstev nejrozšíenjší síová architektura obsahuje i konkrétní protokoly prosadila se lépe než cokoli jiného (RM ISO/OSI, IPX/SPX atd.) obvyklé oznaení: funguje nad vším TCP/IP protocol suite IP over Everything (rodina protokol TCP/IP) protokoly TCP/IP dokáží fungovat nad souástí je více jak 100 protokol každou (linkovou) penosovu postup vzniku: technologií nejprve: protokoly všechno funguje nad IP teprve potom: vrstvy Everything over IP snad všechny již byly TCP/IP vzniklo v akademickém implementovány (portovány( portovány) ) i nad prostedí protokoly TCP/IP a dokáží nad nimi prosadilo se i v komerním prostedí fungovat od svého vzniku se zmnilo jen neznamená to že TCP/IP je ideální relativn málo nikoli zásadn zmny jsou aditivní má také adu nevýhod, nedostatk v celkovém pístupu autor ISO/OSI: všechno musíme vymyslet sami (nebo alespo pevzít to, co vymysleli jiní, a udlat z toho vlastní standard) píklad: ISO vydává Ethernet jako svj standard ISO 8802.3 TCP/IP: to co je rozumné pevezmeme a využijeme soustedí se na "provázání" vlastních ešení s cizími eší nap. jak provozovat IP nad Ethernetem ve zpsobu tvorby nových ešení: ISO/OSI: od složitého k jednoduššímu ešení vznikají od zaátku jako "dokonalá" nejprve navymýšlí vzdušné zámky, pak musí slevovat nejprve vznikne standard, pak se zkoumá á praktická realizovatelnost TCP/IP: od jednoduššího ke složitjšímu ešení vznikají nejprve jako "skromná", postupn se obohacují nejprve se ešení oví, a teprve pak vzniká standard Konkrétn. Historie vzniku TCP/IP v pohledu na poet vrstev a zpsob jejich fungování jaké služby mají být nabízeny a na jaké úrovni mají být poskytovány kde má být zajišována spolehlivost jak mají služby fungovat spolehlivost/nespolehlivost, spojovanost/nespojovanost nespojovanost, princip maximální snahy vs. garance kvality služeb, zda má být ponechána možnost volby mají právo si vybrat nap. mezi spolehlivým a nespolehlivým penosem? TCP/IP vrstva transportní v. (IP vrstva) vrstva síového rozhraní ISO/OSI v. prezentaní v. relaní v. transportní v. síová v. linková v. fyzická v. souvisí s Internetem (ARPANETem( ARPANETem) bylo poteba v praxi ovit životaschopnost paketové technologie pepojování paket byla postavena velká testovací sí ARPAnet (zárodek pozdjšího Internetu) pro zárodenou sí byl vyvinut "prozatímní" protokol: NCP (Network Control Protocol) protokol NCP nebyl vhodný pro rutinní používání vše financoval DoD (Department of Defense), skrze grantovou agenturu (D)ARPA proto: ARPANET další vývoj: když si DoD ovil životaschopnost paketové technologie, rozhodl se testovací sí nezrušit, ale pedat ji akademické sfée do rutinního používání další vývoj: na zárodený ARPANET se zaaly nabalovat další sít postupn vznikl Internet pro rutinní provoz ARPANETu/Internetu byl,o teba vyvinout nové "rutinní" protokoly protokoly TCP/IP byly vyvíjeny jako definitivní ešení pro vznikající Internet peníze na vývoj protokol TCP/IP poskytl DoD (ministerstvo obrany USA) specifikace jsou volné (PD, veejné vlastnictví) (v USA): když už daoví poplatníci jednou zaplatí, nemusí to platit podruhé vlastní návrh vznikal zejména v akademickém prostedí & ' verze 3.0, ást : Rodina protokol TCP/IP Jií Peterka, MFF UK, 200 1
Lidé kolem TCP/IP Historie vzniku TCP/IP ústední postavou byl Vinton G. Cerf do r. 1972 postgraduální student na UCLA od r. 1972 docent na Stanfordu poádá síové semináe (úastní se nap. Robert Metcalfe, Jack Haverty a další) na tchto semináích se pod vedením Vintona Cerfa a Roberta Kahna postupn zrodily protokoly TCP/IP pozdji se stal šéfem Internet Society pracoval také (jako senior vicepresident) v MCI a Worldcom-u dnes je šéfem organizace ICANN chairman ( 1973: pedstava TCP/IP poprvé prezentována veejnosti (konference v UK) 197: koncepce TCP/IP publikována v IEEE Transactions on Computers (Cerf, Kahn) 1977: první praktické zkoušky 1978-9: 9: TCP/IP získává dnešní podobu 1980: DoD akceptuje protokoly TCP jako perspektivní 1982: DoD pikazuje použití TCP/IP u všech sítí, nov pipojovaných k Internetu 1.1.1983: celý Internet pechází na protokoly TCP/IP ) smrování protokolu NCP bylo ukoneno/zastaveno 1983-1986: 1986: nástup protokol TCP/IP do praxe DoD (ARPA) nechává implementovat protokoly TCP/IP u komerní firmy BBN (Bolt( Bolt,, Beranek& Newman) DoD (ARPA) financuje zalenní TCP/IP do BSD Unixu, který je distribuován (zdarma) americkým univerzitám Berkeley Software Distribution protokoly TCP/IP jsou postupn implementovány i v dalších operaních systémech pibližn ve stejné dob vzniká i RM ISO/OSI Filosofie, uplatnná pi vzniku TCP/IP draz na internetworking co bylo požadováno ješt po pvodním ARPANETu: nesmí to mít žádnou centrální ást tu by nepítel zniil jako první dsledek: bude to mít decentralizovaný charakter, dnes naplnno existencí provider a autonomním charakterem jejich sítí musí to být velmi robustní tak aby to aspo njak fungovalo, když nepítel ást sít odstelí dsledek: preferují se nespolehlivé a nespojované penosové mechanismy protokol IP funguje nespolehliv a nespojovan co bylo požadováno po "rutinních" protokolech (TCP/IP): internetworking co nebylo požadováno ani po TCP/IP: zabezpeení nebyl požadavek na zajištní dvrnosti dat jen velmi malé požadavky na identifikaci a autentizaci uživatel mobilita v dob vzniku byly poítae "nepenosné" (rzná) kvalita služeb aby rzné penosy mohly mít rznou prioritu, rzné parametry penosu atd.. pro byl položen draz na internetworking? internetworking = vzájemné propojování sítí když TCP/IP vznikalo, ARPANET už existoval, a byl velký zájem o pipojení k nmu o pipojení k ARPANETu usilovaly sít rzného typu (s rznými síovými technologiemi) ARPANET ARPANET TCP/IP je ešeno tak, aby: šlo snadno pipojovat díve samostatné sít bylo možné propojit i sít fungující na rzných (odlišných) linkových technologiích postupným pipojováním dalších sítí k zárodenému ARPANETu vzniká vlastní Internet ješt pozdji (1. polovina 90. let) se Internet otevírá komernímu svtu * % %% vrstva vrstva síového rozhraní rzné sít sít a penosové technologie vrstvy TCP/IP jednotné (základy) aplikací (email, penos soubor, remote login ) ) jednotné transportní protokoly (TCP a UDP) jednotný penosový protokol (IP) (IP) TCP/IP definuje TCP/IP nedefinuje zahrnuje vše pod síovou vrstvou TCP/IP tuto vrstvu samo nijak nenapluje tj. nespecifikuje svoje vlastní penosové technologie na nejnižších vrstvách % vrstva vrstva síového rozhraní Vrstva síového rozhraní (Network Interface Layer) pro? pedpokládá, že zde se použije to, co vznikne nkde jinde (mimo rámec TCP/IP), napíklad: Ethernet Token Ring ATM nepovažuje za potebné znovu vyvíjet ešení, která již existují a fungují by je vyvinul "nkdo jiný" TCP/IP se zabývá pouze tím, jak tyto již existující technologie co nejlépe využít jak nad nimi provozovat protokol IP výjimka: protokoly SLIP a PPP (pro 2-bodové spoje) pro srovnání: : RM ISO/OSI považuje za potebné pevzít "cizí" ešení a pijmout je jako vlastní standardy verze 3.0, ást : Rodina protokol TCP/IP Jií Peterka, MFF UK, 200 2
Filosofie TCP/IP Dilema pokliky penosové technologie (z vrstvy síového rozhraní) mají svá specifika rzné zpsoby adresování, rznou velikost penášených rámc, rzných charakter poskytovaných služeb všechny tyto penosové technologie "zastešuje" vytváí nad nimi "pokliku" IP IP "pokliku" tvoí protokol IP hlavní penosový protokol síové vrstvy v TCP/IP otázka: jak má tato poklika vypadat? jaký má být protokol IP? Autoi TCP/IP se museli rozhodnout, zda: vytvoí jednotnou nadstavbu nad soustavou vzájemn propojených sítí penosový protokol na úrovni síové vrstvy (IP protokol), který bude mít všude stejné vlastnosti a poskytovat stejné služby stejné adresování. ne ano vyšší vrstvy mohou být jednotné, nemusí se zabývat odlišnostmi nebo zda nadstavba nebude všude stejná tj. protokol IP bude mít v rzných sítích rzné vlastnosti, resp. nabízet rzné služby. ne ano umožuje to dosahovat maximální možné efektivnosti, pizpsobením se specifickým vlastnostem penosových mechanism % % dilema pokliky další otázky výsledek zvolená koncepce jak by mla vypadat "jednotná výchozí pedpoklady/úvahy: poklika" nad penosovými protokoly nižších vrstev? penosová ást by mla hlavn penášet data z hlediska adresování (charakteru a a ne se starat o další vci logiky používaných adres)? je výhodnjší, když inteligence bude z hlediska soustedna až do koncových uzl spojovaného/nespojovaného a nikoli do penosové ásti sít zpsobu fungování? ešení by mlo být decentralizované a z hlediska maximáln robustní spolehlivého/nespolehlivého zpsobu fungování ešení by mlo maximáln podporovat internetworking z hlediska garance kvality služeb?.. %& autoi TCP/IP se rozhodli pro "jednotnou pokliku", která zastírá á konkrétní specifika jednotlivých IP sítí fakticky jde o jednotnou nadstavbu, kterou tvoí: penosový protokol IP, který má všude stejné vlastnosti a všude poskytuje stejné služby je nespojovaný, nespolehlivý, funguje na principu maximální snahy jednotné adresování virtuální 32-bitové adresy (nemají žádný reálný vzor), tzv. IP adresy tyto adresy by mly vyhovovat "pohledu na svt", který má TCP/IP že svt je tvoen dílími sítmi a hostitelskými poítai (a smrovai) IP adresy mají "síovou ást", identifikující sí jako celek, a dále "uzlovou ást", identifikující uzel v rámci sít pevodní mechanismy, které pekládají mezi fyzickými (linkovými) adresami a virtuálními IP adresami protokoly ARP, RARP,. existuje ale jedna výjimka: IP protokol i vyšší vrstvy "vidí" maximální velikost linkového rámce r (skrz parametr MTU, Maximum Transfer Unit) a mli by jej respektovat tak aby nedocházelo ke zbytené fragmentaci pi penosech %' Pedstava pokliky Dnešní stav: IP over Everything protokol IP (protokol síové vrstvy) dokáže fungovat "nad ímkoli" jednotné prostedí transportní protokol MTU smrova poklika transportní protokol nad jakýmkoli penosovým mechanismem, který dokáže (fyzicky) penášet data protokolm vyšších vrstev vytváí jednotné prostedí pro jejich fungování místní smyka (dial-up, ISDN, ADSL) GSM (GPRS, HSCDS) bezdrátové technologie pronajaté okruhy IP IP satelitní penosy optická vlákna IP over Lambda rozvody 230 V ATM + další rozvody kabelové TV %( %) verze 3.0, ást : Rodina protokol TCP/IP Jií Peterka, MFF UK, 200 3
IP adresy Katenetový model problém: penosové technologie nižších vrstev používají znan rznorodé adresy %* nap. Ethernet používá 8- bitové adresy, ARCnet 8- bitové atd. protokol IP nepejímá žádnou a koncepcí adresování na úrovni nižších vrstev. protokol IP zavádí vlastní (ryze abstraktní) adresy v rozsahu 32 bit tzv. IP adresy nemají bezprostední vzor v žádném systému adresování na nižší úrovni IP adresy jsou logicky dvousložkové obsahují síovou ást adresu dílí sít a relativní ást relativní adresu uzlu v rámci sít dvousložkový charakter vychází z pedstavy tzv. katenetového modelu smrování probíhá primárn podle síové ásti adresy a teprve v rámci cílové sít podle (relativní) adresy uzlu 31 adresa sít síová ást adresa uzlu 0 TCP/IP pedpokládá že "svt" je tvoen soustavou dílích sítí chápaných jako celky na úrovni síové vrstvy, tzv. IP sítí dílí sít jsou vzájemn propojeny na úrovni síové vrstvy pomocí smrova (díve nazývaných IP Gateways,, dnes: IP Routers) toto propojení mže být libovolné mže být stylem "každý s každým", nebo "do etzce" apod. "katenet" je je "etzec" ten ten je je podmínkou pro pro souvislost celé celé soustavy sítí sítí pedstava katenetu skutená sí = IP sí = IP smrova (router] Hostitelské é poítae vs. smrovae pvodní "hospodaení" s IP adresami TCP/IP pedpokládá, dva typy uzl v síti: IP sí IP sí hostitelské poítae (host( computers) tj. koncové uzly, nap. servery, pracovní stanice, PC, rzná zaízení (tiskárny, ) jsou pipojeny jen do jedné IP sít (mají jen jednu síovou adresu) IP sí smrovae (IP Routers) jsou pipojeny nejmén do dvou IP sítí zajišují "pestup" (smrování) = smrova teze: každý uzel by ml mít piazenu + + + =hostitelské celosvtov unikátní síovou adresu poítae tzv. IP adresu (hosts) pesnji: : každé rozhraní by mlo mít vlastní adresu = multihomed host smrova má nejmén 2 IP adresy (podle potu svých rozhraní) IP sí IP sí % autoi TCP/IP vyšli z pedpokladu že bude existovat: malý poet opravdu velkých sítí vyžadují malou síovou ást, a naopak velkou ást pro relativní adresu uzlu stední poet stedn velkých sítí mly by mít srovnateln velkou síovou i relativní ást velký poet malých sítí vyžadují velkou síovou ást, staí jim malá ást pro relativní adresy tomu uzpsobili i velikost síové ásti IP adresy 3 možné varianty, které odpovídají 3 tídám adres tída A pro velmi velké sít, poloha hranice 8:2 (rozdluje 32bit na 8 a 2) tída B pro stedn velké sít, 16:16 tída C pro malé sít, 2:8 (pvodní) zpsob pidlování IP adres: vždy se pidlila celá tída adres nap: : 1x B: fakticky 65536 (2 16 ) rzných IP adres (se stejnou síovou ástí) nap. 1x C: fakticky 256 (2 8 ) rzných IP adres pokud takto pidlené adresy nebyly využity, nešlo je už "vzít zpt" a pidlit nkomu jinému dsledek: vedlo to k plýtvání IP adresami píklad: když nkdo chtl 1000 IP adres, dostal 1xB (65 536 adres) pozdji: dostal -8x C (-8x256 IP adres, ale to zase zpsobovalo jiné problémy se smrovacími tabulkami Problém s IP adresami IP adresy distribuce a zápis pvodn navržený systém tíd A, B a C nepoítal s dnešní velkou poptávkou po IP adresách docházelo k plýtvání IP adresami nejmenší "kvantum" je 256 IP adres (1x tída C) a ke znané roztíštnosti pidlených IP adres komplikace pi smrování a udržování smrovacích tabulek zaalo hrozit nebezpeí vyerpání všech IP adres adresa sít adresa uzlu tzv. CIDR prefix (íká, kolik bit tvoí síovou ást) objevila se doasná ešení, která zmírují problém subnetting umožuje "dále dlit" již jednou pidlené tídy IP adres CIDR (Classless Inter-Domain Routing) umožuje pidlovat IP adresy po libovoln velkých kvantech (2 n ) privátní IP adresy umožují opakované použití stejných IP adres napíklad v privátní síti schované za firewallem vzniklo i definitivní ešení celého problému: nová verze protokolu IP IP verze 6, s IP adresami velikosti 128 bit jedna z velmi mála zásadnjších zmn v TCP/IP IP adresy jsou 32-bitové pvodn: lze je chápat jako jedno velké (32- bitové) binární íslo IP adresy se koncovým uživatelm pidlovaly centráln ale to se špatn zapisuje i te bez ohledu na zpsob jejich pipojení používá se jednotný zpsob zápisu: dnes: obsah každého bytu je vyjáden jako IP adresy pidluje svým zákazníkm provider desítkové íslo IP adresy jsou závislé na zpsobu pipojení, pi zmn jednotlivé ásti jsou spojeny tekou providera se musí mnit píklad: 193.8.57.3 píklad: 17.3.1.3 pidlování regionální ICANN velkých blok "pidlovatelé" IP adres C0 H A8 H 0 H 2 H 192 168 0 2 192.168.0.2 pidlování menších blok ARIN pidlování IP adres koncovým uživatelm provider RIPE provider APNIC verze 3.0, ást : Rodina protokol TCP/IP Jií Peterka, MFF UK, 200
& Filosofie TCP/IP spolehlivost, nebo nespolehlivost? spolehlivá penosová služba nespolehlivá penosová služba když zjistí že njaká data jsou poškozena/ztracena, považuje za svou sama z vlastní iniciativy nezpsobuje žádná poškození/ztráty dat povinnost postarat se o nápravu vyvíjí maximální snahu o korektní typicky: vyžádá si nový penos již penos jednou penesených dat, v oekávání že opakovaný penos již dopadne dobe jakmile ale zjistí, že došlo k njaké chyb/poškození/ztrát, nepovažuje za se zajištním spolehlivosti je spojena svou povinnost postarat se o nápravu uritá režie pedpokládá, že pokud bude náprava penosová režie: spotebovává se další penosová kapacita zapotebí, postará se o ni nkdo jiný vyšší vrstvy asová režie: njakou dobu to trvá, má právo zahodit poškozená data zpsobuje to zpoždní v penosu, (ignorovat ztrátu) a pokraovat dál nerovnomrnosti v doruování není s tím spojena žádná režie výpoetní režie: uzly musí mít je to rychlé, efektivní dostatenou inteligenci na zajištní všeho potebného ' Filosofie TCP/IP protokol IP otázka: ešení v rámci TCP/IP: má IP fungovat spolehliv, nebo nespolehliv? penosová ást (síová výchozí úvaha: vrstva, protokol IP) funguje penosová ást by mla hlavn penášet data pouze nespolehliv a ne se starat o další vci mechanismy zajišující je výhodnjší, když si spolehlivost zajistí až koncové uzly a nikoli penosová ást sít spolehlivost jsou implementovány až v transportní vrstv pro? ale jako volitelná možnost (tj. nkdo (nkteré ) nemusí spolehlivost není povinnost je využívat) potebovat, a dá pednost rychlému a pravidelnému penosu protože k zajištní spolehlivosti je teba výpoetní kapacita, a ta je lacinjší v koncových uzlech než uvnit sít si mohou vybrat, zda chtjí spolehlivý i nespolehlivý penos spolehlivost je vždy relativní (nikoli 100%), nkomu by nemusela postaovat míra protokol IP IP je je zabudované spolehlivosti a musel by si ji nespolehlivý zajišovat sám a znovu a a to by bylo neefektivní, protože režie spojená se nespojovaný zajištním spolehlivosti na každé vrstv by se sítala, i dokonce násobila Filosofie TCP/IP Jiný pohled na spolehlivost eší komunikaci koncových úastník (end( end-to-end communication) sama využívá nespojovaný a nespolehlivý penos na úrovni síové vrstvy sama alternativn nabízí: spojovaný a spolehlivý penos nespojovaný protokol UDP a (User nespolehlivý Datagram penos síové si mohou vrstvy vybrat dle vlastního protokol uvážení TCP (Transmission ( TCP Datagram Protocol) zajišuje nespojovaný a nespolehlivý penos je jen lehkou nadstavbou nad síovou vrstvou, nemní povahu penosových p služeb Transmission Control Protocol): zajišuje spolehlivý a spojovaný penos tváí se jako proud (stream( stream), který penáší jednotlivé byty TCP IP UDP UDP vrstva SMTP FTP Telnet HTTP RPC rlogin DNS SNMP TFTP BOOTP DHCP RPC NFS XDR zpsob zajištní spolehlivosti je také o tom, kde v síti má být umístna "inteligence" výpoetní kapacita, logika implementující zajištní spolehlivosti pipomenutí: je ješt ve všech uzlech, transportní již jen v koncových uzlech ) ISO/OSI: inteligence má být v síti spolehlivost musí být ešena na úrovni síové vrstvy inteligence je ve smrovaích je to drahé a nepružné nedává to možnost výbru TCP/IP: inteligence má být v koncových uzlech spolehlivost je ešena až v transportní vrstv je to lacinjší, pružnjší smrova umožuje to, aby si vybíraly zda spolehlivost chtjí i nechtjí Hloupá sí vs. chytré uzly Princip maximální snahy jiná interpretace: penosová ást sít (IP sí) má být "hloupá" * ale efektivní, má co nejrychleji a nejefektivnji plnit své základní úkoly "chytré" mají být koncové uzly inteligence má být soustedna do koncových uzl IP sí inteligence rychlost inteligence anglicky"best effort" penosová ást sít se maximáln snaží vyhovt všem požadavkm, které jsou na ni kladeny pokud se jí to nedaí, má právo krátit požadavky (limitovat, ignorovat je, nevyhovt jim, ) nap. pozdržet penášené pakety do doby, než je bude moci zpracovat mže i zahazovat pakety, které vbec nedokáže zpracovat dlá to rovnomrn vi všem požadavkm "mí všem stejn", nepracuje s prioritami je to celková filosofie TCP/IP je praktickým dsledkem použití paketového penosu a pístupu ke spolehlivosti alternativa: garance služeb (QoS( QoS, Quality of Service) QoS nabízí telekomunikaní sít výhoda: sít fungující na principu "best" effort" jsou mnohem efektivnjší (i ekonomicky) než sít nabízející QoS kdyby Internet poskytoval QoS,, byl by mnohem dražší než dnes a mén rozvinutý nevýhoda: vadí to multimediálním penosm verze 3.0, ást : Rodina protokol TCP/IP Jií Peterka, MFF UK, 200 5
% Píina princip paketového penosu problém: kapacita pepojovacího uzl i "odchozích smr" je omezena. Pokud souet požadavk pekroí dostupnou kapacitu, má uzel právo zahazovat pakety které nedokáže zpracovat pakety pracuje pracuje na na principu store store & forward forward pepojovací uzel?? interní pam (vyrovnávací buffer) pepojovací logika (rozhoduje, (rozhoduje, kudy kudy bude bude dále dále odesláno) odesláno) Filosofie TCP/IP - spojovanost nebo nespojovanost? spojovaný zpsob penosu ped samotným penosem dat dojde k navázání spojení mezi píjemcem a odesilatelem vetn vytyení trasy spojení všechna data pak cestují stejnou trasou poadí penášených paket se nemní odesilatel má jistotu, že píjemce existuje a je ochoten pijímat data v pípad výpadku/zmny topologie musí být spojení detekována zmna, poté ukoneno existující spojení a navázáno nové pedstava spojovaného penosu 5 je to výhodné pro nárazové penosy vtších objem dat není to vhodné pi astjších zmnách v topologii i stavu sít kdy je nutné explicitn ošetovat tyto zmny jde o stavový zpsob fungování mní se stav komunikujících stran 3 2 1 spojení Filosofie TCP/IP - nespojovanost Filosofie TCP/IP - sdílení mechanism nespojovaný zpsob penosu je to výhodné tam, kde dochází k datové pakety (tzv. datagramy) ) jsou astjším zmnám v síti penášeny bez toho, že by se nebo je lze oekávat navazovalo jakékoli spojení s je to vhodnjší pro mén intenzivní píjemcem penosy více rozložené v ase kde se mohou více uplatnit zmny v odesilatel ani neví, zda píjemce síti existuje a je ochoten data pijmout každý paket (tzv. datagram) ) je protokol UDP UDPfunguje nespojovan, penášen samostatn, nezávisle na TCP TCPspojovan (emuluje spojovaný ostatních zpsob zpsob fungování) vždy se pokaždé znovu hledá jeho cesta k cíli 1 provádí se tzv. smrování, vždy znovu v každém uzlu kudy paket prochází 2 není zarueno poadí doruování 3 5 paket protokol IP IPfunguje nespojovan když se nkde musí implementovat njaké mechanismy, jak mají býtešeny? napíklad mechanismy pro vedení relací, konverze apod. RM ISO/OSI: : tak, aby je mli všichni k dispozici sdílen,, tj. jako samostatné vrstvy a režii tchto mechanism pak ponesou všichni (i ti, kdo je nepoužívají) TCP/IP: : tak, aby režii nenesli ti, kdo je nechtjí používat ne-sdílen sdílen,, tj. zabudovávají se pímo a pouze do tch aplikací, které je skuten s potebují režii nenese ten, kdo mechanismy nepotebuje dsledek: TCP/IP ISO/OSI ISO/OSI má samostatnou prezentaní a relaní vrstvu vychází z pedpokladu že prezentaní a relaní služby budou potebovat všechny v. pak mají samostatné vrstvy smyl TCP/IP nemá samostatné vrstvy vychází z pedpokladu, že prezentaní a relaní služby vrstva prezentaní v. budou potebovat jen nkteré pak nemá smysl dlat samostatné vrstvy relaní v., které tyto služby potebují, si je musí realizovat samy transportní v. transportní v. Výjimka: RPC a XDR Aplikace v TCP/IP protokol NFS používá ke svému fungování prezentaní a relaní služby protokol RPC (Remote( Procedure Call) ) pro relaní služby) protokol XDR (external( Data Representation) ) pro prezentaní služby tyto protokoly jsou implementovány jako vícenásobn využitelné jako samostatné moduly, jejichž služby mže využívat každá která chce a naopak nemusí ta, která nechce (a v tom pípad nenese jejich režii ) vrstva XDR RPC pvodn: elektronická pošta (SMTP, RFC 822) penos soubor (FTP) vzdálené pihlašování(telnet, rlogin) tmto aplikacím dobe vyhovovalo fungování sít "na principu maximální snahy, ale nezarueného výsledku" pozdji se objevily a prosadily nové : news sdílení soubor (NFS) Web (HTML, HTTP,.) on-line komunikace (IRC, chat,..) pro tyto princip "maximální snahy" není optimální, ale ješt postauje, dležitá je hlavn disponibilní penosová kapacita dnes se prosazují také "multimediálního" charakteru, nap.: VOIP (Voice( over IP) internetová telefonie, "hlas pes IP" VOD (Video on Demand) penos obrazu na vyžádání audio on demand "živé vysílání" TV a rozhlasu on-line hry.. pro tyto je princip "maximální snahy" velmi nevhodný, potebovaly by zajistit kvalitu služby (QoS( QoS) & ' verze 3.0, ást : Rodina protokol TCP/IP Jií Peterka, MFF UK, 200 6
Aplikace v TCP/IP Problém distribuních aplikací prakticky všechny v rámci TCP/IP jsou založeny na architektue client/server servery poskytující "veejné" služby jsou dostupné na tzv. dobe známých portech (well( well-known ports) penosové mechanismy TCP/IP jsou uzpsobeny komunikaci stylem 1:1 (mezi 1 serverem a 1 klientem) ( klient komunikace penos dat smrova server s postupem asu se objevily i takové, pro které je fungování penosových mechanism TCP/IP principiáln nevhodné "distribuní služby" = videokonference, vysílání rozhlasu a TV,. potebují dopravovat stejná data od 1 zdroje k více píjemcm souasn tzv. multicasting (event. broadcasting) penosové mechanismy TCP/IP to neumí penosové mechanismy poítají s penosem 1:1 (od jednoho zdroje k jednomu píjemci) pokus: služba MBONE (nepíliš úspšná) eší se až v rámci IPv6 a IP Multicast Initiative bez multicastingu s multicastingem ) Problém multimediálních aplikací QoS v TCP/IP možné pístupy potebují dostávat svá data: možná ešení: s malým zpoždním (latence) "kvantitativní": zvyšování disponibilní s pravidelným zpoždním (jitter( jitter) kapacity s pravidelnými odstupy mezi sebou fungování na principu "maximální snahy týká se to napíklad penosu živého obrazu " zstává i zvuku zlepšení je statistické je menší pravdpodobnost, že bude VOIP, TV vysílání, rozhlas, muset dojít ke krácení požadavk video-on on-demand týká se: problém je s fungováním penosových penosových kapacit (tj. linek) mechanism TCP/IP na principu "pepojovacích kapacit" (smrova( smrova, "maximální snahy, ale nezarueného switch) výsledku" "kvalitativní": zavedení podpory QoS byla by zapotebí podpora QoS (kvality fungování na principu "maximální snahy služeb) QoS je v zásad "protipólem" principu " je nahrazeno jiným zpsobem fungování maximální snahy zlepšení je garantované ale drahé a obtížné * prioritizace rezervace rzným druhm penos se piadí rzné priority a je s nimi nakládáno odlišn pro potebu konkrétních penos si lze vyhradit (rezervovat) požadované zdroje a ty pak využívat týká se i vyhrazení penosové kapacity, pepojovací kapacity atd. penosy s vyšší prioritou dostávají "kvalitnjší obsluhu" (a pídl zdroj) píklady ešení: na úkor penos s nižší prioritou RSVP (Resource( Reservation Protocol) píklady ešení: na nj navazuje transportní protokol RTP (Real( Real-Time Protocol) IntServ (Integrated Services) DiffServ (Differentiated Services) MPLS (MultiProtocol( Label Switching) podporu QoS lze poskytovat: "per flow": pro každý jednotlivý jednosmrný tok dat mezi dvma mi "per aggregate": pro celé skupiny tok Problém bezpenosti IPv6, mobilita Penosové mechanismy TCP/IP neposkytují žádné zabezpeení nebylo to "v pvodním zadání" penášená data nejsou žádným zpsobem chránna proti "odposlechu" nejsou šifrována ani jinak kódována i chránna nejsou ani chránna proti ztrát u nespolehlivých penos pedpoklad: pokud njaká potebuje uritou míru zabezpeení, musí si ji zajistit sama jde o stejný "kompromis" jako u spolehlivosti: buto poskytnout zabezpeení všem (i tm kteí jej nepotebují), nebo si jej bude muset každý zájemce udlat sám teze: penosové mechanismy by mly hlavn penášet data, ne se starat o další funkce dsledek: penosová infrastruktura je jednodušší, rychlejší a také lacinjší oproti stavu, kdy by fungovala zabezpeeným zpsobem praxe: zabezpeení se eší na úrovni IPSEC: framework (rámec) pro zajištní bezpenosti na úrovni síové vrstvy IPv6 eší problém nedostatku IP adres pracuje se 128-bitovými adresami podporuje adu dalších vlastností/funkcí nap. QoS zabezpeení autokonfigurace smrování (source( routing,, ) místo broadcastu má unicast mobilita IP adresy nejsou "mobilní" nelze je penášet mezi sítmi ešení mobility: pidlení nové IP adresy v nové síti DHCP atd. skrze agenty a tunely "na pvodním míst" zstane agent, který vše peposílá "skrze tunel" tam, kde se uzel práv nachází je vbec mobilita zapotebí? % verze 3.0, ást : Rodina protokol TCP/IP Jií Peterka, MFF UK, 200 7
Filosofie "vývoje" TCP/IP Standardizace TCP/IP schopnosti služeb a penosových protokol TCP/IP se vyvíjí stylem m "od jednoduššího ke složitjšímu" postupným zdokonalováním zaíná se s minimem funkcí, teprve postupn se pidávají další schopnosti s a vlastnosti, pokud se ukáže jejich poteba a realizovatelnost tomu je pizpsoben i standardizaní proces než se nco stane standardem, musí to prokázat reálnou implementovatelnost alespo 2 nezávislé implementace funkceschopnost musí existovat provozní zkušenosti s pilotním nasazením píklad: elektronická pošta vznikla jako jednoduchá služba pro penos ist textových zpráv postupn byla obohacena o další možnosti (pílohy, formátování, národní abecedy atd. standard MIME) standardy TCP/IP jsou skuten otevené i když nikdo poádn neví, co to pesn znamená nejsou v rukou jediné firmy vznikají (jsou pijímány) na základ všeobecného konsensu specifikace tchto protokol jsou veejným vlastnictvím za jejich využití se neplatí žádné licenní poplatky texty specifikací mají povahu voln šiitelných dokument (dokument RFC) technická ešení, která jsou pedmtem standard, vznikala pvodn v rámci sdružení IETF (Internet Engineering Task Force) dosti volné spoleenství odborník, zainteresovaných na vývoji TCP/IP dnes tato ešení vznikají u komerních firem, které je pedkládají ke standardizaci snaží se je prosadit jako internetový standard Standardizaní orgány pod ISOC Shrnutí standardizaního procesu & IRSG IRTF IAB vdecko-výzkumné skupiny IESG IETF oblast oblast pracovní skupiny ISOC: (http:// ://www.isoc.org) zastešuje, reprezentuje vi jiným organizacím a orgánm IAB: (http://www.iab.org www.iab.org) ídí standardizaní práci, pijímá strategická rozhodnutí, formáln vydává dokumenty RFC IESG,IRSG: "Steering Groups", ídí práci IETF a IRTF, které mají velmi "volnou organizaci" "vnáší ád do chaosu" (kompenzují to, že samotné IETF a IRTF nemají žádné ádné formální lenství.) standardy vydává ISOC výjimkou jsou standardy týkající se WEBu formáln IAB nap.. k HTML, XML, CSS, PICS, PNG ISOC nemá statut standardizaní ty vydává konsorcium W3C jako svá organizace doporuení candidate recommendation její standardy nemají statut standard proposed recommendation de jure recommendation jde o standardy de facto je dohoda o tom, že relevantní doporuení W3C budou publikovány též jako pesto jsou v praxi velmi dsledn dokumenty RFC dodržovány standardy týkající se TCP/IP jsou publikovány formou dokument RFC (STD) ' http://www.isoc.org http://www.w3c.org Srovnání TCP/IP a RM ISO/OSI ISO/OSI a jeho souásti vznikají stylem od složitého k jednoduššímu nejprve se požaduje hodn, a pak se musí ubírat vznikají problémy s kompatibilitou podmnožin k pijetí standardu není nutné ovení praktické realizovatelnosti standardy ISO jsou prodávány a jsou opravdu hodn drahé uplatuje se strategie: chci abys dodržoval moje standardy, a musíš mi nejprve hodn zaplatit, abych ti vbec ekl v em spoívají výsledek tomu odpovídá TCP/IP vzniká stylem od jednoduchého ke složitjšímu nejprve se pijme jednodušší ešení, pak se ev.. pidává existuje záruka kompatibility alespo na úrovni spoleného minima pro pijetí standardu je nutné ovení praktické realizovatelnosti dokonce i praktické provozní zkušenosti standardy TCP/IP (i související dokumenty) jsou dostupné voln a zdarma uplatuje se strategie: když chci nco prosadit, musím k tomu maximáln usnadnit pístup tato strategie funguje ( verze 3.0, ást : Rodina protokol TCP/IP Jií Peterka, MFF UK, 200 8