PKO výpisky ke zkoušce

PKO – výpisky ke zkoušce Úvodem: Podívat se na Xfort, jsou tam nějaké odkazy na to z čeho se učit: http://www.exfort.org/forumbb/viewtopic.php?t=1551

Přednáška 1 – úvod Historie síťových technologií: 1. nejdříve se přenášela data na médiích (štítky, pásky, diskety...) 2. potom se “vynalezly” sériové a paralelní porty (dvoubodové spoje – viz PZA) 3. poté nastoupily terminálové sítě (zapojení do hvězdy) 4. dále... distribuovaný model (lokální sítě - LAN) 5. propojení pracovišť ( sítě WAN ) 6. mobilní technologie (WIFI,GSM) 7. specializované sítě (SAN – viz poslední přednáška nebo PZA) Historie v datech: 1957 – vznika ARPA (Advanced Research Projects Agency), 1960 – AT&T vyvinul dataphone, 1965 – první WAN z Massachussets do kalifornie, 1969 – síť ARPANET (4 uzly), 1970 – NCP, 1972 – věrejná demonstrace ARPANET, 1972 – email, 1973 – ethernet, 1975 – telnet, 1990 – www, 1991 – www server a browser, 1993 – mosaic Taxonomie (rozdělení) sítí • podle použití – na informační systémy nebo průmyslové aplikace • podele rozlehlosti – na LAN (local), MAN(metropolitan) nebo WAN(wide) • podle rychlosti – prostě tak nějak na rychlé a pomalé • podle topologie – sběrnice (viz PZA (nebo slide 9/1) – propojení více počítačů s jednou sběrnicí), hvězda/strom (slide 10), kruh (slide 11), bezdrátové spoje (slide 12) Vrstvená architektura – co to je? - je to vlastně taková obdoba komunikace přes tlumočníky, proč se to zavedlo? – kvůli zjednodušení návrhu, dekompozici problému a také snadné možnosti výměny modulů Funkce vrstev – komunikace probíhá mezi vrstvami na stejné úrovni, vrstvy poskytují služby vyšším vrstvám a využívají služeb nižších vrstev, komunikace mezi stejnými vrstvami je transparentní vůči nižším vrstvám, vrstvy interagují pouze se sousedními vrstvami (tj. vrstvami o 1 vyšší nebo o 1 nižší), komunikace mezi vrstvami je na slidu 15... Pouzdření vrstev – prostě to zabalování probíhá tak, že nejvyšší vrstva poskytne nějaká data, ta se zabalí do dat nižší vrstvy atd... atd...

ISO OSI referenční model: 1. Fyzická vrstva (physical layer) – poskytuje toto: umožňuje přenos bitů kanálem, definuje signály pro „0“ a „1“, předepisuje vlastnosti média, definuje elektrické a mechanické vlastnosti rozhraní. Na fyzické vrstvě je vytvořen tzv. fyzický okruh. Na fyzický okruh mezi 2 počítače bývají často vkládána další zařízení jako modemy atd. Příklad: Ethernet 10BaseT, RS232 (sériový port - COM) 2. Spojová vrstva (link layer) – Poskytuje v případě sériových linek výměnu dat mezi sousedními počítači a v případě lokální sítě výměnu dat na této síti. Základní jednotkou přenosu je rámec, který se skládá se záhlaví, dat a zápatí. Poskytuje funkci

spolehlivého spojení (detekce a korekce chyb), formátování dat do rámců, rozpoznávání rámců, řízení toku na lince, jednoznačnou adresu v rámci segmentu (link adresu – že by to byla MAC?). Na síťové vrstvě může být pro každý konec spojení použit jiný protokol... viz obrázek

Příklad: PPP,LLC 802.2 3. Síťová vrstva (network layer) – poskytuje adresaci a směrování dat přes mezilehlé prvky, jednoznačnou adresu v rámci sítě (síťovou adresu – že by i.p. adresa?), síťovou službu se spojením i bez něj. Základní jednotkou přenosu je síťový paket. který se skládá ze záhlaví a dat ...Jinak se zápatím se u síťových protokolů setkáváme jen zřídka. Směrovač operuje s paketem tak, že ho vybalí z ethernetového rámce a před odeslání do jiné linky jej opět zabalí...viz obrázek

Příklady: X.25, IP 4. Transportní (transport layer) – Síťová vrstva zabezpečí spojení mezi vzdálenými počítači, tak se transportní vrstvě jeví, jakoby tam žádne modemy nebo opakovače ani nebyly. Mezi dvěma počítači může být několik spojení na transportní vrstvě současně (jedno třeba pro mail a jedno pro ssh). Transportní vrstva poskytuje rozklad dat na pakety (pozor, data v paketech mohou být různé délky – viz obr.

uspořádání dat podle pořadí, multiplexuje a demultiplexuje data mezi transportními spoji, poskytuje transportní adresy (adresa, port) a koncové řízení toku. Příklady: UDP,TCP 5. Relační (session layer) – poskytuje vytváření logického rozhraní pro aplikace, synchronizaci spojení (transakce), stará se o relace. DObře představitelnou relací je

např. sdílení síťového disku. Tato relace existuje po celou dobu, ovšem spojení na transportní vrstvě se navazuje jen tehdy, když je třeba s diskem pracovat. Základní jednotkou přenosu relační vrstvy je relační paket. Příklady: RPC, sdílení disků 6. Prezentační (presentation layer) – poskytuje sjednocení prezentace informace, dohodu o syntaxi, transformaci dat, šifrování, kompresi. Příklady: kódování ASCII/EBCDIC, XDR, ASN.1 7. Aplikační (application layer) – poskytuje podpůrné funkce aplikacím ASE (Application Service Element): • SASE – specifická podpora, přenos souborů, pošta, terminály • CASE – univerzální podpora – vytváření aplikačního spojení, obsluha transakcí Také předepisuje v jakém formátu a jak mají být dat přebírána od aplikačních programů. Příklady: knihovny pro tvorbu síťových aplikací Pouzdření do ISO OSI – prostě jako jakékoli pouzdření to jde od nejsvrchější vrstvy k nejnižší - vždy se přidávají hlavičky a v síťové vrstvě se přidá navíc zakončení – fyzická vrstva to už jen přetransformuje na bity ... viz slide 25 Komunikace mezi vrstvami – routery pracují na síťové vrstvě (potřebují znát totiž i.p. adresu), HUBy na fyzické vrstvě (jen překopírují data, k tomu není potřeba žádná adresa), SWITCHe na spojové(linkové) vrstvě (potřebují znát MAC adresu, aby věděly, kam to mají v LANce poslat)

Přednáška 2 – protokolová rodina TCP/IP Všimněte si: TCP/IP není jeden protokol, ale rodina protokolů – a navíc pod souslovím „rodina protokolů“ se skrývá síťový model – tzn. něco jako OSI (viz obrázek), tento model (TCP/IP) používá internet. Jak vidíme, TCP/IP májen 4 vrstvy, podobné OSI jsou jen síťová a transportní.

Rodina síťových protokolů TCP/IP neřeší (až na výjimky, jako je protokol SLIP) linkovou a fyzickou vrstvu,proto se i v Internetu setkáváme s linkovými a fyzickými protokoly z modelu ISO OSI.

Historie: 1974 – první zmínka o TCP, 1978 – oficiální uvedení TCP/IP, 1983 – ARPANET adoptuje TCP/IP, 1991 – začátek prací na TCP/IP verze 6, 1995 – první RFC(co ta zkratka znamená viz dále) dokumenty k TCP/IP v 6 RFC – Request for Comments – je to množina technických a organizačních dokumentů TCP/IP protokoly: DNS, SNMP, FTP, SMTP, OSPF, UDP, TCP, RARP, ARP, IP, ICMP, ... viz slide 4 Jak probíhá adresace? adresy jsou hierarchicky vrstvené, máme různé třídy adres nebo také beztřídní adresy, dělíme adresy na subnet a supernet, probíhají tam převody mezi IP a linkovými adresami, existují speciální adresy, máme i privátní sítě a nečíslované sítě... uf ... slide 5 Třídy adres: A. 0... .... (místo teček doplň jedničky či nuly) prostě první osmice bitů může být od 0 do 127 (neboli 0000 0000 až 0111 1111). Adresu sítě určuje první bajt, zbytek je určen pro adresu v rámci sítě B. 10.. .... (místo teček doplň cokoli) první osmice bitů může být od 128 do 191 (1000 0000 až 1011 1111) . Adresu sítě určují první dva bajyt, zbytek je určen pro adresu v rámci sítě C. 110. ....(místo teček doplň cokoli) první osmice bitů je od 192 do 223 (1100 0000 až 1101 1111). Adresu sítě určují první tři bajty, zbytek je určen pro adresu v rámci sítě D. 1110 ....(místo teček doplň cokoli) první osmice bitů je od 224 do 239 (1110 0000 až 1110 1111). Adresa se již nedělí na adresu sítě a adresu počítače. Zbytek adresy tvoří adresný oběžník (multicast) E. 1111 ....(místo teček doplň cokoli) první osmice bitů je větší než 239 (1111 0000 až 1111 1111). Třída E je víceméně rezervou pro adresy Maska sítě ... viz slidy – na slidu 7 je ukázané jak funguje maska podsítě, pokud je v masce číslo za lomítkem, pak toto číslo udává počet jedniček zleva masky. Speciální adresy: • 0.0.0.0 - tento počítač na této síti • 00..0.počítač – počítač na této síti • síť.00..0 – adresa sítě jako takové • síť.subsíť.00..0 adresa subsítě • síť.11..1 – broadcast do sítě (do všech subsítí dané sítě) • síť.subsíť.11..1 – broadcast do subsítě • 11..1 – broadcast na lokální síti • 127.xx – loopback (127.0.0.1) Takže pokud máme např. síť 192.168.6.0 a dáme PING 192.168.6.255, pak nám odpoví všechny počítače na této síti (ale implementace PING od Microsoftu je všechny nezobrazí, ostatní ano). Subsíť – počet jedniček v jejich síťové masce je větší než u standartní síťové masky síťe Supersíť - počet jedniček v jejich síťové masce je menší než u standartní síťové masky síťe Privátní sítě – Takto se označují sítě Intranetu – prostě dejmetomu LAN sítě firem nebo uživatelů.Tyto sitě mají vyhrazené adresy (pro počítače uvnitř sítě – schované za NATem ), které se nesmí vyskytovat v internetu, probíhá tam filtrování, překlad adres, třídy privátních sítí: A. 10.0.0.0 – 10.255.255.255 B. 172.16.0.0 – 172.31.255.255 C. 192.168.0.0 – 192.168.255.255

Nečíslované sítě (pokud by to někoho zajímalo – ve slidech to nejni) jsou to linky mezi směrovači – prostě tyto linky se neberou jako nějaká síť, bere se to tak, že dva spojené směrovače tvoří jeden virtuální směrovač. Komunikace po síti – viz slidy 12-32 • slidy 12-18- komunikace po LAN – každý počítač má svou IP a MAC – to je ten třetí řádek, pokud chce 192.168.1.1 komunikovat s 192.168.1.10 musí zadat do rámce svou MACadresu a ip adresu cíle a dále svoji ip adresu (to aby příjemce věděl, kam má data vrátit) a nakonec samozřejmě data co posílá. Nejprve se porovnají adresy vyANDované (log, operace AND) s maskou podsítě a zjistí se, že oba kompy jsou ze stejné sítě. Poté se zjistí MAC adresa cíle a to tak, že odesílatel pošle dotaz do sítě na ip adresu příjemce (slide 16), příjemce mu v odpovědi zašle svou MAC. Tím je rámec kompletní a může proběhnout komunikace • slidy 19 – 32 – komunikace přes routery – jak každý počítač, tak každý router má svoji IP a MAC adresu, routery navíc mají více IP a MAC adres, protože mají více síťových rozhraní. Na slidech chce počítač 192.168.1.1 komunikovat se 147.32.83.10, zadá tedy do rámce opět svou MAC, svoji ip a cílovou ip a data, porovnají se adresy vyANDované s maskou a zjistí se že zdroj a cíl nejsou ve stejné síti (slide 21), takže se bude posílat přes výchozí bránu (adresa 192.168.1.254). Tak, teď se přes tu bránu opět pošle dotaz na MAC adresu brány (slide 23), příjde odpověď s MAC brány (slide 24), takže rámec pošleme na bránu (slide 25), dobře, ale teď stále nevíme MAC cíle, známe jen jeho IP. Opět zjistíme, že cíl není v téhle síti,no tak zase pošleme dotaz (!!pozor, v téhle chvíli se nám změnila MAC zdroje na MAC routeru, IP zdroje zůstává!!), tentokrát na druhý router.Ten router nám vrátí svoji MAC aresu, takže pošleme data na něj (nezapomeň, že IP adresa zdroje zůstává stále stejná, aby se vědělo, kam se mají data vrátit) atd. atd... konec pohádky Překlad adres (NAT) – probíhá při komunikaci z vnitřní do vnější sítě a naopak, je to překlad zdrojové a (nebo) cílové adresy, zdrojového a (nebo) cílového portu. Překlad může být buď statický nebo dynamický. NAT se označuje také jako Maškaráda(Masquerade). NAT je vysvětlený na slidu 33 – všimni si, že při „přechodu dat“ přes první router se změnila cílová IP na adresu tohoto routeru (bez NATu by tam byla IP adresa cílového počítače) Konfigurace počítačů: • Nastavení IP adresy a síťové masky prvního kompa – ifconfig eth0 192.168.1.1 netmask 255.255.255.0 (slide 35) • Nastavení defaultní brány pro kompy v podsíti – route add default gw 192.168.1.254 (slide 36) • Nastavení směrovacích tabulek routeru 1 – je to na slidu 37, sloupce směrovací tabulky jsou cíl v síti, maska, brána, tzn. pokud chceme poslat data na nějakou adresu (mimochodem síť 0.0.0.0 s adresou 0.0.0.0 znamená všechny adresy), tak ta se porovná s cílem v síti a její maskou a poud to sedí, tak se data pošlou na bránu, co je u toho nastavená (0.0.0.0 znamená asi defaultní brána) • Nastavení NATu – iptables -t nat –A POSTROUTING -o eth2 –j MASQUERADE Pomocné protokoly: ICMP (Internet Control Message Protocol), IGMP(Internet Group Management Protocol), ARP(Address Resolution Protocol), RARP(Reverse Address Resolution Protocol), BOOTP(Bootstrap Protocol),DHCP(Dynamic Host Configuration Protocol), RIP (Routing Information Protocol), OSPF (Open Shortest Path First Routing Protocol), EGP (Exterior Gateway Protocol), BGP (Border Gateway Protocol)...

Přednáška 3 – protokoly linkové vrstvy Použití linkové vrstvy – přenos dat mezi přímo propojenými systémy, dělení proudu bitů na jednotku informace, kontrola integrity dat, adresace v rámci segmentu, zapouzdření dat vyšší vrstvy. Na této vrstvě pracují bitově a znakově orientované protokoly.

Protokol SLIP Serial Line Internet Protocol – vznikl na počátku 80.let, j popsán v rfc1055. Vkládá pakety přímo do sériové linky a pro řízení linky vkládá mezi data tzv. ESCape sekvence. Každý rámec protokolu SLIP je zakončen esc. sekvencí END (c016), většina implementací protokolu SLIP však END umisťuje i na začátek rámce. Jestliže se znak c016 (END) vyskytne i v přenášených datech, pak je nahrazen dvojicí znaků db16, dc16 viz obrázek...

Protokol SLIP definuje pouze zapouzdření paketů na sériové lince (vzpomeň jsi jak jsme přes sériák hráli kdysi Duka).Nedefinuje adresaci, typ paketů,detekci chyb, kompresi ani informace ke konfiguraci. další info na http://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol nebo na http://sunsite.nus.edu.sg/pub/slip-ppp/whatis.html nebo na str. 75 v bibli

Protokol CSLIP Compressed SLIP, neboli varianta protokolu slip používající kompresi, redukuje záhlaví TCP (20b) a IP(taky 20b) (ze 40B na 3 až 16B). Komprimuje se jen záhlaví, nikoliv data. Myšlenka komprese spočívá v tom, že autor se zamyslel nad IP a TCP záhlavím a zjistil, že mnohé údaje v těchto záhlavích se během TCP spojení nemění nebo se mění jen málo, takže stačí přenášet jen změněné položky IP a TCP záhlaví nebo dokonce jen přírůstky těchto položek. Obrázek TCP a IP záhlaví je zde:

Přenáší se tyto změny položek záhlaví: identifikace IP datagramu, SeqN (pořadové číslo odesílaného bajtu), AckN (pořadové číslo přijatého bytu), příznaky, délka okna, kontrolní součet TCP, ukazatel urgentních dat. Ignorují se tyto změny položek záhlaví: délka IP, kontrolní součet IP. Komprese záhlaví komprimuje záhlaví pouze v případě, že se jedná o TCP protokol a v záhlavích se mění pouze uvedené položky. V opačném případě (např. je odeslán ICMP paket, je odeslán UDP datagram, jedná-li se o fragment IP-datagramu, je-li nastaven některý z příznaků RST, SYN, FIN nebo naopak nenastaven příznak ACK atp.) se komprese neprovede a linkou je přenesen nekomprimovaný (nezměněný) rámec. Taktéž se nekomprimuje, pokud se změní jiné položky hlavičky. Kopresi provádí komponenta zvaná kompresor – ta studuje pakety a v případě, že je paket komprimovatelný (jedná se o paket se záhlavím TCP + IP), zkomprimuje ho. v opačném případě ho propustí dále. Komprimované záhlaví obsahuje v prvním bajtu tzv. masku. Jednotlivé bity masky specifikují, které položky v záhlaví originálního paketu se změnily, a proto celé položky nebo jejich přírůstky musí být přenášeny i v komprimovaném záhlaví. Je-li příznak nastaven, pak v komprimovaném záhlaví je uvedena konkrétní položka komprimovaného záhlaví, pokud není nastaven, pak příslušná položka není v komprimovaném záhlaví přítomna. Pro další informace, co který bit masky znamená se mrkni do bible na str. 78. Obrázek CSLIP je na slidu 5/3 a komprimované záhlaví je na slidu 6. Více o CSLIP na http://www.ics.muni.cz/zpravodaj/articles/16.html

Protokol HDLC High Level Data Link Control. Tento protokol provádí detekci chyb a řízení toku dat. Je to protokol podporující synchronní i asynchronní přenos (viz PZA), má velmi rozsáhlou normu, která je výrobci jen částečně implementovaná a mnohdy si výrobci dělají části protokolu podle sebe a tak se mezi různými výrobci u HDLC může projevit nekompatibilita (CISCO HDLC, DEC HDLC). Protokol HDLC má tři přenosové režimy:

•

ABM (Asynchronous Balanced Mode) – používá se pro komunikaci mezi 2 stanicemi. Je full duplex tj. obě stanice mohou vysílat současně, aniž by si vzájemně na lince překážely. Většinou se dnes setkáváme právě s tímto módem. obrázek dole...

•

NRM (Normal Response Mode) – více stanic, half duplex. Pro vysílání i příjem slouží společné přenosové médium, tj. v jednom okamžiku lze buK přijímat, nebo vysílat. Jedna stanice je označena jako řídící stanice a ostatní jako podřízené stanice. Je definován tzv. pooling, tj. řízení, kdy která stanice smí vysílat. Bez povolení smí vysílat pouze řídící stanice. Ostatní stanice mohou vysílat jen tehdy, když jim to řídící stanice povolí. Tento mód je v internetu používán jen výjimečně.

•

ARM(Asynchronous Response Mode) – obdoba NRM, ale stanice může vysílat bez vyzvání. Tento mód se moc nepoužívá. Formát HDLC rámce – slide 8/3 – rámec začíná a končí tzv. křídlovou značkou (pokud jsou dvě křídlové značky po sobě, jedná se o prázdný rámec), křídlová značka je 0111 1110, pokud by bylo náhodou šest jedniček v datech, pak se použije bit stuffing, tzn. pokud máme po sobě 5 jedniček, vložime za ně 0, dále je v rámci adresa, kontrolní součet, data, řídící pole – to dělí rámce na 3 skupiny: • U-rámce – slouží k přenosu dat, ale i pro některé řídící funkce (úvodní inicializační dialog, řzení linky, diagnostiku).Jsou nečíslované(unnumbered) • I-rámce – slouží k přenosu dat, ale mohou ve svém řídícím poli přenášet i některé řídící informace (např pozitivní potvrzení přijatých rámců) • S-rámce se používají k řízení toku dat (požadavek na vyslání a potvrzování rámců) . S rámce zpravidla neobsahují datové pole. Velikost řídícího pole je různá, v závislosti na režimu přenosu, potvrzování může být střídavé, okénkové, pozitivní, negativní... formát HDLC rámce je zde na obrázku:

HDLC dialogy – slide 10 – význam zkratek: • •

•

SABM (Set Asynchronous Balanced Mode) – příkaz nastavuje linku do módu ABM UA (Unnumbered Acknowledgement) - potvrzování řídících příkazů v U rámcich.Sekvenení čísla nepotřebná, protože v jedne chvíli může být vyslán jen jeden (nepotvrzený) příkaz DISC (Disconnect) - informace o vypínáni stanice

• •

FRMR (Frame Reject) - indikuje, ze přišel rámec s nesprávnou sémantikou. DM (Disconnect Mode) - vyjadřuje pozitivní potvrzení příkazu DISC

Více o HDLC na: http://www.elektrorevue.cz/clanky/01026/index.html a bible str. 79

Protokol PPP Point to Point Protocol. Je to podmnožina HDLC protokolu a proto využívá rámce tvaru protokolu HDLC. Nevyužívá však zdaleka všechny možnosti protokolu HDLC. Dokáže používa jak asynchronní, tak i bitově a znakově synchronní přenos dat, pro asynchronní přenos použije 1 start bit, 8 datových bitů a 1 stop bit. Vyžaduje plně duplexní dvoubodové spoje (Point to Point). Cílem protokolu PPP je umožnit po jedné lince přenos více síťových protokolů současně (mixovat protokoly). Nepoužívá I-rámce, ale přenos provádí pouze pomocí U-rámců. Nemůže tedy použít číslování rámců, a tedy ani možnost opakování rámce v případě zjištění chybného rámce. Na počátku datového pole umísťuje osmi nebo šestnáctibitovou identifikaci přenášeného síťového protokolu (takhle umožní mix těch protokolů). Formát rámce PPP – je tam křídlová značka (opět použit bit stuffing), adresa, řídící pole, identifikátor protokolu (zde je identifikován protokol, pomocí něhož se přenáší data, datové protokoly začínají na 0, NCP začíná na 8), data ,kontrolní součet a křídlová značka... viz obr.

Součástí protokolu PPP jsou dva služební protokoly: Protokol LCP sloužící k navázání spojení, autentizaci stanic apod. Dále skupina protokolů NCP. Důležité je množné číslo. Každý síťový protokol, který bude využívat linkový protokol PPP má definovánu vlastní normu pro protokol NCP. Součástí této normy je vždy i číslo protokolu, které se použije v poli protokol rámce, a to jak pro příslušný protokol NCP (číslo začíná číslicí 8), tak i pro datové rámce (číslo začíná číslicí 0). Více o PPP na...http://www.elektrorevue.cz/clanky/01026/index.html Protokol LCP Link Control Protocol – používá se ještě před tím, než se vůbec uvažuje o tom, jaký sí+ový protokol na lince poběží.LCP je společný protokol (na rozdíl od protokolů NCP) pro všechny sí+ové protokoly. Protokol LCP je určen pro navázání spojení, ukončení spojení, výměnu autentizačních informací apod. Linka se nachází postupně ve fázi navazování spojení,

autentizace, síťový protokol a ukončování spojení, jak je znázorněno na obr. Linka začíná vždy ve stavu odpojena.

Autentizace je fáze, kdy klient prokazuje svou totožnost. Slovo klient jsem použil záměrně. Asi jste si položili otázku, kdo je to klient? Klientem je ta strana (stanice), která je vyzvána k prokázání své totožnosti. Po prokázání totožnosti jedné stanice si mohou stanice svou roli vyměnit a k prokázání své totožnosti může být vyzvána druhá strana. V praxi většinou prokazuje svou totožnost jen jedna strana Autentizace probíhá přes nějaký PAP – Password Authentiction Protokol) Fáze síťový protokol v sobě může obsahovat celou řadu kroků.V tomto okamžiku přicházejí ke slovu jednotlivé protokoly NCP. Každý síťový protokol, který chce linku využívat si musí přivést pomocí svého protokolu NCP linku do otevřeného stavu pro tento protokol.Pokud se objeví datové pakety síťového protokolu, pro který není linka otevřena, pak se tyto pakety zahodí. Formát LCP rámce je na obrázku – obsahuje kód (ten specifikuje typ příkazu protokolu LCP , příkazy mohou být např.Conf-Req/Ack/Nack/Rej...), ID (identifikace požadavku Odesílatel zvolí identifikaci do tohoto pole a adresát ji zkopíruje do své odpovědi. Pomocí tohoto pole se určuje příslušnost odpovědi k danému požadavku.), délku (součet velikosti polí kód,ID,délka a volby) a volby (požadavky/odpovědi na změnu parametrů linky)

