Rozložení učiva. Vývoj výpočetního modelu, základní paradigmata PC sítí OPAKOVÁNÍ. Síťové protokoly a webové služby

Počítačové sítě 3IT

Rozložení učiva Vývoj výpočetního modelu, základní paradigmata PC sítí OPAKOVÁNÍ Síťové protokoly a webové služby Routery, adresování přes CLI, konstrukce routovací tabulky Statické routování Dynamické routování Navrhování sítí VLAN WAN PPP

Kapitola: Vývoj výpočetního modelu, základní paradigmata PC sítí OPAKOVÁNÍ Vývoj výpočetního modelu, základní paradigmata PC sítí Hodinová dotace: 4 hodiny dávkové zpracování dat model host - terminál file server pracovní stanice tenký klient server based computing přepojování okruhů/packetů spolehlivé, nespolehlivé přenosy

Kapitola: Vývoj výpočetního modelu, základní paradigmata PC sítí OPAKOVÁNÍ Dávkové zpracování dat souhrn Historický aspekt vysoká cena PC, více uživatelů na jedno PC, nedokonalost SW, HW V jedné dávce mohlo být až několik programů (úloha) Rozdělení zdrojů pro jednotlivé dávky Dávkové režimy přestávají mít smysl s příchodem interaktivních systémů Výhody dávkového zpracování Sdílení zdrojů počítače mezi mnoha uživateli a programy Odložení zpracování dávek do doby, kdy je počítač méně vytížen Odstranění prodlev způsobeným čekáním na vstup od uživatele Maximalizace využití počítače zlepšuje využití investic (zejména u dražších počítačů)

Kapitola: Vývoj výpočetního modelu, základní paradigmata PC sítí OPAKOVÁNÍ Dávkové zpracování dat Pro správné pochopení podstaty dávkového zpracování je vhodné si připomenout, čím bylo motivováno: nedokonalostí prvních počítačů. Dokonce nejen tím, že jejich cena byla tak vysoká, že o nějakém výlučném využitím jedním uživatelem se nedalo vůbec uvažovat, a jeden počítač tudíž muselo sdílet více uživatelů. Problém byl i v tom, že neexistovaly dostatečné softwarové a hardwarové prostředky pro podporu souběžného běhu více úloh (které by mohly patřit různým uživatelům), a stejně tak ještě nebyly na dostatečném stupni vývoje ani takové prostředky, které by umožňovaly jednotlivým uživatelům být v průběžném kontaktu se svými úlohami (tedy pozdější terminály, ale hlavně vše, co s jejich využitím souvisí - především pak systémová podpora ze strany operačního systému). Dávkové zpracování je přes svoji historii velmi populární jak v prostředí unixových systémů, tak v prostředí Microsoft Windows. Unixové systémy využívají pro psaní dávek skriptovací jazyky (různé shelly, Perl, Python, ). DOSové systémy disponovaly jednoduchým systémem pro vytváření dávkových souborů v rámci interpretu COMMAND.COM (tzv. bat soubory). Systémy Windows NT obsahují mírně pokročilejší cmd.exe, v současnosti pak Windows Script Host a pokročilý Windows PowerShell.

Kapitola: Vývoj výpočetního modelu, základní paradigmata PC sítí OPAKOVÁNÍ Charakteristika výpočetního modelu host/terminál Vznikl jako reakce na neinteraktivnost dávkového zpracování Dokáže uživatelům zajistit přímý kontakt s jejich úlohami a interaktivní způsob práce Dokáže obsloužit více uživatelů Výhody: Centralizovaný charakter Snadná implementace aplikací Nevýhody: Velké nároky na přenos dat

Kapitola: Vývoj výpočetního modelu, základní paradigmata PC sítí OPAKOVÁNÍ File server (souborový server) Souborový server (zkratka FS, anglicky File Server) je v informatice označení pro počítač (server), který je připojen k počítačové síti a jeho hlavním úkolem je poskytovat přístup k souborům, které jsou na něm uloženy (model klient-server). Výhodou souborového serveru je centralizovaná správa, úspora nákladů, snadnější zálohování, údržba, podpora sdílení dat a podobně Průběh komunikace 1. Klient provede autentizaci uživatele (nebo jiný mechanismus) 2. Klient si připojí ze serveru nabízenou a možnou adresářovou strukturu 3. Klient pošle přes sít serveru požadavky na manipulaci se soubory a adresáři ve formě aplikačního protokolu (SMB, FTP, NFS,...)

Kapitola: Vývoj výpočetního modelu, základní paradigmata PC sítí OPAKOVÁNÍ Tenký klient Je v podstatě klasickým počítačem disponujícím vlastním výpočetním výkonem, ovšem ke běhu náročnějších aplikací by tento výkon nestačil (nebo to není vyžadováno). Na výkonném centrálním serveru pracují všichni uživatelé pod jedním OS. Hlavní výhody 1. Centrální správa OS 2. Jednoduchý HW tenkých klientů 3. Mobilita uživatelů Hlavní nevýhody: 1. Velké nároky na infrastrukturu 2. Vetší riziko chyby 3. Nutné redundance hlavních serverů

Kapitola: Vývoj výpočetního modelu, základní paradigmata PC sítí OPAKOVÁNÍ Server based computing Termín označující implementaci, spouštění a kontrolu aplikace na straně serveru namísto klienta. Tenký klient aplikaci spouští pouze ve formě zobrazovaného rozhraní. Hlavní část aplikace běží na serveru.

Kapitola: Vývoj výpočetního modelu, základní paradigmata PC sítí OPAKOVÁNÍ Přepojování okruhů Předpokládá síť, kde dochází k vytváření souvislých okruhů mezi komunikujícími stranami s danou přenosovou kapacitou. Komunikující strany samy rozhodují o tom, jak využít přenosovou kapacitu, která jim byla vyhrazena. Komunikující strany samy rozhodují, zda-li budou data přenášet jako souvislý proud, či zda je budou členit po blocích určité velikosti, kterou si mohou stanovit samy. Přidelování kanálů lze provádět multiplexováním pro sdílení kapacity systému v čase nebo kmitočtu

Kapitola: Vývoj výpočetního modelu, základní paradigmata PC sítí OPAKOVÁNÍ Přepojování packetů Mezilehlé uzly (směrovače) na cestě rozhodují, jakou cestou se packet pošle dál Přenášené data (rozdělena na jednotlivé bloky - packety) od různých odesílatelů a určené různým příjemcům se přenáší společným přenosovým kanálem. Musí být jasně definováno odkud packet pochází a komu je určen a pořadí Zpracovávání typu store and forward

Kapitola: Vývoj výpočetního modelu, základní paradigmata PC sítí OPAKOVÁNÍ Spolehlivé a nespolehlivé přenosy Detekce chyb Metodika rozpoznání přiřazená doplňující informace (porovnání) např.: Parita přidáním jednoho paritního bitu (lichá, sudá) Kontrolní součet součet jednotlivých dat od odesílatele k příjemci CRC (cyclic rendundancy check) Dostatečně spolehlivý mechanismus umožňující detekci případných chyb Odesilatel aplikuje na odesílaná data algoritmus, na kterém je dohodnut s příjemcem, a který vyplývá z povahy detekčního kódu. Výsledkem je pak zabezpečovací údaj, který odesilatel přišpendlí" k původním datům, a odešle je příjemci. Ten aplikuje na přijatá data přesně stejný algoritmus, a výsledek porovná se zabezpečovacím údajem, který obdržel od odesilatele.

Kapitola: Vývoj výpočetního modelu, základní paradigmata PC sítí OPAKOVÁNÍ Spolehlivé a nespolehlivé přenosy Kontrola přijatých dat se dělá obecně na každé vrstvě. Situace, kdy určitá vrstva se chápe jako svou povinnost postarat se o nápravu případných chyb při přenosu, odpovídá tzv. spolehlivému přenosu (reliable transfer). Opačná situace, kdy daná vrstva sice detekuje případné chyby, ale při jejich výskytu nemá povinnost se postarat o nápravu, odpovídá tzv. nespolehlivému přenosu. Acknowledgement Potvrzení správnosti doručených dat dat od příjemce směrem k odesílateli stop-and-wait acknowledgement - odesílatel si po odeslání každého bloku dat nejprve počká na jeho explicitní potvrzení (nebo na vypršení časového limitu, do kterého by měl potvrzení dostat), a teprve pak podnikne další akci - podle přijatého potvrzení buď odešle další blok, nebo opakuje přenos již jednou odeslaného bloku doba přenosu musí být zanedbatelná

Kapitola: Vývoj výpočetního modelu, základní paradigmata PC sítí OPAKOVÁNÍ Spolehlivé a nespolehlivé přenosy Acknowledgement continuous acknowledgement - odesilatel počítá s tím, že zatímco on bude průběžně vysílat jednotlivé bloky dat, bude mu druhá strana (příjemce) průběžně posílat svá potvrzení. Tomuto způsobu potvrzování se říká spojité potvrzování. Flow Control Když spolu komunikují dva subjekty, je vždy velmi důležité, aby jeden z nich nezahltil toho druhého (např. výkonný PC odesíla a malo výkonný PC přijímá). Navíc příjemce nemusí mít na starosti jen příjem dat. Prakticky vždy je tedy nutné mít k dispozici vhodný mechanismus, kterým by bylo možné regulovat průběh přenosu. Obecně se přitom hovoří o mechanismech pro tzv. řízení toku (flow control).

Kapitola: Vývoj výpočetního modelu, základní paradigmata PC sítí Síťové protokoly a webové služby (10h) Síťové protokoly ISO/OSI - doplnění TCP/IP doplnění TCP UDP ICMP ARP IGMP

ISO/OSI vrstva AJ vrstva CZ jednotka funkce vrstvy příklad Layer 7 Application Aplikační Data Síťové procesy pro aplikaci, ověření uživatelů, vše závislé na aplikaci. Telnet, FTP Layer 6 Presentation Prezentační Data Reprezentace dat a šifrování. Řeší rozdíly v reprezentaci dat mezi aplikací a síťovým formátem - kóduje data pro přenos. MIDI, MPEG Layer 5 Session Relační Data Layer 4 Transport Transportní Segments (segmenty) Spojení mezi aplikacemi, správa session. Komunikace jedné aplikace s druhou, posílání více dat po sobě. Udržuje celé spojení mezi dvěma počítači. End-to-end spojení systémů, spolehlivost - zajišťuje kompletní přenos dat, kvalita služby. Řeší spolehlivé odeslání všech dat ze zdroje do cíle pomocí segmentace a potvrzování. NetBIOS TCP, UDP Layer 3 Network Síťová Packets (pakety) Logická adresace - routování - určení cesty paketu, přenos dat z bodu do bodu, používá IP adresy. Komunikace mezi zdrojovým a cílovým zařízením pomocí IP adresy. IP, ICMP, ARP, RIP Layer 2 Data Link Linková Frames (rámce) Fyzická adresace, MAC - media access control a LLC - logical link control, datový tok, synchronizace rámů, komunikace 1 hop, používá MAC adresy. Detekce chyb, řízení toku a přístupu na médium. Komunikace mezi dvěma zařízeními v jednom subnetu (nebo na bránu) pomocí MAC adresy. Vytváří rámce (hlavička + data + zápatí). Ethernet, FDDI, Token Ring, PPP, SLIP Layer 1 Physical Fyzická Bits (bity) Fyzické parametry linky - média (kabely, rádio, světlo), signály a binární přenos. Řeší fyzické poslání dat (přenášeným bitům nepřiřazuje žádný význam). 100BaseT, RS-232, 802.11g

Kapitola: ISO/OSI model - doplnění ISO/OSI model

Kapitola: ISO/OSI model - doplnění ISO/OSI model L1 Fyzická vrtva: Definuje tvar konektorů, použitý kabel, jaký je který vodič a další mechanické nebo funkční vlastnosti. L2 Linková vrstva: Provádí přenos datových rámců, např. po fyzické kabeláži, používá pro práci MAC adresy sítových rozhraní, kontroluje cílové adresy přijatého datového rámce, rozhoduje, zda odevzdá datové rámce vyšší, nebo nižší vrstvě. Linkový rámec L3 Síťová vrstva: Síťová vrstva zabezpečuje přenos dat mezi vzdálenými počítači WAN (LAN). Základní jednotkou přenosu je síťový paket, který se balí do datového rámce. Síťový paket se také skládá ze záhlaví a datového pole. Se zápatím se u síťových protokolů setkáváme jen zřídka. Síťový packet a jeho vkládání (encapsulation) do linkového rámce

Kapitola: ISO/OSI model - doplnění ISO/OSI model L4 Transportní vrstva: Síťová vrstva zabezpečí spojení mezi vzdálenými počítači, takže transportní vrstvě se jeví jakoby žádné modemy, opakovače, mosty či směrovače na cestě nebyly. Transportní vrstva se zcela spoléhá na služby nižších vrstev. Také předpokládá, že spojení mezi počítači je zajištěno, proto se bez zbytečných starostí může věnovat spojení mezi aplikacemi na vzdálených počítačích.

Kapitola: ISO/OSI model - doplnění ISO/OSI model Komunikace na L4 ISO/OSI

Kapitola: ISO/OSI model - doplnění ISO/OSI model L5 Relační vrstva: Navazuje a ukončuje po datovém přenosu spojení, zabezpečuje přístup k zařízením, má možnost ověření uživatelů. L6 Prezentační vrstva: Data komprimuje, šifruje, data se snaží dostat do sjednocené podoby, neboť různé sítě mohou mít data různě kódovaná. L7 Aplikační vrstva: Aplikační vrstva předepisuje v jakém formátu a jak mají být data přebírána/předávána od aplikačních programů. Např. protokol Virtuální terminál popisuje jak mají být data formátována, ale i dialog mezi oběma konci spojení

