Guia Avançado de Infraestrutura para Streaming de Mídia, Transcodificação e Distribuição de Vídeo em Servidores VPS e VDS

O consumo de conteúdo em vídeo e áudio via streaming cresceu exponencialmente nos últimos anos. Seja para transmissões ao vivo de eventos, plataformas de ensino online (EAD), web TVs, transmissões de eSports ou sistemas corporativos de comunicação interna, a demanda por largura de banda e poder de processamento disparou. No entanto, depender de serviços de nuvem pública de grandes corporações para transcodificação e distribuição de vídeo pode se tornar financeiramente inviável à medida que o público cresce. Tarifas exorbitantes de tráfego de saída (egress fees) e o custo elevado por minuto de transcodificação em plataformas proprietárias forçam desenvolvedores e engenheiros de infraestrutura a buscar alternativas mais inteligentes, escaláveis e econômicas.

A solução para esse desafio reside na construção de uma infraestrutura própria de streaming de mídia utilizando servidores privados virtuais de alta performance e servidores dedicados virtuais. Combinando o poder de computação de um VDS (Virtual Dedicated Server) para processamento pesado, a agilidade do VPS Performance para entrega e caching de borda (edge nodes), e o espaço massivo do VPS Storage para armazenamento de acervos de vídeo sob demanda (VOD), é possível estruturar uma plataforma de nível empresarial com redução de custos que pode chegar a até 85% em comparação com as soluções de nuvem tradicionais.

Neste guia técnico definitivo, você aprenderá detalhadamente como projetar, configurar, otimizar e escalar uma arquitetura de streaming de vídeo de ultra-baixa latência e alta disponibilidade, utilizando tecnologias open-source como Nginx RTMP/SRT, FFmpeg, HLS/DASH e sistemas avançados de cache.

Infraestrutura de Transmissão de Vídeo e Streaming

1. Compreendendo a Arquitetura de Streaming de Mídia

Antes de colocar as mãos no terminal para configurar os servidores, é fundamental compreender o fluxo de vida de uma transmissão de vídeo digital, desde a captura na câmera do produtor até a reprodução na tela do usuário final. Esse pipeline é composto por quatro fases cruciais:

  • Ingestão (Ingest): O sinal de vídeo capturado é codificado localmente (por exemplo, no OBS Studio ou em uma câmera de hardware) e enviado para o servidor de processamento através de protocolos de transporte de baixa latência, como o tradicional RTMP (Real-Time Messaging Protocol) ou o moderno e resiliente SRT (Secure Reliable Transport).
  • Transcodificação (Transcoding): O servidor recebe o fluxo de alta qualidade e o decodifica para, em seguida, recodificá-lo em múltiplas resoluções e taxas de quadros (bitrates) simultaneamente (por exemplo, 1080p a 6000 kbps, 720p a 3000 kbps, 480p a 1200 kbps). Esse processo é chamado de Transmissão de Taxa de Bits Adaptável (ABR - Adaptive Bitrate Streaming).
  • Empacotamento (Packaging): O fluxo de vídeo transcodificado é segmentado em pequenos arquivos (geralmente com duração de 2 a 6 segundos) e organizado em listas de reprodução (arquivos indexadores de formato .m3u8 para HLS ou .mpd para DASH).
  • Entrega (Distribution/Delivery): Os pequenos arquivos de vídeo segmentados são distribuídos para os usuários finais através de servidores web configurados para cache agressivo de conteúdo estático.

O diagrama abaixo exemplifica como essas camadas se distribuem na infraestrutura ideal utilizando os servidores da CoelhoVPS:

Camada da Arquitetura Função Principal Tipo de Servidor Recomendado
Ingestão & Transcodificação Receber sinal de vídeo ao vivo, decodificar e recodificar em múltiplos formatos (ABR) usando FFmpeg. Requer alto poder de processamento estável. VDS (Virtual Dedicated Server)
Armazenamento VOD (Video On Demand) Hospedar gigabytes ou terabytes de arquivos de vídeo gravados (arquivos MP4 brutas, gravações DVR de transmissões ao vivo). VPS Storage
Distribuição de Conteúdo (Edge Caching) Entregar os arquivos segmentados de vídeo para milhares de usuários simultâneos, reduzindo a latência e protegendo o core do sistema. VPS Performance

