Komunikace v síti
Sada protokolů TCP/IP (Transmission Control Proto col/Internet Proto col) vznikla pod záštitou amerického ministerstva obrany (Department of Defense - DoD) s cílem zajistit a zachovat integritu dat a rovněž udržet možnost komunikace v případě katastrofálního konfliktu. Z toho tedy vyplývá, že pokud je síť TCP/IP správně navržena a implementována, může být skutečně spolehlivá a odolná. V této kapitole se budeme zabývat protokoly TCP/IP a v dalších částech této knihy si ukážeme, jak vytvořit dokonalé sítě TCP/IP - samozřejmě pomocí směrovačů Cisco.
Nejdříve se podíváme na verze protokolů TCP/IP podle ministerstva obrany a poté porovnáme tuto verzi a její protokoly s referenčním modelem OSI, který jsme analyzovali v kapitole 1 "Datové sítě". Jakmile porozumíte protokolům, které se uplatňují na různých úrovních modelu ministerstva obrany, zaměříme se na IP adresování a různé třídy adres používané v současných sítích.
Vzhledem k mimořádnému významu všesměrových adres pro pochopení adresování IP a také tvorby podsítí a VLSM, je zásadně důležité, abyste se vyznali v různých variantách všesměrových adres. Kapitolu uzavřeme popisem jednotlivých typů všesměrových adres, které prostě musíte znát. V této kapitole vynecháme protokol IPv6 (Internet Protocol version 6). Soustředíme se zde výhradně na protokol IPv4. Protokol IPv6 analyzujeme v kapitole 1 3, "Protokol IPv6 (IP Version 6)". I když tedy budeme diskutovat o protokolu IPv4, budeme jeho zkratku pro jednoduchost uvádět jako IP.
Protokoly TCP/ IP a model ministerstva obrany
Model ministerstva obrany lze v zásadě popsat jako zhuštěnou verzi modelu OSI. Místo ze sedmi se skládá jen ze čtyř vrstev:
• Procesní/aplikační vrstva • Hostitelská vrstva • Internetová vrstva • Síťová přístupová vrstva
Obrázek 2. 1 znázorňuje porovnání modelu ministerstva obrany a referenčního modelu OSI. Jak je patrné, oba mají podobnou koncepci, ale obsahují odlišný počet vrstev s různými názvy.
Poznámka Při rozboru různých protokolů sady IP lze vrstvy modelů OSI a ministerstva obrany libovolně zaměňovat. Jinými slovy internetová vrstva a sítová vrstva popisují totéž, stejně jako jsou vzájemně ekvivalentní hostitelská a transportní vrstva.
Mnoho různých protokolů kombinuje procesní/aplikační vrstvu modelu ministerstva obrany při integraci různých aktivit a funkcí, které zahrnují aspekty tří odpovídajících horních vrstev modelu OSI (aplikační, prezentační a relační). Na tyto protokoly se podrobně zaměříme v další části této kapitoly. Procesní/aplikační vrstva definuje protokoly pro komunikaci aplikací mezi jednotlivými uzly a řídí také specifikace uživatelského rozhraní. Hostitelská vrstva odpovídá funkcím transportní vrstvy modelu OSI. Definuje protokoly, které nastavují úroveň přenosových služeb poskytovaných aplikacím. Řeší záležitosti typu navazování spolehlivé komunikace mezi koncovými body a zajištění bezchybného doručení dat. Manipuluje s řazením paketů a udržuje integritu dat.
Internetová vrstva je protějškem síťové vrstvy modelu OSI a zahrnuje protokoly, které se týkají logického přenosu paketů v rámci celé sítě. Odpovídá za adresování hostitelů, kterým přiděluje IP adresu (adresu protokolu Internet Protocol) a obsluhuje směrování paketů mezi více sítěmi. V základech modelu ministerstva obrany leží síťová přístupová vrstva, která sleduje výměnu dat mezi hostitelem a sítí. Ekvivalentem linkové a fyzické vrstvy modelu OSI je síťová přístupová vrstva, která dohlíží na hardwarové adresování a definuje protokoly fyzického přenosu dat. Modely ministerstva obrany a OSI vycházejí z obdobného návrhu a koncepce a v rámci podobných vrstev zajišťují podobné funkce. Obrázek 2.2 znázorňuje sadu protokolů TCP/IP a vztah příslušných protokolů k vrstvám modelu ministerstva obrany. V následujících podkapitolách se na jednotlivé protokoly podíváme podrobněji. Začneme přitom od protokolů procesní/aplikační vrstvy.
Protokoly procesní! aplikační vrstvy
v této sekci si popíšeme různé aplikace a služby, které se běžně používají v sítích IP. Zastavíme se u následujících protokolů a aplikací:
• Telnet • FTP • TFTP • NFS • SMTP • LPD • X Window • SNMP • DNS • DHCP/BootP
Telnet
Telnet je jakýmsi chameleónem mezi protokoly. Jeho specialitou je emulace terminálu. Uživateli vzdáleného klientského počítače, který se označuje jako klient Telnet, umožňuje přístup k prostředkům v jiném počítači, takzvaném serveru Telnet. Protokol Telnet přitom klame server a předstírá, že klientský počítač je vlastně terminál, který je přímo připojen do lokální sítě. Tato projekce je v praxi pouhý softwarový obraz - virtuální terminál, který dokáže interagovat se zvoleným vzdáleným hostitelem.
Emulované terminály textového typu dovolují spouštět komplikované procedury typu zobrazení nabídek, z nichž mohou uživatelé volit možnosti a přistupovat k aplikacím na podvedeném serveru. Uživatelé zahájí relaci Telnet tak, že spustí klientský software Telnet a poté se přihlásí k server Telnet.
Protokol FTP (File Transfer Protocol)
Protokol FTP (File Transfer Protocol) v praxi umožňuje přenášet soubory a tuto operaci lze provést mezi libovolnými dvěma počítači, které tento protokol podporují. FTP však není pouze protokol, jedná se rovněž o program. FTP v roli protokolu poskytuje služby aplikacím. Jedná-Ii se o program, pracují s ním uživatelé, kteří požadavky na přenos souborů zadávají ručně. FTP také umožňuje přístup k adresářům i souborům a dokáže provádět určité typy operací s adresáři, jako např. přesun do jiného adresáře. FTP v kombinaci s protokolem Telnet umožňuje transparentní přihlášení k serveru FTP a poté zajišťuje samotný přenos souborů. Přístup k hostiteli pomocí protokolu FTP však představuje pouze první krok. Uživatelé se pak musí autentizovat při přihlášení, které je obvykle zabezpečeno pomocí uživatelských jmen a hesel. Správci systému tím omezují přístup. Požadavku na autentizaci se do jisté míry můžete vyhnout, když zadáte uživatelské jméno anonymous, ačkoli tím získáte právo přístupu jen k části dostupných položek. I když FTP funguje jako uživatelský program, jsou jeho funkce omezeny na výpis adresářů a manipulaci s nimi, zjišťování obsahu souborů a kopírování souborů mezi hostiteli. Nedokáže spouštět vzdálené soubory jako programy.
Protokol TFTP (Trivial File Transfer Protocol)
Protokol TFTP (Trivial File Transfer Protocol) je omezenou a standardní verzí protokolu FTP. Pokud ale víte, co chcete a kde to najít, jedná se o nejvýhodnější volbu. Navíc se tento protokol snadno používá a je velmi rychlý! Neposkytuje však přehršel funkcí jako protokol FTP. Protokol TFTP neumožňuje procházet adresáře. Nedokáže nic jiného, než odesílat a přijímat soubory. Tento kompaktní a malý protokol je úsporný při přenosu dat, protože odesílá mnohem menší bloky dat než protokol FTP. Není k dispozici žádná autentizace jako u FTP, takže se jedná o nezabezpečený protokol. Vzhledem k tomu, že tento protokol ze své podstaty představuje bezpečnostní riziko, podporují jej pouze málokteré weby.
NFS (Network File System)
NFS (Network File System) je hvězdou mezi protokoly a specializuje se na sdílení souborů. Umožňuje spolupráci dvou různých typů systémů souborů. Funguje takto: Předpokládejte, že serverový software NFS funguje na serveru NT a klientský software NFS běží na unixovém hostiteli. NFS dovoluje, aby část paměti RAM na serveru NT transparentně ukládala soubory systému Unix a následně k nim mohli přistupovat uživatelé Unixu. Systémy souborů v operačních systémech NT a Unix sice nejsou stejné - liší se rozlišováním velkých a malých písmen, délkou názvů souborů, zabezpečením atd. - ale uživatelé systému Unix i NT mohou přistupovat k témuž souboru v rámci svých standardních systémů souborů tak, jak jsou zvyklí.
Z praxe Kdy je vhodné použít FTP? Uživatelé v brněnské pobočce potřebují, abyste jím okamžítě poslali soubor velikosti 50 MB. Co uděláte? Většina poštovních serverů by e-mail s takovou přílohou odmítla, protože mají nastaveny velikostní limity. I kdyby na serveru nebylo žádné omezení velikosti, stejně by odeslání tak velkého souboru do Brna trvalo značně dlouho. Na pomoc zde přichází protokol FTP. Chcete-Ii někomu předat velký soubor nebo potřebujete velký soubor přijmout, představuje protokol FTP rozumnou volbu. Jestliže máte k dispozici širokopásmové připojení ADSL nebo kabelové připojení, lze menší soubory (méně než 5 MB) prostě poslat e-mailem. Většina poskytovatelů služeb Internetu však nedovoluje posílat e-mailem soubory nad 5 MB. Pokud tedy požadujete odesílání a příjem velkých souborů, měli byste zvážit nasazení protokolu FTP. (Ostatně, kdo se v současnosti s takovými soubory nesetkává?) Chcete-Ii pOUŽívat protokol FTP, musíte v Internetu nastavit server FTP, aby bylo možné soubory sdílet. Přenos FTP je kromě toho rychlejší než e-mail, což je další d ůvod pro posílání či přijem velkých souborů tímto protokolem. Protože je navíc založen na protokolu TCP a jedná se o spojovaný protokol, m ůže FTP při přerušení relace někdy navázat tam, kde přenos posledně skončil. Zkuste totéž zvládnout se svým e-mailovým klientem!
SMTP (Simple Mail Transfer Protocol)
Protokol SMTP (Simple Mail Transfer Protocol) plní naši touhu po nových e-mailových zprávách. Při doručování zpráv používá zařazování do fronty. Jakmile je zpráva odeslána do cílového umístění, je zařazena na zařízení - obvykle na pevný disk. Serverový software v cílovém umístění hlídá příchozí data a pravidelně kontroluje, zda se ve frontě neobjevily nové zprávy. Pokud je detekuje, zajistí jejich doručení koncovému příjemci. Protokol SMTP slouží k odesílání pošty. Na příjem zpráv se specializuje protokol POP3.
LPD (Line Printer Daemon)
Protokol LPD (Line Printer Daemon) slouží ke sdílení tiskáren. Protokol LPD spolu s programem LPR (Line Printer) umožňují zařazovat tiskové úlohy a odesílat je na síťové tiskárny pomocí protokolů TCP/IP.
X Window
Protokol X Window určený ke komunikaci klientů a serveru definuje parametry aplikací klient/server založených na grafickém uživatelském rozhraní (GUI). Princip je založen na tom, že program označovaný jako klient je spuštěn v jednom počítači a zobrazuje prvky uživatelského rozhraní pomocí okenního serveru, který funguje v jiném počítači.
Protokol SNMP (Simple Network Management Protocol)
Protokol SNMP (Simple Network Management Protocol) shromažďuje klíčové informace o síti a manipuluje s nimi. Data získává dotazováním zařízení v síti ze stanice pro správu v pevných či náhodných intervalech. Od zařízení přitom požaduje zveřejnění určitých informací. Pokud vše funguje správně, obdrží SNMP tzv. standardní hodnoty (baseline), což je sestava popisující provozní parametry zdravé sítě. Tento protokol také kontroluje provoz sítě a zodpovědné osoby rychle informuje o případných změnách stavu. Tyto síťové hlídky se označují jako agenty a když se vyskytnou odchylky, odesílají agenty na adresu stanice pro správu upozornění, která se nazývají depeše (trap).
DNS (Domain Name Service)
Systém DNS (Domain Name Service) překládá názvy hostitelů - konkrétně internetové názvy jako www . route r s i m. c om. Systém DNS nemusíte používat. Místo toho stačí zadat IP adresu libovolného zařízení, s nimž chcete komunikovat. IP adresa identifikuje hostitele v lokální síti i v Internetu. Systém DNS však usnadňuje uživatelům život. Zamyslete se nad tím: Co se stane, pokud se rozhodnete přesunout své webové stránky k jinému poskytovateli služeb? Změní se jejich IP adresa a žádný návštěvník nebude novou adresu znát. Systém DNS umožňuje požádat o přístup k IP adrese pomocí doménového názvu. IP adresu lze pak měnit libovolně často a nikdo si toho nevšimne. Systém DNS překládá plně kvalifikovaný doménový název (FQDN - fully qualified domain name), jako např. www . 1 amml e. c om či todd . 1 a mml e. c om. Plně kvalifikovaný doménový název popisuje hierarchii, která logicky lokalizuje systém podle jeho doménového identifikátoru. Chcete-Ii přeložit název todd, musíte buď zadat plně kvalifikovaný doménový název todd . 1 amml e. c om, nebo pracovat se zařízením typu PC či směrovače, které příponu doplní automaticky. Ve směrovačích Cisco je například možné zadat příkaz i p d oma i n - n a me 1 amml e. c om, který ke každému požadavku připojí doménu 1 amml e. c om. Jestliže příkaz nepoužijete, musíte zadávat plně kvalifikovaný doménový název. Jinak by systém DNS nedokázal název přeložit.
Tip U systému DNS je důležité si pamatovat, že pokud můžete zařizeni kontaktovat příkazem ping pomoci IP adresy, ale nelze použit jeho plně kvalifikovaný doménový název, pravděpodobně se jedná o nějaký typ chybné konfigurace systému DNS.
Protokol DHCP (Dynamic Host Configuration Protocol)/ protokol BootP (Bootstrap Protocol)
Protokol DHCP (Dynamic Host Configuration Protocol) přiřazuje hostitelům IP adresy. Usnadňuje správu a dobře funguje v prostředí malých až značně rozsáhlých sítí. Jako server DHCP lze použít libovolný hardware, včetně směrovače Cisco. Protokol DHCP se od protokolu BootP liší v tom, že protokol BootP přiřazuje IP adresu hostiteli, ale hardwarovou adresu hostitele je nutné zadat ručně do tabulky BootP. Protokol DHCP si můžete představit jako dynamický protokol BootP. Pamatujte však, že BootP také slouží k odeslání operačního systému, ze kterého je možné hostitele spustit. Protokol DHCP tuto funkci neposkytuje. Když však hostitel požádá server DHCP o IP adresu, může tento server hostiteli sdělit mnoho informací. Následuje seznam údajů, které server DHCP dokáže poskytovat:
• IP adresa • Maska podsítě • Doménový název • Výchozí brána (směrovače) • DNS • Informace WINS
Server DHCP může nabídnout i informace nad rámec tohoto seznamu, ale uvedené položky jsou nejběžnější. Klient, který odesláním zprávy DHCP Discover požádá o přidělení IP adresy, odesílá všesměrové vysílání na vrstvách 2 i 3. Všesměrové vysílání na vrstvě 2 obsahuje výhradně hexadecimální znaky F. Cílová adresa tedy vypadá takto: FF:FF:FF:FF:FF:FF. Všesměrové vysílání na vrstvě 3 má cílovou adresu ve tvaru 255.255.255.255, což znamená všechny sítě a všichni hostitelé. Protokol DHCP je nespojovaný. To znamená, že používá protokol UDP (User Datagram Proto col) na transportní vrstvě, která se také označuje jako hostitelská vrstva. Na tyto protokoly se zaměříme v další sekci. Pokud máte pochybnosti, můžete se přesvědčit v následujícím příkladu výstupu ze spolehlivého analyzátoru Ethereal:
Ethe rnet II. Src : 1 9 2 . 1 6 8.0.3 ( 0 0:O b:d b:9 9:d 3:5 e ) . Dst : 8 r oadca st
( f f : ff : ff : f f : ff : f f)
I n ternet P r otocol . Src : 0.0.0.0 (0.0.0.0) . Dst : 255 . 2 5 5.2 5 5 . 255
( 2 5 5 . 2 5 5 . 2 5 5 . 255 )
Linková i síťová vrstva odesílají všesměrová vysílání se žádostí typu: "Pomozte - neznám svou IP adresu!"
Protokoly hostitelské vrstvy
Hlavním účelem hostitelské vrstvy je odstínit aplikace na horních vrstvách od detailů fungování sítě. Tato vrstva sděluje vyšší vrstvě "Stačí, když mi dáš svůj datový proud s příslušnými pokyny, a já začnu tvoje informace připravovat k odeslání". Následující sekce popisují dva protokoly této vrstvy:
• TCP (Transmission Control Proto col) • UDP (User Datagram Proto col)
Kromě toho se budeme zabývat některými základními koncepcemi protokolů hostitelské vrstvy a seznámíme se i s čísly portů.
Poznámka Pamatujte, že se stále nacházíme načtvrté vrstvě, a společnost Cisco široce využívá toho, jak lze na vrstvě 4 pracovat s potvrzenimi, řazením paketů a řízením toku.
TCP (Transmission Control Protocol)
Protokol TCP (Transmission Control Protocol) přijímá od aplikací velké bloky dat a dělí je na segmenty. Každý segment očísluje a zařadí, aby cílový zásobník protokolu TCP mohl segmenty znovu uspořádat tak, jak to požaduje příslušná aplikace. Po odeslání těchto segmentů vyčká zásobník protokolu TCP (na vysílajícím hostiteli) na potvrzení relace virtuálního okruhu TCP přijímající strany a opakuje přenos těch paketů, které nebyly potvrzeny. Před tím, než přenášející hostitel v tomto modelu začne odesílat segmenty, kontaktuje zásobník protokolu TCP odesilatele odpovídající zásobník příjemce, aby bylo navázáno spojení. Vytvořená vazba se označuje jako virtuální okruh. Tento typ komunikace se označuje jako spojovaný (connection-oriented). Během počátečního navazování komunikace se obě vrstvy TCP dohodnou rovněž na objemu informací, které se budou předávat. Pak zásobník TCP příjemce odešle zpět potvrzení. Poté, co je vše předem domluveno, může probíhat spolehlivá komunikace. Protokol TCP je plně duplexní, spojovaný, spolehlivý a přesný, ale nastavení všech podmínek přenosu nad rámec kontroly chyb rozhodně není zadarmo. Protokol TCP je velmi komplikovaný a nepřekvapuje, že s ohledem na svou síťovou režii také poměrně nákladný. Vzhledem k tomu, že dnešní sítě jsou mnohem spolehlivější než kdysi, bývá tato zvýšená spolehlivost často zbytečná.
Formát segmentu TCP
Horní vrstvy pouze odesílají datové proudy protokolům na transportních vrstvách. Nyní si tedy ukážeme, jak protokol TCP segmentuje datový proud a připravuje jej pro internetovou vrstvu. Když datový proud přijme internetová vrstva, směruje segmenty v rámci datové sítě v podobě paketů. Segmenty zpracovává protokol hostitelské vrstvy přijímaj ícího hostitele, který datový proud rekonstruuje a předá aplikacím či protokolům vyšších vrstev. Formát segmentu TCP je znázorněn na obrázku 2.3. Schéma představuje různá pole v hlavičce paketu TCP. Hlavička TCP má délku 20 bajtů, případně až 24 bajtů včetně možností. Je nutné se seznámit s tím, co každé pole v segmentu TCP znamená:
Source port (Zdrojový port) - číslo portu aplikace na straně hostitele, která odesílá data. (Čísla portů si vysvětlíme dále v této sekci.)
Destination port (Cílový port) - číslo portu požadované aplikace v cílovém hostiteli.
Sequence number (Pořadové číslo) - číslo používané protokolem TCP, které umožňuje znovu uspořádat data ve správném pořadí nebo znovu přenést chybějící či poškozená data na základě procesu označovaného jako řazení paketů (sequencing).
Acknowledgement number (Číslo potvrzení) - následně očekávaný oktet TCP.
Header length (Délka hlavičky) - počet 32bitových slov v hlavičce TCP. Tato hodnota informuje o tom, kde začínají data. Délka hlavičky TCP (i v případě, že zahrnuje další možnosti) je celočíselným násobkem 32 bitů.
Reserved (Vyhrazeno) - vždy nastaveno na nulu.
Code bits (Kódové bity) - řídicí funkce, které slouží k navázání a ukončení relace.
Window (Okno) - velikost okna, které je příjemce ochoten přijmout. Udává se v oktetech. Checksum (Kontrolní součet) - hodnota CRC (cyclic redundancy check), protože protokol TCP nedůvěřuje nižším vrstvám a vše kontroluje. Hodnota CRC ověřuje hlavičku a datová pole.
Urgent (Naléhavé) - pole je platné pouze v případě, že je nastaven ukazatel Urgent v kódových bitech. V kladném případě tato hodnota udává posun oproti aktuálnímu pořadovému číslu (v oktetech), kde začíná první segment dat s nižší prioritou.
Options (Možnosti) - může se rovnat O nebo násobku 32 bitů, pokud se používá. To znamená, že nemusí být uvedena žádná možnost (pole Options má nulovou velikost). Jestliže se však v tomto poli používají jakékoli možnosti, které se v souhrnu nerovnají násobku 32 bitů, je nutné použít vyplnění nulami, aby data začínala na hranici násobku 32 bitů.
Data - předávají se směrem dolů protokolu TCP na transportní vrstvě a zahrnují hlavičky protokolů vyšší vrstvy.
Podívejte se na segment TCP zkopírovaný ze síťového analyzátoru:
TCP - Transp ort Control P r otocol
Source Port : 5973
Destinati on Port : 23
Sequence N u mbe r: 1 4 56389907
Ack Number: 1 2 42056456
Offset : 5
Reserved : %000000
Code : % 0 1 1 0 00
Ack is va l i d
Pus h Reques t
W indow : 613 20
Checksum: Ox6 1a6
Urgent Poi nter : 0
No TCP O p tio ns
TCP Data Area :
vL.5 .+.5.+. 5.+.5 76 4c 19 35 II 2b 19 35 II 2b 19 35 II
2 b 1 9 3 5 +. II 2b 19
F r ame Check Sequence : OxOdOOOOOf
Všimli jste si, že tento segment obsahuje vše, co bylo uvedeno v předchozím popisu? Jak je zřejmé z počtu polí v hlavičce, generuje protokol TCP značnou režii. Vývojáři aplikací se mohou rozhodnout, že kvůli snížení režie dají před spolehlivostí přednost efektivitě. Za tímto účelem byl jako alternativa na transportní vrstvě definován i protokol UDP (User Datagram Protocol).
UDP (User Datagram Protocol)
Pokud porovnáte protokol UDP (User Datagram Protocol) s protokolem TCP, zjistíte, že první z nich je v zásadě zjednodušenou ekonomickou verZÍ druhého. Tento model se někdy označuje jako tenký protokol. Podobně jako hubený člověk na lavičce v parku ani tenký protokol nezabírá mnoho místa - v tomto případě vyžaduje menší šířku pásma sítě. Protokol UDP ani nenabízí všechny pokročilé funkce protokolu TCP, ale dokonale plní úkol přenosu informací, které nevyžadují spolehlivé doručení - a konzumuje přitom mnohem méně síťových prostředků. (Protokol UDP je podrobně popsán ve standardu RFC - Request for Comments - 768.)
Poznámka Dokumenty RFC (Requests for Comments) tvoří od roku 1969 souvislou řadu komentářů týkajících se Internetu (původně sítě ARPAnet). Tyto texty se týkají mnoha aspektů počítačové komunikace. Zaměřují se na síťové protokoly, postupy, programy a koncepce, ale zahrnují i poznámky ze schůzí, osobní názory a někdy i vtipy.
V některých situacích je rozhodně rozumné, aby vývojáři dali přednost protokolu UDP před protokolem TCP. Pamatujete si na hlídací protokol SNMP na vyšší procesní/aplikační vrstvě? Protokol SNMP sleduje síť a odesílá příležitostné zprávy a poměrně stabilní tok aktualizací stavu a upozornění, zejména v případě, kdy se používá v rozsáhlé síti. Náklady na navazování, údržbu a ukončování spojení TCP pro každou z těchto krátkých zpráv by způsobily, že jinak funkční a efektivní síť by se okamžitě zpomalila až k nepoužitelnosti! Jiná situace, kdy je vhodné zvolit protokol UDP místo protokolu TCP, nastává, když je spolehlivost již zajišťována na procesní/aplikační vrstvě. Protokol NFS (Network File System) se stará o spolehlivost sám, takže je v tomto případě použití protokolu TCP nepraktické i nadbytečné. Rozhodnutí o výběru protokolu UDP nebo TCP však nakonec musí přijmout vývojář, nikoli uživatel, který chce přenášet svá data rychleji.
Protokol UDP neřadí segmenty a nestará se o to, v jakém pořadí dorazí do cílového umístění. UDP prostě segmenty odešle a dále se jimi nezabývá. Nesleduje tyto segmenty, nekontroluje jejich stav ani neposkytuje potvrzení bezpečného doručení - dá se říci, že segmenty naprosto opouští. Vzhledem k tomu se označuje jako nespolehlivý protokol. To neznamená, že by byl protokol UDP neefektivní, pouze neřeší otázky spolehlivosti. UDP dále nevytváří virtuální okruh ani nekontaktuje cílové umístění před tím, než mu odešle data. Z tohoto důvodu se také považuje za nespojovaný protokol. Protokol UDP předpokládá, že aplikace zajistí spolehlivost svými vlastními metodami a sám žádnou metodu tohoto typu nepoužívá. Vývojář aplikace, který pracuje se zásobníkem protokolu IP, má tedy na výběr: TCP poskytující spolehlivost, nebo UDP urychlující přenosy.
Jestliže tedy například pracujete s technologií přenosu hlasu VolP (Voice over IP), rozhodně není vhodné zvolit protokol UDP. Pokud by totiž segmenty dorazily v nesprávném pořadí (což se v sítích IP stává velmi běžně), jednoduše by byly předány další vrstvě modelu OSI (ministerstva obrany) v libovolném pořadí tak, jak byly přijaty. Výsledná data by byla nesmyslně promíchána. Oproti tomu protokol TCP řadí segmenty tak, aby je bylo možné sestavit zpět přesně ve stejném pořadí. Tuto možnost protokol UDP jednoduše nenabízí.
Formát segmentu UDP
Obrázek 2.4 jasně dokládá mimořádně nízkou režii protokolu UDP v porovnání s vysokými nároky protokolu TCP. Pečlivě se na toto schéma podívejte. Jak se můžete sami přesvědčit, protokol UDP nepoužívá ve své hlavičce okna a ani neposkytuje potvrzení.
Potřebujete rozumět tomu, jaký význam mají jednotlivá pole v segmentu UDP:
Source port (Zdrojový port): Číslo portu aplikace na straně hostitele, která odesílá data.
Destination port (Cílový port): Číslo portu požadované aplikace v cílovém hostiteli.
Length (Délka): Délka hlavičky UDP a přenášených dat.
Checksum (Kontrolní součet): Kontrolní součet kombinace hlavičky UDP s datovými poli.
Data: Data horní vrstvy.
Protokol UDP stejně jako TCP nespoléhá na vyšší vrstvy a počítá vlastní hodnoty CRC. Pamatujte, že hodnota kontrolního součtu CRC se nachází v poli Frame Check Sequence (FCS). Z tohoto důvodu je uvedena informace FCS.
Následující výpis představuje segment UDP zachycený síťovým analyzátorem:
UDP - User Datagram P rotocol
Source Port : 1 0 85
Destination Port : 513 6
Length : 41
Checksum: Ox7a3c
UDP Data Area :
.. Z ...... 00 Ol 5a 96 00 Ol 00 00 00 00 00 II 0000 00
... C .. 2 . _C . _C 2e 03 00 43 02 1e 32 Oa 00 Oa 00 80 43 00 80
F r ame Check Sequence : OxOOOOOOOO
Všimněte si nízké režie! Pokuste se v segmentu UDP najít pořadové číslo, číslo potvrzení a velikost okna. Nepodaří se vám to, protože tyto hodnoty zde jednoduše nejsou.
Klíčové koncepce protokolů hostitelské vrstvy
Vzhledem k tomu, že už jste získali představu o fungování spojovaného (TCP) i nespojovaného (UDP) protokolu, můžeme nyní shrnout jejich vlastnosti. Tabulka 2. 1 zdůrazňuje některé klíčové aspekty, které byste u těchto protokolů měli mít na paměti. Obsah tabulky byste si měli zapamatovat.
Tabulka 2.1: Klíčové vlastnosti protokolů TCP a UDP
TCP UDP
Řazený Neřazený
Spolehlivý Nespolehlivý
Spojovaný Nespojovaný
Virtuální okruh Nízká režie
Potvrzení Bez potvrzení
Řízení toku dat pomocí oken Bez oken či řízení toku dat
Fungování protokolu TCP lze dobře osvětlit pomocí analogie s telefonními službami. Chcete-Ii s někým mluvit po telefonu, musíte nejdříve s touto osobou navázat spojení, ať už se nachází kdekoli. To je obdobou virtuálního okruhu u protokolu TCP. Když někomu při hovoru sdělujete důležité informace, můžete říci "Představ si" nebo "Rozumíš tomu?". Tyto fráze, které druhou stranu pobízejí, aby zareagovala, velmi připomínají potvrzení u protokolu TCP. Čas od času (zejména při mobilním telefonování) se lidé také ptají "Jsi tam ještě"? Konverzaci ukončují např. pozdravem "Ahoj", aby dali najevo, že telefonát končí. Protokol TCP rovněž poskytuje obdobné funkce.
Oproti tomu použití protokolu UDP se podobá odeslání pohlednice. Jestliže chcete někomu napsat, nemusíte jej nejdříve kontaktovat. Stačí vymyslet zprávu, uvést adresu a hodit lístek do schránky. Můžeme to přirovnat k nespojovanému charakteru protokolu UDP. Zpráva na pohlednici pravděpodobně není životně důležitá, takže nepotřebujete potvrzení jejího příjmu. Ani protokol UDP neposkytuje potvrzení. Podívejte se nyní na další obrázek 2.5, který znázorňuje protokoly TCP a UDP a aplikace, které jsou k jednotlivým protokolům přidruženy.
Čísla portů
Protokoly TCP a UDP musí při komunikaci s vyššími vrstvami používat čísla portů. Tato čísla totiž dovolují rozlišovat různé komunikace, které jsou v síti aktivní ve stejnou dobu. Zdrojový hostitel dynamicky na zdrojové straně přiděluje čísla portů s hodnotou 1 024 a vyšší. Čísla portů do hodnoty 1 023 jsou definována ve standardu RFC 3232 (případně navštivte web www . i ana . o rg), který se zabývá tzv. dobře známými čísly portů. Virtuální okruhy, které nepoužívají aplikaci s dobře známým číslem portu, mají místo toho přidělena náhodná čísla portů z určitého rozsahu. Tato čísla portů identifikují v segmentu TCP zdrojovou a cílovou aplikaci nebo proces.
Obrázek 2.5 dokládá, jakým způsobem protokoly TCP i UDP pracují s čísly portů.
Dále jsou vysvětlena různá čísla portů, které lze použít:
• Čísla nižší než 1 024 se považují za dobře známá čísla portů a jejich definici naleznete v dokumentu RFC 3232.
• Čísla 1 024 a vyšší slouží horním vrstvám k navázání relací s jinými hostiteli a protokol TCP je používá jako zdrojové a cílové adresy v segmentu TCP.
V následujících sekcích si rozebereme výstup analyzátoru s ukázkou relace TCP.
Relace TCP: Zdrojový port
Následující výpis dokumentuje relaci TCP zaznamenanou analytickým softwarem OmniPeek:
TCP - Transport Control Protocol
Source Port : 5973
Destinati on Port : 23
Sequence Number: 1 4 56389907
Ack Number: 1 2 42056456
Offset : 5
Re s e rved : %000000
Code : % 0 110 00
Ack is valid
Push Request
Window : 6 1 320
Checksum: Ox61a6
Urgent Pointer : 0
No TCP Options
TCP Data Area :
vL.5.+.5.+.5.+.5 76 4c 19 35 II 2b 19 35 II 2b 19 35 II
2 b 1 9 3 5 +. II 2b 19
Frame Check Sequence : OxOdOOOOOf
Všimněte si, že zdrojový hostitel určuje hodnotu zdrojového portu, která se v tomto případě rovná 5973. Cílový port má hodnotu 23, která sděluje přijímajícímu hostiteli účel zamýšleného spojení (Telnet). Při pohledu na tuto relaci vidíte, že zdrojový hostitel nastavuje zdrojový port na číslo od 1 024 do 65535. Proč však zdroj pokaždé volí jiná čísla portů? Díky tomu lze totiž rozlišit relace s různými hostiteli. Pokud by server neměl od odesílajícího hostitele jedinečné číslo, jak by věděl, odkud informace pochází? Protokol TCP a protokoly vyšších vrstev nerozlišují odesílajícího hostitele podle hardwarové a logické adresy jako protokoly linkové a síťové vrstvy. Místo toho používají čísla portů. Snadno si můžete představit, jaký zmatek by nastal na straně přijímajícího hostitele, kdyby všichni hostitelé požadovali připojení k FTP pomocí stejného čísla zdrojového portu!
Relace TCP: cílový port
Ve výstupu analyzátoru někdy pouze zjistíte, že zdrojový port má číslo vyšší než 1 024 a cílový port patří mezi dobře známé porty, jak je patrné v následujícím sledování:
TCP - T ransport Control P rotocol
Source Port : 1 1 44
Destinati on Port : 80 Wo rld Wide Web HTTP
Sequence Number: 9356570
Ack Numbe r: O
Offset : 7
Rese rved : %000000
Code : %00 0010
Sy nch Sequence
Window : 8192
Checksum O x 57E7
Urgent Pointer: 0
TCP Options :
O p tio n Type : 2 Maximum Segment Size
Length : 4
MSS : 536
Opti on Type : 1 No Opera t i o n
Option Type : 1 No Opera t i o n
Option Type : 4
Length : 2
Opt Value:
No More HTTP Data
Frame Check Seque nce : Ox4369 7363
Je zřejmé, že zdrojový port má číslo vyšší než 1 024, ale cílový port se rovná 80. Jedná se tedy o službu HTTP. Server (přijímající hostitel) může cílový port v případě potřeby změnit. V předchozím sledování je na cílové zařízení odeslán paket "syn". Sekvence syn sděluje vzdálenému cílovému zařízení, že zdroj požaduje vytvoření relace.
Relace TCP: Potvrzení paketu Syn
Další sledování ukazuje potvrzení paketu syn:
Všimněte si údaje Ack is va1id, který znamená, že zdrojový port byl přijat a zařízení souhlasilo s tím, že s výchozím hostitelem vytvoří virtuální okruh. Na tomto místě se opět můžete přesvědčit, že odpověď serveru obsahuje zdrojový port 80 a cílový port 1 144 odeslaný z původního hostitele. Vše je tedy v pořádku. Tabulka 2.2 uvádí seznam běžných aplikací založených na sadě protokolů TCP/IP, jejich dobře známá čísla portů a rovněž protokoly transportní vrstvy, které každá aplikace či proces používá. Je důležité, abyste si tuto tabulku osvojili. Všimněte si, že systém DNS pracuje s protokoly TCP i UDP. Konkrétní zvolený protokol závisí na požadované operaci. Aplikací, které mohou používat oba protokoly, je sice více, ale tento příklad byste si rozhodně měli pamatovat.
Tabulka 2.2: Klíčové protokoly založené na protokolech TCP a UDP
Poznámka Protokoly TCP/IP a model ministerstva obrany 117 Protokol TCP je spolehlivý díky řazení, potvrzení a řízení toku dat (posunu oken). Protokol UDP spolehlivost neposkytuje
Protokoly internetové vrstvy
Model ministerstva obrany uvádí dva hlavní důvody pro vznik internetové vrstvy: směrování a zajištění jednotného síťového rozhraní pro vyšší vrstvy. Žádný z protokolů vyšších ani nižších vrstev nemá funkce týkající se směrování. O tento složitý a důležitý úkol se stará výhradně internetová vrstva. Druhou povinností internetové vrstvy je poskytnout jediné síťové rozhraní pro protokoly vyšších vrstev. Bez této vrstvy by programátoři museli do každé aplikace přidávat rozhraní pro všechny protokoly síťové přístupové vrstvy. Kromě toho, že by to bylo pracné, vedlo by to ke vzniku odlišných verzí každé aplikace - jedné pro Ethernet, další pro Token Ring atd. Aby to nebylo nutné, poskytuje protokol IP protokolům vyšších vrstev jediné unifikované síťové rozhraní. Jakmile je tento úkol splněn, je potřeba ještě zajistit, aby protokol IP a různé protokoly síťové přístupové vrstvy vzájemně spolupracovaly. Všechny síťové cesty nevedou do Říma, ale k protokolu IP. Tento protokol používají všechny další protokoly na stejné vrstvě a také všechny protokoly na vyšších vrstvách. Nikdy na to nezapomínejte. Všechny cesty modelem ministerstva obrany směřují přes protokol IP. V následujících sekcích si popíšeme protokoly na internetové vrstvě:
• IP (Internet Protocol) • ICMP (Internet Control Message Proto col) • ARP (Address Resolution Protocol) • RARP (Reverse Address Resolution Protocol) • Proxy ARP
IP (Internet Protocol)
IP (Internet Protocol) v zásadě představuje internetovou vrstvu. Další protokoly zde plní pouze pomocnou funkci. Protokol IP tvoří základní schéma a dá se říci, že "vše vidí" - v tom smyslu, že má informace o všech propojených sítích. Tato vlastnost protokolu IP je založena na tom, že všechny počítače v síti mají softwarovou neboli logickou adresu označovanou jako IP adresa, kterou se budeme podrobněji zabývat v další části této kapitoly. Protokol IP kontroluje adresy všech paketů. Poté pomocí směrovací tabulky rozhoduje, kam bude paket odeslán dále. Volí přitom optimální trasu. Protokoly na síťové přístupové vrstvě v dolní části modelu ministerstva obrany nemají stejně jako protokol IP znalosti celé sítě. Místo toho se týkají pouze fyzických spojení (lokálních sítí). Při identifikaci zařízení v sítích je nutné zodpovědět tyto dvě otázky: Ve které síti se zařízení nachází? A jaké je jeho ID v dané síti? Odpovědí na první otázku je softwarová adresa neboli logická adresa (správná ulice).
Druhou odpovědí je hardwarová adresa (správná poštovní schránka). Všichni hostitelé v síti mají logický identifikátor zvaný IP adresa. Jedná se o softwarovou neboli logickou adresu, která v sobě nese důležité informace značně zjednodušující složitý úkol směrování. (Protokol IP je popsán ve standardu RFC 79 1 .) Protokol IP přijímá segmenty z hostitelské vrstvy a v případě potřeby je rozkládá na datagramy (pakety). Na přijímající straně pak datagramy sestavuje zpět do segmentů. Odesilatel i příjemce přiřazuje každému datagramu IP adresu. Každý směrovač (zařízení vrstvy 3), který datagram přijme, pak rozhoduje o dalším směrování na základě cílové IP adresy paketu. Hlavička IP je znázorněna na obrázku 2.6. Toto schéma vám poskytne představu o tom, jaké operace musí protokol IP plnit při každém odeslání uživatelských dat z vyšších vrstev do vzdálené sítě.
Hlavička IP sestává z následujících polí:
Version (Verze) - číslo verze IP.
Header length (Délka hlavičky) - délka hlavičky (HLEN) v 32bitových slovech.
Priority and Type of Service (Priorita a typ služby) - typ služby určuje způsob zpracování datagramu. První 3 bity udávají prioritu.
Total length (Celková délka) - délka paketu včetně hlavičky a dat.
Identification (Identifikace) - unikátní hodnota paketu IP.
Flags (Příznaky) - udává, zda může nastat fragmentace.
Fragment offset (Posun fragmentu) - zajišťuje fragmentaci a opakované sestavení v případě, že je paket příliš velký a nevejde se do rámce. Díky této funkci lze také v Internetu používat různé hodnoty MTU (maximum transmission unit).
Time to Live (Hodnota TTL) - hodnota TTL je zapsána do paketu při jeho generování. Pokud se paket nedostane na místo svého určení dříve, než hodnota TTL vyprší, jednoduše se zahodí. Tím je zaručeno, že bezprizorní pakety IP nebudou neomezeně obíhat po síti.
Protocol (Protokol) - port protokolu vyšší vrstvy (TCP má port 6 a UDP 17 [hex] ). K dispozici je i podpora protokolu síťové vrstvy, jako je ARP a ICMP. Některé analyzátory mohou toto pole označovat jako Type (Typ). Zakrátko si toto pole rozebereme podrobněji.
Header checksum (Kontrolní součet hlavičky) - výsledek cyklického kontrolního součtu samotné hlavičky.
Source IP address (Zdrojová IP adresa) - 32bitová IP adresa odesílající stanice.
Destination IP address (Cílová IP adresa) - 32bitová IP adresa stanice, pro kterou je paket určen. Options (Možnosti) - slouží k testování sítě, ladění, zabezpečení a dalším funkcím.
Data - za polem možností IP budou uvedena data vyšší vrstvy.
Uveďme si nyní snímek paketu IP zachyceného síťovým analyzátorem (všimněte si, že se zde vyskytují všechny hlavičky popsané výše):
Velmi důležité je pole Type (obvykle se označuje jako pole Proto col, ale tento analyzátor je detekuje jako pole IP Type). Pokud by hlavička neobsahovala informace protokolu další vrstvy, protokol IP by nevěděl, jak data uložená v paketu zpracovat. V předchozím příkladu může protokol IP zjistit, že má segment předat protokolu TCP. Obrázek 2.7 dokumentuje, jak síťová vrstva přistupuje k protokolům na transportní vrstvě, když potřebuje předat paket protokolům vyšších vrstev.
P
ole Protocol v tomto příkladu zajistí, že protokol IP odešle data buď na port TCP (číslo 6), nebo na port UDP (číslo 1 7) (obě adresy jsou hexadecimální). Protokol UDP či TCP se však uplatní pouze tehdy, jsou-Ii data součástí datového proudu, který je určen pro službu nebo aplikaci na vyšší vrstvě. Cílem může být stejně dobře protokol ICMP (Internet Co nt rol Message Protocol), ARP (Address Resolution Protocol) nebo jiný typ protokolu síťové vrstvy. Tabulka 2.3 shrnuje některé další oblíbené protokoly, které lze nastavit v poli Protocol.
ICMP (Internet Control Message Protocol)
Protokol ICMP (Internet Control Message Protocol) funguje na síťové vrstvě a protokol IP pomocí něj zajišťuje mnohé služby. ICMP slouží jako protokol pro správu a poskytování služeb zasílání zpráv pro protokol IP. Jeho zprávy jsou přenášeny jako datagramy IP. Dokument RFC 1 256 popisuje dodatek protokolu ICMP, který rozšiřuje možnosti hostitele při zjišťování cest k branám. Pakety protokolu ICMP mají následující vlastnosti:
• Mohou hostitelům sdělovat informace o potížích se sítí. • Jsou zapouzdřeny v rámci datagramů IP.
Uveďme si některé běžné události a zprávy, se kterými protokol ICMP souvisí:
Destination Unreachable (Cíl není dosažitelný): Pokud směrovač nedokáže předat datagram IP dále, odešle pomocí protokolu ICMP zprávu zpět odesilateli s informací o situaci. Podívejte se například na obrázek 2.8, ze kterého je patrné, že rozhraní EO směrovače Lab_B není aktivní.
Když hostitel A odešle paket určený hostiteli B, směrovač Lab_B odešle zpět vysílajícímu zařízení (v tomto případě hostiteli A) zprávu ICMP o nedosažitelnosti cíle.
Buffer Full (Zaplněná vyrovnávací pamět): Jestliže se zaplní vyrovnávací paměť směrovače pro příjem příchozích datagramů, bude směrovač pomocí protokolu ICMP šířit tuto zprávu, dokud se zahlcení nevyřeší.
Hops (Počet přeskoků): Každému datagramu IP je přiřazen určitý počet směrovačů, přes které může projít. Tato hodnota se označuje jako počet přeskoků (TTL). Pokud datagram dosáhne limitního počtu přeskoků dříve, než dorazí do cíle, odstraní jej směrovač, který jej přijal jako poslední. Likvidující směrovač pak pomocí protokolu ICMP odešle jakési "parte", které zdrojovému počítači dává na vědomí, že jeho datagram nedorazil do cíle.
Ping: Ping (Packet Internet Groper) pomocí požadavků ozvěny ICMP a odpovědí kontroluje fyzickou a logickou konektivitu počítačů v datové síti.
Traceroute: Příkaz Traceroute na základě vypršení časového limitu ICMP (TTL) zjišťuje cestu, kterou paket prochází datovou sítí.
Poznámka Příkazy Ping i Traceroute (také se zkráceně označuje jako Trace; v systému Microsoft Windows má název tracert) dovolují ověřit konfigurace adres v datové síti.
Následující data pocházejí ze síťového analyzátoru, který zachytil požadavek ozvěny ICMP:
Nevšimli jste si ničeho zvláštního? Postřehli jste, že ačkoli protokol ICMP funguje na internetové (síťové) vrstvě, přesto i nadále realizuje požadavek Ping pomocí protokolu IP? Pole Type v hlavičce IP má hodnotu OxO l, což znamená, že přenášená data patří protokolu ICMP. Nezapomínejte, že stejně jako všechny cesty vedou do Říma, všechny segmenty nebo data musí projít přes protokol IP!
Poznámka Program Ping používá abecedu v datové části paketu pouze jako výplň, která má standardně délku 1 00 bajtů. Pokud však odesíláte příkaz Ping ze systému Windows, vypadá datová část jinak. Tento systém nejspíš předpokládá, že abeceda končí písmenem W. Vynechává písmena X, Y a Z a znovu začíná písmenem A. Přeberte si to sami!
Pokud si pamatujete na výklad o linkové vrstvě a různých typech rámců v kapitole 1, měli byste být schopni z předchozího sledování zjistit, o jaký typ rámce Ethernet se jedná. Pole jsou omezena na cílovou hardwarovou adresu, zdrojovou hardwarovou adresu a Ether-Type. Pole Ether-Type se vyskytuje výhradně v rámcích EtherneCII. Než však přejdeme k protokolu ARP, podívejme se znovu na protokol ICMP v činnosti. Obrázek 2.9 představuje datovou síť (vyskytuje se tam směrovač, takže se musí jednat o datovou síť, že?).
Serverl ( 1 0. 1 .2.2) se z okna příkazového řádku připojuje protokolem Telnet k počítači 1 0.1.1.5. Co myslíte, že Serverl obdrží jako odpověď? Počítač Serverl odesílá data protokolu Telnet na výchozí bránu, tj. na směrovač. Tento směrovač paket zahodí, protože směrovací tabulka neobsahuje žádnou síť 1 0.1.1.0. Server! proto dostane zprávu protokolu ICMP o nedosažitelnosti cíle.
ARP (Address Resolution Protoco!)
Protokol ARP (Address Resolution Protocol) vyhledává hardwarovou adresu hostitele podle známé IP adresy. Funguje to následovně: Když protokol IP potřebuje odeslat datagram, musí sdělit síťovému přístupovému protokolu, jako je Ethernet či Token Ring, hardwarovou adresu cíle v lokální síti. (Protokoly vyšší vrstvy již poskytly informaci o IP adrese cíle.) Jestliže protokol IP nenajde hardwarovou adresu cílového hostitele v mezipaměti ARP, zjistí tyto informace pomocí protokolu ARP. Protokol ARP plní roli detektiva, který ve prospěch protokolu IP prozkoumá lokální síť pomocí všesměrového vysílání, kdy požádá počítač s konkrétní IP adresou, aby sdělil svou hardwarovou adresu. Protokol ARP tedy v praxi překládá softwarovou (IP) adresu na hardwarovou adresu - například adresu ethernetové síťové karty cílového počítače. Díky všesměrovému vysílání určenému této adrese pak zjišťuje umístění v lokální síti. Obrázek 2. 10 dokumentuje, jak vypadá činnost protokolu ARP v lokální síti.
Poznámka Protokol ARP pfekládá IP adresy na adresy Ethernet (MAC).
Následující sledování představuje všesměrové vysílání protokolu ARP. Všimněte si, že cílová hardwarová adresa není známa a uvedena je řada hexadecimálních znaků F (binárně samé jedničky). Jedná se o všesměrové vysílání se žádostí o hardwarovou adresu:
RARP (Reverse Address Resolution Protocol)
Když počítač v síti IP nemá pevný disk, nemůže po zapnutí znát svou IP adresu. Ví však, jakou má adresu MAC. Protokol RARP (Reverse Address Resolution Protocol) zjistí hodnotu IP adresy počítačů bez disku tak, že odešle paket, který obsahuje MAC adresu a požadavek na IP adresu přiřazenou k dané adrese MAC. Vyhrazený počítač označovaný jako server RARP na žádost odpoví a krize identity je zažehnána. Protokol RARP na základě známé hodnoty adresy MAC počítače zjistí jeho IP adresu a doplní identifikaci počítače. Obrázek 2. 11 znázorňuje pracovní stanici bez disku, která požaduje svou IP adresu pomocí všesměrového vysílání protokolu RARP.
Proxy ARP (Proxy Address Resolution Protocol)
Pro hostitele v síti nelze nakonfigurovat více než jednu výchozí bránu. Zamyslete se nad tím. Co se stane, pokud výchozí brána (směrovač) náhodou přestane fungovat? Hostitel nezačne automaticky odesílat data jinému směrovači. Nejdříve musíte změnit konfiguraci příslušného hostitele. Protokol Proxy ARP však může počítačům v podsíti pomoci kontaktovat vzdálené podsítě, aniž by bylo nutné konfigurovat směrování nebo dokonce vzdálenou bránu. Jedna výhoda protokolu Proxy ARP spočívá v tom, že jej lze aktivovat na jediném směrovači v síti, aniž by to mělo vliv na směrovací tabulky všech ostatních lokálních směrovačů. Použití protokolu Proxy ARP má však zásadní nevýhodu. Nasazení tohoto protokolu v každém případě zvýší objem provozu v rámci síťového segmentu a hostitelé budou mít větší tabulky ARP než obvykle, aby dokázali zvládnout kompletní mapování IP adres na adresy MAC. Protokol Proxy ARP je navíc ve výchozím nastavení nastaven ve všech směrovačích Cisco. Pokud se domníváte, že jej nebudete potřebovat, měli byste jej vypnout. Poslední postřeh týkající se protokolu Proxy ARP: Ve skutečnosti nejde o samostatný protokol. Jedná se o službu, kterou směrovače zajišťují pro jiná zařízení (obvykle PC), která se nemohou přímo dotazovat jiného zařízení k
Tip Pokud si to můžete dovolit, použijte raději protokol HSRP (Hot Standby Router Protocol) společnosti Cisco. Předpokladem je sice nákup dvou nebo více zařízení Cisco, ale tato investice se rozhodně vyplati. Další informace o protokolu HSRP naleznete na webu společnosti Cisco.
Tvorba podsítí, masky podsítí s proměnnou délkou (VLSM) a řešení problému v TCP/I P
V této kapitole navážeme přesně tam, kde jsme v předchozí kapitole skončili. Budeme pokračovat v diskusi o adresování v sítích IP. Nejdříve začneme tvorbou podsítí v síti IP. Na tuto problematiku se musíte opravdu soustředit, protože zvládnutí tvorby podsítí vyžaduje čas i praxi. Obrňte se tedy trpělivostí. Maximálně se snažte, abyste této problematice porozuměli. Tato kapitola je skutečně důležitá a možná se z hlediska výuky jedná o nejdůležitější kapitolu knihy. Tvorbu podsítí IP si rozebereme od samých základů. Následující rada vám možná bude připadat podivná. Podle mých zkušeností vám ale pomůže, když se před čtením této kapitoly pokusíte zapomenout na vše, co jste se o tvorbě podsítí zatím naučili - zejména pokud jste absolvovali školení společnosti Microsoft! Po dokončení rozboru podsítí IP se podrobně zaměříme na masky podsítí s proměnnou délkou (VLSM) a ukážeme si, jak pomocí VLSM navrhovat a implementovat sítě.
Jakmile zvládnete návrh a implementaci masek VLSM, předvedeme si, jak lze sumarizovat třídní hranice. Na tuto problematiku dále navážeme v kapitole 7, "Protokoly EIGRP (Enhanced IGRP) a OSPF (Open Shortest Path First)", kde si předvedeme sumarizaci pomocí směrovacích protokolů EIGRP a OSPF. Tuto kapitolu uzavřeme řešením potíží s IP adresami a projdeme si kroky, které společnost Cisco při řešení problémů sítě IP doporučuje. Duševně se tedy připravte - čeká nás náročný program! Tato kapitola vám umožní skutečně porozumět adresování a tvorbě sítí IP, takže se nenechejte odradit její obtížností a nevzdávejte se. Pokud vytrváte, určitě budete časem velmi rádi, že jste se rozhodli vytrvat. Jakmile této problematice porozumíte, budete se divit, že vám kdysi připadala tak těžká. Jste připraveni? Pusťme se tedy do toho!
Základy tvorby podsítí
Správný překlad "vypnutí" a "zapnutí" bitu:
Vypnutí bitu = nastaven í bitu na O.
Zapnutí bitu = nastavení bitu na 1.
V dalším textu nejsou tyto výrazy opraveny.
V kapitole 2 jste se dozvěděli, jak definovat a najít platné rozsahy hostitelů v sítích třídy A, BaC pomocí vypnutí a následného zapnutí všech hostitelských bitů. Tato metoda je velmi dobrá, ale má jeden háček: Definujete pouze jedinou síť. Jak postupovat, pokud byste vycházeli z jedné síťové adresy a chtěli pomocí ní vytvořit šest sítí? Museli byste použít metodu zvanou tvorba podsítí (subnetting). Tento postup totiž umožňuje vzít jednu velkou síť a rozdělit ji na sadu menších sítí.
Ve prospěch podsítí mluví mnoho důvodů, včetně těchto výhod:
Omezení síťového provozu: Všichni oceňujeme menší provoz, ať už jakéhokoli typu. Počítačové sítě nejsou výjimkou. Bez spolehlivých směrovačů by přenos paketů dokázal ochromit celou síť tak, že by se provoz téměř zastavil. Díky směrovačům je většina provozu omezena na lokální síť. Přes směrovače projdou pouze pakety, které jsou určeny jiným sítím. Směrovače vytvářejí všesměrové domény. Čím více všesměrových domén vytvoříte, tím menší budou a tím více omeZÍte síťový provoz ve všech síťových segmentech.
Optimalizovaný výkon sítě: Tato výhoda vyplývá ze snížení objemu síťového provozu.
Zjednodušená správa: Síťové problémy lze snáze identifikovat a izolovat ve skupině malých propojených sítí, než v rámci jediné gigantické sítě.
Snazší překlenutí velkých geografických vzdáleností: Spoje WAN jsou výrazně pomalejší a také dražší než spoje LAN. Jediná velká síť, která přesahuje velké vzdálenosti, proto může způsobovat problémy ve všech výše zmíněných aspektech. Díky spojení více menších sítí se zvyšuje efektivita celého systému.
V následujících sekcích přejdeme k tvorbě podsítí na základě síťové adresy. Jedná se o zajímavé téma, takže směle do toho.
Příkaz IP subnet-zero
Příkaz IP subnet - zero není nový, ale v minulosti se neobjevoval ve školicích materiálech Cisco ani v okruzích zkoušek. To se však již změnilo. Tento příkaz umožňuje použít první a poslední podsíť v návrhu sítě. Maska 192 třídy C například poskytuje podsítě 64 a 1 28 (podrobněji je rozebereme dále v této kapitole). Pomocí příkazu ip s ubnet - zero však nyní můžete použít podsítě O, 64, 1 28 a 192. Pro každou použitou masku podsítě tím ZÍskáte dvě další podsítě. K rozhraní příkazového řádku (CLI) se sice dostaneme až v další kapitole, "Systém Cisco lOS (lnternetwork Operating System) a nástroj SDM (Security Device Manager)", ale již nyní byste se měli seznámit s tímto příkazem:
PIRl#sh running - config
Building configurati on ... Current configurati on : 827 bytes
!
hostn ame P o dlRl
!
ip s u bnet - z ero
!
Z výstupu je patrné, že v tomto směrovači je příkaz i p s ubnet - zero zadán. Společnost Cisco tento příkaz standardně povoluje od verze 1 2.x svého systému Cisco lOS.
Poznámka Při přípravě na zkoušky Cisco si nezapomeňte velmi pečlivě přečíst, zda společnost Cisco náhodou nepožaduje, abyste příkaz i p s u bnet - zer o nepoužili. V některých případech se s tímto požadavkem můžete setkat.
Jak vytvářet podsítě
Chcete-li vytvořit podsíť, musíte vzít bity z hostitelské části IP adresy a rezervovat je pro definici adresy podsítě. To znamená, že bude méně bitů pro hostitele. Čím více podsítí, tím méně bitů je tedy dostupných k definování hostitelů. Dále v této kapitole se dozvíte, jak vytvořit podsítě počínaje adresami třídy C. Než se však pustíte do vlastní implementace podsítí, měli byste upřesnit své aktuální požadavky a naplánovat také budoucí rozvoj.
Poznámka Než přejdeme k návrhu a vytváření masek podsítí, měli byste vědět, že v této první sekci se budeme zabývat třídním směrováním. To znamená, že všíchni hostitelé (všechny uzly) v síti pracují s přesně stejnou maskou podsítě. Až se pustíme do masek podsítí s proměnnou délkou (VLSM), rozebereme beztřídní směrováni. V tomto případě m ůže každý sítový segment používat odlišnou masku podsítě.
Při vytváření podsítě postupujte takto:
1. Určete počet požadovaných síťových ID: O Jedno pro každou podsíť O Jedno pro každé připojení sítě WAN 2. Určete počet požadovaných hostitelských ID v jedné podsíti: O Jedno pro každého hostitele TCP/IP O Jedno pro každé rozhraní směrovače 3. Na základě výše uvedených požadavků vytvořte: O Jednu masku podsítě pro celou síť O Jedinečné ID podsítě pro každý fyzický segment O Rozsah hostitelských ID pro každou podsíť
Seznámení s mocninami čísla 2
Při tvorbě podsítí IP je důležíté rozumět mocninám čísla 2 a pamatovat si je. U mocnin čisla 2 platí obecné pravidlo: vidíte-Ii číslo, které má vpravo nahoře zapsánu menší číslici (označuje se jako exponent), znamená to, že je potřeba dané číslo vynásobít sebou samým tolikrát, jak určuje příslušný exponent. Například 23 je 2 x 2 x 2, což se rovná 8. Následuje seznam mocnin čísla 2, který byste si měli osvojit:
21 = 2 22 = 4 23 = 8 24 = 16 25 = 32 26 = 64 27 = 128 28 = 256 29 = 512 210 = 1 024 211 = 2 048 212 = 4 096 213 = 8 192 214 = 16 384
Než se začnete stresovat tím, že sí musíte pamatovat tolik hodnot, uvědomte si, že je sice výhodné tato čísla znát, ale není to absolutně nutné. uveďme si malý trik pro práci s mocninami dvojky: Každá následná mocnina je dvojnásobkem předchozí. Pokud například potřebujete zjistit hodnotu 29, stačí pouze znát, že 28 = 2 56. Proč? Když totiž zdvojnásobíte 2 na osmou ( 2 56), dostanete 29 (neboli 512). Jestliže potřebujete hodnotu 210, stačí, když vyjdete od čísla 28 = 2 56, které vynásobíte dvěma dvakrát. Můžete také postupovat opačným směrem. Potřebujete-Ii získat například hodnotu 26, prostě dvakrát vydělíte 256 dvěma: poprVé, abyste dostali 27, a podruhé, abyste dosáhli požadovanou hodnotu 26.
Masky podsítí
Aby mohlo schéma adres podsítí fungovat, musí každý počítač v síti "vědět", které části hostitelské adresy se budou používat ve významu adresy podsítě. Toho můžete dosáhnout tak, že každému počítači přiřadíte masku podsítě (subnet mask). Maska podsítě je 32bitová hodnota, která umožňuje příjemci paketů IP rozlišit v IP adrese část se síťovým ID od části s ID hostitele. Správce sítě vytváří 32bitovou masku podsítě, která se skládá z binárních jedniček a nul. Hodnoty 1 v masce podsítě reprezentují pozice, které se týkají síťových adres nebo adres podsítí.
Některé sítě se obejdou bez podsítí a používají tedy výchozí masku podsítě. V zásadě to znamená totéž jako prohlásit, že síť nemá adresu podsítě. Tabulka 3. 1 znázorňuje výchozí masky podsítí pro sítě třídy A, BaC. Tyto výchozí masky nelze změnit. Jinými slovy, nemůžete nastavit masku podsítě třídy B na 255.0.0.0. Pokud se o to pokusíte, hostitel bude adresu považovat za neplatnou a obvykle ji vůbec neumožní zadat. V případě sítě třídy A není možné změnit první bajt v masce podsítě. Její hodnota musí být minimálně 255.0.0.0. Podobně není dovoleno nastavit hodnotu 255.255.255.255, protože obsahuje samé jedničky a jedná se tedy o všesměrovou adresu. Maska adresy třídy B musí začínat hodnotami 255.255.0.0 a na začátku masky třídy C musí být uvedeno 255.255.255.0.
