Slidy z prednášky (820 kB)
YouTube

verzia učebného textu pre tlač

1.  DNS

DNS: domain name system, komplexný systém spomínaný v mnohých RFC, základný protokol na získanie DNS záznamov je popísaný v RFC 1035.

DNS je systém, spravujúci distribuovanú databázu DNS záznamov (anglicky RR: resource record). Databáza DNS záznamov je organizovaná v hierarchickej štruktúre doménových serverov (DNS serverov, name serverov).

Hlavnou úlohou DNS je preklad doménových mien na IP adresy a späť. IP adresy používa sieťová vrstva Internetu na adresáciu datagramov a identifikáciu zariadení v sieti. Keďže IP adresy sú 32-bitové čísla (alebo, v prípade IPv6, 128-bitové čísla), sú pre ľudí ťažko zapamätateľné. Ľudia teda používajú na adresáciu zariadení v sieti doménové mená. Samotná komunikácia na internete s daným zariadením je možná až po preklade na IP adresu.

DNS ponúka aj širšie možnosti ako len preklad z doménových mien na IP adresy:

  • nevynucuje reverzné doménové mená
    • Nie každá IP adresa musí mať pridelené doménové meno. Niekedy sa stáva, že sa preklad z doménového mena na IP adresu podarí, ale opačný preklad už nie. Ak chceme zabezpečiť aj opačný smer prekladu, tak pre danú IP adresu musíme prideliť reverzné doménové meno.
  • host aliasing
    • Viac doménových mien môže mať pridelenú rovnakú IP adresu. Toto je často využívané vo webhostingu, kde na jednom počítači (aj v jednom webovom serveri) sú k dispozícii webové stránky rôznych zákazníkov s rôznymi doménovými menami.
  • mail server aliasing
    • Mailový server pre danú doménu môže sídliť, a často aj sídli, na inom počítači ako webový server, aj keď s rovnakým doménovým menom v mailovej adrese (za zavináčom) a pre web. Tiež je možné špecifikovať aj náhradné mailové servery pre jednu doménu.
  • distribúcia záťaže
    • Táto metóda umožňuje viacerým IP adresám prideliť rovnaké doménové meno. Využitie je pri veľmi zaťažených serveroch, kedy je potrebné vytvoriť viac replikovaných serverov poskytujúcich rovnakú službu. DNS klient potom dostane zoznam IP adries týchto serverov v náhodnom poradí (pre každého klienta náhodnom). Klient si obvykle vyberie prvú IP adresu a daný server kontaktuje. Keďže sa na prvom mieste zoznamov pre klientov vyskytujú jednotlivé IP adresy podobne často, klienti oslovujú všetky servery s rovnakou pravdepodobnosťou, čím sa rozkladá záťaž viac-menej rovnomerne.

Infraštruktúra DNS je tvorená celosvetovou hierarchiou serverov. Na vrchole hierarchie sa nachádza presne 13 koreňových DNS serverov, z ktorých každý má svoju IP adresu (niektoré z nich už aj IP adresu verzie 6). Nejde však iba o 13 počítačov. Mnohé z týchto serverov majú svoje kópie s rovnakou IP adresou po celom svete. Umožňuje to smerovacia schéma anycast smerovacieho protokolu BGP, ktorá paket s danou cieľovou IP adresou nasmeruje iba k "najbližšiemu" počítaču s touto IP adresou. Prehľad všetkých lokalít koreňových serverov si môžete pozrieť na adrese http://www.root-servers.org/

