Websockets se diseñaron para una comunicación bidireccional rápida en el navegador. Asumiendo que tiene control sobre el servidor y un cliente nativo (digamos una aplicación iOS o Mac), ¿hay buenas razones o situaciones para comunicarse a través de un websocket en lugar de usar una biblioteca HTTP?¿Hay alguna buena razón para usar Websockets fuera del navegador?
voy a responder un par de preguntas diferentes que se espera termina respondiendo a la pregunta:
¿Hay una razón para utilizar WebSockets de un cliente en lugar de HTTP? Sí.
WebSockets es bidireccional, dúplex completo, de baja latencia y baja sobrecarga en comparación con HTTP.
Parte de la menor latencia y sobrecarga en comparación con HTTP/AJAX/COMET es que no tiene que volver a establecer la conexión para cada solicitud.
¿Hay alguna razón para usar WebSockets de un cliente en lugar de sockets sin formato? Sí.
El handshake inicial de WebSockets es compatible con el servidor HTTP (y tiene algunos mecanismos de seguridad de intercambio de origen y hash). Permite que los servidores web se actualicen fácilmente para admitir el redireccionamiento o el proxy para las conexiones de WebSockets a la aplicación real del servidor WebSockets.
Otra ventaja de WebSockets es que es un protocolo enmarcado que permite a la aplicación enfocarse en una funcionalidad útil sin tener que lidiar con su propio encuadre y almacenamiento en búfer.
Es bastante fácil agregar soporte WebSockets a los servidores de socket TCP existentes o proxy a través de algo como wsproxy. Descargo de responsabilidad: hice wsproxy.
Desde el punto de vista del servidor WebSockets es una gran ventaja, ya que se puede acceder a través de clientes independientes o mediante navegadores. Esto significa que habrá más y más servicios que actualmente están basados en socket TCP y que estarán expuestos a través de WebSockets. Por lo tanto, agregar compatibilidad con WebSockets a un cliente ahora dará sus frutos en el futuro.