socket services restful ajax http websocket comet

ajax - services - Protocolo webSockets vs HTTP



websocket vs socket (6)

¿Por qué es mejor el protocolo websockets?

No creo que podamos compararlos uno al lado del otro como quién es mejor. Eso 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 lo da. Es decir. Si el cliente de datos desea 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 realizar la solicitud de los clientes y cómo responder a los recursos (texto inteligente) que solicitan. Ahí es donde brilla el HTTP.

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

WebSocket no es un protocolo de solicitud-respuesta donde solo el cliente puede solicitar. Es un socket (muy similar al socket TCP). Significa que una vez que la conexión está abierta, cualquiera de los lados puede enviar datos hasta que se cierre la conexión TCP. Es como un zócalo normal. La única diferencia con el socket TCP es que websocket se puede usar en la web. En web, tenemos mucha restricción para un socket normal. La mayoría de los cortafuegos bloquearán el puerto distinto al 80 y 433 que utiliza HTTP. Los proxies e intermediarios también serán problemáticos. Para hacer que el protocolo sea más fácil de implementar en las infraestructuras existentes, websocket usa 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".

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

Una vez que el servidor comprende la solicitud y se actualiza al protocolo websocket, ya no se aplica ningún protocolo HTTP.

Así que mi respuesta es: ninguna es mejor que la otra. Son completamente diferentes.

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

Bueno, podemos hacer todo bajo el nombre llamado HTTP también. ¿Pero nosotros? Si son dos cosas diferentes, preferiré dos nombres diferentes. Lo mismo ocurre con Hickson y Michael Carter .

Hay muchos blogs y discusiones sobre websocket y HTTP, y muchos desarrolladores y sitios abogan fuertemente por websockets, pero todavía no puedo entender 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 de dúplex completo que funciona a través de un solo socket a través de la Web. ( http://www.websocket.org/quantum.html )

HTTP admite la transmisión: solicitud de transmisión por el cuerpo (la está utilizando al cargar archivos grandes) y transmisión de la respuesta por el cuerpo.

Durante la conexión con WebSocket, el cliente y el servidor intercambian datos por trama de 2 bytes cada uno, en comparación con los 8 kilos de la cabecera http cuando realiza un sondeo continuo.

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

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

Esto es ~ 48 bytes de encabezado http.

Codificación fragmentada de 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 trozo 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 allí.

Pregunta:

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

Las otras respuestas no parecen referirse a un aspecto clave aquí, y es que usted no hace mención alguna de la necesidad de admitir un navegador web como cliente. La mayoría de las limitaciones de HTTP simple mencionadas anteriormente suponen que trabajaría 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 un servidor para devolver una respuesta con un cuerpo de codificación fragmentada. Esto eliminaría la sobrecarga del encabezado justo en el momento de inicio.

Por lo tanto, si todo lo que busca es dúplex completo, controle el cliente y 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 realmente solo diferiría en microsegundos o menos para cualquiera de los dos).

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

  1. WebSockets proporciona estos beneficios sobre HTTP:

    • Conexión permanente persistente para la duración de la conexión
    • Baja latencia: comunicación casi en tiempo real entre el servidor / cliente debido a la sobrecarga de restablecer las conexiones para cada solicitud según lo requiera HTTP.
    • Dúplex completo: 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 utilizando un modelo de solicitud / respuesta. Aparte de compartir los puertos por razones heredadas (firewall / penetración de proxy), no hay muchos puntos en común para combinarlos en un solo protocolo.

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

El principal caso de uso 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 función WebSocket permite que el servidor envíe datos cuando lo desee. Esto permite implementar juegos basados ​​en el navegador con una latencia mucho menor y sin tener que usar hacks feos como AJAX de sondeo largo o complementos del navegador.

Entonces, ¿por qué no usar HTTP normal con solicitudes y respuestas de flujo continuo?

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

De hecho, los WebSockets son básicamente eso. Un intento de abrir una conexión WebSocket desde el cliente parece una solicitud HTTP al principio, pero una directiva especial en el encabezado (Upgrade: 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 algunos acuerdos para asegurar que el servidor realmente entienda que el cliente desea comunicarse de forma asíncrona. Pero luego se dio cuenta de que los servidores proxy se confundirían con eso, porque están acostumbrados al modelo de solicitud / respuesta habitual 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. Es por eso que las claves de enmascaramiento se introdujeron en la versión final del protocolo .

1) ¿Por qué es mejor el protocolo WebSockets?

WebSockets es mejor para situaciones que involucran 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 del cliente al servidor, que requiere que se establezca una nueva conexión para cada mensaje del cliente al servidor.

