5/9 BEZPEČNOST MULTIMEDIÁLNÍCH PŘENOSŮ PROSTŘEDNICTVÍM IP

Transkript

1 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 5, díl 9, str. 1 5/9 BEZPEČNOST MULTIMEDIÁLNÍCH PŘENOSŮ PROSTŘEDNICTVÍM IP Standard MPEG byl vyvinut na základě požadavku průmyslu, který potřeboval kvalitní způsob ukládání a získávání audio- a videoinformací na digitální záznamová média (Digital Storage Media - DSM). CD-ROM je levný nosič poskytující přenosovou rychlost přibližně 1,2 Mbps. MPEG standard byl vyvíjen s cílem dosáhnout podobnou přenosovou rychlost. Constrained Parameters Bitstream (datový tok s omezenými parametry) je podmnožina všech přístupných bitových toků, u kterých se očekává, že budou široce využívány. Jsou omezeny na datovou rychlost až do 1,856 Mbps. Nicméně je třeba podotknout, že standard není omezen jen touto hodnotou a že může být použit i pro vyšší datové rychlosti. Během práce na standardu MPEG videa byly vyvinuty další dva závažné mezinárodní standardy: H.261 od společnosti CCITT zaměřený na telekomunikační aplikace a ISO od výboru ISO JPEG zaměřený MPEG-1

2 část 5, díl 9, str. 2 BEZPEČNÁ POČÍTAČOVÁ SÍŤ MPEG video - kompresní techniky na kódování obrázků. Základy obou těchto standardů byly začleněny do standardu MPEG videa, ale výsledkem další práce výboru byly prvky, které nebyly obsaženy ani v jednom z výchozích standardů (H.261 a ISO 10918). Standard MPEG video definuje formát pro kompresi digitálního videa a možnosti, jak může být video kódováno a dekódováno. Ačkoliv je tento standard flexibilní, základní algoritmy byly laděny tak, aby dobře pracovaly v datové rychlosti od 1 do 1,5 Mbps, při rozlišení okolo 350 x 250 a snímkovací frekvenci mezi 24 a 30 snímky. Použití slova obraz jako protiklad ke slovu rám je záměrné. Kódy MPEG videa postupně snímají vyobrazení a nerozpoznávají způsob proplétání. Prokládané místo videa musí být před kódováním převedeno na neprokládaný formát. Po dekódování může dekóder libovolně vytvořit pro zobrazení nějaký prokládaný formát. Standard MPEG videa je navržen k povolení několika metod, aby sledovaly kódování videa, které normálně souvisí s VCR: přehrávání, pozastavení obrazu, rychlé převíjení vpřed, rychlé převíjení zpět a zpomalené přehrávání. Navíc je možný i libovolný přístup. Schopnost dekóderu realizovat tyto režimy záleží na rozsahu povahy digitálního paměťového média, ve kterém je zakódované video uloženo. Video je představováno jako posloupnost jednotlivých obrázků a každý obraz je považován za dvojrozměrné pole obrazových prvků (pixelů). Barva každého pixelu se skládá ze tří složek: hodnoty Y (jasu) a dvou barevných složek.

