Statistiky sledování televize

Transkript

1 Statistiky sledování televize Semestrální práce (36SEM) ZS 2005/2006 Martin Fiala FEL ČVUT 5.ročník

2 - 2 -

3 Obsah 1. Úvod Digitální vysílání Převod přijímaného signálu na lokální síť Sběr statistik Vyhodnocování statistik Multicastové vysílání Multicastová adresa IGMP Formát IGMPv Formát IGMPv Sledování stavu všech účastníků skupiny IGMP snooping Sběr statistik Síť s hloupými přepínači L2 přepínač se zapnutým IGMP snoopingem Kombinace předchozího Vyhodnocování Závěr

4 1. Úvod Na vysokoškolských kolejích ČVUT působí kolejní kluby Studentské unie ČVUT ( su.cvut.cz/). Tyto kluby se starají nejen o připojení svých členů k internetu, ale v poslední době se snaží nabízet i další služby, mezi které patří šíření multicastových vysílání do lokálních sítí [1] [2]. Mezi zdroje multicastového vysílání patří vysílání přijímaného DVB signálu po IP protokolu, dále je to pak přijímání některých multicastových kanálů ze světa. Pro zjištění využívání služeb jsem se pokusil vyvinout software pro sledování statistiky přijímaných multicastů. Obecně je poměrně obtížné sledovat, kudy data tečou, musíme tedy kombinovat několik způsobů v závislosti na použitých aktivních prvcích sítě. 1.1 Digitální vysílání Už nějakou dobu funguje digitální vysílání TV, tzv. DVB = Digital Video Broadcasting, a to i v našich končinách. Toto vysílání se dělí na DVB-S (satelitní) a DVB-T (terestrialní). DVB-T, neboli pozemní digitální vysílání je nový způsob přenosu televizního signálu, který postupně nahradí současné analogové televizní vysílání. Na jednom kanále o kapacitě až 23Mbps se vysílá tzv. multiplex, což je sada několika televizních kanálů a radiostanic v datovém formátu MPEG-2. Do multiplexu je možné poskládat kanály v různých kvalitách. Na jednom tuneru je tedy možné s jednou naladěnou frekvencí chytat najednou třeba 5 televizních kanálů a z nich si pouze jeden vybrat a sledovat ho. Podobně je však možné celý přijímaný multiplex šířit dál bez úprav po zcela jiném médiu, po IP protokolu nad širokopásmovým připojením. 1.2 Převod přijímaného signálu na lokální síť Digitální signál je přijímán na počítači vybaveném DVB-T kartou, přijímaný multiplex je rozdělen na jednotlivé kanály a vysílán na různé multicastové IP adresy, to vše pomocí software VideoLAN ( Uživatel si vždy přihlásí jen kanál, o který má v danou chvíli zájem. Přihlášení i odhlášení kanálu se provede pomocí IGMP paketu, který putuje k nejbližšímu multicastovému routeru, kde je možné tento paket odchytit a zaznamenat tuto událost do databáze. 1.3 Sběr statistik Protože je nutné multicastové pakety sbírat na daném multicastovém routeru, potřebujeme nějakou možnost, jak toto na routeru sledovat. Poměrně jednoduchá situace nastává při použití linuxového routeru, kde připravíme vlastní aplikaci sledující paketový provoz na vnitřním síťovém rozhraní. Ovšem tento způsob sběru statistik funguje pouze za předpokladu, že pou

5 žité aktivní přepínače v síti jsou hloupé L2 zařízení, které nepodporují či nemají aktivovaný IGMP snooping. V případě použití přepínačů se zapnutým IGMP snoopingem budeme muset statistiky sbírat přímo na těchto zařízeních. 1.4 Vyhodnocování statistik Nashromážděné statistiky můžeme později vyhodnocovat, určit přibližně počet uživatelů sledujících danou stanici, určit, jak často uživatelé přepínají kanály a v jaký časový okamžik, a určit statistiku sledování kanálů za nějaké období, kolik hodin týdně průměrný uživatel sleduje televizi a kolik lidí se dívalo na konkrétní pořad. K tomu nám postačí skripty napsané např. v PHP či Pythonu, grafy můžeme vykreslovat pomocí knihovny GD. 2. Multicastové vysílání K pochopení multicastového vysílání si nejdříve budeme muset objasnit některé pojmy. Výhody multicastového vysílání protí broadcastu a multicastu jsou zřejmé. Při broadcastu se vysílají pakety ke všem strojům na stejné síti, což způsobuje zbytečné zahlcení jejich síťových rozhraní a také zbytečné zatěžuje procesor při zkoumání paketů, které přijímat nechceme. Při unicastu jsou naopak kladeny velké nároky na zdroj vysílání, z kterého se stává úzké hrdlo systému. Pro náš případ šíření digitálního signálu televizního vysílání po lokální síti si tedy ani jiný způsob než multicast nelze představit [3] [4]. Pro správnou funkci multicastů budeme potřebovat multicastovou adresu. 2.1 Multicastová adresa Multicastová adresa je IP adresa třídy D, tedy všechny IP adresy v rozsahu až jsou multicastové IP adresy. Někdy se také označují jako GDA (=Group Destination Addresses). Některé multicast adresy jsou vyhrazené pro zvláštní účely, adresy v rozsahu jsou lokální linkové, je zakázané je forwardovat za hranice lokální sítě, také pro tyto IP adresy zpravidla nefunguje IGMP snooping, provoz je vysílán broadcastem na všech portech Level 2 přepínače. Multicastové adresy v rozsahu přiděluje známá organizace IANA. V privátních sítích se používají adresy s administrativně omezeným rozsahem Vybrané multicast adresy naleznete v tabulce [5]. multicastová IP adresa význam všechny počítače schopné multicastu všechny routery schopné multicastu - 5 -

6 multicastová IP adresa , OSPF routery RIPv2 routery IGMPv3 routery význam 3. IGMP Budeme uvažovat pouze IGMP verze 2 a 3, IGMP verze 1 dnes již využívá jen malé množství zařízení a operačních systémů. Hlavním rozdílem verze 1 proti novějším je to, že příjemci multicastového vysílání nemají možnost routeru oznámit, že si již nepřejí přijímat daný multicast stream. Toto se ve verzi 1 dělalo pouze vypršením časového limitu, v novějších verzích se odhlášení provádí k tomu určeným IGMP paketem. Následující popis je zjednodušený, ale obecně platí pro všechny verze IGMP. Aby se ušetřil síťový provoz, posluchači naslouchají síťovému provozu a pokud uslyší, že někdo poslouchá jejich skupinu, sami se už neohlásí. To nám ovšem v našem sbírání statistik způsobí značné problémy. Počítače nebo IGMP router (v závislosti na verzi IGMP) si udržují čítač, který má za úkol periodické ohlašování účasti ve skupině. Podíváme se nyní podrobněji na strukturu paketů verzí 2 a Formát IGMPv Type Max Resp Time Checksum Group Address Type - typ zprávy 11=Query - General a Group Specific (dle obsahu pole Group Address) 12=IGMPv1 Membership Report 16=IGMPv2 Membership Report 17=Leave Group Max Resp Time - maximální čas u Query na zaslání reportu v desetinách sekundy Checksum - kontrolní součet Group Address - multicastová adresu - 6 -

7 Narozdíl od verze 1 je zde možnost odhlásit se ze skupiny pomocí zprávy Leave Group na adresu [6]. Většina dnešních L2 i L3 zařízení a operačních systémů již s podporou IGMPv2 nemá problémy a zvládá IGMP snooping. Účastník skupiny, který si přeje ukončit své členství a byl posledním, kdo hlásil routeru svoji účast ve skupině, pošle Leave Group zprávu. Router obdrží odhlašovací zprávu, vyšle do skupiny Group Specific Query, aby zjistil, zda ještě někdo poslouchá skupinu. V kladném případě obdrží odpověď opět jen od jednoho účastníka a vysílání dané skupiny je zachováno. 3.2 Formát IGMPv3 Tento formát je složitější než IGMPv2, jeho struktura je podobná, ale paket má variabilní délku [7]. Zásadní změnou proti přechozím dvěma protokolům je, že je možné uvést zdroje v rámci skupiny, které si přejeme poslouchat. IGMPv3 Report se neposílá do příslušné skupiny, ale na adresu Rozeznáváme opět více typů zpráv: 11=Membership Query 22=IGMPv3 Membership Report 12=IGMPv1 Membership Report 16=IGMPv2 Membership Report 17=IGMPv2 Leave Group Ačkoli tento formát podporují některé operační systémy a L3 prvky (routery), mnoho jednodušších zařízení, typicky L2 switchů si s ním příliš neporadí a dokonce se doporučuje v takovém případě na přepínačích vypnout IGMP snooping. Budeme tedy dále uvažovat pouze IGMPv2 pakety. 3.3 Sledování stavu všech účastníků skupiny Naštěstí pro nás, při zapojení do skupiny, kterou účastník předtím neposlouchal, pošle Membership Report. Tento si poznačíme do databáze a v pravidelných intervalech budeme posílat všem v seznamu vlastní IGMPv2 Group Specific Query, ale s MAC adresou účastníka. Takto by nám měl odpovědět každý účastník zvlášť, neuslyší totiž odpověď od jiného účastníka. Tuto vlastnost využijeme na síti bez L2 prvků s podporou IGMP snoopingu

8 3.4 IGMP snooping Konečně bychom se měli podívat na to, k čemu je vlastně onen IGMP snooping. IGMP pakety jsou určeny totiž především pro router, aby přijímal zvenku pouze skupiny, které mají alespoň jednoho účastníka. Struktura paketů pro L2 prvky není právě nejjednodušší, ty potřebují speciální HW, který přečte obsah paketu na L3 vrstvě a poznačí si číslo portu u odpovídající GDA adresy. Přepínače si tedy udržují seznam multicastových adres a portů s účastníky skupin. Hloupé přepínače touto informací nedisponují, a tak přijímaný multicastový provoz posílají na všechny porty, jak je možné vidět na obrázku, kde počítač A vysílá do skupiny s účastníky B a C. Přepínače s aktivovaným IGMP snoopingem však ví, kdo je ve skutečnosti účastníkem skupiny, a tak vysílají provoz pouze na patříčné porty, jak můžeme vidět na dalším obrázku [8]

9 Zároveň se přepínače snaží šetřit provoz IGMP paketů, pokud je na přepínači více členů jedné skupiny, vysílají směrem k routeru pouze jeden paket s informací Membership Report. Zároveň pokud na nějakém portu přepínač přijme Leave Report, pošle nejdříve na port Query, protože neví jistě, zda na portu nebylo více účastníků. Chová se tedy podobně jako multicast router. V případě, že se ze skupiny odhlásili všichni účastníci, přepošle Leave Report výše, tedy na port routeru, který musí mít přepínač poznačený. Přepínač tedy ještě má další úkol - sleduje všechny porty a hledá IGMPv2 Query, PIM zprávy a další, které může očekávat pouze od multicast routeru. Takový port si tedy označí a předpokládá, že přes něj vede cesta k multicast routeru. 4. Sběr statistik 4.1 Síť s hloupými přepínači V síti s přepínači bez podpory IGMP snoopingu nám nezbývá nic jiné, než sledovat IGMP zprávy, ty je možné sledovat v prakticky libovolném bodě sítě, neboť přepínače je posílají bez rozdílu vždy na všechny porty. Využíjeme tedy sledování přihlašování hostů s poznačením jejich IP adresy do databáze a napíšeme si speciální aplikaci, která bude periodicky vysílat - 9 -

10 Query s MAC adresou hosta. Tímto způsobem by nám měl každý na náš dotaz odpovědět, pro jistotu se budeme v daném časovém intervalu dotazovat vždy pouze jednoho potenciálního účastníka skupiny. Zatížení sítě se již zásadně nezvýší. Pro jednoduchost lze také předpokládat, že účastník se stejnou IP adresou bude vždy najednou sledovat pouze jeden televizní kanál, bude tedy účastníkem pouze jedné skupiny. Pošle-li tedy Membership Report do jiné skupiny, aniž by poslal odhlašovací Leave Group, budeme předpokládat, že starou skupinu již také nesleduje. 4.2 L2 přepínač se zapnutým IGMP snoopingem V síti s přepínači s IGMP snoopingem budeme muset použít zcela jiné řešení, neboť pakety se za přepínač šíří jen omezeným způsobem. Přitom samotný přepínač zná účastníky jednotlivých skupin. Je tedy třeba vhodným způsobem sbírat periodicky informace z přepínače a ukládat je do databáze. Logicky se nabízí možnost sbírat data přes SNMP, bohužel většina přepínačů tuto informaci přes SNMP jednoduše nenabízí, zřejmě nebyl vyvinut dostatečný tlak na výrobce, aby tuto informaci obsáhli do SNMP. Měl jsem možnost sběr vyzkoušet na přepínači Cisco Catalyst 2950, po značném zkoumání se bohužel jedinou možností jeví sbírat data přímo z konzole zařízení, k čemuž je potřeba se k zařízení přihlásit (telnet/ssh) a zadat příkaz sh ip igmp snooping group. Tento příkaz nám vytiskne poměrně přehlednou tabulku, kde vlevo je IP adresa skupiny a vpravo seznam portů. Je třeba tuto tabulku vhodně zpracovat skriptem a data uložit do databáze. Chybí nám zde ovšem vazba portu na IP adresu, statistika tedy nebude tak zajímavá. 4.3 Kombinace předchozího Tato síť nám přinese zřejmě nejvíce problémů a případně zkreslených statistik. Pakety proudící z přepínače směrem k routeru se nám budou šířit po celé síti, naopak pakety ze zbytku sítě nám budou pronikat na router port přepínače a zkreslovat statistiky. Bohužel, pokud centrální přepínač nebude disponovat podporou IGMP snoopingu, nelze tuto situaci prakticky řešit a budeme se muset spokojit i s mírně zkreslenými statistikami. 5. Vyhodnocování Záznamy o účastnictví ve skupinách máme uložené v databázi a můžeme se pustit do jejich zpracování - buď jednorázové offline nebo průběžné na vyžádání. S rostoucí velikostí sítě bude zpracování na vyžádání časově náročnější, a tak bude vhodné data nějakým způsobem předzpracovat dle potřebných datových pohledů. Na ukázku jsem zvolil zpracování na

11 vyžádání pomocí databáze MySQL a PHP skriptů. Podrobnější statistiky jsou již nad rámec této práce. 6. Závěr Můj původní záměr se po důkladnějším prostudování problematiky jako dosti obtížný a těžko implementovaný obecně, je třeba ho do značné míry přizpůsobit na konkrétní podmínky. Podobné projekty, které se věnují sledování multicastového provozu se zabývají sledováním toku dat mezi routery, které pro náš účel není příliš zajímavé, neboť s již více než 100 lidmi na jedné lokální síti je více než pravděpodobné, že určitý televizní kanál bude sledovat alespoň jeden účastník. Navrhl jsem tedy možné způsoby, jak situaci řešit a dopátrat se nějakých užitečných statistik, které se do značné míry blíží skutečnosti. Zároveň jsem tyto své závěry ukázkově implementoval a dokázal, že by to takto mohlo fungovat. Statistické zpracování nasbíraných dat se může stát úkolem pro práci někoho dalšího

12 Seznam použité literatury [1] Rastislav Macko, Pavel Dobiáš, "Digital Video Broadcasting", 2005, [2] klub Pod-O-Lee, Studentská unie ČVUT, "Streamování digitální televize na síti Pod-O- Lee", 2004, [3] Cisco Systems, Inc., "IP Multicast Technology Overview", 2002, [4] Ondřej Filip, "Úvod do IP multicastu", 2004, [5] The Internet Corporation for Assigned Names and Numbers (IANA), "INTERNET MULTICAST ADDRESSES", 2006, [6] W. Fenner [Xerox PARC], "RFC 2236: Internet Group Management Protocol, Version 2", 1997 [7] B. Cain [Cereva Networks], S. Deering [Cisco Systems], I. Kouvelas [Cisco Systems], B. Fenner [AT&T Labs - Research], A. Thyagarajan [Ericsson], "RFC 3376: Internet Group Management Protocol, Version 3", 2002 [8] Cisco Systems, Inc., "Multicast in a Campus Network: CGMP and IGMP Snooping", 2005,