OpenVPN разпръсква multicast към всеки клиент, не към абонатите
Сървърът в потребителското пространство копира групов пакет за всеки клиент, не за всеки абонат. Планирайте разпръскването, докажете го с броячи на тунела, после ограничете обхвата на дизайна.
"Поддържа multicast" отговаря на въпрос за протокола и оставя въпроса за капацитета непипнат. Оперативно важно е колко копия излъчва сървърът за един групов пакет и кои тунели ги носят. Едно абонирано приложение, което получава потока, доказва само че доставката работи някъде. То не доказва, че незаинтересованите клиенти са пощадени от трафика.
Три въпроса в едно твърдение за функция
Груповото членство пита дали получателят се е присъединил към групата. Доставката през тунел пита дали пакетът изобщо е преминал през тунела. Политиката на репликация пита колко копия е направил сървърът и на кого. Твърдение на доставчик може да е вярно за първото и да мълчи за третото, а именно там живее разходът.
Дръжте ги разделени, когато оразмерявате връзка. Само третият въпрос задава бюджета за изходящ трафик от страна на сървъра.
Какво прави сървърът в потребителското пространство с групов пакет
В традиционния сървър OpenVPN 2.6 в потребителското пространство пристигащ пакет за broadcast или multicast се класифицира по входния път TUN/TAP и се предава на процедурата за broadcast разпръскване, а не на търсене по група. Тази процедура обхожда клиентските инстанции, пропуска подателя и всяка спряна инстанция, прилага проверката си за VLAN там, където е настроена, и поставя копие в опашката за всеки останал клиент. Нито една стъпка в този цикъл не се обръща към таблица за членство. Това е репликация в broadcast стил и това е целият механизъм.
Третирайте това като свойство на онзи кодов път, а не като универсален закон. Ускорените пътища за данни, други реализации и различни версии може да се държат различно и нищо от това не прави TAP изискване или поправка.
Планирайте копията, преди да измервате каквото и да е
Вземете скоростта на полезния товар и я умножете по броя на подходящите клиенти. Поток, който изпраща един мегабит в секунда към двадесет клиента, произвежда двадесет мегабита в секунда полезен товар, напускащ сървъра, преди капсулиране, повторно предаване и каквито и да е разходи за клиент. Тази аритметика е бюджет, а не измерване на вашето внедряване.
ip -s link show tun0Прочетете брояча на предадените байтове преди и след фиксиран интервал с един известен активен подател. Разделете на интервала и сравнете със скоростта на полезния товар, умножена по броя клиенти. Число близо до скоростта на един поток означава, че репликацията е ограничена; число близо до умножената скорост означава, че всеки клиент получава копие.
Броячът включва и собствения ви тунелен трафик, затова дръжте тестовия прозорец кратък, а хоста иначе тих. Прецизността е по-малко важна от порядъка на величина и това е всичко, което ви трябва, за да различите едно копие от двадесет.
Тест с два клиента, който решава въпроса за обхвата
Свържете един клиент, който трябва да получава потока, и втори, който не трябва. Стартирайте подателя, после наблюдавайте броячите на тунела на втория клиент за същия интервал. Ръст при втория клиент е пряко доказателство за широко разпръскване, каквото и да казва списъкът с функции.
Филтрирайте заснемането по адреса на групата, за да не четете несвързан трафик, и го ограничете до тунелния интерфейс. Заснемането на физическия интерфейс на натоварен хост създава файл, който никой не може да тълкува, и може да запази потребителски данни, които не сте възнамерявали да събирате.
После разменете ролите. Ако резултатът следва получателя, а не групата, виждате нещо, което отчита членството, и по-ранното допускане е било грешно във ваша полза.
Избор на ограничен дизайн вместо премахване на ограниченията
Когато разпръскването е твърде широко, поправката е поддържана схема за ограничено разпространение, а не изтриване на всеки контрол, който имате. Опциите включват преместване на точката на разпространение по-близо до получателите, използване на модел на абонамент, специфичен за източника, който носи идентичността на източника заедно с групата, или разделяне на потока, така че незаинтересованите сайтове никога да не попадат на една и съща граница на разпространение.
Дръжте идентичността на източника и групата отделно от голия факт, че дестинацията е multicast. Получател, който разпознава групата, но не източника, е различен абонат от този, който е поискал конкретен канал. Смесването на двете прави по-късното планиране на капацитета догадка.
Моделът на multicast канал, специфичен за източника е ориентирът за това разграничение. Който и дизайн да изберете, запишете набора от подходящи връстници, собственика на репликацията и брояча, който ще прочетете следващия път; този запис превръща изненадата с трафика в известен разход.