Poítaové sít, v. 3.0 Katedra softwarového inženýrství, Matematicko-fyzikální fakulta, Univerzita Karlova, Praha Lekce : Rodina protokol TCP/IP Jií Peterka, 200 "#$%
Srovnání RM ISO/OSI 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 aplikaní transportní síová vrstva síového rozhraní RM ISO/OSI aplikaní prezentaní relaní transportní síová linková fyzická
Co je TCP/IP? síová architektura: obsahuje ucelenou pedstavu o potu a úloze vrstev obsahuje i konkrétní protokoly obvyklé oznaení: TCP/IP protocol suite (rodina protokol TCP/IP) souástí je více jak 100 protokol postup vzniku: nejprve: protokoly teprve potom: vrstvy TCP/IP vzniklo v akademickém prostedí prosadilo se i v komerním prostedí od svého vzniku se zmnilo jen relativn málo nikoli zásadn zmny jsou aditivní dnes: nejpoužívanjší síová technologie nejrozšíenjší síová architektura prosadila se lépe než cokoli jiného (RM ISO/OSI, IPX/SPX atd.) funguje nad vším IP over Everything protokoly TCP/IP dokáží fungovat nad každou (linkovou) penosovu technologií všechno funguje nad IP Everything over IP snad všechny aplikace již byly implementovány (portovány( portovány) ) i nad protokoly TCP/IP a dokáží nad nimi fungovat neznamená to že TCP/IP je ideální má také adu nevýhod, nedostatk "#$
V em se liší TCP/IP a ISO/OSI? 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. 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í aplikace právo si vybrat nap. mezi spolehlivým a nespolehlivým penosem? TCP/IP aplikaní vrstva transportní v. síová vrstva (IP vrstva) vrstva síového rozhraní ISO/OSI aplikaní v. prezentaní v. relaní v. transportní v. síová v. linková v. fyzická v. "#$&
Historie vzniku TCP/IP 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í "#$'
Lidé kolem 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 "#$(
Historie vzniku TCP/IP 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 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. "#$*
draz na internetworking 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 "#$%
vrstvy TCP/IP aplikaní vrstva transportní vrstva síová vrstva vrstva síového rozhraní jednotné (základy) aplikací (email, penos soubor, remote login login ) ) jednotné transportní protokoly (TCP a UDP) jednotný penosový protokol (IP) (IP) TCP/IP definuje TCP/IP nedefinuje "#$%% rzné sít sít a penosové technologie
Vrstva síového rozhraní (Network Interface Layer) aplikaní vrstva transportní vrstva síová vrstva vrstva síového rozhraní 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 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
Filosofie TCP/IP síová vrstva 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 síová vrstva všechny tyto penosové technologie "zastešuje" vytváí nad nimi "pokliku" "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? IP IP "#$%
Dilema pokliky 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í. ano ne 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 jak by mla vypadat "jednotná poklika" nad penosovými protokoly nižších vrstev? z hlediska adresování (charakteru a logiky používaných adres)? z hlediska spojovaného/nespojovaného zpsobu fungování? z hlediska spolehlivého/nespolehlivého zpsobu fungování z hlediska garance kvality služeb? výchozí pedpoklady/úvahy: penosová ást by mla hlavn penášet data a ne se starat o další vci je výhodnjší, když inteligence bude soustedna až do koncových uzl a nikoli do penosové ásti sít ešení by mlo být decentralizované a maximáln robustní ešení by mlo maximáln podporovat internetworking.. "#$%&
výsledek zvolená koncepce 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 aplikace aplikace aplikace aplikace jednotné prostedí transportní protokol transportní protokol transport. vrstva MTU poklika transport. vrstva síová vrstva síová vrstva síová vrstva vrstva sí. rozhraní koncový uzel vrstva sí. rozhraní smrova vrstva sí. rozhraní koncový uzel "#$%(
Dnešní stav: IP over Everything protokol IP (protokol síové vrstvy) dokáže fungovat "nad ímkoli" nad jakýmkoli penosovým mechanismem, který dokáže (fyzicky) penášet data protokolm vyšších vrstev vytváí jednotné prostedí pro jejich fungování IP IP místní smyka (dial-up, ISDN, ADSL) pronajaté okruhy optická vlákna IP over Lambda + další GSM (GPRS, HSCDS) rozvody 230 V rozvody kabelové TV bezdrátové technologie satelitní penosy ATM "#$%)
IP adresy 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 31 smrování probíhá primárn podle síové ásti adresy a teprve v rámci cílové sít podle (relativní) adresy uzlu adresa sít adresa uzlu síová ást 0
Katenetový model 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 TCP/IP pedpokládá, dva typy uzl v síti: teze: 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) smrovae (IP Routers) jsou pipojeny nejmén do dvou IP sítí zajišují "pestup" (smrování) každý uzel by ml mít piazenu celosvtov unikátní síovou adresu tzv. IP adresu tzv. pesnji: : každé rozhraní by mlo mít vlastní adresu smrova má nejmén 2 IP adresy (podle potu svých rozhraní) IP sí = smrova + + + =hostitelské poítae (hosts) IP sí IP sí IP sí = multihomed host IP sí "#$%
pvodní "hospodaení" s IP adresami 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 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 distribuce a zápis IP adresy jsou 32-bitové lze je chápat jako jedno velké (32- bitové) binární íslo ale to se špatn zapisuje i te používá se jednotný zpsob zápisu: dnes: obsah každého bytu je vyjáden jako desítkové íslo jednotlivé ásti jsou spojeny tekou píklad: 193.8.57.3 píklad: 17.3.1.3 pvodn: IP adresy se koncovým uživatelm pidlovaly centráln bez ohledu na zpsob jejich pipojení IP adresy pidluje svým zákazníkm provider IP adresy jsou závislé na zpsobu pipojení, pi zmn providera se musí mnit regionální "pidlovatelé" ICANN pidlování velkých blok IP adres C0 H A8 H 0 H 2 H ARIN RIPE APNIC 192 168 0 2 pidlování menších blok provider provider "#$ 192.168.0.2 pidlování IP adres koncovým uživatelm
Filosofie TCP/IP spolehlivost, nebo nespolehlivost? spolehlivá penosová služba když zjistí že njaká data jsou poškozena/ztracena, považuje za svou povinnost postarat se o nápravu typicky: vyžádá si nový penos již jednou penesených dat, v oekávání že opakovaný penos již dopadne dobe se zajištním spolehlivosti je spojena uritá režie penosová režie: spotebovává se další penosová kapacita asová režie: njakou dobu to trvá, zpsobuje to zpoždní v penosu, nerovnomrnosti v doruování výpoetní režie: uzly musí mít dostatenou inteligenci na zajištní všeho potebného nespolehlivá penosová služba sama z vlastní iniciativy nezpsobuje žádná poškození/ztráty dat vyvíjí maximální snahu o korektní penos jakmile ale zjistí, že došlo k njaké chyb/poškození/ztrát, nepovažuje za svou povinnost postarat se o nápravu pedpokládá, že pokud bude náprava zapotebí, postará se o ni nkdo jiný vyšší vrstvy má právo zahodit poškozená data (ignorovat ztrátu) a pokraovat dál není s tím spojena žádná režie je to rychlé, efektivní "#$&
Filosofie TCP/IP protokol IP otázka: "#$' má IP fungovat spolehliv, nebo nespolehliv? výchozí úvaha: penosová ást by mla hlavn penášet data a ne se starat o další vci je výhodnjší, když si spolehlivost zajistí až koncové uzly a nikoli penosová ást sít pro? nkdo (nkteré aplikace) nemusí spolehlivost 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 spolehlivost je vždy relativní (nikoli 100%), nkomu by nemusela postaovat míra zabudované spolehlivosti a musel by si ji zajišovat sám a znovu a to by bylo neefektivní, protože režie spojená se zajištním spolehlivosti na každé vrstv by se sítala, i dokonce násobila ešení v rámci TCP/IP: penosová ást (síová vrstva, protokol IP) funguje pouze nespolehliv mechanismy zajišující spolehlivost jsou implementovány až v transportní vrstv ale jako volitelná možnost (tj. není povinnost je využívat) aplikace si mohou vybrat, zda chtjí spolehlivý i nespolehlivý penos protokol IP IP je je nespolehlivý a nespojovaný
Filosofie TCP/IP transportní vrstva 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 Datagram Protocol) zajišuje nespojovaný a nespolehlivý penos je jen lehkou nadstavbou nad síovou vrstvou, nemní povahu penosových p služeb aplikace síové si mohou vrstvy vybrat dle vlastního protokol uvážení TCP (Transmission Transmission Control Protocol): zajišuje spolehlivý a spojovaný penos tváí se jako proud (stream( stream), který penáší jednotlivé byty aplikace aplikace aplikace aplikace transportní vrstva síová vrstva TCP IP UDP transportní vrstva aplikaní vrstva "#$( SMTP FTP Telnet HTTP RPC rlogin DNS SNMP TFTP BOOTP DHCP RPC NFS XDR TCP UDP
Jiný pohled na spolehlivost 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í: síová vrstva je ješt ve všech uzlech, transportní již jen v koncových uzlech ISO/OSI: inteligence má být v síti TCP/IP: 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 inteligence má být v koncových uzlech spolehlivost je ešena až v transportní vrstv je to lacinjší, pružnjší umožuje to, aby si aplikace vybíraly zda spolehlivost chtjí i nechtjí "#$) transport. vrstva síová vrstva vrstva sí. rozhraní koncový uzel síová vrstva vrstva sí. rozhraní smrova transport. vrstva síová vrstva vrstva sí. rozhraní koncový uzel
Hloupá sí vs. chytré uzly 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 "#$*
Princip maximální snahy 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) výhoda: QoS nabízí telekomunikaní sít sít fungující na principu "best" effort" jsou mnohem efektivnjší (i ekonomicky) než sít nabízející QoS nevýhoda: kdyby Internet poskytoval QoS,, byl by mnohem dražší než dnes a mén rozvinutý vadí to multimediálním penosm "#$
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 pepojovací uzel?? pepojovací logika (rozhoduje, (rozhoduje, kudy kudy bude bude dále dále odesláno) odesláno) pakety "#$% pracuje pracuje na na principu principu store store & forward forward interní pam (vyrovnávací buffer)
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 nespojovaný zpsob penosu datové pakety (tzv. datagramy) ) jsou penášeny bez toho, že by se navazovalo jakékoli spojení s píjemcem odesilatel ani neví, zda píjemce existuje a je ochoten data pijmout každý paket (tzv. datagram) ) je penášen samostatn, nezávisle na ostatních vždy se pokaždé znovu hledá jeho cesta k cíli provádí se tzv. smrování, vždy znovu v každém uzlu kudy paket prochází 2 3 není zarueno poadí doruování paket je to výhodné tam, kde dochází k astjším zmnám v síti nebo je lze oekávat je to vhodnjší pro mén intenzivní penosy více rozložené v ase kde se mohou více uplatnit zmny v síti protokol UDP UDPfunguje nespojovan, TCP TCPspojovan (emuluje spojovaný zpsob zpsob fungování) 1 5 "#$ protokol IP IPfunguje nespojovan
Filosofie TCP/IP - sdílení mechanism 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í dsledek: režii nenese ten, kdo mechanismy nepotebuje ISO/OSI má samostatnou prezentaní a relaní vrstvu vychází z pedpokladu že prezentaní a relaní služby budou potebovat všechny aplikace pak mají samostatné vrstvy smyl TCP/IP nemá samostatné vrstvy vychází z pedpokladu, že prezentaní a relaní služby budou potebovat jen nkteré aplikace pak nemá smysl dlat samostatné vrstvy aplikace, které tyto služby potebují, si je musí realizovat samy TCP/IP aplikaní vrstva realizovat samy transportní v. ISO/OSI aplikaní v. prezentaní v. relaní v. transportní v.
Výjimka: RPC a XDR aplikaní 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á aplikace která chce a naopak nemusí ta aplikace, která nechce (a v tom pípad nenese jejich režii ) aplikace aplikace aplikaní vrstva XDR RPC transportní vrstva aplikace "#$&
Aplikace v TCP/IP 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é aplikace: news sdílení soubor (NFS) Web (HTML, HTTP,.) on-line komunikace (IRC, chat,..) pro tyto aplikace princip "maximální snahy" není optimální, ale ješt postauje, dležitá je hlavn disponibilní penosová kapacita dnes se prosazují také aplikace "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 aplikace je princip "maximální snahy" velmi nevhodný, potebovaly by zajistit kvalitu služby (QoS( QoS) "#$'
Aplikace v TCP/IP prakticky všechny aplikace 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 transport. vrstva síová vrstva vrstva sí. rozhraní koncový uzel komunikace penos dat síová vrstva vrstva sí. rozhraní smrova server transport. vrstva síová vrstva vrstva sí. rozhraní koncový uzel
Problém distribuních aplikací s postupem asu se objevily i takové aplikace, 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í potebují dostávat svá data: s malým zpoždním (latence) s pravidelným zpoždním (jitter( jitter) s pravidelnými odstupy mezi sebou týká se to napíklad penosu živého obrazu i zvuku aplikace VOIP, TV vysílání, rozhlas, video-on on-demand problém je s fungováním penosových mechanism TCP/IP na principu "maximální snahy, ale nezarueného výsledku" byla by zapotebí podpora QoS (kvality služeb) QoS je v zásad "protipólem" principu maximální snahy možná ešení: "kvantitativní": zvyšování disponibilní kapacity fungování na principu "maximální snahy " zstává zlepšení je statistické je menší pravdpodobnost, že bude muset dojít ke krácení požadavk týká se: penosových kapacit (tj. linek) "pepojovacích kapacit" (smrova( smrova, switch) "kvalitativní": zavedení podpory QoS fungování na principu "maximální snahy " je nahrazeno jiným zpsobem fungování zlepšení je garantované ale drahé a obtížné "#$*
QoS v TCP/IP možné pístupy prioritizace rzným druhm penos se piadí rzné priority a je s nimi nakládáno odlišn penosy s vyšší prioritou dostávají "kvalitnjší obsluhu" (a pídl zdroj) na úkor penos s nižší prioritou píklady ešení: IntServ (Integrated Services) DiffServ (Differentiated Services) MPLS (MultiProtocol( Label Switching) rezervace 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. píklady ešení: RSVP (Resource( Reservation Protocol) na nj navazuje transportní protokol RTP (Real( Real-Time Protocol) podporu QoS lze poskytovat: "per flow": pro každý jednotlivý jednosmrný tok dat mezi dvma aplikacemi "per aggregate": pro celé skupiny tok "#$
Problém bezpenosti 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 pedpoklad: u nespolehlivých penos pokud njaká aplikace 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 aplikaní úrovni IPSEC: framework (rámec) pro zajištní bezpenosti na úrovni síové vrstvy "#$%
IPv6, mobilita 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í? "#$
Filosofie "vývoje" 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) "#$
Standardizace TCP/IP 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 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í.) "#$&
Shrnutí standardizaního procesu http://www.isoc.org http://www.w3c.org standardy vydává ISOC "#$' formáln IAB ISOC nemá statut standardizaní organizace její standardy nemají statut standard de jure jde o standardy de facto jde o standardy pesto jsou v praxi velmi dsledn dodržovány standardy týkající se TCP/IP jsou publikovány formou dokument RFC (STD) výjimkou jsou standardy týkající se WEBu nap.. k HTML, XML, CSS, PICS, PNG ty vydává konsorcium W3C jako svá doporuení candidate recommendation proposed recommendation recommendation je dohoda o tom, že relevantní doporuení W3C budou publikovány též jako dokumenty RFC
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 "#$(