OpenVPN distribueix el multicast a cada client, no als subscriptors

"Admet multicast" respon una pregunta de protocol i deixa intacta la pregunta de capacitat. El que importa operativament és quantes còpies emet el servidor per a un paquet de grup i quins túnels les transporten. Una aplicació subscrita que rep el flux només demostra que el lliurament funciona en algun lloc. No demostra que els clients no interessats s’hagin estalviat l’amplada de banda.

Tres preguntes dins d’una sola afirmació de funcionalitat

La pertinença al grup pregunta si el receptor s’ha unit al grup. El lliurament pel túnel pregunta si el paquet ha travessat el túnel. La política de replicació pregunta quantes còpies ha fet el servidor i a qui. Una declaració del proveïdor pot ser certa per a la primera i muda sobre la tercera, i és aquí on viu el cost.

Manteniu-les separades quan dimensiones un enllaç. Només la tercera pregunta fixa el pressupost de sortida al costat del servidor.

Què fa el servidor d’espai d’usuari amb un paquet de grup

Al servidor tradicional d’espai d’usuari d’OpenVPN 2.6, un paquet de broadcast o multicast que arriba es classifica al camí d’entrada TUN/TAP i es lliura a la rutina de distribució de broadcast en lloc d’una cerca per grup. Aquesta rutina recorre les instàncies de client, salta l’emissor i qualsevol instància aturada, aplica la seva comprovació de VLAN on n’hi ha una de configurada i encua una còpia per a cada client restant. Cap pas d’aquest bucle consulta una taula de pertinença. Això és replicació d’estil broadcast, i és tot el mecanisme.

Tracteu-ho com una propietat d’aquest camí de codi, no com una llei universal. Els camins de dades accelerats, altres implementacions i versions diferents poden comportar-se diferent, i res d’això no fa que TAP sigui un requisit ni una reparació.

Pressuposteu les còpies abans de mesurar res

Preneu la taxa de càrrega útil i multipliqueu-la pel nombre de clients elegibles. Un flux que envia un megabit per segon a vint clients produeix vint megabits per segon de càrrega útil que surten del servidor, abans d’encapsulament, retransmissió i qualsevol sobrecost per client. Aquesta aritmètica és un pressupost, no una mesura del vostre desplegament.

ip -s link show tun0

Llegiu el comptador de bytes de transmissió abans i després d’un interval fix amb un emissor conegut actiu. Dividiu per l’interval i compareu-ho amb la taxa de càrrega útil multiplicada pel nombre de clients. Un nombre proper a la taxa d’un sol flux vol dir que la replicació està limitada; un nombre proper a la taxa multiplicada vol dir que cada client rep una còpia.

El comptador també inclou el vostre propi trànsit de túnel, així que manteniu la finestra de prova curta i l’amfitrió tranquil la resta del temps. La precisió importa menys que l’ordre de magnitud, que és tot el que cal per distingir una còpia de vint.

Una prova amb dos clients que resol la qüestió de l’abast

Connecteu un client que hauria de rebre el flux i un segon que no. Engegueu l’emissor i observeu els comptadors de túnel del segon client durant el mateix interval. Un creixement al segon client és prova directa d’una replicació àmplia, digui el que digui la llista de funcionalitats.

Filtreu la captura a l’adreça del grup per no llegir trànsit no relacionat, i limiteu-la a la interfície del túnel. Capturar la interfície física en un amfitrió ocupat produeix un fitxer que ningú no pot interpretar i pot retenir dades d’usuari que no teníeu intenció de recollir.

Després invertiu els papers. Si el resultat segueix el receptor i no el grup, esteu veient una cosa conscient de la pertinença, i la suposició anterior era errònia a favor vostre.

Triar un disseny limitat en lloc de treure límits

Quan la distribució és massa àmplia, la solució és un desplegament de distribució limitat i suportat, no eliminar tots els controls que tingueu. Les opcions inclouen apropar el punt de distribució als receptors, fer servir un model de subscripció específic de la font que porti la identitat de la font així com el grup, o dividir el flux perquè els llocs no interessats no quedin mai a la mateixa frontera de distribució.

Manteniu la identitat de la font i del grup separada del simple fet que una destinació sigui multicast. Un receptor que reconeix el grup però no la font és un subscriptor diferent d’un que va demanar un canal concret. Barrejar les dues coses converteix la planificació de capacitat posterior en una endevinalla.

El model de canal multicast específic de la font és la referència per a aquesta distinció. Trieu el disseny que trieu, anoteu el conjunt d’iguals elegibles, l’amo de la replicació i el comptador que llegireu la propera vegada; aquest registre és el que converteix una sorpresa d’amplada de banda en un cost conegut.