Více o LCP například zde: http://www.networksorcery.com/enp/protocol/LCP.htm Protokoly NCP Network Control Protocols – jsou to IPCP, IPV6CP, SNACP, DNCP a IPXCP a další. Protokol IPCP Internet Protocol Control Protocol – je to protokol NCP pro protokol IP verze 4. Má ID = 8021, struktura rámce je na obrázku...

Takže kód příkazu , volby (jsou podobné LCP) Pokud dáme jako protokol v rámci PPP číslo 0021, bude nám to posílat nekomprimované pakety, pokud tam dáme 002d, posílá je komprimované...slide 16/3

Protokol Ethernet Předmluva Instituce IEEE před dvaceti lety předložila projekt, jehož cílem bylo vypracovat normy pro jednotlivé typy LAN (např. Ethernet, Arcnet, Token Ring atd.). Tyto normy popisovaly pro každý typ LAN vrstvu MAC. Vznikla tak norma IEEE 802.3 pro Ethernet, IEEE 802.4 pro Token Bus, IEEE 802.5 pro Token Ring atd. Pro všechny systémy pak byla vypracována společná norma pro vrstvu LLC pod označením IEEE 802.2, což schématicky vyjadřuje obrázek.

Problematika linkové vrstvy pro LAN tak byla rozdělena do dvou podvrstev. Spodní vrstva Medium Access Control (MAC) částečně zasahující do fyzické vrstvy se zabývá přístupem na přenosové médium. Horní vrstva Logical Link Control (LLC) umožňuje navazovat, spravovat a ukončovat logická spojení mezi jednotlivými stanicemi LAN. Nyní již o protokolu Ethernet – mnohem více o něm je v bibli na straně 112 Protokol Ethernet byl původně vyvinut firmami DEC, Intel a Xerox. Jeho varianta 10 MHz se označuje jako Ethernet II. Později byl Ethernet normalizován institutem IEEE jako norma 802.3. Tato norma byla převzata ISO a publikována jako ISO 8802-3. Formát rámců podle normy Ethernet II se mírně odlišuje od formátu ISO 8802-3. Postupem času vznikla norma IEEE 802.3u pro Ethernet na frekvenci 100 MHz (Fast Ethernet) a norma IEEE 802.3z pro frekvenci 1 GHz (gigabitový Ethernet). Struktura rámce protokolu Ethernet závisí na použité normě. Probereme si více možných typů... Formát rámce Ethernet II (DIX) – viz obrázek...

