He leído muchas publicaciones en SO y en 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 leí están relacionadas con desafíos de implementación específicos, mientras que otras se enfocan en conceptos generales. Solo quiero asegurarme de que entendí todos los conceptos y el razonamiento por el que se inventó la tecnología X sobre la tecnología Y, etc. Así que aquí va:
Sondeo Http: Básicamente AJAX, usando XmlHttpRequest.
Http Long Polling: AJAX pero el servidor retiene la respuesta a menos que el servidor tenga una actualización, tan pronto como el servidor tiene una actualización, la envía y luego el cliente puede enviar otra solicitud. La desventaja son los datos de encabezado adicionales que deben enviarse de un lado a otro, lo que genera una sobrecarga adicional.
Http Streaming: similar al sondeo largo, pero el servidor responde con un encabezado con "Transferir codificación: fragmentado" 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 adicional del encabezado). El inconveniente aquí es que tenemos que "entender" y averiguar la estructura de los datos para distinguir entre varios fragmentos enviados por el servidor.
Java Applet, Flash, Silverlight: brindan la capacidad de conectarse a servidores de socket a través de tcp / ip, pero como son complementos, los desarrolladores no quieren depender de ellos.
WebSockets: son la nueva API que intenta abordar las deficiencias de los métodos anteriores de la siguiente manera:
- La única ventaja de WebSockets sobre complementos como Java Applets, Flash o Silverlight es que los WebSockets están integrados de forma nativa en los navegadores y no dependen de complementos.
- La única ventaja de WebSockets sobre la transmisión http es que no tiene que hacer un esfuerzo para "comprender" y analizar los datos recibidos.
- La única ventaja de WebSockets sobre Long Polling es la eliminación del tamaño adicional de los encabezados y la apertura y cierre de la conexión del socket a pedido.
¿Hay otras diferencias significativas que me falten? Lo siento si estoy volviendo a hacer o combinando muchas de las preguntas que ya están en SO en una sola pregunta, pero solo quiero entender perfectamente toda la información que hay en SO y en la web con respecto a estos conceptos.
¡Gracias!
fuente
Respuestas:
Hay más diferencias que las que ha identificado.
Dúplex / direccional:
En orden de latencia creciente (aproximada):
CORS (soporte de origen cruzado):
Datos binarios nativos (matrices escritas, blobs):
Ancho de banda en eficiencia decreciente:
Soporte para dispositivos móviles:
Complejidad del uso de Javascript (del más simple al más complicado). Es cierto que las medidas de complejidad son algo subjetivas.
También tenga en cuenta que existe una propuesta del W3C para estandarizar la transmisión HTTP llamada Eventos enviados por el servidor . Actualmente se encuentra bastante temprano en su evolución y está diseñado para proporcionar una API de JavaScript estándar con una simplicidad comparable a WebSockets.
fuente
Algunas grandes respuestas de otros que cubren mucho terreno. Aquí tienes un poco más.
Si con esto quiere decir que puede usar Java Applets, Flash o Silverlight para establecer una conexión de socket, entonces sí, eso es posible. Sin embargo, no lo ve implementado en el mundo real con demasiada frecuencia debido a las restricciones.
Por ejemplo, los intermediarios pueden cerrar ese tráfico y lo hacen. 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 firewalls y proxies.
Además, WebSocket puede usar los puertos 80 y 443 sin requerir 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 hacer el esfuerzo de 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 deben administrarse.
En resumen, el uso de Java, Flash o Silverlight para la conectividad de sockets es lo suficientemente problemático como para que no lo vea implementado en arquitecturas serias con demasiada frecuencia. Flash y Java han tenido esta capacidad durante probablemente al menos 10 años y, sin embargo, no es frecuente.
El estándar WebSocket pudo comenzar con un enfoque nuevo, teniendo en cuenta esas restricciones y, con suerte, haber aprendido algunas lecciones de ellas.
Algunas implementaciones de WebSocket utilizan 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 interfiere un intermediario).
Si bien 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 por qué ser así, existen soluciones alternativas para lograr conexiones seguras con capacidad de origen cruzado utilizando 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, funcionará bien. Pero si luego ejecuta en un navegador antiguo o un firewall / proxy interfirió y confía en Flash, digamos, como su respaldo, le resultará difícil hacer esa misma conexión de origen cruzado. A menos que no le importe la seguridad, por supuesto.
Eso significa que es difícil tener una única arquitectura unificada que funcione para conexiones nativas y no nativas, a menos que esté preparado para trabajar bastante o ir con un marco que lo haya hecho bien. En una arquitectura ideal, no notaría si las conexiones fueran nativas o no; su configuración de seguridad funcionaría en ambos casos; su configuración de agrupación en clúster aún funcionaría; su planificación de capacidad aún se mantendría; y así.
No es tan simple como abrir un flujo HTTP y sentarse mientras sus datos fluyen durante minutos, horas o más. Los diferentes clientes se comportan de manera diferente y tienes que gestionar eso. Por ejemplo, algunos clientes almacenarán los datos en búfer y no los enviarán a la aplicación hasta que se alcance algún 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 varios mensajes al cliente, es posible que la aplicación cliente no reciba los datos hasta que se hayan recibido 50 mensajes de datos, 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. Se necesita una buena comprensión para trabajar de manera sólida en las tierras baldías de la Web en condiciones del mundo real.
Hay otra cosa que nadie ha mencionado todavía, así que la 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 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 a través de WebSocket, como ya lo ha hecho la gente. Por lo tanto, un cliente podría recibir mensajes de un corredor de AMQP como si estuviera conectado directamente al corredor en sí (y en algunos casos lo está).
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 la infraestructura de back-end.
(Naturalmente, querrá poder hacer todo eso de forma segura, así que consulte con el proveedor o 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 compatible con la infraestructura web.
Entonces, si bien siempre es posible enviar mensajes JSON (o lo que sea) directamente a través de WebSocket, también se deben considerar los protocolos existentes. Porque para muchas cosas que desea hacer, probablemente ya se ha pensado en un protocolo para hacerlo.
Esta fue una gran pregunta, ¡y todas las respuestas han sido muy informativas!
fuente
(StackOverflow limita el tamaño de las respuestas a los comentarios, así que tuve que responder aquí en lugar de en línea).
Ese es un buen punto. Para entender esto, piense en un escenario HTTP tradicional ... Imagine que un navegador abre una página web, por lo que solicita http://example.com , digamos. 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 archivos CSS, archivos JavaScript e 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é los 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 almacenamiento en caché y es una gran estrategia para descargar solicitudes y procesamiento de sus servicios centrales.
Entonces el cliente # 1 solicita http://example.com/images/logo.gif , digamos. Esa solicitud pasa por el proxy hasta el servidor web central, que sirve logo.gif. A medida que logo.gif pasa a través del proxy, el proxy guardará esa imagen y la asociará con la dirección http://example.com/images/logo.gif .
Cuando aparece el cliente # 2 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 le da una respuesta más rápida al usuario final, lo que siempre es genial, pero también significa que hay menos carga en el centro. Eso puede traducirse en costos de hardware reducidos, costos de redes reducidos, etc. Así que es algo bueno.
El problema surge cuando logo.gif se actualiza en el servidor web. El proxy seguirá sirviendo la imagen anterior sin saber que hay una nueva imagen. Esto conduce a una cuestión de caducidad, de modo que el proxy solo almacenará en caché la imagen durante un breve período de tiempo antes de que "caduque" y la siguiente solicitud pase por el proxy al servidor web, que luego actualiza la 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 su pregunta?
Preguntó acerca de 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 deja de enviar datos. Si un servidor web sirve una imagen, envía HTTP al cliente que finalmente termina: ha enviado la imagen completa. Y si desea enviar datos, es exactamente lo mismo, pero el servidor solo 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 la transmisión HTTP. En ambos casos, el cliente hizo una solicitud al servidor. El apoderado recordó esa solicitud y también la respuesta. La próxima vez que llegue esa 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 sea lo que quieres! Si solicita precios de acciones, desea los datos más recientes, ¿verdad?
Entonces es un problema.
Hay trucos y soluciones para manejar problemas como ese, es cierto. Obviamente, puede hacer que funcione la transmisión HTTP, 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 superar obstáculos y pagar un precio. Da como resultado arquitecturas demasiado complicadas, lo que significa más mantenimiento, más hardware, más complejidad, más costo. También significa que los desarrolladores a menudo tienen que preocuparse por algo que no deberían tener cuando solo deberían centrarse en la aplicación, la GUI y la lógica empresarial; no deberían tener que preocuparse por la comunicación subyacente.
fuente
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 sabe que IE hace cumplir esto con entusiasmo. Firefox y Chrome permiten más (aunque no puedo recordar exactamente cuántos). Puede que esto no parezca un gran problema, pero si está utilizando una conexión constantemente para actualizaciones en tiempo real, todas las demás solicitudes deben atravesar el cuello de botella de 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.
Los WebSockets son un protocolo basado en TCP y, como tal, no sufren este límite de conexión a nivel HTTP (pero, por supuesto, el soporte del navegador no es uniforme).
fuente