Posteriormente a mirar en diversos repositorios y sitios de internet al concluir dimos con la respuesta que te enseñaremos ahora.
Solución:
El objetivo de una conexión websocket es que nunca tiene que hacer ping a la aplicación para ver los cambios. En cambio, el cliente solo se conecta una vez y luego el servidor puede enviar directamente los cambios del cliente siempre que estén disponibles. El cliente nunca tiene que preguntar. El servidor solo envía datos cuando están disponibles.
Para cualquier tipo de datos iniciados por el servidor, esto es mucho más eficiente con el ancho de banda que el sondeo http. Además de brindarle resultados mucho más oportunos (los resultados se entregan de inmediato en lugar de que el cliente los descubra solo en el siguiente intervalo de sondeo).
Para el uso puro del ancho de banda, los detalles dependerán de las circunstancias exactas. Una solicitud de sondeo http debe configurar una conexión TCP y confirmar esa conexión (incluso más datos si se trata de una conexión SSL), luego debe enviar la solicitud http, incluidas las cookies relevantes que pertenecen a ese host y los encabezados relevantes y el OBTENER URL. Luego, el servidor tiene que enviar una respuesta. Y, la mayoría de las veces, toda esta sobrecarga de sondeo será un ancho de banda completamente desperdiciado porque no hay nada nuevo que informar.
Un webSocket comienza con una solicitud http simple, luego actualiza el protocolo al protocolo webSocket. La conexión webSocket en sí misma no necesita enviar ningún dato hasta que el servidor tenga algo que enviar al cliente, en cuyo caso el servidor simplemente envía el paquete. Enviar los datos en sí también tiene muchos menos gastos generales. No hay cookies, ni encabezados, etc… solo los datos. Incluso si usa algunos keep-alives en el webSocket, esa cantidad de datos es increíblemente pequeña en comparación con la sobrecarga de una solicitud HTTP.
Por lo tanto, cuánto ahorraría exactamente en ancho de banda depende de los detalles de las circunstancias. Si se necesitan 50 solicitudes de sondeo antes de encontrar datos útiles, entonces cada una de esas solicitudes http se desperdicia por completo en comparación con el escenario webSocket. La diferencia en el ancho de banda podría ser enorme.
Usted preguntó acerca de una aplicación que solo necesita controles periódicos. Tan pronto como tenga una verificación periódica que resulte en que no se recuperen datos, eso es ancho de banda desperdiciado. Esa es toda la idea de un webSocket. No consume ancho de banda (o casi no consume ancho de banda) cuando no hay datos para enviar.
Creo que @jfriend00 respondió la pregunta muy claramente. Sin embargo, quiero añadir un pensamiento.
Al presentar el peor de los casos (e improbable) para Websockets frente a HTTP, vería claramente que una conexión Websocket siempre tendrá una ventaja con respecto al ancho de banda (y probablemente el rendimiento general).
Este es el peor de los casos para Websockets v/s HTTP:
-
su código usa conexiones Websocket exactamente de la misma manera que usa las solicitudes HTTP, para el sondeo.
(que no es algo que harías, lo sé, pero es el peor de los casos).
-
Cada evento de sondeo se responde positivamente, lo que significa que ninguna solicitud HTTP se realizó en vano.
Esta es la peor situación posible para Websockets, que están diseñados para enviar datos en lugar de sondear… incluso en esta situación, Websockets le ahorrará ancho de banda y ciclos de CPU.
En serio, incluso ignorando la consulta DNS (realizada por el cliente, por lo que es posible que no le importe) y el protocolo de enlace TCP/IP (que es costoso tanto para el cliente como para el servidor), una conexión Websocket es aún más eficiente y rentable. eficaz.
Lo explicaré:
Cada solicitud HTTP incluye una gran cantidad de datos, como cookies y otros encabezados. En muchos casos, cada solicitud HTTP también está sujeta a la autenticación del cliente… rara vez se entregan datos a nadie.
Esto significa que las conexiones HTTP pasan todos estos datos (y posiblemente realicen la autenticación del cliente) una vez por solicitud.[Stateless]
Sin embargo, las conexiones de Websocket tienen estado. Los datos se envían una sola vez (en lugar de cada vez que se realiza una solicitud). La autenticación del cliente ocurre solo durante la negociación de la conexión Websocket.
Esto significa que las conexiones de Websocket pasan los mismos datos (y posiblemente realicen la autenticación del cliente) una vez por conexión (una vez para todas las encuestas).
Entonces, incluso en el peor de los casos, donde el sondeo siempre es positivo y los Websockets se utilizan para sondear en lugar de enviar datos, los Websockets seguirán ahorrando ancho de banda y otros recursos a su servidor (es decir, tiempo de CPU).
Creo que la respuesta a su pregunta, en pocas palabras, es “nunca”. Los websockets nunca son menos eficientes que el sondeo.