3 BEZPEČNÁ POČÍTAČOVÁ SÍŤ Mnoho dalších jemných zlepšení (jako např. 10bitová diskrétní kosinová transformace s dvojitou přesností, nelineární kvantizace, tabulky VLC kódování a další) přispívá ke zlepšenému výkonu kódování, a to dokonce i pro progresivní video. Dalšími klíčovými vlastnostmi standardu MPEG-2 jsou rozšiřitelné dočást 5, díl 9, str. 3 Komprimace digitalizovaného videa je možná díky několika technikám: vzorkování barevné informace vzhledem k citlivosti lidského zraku, kvantizaci, kompenzaci pohybu (Motion Compensation), transformaci frekvence pomocí: diskrétní kosinové transformace (Discrete Cosine Transform - DCT), kódování VLC (Variable Length Coding) a obrazové interpolaci. Definitivní schválení ISO/IEC (MPEG-2 systémy), ISO/IEC (MPEG-2 video) a ISO/IEC (MPEG-2 audio) jako mezinárodních standardů bylo dáno 29. setkáním ISO/IEC JTC1/SC29/WG11 (MPEG), konaném v Singapuru v listopadu MPEG-2 koncepce je podobná jako u MPEG-1, ale zahrnuje zaměření na širší použitelnost. Základní aplikace je zaměřena na plně digitální přenos videa v přenosových rychlostech mezi 4 a 9 Mbps. Nicméně bylo zjištěno, že syntaxe MPEG-2 nachází uplatnění také pro aplikace s vyšší vzorkovací frekvencí a bitrate (jako např. HDTV). Nejvýraznějším zlepšením, oproti MPEG-1, je přidání syntaxe pro účinné kódování prokládaného videa (např. kompenzace pohybu pro bloky 16x8, Dual Prime a další). MPEG-2

4 část 5, díl 9, str. 4 BEZPEČNÁ POČÍTAČOVÁ SÍŤ MPEG-4 Streaming datky, které umožňují dělení kontinuálního videosignálu do dvou nebo více kódovaných datových toků, které mohou reprezentovat video s různým rozlišením, kvalitou obrazu nebo snímkovací frekvencí. Na rozdíl od *.MPG žádný souborový formát *.MPEG-4 neexistuje. Otázka, Jak si vytvořím MPEG-4 soubor? tedy nemá smysl. Lze vytvořit soubor AVI, ve kterém je obraz zkomprimován technikou MPEG-4. MPEG-4 je mnohem variabilnější formát pro kompresi pohyblivých obrázků, než jakým je MPEG-1. Na rozdíl od MPEG-1 může mít téměř libovolné rozměry obrazu, počet snímků za sekundu a vzdálenost mezi klíčovými snímky (KeyFrame, IFrame). Navíc nemá pouze konstantní datový tok (CBR: constant bitrate), ale proměnný datový tok (VBR: variable bitrate), což snižuje výslednou velikost videa. Co však MPEG-4 nemá, je široká podpora výrobců stolních DVD/VCD přehrávačů. To znamená, že v tuto chvíli pro MPEG-4 video neexistuje žádný CD standard. Tudíž ani není možné říci, jaký formát mají mít CD ve formátu MPEG-4, a je tedy nemožné taková CD ve stolních přístrojích přehrávat, pokud ovšem tato zařízení nejsou vlastně PC. Jde o technologii, díky které můžete poslouchat hudbu a ostatní druhy zvukových souborů v reálném čase přímo z internetu, aniž byste je museli nejprve zdlouhavě stahovat. Od roku 1995, kdy se RealPlayer stal prvním široce dostupným streamingovým přehrávačem, se ocitl zvuk v reálném čase na dosah jediného kliknutí myši. Volně dostupné nebo levné streamingové přehrávače dokáží zprostředkovat zvuk v dobré kvalitě, a to dokonce

