Aplikace
2
Jaké aplikace jsou nejčastější Vzdálené soubory FTP (SCP,SFTP,FTPS), NFS, SMB WWW HTTP, HTTPS Vzdálené připojení telnet (rlogin, rsh), SSH Elektronická pošta SMTP 3
a další DNS (LDAP) BootP, DHCP získání síťových nastavení RPC a navazující (CORBA) vzdálené volání procedur SNMP vzdálená správa síťových prvků konference, news IP telefonie (VoIP Voice Over IP) Skype, portály, Blog 4
5
DNS...proč? k jednoznačné identifikaci uzlů a pro fungování přenosových mechanismů stačí IP adresy ale jsou těžko zapamatovatelné v některých speciálních situacích a pro některé účely nepostačují aliasy dynamicky přidělované IP adresy pro některé účely nejsou vhodné když je potřeba "oslovit" poskytovatele určité služby, ne konkrétní uzel pro flexibilní doručování elektronické pošty ("na doménu").. když hrozí přečíslování nevypovídají nic o povaze/určení/umístění uzlu 147.32.100.13 vs. Fdinfo.fd.cvut.cz DNS je řešení, které umožňuje používat symbolická jména místo číselných adres DNS = Domain Name System zahrnuje: pravidla pro tvorbu jmen a fungování celého systému založená na principu domén databázi symbolických jmen a jim odpovídajícíčíselných adres dnes i dalších údajů převodní mechanismy.. pro převod mezi symbolickými a doménovými jmény 6
Koncepce DNS musí to být distribuované řešení distribuované co do umístění dat objemy dat budou velké data by měla být uchovávána co nejblíže místu kde vznikají a kde "žijí" (mění se) distribuované co do pravomocí aby různé subjekty mohly přijímat určitá rozhodnutí a vykonávat úkony bez nutnosti koordinace s jinými subjekty aby bylo možné přidělovat nová jména bez nutnosti ptát se, zda jsou již použita jinde. distribuované co do fungování kvůli spolehlivosti i kvůli vytížení to nesmí mít jeden centrální prvek dotazy týkající se určitých dat se budou zodpovídat tam, kde se tato data nachází musí to fungovat efektivně týká se to hlavně převodních mechanismů mezi symbolickými jmény a číselnými IP adresami může to využívat "princip lokality" dotazy nejčastěji směřují na "místní" uzly, nebo na stále stejná jména "cizích" uzlů má smysl optimalizovat fungování pomocí vyrovnávacích pamětí (cache) 7
Plochý vs. hierarchický prostor jmen Plochý jmenný prostor všechna jména jsou "jednorozměrná" např. ALPHA, Sun, PC1 je omezený počet "smysluplných" jmen jména se přidělují z jedné "množiny" musí to být centrálně koordinováno ten kdo chce nějaké jméno se musí ptát zda ještě nebylo použito nevýhody: je to nepružné, neškálovatelné, organizačně náročné Hierarchický jmenný prostor existuje hierarchie (strom) dílčích jmenných prostorů, těmto dílčím jmenným prostorům se říká domény "výsledná" jména budou mít více složek organizačně to je zařízeno tak, aby (dílčí, složková..) jména v rámci domén bylo možné "čerpat" nezávisle na ostatních doménách tomu musí odpovídat i "sestavování" dílčích složek jmen do větších celků 8
Symbolická doménová jména cz cz obecně nemusí být uvedeny všechny složky (všechna dílčí jména) cvut fd fd www www.fd.cvut.cz k107a-01 ucebny K105-14 www www jednotlivá dílčí jména se zapisují za sebou a oddělují tečkami pořadí: nejvíce vlevo je "nejnižší" jméno ve smyslu hierarchie domén 9
Syntaxe doménových jmen každá složka (dílčí jméno, label) smí mít nejvýše 63 znaků mohou se používat pouze písmena, číslice a pomlčka ne háčky a čárky!! pomlčka nesmí být na začátku ani na konci velká a malá písmena se nerozlišují pozor, neplatí pro celé URL!! celé doménové jméno musí mít max. 255 znaků v praxi lze používat i doménová jména, která nejsou plně kvalifikovaná chybí jim něco "zprava" může se doplnit automaticky např. mailto:xjmeno@fdinfo se doplní na xjmeno@fdinfo.fd.cvut.cz ale jen v "působnosti" domény fd.cvut.cz přesný mechanismus "doplňování" je v kompetenci místní sítě nemusí být přesně známo jak to dopadne 10
Princip delegace pravomoci v každé doméně mohli přidělit jméno www, aniž se museli kohokoli ptát!!!! cz cz cvut fd fd Pravidlo: v jedné doméně nesmí být stejné jméno použito dvakrát!!! ucebny fdinfo dc dc www www www www.fd.cvut.cz www.fdinfo.fd.cvut.cz www.dc.fd.cvut.cz 11
Co je doména? prvek v rámci hierarchického členění jmenného prostoru není apriorně stanovena ani hloubka, ani košatost hierarchie (stromu)!! "okruh působnosti" někoho, kdo má právo přidělovat symbolická jména čemu má doména odpovídat? organizačnímu členění? teritoriálnímu členění? jinému členění? NENÍ TO PŘEDEPSÁNO!!! je to ponecháno na uvážení správce nadřazené domény výjimka: je předepsán charakter domén nejvyšší úrovně tzv. TLD domén (Top Level Domén) existují cctld (country code TLD), odpovídající státním útvarům, tvar dle normy ISO-3166.cz pro ČR.sk pro Slovesko.us pro USA.ru pro Rusko existují gtld (generic TLD), vyjadřující charakter subjektu.edu pro školské instituce přiděluje IANA/ICANN.com pro komerční organizace.int,.net,.gov,.mil,.org,.arpa 12
Některé jmenné domény (DNS) doména COM EDU GOV MIL NET ORG ARPA INT CZ AT DE UK Význam Komerční organizace USA Vzdělávací organizace USA Vládní instituce USA Armádní skupiny USA Hlavní správní armádní centra USA Ostatní organizace USA Dočasná doména ARPANETU Mezinárodní organizace Česká republika Rakousko Německo Velká Britanie www.iana.org www.nic.cz 13
Jak má být doména "velká"? není apriorně stanoveno to co komu vyhovuje, co do velikosti i logice členění "příliš velká" doména není smysluplné, aby se přímo v této doméně přidělovala jména uzlům spadajícím do domény např. z organizačních důvodů řeší se "delegováním pravomoci" (parcelací "okruhu působnosti") vytváří se dceřinné domény "vhodně velká" doména s takovým počtem uzlů, aby se nevyčerpala smysluplná/požadovaná jména netýká se to až tak správy domény!! příklady: pro malou organizaci bývá "vhodně velká" doména druhé úrovně pro velkou organizaci je vhodnější víceúrovňové členění např. (cvut.cz) 14
Zóny zóna oblast tvořená skupinou domén, nad kterou má někdo konkrétní (jeden subjekt) autoritu zóny se "zvětšují" vytvářením dceřinných domén zóny se "zmenšují" delegováním pravomoci (autority) nad dceřinnými doménami dohází k "vykousnutí" celých podstromů domén ze stávající zóny a ke vzniku nové zóny zone file všechny údaje týkající se domén nad kterými má někdo autoritu (týkající se jedné zóny) jsou uchovávány na jednom místě v jedné databázi, resp. jednom souboru, tzv. zone file tam kde "žijí" a kde s nimi správce pracuje 15
Struktura name serverů dc dc cz cz cvut cvut fd fd root cz cz fd fd dc dc horska ucebny horska ucebny struktura name serverů logicky odpovídá struktuře domén každá doména má svůj name server existuje tzv. kořenový (root) name server, který "zná" name servery všech TLD (domén nejvyšší úrovně) fyzicky jsou name servery členěny jinak 1 zóna má 1 name server kvůli dostupnosti jsou name servery nejméně zdvojeny name server doména 16
Princip překladu tazatel se nejprve ptá kořenového name serveru, jehož adresa je všeobecně známa tazatel ptá se na IP adresu uzlu k105-05.ucebny.fd.cvut.cz 5 4 až se dostane k takovému name serveru, který mu dokáže odpovědět 3 147.32.103.35 2 1 cz cz fd fd 5 ucebny ucebny dc dc uzel K105-05.ucebny.fd.cvut.cz 2 root cz cz cvut cvut 4 fd fd dc dc 3 1 horska horska tazatel je postupně odkazován na další name servery 17
Primární a sekundární name servery z pohledu tazatelů jsou ekvivalentní primární name server zone file je na místním disku sekundární name server získává data z primárního name serveru každá doména musí mít (hlavní) name server, který je tzv. primární primární name server má přímo k dispozici relevantní data o doméně svůj zone file získává z místního disku kromě toho by měla mít nejméně jeden (záložní) name server, tzv. sekundární sekundární name server by měl být umístěn v jiné síti nejčastěji u (nadřazeného) providera sekundární name server "seřizuje svůj obsah" sám a automaticky podle obsahu primárního name serveru vyžádá si tzv. zone transfer 18
DNS servery a resolvery aplikace data resolver resolver cache name server dotazy odpovědi dotazy odpovědi dotazy odpovědi DNS má architekturu klient/server name server odpovídá na dotazy plní roli serveru resolver pokládá dotazy name serverům plní roli klienta na uzlu který plní roli name serveru musí být implementovány obě složky i name server se ptá jiných name serverů, k tomu potřebuje resolver na ostatních uzlech stačí jen resolver 19
Optimalizace fungování DNS replikace name servery domén jsou replikovány jako primární a alespoň jeden sekundární v praxi bývá i více záložních name serverů replikovány jsou i kořenové name servery všechny jsou primární slouží i k rozložení zátěže cacheování odpovědi autoritativních name serverů si ostatní servery ukládají do svých cache pamětí a pak je používají pro přímou (neautoritativní) odpověď) cacheování přináší největší optimalizaci!! forwarding name server přijímá rekurzivní dotazy, ale neřeší je, nýbrž pouze předává (forwarduje) jinému name serveru obvykle kvůli tomu že je připojen po pomalé lince, dotazy předává lépe připojenému serveru 20
RR Resource Records (informace v DNS - příklady) Typ anglický název význam pole RDATA A A host address IP adresa uzlu NS Authoritative name server doménové jméno name serveru, který je autoritativní pro danou doménu CNAME Cannonical name kanonické synonymum k NAME HINFO Host INFO popis HW s SW MX Mail exchange kam má být doručována el. pošta pro doménu AAA IPv6 address 128-bitová adresa dle IP verze 6 MX. Preference a jméno mail-serveru 21
DNS protokol DNS klient a server spolu komunikují pomocí jednoduchého aplikačního protokolu protokolu DNS pro transport je nejčastěji využíván protokol UDP ale může být použit i TCP pro dotazy na překlad jména je preferován protokol UDP DNS server "poslouchá" na portu 53 přes TCP i UDP, UDP jen paket délky 512B DNS protokol používá stejný formát paketu (DNS QUERY) pro dotaz i odpověď HEADER QUESTION ANSWER AUTHORITY ADDITIONAL 22
nslookup - příklady > www.seznam.cz Server: dhcp.fd.cvut.cz Address: 147.32.103.3 Neautorizovaná odpověď: N zev: www.seznam.cz Addresses: 212.80.76.18, 212.80.76.3 > www.fd.cvut.cz Server: dhcp.fd.cvut.cz Address: 147.32.103.3 Název: fd.cvut.cz Address: 147.32.100.7 Aliases: www.fd.cvut.cz > 147.32.100.13 Server: dhcp.fd.cvut.cz Address: 147.32.103.3 Název: fdinfo.fd.cvut.cz Address: 147.32.100.13a > server 147.32.1.20 Výchozí server: ns.cvut.cz Address: 147.32.1.20 > www.seznam.cz Server: ns.cvut.cz Address: 147.32.1.20 Neautorizovaná odpověď: Název: www.seznam.cz Addresses: 212.80.76.3, 212.80.76.18 23
Poznámka: Microsoft vytvořil vlastní systém překladu tzv. NETBIOS jmen na IP adresy: WINS (Windows Intranet Name Server) pracuje pouze na lokálních sítích 24
25
LDAP Lightweight Directory Access Protocol standardizovaný protokol pro přístup k adresářovým službám ukládání/čtení dat na/z adresářový server vhodný pro správu uživatelů v adresářích založen na protokolu X.500 lighweight - odlehčená verze X.500 architektura klient/server 26
LDAP používá devět základních operací dotazovací (search, compare) změnové (add, delete, modify) autentizační a řídicí strukturu záznamů (atributy, datové typy) definuje informační model objektový princip - třídy, dědičnost způsob odkazu na data definuje jmenný model pomocí cesty 27
LDAP autentizace - ověření identity uživatele (uživatelského jména a hesla) šifrovaně - SSL kanál, digitální certifikáty autorizace zajištění přístupu k oprávněným operacím volně šířitelná implementace: OpenLDAP 28
29
Vzdálené přihlašování (remote login) cílem je možnost "používat aplikace na dálku" uživatel je na místním počítači, ale aplikace běží na vzdáleném počítači týká se aplikací fungujících na bázi výpočetního modelu "host/terminál" typicky: starších aplikací fungujících ve znakovém režimu aplikací které ani nemusí počítat s tím že fungují v prostředí sítě podmínka: aplikace musí podporovat tzv. terminálové relace musí své výstupy posílat "skrz OS" na terminál a své vstupy přijímat "skrz OS" z terminálu takto se děje např. v prostředí UNIXu nesmí "jít napevno" do videoram a klávesnicového bufferu jako v MS DOS také operační systém musí podporovat terminálové relace 30
Představa výpočetního modelu host/terminál aplikace aplikace terminál operační systém procesor paměť soubory programy vstupy výstupy terminál hostitelský počítač 31
Představa terminálové relace aplikace hostitelský počítač počítačová síť hostitelský počítač (lokální) (lokální) terminálová terminálová relace vzdálená vzdálená terminálová terminálová relace relace relace A B T A1 T A2 T A3 T B1 T B2 T B3 terminál terminál terminál terminál terminál terminál 32
Vzdálené přihlašování v TCP/IP TELNET hlavní prostředek pro realizaci vzdáleného přihlašování v rámci TCP/IP, snaží se být maximálně univerzální snaží se nevázat na konkrétní systémové prostředí (nebýt závislý na operačním systému) podporuje terminálové relace mezi různými platformami rlogin na straně uživatele počítá i s terminálovou emulací... nabízí jen jednoduché služby, a nikoli např. možnost automatického přihlašování apod. podporuje pouze znakové uživatelské rozhraní vzniknul v prostředí BSD Unixu je vázán na prostředí Unixu (BSD Unixu), a podporuje tzv. trusted hosts dokáže si některé informace vytáhnout ze svého okolí (např. jméno uživatele a jeho heslo)...... a pak je využít, např. pro automatické přihlášení uživatele na vzdáleném počítači WinFrame, MS Terminal Server, Remote Desktop nové řešení, podporuje grafiku 33
Terminálová emulace vs. TELNET aplikace TELNET server IP síť emulátor terminálu (lokální) terminálová relace A protokol TELNET TELNET klient hostitelský počítač vzdálená vzdálená terminálová terminálová relace T A1 T A2 T relace A3 T 1 T B3 terminál terminál terminál počítač, emulující jednoúčelový terminál 34
TELNET základní problém každý terminál je jiný liší se: v rozsahu schopností v parametrech v režimu fungování znakový celoobrazovkový formulářový s odlišnostmi terminálů se lze vyrovnat přizpůsobením stylem každý s každým... nebo přes společný mezistupeň, s přizpůsobením typu každý s jedním a jeden s každým v případě TELNETu jde hlavně o tvar, v jakém se mají data přenášet TCP/IP sítí TELNET zavádí jeden, pevně daný mezistupeň: virtuální terminál NVT (Network Virtual Terminal) NVT má vždy stejné vlastnosti reálné terminály se mu přizpůsobují (jsou mapovány z/do NVT) NVT především definuje formát skutečně přenášených dat 35
TELNET - představa platforma 1 platforma 2 TELNET klient TELNET server aplikace zde zde je je používán používán specifický specifický formát formát platformy, platformy, na na které které "stojí" "stojí" klient klient zde jsou data přenášena ve formátu NVT zde zde je je používán používán specifický specifický formát formát platformy, platformy, na na které které "stojí" "stojí" klient klient 36
telnet - příkaz Vítá vás program Microsoft Telnet Client. Řídicí znak je CTRL+) Microsoft Telnet> help Příkazy mohou být zadány ve formě zkratek. Podporované příkazy: c - close Uzavře aktuální připojení. d - display Zobrazí pracovní parametry. o - open hostitel [port] Otevře připojení k hostiteli (výchozí port 23). q - quit Ukončí program telnet. set - set Nastaví možnosti (pro seznam možností zadejte 'set?' ). sen - send Odešle řetězce serveru. st - status Vytiskne stavové informace. u - unset Zruší nastavení možností. (pro seznam možností zadejte 'unset?')?/h - help Zobrazí nápovědu. 37
příklad Spouštění z příkazové řádky C:>telnet připojení ke vzdálenému počítači Připojit Vzdálený systém Vítá vás program Microsoft Telnet Client. Řídicí znak je CTRL+) Microsoft Telnet> o ( do ) anezka.vc.cvut.cz do políčka hostitel vypisujeme jméno vzdáleného počítače anezka.vc.cvut.cz terminál = volba typu terminálu (z historických důvodů) - nejčastěji VT100; typ terminálu určuje zasílání a implementaci řídících znaků (klíčových kláves) 38
Telnet s ochranou hesla standardní telnet (i ftp) nepoužívá šifrování hesla při přenosu heslo putuje v paketu po síti nešifrované možný odchyt byly doplněny mechanismy ochrany hesla (např. OTP one time password) telnet ve Win95/NT neumí ochranu hesla Některé telnetové aplikace se zabudovanou ochranou ArcTel k dispozici na novellském serveru CDROM VC ČVUT User: aspi Pass: (není, anonymní uživatel) SemTel 39
40
Vzdálené přihlašování vs. práce se soubory cíl: chci pracovat se souborem, který se nachází na jiném počítači přesněji: chci zpracovávat obsah vzdáleného souboru, pomocí aplikace, která běží na mém uzlu!!!... účelem není dostat se do role vzdáleného terminálu jiného uzlu!!! pak by byl soubor zpracováván aplikací běžící na vzdáleném počítači 41
Přenos vs. sdílení souborů přenos souborů: jde o netransparentní řešení uživatel/aplikace si uvědomuje, že soubor se nachází na vzdáleném počítači uživatel/aplikace musí explicitně znát umístění souboru na vzdáleném počítači uživatel/aplikace musí explicitně podnikat určité kroky ke zpřístupnění souboru typicky: vzdálený soubor se celý přenese na "místní" počítač a zde se zpracuje označuje se jako "file transfer" v rámci TCP/IP řeší protokol FTP (File Transfer Protocol) sdílení souborů: jde o transparentní řešení uživatel/aplikace si neuvědomuje, že soubor se nachází na vzdáleném počítači uživatel/aplikace nemusí explicitně znát umístění souboru na vzdáleném počítači uživatel/aplikace nemusí podnikat žádné explicitní kroky ke zpřístupnění souboru typicky: vzdálený soubor se "chová" ("tváří") jako místní soubor, a také se s ním jako s místním pracuje označuje se jako "file sharing" v rámci TCP/IP řeší protokol NFS (Network File System) 42
Problémy přenosu a sdílení protokoly pro přenos a sdílení se musí vyrovnat s mnoha úskalími, typu: rozdílnost v pohledu na soubory, jejich jména, přípony... vlastnictví souborů, jejich atributy... souborů problém je i se zajištěním vícenásobného přístupu k souborům lze použít obecné techniky typu: uzamykání celých souborůči jejich částí replikace ponechat vše na uživateli... řešení je snazší u netransparentního přístupu (file transfer) kde lze požadovat po uživateli, aby rozdílnosti vyřešil vlastním rozhodnutím například aby zadal atributy místního souboru, do kterého má být přenesen (zkopírován) obsah vzdáleného souboru 43
Implementace protokolu FTP požadavek na přenos přenos souboru klient uživatelské rozhraní interpret protokolu řídící spojení interpret protokolu systém souborů přenosový proces datové spojení přenosový proces systém souborů využívají se transportní služby protokolu TCP 44
Datové a řídící spojení oddělení datového a řídícího spojení je výhodné: kvůli zajištění transparence kvůli možnosti přerušit probíhající přenos kvůli možnosti signalizovat konec souboru uzavření datového spojení signalizuje konec souboru lze přenášet soubory které během přenosu narůstají definice FTP (RFC) požaduje aby datové spojení bylo 1 pro všechny přenášené soubory v praxi se pro každý přenášený soubor používá 1 (samostatné, nové) datové spojení řídící spojení "přežívá" po celou dobu relace, datová spojení se mění řídící spojení iniciuje (navazuje) klient ze svého (dynamicky přiděleného) portu na port 21 ruší se až explicitním příkazem datové spojení iniciuje (navazuje) server ze svého portu 20 na port klienta, ze kterého bylo navázáno řídící spojení passive-mode: datové spojení nenavazuje server, ale klient kvůli firewallům, které neakceptují žádosti o otevření spojení vedoucí dovnitř na "náhodný" 45 port
Řídící jazyk FTP FTP definuje vlastní řídící jazyk příkazy řídícího jazyka jsou přenášeny řídícím spojením řídící příkazy mají textovou povahu, a jsou přenášeny ve stejném tvaru, jakou předpokládá protokol TELNET resp. pro jejich přenos mohou být využívány již existující implementace TELNETu příkazy lze rozdělit na: řízení přístupu (access control commands) - např. pro zadání uživatelského jména a hesla nastavení parametrů přístupu (transfer parameter commands) - např. pro změnu implicitních čísel portů, pro nastavení režimu přenosu apod. výkonné příkazy (FTP service commands) - pro vlastní přenos souborů, rušení, přejmenovávání atd., pro přechody mezi adresáři apod. 46
C:\>ftp ftp>? Příkazy lze zkracovat. Příkazy: FTP řádkový klient! delete literal prompt send? debug ls put status append dir mdelete pwd trace ascii disconnect mdir quit type bell get mget quote user binary glob mkdir recv verbose bye hash mls remotehelp cd help mput rename close lcd open rmdir ftp> 47
ftp grafický klient - 1 důležitá políčka k vyplnění: host address adresa (jméno) vzdáleného počítače user ID - uživatelské jméno password - heslo Volba přihlášení (Login Type): normal s uživatelským jménem anonymous anonymní přihlášení dual - anonymní s heslem 48
ftp grafický klient - 2 49
SCP a SFTP Protokol SCP Secure Copy Protocol slouží k bezpečnému přenosu souborů mezi dvěma počítači (jako FTP, ale k utajení obsahu využívá SSH) oproti FTP umí přenášet informace o souboru (oprávnění, čas modifikace, apod.) vychází z protokolu rcp z Unixu dnes je nahrazován novější variantou SFTP 50
Transparetnířešení (Sdílení souborů) protokol NFS (Network File System) UNIX protokol SMB (Session Message Block) protokol pro sdílení souborů a tiskáren využíván především v MS Windows implementace je i součástí Linuxu a nazývá se Samba 51
52
DHCP Dynamické přidělování adresřeší aplikační protokol DHCP. Protokol DHCP vychází ze zkušeností a částečně v sobě zahrnuje i podporu starších protokolů z této oblasti, tj. protokolů RARP, DRARP BOOTP. Blíže viz RFC- 1531. V protokolu DHCP žádá klient DHCP-server o přidělení IP-adresy (případně o další služby). DHCP-server může být realizován jako proces na počítači s operačním systémem UNIX, Windows NT atp. Nebo DHCP-server může být realizován i jako součást směrovače. Zatímco přidělování IP-adres na LAN je v současné době doménou protokolu DHCP, pro přidělování IP-adres počítačům za komutovanou linkou (např. zákazníkům poskytovatele Internetu) se zpravidla přidělují IP-adresy pomocí protokolu PPP. 53
option time-servers 147.32.103.3; option domain-name "fd.cvut.cz"; option domain-name-servers 147.32.103.3, 147.32.100.3, 147.32.1.20; option subnet-mask 255.255.252.0; option slp-directory-agent true 147.32.101.56; option routers 147.32.100.1; ddns-update-style none; ###subnet 147.32.100.0 Záznamy DHCP netmask 255.255.252.0 { option domain-name "fd.cvut.cz"; option domain-nameservers 147.32.103.3, 147.32.100.3, 147.32.1.20; option time-servers 147.32.103.3; option routers 147.32.100.1; option subnet-mask 255.255.252.0; range dynamic-bootp 147.32.102.150 147.32.102.254; default-lease-time 21600; max-lease-time 43200;##cela sit# group { option domain-name-servers 147.32.103.3; ddnsdomainname "ucebny.fd.cvut.cz"; option time-servers 147.32.103.3; option subnet-mask 255.255.252.0; option routers 147.32.100.1; use-hostdecl-names on; deny unknown-clients; } host K207b { hardware ethernet 00:04:76:e3:dc:ed; fixed-address 147.32.100.139; } host HP9500.fd.cvut.cz. { hardware ethernet 00:01:e6:ad:dd:cc; fixed-address 147.32.103.249; }##K107C#group { host K107C-02 { hardware ethernet 00:10:dc:cd:8b:4c; fixed-address 147.32.103.142; } host K107C-03 { hardware ethernet 00:10:dc:cd:c6:94; fixed-address 147.32.103.143; } deny unknown-clients; host K107C-04 { hardware ethernet 00:10:dc:cd:c9:57; fixed-address 147.32.103.144; } host K107C-05 { hardware ethernet 00:10:dc:cd:c9:6a; fixed-address 147.32.103.145; } host 54 K107C-06 { hardware ethernet 00:10:dc:cd:c6:8c;
55
Co je elektronická pošta? je to služba! může být realizována různými způsoby, v různém prostředí existují různé "koncepce" elektronické pošty např. Mail602, ccmail, MS Mail, X.400, SMTP,.. liší se formátem zpráv, adresami, přenosovými mechanismy,... obecně jsou vzájemně nekompatibilní pro možnost vzájemné spolupráce vyžadují existenci poštovních bran v Internetu se používá tzv. SMTP-pošta založená na jedné konkrétní koncepci (na bázi protokolu SMTP a RFC 822) stejná koncepce elektronické pošty může být použita i jinde mimo Internet není proprietární není "vlastněná" žádnou firmou, vychází z plně otevřených standardů 56
Elektronická pošta jako služba je rychlá časy doručování se měří na minuty a sekundy je laciná i když záleží na konkrétním způsobu připojení je pohodlná mnoho úkonů lze zautomatizovat, např. třídění došlých zpráv, příprava odpovědí je efektivní může být provázána s dalšími aplikacemi umožňuje snadné hromadné rozesílání funguje off-line způsobem nevyžaduje současnou aktivitu komunikujících stran ve stejném čase odesilatel může psát své zprávy tehdy, když se to hodí jemu příjemce může zpracovávat došlou poštu tehdy, kdy se to zase hodí jemu dnes je elektronická pošta univerzálním přenosovým mechanismem ke zprávám lze přidávat prakticky libovolné přílohy 57
Filosofie SMTP pošty začíná skromně, postupně se obohacuje původně vznikla jako velmi jednoduchá služba jako elektronická obdoba "office memo" další vlastnosti a schopnosti se přidávaly teprve postupně, po ověření jejich účelnosti a funkčnosti vývoj je "inkrementální", není nutné vyřazovat dřívější vybavení byť nepodporuje nové funkce původně: pouze krátké texty v čistém ASCII nyní: možnost formátování textu, vkládání obrázků atd. možnost přenosu netextových příloh podpora národních abeced (háčky&čárky).. 58
Architektura SMTP pošty vychází z modelu klient/server poštovní server (mail server): v terminologii ISO/OSI: MTA, Message Transfer Agent zajišťuje transport zpráv shromažďuje zprávy pro ty účastníky, kteří nejsou momentálně dostupní poštovní klient v terminologii ISO/OSI: UA, User Agent umožňuje číst, psát a jinak zpracovávat jednotlivé zprávy vytváří uživatelské rozhraní Standardy el. pošty musí pokrývat přenos zpráv, download formát zpráv, formát adres, přílohy, přenos zpráv: definuje protokol SMTP (Simple Mail Transfer Protocol) formát zpráv a adres definuje doporučení RFC822 download stahování zpráv ze schránky na poštovním serveru definuje protokol POP3, IMAP. rozšíření definuje standard MIME 59
60
tři základní pilíře HTML (Hyper Text Markup Language) jazyk sloužící k popisu toho co WWW stránka obsahuje URL (Uniform Resource Locator) dnes URI (Uniform Resource Identifier) HTTP (HyperText Transfer Protokol) zajišťující vlastní přenos stránek 61
obecné schéma URL <<schéma>>://<<uživatel>>:<<heslo>>@<<počítač>>:<<port>>/<<cesta>>; <<parametry>> <<schéma>> určuje typ zdroje na který adresa ukazuje. Pro orientaci uveďme nejpoužívanější schémata: file soubor na lokálním disku ftp soubor přístupný přes FTP gopher Gopher protokol http webovské stránky mailto adresa elektronické pošty news diskusní skupiny nntp diskusní skupina na určitém serveru telnet terminálový přístup ke vzdálenému počítači wais Wide Area Information Server Některé z těchto položek jsou nepovinné 62
Absolutní vs. Relativní URL URL, která obsahují schéma, adresu počítače a případné určení cesty k dokumentu, se nazývají absolutní URL. Relativní URL obsahuje pouzečást informace o umístění zdroje. Pro získání absolutního URL je třeba získatčást informace z kontextu. Kontextem bývá nejčastěji URL dokumentu, ve kterém se relativní URL vyskytuje Příklad: Máme základní URL http://www.fd.cvut.cz/studenti/xuzivatel/index.htm Relativní URL Absolutní URL Pokus.htm http://www.fd.cvut.cz/studenti/xborka/pokus.htm Prace/uloha1.htm http://www.fd.cvut.cz/studenti/xborka/ Prace/uloha1.htm../semestralka.htm http://www.fd.cvut.cz/studenti/semestralka.htm../.. http://www.fd.cvut.cz/ 63
64
SNMP protokol pro vzdálenou správu a ovládání síťových prvků pomocí protokolu je možné nastavovat síťové komponenty (např. vypínat porty), číst statistická data (počet prošlých TCP paketů přes port apod.) a různé další informace (směrovací tabulky) softwarové aplikace SNMP agent server na sledovaném zařízení SNMP manažer sbírá informace z agenta 65
množina objektů, které je možné spravovat, je definována pomocí MIB (Management Information Base) MIB je hierarchická, má stromovou strukturu každému uzlu je přiřazeno číslo objekty se definují a identifikují tečkovou notací pomocí jmen, resp. čísel 66
Část stromové struktury 67
Příklad: proměnná ipinrecieves počet přijatých datagramů iso.org.dod.internet.mgmt.mib-2.ip.ipinreceives 1.3.6.1.2.1.4.3.0 instance v SNMP protokolu jsou požadavky na to, co chceme spravovat, zapsány číselnou reprezentací uživatel softwarů může požadavek zadat pomocí textu 68
Typy SNMP objektů skalární hodnoty tabulky Příklady skalárních typů: Integer Counter čítač s přetečením (např. čítač paketů) Gauge čítač se stropem TimeTicks IpAddress OCTET STRING OBJECT IDENTIFIER 69
Tabulky obsahem jsou skutečné tabulky, např. směrovací tabulky ze směrovačů přístup k obsahu se děje pomocí klíčových hodnot jednotlivých řádků a čísla sloupců klíčové hodnoty zpravidla neznám pak je lepší využívat funkce protokolu getnext 70
sloupec klíč 71
SNMP je vylepšeno standardem RMON (Remote MONitoring) SNMP neumí historii údajů, poskytuje pouze určitý přehled -> vznik RMON komplexní pohled na správu (statistika) RMON agent je inteligentní, je možné jej konfigurovat např. ke sběru informací za čas existuje balík funkcí v jazyku JAVA 72
Windows - SNMPUtil 73