====== Služby aplikační vrstvy ======
===== E-mail =====
[[wp>e-mail]]
E-mail je způsob jak posílat prakticky libovolné zprávy v prostředí internetu.
Samotná zpráva je posílána jako čistý text definovaný [[wp>E-mail#Message_format|hromadou RFC]] a je rozdělena na dvě části:
- hlavičku (obálka)
- tělo (obsah obálky)
Hlavička je od těla oddělena prázdným řádkem (všechny následující prázdné řádky se pak považují za součást těla).
Delivered-To: pitlicek@gmail.com
Received: by 10.213.17.207 with SMTP id t15cs301289eba;
Thu, 25 Feb 2010 08:48:07 -0800 (PST)
Received: by 10.216.85.83 with SMTP id t61mr690244wee.167.1267116477872;
Thu, 25 Feb 2010 08:47:57 -0800 (PST)
Received-SPF: softfail (google.com: best guess record for domain of transitioning eysselt@fit.vutbr.cz does not designate 147.229.9.21 as permitted sender) client-ip=147.229.9.21;
Received: by 10.241.103.21 with POP3 id 21mf36262ewy.62;
Thu, 25 Feb 2010 08:47:57 -0800 (PST)
X-Gmail-Fetch-Info: xkalab00@stud.fit.vutbr.cz 2 eva.fit.vutbr.cz 995 xkalab00
Return-Path:
Received: from wis.fit.vutbr.cz (agata.fit.vutbr.cz [147.229.9.21])
by eva.fit.vutbr.cz (envelope-from eysselt@fit.vutbr.cz) (8.14.4/8.14.4) with ESMTP id o1O8xvKG032048;
Wed, 24 Feb 2010 10:00:05 +0100 (CET)
X-Received-From: pceysselt.fit.vutbr.cz ([147.229.12.52])
Date: Wed, 24 Feb 2010 10:00:05 +0100
To: undisclosed-recipients:;
From: =?iso-8859-2?Q?Eysselt_Milo=B9?=
Subject: temata k ustni casti ISZ
Message-ID: <236ed0fb8e25bf788fc9b43055da50bf@wis.fit.vutbr.cz>
X-Priority: 3
X-Mailer: PHPMailer [version 1.73pl]
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="iso-8859-2"
X-Spam-Score: -0.527 () ALL_TRUSTED,AWL
X-Scanned-By: MIMEDefang 2.64 on 147.229.176.14
X-UIDL: ~1L"!oF1!!b6d"!]ff"!
Informace k předmětu ISZ/2009L
Pokud jsem vas dosud neinformoval, tak jsou mj. uvedena v
"anotaci" prihlasky(/kvazipredmetu) k ISZ, na uredni desce a
take na http://www.fit.vutbr.cz/~eysselt/index.html.cz.
Em.
--
Ústav počítačových systémů FIT VUT v Brně
E-mail: eysselt@fit.vutbr.cz
Web: http://www.fit.vutbr.cz/~eysselt/
Tel: 54114-1230
Pojďme se teď podívat na výše uvedený příklad. Představuje snad všem dobře známý e-mail který byl odeslán do školní mailové schránky odkud byl vyzvednut Gmailem. Rozdělení na hlavičku a tělo je snad zřejmé, probereme si tedy podrobněji některé hlavičky.
Jak e-mail putuje internetem přes různé mailservery, jsou na jeho začátek připojovány další a další hlavičky ''Received'' které sledují cestu této zprávy. Když tedy budeme hlavičku postupně číst, dostaneme se zpět až k odesílateli. Na příkladu můžeme vidět že si zprávu zřejmě předalo několik serverů Gmailu, předtím byla zpráva Gmailem vyzvednuta ze školní schránky a na konci vidíme že byla zpráva přijata školním mailserverem.
Mezi tím jsme narazili na několik řádků začínajících ''X-'', to jsou různá rozšíření různých mailserverů, které můžeme ignorovat.((Takto je to nejspíš popsáno i v některém RFC))
Hlavička ''Date'' popisuje datum a čas odeslání e-mailu.
Hlavička ''To'' by měla obsahovat adresu na kterou má být e-mail odeslán. V tomto případě byl ale email rozeslán většímu počtu příjemců a navíc byli všichni na stejném mailserveru jako odesílatel, a tak jsou příjemci skryti.
''From'' je naopak e-mail odesílatele zprávy.
''Subject'' představuje předmět zprávy.
Řádky ''MIME-'' a ''Content-'' pak určují kódování zprávy a případných příloh.
==== SMTP ====
[[wp>Simple Mail Transfer Protocol]]
Protokol SMTP slouží k odesílání e-mailů. Opět se jedná o textový protokol a je specifikován především v [[rfc>821|RFC 821]], rozšířen byl pak v roce 2008 v [[rfc>5322|RFC 5322]]. SMTP serverům je vyhrazen port 25.
Příklad poslání e-mailu najdete na [[wp>Simple_Mail_Transfer_Protocol#SMTP_transport_example|Wikipedii]]. V zásadě se ale klient a server nejdřív pozdraví (''HELO''), pak klient nadiktuje hlavičky (''MAIL FROM'', ''RCPT TO'') a pak konečně tělo zprávy (''DATA'', včetně všech hlaviček) ukončené tečkou na samostatném řádku. V ten moment server dokončí příjem zprávy, zařadí ji do fronty a následně odešle. Zprávou ''QUIT'' se pak klient rozloučí a server uzavře spojení.
==== POP3 ====
[[wp>Post Office Protocol]]
Když jsou zprávy doručené do svého cíle, musí přijít klient (Mozilla Thunderbird, Outlook, ...) a zprávy si z mailboxu vyzvednout. Přesně k tomu slouží protokol POP3. Opět je to protokol čistě textový, opět je definovaný [[wp>Post_Office_Protocol#Related_Requests_For_Comments_.28RFCs.29|spoustou RFC]] a POP3 servery běží na portu 110 (995, pokud jsou zabezpečeny SSL).
Příklad použití POP3 najdete opět na [[wp>Post_Office_Protocol#Dialog_example|Wikipedii]].
Důležité je především to, že zprávy leží "na hromadě" v mailboxu a klient je pouze stáhne, případně smaže. POP3 nijak neřeší rozdělení zpráv do složek či jejich jinou organizaci.
==== IMAP ====
[[wp>Internet Message Access Protocol]]
Nedostatek POP3 (nemožnost správy mailboxu) řeší protokol IMAP. Definuje ho [[rfc>3501|RFC 3501]].
Protokol IMAP umožňuje zprávy nejen stahovat (navíc umožňuje stáhnout nejdřív pouze hlavičky a tělo a přílohy až poté co si je klient vyžádá) a mazat, ale také přesouvat mezi adresáři, vytvářet adresáře a vůbec provádět kompletní správu mailboxu.
===== DNS =====
[[wp>Domain Name System]]
Mapovanie doménových adries na IP adresy a obrátene, obsahuje teda databázu všetkých mien a IP adries. Využíva DNS servery, ktoré používajú hierarchické usporiadanie záznamov. Korenom stromu je //root//, jeho názov je reťazec dĺžky nula (tj. ""). Každá doména je podstromom tohto záznamu. Doménové meno je cesta medzi vrcholom domény a korenom stromu -- nazýva sa aj absolútna adresa (FQDN). Listy stromu sú teda konkrétne sieťové zariadenia.
{{dns-hierarchy.png}}
Správa domén je decentralizovaná. Je rozdelená do zón, čo je fyzická časť priestoru DNS pod jednotnou správou. Špeciálne zóny: stub, hint.
{{zona-vutbr.png}}
==== Reverzné mapovanie ====
Toto trochu nechapem, je to v slajdoch divne.
Záznamy v DNS sú indexované podľa doménových adries. Špeciálne domény arpa tvoria tzv. reverzný strom. Príklad 12.8.229.147.in-addr.arpa.
{{reverzne-mapovanie.png}}
==== Registrácia ====
Registráciu zabezpečuje ICANN (Internet Corporation for Assigned Names and Numbers). Ten akredituje registrátorov generických doménových mien:
* Národné (ccTLD, country code TLD) -- .uk, .cz
* Generické (gTLD, generic top level domains) -- .com, .org
Národné domény registruje národný správca domény, v ČR je to [[http://www.nic.cz|CZ.NIC]]. Zmeny vkladajú iba oprávnení registrátori.
==== DNS servery ====
Obsahuje záznamy, informácie o stromovej štruktúre a dátach. Každý server však obsahuje iba časti DNS priestoru -- zóny.
Typy:
* Primárne (master, primary name servers) -- úplné, autoritatívne záznamy o doménach, ktoré spravuje. Pre každú doménu je jeden.
* Sekundárne (slave, secondary name servers) -- autoritatívne kópie dát od primárnych serverov (zone transfer).
* Záložné (caching-only name servers) -- iba preposiela dotazy ďalším DNS serverom a ukladá odpovede do vyrovnávacej pamäte. Poskytuje neautoritatívne odpovede (neúplne, neaktuálne)
==== Rezolúcia DNS dotazu ====
**Resolver** je klientský program, ktorý získava informácie od DNS serveru podľa [[rfc>1035|RFC 1035]]. Je to systémová rutina, tj. je súčasťou operačného systému.
**Rezolúcia** je samotný proces vyhľadania odpovede v DNS systéme. Využíva korenovú štruktúru mien, takže vyhľadáva od korenového DNS serveru. Pri rekurzívnych dotazoch sa server pýta ďalších v prípade, že nevie odpoveď. Iteratívne dotazy znamenajú, že server vráti najlepšiu možnú odpoveď. Klient si pak musí zbytek zajistit dalším dotazem na server, který mu byl vrácen.
[[http://commons.wikimedia.org/wiki/File:An_example_of_theoretical_DNS_recursion.svg|{{http://upload.wikimedia.org/wikipedia/commons/thumb/7/77/An_example_of_theoretical_DNS_recursion.svg/500px-An_example_of_theoretical_DNS_recursion.svg.png}}]]
==== Štruktúra DNS záznamov ====
[owner] [ttl] class type rdata
www.fit.vutbr.cz. 14400 IN CNAME tereza.fit.vutbr.cz.
tereza.fit.vutbr.cz. 14400 IN A 147.229.9.22
==== Typy DNS záznamov ====
=== SOA – Start of Authority ===
Každá zóna má práve jeden SOA. Obsahuje názov primárneho serveru a e-mailovú adresu správcu. Sériové číslo ''serial'' identifikuje zmenu záznamu, ''refresh'' je interval pre sekundárny server na zisťovanie zmeny, ''retry'' je doba, po ktorej sa sekundárny server pokusí znova aktualizovať záznam v prípade neúspešného prenosu, ''expire'' je doba platnosti dát na sekundárnom serveri.
Doporučené hodnoty podľa [[rfc>1537|RFC 1537]]:
^ hodnota ^ TLD DNS servery ^ ostatné DNS servery ^
| Refresh | 24 hodín | 8 hodín |
| Retry | 2 hodiny | 2 hodiny |
| Expire | 30 dní | 7 dní |
| Minimum TTL | 4 dni | 1 den |
=== NS – Name Server ===
Určuje autoritatívne servery pre danú zónu, slúži k budovaniu hierarchickej štruktúry systému DNS.
fit.vutbr.cz. IN NS boco.fee.vutbr.cz.
IN NS gate.feec.vutbr.cz.
IN NS kazi.fit.vutbr.cz.
IN NS rhino.cis.vutbr.cz.
=== A – Address ===
Priame mapovanie doménových adries na IP adresy.
eva.fit.vutbr.cz. IN A 147.229.10.14
=== MX – Mail Exchanger ===
Presmeruje poštu pre danú doménu na konkrétny poštový server, je možné ich mať aj viac, vtedy sa riadia podľa priority. Doménové meno sa dá zadať aj hviezdičkovou notáciou pre subdomény.
stud.fit.vutbr.cz. IN MX 10 eva.fit.vutbr.cz.
IN MX 20 kazi.fit.vutbr.cz.
=== CNAME – Canonical Name ===
Mapuje alias na kanonické meno počítača. Alias nesmie stáť na pravej strane záznamu.
www in CNAME eva.fit.vutbr.cz.
=== PTR – Domain Name Pointer ===
Mapuje IP adresu na doménovú adresu - reverzné mapovanie.
14.10.229.147.in-addr.arpa. IN PTR eva.fit.vutbr.cz.
=== NAPTR – Naming Authority Pointer ===
Mapovanie reťazca pre dáta - podpora dynamických konfiguračných systémov DDDS. Používa regulárne výrazy pre dynamické záznamy. Využitie napríklad u SIP alebo H.323.
=== TXT – Text ===
Obsahuje textové dáta - dodatočné info o doméne, serveri, správcovi atď.
=== SRV – Server Selection ===
Lokalizácia služieb a serverov, distribúcia záťaže či zálohovanie služieb.
=== AAAA a ip6.arpa ===
Rozšírenie DNS pre IPv6. Je to mapovanie doménového mena na IPv6 adresu -- doména ip6.arpa. Reverzný záznam je zapisovaný opačne po bytoch (nie binárne, tiež v 16tkovej sústave). Dotazy na A záznamy sa hľadajú aj v AAAA.
==== Rotácia záznamov ====
Nejde o vyvažovanie záťaže (load balancing), ale o vyvažovanie (distribution). Sú to A záznamy s posunutými adresami pre rovnaké doménové meno, tj. server automaticky prideľuje rôzne IP adresy. Rotácia môže byť fixná, cyklická alebo náhodná.
foo.bar.baz. 60 IN A 192.168.1.1
foo.bar.baz. 60 IN A 192.168.1.2
foo.bar.baz. 60 IN A 192.168.1.3
==== DNS protokol ====
Komunikácia medzi resolverom a serverom je rezolúcia, prebieha na UDP porte 53. Komunikácia medzi serverom a serverom je zónovým prenosom, TCP port 53.
Aktualizácia zónových dát:
- Aktualizácia sériového čísla SOA
- Pridanie/odstránenie/aktualizácia priamych záznamov
- Pridanie/odstránenie/aktualizácia reverzných záznamov
- Reštart DNS serveru
Zmeny sa dajú robiť iba na primárnom DNS serveri, tie sú totiž autoritatívne, všetky ostatné servery si berú záznamy z primárnych serverov.
Pri prenose zón začína komunikáciu sekundárny server zaslaním SOA. Primárny mu pošle svoje SOA a sekundárny si potom vyžiada dáta.
==== Bezpečnosť ====
DNS je verejný distribuovaný systém pre komunikáciu na internete. Preto je potrebné sa starať o bezpečnosť -- zaistenie integrity dát, autentizácia zdroja dát. Problémami sú podvrhnuté odpovede, cache poisoning, DoS.
Riešenie: DNSSEC. Zabezpečenie prenosu pomocou asymetrickej kryptografie. Využíva DNSKEY (verejný kľúč), RRSIG (podpis záznamu), NSEC (usporiadanie záznamu), DS (overenie vyššou autoritou). Vytvára sa tak reťaz dôveryhodnosti. Pre každú zónu existuje pár verejný kľúč - tajný kľúč. Významne to zvyšuje veľkosť paketu DNS, taktiež je šifrovanie náročnejšie na spracovanie.
Programy pre zisťovanie info v DNS: [[man>nslookup]], [[man>host]], [[man>dig]].
===== IP telefónia =====
[[wp>Voice over Internet Protocol]]
Výhody: prenos hlasu nad sieťami IP, integrácia dátových a hlasových služieb, rozšírené vlastnosti IP telefónov a ústrední, centrálna správa systémov, nižšie poplatky za hovory, mobilita.
Požiadavky: prenosové pásmo, kvalita signálu, spoľahlivosť siete, integrácia s PSTN.
Prenosové protokoly:
* Signalizačné: H.323, SIP, H.248, MGCP, SCCP
* Transportné: RTP (kontrolní protokol pro RTP: RTCP)
Základné komponenty:
* IP telefon (hardware/software phone)
* Ústredňa (gatekeeper) -- riadenie prístupu, volanie
* Brána (gateway) -- zaisťuje prepojenie VoIP a PSTN
* Jednotka MCU -- riadenie komunikácie viacerých bodov (konferencie)
* Aplikačné servery -- DHCP, DNS, IM, XML/WWW, LDAP
==== Digitalizácia signálu ====
- Vzorkovanie analogového signálu -- vzorkovací frekvence musí být 2× větší, než maximální frekvence vzorkovaného signálu(([[wp>Nyquist–Shannon sampling theorem]])) -- výstupom PAM
- Kvantifikácia vzorkov -- "zaokrouhlování" naměřených hodnot -- μ-law (USA, Kanada, Japonsko), α-law (ostatní)
- Kódovanie hodnôt na binárne čísla -- PCM, ADPCM, LDCEL, CS-ACELP
- Kompresia
==== Prenos ====
=== Réžia prenosu ===
* RTP hlavička (12 B), UDP (8 B), IP (20 B)
* Ethernet (18 B), Frame Relay (6 B)
* IPSec transport (30--53 B), IPSec tunel (50-73 B)
=== Šírka prenosového pásma kodeku ===
Kódovanie G.711 (PCM): 8000 vzoriek/s, každá vzorka 8 bitov => požadované pásmo: 8 kHz × 8 bitov = 64 kb/s
=== Veľkosť vzorky v pakete ===
Cisco posiela jeden rámec so vzorkou (PDU) za 20 ms, takže veľkosť vzorku: 20 ms × 64kHz = 1280 bitov = 160 Bytov
=== Potrebné prenosové pásmo pre PDU ===
Zapúzdrenie: RTP (12), UDP (8), IP (20), Ethernet (18), tj. réžia 58 B. Paketov za sekundu: 64 kb/s / 1280 bitov = 50. Celkové prenosové pásmo teda: (58 + 160) × 8 × 50 = 87200 b/s = 85 kb/s
==== Vplyvy na kvalitu prenosu ====
* Ozvena - eliminuje sa aktívnym potlačením v DSP
* Oneskorenie - musí byť zaistená prioritizácia hlasových paketov
* Kolísanie oneskorenia (jitter) - použitie vyrovnávacích bufferov
* Strátovosť - deštruktívne účinky u kodekov s prediktívnymi metódami
* Kodek - kvalita kódovania signálu, úrovne signálu, početnosť vzoriek
===== Správa SNMP =====
[[wpcs>Simple Network Management Protocol]]
Simple Network Management Protocol je součástí sady protokolů TCP/IP. Jde o protokol hlavně pro získávání informací o sítí.
==== Monitorovaná strana ====
Jde o zařízení, jehož provoz na síti chceme sledovat běží zde tzv. **agent**, který se stará o sběr údajů o provozu zařízení a ukládá je do lokální paměti.
==== Monitorovací strana ====
Jde o zařízení, kde probíhá sběr údajů z agentů na síti a jejich následné vyhodnocování. O to se stará **monitoring manager**. Údaje pak můžeme různě statisticky vyhodnocovat atd.
==== Komunikace mezi agentem a monitorem ====
Buď si manager vyžádá zaslání informací od agenta (request--response), nebo se použije mechanismus zvaný SNMP TRAP (it's a trap!), což je analogické k přerušení v počítači. V tomto případě se agent nastaví tak, aby za určitých okolností (něco se stane na monitorované straně) zaslal informace monitoru i bez dotazu. Přenos dat mezi agentem a monitorem nazýváme SNMP operací.
==== OID a MIB ====
Každá položka v SNMP má své Object ID. To má tvar podobný jako v LDAP adresářích: jde o posloupnost čísel oddělených tečkami. Tato posloupnost vyjadřuje zanoření ve stromu Management Information Base. Přes OID se vyhledá položka v MIB a odsud se vyčte o jakou jde položku, jakých může nabývat hodnot, ...
===== Netflow =====
[[wpcs>Netflow]]
Netflow je otevřený protokol, který vyvinuli v Ciscu hlavně pro správu jejich strojů. Dnes se používá i jinde.
Hezky vysvetlene zaklady jsou primo na wikipedii, hlavne toto:\\
//NetFlow architektura se typicky skládá z několika NetFlow exportérů a jednoho NetFlow kolektoru. NetFlow exportér je připojen k monitorované lince a analyzuje procházející pakety. Na základě zachycených IP toků generuje NetFlow statistiky a ty exportuje na NetFlow kolektor. NetFlow kolektor je zařízení s velkou úložnou kapacitou, které sbírá statistiky z většího počtu NetFlow exportérů a ukládá je do dlouhodobé databáze. Nad těmito daty obvykle běží aplikace, která je umí efektivně vizualizovat a generovat z nich přehledy v podobě grafů a tabulek, které umožňují jednoduše analyzovat monitorovaný provoz i běžnému uživateli.//
Exportéry byly dříve implementovány jako součást směrovače. Jenže protože Cisco routery jsou poněkud drahé, přešlo se dnes k zařízením, kterým se říka **pasivní sondy** -- taková sonda je krabička, která má vstup a výstup, sedí na lince, čte a přeposílá všechny pakety.
==== Tok ====
Už z názvu vyplývá, že půjde o nějaké síťové toky. Netflow na těchto tocích stojí a podle nich klasifikuje pakety. Tok je pěticí údajů: cílová/zdrojová IP adresa, cílový/zdrojový port a IP protokol (TCP, UDP, IGMP, ...). Pro každý tok je zaznamenávána doba jeho vzniku, délka jeho trvání, počet přenesených paketů a bajtů a další údaje.
Hlavní výhodou NetFlow oproti SNMP je právě v použití těchto toků -- lze pak totiž jednoduše zjistit co přesně která stanice ve kterou dobu dělala, např.: "Kdo mi jedl z mého bandwidthu?" -- síťový big brother.
===== Shrnutí =====
* aplikační vrstva: nestará se o přenos po síti, ale až o samotnou komunikaci dvou aplikací
* e-mail: textový protokol, nabalování hlaviček, posílání SMTP, příjem POP3, příjem a lepší správa IMAP
* dns: domain-name system, hierarchická decentralizovaná struktura, primární, sekundární a záložní servery, registrace ICANN, záznamy A, CNAME, PTR, MX, iterativní vs rekurzivní rezoluce, DNSSEC
* IP telefonie: signalizační (SIP, H.323) vs přenosové (RTP) protokoly, překlad čísel přes arpa záznamy (ENUM), (?digitalizace), vlivy na kvalitu: spoždění, rozptyl spoždění, kodek, ztrátovost, ozvěna (zpětná vazba)
* SNMP: monitoring manager, agent, Object ID, Management Information Base
* Netflow: tok, exporter, kolektor, sonda