V hierarchii pod koreňovými DNS servermi sa nachádzajú TLD (Top Level Domain) DNS servery. Ide o servery zodpovedné za poslednú časť názvu domény napr. com, net, org, edu, sk, cz, eu, a tak ďalej. Každý z týchto "serverov najvyššej úrovne" je zodpovedný za jednu z koncoviek. Záznamy o tom, ktorý z TLD serverov je zodpovedný za ktorú koncovku, spravujú práve koreňové servery. Samozrejme, že pre každú koncovku je prevádzkovaných viac TLD DNS serverov, aby pri výpadku niektorého z nich boli k dispozícii ďalšie, ktoré vedia poskytnúť rovnaké informácie. TLD DNS servery spravujú záznamy o DNS serveroch prvej úrovne napr. upjs.sk, sme.sk, atď., ktoré môžu mať pod sebou ďalšiu hierarchiu serverov druhej a ďalších úrovní. Okrem toho servery prvej a ďalších úrovní už spravujú aj záznamy o IP adresách konkrétnych cieľových počítačov. DNS servery, ktoré spravujú danú doménu pre cieľové počítače, sa nazývajú aj autoritatívne DNS servery.

Okrem DNS serverov zapojených v hierarchii sa bežne prevádzkujú aj lokálne DNS servery, ktoré nie sú správcom žiadnej domény, ale slúžia ako predvolené DNS servery koncových staníc z rovnakej siete, aby za nich komunikovali s DNS servermi v hierarchii pri zisťovaní prekladu doména/IP adresa. Tieto DNS servery si ukladajú všetky zistené DNS záznamy do svojho lokálneho cache úložiska. Často požadované DNS záznamy sa tak nemusia vždy zisťovať z internetu, ale ak sú v cache, aj priamo od lokálneho DNS servera, čo odľahčuje hlavne DNS servery vyšších úrovní. Takéto odpovede z cache DNS servera sa nazývajú neautoritatívne. Záznamy v cache majú svoju životnosť a po čase musia byť obnovované. Obvykle je táto životnosť jeden deň.

Spôsob získania požadovaného DNS záznamu môže byť rekurzívny a nerekurzívny. Pri rekurzívnom spôsobe poprosíme oslovený DNS server, nech nám priamo on zistí hľadaný DNS záznam. Tento DNS server pre nás zistí v hierarchii požadovaný záznam a vráti nám ho. Rekurzívny spôsob teda nechá hľadanie záznamu z hierarchie serverov na iný (typicky lokálny) DNS server. Pri nerekurzívnom spôsobe, ktorý je typický na komunikáciu lokálneho DNS servera s inými DNS servermi v hierarchii, sa postupne pýtame koreňového servera na IP adresu TLD servera, následne oslovujeme TLD DNS server na získanie záznamu o serveri prvej úrovne a tak ďalej, pokiaľ nezískame od posledného z oslovených serverov hľadaný DNS záznam. Ak tento server už pozná niektorý zo serverov v tomto zozname kontaktovaných serverov, nemusí svoje hľadanie realizovať cez koreňový server. Postup nerekurzívneho hľadania záznamu uveďme na príklade hľadaného prekladu doménového mena web.ics.upjs.sk:

  1. Ak mám aktuálny záznam prekladu web.ics.upjs.sk v svojej cache, vrátim ho ako odpoveď.
  2. Ak mám aktuálny záznam o autoritatívnom doménovom serveri pre doménu web.ics.upjs.sk (ak taký DNS server vôbec existuje), opýtam sa ho na preklad doménového mena web.ics.upjs.sk a vrátim ho ako odpoveď.
  3. Ak mám aktuálny záznam o autoritatívnom doménovom serveri pre doménu ics.upjs.sk (ak taký DNS server vôbec existuje), opýtam sa ho na preklad doménového mena web.ics.upjs.sk. Ak ho má, vrátim ho ako odpoveď, ak nie, popýtam sa na adresu autoritatívneho doménového servera pre doménu web.ics.upjs.sk a pokračujem bodom 2.
  4. Ak mám aktuálny záznam o autoritatívnom doménovom serveri pre doménu upjs.sk (ak taký DNS server vôbec existuje), opýtam sa ho na preklad doménového mena web.ics.upjs.sk. Ak ho má, vrátim ho ako odpoveď, ak nie, popýtam sa na adresu autoritatívneho doménového servera pre doménu ics.upjs.sk a pokračujem bodom 3.
  5. Ak mám aktuálny záznam o TLD doménovom serveri pre koncovku sk (ak taký DNS server vôbec existuje), popýtam sa na adresu autoritatívneho doménového servera pre doménu upjs.sk a pokračujem bodom 4.
  6. Popýtam sa niektorého koreňového servera na adresu TLD doménového servera pre koncovku sk a pokračujem bodom 5.