2. Por que a Escolha do Hardware de Servidor é Crítica para Streaming

O processamento de vídeo é uma das atividades computacionais mais exigentes do mundo da TI. A compressão de imagens em movimento quadro a quadro requer bilhões de cálculos matemáticos por segundo. Se o hardware subjacente não possuir recursos garantidos, o gargalo se manifestará sob a forma de quedas bruscas na taxa de quadros (dropped frames), buffering constante para os espectadores e travamentos completos do pipeline de transmissão.

VDS: A Escolha Definitiva para Processamento e Transcodificação

Quando você realiza transcodificação de vídeo em tempo real em um ambiente de virtualização tradicional compartilhada, a sua aplicação pode sofrer com o efeito conhecido como "Noisy Neighbor" (vizinho barulhento). Se outra VPS hospedada no mesmo hipervisor físico começar a utilizar a CPU intensamente, o seu processo de codificação perderá ciclos essenciais de processamento, interrompendo a transmissão em tempo real.

O VDS (Virtual Dedicated Server) elimina esse problema por completo. Com recursos 100% dedicados (incluindo núcleos físicos de CPU Intel Xeon ou AMD EPYC dedicados exclusivamente à sua instância), você obtém desempenho bruto previsível e contínuo. Isso é crucial para que o decodificador e o codificador do FFmpeg possam operar em velocidade constante de compressão (speed > 1.0x), garantindo transmissões ao vivo fluidas sem riscos de gargalos de CPU compartilhada.

VPS Performance: Distribuição de Ultra-Baixa Latência

Uma vez transcodificado o vídeo, ele precisa chegar rapidamente aos usuários. A entrega de playlists HLS e arquivos de vídeo segmentados (.ts ou .m4s) depende de alta velocidade de leitura de disco e de uma excelente largura de banda de rede. O VPS Performance se destaca nessa função devido ao seu armazenamento NVMe ultra-rápido de baixíssima latência e canais de rede de alta capacidade. Configurar nós de VPS Performance geograficamente distribuídos atuando como proxies de cache reversos garante que os dados sejam servidos instantaneamente do disco ou da memória RAM mais próximos do espectador.

VPS Storage: O Repositório de Arquivos sob Demanda

Se a sua plataforma armazena gravações de lives (DVR) ou possui um vasto catálogo de vídeos gravados (VOD), armazenar esses arquivos pesados em discos SSD ou NVMe de alta performance pode se tornar financeiramente inviável. É aqui que entra o VPS Storage. Ele fornece capacidades massivas de armazenamento a custos extremamente baixos por Gigabyte, servindo como o repositório centralizado ideal de onde as instâncias de entrega puxam os vídeos sob demanda para realizar o cache local na borda da rede.

Código de Programação e Configuração de Servidores

3. Configurando o Servidor de Ingestão: Nginx com Módulo RTMP

Vamos iniciar a parte prática construindo o nosso servidor de ingestão de mídia. Utilizaremos o sistema operacional Ubuntu 22.04 LTS instalado em um servidor VDS de alta performance. O Nginx, estendido com o módulo RTMP, atuará como o gateway que recebe a transmissão do OBS Studio ou similar e a prepara para o FFmpeg.

Passo 1: Instalação das Dependências e Compilação do Nginx

Embora existam pacotes pré-compilados do Nginx, compilar a partir do código-fonte com o módulo RTMP garante que tenhamos o controle total de performance, habilitando otimizações de CPU específicas para o nosso hardware.

# Atualizar o sistema operacional
sudo apt update && sudo apt upgrade -y

# Instalar dependências essenciais de compilação
sudo apt install -y build-essential libpcre3 libpcre3-dev libssl-dev zlib1g-dev git

# Criar diretório de trabalho
mkdir ~/build && cd ~/build

