Quelques bonnes réponses d'autres qui couvrent beaucoup de terrain. Voici un petit plus.
Le seul avantage des WebSockets par rapport aux plugins tels que Java Applets, Flash ou Silverlight est que les WebSockets sont nativement intégrés aux navigateurs et ne reposent pas sur des plugins.
Si vous voulez dire par là que vous pouvez utiliser des applets Java, Flash ou Silverlight pour établir une connexion socket, alors oui, c'est possible. Cependant, vous ne voyez pas cela déployé trop souvent dans le monde réel en raison des restrictions.
Par exemple, les intermédiaires peuvent arrêter ce trafic et le font. Le standard WebSocket a été conçu pour être compatible avec l'infrastructure HTTP existante et est donc beaucoup moins susceptible d'être perturbé par des intermédiaires tels que les pare-feu et les proxies.
De plus, WebSocket peut utiliser les ports 80 et 443 sans nécessiter de ports dédiés, encore une fois grâce à la conception du protocole pour être aussi compatible que possible avec l'infrastructure HTTP existante.
Ces alternatives de socket (Java, Flash et Silverlight) sont difficiles à utiliser en toute sécurité dans une architecture cross-origin. Ainsi, les gens qui tentent souvent de les utiliser d'origine croisée toléreront les insécurités plutôt que de s'efforcer de le faire en toute sécurité.
Ils peuvent également exiger l'ouverture de ports "non standard" supplémentaires (ce que les administrateurs répugnent à faire) ou des fichiers de stratégie qui doivent être gérés.
En bref, l'utilisation de Java, Flash ou Silverlight pour la connectivité de socket est suffisamment problématique pour que vous ne la voyiez pas trop souvent déployée dans des architectures sérieuses. Flash et Java ont cette capacité depuis probablement au moins 10 ans, et pourtant ce n'est pas répandu.
Le standard WebSocket a pu commencer avec une nouvelle approche, en gardant ces restrictions à l'esprit et, espérons-le, en ayant tiré des leçons.
Certaines implémentations WebSocket utilisent Flash (ou éventuellement Silverlight et / ou Java) comme solution de secours lorsque la connectivité WebSocket ne peut pas être établie (par exemple lors de l'exécution dans un ancien navigateur ou lorsqu'un intermédiaire interfère).
Bien qu'une sorte de stratégie de repli pour ces situations soit intelligente, voire nécessaire, la plupart de ceux qui utilisent Flash et al souffriront des inconvénients décrits ci-dessus. Il n'est pas nécessaire qu'il en soit ainsi - il existe des solutions de contournement pour obtenir des connexions sécurisées compatibles avec les origines croisées à l'aide de Flash, Silverlight, etc. - mais la plupart des implémentations ne le feront pas car ce n'est pas facile.
Par exemple, si vous comptez sur WebSocket pour une connexion cross-origin, cela fonctionnera correctement. Mais si vous exécutez ensuite dans un ancien navigateur ou un pare-feu / proxy interféré et comptez sur Flash, par exemple, comme solution de secours, vous aurez du mal à faire la même connexion cross-origin. À moins que vous ne vous souciez pas de la sécurité, bien sûr.
Cela signifie qu'il est difficile d'avoir une architecture unifiée unique qui fonctionne pour les connexions natives et non natives, à moins que vous ne soyez prêt à faire pas mal de travail ou à utiliser un cadre qui l'a bien fait. Dans une architecture idéale, vous ne remarqueriez pas si les connexions étaient natives ou non; vos paramètres de sécurité fonctionneraient dans les deux cas; vos paramètres de mise en cluster fonctionneraient toujours; votre planification de la capacité tiendrait toujours; etc.
Le seul avantage de WebSockets par rapport au streaming http est que vous n'avez pas à faire un effort pour «comprendre» et analyser les données reçues.
Ce n'est pas aussi simple que d'ouvrir un flux HTTP et de rester assis pendant que vos données circulent pendant des minutes, des heures ou plus. Différents clients se comportent différemment et vous devez gérer cela. Par exemple, certains clients mettront en mémoire tampon les données et ne les publieront pas dans l'application tant qu'un certain seuil n'est pas atteint. Pire encore, certains ne transmettront pas les données à l'application tant que la connexion ne sera pas fermée.
Ainsi, si vous envoyez plusieurs messages au client, il est possible que l'application cliente ne reçoive pas les données tant que 50 messages de données n'ont pas été reçus, par exemple. Ce n'est pas trop en temps réel.
Bien que le streaming HTTP puisse être une alternative viable lorsque WebSocket n'est pas disponible, ce n'est pas une panacée. Il faut une bonne compréhension pour travailler de manière robuste dans les badlands du Web dans des conditions réelles.
Y a-t-il d'autres différences importantes qui me manquent?
Il y a une autre chose que personne n'a encore mentionnée, alors je vais en parler.
Le protocole WebSocket a été conçu pour être une couche de transport pour les protocoles de niveau supérieur. Bien que vous puissiez envoyer des messages JSON ou quoi que ce soit directement via une connexion WebSocket, il peut également transporter des protocoles standard ou personnalisés.
Par exemple, vous pouvez faire AMQP ou XMPP sur WebSocket, comme les gens l'ont déjà fait. Ainsi, un client peut recevoir des messages d'un courtier AMQP comme s'il était connecté directement au courtier lui-même (et dans certains cas, c'est le cas).
Ou si vous avez un serveur existant avec un protocole personnalisé, vous pouvez le transporter via WebSocket, étendant ainsi ce serveur principal au Web. Souvent, une application existante qui a été verrouillée dans l'entreprise peut élargir sa portée à l'aide de WebSocket, sans avoir à modifier l'infrastructure principale.
(Naturellement, vous voudriez pouvoir faire tout cela en toute sécurité, alors vérifiez auprès du fournisseur ou du fournisseur WebSocket.)
Certaines personnes ont qualifié WebSocket de TCP pour le Web. Parce que tout comme TCP transporte des protocoles de niveau supérieur, WebSocket fait de même, mais d'une manière compatible avec l'infrastructure Web.
Ainsi, bien que l'envoi de messages JSON (ou autre) directement sur WebSocket soit toujours possible, il faut également considérer les protocoles existants. Parce que pour beaucoup de choses que vous voulez faire, il y a probablement un protocole qui a déjà été pensé pour le faire.
Je suis désolé si je pose à nouveau ou combine plusieurs des questions déjà sur SO en une seule question, mais je veux juste donner un sens parfait à toutes les informations disponibles sur SO et sur le Web concernant ces concepts.
C'était une excellente question, et les réponses ont toutes été très instructives!