je tam nějaká preambule – při ní se synchronizují všechny stanice přijímající rámec, dále DA(destination address)-adresa cíle, SA(source address) – adresa zdroje, adresy mají 24b – jsou to adresy přidělené zařízení výrobcem, prostě adresy MAC (viz

http://en.wikipedia.org/wiki/MAC_address), dále je tam typ (ID) přenášeného protokolu, kde 0800 znamená IP, 0806 ARP, 8035 = RARP, 86DD = IPV6, 88A2 = ATA over ethernet, dále jsou tam data (musí být minimálně 46 B dlouhé, pokud tomu tak není, vyplní se zbytek bezvýznamnou výplní) a nakonec CRC IEEE 802.3 – je to taktéž norma pro Ethernet – tako vá konkurence pro protokol Ethernet II Zabývá se vrstvou MAC. Formát rámce je na obrázku...

Formát rámce je stejný jako u Ethernet II až na to že místo typu protokolu máme pole délka označující délku přenášených dat. Dalším rozdílem je, že datové pole může v sobě nést nikoliv jen data, ale paket protokolu 802.2, jehož záhlaví může být ještě rozšířeno o dvě pole tvořící tzv. SNAP Formát rámce IEEE 802.2 – viz obrázek

Nyní k popisu polí Destination Service Access Point (DSAP)/Source Service Access point (SSAP) specifikují aplikaci cílovou/zdrojovou aplikaci, která rámec odesílá/přijímá. Např. pro IP-protokol se používá DSAP=SSAP=AA16 a pro NetBIOS se používá DSAP=SSAP=F016. Při použití protokolu ISO 8802-2 je možné doručovat data až jednotlivým aplikacím běžícím na stanici. Existují i síťové protokoly, které pro komunikaci na LAN používají pouze tuto adresaci (nepoužívají sí+ovou vrstvu). Použití takových protokolů je sice efektní (o jednu vrstvu jsou rychlejší), ale jsou nesměrovatelné, tj. jsou určeny pouze pro LAN, nikoliv pro WAN. Příkladem takovéhoto exotického protokolu je protokol NetBEUI.Řídící pole je naprosto analogické řídícímu poli protokolu HDLC. Opět mezi stanicemi se může komunikovat pomocí U, I a S-rámců. Rámce mohou být číslovány, v případě ztráty nebo chyby v rámci může být vyžádána retransmise atd. Pro potřeby protokolu IP se používají pouze U-rámce a P/F bit je nastaven na nulu, tj. řídící pole má hodnotu 0316 (obdobně jako v případě protokolu PPP). Pomocí záhlaví SNAP (Sub-network Access Protocol) je možné specifikovat protokol vyšší vrstvy, jedná se tedy o obdobu pole protokol v Ethernetu II. Dokonce pro specifikaci protokolu vyšší vrstvy se používají stejné hodnoty. Jinými slovy co chybělo protokolu ISO 8802-3 oproti protokolu Ethernet II(pole protokol), se krkolomně řeší pomocí záhlaví SNAP.

Porovnání Ethernet II a SNAP:

(co je SNAP (Subnetwork Access Protocol) se dočtete zde: http://en.wikipedia.org/wiki/Subnetwork_Access_Protocol ) Teď tedy to porovnání: SNAP přenáší méně dat a podporuje další typy sítí, výsledek přenosu je u obou stejný, nicméně v internetu je vyžadována podpora Ethernet II

Přednáška 3 – Data Link Layer (diagramy přenosu) Přečti, pokud chceš: http://www.angelfire.com/ut/cnst/chap05.html Možnosti potvrzování – jsou 3 možnosti potvrzování – buď pomocí ACK/NACK, nebo pomocí BCC (block check character – něco jako parita), nebo se vrátí celý rámec s daty. Positivní potvrzování – pokud rámec dorazí, příjemce pošle potvrzení Čistě negativní potvrzování – potvrzení příjemce pošle, pokud rámec nedorazí, positivní potvrzení se neposílají Negativní potvzování – příjemce posílá jak negativní, tak pozitivní potvrzení Číslování rámců – prostě zpět v potvrzení se pošle číslo rámce, který se nyní očekává. Sliding window – posíláme najednou několik rámců a čekáme na potvrzení do určitého timeoutu Selektivní odmítnutí (Selective Reject) - pokud jsme už ten který rámec dostali (například na slidech je to ráemec číslo 1) a příjde k nám podruhé, zašleme odesílateli odmítnutí, ať ho příště už neposílá Sliding Window – duplex – prostě rámce odesílají a přijímají obě strany a na konec odeslaných rámců vždy přiloží potvrzení (tomu se říká piggybacking)

Přednáška 4 –Protokolová rodina TCP/IP – dokončení Obsah přednášky – protokol síťové vrstvy (IP), podpůrné protokoly (ICMP,RARP,BOOTP,DHCP), protokoly transportní vrstvy (UDP,TCP)

Protokol IP Internet Protocol. Jeho úkolem je dopravovat data mezi dvěma libovolnými směrovači v internetu (tzn. i přes mnohé LAN). IP-protokol je protokol, umožňující spojit jednotlivé lokální sítě do celosvětového Internetu. Od protokolu IP dostal také Internet své jméno. Zkratka IP totiž znamená InterNet Protocol. IP-protokol je tvořen několika dílčími protokoly: • Vlastním protokolem IP • Službním protokolem ICMP sloužícím zejména k signalizaci mimořádných stavů • Služebním protokolem IGMP sloužícím pro dopravu adresných oběžníků • Služebními protokoly ARP a RARP, které jsou často vyčleňovány jako na IP nezávislé protokoly, protože jejich rámce nejsou předcházeny IP záhlavím

Má podporu fragmentace (co to je zjistíte zde nebo zde), podporu komunikace přes směrovače, vytváří IP pakety z paketů vyšší vrstvy. IP adresa má velikost 4B. IP protokol pracuje s koncovými uzly a směrovači a je to základní protokol rodiny TCP/IP. Fragmentace – umožňuje vložení IP paketu do kratších rámců nižší vrstvy (MTU Ethernet II je např. jen 1500B – takže si vemte, že máme třeba 64 KB velký IP datagram (64 KB je max velikost IP datagramu), jak ho Směrovač vloží do rámce, který může mít třeba max 1500B?

Směrovač není schopen takový IP-datagram poslat dále. Směrovač se rozhoduje co dále na základě příznaku „Fragmentace možná” (DF bit) v záhlaví IP-datagramu. Příznak „Fragmentace možná” může být buď nastaven nebo ne. Jsou tedy dvě možnosti: • Fragmentace je možná, pak se fragmentace provede (viz dále) • Fragmentace není možna – pak směrovač IP datagram zahodí a odesílatele o tom pomocí ICMP informuje signalizací „Fragmentace zakázána“ (a pokud to směrovač umí, pošle nám, jaké nejmenší MTU je po cestě) Pokud je fragmentace povolena, pak pak směrovač dělí delší IP-datagramy na fragmenty, jejichž celková délka (total length) je menší nebo rovná MTU následující linky ... viz obr

Každý IP-datagram má ve svém záhlaví svou identifikaci, kterou dědí i jeho fragmenty. Díky identifikaci příjemce pozná, ze kterých fragmentů má datagram složit. Nikdo jiný než příjemce není oprávněn z fragmentů skládat původní datagram, tj. ani např. směrovač ze kterého vede linka s takovým MTU, do kterého by se celý datagram již vešel. Důvod je prostý, Internet negarantuje, že jednotlivé fragmenty půjdou stejnou cestou (ani negarantuje pořadí v jakém dojdou). Takže směrovač, který by se pokoušel datagram sestavit by mohl být na závadu spojení, protože fragmentů, které by šly jinou cestou by se nikdy nedočkal. Každý fragment tvoří samostatný IP-datagram. Při fragmentaci je nutné vytvořit pro každý fragment nové IP-záhlaví. Některé údaje (jako protokol vyšší vrstvy, či IP-adresa odesílatele a příjemce) se získají ze záhlaví původního IP-datagramu. Při fragmentaci vstupuje do hry pole „Posunutí fragmentu od počátku IP-datagramu (fragment offset)”, které vyjadřuje kolik bajtů datové části původního IP-datagramu bylo vloženo do předchozích fragmentů. Pole „Celková délka IP-datagramu (total length)” obsahuje délku fragmentu, nikoliv délku původního datagramu. Aby příjemce poznal jak je původní datagram dlouhý, tak je poslední fragment opatřen příznakem „Poslední fragment”. Celý mechanismus je znázorněn na obrázku.

Síť 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í fragment”. Proto se často slova IP-datagram a fragment zaměňují. Mechanismus fragmentace umožňuje i fragmentovat fragment dorazí-li na směrovač jehož odchozí linka má ještě menší MTU. Podpora fragmentace je dána příkazy DF(Don’t fragment) a MF(More Fragments), dále identifikací IP datagramu a také offsetem ve fragmentu Směrování – existuje buď přímé směrování (směrování na uzly ve stejné síti), nebo nepřímé směrování (uzly v různých sítích). Implicitní směrování probíhá přes defaultní bránu. Směrování může být podle směrovacích tabulek rozděleno na statické (informace jsou do tabulky uloženy ručně při konfiguraci směrovače) a dynamické (směrovací uzly si pravidelně vyměňují informace a podle toho tvoří sěrovací tabulky – použito u velkých sítí ). Služby směrovače: podpora předávání paketů (forwarding – viz zde), kontrola a snižování TTL (Time to live-viz zde), přepínání kontrolního součtu, zohlednění ToS(Terms of Service – viz zde) podle priority (precedence - pole o 3b), nízkého zpoždění (delay - 1b) a vysoké propustnosti (throughput – 1p). Struktura IP datagramu – tvoří ji hlavička(záhlaví) a data. Hlavička IP datagramu – je v ní: • verze IP protokolu (4b) • délka záhlaví – je udávána ne v bytech, ale ve čtyřbytech (32b), typ služby (ToS – 5b – je to položka, která nenašla v praxi svého naplnění, měla označovat IP datagramy tak, aby byly některé předávány přednostně a byla tak zaručena rychlá odezva), • celková délka IP datagramu (omezeno na 64KB) • identifikace IP datagramu (tato položka je společně s příznaky a posunutím fragmentu využívána mechanismem fragmentace datagramu) • příznaky (DF =1 -> nefagmentovat, MF = 0 -> poslední fragment) • posunutí fragmentu • TTL (pokud je 0 -> likvidace paketu) • protokol vyšší vrstvy (1-ICMP,2-IGMP,6-TCP,17-UDP...) - je to číselná identifikace protokolu vyšší vrstvy, který využívá IP datagram ke svému transportu . V praxi je

•

• •

použit např. TCP/UDP nebo ICMP, IGMP – tyto dva jsou sice součástí protokolu IP, ale chovají se jako protokoly vyšší vrstvy, tzn. v přenášeném paketu je záhlaví IP následováno záhlavím ICMP resp. IGMP . dále kontrolní součet záhlaví- všimni si – je to pouze kontrolní součet záhlaví nikoliv z datagramu celého, význam tohoto pole je tedy pochybný – navíc když směrovač změní nějakou položku záhlaví, amění se i kontrolní součet, což přináší určitou režii IPadresy příjemce a odesílatele volitelné položky (max 40B např. může být nastavena položka zaznamenávej směrovače či zaznamenávej čas, což může být snadno zneužitelné hackery.Dále jsou tam položky jako explicitní směrování (vyjádřeno, přes které směrovače se má směrovat), striktní explicitní směrování (vypsány všechny směrovače, přes které se směruje), upozornění pro směrovač...viz slide 8) viz obrázek...

Protokol ICMP Internet 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 IP-protokolu. Protokol ICMP svoje datové pakety balí do IP-protokolu, tj. pokud budeme prohlíž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 nejrůznější situace, skutečnost je však taková, že konkrétní implementace TCP/IP podporují vždy jen jistou část těchto signalizací a navíc z bezpečnostních důvodů mohou být na směrovačích mnohé ICMP signalizace zahazovány. Formát ICMP Paketu – Záhlaví ICMP-paketu je vždy osm bajtů dlouhé (viz obr. 5.10). První čtyři bajty jsou vždy stejné a obsah zbylých čtyř závisí na typu ICMP-paketu. První čtyři bajty záhlaví obsahují vždy typ zprávy, kód zprávy a šestnáctibitový kontrolní součet. Formát zprávy závisí na hodnotě pole Typ. Pole Typ je hrubým dělení ICMP-paketů. Pole Kód pak specifikuje konkrétní problém (jemné dělení), který je signalizován ICMP protokolem...viz obrázek

Typy ICMP paketů – určují se typem a kódem, tady jsou: typ kód popis paketu 0 0 echo odpověď 3 x nedoručitelny IP datagram – důvod udává kód...viz dále 3 0 nedosažitelná síť 3 1 nedosažitelný uzel 3 2 nedosažitelný protokol 3 3 nedosažitelný UDP port 3 4 fragmentace zakázána 3 5 chyba explicitního směrování 3 6 neznámá síť 3 7 neznámý uzel 3 9 administrativně uzavřená síť 3 10 administrativně uzavřený uzel 3 11 nedosažitelná síť pro službu 3 12 nedosažitelný uzel pro službu

3 4 5 5 5 5 5 8 9 11 11 11 12 12 12 13 14 17 18

13 0 x 0 1 2 3 0 0 x 0 1 x 0 1 0 0 0 0

komunikace administrativně uzavřena filtrací sniž rychlost odesílání změň směrování ... pro co určuje kód pro síť pro uzel pro síť pro daný typ služby pro uzel pro daný typ služby echo požadavek odpověď na žádost o směrování čas vypršel... proč viz kód TTL defragmentace chybný parametr...jaký viz kód chybné IP záhlaví schází volitelný parametr časová synchronizace – požadavek časová synchronizace - odpověď žádost o masku odpověď na žádost o masku

Některé typy zpráv ICMP: • nástroj Echo - Je jednoduchý nástroj protokolu ICMP, kterým můžeme testovat dosažitelnost jednotlivých uzlů v Internetu. Žadatel vysílá ICMP-paket „Žádost o echo“ a cílový uzel je povinen odpovědět ICMP-paketem „Echo“. Používá se např. u programu PING • nedoručitelný IP datagram – pokud nemůže být IP datagram doručen adresátovi, pak je zahozen a odesílatel je o tomto informován přesně touto zprávou • sniž rychlost odesílání – jestliže je síť mezi odesílatelem a příjemcem přetížena a směrovač není schopen předávat všechny IP datagramy, pak odesílatele informuje touto zprávou, ať je odesílá pomaleji. • změň seměrování – pomocí tohoto ICMP se provádějí dynamické změny ve směrovací tabulce – například touto zprávou upozorní směrovač (koho, co?) další směrovač nebo počítač tehdy, pokud má příchozí paket odeslat na tu cestu, ze které paket přišel. • čas vypršel – například když TTL bylo sníženo na 0 (kód zprávy 1), nebo se signalizuje, že počítač adresáta není schopen z IP fragmentů sestavit celý IP datagram. ICMP paket čas vypršel používají ke své činnosti programy TRACERT (WIN) a TRACEROUTE (Linux) • ... ... ...

Protokol IGMP O něm jen krátce, na slidech to není, ale je to dobré vědět... Protokol IGMP je podobně jako protokol ICMP služebním protokolem (podmnožinou) protokolu IP.Pakety IGMP protokolu jsou baleny do IP-datagramů. Protokol IGMP slouží k šíření adresných oběžníků (multicasts) – To znamená, že si do toho paketu IGMP napíšeme explicitně adresy, na které chceme paket (vyšší vrstvy – např. UDP) poslat a on se nám skutečně pošle na více adres – na tom principu funguje například VLC na Strahově a dobře to šetří síť. Multicasty jsou ale v internetu víceméně nepoužitelné, protože nelze zajisti to, že je všechny směrovače po cestě budou podporovat.

Pokračujeme v povídání o IP ... užitečný protokol, jež IP využívá je protokol ARP Protokol ARP – Address Resolution Protocol - řeší problém zjištění linkové adresy protější stanice ze znalosti její IP-adresy. Řešení je jednoduché, do LAN vyšle linkový oběžník (linková adresa FF:FF:FF:FF:FF:FF) s prosbou: „Já stanice o linkové adrese HW1, IP-adrese IP1, chci komunikovat se stanicí o IP-adrese IP2, kdo mi pomůže s nalezením linkové adresy stanice o IP-adrese IP2? Stanice IP2 takovou žádost uslyší a odpoví. V odpovědi uvede svou linkovou 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 používat i jiné protokoly, které s protokoly TCP/IP nemají nic společného. Jak ARP funguje, resp. to, co bylo popsáno na předešlých řádcích je na obrázku

IP adresa Zajímavosti – jedno síťové rozhraní počítače může mít více IP adres. První adresa se pak obvykle 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 firem a každý se má tvářit jako samostatný WWW-server. Přidělení IP adresy počítači – může být buď statickéí(IP adresa je trvale přidělena ) nebo dynamické (IP adresa se přidělí jen na dobu připojení). Pro přidělování adres se používají protokoly: • RARP -Reverse Address Resolution Protocol – přidělení adresy bezdiskové stanici, moc se nepožívá.

•

•

BOOTP - Bootstrap Protocol – využívá protokolu UDP, slouží ke statickému přidělování parametrů, dokáže přidělit adresu, jméno, masku, směrovače, DNS, time server, forwarding, MTU (co to je MTU viz zde)... DHCP – Dynamic Host Configuration Protocol Protokol DHCP vychází ze zkušeností a částečně v sobě zahrnuje i podporu starších protokolů z této oblasti, tj. protokolů RARP, 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 počítači s operačním systémem UNIX, Windows NT atp. Nebo DHCP-server může být realizován i jako součást směrovače. DHCP se používá k dynamickému přidělování parametrů narozdíl od BOOTP

Transportní protokoly – slouží k přenosu dat mezi aplikacemi, mají podporu aplikačního multiplexu (asi že když máme spuštěné 2 stejné aplikace, tak to neva a data se multiplexují) pomocí portů, podporu řízení toku. K transportním protokolům patří nepotvrzovaný UDP a potvrzovaný TCP

Protokol UDP Něco o tomto protokolu... jinak UDP = User Datagram Protocol Protokol UDP je jednoduchou alternativou protokolu TCP. Protokol UDP je nespojovaná služba (na rozdíl od protokolu TCP), tj. nenavazuje spojení. Odesílatel odešle UDP datagram příjemci a už se nestará o to, zdali se datagram náhodou neztratil (o to se musí postarat aplikační protokol). Záhlaví UDP -... viz obrázek

Z předchozího obrázku je patrné, že záhlaví UDP protokolu je velice jednoduché. Obsahuje čísla zdrojového a cílového portu – což je zcela analogické protokolu TCP. Opět je třeba dodat, že čísla portů protokolu UDP nesouvisí s čísly portů protokolu TCP. Protokol UDP má svou nezávislou sadu čísel portů. Pole délka dat obsahuje délku UDP datagramu (délku záhlaví + délku dat). Minimální délka je tedy 8, tj. UDP datagram obsahující pouze záhlaví a žádná data. Zajímavé je že pole kontrolní součet nemusí být povinně vyplněné. Výpočet kontrolního součtu je tak v protokolu UDP nepovinný. Pakliže se kontrolní součet počítá, pak se podobně jako pro protokol TCP počítá ze struktury (pseudozáhlaví)znázorněné na obrázku

Fragmentace - I u UDP datagramů je možná fragmentace v IP-protokolu. Avšak u UDP protokolu se zásadně snažíme fragmentaci vyhýbat. Oběžníky - Na první pohled by se zdálo, že protokol UDP je chudým příbuzným protokolu TCP. Může však existovat něco, co umí protokol UDP a nelze to udělat protokolem TCP? Právě zvláštností protokolu UDP je skutečnost, že adresátem UDP datagramu nemusí být pouze jednoznačná IP-adresa, tj. síťové rozhraní konkrétního počítače. Adresátem může být skupina stanic – adresovat lze i oběžník. Adresovat lze všeobecné oběžníky (broadcast), ale podstatně zajímavějším případem je adresování adresných oběžníků (multicast). Např. u aplikací typu RealAudio navazuje každý klient spojení se serverem. Kdežto u ProgresiveRealAudio se šíří data pomocí adresných oběžníků, tj. dochází k ohromné úspoře kapacity přenosových cest. A právě to je příležitost pro UDP. Pomocí UDP multicast pracuje i přenos televize na Strahově Kecy ze slidů... User Datagram Protocol, je to nepotvrzovaná služba bez spojení, umožňuje broadcast, pracují přes něj DNS, Bootp, TFTP, SNMP... Formát datagramu UDP – slide 16... budu říkat jen to barevné, zbytek je z IP paketu. Takže hlavička obsahuje volitelné položky hlavičky, zdrojový a cílový port UDP, délku dat a kontrolní součet (nepovinný, ale aplikace jej mohou vyžadovat, vypočítává se z pseudohlavičky). Pseudohlavička neobsahuje volitelné položky hlavičky a z toho IP je tam mnohem méně ... viz slide 17

Protokol TCP Něco o tomto protokolu – jinak TCP = Transmision Control Protocol Zatímco protokol IP přepravuje data mezi libovolnými počítači v Internetu, tak protokol TCP dopravuje data mezi dvěma konkrétními aplikacemi běžícími na těchto počítačích. Protokol IP adresuje IP-adresou pouze sí;ové rozhraní počítače. Pokud bychom použili přirovnání k běžnému poštovnímu styku, pak IP-adresa odpovídá adrese domu a port (adresa v protokolu TCP) pak odpovídá jménu konkrétního obyvatele domu. Protokol TCP je spojovanou službou (connection oriented), tj. službou která mezi dvěma aplikacemi naváže spojení – vytvoří na dobu spojení virtuální okruh. Tento okruh je plně duplexní (data se přenášejí současně na sobě

nezávisle oběma směry). Přenášené bajty jsou číslovány. Ztracená nebo poškozená data jsou znovu vyžádána. Integrita přenášených dat je zabezpečena kontrolním součtem. Konce spojení (“odesílatel” a „adresát”) jsou určeny tzv. číslem portu. Toto číslo je dvojbajtové, takže může nabývat hodnot 0 až 65535. Základní jednotkou přenosu v protokolu TCP je TCP segment. Někdy se také říká TCP paket. Proč segment? Aplikace běžící na jednom počítači posílá protokolem TCP data aplikaci běžící na jiném počítači. Aplikace potřebuje přenést např. soubor velký 2 GB. Jelikož TCP segmenty jsou baleny do IP datagramů, který má pole dé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 – 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 přenášeného linkového rámce (MTU), pak IP protokol musí provést fragmentaci IPdatagramu Nyní nějaká fakta ze slidů... Transmission Control Protocol – je to spolehlivá spojovaná služba, podporuje multiplex i duplexní přenos (piggybacking), dále také proudový přenos (stream – navážeš spojení, vytvoří se nějaký tunel a přes to to běží), umožňuje potvrzování a opakování segmentů, adaptivní přizpůsobení parametrů, má implementované sliding window, umožňuje vytváření a rušení transportních spojení, příjem dat z vyšší vrstvy a vytváření TCP paketů, koncové řízení toku. TCP využívají protokoly http, ssh, telnet Hlavička (záhlaví) TCP – viz obrázek...

Hlavička TCP má tyto pole: • zdrojový a cílový port TCP- je to port odesílatele a port příjemnce. Pětice zdrojový port, cílový port, zdrojová IP, cílová IP a protokol (typ protokou) jednoznačně identifikuje v daném okamžiku spojení v internetu. • pořadové číslo odesílaného bytu (číslo prvního bytu) – TCP segment je část z toku dat tekoucích od odesílatele k příjemci. Pořadové číslo odesílaného bytu je pořadové

číslo prvního bajtu TCP segmentu v toku dat od odesílatele k příjemci (TCP segment nese bajty od pořadového čísla odesílaného bajtu až do délky segmentu) • , pořadové č. očekávaného bytu(poslední dobře přijatý byte + 1) vyjadřuje číslo následujícího bytu, který je příjemce připraven přijmout, tj. příjemce tak vlastně potvrzuje, že úspěšně přijal data do (pořadové_číslo_očekávaného_ bytu - 1) • délka záhlaví – vyjedřuje délku TCP záhlaví, je v násobcích 32b • rezerva • příznaky (URG – TCP segment nese urgentní data, ACK – potvrzení, PSH – TCP segment nese aplikační data, RST-odmítnutí TCP spojení, SYN – Odesílatel začíná s novou sekvencí číslování, FIN – odesílatel ukončil odesílání dat) • délka okna – vyjadřuje maximální přírůstek čísla přijatého bytu, který bude příjemcem ještě akceptován • kontrolní součet TCP • ukazatel naléhavých dat – může být nastaven pouze tehdy, je-li nastaven příznak URG. Přičte li se tento ukazatel k pořadovému číslu odesílaného bytu, pak ukazuje na konec úseku naléhavých dat. Odesílatel si přeje, aby příjemce tato data přednostně zpracoval. K poli volitelné položky: oproti položkám UDP se používají a přenáší. Volitelná položka se skládá z typu volitelné položky, délky volitelné položky a hodnoty. Na tyto položky zbývá 40B TCP záhlaví. Mezi volitelné položky patří např.: maximální délka segmentu, zvětšení okna, časové razítko, čítač spojení. Navázání TCP spojení - klient začíná navazovat spojení odesláním prvního TCP segmentu. Tento TCP 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é použije jako startovací pořadové číslo odesílaného bajtu (tzv. ISN). V našem případě bylo vytvořeno ISN=145165778. Skutečnost, že klient právě vytvořil startovací pořadové číslo odesílaného bajtu vyznačí v TCP segmentu nastavením příznaku SYN (….S.). Během spojení již pořadové číslo odesílaného bajtu bude vždy vyjadřovat číslo odesílaného bajtu, tj. nemůže být znovu vygenerováno. Obrázek navazování spojení je tady:

Segment (1) je prvním segmentem v TCP komunikaci, proto nemůže potvrzovat žádná přijatá data. Pole pořadové číslo přijatého bajtu nemá platný význam (bývá vyplněno binárními nulami) a nemůže být tedy ani nastaven příznak ACK (příznak ACK je nastaven ve všech dalších TCP segmentech až do ukončení spojení). Součástí segmentů (1)a (2) byla volitelná položka záhlaví TCP segmentu MSS (Maximum segment size). Tato položka oznamuje druhé straně maximální délku datové části TCP segmentu jakou si přeje přijímat (aby se pokud možno zamezilo fragmentaci IP-datagramu). Implicitně se MSS používá 536 bajtů. Tato hodnota je používána pro spojení mimo lokální sí; (přes WAN). Pro náš příklad jsme použili spojení v rámci lokální sítě protokolem Ethernet II. Pro linkový protokol Ethernet II je maximální délka datové části rámce rovna 1500. Pokud od 1500 odečteme 20 pro IP-záhlaví a dalších 20 pro TCP záhlaví, pak dojdeme k hodnotě z našeho příkladu (1460). Takže pokud to shrneme...,tak... stavy při navazování spojení jsou : LISTEN (server je připraven na spojení s klienty), SYN_SEND (klient odeslal první TCP segment) a SYN_RCVD (server přijal od klienta první TCP segment, tj. segment s příznakem SYN), potom je spojení ESTABLISHED, tedy ustanoveno...viz obrázek

Ukončování spojení TCP - Zatímco spojení navazoval v architektuře klient/server zpravidla klient, tak ukončit spojení může libovolná strana. Strana, která první odešle TCP segment s příznakem FIN (ukončení spojení) provádí tzv.aktivní ukončení spojení (active close), druhé straně nezbývá než provést pasivní ukončení spojení (pasive close). Teoreticky je možné i současné ukončení spojení. Stavy při ukončování spojení: • FIN_WAIT1 (strana zjistila, že už všechna data odeslala, a potřebuje např. signalizovat konec souboru, tak v TCP segmentu nastaví příznak FIN, čímž signalizuje aktivní ukončení spojení ) • CLOSE_WAIT (druhá strana obdržela aktivní uzavření spojení a nezbývá jí nic jiného než potvrdit segmentem přechod do pasivního uzavření spojení – tomuto stavu odpovídá právě CLOSE_WAIT) • FIN_WAIT2 ( toto je stav poté, co strana obdrží potvrzení aktivního uzavření spojení od protějšku. Ve stavu FIN_WAIT2 strana zůstává do té doby, dokud protějšek nezašle TCP segment s příznakem FIN, tj. do přechodu do stavu TIME_WAIT. Pokud

• •

•

aplikace nepočítá s přenosem dat v polouzavřeném spojení, a spojení je nečinné po 11,25 minuty, pak operační systém automaticky změní stav spojení na CLOSED.) LAST_ACK – druhá strana již odeslala všechna data a signalizuje úplné končení spojení TIME_WAIT - všechna data oběma směry již byla přenesena. Je nutné pouze potvrdit úplné uzavření spojení. Odesláním TCP segmentu ) je potvrzeno úplné ukončení spojení. Tento segment již není potvrzován, proto strana zůstává ve stavu TIME_WAIT po dobu 2 minut (některé implementace TCP/IP zkracují tuto dobu až na 30 s). CLOSED – druhá strana obdržela potvrzení úplného uzavření spojení a přechází do stavu CLOSED. Strana, která odeslala toto potvrzení (segment) přechází do CLOSED až po uplynutí zmíněného intervalu.

Stavy při uzavírání spojení jsou dobře vidět na obrázku...

Vylepšení provozu TCP – sloučení dat a potvrzení (piggyback), technika okna (viz bible strana 234), vyhnutí se zahlcení sítě a výpadku segmentu (jak, to je na slidech, ale já to teda nechápu...), nastavení správného timeoutu

Přednáška 5 –Síťová vrstva –směrování Předmluva Směrování provádí zařízení zvané směrovač. Zjednodušeně řečeno směrovač je zařízení, které př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, takže o tom odesílatele IP-datagramu upozorní ICMP-paketem „redirect”. („změň směrování“). Směrovači k rozhodování slouží směrovací tabulka. Příklad takovéto tabulky je na obrázku...

Směrovací tabulka má v prvním sloupci IP-adresu cílové sítě. Představme si pro jednoduchost, že směrovací tabulka je podle prvního sloupce sestupně tříděna. To nám umožní snadno aplikovat základní pravidlo směrování: Více specifická adresa cílové sítě má přednost před méně specifickou. Více specifickou adresou sítě se rozumí adresa, která má v síťové masce více jedniček. V případě, že by se ve směrovací tabulce našly dvě či více cest k cíli, pak se zvolí více specifická cesta. V případě, že se najdou dvě stejně specifické cesty, pak se zvolí cesta s nejnižší metrikou (cenou). V případě, že jsou řádky směrovací tabulky sestupně tříděny, pak stačí směrovací tabulku procházet odshora dolů. Na každém řádku se vezme sí;ová maska, kterou se bit po bitu vynásobí IP-adresa příjemce IP-datagramu. Výsledek se porovná s prvním sloupcem. Pokud se výsledek nerovná IP-adrese sítě v prvním sloupci, pak se přejde na zpracování následujícího řádku. Pokud se výsledek shoduje s IPadresou v prvním sloupci, pak se ještě otestuje následující řádek, zdali ve směrovací tabulce neexistuje ještě k cíli jiná cesta, (pak by vstoupila do hry metrika). Poslední řádek obsahující v prvním sloupci 0.0.0.0 s maskou 0.0.0.0 se nazývá default. Tímto implicitním směrem jsou pak odesílány všechny IP-datagramy, pro které nevyhovoval žádný jiný řádek směrovací tabulky (všimněte si, že vyhovuje každé IP-adrese: nula krát nula je nula). Implicitní směr ve směrovací tabulce může a nemusí být – závisí to na správci, jak tabulku naplnil. Implicitní směr používají např. firmy pro cestu do Internetu. Způsoby přenosu dat: • přepojování kanálů – celý přenosový kanál je vyhrazen pro jednoho uživatele až do ukončení přenosu • přepojování zpráv – zpráva se posílá jako celek, nedělí se na pakety • přepojování paketů - umožňuje sdílení přenosového kanálu více uživateli - ihned po vyslání paketu se kanál uvolní a může tedy vysílat i jiný uživatel

Způsob doručení: • virtuální kanál – Je vedený sítí a všechny pakety spojení prochází přes tento kanál. V případě, že se spojení někde přeruší, je vytvořen nový kanál a poté se mohou opět přenášet data...viz obr...

Je to jakoby roura, kterou proudí data jedním šměrem, je vytvořena pospojováním síťových elementů. Kanál má své identifikační číslo a přenášené datové jednotky jsou do tohoto kanálu vloženy s jeho identifikačním číslem v záhlaví. Projdou pak pomyslným virtuálním kanálem až k adresátovi. Výhodou tohoto přenosu je to, že datové jednotky prochází všechny stejnou cestu se stejným zpožděním a ve stejném pořadí, což u datagramové služby zajistit nelze. IP protokol virtuální kanály nepoužívá. (více na http://cag.csail.mit.edu/PSRG/papers/dally-ieee92.pdf) • datagramová služba - je obdoba klasické pošty, tedy datová jednotka je vložena do přístupového bodu sítě a má kompletní informace pro cestu k adresátovi. Virtuální kanály – propojovací tabulky – slide 4... v tabulce směrovače je pro každý kanál jeden řádek, v řádku jsou uvedeny uzly, které kanál propojuje (ty jsou vždy jen 2 – kanál se totiž nemůže rozdělit) a „vzdálenost“ k těmto uzlům. Směrovací metody: záplavové směrování, náhodné směrování, izolované směrování (buď „horký brambor“ nebo „zpětné učení“),statické směrování, adaptivní směrování(buď „distance vector“ nebo „link state“), hierarchické směrování • záplavové směrování – viz slide 6 – 11 – každý směrovač vyšle paket do všech směrů kromě toho směru (resp. „těch“ směrů, paket totiž může přijít ke směrovači i z více směrů), z nějž paket přišel. Poté co se takto odešle, zjistí se nejkratší cesta (dijkstrovým algoritmem, protože síť je vlastně graf, že ano), přes niž bude probíhat směrování. Negativem může být zahlcení sítě při zjišťování cesty, proto je potřeba nadbytečné pakety likvidovat. To se dá buď pomocí TTL, informace ve směrovači nebo informace v paketu. • náhodné směrování – odesílání paketu na náhodný výstup. Toto směrování, ale nezaručuje omezenou dobu doručení a potřebuje dodatečné informace. • horký brambor – odesílání paketu do nejkratší fronty (paketů). Stejně jako náhodné směrování nezaručuje omezenou dobu doručení a potřebuje dodatečné informace. • zpětné učení – využívá informaci o času/počtu průchodů paketu směrovačem (tato informace je uložena v paketu). Směrovač má pro tuto metodu tabulku, která obsahuje odesílatele, nejkratší čas a směr odkud paket přišel. Tuto metodu je nutno kombinovat s jinou metodou. Při nějaké chybě se metoda pomalu adaptuje.

•

•

•

statické směrování – prostě ručně nastavíme tabulky při návrhu sítě nebo při změně její topologie. Nereaguje však na změnu topologie, nicméně jej můžeme využít například při nějakém výpadku síťových prvků. Nepodporuje rozdělení toku (řešením může být stochastické směrování). Jinak statické směrování se dá kombinovat s předchozími metodami. adaptivní směrování – opakovaný výpočet směrovacích tabulek při provozu sítě. Ten výpočet může být buď centralizovaný nebo distribuovaný. Toto směrování závisí na metrice, bezpečnosti,množství přenášené informace...Je možné jej kombinovat s předchozími metodami. Adaptivní směrování používá například „Distance vector algoritmy“, kdy probíhá výměna kompletních směrovacích tabulek. To ale velmi zatěžuje síť a má to pomalou konvergenci (reakci na chyby), zvláště při výpadku. Toto směrování používají protokoly RIP, IGRP, EIGRP, BGP delta směrování - dohledat...

protokoly RVP – ve slidech označené jako distance vector Protokoly RVP (Routing Vector Protocols) pracují tak, že si sousední směrovače mezi sebou vyměňují obsahy směrovacích tabulek (vektorem se míní jedna položka směrovací tabulky). Obdržím-li jednotlivé vektory ze směrovací tabulky svého souseda, pak si z nich mohu vybrat vektory, které ve vlastní směrovací tabulce nemám a doplnit je do vlastní směrovací tabulky. Nesmím zapomenout u takto doplněné položky zvýšit metriku. Tyto protokoly jsou jednoduché a snadno se implementují. Jejích nevýhodou je, že ve větších rozsáhlých sítích může výměna vektorů oscilovat a pak některé vzdálenější sítě mohou být chvilku dostupné a za okamžik již nikoliv. Většími sítěmi se rozumí sítě o více jak 10 LAN. Příkladem protokolů RVP jsou protokoly RIP a RIP 2. Jelikož jsou protokoly RVP vhodné pro menší rozsáhlé sítě, pak je vždy otázkou, zda-li se bude konfigurace sítě opravdu natolik dynamicky měnit, nebo se sice pracněji, ale lépe nakonfigurují směrovače ručně pomocí statických položek.

Protokol RIP Routing Information Protocol. Jeho metrikou je počet směrovačů, přes které se jde k cíli. Spoléhá na komunikaci se sousedy, prostě si směrovače mezi sebou (pomocí bradcastů) vyměňují obsahy směrovacích tabulek. Při směrování je nalezena pouze jedna cesta (ta nejkratší) od odesílatele k cíli. Nevýhodou je, že v tomto protokolu není v položce směrovací tabulky uváděna síťová maska. Proto lze protokol RIP použít jen tehdy, když v síti používáme pouze sítě se standardní maskou. Vylepšením je RIP2, který pracuje navíc s maskou podsítě, požaduje autorizaci a podporuje multicast. Docela dobré info o RIP je zde... ještě víc o RIP je ve sriptech na straně 91 RIP výpočet (viz slidy 18-28): Tento algoritmus vytváří přímo routovací tabulky.Tabulky směrovačů i uzlů obsahují identifikaci směrovačů (ve slidech písmenem) a vzdálenost k nim. Původně má v tabulce směrovač sám sebe a se vzdáleností 0. Takže, nyní: 1) každý směrovač vyšle do všech směrů iformace o své tabulce. Ty informace co k němu v „prvním kole“ dojdou identifikují bezprostředně okolní směrovače (tedy ty se vzdáleností 1) 2) Opakuje se bod 1 s tím, že nyní proudí již od každého směrovače informací (každý směrovač pošle tzv. update) více. Podle toho si předělá ten který směrovač svou tabulku. Prostě například E ví, že mu B poslalo update, v němž je informace, že H je od 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 3) To se opakuje celkově tolikrát, kolikrát je to zapotřebí, prostě směrovače tu tam rozešlou update.

