socket nodejs node example ejemplo javascript web-applications websocket comet http-streaming

javascript - nodejs - Mi comprensión del sondeo HTTP, sondeos largos, HTTP Streaming y WebSockets



websocket server (4)

He leído muchas publicaciones sobre SO y la web con respecto a las palabras clave en el título de mi pregunta y aprendí mucho de ellas. Algunas de las preguntas que leo están relacionadas con desafíos específicos de implementación, mientras que otras se centran en conceptos generales. Solo quiero asegurarme de haber entendido todos los conceptos y el razonamiento de por qué la tecnología X se inventó sobre la tecnología Y, y así sucesivamente. Así que aquí va:

Http Polling: Básicamente AJAX, utilizando XmlHttpRequest.

Http Long Polling: AJAX pero el servidor mantiene la respuesta a menos que el servidor tenga una actualización, tan pronto como el servidor tenga una actualización, la envía y luego el cliente puede enviar otra solicitud. La desventaja es que los datos adicionales del encabezado deben enviarse hacia atrás y hacia adelante causando gastos adicionales.

Http Streaming: Similar al sondeo largo, pero el servidor responde con un encabezado con "Transfer Encoding: chunked" y por lo tanto no necesitamos iniciar una nueva solicitud cada vez que el servidor envía algunos datos (y por lo tanto, guarda la sobrecarga del encabezado adicional). El inconveniente aquí es que tenemos que "entender" y descubrir la estructura de los datos para distinguir entre múltiples fragmentos enviados por el servidor.

Java Applet, Flash, Silverlight: Proporcionan la capacidad de conectarse a los servidores de socket a través de tcp / ip pero, como son complementos, los desarrolladores no desean depender de ellos.

WebSockets: son la nueva API que trata de abordar las deficiencias de los métodos anteriores de la siguiente manera:

  • La única ventaja de WebSockets sobre los complementos como Applets de Java, Flash o Silverlight es que los WebSockets están incorporados de forma nativa en los navegadores y no dependen de los complementos.
  • La única ventaja de WebSockets sobre la transmisión de http es que no tiene que esforzarse para "entender" y analizar los datos recibidos.
  • La única ventaja de WebSockets durante Long Polling es la eliminación del tamaño de los encabezados adicionales y la apertura y el cierre de la conexión del socket para su solicitud.

¿Hay alguna otra diferencia significativa que me falta? Lo siento si vuelvo a preguntar o si combino muchas de las preguntas que ya están en SO en una sola pregunta, pero solo quiero dar sentido a toda la información que está disponible en SO y la web con respecto a estos conceptos.

¡Gracias!

Si puedo hacer una pregunta adicional: me encontré con un artículo en algún lugar que dice que la transmisión http también puede ser almacenada en caché por los proxies mientras que los websockets no. ¿Qué significa eso?

( limita el tamaño de las respuestas de comentarios, así que he tenido que responder aquí en lugar de en línea).

Ese es un buen punto. Para comprender esto, piense en un escenario HTTP tradicional ... Imagine que un navegador abriera una página web, por lo que solicita http://example.com , por ejemplo. El servidor responde con HTTP que contiene el HTML de la página. Luego, el navegador ve que hay recursos en la página, por lo que comienza a solicitar los archivos CSS, los archivos JavaScript y las imágenes, por supuesto. Todos son archivos estáticos que serán iguales para todos los clientes que los soliciten.

Algunos proxies almacenarán en caché recursos estáticos para que las solicitudes posteriores de otros clientes puedan obtener esos recursos estáticos del proxy, en lugar de tener que volver al servidor web central para obtenerlos. Esto es el almacenamiento en caché, y es una gran estrategia para descargar las solicitudes y el procesamiento de sus servicios centrales.

Por lo tanto, el cliente n.º 1 solicita http://example.com/images/logo.gif , por ejemplo. Esa solicitud pasa por el proxy hasta el servidor web central, que sirve de logo.gif. Como logo.gif pasa a través del proxy, el proxy guardará esa imagen y la asociará a la dirección http://example.com/images/logo.gif .

