WebSocket est une technologie intégrée dans de nombreuses applications Web modernes. Si vous écrivez du code pour le Web, vous avez probablement déjà entendu ce terme, mais vous ne savez peut-être pas exactement de quoi il s'agit ni comment l'utiliser. Heureusement, WebSocket n'est pas un concept complexe et vous pouvez en acquérir une compréhension de base assez rapidement.
Qu'est-ce que WebSocket ?
WebSocket, malheureusement, est l'un de ces noms qui ne semble pas avoir de sens à première vue. WebSocket est en fait le nom d'un protocole de communication qui permet une communication bidirectionnelle entre le client et le serveur Web.
En termes plus simples, WebSocket est une technologie qui permet à un client et à un serveur de créer une connexion où l'une des parties peut envoyer un message à l'autre à tout moment.
Ceci est différent d'une connexion HTTP normale, où le client doit lancer une requête, et alors seulement le serveur peut envoyer une réponse. En fait, WebSocket est un protocole de communication complètement différent de HTTP qui a été conçu pour être compatible HTTP. Lorsqu'une application cliente souhaite initier une connexion WebSocket, elle doit utiliser le
Mécanisme de mise à niveau HTTP pour passer au protocole WebSocket.À ce stade, vous pensez peut-être: "un protocole n'est qu'un ensemble de règles, comment pouvez-vous l'utiliser pour coder ?".
La pièce manquante est ce qu'on appelle un pile de protocoles. Essentiellement, les appareils qui prennent en charge un protocole intègrent du matériel et des logiciels qui vous permettent d'écrire des applications qui communiquent à l'aide du protocole. Le protocole n'est pas directement utilisé pour construire quoi que ce soit.
Pourquoi WebSocket a-t-il été créé ?
Pour illustrer le besoin de WebSocket, considérons le mécanisme derrière le chat sur Internet.
Quelqu'un envoie un message au serveur de chat depuis son appareil, mais le serveur doit encore envoyer ce message à votre appareil avant que vous puissiez le lire. Si le serveur utilise HTTP, le serveur ne peut pas vous transmettre directement ce message, car le serveur ne peut pas initier de requêtes.
Il existe plusieurs façons de résoudre ce problème avec HTTP. Une façon consiste pour le client à envoyer constamment des demandes de mise à jour au serveur, et le serveur transmettra toutes les données qu'il a dans la réponse. Cette technique est appelée polling, et chaque requête est appelée poll. Il existe deux variantes d'interrogation: l'interrogation longue et l'interrogation courte.
L'utilisation de la variante d'interrogation longue signifie que le périphérique client demande constamment au serveur si de nouveaux messages sont disponibles. Si de nouveaux messages sont disponibles, le serveur enverra les messages en réponse. Sinon, le serveur retarderait la réponse et maintiendrait la connexion ouverte jusqu'à ce qu'il ait des données à renvoyer, puis le client ferait immédiatement une nouvelle demande.
Cette technique est inefficace, car HTTP n'a pas été conçu pour être utilisé de cette façon. Il fonctionne correctement à petite échelle, mais chaque requête HTTP implique l'envoi de données supplémentaires dans le en-tête, et il en résulte une charge considérablement accrue sur le serveur lorsque de nombreux clients interrogent ce.
Voici un schéma illustrant une interrogation longue :
La variante d'interrogation courte est encore moins efficace. Dans une interrogation courte, le serveur ne maintient pas la connexion ouverte jusqu'à ce qu'il y ait de nouvelles données, ce qui signifie que le client doit continuer à interroger le serveur à des intervalles fixes et très courts.
Une autre technique de communication bidirectionnelle dans HTTP est appelée streaming.
En streaming, après l'envoi de la première requête, le serveur maintient la connexion ouverte indéfiniment, en envoyant de nouvelles informations sous forme de réponses partielles continues au client.
L'utilisation de la diffusion en continu entraîne une surcharge de données et une charge de serveur inférieures à celles de l'interrogation, car idéalement, le client ne fait qu'une seule requête HTTP. Malheureusement, le streaming crée des problèmes dans certaines conditions car les navigateurs et les intermédiaires du réseau (comme les proxys) essaient souvent de gérer le les réponses partielles en tant que morceaux d'une grande réponse HTTP (ce qui est un comportement HTTP normal), au lieu des messages séparés auxquels elles étaient destinées être.
WebSocket a été créé pour résoudre ces problèmes. Contrairement à HTTP, WebSocket a été conçu spécifiquement pour la communication bidirectionnelle. Avec WebSocket, une fois qu'une connexion est ouverte, le client et le serveur peuvent envoyer des messages dans les deux sens sans les problèmes d'interrogation ou de diffusion.
Cas d'utilisation pour WebSocket
WebSocket est génial, mais cela ne signifie pas qu'il doit être utilisé partout.
L'implémentation de WebSocket peut ajouter de la complexité à votre application, en particulier du côté serveur, donc cela ne devrait pas être fait à moins que vous n'ayez une bonne raison. Cela soulève la question: à quoi ressemble une bonne raison ?
WebSocket est idéal pour les cas d'utilisation où une communication bidirectionnelle fréquente à faible latence est requise. En d'autres termes, WebSocket offre un avantage pour les applications qui doivent communiquer fréquemment ou à grande échelle. Si la communication n'a pas besoin d'être en temps réel ou si l'application ne se développera jamais à grande échelle, l'interrogation ou la diffusion en continu peuvent être suffisantes pour une utilisation dans cette application.
Les utilisations typiques de WebSocket sont dans la création d'applications de chat, de jeux multijoueurs en ligne, de logiciels de collaboration et de notification en temps réel, etc.
Comment utiliser WebSocket côté client
L'utilisation de WebSocket côté serveur peut être assez complexe, et le processus varie considérablement en fonction de la langue (comme C#, Java, etc.) et bibliothèque de choix, nous ne le couvrirons donc pas ici. Ensuite, nous verrons brièvement comment utiliser WebSocket côté client.
Tous les navigateurs modernes implémentent une API Web appelée API WebSocket, qui est la pile de protocoles du navigateur pour le protocole WebSocket. Vous pouvez utiliser WebSocket en JavaScript à l'aide de cette API. L'API vous permet de créer un objet WebSocket, à travers lequel vous créez une connexion WebSocket et interagissez avec le serveur WebSocket.
Vous pouvez utiliser le format de code suivant pour créer un objet WebSocket :
let exampleSocket = new WebSocket("wss://www.example.com/socketserver", "protocole factice");Le premier argument du constructeur est l'URI du serveur WebSocket avec lequel vous souhaitez créer une connexion. Il commencera toujours par "ws" ou "wss". Le deuxième argument est facultatif. Sa valeur est soit une chaîne, soit un tableau de chaînes, qui spécifie les sous-protocoles que vous prenez en charge.
L'objet WebSocket a une propriété en lecture seule appelée readyState. L'accès à cette propriété fournit l'état actuel de la connexion WebSocket. readyState a quatre valeurs possibles: "connecting", "open", "closing" et "closed".
Lorsque cette ligne de code s'exécute, le navigateur essaie de se connecter au serveur spécifié. La connexion ne sera pas terminée immédiatement, donc le readyState de exampleSocket sera "connecting". Aucun message ne peut être envoyé ou reçu tant que la connexion n'est pas terminée, moment auquel la valeur de readyState deviendra "open".
La exempleSocket objet a un écouteur d'événement (qui est différent de Écouteurs d'événements DOM) appelé "onopen" qui vous permet d'effectuer d'autres actions uniquement après l'établissement de la connexion. L'objet a également une méthode "send" qui vous permet d'envoyer des chaînes, des blobs (données binaires) et des ArrayBuffers sous forme de messages au serveur.
Voici un exemple qui les utilise ensemble :
exempleSocket.onopen = fonction (un événement) {
exempleSocket.send("WebSocket est vraiment cool");
};L'API vous permet également de réagir aux messages envoyés par le serveur. Cela se fait avec l'écouteur d'événement "onmessage". Voici un exemple :
exempleSocket.onmessage = fonction (un événement) {
console.Journal(un événement.Les données);
}Au lieu de cela, vous pouvez également écrire une fonction flèche:
exampleSocket.onmessage = (événement) => { console.log (événement.données); }L'API fournit également un proche() méthode pour fermer la connexion. Voici à quoi ça ressemble :
exempleSocket.proche();WebSocket permet une communication bidirectionnelle efficace
WebSocket est un protocole de communication bidirectionnel. Les serveurs et les navigateurs implémentent des piles de protocoles pour communiquer à l'aide de WebSocket. WebSocket existe car HTTP n'a pas été conçu pour être bidirectionnel. Il existe des méthodes pour implémenter des connexions bidirectionnelles avec HTTP, mais elles ont des problèmes.
WebSocket est une technologie puissante, mais n'est pas nécessaire dans tous les cas, car elle peut considérablement compliquer l'architecture des applications. L'utilisation de WebSocket côté client se fait avec l'API WebSocket du navigateur.
