Utilisation de NGINX et NGINX Plus avec Node.js et Socket.IO, l'API WebSocket

Dans cet article, nous parlerons de l'utilisation de NGINX et NGINX Plus avec Node.js et Socket.IO. Notre article sur la création d'applications Web en temps réel avec WebSocket et NGINX a été très populaire, donc dans cet article, nous continuerons avec la documentation et les meilleures pratiques utilisant Socket.IO.

Pourquoi utiliser NGINX avec Node.js et Socket.IO ?

Socket.IO est une API WebSocket qui est devenue très populaire avec l’essor des applications Node.js. L'API est bien connue car elle simplifie la création d'applications en temps réel, comme les jeux en ligne ou le chat. NGINX 1.3.13 et les versions ultérieures ainsi que toutes les versions NGINX Plus prennent en charge le proxy des connexions WebSocket, ce qui vous permet d'utiliser Socket.IO. Le protocole WebSocket permet une communication en duplex intégral, ou bidirectionnelle, via une seule connexion TCP.

Les applications exécutées en production doivent généralement s'exécuter sur le port 80 (HTTP), le port 443 (HTTPS) ou les deux. Cela peut constituer un défi si plusieurs composants de votre application interagissent avec l’utilisateur ou si vous utilisez un serveur Web sur le port 80 pour fournir d’autres ressources. Cela nécessite un proxy vers le serveur Socket.IO, et NGINX est le meilleur moyen d'y parvenir. Que vous ayez une seule instance de votre application backend ou des centaines, NGINX peut également équilibrer la charge de vos flux en amont lorsque vous utilisez plusieurs nœuds.

Configuration de Socket.IO

Pour installer Node.js, téléchargez la distribution appropriée (ou installez-la avec un gestionnaire de packages ). Exécutez la commande npm install socket.io pour installer Socket.IO.

Pour cet exemple, nous supposons que le serveur Socket.IO de votre application en temps réel s’exécute sur le port 5000. Ce qui suit est un modèle pour un fichier d'application de nœud server.js ; c'est un programme de base qui agit comme un serveur et achemine les requêtes entrantes vers le port approprié exécutant le serveur 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('Message de discussion par ', name);
});
});
});

Ajoutez du code JavaScript comme celui-ci au fichier qui est livré à votre client, par exemple index.html . Cet exemple demande une connexion à votre application pour créer un WebSocket avec le navigateur de votre utilisateur.

<script src="/socket.io/socket.io.js"></script>
<script>
var socket = io(); // votre code d'initialisation ici.
</script>

Configuration NGINX

Déclaration en amont

NGINX et NGINX Plus peuvent équilibrer la charge et distribuer les sessions utilisateur sur plusieurs nœuds si votre application comporte plusieurs instances. Dans le contexte http de votre configuration NGINX ou NGINX Plus, incluez un bloc en amont pour définir les nœuds dans un groupe en amont.

Comme indiqué dans l’exemple suivant, vous pouvez inclure le paramètre de poids dans une directive de serveur pour définir la proportion de trafic qui lui est dirigée. Ici, srv1.app.com reçoit cinq fois plus de sessions que les autres serveurs. NGINX Plus étend les capacités de proxy inverse de NGINX avec des méthodes d’équilibrage de charge améliorées et en ajoutant la persistance de session, des contrôles de santé, des rapports d’état étendus et une reconfiguration à la volée des groupes de serveurs à charge équilibrée.

# dans le bloc de configuration http{}
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;
}

Configuration de l'hôte virtuel

Maintenant que le groupe de serveurs en amont est déclaré, un serveur virtuel doit être configuré pour diriger le trafic vers celui-ci. Au minimum, incluez la directive proxy_pass et nommez le groupe en amont. Étant donné que le protocole WebSocket utilise l'en-tête Upgrade introduit dans HTTP/1.1, nous incluons la directive proxy_http_version .

serveur {
nom_serveur app.domaine.com;
emplacement / {
proxy_set_header Mise à niveau $http_upgrade;
proxy_set_header Connexion "upgrade";
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Hôte $host;
proxy_pass http://socket_nodes;
}
}

Qu'en est-il des fichiers statiques ?

Pour fournir des ressources statiques, vous pouvez envoyer des requêtes proxy NGINX à une instance Node.js en amont, mais dans la plupart des cas, il est plus efficace que NGINX les serve directement.

En combinaison avec la directive server_name dans le bloc serveur ci-dessus, le bloc d'emplacement suivant indique à NGINX de répondre aux demandes client pour le contenu dans http://app.domain.com/assets/ en le diffusant à partir du répertoire local /path/to/assets . Vous pouvez optimiser davantage la gestion des fichiers statiques ou définir des paramètres d’expiration du cache qui répondent à vos besoins.

emplacement /assets {
alias /chemin/vers/assets ;
access_log désactivé ;
expire max ;
}

Dépannage

Si vous recevez l’erreur suivante, vous exécutez probablement une version de NGINX antérieure à 1.3. L'utilisation de WebSocket est prise en charge dans NGINX 1.3.13 et versions ultérieures.

La connexion WebSocket à « … » a échoué : Erreur lors de l'établissement de la liaison WebSocket : La valeur de l'en-tête « Connexion » n'est pas « Mise à niveau » : keep-alive socket.io.js:2371

Lectures complémentaires

• NGINX comme proxy WebSocket
• Comparaison des fonctionnalités de NGINX et NGINX Plus
• Spécifications techniques de NGINX Plus

Pour essayer NGINX Plus, démarrez votre essai gratuit de 30 jours dès aujourd'hui ou contactez-nous pour discuter de vos cas d'utilisation.