Zonas de entrega¶

Uma zona é a unidade a partir da qual o espectador assiste. Em uma rede corporativa uma unidade costuma coincidir com um escritório: o escritório de Moscou tem os seus servidores, o de São Petersburgo os dele, e um funcionário não tem motivo para puxar a transmissão do outro lado do país quando a imagem está disponível na sua própria sala de servidores.

As zonas respondem a uma única pergunta: para qual servidor enviar o espectador que acabou de abrir uma transmissão.

Como um espectador cai em uma zona¶

Uma zona é descrita por uma lista de sub-redes em notação CIDR — 10.10.0.0/16, 2a02:6b8::/32. IPv4 e IPv6 convivem na mesma lista.

Quando um espectador abre uma transmissão, o endereço dele é comparado com as sub-redes de todas as zonas. Vence o prefixo coincidente mais longo, ou seja, a descrição mais precisa. Isso permite descrever a rede em camadas: uma zona ampla para toda a empresa e zonas estreitas para cada escritório dentro dela; o funcionário de um escritório cai na sua própria zona, enquanto um visitante vindo de uma sub-rede que ninguém descreveu à parte cai na geral.

Os servidores são vinculados a uma zona nas configurações deles: uma zona não é uma lista de máquinas, e sim um atributo da máquina.

A zona de reserva¶

Uma zona pode indicar uma zona de reserva: para onde levar o espectador quando na dele não resta nenhum servidor vivo. É isso que transforma a queda da sala de servidores de um escritório de «a transmissão acabou» em «a transmissão está mais lenta».

A reserva é uma referência, não uma cópia: uma cadeia de zonas pode seguir adiante, e é permitida uma referência a uma zona que ainda não existe — a cadeia simplesmente termina ali.

Por que isso interessa a um difusor corporativo¶

O sentido das zonas não é economizar tráfego em si, e sim onde está o gargalo. Uma reunião geral é assistida por todos os escritórios ao mesmo tempo, e o enlace entre as unidades é o único lugar onde mil espectadores viram mil fluxos. As zonas mantêm esse tráfego dentro da unidade: entre escritórios viaja um fluxo, não mil.

Por isso as zonas são configuradas antes da primeira reunião grande, não depois dela.

Rotas explícitas e recusa¶

Uma única zona ativa o roteamento CDN. O central seleciona somente nós da zona do cliente e da cadeia explícita fallback_zone. Nós sem zona e zonas alheias ficam excluídos. none (null na API), uma zona inexistente ou repetida encerram a cadeia. Sem destinos aptos, o central responde 503 com Retry-After; um stream desconhecido recebe 404.

Sem CIDR correspondente ou IP do cliente também há recusa. Configure explicitamente 0.0.0.0/0 para IPv4 e ::/0 para IPv6 se precisar de uma rota geral. Mesmo uma zona sem rotas ativa esse modo. Excluir a última zona restaura a seleção sem restrições: primeiro edge, depois ingest.

A origem não é uma reserva universal. Espectadores de um escritório com falha podem sobrecarregá-la e prejudicar outros escritórios. Para permiti-la, atribua o nó de origem a origin-pool, crie essa zona (as rotas podem ficar vazias) e use-a como reserva do escritório. O nome não tem significado especial. Uma origem na própria zona do cliente também é explicitamente permitida.

Carga e limites¶

Na mesma zona, edge e ingest são iguais: vence o nó com menos sessões Play ativas; empates são distribuídos uniformemente. A origem não tem prioridade especial. JSON ordena zonas pela cadeia e nós por carga crescente; endereços privados são excluídos. GET normal permite proxy e entrega local.

A seção CDN do nó oferece dois campos independentes:

• playback_session_limit: limite de sessões Play ativas, sem Publish.
• playback_bandwidth_kbit: tráfego de saída de todo o host em kbit/s, incluindo tráfego entre nós. Independente de network_bandwidth_kbit, o orçamento RX+TX de alocação.

Vazio remove o limite; 0 impede novas seleções. Um valor igual ou superior ao limite exclui o nó. Se todos forem excluídos, tenta-se a próxima zona explícita. Métricas necessárias ausentes excluem o nó; o último relatório vale enquanto estiver online. Limites explícitos também se aplicam sem zonas.

Os limites afetam novas decisões do central. Relatórios atrasados e URLs já emitidas permitem ultrapassá-los. Não limitam a banda nem encerram sessões. O player recebe alterações na próxima solicitação de rotas; URLs existentes não são revogadas.

Para VOD, primeiro filtram-se as réplicas disponíveis pelas zonas permitidas; depois selecionam-se a maior revisão disponível, a zona e a carga. Uma réplica recente proibida não exclui uma antiga permitida; uma reserva permitida mais recente pode prevalecer sobre a cópia local antiga.

Um proxy confiável¶

Informe CIDRs em Proxies confiáveis do cluster, nas configurações compartilhadas do central, um prefixo por linha. A lista vale para todo o cluster, incluindo todas as instâncias do central e os streamers, sem exceções locais. Por exemplo:

192.0.2.10/32
2001:db8::10/128

Somente de um par confiável aceita-se o último IP de X-Forwarded-For. O proxy deve acrescentar o endereço real do cliente. Se ausente ou inválido, usa-se o IP da conexão; X-Real-IP é ignorado. Uma lista vazia não confia em cabeçalhos. Uma cadeia de vários proxies confiáveis não é suportada.

As alterações e a limpeza da lista são aplicadas automaticamente na atualização da configuração, sem reiniciar. Um CIDR inválido é rejeitado e o campo mostra o erro. A API expõe trusted_proxies por PATCH /central/api-v4/config; um array vazio ou null remove a confiança em todos os proxies. O listener determina o esquema da URL pública.