Hlavní navigace

Úvod do IP multicastu

Ondřej Filip 10. 9. 2004

Nedávno jste si na Lupě mohli přečíst o rozdílech mezi anycastem a multicastem. Ačkoliv je technologie IP multicastu již poměrně stará a využívá ji i taková slovutná instituce, jakou je newyorská burza, není díky jejímu malému rozšíření mezi uživateli příliš známa. Pojďme se v krátkém seriálu seznámit s jejími základními principy.

Rozdíl mezi multicastem a běžným způsobem komunikace mezi dvěma počítači, tedy unicastem, jsem se snažil znázornit ve svém článku o anycastu.

Pro jistotu ještě všechny druhy komunikace zrekapituluji. Při unicastu jsou data ze zdroje přijímána pouze jedním příjemcem. V případě anycastu je příjemcem pouze jeden z vybrané skupiny. Při broadcastu příjímají data všichni účastníci a při multicastové komunikaci přijímá data pouze vybraná skupina ze všech účastníků.

Kde se vzal multicast

Dějiny implementace multicastu ve světě Internetu se datují začátkem osmdesátých let minulého století. Tehdy postgraduální student Stanfordské University Steve Deering začal pracovat na distribuovaném operačním systému Vsystem. Tento systém se původně skládal z několika počítačů propojených mezi sebou na jednom ethernetovém segmentu. Tyto stroje si posílaly zprávy pouze pomocí ethernetového multicastu. Růst projektu vyžadoval zapojení více počítačů a naštěstí (tedy teď se dívám z pohledu rozvoje multicastu) jediné volné stroje byly až v jiné budově university. Propojení s tamní sítí bylo realizované pomocí protokolu IP přes routery a tedy přímé posílání zpráv přes ethernet nebylo dále možné.

Ukázalo se tedy nutné převést komunikaci mezi počítači z ethernetových rámců do světa IP packetů. S tím se objevil problém, jak ve světě IP protokolů používat skupinové adresování, multicast. Právě vyřešením tohoto problému byl pověřen Steve Deering. Ve své práci mimo jiné navrhnul způsob, jak multicastové packety adresovat, posílat sítí, navrhl jak rozšířit link-state routovací protokol OSPF o podporu multicastingu (MOSPF), navrhl nový vektorový routovací protokol na bázi RIP (DVMRP) a navrhl základy protokolu IGMP. Své výsledky shrnul ve své doktorské práci „Multicast Routing in a Datagram Network“ ( [Část 1 – 991 Kb postscript] [Část 2 – 794 Kb postscript] [Část 3 – 592 Kb postscript] )

Na jeho dílo navázala řada dalších a již kolem roku 1992 vznikla první experimentální IP multicastová sít MBone. V současné době je multicast podporován především u akademických a výzkumných sítí, komerční poskytovatelé mají v této oblasti obvykle hodně co dohánět. V České republice není situace nijak specifická, o malém používání IP multicastu svedčí i fakt, ze tento druh dat si nevyměňují ani poskytovatelé v rámci propojovacího uzlu NIX.CZ.

Co je uvnitř

Na první pohled se multicastový packet v ničem neliší od běžného unicastového. Jediný rozdíl tkví v tom, že cílová IP adresa je z rozsahu adres D. Znalci si možná pamatují že dříve byly IP adresy rozdělené mezi rozsahy A, B, C, D a E. Po zavedení CIDR (classless inter-domain routing) se rozdíl mezi rozsahy A, B a C smazal, a dnes se použití adres z těchto rozsahů nijak neliší. Nicméně použití adres z D i nadále zůstala zcela odlišné. Tyto IP adresy se poznají tak, že první oktet začíná na v binárním vyjádření na 1110 a tedy adresy leží v rozsahu 224.0.0.0 – 239.255.255.255.

Ačkoliv multicastový packet je zcela stejný jako běžný unicastový, zpracování takového packetu routerem má jednu velmi výraznou odlišnost. U unicastového packetu se router pouze jednoduše rozhodne, kterým směrem ho (pokud vůbec) přepošle. V případě multicastového routování může být dalších destinací více a router musí v takovém případě takový packet zreplikovat. To přírozeně routery trochu více zatěžuje a zároveň je nutné velmi pečlivě sledovat, zda-li se toto množení neděje nadměrně, aby protistrana nedostávala svá data zbytečně ve více kopiích a neplytvalo se tak s pásmem. Příklad průběhu packetu sítí znázorňuje následujíci obrázek.

1335

Na tomto příkladu se routery B, C, D, G musely postarat o duplikaci packetu.

Aby síť věděla, kam má packet směřovaný na nějakou multicastovou adresu posílat, je nutné, aby se koncový stroj k používání takové adresy zaregistroval. Routery pak musí být schopny spočítat optimální cestu pro průchod a duplikaci packetů pro všechny přihlášené.

K čemu je tedy IP multicasting tedy vhodný? Především se zcela dokonale hodí pro aplikace, kdy jeden zdroj posílá velkému množství klientů stejná data, tedy hlavně jde o internetové vysílání rozhlasu či televize. Zde jsou výhody zřejmé. Vysílač posílá své vysílání pouze multicastové skupině a o duplikace se stará síť v místě, kde to je optimální. Výrazně se tím zmenšuje zatížení sítě a také zátěž vysílacího stroje. Například zmíněná burza tímto způsobem distribuuje data svým klientům. Poněkud komplikovanějším případem předchozího jsou konferenční hovory. Zapojení více uživatelů do hovoru vyžaduje v unicastovém prostředí buď N2 vzájemných relací mezi účastníky nebo v lepším připadě musí existovat centrální server, který se duplikaci dat stará. I on může být přetížen či připojen nedostatečnou kapacitou k síti. Použitím IP multicastu tento problem odpadá.

