OpenVPN versprei multicast na elke kliënt, nie na intekenare nie

"Ondersteun multicast" beantwoord 'n protokolvraag en laat die kapasiteitsvraag onaangeraak. Wat operasioneel saak maak, is hoeveel kopieë die bediener vir een groeppakket uitstuur en watter tonnels dit dra. Een ingetekende toepassing wat die stroom ontvang, bewys net dat aflewering ergens werk. Dit bewys nie dat onbetrokke kliënte die bandwydte gespaar is nie.

Drie vrae binne een kenmerkbewering

Groepslidmaatskap vra of die ontvanger by die groep aangesluit het. Tonnelaflewering vra of die pakket hoegenaamd deur die tonnel gegaan het. Repliseringsbeleid vra hoeveel kopieë die bediener gemaak het en vir wie. 'n Verskaffer se verklaring kan waar wees vir die eerste en stil bly oor die derde, en dit is waar die koste lê.

Hou hulle apart wanneer jy 'n skakel beplan. Net die derde vraag bepaal die uitgaande begroting aan die bedienerkant.

Wat die gebruikerruimte-bediener met 'n groeppakket doen

In die tradisionele gebruikerruimte-bediener van OpenVPN 2.6 word 'n inkomende uitsaai- of multicastpakket in die TUN/TAP-invoerpad geklassifiseer en aan die uitsaai-verspreidingsroetine oorhandig eerder as aan 'n soektog per groep. Daardie roetine loop deur die kliëntinstansies, slaan die sender en enige gestaakte instansie oor, pas sy VLAN-kontrole toe waar een opgestel is, en plaas 'n kopie in die tou vir elke oorblywende kliënt. Geen stap in daardie lus raadpleeg 'n lidmaatskapstabel nie. Dit is uitsaai-styl replisering, en dit is die hele meganisme.

Besking dit as 'n eienskap van daardie kodepad, nie as 'n universele wet nie. Versnelde datapaaie, ander implementasies en verskillende weergawes kan anders optree, en niks hiervan maak TAP 'n vereiste of 'n herstelling nie.

Begroot die kopieë voordat jy enigiets meet

Neem die nutstempo en vermenigvuldig dit met die aantal geskikte kliënte. 'n Stroom wat een megabit per sekonde na twintig kliënte stuur, produseer twintig megabit per sekonde se nutsvrag wat die bediener verlaat, voor enkapsulering, hertransmissie en enige oorhoofse koste per kliënt. Daardie rekenkunde is 'n begroting, nie 'n meting van jou ontplooiing nie.

ip -s link show tun0

Lees die versending-grepe-teller voor en na 'n vaste interval met een bekende sender aktief. Deel deur die interval en vergelyk met die nutstempo vermenigvuldig met die kliënttal. 'n Getal naby die enkelstroomtempo beteken die replisering is beperk; 'n getal naby die vermenigvuldigde tempo beteken elke kliënt ontvang 'n kopie.

Die teller sluit ook jou eie tonnelverkeer in, so hou die toetsvenster kort en die gasheer verder stil. Presisie maak minder saak as die orde van grootte, wat al is wat jy nodig het om een kopie van twintig te onderskei.

'n Toets met twee kliënte wat die omvangvraag besleg

Verbind een kliënt wat die stroom moet ontvang en 'n tweede wat dit nie moet nie. Begin die sender en kyk dan vir dieselfde interval na die tweede kliënt se tonneltellers. Groei by die tweede kliënt is direkte bewys van wye replisering, ongeag wat die kenmerklys gesê het.

Filtreer die opname na die groepadres sodat jy nie onverwante verkeer lees nie, en hou dit by die tonnelkoppelvlak. Om die fisiese koppelvlak op 'n besige gasheer op te neem, lewer 'n lêer wat niemand kan interpreteer nie en kan gebruikersdata behou wat jy nie bedoel het om in te samel nie.

Draai dan die rolle om. As die resultaat die ontvanger volg eerder as die groep, kyk jy na iets wat lidmaatskap in ag neem, en die vroeëre aanname was verkeerd in jou guns.

Kies 'n beperkte ontwerp eerder as om grense te verwyder

Wanneer die verspreiding te wyd is, is die oplossing 'n ondersteunde beperkte verspreidingsreëling, nie die skrap van elke kontrole wat jy het nie. Opsies sluit in om die verspreidingspunt nader aan die ontvangers te skuif, 'n bron-spesifieke intekenmodel te gebruik wat die bronidentiteit sowel as die groep dra, of die stroom te verdeel sodat onbetrokke terreine nooit op dieselfde verspreidingsgrens sit nie.

Hou die bron- en groepidentiteit apart van die blote feit dat 'n bestemming multicast is. 'n Ontvanger wat die groep herken maar nie die bron nie, is 'n ander intekenaar as een wat 'n spesifieke kanaal gevra het. Om die twee te meng, maak latere kapasiteitsbeplanning giswerk.

Die bron-spesifieke multicast-kanaalmodel is die verwysing vir daardie onderskeid. Watter ontwerp jy ook al kies, skryf die stel geskikte eweknieë, die repliseringseienaar en die teller wat jy volgende keer gaan lees neer; daardie rekord is wat 'n bandwydte-verrassing in 'n bekende koste omskep.