Permettez-moi tout d'abord d'aborder la préparation des WebSockets :
La mise en œuvre de WebSockets de la Hixie-76 sont livrés et activés par défaut dans Chrome, Safari et iOS (iPhone et iPad). Le protocole Hixie-76 est également livré mais désactivé par défaut dans Firefox 4 et Opera 11. Le site web-socket-js est un shim/polyfill Flash qui ajoute le support WebSocket (Hixie-76) à n'importe quel navigateur avec Flash.
En d'autres termes, les WebSockets sont disponibles pour presque tous les navigateurs dans la nature.
Si Opera et Mozilla ont choisi de désactiver le protocole par défaut, c'est parce qu'ils craignent théoriquement que certains proxys/intermédiaires HTTP défectueux puissent être attaqués ou empoisonnés en utilisant les versions Hixie du protocole. La même inquiétude s'applique à Flash, mais Mozilla et Opera se sentent davantage responsables du code qu'ils fournissent. Les versions HyBi du protocole (le protocole a été transféré au groupe de travail HyBi de l'IETF) répondent à ce problème de sécurité.
Mozilla, Opera, Google et Microsoft travaillent tous sur des implémentations du protocole HyBi (bien que Microsoft maintienne le sien en tant qu'implémentation du protocole HyBi). téléchargement séparé pour l'instant). Il existe un branche de web-socket-js avec le soutien de HyBi-07.
Mise à jour : En février 2013, la dernière Spécification HyBi/IETF RFC 6455 est pris en charge par Chrome 14, Firefox 7, IE10, Opera 12.1, Safari 6.0 et par le système de gestion de l'information de la Commission européenne. web-socket-js Flash shim/polyfill. Sur les appareils mobiles, la norme IETF6455 est prise en charge par Safari sur iOS 6.0, Opera Mobile 12.1, Chrome 14 pour Android, Firefox 7 pour Android et Blackberry 7. Le navigateur Android d'origine par défaut ne prend pas en charge WebSocket.
Les serveurs WebSocket sont faciles à mettre en œuvre. Il existe de nombreuses implémentations autonomes et plugins, dont la plupart supportent les deux versions du protocole Hixie-76 et HyBi :
BOSH vs WebSockets :
-
latence : Bien que le projet de document BOSH revendique une très faible latence, il sera difficile pour BOSH de concurrencer les WebSockets. À moins de disposer de conditions idéales où HTTP/1.1 est pris en charge par tous les intermédiaires et par le serveur cible, le client BOSH et le gestionnaire de connexion devront rétablir les connexions après chaque paquet et chaque dépassement de délai de requête. Cela augmentera considérablement la latence et la gigue de la latence. Une faible gigue est souvent plus importante pour les applications en temps réel que la latence moyenne. Les connexions WebSocket seront très similaires en termes de latence et de gigue aux connexions TCP brutes. Et même dans des conditions idéales, la latence client-serveur de la communication BOSH (et donc l'aller-retour) sera toujours supérieure à celle des WebSockets : BOSH doit toujours respecter la sémantique demande-réponse HTTP. Le streaming HTTP permet des réponses multiples par demande (en divisant une réponse "unique" en plusieurs parties) mais pas l'inverse (chaque message du client est une nouvelle demande).
-
surcharge des petits paquets : Dans les WebSockets, il y a deux octets de surcharge de trame pour les petits messages. Dans BOSH, chaque message a des en-têtes de demande et de réponse HTTP (facilement 180+ octets pour chaque aller-retour). De plus, chaque message est enveloppé dans du XML (censé être optionnel mais la spécification ne définit pas comment) avec plusieurs attributs liés à la session.
-
complexité BOSH : si BOSH utilise les mécanismes existants dans le navigateur, il nécessite une bibliothèque JavaScript modérément complexe pour mettre en œuvre la sémantique BOSH. Cette gestion en JavaScript augmentera également la latence et la gigue par rapport à une mise en œuvre native/navigateur (ou même Flash).
-
traction : BOSH a commencé sa vie comme un moyen de rendre XMPP plus efficace. Il s'est développé à partir de la communauté XMPP et d'après ce que je peux dire, il a eu très peu d'intérêt en dehors de cette communauté. Les projets de documents pour BOSH et XMPP sont séparés, mais il semble y avoir très peu d'utilisation réelle de BOSH sans XMPP.
Mise à jour :
Je viens de trouver une vidéo où Ian Fette discute de la les avantages des WebSockets par rapport à l'API Channel, qui est similaire à BOSH (à 44:00)
