web-dev-qa-db-fra.com

Protocole WebSockets vs HTTP

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 amateurs de websocket):

HTML5 Web Sockets représente la prochaine évolution des communications Web: un canal de communication bidirectionnel en duplex intégral fonctionnant via un seul socket sur le Web. ( http://www.websocket.org/quantum.html )

HTTP prend en charge la diffusion: requête de diffusion en continu (vous l'utilisez lors du téléchargement de fichiers volumineux) et réponse en continu.

Lors de la connexion à 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 lors d’une interrogation continue.

Pourquoi ces 2 octets n'incluent-ils pas TCP et les frais généraux des protocoles TCP?

GET /about.html HTTP/1.1
Host: example.org

C'est l'en-tête http de ~ 48 octets.

encodage http chunked - http://ru.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 pour chaque morceau n'est pas énorme.

De plus, les deux protocoles fonctionnent sur TCP, de sorte que tous les TCP problèmes liés aux connexions longue durée sont toujours présents.

Question:

  1. Pourquoi le protocole websockets est-il meilleur?
  2. Pourquoi a-t-il été mis en œuvre au lieu de mettre à jour le protocole http?
ajaxhttpwebsocketcomet
284
4esn0k

1) Pourquoi le protocole WebSockets est-il meilleur?

WebSockets est préférable pour les situations impliquant une communication à faible temps de latence, en particulier pour les messages client à serveur à faible temps de latence. Pour les données serveur à client, vous pouvez obtenir une latence relativement faible en utilisant des connexions de longue durée et un transfert fractionné. Toutefois, cela n’aide en rien avec la latence client à serveur, qui nécessite l’établissement d’une nouvelle connexion pour chaque message client à serveur.

Votre négociation HTTP à 48 octets n'est pas réaliste pour les connexions de navigateur HTTP réelles où plusieurs kilo-octets de données sont souvent envoyés 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 pour utiliser Chrome:

Exemple de demande (2800 octets comprenant des données de cookie, 490 octets sans données de cookie): 

GET / HTTP/1.1
Host: www.cnn.com
Connection: keep-alive
Cache-Control: no-cache
Pragma: no-cache
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.68 Safari/537.17
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: [[[2428 byte of cookie data]]]

Exemple de réponse (355 octets): 

HTTP/1.1 200 OK
Server: nginx
Date: Wed, 13 Feb 2013 18:56:27 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: CG=US:TX:Arlington; path=/
Last-Modified: Wed, 13 Feb 2013 18:55:22 GMT
Vary: Accept-Encoding
Cache-Control: max-age=60, private
Expires: Wed, 13 Feb 2013 18:56:54 GMT
Content-Encoding: gzip

Les connexions HTTP et WebSockets ont une négociation initiale de taille équivalente, mais avec une connexion WebSocket, la négociation initiale est effectuée une fois, puis les petits messages ne disposent que de 6 octets de surcharge (2 pour l'en-tête et 4 pour la valeur de masque). La surcharge de latence ne provient pas tellement de la taille des en-têtes, mais de la logique d'analyse/de traitement/de stockage de 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 de chaque demande.

2) Pourquoi a-t-il été mis en œuvre au lieu de mettre à jour le protocole HTTP?

Des efforts sont en cours pour repenser le protocole HTTP afin d'obtenir de meilleures performances et une latence moindre, tels que SPDY , HTTP 2. 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 inférieure pour le transfert de données client à serveur par rapport au protocole HTTP (ou qu'il sera utilisé dans un mode qui ressemble beaucoup à WebSockets. de toute façon).

Mise à jour :

