OpenVPN difunde multicast para cada cliente, não para assinantes

"Suporta multicast" responde a uma pergunta de protocolo e deixa a pergunta de capacidade intacta. O que importa operacionalmente é quantas cópias o servidor emite por um pacote de grupo e quais túneis as transportam. Uma aplicação subscrita que recebe o fluxo prova apenas que a entrega funciona em algum sítio. Não prova que os clientes não interessados foram poupados à largura de banda.

Três perguntas dentro de uma só afirmação de funcionalidade

A pertença ao grupo pergunta se o recetor se juntou ao grupo. A entrega pelo túnel pergunta se o pacote atravessou o túnel. A política de replicação pergunta quantas cópias o servidor fez e a quem. Uma declaração do fornecedor pode ser verdadeira para a primeira e muda sobre a terceira, e é aí que vive o custo.

Mantenha-as separadas quando dimensiona uma ligação. Só a terceira pergunta fixa o orçamento de saída do lado do servidor.

O que o servidor em espaço de utilizador faz com um pacote de grupo

No servidor tradicional em espaço de utilizador de OpenVPN 2.6, um pacote de difusão ou multicast que chega é classificado no caminho de entrada TUN/TAP e entregue à rotina de distribuição de difusão em vez de uma pesquisa por grupo. Essa rotina percorre as instâncias de cliente, salta o emissor e qualquer instância parada, aplica a verificação de VLAN onde está configurada e coloca uma cópia em fila para cada cliente restante. Nenhum passo desse ciclo consulta uma tabela de pertença. Isso é replicação ao estilo de difusão, e é todo o mecanismo.

Trate isto como uma propriedade desse caminho de código, não como uma lei universal. Caminhos de dados acelerados, outras implementações e versões diferentes podem comportar-se de outro modo, e nada disto torna o TAP um requisito nem uma reparação.

Orçamente as cópias antes de medir seja o que for

Pegue na taxa de carga útil e multiplique-a pelo número de clientes elegíveis. Um fluxo que envia um megabit por segundo a vinte clientes produz vinte megabits por segundo de carga útil que sai do servidor, antes de encapsulamento, retransmissão e qualquer sobrecarga por cliente. Essa aritmética é um orçamento, não uma medição da sua implementação.

ip -s link show tun0

Leia o contador de bytes transmitidos antes e depois de um intervalo fixo com um emissor conhecido ativo. Divida pelo intervalo e compare com a taxa de carga útil multiplicada pelo número de clientes. Um número próximo da taxa de um só fluxo significa que a replicação está limitada; um número próximo da taxa multiplicada significa que cada cliente recebe uma cópia.

O contador também inclui o seu próprio tráfego de túnel, por isso mantenha a janela de teste curta e o anfitrião calmo no resto. A precisão importa menos do que a ordem de grandeza, e é tudo o que precisa para distinguir uma cópia de vinte.

Um teste com dois clientes que resolve a questão do âmbito

Ligue um cliente que deveria receber o fluxo e um segundo que não deveria. Inicie o emissor e observe os contadores de túnel do segundo cliente no mesmo intervalo. O crescimento no segundo cliente é prova direta de replicação ampla, diga o que disser a lista de funcionalidades.

Filtre a captura para o endereço do grupo para não ler tráfego não relacionado, e limite-a à interface do túnel. Capturar a interface física num anfitrião ocupado produz um ficheiro que ninguém consegue interpretar e pode reter dados de utilizador que não pretendia recolher.

Depois inverta os papéis. Se o resultado seguir o recetor e não o grupo, está perante algo consciente da pertença, e a suposição anterior estava errada a seu favor.

Escolher um desenho limitado em vez de remover limites

Quando a distribuição é demasiado ampla, a correção é um arranjo de distribuição limitado e suportado, não apagar todos os controlos que tem. As opções incluem aproximar o ponto de distribuição dos recetores, usar um modelo de subscrição específico da fonte que transporte a identidade da fonte além do grupo, ou dividir o fluxo para que os sítios não interessados nunca fiquem na mesma fronteira de distribuição.

Mantenha a identidade de fonte e grupo separada do simples facto de um destino ser multicast. Um recetor que reconhece o grupo mas não a fonte é um assinante diferente daquele que pediu um canal específico. Misturar os dois torna o planeamento de capacidade posterior em conjectura.

O modelo de canal multicast específico da fonte é a referência para essa distinção. Escolha o desenho que escolher, anote o conjunto de pares elegíveis, o responsável pela replicação e o contador que lerá da próxima vez; esse registo é o que transforma uma surpresa de largura de banda num custo conhecido.