Az OpenVPN minden kliensnek szétosztja a multicastot, nem az előfizetőknek

"Támogatja a multicastot" egy protokollkérdésre válaszol, és érintetlenül hagyja a kapacitáskérdést. Üzemeltetésileg az számít, hogy a kiszolgáló hány példányt bocsát ki egy csoportcsomagért, és mely alagutak szállítják azokat. Egy előfizetett alkalmazás, amely megkapja a folyamot, csak azt bizonyítja, hogy a kézbesítés valahol működik. Nem bizonyítja, hogy az érdektelen kliensek megúszták a sávszélességet.

Három kérdés egyetlen funkcióállításban

A csoporttagság azt kérdezi, belépett-e a fogadó a csoportba. Az alagút kézbesítés azt kérdezi, átlépte-e a csomag egyáltalán az alagutat. A replikációs szabály azt kérdezi, hány példányt készített a kiszolgáló, és kinek. Egy szállítói nyilatkozat igaz lehet az elsőre és hallgat a harmadikról, és ott lakik a költség.

Tartsa őket külön, amikor egy kapcsolatot méretez. Csak a harmadik kérdés állítja be a kimenő költségvetést a kiszolgáló oldalán.

Mit tesz a felhasználói térben futó kiszolgáló egy csoportcsomaggal

A hagyományos, felhasználói térben futó OpenVPN 2.6 kiszolgálóban a beérkező broadcast vagy multicast csomag a TUN/TAP bemeneti útvonalon osztályozódik, és a broadcast szétosztó rutinhoz kerül, nem csoportonkénti kereséshez. Ez a rutin végigjárja a klienspéldányokat, kihagyja a küldőt és minden leállított példányt, alkalmazza a VLAN-ellenőrzést ott, ahol be van állítva, és sorba tesz egy példányt minden fennmaradó kliensnek. A ciklus egyetlen lépése sem kérdez csoporttagsági táblát. Ez broadcast stílusú replikáció, és ez az egész mechanizmus.

Tekintse ezt az adott kódútvonal tulajdonságának, nem egyetemes törvénynek. A gyorsított adatútvonalak, más megvalósítások és különböző verziók másként viselkedhetnek, és ezek egyike sem teszi a TAP-ot követelménnyé vagy javítássá.

Költségvetje a példányokat, mielőtt bármit mérne

Vegye a hasznos terhelés sebességét, és szorozza meg a jogosult kliensek számával. Egy folyam, amely másodpercenként egy megabitet küld húsz kliensnek, másodpercenként húsz megabit hasznos terhelést állít elő, amely elhagyja a kiszolgálót, a beágyazás, az újraküldés és bármilyen kliensenkénti többlet előtt. Ez az aritmetika költségvetés, nem a telepítés mérése.

ip -s link show tun0

Olvassa le az elküldött bájtok számlálóját egy rögzített intervallum előtt és után egy ismert aktív küldővel. Ossza el az intervallummal, és hasonlítsa össze a hasznos terhelés sebességének és a kliensek számának szorzatával. Az egyfolyamos sebességhez közeli szám azt jelenti, hogy a replikáció korlátozott; a szorzott sebességhez közeli szám azt jelenti, hogy minden kliens példányt kap.

A számláló a saját alagútforgalmát is tartalmazza, ezért tartsa rövidre a tesztablakot, és a gazdagépet egyébként csendben. A pontosság kevésbé számít, mint a nagyságrend, és ennyi elég ahhoz, hogy megkülönböztessen egy példányt húsztól.

Kétklienses teszt, amely eldönti a hatókör kérdését

Csatlakoztasson egy klienst, amelynek meg kell kapnia a folyamot, és egy másodikat, amelynek nem. Indítsa el a küldőt, majd figyelje a második kliens alagút-számlálóit ugyanazon intervallum alatt. A növekedés a második kliensnél közvetlen bizonyítéka a széles replikációnak, bármit is mondott a funkciólista.

Szűrje a rögzítést a csoportcímre, hogy ne olvasson összefüggéstelen forgalmat, és tartsa az alagút-interfésznél. A fizikai interfész rögzítése egy forgalmas gazdagépen olyan fájlt hoz létre, amelyet senki sem tud értelmezni, és olyan felhasználói adatokat őrizhet meg, amelyeket nem szándékozott gyűjteni.

Aztán cserélje fel a szerepeket. Ha az eredmény a fogadót követi a csoport helyett, akkor tagságtudatos dologgal van dolga, és a korábbi feltevés az Ön javára téves volt.

Korlátozott tervezés választása a korlátok eltávolítása helyett

Amikor a szétosztás túl széles, a javítás egy támogatott, korlátozott elosztási elrendezés, nem pedig az összes rendelkezésre álló vezérlő törlése. A lehetőségek közé tartozik az elosztási pont közelebb hozása a fogadókhoz, a forrásspecifikus előfizetési modell használata, amely a forrás identitását a csoporttal együtt hordozza, vagy a folyam felosztása, hogy az érdektelen helyek soha ne üljenek ugyanazon az elosztási határon.

Tartsa külön a forrás és a csoport identitását attól a puszta ténytől, hogy a cél multicast. Az a fogadó, amely felismeri a csoportot, de a forrást nem, más előfizető, mint aki egy adott csatornát kért. A kettő összekeverése a későbbi kapacitástervezést találgatássá teszi.

A forrásspecifikus multicast csatornamodell a hivatkozás ehhez a megkülönböztetéshez. Bármelyik tervezést választja, írja le a jogosult partnerek halmazát, a replikáció tulajdonosát és a számlálót, amelyet legközelebb olvasni fog; ez a feljegyzés az, ami a sávszélesség-meglepetést ismert költséggé változtatja.