Kapitola: TCP/IP model - doplnění TCP/IP Rodina protokolů TCP/IP se nezabývá (až na výjimky) fyzickou a linkovou vrstvou. V praxi se i v Internetu používají pro fyzickou a linkovou vrstvu často protokoly vyhovující normám ISO OSI. Zkratka TCP/IP označuje celou soustavu protokolů přičemž TCP a IP jsou sice nejznámější protokoly této soustavy, ale zdaleka ne protokoly jediné. Správnější je ale považovat TCP/IP za ucelenou soustavu názorů o tom, jak by se počítačové sítě měly budovat, a jak by měly fungovat. Zahrnuje totiž i vlastní představu o tom, jak by mělo být síťové programové vybavení členěno na jednotlivé vrstvy, jaké úkoly by tyto vrstvy měly plnit, a také jakým způsobem by je měly plnit - tedy jaké konkrétní protokoly by na jednotlivých úrovních měly být používány.

Kapitola: TCP/IP model - doplnění ISO/OSI vs TCP/IP ISO/OSI model počítá se soustředěním co možná nejvíce funkcí, včetně zajištění spolehlivosti přenosů, již do komunikační podsítě, která v důsledku toho bude muset být poměrně složitá, zatímco k ní připojované hostitelské počítače budou mít relativně jednoduchou úlohu. Později se ale ukázalo, že například právě v otázce zajištění spolehlivosti to není nejšťastnější řešení - že totiž vyšší vrstvy nemohou považovat spolehlivou komunikační podsíť za dostatečně spolehlivou pro své potřeby, a tak se snaží zajistit si požadovanou míru spolehlivosti vlastními silami. V důsledku toho se pak zajišťováním spolehlivosti do určité míry zabývá vlastně každá vrstva referenčního modelu ISO/OSI.

Kapitola: TCP/IP model - doplnění TCP/IP vs ISO/OSI TCP/IP naopak vychází z předpokladu, že zajištění spolehlivosti je problémem koncových účastníků komunikace, a mělo by tedy být řešeno až na úrovni transportní vrstvy. Komunikační podsíť pak podle této představy nemusí ztrácet část své přenosové kapacity na zajišťování spolehlivosti (na potvrzování, opětné vysílání poškozených paketů atd.), a může ji naopak plně využít pro vlastní datový přenos. Komunikační podsíť tedy podle této představy nemusí být zcela spolehlivá - může v ní docházet ke ztrátám přenášených paketů, a to bez varování a bez snahy o nápravu. Komunikační síť by ovšem neměla zahazovat pakety bezdůvodně. Měla by naopak vyvíjet maximální snahupřenášené pakety doručit (v angličtině se v této souvislosti používá termín: best effort), a zahazovat pakety až tehdy, když je skutečně nemůže doručit - tedy např. když dojde k jejich poškození při přenosu, když pro ně není dostatek vyrovnávací paměti pro dočasné uložení, v případě výpadku spojení apod. Na rozdíl od referenčního modelu ISO/OSI tedy TCP/IP předpokládá jednoduchou (ale rychlou) komunikační podsíť, ke které se připojují inteligentní hostitelské počítače.

Kapitola: TCP/IP model - doplnění TCP/IP L1 Network Interface Layer (Link Layer) Má na starosti vše, co je spojeno s ovládáním konkrétní přenosové cesty resp. sítě, a s přímým vysíláním a příjmem datových paketů. V rámci soustavy TCP/IP není tato vrstva blíže specifikována, neboť je závislá na použité přenosové technologii. L2 Network Layer (IP Layer, Internet Layer) Úkol této vrstvy je v prvním přiblížení stejný, jako úkol síťové vrstvy v referenčním modelu ISO/OSI - stará se o to, aby se jednotlivé pakety dostaly od odesílatele až ke svému skutečnému příjemci, přes případné směrovače resp. brány. Vzhledem k nespojovanému charakteru přenosů v TCP/IP je na úrovni této vrstvy zajišťována jednoduchá (tj. nespolehlivá) datagramová služba.

Kapitola: TCP/IP model - doplnění TCP/IP L3 Transport Layer (TCP Layer) Je nejčastěji realizována právě protokolem TCP (Transmission Control Protocol). Hlavním úkolem této vrstvy je zajistit přenos mezi dvěma koncovými účastníky, kterými jsou v případě TCP/IP přímo aplikační programy (jako entity bezprostředně vyšší vrstvy). Podle jejich nároků a požadavků může transportní vrstva regulovat tok dat oběma směry a zajišťovat spolehlivost přenosu. Přestože je transportní vrstva TCP/IP nejčastěji zajišťována právě protokolem TCP, není to zdaleka jediná možnost. Dalším používaným protokolem na úrovni transportní vrstvy je například protokol UDP (User Datagram Protocol), který na rozdíl od TCP nezajišťuje mj. spolehlivost přenosu - samozřejmě pro takové aplikace, které si to (na úrovni transportní vrstvy) nepřejí.

Kapitola: TCP/IP model - doplnění TCP/IP L4 Application Layer Jejími entitami jsou jednotlivé aplikační programy, které na rozdíl od referenčního modelu ISO/OSI komunikují přímo s transportní vrstvou. Případné prezentační a relační služby, které v modelu ISO/OSI zajišťují samostatné vrstvy, si zde musí jednotlivé aplikace v případě potřeby realizovat samy.

Kapitola: TCP/IP model - doplnění https://commons.wikimedia.org/wiki/file:tcpip_zapouzdreni.svg

- TCP TCP/IP - IP protokol Internetový protokol (Internet Protocol), obvykle se používá zkratka IP, je nejpoužívanější protokol pro komunikaci v počítačových sítích a na celosvětové síti Internetu. Je to množina pravidel popisujících přenos dat prostřednictvím sítě. V současné době je nejhojněji využívaná verze tohoto protokolu IPv4, která používá 32bitové adresy a poskytuje tak asi 4 miliardy adres. Kvůli docházení volných adres se rozšiřuje využití verze IPv6. Internet Protocol je základní protokol síťové vrstvy a celého Internetu. Provádí vysílání datagramů na základě síťových IP adres obsažených v jejich záhlaví. Poskytuje vyšším vrstvám síťovou službu bez spojení. Každý datagram je samostatná datová jednotka, která obsahuje všechny potřebné údaje o adresátovi i odesilateli a pořadovém čísle datagramu ve zprávě. Datagramy putují sítí nezávisle na sobě a pořadí jejich doručení nemusí odpovídat pořadí ve zprávě. Doručení datagramu není zaručeno, spolehlivost musí zajistit vyšší vrstvy (TCP, aplikace).

- TCP TCP/IP - IPv4 Třídy IPv4 třída určující bity rozsah adres maska CIDR maska class A 0 0-127.x.x.x 255.0.0.0 /8 class B 10 128-191.x.x.x 255.255.0.0 /16 class C 110 192-223.x.x.x 255.255.255.0 /24 class D 1110 224-239.x.x.x 255.255.255.255 /32 class E 1111 240-255.x.x.x rezervováno Neveřejné síťové rozsahy síť adresa sítě broadcast adresa adresy hostů 10.0.0.0/8 10.0.0.0 10.255.255.255 10.0.0.1-10.255.255.254 192.168.0.0/16 192.168.0.0 192.168.255.255 192.168.0.1-192.168.255.254 172.16.0.0/12 172.16.0.0 172.31.255.255 172.16.0.1-172.31.255.254

- TCP TCP/IP - IP protokol IPv4 adresace Zjistěte z dané IP rozsah subnetu, ve kterém se nachází. Spočítejte počet použitelných IP adres pro hosty, zjistěte identifikátor sítě a broadcast. 172.16.32.254/24 10.10.10.20/25 10.17.18.239/26 192.168.1.35/27 192.168.88.134/28 10.100.100.100/29 10.0.100.50/30

- TCP TCP/IP - IP protokol 172.16.32.254/24 Network: 172.16.32.0 Netmask: 255.255.255.0 Broadcast: 172.16.32.255 Hosts: 172.16.32.1-172.16.32.254 (254) 192.168.1.35/27 Network: 192.168.1.32 Netmask: 255.255.255.224 Broadcast: 192.168.1.63 Hosts: 192.168.1.33-192.168.1.62 (30) 10.0.100.50/30 Network: 10.0.100.48 Netmask: 255.255.255.252 Broadcast: 10.0.100.51 Hosts: 10.0.100.49-10.0.100.50 (2) 10.10.10.20/25 Network: 10.10.10.0 Netmask: 255.255.255.128 Broadcast: 10.10.10.127 Hosts: 10.10.10.1-10.10.10.126 (126) 192.168.88.134/28 Network: 192.168.88.128 Netmask: 255.255.255.240 Broadcast: 192.168.88.143 Hosts: 192.168.88.129-192.168.88.142 (14) 10.17.18.239/26 Network: 10.17.18.192 Netmask: 255.255.255.192 Broadcast: 10.17.18.255 Hosts: 10.17.18.193-10.17.18.254 (62) 10.100.100.100/29 Network: 10.100.100.96 Netmask: 255.255.255.248 Broadcast: 10.100.100.103 Hosts: 10.100.100.97-10.100.100.102 (6)

- TCP TCP/IP - IP protokol IPv4 adresace Zjistěte z dané IP rozsah subnetu, ve kterém se nachází. Spočítejte počet použitelných IP adres pro hosty, zjistěte identifikátor sítě a broadcast. 192.168.254.35/22 10.0.253.200/23 172.22.3.134/30

- TCP TCP/IP - IP protokol 192.168.254.35/22 Network: 192.168.252.0 Netmask: 255.255.252.0 Broadcast: 192.168.255.255 Hosts: 192.168.252.1 192.168.255.254 (1022) 172.22.3.132/30 Network: 172.22.3.132 Netmask: 255.255.255.252 Broadcast: 172.22.3.135 Hosts: 172.22.3.133 172.22.3.134 (2) 10.0.252.0/23 Network: 10.0.252.0 Netmask: 255.255.254.0 Broadcast: 10.0.253.255 Hosts: 10.0.252.1 10.0.253.254 (510)

- TCP UDP Úkolem UDP (User datagram protokol) transportního protokolu je zajistit negarantovaný přenos dat, stejně jak je tomu při přenosu IP paketů. UDP však umožňuje použít jednu IP adresu cíle a zdroje pro přenos dat mezi více aplikacemi běžícími na koncových stanicích. Tuto možnost IP protokol v sobě integrovanou nemá. Tato vlastnost je velice důležitá u dnešních moderních koncových zařízení, která většinou pracují ve víceúlohovém režimu, kdy současně běží na stroji více aplikací současně. Aby bylo možné odlišit od sebe datové bloky patřící té či oné aplikaci/procesu, je nutné s nimi spojit identifikační informaci a tu přenášet společně v odpovídajících datových blocích sítí. Na protější straně lze díky ní snadno rozeznat, které aplikaci se mají data předat. Výše zmíněná informace může mít různou reprezentaci, nicméně v modelu TCP/IP bylo pro tento účel zavedené 16 bitové číslo. Aby bylo možné identifikovat i zdrojovou úlohu na straně vysílače, používá se toto číslo i pro zdrojovou aplikaci.

- TCP UDP

- TCP UDP UDP protokol, kromě výše zmiňované identifikace portů, umožňuje: Ověřit, zdali doručené datové segmenty jsou správně dlouhé, tj. zda nedošlo při přenosu k jejich zkrácení. UDP protokol k tomu používá pole délka, do něhož se na straně vysílací doplní celkové délka UDP segmentu, těsně před tím, než se segment pošle ke zpracování vrstvě IP. Omožňuje detekovat případný vznik chyb v rozšířeném záhlaví UDP segmentu, včetně uživatelských dat. Toto rozšířené záhlaví zahrnuje některá v průběhu přenosu neměnící se pole z IP paketu, jako je např. cílová a zdrojová adresa a některá další pole. Toto je vlastnost, která odlišuje UDP protokol od IP protokolu a posouvá komunikaci o další stupeň výše. Zasílat datové segmenty více koncovým stanicím současně. Tuto vlastnost dědí UDP od IP protokolu, který ji má také. Zde toto uvádíme pro úplnost, protože později zmiňovaný druhý transportní protokol TCP tuto vlastnost postrádá.

- TCP TCP Druhým v praxi velice často používaným protokolem z architektury TCP/IP je protokol TCP (Transmission Control Protocol). Hlavní motivací pro zavedení tohoto protokolu bylo zajistit spolehlivý přenos dat, tak aby programátor aplikace již nemusel řešit následující problémy, které při přenosu IP paketů mohou nastat. Některé pakety nemusí do cílové stanice vůbec dorazit, protože protokol IP je koncipován od základu tak, že se data přenáší způsobem, kterému se v angličtině říká best effort, což lze volně přeložit, jako snaž se doručit, ale když se to z nějakého důvodu není možné, tak paket zahoď. Zde se jedná o zahození paketů v důsledku chyb v nich vzniklých vlivem fyzikálních podmínek přenosu. Žádný fyzický kanál není totiž za všech podmínek bezchybový protější stanice nemusí být schopna v daném okamžiku zpracovat velký objem generovaných dat stranou vysílací síť je přetížena a není schopna dočasně pakety přijímací stanici doručit, a tak je zahazuje někde podél (v uzlu sítě) cesty k cíli.

- TCP TCP Aby bylo možné garantovat bezchybný a ucelený přenos bloku dat dané aplikace, je nutné tento blok nejprve rozdělit do menších částí - segmentů, které musí být tak dlouhé, aby se každý z nich, včetně servisních informací, vešel do odpovídajícího IP paketu. Pro opětovné sestavení datového bloku na straně přijímače je zapotřebí znát, které ze segmentů nebyly doručené a které naopak ano. Je tedy nezbytné, aby každý vyslaný segment obsahoval kromě části dat aplikačního bloku ještě další identifikátor, který by jej jednoznačně odlišil od ostatních. Přijímací strana takto pozná, který segment z bloku dat chybí, podle chybějícího identifikátoru segmentu. TCP protokol pro identifikaci vysílaných datových segmentů standardně používá celé binární 32 bitové číslo, které se průběžně mění u každého vysílaného segmentu. Mějme však na paměti, že toto číslo není pořadovým číslem vyslaného segmentu, tak jak je tomu u některých jiných protokolů, ale přímo ukazatel místa v datovém bloku aplikace, jehož součástí segment je. To je také důvod, proč se mu říká sekvenční číslo.