Nicméně IP multicast není žádný univerzálně použitelný prostředek. K jeho největší slabinám patří fakt, že není schopen provádět spolehlivý přenos dat, tedy není možné přes něj přenášet protokol TCP. Problém tkví právě v té spolehlivosti. TCP striktně vyžaduje opětovné posílání dat, která se ztratila po cestě. Síť by si tedy musela pamatovat packety, které již přenesla a to by neúměrně zatěžovalo routery, jiný problém by byl s přenosem potvrzení od doručení od všech příjemců. Aplikace využívající IP multicast jsou tedy převážně založené na protokolu UDP a se ztrátou informací prostě musí počítat.

Abych nemluvil jen pouze abstraktně, raději uvedu konkrétní případy aplikací, které multicast využívají. Právě díky projektu MBone dostali uživatelé pěkné dárky. Prvním je aplikace Robust Audio Tool (RAT), což je ukázkový příklad využití multicastu. Tento open source software použitelný na mnoha platformách zprostředkovává konferenční hovory. O video se pak stará příbuzná aplikace Videoconferencing Tool (VIC). Příjemnou zprávou pro internetovou většinu, jež k multicastu přístup nemá, je fakt, že obě aplikaci dokáží fungovat i v unicastovém prostředí, nicméně pochopitelně zde mají vyšší spotřebu konektivity.

Nezůstávejme ale pouze líbivých okeních aplikacích. Multicast může zjednodušit například i časovou synchronizaci. UNIXový démon NTP se je schopen synchonizovat s počítači v multicastové skupině. Správa takového systému je pak jednodušší. Například přidání dalšího časového serveru pak obnáší pouze jeho přihlášení do multicasatové skupiny. Vyhledávání okolních serverů si již pak vezme na starost siť.

První díl našeho miniseriálu, obecný úvod, končí. V díle příštím se pokusíme podívat trochu hlouběji do principů multicastového routingu a adresování.

Anketa

Převáží podle vás někdy internetové televizní vysílání nad "klasickým?"

Našli jste v článku chybu?

13. 10. 2008 22:55

Alim (neregistrovaný)
To se trochu pletete, zrovna na Kolejích to je plně legální bez jakékoliv licence a smluv. Níže to trochu vysvětlí, Nepamatuji si ale přesné právnické termíny, ale pokusím se bíti přesný.

Protože stremování TV a rozhlasu se nepovažuje za vysílání a není na to tudíž třebažádné povolení ani licence za předpokladu, že streamy mají nezměněný obsah, a streamuje se pro uzavřenou skupinu lidí která není větší než 100 jedinců, ve výjmečných případech může bíti i větší a to za předpokladu, že se všichni…

22. 4. 2008 15:48

uživatel si přál zůstat v anonymitě
Jenom opravuji kolegu, jedná se o §2 odst. 3 ZRTV ;-) (§3/3 se zabývá působností zákona, konkrétně odst. rozebírá, kdy se PO považuje za usazenou v ČR)
120na80.cz: Popraskané rty? Některé balzámy stav zhoršují

Popraskané rty? Některé balzámy stav zhoršují

Podnikatel.cz: Přehledná titulka, průvodci, responzivita

Přehledná titulka, průvodci, responzivita

Vitalia.cz: To není kašel! Správná diagnóza zachrání život

To není kašel! Správná diagnóza zachrání život

Měšec.cz: Zdravotní a sociální pojištění 2017: Připlatíte

Zdravotní a sociální pojištění 2017: Připlatíte

DigiZone.cz: Mňam TV splnila slib a odešla z DVB-T

Mňam TV splnila slib a odešla z DVB-T

Měšec.cz: Vklad na cizí účet je draze zpoplatněn (přehled)

Vklad na cizí účet je draze zpoplatněn (přehled)

Vitalia.cz: Spor o mortadelu: podle Lidlu falšovaná nebyla

Spor o mortadelu: podle Lidlu falšovaná nebyla

Vitalia.cz: Tesco: Chudá rodina si koupí levné polské kuře

Tesco: Chudá rodina si koupí levné polské kuře

Měšec.cz: Platby do zahraničí: pozor na tučné poplatky

Platby do zahraničí: pozor na tučné poplatky

Podnikatel.cz: K EET. Štamgast už peníze na stole nenechá

K EET. Štamgast už peníze na stole nenechá

120na80.cz: Rakovina oka. Jak ji poznáte?

Rakovina oka. Jak ji poznáte?

Lupa.cz: Google měl výpadek, nejel Gmail ani YouTube

Google měl výpadek, nejel Gmail ani YouTube

DigiZone.cz: Digi CZ výrazně zlevnila balíček HBO

Digi CZ výrazně zlevnila balíček HBO

120na80.cz: Bojíte se encefalitidy?

Bojíte se encefalitidy?

Vitalia.cz: Vláknina: Rozpustná, nebo nerozpustná?

Vláknina: Rozpustná, nebo nerozpustná?

Lupa.cz: Babiš: E-shopů se EET možná nebude týkat

Babiš: E-shopů se EET možná nebude týkat

Vitalia.cz: Chtějí si léčit kvasinky. Lék je jen v Německu

Chtějí si léčit kvasinky. Lék je jen v Německu

120na80.cz: Rovnátka, která nejsou vidět

Rovnátka, která nejsou vidět

Podnikatel.cz: Babiše přesvědčila 89letá podnikatelka?!

Babiše přesvědčila 89letá podnikatelka?!

Vitalia.cz: Znáte „černý detox“? Ani to nezkoušejte

Znáte „černý detox“? Ani to nezkoušejte