Quelle est la différence entre WebSocket et la communication simple?

les sockets web et les sockets réguliers ne sont pas la même chose. Un webSocket fonctionne sur une socket régulière, mais exécute son propre schéma de connexion, le schéma de sécurité et le protocole d'encadrement sur le dessus de la socket régulière et les deux points terminaux doivent suivre ces étapes supplémentaires pour une connexion à même d'être faite. Vous pouvez voir le protocole webSocket ici: http://tools.ietf.org/html/rfc6455

la plus grande différence est que toutes les connexions webSocket commencent par un HTTP requête du client au serveur. Le client envoie une requête HTTP vers le même serveur et le même port qui est ouvert pour une communication web normale (par défaut du port 80, mais si le serveur web tourne sur un port différent, alors la communication webSocket le suivra sur cet autre port). Le client définit quelques en-têtes personnalisés, dont le plus important est un en-tête qui indique que le client souhaite "mettre à niveau" vers le protocole webSocket. En outre, les deux parties échangent des clés de sécurité. Si le serveur accepte la "mise à niveau", alors le client et le serveur changent le protocole parlé sur la socket originale de HTTP à webSocket et maintenant le protocole d'encadrement webSocket est utilisé.

de plus, la requête HTTP initiale peut avoir un chemin de requête pour indiquer une "sous-destination" pour la requête webSocket. Cela permet à toutes sortes de requêtes webSocket différentes d'être initialisées avec le même serveur et le même port.

Il y a aussi une option spécificateur de sous-protocole avec le Sec-WebSocket-Protocol en-tête qui permet à request de mieux identifier les sous-protocoles (un sous-protocole commun pourrait être "chat") afin que les deux parties puissent s'entendre sur un ensemble spécifique d'identificateurs de messages et leur signification correspondante qui pourrait être utilisée.

le fait qu'une connexion webSocket commence par une connexion HTTP est d'une importance critique car si vous pouvez atteindre le serveur web pour une communication web normale, alors vous pouvez l'atteindre pour une requête webSocket sans aucune infrastructure de réseau n'importe où entre le client et le serveur devant ouvrir de nouveaux trous dans le pare-feu ou ouvrir de nouveaux ports ou quelque chose comme ça.

vous pouvez voir un excellent résumé de la façon dont une connexion webSocket est commencée ici: https://developer.mozilla.org/en-US/docs/WebSockets/Writing_WebSocket_servers.

le protocole webSocket définit également les paquets ping et pong qui aident les deux parties à savoir si un webSocket inactif est toujours connecté.

On peut seulement supposer que la raison pour laquelle il a fallu un certain temps pour obtenir webSockets dans tous les navigateurs communs est la même raison que beaucoup de capacités utiles a pris un certain temps. Tout d'abord, un groupe de gens motivés doivent identifier et s'entendre sur un besoin, puis ce groupe doit prendre la tête dans l'élaboration d'une approche pour résoudre le problème, puis l'idée est lancé pendant un certain temps soit rassembler le soutien et traiter les objections ou en concurrence avec d'autres façons de résoudre un tel problème, puis il semble avoir assez d'élan pour être réellement quelque chose qui pourrait devenir une norme, puis quelqu'un décide de faire un test/essai de mise en œuvre dans un navigateur et une mise en œuvre de serveur correspondante (parfois cette étape vient beaucoup plus tôt). Puis, s'il est encore en train de trouver l'élan et semble être sur une voie de normes, d'autres fabricants de navigateur va ramasser l'idée et de commencer à leur mise en œuvre. Une fois que tous les fabricants de navigateur ont une mise en œuvre de travail décent (Généralement, il ya des séries d'amélioration des normes comme différentes implémentations trouvent des trous dans la spécification ou lorsque les développeurs identifient des problèmes ou des capacités manquantes ou des problèmes de sécurité se posent). Puis, il arrive au point où au moins deux navigateurs principaux ont la fonctionnalité dans leurs dernières versions, la norme est considérée comme relativement solide et les consommateurs commencent à adopter ces navigateurs et certains sites commencent à améliorer leur expérience utilisateur en utilisant la nouvelle capacité. À ce moment-là, les navigateurs arrière commencent à sentir la pression pour la mettre en œuvre. Puis, parfois des années plus tard, tous les navigateurs principaux ont la fonctionnalité et ces navigateurs ont suffisamment d'adoption globale par l'utilisateur que les sites web peuvent compter sur la fonctionnalité (sans avoir à avoir un deuxième design de secours majeur qui fonctionne quand un navigateur ne supporte pas la fonctionnalité). Tout ce processus peut prendre de nombreuses années.

voici un exemple de requête HTTP initiale pour lancer une connexion webSocket:

GET /chat HTTP/1.1
Host: example.com:8000
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

Et le serveur réponse:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Et, d'un bloc de données exemple:

0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len |    Extended payload length    |
|I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
|N|V|V|V|       |S|             |   (if payload len==126/127)   |
| |1|2|3|       |K|             |                               |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
|     Extended payload length continued, if payload len == 127  |
+ - - - - - - - - - - - - - - - +-------------------------------+
|                               |Masking-key, if MASK set to 1  |
+-------------------------------+-------------------------------+
| Masking-key (continued)       |          Payload Data         |
+-------------------------------- - - - - - - - - - - - - - - - +
:                     Payload Data continued ...                :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|                     Payload Data continued ...                |
+---------------------------------------------------------------+