DEV Community: Juan Nunes

Criando seu próprio servidor de stream usando NGINX- RTMP

Juan Nunes — Thu, 27 Oct 2022 12:20:47 +0000

Objetivo desse Post é mostrar como é simples criar um servidor de stream utilizando o NGINX.

Protocolos de transmissão de vídeo

Antes de começarmos a configurar o nosso servidor precisamos conhecer um pouco dos Protocolos que utilizaremos, no nosso caso teremos o RTMP e o HLS.

RTMP - (Real Time Messaging Protocol) é um sistema baseado no protocolo TCP e foi criado excluisivamente para transmissão de Vídeo, Áudio e Dados. Os Dados podem ser transmitidos em Live(ao vivo) ou pre-recorded (Pré-gravado) além disso pode ser compartilhado mensagens de bate papo e push de notificações. Foi criado com intuito de transmitir mídia entre um servidor e o Adobe flash Player.

Um dos pontos positivos de utilizar o RTMP é a baixa latência que ele possui.

HLS - (HTTP Live Streaming) Como o própio nome diz o HLS é um sistema baseado no protocolo HTTP e foi criado pela apple para ser a evolução do RTMP no cenário de Mídia. Uma das vantagens desse protocolo é a sua adaptabilidade a diferentes dispositivos e resoluções. Por ser baseado em HTTP ele não é bem um "stream" pois no final das contas acaba fazendo múltiplas requisições e enviando pequenos fragmentos do conteúdo, com essa fragmentação devido as múltiplas requisições ele "escolhe" qual qualidade deve ser enviada de acordo com o dispositivo e conexão.

Diferente do RTMP esse protocolo possui uma alta latência, porém pode ser mitigada utilizando outros recurso em conjunto.

Criando o Servidor

Para criação do servidor utilizaremos o Docker para subir nossa imagem com Nginx.

No código abaixo temos o nosso Dockerfile com seus Workflows. Para possibilitar o nginx utilizar o RTMP nos utilizaremos um modulo chamado NGINX_RTMP_MODULE.



FROM buildpack-deps:stretch


ENV NGINX_VERSION nginx-1.18.0
ENV NGINX_RTMP_MODULE_VERSION 1.2.1