5 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 5, díl 9, str. 5 i v případě připojení prostřednictvím dial-up modemu. Zvukový obsah internetu bobtná a dnes již existují tisíce webových stránek nabízejících svůj obsah živě nebo na vyžádání. Současně se ale prosazují i vyšší rychlosti připojení a rozšiřují se tak nejen možnosti zvuku, ale i obrazu. Zvláštní půvab streaming audia spočívá v jeho okamžité dostupnosti a aktuálnosti. V případě tradičních souborů ke stažení musíte nejdříve uložit celý soubor na disk a teprve poté si jej můžete poslechnout. Streaming audio začne hrát několik málo vteřin poté, co ťuknete na odkaz. Soubory jsou uloženy na speciálních webových serverech. Poté, co kliknete myší na odkaz s hlasovou nahrávkou, stáhne váš streamingový přehrávač několik vteřin audionahrávky do vyhrazené oblasti paměti, zvané buffer (mezipaměť nebo vyrovnávací paměť). Jakmile se buffer naplní, začne dávkovat data do té části streamingového softwaru, která slouží pro přehrávání, a je uslyšet zvuk. Mezitím software pokračuje ve stahování dat do bufferu. Díky tomuto procesu stahování dat, během jejich přehrávání, může technologie streamingu nabídnout zvuk v téměř reálném čase. Vzniká zde ovšem nemalý bezpečnostní problém. Při stažení celého souboru můžete soubor zašifrovat a podepsat, při stahování částí do bufferu je to problém. Teoreticky sice můžete podepsat a zašifrovat i jednotlivé části, ale obvykle nevíte, jak velké, protože velikost bufferu může být velmi individuální dle podmínek aplikace, PC a internetové konektivity. Kontrola a dešifrování souboru bude naopak zpomalovat přehrávání a zhoršovat podmínky pro přehrávání v reálném čase.

6 část 5, díl 9, str. 6 BEZPEČNÁ POČÍTAČOVÁ SÍŤ Komprese Pokud se buffer zcela vyprázdní, začne docházet ke ztrátě kvality, zvuk bude přerušovaný a dostupnost obsahu se sníží, někdy až za hranici použitelnosti. Základem streamingové audiotechnologie je komprese souborů. Většina hudebních souborů je příliš veliká na to, aby se dala protlačit těsnými přenosovými trasami modemů, které většina uživatelů pro připojení k internetu používá. Následkem ztrátové komprese dochází k odstranění části originálního zvukového signálu, který lidské ucho většinou není schopno vnímat. Tomuto procesu se říká perceptual encoding (percepční kódování - kóduje se pouze to, co může člověk vnímat). Odříznuty jsou například velmi vysoké a velmi nízké frekvence. Tímto způsobem vzniká soubor, jehož velikost je již dostatečně malá pro stažení z internetu, avšak jehož zvuková kvalita se pro běžného uživatele příliš neliší od originálu. Milovníci hudby s vytříbeným sluchem si nicméně rozdílu všimnou: výrazně komprimovaný zvukový záznam postrádá brilanci a mohou se v něm vyskytnout poruchy podobné vířivému zvuku krátkovlnného rozhlasového vysílání. Nejnovější kompresní schémata, známá pod souhrnným názvem kodek, však odvádějí mnohem lepší práci než streamingové technologie první generace, jejímž představitelem byl například software RealAudio 1.0. Komprese představuje pouze jednu část procesu, díky kterému se zvuk přenese do vašeho počítače. O zbytek se starají speciální schémata pro přenos dat, zvaná rovněž streamingové protokoly (např. RealTime Streaming Protocol). Pro streaming audio je správné časování vším. Streamingové protokoly zajišťují, že k vám jednotlivé noty skladeb dorazí ve správném pořadí a ve správném časovém okamžiku.

7 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 5, díl 9, str. 7 Z hlediska bezpečnosti přinášejí ztrátové komprese další podstatný problém. Je zcela zřejmé, že po takové kompresi je datový obsah jiný, než jaký byl před touto kompresí. Podepisovat nebo šifrovat má tedy smysl pouze již kompresovanou nahrávku, ta ale není původním záznamem. Zvukovým vlnám na internetu dnes dominují čtyři streamingové technologie: RealAudio společnosti RealNetworks, Windows Media od Microsoftu, QuickTime firmy Apple a společností Nullsoft vyvinutá streamingová technologie MP3 - zvaná SHOUTcast. Každý ze zmíněných produktů pracuje s vlastním komprimačním schématem. Některé z nich jsou zejména vhodné pro přenost zvuku přes nízkokapacitní přenosové trasy připojené přes modem. Software RealAudio například implementuje funkci zvanou SureStream, která se dokáže vypořádat se zácpami na internetu automatickým přechodem na nižší kvalitu zvuku, a tedy na menší objem přenášených dat. Díky tomu nemusí docházet k přerušování proudu hudby v kritických chvílích. K přenosu informací přes síť pro přehrávání záznamu v reálném čase jsou k dispozici dvě možnosti. Progresivní stahování ( Fast Start ) dovoluje uživateli sledovat nebo poslouchat média tak, jak jsou stahovány ze standardního Web serveru (např. Apache) na váš harddisk. Tato metoda funguje také v případě krátkých klipů, jejichž velikost není velká, a zajišťuje vysokou kvalitu přehrávání bez ohledu na propustnost sítě. Ale pokud chcete vysílat živě po síti nebo provozovat rádio, které Streamingové technologie