- TCP TCP/IP - TCP Aby byl přijímač schopen rozpoznat, který ze segmentů chybí v bloku aplikačních dat musí být každý segment doplněn jednoznačným sekvenčním číslem. Zásadní otázkou však je, od jakého sekvenčního čísla se začnou jednotlivé segmenty bloku dat počítat. Vzhledem k tomu, že je přenos TCP plně duplexní, je nutné mít k dispozici tyto informace na obou komunikujících stranách. Obě strany si proto ve fázi navázání TCP spojení musí vzájemně vyměnit mezi sebou počáteční sekvenční čísla ISN pro jednu a druhou stranu přenosu.

- TCP TCP záhlaví Koncept portů umožňuje vícenásobné použití jedné implementace TCP protokolu pro více procesů na jednom zařízení (nebo operačním systému) s jednou IP adresou. Tato pole jsou 16 bitová, což znamená, že teoreticky lze na jedné IP adrese vytvořit až 65 536 vzájemně nezávislých TCP zásuvek. Spodní rozsah portů od nuly do 1024 je však rezervován pro specifické serverové služby a za normálních okolností se tento rozsah nevyskytuje v poli zdrojový port (jsou však určité výjimky). Pro aktivní zásuvky (klientská část TCP) se volí dočasný dynamicky vytvořený rozsah počínaje většinou hodnotou 1025 a výše (rozsah však závisí na použitém operačním systému).

- TCP TCP - bitové příznaky SYN používá se při navázání spojení. Samotný příznak používá TCP strana aktivní, informuje TCP přijímač o příchozím požadavku na navázání spojení a o nastaveném počátečním sekvenčním čísle (ISN) v sekvenčním poli záhlaví ACK tento příznak se používá vždy, když segment nese potvrzovací číslo. Současné nastavení příznaků SYN a ACK je potvrzením od pasivní strany TCP spojení, že byl přijat požadavek na navázání spojení stranou aktivní a zároveň, že segment v záhlaví nese počáteční sekvenční číslo ISN pro číslování segmentů v opačném směru přenosu od strany pasivní ke straně aktivní 19 FIN používá se při požadavku libovolné strany TCP spojení na ukončení probíhající spojení RST používá se pro obnovu spojení TCP (reset) pokud dojde k nekonzistenci řídících dat spojení nebo když na daném portu není připojená žádná aplikace, nebo je daný port zakázán PSH tento příznak se používá, pokud vysílací část aplikace vyžaduje okamžité předání všech dat ve vyrovnávací paměti přijímací strany TCP protější aplikaci.

- TCP TCP - navázaní spojení Prvotní výměně kontrolních dat (např. hodnoty počátečních sekvenčních čísel) mezi oběma komunikujícími stranami TCP se říká navázání spojení. Teprve po bezprostředním navázání spojení probíhá fáze přenosu dat. TCP protokol byl navržen tak, že používá třífázový systém navázání spojení. Před vlastním popisem procesu navázaní spojení se věnujme otázce, jakým způsobem reaguje TCP přijímací strana při příjmu datového segmentu. Jak již bylo řečeno, TCP zajišťuje spolehlivý přenos dat v tom smyslu, že všechna aplikační data jsou doručena beze změn protější aplikaci.

- TCP TCP - navázaní spojení Navázání spojení, viz obrázek, se uskutečňuje výměnou tří řídicích zpráv (three way handshake). Tyto zprávy se přenáší doplněním odpovídajících informací do záhlaví TCP segmentů. V záhlaví TCP segmentu se nachází kromě 32 bitového sekvenčního (na obrázku označené jako sek ) a potvrzovacího čísla (na obrázku označené jako ack ) i pole jednobitových bitových příznaků (SYN, ACK, URG, PSH, FIN, RST). Dva z těchto příznaků v různé kombinaci jsou použity ve fázi navázání TCP spojení, konkrétně SYN a ACK. Při navázaní TCP spojení je ve většině případů aktivní jedna strana spojení (typicky klient v modelu klient/server) a druhá strana pasivní (strana serveru).

- TCP TCP/IP - navázaní spojení Aktivní strana vyšle první TCP segment s nastaveným příznakem SYN, který indikuje počáteční sekvenční číslo ISN (Initial Sequence Number) v poli sek (v našem případě se jedná o hodnotu ISNA) pro směr A-B. Tímto sděluje aktivní strana TCP, že svá data bude číslovat počínaje hodnotou ISNA+1. Pokud tato zpráva dojde k pasivní straně TCP, tak ta, pokud je spojení akceptovatelné, odešle aktivní straně odpověď v TCP segmentu v jehož záhlaví nastaví bitový příznaky 21 SYN a ACK a do pole sekvenčního čísla sek dosadí své ISN číslo pro opačný směr přenosu dat B-A (v našem případě to bude hodnota ISNB). Nastavením příznaku SYN v TCP záhlaví odpovědi signalizuje aktivní straně, že v tomto segmentu se nachází platné počáteční číslo pro obráceny směr přenosu. Příznak ACK signalizuje potvrzení přijetí zprávy od A ve směru od pasivní (server) strany TCP spojení k aktivní straně (klient). Pokud aktivní strana tuto odpověď přijme, má potvrzeno, že je spojení obousměrně funkční a také, že protější strana akceptovala její, tedy klientské počáteční sekvenční číslo. Stále ale chybí toto potvrzení straně pasivní. Z tohoto důvodu má aktivní strana TCP ještě za povinnost poslat v rámci procesu navázání spojení poslední, v pořadí třetí, zprávu, která potvrdí, že i aktivní strana akceptovala počáteční sekvenční číslo strany opačné (server). Výměnou výše uvedených tří řídicích segmentů je provedeno navázání TCP spojení, které tak přechází do další fáze přenosu dat

- TCP TCP/IP - ukončení spojení Vzhledem k tomu, že s každým TCP spojením souvisí určité množství rezervové paměti, je nutné ji uvolnit, pokud sestavené TCP spojení není již potřeba. Pro ukončení spojení nelze použít dobu nečinnosti, protože TCP spojení může být teoreticky navázané, aniž by se v daném okamžiku přenášela určitá data. Teoreticky může být TCP spojení nekonečně dlouhé a přitom se jím mohou přenášet data jen po velice krátkou dobu, nebo interval. Nemáme tedy jinou možnost, jak nepotřebné spojení deaktivovat, než přímou indikací ukončení spojení. Tento princip u TCP musí existovat, protože by časem nerozpojená a nepotřebná TCP spojení vyčerpala většinu prostředků v koncovém systému (paměť, ale i CPU). Je to stejné, jako když v programu programátor uvolňuje již nepotřebné dynamicky alokované prostředky.

- TCP TCP - ukončení spojení Explicitní metoda ukončení TCP spojení je založena na výměně zpráv mezi oběma TCP stranami, podobně jako se realizuje navázání TCP spojení. Ukončení spojení je však poněkud složitější. Pokud totiž jedna strana TCP žádá o ukončení spojení, protože v tomto směru již není zapotřebí data předávat, nemusí stejné podmínky platit i v opačném směru, kdy protější strana ještě určitá data potenciálně k přenosu mít může. Z tohoto důvodu je fáze ukončení spojení dvoustupňová. Nezávisle na sobě se ukončuje spojení nejprve v jednom a potom i v druhém směru. Pro každý směr jsou k tomu zapotřebí dvě zprávy, tj. celkově pro úplné ukončení TCP spojení jsou zapotřebí zprávy čtyři (4 way handshake), viz obrázek. Ukončení spojení v daném směru TCP přenosu se signalizuje protější straně nastavením příznaku FIN v záhlaví posledního datového segmentu. Protější strana odpoví na tento segment klasickým potvrzením ACK, čímž se v tomto směru tok data ukončí. Následuje ukončení spojení ve druhém směru podle stejných pravidel. Spojení TCP je plně ukončené pokud je ukončené v obou směrech.

- TCP TCP - TCP navázání spojení Navázání spojení: Klient odešle na server datagram s nastaveným příznakem SYN a náhodně vygenerovaným číslem sekvence (x), potvrzovací číslo=0. Server odešle klientovi datagram s nastavenými příznaky SYN a ACK, potvrzovací číslo=x+1, číslo sekvence je náhodně vygenerované Klient odešle datagram s nastaveným příznakem ACK, číslo sekvence=x+1, číslo odpovědi=y+1. Ukončení spojení: Klient odešle datagram s nastaveným příznakem FIN Server odpoví datagramem s nastaveným příznakem ACK Server odešle datagram s nastaveným příznakem FIN Klient odpoví s nastaveným příznakem ACK Teprve po těchto čtyřech krocích je spojení ukončeno.

Kapitola: TCP TCP/IP - TCP řízení přetížení Důležitou funkcí při přenosu datových segmentů TCP protokolem je schopnost reagovat na aktuální zatížení v síti. Pokud by TCP spojení nebralo v úvahu aktuální zatížení sítě, docházelo by k lavinovému přetížení síťové cesty, podél níž se TCP segmenty přenášejí v IP paketech, což by vedlo k významnému snížení propustnosti.

ARP Protokol ARP (Address Resolution Protocol) umožňuje překlad IP adresy na fyzickou hardwarovou adresu. Protokol IP (vrstva 3, síťová) přiřazuje každému hostitelskému počítači jedinečnou adresu, která se skládá z hostitelské a síťové části. Paket IP obsahuje zdrojovou a cílovou IP adresu. Směrovač poté zjišťuje cílovou adresu a rozhodne o nejlepší cestě paketu. Bez ohledu na to, kam paket směřuje, musí projít nejdříve sítí LAN. Pohyby paketů v síti LAN ale řídí datová vrstva (vrstva 2). Ta však rozumí pouze fyzickým hardwarovým adresám. Pro snížení zatížení sítě jsou záznamy s překlady IP adres uchovávány v mezipaměti. Než počítač zahájí proces ARP, prozkoumá nejdříve mezipamět pro spojení IP a fyzické adresy. Tento záznam je v paměti ponechán určitou dobu, nazývanou časovač. Záznam je obnovován po přijetí dalšího paketu ARP ze sítě.

Reverzní ARP Tento protokol je má opačnou funkci k protokolu ARP. Tedy překlad známé fyzické adresy na adresu IP. Tento protokol bývá využíván na bezdiskových pracovních stanicích. Ty totiž nemají kam si uložit záznamy o IP adresách a záznam o své IP adrese získávají ze serveru Toto řešení ovšem vyžaduje přítomnost serveru RARP v síti. Postup je získání adresy je následující: bezdisková stanice vyšle všem hostitelům v síti paket RARP. Počítač, nakonfigurovaný jako server, vyhledá podle MAC adresy příslušnou IP adresu a odešle ji zpět. Pracovní stanice paket příjme a uloží si jej do své paměti. Protokol RARP nemusí být opakován až do opětovného restartu bezdiskové stanice.

ICMP Protokol ICMP (Internet Control Message Protocol) slouží pro přenos chybových a řídících zpráv mezi uzly a směrovači sítě TCP/IP. Mnoho běžně používaných síťových pomůcek je realizováno právě pomocí protokolu ICMP, jako příkaz traceroute, který přenáší UDP datagram se speciálně nastavenou hlavičkou (IP TTL pole). Také příkaz ping využívá protokolu ICMP a to příkaz Echo Request/replay. K základním funkcím protokolu ICMP patří: 1. testování dostupnosti a stavu cílového uzlu sítě (Echo Request/Reply) 2. řízení zahlcení sítě a toku paketů (Source quench) 3. aktualizace směrovacích tabulek uzlů od IP směšovačů (Redirect) 4. odesílání masky podsítě (Address mask request/reply)

Záhlaví ICMP Symboly v polích záhlaví protokolu ICMP a jejich význam: Označení: Význam: TYPE (Type) Typ a formát zprávy ICMP (Echo, Teplat) CODE (Code) Upřesnění informace k typu zprávy CHS (Checksum) Zabezpečení zprávy proti chybám I (Identifier) Identifikace odpovědi k vyslanému požadavku SN (Sequence Number) Sekvenční číslo zprávy OD (Optional Data) Přenášené inf. A zprávy protokolu ICMP Kódy příkazu pole TYPE protokolu ICMP: Kód: Význam: 0 Echo Replay 3 Destination Unreachable 4 Source Quench 5 Redirect 8 Echo Request Kódy příkazu pole CODE protokolu ICMP: Kód: Význam: 0 Network Unreachable 1 Host Unreachable 2 Protocol Unreachable 3 Port Unreachable 4 Fragmentation Needed 5 Source Route Failed 6 Network Unknown 7 Host Unknown

Telnet Protokol Telnet (TELecommunication NETwork) je jedním z nejstarších protokolů sítí TCP/IP (+1969). Zajišťuje standardní metodu spojování vzdálených terminálových zařízení a terminálových procesů přes síť prostřednictvím obousměrné, znakově orientované, komunikace. Výhodou tohoto protokolu je jeho schopnost připojit fyzický terminál jednoho počítače k jinému počítači sítě tak, jako by byl jeho fyzikým terminálem (tzv. virtuální terminál). Jediným neduhem tohoto protokolu je zabezpečení. V době jeho vzniku, kdy internet byl ještě teprve v plenkách, byla většina propojených uživatelů byli lidé z počítačových oddělení výzkumných a vládních institucí. Nebyl důvod pro nějaké šifrování a zabezpečení. Pokud budeme tento protokol používat dnes, je nutné použít nějaké doplňkové zabezpečení přenosu, např. protokol SSH, který poskytuje robustní ochranu před napadením citlivých dat zvenčí.

Telnet Protokol Telnet vychází z modelu Klient-Server. Klient představuje proces požadující terminálový přístup ke vzdáleným uzlům sítě. Server protokolu Telnet je proces, běžící na vzdáleném počítači, který se chová vůči procesům běžícím na počítači jako lokální terminál. Proces serveru očekává požadavky klientů na portu TCP/23. Po vytvoření TCP spojení jsou data přenášena po řádcích spolu s řídícími znaky protokolu Telnet. Server Telnet odevzdává data přímo aplikaci, s níž virtuálně komunikuje vzdálený terminál. Vzdálenému počítači se spojení jeví, jako by byl přímo připojen k cílovému počítači. V rámci protokolu Telnet je dvě základní služby.

