Protocolo WebSockets vs HTTP

Hay muchos blogs y discusiones sobre websocket y HTTP, y muchos desarrolladores y sitios defienden enérgicamente websockets, pero todavía no puedo entender por qué.

por ejemplo (argumentos de amantes de websocket):

HTML5 Web Sockets representa la siguiente evolución de las comunicaciones web: un canal de comunicaciones bidireccional full-duplex que opera a través de un único socket a través de la Web. ( http://www.websocket.org/quantum.html )

HTTP admite transmisión: solicitud de transmisión de cuerpo (lo está utilizando mientras carga archivos de gran tamaño) y transmisión de cuerpo de respuesta.

Durante la conexión con WebSocket, el cliente y el servidor intercambian datos por cuadro, que son de 2 bytes cada uno, en comparación con 8 kilobytes de encabezado http cuando realiza un sondeo continuo.

¿Por qué esos 2 bytes no incluyen tcp y bajo la sobrecarga de protocolos tcp?

GET /about.html HTTP/1.1 Host: example.org 

Esto es ~ 48 bytes de encabezado http.

encoding por fragmentos HTTP – http://ru.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 fragmento no es grande.

Además, ambos protocolos funcionan con TCP, por lo que todos los problemas de TCP con conexiones de larga duración todavía están allí.

Pregunta:

  1. ¿Por qué es mejor el protocolo websockets?
  2. ¿Por qué se implementó en lugar de actualizar el protocolo http?

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 mediante conexiones de larga duración y transferencia fragmentada. Sin embargo, esto no ayuda con la latencia de cliente a servidor 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 hay varios kilobytes de datos enviados como parte de la solicitud (en ambas direcciones), incluidos muchos encabezados y datos de cookies. Aquí hay un ejemplo de una solicitud / respuesta al uso de Chrome:

Solicitud de ejemplo (2800 bytes incluyendo datos de cookies, 490 bytes sin datos de cookies):

 GET / HTTP/1.1 Host: www.cnn.com Connection: keep-alive Cache-Control: no-cache Pragma: no-cache Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.68 Safari/537.17 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: [[[2428 byte of cookie data]]] 

Ejemplo de respuesta (355 bytes):

 HTTP/1.1 200 OK Server: nginx Date: Wed, 13 Feb 2013 18:56:27 GMT Content-Type: text/html Transfer-Encoding: chunked Connection: keep-alive Set-Cookie: CG=US:TX:Arlington; path=/ Last-Modified: Wed, 13 Feb 2013 18:55:22 GMT Vary: Accept-Encoding Cache-Control: max-age=60, private Expires: Wed, 13 Feb 2013 18:56:54 GMT Content-Encoding: gzip 

Tanto HTTP como WebSockets tienen apretones iniciales de conexión de tamaño equivalente, pero con una conexión WebSocket, el saludo 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 es tanto del tamaño de los encabezados, sino de la lógica para analizar / manejar / almacenar esos encabezados. Además, la latencia de configuración de la conexión TCP es probablemente un factor más grande que el tamaño o el tiempo de procesamiento para 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 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 aún tengan una latencia menor para la transferencia de datos entre el cliente y el servidor que el protocolo HTTP (o se usará en un modo que se parece mucho a WebSockets de todos modos).

Actualización :

Aquí hay un marco para pensar acerca de los protocolos web:

  • TCP : nivel bajo, bidireccional, dúplex completo y capa de transporte garantizada. Sin soporte de navegador (excepto a través de plugin / Flash).
  • HTTP 1.0 : protocolo de transporte solicitud-respuesta en capas en TCP. El cliente realiza una solicitud completa, el servidor da una respuesta completa y luego se cierra la conexión. Los métodos de solicitud (GET, POST, HEAD) tienen un significado transaccional específico para los recursos en el servidor.
  • HTTP 1.1 : mantiene la naturaleza de solicitud y respuesta de HTTP 1.0, pero permite que la conexión permanezca abierta para múltiples solicitudes completas / respuestas completas (una respuesta por solicitud). Todavía tiene encabezados completos en la solicitud y la respuesta, pero la conexión se reutiliza y no se cierra. HTTP 1.1 también agregó algunos métodos de solicitud adicionales (OPCIONES, PUT, DELETE, TRACE, CONNECT) que también tienen significados transaccionales específicos. Sin embargo, como se señala en la introducción al borrador de la propuesta de HTTP 2.0, HTTP 1.1 pipelining no se implementa ampliamente, por lo que limita en gran medida la utilidad de HTTP 1.1 para resolver la latencia entre navegadores y servidores.
  • Encuesta larga : una especie de “hack” para HTTP (1.0 o 1.1) donde el servidor no responde de manera inmediata (o solo responde parcialmente con encabezados) a la solicitud del cliente. Después de una respuesta del servidor, el cliente envía inmediatamente una nueva solicitud (usando la misma conexión si sobre HTTP 1.1).
  • Transmisión HTTP : una variedad de técnicas (respuesta multipart / chunked) que permiten al servidor enviar más de una respuesta a una única solicitud del cliente. El W3C está estandarizando esto como Eventos enviados por el servidor usando un tipo MIME text/event-stream . La API de navegador (que es bastante similar a la API de WebSocket) se denomina API de EventSource.
  • Empuje de cometa / servidor : este es un término general que incluye tanto la transmisión larga como la transmisión HTTP. Las bibliotecas de Comet suelen admitir varias técnicas para tratar de maximizar el soporte entre navegadores y entre servidores.
  • WebSockets : un TCP integrado en la capa de transporte que utiliza un saludo de actualización amigable con HTTP. A diferencia de TCP, que es un transporte de transmisión, WebSockets es un transporte basado en mensajes: los mensajes se delimitan en el cable y se vuelven a ensamblar en su totalidad antes de la entrega a la aplicación. Las conexiones de WebSocket son bidireccionales, dúplex completo y de larga duración. Después de la solicitud / respuesta inicial de handshake, no hay semántica transaccional y hay muy poca carga por mensaje. El cliente y el servidor pueden enviar mensajes en cualquier momento y deben manejar la recepción de mensajes de forma asincrónica.
  • SPDY : una propuesta iniciada por Google para extender HTTP usando un protocolo wireline más eficiente pero manteniendo toda la semántica HTTP (solicitud / respuesta, cookies, encoding). SPDY presenta un nuevo formato de encuadre (con fotogtwigs con prefijo de longitud) y especifica una forma de aplicar capas a los pares de petición / respuesta HTTP en la nueva capa de encuadre. Los encabezados se pueden comprimir y se pueden enviar nuevos encabezados después de establecer la conexión. Existen implementaciones de SPDY en el mundo real en navegadores y servidores.
  • HTTP 2.0 : tiene objectives similares a SPDY: reduce la latencia y la sobrecarga de HTTP mientras preserva la semántica de HTTP. El borrador actual se deriva de SPDY y define un handshake de actualización y un dataframe que es muy similar al estándar de WebSocket para handshake y framing. Una propuesta alternativa de borrador HTTP 2.0 (httpbis-speed-mobility) realmente usa WebSockets para la capa de transporte y agrega la multiplexación SPDY y la asignación HTTP como una extensión WebSocket (las extensiones WebSocket se negocian durante el intercambio).
  • WebRTC / CU-WebRTC : propuestas para permitir la conectividad punto a punto entre los navegadores. Esto puede permitir una comunicación de latencia media y máxima más baja porque el transporte subyacente es SDP / datagtwig en lugar de TCP. Esto permite la entrega desordenada de paquetes / mensajes que evita el problema de TCP de picos de latencia causados ​​por paquetes caídos que retrasan la entrega de todos los paquetes subsiguientes (para garantizar la entrega ordenada).
  • QUIC : es un protocolo experimental dirigido a reducir la latencia web sobre la de TCP. En la superficie, QUIC es muy similar a TCP + TLS + SPDY implementado en UDP. QUIC proporciona multiplexación y control de flujo equivalente a HTTP / 2, seguridad equivalente a TLS, semántica de conexión, confiabilidad y control de congestión equivalente a TCP. Debido a que TCP se implementa en los kernels del sistema operativo y en el firmware de middlebox, realizar cambios significativos en TCP es casi imposible. Sin embargo, dado que QUIC se construye sobre UDP, no adolece de tales limitaciones. QUIC está diseñado y optimizado para la semántica HTTP / 2.

Referencias

  • HTTP :
    • Página de HTTP de Wikipedia
    • W3C Lista de borradores / protocolos relacionados con HTTP
    • Lista de IETF HTTP / 1.1 y HTTP / 2.0 Borradores
  • Evento enviado por el servidor :
    • Recomendación de candidatos enviados por el servidor W3C / Candidatos de EventSource
    • Eventos enviados por el servidor W3C / Borrador de EventSource
  • WebSockets :
    • Protocolo IETF RFC 6455 WebSockets
    • IETF RFC 6455 WebSocket Errata
  • SPDY :
    • IETF SPDY Draft
  • HTTP 2.0 :
    • IETF HTTP 2.0 httpbis-http2 Draft
    • IETF HTTP 2.0 httpbis-speed-mobility Borrador
    • Draft de IETF httpbis-network-friendly : una propuesta anterior relacionada con HTTP 2.0
  • WebRTC :
    • Borrador API W3C WebRTC
    • Lista de borradores de IETF WebRTC
    • Descripción general de IETF WebRTC
    • IETF WebRTC DataChannel Draft
    • Página de inicio de la propuesta de Microsoft CU-WebRTC
  • QUIC :
    • Proyecto QUIC Chrominum
    • IETF QUIC Draft

Parece asumir que WebSocket es un reemplazo para HTTP. No lo es. Es una extensión

El caso de uso principal de WebSockets son las aplicaciones de 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 de JavaScript interactúen con un servidor era a través de 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 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 feos como los sondeos largos de AJAX o los complementos del navegador.

Entonces, ¿por qué no usar HTTP normal con solicitudes y respuestas transmitidas por streaming?

En un comentario a otra respuesta, sugirió simplemente transmitir el cuerpo de solicitud y respuesta del cliente de forma asincrónica.

De hecho, los WebSockets son básicamente eso. Un bash de abrir una conexión WebSocket desde el cliente parece una solicitud HTTP al principio, pero una directiva especial en el encabezado (Actualizar: websocket) le dice al servidor que comience a comunicarse en este modo asincrónico. Los primeros borradores del protocolo WebSocket no fueron mucho más que eso y algunos apretones de manos para garantizar que el servidor entienda realmente que el cliente desea comunicarse de forma asincrónica. Pero luego se descubrió que los servidores proxy estarían confundidos por eso, porque están acostumbrados al modelo habitual de solicitud / respuesta de HTTP. Se descubrió un posible escenario de ataque contra los servidores proxy. Para evitar esto, fue necesario hacer que el tráfico WebSocket se parezca a cualquier tráfico HTTP normal. Es por eso que las claves de enmascaramiento se introdujeron en la versión final del protocolo .

Para TL; DR, aquí hay 2 centavos y una versión más simple para sus preguntas:

  1. WebSockets proporciona estos beneficios a través de HTTP:

    • Conexión persistente con estado durante la duración de la conexión
    • Baja latencia: comunicación casi en tiempo real entre el servidor y el cliente debido a que no hay gastos generales para restablecer las conexiones para cada solicitud según lo requiera HTTP.
    • Full dúplex: tanto el servidor como el cliente pueden enviar / recibir simultáneamente
  2. 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 apátrida, distribuido mediante un modelo de solicitud / respuesta. Además de compartir los puertos por razones heredadas (penetración de firewall / proxy), no hay mucho terreno común para combinarlos en un solo protocolo.

¿Por qué es mejor el protocolo websockets?

No creo que podamos compararlos uno al lado del otro 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 y respuesta. El cliente (navegador) quiere algo, el servidor lo da. Es decir. Si el cliente de datos quiere es grande, el servidor podría enviar datos de transmisión para anular problemas de búfer no deseados. Aquí el principal requisito o problema es cómo hacer la solicitud de los clientes y cómo responder a los recursos (hybertext) que solicitan. Ahí es donde brilla el HTTP.

En HTTP, solo solicitud del cliente. El servidor solo responde.

WebSocket no es un protocolo de solicitud y respuesta donde solo el cliente puede solicitarlo. Es un zócalo (muy similar al zócalo TCP). Una vez que la conexión está abierta, una de las partes puede enviar datos hasta que se resalte la conexión TCP. 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 mucha restricción para un socket normal. La mayoría del cortafuegos bloqueará otros puertos que no sean 80 y 433 que utilizó HTTP. Los proxies y los intermediarios también serán problemáticos. Para que el protocolo sea más fácil de implementar en las infraestructuras existentes, websocket utiliza el protocolo de enlace HTTP para actualizar. Eso significa que cuando se abra la primera vez que se abre la conexión, el cliente envió una solicitud HTTP para decirle al servidor que “Eso no es una solicitud HTTP, actualice al protocolo websocket”.

 Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13 

Una vez que el servidor entendió la solicitud y se actualizó al protocolo websocket, ya no se aplicó el protocolo HTTP.

Entonces mi respuesta es: ninguno es mejor que el otro. Ellos son completamente diferentes.

¿Por qué se implementó en lugar de actualizar el protocolo http?

Bien, podemos hacer todo bajo el nombre llamado HTTP también. ¿Pero lo haremos? Si son dos cosas diferentes, preferiré dos nombres diferentes. Lo mismo hacen Hickson y Michael Carter .

Las otras respuestas no parecen tocar un aspecto clave aquí, y es que no mencionas la necesidad de apoyar un navegador web como cliente. La mayoría de las limitaciones de HTTP simple anterior asumen que estarías trabajando con implementaciones de navegador / JS.

El protocolo HTTP es completamente capaz de comunicación full-duplex; es legal que un cliente realice una POST con transferencia de encoding fragmentada y un servidor para devolver una respuesta con un cuerpo de encoding fragmentada. Esto eliminaría la cabecera del encabezado justo al momento de la inicialización.

Entonces, si todo lo que está buscando es dúplex completo, controle tanto el cliente como el servidor, y no esté interesado en el encuadre adicional / características de websockets, entonces yo diría que HTTP es un enfoque más simple con menor latencia / CPU (aunque la latencia realmente solo diferiría en microsegundos o menos para cualquiera de los dos).

Sondeo HTTP

El sondeo HTTP es el proceso de buscar el servidor por cliente en intervalos de tiempo predefinidos para obtener información actualizada si está disponible. En el sondeo HTTP, el cliente envía una solicitud a un servidor. Entonces el servidor responde con cualquier mensaje nuevo. Si no hay nuevos mensajes disponibles, el servidor responde con un formato vacío o acordado previamente. Este flujo se repite mediante el intervalo de sondeo configurado. El sondeo HTTP genera una sobrecarga de red significativa en el sistema ya que requiere la repetición de los encabezados en cada solicitud.

Por lo tanto, el sondeo HTTP funciona comparativamente bien, si la frecuencia de recepción de actualización es fija. Si la frecuencia de recepción de la actualización es alta o la recepción de la actualización es aleatoria o no predecible, el sondeo HTTP puede generar una sobrecarga de comunicación. Por lo tanto, el principal inconveniente de la interrogación HTTP es el envío de una cantidad de solicitudes innecesarias al servidor, incluso si no hay nuevas actualizaciones para recuperar.

HTTP Long Polling

El sondeo largo HTTP es una variación de la técnica de sondeo definida para superar los inconvenientes antes mencionados de un sondeo simple. Está definido para manejar de manera eficiente la transmisión de datos entre el servidor y el cliente. La diferencia de la encuesta larga es que no envía una respuesta vacía de inmediato, cuando no hay mensajes nuevos. En lugar de eso, el servidor espera a que responda un nuevo mensaje o se agota el tiempo de espera de la solicitud. Esto ofrece una solución más eficiente para el sondeo, especialmente cuando hay menos mensajes nuevos en el sistema, lo que reduce el número de solicitudes de los clientes. Una vez más, si los tiempos de espera de la conexión están apareciendo más allá de la respuesta, aún el sondeo largo HTTP no es muy ventajoso. Por lo tanto, el sondeo largo HTTP no ha resuelto todos los inconvenientes aparecidos por el sondeo HTTP.

WebSockets

El protocolo WebSockets se introdujo como una extensión, para mejorar la comunicación cliente-servidor con varias adiciones de valor. En el intercambio de datos en tiempo real, WebSockets funciona bien con menos sobrecarga de comunicación, proporcionando una comunicación eficiente y con estado entre el cliente y el servidor. El protocolo WebSockets permite mantener conexiones de socket TCP a largo plazo entre clientes y servidores. Lo que es más importante, los sockets web permiten que los mensajes se entreguen instantáneamente con una sobrecarga insignificante al sistema, en tiempo real, bidireccional y dúplex. WebSockets exhibe una característica única de atravesar a través de firewall y proxies. Puede detectar la presencia del servidor proxy y configura automáticamente un túnel para pasar a través del proxy. Especialmente los navegadores web pueden aprovechar la ventaja del modo dúplex completo para enviar datos en cualquier dirección al mismo tiempo. Además, los WebSockets proporcionan una reducción significativa de la congestión de la red y de los gastos generales que un sistema dúplex regular que mantiene dos conexiones con el sondeo, al operar pensado en un solo socket a través de la web.

Con las capacidades mejoradas del protocolo WebSockets, a menudo es adecuado para los marcos de aplicaciones de red para proporcionar más consistencia, lo que permite una escalabilidad masiva en plataformas en tiempo real. Además, ha estado surgiendo como un protocolo muy fiable, de alto rendimiento, en tiempo real y prometedor para la comunicación entre nodos, lo que lo convierte en una metodología confiable para la gestión de clusters.

Referencias http://www.devdummy.com/2017/12/http-polling-http-long-polling.html