PKO-vypisky ke zkousce - Router\nPKO – výpisky ke zkoušce\nPodívat se na Xfort, jsou tam nějaké odkazy na to z čeho se učit:\nPřednáška 1 – úvod\nHistorie síťových technologií:\n1. nejdříve se přenášela data na médiích (štítky, pásky, diskety...)\n2. potom se “vynalezly” sériové a paralelní porty (dvoubodové spoje – viz PZA)\n3. poté nastoupily terminálové sítě (zapojení do hvězdy)\n4. dále... distribuovaný model (lokální sítě - LAN)\n5. propojení pracovišť ( sítě WAN )\n6. mobilní technologie (WIFI,GSM)\n7. specializované sítě (SAN – viz poslední přednáška nebo PZA)\nHistorie v datech: 1957 – vznika ARPA (Advanced Research Projects Agency), 1960 –\nAT&T vyvinul dataphone, 1965 – první WAN z Massachussets do kalifornie, 1969 – síť\nARPANET (4 uzly), 1970 – NCP, 1972 – věrejná demonstrace ARPANET, 1972 – email,\n1973 – ethernet, 1975 – telnet, 1990 – www, 1991 – www server a browser, 1993 – mosaic\nTaxonomie (rozdělení) sítí\n• podle použití – na informační systémy nebo průmyslové aplikace\n• podele rozlehlosti – na LAN (local), MAN(metropolitan) nebo WAN(wide)\n• podle rychlosti – prostě tak nějak na rychlé a pomalé\n• podle topologie – sběrnice (viz PZA (nebo slide 9/1) – propojení více počítačů s\njednou sběrnicí), hvězda/strom (slide 10), kruh (slide 11), bezdrátové spoje (slide 12)\nVrstvená architektura – co to je? - je to vlastně taková obdoba komunikace přes\ntlumočníky, proč se to zavedlo? – kvůli zjednodušení návrhu, dekompozici problému a také\nsnadné možnosti výměny modulů\nFunkce vrstev – komunikace probíhá mezi vrstvami na stejné úrovni, vrstvy poskytují služby\nvyšším vrstvám a využívají služeb nižších vrstev, komunikace mezi stejnými vrstvami je\ntransparentní vůči nižším vrstvám, vrstvy interagují pouze se sousedními vrstvami (tj.\nvrstvami o 1 vyšší nebo o 1 nižší), komunikace mezi vrstvami je na slidu 15...\nPouzdření vrstev – prostě to zabalování probíhá tak, že nejvyšší vrstva poskytne nějaká data,\nta se zabalí do dat nižší vrstvy atd... atd...\nISO OSI referenční model:\n1. Fyzická vrstva (physical layer) – poskytuje toto: umožňuje přenos bitů kanálem,\ndefinuje signály pro „0“ a „1“, předepisuje vlastnosti média, definuje elektrické a\nmechanické vlastnosti rozhraní. Na fyzické vrstvě je vytvořen tzv. fyzický okruh. Na\nfyzický okruh mezi 2 počítače bývají často vkládána další zařízení jako modemy atd.\nPříklad: Ethernet 10BaseT, RS232 (sériový port - COM)\n2. Spojová vrstva (link layer) – Poskytuje v případě sériových linek výměnu dat mezi\nsousedními počítači a v případě lokální sítě výměnu dat na této síti. Základní\njednotkou přenosu je rámec, který se skládá se záhlaví, dat a zápatí. Poskytuje funkci\nspolehlivého spojení (detekce a korekce chyb), formátování dat do rámců,\nrozpoznávání rámců, řízení toku na lince, jednoznačnou adresu v rámci segmentu\n(link adresu – že by to byla MAC?). Na síťové vrstvě může být pro každý konec\nspojení použit jiný protokol... viz obrázek\nPříklad: PPP,LLC 802.2\n3. Síťová vrstva (network layer) – poskytuje adresaci a směrování dat přes mezilehlé\nprvky, jednoznačnou adresu v rámci sítě (síťovou adresu – že by i.p. adresa?), síťovou\nslužbu se spojením i bez něj. Základní jednotkou přenosu je síťový paket. který se\nskládá ze záhlaví a dat ...Jinak se zápatím se u síťových protokolů setkáváme jen\nzřídka. Směrovač operuje s paketem tak, že ho vybalí z ethernetového rámce a před\nodeslání do jiné linky jej opět zabalí...viz obrázek\nPříklady: X.25, IP\n4. Transportní (transport layer) – Síťová vrstva zabezpečí spojení mezi vzdálenými\npočítači, tak se transportní vrstvě jeví, jakoby tam žádne modemy nebo opakovače ani\nnebyly. Mezi dvěma počítači může být několik spojení na transportní vrstvě současně\n(jedno třeba pro mail a jedno pro ssh). Transportní vrstva poskytuje rozklad dat na\npakety (pozor, data v paketech mohou být různé délky – viz obr.\nuspořádání dat podle pořadí, multiplexuje a demultiplexuje data mezi transportními\nspoji, poskytuje transportní adresy (adresa, port) a koncové řízení toku. Příklady:\n5. Relační (session layer) – poskytuje vytváření logického rozhraní pro aplikace,\nsynchronizaci spojení (transakce), stará se o relace. DObře představitelnou relací je\nnapř. sdílení síťového disku. Tato relace existuje po celou dobu, ovšem spojení na\ntransportní vrstvě se navazuje jen tehdy, když je třeba s diskem pracovat. Základní\njednotkou přenosu relační vrstvy je relační paket. Příklady: RPC, sdílení disků\n6. Prezentační (presentation layer) – poskytuje sjednocení prezentace informace,\ndohodu o syntaxi, transformaci dat, šifrování, kompresi. Příklady: kódování\nASCII/EBCDIC, XDR, ASN.1\n7. Aplikační (application layer) – poskytuje podpůrné funkce aplikacím ASE\n(Application Service Element):\n• SASE – specifická podpora, přenos souborů, pošta, terminály\n• CASE – univerzální podpora – vytváření aplikačního spojení, obsluha transakcí\nTaké předepisuje v jakém formátu a jak mají být dat přebírána od aplikačních\nPříklady: knihovny pro tvorbu síťových aplikací\nPouzdření do ISO OSI – prostě jako jakékoli pouzdření to jde od nejsvrchější vrstvy k\nnejnižší - vždy se přidávají hlavičky a v síťové vrstvě se přidá navíc zakončení – fyzická\nvrstva to už jen přetransformuje na bity ... viz slide 25\nKomunikace mezi vrstvami – routery pracují na síťové vrstvě (potřebují znát totiž i.p.\nadresu), HUBy na fyzické vrstvě (jen překopírují data, k tomu není potřeba žádná adresa),\nSWITCHe na spojové(linkové) vrstvě (potřebují znát MAC adresu, aby věděly, kam to mají v\nPřednáška 2 – protokolová rodina TCP/IP\nVšimněte si: TCP/IP není jeden protokol, ale rodina protokolů – a navíc pod souslovím\n„rodina protokolů“ se skrývá síťový model – tzn. něco jako OSI (viz obrázek), tento model\n(TCP/IP) používá internet. Jak vidíme, TCP/IP májen 4 vrstvy, podobné OSI jsou jen síťová a\nRodina síťových protokolů TCP/IP neřeší (až na výjimky, jako je protokol SLIP) linkovou a\nfyzickou vrstvu,proto se i v Internetu setkáváme s linkovými a fyzickými protokoly z modelu\nHistorie: 1974 – první zmínka o TCP, 1978 – oficiální uvedení TCP/IP, 1983 – ARPANET\nadoptuje TCP/IP, 1991 – začátek prací na TCP/IP verze 6, 1995 – první RFC(co ta zkratka\nznamená viz dále) dokumenty k TCP/IP v 6\nRFC – Request for Comments – je to množina technických a organizačních dokumentů\nTCP/IP protokoly: DNS, SNMP, FTP, SMTP, OSPF, UDP, TCP, RARP, ARP, IP, ICMP, ...\nviz slide 4\nJak probíhá adresace? adresy jsou hierarchicky vrstvené, máme různé třídy adres nebo také\nbeztřídní adresy, dělíme adresy na subnet a supernet, probíhají tam převody mezi IP a\nlinkovými adresami, existují speciální adresy, máme i privátní sítě a nečíslované sítě... uf ...\nA. 0... .... (místo teček doplň jedničky či nuly) prostě první osmice bitů může být od 0 do\n127 (neboli 0000 0000 až 0111 1111). Adresu sítě určuje první bajt, zbytek je určen\npro adresu v rámci sítě\nB. 10.. .... (místo teček doplň cokoli) první osmice bitů může být od 128 do 191 (1000\n0000 až 1011 1111) . Adresu sítě určují první dva bajyt, zbytek je určen pro adresu v\nC. 110. ....(místo teček doplň cokoli) první osmice bitů je od 192 do 223 (1100 0000 až\n1101 1111). Adresu sítě určují první tři bajty, zbytek je určen pro adresu v rámci sítě\nD. 1110 ....(místo teček doplň cokoli) první osmice bitů je od 224 do 239 (1110 0000 až\n1110 1111). Adresa se již nedělí na adresu sítě a adresu počítače. Zbytek adresy tvoří\nadresný oběžník (multicast)\nE. 1111 ....(místo teček doplň cokoli) první osmice bitů je větší než 239 (1111 0000 až\n1111 1111). Třída E je víceméně rezervou pro adresy\nMaska sítě ... viz slidy – na slidu 7 je ukázané jak funguje maska podsítě, pokud je v masce\nčíslo za lomítkem, pak toto číslo udává počet jedniček zleva masky.\n• 0.0.0.0 - tento počítač na této síti\n• 00..0.počítač – počítač na této síti\n• síť.00..0 – adresa sítě jako takové\n• síť.subsíť.00..0 adresa subsítě\n• síť.11..1 – broadcast do sítě (do všech subsítí dané sítě)\n• síť.subsíť.11..1 – broadcast do subsítě\n• 11..1 – broadcast na lokální síti\n• 127.xx – loopback (127.0.0.1)\nTakže pokud máme např. síť 192.168.6.0 a dáme PING 192.168.6.255, pak nám odpoví\nvšechny počítače na této síti (ale implementace PING od Microsoftu je všechny nezobrazí,\nSubsíť – počet jedniček v jejich síťové masce je větší než u standartní síťové masky síťe\nSupersíť - počet jedniček v jejich síťové masce je menší než u standartní síťové masky síťe\nPrivátní sítě – Takto se označují sítě Intranetu – prostě dejmetomu LAN sítě firem nebo\nuživatelů.Tyto sitě mají vyhrazené adresy (pro počítače uvnitř sítě – schované za NATem ),\nkteré se nesmí vyskytovat v internetu, probíhá tam filtrování, překlad adres, třídy privátních\nNečíslované sítě (pokud by to někoho zajímalo – ve slidech to nejni) jsou to linky mezi\nsměrovači – prostě tyto linky se neberou jako nějaká síť, bere se to tak, že dva spojené\nsměrovače tvoří jeden virtuální směrovač.\nKomunikace po síti – viz slidy 12-32\n• slidy 12-18- komunikace po LAN – každý počítač má svou IP a MAC – to je ten třetí\nřádek, pokud chce 192.168.1.1 komunikovat s 192.168.1.10 musí zadat do rámce svou\nMACadresu a ip adresu cíle a dále svoji ip adresu (to aby příjemce věděl, kam má data\nvrátit) a nakonec samozřejmě data co posílá. Nejprve se porovnají adresy\nvyANDované (log, operace AND) s maskou podsítě a zjistí se, že oba kompy jsou ze\nstejné sítě. Poté se zjistí MAC adresa cíle a to tak, že odesílatel pošle dotaz do sítě na\nip adresu příjemce (slide 16), příjemce mu v odpovědi zašle svou MAC. Tím je rámec\nkompletní a může proběhnout komunikace\n• slidy 19 – 32 – komunikace přes routery – jak každý počítač, tak každý router má\nsvoji IP a MAC adresu, routery navíc mají více IP a MAC adres, protože mají více\nsíťových rozhraní. Na slidech chce počítač 192.168.1.1 komunikovat se 147.32.83.10,\nzadá tedy do rámce opět svou MAC, svoji ip a cílovou ip a data, porovnají se adresy\nvyANDované s maskou a zjistí se že zdroj a cíl nejsou ve stejné síti (slide 21), takže se\nbude posílat přes výchozí bránu (adresa 192.168.1.254). Tak, teď se přes tu bránu opět\npošle dotaz na MAC adresu brány (slide 23), příjde odpověď s MAC brány (slide 24),\ntakže rámec pošleme na bránu (slide 25), dobře, ale teď stále nevíme MAC cíle,\nznáme jen jeho IP. Opět zjistíme, že cíl není v téhle síti,no tak zase pošleme dotaz\n(!!pozor, v téhle chvíli se nám změnila MAC zdroje na MAC routeru, IP zdroje\nzůstává!!), tentokrát na druhý router.Ten router nám vrátí svoji MAC aresu, takže\npošleme data na něj (nezapomeň, že IP adresa zdroje zůstává stále stejná, aby se\nvědělo, kam se mají data vrátit) atd. atd... konec pohádky\nPřeklad adres (NAT) – probíhá při komunikaci z vnitřní do vnější sítě a naopak, je to překlad\nzdrojové a (nebo) cílové adresy, zdrojového a (nebo) cílového portu. Překlad může být buď\nstatický nebo dynamický. NAT se označuje také jako Maškaráda(Masquerade). NAT je\nvysvětlený na slidu 33 – všimni si, že při „přechodu dat“ přes první router se změnila cílová\nIP na adresu tohoto routeru (bez NATu by tam byla IP adresa cílového počítače)\n• Nastavení IP adresy a síťové masky prvního kompa – ifconfig eth0 192.168.1.1\nnetmask 255.255.255.0 (slide 35)\n• Nastavení defaultní brány pro kompy v podsíti – route add default gw 192.168.1.254\n• Nastavení směrovacích tabulek routeru 1 – je to na slidu 37, sloupce směrovací\ntabulky jsou cíl v síti, maska, brána, tzn. pokud chceme poslat data na nějakou adresu\n(mimochodem síť 0.0.0.0 s adresou 0.0.0.0 znamená všechny adresy), tak ta se\nporovná s cílem v síti a její maskou a poud to sedí, tak se data pošlou na bránu, co je u\ntoho nastavená (0.0.0.0 znamená asi defaultní brána)\n• Nastavení NATu – iptables -t nat –A POSTROUTING -o eth2 –j MASQUERADE\nPomocné protokoly: ICMP (Internet Control Message Protocol), IGMP(Internet Group\nManagement Protocol), ARP(Address Resolution Protocol), RARP(Reverse Address\nResolution Protocol), BOOTP(Bootstrap Protocol),DHCP(Dynamic Host Configuration\nProtocol), RIP (Routing Information Protocol), OSPF (Open Shortest Path First Routing\nProtocol), EGP (Exterior Gateway Protocol), BGP (Border Gateway Protocol)...\nPřednáška 3 – protokoly linkové vrstvy\nPoužití linkové vrstvy – přenos dat mezi přímo propojenými systémy, dělení proudu bitů na\njednotku informace, kontrola integrity dat, adresace v rámci segmentu, zapouzdření dat vyšší\nvrstvy. Na této vrstvě pracují bitově a znakově orientované protokoly.\nSerial Line Internet Protocol – vznikl na počátku 80.let, j popsán v rfc1055. Vkládá pakety\npřímo do sériové linky a pro řízení linky vkládá mezi data tzv. ESCape sekvence. Každý\nrámec protokolu SLIP je zakončen esc. sekvencí END (c016), většina implementací protokolu\nSLIP však END umisťuje i na začátek rámce. Jestliže se znak c016 (END) vyskytne i v\npřenášených datech, pak je nahrazen dvojicí znaků db16, dc16 viz obrázek...\nProtokol SLIP definuje pouze zapouzdření paketů na sériové lince (vzpomeň jsi jak jsme přes\nsériák hráli kdysi Duka).Nedefinuje adresaci, typ paketů,detekci chyb, kompresi ani informace\ndalší info na http://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol nebo na\nhttp://sunsite.nus.edu.sg/pub/slip-ppp/whatis.html nebo na str. 75 v bibli\nCompressed SLIP, neboli varianta protokolu slip používající kompresi, redukuje záhlaví TCP\n(20b) a IP(taky 20b) (ze 40B na 3 až 16B). Komprimuje se jen záhlaví, nikoliv data.\nMyšlenka komprese spočívá v tom, že autor se zamyslel nad IP a TCP záhlavím a zjistil, že\nmnohé údaje v těchto záhlavích se během TCP spojení nemění nebo se mění jen málo, takže\nstačí přenášet jen změněné položky IP a TCP záhlaví nebo dokonce jen přírůstky těchto\npoložek. Obrázek TCP a IP záhlaví je zde:\nPřenáší se tyto změny položek záhlaví: identifikace IP datagramu, SeqN (pořadové číslo\nodesílaného bajtu), AckN (pořadové číslo přijatého bytu), příznaky, délka okna, kontrolní\nsoučet TCP, ukazatel urgentních dat. Ignorují se tyto změny položek záhlaví: délka IP,\nkontrolní součet IP.\nKomprese záhlaví komprimuje záhlaví pouze v případě, že se jedná o TCP protokol a v\nzáhlavích se mění pouze uvedené položky. V opačném případě (např. je odeslán ICMP paket,\nje odeslán UDP datagram, jedná-li se o fragment IP-datagramu, je-li nastaven některý z\npříznaků RST, SYN, FIN nebo naopak nenastaven příznak ACK atp.) se komprese neprovede\na linkou je přenesen nekomprimovaný (nezměněný) rámec. Taktéž se nekomprimuje, pokud\nse změní jiné položky hlavičky. Kopresi provádí komponenta zvaná kompresor – ta studuje\npakety a v případě, že je paket komprimovatelný (jedná se o paket se záhlavím TCP + IP),\nzkomprimuje ho. v opačném případě ho propustí dále.\nKomprimované záhlaví obsahuje v prvním bajtu tzv. masku. Jednotlivé bity masky\nspecifikují, které položky v záhlaví originálního paketu se změnily, a proto celé položky nebo\njejich přírůstky musí být přenášeny i v komprimovaném záhlaví. Je-li příznak nastaven, pak v\nkomprimovaném záhlaví je uvedena konkrétní položka komprimovaného záhlaví, pokud není\nnastaven, pak příslušná položka není v komprimovaném záhlaví přítomna. Pro další\ninformace, co který bit masky znamená se mrkni do bible na str. 78.\nObrázek CSLIP je na slidu 5/3 a komprimované záhlaví je na slidu 6. Více o CSLIP na\nHigh Level Data Link Control. Tento protokol provádí detekci chyb a řízení toku dat. Je to\nprotokol podporující synchronní i asynchronní přenos (viz PZA), má velmi rozsáhlou normu,\nkterá je výrobci jen částečně implementovaná a mnohdy si výrobci dělají části protokolu\npodle sebe a tak se mezi různými výrobci u HDLC může projevit nekompatibilita (CISCO\nHDLC, DEC HDLC).\nProtokol HDLC má tři přenosové režimy:\nABM (Asynchronous Balanced Mode) – používá se pro komunikaci mezi 2 stanicemi.\nJe full duplex tj. obě stanice mohou vysílat současně, aniž by si vzájemně na lince\npřekážely. Většinou se dnes setkáváme právě s tímto módem. obrázek dole...\nNRM (Normal Response Mode) – více stanic, half duplex. Pro vysílání i příjem slouží\nspolečné přenosové médium, tj. v jednom okamžiku lze buK přijímat, nebo vysílat.\nJedna stanice je označena jako řídící stanice a ostatní jako podřízené stanice. Je\ndefinován tzv. pooling, tj. řízení, kdy která stanice smí vysílat. Bez povolení smí\nvysílat pouze řídící stanice. Ostatní stanice mohou vysílat jen tehdy, když jim to řídící\nstanice povolí. Tento mód je v internetu používán jen výjimečně.\nARM(Asynchronous Response Mode) – obdoba NRM, ale stanice může vysílat bez\nvyzvání. Tento mód se moc nepoužívá.\nFormát HDLC rámce – slide 8/3 – rámec začíná a končí tzv. křídlovou značkou (pokud jsou\ndvě křídlové značky po sobě, jedná se o prázdný rámec), křídlová značka je 0111 1110,\npokud by bylo náhodou šest jedniček v datech, pak se použije bit stuffing, tzn. pokud máme\npo sobě 5 jedniček, vložime za ně 0, dále je v rámci adresa, kontrolní součet, data, řídící pole\n– to dělí rámce na 3 skupiny:\n• U-rámce – slouží k přenosu dat, ale i pro některé řídící funkce (úvodní inicializační\ndialog, řzení linky, diagnostiku).Jsou nečíslované(unnumbered)\n• I-rámce – slouží k přenosu dat, ale mohou ve svém řídícím poli přenášet i některé\nřídící informace (např pozitivní potvrzení přijatých rámců)\n• S-rámce se používají k řízení toku dat (požadavek na vyslání a potvrzování rámců) . S\nrámce zpravidla neobsahují datové pole.\nVelikost řídícího pole je různá, v závislosti na režimu přenosu, potvrzování může být\nstřídavé, okénkové, pozitivní, negativní... formát HDLC rámce je zde na obrázku:\nHDLC dialogy – slide 10 – význam zkratek:\nSABM (Set Asynchronous Balanced Mode) – příkaz nastavuje linku do\nUA (Unnumbered Acknowledgement) - potvrzování řídících příkazů v U\nrámcich.Sekvenení čísla nepotřebná, protože v jedne chvíli může být\nvyslán jen jeden (nepotvrzený) příkaz\nDISC (Disconnect) - informace o vypínáni stanice\nFRMR (Frame Reject) - indikuje, ze přišel rámec s nesprávnou\nDM (Disconnect Mode) - vyjadřuje pozitivní potvrzení příkazu DISC\nVíce o HDLC na: http://www.elektrorevue.cz/clanky/01026/index.html a bible str. 79\nPoint to Point Protocol. Je to podmnožina HDLC protokolu a proto využívá rámce tvaru\nprotokolu HDLC. Nevyužívá však zdaleka všechny možnosti protokolu HDLC. Dokáže\npoužíva jak asynchronní, tak i bitově a znakově synchronní přenos dat, pro asynchronní\npřenos použije 1 start bit, 8 datových bitů a 1 stop bit. Vyžaduje plně duplexní dvoubodové\nspoje (Point to Point).\nCílem protokolu PPP je umožnit po jedné lince přenos více síťových protokolů současně\n(mixovat protokoly). Nepoužívá I-rámce, ale přenos provádí pouze pomocí U-rámců. Nemůže\ntedy použít číslování rámců, a tedy ani možnost opakování rámce v případě zjištění chybného\nrámce. Na počátku datového pole umísťuje osmi nebo šestnáctibitovou identifikaci\npřenášeného síťového protokolu (takhle umožní mix těch protokolů).\nFormát rámce PPP – je tam křídlová značka (opět použit bit stuffing), adresa, řídící pole,\nidentifikátor protokolu (zde je identifikován protokol, pomocí něhož se přenáší data, datové\nprotokoly začínají na 0, NCP začíná na 8), data ,kontrolní součet a křídlová značka... viz obr.\nSoučástí protokolu PPP jsou dva služební protokoly: Protokol LCP sloužící k navázání\nspojení, autentizaci stanic apod. Dále skupina protokolů NCP. Důležité je množné číslo.\nKaždý síťový protokol, který bude využívat linkový protokol PPP má definovánu vlastní\nnormu pro protokol NCP. Součástí této normy je vždy i číslo protokolu, které se použije v\npoli protokol rámce, a to jak pro příslušný protokol NCP (číslo začíná číslicí 8), tak i pro\ndatové rámce (číslo začíná číslicí 0).\nVíce o PPP na...http://www.elektrorevue.cz/clanky/01026/index.html\nLink Control Protocol – používá se ještě před tím, než se vůbec uvažuje o tom, jaký sí+ový\nprotokol na lince poběží.LCP je společný protokol (na rozdíl od protokolů NCP) pro všechny\nsí+ové protokoly. Protokol LCP je určen pro navázání spojení, ukončení spojení, výměnu\nautentizačních informací apod. Linka se nachází postupně ve fázi navazování spojení,\nautentizace, síťový protokol a ukončování spojení, jak je znázorněno na obr. Linka začíná\nvždy ve stavu odpojena.\nAutentizace je fáze, kdy klient prokazuje svou totožnost. Slovo klient jsem použil záměrně.\nAsi jste si položili otázku, kdo je to klient? Klientem je ta strana (stanice), která je vyzvána k\nprokázání své totožnosti. Po prokázání totožnosti jedné stanice si mohou stanice svou roli\nvyměnit a k prokázání své totožnosti může být vyzvána druhá strana. V praxi většinou\nprokazuje svou totožnost jen jedna strana Autentizace probíhá přes nějaký PAP – Password\nFáze síťový protokol v sobě může obsahovat celou řadu kroků.V tomto okamžiku přicházejí\nke slovu jednotlivé protokoly NCP. Každý síťový protokol, který chce linku využívat si musí\npřivést pomocí svého protokolu NCP linku do otevřeného stavu pro tento protokol.Pokud se\nobjeví datové pakety síťového protokolu, pro který není linka otevřena, pak se tyto pakety\nFormát LCP rámce je na obrázku – obsahuje kód (ten specifikuje typ příkazu protokolu LCP\n, příkazy mohou být např.Conf-Req/Ack/Nack/Rej...), ID (identifikace požadavku Odesílatel\nzvolí identifikaci do tohoto pole a adresát ji zkopíruje do své odpovědi. Pomocí tohoto pole se\nurčuje příslušnost odpovědi k danému požadavku.), délku (součet velikosti polí kód,ID,délka\na volby) a volby (požadavky/odpovědi na změnu parametrů linky)\nVíce o LCP například zde: http://www.networksorcery.com/enp/protocol/LCP.htm\nNetwork Control Protocols – jsou to IPCP, IPV6CP, SNACP, DNCP a IPXCP a další.\nInternet Protocol Control Protocol – je to protokol NCP pro protokol IP verze 4. Má ID =\n8021, struktura rámce je na obrázku...\nTakže kód příkazu , volby (jsou podobné LCP) Pokud dáme jako protokol v rámci PPP číslo\n0021, bude nám to posílat nekomprimované pakety, pokud tam dáme 002d, posílá je\nInstituce IEEE před dvaceti lety předložila projekt, jehož cílem bylo vypracovat normy pro\njednotlivé typy LAN (např. Ethernet, Arcnet, Token Ring atd.). Tyto normy popisovaly pro\nkaždý typ LAN vrstvu MAC. Vznikla tak norma IEEE 802.3 pro Ethernet, IEEE 802.4 pro\nToken Bus, IEEE 802.5 pro Token Ring atd. Pro všechny systémy pak byla vypracována\nspolečná norma pro vrstvu LLC pod označením IEEE 802.2, což schématicky vyjadřuje\nProblematika linkové vrstvy pro LAN tak byla rozdělena do dvou podvrstev. Spodní vrstva\nMedium Access Control (MAC) částečně zasahující do fyzické vrstvy se zabývá přístupem na\npřenosové médium. Horní vrstva Logical Link Control (LLC) umožňuje navazovat, spravovat\na ukončovat logická spojení mezi jednotlivými stanicemi LAN.\nNyní již o protokolu Ethernet – mnohem více o něm je v bibli na straně 112\nProtokol Ethernet byl původně vyvinut firmami DEC, Intel a Xerox. Jeho varianta 10 MHz se\noznačuje jako Ethernet II. Později byl Ethernet normalizován institutem IEEE jako norma\n802.3. Tato norma byla převzata ISO a publikována jako ISO 8802-3. Formát rámců podle\nnormy Ethernet II se mírně odlišuje od formátu ISO 8802-3. Postupem času vznikla norma\nIEEE 802.3u pro Ethernet na frekvenci 100 MHz (Fast Ethernet) a norma IEEE 802.3z pro\nfrekvenci 1 GHz (gigabitový Ethernet). Struktura rámce protokolu Ethernet závisí na použité\nnormě. Probereme si více možných typů...\nFormát rámce Ethernet II (DIX) – viz obrázek...\nje tam nějaká preambule – při ní se synchronizují všechny stanice přijímající rámec, dále\nDA(destination address)-adresa cíle, SA(source address) – adresa zdroje, adresy mají 24b –\njsou to adresy přidělené zařízení výrobcem, prostě adresy MAC (viz\nhttp://en.wikipedia.org/wiki/MAC_address), dále je tam typ (ID) přenášeného protokolu, kde\n0800 znamená IP, 0806 ARP, 8035 = RARP, 86DD = IPV6, 88A2 = ATA over ethernet, dále\njsou tam data (musí být minimálně 46 B dlouhé, pokud tomu tak není, vyplní se zbytek\nbezvýznamnou výplní) a nakonec CRC\nIEEE 802.3 – je to taktéž norma pro Ethernet – tako vá konkurence pro protokol Ethernet II\nZabývá se vrstvou MAC. Formát rámce je na obrázku...\nFormát rámce je stejný jako u Ethernet II až na to že místo typu protokolu máme pole délka\noznačující délku přenášených dat. Dalším rozdílem je, že datové pole může v sobě nést\nnikoliv jen data, ale paket protokolu 802.2, jehož záhlaví může být ještě rozšířeno o dvě pole\ntvořící tzv. SNAP\nFormát rámce IEEE 802.2 – viz obrázek\nNyní k popisu polí Destination Service Access Point (DSAP)/Source Service Access point\n(SSAP) specifikují aplikaci cílovou/zdrojovou aplikaci, která rámec odesílá/přijímá. Např. pro\nIP-protokol se používá DSAP=SSAP=AA16 a pro NetBIOS se používá DSAP=SSAP=F016.\nPři použití protokolu ISO 8802-2 je možné doručovat data až jednotlivým aplikacím běžícím\nna stanici. Existují i síťové protokoly, které pro komunikaci na LAN používají pouze tuto\nadresaci (nepoužívají sí+ovou vrstvu). Použití takových protokolů je sice efektní (o jednu\nvrstvu jsou rychlejší), ale jsou nesměrovatelné, tj. jsou určeny pouze pro LAN, nikoliv pro\nWAN. Příkladem takovéhoto exotického protokolu je protokol NetBEUI.Řídící pole je\nnaprosto analogické řídícímu poli protokolu HDLC. Opět mezi stanicemi se může\nkomunikovat pomocí U, I a S-rámců. Rámce mohou být číslovány, v případě ztráty nebo\nchyby v rámci může být vyžádána retransmise atd. Pro potřeby protokolu IP se používají\npouze U-rámce a P/F bit je nastaven na nulu, tj. řídící pole má hodnotu 0316 (obdobně jako v\npřípadě protokolu PPP).\nPomocí záhlaví SNAP (Sub-network Access Protocol) je možné specifikovat protokol vyšší\nvrstvy, jedná se tedy o obdobu pole protokol v Ethernetu II. Dokonce pro specifikaci\nprotokolu vyšší vrstvy se používají stejné hodnoty. Jinými slovy co chybělo protokolu ISO\n8802-3 oproti protokolu Ethernet II(pole protokol), se krkolomně řeší pomocí záhlaví SNAP.\nPorovnání Ethernet II a SNAP:\n(co je SNAP (Subnetwork Access Protocol) se dočtete zde:\nTeď tedy to porovnání: SNAP přenáší méně dat a podporuje další typy sítí, výsledek přenosu\nje u obou stejný, nicméně v internetu je vyžadována podpora Ethernet II\nPřednáška 3 – Data Link Layer (diagramy přenosu)\nPřečti, pokud chceš: http://www.angelfire.com/ut/cnst/chap05.html\nMožnosti potvrzování – jsou 3 možnosti potvrzování – buď pomocí ACK/NACK, nebo\npomocí BCC (block check character – něco jako parita), nebo se vrátí celý rámec s daty.\nPositivní potvrzování – pokud rámec dorazí, příjemce pošle potvrzení\nČistě negativní potvrzování – potvrzení příjemce pošle, pokud rámec nedorazí, positivní\npotvrzení se neposílají\nNegativní potvzování – příjemce posílá jak negativní, tak pozitivní potvrzení\nČíslování rámců – prostě zpět v potvrzení se pošle číslo rámce, který se nyní očekává.\nSliding window – posíláme najednou několik rámců a čekáme na potvrzení do určitého\nSelektivní odmítnutí (Selective Reject) - pokud jsme už ten který rámec dostali (například\nna slidech je to ráemec číslo 1) a příjde k nám podruhé, zašleme odesílateli odmítnutí, ať ho\npříště už neposílá\nSliding Window – duplex – prostě rámce odesílají a přijímají obě strany a na konec\nodeslaných rámců vždy přiloží potvrzení (tomu se říká piggybacking)\nPřednáška 4 –Protokolová rodina TCP/IP – dokončení\nObsah přednášky – protokol síťové vrstvy (IP), podpůrné protokoly\n(ICMP,RARP,BOOTP,DHCP), protokoly transportní vrstvy (UDP,TCP)\nInternet Protocol. Jeho úkolem je dopravovat data mezi dvěma libovolnými směrovači v\ninternetu (tzn. i přes mnohé LAN). IP-protokol je protokol, umožňující spojit jednotlivé\nlokální sítě do celosvětového Internetu. Od protokolu IP dostal také Internet své jméno.\nZkratka IP totiž znamená InterNet Protocol. IP-protokol je tvořen několika dílčími protokoly:\n• Vlastním protokolem IP\n• Službním protokolem ICMP sloužícím zejména k signalizaci mimořádných stavů\n• Služebním protokolem IGMP sloužícím pro dopravu adresných oběžníků\n• Služebními protokoly ARP a RARP, které jsou často vyčleňovány jako na IP nezávislé\nprotokoly, protože jejich rámce nejsou předcházeny IP záhlavím\nMá podporu fragmentace (co to je zjistíte zde nebo zde), podporu komunikace přes\nsměrovače, vytváří IP pakety z paketů vyšší vrstvy. IP adresa má velikost 4B. IP protokol\npracuje s koncovými uzly a směrovači a je to základní protokol rodiny TCP/IP.\nFragmentace – umožňuje vložení IP paketu do kratších rámců nižší vrstvy (MTU Ethernet II\nje např. jen 1500B – takže si vemte, že máme třeba 64 KB velký IP datagram (64 KB je max\nvelikost IP datagramu), jak ho Směrovač vloží do rámce, který může mít třeba max 1500B?\nSměrovač není schopen takový IP-datagram poslat dále. Směrovač se rozhoduje co dále na\nzákladě příznaku „Fragmentace možná” (DF bit) v záhlaví IP-datagramu. Příznak\n„Fragmentace možná” může být buď nastaven nebo ne. Jsou tedy dvě možnosti:\n• Fragmentace je možná, pak se fragmentace provede (viz dále)\n• Fragmentace není možna – pak směrovač IP datagram zahodí a odesílatele o tom\npomocí ICMP informuje signalizací „Fragmentace zakázána“ (a pokud to směrovač\numí, pošle nám, jaké nejmenší MTU je po cestě)\nPokud je fragmentace povolena, pak pak směrovač dělí delší IP-datagramy na fragmenty,\njejichž celková délka (total length) je menší nebo rovná MTU následující linky ... viz obr\nKaždý IP-datagram má ve svém záhlaví svou identifikaci, kterou dědí i jeho fragmenty. Díky\nidentifikaci příjemce pozná, ze kterých fragmentů má datagram složit. Nikdo jiný než\npříjemce není oprávněn z fragmentů skládat původní datagram, tj. ani např. směrovač ze\nkterého vede linka s takovým MTU, do kterého by se celý datagram již vešel. Důvod je\nprostý, Internet negarantuje, že jednotlivé fragmenty půjdou stejnou cestou (ani negarantuje\npořadí v jakém dojdou). Takže směrovač, který by se pokoušel datagram sestavit by mohl být\nna závadu spojení, protože fragmentů, které by šly jinou cestou by se nikdy nedočkal. Každý\nfragment tvoří samostatný IP-datagram. Při fragmentaci je nutné vytvořit pro každý fragment\nnové IP-záhlaví. Některé údaje (jako protokol vyšší vrstvy, či IP-adresa odesílatele a\npříjemce) se získají ze záhlaví původního IP-datagramu. Při fragmentaci vstupuje do hry pole\n„Posunutí fragmentu od počátku IP-datagramu (fragment offset)”, které vyjadřuje kolik bajtů\ndatové části původního IP-datagramu bylo vloženo do předchozích fragmentů. Pole „Celková\ndélka IP-datagramu (total length)” obsahuje délku fragmentu, nikoliv délku původního\ndatagramu. Aby příjemce poznal jak je původní datagram dlouhý, tak je poslední fragment\nopatřen příznakem „Poslední fragment”. Celý mechanismus je znázorněn na obrázku.\nSíť nerozlišuje mezi přenosem fragmentu a přenosem celého (nefragmentovaného) IPdatagramu. Nefragmentovaný datagram je fragment s posunutím nula a příznakem „Poslední\nfragment”. Proto se často slova IP-datagram a fragment zaměňují. Mechanismus fragmentace\numožňuje i fragmentovat fragment dorazí-li na směrovač jehož odchozí linka má ještě menší\nPodpora fragmentace je dána příkazy DF(Don’t fragment) a MF(More Fragments), dále\nidentifikací IP datagramu a také offsetem ve fragmentu\nSměrování – existuje buď přímé směrování (směrování na uzly ve stejné síti), nebo nepřímé\nsměrování (uzly v různých sítích). Implicitní směrování probíhá přes defaultní bránu.\nSměrování může být podle směrovacích tabulek rozděleno na statické (informace jsou do\ntabulky uloženy ručně při konfiguraci směrovače) a dynamické (směrovací uzly si pravidelně\nvyměňují informace a podle toho tvoří sěrovací tabulky – použito u velkých sítí ).\nSlužby směrovače: podpora předávání paketů (forwarding – viz zde), kontrola a snižování\nTTL (Time to live-viz zde), přepínání kontrolního součtu, zohlednění ToS(Terms of Service –\nviz zde) podle priority (precedence - pole o 3b), nízkého zpoždění (delay - 1b) a vysoké\npropustnosti (throughput – 1p).\nStruktura IP datagramu – tvoří ji hlavička(záhlaví) a data.\nHlavička IP datagramu – je v ní:\n• verze IP protokolu (4b)\n• délka záhlaví – je udávána ne v bytech, ale ve čtyřbytech (32b), typ služby (ToS – 5b\n– je to položka, která nenašla v praxi svého naplnění, měla označovat IP datagramy\ntak, aby byly některé předávány přednostně a byla tak zaručena rychlá odezva),\n• celková délka IP datagramu (omezeno na 64KB)\n• identifikace IP datagramu (tato položka je společně s příznaky a posunutím fragmentu\nvyužívána mechanismem fragmentace datagramu)\n• příznaky (DF =1 -> nefagmentovat, MF = 0 -> poslední fragment)\n• posunutí fragmentu\n• TTL (pokud je 0 -> likvidace paketu)\n• protokol vyšší vrstvy (1-ICMP,2-IGMP,6-TCP,17-UDP...) - je to číselná identifikace\nprotokolu vyšší vrstvy, který využívá IP datagram ke svému transportu . V praxi je\npoužit např. TCP/UDP nebo ICMP, IGMP – tyto dva jsou sice součástí protokolu IP,\nale chovají se jako protokoly vyšší vrstvy, tzn. v přenášeném paketu je záhlaví IP\nnásledováno záhlavím ICMP resp. IGMP .\ndále kontrolní součet záhlaví- všimni si – je to pouze kontrolní součet záhlaví nikoliv\nz datagramu celého, význam tohoto pole je tedy pochybný – navíc když směrovač\nzmění nějakou položku záhlaví, amění se i kontrolní součet, což přináší určitou režii\nIPadresy příjemce a odesílatele\nvolitelné položky (max 40B např. může být nastavena položka zaznamenávej\nsměrovače či zaznamenávej čas, což může být snadno zneužitelné hackery.Dále jsou\ntam položky jako explicitní směrování (vyjádřeno, přes které směrovače se má\nsměrovat), striktní explicitní směrování (vypsány všechny směrovače, přes které se\nsměruje), upozornění pro směrovač...viz slide 8) viz obrázek...\nInternet Control Message Protocol.Protokol ICMP je služební protokol, který je součástí IPprotokolu. Protokol ICMP slouží k signalizaci mimořádných událostí v sítích postavených na\nIP-protokolu. Protokol ICMP svoje datové pakety balí do IP-protokolu, tj. pokud budeme\nprohlížet přenášené datagramy, pak v nich najdeme za linkovým záhlavím záhlaví IPprotokolu následované záhlavím ICMP paketu. Protokolem ICMP je možné signalizovat\nnejrůznější situace, skutečnost je však taková, že konkrétní implementace TCP/IP podporují\nvždy jen jistou část těchto signalizací a navíc z bezpečnostních důvodů mohou být na\nsměrovačích mnohé ICMP signalizace zahazovány.\nFormát ICMP Paketu – Záhlaví ICMP-paketu je vždy osm bajtů dlouhé (viz obr. 5.10).\nPrvní čtyři bajty jsou vždy stejné a obsah zbylých čtyř závisí na typu ICMP-paketu.\nPrvní čtyři bajty záhlaví obsahují vždy typ zprávy, kód zprávy a šestnáctibitový kontrolní\nsoučet. Formát zprávy závisí na hodnotě pole Typ. Pole Typ je hrubým dělení ICMP-paketů.\nPole Kód pak specifikuje konkrétní problém (jemné dělení), který je signalizován ICMP\nTypy ICMP paketů – určují se typem a kódem, tady jsou:\nnedoručitelny IP datagram – důvod udává kód...viz dále\nnedosažitelný UDP port\nchyba explicitního směrování\nadministrativně uzavřená síť\nadministrativně uzavřený uzel\nnedosažitelná síť pro službu\nnedosažitelný uzel pro službu\nkomunikace administrativně uzavřena filtrací\nsniž rychlost odesílání\nzměň směrování ... pro co určuje kód\npro síť pro daný typ služby\npro uzel pro daný typ služby\nodpověď na žádost o směrování\nčas vypršel... proč viz kód\nchybný parametr...jaký viz kód\nchybné IP záhlaví\nschází volitelný parametr\nčasová synchronizace – požadavek\nčasová synchronizace - odpověď\nžádost o masku\nodpověď na žádost o masku\nNěkteré typy zpráv ICMP:\n• nástroj Echo - Je jednoduchý nástroj protokolu ICMP, kterým můžeme testovat\ndosažitelnost jednotlivých uzlů v Internetu. Žadatel vysílá ICMP-paket „Žádost o\necho“ a cílový uzel je povinen odpovědět ICMP-paketem „Echo“. Používá se např. u\n• nedoručitelný IP datagram – pokud nemůže být IP datagram doručen adresátovi, pak\nje zahozen a odesílatel je o tomto informován přesně touto zprávou\n• sniž rychlost odesílání – jestliže je síť mezi odesílatelem a příjemcem přetížena a\nsměrovač není schopen předávat všechny IP datagramy, pak odesílatele informuje\ntouto zprávou, ať je odesílá pomaleji.\n• změň seměrování – pomocí tohoto ICMP se provádějí dynamické změny ve směrovací\ntabulce – například touto zprávou upozorní směrovač (koho, co?) další směrovač nebo\npočítač tehdy, pokud má příchozí paket odeslat na tu cestu, ze které paket přišel.\n• čas vypršel – například když TTL bylo sníženo na 0 (kód zprávy 1), nebo se\nsignalizuje, že počítač adresáta není schopen z IP fragmentů sestavit celý IP datagram.\nICMP paket čas vypršel používají ke své činnosti programy TRACERT (WIN) a\nO něm jen krátce, na slidech to není, ale je to dobré vědět... Protokol IGMP je podobně\njako protokol ICMP služebním protokolem (podmnožinou) protokolu IP.Pakety IGMP\nprotokolu jsou baleny do IP-datagramů. Protokol IGMP slouží k šíření adresných oběžníků\n(multicasts) – To znamená, že si do toho paketu IGMP napíšeme explicitně adresy, na které\nchceme paket (vyšší vrstvy – např. UDP) poslat a on se nám skutečně pošle na více adres – na\ntom principu funguje například VLC na Strahově a dobře to šetří síť. Multicasty jsou ale v\ninternetu víceméně nepoužitelné, protože nelze zajisti to, že je všechny směrovače po cestě\nPokračujeme v povídání o IP ... užitečný protokol, jež IP využívá je protokol ARP\nProtokol ARP – Address Resolution Protocol - řeší problém zjištění linkové adresy protější\nstanice ze znalosti její IP-adresy. Řešení je jednoduché, do LAN vyšle linkový oběžník\n(linková adresa FF:FF:FF:FF:FF:FF) s prosbou: „Já stanice o linkové adrese HW1, IP-adrese\nIP1, chci komunikovat se stanicí o IP-adrese IP2, kdo mi pomůže s nalezením linkové adresy\nstanice o IP-adrese IP2? Stanice IP2 takovou žádost uslyší a odpoví. V odpovědi uvede svou\nlinkovou adresu HW2. ARP-paket je balen přímo do Ethernetu, tj. nepředchází mu žádné IPzáhlaví. Protokol ARP je vlastně samostatný, na IP nezávislý protokol. Proto jej mohou\npoužívat i jiné protokoly, které s protokoly TCP/IP nemají nic společného. Jak ARP funguje,\nresp. to, co bylo popsáno na předešlých řádcích je na obrázku\nZajímavosti – jedno síťové rozhraní počítače může mít více IP adres. První adresa se pak\nobvykle nazývá primární a další adresy pak sekundární nebo aliasy.Využití sekundárních IPadres je běžné např. pro WWW-servery, kdy na jednom počítači běží WWWservery několika\nfirem a každý se má tvářit jako samostatný WWW-server.\nPřidělení IP adresy počítači – může být buď statickéí(IP adresa je trvale přidělena ) nebo\ndynamické (IP adresa se přidělí jen na dobu připojení). Pro přidělování adres se používají\n• RARP -Reverse Address Resolution Protocol – přidělení adresy bezdiskové stanici,\nmoc se nepožívá.\nBOOTP - Bootstrap Protocol – využívá protokolu UDP, slouží ke statickému\npřidělování parametrů, dokáže přidělit adresu, jméno, masku, směrovače, DNS, time\nserver, forwarding, MTU (co to je MTU viz zde)...\nDHCP – Dynamic Host Configuration Protocol Protokol DHCP vychází ze zkušeností\na částečně v sobě zahrnuje i podporu starších protokolů z této oblasti, tj. protokolů\nRARP, RARP a BOOTP. V protokolu DHCP žádá klient DHCP-server o přidělení IPadresy (případně o další služby). DHCP-server může být realizován jako proces na\npočítači s operačním systémem UNIX, Windows NT atp. Nebo DHCP-server může\nbýt realizován i jako součást směrovače. DHCP se používá k dynamickému\npřidělování parametrů narozdíl od BOOTP\nTransportní protokoly – slouží k přenosu dat mezi aplikacemi, mají podporu aplikačního\nmultiplexu (asi že když máme spuštěné 2 stejné aplikace, tak to neva a data se multiplexují)\npomocí portů, podporu řízení toku. K transportním protokolům patří nepotvrzovaný UDP a\nNěco o tomto protokolu... jinak UDP = User Datagram Protocol\nProtokol UDP je jednoduchou alternativou protokolu TCP. Protokol UDP je nespojovaná\nslužba (na rozdíl od protokolu TCP), tj. nenavazuje spojení. Odesílatel odešle UDP datagram\npříjemci a už se nestará o to, zdali se datagram náhodou neztratil (o to se musí postarat\nZáhlaví UDP -... viz obrázek\nZ předchozího obrázku je patrné, že záhlaví UDP protokolu je velice jednoduché. Obsahuje\nčísla zdrojového a cílového portu – což je zcela analogické protokolu TCP. Opět je třeba\ndodat, že čísla portů protokolu UDP nesouvisí s čísly portů protokolu TCP. Protokol UDP má\nsvou nezávislou sadu čísel portů. Pole délka dat obsahuje délku UDP datagramu (délku\nzáhlaví + délku dat). Minimální délka je tedy 8, tj. UDP datagram obsahující pouze záhlaví a\nžádná data. Zajímavé je že pole kontrolní součet nemusí být povinně vyplněné. Výpočet\nkontrolního součtu je tak v protokolu UDP nepovinný. Pakliže se kontrolní součet počítá, pak se\npodobně jako pro protokol TCP počítá ze struktury (pseudozáhlaví)znázorněné na obrázku\nFragmentace - I u UDP datagramů je možná fragmentace v IP-protokolu. Avšak u UDP\nprotokolu se zásadně snažíme fragmentaci vyhýbat.\nOběžníky - Na první pohled by se zdálo, že protokol UDP je chudým příbuzným protokolu\nTCP. Může však existovat něco, co umí protokol UDP a nelze to udělat protokolem TCP?\nPrávě zvláštností protokolu UDP je skutečnost, že adresátem UDP datagramu nemusí být\npouze jednoznačná IP-adresa, tj. síťové rozhraní konkrétního počítače. Adresátem může být\nskupina stanic – adresovat lze i oběžník. Adresovat lze všeobecné oběžníky (broadcast), ale\npodstatně zajímavějším případem je adresování adresných oběžníků (multicast). Např. u\naplikací typu RealAudio navazuje každý klient spojení se serverem. Kdežto u\nProgresiveRealAudio se šíří data pomocí adresných oběžníků, tj. dochází k ohromné\núspoře kapacity přenosových cest. A právě to je příležitost pro UDP. Pomocí UDP multicast\npracuje i přenos televize na Strahově\nKecy ze slidů...\nUser Datagram Protocol, je to nepotvrzovaná služba bez spojení, umožňuje broadcast, pracují\npřes něj DNS, Bootp, TFTP, SNMP...\nFormát datagramu UDP – slide 16... budu říkat jen to barevné, zbytek je z IP paketu. Takže\nhlavička obsahuje volitelné položky hlavičky, zdrojový a cílový port UDP, délku dat a\nkontrolní součet (nepovinný, ale aplikace jej mohou vyžadovat, vypočítává se z\npseudohlavičky). Pseudohlavička neobsahuje volitelné položky hlavičky a z toho IP je tam\nmnohem méně ... viz slide 17\nNěco o tomto protokolu – jinak TCP = Transmision Control Protocol\nZatímco protokol IP přepravuje data mezi libovolnými počítači v Internetu, tak protokol TCP\ndopravuje data mezi dvěma konkrétními aplikacemi běžícími na těchto počítačích. Protokol\nIP adresuje IP-adresou pouze sí;ové rozhraní počítače. Pokud bychom použili přirovnání k\nběžnému poštovnímu styku, pak IP-adresa odpovídá adrese domu a port (adresa v protokolu\nTCP) pak odpovídá jménu konkrétního obyvatele domu. Protokol TCP je spojovanou službou\n(connection oriented), tj. službou která mezi dvěma aplikacemi naváže spojení – vytvoří na\ndobu spojení virtuální okruh. Tento okruh je plně duplexní (data se přenášejí současně na sobě\nnezávisle oběma směry). Přenášené bajty jsou číslovány. Ztracená nebo poškozená data jsou\nznovu vyžádána. Integrita přenášených dat je zabezpečena kontrolním součtem. Konce\nspojení (“odesílatel” a „adresát”) jsou určeny tzv. číslem portu. Toto číslo je dvojbajtové,\ntakže může nabývat hodnot 0 až 65535. Základní jednotkou přenosu v protokolu TCP je TCP\nsegment. Někdy se také říká TCP paket. Proč segment? Aplikace běžící na jednom počítači\nposílá protokolem TCP data aplikaci běžící na jiném počítači. Aplikace potřebuje přenést\nnapř. soubor velký 2 GB. Jelikož TCP segmenty jsou baleny do IP datagramů, který má pole\ndélka dlouhé 16 bitů, tak TCP segment může být dlouhý maximálně 65535 minus délka TCPzáhlaví. Přenášené 2 GB dat musí být rozděleny na segmenty, které se vkládají do TCP paketu\n– přeneseně se pak místo TCP paket říká TCP segment. TCP segment se vkládá do IPdatagramu. IP-datagram se vkládá do linkového rámce. Použije-li se příliš velký TCPsegment, který se celý vloží do velkého IP-datagramu, který je větší než maximální velikost\npřenášeného linkového rámce (MTU), pak IP protokol musí provést fragmentaci IPdatagramu\nNyní nějaká fakta ze slidů...\nTransmission Control Protocol – je to spolehlivá spojovaná služba, podporuje multiplex i\nduplexní přenos (piggybacking), dále také proudový přenos (stream – navážeš spojení, vytvoří\nse nějaký tunel a přes to to běží), umožňuje potvrzování a opakování segmentů, adaptivní\npřizpůsobení parametrů, má implementované sliding window, umožňuje vytváření a rušení\ntransportních spojení, příjem dat z vyšší vrstvy a vytváření TCP paketů, koncové řízení toku.\nTCP využívají protokoly http, ssh, telnet\nHlavička (záhlaví) TCP – viz obrázek...\nHlavička TCP má tyto pole:\n• zdrojový a cílový port TCP- je to port odesílatele a port příjemnce. Pětice zdrojový\nport, cílový port, zdrojová IP, cílová IP a protokol (typ protokou) jednoznačně\nidentifikuje v daném okamžiku spojení v internetu.\n• pořadové číslo odesílaného bytu (číslo prvního bytu) – TCP segment je část z toku dat\ntekoucích od odesílatele k příjemci. Pořadové číslo odesílaného bytu je pořadové\nčíslo prvního bajtu TCP segmentu v toku dat od odesílatele k příjemci (TCP segment\nnese bajty od pořadového čísla odesílaného bajtu až do délky segmentu)\n• , pořadové č. očekávaného bytu(poslední dobře přijatý byte + 1) vyjadřuje číslo\nnásledujícího bytu, který je příjemce připraven přijmout, tj. příjemce tak vlastně\npotvrzuje, že úspěšně přijal data do (pořadové_číslo_očekávaného_ bytu - 1)\n• délka záhlaví – vyjedřuje délku TCP záhlaví, je v násobcích 32b\n• příznaky (URG – TCP segment nese urgentní data, ACK – potvrzení, PSH – TCP\nsegment nese aplikační data, RST-odmítnutí TCP spojení, SYN – Odesílatel začíná s\nnovou sekvencí číslování, FIN – odesílatel ukončil odesílání dat)\n• délka okna – vyjadřuje maximální přírůstek čísla přijatého bytu, který bude\npříjemcem ještě akceptován\n• kontrolní součet TCP\n• ukazatel naléhavých dat – může být nastaven pouze tehdy, je-li nastaven příznak\nURG. Přičte li se tento ukazatel k pořadovému číslu odesílaného bytu, pak ukazuje\nna konec úseku naléhavých dat. Odesílatel si přeje, aby příjemce tato data přednostně\nK poli volitelné položky: oproti položkám UDP se používají a přenáší. Volitelná položka se\nskládá z typu volitelné položky, délky volitelné položky a hodnoty. Na tyto položky zbývá\n40B TCP záhlaví. Mezi volitelné položky patří např.: maximální délka segmentu, zvětšení\nokna, časové razítko, čítač spojení.\nNavázání TCP spojení - klient začíná navazovat spojení odesláním prvního TCP segmentu. Tento\nTCP segment klient vloží do IP-datagramu jehož IP-adresa odesílatele bude „Klient” a IPadresa příjemce „Server”. Klient vygeneruje náhodné číslo v intervalu 0 až 232-1, které\npoužije jako startovací pořadové číslo odesílaného bajtu (tzv. ISN). V našem případě bylo\nvytvořeno ISN=145165778. Skutečnost, že klient právě vytvořil startovací pořadové číslo\nodesílaného bajtu vyznačí v TCP segmentu nastavením příznaku SYN (….S.). Během spojení\njiž pořadové číslo odesílaného bajtu bude vždy vyjadřovat číslo odesílaného bajtu, tj. nemůže\nbýt znovu vygenerováno. Obrázek navazování spojení je tady:\nSegment (1) je prvním segmentem v TCP komunikaci, proto nemůže potvrzovat žádná přijatá\ndata. Pole pořadové číslo přijatého bajtu nemá platný význam (bývá vyplněno binárními\nnulami) a nemůže být tedy ani nastaven příznak ACK (příznak ACK je nastaven ve všech\ndalších TCP segmentech až do ukončení spojení). Součástí segmentů (1)a (2) byla volitelná\npoložka záhlaví TCP segmentu MSS (Maximum segment size). Tato položka oznamuje druhé\nstraně maximální délku datové části TCP segmentu jakou si přeje přijímat (aby se pokud\nmožno zamezilo fragmentaci IP-datagramu). Implicitně se MSS používá 536 bajtů. Tato\nhodnota je používána pro spojení mimo lokální sí; (přes WAN). Pro náš příklad jsme použili\nspojení v rámci lokální sítě protokolem Ethernet II. Pro linkový protokol Ethernet II je\nmaximální délka datové části rámce rovna 1500. Pokud od 1500 odečteme 20 pro IP-záhlaví a\ndalších 20 pro TCP záhlaví, pak dojdeme k hodnotě z našeho příkladu (1460).\nTakže pokud to shrneme...,tak... stavy při navazování spojení jsou : LISTEN (server je\npřipraven na spojení s klienty), SYN_SEND (klient odeslal první TCP segment) a\nSYN_RCVD (server přijal od klienta první TCP segment, tj. segment s příznakem SYN),\npotom je spojení ESTABLISHED, tedy ustanoveno...viz obrázek\nUkončování spojení TCP - Zatímco spojení navazoval v architektuře klient/server zpravidla\nklient, tak ukončit spojení může libovolná strana. Strana, která první odešle TCP segment s\npříznakem FIN (ukončení spojení) provádí tzv.aktivní ukončení spojení (active close), druhé\nstraně nezbývá než provést pasivní ukončení spojení (pasive close). Teoreticky je možné i\nsoučasné ukončení spojení.\nStavy při ukončování spojení:\n• FIN_WAIT1 (strana zjistila, že už všechna data odeslala, a potřebuje např.\nsignalizovat konec souboru, tak v TCP segmentu nastaví příznak FIN, čímž signalizuje\naktivní ukončení spojení )\n• CLOSE_WAIT (druhá strana obdržela aktivní uzavření spojení a nezbývá jí nic jiného\nnež potvrdit segmentem přechod do pasivního uzavření spojení – tomuto stavu\nodpovídá právě CLOSE_WAIT)\n• FIN_WAIT2 ( toto je stav poté, co strana obdrží potvrzení aktivního uzavření spojení\nod protějšku. Ve stavu FIN_WAIT2 strana zůstává do té doby, dokud protějšek\nnezašle TCP segment s příznakem FIN, tj. do přechodu do stavu TIME_WAIT. Pokud\naplikace nepočítá s přenosem dat v polouzavřeném spojení, a spojení je nečinné po\n11,25 minuty, pak operační systém automaticky změní stav spojení na CLOSED.)\nLAST_ACK – druhá strana již odeslala všechna data a signalizuje úplné končení\nTIME_WAIT - všechna data oběma směry již byla přenesena. Je nutné pouze potvrdit\núplné uzavření spojení. Odesláním TCP segmentu ) je potvrzeno úplné ukončení\nspojení. Tento segment již není potvrzován, proto strana zůstává ve stavu\nTIME_WAIT po dobu 2 minut (některé implementace TCP/IP zkracují tuto dobu až\nna 30 s).\nCLOSED – druhá strana obdržela potvrzení úplného uzavření spojení a přechází do\nstavu CLOSED. Strana, která odeslala toto potvrzení (segment) přechází do CLOSED\naž po uplynutí zmíněného intervalu.\nStavy při uzavírání spojení jsou dobře vidět na obrázku...\nVylepšení provozu TCP – sloučení dat a potvrzení (piggyback), technika okna (viz bible\nstrana 234), vyhnutí se zahlcení sítě a výpadku segmentu (jak, to je na slidech, ale já to teda\nnechápu...), nastavení správného timeoutu\nPřednáška 5 –Síťová vrstva –směrování\nSměrování provádí zařízení zvané směrovač. Zjednodušeně řečeno směrovač je zařízení, které\npředává IP-datagramy z jednoho svého rozhraní do jiného rozhraní. Směrovač umí předat IPdatagram i do téhož rozhraní, ze kterého IP-datagram přišel. Považuje to však ze výstřednost,\ntakže o tom odesílatele IP-datagramu upozorní ICMP-paketem „redirect”. („změň\nsměrování“). Směrovači k rozhodování slouží směrovací tabulka. Příklad takovéto tabulky je\nSměrovací tabulka má v prvním sloupci IP-adresu cílové sítě. Představme si pro\njednoduchost, že směrovací tabulka je podle prvního sloupce sestupně tříděna. To nám\numožní snadno aplikovat základní pravidlo směrování: Více specifická adresa cílové sítě má\npřednost před méně specifickou. Více specifickou adresou sítě se rozumí adresa, která má v\nsíťové masce více jedniček. V případě, že by se ve směrovací tabulce našly dvě či více cest k\ncíli, pak se zvolí více specifická cesta. V případě, že se najdou dvě stejně specifické cesty, pak\nse zvolí cesta s nejnižší metrikou (cenou). V případě, že jsou řádky směrovací tabulky\nsestupně tříděny, pak stačí směrovací tabulku procházet odshora dolů. Na každém řádku se\nvezme sí;ová maska, kterou se bit po bitu vynásobí IP-adresa příjemce IP-datagramu.\nVýsledek se porovná s prvním sloupcem. Pokud se výsledek nerovná IP-adrese sítě v prvním\nsloupci, pak se přejde na zpracování následujícího řádku. Pokud se výsledek shoduje s\nIPadresou v prvním sloupci, pak se ještě otestuje následující řádek, zdali ve směrovací tabulce\nneexistuje ještě k cíli jiná cesta, (pak by vstoupila do hry metrika). Poslední řádek obsahující\nv prvním sloupci 0.0.0.0 s maskou 0.0.0.0 se nazývá default. Tímto implicitním směrem jsou\npak odesílány všechny IP-datagramy, pro které nevyhovoval žádný jiný řádek směrovací\ntabulky (všimněte si, že vyhovuje každé IP-adrese: nula krát nula je nula). Implicitní směr ve\nsměrovací tabulce může a nemusí být – závisí to na správci, jak tabulku naplnil. Implicitní\nsměr používají např. firmy pro cestu do Internetu.\nZpůsoby přenosu dat:\n• přepojování kanálů – celý přenosový kanál je vyhrazen pro jednoho uživatele až do\n• přepojování zpráv – zpráva se posílá jako celek, nedělí se na pakety\n• přepojování paketů - umožňuje sdílení přenosového kanálu více uživateli - ihned po\nvyslání paketu se kanál uvolní a může tedy vysílat i jiný uživatel\n• virtuální kanál – Je vedený sítí a všechny pakety spojení prochází přes tento kanál. V\npřípadě, že se spojení někde přeruší, je vytvořen nový kanál a poté se mohou opět\npřenášet data...viz obr...\nJe to jakoby roura, kterou proudí data jedním šměrem, je vytvořena pospojováním\nsíťových elementů. Kanál má své identifikační číslo a přenášené datové jednotky jsou\ndo tohoto kanálu vloženy s jeho identifikačním číslem v záhlaví. Projdou pak\npomyslným virtuálním kanálem až k adresátovi. Výhodou tohoto přenosu je to, že\ndatové jednotky prochází všechny stejnou cestu se stejným zpožděním a ve stejném\npořadí, což u datagramové služby zajistit nelze. IP protokol virtuální kanály\nnepoužívá. (více na http://cag.csail.mit.edu/PSRG/papers/dally-ieee92.pdf)\n• datagramová služba - je obdoba klasické pošty, tedy datová jednotka je vložena do\npřístupového bodu sítě a má kompletní informace pro cestu k adresátovi.\nVirtuální kanály – propojovací tabulky – slide 4... v tabulce směrovače je pro každý kanál\njeden řádek, v řádku jsou uvedeny uzly, které kanál propojuje (ty jsou vždy jen 2 – kanál se\ntotiž nemůže rozdělit) a „vzdálenost“ k těmto uzlům.\nSměrovací metody: záplavové směrování, náhodné směrování, izolované směrování (buď\n„horký brambor“ nebo „zpětné učení“),statické směrování, adaptivní směrování(buď\n„distance vector“ nebo „link state“), hierarchické směrování\n• záplavové směrování – viz slide 6 – 11 – každý směrovač vyšle paket do všech směrů\nkromě toho směru (resp. „těch“ směrů, paket totiž může přijít ke směrovači i z více\nsměrů), z nějž paket přišel. Poté co se takto odešle, zjistí se nejkratší cesta\n(dijkstrovým algoritmem, protože síť je vlastně graf, že ano), přes niž bude probíhat\nsměrování. Negativem může být zahlcení sítě při zjišťování cesty, proto je potřeba\nnadbytečné pakety likvidovat. To se dá buď pomocí TTL, informace ve směrovači\nnebo informace v paketu.\n• náhodné směrování – odesílání paketu na náhodný výstup. Toto směrování, ale\nnezaručuje omezenou dobu doručení a potřebuje dodatečné informace.\n• horký brambor – odesílání paketu do nejkratší fronty (paketů). Stejně jako náhodné\nsměrování nezaručuje omezenou dobu doručení a potřebuje dodatečné informace.\n• zpětné učení – využívá informaci o času/počtu průchodů paketu směrovačem (tato\ninformace je uložena v paketu). Směrovač má pro tuto metodu tabulku, která\nobsahuje odesílatele, nejkratší čas a směr odkud paket přišel. Tuto metodu je nutno\nkombinovat s jinou metodou. Při nějaké chybě se metoda pomalu adaptuje.\nstatické směrování – prostě ručně nastavíme tabulky při návrhu sítě nebo při změně\njejí topologie. Nereaguje však na změnu topologie, nicméně jej můžeme využít\nnapříklad při nějakém výpadku síťových prvků. Nepodporuje rozdělení toku (řešením\nmůže být stochastické směrování). Jinak statické směrování se dá kombinovat s\nadaptivní směrování – opakovaný výpočet směrovacích tabulek při provozu sítě. Ten\nvýpočet může být buď centralizovaný nebo distribuovaný. Toto směrování závisí na\nmetrice, bezpečnosti,množství přenášené informace...Je možné jej kombinovat s\npředchozími metodami. Adaptivní směrování používá například „Distance vector\nalgoritmy“, kdy probíhá výměna kompletních směrovacích tabulek. To ale velmi\nzatěžuje síť a má to pomalou konvergenci (reakci na chyby), zvláště při výpadku.\nToto směrování používají protokoly RIP, IGRP, EIGRP, BGP\ndelta směrování - dohledat...\nprotokoly RVP – ve slidech označené jako distance vector\nProtokoly RVP (Routing Vector Protocols) pracují tak, že si sousední směrovače mezi sebou\nvyměňují obsahy směrovacích tabulek (vektorem se míní jedna položka směrovací tabulky).\nObdržím-li jednotlivé vektory ze směrovací tabulky svého souseda, pak si z nich mohu vybrat\nvektory, které ve vlastní směrovací tabulce nemám a doplnit je do vlastní směrovací tabulky.\nNesmím zapomenout u takto doplněné položky zvýšit metriku. Tyto protokoly jsou\njednoduché a snadno se implementují. Jejích nevýhodou je, že ve větších rozsáhlých sítích\nmůže výměna vektorů oscilovat a pak některé vzdálenější sítě mohou být chvilku dostupné a\nza okamžik již nikoliv. Většími sítěmi se rozumí sítě o více jak 10 LAN. Příkladem protokolů\nRVP jsou protokoly RIP a RIP 2. Jelikož jsou protokoly RVP vhodné pro menší rozsáhlé sítě,\npak je vždy otázkou, zda-li se bude konfigurace sítě opravdu natolik dynamicky měnit, nebo\nse sice pracněji, ale lépe nakonfigurují směrovače ručně pomocí statických položek.\nRouting Information Protocol. Jeho metrikou je počet směrovačů, přes které se jde k cíli.\nSpoléhá na komunikaci se sousedy, prostě si směrovače mezi sebou (pomocí bradcastů)\nvyměňují obsahy směrovacích tabulek. Při směrování je nalezena pouze jedna cesta (ta\nnejkratší) od odesílatele k cíli. Nevýhodou je, že v tomto protokolu není v položce směrovací\ntabulky uváděna síťová maska. Proto lze protokol RIP použít jen tehdy, když v síti používáme\npouze sítě se standardní maskou.\nVylepšením je RIP2, který pracuje navíc s maskou podsítě, požaduje autorizaci a podporuje\nmulticast. Docela dobré info o RIP je zde... ještě víc o RIP je ve sriptech na straně 91\nRIP výpočet (viz slidy 18-28): Tento algoritmus vytváří přímo routovací tabulky.Tabulky\nsměrovačů i uzlů obsahují identifikaci směrovačů (ve slidech písmenem) a vzdálenost k nim.\nPůvodně má v tabulce směrovač sám sebe a se vzdáleností 0. Takže, nyní:\n1) každý směrovač vyšle do všech směrů iformace o své tabulce. Ty informace co k\nněmu v „prvním kole“ dojdou identifikují bezprostředně okolní směrovače (tedy ty se\n2) Opakuje se bod 1 s tím, že nyní proudí již od každého směrovače informací (každý\nsměrovač pošle tzv. update) více. Podle toho si předělá ten který směrovač svou\ntabulku. Prostě například E ví, že mu B poslalo update, v němž je informace, že H je\nod B vzdálené o 1. Jelikož E ví, že B je od něj o 1, musí být H od B vzdálené o 2\n3) To se opakuje celkově tolikrát, kolikrát je to zapotřebí, prostě směrovače tu tam\nRIP – výpadek linky – může způsobit problém – dobře je to popsáno ve skriptech na str. 93.\nPodívejte se na obrázek...\nProblém je ten, že pokud vypadne ze sítě uzel A, uzly si postupně navyšují jeho vzdálenost\nDejme tomu, že situace na počátku je 0 1 2 3 4, Nyní se A čko je odpojí, takže vzdálenost B\nod A uvedená v tabulce B je neplatná, proto čeká na informaci od C, to mu pošle, že A je od\nněj vzdáleno o 2, proto si B zapíše do své tabulky vzdálenost 3, nyní proběhne další update:\nB pošle C to, že je od něj A vzdáleno o 3, C si zapíše 4...a vzdálenosti stoupají ... Aby si tuto\nvzdálenost nenavyšovaly donekonečna, je nutné zavést nějakou max hranici, po kterou se\nbude zvyšovat (tzv. nekonečno), tato hranice je u RIP stanovena na 16. Proto tedy trvá docela\ndlouho, než se RIP adaptuje na výpadek linky. Ze stanovení nekonečna také plyne to, že uzel\nse vzdáleností 16 a více je označen jako nedostupný.Naopak adaptace RIP na „dobré zprávy“\n(změna v síti) je rychlá.\nPro rychlejší adaptaci na „špatné zprávy“ lze zavést algoritmus split horizon (v našem\npříkladě to znamená, že uzel C vdálenost od A, kterou získal od B, béčku zpět nepředá, tzn. B\npřijme pouze aktualizace z jiného uzlu), dalším ztychlením je algoritmus reverse poisson( C\nbéčku předá vzdálenost od A rovnou jako nekonečno)\nLink State Protocols - Protokoly LSP pracují na zcela odlišném principu. Každý směrovač si\nzjistí, jaké směrovače má za své sousedy a v pravidelných intervalech testuje jejich\ndostupnost. Celou síť pak zaplavuje svými oběžníky o tom, koho má za své sousedy. Takže\nkaždý směrovač má od všech ostatních směrovačů zprávu o tom jaké mají sousedy. Takže\nkaždý směrovač má seznam všech cest v síti.\nNa tento seznam se pustí algoritmus nejkratší cesty, kterým se zjišťuje směr kam se má IPdatagram odeslat. Tj. položky směrovací tabulky se počítají algoritmem nejkratší cesty z dat\nobdržených od ostatních směrovačů. U rozsáhlých sítí je problematické zaplavovat je velkým\nmnožstvím informací ze směrovačů, proto se takové sítě rozdělí na oblasti a zmíněný postup\nse aplikuje pouze v rámci této oblasti. Na hranicích se sousedními oblastmi jsou hraniční\nsměrovače, které si pak vyměňují informace o celých oblastech.\nProtokoly LSP jsou oproti protokolům RVP nesrovnatelně stabilnější a lze je aplikovat i u\nvelmi rozsáhlých sítí. Nevýhodou je, že návrh sítě, tj. rozdělení sítě na oblasti musí provést\nzkušený odborník, rovněž konfigurace je netriviální. Pokud se použije protokol typu LSP bez\nvětších zkušeností, tak je také možné, že některými linkami data prostě nepotečou a jiné\nbudou přetížené. Příkladem protokolu LSP je třeba protokol OSPF.\nOpen Shortest Path First – dělí sítě na oblasti, kde každá oblast je očíslovaná (32 b číslem).\nOblast číslo 0 je tzv. páteř (backbone) Směrovače se rozdělí na interní, hraniční nebo páteřní\npodle toho, kde směrovač leží...viz obr. slide 46. Směrování probíhá buď uvnitř oblasti nebo\nmezi oblastmi (vždy přes oblast 0). Propojení sítí je buď přes autonomní systém nebo přes\nhraniční směrovač autonomního systému (viz slide 47/5). Algoritmus používá autorizaci\n(buď žádnou nebo jednoduchou nebo pomocí MD5).\nOSPF zprávy – jsou to LSA (Link State Advertisments) zprávy, tyto zprávy mohou být\nzasílány jen ve své oblasti (tedy ne mezi oblastmi). Typy paketů jsou: hello (pro testování a\nnestavení spojení), popis databáze (popis databáze stavů linek) , požadavek stavu linky\n(vyžádání konkrétní části databáze stavů linek), aktualizace stavu linky (LSA o lince\nsměrovače, o síťové lince...), potvrzení stavu linky (potvrzení příjmu paketu)\nOSPF metriky – automatické – automaticky vypočtené směrovači, nemusí být\nimplementovány, mohou se dynamicky měnit, cena je 100 000 000/šířka pásma [bps](??),\nimplicitní – jsou v celé síti stejné, jsou vhodné pro homogenní prostředí, manuální – jsou\nProtokoly IGP a EGP – ve slidech označené jako skupina exterior algoritmy\nProtokoly IGP jsou určeny pro činnost v rámci autonomního systému. Již zmíněné protokoly\nRIP, RIP2, OSPF jsou vesměs protokoly IGP.Ovšem poskytovatelé Internetu si mezi sebou\npotřebují také vyměňovat směrovací informace. Poskytovatelé Internetu pro výměnu\nsměrovacích informací mezi autonomními systémy používají protokoly EGP. V dnešní době\npoužívají protokol BGP (Border Gateway Protocol) verze 4.Protokoly EGP se liší od\nprotokolů IGP zejména tím, že ve směrování umožňují zohlednit směrovací politiku (tj. kdo\nAgregace - Agregace je proces, kdy se z několika položek směrovací tabulky udělá jedna\npoložka. Tento proces je žádoucí např. při propagaci sítí vně autonomního systému.\nJednu položku můžeme z více udělat tehdy, když sítě slučované do jedné položky vytvoří\nsupersíť. Automatická agregace je spíše přání než realita. Poskytovateli většinou vypadnou z\njeho supersítí některé adresy, které ještě nikomu nepřidělil, takže nelze automaticky agregovat\nvšechny IP-adresy autonomního systému do jedné nebo několika málo položek. Prakticky se\nagregace provede ručně tak, že se vně autonomního systému propagují všechny IP-adresy,\nkteré jsou přiděleny.\nRedistribuce - Na obrázku dole je otazníkem označen směrovač, který si vyměňuje současně\nsměrovací informace protokoly BGP, OSPF, RIP a k tomu možná má ve směrovací tabulce\nněkolik statických položek. Otázka je, zdali se mají informace (položky směrovací tabulky)\nzískané jedním směrovacím protokolem propagovat do ostatních směrovacích protokolů, tj.\nmá-li se provést redistribuce.\nZnamená to tedy vlastně to, že položka ve směrovací tabulce musí v sobě nést informaci,\njakým protokolem byla vytvořena\nBGP – Border Gateway Protocol – zajišťuje směrování a řízení provozu mezi autonomními\nsystémy, přiděluje autonomním systémům jednoznačné identifikátory. Používá Distance\nVector Algoritmus. Směrovače jsou propojeny pomocí TCP. Slouží k připojení zákazníků s\nvíce cestami do internetu. Obrázek jak to celé vypadá je na slidu 52 anebo se podívej na\nobrázek nahoře (myslím ten s AS1 a AS2).\nPřednáška 6 –QoS\nKvalita služeb – je to opatření snažící se zaručit koncovému uživateli doručení dat v potřebné\nkvalitě. Uplatňuje se u přenosu multimédií, IP telefonii atd. Kvalita služby je ovlivněna\nstanicemi (uživatelé a servery), směrovači, přepínači a linkami (mezi směrovači nebo na\nSdílení kapacity sítě – v jednoduché síti typu Internet se všichni uživatelé dělí o prostředky\nsítě stejným dílem (100 uživatelů a linka 100 Mbit/s -> 1 Mbit/s na každého), většinou není\nrychlost problém, některé aplikace (např. IP telefonie) nemusí fungovat.\nJaké jsou možnosti Qos v tomto případě?\n• Rezervovat přenosovou kapacitu jen pro daný kanál\n• Nastavit vyšší prioritu některým službám a zkrátit jejich odezvu\n• Omezit přenos na definovaný limit (např. omezení FTP tak, aby bylo možno při tom\n• Definovat maximální zpoždění dat - vemte si například, že sledujete video – tam je\nžádoucí, aby zpoždění dat bylo minimální, naopak u HTTP nějaké to zpoždění moc\nPříklad sítě bez a s QoS: bez: slide 5 – tok se dělí rovnoměrně mezi kompy, s: slide 6 –\nkomunikace mezi 2 počítači si žádá tok 1 Mbps. Tak jim ji dáme a ostatním rozdělíme ten\nParametry tvořící QoS: šířka pásma (= rychlost přenosu dat), jednosměrné zpoždění (tzn.\nčas potřebný pro přenesení paketu přes fyzické médium, což zahrnuje i čas způsobený\nřazením paketů do front), rozptyl zpoždění (to jak zpoždění kolísá), ztrátovost paketů. K tomu\naby to celé funcovalo co nejlépe, je nutno zavést nějaké...\n...Plánovací mechanismy: FIFO, prioritní FIFO, Round Robin, WFQ, Leaky Bucket, Leaky\nBucket + WFQ... popis:\n• FIFO – slide 9 – pakety přicházejí ve frontě a postupně jsou obslouženy\n• Prioritní FIFO – slide 10 nebo obrázek...\npakety jsou ukládány jak do fronty, tak do prioritní fronty. Pakety z prioritní fronty\nmají vždy přednost...viz zde\nRound Robin – dejme tomu že máme dvě fronty – jednu prioritní a druhou ostatní.\nPakety se obsluhují postupně tak, jak přicházejí, ale pokud příjde najednou paket z\nfronty ostatních a z prioritní fronty, má přednost ten z té prioritní. (tady ovšem moc\nnechápu jeký je rozdíl oproti prioritní FIFO)\nWFQ – weighted fair queuing – každý datový tok má svoji frontu, každá tato fronta\nmá svou váhu. Tyto fronty jsou obsluhovány současně tak, aby se na každou dostalo,\nale samozřejmě prvků s nejvyšší váhou jde k obsluze asi nejvíc... viz obr.\nLeaky Bucket – neboli děravý kýbl – viz zde nebo viz obrázek... na tomto obrázku jsou\novšem pakety na které nezbyly tokeny, zahozeny. Podotýkám, že tomu tak nemusí být,\npakety mohou třeba jen čekat (sice se tím způsobí nějaké zpoždění, ale pokud to neva,\ntak co). To co je na obrázku bych viděl jako Leaky Bucket pro UDP\nTak, nyní k principu. Zásobník má nějaký maximální počet tokenů, který jej může\nnaplnit. Tokeny přibývají rychlostí x tokenů za sekundu. Do té doby, než se zásobník\nnaplní, příchozí pakety čekají. Poté co se naplní, jsou pakety odeslány po řadě\nmaximální možnou rychlosí do sítě (tu rychlost označme B) a zásobník se vyprazdňuje\nrychlostí Bt (t=čas). Poté co se zásobník tokenů vyprázdní, nezbývá dalším paketům\nčekat, než se opět naplní.\nLeaky Bucket + WFQ – máme n front (označených váhou), přičemž každá obsahuje v\nsobě navíci Leaky Bucket ... viz slide 14\nCo říká na QoS IP Protokol? IP protokol má v hlavičče informační pole ToS (Type of\nService), jehož hodnoty znamenají toto:\nminimalizuj finanční náklady\nToS v aplikacích - ... viz slide 16, tam je napsané, pro jaké aplikace se používají jaká\nnastavení ToS. Např. pro telnet je to 1000 (minimalizacee zpoždění), pro ftpdata je to 0100\n(maximalizuj propustnost)... je to celkem logické nastavení nebo ne?...\nTCP protokol a řízení toku\nEfektivně lze omezovat pouze odchozí tok dat, pro příchozí musíme použít nepřímé metody.\nMůžeme například pozdržet odeslání potvrzení a tím prodloužit RTT (Round Trip Time – co\nto je viz dále ), ale pozor na timeout, který by po vypršení způsobil opětovné odeslání dat.\nDále můžeme měnit velikost okénka.\nRTT v TCP – Zpoždění je čas, který uplyne od odeslání zprávy zdrojovým uzlem po její\npřijetí na uzlu cílovém. Zahrnuje zpoždění v přenosové trase a na zařízeních, které jsou její\nsoučástí. Je nutné rozlišit zpoždění jednosměrné (čas mezi odesláním paketu zdrojem a jeho\npřijetí cílem) a zpoždění obousměrné, tzv. round-trip latency, zahrnující dobu cesty paketu\ntam i zpět plus čas jeho zpracování cílem. Round-trip latency nebo také Round Trip Time\n(RTT) se v síťové praxi požívá nejčastěji, protože jej lze změřit z jednoho místa (uzlu).\nOd RTT se odvozuje timeout. Jenže...jak dopředu zjistit hodnotu RTT? Mějme SampleRTT =\nposledně naměřený RTT, EstimatedRTT = očekávaný RTT. Pak platí:\nEstimatedRTT = (1 − α ) ⋅ EstimatedRTT + α ⋅ SampleRTT kde α = 0,125\nPěkný graf na SampleRTT a EstimatedRTT je na slidu č.19.\nTCP Timeout – jak se odvozuje od RTT?\nDevRTT = (1 − β ) ⋅ DevRTT + β ⋅ ( SampleRTT − EstimatedRTT ) kde β = 0, 25\nDevRTT popisuje proměnlivost RTT. Nyní konečně ten vzoreček pro timeout:\nTimeout = EstimatedRTT + 4 ⋅ DevRTT ... timeout se po každé ztrátě paketu zdvojnásobí\nTCP technika okna - Nyní je naším problémem případ, kdy klient potřebuje odeslat velké\nmnožství dat. Klient (resp. Server) může odesílat data druhé straně aniž by jejich příjem měl\npotvrzen až do tzv. okna (Window – zkratkou WIN). Představme si (viz obrázek), že klient se\nserverem navázal spojení a vzájemně se dohodli na maximální velikosti segmentu (MSS) o\nvelikosti 1 K (tj. 1024 B) a vzájemné velikosti okna 4 K (tj. 4096 B).\nKlient začne s odesíláním dat, odešle segmenty 1, 2 a 3. Poté obdrží od serveru potvrzení (4),\nkteré potvrzuje segmenty 1 a 2. Klient v zápětí odesílá segmenty 5, 6 a 7. Jenže server data\nmezitím nedokázal zpracovat a data mu zaplnila vyrovnávací pamě;, proto segmentem 8 sice\npotvrdí příjem segmentů 3, 5, 6 a 7, ale zároveň klientovi uzavře okno, tj. klient nemůže s\nodesíláním dat pokračovat. Poté co server zpracuje část dat (2 KB), tak umožní klientovi\npokračovat v odesílání, ale neotevře mu segmentem 9 okno celé – pouze 2 KB, protože\nvšechna data ve vyrovnávací paměti ještě nezpracoval a pro více dat nemá místo.\nProzkoumejme na obr. 9.16 jak vidí klient okno po přijetí segmentu 4...\nPrvní 2 KB jsou již potvrzeny, okno je tedy posunuto za bajt 2048. Tato potvrzená data již\nklient nemusí udržovat v paměti. Odeslaná, ale nepotvrzená data (segment 3) tvoří 1 KB.\nKlient může tedy odeslat bez dalšího potvrzení 3 KB dat.\nIPv6 a QoS – QoS v dnešním internetu funguje nepovinně, je jen jeho částech. Zajištění QoS\nmezi jednotlivými uživateli je tedy obtížné, IPv6 by měl tento nedostatek odstranit, protože\nmá v hlavičce nová pole definující způsob zpracování a identifikace informací přenášených v\nPřednáška 7a) – Propojování sítí\nPropojování sítí – sítě se propojují s různými topologiemi a operačními systémy. Tím se\nvytvářejí „internety“. Největším „internetem“ je Internet (:-)). K propojení sítí můžeme použít\nopakovač(repeater, hub), most(bridge), přepínač(switch), směrovač(router) nebo přenosovou\nbránu(geteway). Některé tyto prvky použijeme i pro zlepšení spojení v rámci sítě LAN.\nOpakovač – Opakovač je tvořen dvěma nebo více síťovými kartami, které jsou vzájemně\npropojeny. Objeví-li se nějaký datový rámec na jednom rozhraní,pak je automaticky\nzopakován na všechny ostatní. Opakovačslouží pro překonání problému útlumu signálu (čím\nvětší vzdálenost signál urazí, tím je slabší). Tento útlum je následkem odporu a šumu.\nOpakovač vstupní signál vyčistí a zesílí, tím se prodlouží možná vzdálenost mezi\nkomunikujícími uzly (viz slide 3). Opakovač pro krocenou dvojlinku se označuje jako HUB.\nPrincip opakovače: Pracuje na úrovni bitů, nemá žádnou vyrovnávací paměť, může\npropojovat libovolný počet segmentů sítě, může propojovat pouze segmenty sítě se stejnou\npřenosovou rychlostí. Opakovač musí šířit kolize. V ethernetu jich nemůže být libovolně\nmnoho kvůli době šíření kolize (kolize je, když vysílá více zdrojů na jedno médium současně,\nsignál je znehodnocen, k odstranění kolizí slouží CSMA/CD – co to je zde nebo bible strana\n117) – proto mohou být mezi každými 2 body max 2 opakovače .\nFiltrování opakovače – Opakovače šíří do všech směrů i to, co by šířit nemusely.Chtělo by\nto nějaké filtrování provozu, což znamená, aby opakovač dokázal „rozumět“ alespoň adresám\nlinkové vrstvy. Pokud by se zařízení rozhodovalo podle obsahu paketu, zda poslat, či ne,\nmuselo by mít nějakou vyrovnávací paměť. Tím pádem by šlo propojit segmenty s různými\nMost (bridge) – je to jednotka, která řídí mezi sítěmi přepojování paketů z jedné sítě do\ndruhé. Nešíří tedy paket do všech připojených segmentů sítě. Zlepšuje spolehlivost a\nbezpečnost sítí. Most pracuje na linkové vrstvě, nemusí propagovat kolize (má vyrovnávací\npaměť). Most propojuje právě 2 sítě. Varianta „vzdálený půlmost“ znamená, že jsou spolu\npropojeny 2 mosty a přes ně se propojují sítě (viz slide 7). Více o mostu je tady nebo raději v\nbibli na straně 115.\nPřepínač (switch) – jedná se o víceportový most, je novější, rychlejší a je to jeden z\nnejpoužívanějších aktivních síťových prvků. Switch nepropaguje kolize (má vlastní\nvyrovávací paměť), všesměrově šíří pouze bradcasty a často se používá jako náhrada\nopakovače. Přes jeden přepínač může probíhat více přenosů až do maximální kapacity\npřepínače. Přepínačem se označují výkonnější mosty, které umí opakovat rámce nejen mezi\njednotlivými segmenty Ethernetu, ale i např. mezi Ethernetem a Fast Ethernetem, mezi\nEthernetem a FDDI atd. Přepínač musí umět nejenom změnit tvar rámce např. z Ethernetu na\nFDDI, ale i pokusit se překlenout rozdíl mezi přenosovými rychlostmi. Problém je totiž při\npřenosu dat mezi rychlým segmentem (FDDI) a např. Ethernetem, kdy z FDDI může\nsměrovat na Ethernet takové množství dat, že je Ethernet nedokáže odebírat.Rámce se musí\nukládat do vyrovnávací paměti přepínače atd.\nPřepínač – filtrace – aby mohl přepínač filtrovat (tzn. neposílat příchozí pakety na všechny\nsvé výstupy, ale jen tam, kam skutečně patří, resp. pokud tam nepatří, tak je zahodit), musí\nznát topologii sítě, tzn. na jakém portu (zde nemyslíme samozřejmě port v soketech, ale\nsíťový port) je která stanice. Pokud přepínač topologii nezná, chová se podobně jako\nopakovač (hub). Tu topologii můžeme na přepínači nastavit buď ručně (ale to je pracné,\nprotože síť se může často měnit) nebo ho nechat, ať si to zjistí sám zpětným učením. To\nprobíhá tak, že nejdříve se přepínač chová jako opakovač (vysílá pakety na všechny strany a\ndostává odpovědi, ze kterých se učí) a učí se (ukládá si do své tabulky dvojici port, adresa\n(MAC)) a po určité době začne filtrovat provoz.\nPřepínač – dále... může buď celý rámec příjmout, analyzovat a poté odeslat (metoda store\nand forward) nebo může přečíst pouze cílovou adresu a zbytek již rovnou odesílat (metoda cut\nthrough) nebo může kombinovat obě metody.\nUčení přepínače – viz slide 11-13 ... přepínač dostane rámec o kterém neví, do kterého portu\njej má odeslat. Pošle jej tedy do všech portů, kromě toho, ze kterého přišel a upraví tabulku.\nPokud přepínač již má stanovenou tabulku a dostane nějaký rámec nyní, pošle jej na port,\nkterý odpovídá adrese v tabulce. Pokud přepínač dostane paket, jehož příjemcem má být\nzároveň jeho odesílatel, přepínač tento paket ignoruje. Učení přepínače nebude fungovat,\npokud graf sítě bude obsahovat nějakou kružnici (smyčku). Přepínače se ale umí domluvit a\nvzniklou smyčku přerušit. Ta kružnice ale může být v síti úmyslně např. jako záloha spojení.\nCo když takovouto kružnici přepínače zruší? To by nebylo dobré... proto máme šikovný\nSpanning Tree Algorithm – Je to algoritmus, který najde kostru grafu sítě a přeruší tak\npřípadné kružnice (tak že zablokuje některé porty směrovačů). Tím se zachová stromová\nstruktura. Pokud by náhodou došlo k nějakému výpadku, zablokované porty se opět uvolní.\nTento algoritmus podporují všechny moderní přepínače. Tak nyní k tomu, jak to funguje\n(animace spanning tree ) ...\nSpannning Tree Algorithm – princip –\n1. nejdříve se zvolí „kořenový přepínač“ (root switch), bude to ten s nejmenší MAC\nadresou. Na začatku (toho zvolení kořenu) bude každý přepínač tvrdit, že je root,\npokud neví o jiném přepínači. Postupně si přepínače rozesílají broadcastem BPDU\nzprávy (Bridge Protocol Data Units – viz zde) a na kořenovém řepínači se dohodnou\n2. Po tom zvolení si každý přepínač,co není rootem, zvolí jeden root port – to je port\ntohoto přepínače na nejkratší cestě (metrikou je cena,ne jen počet hopů, záleží také na\nrychlosti linek) ke kořeni .\n3. Poté se na každém segmentu sítě (segment = linka propojující switche, která je\nsoučástí kostry grafu) zvolí vyhrazený přepínač (to je ten, jež má nejlepší cestu ke\nkořenovému přepínači) a jeho port s touto cenou bude vyhrazený (designated) port.\nDocela dobře je to vyobrazeno na obrázku se slidů...\n4. Porty přepínačů, které nepatří ke kostře grafu, se přepnou do blokujícíh o stavu. Root i\ndesignated porty jsou vždy ve stavu forwarding.\nVíce o spanning tree slidy 19 – 21 a taky zde.\nStavů portů může být celkem 5: blocking (neprocházejí jím rámce, je to záložní port, pouze\npřijímá BPDU a hledá root switch), listening(slouží k příjmu a vysílání BPDU (ne rámců),\nbuduje kostru sítě), learning(neprocházejí jím rámce, učí se MAC ostatních a přijímá BPDU),\nforwarding (procházejí jím rámce, předává BPDU, zkrátka plně funkční port), disabled.\nDále ke Spanning Tree – jeho konvergence při změně topologie sítě trvá implicitně 50\nsekund (20 + 15 + 15...viz slide 22). Existuje protokol Rapid Spanning Tree, který slučuje\nstavy blocking,disabled a listening do jednoho stavu – discarted. Tento Rapid Spanning Tree\nnemusí díky aktivnímu potvrzování čekat na timeouty.\nSměrovač – Router – pracuje na síťové vrstvě (potřebuje IP adresu), propojuje sítě a pracuje\nse síťovými adresami. Nešíří broadcasty z jedné sítě do druhé. Pojem směrovače je nezávislý\nna stroji a OS (může to být krabička běžící na linuxu, nebo i počítač s Windows). Směrovač\npřenáší data i mezi sítěmi, které používají naprosto odlišné technologie, směrovače jsou tedy\npro internet nezbytné. Kromě směrování může směrovač podporovat i další funkce (firewall,\nNAT, VPN). Směrování může být statické nebo dynamické (např. RIP, OSPF...) Schopnost\npředávat datové pakety mezi sí;ovými rozhraními směrovače se nazývá jako předávání\n(forwarding). Zatímco u směrovačů je tato funkce požadována, tak u počítačů s klasickým\noperačním systémem (UNIX, OpenVMS, NT apod.) je někdy dotazováno, jak přinutit jádro\noperačního systému předávání zakázat. Na každém rozhraní směrovače může být použit jiný\nlinkový protokol, na jednom např. Ethernet a na druhém např. HDLC.\nPřepínače na vyšších vrstvách – dnešní přepínače podporují QoS, VLAN a další funkce,\npodporují různé verze Spanning Tree Algorimů. Umí filtrování rámců na různých vrstvách:\nlinková, síťová(Layer 3 switch – filtrování IP adres a IP protokolu, je to vlastně HW\noptimalizovaný směrovač), transportní (Layer 4 switch – filtruje na úrovni portů TCP a UDP\na umožňuje rozlišovat provoz), aplikační(Layer7 switch – slouží k rozložení zátěže na více\nserverů, které se navenek budou takhle tvářit jako 1 server)\nBrána – přenosová brána je obecný termín, brána může znamenat:\n• aplikační bránu – např. software pro poštovní aplikace, proxy WWW server atd.\n• bránu pro překlad protokolů z jedné množiny protokolů do druhé\nPřednáška 7b) – Protokol SCTP\nSCTP – Stream Control Transmission Protocol – jedná se o komnikační protokol transportní\nvrstvy (tedy něco jako TCP), byl původně navržen pro telefonní signalizaci po IP. Odstraňuje\nnedostatky TCP a propůjčuje si některé vlastnosti UDP. V současnosti je podporován v\nLinuxu , Free BSD, MacOS, Solarisu ... , tedy skoro všem kromě Windows.\nVlastnosti SCTP – po navázání spojení můžeme komunikovat ve více streamech najednou. V\nrámci každého proudu (streamu) protokol garantuje doručení dat ve správném pořadí (tedy\njako TCP, ale více streamů), případný výpadek v jednom streamu neovlivní ostatní streamy.\nSCTP lze tedy přirovnat ke svazku spojení TCP, ale má menší režii a několik vylepšení.\nFormát SCTP – paket začíná univerzální hlavičkou (zdrojový + cílový port, ověřovací\nznačka, kontrolní součet), následují tzv. kousky (chunks), které obsahují řídící informace či\ndata pro jednotlivé proudy (typ, příznaky, délku, další hlavičky a data...). Počet nebo struktura\ntěchto kousků nejsou pevně dány. Formát SCTP paketu je na obrázku.\nJak probíhá u SCTP potvrzování dat? – Citelné změny v porovnání s TCP zaznamenalo\npotvrzování. SCTP k němu využívá pořadová čísla (jak také jinak), která zde najdete na dvou\núrovních: Transmission Sequence Number (TSN) slouží k číslování jednotlivých datových\nkousků (na úrovni asociace), zatímco Stream Sequence Number (SSN) určuje číslování v\nrámci jednoho konkrétního proudu.Hlavní předností potvrzování v SCTP je, že dokáže ohlásit\nchybějící kusy dat. Slouží k tomu speciální kousek nazvaný selektivní potvrzení. Ten\nobsahuje nejvyšší pořadové číslo přijatého datového kousku a zároveň vyjmenovává chybějící\núseky dat. Díky tomu je odesilatel přesně informován, která data dorazila a která ne. Navíc\npokud vysílající dostane čtyři potvrzení ohlašující stejnou díru v datech, na nic nečeká a\nchybějící část rovnou pošle znovu (tzv. rychlé opakování).\nMulti Homing – komunikující stanice má několik IP adres, během komunikace je vybrána\njedna brána jako privátní a z ní jsou odesílána data. Pro opakování je vybrána jiná brána.\nPokud jsou s komunikací přes primární bránu větší problémy, přejde se kompletně na jinou\nbránu. SCTP monitoruje všechny cesty a udržuje si přehled o jejich stavu ... více o\nmutlihomingu je zde\nIniciace spojení SCTP – oproti TCP se posílá cookie – SCTP má 4 cestný handshake – init,\ninit-ack,cookie-echo,cookie-ack. Viz slide 8.\nFormátování do zpráv – SCTP garantuje, že příjemce dostane zprávy rozdělené tak, jak je\nodesílatel odeslal (podobně jako UDP – to taky posílá data po kouscích – vzpomeň na sliding\nwindow, oproti tomu TCP odesílá se chová v podstatě jako proud bitů – zprávy nejsou nijak\nUkončení spojení SCTP – oproti TCP uzavřou všechny stanice spojení najednou – viz slide\nBudoucnost SCTP – jedná se o velmi mladý protokol (RFC z roku 2000), je velmi vhodný\npro běžné služby jako je FTP a HTTP. Zatím se čeká na podporu SCTP ve Widows a taky ve\nsměrovačích. Pak to příjde a to nezachápeš, woe! více zde\nPřednáška 8 – Jmenné služby\nObsah přednášky - úloha jmenných služeb, informace ve jmenných službách, jmenné\nslužby X.500, DNS a jiné\nÚloha jmenných služeb – je to specalizovaná databáze optimalizovaná pro čtení a\nvyhledávání – něco jako adresář. Provádí se v ní překlad, lokalizace, ověření a poskytování\nJmenné služby: je jich více druhů, jako příklad jmenujme X.500, LDAP, DNS (Domain\nName System), NIS (Network Information System), CDS (Cell Directory Service), Active\nX.500 – je to skupina protokolů pro elektronické adresářové služby .Vznik v roce 1988, je to\nhierarchický jmenný prostor, pracuje na principu komunikace klient – server.\nKoncept X.500 je ten, že je to jedna hierarchická struktura – tzv. Adresářový informační\nstrom. Hierarchická organizace položek tohoto stromu je samozřejmě obhospodařována více\nservery. Jenda položka se skládá ze seznamu atributů, každý z těhto atributů má jednu nebo\nX.500 – organizace dat – záznam se zkládá z jedinečného jména, jedinečného jména a\natributů. Toto jedninečné jméno se skládá jednak z relativního jedinečného jména položky a\njednak z položek umístěných v Adresářovém stromě hierarchicky nad touto položkou v cestě\nke kořeni. Takže je to, jak psal Kubr, vlastně posloupnost relativních jedinečných jmen od\nkořene. Relativní jedinečné jméno je dejme tomu něco jako název položky. Berte to jako\nsystém adresářů v počítači – jedinečné jméno by byla kompletní cesta k adresáři (např.\nC:\_programy\_Kuba\_PKO) a relativní jedinečné jméno by byla relativní cesta k adresáři (jen\nPKO). Atributy jsou prostě jen už informace o položce – viz obrázek...\nNa obrázku je jedna položka stromu. Jedinečným jménem je celý první řádek, relativním\njedinečným jménem je to “cn”. Zbytek jsou atributy.\nAtributy mohou být třeba tyto: C (Country), SP (State or Province), L (Locality), O\n(Organisation), OU (Organisation Unit), CN (Common Name). Příkladem může být např.\nzáznam: CN = atm.felk.cvut.cz, OU=FELK, O=CVUT,C=CZ ...nebo...\nCN = Jan Kubr, C= CZ\nX.500 využívá pro přístup k položkám protokoly DAP (Directory Access Protocol, je to\nprorokol OSI) a LDAP (Lightweight Directory Access Control Protocol).\nProtokol LDAP – funkce – dotazování a prohledávání (operace search a compare), změny\ndat (operace add, delete a modify), autentizace (operace bind a unbind). Více o LDAP je na\nShrnutí: X.500 využívá decentralizovaný, jednotný globální prostor, podporuje složité dotazy\ni autentizaci. Více o X.500 je na http://en.wikipedia.org/wiki/X.500\nDNS... Domain Name System\nVazba mezi jménem počítače a IP adresou je definována v DNS databázi. DNS (Domain\nName System)je celosvětově distribuovaná databáze. Jednotlivé části této databáze jsou\numístěny na tzv. name serverech. Chci-li se přihlásit na uzel info.pvt.net s IP adresou\n194.149.104.203, použiji příkaz: telnet info.pvt.net. Ještě předtím, než se vlastní příkaz\nprovede, přeloží se DNS jméno info.pvt.net na IP adresu a teprve poté se provede příkaz:\nDomény a subdomény - Celý Internet je rozdělen do tzv. domén, tj. skupin jmen, která k\nsobě logicky patří. Domény specifikují, patří-li jména jedné firmě, jedné zemi apod. V rámci\ndomény je možné vytvářet podskupiny, tzv. subdomény, např. doméně firmy lze vytvořit\nsubdomény pro oddělení. Doménové jméno odráží příslušnost uzlu do skupiny a podskupiny.\nKaždá skupina má přižazeno jméno. Z jednotlivých jmen skupin je pak složeno doménové\njméno uzlu. Např. uzel se jménem jakub.firma.cz je uzel se jménem jakub v subdoméně\nfirma domény cz.\nReverzní domény - Již jsme uvedli, že komunikace mezi uzly probíhá na základě IP adres,\nnikoli doménových jmen. Některé aplikace naopak potřebují k IP-adrese nalézt jméno, tj.\nnalézt tzv. reverzní záznam. Jedná se tedy o překlad IP-adresy na doménové jméno. Tento\npřeklad se často nazývá zpětným (reverzním) překladem. Podobně jako domény tvoří i IPadresy stromovou strukturu. Domény tvořené IP-adresami se pak často nazývají reverzní\ndomény. Pro účely reverzního překladu byla definována pseudodoména „inaddr.arpa“. Jméno\ntéto pseudo domény má historický původ, jde o zkratku „inverse addresses in theArpanet“.\nPod doménou in-addr.arpa jsou domény jmenující se jako první číslo z IP-adresy sítě. Např.\nsíť 194.149.101.0 patří do domény 194.in-addr.arpa. Sí_ 172.17 patří do domény 172.inaddr.arpa. Dále doména 172.in-addr.arpa se dělí na subdomény, takže sí_ 172.17 tvoří\nsubdoménu 17.172.in-addr.arpa. Je-li sí_ 172.17 rozdělena pomocí sí_ové masky na subsítě,\npak každá subsí_ tvoří ještě vlastní subdoménu. Všimněte si, že domény jsou zde tvořeny\njakoby IP-adresami sítí psanými ale pozpátku. Např. Reverzní doména pro subsíť\n194.149.150.16/28 je 16.150.149.194.in-addr.arpa\nZóna - Zóna je část prostoru jmen, kterou obhospodařuje jeden name server. viz obrázek\nTakže doména pvtnet.cz obsahuje v sobě všechny subdomény, ale zóna pvtnet.cz delegovala\nna jiné name servery pravomoci na zóny brn.pvtnet.cz, plz.pvtnet.cz a ova.pvtnet.cz. Takže\nzóna pvtnet.cz obsahuje doménu pvtnet.cz až na tři uvedené výjimky.\nDoména vs. autonomní systém - Autonomní systémy dělí Internet z hlediska IP-adres\n(směrování), naproti tomu domény dělí Internet z hlediska jmen počítačů...viz obrázek\nJiná je situace u reverzních domén, které kopírují strukturu poskytovatelů Internetu.\nDNS dotazy a odpovědi - Přeložení jména na IP-adresu zprostředkovává tzv. resolver.\nResolver je klient, který se dotazuje name serveru. Jelikož je databáze celosvětově\ndistribuována, nemusí nejbližší name server znát odpověď, proto může tento name server\npožádat o pomoc další name servery. Získaný překlad pak name server vrátí jako odpověď\nresolveru. Veškerá komunikace se skládá z dotazů a odpovědí.\nRekurzivní dotaz a odpověď - Resolver předává všechny dotazy na lokální name server. Od\nname serveru pak očekává konečnou (rekurzivní) odpověď. Name server buď odpoví přímo,\nnebo sám kontaktuje další name servery - prostě spustí standardní algoritmus pro vyhledání\nodpovědi (tj. začne u kořenových DNS serverů a postupuje do nižších úrovní až k cíli), tj.\nname server rekurzivně řeší dotaz a klientovi zašle až výsledek. Vypadá to tak, jak to ukazuje\nDNS komunikace - DNS používá jak protokol UDP, tak i protokol TCP. Pro oba protokoly\npoužívají port 53 (tj. porty 53/udp a 53/tcp). Běžné dotazy, jako je překlad jména na IP-adresu\na naopak, se provádějí přes protokol UDP. Délka přenášených dat protokolem UDP je\nimplicitně omezena na 512 B (příznakem truncation může být signalizováno, že se odpověď\nnevešla do 512 B a pro přídanou kompletní odpověď je nutné použít protokol TCP). Délka\nUDP paketu je omezena na 512 B, protože u větších IP-datagramů by mohlo dojít k\nfragmentaci. Fragmentaci UDP datagramu DNS nepovažuje za rozumnou.\nZe slidů...neboli +/- to samé ve zkratce\nDNS je systém primárně určen pro překlad mezi doméovými jmény a adresami, vychází z\nhosts.txt (lokální soubor v počítači, kde jsou položky typu “jméno” – “IP adresa” – většinou\nse při pokusu o překlad doménového jména na IP počítač podívá najdříve do něj a až potom\nžádá o pomoc DNS ). DNS shromažďuje v tabulkách tyto informace:\nA (32b IP adresa), NS (autoritativní jmenný server), CNAME (synonymum ke jménu), SOA\n(start of authority), PTR (reverzní překlad), HINFO (popis SW a HW), MX (preference a\njméno mail serveru), TXT (textový řetězec), AAAA (128b IP adresa ). více o DNS je zde\n• jmenný prostor a zdrojové záznamy – jmenný prostor má strukturu stromu, jméno má\nvelikost 0-63 B, celkově až 255 B. Jména se dělí na absolutní (atm.felk.cvut.cz) a\n• jmenné servery – jsou to datové sklady vytvářející jmennou databázi. Tyto servery\nodpovídají na dotazy, synchronizují databázi a udržují mezipaměť odpovědí (nějakou\nCache na časté dotazy)\n• resolvery – je to soustava knihovních funkcích zajišťujících překlad. Je součástí\nklienta i DNS serveru.\nStrom DNS domén – struktura je hierarchická, jak poznáme jednak z názvů stránek na webu\na taky ze slidu 10. Strom reverzních domén DNS můžeme vidět na slidu 11.\nTypy serverů DNS:\n• primární –udržuje data o své zóně v databázích na disku. Pouze na primárním Name\nServeru má smysl editovat tyto databáze\n• sekundární – kopíruje si databáze v pravidelných intervalech z primárního serveru.\nPrimární i sekundární Name Servery jsou tzv. autoritou pro své zóny, tj. jejich data o\nzóně se považují za nezvratná (autoritativní)\n• caching only – není pro žádnou doménu ani primárním ani sekundárním Name\nServerem avšak využívá obecné vlastnosti name serveru, tj. data, která jím prochází ,\nukládá do své paměti. Každý server je Caching server, ale souslovím Caching Only\nzdůrazňujeme, že není pro žádnou zónu ani primárním ani sekundárním Name\n• root – je Name Server obsahující root doménu. Každý root server je primární server.\n• forwarding – předává rekurzivní dotaz (odlehčení linky), může sám resolvovat\n• slave - umí jen forwarding\nVěty RR - Informace o doménových jménech a jim příslušejících IP adresách, stejně tak jako\nvšechny ostatní informace distrubuované pomocí DNS, jsou uloženy v paměti DNS serverů\nve tvaru zdrojových vět (Resource Records – RR). Name server naplňuje svou paměť\nněkolika způsoby. Autoritativní data načte ze souborů na disku, nebo je získá pomocí dotazu\nzone transfer z paměti jiného serveru. Neautoritativní data získává postupně z paměti jiných\nserverů, tak jak vyřizuje jednotlivé DNS dotazy. V případě, že DNS klient (resolver)\npotřebuje získat informace z DNS, pak požaduje po name serveru věty RR podle zadaných\npožadavků. Klient může např. požadovat po serveru věty RR typu A, které obsahují IP adresy\npro dané doménové jméno apod.Všechny věty RR mají stejnou strukturu. Struktura RR věty\nje znázorněna na obr.\nPopis jednotlivých polí vět RR:\n• NAME – doménové jméno\n• TYPE – typ věty\n• CLASS – třída věty\n• TTL – Time to Live. 32bitové číslo udávající dobu, po kterou může být tento RR\nudržován v cache serveru jako platný. Po vypršení této doby musí být věta\npovažována za neplatnou. Hodnota 0 zabraňuje neautoritativním serverům uložit RR\nvětu do cache.\n• RDLENGTH – 16 bitové číslo specifikující délku pole RDATA\n• RDATA – vlastní data ve tvaru řetězce proměnné délky. Formát tohoto pole závisí na\ntypu a třídě RR\nNa následujícím obrázku jsou příklady nejčastějších typů vět RR:\nDNS komunikace – probíhá přes protokol TCP i UDP na portu 53, u UDP je povoleno\npřenést jen max 512B(?? opravdu ??). Dotaz se posílá na více serverů, první odpověď je\nplatná, ostatní se zahodí. Je tu možnost jisté nekonzistence name serverů. DNS dotaz a DNS\nodpověď jsou rekurzivní. DNS update je podpora pro ddns (??), informace o zóně,\npředpoklady, update. DNS komunikace podporuje pozitivní i negativní caching, umožňuje\nnotify –což je předání informací sekundárním DNS serverům o změně, replikaci primárního\nserveru a autentizaci.\nDNS dotaz – může být zodpovězen autoritativně i neautoritativně, pokud server nezná\nodpověď obrátí se na root servery a potom postupuje směrem k subdoménám podle záznamů.\nMůže být vyžadován UDP checksum a odpověď může být omezena na velikost 512B.\nObsahem odpovědi je i doba platnosti (asi té odpovědi).\nKombinace služeb – integrace různých služeb v distribuovaném prostředí, kombinace\njmenné služby s portmapem (co to je?). DCE RPC, SUN RPC, JAVA RMI\nPřednáška 9 – Bezpečnost v počítačových sítích\nOsnova přenášky: základní pojmy, typy šífer, autentizace, integrita, distribuce klíčů,\nfirewally, typy útoků, zabezpečení aplikací\nZákladní pojmy síťové bezpečnosti: pro utajení přenášených dat se používá šifrování a\ndešifrování, pro ověření totožnosti odesílaele a příjemce se používá autentizace, dále budeme\nv předášce probírat integritu a neporiatelnost, dostupnost a řízení přístupu, detekci útoků a\nPrincipy kryptografie – kryptovat se začalo už za Caesara, moderní techniky šifrování se\npoužívají cca 30 let. Šifrovací algoritmus umožňuje odesilateli zašifrovat otevřený text (na\nšifrovaný) a příjemci text rozšifrovat. Máme šifroací klíče – jeden pro šifrování (označme ho\nKA) a jeden pro dešifrování (KB). Pokud K A = K B , pak je šifrování symetrické, pokud\nK A ≠ K B , pak je šifrování asymetrické (klíč pro zašifrování může být veřejný). Označme\notevřený text jako m. Pak K A ( m ) je šifrovaný text a K B ( K A ( m ) ) je dešifrovaný (neboli opět\notevřený) text. Jak šifrování probíhá, je na slidu 6 – text se zašifruje, odešle šifrovaný a\npříjemce ho rozšifruje.\nSymetrické šifry – používají substituce (nahrazení písmenek) nebo transpozice (změna\npozice písmenek )\n• Caesarova šifra – mějme klíč K=n, posuneme celou abecedu o n písmenek, takže\nnapříklad slovo ahoj nám to při K=3 zašifruje jako dkrm...viz slidy. Logicky počet\nklíčů je roven počtu písmen v abecedě – 1 (protože kdybychom to posunuli moc, jsme\nzas tam, kde jsme byli).\n• Monoalfabetické šifry – náhrada jednoho písmena abecedy jiným písmenem. Je 26!\nklíčů. Na šifry tohoto typu lze aplikovat statistický útok.\n• Polyalfabetické šifry – náhrada jednoho písmena abecedy různými písmeny – něco\njako Caesarova šifra s více možostmi nahrazení ... viz slide 7\n• Transpozice – slide 8 – napíšeme si text do řádků a každý sloupeček označíme číslem\n(ale pozor – na po řadě, ale zpřeházeně) – nyní čteme písmena podle čísel sloupců...ale\nobrázek na slidu vydá za tisíc slov\n• Data Encryption Standard – neboli DES, je to šifra která byla publikována v roce\n1977. Má 56b symetrický klíč (+8b parita), byl to několikrát obnovený stadnard\n(prodloužení klíče, triple DES), ale v současnosti je to slabá šifra. Její prolomení\ntrvalo v roce 1997 4 měsíce, ale v roce 1999 to bylo už jen 22 hodin. Proto byl v roce\n2001 přijat nový standard AES (Advanced Encryption Standard) – kde jsou 128b,\n192b nebo 256b klíče...více o DES je na slidu 10 a zde, o AES pak zde.\nAsymetrické šifry – klíč na zašifrování a dešifrování je odlišný, existuje množství klíčů při\nkomunikaci různých subjektů. Je veřejný klíč (označme ho např. K B + ) – ten slouží k\nzašifrování textu a je veřejně známý, a pak je privátní klíč (označme ho K B − ) - ten slouží k\ndešifrování textu. Tyto klíče je složité vzájemně odvodit.\nPlatí rovnice: K B − ( K B + ( m ) ) = K B + ( K B − ( m ) ) = m . Jak je vidět na slidu 12, přenos probíhá\ntak, že odesílael zašifruje text veřejným klíčem, a příjemce na přijatý text aplikuje svůj\nRSA – je to algoritmus pro vytváření klíčů, název odvozen z příjmení jejich vynálezců (Ron\nRivest, Adi Shamir, Leonard Adleman). Princip je tento:\nmáme dvě prvočísla: p a q. (velikost cca 1024b a 768b).\nMějme čísla n = p ⋅ q ; z = ( p − 1) ⋅ ( q − 1) ; a číslo e, které je nesoudělné se z a menší než n\ndále číslo d, kde musí plait, že ( ( e ⋅ d ) mod z = 1)\nPak platí K B + = ( n, e ) a K B − = ( n, d ) .\nAlgoritmus pro šifrování je c = m e mod n a pro dešifrování je m = c d mod n (kde m je\notevřený text a c je zašifrovaný text). Příklad na RSA je na slidu 14. Neděste se toho, první\ntabulka je zašifrování – první sloupeček je původní text, druhý sloupeček je operace m e a třetí\nsloupec je m e mod n . Analogicky probíhá dešifrování (druhá tabulka).\nAutentizace – je to poskytnutí informace o identitě jednoho subjektu subjektu druhému.\nProvádí se před použitím dalších protokolů a často se provádí oboustranně.\n• Autentizační protokol 1.0 – pouze zadání jména (nebo nějaké jiné identifikace). Tento\nje samozřejmě nedostatečný, taky se můžu představit jako někdo jiný, že...viz slide 16\nAutentizační protokol 2.0 – kontrola uživatelského jména a IP adresy, ze které se\nuživatel připojuje. Zde je ovšem možnost podvržení IP adresy\nAutentizační protokol 3.0 – uživatel se přihlašuje jménem a heslem. Toto používají\nnapříklad protokoly telnet nebo ftp. Zde je ovšem možnost heslo odposlechnout a\nněkdy ani zašifrování nepomůže.\nAutentizační protokol 4.0 – to samé jako 3.0, ale pokaždé uživatel použije jiné heslo.\nZde ovšem musíme nějak pošéfovat to, jak hesla generovat tak, aby to bylo bezpečné,\nprotože, jak někdo na algoritmus generování příjde, tak jsme v pr...\nAutentizační protokol 4.1 – uživatel zadá heslo, podle tohoto hesla se zašifruje výzva,\nkterá se uživateli předá. Uživatel výzvu nějakým klíčem rozluští a odpoví na ni. Tento\nprotokol je bezpečný, ale je tu problém, jak uživateli předat klíče.\nAutentizační protokol 5.0 –výzvu zašifrujeme asymetrickou šifrou (předpokládejme,\nže uživateli jsme jeho privátní klíč předali už předtím), poté pošleme uživateli dotaz\nna to, jaký je veřejný klíč? on nám odpoví a tím pádem můžeme přijatý text\nrozšifrovat. Nojo, ale problémem je to, že hacker může mít svůj privátní i svůj veřejný\nklíč – a pokud přijímá zprávy od uživatele (Alice) a tváří se jako server (Bob), je\nprakticky nemožné jeho hrozbu odhalit. Jinak ještě u protokolu 5.0 je asymetrická\nšifra, což je výpočetně složitější - dá se to obejít tak, že budeme mít symetrickou šifru\na klíč k ní bude jen dočasný (budeme ho po nějaké době měnit).\nIntegrita, digitální podpis – integrita je zaručení, že dokument nebyl změněn, dá se zaručit:\nnepopiratelností – podpis zodpovědého subjektu , nebo nějakou doručenkou a nebo využitím\n• podpis – buď šifrujeme celý dopis (zbytečně náročné) nebo hodíme na dopis nějaký\notisk (otisk se vytvoří, zašifruje (můžeme ho předtím ještě zahashovat), a dešifruje) –\npo doručení dokumentu rozšifrujeme otisk a ten ověříme, jestli sedí. To jak to vypadá\nje graficky znázorněno na sidech 27 a 28.\nDistribuce klíčů – řešení je jak pro symetrické tak i pro asymetrické klíče.\n• symetrické: KDS(Key Distribution Center – obrázek slide 30), Kerberos (každý\nuživatel má vlastní klíč, kerberos přiděluje dočasné komunikační klíče)\n• asymetrické: CA - Certification Authority – nejdříve se ověří uživatel dle nějakého\nprůkazu totožnosti a pak se mu vystaví certifikát podepsaný CA, jak to probíhá, je na\nŘízení přístupu – zamezení útočníkům v přístupu k prostředkům, je více možností, jak toho\n• firewall – buď může být hardwarový nebo softwarový... obrázky (i když divné) jsou\nna slidu 33 a 34\n• zahazování,akceptace a forwardování paketů – na to máme paketové filtry (rozhodují\nse podle obsahu paketu), kontextové filtry (rozhodují se podle kontextu spojení) a\naplikační brány (speciální aplikace – např. proxy)\nTypy útoků :\n• mapování(mapping) –první fáze útoku, kdy si hacker sbírá informace (pomocí pingu,\nscanování portů). Je to dobrý předpoklad pro DDoS (viz dále co to je)\n• odposlouchávání – to je snad jasné, co to je, odposlouchává na síti např. hesla a tak\npodvrhnutí (spoofing)- je to podvrhnutí zdrojové IP adresy, ale dá se to poměrně\njednoduše omezit pomocí firewallu.\nDoS (Denial of Service) – omezení dostupnosti služby pro legitimní uživatele. Tento\nútok využívá chyby nebo přetížení\nDDoS (Distributed DoS) – je to velmi nebezpečná varianta DoS, téměř bez možnosti\núnos spojení (hijacking) – možnost ukradení spojení navázaného někým jiným.\nNicméně šifrování tento problém řeší.\n• aplikační vrstva – zabezpečení souboru např. pomocí PGP\n• transportní vrstva – zabezpečení spoje, např. pomocí SSL (Secure Socket Layer)\n• síťová vrstva – zabezpečení mezi dvěma uzly, např. pomocí IPsec\n• linková vrstva – zabezpečení linky, např. pomocí šifrování modemů\nŠifrování může probíhat na libovolné vrstvě, nižší vrstvy pak šifrují hlavičky vyšších vrstev.\nPřednáška 10 – IPv6\nObsah přednášky – historie, motivace, formát datagramu, adresace, objevování sousedů,\nautomatická konfigurace, IPsec, mobilita\nHistorie a požadavky – počátkem 90, let se objevila studie o vyčerpání adres IPv4 do 10 let,\n1995 vznikl IPv6, poté pomalu pronikal do praxe. Požadavky na tento protokol byly: větší\nadresní prostor, zvýšení bezpečnosti, QoS, automatická konfigurace a mobilita.\nFormát datagramu IPv6 – IP-datagram verze 6 se skládá ze čtyřicet bajtů dlouhého\nzákladního záhlaví následovaného rozšířeními. Čtyřicet bajtů základního záhlaví se může zdát\nhodně, ale je třeba si uvědomit, že jen IP-adresy odesílatele a příjemce zaberou 32 bajtů.\nStruktura základního záhlaví je zobrazena na obr.\núčelem struktury bylo minimalizovat položky a udržet konstantní délku hlavičky. Bylo\nodstranění přepočítávání kontrolího součtu (ponecháno na nižší vrstvě), délka hlavičky (je\nvždy stejná), rozšiřující volby a fragmentace (přesunuta do dalších hlaviček) . Volitelné\npoložky jsou umístěny do samostatných hlaviček. Zpracování datagramu je tedy\nTakže co tedy zbylo vlastně v té hlavičce?\n• verze protokolu (ta je samozřejmě 6)\n• třída dat resp. - podpora pro QoS – skládá se ze 4 bitů, tzn. nabývá hodnoty 0-15Hodnoty 0-7 jsou určený pro klasický provoz (0-nespecifikovaná data, 1-provoz na\npozadí (např. news), 1-automatický provoz (např. mail), 4 – velké přenosy dat (např.\nHodnoty 8 – 15 jsou určeny pro přenosy v reálném čase (např. audio). Datagramy s\nnižší hodnotou (to však platí jen pro interval 8-15) si přeje uživatel zahodit dříve než\ndatagramy s vyšší hodnotou.\nspecifikuje přenášená data pro případ rozhodování v okamžiku zahlcení sítě.\n• identifikace toku dat – toto je naprosto neotřelá myšlenka. Spolu s adresou odesílatele\nse jednoznačně identifikuje dílčí tok dat v internetu. Doposud se směrování provádělo\npouze na základě adresy příjemce. Nevýhodou směrování v intenetu je, že jednotlivé\nIP datagramy se dopravují samostatně, tj. pokud Internetem prochází tok IP datagramů\nmezi 2 aplikacemi, pak směrovače na cestě řeší směrování pro každý datagram\nsamostatně. Prostě pokud posíláme megabajty dat a během přenosu nedojde ke změně\nv topologii sítě, pak směrovače po cestě řeší tu samou úlohu s tím samým výsledkem\npro tisíce datagramů. Myšlenka spočívá v tom, že datagramy jednoho toku dostanou\nsvou identifikaci. Pak stačí, aby směrovač vyřešil úlohu (do kterého rozhraní datagram\npředat) pro první datagram toku a do paměti si poznamenal výsledek. Pro další\ndatagram nejprve prohlédne pamě; a pokud by tam nenašel poznamenaný tok, tak řeší\núlohu směrování. Další datagramy stejného toku pak bude předávat do stejného\nrozhraní aniž by řešil úlohu směrování – pouze na základě údajů v paměti. Položka v\npaměti směrovače nesmí zůstat déle než 6 vteřin. Nebezpečí číhá totiž v tom, že\nodesílatel resetuje svůj počítač. Zavede znovu operační systém a shodou okolností\nvygeneruje stejnou identifikaci pro jiný tok. Nepředpokládá se, že by uživatel stihl\nprovést reset počítače do 6 vteřin. Jinou možností je využít identifikaci toku dat k\nzajištění šířky přenášeného pásma. Směrovače na cestě od odesílatele k příjemci se\nnakonfigurují tak, aby pro datový tok o jisté identifikaci zajišťovaly určitou šířku\npásma. Datagramy docházejí na směrovač, kde se umísťují do vyrovnávací paměti. Za\nnormálních okolností se jedná o frontu datagramů, která z jednoho konce přibývá a z\ndruhého konce se datagramy odebírají (odesílají). Směrovač však nemusí frontu\nzpracovávat sekvenčně, ale může přednostně vybírat datagramy tak, aby zajistil\ndohodnutou šíři pásma. V tomto případě pochopitelně nelze hrát na šestivteřinový\n• délka dat (počet bytů za hlavičkou) – specifikuje délku IP datagramu bez základního\nzáhlaví (to má totiž délku vždy stejnou – 40B). Jelikož je toto pole dlouhé 2B, tak\nnejvětší délka přenášeného IP datagramu je 65535B. Je však možné použít volbu\n„ohromný datagram“ v další hlavičce, která umožňuje posílat ještě větší datagramy\n• další hlavička – specifikuje typ následující (zřetězené) hlavičky. Následující hlavičky\nmohou být například tyto:\nPouze typy, které jsou uvedeny tučně jsou součástí IP protokolu. Ostatní typy jsou\ntypy protokolů vyšších vrstev\ndosah (počet hopů) toto poslední pole odpovídá položce TTL v IPv4\nŘetězení hlaviček – viz slide 7 – Pole další hlavička v základním záhlaví ukazuje jaký typ dat\n(“jaká hlavička”) následuje za základním záhlavím. Teoreticky může ukazovat již na TCP\nsegment nebo jiný protokol vyšší vrstvy. Avšak může také ukazovat na další rozšiřující\nhlavičky IP-protokolu. Pokud ukazuje na další rozšiřující hlavičku, pak i tato hlavička má\npole „další hlavička”, která ukazuje na další hlavičku. Hlavičky tak tvoří řetězec. Řetězec\nobsahuje jen ty hlavičky, které jsou nutné. Je to rozdíl od IP-protokolu verze 4, který ve svém\nzáhlaví často přenáší nadbytečné informace. Za polem další hlavička je pole délka hlavičky.\nPole délka hlavičky specifikuje posunutí jaké je třeba udělat k další hlavičce. Základní záhlaví\ndélku nemá, protože je dlouhé vždy 40 bajtů. Rovněž u záhlaví fragmentů se délka nepoužívá,\nprotože tato hlavička je vždy 8 bajtů dlouhá.\nDále popíšu některé typy dalších hlaviček:\n• Informace pro směrovače –obsahuje jednotlivé informace (volby), které jsou určeny\npro směrovače přepravující datagram. Každý směrovač, který datagram předává se\nmusí těmito volbami zabývat. Volba se skládá z pole typ dlouhého 1 B, pole délka\ndlouhého 1 B a pole obsahujícího vlastní volbu. Obrázek uvádí některé volby.\nPokud je volba délka rozsáhlého datagramu použita, pak délka datagramu v základním\nzáhlaví je nastavena na nulu a používá se délka uvedená v této volbě. Zatímco v\nzákladním záhlaví jsou pro délku určeny 2 bajty (tj. datagram může být dlouhý až 64\nKB), pak 4 bajty volby rozsáhlý datagram umožňují délku až 4 GB.\n• směrovací informace - Hlavička směrovací informace používá tč. jedinou volbu\n(Typ=0), kterou je explicitní směrování. Kdy odesílatel specifikuje IP-adresy\nsměrovačů, přes které má být datagram dopravován\n• záhlaví fragmentu - Fragmentovat IP-datagramy verze 6 může pouze operační systém\nna straně odesílatele. Směrovače, kterými datagram prochází na své cestě od\nodesílatele k příjemci fragmentovat na rozdíl od IPv4 již nesmí. Jak vypadá tato\nhlavička, je znázorněno na obrázku\nNa rozdíl od IP-protokolu verze 4 neobsahuje každý IP-datagram (např. v základním\nzáhlaví) identifikaci IP-datagramu. Identifikace IP-datagramu je nutná pro\nfragmentaci, aby příjemce zjistil, které fragmenty patří do stejného datagramu. V IPv6\nje identifikace datagramu pouze v dalším záhlaví, tj. není součástí každého IPdatagramu.Pole posunutí od počátku datagramu slouží k sestavení datagramů. Pomocí\ntohoto pole příjemce zjistí pořadí v jakém má fragmenty skládat za sebe. Pole posunutí\nod počátku datagramu neudává posunutí v bajtech, ale v násobcích osmi bajtů (v\n„osmibajtech”), proto se při fragmentaci musí zajistit, aby fragmenty byly odřezávány\nv délce, která je dělitelná osmi.A konečně pole M (More Fragment) indikuje poslední\nfragment. Jednobitové pole M je nastaveno na jedničku, pouze v případě posledního\nfragmentu na nulu.\nautentizační hlavička - Pomocí autentizační hlavičky odesílatel autentizuje data, tj.\nprokazuje, že data odeslal on. Datagram je tak zabezpečen proti změně IP-datagramu\nútočníkem i proti záměně celých IP-datagramů odesílatele za IP-datagramy vložené\nútočníkem. Základní autentizace je za využití algoritmu MD-5 (RFC-1321) pro\nvýpočet kontrolního součtu.\nbezpečnostní hlavička – umožňuje přenášená data šifrovat – musí to být poslední\npřenášená hlavička datagramu, protože data jsou již dále šifrovaná, tj. nedostupná ke\nzpracování směrovačům dopravujícím IP datagram.\nŘetězení hlaviček je znázorněno na obrázku...\nFragmentace - Provádí se pouze u odesílatele, informace o fragmentaci je uložena v\nrozšiřující hlavičce. Hlavičky až po tu fragmentační jsou nefragmentovatelné. Doporučené\nMTU (Maximum Transfer Unit) pro IPv6 je 1280B. Vyhledávání MTU cesty se děje pomocí\nICMPv6 – nemusí se implementovat.\nJumbogramy – to budou asi nějaké ty velké datagramy:-). Jejich maximální délka je až 4GB.\nAle uzly s menším MTU nemusí Jumbogramy podporovat.\nPár slov o ICMPv6 - Podobně jako v případě IP-protokolu verze 4 se pro signalizaci chybových stavů a\npro diagnostiku v IPv6 používá protokol ICMP. Protokol ICMPv6 v mnoha případech přináší zcela odlišné\nfunkčnosti oproti protokolu ICMPv4. Řeší např. překlad IP-adres na linkové adresy. (Na tento\nproblém jsou v IPv4 určeny samostatné protokoly ARP a RARP. ) Z hlediska struktury paketu\nse ICMP paket jeví jako protokol vyšší vrstvy, tj. je předcházen základním záhlavím IPprotokolu i případnými dalšími hlavičkami. Jinak ICMPv6 slouží samozřejmě pro diagnostiku\na signalizaci zpráv. Pokud by to někoho zaajímalo, tak tabulka různých typů ICMPv6 paketů\nje v bibli na straně 207.\nDélka adresy je 128b, tedy 16 8-bitových polí (oproti IPv4, kde byly jen 4 pole –\nRozeznáváme tři druhy adres:\n• unicast – jednoznačná adresa síťového rozhraní\n• anycast – adresa skupiny síťových rozhraní. IP datagram adresovaný adresou anycast\nbude doručen jednomu z těchto rozhraní.\n• multicast – neboli oběžník\n• !Broadcast adresy nejsou podporovány!\nPoužívají se různé zápisy IP adresy:\n• normální zápis - např. FEDC:1234:0000:ABCD:0F12:0000:0000:4567 – vedoucí\nnuly (to jsou nuly,kterými čtyřčíslí začíná) se uvádět nemusí, takže zápis této adresy\nmůže vypadat např. FEDC:1234:0:ABCD: F12:0:0:4567\n• zkrácený zápis pomocí zvolené dvojtečky – zvolená dvojtečka se může v adrese\nvyskytovat pouze jednou a nahrazuje tam libovolné množství čtveřic null, např.\npokud máme adresu 1234:0:0:0:0:0:0:0:14, pak ji pomocí zvolené dvojteky můžeme\nnapsat jako 1234::14\nAdresy sítí: viz obrázek...\nOběžníky resp. Skupinové adresy: Oběžníky mají prefix obsahující v prvním bajtu samé\nbinární jedničky, tj. šestnáctkově FF (viz obrázek).\nTaké viz slide 12 – koukni, kde se vyskytuje bit T – to udává, zda je oběžník přidělen trvale\n(0), nebo jen dočasně (1). Dalším polem je rozsah (4b), to je, jak jsme si řekli něco jako TTL,\nhodnoty dosahu: rozhraní (1), linka (2), podsíť (3), správa (4), místo (5), globální (E) – na\nslidu 12 jsou ještě příklady pro adresy, ale myslím, že je to jasné.\nAdresy rozhraní – uzel – má lokální linkovou adresu, loopback, individuální a výběrovou,\nmůže být skupinová adresa pro všechny uzly, také skupinová pro skupiny, jichž je uzel\nčlenem a také skupinová pro vyzývaný uzel. směrovač – má adresy jako uzel + navíc\nskupinové pro všechny směrovače, výběrové pro směrovače v podsíti a také všechny\npřidělené výběrové adresy.\nObjevování sousedů - k tomuto slouží protokol, jež je rozšířenou náhradou ARP (vzpomeň\nsi na zjišťování MAC). Tento protokol využívá ICMPv6 pro výzvu směrovači, odhlášení\nsměrovače, výzvu sousedovi, ohlášení souseda, přesměrování.Tento protokol poskytuje:\nzjišťování linkových adres v lokální síti, rychlou aktualizaci změn a neplatných položek,\nhledání směrovačů, přesměrování, detekci duplikových adres, ověření dosažitelnosti sousedů\na zjišťování údajů pro automatickou konfiguraci.\nHledání linkové adresy: - pošleme výsvu sousedům pomocí skupinové adresy, posledních\n24b necháme samé Fka – tam se doplní ty hledané linkové adresy (jestli to chápu správně).\nPokud se nám soused s linkovou adresou ohlásí, aktualizujeme si jeho adresu.\nAutomatická konfigurace – viz http://www.ipv6.cz/v6about/autokonf/\nJedním z požadavků na IPv6 je automatická konfigurace. Představa, že člověk jednoduše\npřipojí počítač k síti a bude mu fungovat síťování, aniž by kdokoli cokoli konfiguroval, je\nvelmi lákavá (a z pohledu správce sítě částečně děsivá).\nstavovou konfiguraci obstarává DHCPv6, nevyužívá však broadcast (jak by taky, když je\nzakázaný). DHCP unique identifier (DUID) je záznam, který jednoznačně identifikuje uzel je v něm obsažena linková adresa a čas, je přiděleno výrobcem. Identity Association je zázam\njednoznačně idenifikující rozhaní ... zbytek slidu nechápu (???)\nbezestavovová konfigurace – nevyžaduje konfiguraci... Jejím základním pilířem je tak zvané\nobjevování sousedů (neighbor discovery). Základní myšlenka je celkem prostá: každý\nsměrovač v určitých intervalech rozesílá do sítí, k nimž je připojen, tak zvané ohlášení\nsměrovače. V něm jsou obsaženy základní informace - především prefixy adres dané sítě a\nzda on sám může sloužit pro předávání paketů ven (jako implicitní směrovač, default\ngateway).Z ohlášení směrovačů (o které může při startu aktivně požádat pomocí výzvy\nsměrovači) se počítač dozví, jaké adresy používá zdejší síť. K nim si doplní zbývající část\n(typicky 64 bitů), která se jednoznačně generuje z jeho Ethernetové adresy. Tak získá platné\nIPv6 adresy pro své rozhraní. Také si vytvoří seznam implicitních směrovačů, kterým bude\npředávat pakety směřující mimo síť. Pokud je jich víc, zpočátku je prostě střídá a směrovací\ntabulku si postupně vylepšuje na základě jejich upozornění (ICMP přesměrování), pokud\npaket k určitému cíli poslal nevhodným směrovačem.Zní to dost dobře, přesto však má\nbezstavová konfigurace dost velkou pihu krásy. Vůbec totiž neřeší otázku DNS. Počítač se z\nní nedozví adresy zdejších DNS serverů a jak již bylo řečeno, bez DNS se v IPv6 žije velmi\nBezpečnost – je povinná implementace IPsec, autentizace je prováděna pomocí\nAuthentication header, šifrování pomocí ESP (Encapsulating Security Payload). Při\ntransportním režimu se bezpečnostní hlavičky jednoduše vloží, při tunelujícím režimu se\ndatagram zabalí da datagramu s bezpečnostními hlavičkami.\nBezpečnostní asociace – Security Association (SA) – obsahuje informace potřebné pro\nšifrované spojení –bezpečnostní protokol, šifrovací algoritmus, klíče, čítače, doba\nživotnosti... SA je jednosměrná a vytváří se ve dvojicích, pro AH (Authentication Header) i\nESP je jedna dvojice. Na jeden paket se vztahuje svazek SA.\nDatabáze bezpečnostní politiky – je to sada pravidel uplatňovaná na všechny pakety. Říká,\njestli pakety zahodit, zpracovat bez IPsec (tedy jen odeslat a přijmout) a nebo zpracovat s IP\nsec (tehdy databáze vydá svazek SA). Tuto databázi můžeme buď nakonfigurovat manuálně\nnebo automaticky pomocí ISAKMP\nAuthentication Header – složí pro autentizaci odesílatele, umožňuje ochranu proti\nopakování. Postup je takový: Nejdříme vložíme AH hlavičku, potom vyplníme položky\n(autentizační data se vyulují) a poté se autentizační data vypočtou.\nEncapsulation Security Payload (ESP) - slouží k šifrování obsahu (i služby AH). Obsahem\nESP hlavičky jsou data a další hlavičky. Postup je takový: Umístění ESP hlavičky, vycpávky\na šifrování, vytvoření pořadového čísla, vytvoření autentizačních dat (je li požadována\nautentizace a kontrola integrity), fragmentace až po šifrování.\nMobilita - pracuje na principu domácí adresy a domácího ageta (co to ku... je?)... obrázky\nviz slide 25-28\nPřednáška 11 – Síťová správa\nObsah přednášky : definice, historie, protokoly a příklady\nSíťová správa podle ISO:\n• správa výkonu (performance management) – reaktivní a proaktivní, měření výkonnosti\n• správa konfigurací (cofiguration management) – monitorování síťové konfigurace\n• správa účetní (accounting management) - monitorování využití sítě\n• správa poruch a chyb(fault management) – detekce chyb, logování a oznámení\n• správa bezpečnosti (security management) – nastavení a monitorování přístupu\nArchitektura správy – slide 4 v síti je jeden počítač připojen jako Agent a obsahuje databázi\nsprávy sítě, kam se ukládají data\nSimple Network Management Protocol je sada protokolů usnadňujících správu\nkomplexních IP sítí. V současné době tímto protokolem umí komunikovat nejrůznější sítové\nprvky, ať už se jedná o servery, pracovní stanice, směrovače, switche, huby a další.\nAdministrátorům SNMP umožňuje sledovat výkon a provoz v síti, odhalit a řešit vzniklé\nproblémy. SNMP může být důležitým zdrojem dat při plánování rozvoje sítě...více zde\nPředstavte si že chcete jednomu počítači manuálně nastavit směrovací tabulku. Použijete\npříkaz route add – net...\nPokud ovšem nespravujeme jeden počítač, ale rozsáhlou síť počítačů, pak je velice náročné se\npostupně přihlašovat na jednotlivé systémy a tam dávat příkaz route. Zpravidla máme k\ndispozici manažerskou stanici a na všech aktivních prvcích sítě (počítače, směrovače, HUBy,\nmodemy, databáze atd.) běží SNMP agenti, kteří jsou k dispozici manažerské stanici.\nZ manažerské stanice je možné provádět dotazy na nejrůznější parametry jednotlivých\nsystémů. Mj. je takovým parametrem i položka směrovací tabulky. Takže z manažerské\nstanice můžeme vypisovat obsah směrovacích tabulek, ale i směrovací tabulky modifikovat.\nNesmíte si jen zmodifikovat směrovací tabulky tak, abyste ztratili spojeni s manažerskou\nMIB – Management Information Base – je to databáze parametrů zařízení. Každé zařízení\ntakovouto databázi obsahuje. tato DB musí mít urč. jmennou strukturu ve formě\nhierarchického stromu. Touto databází je určeno, jaké proměnné jakého typu spravuje tzv.\nagent. Ten běží na každém zařízení a zpracovává zprávy od tzv. managera. Obsahem zprávy\nmůže být požadavek na čtení nebo zápis dat, agent požadavky přijímá a výsledkem jeho\nčinnosti je nějaká odezva managerovi. Agent nemusí jen pasivně čekat na požadavky. Pokud\nnastane určitá událost, dokáže o tom informovat managera pomocí tzv. TRAP zpráv. Na řídící\nstanici běží manažer komunikující s jedním či více agenty. Jedná se vlastně o architekturu\nklient-server, agent je serverem, manažer klientem. Zprávy mezi nimi jsou přenášeny\nprotokolem UDP, jenž byl zvolen pro svoji jednoduchost a vhodnost při komunikaci typu\nžádost/odpověď, na níž je síťový management založen.\nSNMP rozlišuje pouze pět typů zpráv:\nget-request – žádost o nějakou hodnotu\nget-next-request – žádost o další hodnotu v pořadí (použití při žádosti o pole dat)\nget-response – odpověď na žádost\nset-request – žádost o zápis hodnoty\ntrap – zpráva, kterou agent informuje managera o nějaké události\nModel komunikace SNMP je na obrázku – podstatou SNMP je, jak od síťových zařízení\nzískat informace (parametry) a také možnost, jak tyto informace změnit.\nPoslední verzí je verze 3. Model je takový, že máme nějaký „Uzel Správy“ – ten obsahuje\nSNMP agenta a stavové a konfigurační informace. Tento „Uzel Správy“ pak komunikuje\npomocí SNMP služeb se „Stanicí správy“.\nManagement Information Base – slide 7 – nechápu, vysvětlit\nSNMP služby – snmpget, snmpset, snmpgetnext, snmpgetbulk, trap, inform\nRemote monitoring – viz zde – Jde o sledování stavu vzdálené sítě na dálku. Oproti SNMP\numožňuje mnohem lepší monitoring sítě, všelijakou historickou analýzu atd.Základní ideou\npři návrhu RMON bylo mít inteligentního agenta, který je schopen co nejpodrobnějšího\nmonitorování síťového segmentu a uchovávání sesbíraných informací. Získané informace\n(aktuální i historická data) z různých agentů lze pak prezentovat na centrální správcovské\nkonzole při minimální komunikační zátěži a zároveň minimální výpočetní zátěži konzoly.\nPrincip RMON - RMON standard definuje skupiny informací, které mohou být\nmonitorovány síťovým analyzátorem nebo sondou (agentem). RMON MIB (Management\nInformation Base) standard umožňuje vzdálené monitorování Ethernet i Token Ring\nsegmentů a to využitím již zavedeného protokolu SNMP. RMON je typickým příkladem\ndistribuovaného řešení. Stejně jako klasický SNMP model, i RMON model se skládá ze dvou\nčástí. Tou první je agent (sonda), která je umístěna na monitorovaném segmentu. Druhou částí\nje správní aplikace, běžící na centrální konzole, v ideálním případě jako nadstavba základní\nsprávní platformy. Pomocí této RMON aplikace můžeme zkonfigurovat agenta ke sběru\npožadovaných informací, které jsou zasílány na centrální konzolu při vyžádání nebo při\nvýskytu definované události. Těchto agentů - sond může být rozmístěno v síti tolik, kolik má\nsíť segmentů. Samozřejmě u velkých sítí se tyto sondy umisťují strategicky jen na\nnejdůležitější segmenty, případně podle potřeby na ty segmenty, kde se objevují nějaké\nSkupiny informací RMON, které mohou být monitorovány: statistic (monitoruje se\nokamžitý provoz – byte, kolize, cyby), history – (dtto (??) ale historie), alarms (prahování\nněkterých hodnot), hosts (přenosová statistika pro každý uzel), hosts top N (setříděná\nstatistika hosts), Traffic Matrix (monitoring vzájemné komunikace mezi uzly ), Filters ,\nPacket Capture (Pakety pro další dekódování), Events (záznamy událostí)\nRMON MIB – podobně jako v SNMP má i každé zařízení v RMON svou MIB (Management\nPřednáška 12 – ukládání dat\nDirect Attached Storage – je když...připojíme (např. k serveru nebo pracovní stanici) přímo\nnějaké datové uložiště (datový sklad třeba...). Připojení může být realizováno např. přes SCSI\nnebo opická vlákna.více zde\nNetwork Attached Storage – uložiště dat (stanice s RAID poli např.) je k počítači připojeno\npomocí sítě rozhraní (klasický IP protokol) a tak poskytuje centralizovaný datový sklad pro\nrůzné klienty. Počítači se disky jeví jako dálkově připojené.K přístupu k datům používá\n(narozdíl od SAN) dobře známé protokoly. více zde\nStorage Area Network – je to vlastní síť datových uložišť, je připojena k serveru nebo\npracovní stanici např. přes SCSI nebo přes Fibre Channel. Tato datová uložiště se pak v\npočítači jeví jako lokálně připojené disky. Proto může např. server ze SANu klidně\nnabootovat. více zde\niSCSI (SCSI over IP) Attached Storage – je to nějaký datový sklad připojený k síti IP přes\niSCSI protokol – to je protokol transportní vrstvy, který umožňuje využívat SCSI přes síť\nTCP/IP. více zde\nLAN – NAS (SAN) – jak lze vidět na slidech, NAS i SAN může být připojeno k počítačům\npomocí sítě LAN.\nPřenos dat – jak je vidět, Direct Attached Storage a SAN se v architektuře datových skladů\nnijak neliší, ale rozdíl je v přenosu dat. U DAS se přenáší přímo přes SCSI sběrnici, u SAN\npřes síť SAN a u iSCSI a stejně tak u NAS přes TCP/IP síť.\nFibre channel – je to síťová technologie (gigabitová rychlost) pro přenos dat z datových\nskladů po síti. I když název je Fibre Channel, tato technologie dokáže pracovat jak přes\noptická vlákna,tak přes kroucenou dvojlinku. Topologie může být buď Point to Point (dvě\nzařízení jsou propojeny spolu – viz zde) nebo Arbitrated Loop(zařízení jsou propojeny ve\nsmyčkách – viz zde) nebo Switched Fabric (všechny zařízení i smyčky jsou připojeny k\nnějakým switchům – viz zde ). Propustnost Fibre Channel může být od 200 do 4800 MB/s\n(wow!) a fibre channel podporuje řízení toku. Struktura paketu (rámce) fibre channel je na\niSCSI – je to protokol pro přenos SCSI příkazů přes síť TCP/IP, je to protokol transportní\nvrstvy (tedy přenos SCSI příkazů přes TCP), HyperSCSI je protokol podobný iSCSI až na to,\nže kašle na rodinu TCP/IP a pracuje přes Ethernet, proto se např. nemusí zabývat segmentací\na sestavením, díky tomu je rychlejší, ale nemá takovou flexibilitu pro IP sítě. Jak vypadá\nrámec obsahující iSCSI je vyobrazeno na slidu 11.\nFibre Channel over IP – umožňuje přenos Fibre Channel paketů přes IP protokol, využívá k\ntomu opět protokol TCP, takže je to v podstatě něc jako iSCSI. Využívá tunelování (???) pro\npřenos FC informací přes IP sítě. Rámec obsahující FCIP je na slidu 12. FCIP je dobrý pro\nPoint to Point komunikaci mezi síti SAN (viz slide 14)\nInternet Fibre Channel Protocol (iFCP)- pro přenos FC informací využívá ne tunelování,\nale směrování, propojuje různé SAN struktury (slide 14)\nATA over ethernet – je to síťový protokol, který dává možost si vytvořit levné sítě SAN,\nProtože funguje přes Ethernet,nezávisí na technologiích vyšších vrstev (IP,UDP,TCP...) –\nprostě se ATA příkazy vkládají přímo do ethernetových rámců. Proto to nejde nijak směrovat\n(není tam totiž IP paket, ale pouze Ethernet)\nDalší technologie – IPv4, IPv6, ARP over FC.\nPřednáška 12 – IDS\nIntrusion Detection System – je to systém, který detekuje nechtěné manipulace s počítačem\nskrz internet. Používá se k detekování rozličných hrozeb, které nedokáže detekovat firewall\n(toto zahrnuje síťové útoky proti zranitelným služám nebo nějaký malware (viry, trojany,\nčervy...)). Jsou různé typy IDS\n• :network IDS - NIDS – je položen na strategickém bodě (bodech) v síti, aby\nmonitoroval traffic, který přez něj jde a podel toho odchytávat pakety. To je sice\nhezké, ale může to docela omezit propustnost sítě . Příkladem Network IDS je třeba\nSnort – Open source program.\n• host based - prostě na hostitelském kompu je spuštěn nějaký soft, který identifikuje\nútoky na systém tak, že analyzuje systémová volání, modifikace souborového\nsystému, příchozí data... – prostě nějaký takový antivir\n• sinature based - monitoruje pakety na síti a porovnává je s databází (vzpomeň na\nNOD signature database) údajů, Problém je, že když je objevena nějaká nová\nhrozba,nějaky čas to trvá, než se zanese do databáze -\nanomaly based (IDS monitoruje traffic a porovnává ho s „baseline“, což jsou vlastně\ninformace, co by měl normálně traffic obsahovat, jaké protokoly a porty by se měly\nnormálně využívat. Tyto informace jsou získávány nějakou heuristikou sítě Pokud se\nv trafficu vyskytne nějaká anomálie, IDS informuje admina )\n• honeypot – podle překladu je to hrnec s medem, je to tedy nějaké lákadlo pro\nnebezpečné útočníky, jejich útoky směřuje na sebe, čímž je odvrací od ostatních\n(cenných) počítačů a navíc tyto útoky může analyzovat a tak sesbírat informace.\nKomponenty IDS: sensory – generují bezpečnostní události, console – monitorují události,\ninformují o hrozbách a ovládají sensory, Central Engine – ukládá záznamy o událostech\n(zachycené sensory) do databáze a reaguje na bezpečnostní události.\nChyby IDS mohou být buď false positives (zbytečný poplach) nebo false negatives\nPasivní x reaktivní IDS – pasivní IDS pouze detekuje hrozby a upozorní na ně, kdežto\nreaktivní IDS (známý jako IPS, resp. Intrusion Prevention System) dělá nejen to, co pasivní,\nale také provádí nějaká opatření proti hrozbám (blokuje je)\nIntrusion Prevention System – je to považováno za takové rozšíření IDS. Výhodou oproti\nIDS je to, že dokáží v reálném čase reagovat na hrozby (odvrátit je). Většina IPS systémů je\nschopná sledovat protokoly 7 vrstvy (aplikační), jako jsou HTTP,FTP a SMTP, kteréžto\npředstavují největší nebezpečí. Možnosti realizace IPS jsou L7 switch, aplikační firewall +\nIDS, hybrid switch, inline NIDS.\nPozitivní TV kanál vysílá v Evropě\nNejvyšší Mistryně Ching Hai se narodila ve střední části Au Lac, přicestovala na studia do Evropy a pracovala tam jako dobrovolná ošetřovatelka a překladatelka pro Červený kříž. Brzy si uvědomila, ...\nVýrobce nebo jeho provozovatelé si ponechávají vlastnická práva k softwaru. Vy se stáváte pouze vlastníkem CDROMu. Software ani dokumentaci nesmíte měnit, přizpůsobovat, dekompilovat, překládat, vy...\nHledání chyb na směrovačích\ndebug ip rip debug ip igrp events debug ip igrp transaction\nsend(ip/udp/hsrp, iface='eth0', inter=3, loop=1) >>> ip/udp/hsrp\nMartin Zikmund stojící, bdící\nZájem o telekomunikace a především o mobilní technologie vyústil k sepsání publikace SMS pro zamilované. Útlá brožurka velikostí i designově připomínající mobilní telefon vyšla v nakladatelství Com...\nplatina - 10 % rhodium / platina platina - 13 % rhodium / platina platina - 30 % rhodium / platina – 6 % rhodium wolfram – 5 % rhenium / wolfram – 20 % rhenium\nTechnologie počítačových sítí - Katedra technické a informační\ndoc. PhDr. Milan Klement, Ph.D. Ještě před nedávnou dobou byl nejpoužívanějším přenosovým médiem v Ethernet LAN sítích koaxiální kabel (v Token Ring sítích s modifikací twinax). Výhodou byla cena ...\n■ Velká palivová nádrž o objemu 128 litrů se zdokonaleným systémem doplňování paliva umožňuje prodloužit dobu činnosti stroje bez doplňování paliva. ■ Volitelný systém Caterpillar pro tlumení rázů ...\nZáklady transportního protokolu TCP\nJedním z prvních a nejdůležitějších úkolů protokolu TCP je zajištění spolehlivého přenosu datového bloku konkrétní aplikace k aplikaci cílové. TCP protokol pracuje na 4. vrstvě RM OSI modelu a použ...\nZavádění protokolu IP verze 6\n2 - Instalace\n07 – Další přídavné - rozšiřující karty\nDialogy prezentacia na stiahnutie\nObecně o GPRS - FCC PS technická podpora / support website\nIT ŠVP (verze 1.9.2011)\nstarý sylabus ve formátu pdf\nmultiagentní systémy nail106 - Department of Theoretical Computer