Cuando el cliente # 2 aparece y también solicita http://example.com/images/logo.gif , el proxy puede devolver la imagen y no se requiere comunicación con el servidor web en el centro. Esto proporciona una respuesta más rápida para el usuario final, que siempre es excelente, pero también significa que hay menos carga en el centro. Eso puede traducirse en costos de hardware reducidos, costos de red reducidos, etc. Por lo tanto, es algo bueno.

El problema surge cuando el logo.gif se actualiza en el servidor web. El proxy continuará publicando la imagen anterior sin saber que hay una nueva imagen. Esto lleva a que todo caduque para que el proxy solo guarde en caché la imagen durante un breve período de tiempo antes de que "caduque" y la siguiente solicitud pasa por el proxy al servidor web, que luego actualiza el caché del proxy. También hay soluciones más avanzadas en las que un servidor central puede enviar a cachés conocidos, y así sucesivamente, y las cosas pueden volverse bastante sofisticadas.

¿Cómo se relaciona esto con tu pregunta?

Preguntaste sobre la transmisión HTTP donde el servidor está transmitiendo HTTP a un cliente. Pero la transmisión de HTTP es como HTTP normal, excepto que no dejas de enviar datos. Si un servidor web sirve una imagen, envía HTTP al cliente que finalmente finaliza: has enviado toda la imagen. Y si desea enviar datos, es exactamente lo mismo, pero el servidor simplemente lo envía durante mucho tiempo (como si fuera una imagen enormemente gigantesca, por ejemplo) o incluso nunca termina.

Desde el punto de vista del proxy, no puede distinguir entre HTTP para un recurso estático como una imagen o datos de transmisión HTTP. En ambos casos, el cliente hizo una solicitud al servidor. El proxy recordó esa solicitud y también la respuesta. La próxima vez que entre la solicitud, el proxy ofrecerá la misma respuesta.

Entonces, si su cliente hizo una solicitud de precios de acciones, por ejemplo, y obtuvo una respuesta, entonces el próximo cliente puede hacer la misma solicitud y obtener los datos en caché. Probablemente no es lo que quieres! Si solicita precios de acciones, quiere los datos más recientes, ¿verdad?

Entonces es un problema.

Hay trucos y soluciones para manejar problemas como ese, es verdad. Obviamente, puede hacer que la transmisión HTTP funcione, ya que está en uso hoy en día. Todo es transparente para el usuario final, pero las personas que desarrollan y mantienen esas arquitecturas tienen que pasar por el aro y pagar un precio. Resulta en arquitecturas demasiado complicadas, lo que significa más mantenimiento, más hardware, más complejidad y más costos. También significa que los desarrolladores a menudo tienen que preocuparse por algo que no deberían tener cuando deberían centrarse solo en la aplicación, la GUI y la lógica comercial: no deberían preocuparse por la comunicación subyacente.

Algunas excelentes respuestas de otros que cubren mucho terreno. Aquí hay un poco más.

La única ventaja de WebSockets sobre los complementos como Applets de Java, Flash o Silverlight es que los WebSockets están incorporados de forma nativa en los navegadores y no dependen de los complementos.

Si con esto quiere decir que puede usar Applets de Java, Flash o Silverlight para establecer una conexión de socket, entonces sí, eso es posible. Sin embargo, no se ve eso desplegado en el mundo real con demasiada frecuencia debido a las restricciones.

Por ejemplo, los intermediarios pueden y cierran ese tráfico. El estándar WebSocket fue diseñado para ser compatible con la infraestructura HTTP existente y, por lo tanto, es mucho menos propenso a ser interferido por intermediarios como servidores de seguridad y servidores proxy.

Además, WebSocket puede usar los puertos 80 y 443 sin necesidad de puertos dedicados, nuevamente gracias al diseño del protocolo para ser lo más compatible posible con la infraestructura HTTP existente.

