Hay muchos blogs y debates sobre websocket y HTTP, y muchos desarrolladores y sitios recomiendan firmemente los websockets, pero aún no entiendo por qué.
por ejemplo (argumentos de los amantes de websocket):
HTML5 Web Sockets representa la próxima evolución de las comunicaciones web: un canal de comunicaciones bidireccional full-duplex que opera a través de un único socket en la Web. ( http://www.websocket.org/quantum.html )
HTTP admite la transmisión: solicite la transmisión del cuerpo (lo está usando mientras carga archivos grandes) y responda la transmisión del cuerpo.
Durante la conexión con WebSocket, el cliente y el servidor intercambian datos por trama, que es de 2 bytes cada uno, en comparación con los 8 kilobytes del encabezado http cuando realiza un sondeo continuo.
¿Por qué esos 2 bytes no incluyen tcp y bajo los gastos generales de los protocolos tcp?
GET /about.html HTTP/1.1
Host: example.orgEste es un encabezado http ~ 48 bytes.
codificación fragmentada http - https://en.wikipedia.org/wiki/Chunked_transfer_encoding :
23
This is the data in the first chunk
1A
and this is the second one
3
con
8
sequence
0- Por lo tanto, la sobrecarga por cada porción no es grande.
Además, ambos protocolos funcionan sobre TCP, por lo que todos los problemas de TCP con conexiones de larga duración siguen ahí.
Preguntas:
- ¿Por qué es mejor el protocolo websockets?
- ¿Por qué se implementó en lugar de actualizar el protocolo http?
Respuestas:
1) ¿Por qué es mejor el protocolo WebSockets?
WebSockets es mejor para situaciones que implican comunicación de baja latencia, especialmente para baja latencia para mensajes de cliente a servidor. Para los datos de servidor a cliente, puede obtener una latencia bastante baja utilizando conexiones de larga duración y transferencia fragmentada. Sin embargo, esto no ayuda con la latencia de cliente a servidor, lo que requiere que se establezca una nueva conexión para cada mensaje de cliente a servidor.
Su protocolo de enlace HTTP de 48 bytes no es realista para las conexiones del navegador HTTP del mundo real, donde a menudo se envían varios kilobytes de datos como parte de la solicitud (en ambas direcciones), incluidos muchos encabezados y datos de cookies. Aquí hay un ejemplo de una solicitud / respuesta para usar Chrome:
Ejemplo de solicitud (2800 bytes incluyendo datos de cookies, 490 bytes sin datos de cookies):
Respuesta de ejemplo (355 bytes):
Tanto HTTP como WebSockets tienen enlaces de conexión inicial de tamaño equivalente, pero con una conexión de WebSocket, el enlace inicial se realiza una vez y luego los mensajes pequeños solo tienen 6 bytes de sobrecarga (2 para el encabezado y 4 para el valor de máscara). La sobrecarga de latencia no se debe tanto al tamaño de los encabezados, sino a la lógica de analizar / manejar / almacenar esos encabezados. Además, la latencia de configuración de la conexión TCP es probablemente un factor mayor que el tamaño o el tiempo de procesamiento de cada solicitud.
2) ¿Por qué se implementó en lugar de actualizar el protocolo HTTP?
Hay esfuerzos para rediseñar el protocolo HTTP para lograr un mejor rendimiento y una menor latencia, como SPDY , HTTP 2.0 y QUIC . Esto mejorará la situación para las solicitudes HTTP normales, pero es probable que WebSockets y / o WebRTC DataChannel sigan teniendo una latencia menor para la transferencia de datos de cliente a servidor que el protocolo HTTP (o se utilizará en un modo que se parece mucho a WebSockets de todos modos).
Actualización :
Aquí hay un marco para pensar en protocolos web:
text/event-streamtipo MIME. La API del navegador (que es bastante similar a la API de WebSocket) se denomina API EventSource.referencias :
fuente
Parece suponer que WebSocket es un reemplazo para HTTP. No lo es. Es una extensión.
El principal caso de uso de WebSockets son las aplicaciones Javascript que se ejecutan en el navegador web y reciben datos en tiempo real de un servidor. Los juegos son un buen ejemplo.
Antes de WebSockets, el único método para que las aplicaciones Javascript interactuaran con un servidor era a través
XmlHttpRequest. Pero estos tienen una gran desventaja: el servidor no puede enviar datos a menos que el cliente lo haya solicitado explícitamente.Pero la nueva característica de WebSocket permite que el servidor envíe datos cuando lo desee. Esto permite implementar juegos basados en navegador con una latencia mucho más baja y sin tener que usar hacks desagradables como AJAX long-polling o plugins de navegador.
Entonces, ¿por qué no usar HTTP normal con solicitudes y respuestas transmitidas?
En un comentario a otra respuesta, sugirió simplemente transmitir la solicitud del cliente y el cuerpo de respuesta de forma asincrónica.
De hecho, WebSockets son básicamente eso. Al principio, un intento de abrir una conexión WebSocket desde el cliente parece una solicitud HTTP, pero una directiva especial en el encabezado (Actualización: websocket) le dice al servidor que comience a comunicarse en este modo asíncrono. Los primeros borradores del protocolo WebSocket no fueron mucho más que eso y un poco de apretón de manos para garantizar que el servidor realmente entienda que el cliente quiere comunicarse de forma asincrónica. Pero luego se dio cuenta de que los servidores proxy se confundirían con eso, porque están acostumbrados al modelo habitual de solicitud / respuesta de HTTP. Se descubrió un posible escenario de ataque contra servidores proxy. Para evitar esto, era necesario hacer que el tráfico de WebSocket se viera diferente a cualquier tráfico HTTP normal. Por eso se introdujeron las claves de enmascaramiento enLa versión final del protocolo .
fuente
Una API REST normal usa el HTTP como el protocolo subyacente para la comunicación, que sigue el paradigma de solicitud y respuesta, lo que significa que la comunicación implica que el cliente solicita algunos datos o recursos de un servidor y el servidor responde a ese cliente. Sin embargo, HTTP es un protocolo sin estado, por lo que cada ciclo de solicitud-respuesta terminará teniendo que repetir la información de encabezado y metadatos. Esto incurre en latencia adicional en caso de ciclos de solicitud-respuesta repetidos con frecuencia.
Con WebSockets, aunque la comunicación todavía comienza como un protocolo de enlace HTTP inicial, se trata de actualizaciones adicionales para seguir el protocolo de WebSockets (es decir, si tanto el servidor como el cliente cumplen con el protocolo, ya que no todas las entidades admiten el protocolo de WebSockets).
Ahora con WebSockets, es posible establecer una conexión dúplex completa y persistente entre el cliente y un servidor. Esto significa que, a diferencia de una solicitud y una respuesta, la conexión permanece abierta mientras la aplicación se está ejecutando (es decir, es persistente), y dado que es dúplex completo, es posible la comunicación simultánea bidireccional, es decir, ahora el servidor es capaz de iniciar una comunicación y "enviar" algunos datos al cliente cuando haya nuevos datos (que le interesen al cliente) disponibles.
El protocolo WebSockets tiene estado y le permite implementar el patrón de mensajería Publish-Subscribe (o Pub / Sub), que es el concepto principal utilizado en las tecnologías en tiempo real donde puede obtener nuevas actualizaciones en forma de envío de servidor sin el El cliente tiene que solicitar (actualizar la página) repetidamente. Ejemplos de tales aplicaciones son el seguimiento de la ubicación del automóvil Uber, las notificaciones automáticas, la actualización de los precios del mercado de valores en tiempo real, chat, juegos multijugador, herramientas de colaboración en línea en vivo, etc.
Puede consultar un artículo de inmersión profunda en Websockets que explica la historia de este protocolo, cómo surgió, para qué se utiliza y cómo puede implementarlo usted mismo.
Aquí hay un video de una presentación que hice sobre WebSockets y cómo son diferentes de usar las API REST regulares: estandarización y aprovechamiento del aumento exponencial en la transmisión de datos
fuente
Para el TL; DR, aquí hay 2 centavos y una versión más simple para sus preguntas:
WebSockets proporciona estos beneficios sobre HTTP:
WebSocket y el protocolo HTTP han sido diseñados para resolver diferentes problemas, IE WebSocket fue diseñado para mejorar la comunicación bidireccional, mientras que HTTP fue diseñado para ser sin estado, distribuido utilizando un modelo de solicitud / respuesta. Aparte de compartir los puertos por motivos heredados (penetración de firewall / proxy), no hay mucho en común para combinarlos en un solo protocolo.
fuente
¿Por qué es mejor el protocolo websockets?
No creo que podamos compararlos lado a lado como quién es mejor. Esa no será una comparación justa simplemente porque están resolviendo dos problemas diferentes . Sus requisitos son diferentes. Será como comparar manzanas con naranjas. Ellos son diferentes.
HTTP es un protocolo de solicitud-respuesta. El cliente (navegador) quiere algo, el servidor se lo da. Es decir. Si el cliente de datos quiere es grande, el servidor puede enviar datos de transmisión para anular los problemas de búfer no deseados. Aquí, el requisito o problema principal es cómo realizar la solicitud de los clientes y cómo responder a los recursos (texto híbrido) que solicitan. Ahí es donde brilla HTTP.
WebSocket no es un protocolo de solicitud-respuesta donde solo el cliente puede solicitar. Es un socket (muy similar al socket TCP). Es decir, una vez que la conexión está abierta, cualquier lado puede enviar datos hasta que la conexión TCP esté cerrada. Es como un enchufe normal. La única diferencia con el socket TCP es que websocket se puede usar en la web. En la web, tenemos muchas restricciones para un socket normal. La mayoría de los cortafuegos bloquearán otros puertos que no sean 80 y 433 que utilizó HTTP. Los proxies e intermediarios también serán problemáticos, por lo que para que el protocolo sea más fácil de implementar en infraestructuras existentes, Websocket utiliza el protocolo de enlace HTTP para actualizar. Eso significa que cuando se abra la primera conexión, el cliente envió una solicitud HTTP para decirle al servidor que dice "Esa no es una solicitud HTTP, actualice al protocolo websocket".
Una vez que el servidor comprende la solicitud y se actualiza al protocolo websocket, ya no se aplica nada del protocolo HTTP.
Entonces mi respuesta es que ninguno es mejor que el otro. Son completamente diferentes
¿Por qué se implementó en lugar de actualizar el protocolo http?
Bueno, también podemos hacer todo bajo el nombre llamado HTTP . ¿Pero lo haremos? Si son dos cosas diferentes, preferiré dos nombres diferentes. También lo hacen Hickson y Michael Carter .
fuente
Las otras respuestas no parecen tocar un aspecto clave aquí, y es que no mencionas la necesidad de admitir un navegador web como cliente. La mayoría de las limitaciones de HTTP simple anteriores suponen que estaría trabajando con implementaciones de navegador / JS.
El protocolo HTTP es totalmente capaz de comunicación full-duplex; Es legal que un cliente realice una POST con transferencia de codificación fragmentada y que un servidor devuelva una respuesta con un cuerpo de codificación fragmentada. Esto eliminaría la sobrecarga del encabezado solo en el momento de inicio.
Entonces, si todo lo que está buscando es full-duplex, controla tanto el cliente como el servidor, y no está interesado en el encuadre / características adicionales de websockets, entonces diría que HTTP es un enfoque más simple con menor latencia / CPU (aunque la latencia en realidad solo diferiría en microsegundos o menos para cualquiera).
fuente