BLOG | NGINX

Usando NGINX e NGINX Plus com Node.js e Socket.IO, a API WebSocket

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Patrick Nommensen Miniatura
Patrick Nomensen
Publicado em 19 de novembro de 2014

Neste post falaremos sobre o uso do NGINX e do NGINX Plus com Node.js e Socket.IO. Nossa postagem sobre a criação de aplicativos web em tempo real com WebSocket e NGINX tem sido bastante popular, então, nesta postagem, continuaremos com a documentação e as melhores práticas usando Socket.IO.

Por que usar NGINX com Node.js e Socket.IO?

Socket.IO é uma API WebSocket que se tornou bastante popular com o surgimento de aplicativos Node.js. A API é bem conhecida porque simplifica a criação de aplicativos em tempo real, como jogos online ou bate-papo. O NGINX 1.3.13 e versões posteriores e todas as versões do NGINX Plus oferecem suporte ao proxy de conexões WebSocket, o que permite que você utilize o Socket.IO. O protocolo WebSocket permite comunicação full-duplex, ou bidirecional, por meio de uma única conexão TCP.

Os aplicativos em execução em produção geralmente precisam ser executados na porta 80 (HTTP), na porta 443 (HTTPS) ou em ambas. Isso pode ser um desafio se vários componentes do seu aplicativo interagirem com o usuário ou se você estiver usando um servidor web na porta 80 para entregar outros ativos. Isso torna necessário fazer proxy para o servidor Socket.IO, e o NGINX é a melhor maneira de fazer isso. Não importa se você tem uma instância do seu aplicativo de backend ou centenas, o NGINX também pode balancear a carga dos seus upstreams ao usar vários nós.

Configuração Socket.IO

Para instalar o Node.js, baixe a distribuição apropriada (ou instale com um gerenciador de pacotes ). Execute o comando npm install socket.io para instalar o Socket.IO.

Para este exemplo, assumimos que o servidor Socket.IO para seu aplicativo em tempo real está sendo executado na porta 5000. A seguir está um modelo para um arquivo de aplicativo de nó server.js ; é um programa básico que atua como um servidor e roteia solicitações de entrada para a porta apropriada que executa o servidor Socket.IO.

var io = require('socket.io').listen(5000); 
io.sockets.on('connection', function (socket) {
socket.on('set nickname', function (name) {
socket.set('nickname', name, function () {
socket.emit('ready');
});
});

socket.on('msg', function () {
socket.get('nickname', function (err, name) {
console.log('Mensagem de bate-papo por ', name);
});
});
});

Adicione um código JavaScript como o seguinte ao arquivo que é entregue ao seu cliente, por exemplo index.html . Este exemplo solicita uma conexão com seu aplicativo para criar um WebSocket com o navegador do seu usuário.

<script src="/socket.io/socket.io.js"></script>
<script>
var socket = io(); // seu código de inicialização aqui.
</script>

Configuração NGINX

Declaração Upstream

O NGINX e o NGINX Plus podem balancear a carga e distribuir sessões de usuários para vários nós se seu aplicativo tiver várias instâncias. No contexto http na sua configuração do NGINX ou NGINX Plus, inclua um bloco upstream para definir os nós em um grupo upstream.

Conforme mostrado no exemplo a seguir, você pode incluir o parâmetro weight em uma diretiva de servidor para definir a proporção de tráfego direcionado a ele. Aqui srv1.app.com recebe cinco vezes mais sessões que os outros servidores. O NGINX Plus estende os recursos de proxy reverso do NGINX com métodos aprimorados de balanceamento de carga e adicionando persistência de sessão, verificações de integridade, relatórios de status estendidos e reconfiguração dinâmica de grupos de servidores com balanceamento de carga.

# no bloco de configuração http{}
upstream socket_nodes {
ip_hash;
servidor srv1.app.com:5000 peso=5;
servidor srv2.app.com:5000;
servidor srv3.app.com:5000;
servidor srv4.app.com:5000;
}

Configuração do host virtual

Agora que o grupo upstream de servidores foi declarado, um servidor virtual precisa ser configurado para direcionar o tráfego para ele. No mínimo, inclua a diretiva proxy_pass e nomeie o grupo upstream. Como o protocolo WebSocket usa o cabeçalho Upgrade introduzido no HTTP/1.1, incluímos a diretiva proxy_http_version .

servidor {
nome_do_servidor app.domain.com;
localização / {
proxy_set_header Atualização $http_upgrade;
proxy_set_header Conexão "upgrade";
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;
proxy_pass http://socket_nodes;
}
}

E os arquivos estáticos?

Para entregar ativos estáticos, você pode ter solicitações de proxy NGINX para uma instância upstream do Node.js, mas na maioria dos casos é mais eficiente ter o NGINX atendendo-as diretamente.

Em combinação com a diretiva server_name no bloco server acima, o seguinte bloco location informa ao NGINX para responder às solicitações do cliente para conteúdo em http://app.domain.com/assets/ , servindo-o do diretório local /path/to/assets . Você pode otimizar ainda mais o tratamento de arquivos estáticos ou definir configurações de expiração de cache que atendam às suas necessidades.

localização /ativos {
alias /caminho/para/ativos;
access_log off;
expira max;
}

solucao-problemas

Se você receber o seguinte erro, provavelmente está executando uma versão do NGINX anterior à 1.3. O uso do WebSocket é suportado no NGINX 1.3.13 e posteriores.

A conexão do WebSocket com '...' falhou: Erro durante o handshake do WebSocket: O valor do cabeçalho 'Connection' não é 'Upgrade': keep-alive socket.io.js:2371

Leitura adicional

Para experimentar o NGINX Plus, comece hoje mesmo seu teste gratuito de 30 dias ou entre em contato conosco para discutir seus casos de uso.


"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."