FTP (File Transfer Protocol) FTP je protokol pro přenos souborů v sítích TCP/IP. Je využíván například různými internetovými archivy souborů nebo pro upload souborů na webový server. Implementace protokolu FTP vychází z architektury klient-server. Klient je iniciátorem přenosu souborů, server je druhou stranou, která spolupracuje. Klient je typicky představován programem, který si spustíme na počítači, a serverem je démon na počítači, kam nebo odkud chceme soubory přenést. Směr přenosu přitom není důležitý. Protokol FTP se snaží minimalizovat nároky na různé systémové prostředky - žádá o jejich přidělení až na základě skutečné potřeby, a po jejich použití je zase vrátí. Po celou dobu komunikace mezi klientem a serverem existuje jen to, co zajišťuje vysílání a příjem nejrůznějších příkazů a odpovědí mezi klientem a serverem, to, co je potřeba pro přenos dat, vzniká dynamicky na základě potřeby.

FTP (File Transfer Protocol) FTP je protokol pro přenos souborů v sítích TCP/IP. Je využíván například různými internetovými archivy souborů nebo pro upload souborů na webový server. Implementace protokolu FTP vychází z architektury klient-server. Klient je iniciátorem přenosu souborů, server je druhou stranou, která spolupracuje. Klient je typicky představován programem, který si spustíme na počítači, a serverem je démon na počítači, kam nebo odkud chceme soubory přenést. Směr přenosu přitom není důležitý. Protokol FTP se snaží minimalizovat nároky na různé systémové prostředky - žádá o jejich přidělení až na základě skutečné potřeby, a po jejich použití je zase vrátí. Po celou dobu komunikace mezi klientem a serverem existuje jen to, co zajišťuje vysílání a příjem nejrůznějších příkazů a odpovědí mezi klientem a serverem, to, co je potřeba pro přenos dat, vzniká dynamicky na základě potřeby.

FTP (File Transfer Protocol) Řídící spojení Jeho úkolem je nejprve navázat spojení s interpretem protokolu na serveru, a poté iniciovat jednotlivé akce a řídit jejich průběh. Interpret na serveru čeká na navázání spojení na portu TCP, implicitně 21. Jakmile je spojení navázáno, existuje po celou dobu existence relace a je využíváno pro potřeby řízení relace. Pro komunikaci je použito protokolu TCP/IP. Datové spojení Jakmile se interpreti dohodnou, že budou přenášet data, vytvoří si každý svůj přenosový proces (DTP, Data Transfer Process). Tyto procesy si pak mezi sebou naváží samostatné spojení (opět prostřednictvím TCP, tedy spolehlivé a spojované), a jeho prostřednictvím zajistí přenos dat. Při vlastním přenosu jsou veškerá data přenášena zásadně jako 8-bitové Byty. Navázání řídícího spojení zajišťuje klient, povinnost navázat datové spojení má naopak server (tzv. aktivní mód), nebo klient (tzv. pasivní mód). V aktivním módu sdělí klient serveru, na kterém portu naslouchá (port 20, často také vyšší než 1024) a server vytvoří datové spojení, v pasivním módu klient přikáže serveru naslouchat (server v odpovědi sdělí adresu a port) a sám se připojí. Pasivní mód je výhodný z hlediska konfigurace firewallů, kdy je jednodušší z hlediska bezpečnosti povolit spojení vytvořené pouze klientem, než předpokládat náhodně vybraný port datového spojení. Protokol také připouští, aby klient řídil přenos mezi dvěma servery. Řídící spojení je mezi klientem a oběma servery, datové se vytváří pouze mezi servery. Data tak neproudí přes klientský počítač.

FTP (File Transfer Protocol) FTP Server FTP je dnes jednou z nejčastěji používaných služeb na Internetu pro předávání dat. Je určena jak k downloadu a uploadu souborů z serveru nebo na server, tak i k práci se soubory přímo na disku vzdáleného počítače na němž běží FTP server. Pro přístup k FTP serveru se používá nejčastěji FTP klient, který poskytuje výhody grafického prostředí a nevyžaduje hlubší znalosti FTP protokolu. Je jich celá řada jak z kategorie shareware tak i freeware např. CuteFTP, či Total Commander. TFTP (Trivial File Transfer Protocol) Je velice jednoduchý protokol pro přenos souborů, obsahující jen základní funkce protokolu FTP. Jeho specifikace byla poprvé uveřejněna v roce 1980. TFTP je určen pro přenos souborů v případech, kdy je běžný protokol FTP nevhodný pro svou komplikovanost. Typickým případem je bootování bezdiskových počítačů ze sítě (viz také BOOTP), kdy se celý přenosový protokol musí vejít do omezeného množství paměti, která je k dispozici na bezdiskovém stroji.

SSH Zkratka SSH pochází s anglického sousloví Secure Shell. Jde o bezpečnou (šifrovanou) komunikaci mezi dvěma počítači. SSH použijeme, chceme-li například ovládat počítač na dálku (k němuž máme přihlašovací údaje) nebo třeba jen přenášet soubory. SSH jakožto zabezpečený komunikační protokol vznikl v reakci na špatně zabezpečené (ba přímo nebezpečné) protokoly a příslušné služby typu Telnet. Ve své nejzákladnější podobě se pomocí SSH vzdálený počítač ovládá pouze pomocí příkazové řádky (terminálu, konzole). Ovšem je možné díky SSH tunelu ovládat i vzdálenou plochu, a tedy i grafické rozhraní systému včetně programů.

SSH Ovládání SSH přes terminál se báječně hodí například na správu vzdáleného počítače, ke kopírování a přenášení souborů (SCP, viz níže) nebo třeba používání určitých programů, u kterých není nutné pracovat s grafickým rozhraním (vědci a technici třeba ocení možnost mnohem vyššího výpočetního vzdáleného serveru, ke kterému v danou chvíli nemají přístup). Využití SSH je opravdu široké zmiňme dále třeba administraci serverů, založení VPN (virtuální privátní sítě), přesměrování portů TCP i X11 nebo brouzdání po webu přes proxy se šifrováním. Díky síťovému tunelování je tento komunikační kanál pro tyto účely velmi bezpečný. Tyto vlastnosti ocení samozřejmě i jednotlivec/domácí uživatel, který pomocí SSH může vzdáleně spravovat svůj počítač či bezpečně kopírovat mezi počítači data.

SSH Nejčastěji se SSH používá mezi unixovými a Unixu podobnými systémy, zejména pak mezi dvěma linuxovými stroji. To však neznamená, že uživatelé Windows jsou o SSH implementaci ochuzeni: Z Windows se dá připojit na tyto systémy, na kterých SSH server běží, velmi snadno, například pomocí bezplatného (a open-sourcového) programu WinSCP (ten primárně slouží pro přenos souborů přes SSH/SCP či FTP a SFTP) a dalších (o tom později). Stejně tak je možnost na Windows provozovat i samotný SSH server. První verze protokolu SSH-1 byla navržena Tatu Ylönenem, který v červnu v letech 1995 poskytnul tento protokol veřejnosti spolu se zdrojovými kódy (freeware). Do konce téhož roku začalo tento protokol využívat více jak 20 000 uživatelů v padesáti zemích. Ke konci roku 1995 Tatu Ylönen založil společnost SSH Communications Security, která začala vyvíjet SSH dále, ale již ne jako freeware, ale uzavřenou licenci. O rok později vyšla nekompatibilní verze SSH-2, která zaručovala vyšší bezpečnost, díky využítí Diffie-Hellman algoritmu pro výměnu klíčů, kontrola integrity dat pomocí MAC funkce. Oproti SSH-1 mohl SSH-2 řídit libovolný počet shellů pomocí jednoho SSH spojení. Postupem času byly vyvíjeny a zdokonalovány volně šiřitelné verze SSH jako jsou OSSH a později pak OpenSSH, který narozdíl od předchozí verze (OSSH) umožňoval portování i na jiné operační systémy. V roce 2006 byl protokol SSH-2 navržen jako internetový standart.

SSH - vrstvy Transportní vrstva: v této vrstvě probíhá veškeré počátační ověřování klíčů, serverová autorizace, odesílání/přijímání paketů, komprese a ověřování intergrity. Autentifikační vrstva: probíhá zde autentifikace samotného klienta, a to více způsoby. Několik možností ověření autorizace, například - heslo, veřejný klíč, aktivace klávesnicí a nebo GSSAPI. Vrstva spojení: zajišťuje standardní typy kanálů jako jsou terminálové shelly, directtcpip, forwarded-tcpip atd..

SSH - klíče

SSH - klíče Autentizace obecně slouží k tomu, abychom počítači dokázali, že jsme ten uživatel, za kterého se prohlašujeme. Nejčastějším nástrojem autentizace je heslo. To má ale v praktickém životě několik nevýhod: dá se (často) uhodnout, mělo by být složité, musíte si jej pamatovat a hlavně je možné jej odposlechnout. Kompromitovaný SSH server tak může například sledovat, co píšete na klávesnici a na který další počítač se přihlašujete. Navíc pokud používáte jedno extra složité heslo na více strojích, má útočník přístup ke všem. Všechny výše zmíněné nevýhody řeší metoda přihlašování k SSH pomocí veřejného klíče. Princip je velmi jednoduchý: máme soukromý a veřejný klíč, ten veřejný nahrajeme na všechny naše servery a privátní si necháme. Jelikož není možné z veřejného klíče zpětně ten privátní odvodit, servery nemohou tyto klíče využít k přihlášení mezi sebou, ale jen k ověření vaší totožnosti jakožto držitele privátní části. Přihlašování pak funguje tak, že server vygeneruje náhodná data, která vám pošle. Vy je svým privátním klíčem podepíšete a pošlete zpět. Server pomocí veřejného klíče, který jste mu předtím dodali, ověří pravost podpisu a pustí vás dovnitř. To vše samozřejmě plně automaticky a velmi rychle. Navíc nedochází vůbec k přenosu tajné informace privátního klíče. Vlastně tak jednoduše serveru prokážete znalost hesla, aniž mu ho musíte ukázat. Díky tomu není server schopen klíč jakkoliv zjistit, zkopírovat a zneužít. Ať by byl server modifikován jakkoliv. Ze stejného důvodu je pak možné jeden veřejný klíč nahrát na libovolný počet serverů nebo jej zveřejnit třeba na webu s informací Kdo mě chce pustit na svůj server, ať si stáhne můj veřejný klíč. Takový postup je přitom naprosto bezpečný a nijak tím neohrožujete své další servery.

SCP Secure Copy nebo také SCP slouží k bezpečnému přenosu souborů mezi dvěma počítači propojenými počítačovou sítí pomocí protokolu Secure Shell (SSH). SCP má omezené možnosti, a proto je nahrazován komplexnějším protokolem SFTP. Zkratka SCP může označovat protokol nebo program. SFTP SSH File Transfer Protocol (zkratka SFTP) označuje v informatice protokol a zároveň i program pro bezpečný přenos souborů pomocí počítačové sítě. Jeho možnosti jsou obdobné jako u FTP a také je využíván jako náhrada za jednoduchý protokol SCP. Pro vlastní přenos dat využívá SFTP obvykle SSH-2.

DHCP Protokol DHCP (Dynamic Host Configuration Protocol) je používán k dynamickému přiřazování IP adres všem hostitelům v síti. S nárůstem mobilních počítačů je nevýhodné používat pevné adresy IP. Díky dynamickému přiřazování IP adres si uživatel nemusí pamatovat přihlašovací údaje (IP adresa, maska podsítě, výchozí brána, atd.) ke každé síti do které se připojuje. Hlavní předností tohoto protokolu je možnost okamžitého použití (plug-and-play). Pomocí DHCP protokolu je IP adresa podstatě jen zapůjčena. Je-li počítač od sítě odpojen a platnost adresy vyprší, může být tato IP adresa přiřazena jinému počítači.

DHCP Stavy: 1.Inicializace - po připojení do sítě hostitel vysílá požadavek DHCP pro zjištění všech DHCP serverů v síti. 2. Výběr - v této fázi klient obdrží zprávy od DHCP serverů. Nejsou-li v síti žádné servery, hostitel nic neobdrží. Je-li naopak v síti více DHCP serverů, pak si musí hostitel jednu z nabídek vybrat (třeba tu první). Každá z nabídek obsahuje informace o příslušné konfiguraci. Po jejím výběru vstupuje klient do stavu vyjednávání (délka zapůjčení adresy apod.) a zpětně odešle zprávu. 3. Požadavek - server přijme požadavek hostitele a zahájí zapůjčku IP adresy. 4. Vazba - klient začne zapůjčenou adresu používat. V tomto stavu klient funguje normálně - je připojen. Nyní si může klient adresu uložit a znovu o ni požádat po restartování. Vyprší-li doba zapůjčení adresy, klient odešle serveru žádost o její prodloužení. Po jejím zasání klient přechází do dalšího stavu. 5. Obnovení - klient čeká na odpověď ze serveru. Příjde-li kladná odpověď, vrací se klient do předchozího stavu. Byl-li požadavek klienta odmítnut, přechází klient do prvního stavu - inicializace. Neobdrží-li však klient žádnou odpověď do uplynutí určité doby (timeout), klient předpokládá nedostupnost serveru a přechází do šestého stavu. 6. Obnovení vazeb - klient zahájí vysílání požadavků o prodloužení expirace adresy na všechny ostatní servery v síti. Dostane-li klient kladnou odpověď od jakéhokoliv serveru, přechází opět do stavu VAZBA. V opačném případě přechází do stavu INICIALIZACE.

DHCP

DHCP Loopback: V protokolu TCP/IP slouží loopback zařízení jako virtuální síťové rozhraní. Toto síťové rozhraní je čistě softwarovou záležitostí a není tedy připojeno k žádnému hardware, nicméně je plně integrování do vnitřní síťové struktury počítače. Veškerý provoz směřovaný na toto zařízení je okamžitě přesměrováno na totéž rozhraní. Tímto způsobem popisuje protokol IP síť loopback. V IPv4 této síti přísluší dle RFC 3330 prefix 127/8. Nejpoužívanější adresa pro zařízení loopback je 127.0.0.1, nicméně je pro tento účel možné použít libovolnou adresu z rozsahu 127.0.0.0 až 127.255.255.255. Oproti tomu IPv6 má pro loopback vyhrazenu pouze jednu IP adresu, a to 0:0:0:0:0:0:0:1 (lze též napsat jako ::1). Běžné, oficiálně stanovené doménové jméno pro tuto adresu je localhost.