Voici un cadre pour réfléchir aux protocoles Web:

  • TCP: couche de transport de bas niveau, bidirectionnelle, en duplex intégral et à ordre garanti. Pas de support du navigateur (sauf via plugin/Flash).
  • HTTP 1.0 : protocole de transport demande-réponse en couche sur TCP. Le client fait une demande complète, le serveur donne une réponse complète, puis la connexion est fermée. Les méthodes de requête (GET, POST, HEAD) ont une signification transactionnelle spécifique pour les ressources sur le serveur.
  • HTTP 1.1 : conserve la nature requête-réponse de HTTP 1.0, mais permet à la connexion de rester ouverte pour plusieurs demandes complètes/réponses complètes (une réponse par demande). ) A toujours des en-têtes complets dans la demande et la réponse, mais la connexion est réutilisée et non fermée. HTTP 1.1 a également ajouté des méthodes de requête supplémentaires (OPTIONS, PUT, DELETE, TRACE, CONNECT) qui ont également des significations transactionnelles spécifiques. Toutefois, comme indiqué dans la introduction du projet de proposition HTTP 2.0, le traitement en pipeline HTTP 1.1 n’est pas largement déployé, ce qui limite considérablement l’utilité de HTTP 1.1 pour résoudre le temps de latence entre les navigateurs et les serveurs.
  • Long-poll : sorte de "piratage" vers HTTP (1.0 ou 1.1) où le serveur ne répond pas immédiatement (ou ne répond que partiellement avec des en-têtes ) à la demande du client. Après une réponse du serveur, le client envoie immédiatement une nouvelle demande (en utilisant la même connexion si elle est sur HTTP 1.1).
  • Diffusion HTTP en continu : diverses techniques (réponse multipart/chunked) permettant au serveur d’envoyer plusieurs réponses à une requête client unique. Le W3C normalise cette opération sous la forme événements envoyés par le serveur à l'aide d'un type text/event-stream MIME. L'API du navigateur (qui est assez similaire à l'API WebSocket) s'appelle l'API EventSource.
  • Comet/serveur Push : il s’agit d’un terme générique qui inclut à la fois la transmission longue durée et la diffusion HTTP. Les bibliothèques Comet prennent généralement en charge plusieurs techniques pour essayer d'optimiser la prise en charge multi-navigateurs et multi-serveurs.
  • WebSockets : couche de transport incorporée TCP qui utilise une négociation conviviale pour la mise à niveau par HTTP. Contrairement à TCP, qui est un transport en flux continu, WebSockets est un transport basé sur des messages: les messages sont délimités sur le fil et sont ré-assemblés intégralement avant leur remise à l'application. Les connexions WebSocket sont bidirectionnelles, en duplex intégral et de longue durée. Après la demande/réponse initiale d'établissement de liaison, il n'y a pas de sémantique transactionnelle et il y a très peu de temps système par message. Le client et le serveur peuvent envoyer des messages à tout moment et doivent gérer la réception du message de manière asynchrone.
  • SPDY: proposition de Google d'étendre le protocole HTTP à l'aide d'un protocole filaire plus efficace, tout en maintenant la sémantique HTTP (demande/réponse, cookies, codage). SPDY introduit un nouveau format de cadrage (avec des cadres avec préfixe de longueur) et spécifie un moyen de superposer des paires requête/réponse HTTP sur la nouvelle couche de cadrage. Les en-têtes peuvent être compressés et de nouveaux en-têtes peuvent être envoyés une fois la connexion établie. Il existe des applications réelles de SPDY dans les navigateurs et les serveurs.
  • HTTP 2.0 : a des objectifs similaires à ceux de SPDY: réduire la latence et la surcharge HTTP tout en préservant la sémantique HTTP. Le brouillon actuel est dérivé de SPDY et définit une mise à niveau de la négociation et du cadrage des données très similaire à la norme WebSocket pour la négociation et le cadrage. Un autre projet de proposition HTTP 2.0 (httpbis-speed-mobilité) utilise en réalité WebSockets pour la couche de transport et ajoute le multiplexage SPDY et le mappage HTTP en tant qu'extension WebSocket (les extensions WebSocket sont négociées pendant la prise de contact).
  • WebRTC/CU-WebRTC : propositions visant à permettre la connectivité entre homologues entre navigateurs. Cela peut permettre une communication à latence moyenne et maximale plus basse, car le transport sous-jacent est SDP/datagramme plutôt que TCP. Cela permet une livraison hors-commande de paquets/messages, ce qui évite le TCP épisodes de pics de latence causés par des paquets perdus retardant la livraison de tous les paquets suivants (afin de garantir la livraison dans l'ordre).
  • QUIC: est un protocole expérimental visant à réduire la latence du Web par rapport à TCP. En surface, QUIC est très similaire à TCP + TLS + SPDY implémenté sur UDP. QUIC fournit un multiplexage et un contrôle de flux équivalents à HTTP/2, une sécurité équivalente à TLS, ainsi qu'une sémantique de connexion, une fiabilité et un contrôle de congestion équivalents à TCP. Étant donné que TCP est implémenté dans les noyaux du système d'exploitation et dans le micrologiciel du boîtier de médiation, il est pratiquement impossible d'apporter des modifications importantes à TCP. Cependant, étant donné que QUIC est construit sur UDP, il ne souffre pas de telles limitations. QUIC est conçu et optimisé pour la sémantique HTTP/2.

Références :

447
kanaka

Vous semblez supposer que WebSocket remplace HTTP. Ce n'est pas. C'est une extension.

Les principaux cas d'utilisation de WebSockets sont des 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 sont un bon exemple.

Avant WebSockets, la seule méthode permettant aux applications Javascript d'interagir avec un serveur consistait à utiliser XmlHttpRequest. Mais ceux-ci présentent 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 à tout moment. Cela permet d’implémenter des jeux basés sur un navigateur avec une latence bien inférieure et sans avoir à utiliser d’incroyables hacks comme AJAX des plugins de longue interrogation ou de navigateur.

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 requête du client et le corps de la réponse de manière asynchrone.

En fait, les WebSockets sont fondamentalement cela. Une tentative d'ouvrir une connexion WebSocket à partir du client ressemble à une requête HTTP, mais une directive spéciale dans l'en-tête (Upgrade: websocket) indique au serveur de commencer à communiquer en mode asynchrone. Premiers brouillons du protocole WebSocket n'étaient pas beaucoup plus que cela et une poignée de main pour s'assurer que le serveur comprend réellement que le client veut communiquer de manière asynchrone. Mais on s'est rendu compte que cela dérouterait les serveurs proxy, car ils sont habitués au modèle de requête/réponse habituel de HTTP. Un scénario d'attaque potentielle contre les serveurs proxy a été découvert. Pour éviter cela, il était nécessaire de rendre le trafic WebSocket différent de tout trafic HTTP normal. C'est pourquoi les clés de masquage ont été introduites dans la version finale du protocole .

116
Philipp

Pour le TL; DR, voici 2 centimes et une version plus simple pour vos questions:

  1. WebSockets offre ces avantages sur HTTP:

    • Connexion avec état persistant pendant la durée de la connexion
    • Faible latence: communication en temps quasi réel entre serveur/client en raison de l’absence de temps système nécessaire pour rétablir les connexions pour chaque demande requise par HTTP.
    • Full duplex: le serveur et le client peuvent envoyer/recevoir simultanément

  2. WebSocket et le protocole HTTP ont été conçus pour résoudre différents problèmes, I.E. WebSocket a été conçu pour améliorer la communication bidirectionnelle alors que HTTP a été conçu pour être sans état, distribué à l'aide d'un modèle de requête/réponse. Hormis le partage des ports pour des raisons héritées (pénétration de pare-feu/proxy), il n’ya pas vraiment de terrain commun pour les combiner en un seul protocole.

18
Devy

Pourquoi le protocole websockets est-il meilleur?

Je ne pense pas que nous puissions les comparer côte à côte pour savoir qui est meilleur. Ce ne sera pas une comparaison juste 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 lui donne. C'est. Si le client de données souhaite une taille importante, le serveur peut envoyer des données en streaming afin d’annuler les problèmes de mémoire tampon indésirables. Ici, la principale exigence ou le principal problème 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.

En HTTP, seule la demande du client. Le serveur répond seulement.

WebSocket n'est pas un protocole de requête-réponse où seul le client peut demander. C'est une socket (très similaire à TCP socket). Une fois la connexion ouverte, chaque côté peut envoyer des données jusqu'à ce que la connexion TCP soit soulignée. C'est comme une prise normale. La seule différence avec TCP socket est que websocket peut être utilisé dans Web. En web, nous avons beaucoup de restrictions pour un socket normal. La plupart des pare-feu bloquent les ports autres que 80 et 433 utilisés par HTTP. Les procurations et les intermédiaires seront également problématiques. Pour faciliter le déploiement du protocole sur les infrastructures existantes, utilisez Websocket pour établir une liaison HTTP. Cela signifie que, lorsque la première connexion va s'ouvrir, le client a envoyé une requête HTTP au serveur en lui disant: "Ce n'est pas une requête HTTP, veuillez effectuer la mise à niveau vers le protocole websocket".

Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

Une fois que le serveur a compris la demande et mis à niveau vers le protocole websocket, le protocole HTTP ne s’applique plus.

Donc, ma réponse est Ni l'un ni l'autre ne sont meilleurs l'un que l'autre. Ils sont complètement différents.

Pourquoi a-t-il été mis en œuvre au lieu de mettre à jour le protocole http?

Eh bien, nous pouvons tout créer sous le nom appelé HTTP également. Mais allons-nous? Si ce sont deux choses différentes, je préférerai deux noms différents. Il en va de même pour Hickson et Michael Carter .

11
FranXho

Les autres réponses ne semblent pas toucher ici à un aspect clé, à savoir que vous ne mentionnez pas la nécessité de prendre en charge un navigateur Web en tant que client. La plupart des limitations du simple HTTP 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 de demander à un client d'effectuer un POST avec un transfert d'encodage en bloc, et à un serveur de renvoyer une réponse avec un corps d'encodage en bloc. Cela enlèverait la surcharge d'en-tête juste au moment de l'initialisation.

Donc, si tout ce que vous recherchez est en duplex intégral, contrôlez le client et le serveur, et ne vous intéressez pas aux fonctions supplémentaires de cadrage/Websockets, alors je dirais que HTTP est une approche plus simple avec une latence plus faible/CPU (bien que la latence ne différerait vraiment qu'en microsecondes ou moins pour les deux).

5
parity3

Une API normale REST utilise HTTP comme protocole de communication sous-jacent, qui suit le paradigme de la demande et de la réponse, ce qui signifie que le client demande des données ou des ressources à un serveur et que le serveur y répond. client. Cependant, HTTP étant un protocole sans état, chaque cycle de requête-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 demande-réponse fréquemment répétés.

http

Avec WebSockets , bien que la communication commence toujours par une négociation HTTP initiale, il convient de mettre à niveau le protocole WebSockets (c.-à-d. Si le serveur et le client sont conformes au protocole car toutes les entités ne prennent pas en charge le protocole WebSockets).

Maintenant, avec WebSockets , il est possible d’établir une connexion en 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 tant que l'application est en cours d'exécution (c'est-à-dire persistante) et, vu qu'elle est en duplex intégral, une communication simultanée bidirectionnelle est possible, c'est-à-dire que le serveur est maintenant capable de démarrer. une communication et une transmission de données au client lorsque de nouvelles données (qui intéressent le client) sont disponibles.

websockets

Le protocole WebSockets est dynamique et vous permet d'implémenter le modèle de messagerie Publish-Subscribe (ou Pub/Sub) qui est le concept principal utilisé dans les technologies temps réel dans lesquelles vous pouvez obtenir de nouvelles mises à jour. la forme du serveur Push sans que le client ait à demander (actualiser la page) à plusieurs reprises. Parmi les exemples de telles applications, citons le suivi de la localisation d'Uber car, les notifications push, la mise à jour des prix de la bourse en temps réel, les discussions en ligne, les jeux multijoueurs, les outils de collaboration en direct, etc.

Vous pouvez consulter un article de plongée approfondie sur Websockets qui explique l'historique de ce protocole, son origine, son utilisation et sa mise en oeuvre.

Voici une vidéo d'une présentation que j'ai faite sur WebSockets et sur la différence entre leur utilisation et l'utilisation des API REST normales: Normalisation et exploitation de la croissance exponentielle du flux de données

5
Srushtika Neelakantam