# Clonar o módulo RTMP para Nginx
git clone https://github.com/arut/nginx-rtmp-module.git

# Baixar a versão mais recente e estável do Nginx (ex: 1.24.0)
wget http://nginx.org/download/nginx-1.24.0.tar.gz
tar -zxvf nginx-1.24.0.tar.gz
cd nginx-1.24.0

# Configurar e compilar o Nginx incluindo o módulo RTMP
./configure --with-http_ssl_module --add-module=../nginx-rtmp-module
make
sudo make install

Por padrão, o Nginx compilado manualmente será instalado no diretório /usr/local/nginx. Vamos criar um link simbólico para gerenciar o serviço facilmente e configurar um arquivo de serviço do Systemd para gerenciar o processo do Nginx.
# Criar link simbólico para o executável do Nginx
sudo ln -s /usr/local/nginx/sbin/nginx /usr/sbin/nginx

# Criar arquivo de serviço Systemd para o Nginx
sudo nano /etc/systemd/system/nginx.service

Insira o seguinte conteúdo no arquivo do Systemd:
[Unit]
Description=The NGINX HTTP and reverse proxy server
After=syslog.target network-online.target remote-fs.target nss-lookup.target
Wants=network-online.target

[Service]
Type=forking
PIDFile=/usr/local/nginx/logs/nginx.pid
ExecStartPre=/usr/sbin/nginx -t
ExecStart=/usr/sbin/nginx
ExecReload=/usr/sbin/nginx -s reload
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Salve o arquivo, recarregue o daemon do Systemd e habilite o serviço para iniciar automaticamente com o boot do servidor:
sudo systemctl daemon-reload
sudo systemctl start nginx
sudo systemctl enable nginx

Passo 2: Configurando o Bloco RTMP no Nginx
Agora, precisamos editar o arquivo principal de configuração do Nginx (/usr/local/nginx/conf/nginx.conf) para estruturar a nossa porta de ingestão RTMP. O RTMP opera nativamente na porta 1935.
# Fazer backup do arquivo original
sudo cp /usr/local/nginx/conf/nginx.conf /usr/local/nginx/conf/nginx.conf.bak

# Abrir o arquivo para edição
sudo nano /usr/local/nginx/conf/nginx.conf

Substitua ou adicione as seguintes diretivas ao final do arquivo de configuração para ativar o suporte ao protocolo RTMP:
rtmp {
    server {
        listen 1935; # Porta padrão do protocolo RTMP
        chunk_size 4096;

        application live {
            live on;
            record off; # Desativado para economizar disco no nó de ingestão imediato
            
            # Autenticação básica simples via chave de stream (Stream Key)
            # A chave definida no OBS será usada para validar a transmissão
            on_publish http://localhost/auth;
        }
    }
}

http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;

    server {
        listen 80;
        server_name localhost;

        # Endpoint interno para autenticação simples da chave de transmissão
        location /auth {
            if ($arg_key = 'SuaChaveSecretaDeStreaming123') {
                return 201; # Chave aceita, autoriza a publicação do fluxo
            }
            return 403; # Chave incorreta, rejeita a publicação
        }
    }
}

No exemplo acima, configuramos uma verificação simples de chave de stream. No OBS Studio, ao configurar a transmissão, o usuário definirá o servidor como rtmp://IP_DO_SEU_VDS/live e a chave de transmissão como ?key=SuaChaveSecretaDeStreaming123. O Nginx interceptará a requisição de publicação, fará uma chamada local para o bloco /auth e só permitirá a ingestão se o parâmetro bater exatamente com a chave estipulada.
Teste a configuração do Nginx e reinicie o serviço:
sudo nginx -t
sudo systemctl restart nginx