DNS záznamy obsahujú meno, hodnotu, typ a čas života. Po uplynutí času života končí platnosť tohto záznamu v cache DNS servera a nemôže sa už použiť na neautoritatívne odpovede, ale musí byť opätovne vyžiadaný z hierarchie. Základné typy DNS záznamov sú nasledovné:

  • Typ A - Hodnota je IP adresa stanice, meno je doménové meno stanice. Táto stanica môže byť DNS server, ale aj nemusí. Záznamy typu A sú potrebné na základnú funkcionalitu DNS serverov t.j. preklad doménových mien na IP adresy a späť.
  • Typ AAAA – To isté ako typ A, len pre IPv6.
  • Typ NS - Menom je doména a hodnotou je meno (autoritatívneho alebo TLD) DNS servera spravujúceho túto doménu. Tieto záznamy sa používajú na nájdenie DNS servera v hierarchii serverov.
  • Typ CNAME - Menom je alias pre "skutočné" doménové meno, ktorému je primárne určená daná IP adresa. Hodnotou je to skutočné doménové meno.
  • Typ MX - Tento typ sa používa na identifikáciu mailových serverov na základe mailovej adresy. Meno v zázname obsahuje doménové meno, ktoré sa v mailovej adrese vyskytuje za zavináčom. Hodnota v zázname je skutočné meno servera, na ktorom beží mailový server.

DNS server počúva na porte 53 a je možné s ním komunikovať s použitím protokolu TCP aj UDP. Žiadosti o preklad sa obvykle realizujú cez UDP. TCP komunikácia sa používa na stiahnutie celej množiny záznamov, typicky za účelom synchronizácie viacerých autoritatívnych DNS serverov pre tú istú doménu. DNS protokol používa binárne požiadavky a odpovede. Je popísaný v RFC 1035.

2.  P2P siete

Peer-to-peer (P2P, alebo po slovensky rovný s rovným) je architektúra, ktorá sa v súčasnosti najmasívnejšie používa na zdieľanie a paralelné kopírovanie súborov (často s obsahom porušujúcim autorské práva tvorcov). P2P architektúra sa však používa napríklad aj na telefonovanie na internete alebo na distribuované výpočty. Hlavnou výhodou P2P sietí je škálovateľnosť prostriedkov. V prípade klient/server architektúry je častou podmienkou výkonný server, alebo klaster serverov, na ktoré spadá hlavná záťaž, aby poskytli služby mnohým klientom súčasne. Pri P2P architektúre sa záťaž rozkladá na pripojených peerov, z ktorých žiaden nemusí byť výnimočne výkonný. Ak ide o hybrid klient/server a P2P architektúry, tak server je často chápaný iba ako miesto, kde je umiestnený "centrálny register" peerov a hlavnú záťaž (napr. posielanie súborov) už preberajú na seba samotní peerovia.

2.1  Porovnanie klient/server architektúry a P2P architektúry pri distribúcii súboru.

Škálovateľnosť P2P sietí sa dá ľahko ukázať pri probléme distribuovania súboru z jedného na N počítačov. Predpokladajme nasledujúcu situáciu zobrazenú na obrázku.

Každý z počítačov je napojený do internetu, o ktorom v tomto modeli predpokladáme, že má dostatočnú prenosovú rýchlosť, aby nespomaľoval žiadnu potrebnú komunikáciu. Našou úlohou je distribuovať súbor zo servera na N počítačov. Prenosová rýchlosť servera pre upload nech je us a pre cieľové počítače u1 až uN. Pri serveri nás šírka pásma pre download nezaujíma. Cieľové počítače majú šírku pásma pre download d1 až dN.