Esas alternativas de socket (Java, Flash y Silverlight) son difíciles de usar de forma segura en una arquitectura de origen cruzado. Por lo tanto, las personas que a menudo intentan usarlos de origen cruzado tolerarán las inseguridades en lugar de esforzarse por hacerlo de forma segura.

También pueden requerir que se abran puertos "no estándar" adicionales (algo que los administradores detestan hacer) o archivos de políticas que necesitan ser gestionados.

En resumen, usar Java, Flash o Silverlight para la conectividad del socket es lo suficientemente problemático como para no verlo implementado en arquitecturas serias con demasiada frecuencia. Flash y Java han tenido esta capacidad probablemente durante al menos 10 años, y sin embargo no es frecuente.

El estándar WebSocket fue capaz de comenzar con un nuevo enfoque, teniendo en cuenta esas restricciones, y con suerte haber aprendido algunas lecciones de ellos.

Algunas implementaciones de WebSocket usan Flash (o posiblemente Silverlight y / o Java) como respaldo cuando no se puede establecer la conectividad de WebSocket (como cuando se ejecuta en un navegador antiguo o cuando un intermediario interfiere).

Mientras que algún tipo de estrategia alternativa para esas situaciones es inteligente, incluso necesaria, la mayoría de los que usan Flash et al sufrirán los inconvenientes descritos anteriormente. No tiene que ser así: hay soluciones para lograr conexiones seguras de origen cruzado usando Flash, Silverlight, etc., pero la mayoría de las implementaciones no lo harán porque no es fácil.

Por ejemplo, si confía en WebSocket para una conexión de origen cruzado, eso funcionará bien. Pero si luego se ejecuta en un navegador anterior o si interfiere un servidor de seguridad / proxy y confía en Flash, por ejemplo, como alternativa, le resultará difícil hacer la misma conexión de origen cruzado. A menos que no te preocupes por la seguridad, por supuesto.

Eso significa que es difícil tener una sola arquitectura unificada que funcione para conexiones nativas y no nativas, a menos que esté preparado para trabajar bastante o con un marco que lo haya hecho bien. En una arquitectura ideal, no notarías si las conexiones fueran nativas o no; su configuración de seguridad funcionaría en ambos casos; su configuración de clúster aún funcionaría; su planificación de capacidad aún se mantendría; y así.

La única ventaja de WebSockets sobre la transmisión de http es que no tiene que esforzarse para "entender" y analizar los datos recibidos.

No es tan simple como abrir una secuencia HTTP y sentarse mientras fluyen los datos durante minutos, horas o más. Diferentes clientes se comportan de manera diferente y usted tiene que gestionar eso. Por ejemplo, algunos clientes almacenan en búfer los datos y no los liberan a la aplicación hasta que se alcanza un umbral. Peor aún, algunos no pasarán los datos a la aplicación hasta que se cierre la conexión.

Por lo tanto, si envía múltiples mensajes al cliente, es posible que la aplicación cliente no reciba los datos hasta que se hayan recibido 50 mensajes con información valiosa, por ejemplo. Eso no es demasiado en tiempo real.

Si bien la transmisión HTTP puede ser una alternativa viable cuando WebSocket no está disponible, no es una panacea. Necesita una buena comprensión para trabajar de manera robusta en las tierras baldías de la Web en condiciones del mundo real.

¿Hay alguna otra diferencia significativa que me falta?

Hay otra cosa que nadie ha mencionado todavía, así que lo mencionaré.

El protocolo WebSocket fue diseñado para ser una capa de transporte para protocolos de nivel superior. Si bien puede enviar mensajes JSON o lo que sea, no directamente a través de una conexión WebSocket, también puede llevar protocolos estándar o personalizados.

Por ejemplo, podría hacer AMQP o XMPP sobre WebSocket, como ya lo hicieron las personas. De modo que un cliente podría recibir mensajes de un intermediario de AMQP como si estuviese conectado directamente con el intermediario (y en algunos casos sí).

O si tiene un servidor existente con algún protocolo personalizado, puede transportarlo a través de WebSocket, extendiendo así ese servidor de fondo a la Web. A menudo, una aplicación existente que se ha bloqueado en la empresa puede ampliar su alcance utilizando WebSocket, sin tener que cambiar ninguna infraestructura de fondo.

