http - ¿Qué casos de uso específicos requieren BOSH sobre WebSockets y long-polling?

comet (1)

BOSH es ...

un protocolo de transporte que emula la semántica de una conexión TCP bidireccional de larga duración entre dos entidades (como un cliente y un servidor) mediante el uso eficiente de múltiples pares de solicitudes / respuestas sincrónicas sin requerir el uso de sondeos frecuentes o respuestas fragmentadas.

Esto suena como WebSockets y HTTP long-polling, excepto que usa dos conexiones HTTP abiertas en lugar de una y no extiende el protocolo HTTP.

¿Cuáles son las diferencias entre los dos protocolos, y qué caso de uso preferiría WebSockets sobre BOSH?

Primero déjame abordar la preparación de WebSockets :

La implementación de WebSockets del protocolo Hixie-76 se envía y se habilita de forma predeterminada en Chrome, Safari e iOS (iPhone y iPad). El protocolo Hixie-76 también se envía pero se desactiva de forma predeterminada en Firefox 4 y Opera 11. El proyecto web-socket-js es un Flash shim / polyfill que agrega compatibilidad con WebSocket (Hixie-76) a cualquier navegador con Flash.

En otras palabras, WebSockets está disponible para casi todos los navegadores en la naturaleza.

La razón por la cual Opera y Mozilla eligieron desactivar el protocolo de manera predeterminada es debido a la preocupación teórica de que podrían existir algunos intermediarios / intermediarios HTTP que podrían ser atacados / envenenados usando las versiones Hixie del protocolo. La misma preocupación se aplica a Flash pero Mozilla y Opera sintieron un mayor deber de responsabilidad por el código que envían. Las versiones HyBi del protocolo (el protocolo se movió al grupo de trabajo IETF HyBi) abordan el problema de seguridad.

Mozilla, Opera, Google y Microsoft están trabajando en las implementaciones del protocolo HyBi (aunque Microsoft las mantiene como una descarga separada por ahora). Hay una rama de web-socket-js con soporte HyBi-07.

Actualización : a partir de febrero de 2013, la última especificación HyBi / IETF RFC 6455 es compatible con Chrome 14, Firefox 7, IE10, Opera 12.1, Safari 6.0 y Flash shim / polyfill de web-socket-js . En dispositivos móviles IETF6455 es compatible con Safari en iOS 6.0, Opera Mobile 12.1, Chrome 14 para Android, Firefox 7 para Android y Blackberry 7. El navegador Android original no tiene soporte para WebSocket.

Los servidores WebSocket son fáciles de implementar. Existen numerosas implementaciones autónomas y de complemento, la mayoría de las cuales son compatibles con las versiones de protocolo Hixie-76 y HyBi:

BOSH vs WebSockets :

latencia : mientras que el borrador del documento BOSH dice tener muy baja latencia, será difícil para BOSH competir con WebSockets. A menos que tenga las condiciones ideales donde HTTP / 1.1 es compatible a través de todos los intermediarios y el servidor de destino, el cliente BOSH y el administrador de conexión necesitarán restablecer las conexiones después de cada paquete y cada solicitud de tiempo de espera. Esto aumentará significativamente la latencia y la latencia. La baja inestabilidad suele ser más importante para las aplicaciones en tiempo real que la latencia promedio. Las conexiones WebSocket serán muy similares en latencia y fluctuación a las conexiones TCP sin formato. E incluso en condiciones ideales, la latencia de cliente a servidor de la comunicación BOSH (y, por lo tanto, de ida y vuelta) siempre será más alta que WebSockets: BOSH aún tiene que cumplir con la semántica de solicitud-respuesta HTTP. La transmisión HTTP permite múltiples respuestas por solicitud (dividiendo una respuesta "única" en varias partes) pero no viceversa (cada mensaje del cliente es una nueva solicitud).
sobrecarga de paquete pequeño : en WebSockets hay dos bytes de sobrecarga de encuadre para mensajes pequeños. En BOSH, cada mensaje tiene encabezados de solicitud y respuesta HTTP (fácilmente más de 180 bytes para cada viaje de ida y vuelta). Además, cada mensaje está envuelto en XML (supuestamente opcional pero la especificación no define cómo) con varios atributos relacionados con la sesión.
complejidad : mientras BOSH usa mecanismos existentes en el navegador, requiere una biblioteca de JavaScript moderadamente compleja para implementar la semántica de BOSH. Administrar esto en Javascript también aumentará la latencia y la inestabilidad en comparación con una implementación nativa / de navegador (o incluso Flash).
Traction: BOSH comenzó su vida como una forma de hacer que XMPP sea más eficiente. Creció fuera de la comunidad XMPP y, de lo que puedo decir, ha recibido muy poca tracción fuera de esa comunidad. Los borradores de documentos para BOSH y XMPP están separados, pero parece que hay muy poco uso real de BOSH sin XMPP.

Actualización :

Acabo de encontrar un video donde Ian Fette analiza las ventajas de WebSockets sobre Channel API, que es similar a BOSH (a las 44:00)