Comet es un modelo de aplicación web en el que una solicitud HTTPS de larga duración permite a un servidor web enviar datos a un navegador , sin que el navegador los solicite explícitamente. [1] [2] Comet es un término general que abarca múltiples técnicas para lograr esta interacción. Todos estos métodos se basan en funciones incluidas de forma predeterminada en los navegadores, como JavaScript , en lugar de en complementos no predeterminados. El enfoque de Comet difiere del modelo original de la web , en el que un navegador solicita una página web completa a la vez. [3]
El uso de las técnicas Comet en el desarrollo web es anterior al uso de la palabra Comet como neologismo para las técnicas colectivas. Comet es conocido por otros nombres, entre ellos Ajax Push , [4] [5] Reverse Ajax , [6] Two-way-web , [7] HTTP Streaming , [7] y HTTP server push [8], entre otros. [9] El término Comet no es un acrónimo, sino que fue acuñado por Alex Russell en su publicación de blog de 2006. [a] [ cita requerida ]
En los últimos años, la estandarización y el soporte generalizado de WebSocket y eventos enviados por el servidor han dejado obsoleto el modelo Comet.
La capacidad de incorporar applets de Java en los navegadores (a partir de Netscape Navigator 2.0 en marzo de 1996 [10] ) hizo posible la comunicación bidireccional sostenida, utilizando un socket TCP sin formato [11] para comunicarse entre el navegador y el servidor. Este socket puede permanecer abierto mientras el navegador esté en el documento que aloja el applet. Las notificaciones de eventos se pueden enviar en cualquier formato (texto o binario) y el applet las puede decodificar.
La primera aplicación que utilizó comunicaciones de navegador a navegador fue Tango Interactive, [12] [ verificación fallida ] implementada en 1996-98 en el Centro de Arquitecturas Paralelas del Noreste (NPAC) en la Universidad de Syracuse utilizando fondos de DARPA . La arquitectura TANGO ha sido patentada por la Universidad de Syracuse. [13] El marco TANGO se ha utilizado ampliamente como una herramienta de educación a distancia. [14] El marco ha sido comercializado por CollabWorx y se ha utilizado en una docena de aplicaciones de Comando y Control y Entrenamiento en el Departamento de Defensa de los Estados Unidos [ cita requerida ] .
El primer conjunto de implementaciones de Comet se remonta al año 2000, [15] [ ¿fuente poco fiable? ] con los proyectos Pushlets , Lightstreamer y KnowNow. Pushlets , un marco creado por Just van den Broecke, fue una de las primeras [16] implementaciones de código abierto. Pushlets se basaba en servlets Java del lado del servidor y una biblioteca JavaScript del lado del cliente. Bang Networks, una start-up de Silicon Valley respaldada por el cofundador de Netscape , Marc Andreessen , tuvo un intento financiado generosamente de crear un estándar de push en tiempo real para toda la web. [17]
En abril de 2001, Chip Morningstar comenzó a desarrollar un servidor web basado en Java (J2SE) que utilizaba dos conectores HTTP para mantener abiertos dos canales de comunicación entre el servidor HTTP personalizado que él había diseñado y un cliente diseñado por Douglas Crockford ; en junio de 2001 ya existía un sistema de demostración en funcionamiento. [ cita requerida ] El servidor y el cliente utilizaban un formato de mensajería que los fundadores de State Software, Inc. aceptaron acuñar como JSON siguiendo la sugerencia de Crockford. Todo el sistema, las bibliotecas de cliente, el formato de mensajería conocido como JSON y el servidor se convirtieron en el State Application Framework, partes del cual fueron vendidas y utilizadas por Sun Microsystems, Amazon.com, EDS y Volkswagen. [ cita requerida ]
En marzo de 2006, el ingeniero de software Alex Russell acuñó el término Comet en una publicación en su blog personal. [18] El nuevo término era un juego de palabras con Ajax ( Ajax y Comet son limpiadores domésticos comunes en los EE. UU.). [19] [20] [21]
En 2006, algunas aplicaciones expusieron esas técnicas a un público más amplio: la aplicación de chat basada en web multiprotocolo de Meebo permitió a los usuarios conectarse a las plataformas de chat de AOL , Yahoo y Microsoft a través del navegador; Google agregó chat basado en web a Gmail ; JotSpot , una startup adquirida posteriormente por Google, construyó una edición colaborativa de documentos en tiempo real basada en Comet. [22] Se crearon nuevas variantes de Comet, como el marco JSF ICEfaces basado en Java (aunque prefieren el término " Ajax Push " [5] ). Otros que habían utilizado anteriormente transportes basados en subprogramas Java cambiaron a implementaciones puramente JavaScript. [23]
Las aplicaciones Comet intentan eliminar las limitaciones del modelo web página por página y del sondeo tradicional ofreciendo una interacción sostenida bidireccional, utilizando una conexión HTTP persistente o duradera entre el servidor y el cliente. Dado que los navegadores y los servidores proxy no están diseñados teniendo en cuenta los eventos del servidor, se han desarrollado varias técnicas para lograrlo, cada una con diferentes beneficios y desventajas. El mayor obstáculo es la especificación HTTP 1.1, que establece que "esta especificación... alienta a los clientes a ser conservadores al abrir múltiples conexiones". [24] Por lo tanto, mantener una conexión abierta para eventos en tiempo real tiene un impacto negativo en la usabilidad del navegador: el navegador puede quedar bloqueado y no puede enviar una nueva solicitud mientras espera los resultados de una solicitud anterior, por ejemplo, una serie de imágenes. Esto se puede solucionar creando un nombre de host distinto para la información en tiempo real, que es un alias para el mismo servidor físico. Esta estrategia es una aplicación de fragmentación de dominios.
Los métodos específicos de implementación de Comet se dividen en dos categorías principales: streaming y sondeo largo .
Una aplicación que utiliza Comet en streaming abre una única conexión persistente desde el navegador del cliente al servidor para todos los eventos de Comet . Estos eventos se gestionan e interpretan de forma incremental en el lado del cliente cada vez que el servidor envía un nuevo evento, sin que ninguno de los dos lados cierre la conexión. [3]
Las técnicas específicas para lograr el streaming de Comet incluyen las siguientes:
Una técnica básica para aplicaciones web dinámicas es utilizar un elemento HTML iframe oculto (un marco en línea , que permite a un sitio web incrustar un documento HTML dentro de otro). Este iframe invisible se envía como un bloque fragmentado , que implícitamente lo declara como infinitamente largo (a veces llamado "marco para siempre"). A medida que ocurren los eventos, el iframe se llena gradualmente con scriptetiquetas, que contienen JavaScript para ser ejecutado en el navegador. Debido a que los navegadores procesan las páginas HTML de forma incremental, cada scriptetiqueta se ejecuta a medida que se recibe. Algunos navegadores requieren un tamaño de documento mínimo específico antes de que se inicie el análisis y la ejecución, que se puede obtener enviando inicialmente 1–2 kB de espacios de relleno. [25]
Una ventaja del método iframes es que funciona en todos los navegadores comunes. Dos desventajas de esta técnica son la falta de un método confiable de manejo de errores y la imposibilidad de rastrear el estado del proceso de llamada de la solicitud. [25]
El objeto XMLHttpRequest (XHR), una herramienta utilizada por las aplicaciones Ajax para la comunicación entre navegador y servidor, también se puede utilizar para la mensajería Comet entre servidor y navegador generando un formato de datos personalizado para una respuesta XHR y analizando cada evento mediante JavaScript del lado del navegador; confiando únicamente en que el navegador active la onreadystatechangedevolución de llamada cada vez que recibe nuevos datos.
Ninguno de los transportes de streaming anteriores funciona en todos los navegadores modernos sin efectos secundarios negativos. Esto obliga a los desarrolladores de Comet a implementar varios transportes de streaming complejos, alternando entre ellos según el navegador. En consecuencia, muchas aplicaciones Comet utilizan sondeos largos, que son más fáciles de implementar en el lado del navegador y funcionan, como mínimo, en todos los navegadores que admiten XHR. Como sugiere el nombre, el sondeo largo requiere que el cliente sondee al servidor para un evento (o un conjunto de eventos). El navegador realiza una solicitud de estilo Ajax al servidor, que se mantiene abierta hasta que el servidor tenga nuevos datos para enviar al navegador, que se envían al navegador en una respuesta completa. El navegador inicia una nueva solicitud de sondeo largo para obtener eventos posteriores. La RFC 6202 de IETF "Problemas conocidos y mejores prácticas para el uso de sondeo largo y streaming en HTTP bidireccional" compara el sondeo largo y el streaming HTTP. Las tecnologías específicas para lograr el sondeo largo incluyen las siguientes:
En su mayor parte, el sondeo largo de XMLHttpRequest funciona como cualquier uso estándar de XHR. El navegador realiza una solicitud asincrónica al servidor, que puede esperar a que los datos estén disponibles antes de responder. La respuesta puede contener datos codificados (normalmente XML o JSON ) o Javascript para que el cliente los ejecute. Al final del procesamiento de la respuesta, el navegador crea y envía otro XHR, a la espera del próximo evento. De este modo, el navegador siempre mantiene una solicitud pendiente en el servidor, que debe responderse cuando se produce cada evento.
Si bien cualquier transporte Comet puede funcionar en subdominios , ninguno de los transportes anteriores se puede utilizar en diferentes dominios de segundo nivel (SLD), debido a las políticas de seguridad del navegador diseñadas para evitar ataques de secuencias de comandos entre sitios . [26] Es decir, si la página web principal se sirve desde un SLD y el servidor Comet está ubicado en otro SLD (que no tiene habilitado el uso compartido de recursos de origen cruzado ), los eventos Comet no se pueden usar para modificar el HTML y el DOM de la página principal, utilizando esos transportes. Este problema se puede evitar creando un servidor proxy frente a una o ambas fuentes, lo que hace que parezcan originarse en el mismo dominio. Sin embargo, esto a menudo no es deseable por razones de complejidad o rendimiento.
A diferencia de los iframes o los objetos XMLHttpRequest, scriptlas etiquetas pueden apuntar a cualquier URI y el código JavaScript de la respuesta se ejecutará en el documento HTML actual. Esto crea un riesgo de seguridad potencial para ambos servidores involucrados, aunque el riesgo para el proveedor de datos (en nuestro caso, el servidor Comet) se puede evitar utilizando JSONP .
Se puede crear un transporte Comet de sondeo largo creando scriptelementos dinámicamente y estableciendo su origen en la ubicación del servidor Comet, que luego envía JavaScript (o JSONP) con algún evento como su carga útil. Cada vez que se completa la solicitud de script, el navegador abre uno nuevo, al igual que en el caso del sondeo largo XHR. Este método tiene la ventaja de ser multinavegador y, al mismo tiempo, permite implementaciones multidominio. [26]
Las tecnologías nativas del navegador son inherentes al término Comet. Los intentos de mejorar la comunicación HTTP sin sondeo han surgido de múltiples lados:
EventSourcey un nuevo tipo MIME text/event-stream. Todos los navegadores principales, excepto Microsoft Internet Explorer, incluyen esta tecnología.onmessage{{cite speech}}: Mantenimiento de CS1: ubicación ( enlace ){{cite web}}: CS1 maint: bot: estado de URL original desconocido ( enlace )API ha quedado obsoleta.
Daily ofrece información sobre las técnicas de Comet.*