HTTP Hyper Text Transfer Protocolu (zkratka HTTP) je jeden z nejdůležitějších protokolů Internetu pro přenos dat mezi serverem a klientem. Před vznikem HTTP byl nejdůležitějším protokolem pro přenos souborů protokol FTP (File Transfer Protocol). HTTP je jednoduchý protokol implementující malou množinu příkazů, schopný přenášet data určená URL adresou. Využívá standardů MIME, díky čemuž se dá rozšiřovat o formáty různých médií. Klienty HTTP představují většinou webové prohlížeče (browsery) a HTTP servery jsou většinou webové servery. Protokol HTTP komunikuje na portu 80 TCP protokolu, při zadávání adresy ve formátu URL je ovšem možno zadat i jiný port.

HTTP Protokol funguje způsobem dotaz-odpověď. Uživatel (pomocí programu, obvykle internetového prohlížeče) pošle serveru dotaz ve formě čistého textu, obsahujícího označení požadovaného dokumentu, informace o schopnostech prohlížeče apod. Server poté odpoví pomocí několika řádků textu popisujících výsledek dotazu (zda se dokument podařilo najít, jakého typu dokument je atd.), za kterými následují data samotného požadovaného dokumentu. Pokud uživatel bude mít po chvíli další dotaz na stejný server (např. proto, že uživatel v dokumentu kliknul na hypertextový odkaz), bude se jednat o další, nezávislý dotaz a odpověď. Z hlediska serveru nelze poznat, jestli tento druhý dotaz jakkoli souvisí s předchozím. Kvůli této vlastnosti se protokolu HTTP říká bezestavový protokol protokol neumí uchovávat stav komunikace, dotazy spolu nemají souvislost. Tato vlastnost je nepříjemná pro implementaci složitějších procesů přes HTTP (např. internetový obchod potřebuje uchovávat informaci o identitě zákazníka, o obsahu jeho nákupního košíku apod.). K tomuto účelu byl protokol HTTP rozšířen o tzv. HTTP cookies, které umožňují serveru uchovávat si informace o stavu spojení na počítači uživatele

HTTP dotazovací metody HTTP definuje několik metod, které se mají provést nad uvedeným objektem (dokumentem). <metoda> <objekt> HTTP/<verze> GET Požadavek na uvedený objekt se zasláním případných dat (proměnné prohlížeče, session id, atd.). Výchozí metoda při požadavku na zobrazení hypertextových stránek, RSS feedů aj. Celkově nejpoužívanější. HEAD To samé jako metoda GET, ale už nepředává data. Poskytne pouze metadata o požadovaném cíli (velikost, typ, datum změny, atd.). POST Odesílá uživatelská data na server. Používá se například při odesílání formuláře na webu. S předaným objektem se pak zachází podobně jako při metodě GET. Data může odesílat i metoda GET, metoda POST se ale používá pro příliš velká data (víc než 512 bajtů, což je velikost požadavku GET) nebo pokud není vhodné přenášená data zobrazit jako součást URL (data předávaná metodou POST jsou obsažena v HTTP požadavku).

HTTP dotazovací metody PUT Nahraje data na server. Objekt je jméno vytvářeného souboru. Používá se velmi zřídka, pro nahrávání dat na server se běžně používá FTP nebo SCP/SSH. DELETE Smaže uvedený objekt ze serveru. Jsou na to potřeba jistá oprávnění stejně jako u metody PUT. TRACE Odešle kopii obdrženého požadavku zpět odesílateli, takže klient může zjistit, co na požadavku mění nebo přidávají servery, kterými požadavek prochází. OPTIONS Dotaz na server jaké podporuje metody. CONNECT Spojí se s uvedeným objektem přes uvedený port. Používá se při průchodu skrze proxy pro ustanovení kanálu SSL.

HTTP struktura požadavku a odpovědi HTTP 1.0 a 1.1 Ukázka jednoduchého požadavku: GET /clanky/obsah.html HTTP/1.1 Ukázka odpovědi: HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Wed, 06 Dec 2000 13:37:40 GMT X-Powered-By: PHP/4.0.3pl1 Content-type: text/html <!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.0 Transitional//EN'> <html> <head> <title>dobývání znalostí z databází 2000</title> <link rel="stylesheet" type="text/css" href="base.css">

HTTP stavové (návratové) kódy

HTTP stavové (návratové) kódy Stavový kód: Popis: 100 Continue Klient může pokračovat v zasílání požadavku. 101 Switching Protocols Server mění protokol. 200 OK Operace proběhla bez chyby, požadavek je úspěšně splněn. 201 Created Výsledkem požadavku je nově vytvořený objekt. 202 Accepted Byl přijat asynchronní požadavek. Požadavek byl správně akceptován, odpovídající činnost se však ještě zatím nemusela provést. 204 No Content Požadavek byl úspěsný, ale jeho výsledkem nejsou žádná data pro klienta. 300 Multiple choises 301 Moved Permanently 302 Moved Temporarily 304 Not Modified Požadovaný zdroj se dá získat z několika různých míst. V odpovědi se vrací seznam všech možností. Požadovaná adresa URL se trvale přesunula na novou adresu URL. Všechny další odkazy musí použít tuto novou URL. Požadovaná adresa URL se dočasně přesunula na novou adresu URL. Všechny další odkazy mohou používat dosavadní URL. Podmíněný požadavek byl správně zpracován, dokument však od udané doby nebyl modifikován.

HTTP stavové (návratové) kódy Stavový kód: 400 Bad Request Server nerozumí požadavku, klient jej musí opravit a poslat znovu. 401 Unauthorized Jestliže byl původní požadavek klienta anonymní, musí být nyní autentizován. Pokud už požadavek byl autentizován, pak byl přistup odepřen. 403 Forbidden Server nemůže požadavku vyhovět, autorizace nebyla úspěšná. 404 Not Found Server nenašel zadanou adresu URL. 405 Method Not Allowed Použitá metoda není přípustná pro dosažení požadovaného objektu. 406 Not Acceptable Požadovaný objekt není k dispozici ve formátu podporovaném klientem. 408 Request Timeout Klient nedokončil odesílání požadavku v časovém limitu. 410 Gone Požadovaný objekt byl trvale odstraněn. 415 Unsupported Media Type Požadavek obsahuje data v serveru neznámém formátu. 500 Internal Server Error Na serveru došlo k neočekávané chybě. 501 Not Implemented Tento požadavek server nepodporuje. 502 Bad Gateway Proxy server nebo brána obdržely od dalšího serveru neplatnou odpověď. 503 Service Unavailable Popis: Server dočasně nemůže nebo nechce zpracovat požadavek. Většinou když je přetížený nebo se provádí údržba. 505 HTTP Version Not Supported Server nepodporuje verzi HTTP v daném požadavku.

HTTP -> HTTPS HTTP Hypertext Transfer Protocol je způsob, kterým se přenášejí data na internetu. HTTP není chráněné před odposloucháváním/sledováním nebo modifikací obsahu. HTTPS tyto problémy řeší šifrováním dat mezi klientem a serverem. Modifikace obsahu Nezabezpečené HTTP spojení nezaručuje, že obsah, který se dostane do prohlížeče, je ten obsah, který vytvořila příslušná webová stránka. Po cestě od webového serveru dané stránky k prohlížeči návštěvníka je možné modifikovat výsledek, aniž by si toho návštěvník všiml.

HTTPS SSL/TLS SSL certifikát je základním kamenem pro HTTPS zabezpečení komunikace mezi webovým prohlížečem a serverem. Při zahájení komunikace si obě strany vymění své veřejné klíče, které jsou podepsány důvěryhodnou certifikační autoritou (CA). Sice je možné si takový SSL certifikát digitálně podepsat sám, ovšem takový certifikát je považován za nedůvěryhodný a při přístupu na webovou stránku zabezpečenou takovým SSL certifikátem je uživatel odrazen na stránku vstoupit varovným hlášením v prohlížeči. Aby taková situace nenastala, potřebujeme důvěryhodný SSL certifikát, který je digitálně podopsaný důvěryhodnou certifikační autoritou. Mezi nejznámější a celosvětově uznávané certifikační autority patří GeoTrust, Thawte, COMODO a prestižní Symantec (známé jako VeriSign). Protokol Transport Layer Security (TLS) a jeho předchůdce Secure Sockets Layer (SSL) jsou kryptografické protokoly, poskytující možnost zabezpečené komunikace na Internetu pro služby jako WWW, elektronická pošta, internetový fax a další datové přenosy. Mezi protokoly SSL 3.0 a TLS 1.0 jsou drobné rozdíly, ale v zásadě jsou stejné

WebDAV World Wide Web Distributed Authoring and Versioning je standardem IETF (Internet Engeneering Task Force) pro vzdálenou správu souborů, který je specifikován v dokumentu RFC 2518 z roku 1999. Dle tohoto dokumentu je WebDAV rozšířením exitujícího protokolu HTTP/1.1, které umožňuje provádět vzdálenou správu souborů uložených na webových serverech. WebDAV spojuje dvě již propracované technologie: HTTP (Hypertext Transfer Protocol) a XML (Extensible Markup Language). Protokol HTTP je používán pro zajištění způsobu komunikace. Kromě standardních příkazů využívaných v rámci protokolu HTTP (GET, COPY, OPTIONS ) zavádí WebDAV pro své potřeby některé nové. XML naopak WebDAV využívá jako nositele strukturovaných informací, které upřesňují jak dotaz klienta, tak i výsledek zasílaný serverem. V XML části komunikace jsou odesílány výsledky zpracování příkazů pro jednotlivé soubory, informace o souborech a adresářích a podobně.

WebDAV Mezi fukce, které nám WebDAV nabízí můžeme zařadit základní operace se soubory (kopírování, přesunutí, mazání) a adresáři. Rád bych na tomto místě upozornil, že WebDAV chápe adresáře trochu jinak, než jak je známe z běžné práce na lokálním počítači. WebDAV dále umožňuje připojovat k jednotlivým souborům a adresářům informace (vlastnosti), které můžeme později číst, upravovat nebo mazat. Při ukládání vlastností není uživatel omezen jen standardními vlastnostmi WebDAVu. WebDAV rozeznává dva typy zámků: Exclusive Lock (individuální) Shared Lock (společný). Exclusive Lock odpovídá asi nejrozšířenější podobě zámku, kdy majitelem zámku je jen jeden uživatel. Shared Lock naopak umožňuje manipulovat se zdrojem většímu počtu uživatelů, přičemž je možné kombinovat oba dva typy zámků.

POP3 POP (Post Office Protocol) je internetový protokol, který se používá pro stahování emailových zpráv ze vzdáleného serveru na klienta. Jedná se o aplikační protokol pracující přes TCP/IP připojení. V současnosti je používána zejména třetí verze (POP3), která byla standardizována v roce 1996 v RFC 1939. POP3 je následníkem protokolů POP1 a POP2 (označení POP už dnes téměř výhradně znamená POP3). V současné době používají téměř všichni uživatelé elektronické pošty pro stahování emailů programy využívající POP3 nebo IMAP. Jako mnoho jiných starších internetových protokolů, POP3 původně podporoval jenom nešifrované přihlašovací mechanismy. Ačkoli v POP3 je běžný jednoduchý (nezabezpečený) přenos hesel, podporuje současně několik autentizačních metod ověřování na různých úrovních ochrany před neoprávněným přístupem k cizí poštovní schránce. Jedna taková metoda, APOP (kterou základní specifikace definuje jako volitelný příkaz ), užívá MD5 hash funkci pro zabezpečený přenos hesla od klienta na server. Klienti podporující APOP jsou například Mozilla, Thunderbird, Eudora a Novell Evolution. Klienti mohou také šifrovat celou POP3 komunikaci užitím SSL nebo modernějšího TLS. Protokol POP3 má pro své účely vyhrazen TCP port 110. Komunikace probíhá na principu výměny zpráv mezi klientem a serverem.

IMAP U protokolu IMAP (Internet Message Access Protocol) je naprosto klíčové, abyste si uvědomili, že vám umožňuje prohlížet složky elektronické pošty naprosto stejným způsobem na libovolném zařízení, protože se obsah schránky synchronizuje. Tuto synchronizaci zajišťuje centrální poštovní server. Pokud používáte u své poštovní schránky protokol IMAP, jsou složky pro přijatou, odeslanou poštu a popřípadě i další složky stejné, resp. mají stejný obsah, a to ať kontrolujete poštovní schránku ze svého mobilního telefonu, tabletu či počítače. Obecně panuje shoda na tom, že vhodnější je používání modernějšího protokolu IMAP a že používání zastaralého standardu POP3 by mělo být za každou cenu potlačeno. Nic však není tak jednoznačné.

IMAP vs POP Protokol POP3 (Post Office Protocol) je navržen zejména pro stahování e-mailů ze serveru poskytovatele elektronické pošty do vašeho počítače. Operace, které provádíte, se pak nijak nesynchronizují se serverem, jako je tomu u protokolu IMAP. jedná se skutečné o pouhé stažení e-mailu do počítače. V naprosté většině případů (ale ne ve všech) je protokol POP nakonfigurován tak, aby poštovní server, na kterém je e-mail uložen, byl z tohoto serveru po stažení do místního počítače smazán. Nicméně byste měli vědět, že je možné nastavit svůj program pro práci s elektronickou poštou i tak, aby na serveru e-maily ponechával. Co se týče konfigurace programů pro práci s elektronickou poštou, je konfigurace v případě protokolu IMAP o něco jednodušší. Není tedy divu, že většina programů pro práci s elektronickou poštou vytváří standardně účty elektronické pošty, které využívají právě protokol IMAP. U protokolu POP je však často nutné provádět konfiguraci ručně. Bohužel situaci zhoršuje i to, že poskytovatelé elektronické pošty, kteří upřednostňují protokol IMAP, často protokol POP3 vůbec nepodporují, nebo alespoň nikde neuvádí žádné podrobnější informace, jak si může uživatel nastavit v programu pro práci s elektronickou poštou svůj vlastní účet elektronické pošty tak, aby využíval protokol POP3. A přitom to, co jsme dosud popisovali, se odehrává pouze na straně serveru. Protokol POP3 však musí podporovat i váš program pro práci s elektronickou poštou, což rozhodně není samozřejmé.

