Il existe de nombreux blogs et discussions sur websocket et HTTP, et de nombreux développeurs et sites préconisent fortement les websockets, mais je ne comprends toujours pas pourquoi.
par exemple (arguments des amoureux du websocket):
HTML5 Web Sockets représente la prochaine évolution des communications Web: un canal de communication bidirectionnel en duplex intégral qui fonctionne via un seul socket sur le Web. ( http://www.websocket.org/quantum.html )
HTTP prend en charge la diffusion en continu: demandez la diffusion en continu du corps (vous l'utilisez lors du téléchargement de fichiers volumineux) et la réponse en continu.
Lors de l'établissement de la connexion avec WebSocket, le client et le serveur échangent des données par trame de 2 octets chacune, contre 8 kilo-octets d'en-tête http lorsque vous effectuez une interrogation continue.
Pourquoi ces 2 octets n'incluent-ils pas la surcharge TCP et sous les protocoles TCP?
GET /about.html HTTP/1.1
Host: example.orgIl s'agit d'un en-tête http ~ 48 octets.
Encodage HTTP en morceaux - https://en.wikipedia.org/wiki/Chunked_transfer_encoding :
23
This is the data in the first chunk
1A
and this is the second one
3
con
8
sequence
0- Ainsi, les frais généraux par morceau ne sont pas importants.
De plus, les deux protocoles fonctionnent sur TCP, donc tous les problèmes TCP avec les connexions longue durée sont toujours là.
Des questions:
- Pourquoi le protocole websockets est-il meilleur?
- Pourquoi a-t-il été implémenté au lieu de mettre à jour le protocole http?
Réponses:
1) Pourquoi le protocole WebSockets est-il meilleur?
WebSockets est préférable pour les situations impliquant une communication à faible latence, en particulier pour les messages à client à faible latence. Pour les données du serveur au client, vous pouvez obtenir une latence assez faible en utilisant des connexions de longue date et un transfert en bloc. Cependant, cela n'aide pas avec la latence client-serveur qui nécessite une nouvelle connexion pour chaque message client-serveur.
Votre prise de contact HTTP de 48 octets n'est pas réaliste pour les connexions de navigateur HTTP réelles où il y a souvent plusieurs kilo-octets de données envoyées dans le cadre de la demande (dans les deux sens), y compris de nombreux en-têtes et données de cookies. Voici un exemple de demande / réponse à l'utilisation de Chrome:
Exemple de demande (2800 octets, y compris les données des cookies, 490 octets sans les données des cookies):
Exemple de réponse (355 octets):
HTTP et WebSockets ont des prises de contact de connexion initiale de taille équivalente, mais avec une connexion WebSocket, la prise de contact initiale est effectuée une fois, puis les petits messages n'ont que 6 octets de surcharge (2 pour l'en-tête et 4 pour la valeur de masque). La surcharge de latence ne vient pas tant de la taille des en-têtes, mais de la logique pour analyser / gérer / stocker ces en-têtes. De plus, la latence de configuration de la connexion TCP est probablement un facteur plus important que la taille ou le temps de traitement pour chaque demande.
2) Pourquoi a-t-il été implémenté au lieu de mettre à jour le protocole HTTP?
Des efforts sont en cours pour réorganiser le protocole HTTP pour obtenir de meilleures performances et une latence plus faible, tels que SPDY , HTTP 2.0 et QUIC . Cela améliorera la situation pour les requêtes HTTP normales, mais il est probable que WebSockets et / ou WebRTC DataChannel auront toujours une latence plus faible pour le transfert de données client à serveur que le protocole HTTP (ou il sera utilisé dans un mode qui ressemble beaucoup à WebSockets de toute façon).
Mettre à jour :
Voici un cadre pour réfléchir aux protocoles Web:
text/event-streamtype MIME. L'API du navigateur (qui est assez similaire à l'API WebSocket) est appelée l'API EventSource.Références :
la source
Vous semblez supposer que WebSocket remplace HTTP. Ce n'est pas. C'est une extension.
Les principaux cas d'utilisation des WebSockets sont les applications Javascript qui s'exécutent dans le navigateur Web et reçoivent des données en temps réel d'un serveur. Les jeux en sont un bon exemple.
Avant WebSockets, la seule méthode permettant aux applications Javascript d'interagir avec un serveur était d'utiliser
XmlHttpRequest. Mais ceux-ci ont un inconvénient majeur: le serveur ne peut pas envoyer de données à moins que le client ne l'ait explicitement demandé.Mais la nouvelle fonctionnalité WebSocket permet au serveur d'envoyer des données quand il le souhaite. Cela permet de mettre en œuvre des jeux basés sur un navigateur avec une latence beaucoup plus faible et sans avoir à utiliser des hacks laids comme les plugins AJAX à longue interrogation ou les navigateurs.
Alors pourquoi ne pas utiliser HTTP normal avec des requêtes et des réponses en streaming
Dans un commentaire à une autre réponse, vous avez suggéré de simplement diffuser la demande client et le corps de réponse de manière asynchrone.
En fait, les WebSockets sont essentiellement cela. Une tentative d'ouverture d'une connexion WebSocket à partir du client ressemble au début à une requête HTTP, mais une directive spéciale dans l'en-tête (Upgrade: websocket) indique au serveur de commencer à communiquer dans ce mode asynchrone. Les premières versions du protocole WebSocket n'étaient pas beaucoup plus que cela et une poignée de main pour s'assurer que le serveur comprenait réellement que le client voulait communiquer de manière asynchrone. Mais ensuite, on a réalisé que les serveurs proxy seraient confus par cela, car ils sont habitués au modèle de demande / réponse habituel de HTTP. Un scénario d'attaque potentiel contre les serveurs proxy a été découvert. Pour éviter cela, il était nécessaire de faire en sorte que le trafic WebSocket ne ressemble à aucun trafic HTTP normal. C'est pourquoi les touches de masquage ont été introduites dansla version finale du protocole .
la source
Une API REST régulière utilise le HTTP comme protocole sous-jacent pour la communication, qui suit le paradigme de demande et de réponse, ce qui signifie que la communication implique que le client demande des données ou des ressources à un serveur et que le serveur réponde à ce client. Cependant, HTTP est un protocole sans état, donc chaque cycle de demande-réponse finira par devoir répéter les informations d'en-tête et de métadonnées. Cela entraîne une latence supplémentaire en cas de cycles de demande-réponse fréquemment répétés.
Avec WebSockets, bien que la communication démarre toujours comme une poignée de main HTTP initiale, il s'agit de mises à niveau supplémentaires pour suivre le protocole WebSockets (c'est-à-dire si le serveur et le client sont conformes au protocole car toutes les entités ne prennent pas en charge le protocole WebSockets).
Désormais, avec WebSockets, il est possible d'établir une connexion duplex intégral et persistante entre le client et un serveur. Cela signifie que, contrairement à une demande et à une réponse, la connexion reste ouverte aussi longtemps que l'application est en cours d'exécution (c'est-à-dire qu'elle est persistante), et comme elle est en duplex intégral, une communication simultanée bidirectionnelle est possible, c'est-à-dire que le serveur est désormais capable d'initier une communication et «pousser» certaines données vers le client lorsque de nouvelles données (qui intéressent le client) deviennent disponibles.
Le protocole WebSockets est dynamique et vous permet d'implémenter le modèle de messagerie Publish-Subscribe (ou Pub / Sub) qui est le principal concept utilisé dans les technologies en temps réel où vous pouvez obtenir de nouvelles mises à jour sous la forme d'une poussée de serveur sans le le client doit demander (actualiser la page) à plusieurs reprises. Des exemples de telles applications sont le suivi de la localisation de la voiture Uber, les notifications push, la mise à jour des cours boursiers en temps réel, le chat, les jeux multijoueurs, les outils de collaboration en ligne en direct, etc.
Vous pouvez consulter un article approfondi sur Websockets qui explique l'historique de ce protocole, comment il a vu le jour, à quoi il sert et comment vous pouvez l'implémenter vous-même.
Voici une vidéo d'une présentation que j'ai faite sur les WebSockets et en quoi ils diffèrent de l'utilisation des API REST standard : Standardisation et exploitation de l'augmentation exponentielle du streaming de données
la source
Pour le TL; DR, voici 2 cents et une version plus simple pour vos questions:
WebSockets offre ces avantages sur HTTP:
WebSocket et le protocole HTTP ont été conçus pour résoudre différents problèmes, IE WebSocket a été conçu pour améliorer la communication bidirectionnelle tandis que HTTP a été conçu pour être sans état, distribué à l'aide d'un modèle de demande / réponse. Mis à part le partage des ports pour des raisons héritées (pare-feu / pénétration du proxy), il n'y a pas beaucoup de terrain d'entente pour les combiner en un seul protocole.
la source
Pourquoi le protocole websockets est-il meilleur?
Je ne pense pas que nous puissions les comparer côte à côte comme qui est le meilleur. Ce ne sera pas une comparaison équitable simplement parce qu'ils résolvent deux problèmes différents . Leurs exigences sont différentes. Ce sera comme comparer des pommes à des oranges. Ils sont différents.
HTTP est un protocole de requête-réponse. Le client (navigateur) veut quelque chose, le serveur le donne. C'est. Si le client de données souhaite être volumineux, le serveur peut envoyer des données en streaming pour annuler les problèmes de tampon indésirables. Ici, l'exigence ou le problème principal est de savoir comment faire la demande des clients et comment répondre aux ressources (hybertext) qu'ils demandent. C'est là que HTTP brille.
WebSocket n'est pas un protocole de demande-réponse où seul le client peut demander. Il s'agit d'un socket (très similaire au socket TCP). Une fois que la connexion est ouverte, chaque côté peut envoyer des données jusqu'à ce que la connexion TCP soulignée soit fermée. C'est comme une prise normale. La seule différence avec le socket TCP est que websocket peut être utilisé dans le web. Dans le Web, nous avons beaucoup de restrictions pour une socket normale. La plupart des pare-feu bloquent les autres ports que 80 et 433 utilisés par HTTP. Les proxys et intermédiaires seront également problématiques. Pour rendre le protocole plus facile à déployer sur les infrastructures Websocket existantes, utilisez la négociation HTTP pour la mise à niveau. Cela signifie que lors de la première connexion, le client a envoyé une requête HTTP pour dire au serveur "Ce n'est pas une requête HTTP, veuillez mettre à niveau vers le protocole websocket".
Une fois que le serveur a compris la demande et mis à niveau vers le protocole websocket, aucun des protocoles HTTP ne s'est appliqué.
Ma réponse est donc: ni l'un ni l'autre n'est meilleur l'un que l'autre. Ils sont complètement différents.
Pourquoi a-t-il été implémenté au lieu de mettre à jour le protocole http?
Eh bien, nous pouvons aussi tout faire sous le nom de HTTP . Mais le ferons-nous? S'il s'agit de deux choses différentes, je préférerai deux noms différents. Hickson et Michael Carter aussi .
la source
Les autres réponses ne semblent pas toucher à un aspect clé ici, c'est-à-dire que vous ne mentionnez pas la nécessité de prendre en charge un navigateur Web en tant que client. La plupart des limitations de HTTP simple ci-dessus supposent que vous travailleriez avec des implémentations de navigateur / JS.
Le protocole HTTP est entièrement capable de communiquer en duplex intégral; il est légal qu'un client effectue un POST avec un transfert de codage en blocs et qu'un serveur renvoie une réponse avec un corps de codage en blocs. Cela supprimerait la surcharge de l'en-tête juste au moment de l'initialisation.
Donc, si tout ce que vous recherchez est en duplex intégral, contrôlez à la fois le client et le serveur et que vous n'êtes pas intéressé par le cadre / les fonctionnalités supplémentaires des websockets, je dirais que HTTP est une approche plus simple avec une latence / CPU plus faible (bien que la latence ne différerait vraiment qu'en microsecondes ou moins pour les deux).
la source