Kalábovi

Kalábovic wikina

Uživatelské nástroje

Nástroje pro tento web


pitel:isz:sluzby_aplikacni_vrstvy

Služby aplikační vrstvy

E-mail

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ý hromadou RFC a je rozdělena na dvě části:

  1. hlavičku (obálka)
  2. 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: [email protected]
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 [email protected] 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: [email protected] 2 eva.fit.vutbr.cz 995 xkalab00
Return-Path: <[email protected]>
Received: from wis.fit.vutbr.cz (agata.fit.vutbr.cz [147.229.9.21])
	by eva.fit.vutbr.cz (envelope-from [email protected]) (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?= <[email protected]>
Subject: temata k ustni casti ISZ
Message-ID: <[email protected]>
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: [email protected]
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.1)

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

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, rozšířen byl pak v roce 2008 v RFC 5322. SMTP serverům je vyhrazen port 25.

Příklad poslání e-mailu najdete na 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

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ý spoustou RFC a POP3 servery běží na portu 110 (995, pokud jsou zabezpečeny SSL).

Příklad použití POP3 najdete opět na 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

Internet Message Access Protocol

Nedostatek POP3 (nemožnost správy mailboxu) řeší protokol IMAP. Definuje ho 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

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.

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.

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.

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

Š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:

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:

  1. Aktualizácia sériového čísla SOA
  2. Pridanie/odstránenie/aktualizácia priamych záznamov
  3. Pridanie/odstránenie/aktualizácia reverzných záznamov
  4. 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: nslookup, host, dig.

IP telefónia

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

  1. Vzorkovanie analogového signálu – vzorkovací frekvence musí být 2× větší, než maximální frekvence vzorkovaného signálu2) – výstupom PAM
  2. Kvantifikácia vzorkov – „zaokrouhlování“ naměřených hodnot – μ-law (USA, Kanada, Japonsko), α-law (ostatní)
  3. Kódovanie hodnôt na binárne čísla – PCM, ADPCM, LDCEL, CS-ACELP
  4. 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

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

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
1)
Takto je to nejspíš popsáno i v některém RFC
/var/www/wiki/data/pages/pitel/isz/sluzby_aplikacni_vrstvy.txt · Poslední úprava: 03. 07. 2012, 13.53:44 (upraveno mimo DokuWiki)