IMAP vs POP Dalším důvodem, proč využívat POP, je problém zabezpečení. V dnešním světě plném afér se zcizením dat se nemusí každému uživateli jevit jako nejvhodnější řešení ponechávání svých osobních dat, jako jsou například právě e-maily, na naprosto cizím serveru. E-maily uložené na serveru, nad kterým nemáte jako obyčejný uživatel žádnou moc, představuje otevřená vrátka pro veškerý soudní aparát stačí mít v ruce ta správná razítka. Pokud uložíte své e-maily na svá vlastní zařízení mimo těchto serverů spravovaných třetí stranou, pak máte své e-maily relativně v bezpečí, protože každý, kdo by si chtěl vaše e-maily prohlížet, musí přijít přímo za vámi a nikoliv k poskytovateli poštovní schránky. Výše uvedený argument samozřejmě má svoje slabiny, jelikož email se dá zachytit i během svého putování Internetem. Poskytovatel poštovní schránky také může mít redundantní zálohy vašich e-mailů, které dosud nesmazal to všechno samozřejmě hraje proti použití protokolu POP3 jakožto řešení pro zajištění soukromí. Ještě, že je tu možnost šifrování e-mailů. Je samozřejmé, že naprostá většina uživatelů se zřejmě nikdy nestane cílem pátrání policejních orgánů. Nicméně pro řadu uživatelů jsou tyto okolnosti týkající se zabezpečení zásadního charakteru.

IMAP vs POP IMAP (Internet Message Access Protocol) Port: 143 (nezabezpečené spojení) 993 (šifrované spojení SSL) POP3 (Post Office Protocol - Version 3) Port: 110 (nezabezpečené spojení) 995 (šifrované spojení SSL)

SMTP Simple Mail Transfer Protocol (zkratka SMTP) je internetový protokol určený pro přenos zpráv elektronické pošty (e-mailů) mezi přepravci elektronické pošty (MTA). Protokol zajišťuje doručení pošty pomocí přímého spojení mezi odesílatelem a adresátem; zpráva je doručena do tzv. poštovní schránky adresáta, ke které potom může uživatel kdykoli přistupovat (vybírat zprávy) pomocí protokolů POP3 nebo IMAP. Jedná se o jednu z nejstarších aplikací, původní norma RFC 821 byla vydána v roce 1982 (v roce 2001 ji nahradila novější RFC 2821). SMTP funguje nad protokolem TCP, používá port TCP/25 pro komunikaci mezi poštovními servery a port TCP/587 pro příjem e-mailů od e-mailových klientů. Doručování elektronické pošty po Internetu se účastní tři druhy programů: MUA Mail User Agent, poštovní klient, který zpracovává zprávy u uživatele MTA Mail Transfer Agent, server, který se stará o doručování zprávy na cílový systém adresáta MDA Mail Delivery Agent, program pro lokální doručování, který umísťuje zprávy do uživatelských schránek, případně je může přímo automaticky zpracovávat (ukládat přílohy, odpovídat, spouštět různé aplikace pro zpracování apod.)

SMTP SMTP (Simple Mail Transfer Protocol) Port: 25 (nezabezpečené spojení) 465 (šifrované spojení SSL)

DNS Všechny aplikace, které zajišují komunikaci mezi počítači používají k identifikaci komunikujících uzlů IP-adresu. Pro člověka jako uživatele jsou však IP-adresy těžko zapamatovatelné. Proto se používá místo IP-adresy název síťového rozhraní. Pro každou IPadresu máme zavedeno jméno síťového rozhraní (počítače), přesněji řečeno doménové jméno. Toto doménové jméno můžeme používat ve všech příkazech, kde je možné použít IP adresu. Výjimkou, kdy se musí použít IP-adresa, je identifikace samotného name serveru. Jedna IP-adresa může mít přiřazeno i několik doménových jmen. 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. Použití IP-adres místo doménových jmen je praktické vždy, když máme podezření, že DNS nám na počítači nepracuje korektně.

DNS - domé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. Doménové jméno se skládá z řetězců vzájemně oddělených tečkou. Jméno se zkoumá zprava doleva. Nejvyšší instancí je tzv. root doména, která se vyjadřuje tečkou zcela vpravo (tato tečka bývá často vypouštěna). V root doméně jsou definované generické domény (Top Level Domains TLD): edu, com, net, org, mil, int a arpa, které se používají převážně v USA, a dále podle normy ISO-3166 dvojznakové domény jednotlivých států. Pro Českou republiku je vyhrazena doména cz.

DNS - domény Celé jméno může mít maximálně 255 znaků, řetězec pak maximálně 63 znaky. Řetězec se může skládat z písmen, číslic a pomlčky. Pomlčka nesmí být na začátku ani na konci řetězce. Existují i rozšíření specifikující bohatší repertoár znaků použitelných pro tvorbu jmen. Zásadně se však těmto dalším znakům vyhýbáme, protože jen některé aplikace toto rozšíření podporují. Mohou se použít velká i malá písmena, ale není to zase tak jednoduché. Z hlediska uložení a zpracování v databázi jmen (databázi DNS) se velká a malá písmena nerozlišují. Tj. jméno newyork.com bude uloženo v databázi na stejné místo jako NewYork.com nebo NEWYORK.com atp. Tedy při překladu jména na IP-adresu je jedno, kde uživatel zadá velká a kde malá písmena. Avšak v databázi je jméno uloženo s velkými a malými písmeny, tj. bylo-li tam uloženo např. NewYork.com, pak při dotazu databáze vrátí NewYork.com. Poslední tečka je součástí jména.

DNS - domény V některých případech se může část jména zprava vynechat. Téměř vždy můžeme koncovou část doménového jména vynechat v aplikačních programech. V databázích popisujících domény je však situace složitější. Je možné vynechat: Poslední tečku téměř vždy. Na počítačích uvnitř domény se zpravidla může vynechat konec jména, který je shodný s názvem domény.

DNS 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. DNS zóna Jak jsme již uvedli, doména je skupina počítačů, které mají společnou pravou část svého doménového jména. Doména je např. skupina počítačů, jejichž jméno končí cz. Doména cz je však velká. Dělí se dále na subdomény např. pvt.cz, eunet.cz a tisíce dalších. Každou z domén druhé úrovně si většinou spravuje na svých name serverech majitel domény nebo jeho poskytovatel Internetu. Data pro doménu druhé úrovně např. pvt.cz nejsou na stejném name serveru jako doména cz. Jsou rozložena na mnoho name serverů. Data o doméně uložená na name serveru jsou nazývána zónou. Zóna tedy obsahuje jen část domény. Zóna je část prostoru jmen, kterou obhospodařuje jeden name server.

DNS doména a AS Na tomto místě musíme zdůraznit, že rozdělení sítě na autonomní systémy nesouvisí s rozdělením na domény (nebo snad na zóny). Tzn. je-li podniku přiděleno jméno domény a IP-adresy sítí jedním poskytovatelem, pak při přechodu k jinému poskytovateli zůstanou podniku jména domén, ale Ipadresy dostane od nového poskytovatele nové. Musí se tedy přečíslovat jednotlivé LAN, ale jména počítačů a adresy elektronické pošty zůstanou beze změn.

DNS rezervované domény doména.test pro testování. doména.expample pro vytváření dokumentace a příkladů. doména.invalid pro navozování chybových stavů. doména.localhost pro softwarovou smyčku obdobně byla rezervována doména.local pro intranety.

DNS rezervované domény 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 servervrátí jako odpověď resolveru. Veškerá komunikace se skládá z dotazů a odpovědí.

DNS 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. Dotazy, kterými se přenášejí data o zóně (zone transfer) např. mezi primárním a sekundárním name serverem, se přenáší protokolem TCP. Běžné dotazy (např. překlad jména na IP-adresu a naopak) se provádí pomocí datagramů protokolu UDP. Překlad požaduje klient (resolver) na name serveru. Neví-li si name server rady, může požádat o překlad (o pomoc) jiný name server prostřednictvím root name serveru.

DNS Doménová služba je realizována jednoduchým protokolem. Tento protokol pracuje způsobem dotaz odpověď. Klient pošle dotaz serveru a server na dotaz odpoví. Jistou komplikací je komprese jmen, která se provádí proto, aby byly DNS pakety co nejúspornější. Protokol DNS je protokol aplikační vrstvy, neřeší tedy otázku vlastního přenosu paketů. Přenos svých paketů svěřuje transportnímu protokolu. Na rozdíl od drtivé většiny ostatních aplikačních protokolů využívá DNS jako transportní protokoly UDP i TCP. Dotaz i odpověď jsou přenášeny vždy stejným transportním protokolem. Doménová jména byla rozdělena na domény jednotlivých úrovní, které se oddělují tečkou a jejichž celý zápis za sebou tvoří plně kvalifikované doménové jméno např. mail.nic.cz. Jednotlivé úrovně jsou číslované pozpátku. Poslední část jména je doména první úrovně nebo také doména nejvyšší úrovně (TLD Top Level Domain), v našem předchozím příkladě "cz". Následuje doména druhé úrovně (SLD Second Level Domain), v našem případě "nic". Dále následují domény třetí, čtvrté, páté a dalších úrovní (ty již nemají žádné speciální názvy). Náš příklad obsahuje ještě doménu třetí úrovně mail.

DNS Díky hierarchii se zvětšil prostor pro tvorbu doménových jmen. Stačí tedy, aby jednotlivá jména byla unikátní pouze v rámci dané úrovně. Protože není nutné mít seznam na jednom místě, ale stačí mít ke každé doméně pouze informaci o všech jejích subdoménách další úrovně, došlo ke zjednodušení hierarchického uspořádání systému domén. Tím vzniká z jednotlivých úrovní doménový strom. Kořen doménového stromu obsahuje informaci o všech TLD doménách jako.com,.cz,.de.fr a tak dále. Každá z těchto TLD má pak svůj registr všech SLD domén. Například registr domény nejvyšší úrovně.cz obsahuje veškeré domény druhého řádu - např. nic.cz, seznam.cz, idnes.cz atd. Obdobně každá z těchto domén druhého řádu má i seznam domén třetího řádu - např. www.nic.cz, enum.nic.cz, fred.nic.cz atd. Na stejném principu roste doménový strom až k doménám libovolného řádu.

DNS Každý registr domén má svou organizaci či osobu, která je jeho správcem a určuje pravidla pro registraci doménových jmen pro subdomény. Všechny správce národních TLD domén lze najít v seznamu zemí na stránkách IANA. Pravidla obvykle určují: Jak doménové jméno může vypadat, jaké znaky může obsahovat, jak může být dlouhé apod. Zda jsou nějaká omezení v tom, kdo si doménové jméno může registrovat Způsob registrace Kolik stojí registrace vlastní domény apod. Některé registry jsou více otevřené a umožňují registrovat doménové jméno prakticky komukoliv. U jiných jsou pravidla striktnější, záleží na správci domény.

DNS Každý registr domén má svou organizaci či osobu, která je jeho správcem a určuje pravidla pro registraci doménových jmen pro subdomény. Všechny správce národních TLD domén lze najít v seznamu zemí na stránkách IANA. Pravidla obvykle určují: Jak doménové jméno může vypadat, jaké znaky může obsahovat, jak může být dlouhé apod. Zda jsou nějaká omezení v tom, kdo si doménové jméno může registrovat Způsob registrace Kolik stojí registrace vlastní domény apod. Některé registry jsou více otevřené a umožňují registrovat doménové jméno prakticky komukoliv. U jiných jsou pravidla striktnější, záleží na správci domény.

DNS Informace o doménách jsou fyzicky uloženy na tzv. jmenných serverech (Name Servers). A to buď jako přímá informace o IP adresách, náležejících danému doménovému jménu, nebo formou odkazu na jiný jmenný server, který pro dané doménové jméno následuje v doménovém stromu, tzv. delegace. Tomu odpovídá použití DNS v praxi, které vypadá následovně: Každý počítač má nastaven jmenný server, který používá pro překlad jmen. Když uživatel počítače použije doménové jméno tím, že je napíše do řádku adresy ve webovém prohlížeči, počítač pošle dotaz, jaká IP adresa odpovídá tomuto doménovému jménu, jmennému serveru. Ten buď dotaz zodpoví přímo, pokud dotazové doménové jméno zná, anebo dotaz předá dál, dalším jmenným serverům v doménovém stromu, viz následující příklad.

DNS Vezměme uživatele, otevírajícího ve svém prohlížeči webovou stránku www.nic.cz. Počítač tohoto uživatele pošle dotaz na jméno www.nic.cz lokálnímu DNS serveru a ten postupuje dle následujícího schématu.

NFS NFS (Network File System) v polovině osmdesátých let minulého století, společnost Sun Microsystems vyvinula síťový souborový systém, který je velmi jednoduché nakonfigurovat a používat. Od té doby prošel jistým vývojem a nakonec se dostal také do linuxového jádra. Na něm je to v dnešní době jedno z nejpoužívanějších řešení pro sdílení dat na sítích. Protokol je postaven nad UDP. V praxi je velmi rychlý. Od verze 3 je možné ho nakonfigurovat, aby používal protokol TCP, což je na lokální sítě často zbytečné. NFS se o kontrolní součty stará samo, takže UDP je pro tento druh přenosu ideální. V současné době, díky jeho velkému rozšíření v sítích na bázi protokolů TCP/IP, lze protokol NFS považovat za součást rodiny protokolů TCP/IP. Svědčí o tom i skutečnost, že specifikace tohoto protokolu jsou zveřejněny formou dokumentu RFC (konkrétně RFC 1094). Příznačná je i skutečnost, že o tomto protokolu se nejčastěji hovoří jako o "protokolu, který vyvinula firma Sun", a nikoli jako o "protokolu firmy Sun".