RIP – výpadek linky – může způsobit problém – dobře je to popsáno ve skriptech na str. 93. Podívejte se na obrázek...

Problém je ten, že pokud vypadne ze sítě uzel A, uzly si postupně navyšují jeho vzdálenost Dejme tomu, že situace na počátku je 0 1 2 3 4, Nyní se A čko je odpojí, takže vzdálenost B od A uvedená v tabulce B je neplatná, proto čeká na informaci od C, to mu pošle, že A je od něj vzdáleno o 2, proto si B zapíše do své tabulky vzdálenost 3, nyní proběhne další update: B 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 vzdálenost nenavyšovaly donekonečna, je nutné zavést nějakou max hranici, po kterou se bude zvyšovat (tzv. nekonečno), tato hranice je u RIP stanovena na 16. Proto tedy trvá docela dlouho, než se RIP adaptuje na výpadek linky. Ze stanovení nekonečna také plyne to, že uzel se vzdáleností 16 a více je označen jako nedostupný.Naopak adaptace RIP na „dobré zprávy“ (změna v síti) je rychlá. Pro rychlejší adaptaci na „špatné zprávy“ lze zavést algoritmus split horizon (v našem příkladě to znamená, že uzel C vdálenost od A, kterou získal od B, béčku zpět nepředá, tzn. B přijme pouze aktualizace z jiného uzlu), dalším ztychlením je algoritmus reverse poisson( C béčku předá vzdálenost od A rovnou jako nekonečno)

protokoly LSP Link State Protocols - Protokoly LSP pracují na zcela odlišném principu. Každý směrovač si zjistí, jaké směrovače má za své sousedy a v pravidelných intervalech testuje jejich dostupnost. Celou síť pak zaplavuje svými oběžníky o tom, koho má za své sousedy. Takže každý směrovač má od všech ostatních směrovačů zprávu o tom jaké mají sousedy. Takže každý směrovač má seznam všech cest v síti. Na 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 obdržených od ostatních směrovačů. U rozsáhlých sítí je problematické zaplavovat je velkým množstvím informací ze směrovačů, proto se takové sítě rozdělí na oblasti a zmíněný postup se aplikuje pouze v rámci této oblasti. Na hranicích se sousedními oblastmi jsou hraniční směrovače, které si pak vyměňují informace o celých oblastech.

Protokoly LSP jsou oproti protokolům RVP nesrovnatelně stabilnější a lze je aplikovat i u velmi rozsáhlých sítí. Nevýhodou je, že návrh sítě, tj. rozdělení sítě na oblasti musí provést zkušený odborník, rovněž konfigurace je netriviální. Pokud se použije protokol typu LSP bez větších zkušeností, tak je také možné, že některými linkami data prostě nepotečou a jiné budou přetížené. Příkladem protokolu LSP je třeba protokol OSPF.

protokol OSPF Open Shortest Path First – dělí sítě na oblasti, kde každá oblast je očíslovaná (32 b číslem). Oblast číslo 0 je tzv. páteř (backbone) Směrovače se rozdělí na interní, hraniční nebo páteřní podle toho, kde směrovač leží...viz obr. slide 46. Směrování probíhá buď uvnitř oblasti nebo mezi oblastmi (vždy přes oblast 0). Propojení sítí je buď přes autonomní systém nebo přes hraniční směrovač autonomního systému (viz slide 47/5). Algoritmus používá autorizaci (buď žádnou nebo jednoduchou nebo pomocí MD5). OSPF zprávy – jsou to LSA (Link State Advertisments) zprávy, tyto zprávy mohou být zasílány jen ve své oblasti (tedy ne mezi oblastmi). Typy paketů jsou: hello (pro testování a nestavení spojení), popis databáze (popis databáze stavů linek) , požadavek stavu linky (vyžádání konkrétní části databáze stavů linek), aktualizace stavu linky (LSA o lince směrovače, o síťové lince...), potvrzení stavu linky (potvrzení příjmu paketu) OSPF metriky – automatické – automaticky vypočtené směrovači, nemusí být implementovány, mohou se dynamicky měnit, cena je 100 000 000/šířka pásma [bps](??), implicitní – jsou v celé síti stejné, jsou vhodné pro homogenní prostředí, manuální – jsou pevně nastavené

Protokoly IGP a EGP – ve slidech označené jako skupina exterior algoritmy Protokoly IGP jsou určeny pro činnost v rámci autonomního systému. Již zmíněné protokoly RIP, RIP2, OSPF jsou vesměs protokoly IGP.Ovšem poskytovatelé Internetu si mezi sebou potřebují také vyměňovat směrovací informace. Poskytovatelé Internetu pro výměnu směrovacích informací mezi autonomními systémy používají protokoly EGP. V dnešní době používají protokol BGP (Border Gateway Protocol) verze 4.Protokoly EGP se liší od protokolů IGP zejména tím, že ve směrování umožňují zohlednit směrovací politiku (tj. kdo komu platí). Agregace - Agregace je proces, kdy se z několika položek směrovací tabulky udělá jedna položka. Tento proces je žádoucí např. při propagaci sítí vně autonomního systému. Jednu položku můžeme z více udělat tehdy, když sítě slučované do jedné položky vytvoří supersíť. Automatická agregace je spíše přání než realita. Poskytovateli většinou vypadnou z jeho supersítí některé adresy, které ještě nikomu nepřidělil, takže nelze automaticky agregovat všechny IP-adresy autonomního systému do jedné nebo několika málo položek. Prakticky se agregace provede ručně tak, že se vně autonomního systému propagují všechny IP-adresy, které jsou přiděleny. Redistribuce - Na obrázku dole je otazníkem označen směrovač, který si vyměňuje současně směrovací informace protokoly BGP, OSPF, RIP a k tomu možná má ve směrovací tabulce několik statických položek. Otázka je, zdali se mají informace (položky směrovací tabulky) získané jedním směrovacím protokolem propagovat do ostatních směrovacích protokolů, tj. má-li se provést redistribuce.

