OpenVPN distribuisce il multicast a ogni client, non agli abbonati

"Supporta multicast" risponde a una domanda di protocollo e lascia intatta la domanda di capacità. Ciò che conta in esercizio è quante copie il server emette per un pacchetto di gruppo e quali tunnel le trasportano. Una sola applicazione abbonata che riceve il flusso dimostra solo che la consegna funziona da qualche parte. Non dimostra che i client non interessati siano stati risparmiati dalla larghezza di banda.

Tre domande dentro una sola promessa di funzione

L’appartenenza al gruppo chiede se il ricevitore si è unito al gruppo. La consegna tramite tunnel chiede se il pacchetto ha attraversato il tunnel. La politica di replica chiede quante copie ha fatto il server e a chi. Una dichiarazione del fornitore può essere vera per la prima e muta sulla terza, ed è lì che vive il costo.

Tenetele separate quando dimensionate un collegamento. Solo la terza domanda fissa il budget in uscita lato server.

Che cosa fa il server in spazio utente con un pacchetto di gruppo

Nel server tradizionale in spazio utente di OpenVPN 2.6, un pacchetto broadcast o multicast in arrivo viene classificato nel percorso di ingresso TUN/TAP e consegnato alla routine di distribuzione broadcast invece che a una ricerca per gruppo. Quella routine scorre le istanze client, salta il mittente e ogni istanza ferma, applica il controllo VLAN dove è configurato e accoda una copia per ogni client rimanente. Nessun passo di quel ciclo consulta una tabella di appartenenza. È replica in stile broadcast, e questo è l’intero meccanismo.

Consideratelo una proprietà di quel percorso di codice, non una legge universale. Percorsi dati accelerati, altre implementazioni e versioni diverse possono comportarsi diversamente, e nulla di tutto ciò rende TAP un requisito o una riparazione.

Stimate le copie prima di misurare qualsiasi cosa

Prendete la velocità del carico utile e moltiplicatela per il numero di client idonei. Un flusso che invia un megabit al secondo a venti client produce venti megabit al secondo di carico utile che lascia il server, prima di incapsulamento, ritrasmissione e qualsiasi sovraccarico per client. Quell’aritmetica è un budget, non una misura del vostro impiego.

ip -s link show tun0

Leggete il contatore dei byte trasmessi prima e dopo un intervallo fisso con un mittente noto attivo. Dividete per l’intervallo e confrontate con la velocità del carico utile moltiplicata per il numero di client. Un numero vicino alla velocità di un solo flusso significa che la replica è limitata; un numero vicino alla velocità moltiplicata significa che ogni client riceve una copia.

Il contatore include anche il vostro traffico di tunnel, quindi tenete breve la finestra di prova e l’host tranquillo per il resto. La precisione conta meno dell’ordine di grandezza, ed è tutto ciò che serve per distinguere una copia da venti.

Un test a due client che risolve la questione dell’ambito

Collegate un client che dovrebbe ricevere il flusso e un secondo che non dovrebbe. Avviate il mittente, poi osservate i contatori di tunnel del secondo client nello stesso intervallo. La crescita sul secondo client è prova diretta di una replica ampia, qualunque cosa dicesse l’elenco delle funzioni.

Filtrate la cattura sull’indirizzo del gruppo per non leggere traffico non correlato, e limitatela all’interfaccia del tunnel. Catturare l’interfaccia fisica su un host occupato produce un file che nessuno può interpretare e può conservare dati utente che non intendevate raccogliere.

Poi invertite i ruoli. Se il risultato segue il ricevitore invece del gruppo, state guardando qualcosa consapevole dell’appartenenza, e l’ipotesi precedente era sbagliata a vostro favore.

Scegliere un progetto limitato invece di rimuovere i limiti

Quando la distribuzione è troppo ampia, la correzione è un assetto di distribuzione limitato e supportato, non cancellare ogni controllo che avete. Le opzioni includono avvicinare il punto di distribuzione ai ricevitori, usare un modello di abbonamento specifico per la sorgente che porti l’identità della sorgente insieme al gruppo, o dividere il flusso così che i siti non interessati non stiano mai sulla stessa frontiera di distribuzione.

Tenete l’identità di sorgente e gruppo distinta dal semplice fatto che una destinazione sia multicast. Un ricevitore che riconosce il gruppo ma non la sorgente è un abbonato diverso da uno che ha chiesto un canale specifico. Mescolare i due rende la successiva pianificazione della capacità un’ipotesi.

Il modello di canale multicast specifico per la sorgente è il riferimento per quella distinzione. Qualunque progetto scegliate, annotate l’insieme dei pari idonei, il responsabile della replica e il contatore che leggerete la prossima volta; quel registro è ciò che trasforma una sorpresa di larghezza di banda in un costo noto.