NFS Protokol NFS je tedy bezestavový v tom smyslu, že server se po provedení jakéhokoli požadavku klienta nachází v přesně stejném stavu, jako před příchodem tohoto požadavku. V důsledku toho si pak nemusí pamatovat nic o průběhu či stavu komunikace s kterýmkoli klientem, a po případném výpadku či ztrátě spojení nemusí být prováděny žádné nápravné akce. Pokud nějaký klient přijde se svým požadavkem v době, kdy server je mimo provoz (či "spadne" právě v době, kdy takovýto požadavek zpracovává), klientovi stačí jeho požadavek opakovat až doby, než server znovu "naběhne". Pokud se klient do výpadku serveru "nestrefí", nemusí si tento výpadek vůbec uvědomit.

SMB Protokol SMB (Server Message Block) je protokol s velko tradicí, původně vyvinut firmou IBM ve spolupráci s Microsoftem. Dnes je díky téměř monopolnímu postavení firmy Microsoft na trhu nejpoužívanějším protokolem pro peer-2-peer komunikaci souborových serverů a klientů LAN. Protokol SMB využívají tiskové a souborové servery síťových serverů založených na operačních systémech Lan Server, OS/2 fy IBM a samozřejmě servery Microsoft. Microsoft se dále snaží prosadit tento protokol jako náhradu za protokol ftp a http. Protokol pracuje na bázi modelu Klient-Server. Server poskytuje klientům sdílené prostředky, což mohou být pevné disky, adresáře, tiskové fonty a pojmenované kanály. Tyto sdílené prostředky jsou jednoznačně identifikované díky univerzální síťové adrese UNC. Klient se stará o formulaci požadavku na tyto prostředky. Server pak zanalyzuje požadavky, zkontroluje přístupová práva klienta a na jejich základě (ne)provede požadovanou operaci a odešle odpověď.

SMB Pro zprávu přístupů ke sdíleným prostředkům jsou využívány obvykle dva přístupy: 1. Řízení přístupu na úrovni sdíleného prostředku. Přístup je umožněn všem uzlům sítě po zadání správného hesla přiřazeného prostředku na straně serveru. (=každý sdílený prostředek má své vlastní heslo, může být i více hesel pro jeden prostředek s různými úrovní práv). Po zadání hesla je klientu přidělen identifikátor NID (Network ID), pod kterým k prostředku přistupuje. 2. Řízení přístupu na uživatelské úrovni. Při připojení klientu k serveru je požadováno uživatelské jméno a heslo. Je-li korektní, je uživateli přiřazen uživatelský identifikátor UID (User ID), z něhož server odvozuje přístupová práva ke sdíleným prostředkům v síti. Může nastat také situace, kdy se serverem komunikuje najednou více procesů od stejného uživatele. Pak k jejich rozlišení slouží dvojice identifikátorů PID (Process ID) a MID (Multiple ID).

SMB - Samba Samba je v informatice název svobodné implementace síťového protokolu SMB (Server Message Block, v novější verzi CIFS Common Internet File System) používaného především pro vzdálený přístup k souborům (sdílení) v systémech Microsoft Windows. Samba je distribuována pod licencí GNU General Public License. V současné verzi 3 neposkytuje Samba pouze služby pro sdílení souborů a tiskových služeb pro klienty systému Windows, ale lze ji například využít i pro integraci do domény Windows, buď jako primární doménový řadič (Primary Domain Controller, PDC) nebo jako běžného člena v doméně. Může být také součástí domény Active Directory. Samba byla původně vyvinuta pro systém UNIX Andrewem Tridgellem, nyní běží na většině UNIXových systémů, které zahrnují GNU/Linux, Solaris, BSD, Mac OS X (od verze 10.2 je součástí OS X pro pracovní stanice workstation) a jiné. Dne 20.12.2007 obdržel Samba tým kompletní dokumentaci protokolu Microsoftu. Lidé píšící open source software tím získali důležité informace k implementaci volně dostupného řešení sdílení a dalších služeb v síti Microsoft Windows a tím možnost dosáhnout vysoké kompatibility. Výsledkem je vydání verze 4. V této verzi, mezi jinými, Samba může plnit roli řadiče domény Active Directory nebo být plnohodnotným členem Active Directory domény.

SMB - Samba Samba umožňuje sdílet soubory a tiskárny mezi počítači s operačním systémem Windows a počítači s operačním systémem Unix. Jedná se o implementaci desítky služeb a tuctu protokolů, jako NetBIOS po TCP/IP (NBT), SMB, CIFS (a vylepšená verze SMB), DCE/RPC, MSRPC, WINS server známý jako NetBIOS Name Server (NBNS), NT doménový soubor protokolů které obsahuje NT doménové přihlašování, Secure Accounts Manager (SAM) databáze, Local Security Authority (LSA) služba, NT tiskovou službu (SPOOLSS), NTLM a nejnověji Active Directory přihlašování které obsahuje upravenou verzi Kerberos a upravenou verzi LDAP. Všechny tyto protokoly jsou často nazývány jen jako NetBIOS nebo SMB. NetBIOS a WINS protokoly jsou ve Windows zastaralé. Samba zřizuje sdílení souborů pro vybrané Unixové adresáře (včetně všech podadresářů). Tyto se zobrazí uživatelům Windows jako normální složky Windows přístupné prostřednictvím sítě. Unixoví uživatelé se mohou připojit buď tak, že si sdílený adresář připojí do systému pomocí příkazu smbmount, nebo alternativně můžou použít nástroj smbclient (libsmb), který se chová jako FTP klient. Každý adresář může mít různá práva přístupu, která překrývají běžná oprávnění v Unixu. Služby Samby (Unix, Linux) jsou realizovány jako dva démoni: smbd, který poskytuje sdílení souborů a tiskáren, a nmbd, který poskytuje překlad NetBIOS na IP adresu. NetBIOS přes TCP/IP vyžaduje určitou metodu pro mapování názvů NetBIOS počítače na IP adresy TCP/IP síti Konfiguraci Samby je dosaženo editací jednoho souboru (typicky se nachází /etc/smb.conf nebo /etc/samba/smb.conf). Samba může také poskytovat přihlašovací skripty a politiky skupiny prostřednictvím poledit.

RDP Remote Desktop Protocol (zkratka RDP) je v informatice proprietární síťový protokol, který umožňuje uživateli ovládat vzdálený počítač prostřednictvím připojení k jeho desktopovému prostředí. Připojení pracuje na principu klient-server, kdy uživatel na svém počítači využívá jednoduchého klienta pro zobrazeni grafického uživatelského prostředí, které je spuštěno na vzdáleném počítači. Protokol RDP byl poprvé představen ve Windows NT 4.0 Terminal Server Edition. Klienti pro připojení pomocí RDP protokolu existují pro většinu verzí Windows, Mac OS X a další operační systémy. Server implicitně naslouchá na TCP portu 3389. Firma Microsoft nabízí klientský software Remote Desktop Connection (RDC) nebo Terminal Services Client (TSC). V operačním systému Mac OS X se klient nazývá Remote Desktop.

VNC VNC (Virtual Network Computing) slouží k přístupu na plochu vzdáleného počítače. Může být použito i k vytvoření tenkých klientů, kdy se na terminál přenáší jen obraz a většina práce zůstává na hlavním serveru, kterému je terminál připojen. Mnohem častější využití je ale vzdálené ovládání domácího počítače nebo serveru. VNC využijí méně zkušení uživatelé, kteří si na příkazové řádce tolik nevěří a nebo třeba i zkušení administrátoři, kteří určitou činnost vykonávají raději na ploše nějakého desktopového prostředí. Zkrátka každý uživatel si svoji cestu najde a tento článek má sloužit jako návod, jak se poprat s jednou z nich. První kód kolem VNC se objevil v laboratoři Olivetti & Oracle Research Lab, kterou později získalo AT&T a v roce 2002 uzavřelo. Původní nápad dostal TRISTAN RICHARDSON a pod taktovkou ANDYHO HARTERA se tým osmi lidí pustil do návrhu a implementace. Před uzavřením laboratoře dala část vývojového týmu dohromady program RealVNC a ten pak uvolnili ve freeware i komerční licenci. VNC používá protokol RFB, který se stal natolik populární v open source světě, že dnes existuje řada možností, jak ho na Linuxu použít. My se dnes podíváme na programy X11vnc a TightVNC.

VNC U VNC se využívá způsobu připojení klient-server. Server sdílí svůj výstup a klient se k němu připojuje. K jednomu serveru a dokonce i k jednomu virtuálnímu monitoru může být připojeno několik klientů najednou. V úvodní komunikaci se obě strany dohodnou na způsobu kódování komunikace a poté si začnou vyměňovat data. Ten nejjednodušší způsob kódování, který také podporují všichni klienti, je odesílání malých obdélníků se změněnou oblastí. Jako první pošle server klientovi celkový obraz plochy a následně po každé změně, ať už se jedná o kurzor myši nebo celé nové okno, odešle postižený obdélník. Jedná se o nejjednodušší způsob kódování a při změně velké plochy roste velmi rychle zatížení linky. Proto různé implementace přicházejí s vlastními způsoby kódování pro odstranění podobných neduhů.

NTP Protokol NTP (Network Time Protocol) je jedním z nejstarších protokolů a existuje už téměř dvacet let. Tento protokol je primárně určen pro synchronizaci vnitřních hodin počítačů po paketové síti, která má proměnlivou délku zpoždění. NTP klient je schopný přijímat časové údaje od několika serverů najednou a určit výsledný čas. Pro stanovení času se používá Marzullův algoritmus. Základním přenosovým protokolem je UDP (User Datagram Protocol). Jeho výhoda tkví v neexistenci trvalého spojení a v případě výpadku velmi vytíženého serveru nedochází k podstatnému snížení přesnosti. NTP je v současné době velmi důmyslný systém využívající řady zajímavých algoritmů a statistických metod. Celý proces je založen na postupném přibližování se k přesnému času. Při synchronizaci lze rozlišit dvě fáze. V případě velkých rozdílů (nad 128 ms) dochází k tzv. skokové (stepping) synchronizaci, která zaručí okamžité srovnání času. V případě menších rozdílů pak probíhá tzv. slewing, což je postupné přibližování. Dosažení velmi dobré přesnosti tak není otázkou okamžiku, ale spíše několika minut. Během synchronizace se musí změřit a následně korigovat různá zpoždění při přenosu času. Protokol NTP je dnes velice rozšířený a stal se nejpoužívanějším protokolem pro synchronizaci času. Jeho hlavní výhodou je dostupnost po celém internetu. Přesnost synchronizace tímto protokolem není příliš vysoká, ale je plně dostačující pro synchronizaci času v PC a pohybuje se v řádu desítek milisekund.

NTP Zpoždění paketové sítě Paketová síť byla navržena pro přenos paketů, tj. relativně samostatných segmentů dat, a to sebou přináší jisté výhody i nevýhody. Hlavní výhodou při přenosu dat je rozdělení zpráv do jednotlivých paketů, které se mohou přenášet různými cestami sítě. To zlepšuje využití přenosových kapacit sítě a hlavně umožňuje reagovat na přetížení v jednotlivých uzlech sítě a následně posílat pakety jinou cestou. Zpoždění paketu při průchodu sítí se mění vlivem změny zatížení jednotlivých bodů sítě nebo aktuální změnou topologie sítě například při výpadku určitého spojení. Tato vlastnost omezuje využít paketové sítě pro přenos informací, které se musí přenést v reálném čase, jako například přenos hovoru nebo videa. Vliv proměnného zpoždění na přesnost synchronizace je poměrně zásadní. Abychom si udělali představu o rozptylu zpoždění v paketové síti, který je pro přesnost synchronizace důležitý, provedli jsme několik měření. Rozptyl zpoždění paketů při přímém propojení koncových zařízení je samozřejmě nejmenší, a to s hodnotou přibližně 100 μs. Při měření v reálné síti, kdy jsme se pomocí NTP klienta dotazovali veřejného NTP serveru, jsme naměřili rozptyl zpoždění přibližně 5 ms (obr. 1). Z grafu je dále patrné, že nejvíce paketů má zpoždění okolo hodnoty 7,1 ms. Pakety s vyšší hodnotou zpoždění byly nejspíše ovlivněny dobou zpracování na určitém síťovém prvku, který mohl být v určitém okamžiku více vytížen.

NTP Zpoždění paketové sítě Hlavním problémem při přenosu časové informace z NTP serveru je právě proměnné zpoždění, které nejsme schopni predikovat. Zpoždění paketů při cestě od NTP klienta k NTP serveru může být jiné než při zpáteční cestě od NTP serveru k NTP klientu. Toto zpoždění se snaží kompenzovat algoritmy obsažené v NTP protokolu. Obr. 1 Četnost zpoždění paketů při spojení do internetu

NTP Korekce zpoždění u NTP protokolu Protokol NTP je založen na předávání časových informací z jednotlivých zařízení. Časové informace se přenášejí pomocí NTP paketů. Komunikaci zahajuje klient, který vysílá dotaz na NTP server. Tento dotaz obsahuje čas odeslání paketu z klienta, který si označíme jako T 1. Server přijme NTP paket a vloží do něj čas přijetí paketu T 2 a čas odeslání paketu T 3 a pošle paket zpět klientovi. Klient si po přijetí paketu zaznamená ještě čas příchodu paketu T 4 (obr. 2). Je nutné upozornit, že jednotlivé časy nejsou absolutní. Na klientu běží hodiny, které mohou být oproti serveru rozdílné. Časy klienta jsou T 1 a T 4 a časy serveru jsou T 1 a T 3. Obr. 2 Princip přenosu paketu s časovými zprávami přes paketovou síť

Přehled čísel portů Číslo TCP UDP Služba 4 udp NTP 20 tcp udp FTP (data) 21 tcp udp FTP (příkazy) 22 tcp udp SSH 23 tcp udp Telnet 25 tcp udp SMTP 53 tcp udp DNS 67 tcp udp BOOTP (server), DHCP 68 tcp udp BOOTP (klient), DHCP 69 tcp udp TFTP 80 tcp udp HTTP 109 tcp udp Post Office Protocol - Version 2 110 tcp udp Post Office Protocol - Version 3, POP3 115 tcp SFTP - Simple File Transfer Protocol 123 tcp udp NTP 143 tcp udp IMAP 161 tcp udp SNMP 389 tcp LDAP 993 tcp IMAPS, SSL 995 tcp POP3S, SSL