4. O Pipeline de Transcodificação de Alta Performance com FFmpeg
Agora que o servidor VDS é capaz de receber com sucesso o vídeo em tempo real por meio do protocolo RTMP, entra em cena o componente mais poderoso da nossa infraestrutura: o FFmpeg. O FFmpeg será encarregado de decodificar o stream de vídeo recebido em tempo real e re-codificá-lo de forma eficiente em múltiplas qualidades para criar uma experiência adaptativa perfeita para os espectadores, independentemente da velocidade de internet deles.
Abstração de Fluxo de Dados Digitais e Conectividade
Por que o VDS brilha na Transcodificação Multi-bitrate
O processo de transcodificação em tempo real é extremamente sensível ao tempo de CPU. Se o processador levar mais do que 1 segundo para processar 1 segundo de vídeo (fator de velocidade menor que 1.0x), o fluxo começará a atrasar, os buffers de memória vão estourar e a transmissão cairá. O uso de um VDS com recursos de CPU dedicados garante que threads paralelas do codificador de vídeo x264 funcionem em potência máxima, sem latências adicionais provocadas por compartilhamento de hardware.
Instalação do FFmpeg
Instalaremos o FFmpeg completo com todas as bibliotecas necessárias para codificação x264 (H.264), x265 (HEVC), e codificação de áudio AAC:
sudo apt install -y ffmpeg

Configurando a Transcodificação Direta no Nginx
Podemos instruir o módulo RTMP do Nginx a disparar um processo em segundo plano do FFmpeg assim que um fluxo de vídeo ao vivo começar a ser ingerido no servidor. Para fazer isso, modificaremos a seção do aplicativo live no arquivo nginx.conf.
Edite o arquivo de configuração:
sudo nano /usr/local/nginx/conf/nginx.conf

Atualize a seção rtmp para incluir a chamada automática do FFmpeg:
rtmp {
    server {
        listen 1935;
        chunk_size 4096;

        application live {
            live on;
            record off;
            
            # Autenticação de fluxo
            on_publish http://localhost/auth;

            # Ao receber a live, o Nginx dispara o FFmpeg para criar 3 qualidades de vídeo
            exec ffmpeg -i rtmp://localhost:1935/live/$name -async 1 -vsync -1 
                # Configurações do perfil High (1080p)
                -c:v libx264 -preset veryfast -b:v 4500k -maxrate 4500k -bufsize 9000k -s 1920x1080 -r 30 -g 60 -keyint_min 60 -sc_threshold 0 
                -c:a aac -b:a 192k -ar 44100 -ac 2 
                -f flv rtmp://localhost:1935/show/$name_1080 
                
                # Configurações do perfil Medium (720p)
                -c:v libx264 -preset veryfast -b:v 2200k -maxrate 2200k -bufsize 4400k -s 1280x720 -r 30 -g 60 -keyint_min 60 -sc_threshold 0 
                -c:a aac -b:a 128k -ar 44100 -ac 2 
                -f flv rtmp://localhost:1935/show/$name_720
                
                # Configurações do perfil Low (480p)
                -c:v libx264 -preset veryfast -b:v 800k -maxrate 800k -bufsize 1600k -s 854x480 -r 30 -g 60 -keyint_min 60 -sc_threshold 0 
                -c:a aac -b:a 96k -ar 44100 -ac 2 
                -f flv rtmp://localhost:1935/show/$name_480;
        }

        # Nova aplicação interna onde o FFmpeg enviará as qualidades criadas
        application show {
            live on;
            record off;
            # Permite publicações apenas originadas localmente (do FFmpeg rodando no próprio servidor)
            allow publish 127.0.0.1;
            deny publish all;
        }
    }
}