Pri klient/server architektúre musíme posielať celý súbor zo servera každému klientovi zvlášť. Rýchlosť je ovplyvnená hodnotami us a d1 až dN. Dolný odhad celkového času potrebného na distribúciu súboru veľkosti F je max{NF/us, F/min{d1,... , dN}}. Pri veľkom N rastie tento čas lineárne s hodnotou N.

V P2P architektúre stačí, aby server poslal všetkým peerom dohromady jednotlivé časti súboru, ktorý má veľkosť F aspoň raz, na čo mu stačí čas minimálne F/us. Peerovia si už vedia jednotlivé časti poposielať medzi sebou, t.j. každý sa stane poskytovateľom tých dát, ktoré už má k dispozícii. Každý z peerov si teda musí stiahnuť celý súbor raz, na čo potrebuje čas F/di. Celková šírka pásma na upload súboru narástla až na us+u1+...+uN. Celkovo je potrebné cez tento upload poslať klientom NF dát. Dolný odhad celkového času potrebného na distribúciu súboru veľkosti F je max{F/us, F/min{d1,... , dN},NF/(us+u1+...+uN)}.

2.2  P2P s centrálnym adresárom (Napster)

Základným problémom riešeným v P2P sieťach je nájsť peerov, ktorí sú schopní poskytnúť hľadané dáta. Prvou P2P sieťou poskytujúcou voľné sťahovanie mp3 súborov bol Napster uvedený do prevádzky v roku 1999. V skutočnosti ide o hybrid P2P a klient-server architektúry. Jadro architektúry Napsteru predstavoval centrálny server, ktorý centrálne indexoval obsahy adresárov pripojených peerov. Vyhľadávanie žiadaného súboru sa vykonalo nad týmto indexom a hľadajúcim peerom boli zasielané zoznamy peerov, ktorí zdieľajú hľadaný obsah. Samotné kopírovanie súborov sa už realizovalo mimo hlavný server. Táto architektúra nebola odolná voči právnickým útokom nahrávacích spoločností a server musel byť odpojený od siete. Tento krok si "vynútil" vznik distribuovaných spôsobov vyhľadávania, v ktorých po odpojení ľubovoľných počítačov sieť neprestane fungovať.

2.3  Čistá P2P sieť (Gnutella)

Opačným extrémom voči centrálnemu indexovaciemu serveru je čistá P2P sieť bez akéhokoľvek servera, kde sú si všetci peerovia rovní a majú v sieti rovnaké práva a povinnosti. Príkladom takejto siete je pôvodný návrh siete Gnutella. Pri takejto architektúre vznikajú dva nové problémy. Prvým je otázka, ako sa do siete napojiť, keď neexistuje centrálny prihlasovací server. Druhým je spôsob vyhľadávania v takejto sieti.

Na to, aby sa práve spustený P2P program dokázal napojiť do siete, potrebuje poznať aspoň jedného peera, ktorý sa už v sieti nachádza. Je to riešené tak, že každý klient má nejaký zoznam peerov, o ktorých vie, že v sieti už boli/sú napojení. Keďže peerovia sa môžu kedykoľvek pripájať a odpájať, nemusí s pokusom o napojenie na nich uspieť. Úvodný zoznam pre Gnutellu sa dá získať od niektorého nadšeného člena siete, ktorý prevádzkuje GWC (Gnutella Web Cache) a pochváli sa o tom na IRC. GWC je napojený do siete ako peer a neustále aktualizuje zoznam IP adries peerov, ktorých "vidí" pripojených. Niektoré adresy GWC poskytovateľov bývajú tiež súčasťou inštalácií klientov.

