Applications web en temps réel avec WebSocket et NGINX

Rick NelsonVice-président régional, ingénierie des solutions

Dans l’article de blog « NGINX comme proxy WebSocket », nous avons expliqué comment utiliser NGINX comme proxy pour les serveurs d’applications WebSocket. Dans cet article, nous aborderons certains aspects liés à l’architecture et à l’infrastructure à prendre en compte lors de la création d’applications en temps réel avec WebSocket, notamment les composants nécessaires et la manière dont vous pouvez structurer vos systèmes.

WebSocket ajoute de l’interactivité à HTTP

HTTP convient bien aux applications web reposant sur un modèle requête-réponse, dans lequel le client initie toujours la requête à laquelle répond un serveur backend. Les applications web nécessitant une interaction plus interactive entre le client et le serveur, fondée sur l’échange de messages, ont besoin de davantage que le simple protocole HTTP. Les précédentes tentatives visant à simuler une communication bidirectionnelle simultanée sur HTTP étaient complexes et présentaient de nombreux inconvénients. Le protocole WebSocket, associé à l’interface JavaScript WebSocket, permet de créer ce type d’applications beaucoup plus facilement, tout en réduisant le volume de données transférées et la latence.

La possibilité de créer une connexion socket en duplex intégral entre le client et le serveur permet de développer des applications web événementielles en temps réel qui utilisent des communications par envoi automatique, interrogation ou diffusion en continu. Avec WebSocket, le client comme le serveur peut initier une communication une fois la connexion établie. Cela permet de créer de nombreux types d’applications web, notamment des jeux en ligne, des services de discussion instantanée, des outils de suivi des cours boursiers et des systèmes d’affichage en temps réel des résultats sportifs.

Un autre cas d’utilisation de WebSocket est le développement d’applications basées sur WebRTC. WebRTC permet de créer des applications assurant des communications de navigateur à navigateur. Il nécessite un canal de signalisation distinct pour établir les communications, et WebSocket est un protocole bien adapté à cet usage.

Exigences techniques pour une application WebSocket

L’infrastructure minimale requise pour une application web WebSocket se compose d’un navigateur client exécutant une application JavaScript WebSocket et communiquant avec un serveur WebSocket. Les versions récentes de tous les principaux navigateurs prennent désormais en charge WebSocket, mais il est important de s’assurer que les clients disposent d’un navigateur compatible avec WebSocket. Il existe de nombreuses solutions de serveurs WebSocket. En voici quelques exemples pour différents environnements (cette liste est fournie à titre indicatif et ne constitue pas une recommandation de la part de NGINX, Inc.) :

Mise à l’échelle de WebSocket pour gérer de gros volumes de trafic

Il est possible d’utiliser un seul serveur WebSocket, mais les performances de l’application sont limitées par la capacité de ce serveur, qui constitue également un point de défaillance unique. De nombreuses applications en temps réel sont développées dans l’espoir d’être largement adoptées, mais il peut être difficile de prévoir leur rythme de croissance. Pour accompagner la popularité croissante d’une application en temps réel, l’infrastructure doit être capable de :

• Évoluer pour prendre en charge un grand nombre d’utilisateurs simultanés
• Garantir une faible latence lors de la gestion des communications entre le client et le serveur
• Assurer une haute disponibilité (ce qui implique l’absence de point de défaillance unique)
• Permettre de modifier facilement la configuration et de l’adapter à l’évolution des conditions

Pour ce faire, placez NGINX devant les serveurs WebSocket et les serveurs HTTP (puisque la plupart des applications WebSocket utilisent également HTTP), afin qu’il fasse office de proxy inverse compatible avec WebSocket et de répartiteur de charge. Tous les proxys inverses ne prennent pas directement en charge WebSocket. Certains, comme Elastic Load Balancing (ELB) dans l’environnement Amazon Web Services (AWS), doivent fonctionner en mode TCP, ce qui signifie qu’ils ne peuvent pas traiter les en-têtes HTTP. Le protocole PROXY a été développé pour pallier cette limitation et est également pris en charge par NGINX, ce qui permet une prise en charge complète de WebSocket dans AWS. L’utilisation de NGINX comme proxy inverse WebSocket offre d’autres avantages, notamment une plus grande souplesse de routage et la possibilité de confier à NGINX la terminaison des connexions SSL.

Une configuration WebSocket classique utilisant NGINX pourrait ressembler à ceci :

Nous présentons ici différents clients pour ordinateurs et appareils mobiles qui se connectent à une paire de serveurs NGINX à haute disponibilité, lesquels répartissent la charge entre plusieurs serveurs HTTP et WebSocket. Ce type de configuration peut résister à la défaillance d’un serveur WebSocket ou d’un serveur NGINX, et vous permet d’ajouter ou de supprimer facilement des serveurs WebSocket. De plus, tous les détails de routage nécessaires à la connexion aux serveurs WebSocket sont masqués aux clients, ce qui permet de créer une infrastructure d’applications WebSocket robuste et évolutive. Les performances et la fiabilité du Web sont essentielles pour les applications Web en temps réel. Contactez-nous dès aujourd’hui pour découvrir comment NGINX Plus peut contribuer à améliorer les performances, la fiabilité et la disponibilité de vos applications.

Pour plus d’informations, consultez :

• NGINX en tant que proxy WebSocket
• Performances de NGINX avec WebSocket
• Proxy WebSocket sur nginx.org
• Comparaison des fonctionnalités de NGINX et NGINX Plus
• Spécifications techniques de NGINX Plus

À propos de l’auteur

Rick NelsonVice-président régional, ingénierie des solutions

Autres articles de Rick Nelson