Com essa alteração detalhada, quando o sinal de ingestão original (por exemplo, batizado de "minha_live") for enviado para o aplicativo live, o FFmpeg dividirá automaticamente a transmissão original em três versões distintas, reenviando-as internamente para o aplicativo show como minha_live_1080, minha_live_720 e minha_live_480. Tudo isso de forma automatizada e com latência mínima.
5. Empacotamento de Vídeo: Gerando HLS (HTTP Live Streaming) e DASH
Agora que temos os fluxos transcodificados individuais, o próximo passo crítico é convertê-los em formatos de streaming baseados em HTTP (HLS e DASH). O HLS é o formato de distribuição mais popular do mercado devido à sua compatibilidade nativa com quase todos os navegadores, dispositivos móveis (especialmente ecossistemas iOS e macOS), Smart TVs e consoles de videogames.
Para gerar as listas de reprodução HLS (.m3u8) e os blocos de vídeo correspondentes (.ts), estenderemos a aplicação show no Nginx de forma a transformar esses streams RTMP recebidos em fragmentos prontos para entrega estática via Web.
Criando o Diretório de Cache HLS em Ramdisk
Uma grande dica de performance que faz toda a diferença: os arquivos fragmentados do HLS (.ts) são criados, atualizados e apagados constantemente (a cada poucos segundos). Se permitirmos que o Nginx grave esses pedaços de vídeo diretamente no disco rígido convencional ou SSD do servidor, causaremos um desgaste desnecessário de escrita no armazenamento (Write Amplification) e gargalos de I/O de disco sob alto tráfego. 
A solução ideal é utilizar um diretório baseado em RAM (utilizando o sistema de arquivos tmpfs), que garante velocidade de leitura/escrita infinita e latência de gravação virtualmente nula.
# Criar diretório para o HLS
sudo mkdir -p /mnt/ramdisk/hls

# Montar o diretório como ramdisk (tmpfs) com capacidade limitada (ex: 2GB é ideal para armazenar pequenos buffers temporários de lives)
sudo mount -t tmpfs -o size=2G tmpfs /mnt/ramdisk/hls

# Persistir a montagem no /etc/fstab para garantir que sobreviva a reboots
echo 'tmpfs /mnt/ramdisk/hls tmpfs defaults,size=2G 0 0' | sudo tee -a /etc/fstab

# Garantir permissões de leitura e escrita ao usuário do Nginx (normalmente nobody ou www-data)
sudo chown -R nobody:nogroup /mnt/ramdisk/hls

Atualizando as Diretivas do HLS no Nginx
Agora, vamos configurar o Nginx para realizar o empacotamento HLS diretamente dentro deste ramdisk de alta velocidade. Abra novamente o arquivo /usr/local/nginx/conf/nginx.conf e adicione as regras de HLS para a aplicação show:
# Atualização completa do bloco application show dentro da seção rtmp
        application show {
            live on;
            record off;
            allow publish 127.0.0.1;
            deny publish all;

            # Ativação do protocolo HLS
            hls on;
            hls_path /mnt/ramdisk/hls;
            
            # Tamanho do segmento de vídeo (2 segundos para latência reduzida)
            hls_fragment 2s;
            
            # Tamanho máximo de playlist em segundos (mantém os últimos 10 segundos no ar)
            hls_playlist_length 10s;
            
            # Variantes de qualidade (Adaptive Bitrate Mapping)
            hls_variant _1080 BANDWIDTH=4500000,RESOLUTION=1920x1080;
            hls_variant _720  BANDWIDTH=2200000,RESOLUTION=1280x720;
            hls_variant _480  BANDWIDTH=800000,RESOLUTION=854x480;
            
            # Evitar problemas de dessincronização de áudio em conexões instáveis
            hls_cleanup on;
        }

Expondo os Arquivos HLS via HTTP
Para que os navegadores e reprodutores de vídeo de terceiros (como Video.js, Clappr, ou Hls.js) consigam acessar esses arquivos fragmentados .m3u8 e .ts gerados na RAM, precisamos expor esse diretório através de um bloco de servidor HTTP regular. Além disso, é obrigatório tratar a política de compartilhamento de recursos (CORS - Cross-Origin Resource Sharing) para evitar que os navegadores recusem carregar o streaming vindo de domínios externos.
Edite a seção http do arquivo nginx.conf:
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;

    server {
        listen 80;
        server_name stream.seudominio.com;

        # Diretório do streaming HLS
        location /hls {
            types {
                application/vnd.apple.mpegurl m3u8;
                video/mp2t ts;
            }
            
            root /mnt/ramdisk;
            
            # Controle de Cabeçalhos CORS
            add_header 'Access-Control-Allow-Origin' '*' always;
            add_header 'Access-Control-Allow-Methods' 'GET, OPTIONS' always;
            add_header 'Access-Control-Allow-Headers' 'Range' always;
            add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range' always;
            
            if ($request_method = 'OPTIONS') {
                add_header 'Access-Control-Max-Age' 1728000;
                add_header 'Content-Type' 'text/plain; charset=utf-8';
                add_header 'Content-Length' 0;
                return 204;
            }

            # Desativar cache do navegador para os índices .m3u8 (devem atualizar constantemente)
            location ~* \.m3u8$ {
                add_header Cache-Control "no-cache, no-store, must-revalidate";
                add_header Pragma "no-cache";
                add_header Expires 0;
                add_header 'Access-Control-Allow-Origin' '*' always;
            }

            # Ativar cache agressivo de navegadores apenas para os arquivos físicos segmentados .ts
            location ~* \.ts$ {
                add_header Cache-Control "public, max-age=86400";
                add_header 'Access-Control-Allow-Origin' '*' always;
            }
        }
    }
}