(Naturalmente, le gustaría poder hacer todo eso de forma segura, así que consulte con el proveedor o con el proveedor de WebSocket).

Algunas personas se han referido a WebSocket como TCP para la Web. Porque al igual que TCP transporta protocolos de nivel superior, también lo hace WebSocket, pero de una manera que es compatible con la infraestructura web.

Por lo tanto, aunque siempre es posible enviar mensajes JSON (o lo que sea) directamente sobre WebSocket, también se deben considerar los protocolos existentes. Porque para muchas cosas que quieres hacer, probablemente haya un protocolo que ya se pensó para hacerlo.

Lo siento si vuelvo a preguntar o si combino muchas de las preguntas que ya están en SO en una sola pregunta, pero solo quiero dar sentido a toda la información que está disponible en SO y la web con respecto a estos conceptos.

Esta fue una gran pregunta, ¡y todas las respuestas han sido muy informativas!

HTTP limita el número de conexiones que un cliente puede tener con un servidor a 2 (aunque esto se puede mitigar mediante el uso de subdominios) y se ha sabido que IE hace cumplir esto con entusiasmo. Firefox y Chrome permiten más (aunque no puedo recordar la parte superior de mi cabeza exactamente cuántos). Puede que esto no parezca un gran problema, pero si utiliza una conexión constantemente para actualizaciones en tiempo real, todas las demás solicitudes tienen que atravesar la otra conexión HTTP. Y está la cuestión de tener más conexiones abiertas de los clientes que pone más carga en el servidor.

WebSockets es un protocolo basado en TCP y, como tal, no sufre este límite de conexión de nivel HTTP (pero, por supuesto, el soporte del navegador no es uniforme).

Hay más diferencias que las que ha identificado.

Duplex / direccional:

  • Unidireccional: encuesta HTTP, encuesta larga, transmisión.
  • Bi-direcitonal: WebSockets, redes de complementos

Para aumentar la latencia (aproximado):

  • WebSockets
  • Redes de complementos
  • Transmisión HTTP
  • HTTP Long-Poll
  • Sondeo HTTP

CORS (soporte de origen cruzado):

  • WebSockets: sí
  • Redes de complementos: Flash mediante solicitud de política (no estoy seguro de los demás)
  • HTTP * (algunos soportes recientes)

Datos binarios nativos (matrices tipadas, blobs):

  • WebSockets: sí
  • Redes de complementos: no con Flash (requiere codificación URL en ExternalInterface)
  • HTTP *: propuesta reciente para habilitar el soporte de tipo binario

Ancho de banda en eficiencia decreciente:

  • Redes de complementos: las tomas de corriente flash están en bruto, excepto para la solicitud de política inicial
  • WebSockets: protocolo de enlace de configuración de conexión y unos pocos bytes por cuadro
  • Transmisión HTTP (reutilización de la conexión del servidor)
  • Encuesta larga HTTP: conexión para cada mensaje
  • Encuesta HTTP: conexión para cada mensaje + sin mensajes de datos

Soporte de dispositivo móvil:

  • WebSocket: iOS 4.2 y superior. Algunos de Android a través de la emulación de Flash o el uso de Firefox para Android o Google Chrome para Android, que proporcionan soporte nativo de WebSocket.
  • Redes de complementos: algunos de Android. No en iOS
  • HTTP *: en su mayoría sí

Complejidad de uso de Javascript (desde la más simple hasta la más complicada). Es cierto que las medidas de complejidad son algo subjetivas.

  • WebSockets
  • Encuesta HTTP
  • Redes de complementos
  • Encuesta larga HTTP, transmisión

También tenga en cuenta que existe una propuesta del W3C para estandarizar la transmisión HTTP llamada Eventos enviados por el servidor . Actualmente es bastante temprano en su evolución y está diseñado para proporcionar una API JavaScript estándar con una simplicidad comparable a WebSockets.