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

Patrick Nommensen

En este artículo hablaremos sobre el uso de NGINX y NGINX Plus con Node.js y Socket.IO. Nuestro artículo sobre la creación de aplicaciones web en tiempo real con WebSocket y NGINX ha tenido bastante éxito, así que en este artículo ampliaremos la documentación y las prácticas recomendadas para usar Socket.IO.

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

Socket.IO es una API de WebSocket que ha ganado mucha popularidad con el auge de las aplicaciones Node.js. Esta API es muy conocida porque facilita la creación de aplicaciones en tiempo real, como juegos en línea o chats. NGINX 1.3.13 y las versiones posteriores, así como todas las versiones de NGINX Plus, permiten usar un proxy para las conexiones WebSocket, lo que posibilita el uso de Socket.IO. El protocolo WebSocket permite una comunicación dúplex completa, o bidireccional, a través de una única conexión TCP.

Las aplicaciones que se ejecutan en producción suelen tener que utilizar el puerto 80 (HTTP), el puerto 443 (HTTPS) o ambos. Esto puede suponer un reto si varios componentes de la aplicación interactúan con el usuario o si se utiliza un servidor web en el puerto 80 para servir otros recursos. Por ello, es necesario utilizar un proxy para el servidor Socket.IO, y NGINX es la mejor forma de hacerlo. Tanto si dispone de una sola instancia de su aplicación backend como de cientos, NGINX también puede equilibrar la carga entre los servidores ascendentes cuando se utilizan varios nodos.

Configuración de Socket.IO

Para instalar Node.js, descarga la distribución adecuada (o instálalo con un gestor de paquetes). Ejecuta el comando npm install socket.io para instalar Socket.IO.

Para este ejemplo, suponemos que el servidor Socket.IO de tu aplicación en tiempo real se ejecuta en el puerto 5000. A continuación se muestra una plantilla para un archivo de aplicación de Node llamado «server.js»; se trata de un programa básico que actúa como servidor y dirige las solicitudes entrantes al puerto correspondiente en el que se ejecuta el 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('Chat message by ', name);
    });
  });
});

Añade código JavaScript como el siguiente al archivo que se envía al cliente, por ejemplo, index.html. Este ejemplo solicita una conexión con tu aplicación para crear un WebSocket con el navegador del usuario.

<script src="/socket.io/socket.io.js"></script>
<script>
     var socket = io(); // your initialization code here.
</script>

Configuración de NGINX

Declaración de upstream

NGINX y NGINX Plus pueden equilibrar la carga y distribuir las sesiones de usuario entre varios nodos si su aplicación tiene varias instancias. En el contexto http de la configuración de NGINX o NGINX Plus, incluya un bloque upstream para definir los nodos de un grupo de servidores upstream.

Como se muestra en el siguiente ejemplo, puede incluir el parámetro weight en una directiva server para establecer la proporción de tráfico que se dirige a ese servidor. En este caso, srv1.app.com recibe cinco veces más sesiones que los demás servidores. NGINX Plus amplía las capacidades de proxy inverso de NGINX con métodos avanzados de equilibrio de carga y añade persistencia de sesiones, comprobaciones de estado, informes de estado ampliados y reconfiguración sobre la marcha de grupos de servidores con equilibrio de carga.

# in the http{} configuration block
upstream socket_nodes {
    ip_hash;
    server srv1.app.com:5000 weight=5;
    server srv2.app.com:5000;
    server srv3.app.com:5000;
    server srv4.app.com:5000;
}

Configuración del host virtual

Ahora que se ha declarado el grupo de servidores upstream, es necesario configurar un servidor virtual para dirigir el tráfico hacia él. Como mínimo, incluya la directiva proxy_pass e indique el nombre del grupo upstream. Dado que el protocolo WebSocket utiliza la cabecera Upgrade introducida en HTTP/1.1, incluimos la directiva proxy_http_version.

server {
    server_name app.domain.com;
    location / {
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "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;
    }
}

¿Qué ocurre con los archivos estáticos?

Para entregar recursos estáticos, puedes hacer que NGINX redirija las solicitudes mediante proxy a una instancia de Node.js situada en un servidor ascendente, pero en la mayoría de los casos es más eficiente que NGINX los sirva directamente.

En combinación con la directiva server_name del bloque server anterior, el siguiente bloque location 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 la gestión de archivos estáticos o configurar los ajustes de caducidad de la caché según sus necesidades.

location /assets {
    alias /path/to/assets;
    access_log off;
    expires max;
}

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.

WebSocket connection to '...' failed: Error during WebSocket handshake: 'Connection' header value is not 'Upgrade': keep-alive socket.io.js:2371

Lecturas adicionales

• NGINX como proxy de WebSocket
• Comparación de funcionalidades de NGINX y NGINX Plus
• Especificaciones técnicas de NGINX Plus

Para probar NGINX Plus, inicie hoy mismo su prueba gratuita de 30 días o póngase en contacto con nosotros para hablar sobre sus casos de uso.

Sobre el autor

Patrick Nommensen

Más artículos de Patrick Nommensen