Reinicie o Nginx para aplicar as alterações e iniciar o empacotamento HLS:
sudo nginx -t
sudo systemctl restart nginx

6. Construindo uma Rede de Distribuição Própria (CDN Privada) usando VPS Performance
Hospedar a ingestão, transcodificação e distribuição em um único servidor VDS é perfeitamente viável para centenas de usuários simultâneos. Contudo, quando a audiência atinge a marca de milhares de conexões ao mesmo tempo, a demanda por largura de banda e capacidade de envio do servidor de origem pode se esgotar, causando travamentos generalizados. 
Além disso, a distância geográfica entre o servidor e o usuário final afeta diretamente a latência do stream. Para mitigar isso, estruturamos uma arquitetura de CDN privada resiliente e extremamente barata utilizando nós distribuídos de VPS Performance atuando como proxies reversos de cache de borda (Edge nodes).
Datacenter e Servidores de Alta Conectividade
Como Funciona o Edge Caching de Vídeo
Nesta topologia, o servidor VDS original (Origem) realiza todo o trabalho pesado de receber e transcodificar o vídeo. Ele não entrega o vídeo diretamente aos usuários. Em vez disso, criamos uma rede de servidores VPS Performance (Edges) espalhados estrategicamente.
Quando o reprodutor do usuário solicita um pedaço de vídeo (por exemplo, segmento_120.ts), a solicitação atinge o servidor VPS Performance mais próximo do usuário. 
      
  1. Se o VPS Performance já possuir o arquivo em cache (Cache Hit), ele o entrega imediatamente para o usuário.
    2.   
  2. Se o arquivo ainda não estiver no cache (Cache Miss), o VPS Performance baixa o fragmento silenciosamente do servidor VDS de origem, armazena-o localmente em seu armazenamento NVMe ultra-rápido e o entrega ao usuário final.
Como os fragmentos de vídeo .ts são estáticos e nunca mudam, o fator de acerto do cache (cache hit ratio) atinge taxas superiores a 98%, blindando completamente o servidor VDS principal e consumindo muito menos largura de banda na origem.
Configuração do Nó de Borda (Edge VPS) no Nginx
Em cada servidor VPS Performance destinado a atuar como distribuidor, instale o Nginx padrão através do gerenciador de pacotes do próprio Ubuntu (não é necessária compilação para nós puramente de cache):
sudo apt update && sudo apt install nginx -y

Crie uma área de armazenamento dedicada em disco rápido no VPS Performance para guardar o cache do streaming:
sudo mkdir -p /var/cache/nginx_hls
sudo chown -R www-data:www-data /var/cache/nginx_hls

Agora, edite o arquivo de configuração do Nginx deste nó de borda (/etc/nginx/sites-available/default):
# Definição do diretório de armazenamento física do cache e parâmetros de performance
proxy_cache_path /var/cache/nginx_hls levels=1:2 keys_zone=hls_cache:100m max_size=10g inactive=60m use_temp_path=off;

