Usando NGINX y NGINX Plus con Node.js y Socket.IO, la API WebSocket

En esta publicación hablaremos sobre el uso de NGINX y NGINX Plus con Node.js y Socket.IO. Nuestra publicación sobre la creación de aplicações web en tiempo real con WebSocket y NGINX ha sido bastante popular, por lo que en esta publicación continuaremos con la documentación y las mejores prácticas utilizando Socket.IO.

¿Por qué utilizar NGINX con Node.js y Socket.IO?

Socket.IO es una API de WebSocket que se ha vuelto bastante popular con el auge de las aplicações Node.js. La API es bien conocida porque facilita la creación de aplicaciones en tiempo real, como juegos en línea o chat. NGINX 1.3.13 y posteriores y todas las versiones de NGINX Plus admiten el proxy de conexiones WebSocket, lo que le permite utilizar Socket.IO. El protocolo WebSocket permite la comunicación full-duplex o bidireccional a través de una única conexión TCP.

Las aplicações que se ejecutan en producción generalmente necesitan ejecutarse en el puerto 80 (HTTP), el puerto 443 (HTTPS) o ambos. Esto puede ser un desafío si varios componentes de su aplicação interactúan con el usuario o si está utilizando un servidor web en el puerto 80 para entregar otros activos. Esto hace que sea necesario utilizar un proxy hacia el servidor Socket.IO, y NGINX es la mejor manera de hacerlo. Ya sea que tenga una instancia de su aplicação backend o cientos, NGINX también puede equilibrar la carga de sus aplicaciones ascendentes cuando utiliza múltiples nodos.

Configuración de Socket.IO

Para instalar Node.js, descargue la distribución adecuada (o instálela con un administrador de paquetes ). Ejecute el comando npm install socket.io para instalar Socket.IO.

Para este ejemplo, suponemos que el servidor Socket.IO de su aplicación en tiempo real se ejecuta en el puerto 5000. La siguiente es una plantilla para un archivo de aplicação de nodo server.js ; es un programa básico que actúa como un servidor y enruta las solicitudes entrantes al puerto adecuado que ejecuta el servidor Socket.IO.

var io = require('socket.io').listen(5000); 
io.sockets.on('conexión', función (socket) {
socket.on('establecer apodo', función (nombre) {
socket.set('apodo', nombre, función () {
socket.emit('listo');
});
});

socket.on('msg', función () {
socket.get('apodo', función (err, nombre) {
console.log('Mensaje de chat de ', nombre);
});
});
});

Agregue código JavaScript como el siguiente al archivo que se entrega a su cliente, por ejemplo index.html . Este ejemplo solicita una conexión a su aplicação para crear un WebSocket con el navegador de su usuario.

<script src="/socket.io/socket.io.js"></script>
<script>
var socket = io(); // Tu código de inicialización aquí.
</script>

Configuración de NGINX

Declaración Upstream

NGINX y NGINX Plus pueden equilibrar la carga y distribuir sesiones de usuario a múltiples nodos si su aplicação tiene varias instancias. En el contexto http de su configuración NGINX o NGINX Plus, incluya un bloque ascendente para definir los nodos en un grupo ascendente.

Como se muestra en el siguiente ejemplo, puede incluir el parámetro de peso en una directiva de servidor para establecer la proporción de tráfico dirigido a él. Aquí srv1.app.com recibe cinco veces más sesiones que los otros servidores. NGINX Plus amplía las capacidades de proxy inverso de NGINX con métodos de equilibrio de carga mejorados y agregando persistencia de sesión, controles de estado, informes de estado extendidos y reconfiguración sobre la marcha de grupos de servidores con equilibrio de carga.

# en el bloque de configuración 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;
}

Configuración de host virtual

Ahora que se ha declarado el grupo de servidores ascendente, es necesario configurar un servidor virtual para dirigir el tráfico hacia él. Como mínimo, incluya la directiva proxy_pass y nombre el grupo ascendente. Debido a que el protocolo WebSocket utiliza el encabezado Upgrade introducido en HTTP/1.1, incluimos la directiva proxy_http_version .

servidor {
nombre_servidor app.domain.com;
ubicación / {
encabezado_conjunto_proxy Actualización $http_upgrade;
encabezado_conjunto_proxy Conexión "actualización";
versión_http_proxy 1.1;
encabezado_conjunto_proxy Reenviado-para $proxy_add_x_forwarded_for;
encabezado_conjunto_proxy Host $host;
contraseña_proxy http://nodos_socket;
}
}

¿Qué pasa con los archivos estáticos?

Para entregar activos estáticos, puede hacer que NGINX envíe solicitudes de proxy a una instancia Node.js ascendente, pero en la mayoría de los casos es más eficiente que NGINX las atienda directamente.

En combinación con la directiva server_name en el bloque de servidor anterior, el siguiente bloque de ubicación le indica a NGINX que responda a las solicitudes de los clientes de contenido en http://app.domain.com/assets/ sirviéndolo desde el directorio local /path/to/assets . Puede optimizar aún más el manejo de archivos estáticos o establecer configuraciones de expiración de caché que satisfagan sus necesidades.

ubicación/activos {
alias /ruta/a/activos;
registro de acceso desactivado;
caduca máximo;
}

Solución de problemas

Si recibe el siguiente error, probablemente esté ejecutando una versión de NGINX anterior a la 1.3. El uso de WebSocket es compatible con NGINX 1.3.13 y versiones posteriores.

La conexión WebSocket a '...' falló: Error durante el protocolo de enlace de WebSocket: El valor del encabezado 'Conexión' no es 'Actualizar': keep-alive socket.io.js:2371

Más información

• NGINX como proxy WebSocket
• Comparación de características de NGINX y NGINX Plus
• Especificaciones técnicas de NGINX Plus

Para probar NGINX Plus, comience hoy su prueba gratuita de 30 días o contáctenos para analizar sus casos de uso.