Différences
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédenteDernière révisionLes deux révisions suivantes | ||
web:websockets [2019/10/07 09:00] – [Définition] philippe | web:websockets [2021/08/11 12:23] – phil | ||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
+ | [[web: | ||
+ | |||
+ | ===== WEB - Websocket vs REST ====== | ||
+ | |||
+ | [Mise à jour le 23/2/2020] | ||
+ | |||
+ | * **Ressources** | ||
+ | * Référence - < | ||
+ | * JDN - < | ||
+ | * Tutoriel < | ||
+ | |||
+ | * **Lecture connexe** | ||
+ | * < | ||
+ | * < | ||
+ | < | ||
+ | |||
+ | ---- | ||
+ | |||
+ | ==== Définition ==== | ||
+ | WebSocket est un standard du Web désignant un protocole réseau de la **couche application** et une interface de programmation du World Wide Web visant à créer des canaux de communication **full-duplex** par-dessus une connexion TCP pour les navigateurs web. < | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | ==== Avantages du Websocket par rapport à l’API REST HTTP classique ==== | ||
+ | Le protocole WebSocket a été élaboré pour les applications qui nécessitent des réponses rapides ou interactives. Le HTTP a été élaboré au début du Web (par le CERN de Genève). Le protocole HTTP est employé pour faire fonctionner les sites Internet mais également les applications mobiles (par exemple). Les API REST sont également basées sur l’HTTP. L’**HTTP n’est pas adapté aux applications qui nécessitent des réponses rapides ou interactives**. En effet, à chaque fois que le client fait une requête au serveur, on doit ouvrir une connexion, attendre la réponse du serveur puis refermer la connexion ce qui est consommateur de ressources et prend du temps de traitement. | ||
+ | |||
+ | On ne tient pas compte ici de la technologie Ajax qui permet d’actualiser le contenu d’une page web de manière asynchrone. | ||
+ | |||
+ | Le protocole **WebSocket vise à résoudre ces problèmes**. Il ouvre un tunnel de communication entre deux appareils. Ce tunnel reste ouvert jusqu’à ce que le client se déconnecte. À n’importe quel moment le client peut envoyer des messages (JSON, binaire, texte…) et vis versa. | ||
+ | |||
+ | Pour établir une connexion WebSocket, une liaison HTTP spécifique est établie entre le client et le serveur. En cas de réussite, le protocole de la couche Application est « mis à niveau » de HTTP vers WebSockets, à l’aide de la connexion TCP établie. Une fois que cela s’est produit, le protocole HTTP disparaît du paysage. Les données peuvent être envoyées ou reçues aux deux points de terminaison via le protocole WebSocket, jusqu’à la fermeture de la connexion WebSocket. | ||
+ | {{ : | ||
+ | |||
+ | Pour résumer, le Websocket présente les avantages suivants : | ||
+ | |||
+ | * **Bidirectionnel** : le protocole HTTP est unidirectionnel, | ||
+ | * **Full-duplex** : serveur et client peuvent s’envoyer des messages à n’importe quel moment indépendamment des traitements en cours. | ||
+ | * **Connexion TCP unique** : Généralement, | ||
+ | * **Léger** : le Websocket se concentre sur l’essentiel contrairement à l’HTTP qui embarque de nombreuses informations à chaque question / réponse | ||
+ | En termes de performance, | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | La différence peut sembler insignifiante (30% plus rapide) pour un nombre très faible de messages. Pour piloter un bras robotique ou un éclairage à LED depuis une application mobile, la différence est vraiment significative ! | ||
+ | |||
+ | {{ : | ||