server {
    listen 80;
    server_name cdn.seudominio.com;

    # Habilitar compressão Gzip para agilizar a entrega de manifests .m3u8
    gzip on;
    gzip_types application/vnd.apple.mpegurl text/plain;

    location /hls/ {
        # Endereço IP ou Domínio do seu VDS de Origem
        proxy_pass http://IP_DO_SEU_VDS/hls/;
        
        # Configuração das chaves de cache
        proxy_cache hls_cache;
        proxy_cache_key "$uri$is_args$args";
        
        # Definição dos códigos HTTP de sucesso que serão cacheados
        proxy_cache_valid 200 302 10m;
        proxy_cache_valid 404 1m;
        
        # Otimizações críticas de conexão e tráfego simultâneo
        proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
        proxy_cache_lock on;
        proxy_cache_lock_timeout 5s;
        
        # Adiciona cabeçalho informativo sobre o status do cache (HIT ou MISS)
        add_header X-Cache-Status $upstream_cache_status;
        
        # Forçar entrega rápida sem bloqueio de buffers intermediários no proxy
        proxy_buffering on;
        
        # Tratamento de CORS na borda
        add_header 'Access-Control-Allow-Origin' '*' always;
        add_header 'Access-Control-Allow-Methods' 'GET, OPTIONS' always;
        add_header 'Access-Control-Allow-Headers' 'Range' always;
    }
}

Teste e reinicie o serviço no nó de borda para torná-lo ativo:
sudo nginx -t
sudo systemctl restart nginx

Para escalar, basta provisionar múltiplos servidores VPS Performance em diferentes localizações e utilizar um sistema de DNS com balanceamento de carga Round-Robin ou direcionamento por geolocalização (GeoDNS) para guiar o espectador ao servidor mais próximo geograficamente.
7. Otimizações de Kernel e de Rede para Tráfego de Alta Densidade
Hospedar uma infraestrutura de streaming significa lidar com milhares de requisições por segundo e uma grande quantidade de conexões de soquetes abertos simultâneos. Por padrão, as distribuições Linux vêm configuradas de fábrica para servidores de uso genérico e limitam drasticamente o uso de conexões de rede simultâneas para evitar sobrecarga acidental de memória.
Para garantir que o seu servidor VDS de transcodificação e os nós de distribuição VPS Performance consigam extrair o máximo de rendimento das suas interfaces de rede físicas, precisamos realizar ajustes avançados no Kernel do Linux alterando os parâmetros de pilha de rede TCP/IP.
Abra o arquivo de configuração do sistema:
sudo nano /etc/sysctl.conf

Adicione as seguintes linhas ao final do arquivo para otimizar a pilha de conexões de rede do seu servidor:
# Aumentar o limite máximo de arquivos e conexões abertas no sistema operacional
fs.file-max = 2097152

# Aumentar a quantidade máxima de conexões simultâneas pendentes na fila do kernel
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 100000

# Otimização do tamanho dos buffers de recepção e envio de dados para redes de alta largura de banda
net.core.rmem_default = 262144
et.core.wmem_default = 262144
net.core.rmem_max = 16777216
et.core.wmem_max = 16777216

# Configurações do buffer TCP para auto-tunning de performance de rede
net.ipv4.tcp_rmem = 4096 87380 16777216
et.ipv4.tcp_wmem = 4096 65536 16777216

# Habilitar o algoritmo BBR de controle de congestionamento desenvolvido pelo Google
# Essencial para streaming fluido, pois reduz o buffering em conexões móveis ou instáveis
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

# Reutilização rápida de conexões TCP em estado de TIME_WAIT
net.ipv4.tcp_tw_reuse = 1

# Desativar o mecanismo de início lento após ociosidade de conexão (mantém a velocidade máxima ativa)
net.ipv4.tcp_slow_start_after_idle = 0

Aplique instantaneamente as novas otimizações do sistema sem a necessidade de reiniciar a máquina física:
sudo sysctl -p