Vyhľadávanie a vytváranie nových napojení v takejto čistej P2P sieti je realizované takzvaným "Query flooding" algoritmom, teda zaplavovaním otázkou. Po tom, ako sa klient napojí na niektorého člena siete, chce vytvoriť ďalšie spojenia, aby jeho kontakt so sieťou bol "pevnejší". Pošle tomu peerovi, na ktorého sa mu podarilo napojiť, správu nazývanú Ping, ktorá má v sebe počítadlo preposlaní. Kedykoľvek niektorý z peerov dostane správu Ping, zníži počítadlo preposlaní o 1 a prepošle túto Ping správu všetkým svojim susediacim peerom, s ktorými má vytvorené spojenie. Ak ku peerovi dorazí správa Ping s počtom preposlaní nula, posiela správu Pong peerovi, ktorý túto správu inicioval. Ten si potom vyberie z množstva Pong odpovedí niektorých peerov, s ktorými vytvorí nové spojenie. Po tejto inicializačnej fáze môže podobným spôsobom vyhľadávať. Pošle všetkým svojim susedom otázku. Títo peerovia otázku preposielajú ďalej. Ak niektorý z peerov zistí, že má obsah, ktorý bol v otázke vyhľadávaný, odpovie priamo hľadajúcemu a kopírovanie sa môže realizovať.

V súčasnosti už Gnutella nemá takúto P2P architektúru, kde sú si všetci peerovia rovní, ale vytvára hierarchickú sieť, kde sa peerovia delia na bežných peerov a super peerov, na ktorých sú bežní peerovia napojení. Super peerovia si vytvárajú malý index zdieľaných súborov na nich napojených bežných peerov a samotný algoritmus Query flooding sa realizuje už iba medzi super peermi. To, ktorý peer sa stane super peerom, sa môže priebežne meniť podľa situácie v sieti, pretože aj super peerovia sa môžu pokojne odpájať od siete. Bežní peerovia sú preto často napojení na viacerých super peerov, aby sa nestalo, že sa odpojením jedného super peera odpoja aj oni. Najčastejšie sa super peerom stávajú počítače s rýchlym pripojením a samozrejme verejnou IP adresou.

Medzi hierarchické P2P siete patrí napr. aj Kazaa s jej protokolom FastTrack.

2.4  BitTorrent

BitTorrent je v súčasnosti najpopulárnejší P2P protokol. Ide o hybrid klient/server a peer-to-peer architektúry. Jeho špecifikom je to, že skupinu komunikujúcich peerov, tzv. torrent, spája konkrétny súbor alebo adresár, ktorý poskytujú a sťahujú. Serverom každého torrentu je takzvaný tracker, ktorý registruje IP adresy zúčastnených peerov. Zistenie toho, kto je pre daný súbor trackerom, sa realizuje cez vyhľadávacie webové stránky. Webové stránky, ktoré poskytujú vyhľadávanie trackerov s obsahom porušujúcim autorské práva, sídlia väčšinou v krajinách so slabými zákonmi voči počítačovej kriminalite. Zoznamy trackerov pre daný súbor sa poskytujú v súboroch s príponou .torrent.

Po napojení na tracker sa peer dozvie nejakú podmnožinu peerov v danom torrente, od ktorých môže začať žiadať zoznam dostupných častí súboru a poskytnutie niektorej z nich. Súbory v sieti BitTorrent sú rozkúskované na malé časti (256 KB alebo iné mocniny dvojky) nazývané chunks. Každý chunk je možné získať od iného peera.

Pri použití DHT a magnet odkazov tracker poskytuje len magnet link, ktorý ukazuje na torrent, ktorý si už klient stiahne od peerov zapojených v DHT.

Na zníženie záťaže trackerov sa, po napojení do torrentu, dajú na získavanie adries ďalších peerov použiť Peer exchange (PeX) a LocalPeerDiscovery LPD. Pri PeX si od už pripojených peerov vyžiada peerov, ktorí sú napojení na neho. Pri LPD pomocou broadcastu peer objavuje nových peerov na lokálnej sieti.

