La fondation de tout le monde numérique est la communication entre les machines. Les clients autorisés créent une demande que le serveur reçoit, interprète et à laquelle il fournit une réponse appropriée. C'est la compréhension commune de la communication numérique pour les gens ordinaires. Cependant, le travail en arrière-plan est complexe et fastidieux.
Les développeurs d'applications doivent faire beaucoup de travail pour s'assurer que cette communication client-serveur fonctionne correctement. Choisir le bon protocole de communication est l'une de ces tâches. Lorsque les développeurs tentent de sélectionner un protocole de communication viable, HTTP et WebSocket sont deux concepts courants qu'ils rencontreront.
Clarifier ces deux protocoles, leurs similitudes, fonctions et autres aspects est crucial pour s'assurer que l'option correcte est choisie en fonction des besoins réels.
Présentation de HTTP#
Commençons par comprendre HTTP. C'est probablement le protocole le plus couramment utilisé dans le domaine de la communication numérique. La version initiale de HTTP a été publiée en 1989, avec des fonctionnalités et une portée d'application limitées. Mais il a été rapidement amélioré et mis à niveau pour prendre en charge une communication à grande échelle entre les navigateurs et les serveurs.
HTTP est un protocole unidirectionnel, ce qui signifie qu'à tout moment donné, une seule partie de la communication peut envoyer ou recevoir des informations. Lorsqu'un client envoie une requête à un serveur, cette requête est envoyée sous forme de HTTP ou HTTPS, et le serveur envoie une réponse unique correspondante au client après avoir reçu la requête. Chaque requête HTTP ou HTTPS établit une nouvelle connexion avec le serveur et termine automatiquement la connexion après avoir reçu la réponse.
Certaines des principales caractéristiques de HTTP incluent :
- Sans état
- Peut fonctionner sur la base de protocoles orientés connexion (comme SCTP et TCP)
- Les informations sont encodées en ASCII
- Les principaux composants d'une requête HTTP incluent la version HTTP (HTTP/1.1, HTTP/2, HTTP/3), la méthode, l'en-tête HTTP, les informations sur l'hôte et le message
Qu'est-ce que WebSocket ?#
WebSocket est un protocole de communication qui permet une communication bidirectionnelle en temps réel entre le client et le serveur.
WebSocket est un protocole pour créer des canaux de communication bidirectionnels en temps réel dans les applications web. Contrairement aux requêtes HTTP traditionnelles (un seul échange typiquement par requête), WebSocket peut établir des connexions persistantes, permettant au serveur de pousser des données vers le client en temps réel tout en recevant également des données du client. Par rapport aux sondages traditionnels, WebSocket réduit considérablement le trafic réseau et la latence, améliorant l'efficacité et la vitesse de la transmission des données. Il est particulièrement adapté au développement d'applications web en temps réel et de jeux en ligne.
Certaines des principales caractéristiques de WebSocket incluent :
- Basé sur des connexions TCP persistantes, qui restent ouvertes jusqu'à ce que le client ou le serveur initie une demande de terminaison
- Construit sur le protocole HTTP, toutes les requêtes WebSocket sont envoyées via le protocole HTTP standard, puis identifiées comme des informations d'en-tête spécifiques Upgrade côté serveur
- Le protocole WebSocket est basé sur des trames (paquets de données), un paquet de données complet peut être divisé en plusieurs trames, chaque trame contenant une partie des données et des informations d'en-tête
La relation entre HTTP et WebSocket#
D'après l'introduction ci-dessus, nous pouvons voir que les protocoles HTTP et WebSocket :
- Utilisent le protocole TCP pour la transmission des données
- Sont utilisés pour la communication entre le client et le serveur
Nous pouvons montrer de manière plus intuitive les différences entre HTTP et WebSocket à travers le tableau suivant.
| HTTP | WebSocket |
|---|
| Établit une nouvelle connexion pour chaque requête (à moins d'utiliser des connexions longues HTTP, comme HTTP/1.1 Keep-Alive), et ferme la connexion après la fin de la communication | La connexion reste ouverte après la poignée de main initiale réussie à moins d'être activement fermée ou qu'une erreur ne survienne |
| Mode de communication unidirectionnelle, le client envoie une requête, le serveur retourne une réponse, chaque nouvelle communication nécessite de rétablir la connexion | Mode de communication bidirectionnelle, après avoir établi la connexion, le client et le serveur peuvent envoyer des données à tout moment sans rétablir la connexion |
| Chaque communication nécessite d'envoyer des en-têtes de requêtes et de réponses complets, donc la surcharge est grande pour les communications fréquentes de messages courts | Une fois la connexion établie, la transmission des données est plus légère, pas besoin de transmettre les informations d'en-tête à chaque fois, adaptée aux besoins de communication à haute fréquence et à faible latence |
| Principalement utilisé pour transmettre des données relativement stables | Principalement utilisé pour transmettre des données en temps réel |
| En raison de la nécessité de rétablir les connexions pour chaque requête et de transporter les informations nécessaires par le biais des en-têtes, etc., l'efficacité de l'utilisation de la bande passante et la vitesse de réponse sont affectées | La connexion continue élimine les étapes d'établissement des connexions et des informations nécessaires pour chaque requête, aboutissant à une latence plus faible et une meilleure efficacité d'utilisation de la bande passante |
| Les requêtes fréquentes affectent les performances | Les requêtes fréquentes n'affectent pas les performances |
Basé sur la comparaison des avantages et des inconvénients de HTTP et WebSocket dans la section précédente, nous pouvons évaluer les scénarios d'utilisation sous deux dimensions différentes :
- Si les données changent rapidement, et si l'activité dépend de données en temps réel
- Si une communication bidirectionnelle fréquente est impliquée
Par exemple, si Jack souhaite construire une application de chat vidéo où chaque utilisateur doit recevoir des données vidéo en temps réel de son partenaire de chat et transmettre son propre flux vidéo à l'autre partie, alors WebSocket est le meilleur choix.
La Console d'administration de Logto n'a pas besoin d'obtenir fréquemment l'utilisation actuelle des ressources de l'utilisateur connecté, car les ressources ne changent d'état que lorsque les utilisateurs modifient les configurations. Il suffit de ré-acquérir l'état des ressources en temps opportun lorsque les utilisateurs opèrent sur les ressources. Dans cette perspective, HTTP est très adapté au scénario d'utilisation de la Console d'administration de Logto. De même, pour la plupart des tableaux de bord des services cloud, HTTP peut être choisi comme protocole de communication entre le tableau de bord et le serveur.