Znamená to tedy vlastně to, že položka ve směrovací tabulce musí v sobě nést informaci, jakým protokolem byla vytvořena BGP – Border Gateway Protocol – zajišťuje směrování a řízení provozu mezi autonomními systémy, přiděluje autonomním systémům jednoznačné identifikátory. Používá Distance Vector Algoritmus. Směrovače jsou propojeny pomocí TCP. Slouží k připojení zákazníků s více cestami do internetu. Obrázek jak to celé vypadá je na slidu 52 anebo se podívej na obrázek nahoře (myslím ten s AS1 a AS2).

Přednáška 6 –QoS Quality of Service Kvalita služeb – je to opatření snažící se zaručit koncovému uživateli doručení dat v potřebné kvalitě. Uplatňuje se u přenosu multimédií, IP telefonii atd. Kvalita služby je ovlivněna stanicemi (uživatelé a servery), směrovači, přepínači a linkami (mezi směrovači nebo na LANce) Sdílení kapacity sítě – v jednoduché síti typu Internet se všichni uživatelé dělí o prostředky sítě stejným dílem (100 uživatelů a linka 100 Mbit/s -> 1 Mbit/s na každého), většinou není rychlost problém, některé aplikace (např. IP telefonie) nemusí fungovat. Jaké jsou možnosti Qos v tomto případě? • Rezervovat přenosovou kapacitu jen pro daný kanál • Nastavit vyšší prioritu některým službám a zkrátit jejich odezvu • Omezit přenos na definovaný limit (např. omezení FTP tak, aby bylo možno při tom surfovat) • Definovat maximální zpoždění dat - vemte si například, že sledujete video – tam je žádoucí, aby zpoždění dat bylo minimální, naopak u HTTP nějaké to zpoždění moc nevadí Příklad sítě bez a s QoS: bez: slide 5 – tok se dělí rovnoměrně mezi kompy, s: slide 6 – komunikace mezi 2 počítači si žádá tok 1 Mbps. Tak jim ji dáme a ostatním rozdělíme ten zbytek. Parametry tvořící QoS: šířka pásma (= rychlost přenosu dat), jednosměrné zpoždění (tzn. čas potřebný pro přenesení paketu přes fyzické médium, což zahrnuje i čas způsobený řazením paketů do front), rozptyl zpoždění (to jak zpoždění kolísá), ztrátovost paketů. K tomu aby to celé funcovalo co nejlépe, je nutno zavést nějaké...

...Plánovací mechanismy: FIFO, prioritní FIFO, Round Robin, WFQ, Leaky Bucket, Leaky Bucket + WFQ... popis: • FIFO – slide 9 – pakety přicházejí ve frontě a postupně jsou obslouženy • Prioritní FIFO – slide 10 nebo obrázek...

•

•

•

pakety jsou ukládány jak do fronty, tak do prioritní fronty. Pakety z prioritní fronty mají vždy přednost...viz zde Round Robin – dejme tomu že máme dvě fronty – jednu prioritní a druhou ostatní. Pakety se obsluhují postupně tak, jak přicházejí, ale pokud příjde najednou paket z fronty ostatních a z prioritní fronty, má přednost ten z té prioritní. (tady ovšem moc nechápu jeký je rozdíl oproti prioritní FIFO) WFQ – weighted fair queuing – každý datový tok má svoji frontu, každá tato fronta má svou váhu. Tyto fronty jsou obsluhovány současně tak, aby se na každou dostalo, ale samozřejmě prvků s nejvyšší váhou jde k obsluze asi nejvíc... viz obr.

Leaky Bucket – neboli děravý kýbl – viz zde nebo viz obrázek... na tomto obrázku jsou ovšem pakety na které nezbyly tokeny, zahozeny. Podotýkám, že tomu tak nemusí být, pakety mohou třeba jen čekat (sice se tím způsobí nějaké zpoždění, ale pokud to neva, tak co). To co je na obrázku bych viděl jako Leaky Bucket pro UDP

•

Tak, nyní k principu. Zásobník má nějaký maximální počet tokenů, který jej může naplnit. Tokeny přibývají rychlostí x tokenů za sekundu. Do té doby, než se zásobník naplní, příchozí pakety čekají. Poté co se naplní, jsou pakety odeslány po řadě maximální možnou rychlosí do sítě (tu rychlost označme B) a zásobník se vyprazdňuje rychlostí Bt (t=čas). Poté co se zásobník tokenů vyprázdní, nezbývá dalším paketům čekat, než se opět naplní. Leaky Bucket + WFQ – máme n front (označených váhou), přičemž každá obsahuje v sobě navíci Leaky Bucket ... viz slide 14

Co říká na QoS IP Protokol? IP protokol má v hlavičče informační pole ToS (Type of Service), jehož hodnoty znamenají toto: hodnota: význam 1000 minimalizuj zpoždění 0100 maximalizuj propustnost 0010 maximalizuj spolehlivost 0001 minimalizuj finanční náklady 0000 normální služba ToS v aplikacích - ... viz slide 16, tam je napsané, pro jaké aplikace se používají jaká nastavení ToS. Např. pro telnet je to 1000 (minimalizacee zpoždění), pro ftpdata je to 0100 (maximalizuj propustnost)... je to celkem logické nastavení nebo ne?...

TCP protokol a řízení toku Efektivně lze omezovat pouze odchozí tok dat, pro příchozí musíme použít nepřímé metody. Můžeme například pozdržet odeslání potvrzení a tím prodloužit RTT (Round Trip Time – co to je viz dále ), ale pozor na timeout, který by po vypršení způsobil opětovné odeslání dat. Dále můžeme měnit velikost okénka. RTT v TCP – Zpoždění je čas, který uplyne od odeslání zprávy zdrojovým uzlem po její přijetí na uzlu cílovém. Zahrnuje zpoždění v přenosové trase a na zařízeních, které jsou její

součástí. Je nutné rozlišit zpoždění jednosměrné (čas mezi odesláním paketu zdrojem a jeho přijetí cílem) a zpoždění obousměrné, tzv. round-trip latency, zahrnující dobu cesty paketu tam i zpět plus čas jeho zpracování cílem. Round-trip latency nebo také Round Trip Time (RTT) se v síťové praxi požívá nejčastěji, protože jej lze změřit z jednoho místa (uzlu). Od RTT se odvozuje timeout. Jenže...jak dopředu zjistit hodnotu RTT? Mějme SampleRTT = posledně naměřený RTT, EstimatedRTT = očekávaný RTT. Pak platí: EstimatedRTT = (1 − α ) ⋅ EstimatedRTT + α ⋅ SampleRTT kde α = 0,125 Pěkný graf na SampleRTT a EstimatedRTT je na slidu č.19. TCP Timeout – jak se odvozuje od RTT? DevRTT = (1 − β ) ⋅ DevRTT + β ⋅ ( SampleRTT − EstimatedRTT ) kde β = 0, 25 DevRTT popisuje proměnlivost RTT. Nyní konečně ten vzoreček pro timeout: Timeout = EstimatedRTT + 4 ⋅ DevRTT ... timeout se po každé ztrátě paketu zdvojnásobí TCP technika okna - Nyní je naším problémem případ, kdy klient potřebuje odeslat velké množství dat. Klient (resp. Server) může odesílat data druhé straně aniž by jejich příjem měl potvrzen až do tzv. okna (Window – zkratkou WIN). Představme si (viz obrázek), že klient se serverem navázal spojení a vzájemně se dohodli na maximální velikosti segmentu (MSS) o velikosti 1 K (tj. 1024 B) a vzájemné velikosti okna 4 K (tj. 4096 B).

Klient začne s odesíláním dat, odešle segmenty 1, 2 a 3. Poté obdrží od serveru potvrzení (4), které potvrzuje segmenty 1 a 2. Klient v zápětí odesílá segmenty 5, 6 a 7. Jenže server data mezitím nedokázal zpracovat a data mu zaplnila vyrovnávací pamě;, proto segmentem 8 sice potvrdí příjem segmentů 3, 5, 6 a 7, ale zároveň klientovi uzavře okno, tj. klient nemůže s odesíláním dat pokračovat. Poté co server zpracuje část dat (2 KB), tak umožní klientovi pokračovat v odesílání, ale neotevře mu segmentem 9 okno celé – pouze 2 KB, protože všechna data ve vyrovnávací paměti ještě nezpracoval a pro více dat nemá místo. Prozkoumejme na obr. 9.16 jak vidí klient okno po přijetí segmentu 4...

První 2 KB jsou již potvrzeny, okno je tedy posunuto za bajt 2048. Tato potvrzená data již klient nemusí udržovat v paměti. Odeslaná, ale nepotvrzená data (segment 3) tvoří 1 KB. Klient může tedy odeslat bez dalšího potvrzení 3 KB dat.

IPv6 a QoS – QoS v dnešním internetu funguje nepovinně, je jen jeho částech. Zajištění QoS mezi jednotlivými uživateli je tedy obtížné, IPv6 by měl tento nedostatek odstranit, protože má v hlavičce nová pole definující způsob zpracování a identifikace informací přenášených v síti.

Přednáška 7a) – Propojování sítí Propojování sítí – sítě se propojují s různými topologiemi a operačními systémy. Tím se vytvářejí „internety“. Největším „internetem“ je Internet (:-)). K propojení sítí můžeme použít opakovač(repeater, hub), most(bridge), přepínač(switch), směrovač(router) nebo přenosovou bránu(geteway). Některé tyto prvky použijeme i pro zlepšení spojení v rámci sítě LAN. Opakovač – Opakovač je tvořen dvěma nebo více síťovými kartami, které jsou vzájemně propojeny. Objeví-li se nějaký datový rámec na jednom rozhraní,pak je automaticky zopakován na všechny ostatní. Opakovačslouží pro překonání problému útlumu signálu (čím větší vzdálenost signál urazí, tím je slabší). Tento útlum je následkem odporu a šumu. Opakovač vstupní signál vyčistí a zesílí, tím se prodlouží možná vzdálenost mezi komunikujícími uzly (viz slide 3). Opakovač pro krocenou dvojlinku se označuje jako HUB. Princip opakovače: Pracuje na úrovni bitů, nemá žádnou vyrovnávací paměť, může propojovat libovolný počet segmentů sítě, může propojovat pouze segmenty sítě se stejnou přenosovou rychlostí. Opakovač musí šířit kolize. V ethernetu jich nemůže být libovolně mnoho kvůli době šíření kolize (kolize je, když vysílá více zdrojů na jedno médium současně, signál je znehodnocen, k odstranění kolizí slouží CSMA/CD – co to je zde nebo bible strana 117) – proto mohou být mezi každými 2 body max 2 opakovače . Filtrování opakovače – Opakovače šíří do všech směrů i to, co by šířit nemusely.Chtělo by to nějaké filtrování provozu, což znamená, aby opakovač dokázal „rozumět“ alespoň adresám linkové vrstvy. Pokud by se zařízení rozhodovalo podle obsahu paketu, zda poslat, či ne, muselo by mít nějakou vyrovnávací paměť. Tím pádem by šlo propojit segmenty s různými rychlostmi. Most (bridge) – je to jednotka, která řídí mezi sítěmi přepojování paketů z jedné sítě do druhé. Nešíří tedy paket do všech připojených segmentů sítě. Zlepšuje spolehlivost a bezpečnost sítí. Most pracuje na linkové vrstvě, nemusí propagovat kolize (má vyrovnávací paměť). Most propojuje právě 2 sítě. Varianta „vzdálený půlmost“ znamená, že jsou spolu

propojeny 2 mosty a přes ně se propojují sítě (viz slide 7). Více o mostu je tady nebo raději v bibli na straně 115.

Přepínač (switch) – jedná se o víceportový most, je novější, rychlejší a je to jeden z nejpoužívanějších aktivních síťových prvků. Switch nepropaguje kolize (má vlastní vyrovávací paměť), všesměrově šíří pouze bradcasty a často se používá jako náhrada opakovače. Přes jeden přepínač může probíhat více přenosů až do maximální kapacity přepínače. Přepínačem se označují výkonnější mosty, které umí opakovat rámce nejen mezi jednotlivými segmenty Ethernetu, ale i např. mezi Ethernetem a Fast Ethernetem, mezi Ethernetem a FDDI atd. Přepínač musí umět nejenom změnit tvar rámce např. z Ethernetu na FDDI, ale i pokusit se překlenout rozdíl mezi přenosovými rychlostmi. Problém je totiž při přenosu dat mezi rychlým segmentem (FDDI) a např. Ethernetem, kdy z FDDI může směrovat na Ethernet takové množství dat, že je Ethernet nedokáže odebírat.Rámce se musí ukládat do vyrovnávací paměti přepínače atd.

Přepínač – filtrace – aby mohl přepínač filtrovat (tzn. neposílat příchozí pakety na všechny své výstupy, ale jen tam, kam skutečně patří, resp. pokud tam nepatří, tak je zahodit), musí znát topologii sítě, tzn. na jakém portu (zde nemyslíme samozřejmě port v soketech, ale síťový port) je která stanice. Pokud přepínač topologii nezná, chová se podobně jako opakovač (hub). Tu topologii můžeme na přepínači nastavit buď ručně (ale to je pracné, protože síť se může často měnit) nebo ho nechat, ať si to zjistí sám zpětným učením. To probíhá tak, že nejdříve se přepínač chová jako opakovač (vysílá pakety na všechny strany a dostává odpovědi, ze kterých se učí) a učí se (ukládá si do své tabulky dvojici port, adresa (MAC)) a po určité době začne filtrovat provoz. Přepínač – dále... může buď celý rámec příjmout, analyzovat a poté odeslat (metoda store and forward) nebo může přečíst pouze cílovou adresu a zbytek již rovnou odesílat (metoda cut through) nebo může kombinovat obě metody. Učení přepínače – viz slide 11-13 ... přepínač dostane rámec o kterém neví, do kterého portu jej má odeslat. Pošle jej tedy do všech portů, kromě toho, ze kterého přišel a upraví tabulku. Pokud přepínač již má stanovenou tabulku a dostane nějaký rámec nyní, pošle jej na port, který odpovídá adrese v tabulce. Pokud přepínač dostane paket, jehož příjemcem má být zároveň jeho odesílatel, přepínač tento paket ignoruje. Učení přepínače nebude fungovat, pokud graf sítě bude obsahovat nějakou kružnici (smyčku). Přepínače se ale umí domluvit a vzniklou smyčku přerušit. Ta kružnice ale může být v síti úmyslně např. jako záloha spojení. Co když takovouto kružnici přepínače zruší? To by nebylo dobré... proto máme šikovný algoritmus... Spanning Tree Algorithm – Je to algoritmus, který najde kostru grafu sítě a přeruší tak případné kružnice (tak že zablokuje některé porty směrovačů). Tím se zachová stromová struktura. Pokud by náhodou došlo k nějakému výpadku, zablokované porty se opět uvolní. Tento algoritmus podporují všechny moderní přepínače. Tak nyní k tomu, jak to funguje (animace spanning tree ) ... Spannning Tree Algorithm – princip – 1. nejdříve se zvolí „kořenový přepínač“ (root switch), bude to ten s nejmenší MAC adresou. Na začatku (toho zvolení kořenu) bude každý přepínač tvrdit, že je root, pokud neví o jiném přepínači. Postupně si přepínače rozesílají broadcastem BPDU zprávy (Bridge Protocol Data Units – viz zde) a na kořenovém řepínači se dohodnou 2. Po tom zvolení si každý přepínač,co není rootem, zvolí jeden root port – to je port tohoto přepínače na nejkratší cestě (metrikou je cena,ne jen počet hopů, záleží také na rychlosti linek) ke kořeni .

3. Poté se na každém segmentu sítě (segment = linka propojující switche, která je součástí kostry grafu) zvolí vyhrazený přepínač (to je ten, jež má nejlepší cestu ke kořenovému přepínači) a jeho port s touto cenou bude vyhrazený (designated) port. Docela dobře je to vyobrazeno na obrázku se slidů...

4. Porty přepínačů, které nepatří ke kostře grafu, se přepnou do blokujícíh o stavu. Root i designated porty jsou vždy ve stavu forwarding. Více o spanning tree slidy 19 – 21 a taky zde. Stavů portů může být celkem 5: blocking (neprocházejí jím rámce, je to záložní port, pouze přijímá BPDU a hledá root switch), listening(slouží k příjmu a vysílání BPDU (ne rámců), buduje kostru sítě), learning(neprocházejí jím rámce, učí se MAC ostatních a přijímá BPDU), forwarding (procházejí jím rámce, předává BPDU, zkrátka plně funkční port), disabled. Dále ke Spanning Tree – jeho konvergence při změně topologie sítě trvá implicitně 50 sekund (20 + 15 + 15...viz slide 22). Existuje protokol Rapid Spanning Tree, který slučuje stavy blocking,disabled a listening do jednoho stavu – discarted. Tento Rapid Spanning Tree nemusí díky aktivnímu potvrzování čekat na timeouty.

Směrovač – Router – pracuje na síťové vrstvě (potřebuje IP adresu), propojuje sítě a pracuje se síťovými adresami. Nešíří broadcasty z jedné sítě do druhé. Pojem směrovače je nezávislý na stroji a OS (může to být krabička běžící na linuxu, nebo i počítač s Windows). Směrovač přenáší data i mezi sítěmi, které používají naprosto odlišné technologie, směrovače jsou tedy pro internet nezbytné. Kromě směrování může směrovač podporovat i další funkce (firewall, NAT, VPN). Směrování může být statické nebo dynamické (např. RIP, OSPF...) Schopnost předávat datové pakety mezi sí;ovými rozhraními směrovače se nazývá jako předávání (forwarding). Zatímco u směrovačů je tato funkce požadována, tak u počítačů s klasickým operačním systémem (UNIX, OpenVMS, NT apod.) je někdy dotazováno, jak přinutit jádro operač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ý linkový protokol, na jednom např. Ethernet a na druhém např. HDLC.