Su protocolo de enlace HTTP de 48 bytes no es realista para las conexiones de 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, incluidos los 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 handshakes de conexión inicial de tamaño equivalente, pero con una conexión WebSocket el handshake 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 importante 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 menor latencia, como SPDY , HTTP 2.0 y QUIC . Esto mejorará la situación de las solicitudes HTTP normales, pero es probable que WebSockets y / o WebRTC DataChannel aún tengan una latencia menor para la transferencia de datos del cliente al 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 en protocolos web:

  • TCP : nivel bajo, bidireccional, full-duplex y capa de transporte de orden garantizada. No es compatible con el navegador (excepto a través de plugin / Flash).
  • HTTP 1.0 : protocolo de transporte de solicitud-respuesta en capas en TCP. El cliente hace 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-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 (OPTIONS, PUT, DELETE, TRACE, CONNECT) que también tienen significados transaccionales específicos. Sin embargo, como se señaló en la introduction a la propuesta de borrador de HTTP 2.0, la canalización de HTTP 1.1 no se implementa ampliamente, por lo que limita enormemente la utilidad de HTTP 1.1 para resolver la latencia entre los navegadores y los servidores.
  • Encuesta larga : una especie de "pirateo" a HTTP (ya sea 1.0 o 1.1) donde el servidor no responde inmediatamente (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 (utilizando la misma conexión si está sobre HTTP 1.1).
  • Transmisión HTTP : una variedad de técnicas (respuesta multiparte / fragmentada) que permiten al servidor enviar más de una respuesta a una sola solicitud de cliente. El W3C está estandarizando esto como eventos enviados por el servidor utilizando un tipo MIME de text/event-stream . La API del navegador (que es bastante similar a la API de WebSocket) se llama la API EventSource.
  • Comet / server push : este es un término general que incluye tanto el sondeo largo como el streaming HTTP. Las bibliotecas de cometas generalmente admiten múltiples técnicas para intentar maximizar el soporte entre navegadores y servidores.
  • WebSockets : una capa de transporte TCP integrada que utiliza un protocolo de enlace de actualización compatible con HTTP. A diferencia de TCP, que es un transporte de transmisión por secuencias, WebSockets es un transporte basado en mensajes: los mensajes se delimitan en el cable y se vuelven a ensamblar por completo antes de entregarlos a la aplicación. Las conexiones WebSocket son bidireccionales, full-duplex y de larga duración. Después de la solicitud / respuesta inicial del protocolo de enlace, no hay semántica transaccional y hay muy poca sobrecarga por mensaje. El cliente y el servidor pueden enviar mensajes en cualquier momento y deben manejar la recepción de mensajes de forma asíncrona.
  • SPDY : una propuesta iniciada por Google para extender HTTP utilizando un protocolo de conexión más eficiente pero manteniendo toda la semántica de HTTP (solicitud / respuesta, cookies, codificación). SPDY introduce un nuevo formato de encuadre (con marcos con prefijo de longitud) y especifica una manera de colocar pares de solicitud / respuesta HTTP en la nueva capa de encuadre. Los encabezados pueden comprimirse y los nuevos pueden enviarse después de que se haya establecido la conexión. Hay implementaciones de SPDY en el mundo real en navegadores y servidores.
  • HTTP 2.0 : tiene objetivos similares a SPDY: reduce la latencia y la sobrecarga de HTTP al tiempo que conserva la semántica de HTTP. El borrador actual se deriva de SPDY y define un protocolo de actualización y un marco de datos muy similar al estándar WebSocket para el protocolo de enlace y el marco. Una propuesta de borrador de HTTP 2.0 alternativa (httpbis-speed-mobility) en realidad utiliza WebSockets para la capa de transporte y agrega la multiplexación SPDY y la asignación de HTTP como una extensión de WebSocket (las extensiones de WebSocket se negocian durante el protocolo de enlace).
  • WebRTC / CU-WebRTC : propuestas para permitir la conectividad de igual a igual entre navegadores. Esto puede permitir una comunicación de latencia media y máxima más baja porque el transporte subyacente es SDP / datagrama en lugar de TCP. Esto permite la entrega de paquetes / mensajes fuera de orden, lo que evita el problema de TCP de los picos de latencia causados ​​por paquetes caídos que retrasan la entrega de todos los paquetes posteriores (para garantizar la entrega en orden).
  • QUIC : es un protocolo experimental destinado a reducir la latencia de la web en comparación con 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 y semántica de conexión, confiabilidad y control de congestión equivalentes a TCP. Debido a que TCP se implementa en los kernels del sistema operativo y en el firmware de middlebox, es casi imposible realizar cambios significativos en TCP. Sin embargo, dado que QUIC está construido sobre UDP, no tiene tales limitaciones. QUIC está diseñado y optimizado para HTTP / 2 semántica.

Referencias :

Encuesta 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 nuevos mensajes. Si no hay nuevos mensajes disponibles, el servidor responde con un formato vacío o previamente acordado. Este flujo se repite por 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 actualizaciones es fija. Si la frecuencia de recepción de actualizaciones es alta o el recibo de actualización es aleatorio o no predecible, el sondeo HTTP puede generar una sobrecarga de comunicación. Por lo tanto, el principal inconveniente del sondeo HTTP es el envío de una cantidad de solicitudes innecesarias al servidor, incluso si no hay nuevas actualizaciones para obtener.

Encuesta larga HTTP

El sondeo largo HTTP es una variación de la técnica de sondeo definida para superar los inconvenientes mencionados anteriormente del sondeo simple. Se define para manejar eficientemente la transmisión de datos entre el servidor y el cliente. La diferencia del sondeo largo 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 la cantidad de solicitudes de los clientes. Nuevamente, si los tiempos de espera de conexión aparecen más allá de la respuesta, aún el sondeo HTTP largo no es muy ventajoso. Por lo tanto, HTTP polling largo no ha resuelto todos los inconvenientes aparecidos por HTTP polling.

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 se desempeña 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 más importante es que los sockets web permiten que los mensajes se envíen instantáneamente con una sobrecarga insignificante para el sistema, en tiempo real, bidireccional y dúplex completo. Los WebSockets exhiben una característica única de atravesar firewall y proxies. Puede detectar la presencia de un servidor proxy y configurar automáticamente un túnel para pasar a través del proxy. Especialmente los navegadores web pueden aprovechar el 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 red y los gastos generales que un sistema dúplex regular que mantiene dos conexiones con el sondeo, al operar un solo socket en la web.

Con las capacidades mejoradas del protocolo WebSockets, a menudo es adecuado para que los marcos de aplicaciones de red proporcionen más consistencia, lo que permite una escalabilidad masiva en plataformas en tiempo real. Además, también se está convirtiendo en un protocolo muy confiable, de alto rendimiento, preparado para el tiempo real y prometedor para la comunicación entre nodos, lo que lo convierte en una metodología confiable para la administración de clústeres.

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