OpenVPN lähettää multicastin jokaiselle asiakkaalle, ei tilaajille

"Tukee multicastia" vastaa protokollakysymykseen ja jättää kapasiteettikysymyksen koskemattomaksi. Operatiivisesti ratkaisee, montako kopiota palvelin lähettää yhtä ryhmäpakettia kohti ja mitkä tunnelit niitä kuljettavat. Yksi tilattu sovellus, joka vastaanottaa virran, todistaa vain, että toimitus toimii jossain. Se ei todista, että kiinnostumattomat asiakkaat säästyivät kaistanleveydeltä.

Kolme kysymystä yhden ominaisuusväitteen sisällä

Ryhmän jäsenyys kysyy, liittyikö vastaanottaja ryhmään. Tunnelitoimitus kysyy, ylittikö paketti ylipäätään tunnelin. Replikointikäytäntö kysyy, montako kopiota palvelin teki ja kenelle. Toimittajan lausunto voi olla totta ensimmäisestä ja vaiti kolmannesta, ja siinä kustannus asuu.

Pidä ne erillään, kun mitoitat linkkiä. Vain kolmas kysymys asettaa lähtevän budjetin palvelimen puolella.

Mitä käyttäjäavaruuden palvelin tekee ryhmäpaketille

Perinteisessä OpenVPN 2.6:n käyttäjäavaruuden palvelimessa saapuva broadcast- tai multicast-paketti luokitellaan TUN/TAP-tulotielle ja annetaan broadcast-jakelurutiinille ryhmäkohtaisen haun sijaan. Tämä rutiini käy läpi asiakasinstanssit, ohittaa lähettäjän ja jokaisen pysäytetyn instanssin, soveltaa VLAN-tarkistustaan siellä missä se on määritetty, ja asettaa kopion jonoon jokaiselle jäljellä olevalle asiakkaalle. Mikään vaihe tuossa silmukassa ei kysy jäsenyystaulua. Se on broadcast-tyylistä replikointia, ja se on koko mekanismi.

Pidä tätä kyseisen koodipolun ominaisuutena, älä yleisenä lakina. Kiihdytetyt datapolut, muut toteutukset ja eri versiot voivat käyttäytyä toisin, eikä mikään tästä tee TAP:sta vaatimusta tai korjausta.

Budjetoi kopiot ennen kuin mittaat mitään

Ota hyötykuorman nopeus ja kerro se kelvollisten asiakkaiden määrällä. Virta, joka lähettää yhden megabitin sekunnissa kahdellekymmenelle asiakkaalle, tuottaa kaksikymmentä megabittiä sekunnissa hyötykuormaa, joka lähtee palvelimelta ennen kapselointia, uudelleenlähetystä ja mitä tahansa asiakaskohtaista ylikuormaa. Se aritmetiikka on budjetti, ei mittaus käyttöönotostasi.

ip -s link show tun0

Lue lähetysbittien laskuri ennen kiinteää jaksoa ja sen jälkeen, kun yksi tunnettu lähettäjä on aktiivinen. Jaa jaksolla ja vertaa hyötykuorman nopeuteen kerrottuna asiakasmäärällä. Yhden virran nopeutta lähellä oleva luku tarkoittaa, että replikointi on rajattu; kerrottua nopeutta lähellä oleva luku tarkoittaa, että jokainen asiakas saa kopion.

Laskuri sisältää myös oman tunneliliikenteesi, joten pidä testi-ikkuna lyhyenä ja isäntä muuten hiljaisena. Tarkkuus merkitsee vähemmän kuin suuruusluokka, ja se on kaikki mitä tarvitset erottaaksesi yhden kopion kahdestakymmenestä.

Kahden asiakkaan testi, joka ratkaisee laajuuskysymyksen

Yhdistä yksi asiakas, jonka pitäisi vastaanottaa virta, ja toinen, jonka ei pitäisi. Käynnistä lähettäjä ja seuraa sitten toisen asiakkaan tunnelilaskureita saman jakson ajan. Kasvu toisella asiakkaalla on suora todiste laajasta replikoinnista, mitä ominaisuusluettelo sanoi tahansa.

Suodata kaappaus ryhmäosoitteeseen, jotta et lue asiaankuulumatonta liikennettä, ja rajaa se tunneliliitäntään. Fyysisen liitännän kaappaaminen kiireisellä isännällä tuottaa tiedoston, jota kukaan ei osaa tulkita, ja voi säilyttää käyttäjätietoja, joita et aikonut kerätä.

Käännä sitten roolit. Jos tulos seuraa vastaanottajaa eikä ryhmää, katsot jotain jäsenyystietoista, ja aiempi oletus oli väärä edukseksi.

Rajatun suunnittelun valinta rajojen poistamisen sijaan

Kun jakelu on liian leveä, korjaus on tuettu rajattu jakelujärjestely, ei kaikkien käytössä olevien hallintakeinojen poistaminen. Vaihtoehtoja ovat jakelupisteen siirtäminen lähemmäs vastaanottajia, lähdekohtaisen tilausmallin käyttäminen, joka kantaa lähteen identiteetin ryhmän ohella, tai virran jakaminen niin, etteivät kiinnostumattomat sivustot koskaan istu samalla jakelurajalla.

Pidä lähteen ja ryhmän identiteetti erillään pelkästä tosiasiasta, että kohde on multicast. Vastaanottaja, joka tunnistaa ryhmän mutta ei lähdettä, on eri tilaaja kuin se, joka pyysi tiettyä kanavaa. Kahden sekoittaminen tekee myöhemmästä kapasiteettisuunnittelusta arvailua.

Lähdekohtainen multicast-kanavamalli on tuon erottelun viite. Minkä suunnittelun valitsetkin, kirjaa kelvollisten vertaisten joukko, replikoinnin omistaja ja laskuri, jonka luet ensi kerralla; juuri se merkintä muuttaa kaistanleveyden yllätyksen tunnetuksi kustannukseksi.