Jaké aplikace jsou nejčastější

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 • DNS je řešení, které umožňuje fungování přenosových mechanismů používat symbolická jména stačí IP adresy místo číselných adres – 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 = 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 obecně nemusí být uvedeny všechny složky (všechna dílčí jména)

cz cz

cvut cvut

www fd fd

www.fd.cvut.cz www

ucebny ucebny

k107A-01 K105-14

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, • v praxi lze používat i label) smí mít nejvýše 63 doménová jména, která nejsou znaků plně kvalifikovaná – chybí jim něco "zprava" • mohou se používat pouze – může se doplnit automaticky písmena, číslice a • např. mailto:xjmeno@fdinfo se 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!!

doplní na [email protected]

– 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

• celé doménové jméno musí mít max. 255 znaků 10

Princip delegace pravomoci cz cz v každé doméně mohli přidělit jméno www, aniž se museli kohokoli ptát !!!!

cvut cvut

Pravidlo: v jedné doméně nesmí být stejné jméno použito dvakrát !!!

fd fd

www ucebny ucebny fdinfo fdinfo

www

dc dc

www

www.fd.cvut.cz

11 www.fdinfo.fd.cvut.cz

www.dc.fd.cvut.cz

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

přiděluje IANA/ICANN

– existují gTLD (generic TLD), vyjadřující charakter subjektu • .edu pro školské instituce • .com pro komerční organizace • .int, .net, .gov, .mil, .org, .arpa

12

Některé jmenné domény (DNS)

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

doména COM EDU GOV MIL NET ORG ARPA INT

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

• zone file

– 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

– 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ů root root cz cz cz cz cvut cvut cvut cvut fd fd fd fd dc horska dc horska ucebny ucebny dc horska dc horska ucebny 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

root root 2 cz cz

až se dostane k takovému name serveru, který mu dokáže odpovědět

tazatel 5

4

3

2 1

3

cvut cvut cvut cvut 4

147.32.103.35

ptá se na IP adresu uzlu k105-05.ucebny.fd.cvut.cz

cz cz

1 tazatel je postupně odkazován na další name servery

fd fd fd fd

5 horska ucebny dc horska ucebny dc ucebny horska ucebny dc dc horska

uzel K105-05.ucebny.fd.cvut.cz

17

Primární a sekundární name servery • každá doména musí mít (hlavní) name server, který je tzv. primární z pohledu tazatelů jsou ekvivalentní

primární name server

• svůj zone file získává z místního disku

• kromě toho by měla mít sekundární nejméně jeden (záložní) name server, tzv. sekundární name server získává data z primárního name serveru

zone file je na místním disku

– primární name server má přímo k dispozici relevantní data o doméně

– 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 18 • vyžádá si tzv. zone transfer

DNS servery a resolvery aplikace

dotazy

resolver odpovědi

• DNS má architekturu klient/server – name server odpovídá na dotazy • plní roli serveru

– resolver pokládá dotazy name serverům

dotazy

resolver odpovědi

cache dotazy

data

name server odpovědi

• 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

> server 147.32.1.20 • • •

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

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ěď:

• • •

> 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

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

vstupy procesor paměť soubory programy

terminál

výstupy

hostitelský počítač

31

Představa terminálové relace počítačová síť

aplikace

hostitelský počítač

hostitelský počítač

(lokální) (lokální) terminálová terminálová relace relace

vzdálená vzdálená terminálová terminálová relace relace

A

B

TA1

TA2

TA3

TB1

TB2

TB3

terminál

terminál

terminál

terminál

terminál

terminál

32

• TELNET

Vzdálené přihlašování v TCP/IP

• rlogin – “hlavní” prostředek pro realizaci vzdáleného – vzniknul v prostředí BSD Unixu přihlašování v rámci TCP/IP, – je vázán na prostředí Unixu snaží se být maximálně (BSD Unixu), a podporuje tzv. univerzální “trusted hosts” • 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

– 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í

• 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

IP síť emulátor emulátorterminálu terminálu

TELNET server

(lokální) terminálová relace

protok

ol TE LNET

TELNET klient

A hostitelský počítač

TA1

TA2

TA3

terminál

terminál

terminál

vzdálená vzdálená terminálová terminálová relace relace

T1

počítač, počítač,emulující emulující jednoúčelový jednoúčelovýterminál terminál

TB3

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 TELNET klient

zde zdejejepoužíván používán specifický specifickýformát formát platformy, na platformy, nakteré které "stojí" "stojí"klient klient

zde jsou data přenášena ve formátu NVT

platforma 2 TELNET server

aplikace

zde zdejejepoužíván používán specifický specifickýformát formát platformy, na platformy, nakteré 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í souborů • 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 – .....

• 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

systém souborů

klient uživatelské rozhraní

interpret protokolu

řídící spojení

interpret protokolu

přenosový proces

datové spojení

přenosový proces

využívají se transportní služby protokolu TCP

systém souborů

44

Datové a řídící spojení • oddělení datového a řídícího spojení • řídící spojení iniciuje je výhodné: (navazuje) klient – kvůli zajištění transparence – ze svého (dynamicky – kvůli možnosti přerušit probíhající přiděleného) portu na port přenos 21 – 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í

• 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

FTP – řádkový klient C:\>ftp ftp> ? Příkazy lze zkracovat. Příkazy: ! ? append ascii bell binary bye cd close ftp>

delete debug dir disconnect get glob hash help lcd

literal ls mdelete mdir mget mkdir mls mput open

prompt put pwd quit quote recv remotehelp rename rmdir

send status trace type user verbose

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 RFC1531. 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

Záznamy DHCP 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 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řílohy57

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>>://<>:<>@<<počítač>>:<<port>>/<>; <<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 instance 1.3.6.1.2.1.4.3.0

• 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