Přepínače na vyšších vrstvách – dnešní přepínače podporují QoS, VLAN a další funkce, podporují různé verze Spanning Tree Algorimů. Umí filtrování rámců na různých vrstvách: linková, síťová(Layer 3 switch – filtrování IP adres a IP protokolu, je to vlastně HW optimalizovaný směrovač), transportní (Layer 4 switch – filtruje na úrovni portů TCP a UDP a umožňuje rozlišovat provoz), aplikační(Layer7 switch – slouží k rozložení zátěže na více serverů, které se navenek budou takhle tvářit jako 1 server) Brána – přenosová brána je obecný termín, brána může znamenat: • směrovač • aplikační bránu – např. software pro poštovní aplikace, proxy WWW server atd. • bránu pro překlad protokolů z jedné množiny protokolů do druhé

Přednáška 7b) – Protokol SCTP SCTP – Stream Control Transmission Protocol – jedná se o komnikační protokol transportní vrstvy (tedy něco jako TCP), byl původně navržen pro telefonní signalizaci po IP. Odstraňuje nedostatky TCP a propůjčuje si některé vlastnosti UDP. V současnosti je podporován v Linuxu , Free BSD, MacOS, Solarisu ... , tedy skoro všem kromě Windows. Vlastnosti SCTP – po navázání spojení můžeme komunikovat ve více streamech najednou. V rámci každého proudu (streamu) protokol garantuje doručení dat ve správném pořadí (tedy jako TCP, ale více streamů), případný výpadek v jednom streamu neovlivní ostatní streamy. SCTP lze tedy přirovnat ke svazku spojení TCP, ale má menší režii a několik vylepšení. Formát SCTP – paket začíná univerzální hlavičkou (zdrojový + cílový port, ověřovací značka, kontrolní součet), následují tzv. kousky (chunks), které obsahují řídící informace či data pro jednotlivé proudy (typ, příznaky, délku, další hlavičky a data...). Počet nebo struktura těchto kousků nejsou pevně dány. Formát SCTP paketu je na obrázku.

Jak probíhá u SCTP potvrzování dat? – Citelné změny v porovnání s TCP zaznamenalo potvrzování. SCTP k němu využívá pořadová čísla (jak také jinak), která zde najdete na dvou úrovních: Transmission Sequence Number (TSN) slouží k číslování jednotlivých datových kousků (na úrovni asociace), zatímco Stream Sequence Number (SSN) určuje číslování v rámci jednoho konkrétního proudu.Hlavní předností potvrzování v SCTP je, že dokáže ohlásit chybějící kusy dat. Slouží k tomu speciální kousek nazvaný selektivní potvrzení. Ten obsahuje nejvyšší pořadové číslo přijatého datového kousku a zároveň vyjmenovává chybějící úseky dat. Díky tomu je odesilatel přesně informován, která data dorazila a která ne. Navíc

pokud vysílající dostane čtyři potvrzení ohlašující stejnou díru v datech, na nic nečeká a chybějící část rovnou pošle znovu (tzv. rychlé opakování).

Multi Homing – komunikující stanice má několik IP adres, během komunikace je vybrána jedna brána jako privátní a z ní jsou odesílána data. Pro opakování je vybrána jiná brána. Pokud jsou s komunikací přes primární bránu větší problémy, přejde se kompletně na jinou bránu. SCTP monitoruje všechny cesty a udržuje si přehled o jejich stavu ... více o mutlihomingu je zde Iniciace spojení SCTP – oproti TCP se posílá cookie – SCTP má 4 cestný handshake – init, init-ack,cookie-echo,cookie-ack. Viz slide 8. Formátování do zpráv – SCTP garantuje, že příjemce dostane zprávy rozdělené tak, jak je odesílatel odeslal (podobně jako UDP – to taky posílá data po kouscích – vzpomeň na sliding window, oproti tomu TCP odesílá se chová v podstatě jako proud bitů – zprávy nejsou nijak rozdělené) Ukončení spojení SCTP – oproti TCP uzavřou všechny stanice spojení najednou – viz slide 10... Budoucnost SCTP – jedná se o velmi mladý protokol (RFC z roku 2000), je velmi vhodný pro běžné služby jako je FTP a HTTP. Zatím se čeká na podporu SCTP ve Widows a taky ve směrovačích. Pak to příjde a to nezachápeš, woe! více zde

Přednáška 8 – Jmenné služby Obsah přednášky - úloha jmenných služeb, informace ve jmenných službách, jmenné služby X.500, DNS a jiné Úloha jmenných služeb – je to specalizovaná databáze optimalizovaná pro čtení a vyhledávání – něco jako adresář. Provádí se v ní překlad, lokalizace, ověření a poskytování podrobných informací. Jmenné služby: je jich více druhů, jako příklad jmenujme X.500, LDAP, DNS (Domain Name System), NIS (Network Information System), CDS (Cell Directory Service), Active Directory. X.500 – je to skupina protokolů pro elektronické adresářové služby .Vznik v roce 1988, je to hierarchický jmenný prostor, pracuje na principu komunikace klient – server. Koncept X.500 je ten, že je to jedna hierarchická struktura – tzv. Adresářový informační strom. Hierarchická organizace položek tohoto stromu je samozřejmě obhospodařována více servery. Jenda položka se skládá ze seznamu atributů, každý z těhto atributů má jednu nebo více hodnot. X.500 – organizace dat – záznam se zkládá z jedinečného jména, jedinečného jména a atributů. Toto jedninečné jméno se skládá jednak z relativního jedinečného jména položky a jednak z položek umístěných v Adresářovém stromě hierarchicky nad touto položkou v cestě ke kořeni. Takže je to, jak psal Kubr, vlastně posloupnost relativních jedinečných jmen od kořene. Relativní jedinečné jméno je dejme tomu něco jako název položky. Berte to jako systém adresářů v počítači – jedinečné jméno by byla kompletní cesta k adresáři (např. C:\programy\Kuba\PKO) a relativní jedinečné jméno by byla relativní cesta k adresáři (jen PKO). Atributy jsou prostě jen už informace o položce – viz obrázek...

Na obrázku je jedna položka stromu. Jedinečným jménem je celý první řádek, relativním jedinečným jménem je to “cn”. Zbytek jsou atributy. Atributy mohou být třeba tyto: C (Country), SP (State or Province), L (Locality), O (Organisation), OU (Organisation Unit), CN (Common Name). Příkladem může být např. záznam: CN = atm.felk.cvut.cz, OU=FELK, O=CVUT,C=CZ ...nebo... CN = Jan Kubr, C= CZ X.500 využívá pro přístup k položkám protokoly DAP (Directory Access Protocol, je to prorokol OSI) a LDAP (Lightweight Directory Access Control Protocol). Protokol LDAP – funkce – dotazování a prohledávání (operace search a compare), změny dat (operace add, delete a modify), autentizace (operace bind a unbind). Více o LDAP je na http://cs.wikipedia.org/wiki/LDAP

Shrnutí: X.500 využívá decentralizovaný, jednotný globální prostor, podporuje složité dotazy i autentizaci. Více o X.500 je na http://en.wikipedia.org/wiki/X.500

DNS... Domain Name System Předmluva... Vazba mezi jménem počítače a IP adresou je definována v DNS databázi. DNS (Domain Name System)je celosvětově distribuovaná databáze. Jednotlivé části této databáze jsou umístěny na tzv. name serverech. Chci-li se přihlásit na uzel info.pvt.net s IP adresou 194.149.104.203, použiji příkaz: telnet info.pvt.net. Ještě předtím, než se vlastní příkaz provede, přeloží se DNS jméno info.pvt.net na IP adresu a teprve poté se provede příkaz: telnet 194.149.104.203 Domény a subdomény - Celý Internet je rozdělen do tzv. domén, tj. skupin jmen, která k sobě logicky patří. Domény specifikují, patří-li jména jedné firmě, jedné zemi apod. V rámci domény je možné vytvářet podskupiny, tzv. subdomény, např. doméně firmy lze vytvořit subdomény pro oddělení. Doménové jméno odráží příslušnost uzlu do skupiny a podskupiny. Každá skupina má přižazeno jméno. Z jednotlivých jmen skupin je pak složeno doménové jméno uzlu. Např. uzel se jménem jakub.firma.cz je uzel se jménem jakub v subdoméně firma domény cz. Reverzní domény - Již jsme uvedli, že komunikace mezi uzly probíhá na základě IP adres, nikoli doménových jmen. Některé aplikace naopak potřebují k IP-adrese nalézt jméno, tj. nalézt tzv. reverzní záznam. Jedná se tedy o překlad IP-adresy na doménové jméno. Tento př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í domény. Pro účely reverzního překladu byla definována pseudodoména „inaddr.arpa“. Jméno této pseudo domény má historický původ, jde o zkratku „inverse addresses in theArpanet“. viz obrázek...

Pod doménou in-addr.arpa jsou domény jmenující se jako první číslo z IP-adresy sítě. Např. síť 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ří subdoménu 17.172.in-addr.arpa. Je-li sí_ 172.17 rozdělena pomocí sí_ové masky na subsítě, pak každá subsí_ tvoří ještě vlastní subdoménu. Všimněte si, že domény jsou zde tvořeny jakoby IP-adresami sítí psanými ale pozpátku. Např. Reverzní doména pro subsíť 194.149.150.16/28 je 16.150.149.194.in-addr.arpa Zóna - Zóna je část prostoru jmen, kterou obhospodařuje jeden name server. viz obrázek

Takže doména pvtnet.cz obsahuje v sobě všechny subdomény, ale zóna pvtnet.cz delegovala na jiné name servery pravomoci na zóny brn.pvtnet.cz, plz.pvtnet.cz a ova.pvtnet.cz. Takže zóna pvtnet.cz obsahuje doménu pvtnet.cz až na tři uvedené výjimky. Doména vs. autonomní systém - Autonomní systémy dělí Internet z hlediska IP-adres (směrování), naproti tomu domény dělí Internet z hlediska jmen počítačů...viz obrázek

Jiná je situace u reverzních domén, které kopírují strukturu poskytovatelů Internetu. DNS dotazy a odpovědi - Přeložení jména na IP-adresu zprostředkovává tzv. resolver. Resolver je klient, který se dotazuje name serveru. Jelikož je databáze celosvětově distribuována, nemusí nejbližší name server znát odpověď, proto může tento name server požádat o pomoc další name servery. Získaný překlad pak name server vrátí jako odpověď resolveru. Veškerá komunikace se skládá z dotazů a odpovědí. Rekurzivní dotaz a odpověď - Resolver předává všechny dotazy na lokální name server. Od name serveru pak očekává konečnou (rekurzivní) odpověď. Name server buď odpoví přímo, nebo sám kontaktuje další name servery - prostě spustí standardní algoritmus pro vyhledání odpovědi (tj. začne u kořenových DNS serverů a postupuje do nižších úrovní až k cíli), tj. name server rekurzivně řeší dotaz a klientovi zašle až výsledek. Vypadá to tak, jak to ukazuje obrázek

DNS komunikace - DNS používá jak protokol UDP, tak i protokol TCP. Pro oba protokoly používají port 53 (tj. porty 53/udp a 53/tcp). Běžné dotazy, jako je překlad jména na IP-adresu

a naopak, se provádějí přes protokol UDP. Délka přenášených dat protokolem UDP je implicitně omezena na 512 B (příznakem truncation může být signalizováno, že se odpověď nevešla do 512 B a pro přídanou kompletní odpověď je nutné použít protokol TCP). Délka UDP paketu je omezena na 512 B, protože u větších IP-datagramů by mohlo dojít k fragmentaci. Fragmentaci UDP datagramu DNS nepovažuje za rozumnou.

Ze slidů...neboli +/- to samé ve zkratce DNS je systém primárně určen pro překlad mezi doméovými jmény a adresami, vychází z hosts.txt (lokální soubor v počítači, kde jsou položky typu “jméno” – “IP adresa” – většinou se 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 žádá o pomoc DNS ). DNS shromažďuje v tabulkách tyto informace: A (32b IP adresa), NS (autoritativní jmenný server), CNAME (synonymum ke jménu), SOA (start of authority), PTR (reverzní překlad), HINFO (popis SW a HW), MX (preference a jméno mail serveru), TXT (textový řetězec), AAAA (128b IP adresa ). více o DNS je zde DNS komponenty: • jmenný prostor a zdrojové záznamy – jmenný prostor má strukturu stromu, jméno má velikost 0-63 B, celkově až 255 B. Jména se dělí na absolutní (atm.felk.cvut.cz) a relativní (atm) • jmenné servery – jsou to datové sklady vytvářející jmennou databázi. Tyto servery odpovídají na dotazy, synchronizují databázi a udržují mezipaměť odpovědí (nějakou Cache na časté dotazy) • resolvery – je to soustava knihovních funkcích zajišťujících překlad. Je součástí klienta i DNS serveru. Strom DNS domén – struktura je hierarchická, jak poznáme jednak z názvů stránek na webu a taky ze slidu 10. Strom reverzních domén DNS můžeme vidět na slidu 11. Typy serverů DNS: • primární –udržuje data o své zóně v databázích na disku. Pouze na primárním Name Serveru má smysl editovat tyto databáze • sekundární – kopíruje si databáze v pravidelných intervalech z primárního serveru. Primární i sekundární Name Servery jsou tzv. autoritou pro své zóny, tj. jejich data o zóně se považují za nezvratná (autoritativní) • caching only – není pro žádnou doménu ani primárním ani sekundárním Name Serverem avšak využívá obecné vlastnosti name serveru, tj. data, která jím prochází , ukládá do své paměti. Každý server je Caching server, ale souslovím Caching Only zdůrazňujeme, že není pro žádnou zónu ani primárním ani sekundárním Name Serverem • root – je Name Server obsahující root doménu. Každý root server je primární server. • forwarding – předává rekurzivní dotaz (odlehčení linky), může sám resolvovat • slave - umí jen forwarding Věty RR - Informace o doménových jménech a jim příslušejících IP adresách, stejně tak jako všechny ostatní informace distrubuované pomocí DNS, jsou uloženy v paměti DNS serverů ve tvaru zdrojových vět (Resource Records – RR). Name server naplňuje svou paměť několika způsoby. Autoritativní data načte ze souborů na disku, nebo je získá pomocí dotazu zone transfer z paměti jiného serveru. Neautoritativní data získává postupně z paměti jiných serverů, tak jak vyřizuje jednotlivé DNS dotazy. V případě, že DNS klient (resolver) potřebuje získat informace z DNS, pak požaduje po name serveru věty RR podle zadaných požadavků. Klient může např. požadovat po serveru věty RR typu A, které obsahují IP adresy pro dané doménové jméno apod.Všechny věty RR mají stejnou strukturu. Struktura RR věty je znázorněna na obr.

Popis jednotlivých polí vět RR: • NAME – doménové jméno • TYPE – typ věty • CLASS – třída věty • TTL – Time to Live. 32bitové číslo udávající dobu, po kterou může být tento RR udržován v cache serveru jako platný. Po vypršení této doby musí být věta považována za neplatnou. Hodnota 0 zabraňuje neautoritativním serverům uložit RR větu do cache. • RDLENGTH – 16 bitové číslo specifikující délku pole RDATA • RDATA – vlastní data ve tvaru řetězce proměnné délky. Formát tohoto pole závisí na typu a třídě RR

Na následujícím obrázku jsou příklady nejčastějších typů vět RR:

DNS komunikace – probíhá přes protokol TCP i UDP na portu 53, u UDP je povoleno přenést jen max 512B(?? opravdu ??). Dotaz se posílá na více serverů, první odpověď je platná, ostatní se zahodí. Je tu možnost jisté nekonzistence name serverů. DNS dotaz a DNS odpověď jsou rekurzivní. DNS update je podpora pro ddns (??), informace o zóně, předpoklady, update. DNS komunikace podporuje pozitivní i negativní caching, umožňuje notify –což je předání informací sekundárním DNS serverům o změně, replikaci primárního serveru a autentizaci. DNS dotaz – může být zodpovězen autoritativně i neautoritativně, pokud server nezná odpověď obrátí se na root servery a potom postupuje směrem k subdoménám podle záznamů. Může být vyžadován UDP checksum a odpověď může být omezena na velikost 512B. Obsahem odpovědi je i doba platnosti (asi té odpovědi). Kombinace služeb – integrace různých služeb v distribuovaném prostředí, kombinace jmenné služby s portmapem (co to je?). DCE RPC, SUN RPC, JAVA RMI

Přednáška 9 – Bezpečnost v počítačových sítích Osnova přenášky: základní pojmy, typy šífer, autentizace, integrita, distribuce klíčů, firewally, typy útoků, zabezpečení aplikací Základní pojmy síťové bezpečnosti: pro utajení přenášených dat se používá šifrování a dešifrování, pro ověření totožnosti odesílaele a příjemce se používá autentizace, dále budeme v předášce probírat integritu a neporiatelnost, dostupnost a řízení přístupu, detekci útoků a reakce na ně. Principy kryptografie – kryptovat se začalo už za Caesara, moderní techniky šifrování se používají cca 30 let. Šifrovací algoritmus umožňuje odesilateli zašifrovat otevřený text (na šifrovaný) a příjemci text rozšifrovat. Máme šifroací klíče – jeden pro šifrování (označme ho KA) a jeden pro dešifrování (KB). Pokud K A = K B , pak je šifrování symetrické, pokud K A ≠ K B , pak je šifrování asymetrické (klíč pro zašifrování může být veřejný). Označme

otevřený text jako m. Pak K A ( m ) je šifrovaný text a K B ( K A ( m ) ) je dešifrovaný (neboli opět otevřený) text. Jak šifrování probíhá, je na slidu 6 – text se zašifruje, odešle šifrovaný a příjemce ho rozšifruje. Symetrické šifry – používají substituce (nahrazení písmenek) nebo transpozice (změna pozice písmenek ) • Caesarova šifra – mějme klíč K=n, posuneme celou abecedu o n písmenek, takže například slovo ahoj nám to při K=3 zašifruje jako dkrm...viz slidy. Logicky počet klíčů je roven počtu písmen v abecedě – 1 (protože kdybychom to posunuli moc, jsme zas tam, kde jsme byli). • Monoalfabetické šifry – náhrada jednoho písmena abecedy jiným písmenem. Je 26! klíčů. Na šifry tohoto typu lze aplikovat statistický útok. • Polyalfabetické šifry – náhrada jednoho písmena abecedy různými písmeny – něco jako Caesarova šifra s více možostmi nahrazení ... viz slide 7 • Transpozice – slide 8 – napíšeme si text do řádků a každý sloupeček označíme číslem (ale pozor – na po řadě, ale zpřeházeně) – nyní čteme písmena podle čísel sloupců...ale obrázek na slidu vydá za tisíc slov • Data Encryption Standard – neboli DES, je to šifra která byla publikována v roce 1977. Má 56b symetrický klíč (+8b parita), byl to několikrát obnovený stadnard (prodloužení klíče, triple DES), ale v současnosti je to slabá šifra. Její prolomení trvalo v roce 1997 4 měsíce, ale v roce 1999 to bylo už jen 22 hodin. Proto byl v roce 2001 přijat nový standard AES (Advanced Encryption Standard) – kde jsou 128b, 192b nebo 256b klíče...více o DES je na slidu 10 a zde, o AES pak zde.

