Až dosud jsme se v tomto seriálu zabývali technologiemi, které už dávno prokázaly, že patří do pomyslné internetové síně slávy. V dnešním pokračování se budeme zabývat multicastem, jenž o své místo na slunci stále bojuje a je otázka, zda se nakonec opravdu prosadí. Oč jde? Multicast se podobá například rozhlasovému vysílání. Zdroj vysílá data v jediné kopii a přijímat je může zároveň libovolný počet příjemců, pokud se naladí na správnou vlnu. V případě IP multicastu je ale rozdíl v tom, že v rámci jedné relace může zároveň vysílat i několik zdrojů.
Aplikace tohoto typu se v internetu zatím většinou řeší hrubou silou. Vezměme například běžná internetová rádia: pro každého klienta, který se připojí, se vytváří pomocí protokolu TCP samostatné datové spojení. To ovšem znamená, že server musí stejná data – v tomto případě zakódovaný zvuk – posílat v tolika kopiích, kolik je aktuálně připojených klientů. U velmi populárních zdrojů to může znamenat enormní zátěž jak pro vlastní server, tak i pro jeho připojení do internetu. Nejde ale jen o rádia. Viděli jsme například, jak zájem veřejnosti po červnových volbách do poslanecké sněmovny odrovnal server www.volby.cz. Stejně tak šly třebas po útocích na newyorská dvojčata do kolen všechny populární internetové deníky, rádia i televize. Funkční tehdy zůstaly jen ty zdroje, které vysílaly pomocí multicastu.
Deeringův model
Multicast je věcí poměrně novou. Objevil se v disertační práci, kterou v roce 1991 na Stanfordově univerzitě obhájil Steve Deering, mimochodem později také jeden z hlavních architektů IPv6. Základní idea je celkem jednoduchá: data vysílaná zdrojem se replikují podle potřeby ve směrovačích a posílají dále na ta síťová rozhraní, za nimiž se nacházejí zaregistrovaní příjemci dané relace.
Multicastové pakety se poznají snadno podle cílové adresy. Ta totiž v tomto případě neidentifikuje – alespoň ne přímo – příjemce dat, ale označuje skupinu, v jejímž rámci probíhá určitá datová relace, například videokonference nebo vysílání internetového rádia. V IPv4 se pro tento účel používá blok adres 224.0.0.0/4, zatímco v IPv6 je to blok FF::/8. Těmto adresám se říká multicastové, resp. skupinové. Pro odlišení od multicastu se standardní internetová spojení mezi dvěma účastníky označují jako unicast.
Multicast v lokální síti
Šíření multicastu v lokální síti (bez směrovačů) obvykle nevyžaduje žádná speciální opatření. Ve standardu Ethernetu je multicast definován a je pro něj vyhrazen blok MAC adres. Stačí tedy, aby se multicastové IP adresy vhodným způsobem zobrazily na MAC adresy a zbytek už obstará Ethernet.
| Reprezentantem IP multicastu v lokálních sítích je Internet Group Membership Protocol (IGMP), který byl, zřejmě kvůli zpestření nudných internetových standardů, pro použití v IPv6 přejmenován na Multicast Listener Discovery (MLD). Hlavní úlohou IGMP i MLD je informovat směrovače v lokální síti o přítomnosti koncového počítače, který má zájem o příjem určité multicastové skupiny. Od multicastových odesílatelů se naproti tomu žádná explicitní registrace nežádá: ti se totiž „prozradí“ přímo svými daty, jakmile je začnou vysílat. |
Směrování multicastu
Mnohem tvrdším oříškem je směrování multicastu v rozsáhlých sítích, respektive v celém internetu. Jde o to, aby se všechna data vysílaná v rámci konkrétní multicastové skupiny dostala všem přihlášeným příjemcům – a pokud možnou nikomu jinému. Tuto úlohu řeší multicastové směrovací protokoly.
Jak již víme, směrovací protokoly musí bezpodmínečně zajistit ochranu proti smyčkám, v nichž by datagramy obíhaly až do vynulování hodnoty TTL (Time-To-Live). V případě multicastu se pro tento účel používá metoda kontroly zpětné směrovací cesty (RPF, Reverse Path Forwarding): Směrovač přijme multicastový datagram jen z toho rozhraní, z něhož vede zpáteční (unicastová) směrovací cesta ke zdrojové IP adrese uvedené v hlavičce dotyčného datagramu. Pokud tomu tak není, datagram se zahodí.
Směrování multicastu se provozuje ve dvou režimech:
1. Hustý režim (dense mode) předpokládá, že příjemci konkrétní multicastové relace jsou téměř všude, takže každý přijatý multicastový datagram se implicitně posílá na všechna síťová rozhraní s výjimkou RPF rozhraní, z něhož datagram přišel. Nechce-li některý směrovač od svého souseda určitou skupinu dostávat, např. proto, že pro ni nemá žádné příjemce, musí mu to explicitně sdělit.
2. Řídký režim (sparse mode) vychází naopak z toho, že příjemců je relativně málo, a proto sám od sebe přijaté multicastové datagramy nikam neposílá, leda až o ně některý z jeho sousedů požádá.
Použití hustého režimu se dnes omezuje na privátní (firemní) sítě, které používají multicast pro interní aplikace s velkým počtem účastníků. V globálním internetu je ale jasným favoritem režim řídký, a to v podobě směrovacího protokolu PIM-SM (Protocol Independent Multicast – Sparse Mode), který je definován v RFC 4601.
Jestliže v hustém režimu dostává data každý směrovač, který se tomu aktivně nebrání, u řídkého režimu je problém přesně opačný: jak dát dohromady všechny odesílatele a příjemce, kteří se účastní dané multicastové relace? Odesílatelé totiž nevědí, kde se nacházejí příjemci a naopak. Protokol PIM-SM proto odesílatelům a příjemcům vytváří obecně známé místo pro setkání – rendezvous point (RP). Páteřní směrovač se pro tuto roli konfiguruje buď ručně, anebo častěji pomocí automatického mechanismu zvaného PIM-SM bootstrap.
Zdrojově specifický multicast
Řešení, které nabízí PIM-SM je poměrně komplikované – a to jsme se ještě nedotkli všech složitostí. Praktické zkušenosti ukazují, že spolehlivé provozování multicastu ve velkém je zatím chimérou. To je jeden z důvodů, proč se s nabídkou multicastu jako služby u internetových poskytovatelů téměř nesetkáme. Daleko větší šance se proto přisuzují zjednodušené variantě zvané zdrojově specifický multicast (SSM, Source-Specific Multicast). V tomto případě má každá multicastová relace jediného odesílatele a libovolný počet příjemců. Výhoda spočívá v tom, že IP adresa odesílatele je a priori známá, takže směrovače nepotřebují RP a mohou zprávy „PIM Join“ posílat přímým směrem k odesílateli.
SSM si vyžádal rozšíření protokolů IGMP a MLD, protože přijímající aplikace se musí zaregistrovat nejen do multicastové skupiny, ale také přímo ke konkrétnímu odesílateli. Pokud tedy chcete využít SSM, vyberte si směrovač, který podporuje protokol IGMP verze 3 (RFC 3376). Jste-li navíc příznivci IPv6, žádejte také MLD verze 2 podle RFC 3810.
Zajímá vás seriál Technologie Internetu?
Všechny dosud publikované díly jsou k dispozici zde.
PŘEDPLATNÉ
ČLÁNKY DO MAILU