RUN apt-get update && \
    apt-get install -y ca-certificates openssl libssl-dev && \
    rm -rf /var/lib/apt/lists/*


RUN mkdir -p /tmp/build/nginx && \
    cd /tmp/build/nginx && \
    wget -O ${NGINX_VERSION}.tar.gz https://nginx.org/download/${NGINX_VERSION}.tar.gz && \
    tar -zxf ${NGINX_VERSION}.tar.gz


RUN mkdir -p /tmp/build/nginx-rtmp-module && \
    cd /tmp/build/nginx-rtmp-module && \
    wget -O nginx-rtmp-module-${NGINX_RTMP_MODULE_VERSION}.tar.gz https://github.com/arut/nginx-rtmp-module/archive/v${NGINX_RTMP_MODULE_VERSION}.tar.gz && \
    tar -zxf nginx-rtmp-module-${NGINX_RTMP_MODULE_VERSION}.tar.gz && \
    cd nginx-rtmp-module-${NGINX_RTMP_MODULE_VERSION}


RUN cd /tmp/build/nginx/${NGINX_VERSION} && \
    ./configure \
        --sbin-path=/usr/local/sbin/nginx \
        --conf-path=/etc/nginx/nginx.conf \
        --error-log-path=/var/log/nginx/error.log \
        --pid-path=/var/run/nginx/nginx.pid \
        --lock-path=/var/lock/nginx/nginx.lock \
        --http-log-path=/var/log/nginx/access.log \
        --http-client-body-temp-path=/tmp/nginx-client-body \
        --with-http_ssl_module \
        --with-threads \
        --with-ipv6 \
        --add-module=/tmp/build/nginx-rtmp-module/nginx-rtmp-module-${NGINX_RTMP_MODULE_VERSION} && \
    make -j $(getconf _NPROCESSORS_ONLN) && \
    make install && \
    mkdir /var/lock/nginx && \
    rm -rf /tmp/build

RUN ln -sf /dev/stdout /var/log/nginx/access.log && \
    ln -sf /dev/stderr /var/log/nginx/error.log

COPY nginx.conf /etc/nginx/nginx.conf

EXPOSE 1935
CMD ["nginx", "-g", "daemon off;"]

Agora precisamos do nosso arquivo de configuração do nginx o nginx.conf



worker_processes auto;
rtmp_auto_push on;
events {}

rtmp {
    server {
        listen 1935;

        application live {

            live        on; mm

            hls         on;
            hls_path    /tmp/hls;
            hls_fragment 5s;
        }
    }
}

http {
    server {
        listen 80;

        location /hls {
            root /tmp;
        }

        location / {
            add_header 'Access-Control-Allow-Origin' '*' always;
            root /tmp;
        }
    }
}

O arquivo de configuração é bem simples, apenas para colocar no ar o servidor e exemplificar seu uso.

rtmp_auto_push - Possibilita fazer mais de uma transmissão ao mesmo tempo.
listen 1935 - Essa é a porta padrão do RTMP.
live on - habilita a transmissão usando o RTMP.
hls_fragment - Tamanho do fragmento que será enviado.

Tendo esses 2 arquivos já podemos rodar nosso servidor, utilize os comandos abaixo para subir o container.

Build do container:



docker image build -t devtojuan/stream-server .

Subir o container:



docker container run -p 1935:1935 -p 8080:80 devtojuan/stream-server

Iniciando Stream

Para começar sua stream você vai precisar de algum software que transmita, podendo ser OBS Studio, Xsplit, Lightstream etc.

Para iniciar a transmissão informe a url da stream.

Como estamos usando a porta 1935(padrão do rtmp) não é necessário informá-la junto ao caminho.



rtmp://localhost/live/teste

Agora para assistir a livestream vai precisar de um player que consiga transmitir. O VLC é o mais recomendado.

Basta informar esse caminho ao player:



http://localhost/hls/teste.m3u8

Um pouco sobre o NGINX pt.1

Juan Nunes — Mon, 24 Oct 2022 15:34:51 +0000

O NGINX (Engine X) é um Software Open Source que tem como funcionalidade principal atender requisições HTTP na web.
Porém ele não serve somente para isso, não é atoa que ele é o webserver mais utilizado na internet. Além de atender requisições HTTP de forma excepcional existe uma serie de recursos que o torna cada vez mais interessante, sendo elas: proxy reverso, armazenamento em cache, balanceamento de carga, streaming de mídia e muitas vezes utilizado para funcionar como um servidor proxy para e-mail (IMAP, POP3 e SMTP). Mais a frente falo um pouco sobre cada uma dessas funcionalidades do nginx e em quais contextos são mais utilizadas.

História por trás

O NGINX foi escrito originalmente para resolver a dificuldade que os servidores web existentes enfrentavam em lidar com grandes números (os 10K ) de conexões simultâneas.

Em 2004 seu fundador Igor Sysoev após ver seu uso crescer exponencialmente, decide a abrir o código do projeto e cria a NGINX, Inc. para dar suporte ao desenvolvimento contínuo do NGINX e comercializar o NGINX Plus como um produto comercial para clientes corporativos.

Diferenças entre Apache e NGINX

O NGINX supera o Apache e alguns outros servidores em benchmarks que medem o desempenho de servidores web, Desde o lançamento do NGINX. No entanto, os sites evoluiram de páginas HTML estáticas para conteúdo dinâmico. O NGINX cresceu junto com ele e agora suporta todos os componentes da Web "moderna", incluindo WebSocket, HTTP/2, gRPC e streaming de vários formatos de vídeo HDS, HLS entre outros.

Além da alta customização do nginx e suporte de novos componentes da web, o que se da a sua alta performace em relação ao apache é a sua arquitetura que dita a forma na qual o webserver atende suas requisições, por sua vez o apache é "process-based server" (arquitetura baseada em processos) em que cada solicitação de conexão é tratada por um único processo. A maneira como geralmente funciona é um processo pai do servidor recebe solicitações de conexão e, quando isso acontece, ele cria (gera) um processo filho para lidar com isso. Quando outra solicitação chega, o processo pai gera um novo processo filho para lidar com a nova solicitação e assim por diante.

Porém, isso tudo acaba gerando um custo de processamento absurdo, pois, quanto mais solicitações e conexões abertas, mais recursos computacionais serão gastos.

Já no NGINX temos um outro tipo de arquitetura, uma arquitetura assíncrona e “event‑driven architecture” (Arquitetura orientada a eventos).

Significa que threads iguais são comandadas por um process_worker, e cada process_worker contém unidades menores chamadas worker_connections. Esta unidade inteira é responsável de cuidar das solicitações. worker_connections levam as solicitações até um process_worker, que por sua vez as envia para o processo master. Finalmente o processo master fornece o resultado da solicitação.

de forma simples: existe um worker principal e diversos workers menores que recebem requisiçoes, porem cada worker é assincrono e capaz de receber mais de uma requisição, ou seja, enquanto ele está devolvendo um arquivo estático de CSS o mesmo worker já está atendendo uma nova requisição e por ai vai...

Um detalhe: Os workers geralmente são criados de acordo com a quantidade de núcleos da CPU. Porém pode ser "setado" no arquivo de configuração do nginx.

Caso tenha acabado de fazer a instalação do nginx vai estar assim:

 worker_processes: auto;

Desta forma ele está configurado para criar workers de acordo com a quantidade de núcleos da CPU.

Um único worker é capaz "cuidar" de até 1024 solicitações similares.

Proxy Reverso

Quande se fala de NGINX sempre é citado o famoso Proxy reverso, mas afinal, oque seria isso?

Confesso que quando me explicaram o que era fiquei uns 2 minutos com cara de paisagem tentando entender

Bom, para entendermos o proxy reverso primeiro precisamos elucidar o conceito de proxy. Proxy é um servidor que atua como intermediário entre o usuário e a internet, recebendo as requisições e repassando. Geralmente muito utilizado dentro de empresas para bloquear acesso de sites e outros conteúdos.

Tendo essa difinição podemos dizer que um proxy reverso é um servidor intermediário que fica ao lado do servidor e não mais ao lado do cliente recebendo as requisições e redirecionando para outros servidores/serviços corretos.

Um exemplo bem simples:

server {
    listen 80;
    server_name localhost;

    location / {
        root /users/juan/dev/nginx;
        index index.html
    }

    location ~ /.php$ {
        proxy_pass http://localhost:8000;
    }
}

server - é um bloco designado a escrever as configurações de um servidor dentro da sua configuração. Você pode ter vários deles, cada um atendendo em uma porta diferente. Você pode expor um servidor para o mundo e ter outro interno, sem cache, por exemplo, ou até driblando a autenticação, por exemplo.
listen - aqui você define em qual porta seu servidor vai aceitar as conexões.
location - é a diretiva usada para definir as rotas. Elas são bem poderosas. Aceitam expressões regulares, é possível capturar as variáveis e usá-las na configuração. O sistema de location, também, conta com diferentes tipos de match.
- Sem modificador, o match é feito pelo começo da URI.
- = é um match exato.
- ~ é um match com expressão regular.

Nesse caso o nginx foi configurado para redirecionar toda requisição que tenha PHP para um serviço especifico, que vai executar a lógica e processar as informações, caso seja uma requisição de algum arquivo estático como uma página em html, o servidor prontamente devolverá sem precisar enviar requisição ao servidor PHP. Assim dando mais dinâmica a todo o processo.

LoadBalancing

A maioria das vezes uma aplicação em produção tem mais de um servidor para servir ela, isso se dá pois os servidores possuem recursos finitos (CPU,Disco etc.) para atender multiplas requisições. E não é apenas sobre isso. E se o servidor sofrer uma falha de hardware? Ou até alguma falha de rede? Inúmeros motivos podem fazer sua aplicação ficar sem um fallback pra esses casos.

Nesses casos utilizamos o Upstream onde denominamos servidores para balancear a aplicação.

upstream servicos {
    server localhost:8001;
    server localhost:8002;
}

server {
    listen 8080;
    server_name localhost;

    location / {
        proxy_pass http://servicos;
    }

}

Como não estamos utilizando algoritimos de balanceamento como Round robin, IP hash etc. O nosso servidor apenas vai intercalar as requisiçõe entre os serviços, ou seja, 50% das requisções vai para o localhost:8001 e 50% para o localhost:8002.

Esse é um exemplo básico, mas pode ser explorado de várias maneiras assim mitigando riscos de ter sua aplicação fora do ar.

Considerações Finais

Objetivo desse Post é apenas dar uma pincelada sobre o webserver mais rápido do mercado e mostrar algumas caracteristicas que lhe deram esse título. No próximo Post teremos exemplos aplicados e mostrarei algumas outras funcionalidades como: Cache, Stream etc.