8 část 5, díl 9, str. 8 BEZPEČNÁ POČÍTAČOVÁ SÍŤ vysílá nepřetržitě, nebo video kanál, potřebujete QuickTime Streaming Server. Ten umožňuje přenášet mediální data skrz internet po všech typech připojení. Od modemu až po sítě s vysokou propustností. Přenos se uskutečňuje pomocí standardního průmyslového protokolu RTP/RTSP (RealTime Protocol / Real- Time Streaming. Protocol - protokol pro přenos informací v reálném čase, resp. protokol pro streamovanou informaci. Tato metoda poskytuje vydavatelům vyšší bezpečnost a kontrolu nad publikovaným obsahem. Použitím protokolů určených pro streaming v reálném čase pak odpadá ukládání přijímaných informací do souborů na lokálním disku. QuickTime Streaming Server byl dlouho jediným streaming serverem, založeným na standardech, který dával k dispozici zdrojový kód (open source). Je navržen pro operační systém Mac OS X Server, ale je také k dispozici ve verzi pro Linux, Solaris, Windows NT/2000 a FreeBSD pod názvem Darwin Streaming Server. Zdrojový kód je samozřejmě také k dispozici. Z tohoto důvodu je možné velmi jednoduše program přenést na jinou platformu. V takovém případě stačí modifikovat pouze několik zdrojových souborů, které jsou přímo závislé na platformě. Jak QuickTime Streaming Server, tak Darwin Streaming Server jsou freeware. Provozování serveru je také bez poplatků (některé servery pro streaming mají například zpoplatňovaný počet datových toků, které server využívá). Přestože je tato technologie bezplatně k dispozici, nezříkáte se ani výkonu, ani škálovatelnosti. Hranice využitelnosti leží řádově u tisíce proudů

9 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 5, díl 9, str. 9 na jeden server, ovšem je možné využít pro vysílání serverů více. QuickTime Streaming Server 3 má vestavěnou vlastnost nazvanou skip protection - ochranu proti přeskakování. Jak již název napovídá, jedná se o způsob odstranění přerušení či skoků v streamovaných multimediálních prezentacích. Technologie skip protection funguje tak, že používá všechnu přebytečnou šířku komunikačního kanálu k přenosu vyššího množství dat, než je potřeba k přehrávání. Pokud se nějaké pakety po cestě ztratí, datový tok přehrává z místní vyrovnávací paměti. Výsledkem toho je nepřerušovaný zážitek z multimediální prezentace. V poslední době se stalo velmi populární zavádění televizního vysílání prostřednictvím IP sítí. I když se tato oblast i v souvislosti s digitálním vysíláním silně popularizuje, existuje zde řada problémů o kterých se diskrétně mlčí. Z hlediska vysílání můžeme rozlišit několik druhů tohoto vysílání. Jednak je to Video on deamand a jednak je to živé vysílání prostřednictvím streamu. Z hlediska technologie přenosu je třeba říci, že rozumným způsobem pro živé vysílání je využití protokolů IP, nad ním protokolu UDP a nad ním pak protokolu RTP/RTPC. Z hlediska způsobu distribuce signálu k odběratelům (klientům) se pak rozlišuje především unicast a multicast. Unicast při vysílání z jednoho zdroje je silně omezen kapacitou přenosové trasy. Např. při vysílání se šířkou pásma 2 Mbps pro jednu relaci se kapacita spoje u vysílacího serveru při klientech vyšplhá na úctyhodných 2 Gbps, což je běžná kapacita jednoho optického vlákna. Je třeba si také uvědomit, že pro digitální televizi 2 Mbps není použitelná šířka pásma, ale spíše 10-20x tolik. Při tom všichni víme, že televizní vysílání i v našem malém státě běžně sledují miliony diváků. Problém zajištění dostupnosti

10 část 5, díl 9, str. 10 BEZPEČNÁ POČÍTAČOVÁ SÍŤ Z tohoto pohledu se unicast, který by docela dobře splňoval požadavky na možnost zabezpečení přenosu od vysílače ke klientovi, jeví jako perspektivně nepoužitelný. Protože ke každému klientovi jde separátní kanál, není problém tento kanál šifrovat či proudově podepisovat. Přitom podepisování živého proudového vysílání není zase až tak triviální záležitostí (protože při příjmu signálu a jeho zobrazení máme vždy k dispozici pouze kousek celé informace). Je to věc ovšem řešitelná. Problém s omezeným počtem uživatelů je problém zásadní. Existuje celkem známá cesta, jak z tohoto problému ven. Tou cestou je použití technologie multicastu, kde z vysílacího serveru jde pouze jeden proud dat a ten se postupně na jednotlivých směrovačích rozvětvuje ke klientům. Díky této technologii se zátěž páteřní sítě nezvyšuje s narůstajícím počtem klientů. Mohlo by se zdát, že problém je vyřešen. Vznikají však některé další problémy: 1. Není možné jednoduše zabezpečit trasu mezi serverem a zvláště každým klientem. 2. I pro protokol RTP/RTPC existují množstevní omezení pro počet klientů, nad kterým se výrazně omezí dostupnost vysílání i pro multicast. To si ukážeme níže. Pro protokol RTP existuje také bezpečná varianta, a to protokol SRTP (Secure Real-time Transport Protocol), který je upraven prostřednictvím standardu RFC V tomto případě jde vlastně o zašifrování určité porce dat v rámci paketu definovaného dle RFC V normě je šifrování definováno prostřednictvím 128 bitových bloků AES-f8. Zpětnou signalizaci pak provádí analogicky zabezpečený protokol SRTPC. Mandatorně je používán AES-CM pro šifrování, HMAC-SH1

11 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 5, díl 9, str. 11 pro integritu a AES-CM pro odvozené klíče. V každém fixním proudu může být klíč použit maximálně jedenkrát. Master keys mohou být použity i napříč streamy. Tímto způsobem je bezpečnost limitována. Při rychlosti např. 200 SRTPC paketů za sekundu je maximální možná doba streamu asi 4 měsíce. Protokol může být použit i při ochraně proti opětovnému přehrávání audia nebo videa. Dalším rozšířením protokolu SRTP je pak protokol ZRTP, který k definici v normě přidává mechanismy pro počáteční výměnu klíčů. Produktem, který využívá tuto technologii, je např. ZPHONE. Reálně to funguje tak, že pod vlastní VoIP je vnořena vrstva (něco jako SSL PROXY), která zajišťuje bezpečnost. To je ovšem řešení spíše pro systémy komunikace jeden s jedním. 3. Nefunguje rozumný přenos multicastu mezi operátory, takže můžeme předpokládat, že dané vysílání uvidíme pouze u svého poskytovatele připojení, pokud je bude poskytovat. Nějaké celointernetové multicastové vysílání nebude možné bez další specifikace přenosových technologií a standardů. 4. Není rozumně možné individuálně zabezpečit přenos signálu zvlášť pro každého klienta. Vydání stejného klíče všem klientům není zrovna nejlepším řešením zabezpečení. Na takto zabezpečeném satelitním vysílání vyrostly celé generace hackerů a celý průmysl, který se zabývá prolamováním ochrany šifrovaných kanálů. Aby dopad multimediálního vysílání zcela neparalyzoval infrastrukturu, je pochopitelně třeba použít něco jiného než unicast. Rozsáhlá diskuse k tématu nedávno proběhla na internetu v článku M. Krska. Možná řešení

12 část 5, díl 9, str. 12 BEZPEČNÁ POČÍTAČOVÁ SÍŤ My na rozdíl od Michala Krska vycházíme z předpokladu, že vlastní šíření signálu je dávno vyřešeno a nepředstavuje problém. Možná není v sítích implementováno odpovídající řešení, ale teoretický problém v této oblasti není. Řešením je zde SSM - Specific Source Multicast, ale pouze v oblasti šíření datového obsahu. Existují však i jiné problémy. Ty spočívají v protokolu RTP/RTPC, kde dle definice zpětné odezvy protokolu, kterou se např. poskytují informace o kvalitě přeneseného signálu, vychází, že podle klasických vzorců dle RFC 1350 a 1351 je interval reportu přímo úměrný počtu klientů. Např. při divácích (což pro klasické televizní vysílání není žádné velké číslo) bude tento interval už 33 minut. Taková odezva je prakticky nepoužitelná. Existuje několik možných řešení tohoto problému. Jednou je modifikace šíření signálu o koncentraci zpětných vazeb na síťových prvcích. Tato cesta má některá úskalí. Ta spočívají v tom, že síťový prvek by musel řešit řadu úloh, které mu nejsou vlastní, muselo by dojít k implementaci těchto algoritmů výrobcem apod. Z krátkodobého hlediska se jedná o dostatečně neprůchozí variantu. Druhou variantou je, že roli koncentrátora zpětného toku převezmou někteří klienti. V takovém případě, velmi zjednodušeně řečeno, vznikne jakási reverzní situace k technologii CDN. To vyžaduje malou úpravu protokolu, ale teoretická rychlost odezvy pro klientů klesne z výše uvedených 33 minut na cca 30 sekund a to je snížení docela podstatné. Pro klientů pak teoreticky klesne z úctyhodných 5 hodin na 50 sekund.

13 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 5, díl 9, str. 13 Vývoj nárůstu potřeby páteřní kapacity ukazuje následující graf, ze kterého je zřejmé, že při zátěži koncových linek uživatelů je potřeba růstu kapacity páteře při SSM multicastu minimální. Rostoucí křivka odpovídá unicastu. G Následující dva grafy srovnávají interval odezvy pro klasické RTP/RTPC s metodou agregace ve dvou hierarchických úrovních. Otázka vhodného počtu úrovní pro optimální odezvu je momentálně otázkou teoretické analýzy. Z hlediska praktické použitelnosti se do klientů jeví počet dvou úrovní dostatečný. Klasické schéma dle RFC 1350, 1351 vypadá následovně: Poãet klientû Sekund odezvy Minut odezvy Hodin odezvy 10 0, , , , , , T

14 část 5, díl 9, str. 14 BEZPEČNÁ POČÍTAČOVÁ SÍŤ G T Při použití hierarchie se situace dost podstatně vylepší. Následující tabulka ukazuje pouze dvouúrovňovou hierarchii. V této struktuře se dokonce dá podle požadované odezvy navrhnout potřebná hierarchie. I v případě, kdy se nesnažíme nějak minimalizovat dobu odezvy, je vidět, že situace je rozhodně optimističtější. Poãet klientû Poãet uzlû Poãet respondentû Sekund odezvy ve skupinû , , Situace je dosti podobná technologii CDN, ale jaksi v reverzní podobě. Uzly nerozdělují tok dat, ale naopak jej integrují. Případně se to dá chápat jako P2P naopak.

15 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 5, díl 9, str. 15 G Odezva v s. Co říci na závěr? Možná jenom to, že ani multicast sám o sobě není schopen řešit problém velkého počtu respondentů multimediálního vysílání. Metody, které v této oblasti nastupují, v mnohém připomínají metody řešení problémů s pomocí neuronových sítí. Mimo simulace sítí je možné popsat řadu parametrů protokolu RTP/RTPC matematicky a dobrat se k podobným výsledkům * Rychlost * Odezva Počet klientů = ; Velikost paketu Z tohoto vzorce pak můžeme bez problémů vyjádřit dobu odezvy a získat hodnotu, která byla uvedena v předchozí tabulce. Analytické řešení 0.75 * 5 * 10 4 * X 10 5 = ; X = 1963 s; X = 33 minut 736 Teoretickým řešením je, jak bylo uvedeno již výše, použití hierarchie. Pro zjednodušení řešení přijmeme některé předpoklady. V podstatě ne všichni klienti budou odesílat informace serveru, ale informace budou

16 část 5, díl 9, str. 16 BEZPEČNÁ POČÍTAČOVÁ SÍŤ sdružovány po skupinách a budou existovat specializovaní klienti, kteří informace budou slučovat a odesílat dále. Budeme předpokládat, že: 1. skupiny mají stejný počet členů, 2. odezvy všech skupin a všech klientů jsou stejné, 3. délky všech paketů protokolu RTPC jsou stejné, 4. strom hierarchie je vyvážený. V takovém případě bude platit následující vzorec: 0.75 * Rychlost i Počet klientů = ( ) * X i Velikost paketu Doba odezvy jedné skupiny klientů v hierarchii se dá vyjádřit následujícím způsobem: 736 X i = i Počet klientů * 5 * 10 4 * 0.75 Celková doba odezvy ode všech klientů k centrálnímu serveru bude vypadat následovně: 736 X = { i * i Počet klientů * } 5 * 10 4 * 0.75 Problémem tohoto vzorce je ten, že obsahuje parametr i, který odpovídá úrovni hierarchie. Možná je na místě pokusit se zjistit, zda existuje něco, jako je optimální úroveň hierarchie pro daný fixní počet klientů. Jinými slovy je třeba najít hodnotu optimálního i, a to i i 0 = Argmin { i * i Počet klientů * } 5 * 10 4 * 0.75

17 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 5, díl 9, str. 17 Pokud si odmyslíme konstanty, které na hodnotu argumentu minima nemají vliv, pak vlastně hledáme minimum parametrické funkce. Řešením je hodnota: f(i) = i * i n i 0 = 1n (n); Optimální úrovně hierarchie jsou uvedeny v následující tabulce. Poãet klientû Optimální úroveà hierarchie T Docela poučné může být zjištění, jak se s úrovní hierarchie obecně mění velikost odezvy, a zhodnocení, zda řízení hierarchických úrovní stojí za přínos v oblasti odezvy protokolu. Tuto situaci zobrazuje následující tabulka.

18 část 5, díl 9, str. 18 BEZPEČNÁ POČÍTAČOVÁ SÍŤ T Hierarchie/ poãet klientû X X X X X Minima jsou označena silně a rozumné hodnoty jsou zvýrazněny šedým pozadím. Minima jsou totiž velmi plytká a jejich dosažení bude náročné z hlediska řízení celé struktury hierarchie. Situace velmi připomíná situaci, která funguje v p2p sítích, ale jaksi naopak, zde se prostřednictvím takové hierarchie nešíří obsah, ale sbírají se zpětné informace o vysílání od klientů k vysílacímu serveru. Tato strategie je pochopitelně použitelná, ale vyžaduje odpovídající úpravu protokolu RTP/RTPC a speciálně vytvořené klienty, z nichž někteří budou plnit roli sumarizačních center. Plánování takových služeb není jednoduché a bude vyžadovat logiku podobnou fungování výměnných sítí.