8. Armazenamento e Distribuição de Vídeo Sob Demanda (VOD) com VPS Storage
Até o momento, focamos no pipeline de transmissões ao vivo. E se o seu objetivo também englobar a criação de uma plataforma de streaming de vídeos gravados, similar a plataformas famosas de cursos ou entretenimento sob demanda (VOD)?
O armazenamento de arquivos originais MP4 e seus respectivos empacotamentos HLS transcodificados exige terabytes de espaço em disco. Para manter o custo-benefício, o seu design de infraestrutura deve usar o VPS Storage da CoelhoVPS.
Montando um Sistema de Arquivos Centralizado com SSHFS ou NFS
O VPS Storage será o nosso servidor central de arquivos de mídia (NAS). Para permitir que a origem de processamento (VDS) e as bordas de entrega (VPS Performance) acessem os vídeos gravados diretamente, podemos estabelecer uma conexão de rede compartilhada e segura usando o protocolo NFS (Network File System).
Configuração no Servidor VPS Storage (Servidor NFS):
# Instalar servidor NFS
sudo apt update && sudo apt install nfs-kernel-server -y

# Criar diretório que hospedará a biblioteca de vídeos
sudo mkdir -p /var/media_library
sudo chown -R nobody:nogroup /var/media_library
sudo chmod 777 /var/media_library

# Editar o arquivo de exportação para autorizar o acesso seguro do VDS e VPS Performance
sudo nano /etc/exports

Adicione a seguinte regra permitindo o acesso à biblioteca apenas aos IPs autorizados da sua infraestrutura:
/var/media_library   IP_DO_SEU_VDS(rw,sync,no_subtree_check) IP_DO_VPS_PERFORMANCE(ro,sync,no_subtree_check)

Inicie e exporte o serviço NFS:
sudo systemctl restart nfs-kernel-server

Configuração de Montagem no VDS de Transcodificação:
Agora, o VDS de processamento pode montar essa pasta de armazenamento remoto diretamente em seu próprio sistema de arquivos local de maneira transparente:
# Instalar dependências de cliente NFS
sudo apt update && sudo apt install nfs-common -y

# Criar o ponto de montagem local
sudo mkdir -p /mnt/vod_storage

# Montar o diretório de armazenamento remoto do VPS Storage
sudo mount IP_DO_VPS_STORAGE:/var/media_library /mnt/vod_storage

Ao finalizar uma gravação de live ou fazer o upload de novos conteúdos gravados, o processo do FFmpeg será instruído a ler o arquivo do diretório /mnt/vod_storage, realizar a transcodificação e salvar a estrutura de arquivos HLS final diretamente de volta nesse mesmo diretório compartilhado. As bordas de entrega farão a leitura desse mesmo diretório montado para realizar o cache e distribuir de forma extremamente rápida para os espectadores.
Conclusão e Próximos Passos
Construir a sua própria infraestrutura de streaming de vídeo não é apenas uma excelente oportunidade técnica de aprendizado arquitetural, mas também uma decisão de negócio estratégica altamente lucrativa. Ao optar por sair de arquiteturas proprietárias em nuvens sobretaxadas e adotar uma infraestrutura sob seu total controle, você ganha autonomia de mercado, controle absoluto de segurança de dados e uma economia financeira sem precedentes.
Com os servidores dedicados e virtuais da CoelhoVPS, você tem todas as peças necessárias para montar esse ecossistema escalável de alta performance de mídia:
      
  • Utilize o poder das CPUs dedicadas e o isolamento de hardware de um plano de VDS (Virtual Dedicated Server) para processar, decodificar e transcodificar streams pesados de vídeo sem perda de frames ou oscilações de performance.
    •   
  • Aloque múltiplos nós de VPS Performance nas bordas para cachear e distribuir as transmissões com latência reduzida e alta vazão de largura de banda e discos NVMe ultra-rápidos.
    •   
  • Garanta a expansão sustentável da sua biblioteca de mídia gravada com o armazenamento massivo e econômico de um plano de VPS Storage atuando como servidor centralizado.
Explore os planos da CoelhoVPS hoje mesmo e comece a escalar o seu projeto de streaming com hardware robusto, suporte especializado e a estabilidade necessária para suportar milhares de acessos com tranquilidade.