OpenVPN розсилає multicast кожному клієнту, а не підписникам

"Підтримує multicast" відповідає на питання протоколу й залишає питання ємності недоторканим. Операційно важливо, скільки копій сервер випускає на один груповий пакет і які тунелі їх несуть. Один підписаний застосунок, що отримує потік, доводить лише те, що доставка десь працює. Він не доводить, що незацікавлені клієнти були позбавлені смуги пропускання.

Три питання в одному твердженні про функцію

Членство в групі питає, чи приєднався отримувач до групи. Доставка через тунель питає, чи пакет взагалі пройшов тунелем. Політика реплікації питає, скільки копій зробив сервер і кому. Заява постачальника може бути правдивою для першого й мовчати про третє, і саме там живе вартість.

Тримайте їх окремо, коли оцінюєте розмір каналу. Лише третє питання задає бюджет вихідного трафіку на боці сервера.

Що сервер у просторі користувача робить із груповим пакетом

У традиційному сервері в просторі користувача OpenVPN 2.6 пакет broadcast або multicast, що надходить, класифікується на вхідному шляху TUN/TAP і передається процедурі широкомовного розгалуження, а не пошуку за групою. Ця процедура обходить екземпляри клієнтів, пропускає відправника й будь-який зупинений екземпляр, застосовує свою перевірку VLAN там, де вона налаштована, і ставить копію в чергу для кожного клієнта, що залишився. Жоден крок у цьому циклі не звертається до таблиці членства. Це реплікація у стилі broadcast, і це весь механізм.

Вважайте це властивістю того шляху коду, а не універсальним законом. Прискорені шляхи даних, інші реалізації та різні версії можуть поводитися інакше, і ніщо з цього не робить TAP вимогою чи виправленням.

Сплануйте копії, перш ніж щось вимірювати

Візьміть швидкість корисного навантаження й помножте її на кількість відповідних клієнтів. Потік, що надсилає один мегабіт за секунду двадцяти клієнтам, створює двадцять мегабіт за секунду корисного навантаження, яке залишає сервер, до інкапсуляції, повторного надсилання та будь-яких витрат на клієнта. Ця арифметика — бюджет, а не вимірювання вашого розгортання.

ip -s link show tun0

Прочитайте лічильник надісланих байтів до і після фіксованого інтервалу з одним відомим активним відправником. Поділіть на інтервал і порівняйте зі швидкістю корисного навантаження, помноженою на кількість клієнтів. Число, близьке до швидкості одного потоку, означає, що реплікація обмежена; число, близьке до помноженої швидкості, означає, що кожен клієнт отримує копію.

Лічильник включає й ваш власний тунельний трафік, тому тримайте вікно тесту коротким, а хост іншим часом тихим. Точність важлива менше за порядок величини, і цього достатньо, щоб відрізнити одну копію від двадцяти.

Тест із двома клієнтами, який вирішує питання охоплення

Підключіть одного клієнта, який має отримувати потік, і другого, який не має. Запустіть відправника, а потім спостерігайте лічильники тунелю другого клієнта протягом того самого інтервалу. Зростання в другого клієнта — прямий доказ широкої реплікації, хоч би що казав список функцій.

Відфільтруйте захоплення за адресою групи, щоб не читати сторонній трафік, і обмежте його інтерфейсом тунелю. Захоплення фізичного інтерфейсу на зайнятому хості створює файл, який ніхто не зможе витлумачити, і може зберегти дані користувачів, які ви не мали наміру збирати.

Потім поміняйте ролі. Якщо результат іде за отримувачем, а не за групою, ви дивитеся на щось, що враховує членство, і попереднє припущення було хибним на вашу користь.

Вибір обмеженої схеми замість зняття обмежень

Коли розгалуження занадто широке, виправлення — це підтримувана схема обмеженого розподілу, а не видалення всіх наявних у вас засобів контролю. Варіанти включають наближення точки розподілу до отримувачів, використання моделі підписки, специфічної для джерела, яка несе ідентичність джерела разом із групою, або поділ потоку так, щоб незацікавлені майданчики ніколи не опинялися на одній межі розподілу.

Тримайте ідентичність джерела й групи окремо від голого факту, що призначення є multicast. Отримувач, який розпізнає групу, але не джерело, — це інший підписник, ніж той, хто попросив конкретний канал. Змішування обох перетворює подальше планування ємності на здогад.

Модель каналу multicast, специфічного для джерела — це орієнтир для такого розрізнення. Яке б рішення ви не обрали, запишіть набір відповідних партнерів, власника реплікації та лічильник, який прочитаєте наступного разу; саме цей запис перетворює несподіванку зі смугою пропускання на відомі витрати.