OpenVPN trimite multicast fiecărui client, nu abonaților

"Suportă multicast" răspunde la o întrebare de protocol și lasă neatinsă întrebarea despre capacitate. Operațional contează câte copii emite serverul pentru un pachet de grup și ce tuneluri le transportă. O singură aplicație abonată care primește fluxul dovedește doar că livrarea funcționează undeva. Nu dovedește că clienților neinteresați li s-a cruțat lățimea de bandă.

Trei întrebări într-o singură afirmație despre o funcție

Apartenența la grup întreabă dacă receptorul s-a alăturat grupului. Livrarea prin tunel întreabă dacă pachetul a trecut tunelul. Politica de replicare întreabă câte copii a făcut serverul și cui. O declarație a furnizorului poate fi adevărată pentru prima și tăcută despre a treia, și acolo locuiește costul.

Țineți-le separate când dimensionați o legătură. Doar a treia întrebare stabilește bugetul de ieșire pe partea serverului.

Ce face serverul din spațiul utilizatorului cu un pachet de grup

În serverul tradițional din spațiul utilizatorului OpenVPN 2.6, un pachet broadcast sau multicast sosit este clasificat pe calea de intrare TUN/TAP și predat rutinei de distribuire broadcast în locul unei căutări pe grup. Acea rutină parcurge instanțele de client, sare peste expeditor și peste orice instanță oprită, aplică verificarea VLAN acolo unde este configurată și pune o copie în coadă pentru fiecare client rămas. Niciun pas din acea buclă nu consultă un tabel de apartenență. Aceasta este replicare în stil broadcast, și acesta este întregul mecanism.

Tratați acest lucru ca o proprietate a acelei căi de cod, nu ca o lege universală. Căile de date accelerate, alte implementări și versiuni diferite se pot comporta altfel, și nimic din toate acestea nu face din TAP o cerință sau o reparație.

Bugetați copiile înainte de a măsura ceva

Luați rata de încărcare utilă și înmulțiți-o cu numărul de clienți eligibili. Un flux care trimite un megabit pe secundă la douăzeci de clienți produce douăzeci de megabiți pe secundă de încărcare utilă care părăsește serverul, înainte de încapsulare, retransmisie și orice cost suplimentar pe client. Aritmetica aceea este un buget, nu o măsurătoare a implementării dumneavoastră.

ip -s link show tun0

Citiți contorul de bytes transmiși înainte și după un interval fix cu un expeditor cunoscut activ. Împărțiți la interval și comparați cu rata de încărcare utilă înmulțită cu numărul de clienți. Un număr aproape de rata unui singur flux înseamnă că replicarea este limitată; un număr aproape de rata înmulțită înseamnă că fiecare client primește o copie.

Contorul include și traficul propriu de tunel, așa că păstrați fereastra de test scurtă și gazda liniștită în rest. Precizia contează mai puțin decât ordinul de mărime, și este tot ce aveți nevoie pentru a distinge o copie de douăzeci.

Un test cu doi clienți care lămurește întrebarea privind amploarea

Conectați un client care ar trebui să primească fluxul și un al doilea care nu ar trebui. Porniți expeditorul, apoi urmăriți contoarele de tunel ale celui de-al doilea client pentru același interval. Creșterea la al doilea client este dovadă directă a replicării largi, orice ar spune lista de funcții.

Filtrați captura pe adresa grupului ca să nu citiți trafic irelevant, și limitați-o la interfața tunelului. Capturarea interfeței fizice pe o gazdă aglomerată produce un fișier pe care nimeni nu îl poate interpreta și poate păstra date ale utilizatorilor pe care nu intenționați să le colectați.

Apoi inversați rolurile. Dacă rezultatul urmează receptorul și nu grupul, priviți ceva conștient de apartenență, iar presupunerea anterioară era greșită în favoarea dumneavoastră.

A alege un proiect limitat în loc de a elimina limitele

Când distribuirea este prea largă, corecția este o configurare de distribuție limitată și acceptată, nu ștergerea fiecărui control pe care îl aveți. Opțiunile includ apropierea punctului de distribuție de receptori, folosirea unui model de abonare specific sursei care poartă identitatea sursei împreună cu grupul, sau împărțirea fluxului astfel încât siturile neinteresate să nu stea niciodată pe aceeași frontieră de distribuție.

Țineți identitatea sursei și a grupului separată de simplul fapt că o destinație este multicast. Un receptor care recunoaște grupul dar nu sursa este un abonat diferit de cel care a cerut un canal anume. Amestecarea celor două face ca planificarea ulterioară a capacității să fie ghicit.

Modelul de canal multicast specific sursei este referința pentru acea distincție. Orice proiect ați alege, notați setul de parteneri eligibili, proprietarul replicării și contorul pe care îl veți citi data viitoare; acea înregistrare este ce transformă o surpriză de lățime de bandă într-un cost cunoscut.