Les WebSockets protocole vs HTTP

Il existe beaucoup de blogs et de discussions à propos de websocket et HTTP, et de nombreux développeurs et les sites fermement défendre les websockets, mais je n'arrive toujours pas à comprendre pourquoi.

par exemple (les arguments de websocket les amateurs):

Websockets HTML5 représente la prochaine évolution de la communication web—un full-duplex, canal de communication bidirectionnel qui opère à travers un socket unique sur le Web.
( http://www.websocket.org/quantum.html )

HTTP soutient streaming: le corps de la requête de diffusion(vous l'utilisez alors que le téléchargement de fichiers volumineux) et le corps de la réponse en streaming.

Cours de mise en relation avec WebSocket, le client et le serveur échangent des données par trame qui est de 2 octets chacun, par rapport à 8 kilo-octets d'en-tête http lorsque vous effectuez une interrogation continue.

Pourquoi n'a que 2 octets de ne pas inclure tcp et en vertu de protocoles tcp dessus?

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

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

http fragments de codage - 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
  • Donc, les frais généraux par chaque morceau n'est pas grand.

Également dans le protocole fonctionne sur TCP, de sorte que tous TCP problèmes à long live les connexions sont toujours là.

Question:

  1. Pourquoi les websockets protocole de mieux?
  2. Pourquoi il a été mis en œuvre au lieu de la mise à jour du protocole http?
  • Quelle est votre question?
  • 1) pourquoi les websockets protocole est le meilleur? 2) Pourquoi il a été mis en œuvre au lieu de la mise à jour du protocole http? 3) Pourquoi les websockets sont ainsi promues?
  • vous pouvez le faire avec les sockets TCP ou http pour les applications de bureau; et vous devez utiliser le WebRTC pour faire de navigateur à navigateur de communication pour le site web
  • il est webRTC pour le navigateur à navigateur, pas les websockets
  • WS n'est pas mieux, ils sont différents et mieux pour certaines tâches spécifiques. 3) C'est une nouvelle fonctionnalité que les gens doivent être conscients de, et ouvrir de nouvelles possibilités pour le Web
  • C'est faux, les Websockets sont un client de la technologie de serveur et de ne pas le P2P.
  • ...exactement ce que je pense ...

