Úvod do IP multicastu

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.

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ď N² 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í.