LDAP

LDAP (Lightweight Directory Access Protocol) je definovaný protokol pro ukládání a přístup k datům na adresářovém serveru. V praxi to například znamená seznam lidí firmy, jejich přihlašovací jména, domovské adresáře, osobní informace, jména jejich e- mailů nebo čísla telefonů. LDAP může stejně tak dobře uchovávat nastavení uživatelských programů. Data se nemusejí nutně vztahovat na osoby, protokol může pomoct vyhledat různé přístroje ve velké firemní síti (např. fax nebo tiskárnu) a zobrazit jejich umístění či obsahovat různé číselníky (budov, pracovišť atd.). LDAP je jednoduchý a dobře navržený protokol umožňující nejen klást poměrně složité dotazy, ale i vkládat, modifikovat a mazat záznamy. Jde o protokol kterým klient z platformy TCP/IP (LDAP klient) komunikuje s vhodnou bránou (LDAP serverem), která zprostředkovává přístup k vlastním adresářovým službám dle X.500.

LDAP Celou službu je možno si představit jako veliký strom či adresář na souborovém systému, který obsahuje celý svět. Tento strom obsahuje záznamy (entries). Každý záznam musí mít definovány atributy (attributes) povinné a volitelné. Ty definujeme pomocí objektů (object class), které jsou nadefinovány na serveru. Adresářová služba LDAP je založena na modelu klient server. Data uložená v adresáři mohou být distribuována mezi několik LDAP serverů. LDAP klient se připojí k LDAP serveru a zašle mu dotaz. Server vrátí odpověď a/nebo ukazatel, kde může klient získat další informace (obvykle jiný LDAP server). Nezáleží na který LDAP server se klient připojí, vždy se jedná o stejný pohled na adresář. Jméno poskytnuté jednomu LDAP serveru ukazuje na stejný záznam, který může být na jiném serveru.

LDAP V LDAP adresáři jsou záznamy uspořádány v hierarchické stromové struktuře. Tato struktura obvykle odráží geografické nebo organizační hranice. Záznamy reprezentující země jsou na vrcholu stromu. Pod nimi mohou být záznamy reprezentující státy a národní organizace. Pod nimi mohou být záznamy reprezentující organizační jednotky, lidi, tiskárny, dokumenty nebo cokoli jiného, na co si vzpomenete. Na obrázku 1 je příklad takového LDAP adresářového stromu.

LDAP Strom může být uspořádán také na základě doménových jmen Internetu. Tento způsob 3 Obrázek 2: LDAP adresářový strom (Internetové pojmenování) pojmenovávání se stává čím dál více populárnější, protože adresářové služby berou v úvahu umístění podle DNS (Domain Name System). Na obrázku 2 je příklad adresářového stromu LDAP využívající jména založená na doménách.

LDAP Každý záznam je přístupný pomocí svého jedinečného jména Distinguished Name (DN), které je vytvořeno ze jména samotného záznamu (nazývaného Relative Distinguished Name nebo také RDN) a zřetězením jmen záznamů jeho předků. Například záznam Barbory Jenson v příkladu Internetového pojmenování uvedeného na obrázku má RDN uid=babs a DN uid=babs,ou=people,dc=example,dc=com. LDAP poskytuje mechanismy pro autentizaci klienta nebo pro ověření jeho identity u adresářového serveru a využívá bohatou přístupovou kontrolu, aby chránil informace na serveru. Nabízí také možnost velmi efektivně nastavovat přístupová práva a to i na jednotlivé atributy objektů. LDAP servery nabízejí autentizaci přes SSL a je také možné využívat silné autentizační služby poskytované systémem Kerberos. Jeho výhodou je oddělení komponent autentizace a identifikace.

LDAP Country (C) (země) State or Province Name (S) (stát nebo provincie, kraj atd.) Street Address (SA) (místní adresa - ulice atd.) Locality Name (L) (lokalita) Organization Name (O) (jméno organizace) Organizational Unit Name (OU) (jméno organizační jednotky) Common Name (CN) (obecné jméno) samaccountname samaccounttype userprincipalname displayname givenname sn description mail company department location streetaddress memberof SAM Account Name, přihlašovací uživatelské jméno, které podporuje starší systémy typ účtu UPN, přihlašovací jméno uživatelského účtu ve tvaru <user>@<dns-domain-name> jméno, které využívají aplikace (třeba Exchange) křestní jméno surname - příjmení popis adresa elektronické pošty jméno společnosti oddělení ve firmě umístění ulice seznam skupin, kterých je členem X.500 LDAP

Routing Routing, česky řečeno směrování, ale častěji se používá slovo routování (alespoň v mém okolí). Jedná se o techniku, která slouží k propojení jednotlivých sítí (přesněji subnetů). Původním zařízením, určeným pro routování byl router, ale v dnešní době se velmi využívají L3 switche, firewally nebo pouze servery/počítače. Router přeposílá komunikaci z jedné sítě do jiné. Následující obrázek ukazuje jednoduchý příklad sítě, kde máme subnety A, B a C. Tyto subnety jsou propojeny přes router mezi sebou a také do internetu. Takže pokud chce například stanice ze subnetu B komunikovat se serverem v subnetu A, tak pošle data na router a ten zařídí doručení do subnetu A. Pokud by stanice chtěla komunikovat do internetu, tak router naopak zašle data na jiný interface.

Routing

Routing historie Úplně první zařízení, které mělo v podstatě stejné funkce jako má dnes router (tj. packet switch), byl Interface Message Processor (IMP). IMP byla zařízení, která propojovala jednotlivé části ARPANETu první počítačová síť využívající přepínání paketů. Myšlenka routeru (ačkoliv se jim v té době říkalo brány) vznikla v mezinárodní skupině počítačových síťových vývojářů International Network Working Group (INWG). V roce 1972 vznikla neoficiální skupina, která se zabývala technickými otázkami spojenými s propojováním různých sítí, a později se v témže roce stala podvýborem Mezinárodní federace pro zpracování informací (IFIP). IMP se od většiny předchozích paketových přepínačů lišil ve dvou směrech. Za prvé spojovaly různé typy sítí (například sériové linky a LAN). Za druhé se tato zařízení nijak nepodílela na vytváření spojení a nehrála ani žádnou roli při zajišťování spolehlivosti doručování zpráv, což zcela ponechávala na koncových bodech komunikace (i když tento nápad byl dříve již využit v sítích CYCLADES). Úmyslem detailnějšího zaměření na tuto myšlenku bylo vytvořit skutečný prototyp systému, jako součást dvou současných programů. První program, který položil základy dnešní TCP/IP architektury byl vytvořen agenturou DARPA. Druhý program, který zavedl PARC Universal Packet system, byl vyvinut firmou Xerox PARC pro hledání nových síťových technologií.

Routing Dělení sítě na subnety je hierarchické a ve všech propojích musí být router. Při komunikaci pak postupujeme směrem nahoru ve stromu na nejbližší vrstvu, která propojuje dané subnety, a pak opět dolů. Délka cesty se počítá podle počtu hopů (skok), což je každý přechod ze zařízení na zařízení, je to tedy počet routrů v cestě + 1. Přímé spojení dvou počítačů je dlouhé 1 hop. Používá se také termín next hop (další skok) a označuje se jím adresa dalšího routeru v cestě. Na dalším obrázku jsem je zachycena tato situace. Je zde malý (a pouze schematický) výřez větší sítě (či internetu). Na listech stromu jsou malé routery, ke kterým jsou připojeny switche a počítače. Tyto routery se sdružují do dalších (větších) a tak dále na několika úrovních. Samozřejmě v praxi jsou větší routery vždy redundantně, aby byla síť odolná vůči výpadku či kvůli vyvažování zátěže.

Routing

Routing dělení routovacích protokolů Do routovací tabulky se vytváří několik typů záznamů cest (route), záleží na tom, jakým způsobem vznikly. Pakety jsou podle toho směrovány jedním ze základních způsobů routování: statické routování ručně zadané cesty (záznamy v routovací tabulce), bezpečné a dobré, ale nereflektuje změny v topologii sítě dynamické routování - síť se automaticky přizpůsobuje změnám v topologii a dopravě, automaticky se vypočítávají cesty pomocí routovacího protokolu defaultní routování - pokud neexistuje jiná cesta, tak se použije defaultní

Routing směrovací protokoly Distance vector Protokoly z této rodiny fungují tak, že sousední zařízení si v pravidelných intervalech či při topologické změně (obvykle výpadek zařízení) vyměňují svoje kompletní kopie směrovacích tabulek. Na základě obsahu těchto updateů doplňují nové informace a inkrementují své distance vektor číslo (které je obvykle i metrikou udávající počet hopů k dané síti). Nevýhodou je, že zařízení znají topologii sítě jen na základě informací od svých bezprostředních sousedů. Systém budování směrovacích tabulek na základě práce těchto protokolů je následující: 1. Přímo připojené sítě k danému zařízení mají distance vektor číslo rovno 0 2. Distance vektor číslo jiné než přímo připojené sítě je získáno extrakcí ze směrovacích tabulek bezprostředních sousedů s tím, že je vždy inkrementováno o jedničku 3. Spolu s distance vektor číslem obsahuje směrovací tabulka i jiné údaje obvykle celkovou metriku pro danou síť (kde se bere v potaz krom hopů i šířka pásma, zatížení linky, zpoždění a spolehlivost) a zejména logickou adresu prvního zařízení (typicky routeru) na cestě k dané síti;

Routing směrovací protokoly Link-state Protokoly z této rodiny udržují kompletní informace o topologii dané sítě zařízení jsou si vědoma všech ostatních zařízení na síti. Díky tomu je nutné udržovat podstatně více informací než jen směrovací tabulku, typicky ještě minimálně topologickou databázi, která je vystavěna pomocí tzv. LSAs (Link-state advertisments), jež si mezi sebou routery vyměňují. Tato dodatečná režie se projevuje následovně: Routery potřebují více paměti a procesorového času Šířka pásma je na začátku značně vytížena (link-state packet flooding) inicializační tvorbou směrovacích a topologických tabulek, na druhou stranu po této fázi je provoz na síti již minimální.

Routing směrovací protokoly Link-state Při výběru nejvhodnější cesty se využívá SPF algoritmus, který topologii sítě chápe jako strom (s aktuálním routerem jakožto kořenem) a hledá nejkratší cestu od kořene ke koncovému listu, který reprezentuje cílovou síť. Při jakékoli změně topologie (příbytek nového zařízení, některé se zařízení spadlo, změna linky) dojde k zaslání LSA detekovaným zařízením (typicky routerem) všem ostatním zařízením na síti, čímž dojde k přepočítání a k úpravě směrovacích tabulek tak, aby odráželi nově vzniklou situaci. Konvergence je tedy rychlejší než u rodiny protokolů distance vektor, které jsou odkázány na postupné šíření informace v případě změny.

Routing směrovací protokoly - výběr cesty Výběr správné cesty je vždy zcela v režii zařízení, které daný paket zpracovává. 1. Rámec se rozbalí na síťové (network) vrstvě na paket; 2. Prozkoumá se cílová (destination) IP adresa v hlavičce paketu; 3. Porovná se obsah směrovací tabulky s hledanou adresou a zvolí se nejvhodnější následující zařízení podle druhu směrovacího algoritmu, na které je paket poslán; 4. Paket se zabalí na rámec, kterému je přidělena nová cílová MAC adresa následujícího zařízení; 5. Rámec se odešle pryč správným rozhraním;

Routing směrovací protokoly - výběr cesty

Routing dyn. routovací protokoly Dále dělíme dynamické protokoly podle toho, zda jsou určeny pro nasazení uvnitř lokální sítě (přesněji řečeno uvnitř autonomního systému (AS), který může obsahovat několik LAN) nebo fungují napříč sítěmi (spojují AS dohromady) interior gateway protocol - IGP - routuje uvnitř Autonomous System (AS) exterior gateway protocol - EGP - routuje mezi AS

Routing základní pojmy Router Switch Bridge HUB Routing (směrování) Routing protocol Distance vector protocol Link-state protocol Routing table gateway Default route NEXT Hop address Metric Distance Loopback interface Source address Destination address

Routing dyn. routovací protokoly Dynamické směrování je proces směrování odlišný od statického v mnohých aspektech. Jeho základ tvoří použití směrovacích protokolů jako jsou RIP, IGRP, OSPF a pod. Každý z těchto protokolů tvoří komunikaci mezi směrovačemi a umožňuje šíření informací týkající se sítí. Každá z těchto informací se využívá při aktualizovaní směrovací tabulky a celý proces se děje plně automaticky bez nutnosti zásahu administrátora. Oproti statickému směrování má dynamické následující hlavní výhody: administrátor nemusí znát aktuální topologii sítě jakékoli změny v topologii sítě se automaticky okamžitě šíří prostřednictvím směrovacích protokolů na všechny zařízení, které následně flexibilně na tyto změny zareagují naproti složitější počítačové konfiguraci (v závislosti na zvoleném směrovacím protokolu) je potom administrace o mnoho jednodušší jako v případě statického směrování.

Routing dyn. routovací protokoly Směrovací protokoly slouží na správu směrovacích tabulek v určité autonomní oblasti, což je oblast sítí s dohodnutou strategií správy. Autonomní oblast slouží na rozdělení velkých sítí na menší a teda i lehčeji spravovatelné sítě, přičemž každé oblasti je přidělený jednoznačný identifikátor např. v formě čísla. Podle toho, jestli protokoly pracují vevnitř této oblasti a nebo mezi oblastmi, dělí se na interní a externí.

Routing srovnání protokolů

Routing srovnání protokolů Směrovací protokoly a RIP: http://data.cedupoint.cz/oppa_e-learning/2_kme/042.pdf OSPF: http://www.cs.vsb.cz/grygarek/sps/lect/ospf/ospf.html

Kapitola: L2 forwarding, switching VLAN 802.11Q Tag Trunk, access VLAN routing