Asymetrické šifry – klíč na zašifrování a dešifrování je odlišný, existuje množství klíčů při komunikaci různých subjektů. Je veřejný klíč (označme ho např. K B + ) – ten slouží k zašifrování textu a je veřejně známý, a pak je privátní klíč (označme ho K B − ) - ten slouží k dešifrování textu. Tyto klíče je složité vzájemně odvodit. Platí rovnice: K B − ( K B + ( m ) ) = K B + ( K B − ( m ) ) = m . Jak je vidět na slidu 12, přenos probíhá tak, že odesílael zašifruje text veřejným klíčem, a příjemce na přijatý text aplikuje svůj privátní klíč. RSA – je to algoritmus pro vytváření klíčů, název odvozen z příjmení jejich vynálezců (Ron Rivest, Adi Shamir, Leonard Adleman). Princip je tento: máme dvě prvočísla: p a q. (velikost cca 1024b a 768b). Mějme čísla n = p ⋅ q ; z = ( p − 1) ⋅ ( q − 1) ; a číslo e, které je nesoudělné se z a menší než n dále číslo d, kde musí plait, že ( ( e ⋅ d ) mod z = 1) Pak platí K B + = ( n, e ) a K B − = ( n, d ) . Algoritmus pro šifrování je c = m e mod n a pro dešifrování je m = c d mod n (kde m je otevřený text a c je zašifrovaný text). Příklad na RSA je na slidu 14. Neděste se toho, první tabulka je zašifrování – první sloupeček je původní text, druhý sloupeček je operace m e a třetí sloupec je m e mod n . Analogicky probíhá dešifrování (druhá tabulka).

Autentizace – je to poskytnutí informace o identitě jednoho subjektu subjektu druhému. Provádí se před použitím dalších protokolů a často se provádí oboustranně. • Autentizační protokol 1.0 – pouze zadání jména (nebo nějaké jiné identifikace). Tento je samozřejmě nedostatečný, taky se můžu představit jako někdo jiný, že...viz slide 16

• •

•

•

•

Autentizační protokol 2.0 – kontrola uživatelského jména a IP adresy, ze které se uživatel připojuje. Zde je ovšem možnost podvržení IP adresy Autentizační protokol 3.0 – uživatel se přihlašuje jménem a heslem. Toto používají například protokoly telnet nebo ftp. Zde je ovšem možnost heslo odposlechnout a někdy ani zašifrování nepomůže. Autentizační protokol 4.0 – to samé jako 3.0, ale pokaždé uživatel použije jiné heslo. Zde ovšem musíme nějak pošéfovat to, jak hesla generovat tak, aby to bylo bezpečné, protože, jak někdo na algoritmus generování příjde, tak jsme v pr... Autentizační protokol 4.1 – uživatel zadá heslo, podle tohoto hesla se zašifruje výzva, která se uživateli předá. Uživatel výzvu nějakým klíčem rozluští a odpoví na ni. Tento protokol je bezpečný, ale je tu problém, jak uživateli předat klíče. Autentizační protokol 5.0 –výzvu zašifrujeme asymetrickou šifrou (předpokládejme, že uživateli jsme jeho privátní klíč předali už předtím), poté pošleme uživateli dotaz na to, jaký je veřejný klíč? on nám odpoví a tím pádem můžeme přijatý text rozšifrovat. Nojo, ale problémem je to, že hacker může mít svůj privátní i svůj veřejný klíč – a pokud přijímá zprávy od uživatele (Alice) a tváří se jako server (Bob), je prakticky nemožné jeho hrozbu odhalit. Jinak ještě u protokolu 5.0 je asymetrická šifra, což je výpočetně složitější - dá se to obejít tak, že budeme mít symetrickou šifru a klíč k ní bude jen dočasný (budeme ho po nějaké době měnit).

Integrita, digitální podpis – integrita je zaručení, že dokument nebyl změněn, dá se zaručit: nepopiratelností – podpis zodpovědého subjektu , nebo nějakou doručenkou a nebo využitím asymetrického šifrování • podpis – buď šifrujeme celý dopis (zbytečně náročné) nebo hodíme na dopis nějaký otisk (otisk se vytvoří, zašifruje (můžeme ho předtím ještě zahashovat), a dešifruje) – po doručení dokumentu rozšifrujeme otisk a ten ověříme, jestli sedí. To jak to vypadá je graficky znázorněno na sidech 27 a 28. Distribuce klíčů – řešení je jak pro symetrické tak i pro asymetrické klíče. • symetrické: KDS(Key Distribution Center – obrázek slide 30), Kerberos (každý uživatel má vlastní klíč, kerberos přiděluje dočasné komunikační klíče) • asymetrické: CA - Certification Authority – nejdříve se ověří uživatel dle nějakého průkazu totožnosti a pak se mu vystaví certifikát podepsaný CA, jak to probíhá, je na slidu 31.

Řízení přístupu – zamezení útočníkům v přístupu k prostředkům, je více možností, jak toho dosáhnout : • firewall – buď může být hardwarový nebo softwarový... obrázky (i když divné) jsou na slidu 33 a 34 • zahazování,akceptace a forwardování paketů – na to máme paketové filtry (rozhodují se podle obsahu paketu), kontextové filtry (rozhodují se podle kontextu spojení) a aplikační brány (speciální aplikace – např. proxy) Typy útoků : • mapování(mapping) –první fáze útoku, kdy si hacker sbírá informace (pomocí pingu, scanování portů). Je to dobrý předpoklad pro DDoS (viz dále co to je) • odposlouchávání – to je snad jasné, co to je, odposlouchává na síti např. hesla a tak

• • • •

podvrhnutí (spoofing)- je to podvrhnutí zdrojové IP adresy, ale dá se to poměrně jednoduše omezit pomocí firewallu. DoS (Denial of Service) – omezení dostupnosti služby pro legitimní uživatele. Tento útok využívá chyby nebo přetížení DDoS (Distributed DoS) – je to velmi nebezpečná varianta DoS, téměř bez možnosti ochrany. únos spojení (hijacking) – možnost ukradení spojení navázaného někým jiným. Nicméně šifrování tento problém řeší.

Zabezpečení aplikací: • aplikační vrstva – zabezpečení souboru např. pomocí PGP • transportní vrstva – zabezpečení spoje, např. pomocí SSL (Secure Socket Layer) • síťová vrstva – zabezpečení mezi dvěma uzly, např. pomocí IPsec • linková vrstva – zabezpečení linky, např. pomocí šifrování modemů Šifrování může probíhat na libovolné vrstvě, nižší vrstvy pak šifrují hlavičky vyšších vrstev.

Přednáška 10 – IPv6 Obsah přednášky – historie, motivace, formát datagramu, adresace, objevování sousedů, automatická konfigurace, IPsec, mobilita Historie a požadavky – počátkem 90, let se objevila studie o vyčerpání adres IPv4 do 10 let, 1995 vznikl IPv6, poté pomalu pronikal do praxe. Požadavky na tento protokol byly: větší adresní prostor, zvýšení bezpečnosti, QoS, automatická konfigurace a mobilita. Formát datagramu IPv6 – IP-datagram verze 6 se skládá ze čtyřicet bajtů dlouhého základního záhlaví následovaného rozšířeními. Čtyřicet bajtů základního záhlaví se může zdát hodně, ale je třeba si uvědomit, že jen IP-adresy odesílatele a příjemce zaberou 32 bajtů. Struktura základního záhlaví je zobrazena na obr.

účelem struktury bylo minimalizovat položky a udržet konstantní délku hlavičky. Bylo odstranění přepočítávání kontrolího součtu (ponecháno na nižší vrstvě), délka hlavičky (je vždy stejná), rozšiřující volby a fragmentace (přesunuta do dalších hlaviček) . Volitelné položky jsou umístěny do samostatných hlaviček. Zpracování datagramu je tedy zjednodušeno. Takže co tedy zbylo vlastně v té hlavičce? • verze protokolu (ta je samozřejmě 6) • 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 pozadí (např. news), 1-automatický provoz (např. mail), 4 – velké přenosy dat (např. ftp ,...)) Hodnoty 8 – 15 jsou určeny pro přenosy v reálném čase (např. audio). Datagramy s nižší hodnotou (to však platí jen pro interval 8-15) si přeje uživatel zahodit dříve než datagramy s vyšší hodnotou. specifikuje přenášená data pro případ rozhodování v okamžiku zahlcení sítě. • identifikace toku dat – toto je naprosto neotřelá myšlenka. Spolu s adresou odesílatele se jednoznačně identifikuje dílčí tok dat v internetu. Doposud se směrování provádělo pouze na základě adresy příjemce. Nevýhodou směrování v intenetu je, že jednotlivé IP datagramy se dopravují samostatně, tj. pokud Internetem prochází tok IP datagramů mezi 2 aplikacemi, pak směrovače na cestě řeší směrování pro každý datagram samostatně. Prostě pokud posíláme megabajty dat a během přenosu nedojde ke změně v topologii sítě, pak směrovače po cestě řeší tu samou úlohu s tím samým výsledkem pro tisíce datagramů. Myšlenka spočívá v tom, že datagramy jednoho toku dostanou svou identifikaci. Pak stačí, aby směrovač vyřešil úlohu (do kterého rozhraní datagram předat) pro první datagram toku a do paměti si poznamenal výsledek. Pro další datagram nejprve prohlédne pamě; a pokud by tam nenašel poznamenaný tok, tak řeší

úlohu směrování. Další datagramy stejného toku pak bude předávat do stejného rozhraní aniž by řešil úlohu směrování – pouze na základě údajů v paměti. Položka v paměti směrovače nesmí zůstat déle než 6 vteřin. Nebezpečí číhá totiž v tom, že odesílatel resetuje svůj počítač. Zavede znovu operační systém a shodou okolností vygeneruje stejnou identifikaci pro jiný tok. Nepředpokládá se, že by uživatel stihl provést reset počítače do 6 vteřin. Jinou možností je využít identifikaci toku dat k zajištění šířky přenášeného pásma. Směrovače na cestě od odesílatele k příjemci se nakonfigurují tak, aby pro datový tok o jisté identifikaci zajišťovaly určitou šířku pásma. Datagramy docházejí na směrovač, kde se umísťují do vyrovnávací paměti. Za normálních okolností se jedná o frontu datagramů, která z jednoho konce přibývá a z druhého konce se datagramy odebírají (odesílají). Směrovač však nemusí frontu zpracovávat sekvenčně, ale může přednostně vybírat datagramy tak, aby zajistil dohodnutou šíři pásma. V tomto případě pochopitelně nelze hrát na šestivteřinový limit. • délka dat (počet bytů za hlavičkou) – specifikuje délku IP datagramu bez základního záhlaví (to má totiž délku vždy stejnou – 40B). Jelikož je toto pole dlouhé 2B, tak největší délka přenášeného IP datagramu je 65535B. Je však možné použít volbu „ohromný datagram“ v další hlavičce, která umožňuje posílat ještě větší datagramy (Jumbogramy) • další hlavička – specifikuje typ následující (zřetězené) hlavičky. Následující hlavičky mohou být například tyto:

•

Pouze typy, které jsou uvedeny tučně jsou součástí IP protokolu. Ostatní typy jsou typy protokolů vyšších vrstev dosah (počet hopů) toto poslední pole odpovídá položce TTL v IPv4

Řetězení hlaviček – viz slide 7 – Pole další hlavička v základním záhlaví ukazuje jaký typ dat (“jaká hlavička”) následuje za základním záhlavím. Teoreticky může ukazovat již na TCP segment nebo jiný protokol vyšší vrstvy. Avšak může také ukazovat na další rozšiřující hlavičky IP-protokolu. Pokud ukazuje na další rozšiřující hlavičku, pak i tato hlavička má pole „další hlavička”, která ukazuje na další hlavičku. Hlavičky tak tvoří řetězec. Řetězec obsahuje jen ty hlavičky, které jsou nutné. Je to rozdíl od IP-protokolu verze 4, který ve svém záhlaví často přenáší nadbytečné informace. Za polem další hlavička je pole délka hlavičky.

Pole délka hlavičky specifikuje posunutí jaké je třeba udělat k další hlavičce. Základní záhlaví délku nemá, protože je dlouhé vždy 40 bajtů. Rovněž u záhlaví fragmentů se délka nepoužívá, protože tato hlavička je vždy 8 bajtů dlouhá. Dále popíšu některé typy dalších hlaviček: • Informace pro směrovače –obsahuje jednotlivé informace (volby), které jsou určeny pro směrovače přepravující datagram. Každý směrovač, který datagram předává se musí těmito volbami zabývat. Volba se skládá z pole typ dlouhého 1 B, pole délka dlouhého 1 B a pole obsahujícího vlastní volbu. Obrázek uvádí některé volby.

Pokud je volba délka rozsáhlého datagramu použita, pak délka datagramu v základním záhlaví je nastavena na nulu a používá se délka uvedená v této volbě. Zatímco v základním záhlaví jsou pro délku určeny 2 bajty (tj. datagram může být dlouhý až 64 KB), pak 4 bajty volby rozsáhlý datagram umožňují délku až 4 GB. • směrovací informace - Hlavička směrovací informace používá tč. jedinou volbu (Typ=0), kterou je explicitní směrování. Kdy odesílatel specifikuje IP-adresy směrovačů, přes které má být datagram dopravován • záhlaví fragmentu - Fragmentovat IP-datagramy verze 6 může pouze operační systém na straně odesílatele. Směrovače, kterými datagram prochází na své cestě od odesílatele k příjemci fragmentovat na rozdíl od IPv4 již nesmí. Jak vypadá tato hlavička, je znázorněno na obrázku

Na rozdíl od IP-protokolu verze 4 neobsahuje každý IP-datagram (např. v základním záhlaví) identifikaci IP-datagramu. Identifikace IP-datagramu je nutná pro fragmentaci, aby příjemce zjistil, které fragmenty patří do stejného datagramu. V IPv6 je 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í tohoto pole příjemce zjistí pořadí v jakém má fragmenty skládat za sebe. Pole posunutí od počátku datagramu neudává posunutí v bajtech, ale v násobcích osmi bajtů (v „osmibajtech”), proto se při fragmentaci musí zajistit, aby fragmenty byly odřezávány v délce, která je dělitelná osmi.A konečně pole M (More Fragment) indikuje poslední fragment. Jednobitové pole M je nastaveno na jedničku, pouze v případě posledního fragmentu na nulu.

•

autentizační hlavička - Pomocí autentizační hlavičky odesílatel autentizuje data, tj. prokazuje, že data odeslal on. Datagram je tak zabezpečen proti změně IP-datagramu útočníkem i proti záměně celých IP-datagramů odesílatele za IP-datagramy vložené útočníkem. Základní autentizace je za využití algoritmu MD-5 (RFC-1321) pro výpočet kontrolního součtu.

•

bezpečnostní hlavička – umožňuje přenášená data šifrovat – musí to být poslední přenášená hlavička datagramu, protože data jsou již dále šifrovaná, tj. nedostupná ke zpracování směrovačům dopravujícím IP datagram.

Řetězení hlaviček je znázorněno na obrázku...

Fragmentace - Provádí se pouze u odesílatele, informace o fragmentaci je uložena v rozšiřující hlavičce. Hlavičky až po tu fragmentační jsou nefragmentovatelné. Doporučené MTU (Maximum Transfer Unit) pro IPv6 je 1280B. Vyhledávání MTU cesty se děje pomocí ICMPv6 – nemusí se implementovat. Jumbogramy – to budou asi nějaké ty velké datagramy:-). Jejich maximální délka je až 4GB. Ale uzly s menším MTU nemusí Jumbogramy podporovat.

Pár slov o ICMPv6 - Podobně jako v případě IP-protokolu verze 4 se pro signalizaci chybových stavů a pro diagnostiku v IPv6 používá protokol ICMP. Protokol ICMPv6 v mnoha případech přináší zcela odlišné funkčnosti oproti protokolu ICMPv4. Řeší např. překlad IP-adres na linkové adresy. (Na tento

problém jsou v IPv4 určeny samostatné protokoly ARP a RARP. ) Z hlediska struktury paketu se 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 a signalizaci zpráv. Pokud by to někoho zaajímalo, tak tabulka různých typů ICMPv6 paketů je v bibli na straně 207.

Adresace IPv6 Délka adresy je 128b, tedy 16 8-bitových polí (oproti IPv4, kde byly jen 4 pole – 147.32.113.229). Rozeznáváme tři druhy adres: • unicast – jednoznačná adresa síťového rozhraní • anycast – adresa skupiny síťových rozhraní. IP datagram adresovaný adresou anycast bude doručen jednomu z těchto rozhraní. • multicast – neboli oběžník • !Broadcast adresy nejsou podporovány! Používají se různé zápisy IP adresy: • normální zápis - např. FEDC:1234:0000:ABCD:0F12:0000:0000:4567 – vedoucí nuly (to jsou nuly,kterými čtyřčíslí začíná) se uvádět nemusí, takže zápis této adresy může vypadat např. FEDC:1234:0:ABCD: F12:0:0:4567 • zkrácený zápis pomocí zvolené dvojtečky – zvolená dvojtečka se může v adrese vyskytovat pouze jednou a nahrazuje tam libovolné množství čtveřic null, např. pokud máme adresu 1234:0:0:0:0:0:0:0:14, pak ji pomocí zvolené dvojteky můžeme napsat jako 1234::14 Adresy sítí: viz obrázek...