InformationsquelleAutor 4esn0k | 2013-02-05
  1. 458

    1) Pourquoi les WebSockets protocole de mieux?

    WebSockets est mieux pour les situations qui impliquent un faible temps de latence de communication, notamment pour de faibles temps de latence pour le client vers le serveur de messages. Pour le serveur de données de clients que vous pouvez obtenir assez faible latence à l'aide de la longue-tenue des connexions et des fragments de transfert. Cependant, cela n'aide pas avec le client pour la latence du serveur qui nécessite une nouvelle connexion pour chaque client vers le serveur de messages.

    Votre 48 octets HTTP poignée de main n'est pas réaliste dans le monde réel HTTP connexions navigateur où il y a souvent plusieurs kilo-octets de données transmises dans le cadre de la demande (dans les deux sens), y compris de nombreux en-têtes et les données de cookie. Voici un exemple de requête/réponse à l'aide de Chrome:

    Exemple de demande (2800 octets, y compris les données des cookies, 490 octets sans les 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

    HTTP et les WebSockets avoir l'équivalent de la taille initiale de la connexion des poignées de main, mais avec une connexion WebSocket la poignée de main initiale est effectuée une seule fois et puis des petits messages seulement 6 octets de surcharge (2 pour l'en-tête et de 4 pour la valeur de masque). Le temps de latence de frais généraux n'est pas tant la taille des en-têtes, mais de la logique pour analyser/gérer/stockage de ces en-têtes. En outre, la connexion TCP configuration du temps de latence est probablement un facteur plus grand que la taille ou le temps de traitement de chaque demande.

    2) Pourquoi il a été mis en œuvre au lieu de la mise à jour du protocole HTTP?

    Il y a des efforts à re-concevoir le protocole HTTP pour obtenir de meilleures performances et une faible latence comme SPDY, HTTP 2.0 et QUIC. Cela permettra d'améliorer la situation normale pour les requêtes HTTP, mais il est probable que les WebSockets et/ou WebRTC DataChannel auront toujours un temps de latence inférieur pour le client vers le serveur de transfert de données de protocole HTTP (ou il sera utilisé dans un mode qui ressemble beaucoup à WebSockets de toute façon).

    Mise à jour:

    Ici est un cadre de réflexion sur les protocoles web:

    • TCP: bas niveau, bi-directionnel, full-duplex, et de la garantie de l'ordre de la couche de transport. Pas de prise en charge du navigateur (sauf via un plugin ou d'un Flash).
    • HTTP 1.0: requête-réponse de protocole de transport en couches sur le protocole TCP. Le client fait une requête, le serveur donne une réponse complète, et la connexion est fermée. La demande de méthodes (GET, POST, HEAD) ont des transactionnel sens pour les ressources sur le serveur.
    • HTTP 1.1: maintient la requête-réponse de la nature de HTTP 1.0, mais permet la connexion à rester ouvert à de multiples requêtes complètes/réponses complètes (une seule réponse par demande). A encore plein les en-têtes de la requête et de la réponse, mais la connexion est de nouveau utilisé et ne sont pas fermées. HTTP 1.1, a également ajouté quelques autres méthodes de demande (OPTIONS, PUT, DELETE, TRACE, CONNECT) qui ont aussi spécifique transactionnelle significations. Toutefois, comme indiqué dans le introduction à l'adresse HTTP 2.0, le projet de proposition, HTTP 1.1 pipeline n'est pas largement déployé donc cela limite grandement l'utilité de HTTP 1.1 pour résoudre la latence entre les navigateurs et les serveurs.
    • Long-sondage: une sorte de "hack" pour HTTP (soit 1.0 ou 1.1) où le serveur n'a pas de réponse immédiatement (ou n'y répond que partiellement avec les 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 plus de HTTP 1.1).
    • Streaming HTTP: une variété de techniques (multipart/fragments de réponse) qui permettent au serveur d'envoyer plus d'une réponse à une simple demande du client. Le W3C est la standardisation de ce que Server-Sent Events à l'aide d'un text/event-stream type MIME. Le navigateur de l'API (qui est assez similaire à l'API WebSocket) est appelé le EventSource API.
    • Comète/server push: c'est un terme générique qui comprend les deux long-sondage et streaming HTTP. La comète bibliothèques en général de l'aide de multiples techniques pour essayer de maximiser la croix-navigateur et de la croix-serveur.
    • WebSockets: une couche de transport intégré sur TCP qui utilise un HTTP amicale de Mise à niveau de la poignée de main. Contrairement à TCP, qui est un flux de transport, les WebSockets est un message en fonction du transport des messages: les messages sont délimitées sur le fil et sont ré-assemblés en complet avant la livraison de l'application. WebSocket connexions sont bidirectionnelles en duplex intégral et à long terme. Après la poignée de main initiale de demande/réponse, il n'y a pas de sémantique transactionnelle et il est très peu par message généraux. Le client et le serveur peut envoyer des messages à tout moment et doit gérer la réception de message asynchrone.
    • SPDY: Google a initié une proposition visant à étendre HTTP à l'aide plus efficace le fil de protocole, mais le maintien de tous HTTP sémantique (demande/réponse, les cookies, l'encodage). SPDY introduit un nouveau format de trame (avec la longueur de préfixe de cadres) et spécifie un moyen de superposition de requête/réponse HTTP paires sur le nouveau cadrage de la couche. Les en-têtes peuvent être compressés et de nouveaux en-têtes peuvent être envoyés après que la connexion a été établie. Il y a du monde réel implémentations de SPDY dans les navigateurs et les serveurs.
    • HTTP 2.0: a des objectifs similaires à SPDY: réduire HTTP latence et les frais généraux tout en préservant HTTP sémantique. Le projet actuel est dérivé de SPDY et définit une mise à niveau de la poignée de main et des données de cadrage, qui est très semblable à la le WebSocket standard pour l'établissement de liaisons et d'encadrement. Un autre HTTP 2.0 projet de proposition (httpbis à la vitesse de la mobilité) utilise les WebSockets pour la couche de transport et ajoute le SPDY de multiplexage et de HTTP cartographie comme un WebSocket extension (WebSocket extensions sont négociés au cours de la poignée de main).
    • WebRTC/CU-WebRTC: propositions pour permettre peer-to-peer de la connectivité entre les navigateurs. Cela peut permettre à la baisse de la moyenne et maximale de la latence de communication parce que, comme le transport sous-jacent est SDP/datagramme plutôt que TCP. Cela vous permet de commander la livraison de paquets/messages, ce qui évite de TCP problème des pics de latence causée par la perte de paquets, qui retardent la livraison de tous les paquets suivants (pour garantir la livraison dans l'ordre).
    • QUIC: est un protocole expérimental visant à réduire web de latence plus que de TCP. Sur la surface, QUIC est très similaire à TCP+TLS+SPDY mis en œuvre sur UDP. QUIC fournit le multiplexage et de contrôle de débit d'équivalent de HTTP/2, de sécurité équivalent à TLS, de connexion et de la sémantique, de la fiabilité et de contrôle de congestion equivalentto TCP. Parce que le protocole TCP est mis en œuvre dans le noyau du système d'exploitation, et middlebox firmware, d'apporter des changements importants à TCP est à peu près impossible. Cependant, depuis QUIC est construit au-dessus d'UDP, il ne souffre d'aucun de ces limitations. QUIC est conçu et optimisé pour le HTTP/2 de la sémantique.

    Références:

    • >>Toutefois, cela n'aide pas avec le client pour la latence du serveur qui nécessite une nouvelle connexion pour chaque client vers le serveur de messages. - est-ce que le streaming de corps de la réponse? je sais, XMLHttpRequest API ne permet pas cela, mais il existe. avec le streaming sur le serveur, vous pouvez diffuser du côté client.
    • Je ne suis pas au courant de toute façon de faire de la client->serveur HTTP en streaming. Toutes les solutions que je connais sont pour le serveur->client HTTP en streaming. Il est peu probable qu'un client->serveur de streaming solution soit adopté ou standardisés car cela casserait HTTP sémantique (même serveur->client de streaming est discutable pour beaucoup). Les WebSockets est la solution qui a été développé pour permettre faible du client->serveur (et donc l'aller-retour) temps de latence, sans avoir à respecter HTTP sémantique.
    • Je suis désolé pour vous. Vous avez regardé toutes ces sources pour obtenir les 150 rep, mais la seule raison OP de mettre en place la prime est parce qu'il voulait quelqu'un pour lui dire qu'il a raison.
    • il a posé une question que j'avais eu envie de faire de la recherche et de documenter à fond de toute façon. La question des WebSockets vs d'autres basées sur HTTP mécanisme vient assez souvent, mais alors maintenant, il est une bonne référence pour établir le lien. Mais oui, il semble probable que le demandeur était à la recherche de preuves d'une idée préconçue sur les WebSockets vs HTTP particulièrement depuis il n'a jamais choisi une réponse, ni reçu le bounty.
    • Merci beaucoup pour cette très belle et la vue d'ensemble précise ofprotocols.
    • Merci pour cette réponse très claire. Savez-vous si il y a une sorte de "matrice de compatibilité" pour ces protocoles? Quand je suis en train d'élaborer un site web mobile, puis-je utiliser chacun d'eux?
    • href="http://caniuse.com" >caniuse.com donner la compatibilité du navigateur de l'information (y compris mobile).
    • Je me souviens avoir entendu qu'un websocket utilise beaucoup de bande passante afin de garder la connexion. Est-ce vrai?
    • non, le protocole WebSocket niveau de la connexion reste ouverte jusqu'à ce qu'un côté ou de l'autre ferme la connexion. Vous pourriez aussi avoir à vous soucier des délais d'attente TCP (un problème avec l'un protocole basé sur TCP), mais toute sorte de trafic chaque minute ou deux de garder la connexion ouverte. En fait, le protocole WebSocket définition précise d'une table de ping/pong type de trame, bien que, même sans que vous envoyer un octet (plus de deux octets d'en-tête) et qui permettrait de maintenir la connexion ouverte. 2-3 octets toutes les deux minutes n'est pas significative la bande passante de l'impact à tous.

    InformationsquelleAutor kanaka
  2. 122

    Vous semblez supposer que WebSocket est un remplacement pour HTTP. Il n'est pas. C'est une extension.

    Les principaux cas d'utilisation des WebSockets sont Javascript applications qui s'exécutent dans le navigateur web et de recevoir des données en temps réel à partir d'un serveur. Les jeux sont un bon exemple.

    Avant les WebSockets, la seule méthode pour des applications Javascript pour interagir avec un serveur par le biais de XmlHttpRequest. Mais elles ont un inconvénient majeur: Le serveur ne peut pas envoyer de données, sauf si le client a expressément demandé.

    Mais la nouvelle WebSocket permet au serveur d'envoyer des données à chaque fois qu'il veut. Cela permet de mettre en œuvre basée sur le navigateur de jeux avec beaucoup moins de latence et sans avoir à utiliser laid hacks comme AJAX le long du scrutin ou plug-ins de navigateur.

    Alors pourquoi ne pas faire un usage normal l'adresse HTTP en streaming avec les demandes et les réponses

    Dans un commentaire à une autre réponse vous a suggéré de juste de flux de la demande du client et le corps de la réponse de manière asynchrone.

    En fait, les WebSockets sont essentiellement que. Une tentative d'ouverture d'une connexion WebSocket de la client ressemble à une requête HTTP au premier abord, mais une directive spéciale dans l'en-tête (Mise à jour: websocket) indique au serveur de communiquer dans ce mode asynchrone. Les premiers projets de protocole WebSocket n'étaient pas beaucoup plus que cela et certains serrer la main pour s'assurer que le serveur comprend que le client veut communiquer de manière asynchrone. Mais ensuite il s'est rendu compte que les serveurs proxy serait troublé par ça, parce qu'ils sont utilisés à l'habitude de requête/réponse modèle de HTTP. Un potentiel scénario d'attaque contre les serveurs proxy a été découvert. Pour éviter cela, il était nécessaire de faire WebSocket trafic look à la différence de tout le trafic HTTP. C'est pourquoi le masquage clés ont été introduites dans la version finale du protocole.

    • >> il serveur ne peut pas envoyer de données, sauf si le client a expressément demandé.; Navigateur Web doit initier les WebSockets connexion... comme pour XMLHttpRequest
    • Le navigateur ne initier une connexion websocket. Mais après qu'elle est établie, les deux parties peuvent envoyer des données à chaque fois qu'ils veulent. Ce n'est pas le cas pour XmlHttpRequest.
    • POURQUOI ce n'est pas possible avec le protocole HTTP ?
    • J'ai ajouté une nouvelle section à ma réponse
    • les jeux sont un bon exemple où les WebSockets briller. Cependant, il n'est pas en temps réel des données à partir du serveur où vous obtenez la plus grande victoire. Vous pouvez obtenir presque aussi bon serveur->client latence en utilisant le streaming HTTP/longue-tenue des connexions. Et avec une longue-tenue des demandes de serveurs peut effectivement envoyer à chaque fois qu'ils ont données, car le client a déjà envoyé la requête et le serveur est "la tenue de la demande" jusqu'à ce qu'il a données. La plus grande victoire pour les WebSockets est avec le client->latence du serveur (et donc l'aller-retour). Le client doit être en mesure d'envoyer à chaque fois qu'il veut, sans demander de frais généraux est la véritable clé.
    • une autre remarque: il existe d'autres méthodes plus XMLHttpRequest et les WebSockets pour le JavaScript pour interagir avec le serveur, y compris les iframes et à long sondage des balises de script. Voir la Comète page wikipédia pour plus de détails: en.wikipedia.org/wiki/Comet_(programmation)

    InformationsquelleAutor Philipp
  3. 19

    Pour le TL;DR, voici 2 cents et une version plus simple pour répondre à vos questions:

    1. WebSockets fournit ces prestations sur HTTP:

      • Persistante une connexion pour la durée de connexion
      • Faible temps de latence: près de la communication en temps réel entre le serveur/client en raison de l'absence de charge de rétablir les connexions pour chaque requête HTTP exige.
      • Full duplex: à la fois le serveur et le client peut envoyer/recevoir des simutaneously

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

    • Important que vous avez mentionné le terme de dynamique et apatrides dans votre comparaison (Y)
    InformationsquelleAutor Devy
  4. 17

    Un REPOS régulier de l'API utilise le HTTP comme protocole sous-jacent pour la communication, qui suit la demande et de la réponse de paradigme, sens de la communication implique le client, lui demandant de certaines données ou de ressources à partir d'un serveur, et le serveur répond en arrière à ce client. Cependant, HTTP est un protocole sans état, de sorte que chaque cycle de requête-réponse sera à la fin d'avoir à répéter l'en-tête et les informations de métadonnées. Ceci entraîne une latence supplémentaire en cas de répété fréquemment de la requête-réponse cycles.

    Les WebSockets protocole vs HTTP

    Avec les WebSockets, bien que la communication commence toujours comme une initiale HTTP poignée de main, il est en outre des mises à niveau pour suivre les WebSockets protocole (par exemple, si le serveur et le client sont compatibles avec le protocole que pas toutes les entités de soutien les WebSockets protocole).

    Maintenant avec les WebSockets, il est possible d'établir un mode full duplex et connexion 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 qu'il est persistant), et depuis il est full-duplex, les deux sens de communication simultanée est possible, j'.e maintenant que le serveur est capable d'initier une communication et "push" de certaines données pour le client lorsque de nouvelles données (que le client est intéressé par) devient disponible.

    Les WebSockets protocole vs HTTP

    Les WebSockets protocole est dynamique et permet de mettre en oeuvre la publication-souscription (ou d'un Pub/Sub) modèle de messagerie qui est le principal concept utilisé dans les technologies en temps réel où vous êtes en mesure d'obtenir de nouvelles mises à jour sous la forme de serveur push, sans que le client ait besoin de le demander (actualiser la page) à plusieurs reprises. Des exemples de telles applications sont Uber voiture de suivi et de localisation, les Notifications Push, les cours de bourse de la mise à jour en temps réel, le chat, les jeux multijoueurs en ligne et en direct à des outils de collaboration, etc.

    Vous pouvez consulter une plongée profonde à l'article sur les Websockets qui explique l'histoire de ce protocole, comment il est venu en ce qu'il est et comment vous pouvez appliquer vous-même.

    Voici une vidéo de la présentation que j'ai fait sur les WebSockets et comment ils sont différents de ce que l'utilisation régulière des Api REST: La normalisation et de tirer parti de la croissance exponentielle des données en streaming

    InformationsquelleAutor Srushtika Neelakantam
  5. 14

    Pourquoi les websockets protocole de mieux?

    Je ne pense pas que nous pouvons les comparer côte à côte comme qui est mieux. Qui ne sera pas juste de comparaison, simplement parce qu'ils sont en train de résoudre deux problèmes différents. Leurs besoins sont différents. Ce sera comme comparer des pommes à des oranges. Ils sont différents.

    HTTP est un protocole de demande–réponse. Le Client (navigateur), il veut quelque chose, le serveur lui donne. Qui est. Si les données client veut, c'est en gros, le serveur peut envoyer des flux de données à vide indésirables problèmes de buffer. Ici exigence principale ou le problème est de savoir comment faire la demande de clients et comment la réponse de la ressources(hybertext) ils demandent. C'est là que HTTP briller.

    En HTTP, uniquement à la demande du client. Le serveur ne répond.

    WebSocket n'est pas un protocole de demande-réponse où seul le client peut demander. C'est un socket(très similaire à TCP socket). Dire une fois que la connexion est ouverte, chaque partie peut envoyer des données jusqu'en soulignant connexion TCP est fermée. C'est comme une prise normale. La seule différence avec les socket TCP est websocket peut être utilisé dans le web. Dans le web, nous avons beaucoup de restriction pour une prise normale. La plupart des pare-feu bloquera autre port que le port 80 et 433 HTTP utilisée. Les procurations et les intermédiaires sont également problématiques.Afin de rendre le protocole plus facile à déployer des infrastructures existantes websocket utiliser HTTP poignée de main à la mise à niveau. Que dire lors de la première connexion au moment de l'est va ouvrir, client envoie la requête HTTP à dire serveur en disant: "ce n'est pas de la requête HTTP, veuillez la mettre à jour protocole websocket". 

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

    Une fois que le serveur de comprendre la demande et la mise à niveau de protocole websocket, aucun protocole HTTP applique plus.

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

    Pourquoi il a été mis en œuvre au lieu de la mise à jour du protocole http?

    Eh bien, nous pouvons faire tout ce qui est sous le nom de HTTP ainsi. Mais allons-nous? Si elles sont deux choses différentes, je préfère deux noms différents. Donc, ne Hickson et Michael Carter .

    InformationsquelleAutor FranXho
  6. 6

    Les autres réponses ne semblent pas toucher un point clé ici, et qui vous font aucune mention d'exiger l'appui d'un navigateur web comme client. La plupart des limites de la plaine HTTP ci-dessus sont en supposant que vous serait de travailler avec le navigateur/JS implémentations.

    Le protocole HTTP est parfaitement capable de la communication en duplex intégral; il est légal d'avoir un client de faire un POST avec des fragments de codage de transfert, et à un serveur de renvoyer une réponse avec un bloc de codage de corps. Cela permettrait de supprimer l'en-tête de frais généraux pour juste au moment de l'initialisation.

    Donc, si vous êtes à la recherche pour est full-duplex, contrôle à la fois le client et le serveur, et ne sont pas intéressées par les framing/caractéristiques des websockets, alors je dirais que HTTP est une approche plus simple avec un temps de latence inférieur/CPU (bien que le temps de latence serait vraiment ne diffèrent en microsecondes ou moins, soit).

    InformationsquelleAutor parity3