Protokol siete BitTorent je navrhnutý tak, že akonáhle niektorý peer stiahne nejaké časti súboru, stáva sa automaticky ich poskytovateľom. Samozrejme, že niektorí klienti sa môžu rozhodnúť neposkytovať nič, t. j. "byť v móde download only". Sú to takzvaní free-rideri. Sieť BitTorrent má však nádherné regulačné mechanizmy, ako zvýhodniť peerov, ktorí sú ochotní poskytnúť svoje stiahnuté časti súboru. Každý z peerov posiela svoje časti (odpovedá na požiadavky na stiahnutie) iba 4 peerom súčasne. Uprednostňuje tých peerov, ktorí mu poskytli ich časti s najväčšou rýchlosťou prenosu. Týchto najlepších 4 peerov vyhodnocuje každých 10 sekúnd. Okrem toho, každých 30 sekúnd si vyberie jedného náhodného žiadateľa a pošle mu svoje časti. Tento nový žiadateľ sa môže stať jedným zo 4 najlepších. Takýmto spôsobom postupne spolu komunikujú hlavne peerovia, ktorí sú "rovnako štedrí". Výber náhodného žiadateľa je potrebný aj na to, aby sa všetci peerovia mohli dostať minimálne k svojim prvým chunk-om.

2.5  Skype

Skype je príkladom neverejného (uzavretého) protokolu. To znamená, že neexistuje RFC, ktoré by ho popisovalo. Všetko, čo o tomto úspešnom P2P protokole vieme, je iba odpozorované z jeho správania alebo zistené reverzným inžinierstvom.

Skype tvorí hierarchickú sieť, v ktorej sú bežní peerovia a super peerovia. Peer sa pri napájaní do siete pripája na centrálny server, kde sa autentifikuje a následne sa napojí na niektorého zo super peerov. Jeho super peer zisťuje od ostatných super peerov, či sú jeho kontakty pripojené do siete. V čase, keď chce peer realizovať hovor alebo chat, informuje o tom cieľového peera cez svojho a jeho super peera. Samotný rozhovor už prebieha len medzi koncovými peermi. Výnimkou je, ak obaja peerovia majú neverejnú IP adresu. Vtedy super peer určí peera s verejnou IP adresou ako sprostredkovateľa, na ktorého sa títo dvaja napoja a celý rozhovor prebieha cez tieto spojenia. Sprostredkovateľ jednoducho preposiela pakety oboma smermi bez toho, aby o tom používateľ tohto sprostredkovateľa vedel.

Od roku 2012 má Skype všetkých super-peerov hostovaných na vlastných linuxových uzloch [ link].

3.  Úlohy a diskusia

  • Dnes má skoro každý poskytovateľ internetového pripojenia aspoň jeden vlastný lokálny doménový server a jeden autoritatívny doménový server. Aké sú úlohy týchto serverov v rámci celej DNS hierarchie?
  • Autoritatívne DNS servery veľkých spoločností bývajú často veľmi zaťažené, a preto sa snažia rozdeliť záťaž medzi veľa serverov, často geograficky oddelených. Synchronizácia medzi nimi často prebieha štýlom master/slave. Vyhľadajte si informácie o tomto spôsobe synchronizácie. Aký protokol sa pri nej využíva? Existujú pre ňu nejaké formy autentizácie?
  • Okrem základných typov DNS záznamov sa často používa aj záznam typu SRV. Na čo slúži tento záznam a ako vyzerá? Skúste nájsť doménu, ktorá tento záznam používa.
  • Trackery pre sieť BitTorrent sú v poslednom čase pod neustálymi útokmi zo strany nahrávacích a distribučných spoločností, preto vznikla snaha decentralizovať aj túto sieť. Skúste vyhľadať názov a spôsob fungovania tohto rozšírenia siete BitTorrent, ktorý jej umožňuje fungovať aj bez centrálnych trackerov.
  • Čo tvorí obsah torrent súborov a aký je vzťah jeho obsahu k obsahu súborov, ktoré môžete na základe torrent súboru získať? Existuje jednoznačné priradenie stiahnutého súboru k torrentu a naopak, torrentu k stiahnutému súboru?
  • Skype sa pýši tým, že je vďaka svojmu šifrovaniu neodpočúvateľné. Vyhľadajte na internete informácie o protokole Skype. Je možné Skype odpočúvať? Ak áno, tak kým? Diskutujte.

4.  Otestujte sa


zdroje:

Page last modified on 28. 02. 2019 12.06