Oběžníky resp. Skupinové adresy: Oběžníky mají prefix obsahující v prvním bajtu samé binární jedničky, tj. šestnáctkově FF (viz obrázek).

Také viz slide 12 – koukni, kde se vyskytuje bit T – to udává, zda je oběžník přidělen trvale (0), nebo jen dočasně (1). Dalším polem je rozsah (4b), to je, jak jsme si řekli něco jako TTL, hodnoty dosahu: rozhraní (1), linka (2), podsíť (3), správa (4), místo (5), globální (E) – na slidu 12 jsou ještě příklady pro adresy, ale myslím, že je to jasné. Adresy rozhraní – uzel – má lokální linkovou adresu, loopback, individuální a výběrovou, může být skupinová adresa pro všechny uzly, také skupinová pro skupiny, jichž je uzel členem a také skupinová pro vyzývaný uzel. směrovač – má adresy jako uzel + navíc skupinové pro všechny směrovače, výběrové pro směrovače v podsíti a také všechny přidělené výběrové adresy.

Objevování sousedů - k tomuto slouží protokol, jež je rozšířenou náhradou ARP (vzpomeň si na zjišťování MAC). Tento protokol využívá ICMPv6 pro výzvu směrovači, odhlášení směrovače, výzvu sousedovi, ohlášení souseda, přesměrování.Tento protokol poskytuje: zjišťování linkových adres v lokální síti, rychlou aktualizaci změn a neplatných položek, hledání směrovačů, přesměrování, detekci duplikových adres, ověření dosažitelnosti sousedů a zjišťování údajů pro automatickou konfiguraci. Hledání linkové adresy: - pošleme výsvu sousedům pomocí skupinové adresy, posledních 24b necháme samé Fka – tam se doplní ty hledané linkové adresy (jestli to chápu správně). Pokud se nám soused s linkovou adresou ohlásí, aktualizujeme si jeho adresu. Automatická konfigurace – viz http://www.ipv6.cz/v6about/autokonf/ Jedním z požadavků na IPv6 je automatická konfigurace. Představa, že člověk jednoduše připojí počítač k síti a bude mu fungovat síťování, aniž by kdokoli cokoli konfiguroval, je velmi lákavá (a z pohledu správce sítě částečně děsivá). stavovou konfiguraci obstarává DHCPv6, nevyužívá však broadcast (jak by taky, když je zaká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 jednoznačně idenifikující rozhaní ... zbytek slidu nechápu (???) bezestavovová konfigurace – nevyžaduje konfiguraci... Jejím základním pilířem je tak zvané objevování sousedů (neighbor discovery). Základní myšlenka je celkem prostá: každý směrovač v určitých intervalech rozesílá do sítí, k nimž je připojen, tak zvané ohlášení směrovače. V něm jsou obsaženy základní informace - především prefixy adres dané sítě a zda on sám může sloužit pro předávání paketů ven (jako implicitní směrovač, default gateway).Z ohlášení směrovačů (o které může při startu aktivně požádat pomocí výzvy směrovači) se počítač dozví, jaké adresy používá zdejší síť. K nim si doplní zbývající část (typicky 64 bitů), která se jednoznačně generuje z jeho Ethernetové adresy. Tak získá platné IPv6 adresy pro své rozhraní. Také si vytvoří seznam implicitních směrovačů, kterým bude předávat pakety směřující mimo síť. Pokud je jich víc, zpočátku je prostě střídá a směrovací tabulku si postupně vylepšuje na základě jejich upozornění (ICMP přesměrování), pokud paket k určitému cíli poslal nevhodným směrovačem.Zní to dost dobře, přesto však má bezstavová konfigurace dost velkou pihu krásy. Vůbec totiž neřeší otázku DNS. Počítač se z ní nedozví adresy zdejších DNS serverů a jak již bylo řečeno, bez DNS se v IPv6 žije velmi velmi těžko.

Bezpečnost – je povinná implementace IPsec, autentizace je prováděna pomocí Authentication header, šifrování pomocí ESP (Encapsulating Security Payload). Při transportním režimu se bezpečnostní hlavičky jednoduše vloží, při tunelujícím režimu se datagram zabalí da datagramu s bezpečnostními hlavičkami. Bezpečnostní asociace – Security Association (SA) – obsahuje informace potřebné pro šifrované spojení –bezpečnostní protokol, šifrovací algoritmus, klíče, čítače, doba životnosti... SA je jednosměrná a vytváří se ve dvojicích, pro AH (Authentication Header) i ESP je jedna dvojice. Na jeden paket se vztahuje svazek SA. Databáze bezpečnostní politiky – je to sada pravidel uplatňovaná na všechny pakety. Říká, jestli pakety zahodit, zpracovat bez IPsec (tedy jen odeslat a přijmout) a nebo zpracovat s IP sec (tehdy databáze vydá svazek SA). Tuto databázi můžeme buď nakonfigurovat manuálně nebo automaticky pomocí ISAKMP Authentication Header – složí pro autentizaci odesílatele, umožňuje ochranu proti opakování. Postup je takový: Nejdříme vložíme AH hlavičku, potom vyplníme položky (autentizační data se vyulují) a poté se autentizační data vypočtou. Encapsulation Security Payload (ESP) - slouží k šifrování obsahu (i služby AH). Obsahem ESP hlavičky jsou data a další hlavičky. Postup je takový: Umístění ESP hlavičky, vycpávky a šifrování, vytvoření pořadového čísla, vytvoření autentizačních dat (je li požadována autentizace a kontrola integrity), fragmentace až po šifrování. Mobilita - pracuje na principu domácí adresy a domácího ageta (co to ku... je?)... obrázky viz slide 25-28

Přednáška 11 – Síťová správa Obsah přednášky : definice, historie, protokoly a příklady Síťová správa podle ISO: • správa výkonu (performance management) – reaktivní a proaktivní, měření výkonnosti a zatížení • správa konfigurací (cofiguration management) – monitorování síťové konfigurace • správa účetní (accounting management) - monitorování využití sítě • správa poruch a chyb(fault management) – detekce chyb, logování a oznámení • správa bezpečnosti (security management) – nastavení a monitorování přístupu Architektura správy – slide 4 v síti je jeden počítač připojen jako Agent a obsahuje databázi správy sítě, kam se ukládají data

protokol SNMP Simple Network Management Protocol je sada protokolů usnadňujících správu komplexních IP sítí. V současné době tímto protokolem umí komunikovat nejrůznější sítové prvky, ať už se jedná o servery, pracovní stanice, směrovače, switche, huby a další. Administrátorům SNMP umožňuje sledovat výkon a provoz v síti, odhalit a řešit vzniklé problémy. SNMP může být důležitým zdrojem dat při plánování rozvoje sítě...více zde Představte si že chcete jednomu počítači manuálně nastavit směrovací tabulku. Použijete příkaz route add – net... Pokud ovšem nespravujeme jeden počítač, ale rozsáhlou síť počítačů, pak je velice náročné se postupně přihlašovat na jednotlivé systémy a tam dávat příkaz route. Zpravidla máme k

dispozici manažerskou stanici a na všech aktivních prvcích sítě (počítače, směrovače, HUBy, modemy, databáze atd.) běží SNMP agenti, kteří jsou k dispozici manažerské stanici. Z manažerské stanice je možné provádět dotazy na nejrůznější parametry jednotlivých systémů. Mj. je takovým parametrem i položka směrovací tabulky. Takže z manažerské stanice můžeme vypisovat obsah směrovacích tabulek, ale i směrovací tabulky modifikovat. Nesmíte si jen zmodifikovat směrovací tabulky tak, abyste ztratili spojeni s manažerskou stanicí … MIB – Management Information Base – je to databáze parametrů zařízení. Každé zařízení takovouto databázi obsahuje. tato DB musí mít urč. jmennou strukturu ve formě hierarchického stromu. Touto databází je určeno, jaké proměnné jakého typu spravuje tzv. agent. Ten běží na každém zařízení a zpracovává zprávy od tzv. managera. Obsahem zprávy může být požadavek na čtení nebo zápis dat, agent požadavky přijímá a výsledkem jeho činnosti je nějaká odezva managerovi. Agent nemusí jen pasivně čekat na požadavky. Pokud nastane určitá událost, dokáže o tom informovat managera pomocí tzv. TRAP zpráv. Na řídící stanici běží manažer komunikující s jedním či více agenty. Jedná se vlastně o architekturu klient-server, agent je serverem, manažer klientem. Zprávy mezi nimi jsou přenášeny protokolem UDP, jenž byl zvolen pro svoji jednoduchost a vhodnost při komunikaci typu žádost/odpověď, na níž je síťový management založen.

SNMP rozlišuje pouze pět typů zpráv: • • • • •

get-request – žádost o nějakou hodnotu get-next-request – žádost o další hodnotu v pořadí (použití při žádosti o pole dat) get-response – odpověď na žádost set-request – žádost o zápis hodnoty trap – zpráva, kterou agent informuje managera o nějaké události

Model komunikace SNMP je na obrázku – podstatou SNMP je, jak od síťových zařízení získat informace (parametry) a také možnost, jak tyto informace změnit.

Poslední verzí je verze 3. Model je takový, že máme nějaký „Uzel Správy“ – ten obsahuje SNMP agenta a stavové a konfigurační informace. Tento „Uzel Správy“ pak komunikuje pomocí SNMP služeb se „Stanicí správy“.

Management Information Base – slide 7 – nechápu, vysvětlit SNMP služby – snmpget, snmpset, snmpgetnext, snmpgetbulk, trap, inform RMON Remote monitoring – viz zde – Jde o sledování stavu vzdálené sítě na dálku. Oproti SNMP umožňuje mnohem lepší monitoring sítě, všelijakou historickou analýzu atd.Základní ideou při návrhu RMON bylo mít inteligentního agenta, který je schopen co nejpodrobnějšího monitorování síťového segmentu a uchovávání sesbíraných informací. Získané informace (aktuální i historická data) z různých agentů lze pak prezentovat na centrální správcovské konzole při minimální komunikační zátěži a zároveň minimální výpočetní zátěži konzoly. Princip RMON - RMON standard definuje skupiny informací, které mohou být monitorovány síťovým analyzátorem nebo sondou (agentem). RMON MIB (Management Information Base) standard umožňuje vzdálené monitorování Ethernet i Token Ring segmentů a to využitím již zavedeného protokolu SNMP. RMON je typickým příkladem distribuovaného řešení. Stejně jako klasický SNMP model, i RMON model se skládá ze dvou částí. Tou první je agent (sonda), která je umístěna na monitorovaném segmentu. Druhou částí je správní aplikace, běžící na centrální konzole, v ideálním případě jako nadstavba základní správní platformy. Pomocí této RMON aplikace můžeme zkonfigurovat agenta ke sběru požadovaných informací, které jsou zasílány na centrální konzolu při vyžádání nebo při výskytu definované události. Těchto agentů - sond může být rozmístěno v síti tolik, kolik má síť segmentů. Samozřejmě u velkých sítí se tyto sondy umisťují strategicky jen na nejdůležitější segmenty, případně podle potřeby na ty segmenty, kde se objevují nějaké problémy. Skupiny informací RMON, které mohou být monitorovány: statistic (monitoruje se okamžitý provoz – byte, kolize, cyby), history – (dtto (??) ale historie), alarms (prahování některých hodnot), hosts (přenosová statistika pro každý uzel), hosts top N (setříděná statistika hosts), Traffic Matrix (monitoring vzájemné komunikace mezi uzly ), Filters , Packet Capture (Pakety pro další dekódování), Events (záznamy událostí) RMON MIB – podobně jako v SNMP má i každé zařízení v RMON svou MIB (Management Information Base)

Přednáška 12 – ukládání dat Direct Attached Storage – je když...připojíme (např. k serveru nebo pracovní stanici) přímo nějaké datové uložiště (datový sklad třeba...). Připojení může být realizováno např. přes SCSI nebo opická vlákna.více zde Network Attached Storage – uložiště dat (stanice s RAID poli např.) je k počítači připojeno pomocí sítě rozhraní (klasický IP protokol) a tak poskytuje centralizovaný datový sklad pro různé klienty. Počítači se disky jeví jako dálkově připojené.K přístupu k datům používá (narozdíl od SAN) dobře známé protokoly. více zde Storage Area Network – je to vlastní síť datových uložišť, je připojena k serveru nebo pracovní stanici např. přes SCSI nebo přes Fibre Channel. Tato datová uložiště se pak v počítači jeví jako lokálně připojené disky. Proto může např. server ze SANu klidně nabootovat. více zde iSCSI (SCSI over IP) Attached Storage – je to nějaký datový sklad připojený k síti IP přes iSCSI protokol – to je protokol transportní vrstvy, který umožňuje využívat SCSI přes síť TCP/IP. více zde LAN – NAS (SAN) – jak lze vidět na slidech, NAS i SAN může být připojeno k počítačům pomocí sítě LAN.

Přenos dat – jak je vidět, Direct Attached Storage a SAN se v architektuře datových skladů nijak neliší, ale rozdíl je v přenosu dat. U DAS se přenáší přímo přes SCSI sběrnici, u SAN přes síť SAN a u iSCSI a stejně tak u NAS přes TCP/IP síť.

Protokoly pro přenos dat Fibre channel – je to síťová technologie (gigabitová rychlost) pro přenos dat z datových skladů po síti. I když název je Fibre Channel, tato technologie dokáže pracovat jak přes optická vlákna,tak přes kroucenou dvojlinku. Topologie může být buď Point to Point (dvě zařízení jsou propojeny spolu – viz zde) nebo Arbitrated Loop(zařízení jsou propojeny ve smyčkách – viz zde) nebo Switched Fabric (všechny zařízení i smyčky jsou připojeny k nějakým switchům – viz zde ). Propustnost Fibre Channel může být od 200 do 4800 MB/s (wow!) a fibre channel podporuje řízení toku. Struktura paketu (rámce) fibre channel je na slidu 10 iSCSI – je to protokol pro přenos SCSI příkazů přes síť TCP/IP, je to protokol transportní vrstvy (tedy přenos SCSI příkazů přes TCP), HyperSCSI je protokol podobný iSCSI až na to, že kašle na rodinu TCP/IP a pracuje přes Ethernet, proto se např. nemusí zabývat segmentací a sestavením, díky tomu je rychlejší, ale nemá takovou flexibilitu pro IP sítě. Jak vypadá rámec obsahující iSCSI je vyobrazeno na slidu 11. Fibre Channel over IP – umožňuje přenos Fibre Channel paketů přes IP protokol, využívá k tomu opět protokol TCP, takže je to v podstatě něc jako iSCSI. Využívá tunelování (???) pro přenos FC informací přes IP sítě. Rámec obsahující FCIP je na slidu 12. FCIP je dobrý pro Point to Point komunikaci mezi síti SAN (viz slide 14) Internet Fibre Channel Protocol (iFCP)- pro přenos FC informací využívá ne tunelování, ale směrování, propojuje různé SAN struktury (slide 14) ATA over ethernet – je to síťový protokol, který dává možost si vytvořit levné sítě SAN, Protože funguje přes Ethernet,nezávisí na technologiích vyšších vrstev (IP,UDP,TCP...) – prostě se ATA příkazy vkládají přímo do ethernetových rámců. Proto to nejde nijak směrovat (není tam totiž IP paket, ale pouze Ethernet) Další technologie – IPv4, IPv6, ARP over FC.

Přednáška 12 – IDS Intrusion Detection System – je to systém, který detekuje nechtěné manipulace s počítačem skrz internet. Používá se k detekování rozličných hrozeb, které nedokáže detekovat firewall (toto zahrnuje síťové útoky proti zranitelným služám nebo nějaký malware (viry, trojany, červy...)). Jsou různé typy IDS • :network IDS - NIDS – je položen na strategickém bodě (bodech) v síti, aby monitoroval traffic, který přez něj jde a podel toho odchytávat pakety. To je sice hezké, ale může to docela omezit propustnost sítě . Příkladem Network IDS je třeba Snort – Open source program. • host based - prostě na hostitelském kompu je spuštěn nějaký soft, který identifikuje útoky na systém tak, že analyzuje systémová volání, modifikace souborového systému, příchozí data... – prostě nějaký takový antivir • sinature based - monitoruje pakety na síti a porovnává je s databází (vzpomeň na NOD signature database) údajů, Problém je, že když je objevena nějaká nová hrozba,nějaky čas to trvá, než se zanese do databáze -

anomaly based (IDS monitoruje traffic a porovnává ho s „baseline“, což jsou vlastně informace, co by měl normálně traffic obsahovat, jaké protokoly a porty by se měly normálně využívat. Tyto informace jsou získávány nějakou heuristikou sítě Pokud se v trafficu vyskytne nějaká anomálie, IDS informuje admina ) • honeypot – podle překladu je to hrnec s medem, je to tedy nějaké lákadlo pro nebezpečné útočníky, jejich útoky směřuje na sebe, čímž je odvrací od ostatních (cenných) počítačů a navíc tyto útoky může analyzovat a tak sesbírat informace. Komponenty IDS: sensory – generují bezpečnostní události, console – monitorují události, informují o hrozbách a ovládají sensory, Central Engine – ukládá záznamy o událostech (zachycené sensory) do databáze a reaguje na bezpečnostní události. Chyby IDS mohou být buď false positives (zbytečný poplach) nebo false negatives (nezachycený útok) Pasivní x reaktivní IDS – pasivní IDS pouze detekuje hrozby a upozorní na ně, kdežto reaktivní IDS (známý jako IPS, resp. Intrusion Prevention System) dělá nejen to, co pasivní, ale také provádí nějaká opatření proti hrozbám (blokuje je) •

Intrusion Prevention System – je to považováno za takové rozšíření IDS. Výhodou oproti IDS je to, že dokáží v reálném čase reagovat na hrozby (odvrátit je). Většina IPS systémů je schopná sledovat protokoly 7 vrstvy (aplikační), jako jsou HTTP,FTP a SMTP, kteréžto představují největší nebezpečí. Možnosti realizace IPS jsou L7 switch, aplikační firewall + IDS, hybrid switch, inline NIDS.