La tecnología Push, también conocida como Server Push, se refiere a un método de comunicación en el que la comunicación la inicia un servidor en lugar de un cliente. Este enfoque es diferente del método " pull ", en el que la comunicación la inicia un cliente. [1]
En la tecnología push, los clientes pueden expresar sus preferencias por determinados tipos de información o datos, normalmente a través de un proceso conocido como modelo de publicación-suscripción . En este modelo, un cliente se "suscribe" a canales de información específicos alojados en un servidor. Cuando hay nuevo contenido disponible en estos canales, el servidor envía automáticamente, o "envía", esta información al cliente suscrito.
En determinadas condiciones, como políticas de seguridad restrictivas que bloquean las solicitudes HTTP entrantes , a veces se simula la tecnología push mediante una técnica denominada sondeo. En estos casos, el cliente consulta periódicamente al servidor para ver si hay nueva información disponible, en lugar de recibir actualizaciones automáticas.
Las conferencias sincrónicas y la mensajería instantánea son ejemplos de servicios push. Los mensajes de chat y, a veces, los archivos se envían al usuario tan pronto como los recibe el servicio de mensajería. Tanto los programas peer-to-peer descentralizados (como WASTE ) como los programas centralizados (como IRC o XMPP ) permiten enviar archivos, lo que significa que el remitente inicia la transferencia de datos en lugar del destinatario.
El correo electrónico también puede ser un sistema push: SMTP es un protocolo push (ver Push e-mail ). Sin embargo, el último paso (del servidor de correo al ordenador de sobremesa) suele utilizar un protocolo pull como POP3 o IMAP . Los clientes de correo electrónico modernos hacen que este paso parezca instantáneo sondeando repetidamente el servidor de correo y comprobándolo con frecuencia para ver si hay correo nuevo. El protocolo IMAP incluye el comando IDLE , que permite al servidor informar al cliente cuando llegan mensajes nuevos. El BlackBerry original fue el primer ejemplo popular de correo electrónico push en un contexto inalámbrico. [ cita requerida ]
Otro ejemplo es la red PointCast , que tuvo una amplia cobertura en los años 90. Entregaba noticias y datos del mercado de valores como salvapantallas. Tanto Netscape como Microsoft integraron la tecnología push a través del Channel Definition Format (CDF) en su software en el apogeo de las guerras de navegadores , pero nunca fue muy popular. El CDF desapareció y fue eliminado de los navegadores de la época, reemplazado en los años 2000 por RSS (un sistema pull).
Otros usos de las aplicaciones web habilitadas para push incluyen la distribución de actualizaciones de software ("actualizaciones push"), distribución de datos de mercado (tickers de acciones), sistemas de chat/mensajería en línea ( webchat ), subastas, apuestas y juegos en línea, resultados deportivos, consolas de monitoreo y monitoreo de redes de sensores .
La propuesta Web Push del Grupo de Trabajo de Ingeniería de Internet es un protocolo simple que utiliza la versión 2 de HTTP para enviar eventos en tiempo real, como llamadas entrantes o mensajes, que pueden entregarse (o "enviarse") de manera oportuna. El protocolo consolida todos los eventos en tiempo real en una sola sesión, lo que garantiza un uso más eficiente de los recursos de red y radio. Un solo servicio consolida todos los eventos y los distribuye a las aplicaciones a medida que llegan. Esto requiere solo una sesión, lo que evita costos indirectos duplicados. [2]
Las notificaciones web forman parte del estándar W3C y definen una API para notificaciones al usuario final. Una notificación permite alertar al usuario de un evento, como la entrega de un correo electrónico, fuera del contexto de una página web. [3] Como parte de este estándar, Push API está completamente implementada en Chrome , Firefox y Edge , y parcialmente implementada en Safari a partir de febrero de 2023. [actualizar][ 4] [5]
El envío de datos mediante HTTP (también conocido como transmisión HTTP) es un mecanismo para enviar datos no solicitados (asincrónicos) desde un servidor web a un navegador web . El envío de datos mediante HTTP se puede lograr a través de varios mecanismos.
Como parte de HTML5, la API Web Socket permite que un servidor web y un cliente se comuniquen a través de una conexión TCP dúplex completa .
Generalmente, el servidor web no termina una conexión después de que se hayan entregado los datos de respuesta a un cliente. El servidor web deja la conexión abierta de modo que si ocurre un evento (por ejemplo, un cambio en los datos internos que se debe informar a uno o varios clientes), se pueda enviar de inmediato; de lo contrario, el evento tendría que quedar en cola hasta que se reciba la siguiente solicitud del cliente. La mayoría de los servidores web ofrecen esta funcionalidad a través de CGI (por ejemplo, scripts de encabezados no analizados en Apache HTTP Server ). El mecanismo subyacente para este enfoque es la codificación de transferencia fragmentada .
Otro mecanismo está relacionado con un tipo MIMEmultipart/x-mixed-replace especial llamado , que fue introducido por Netscape en 1995. Los navegadores web lo interpretan como un documento que cambia cada vez que el servidor envía una nueva versión al cliente. [6] Todavía es compatible con Firefox , Opera y Safari en la actualidad, pero Internet Explorer lo ignora [7] y Chrome solo lo admite parcialmente . [8] Se puede aplicar a documentos HTML y también para transmitir imágenes en aplicaciones de cámara web .
La propuesta de Aplicaciones Web 1.0 de WHATWG [9] incluye un mecanismo para enviar contenido al cliente. El 1 de septiembre de 2006, el navegador web Opera implementó este nuevo sistema experimental en una función llamada " Eventos enviados por el servidor ". [10] [11] Ahora es parte del estándar HTML5 . [12]
En esta técnica, el servidor aprovecha las conexiones HTTP persistentes , dejando la respuesta perpetuamente "abierta" (es decir, el servidor nunca termina la respuesta), engañando efectivamente al navegador para que permanezca en modo "cargando" después de que la carga de la página inicial podría considerarse completa. Luego, el servidor envía periódicamente fragmentos de JavaScript para actualizar el contenido de la página, logrando así la capacidad de push. Al usar esta técnica, el cliente no necesita applets de Java u otros complementos para mantener una conexión abierta con el servidor; el cliente es notificado automáticamente sobre nuevos eventos, pusheados por el servidor. [13] [14] Sin embargo, un inconveniente grave de este método es la falta de control que tiene el servidor sobre el tiempo de espera del navegador; siempre es necesaria una actualización de la página si se produce un tiempo de espera en el extremo del navegador.
El sondeo largo en sí no es un verdadero push; el sondeo largo es una variación de la técnica de sondeo tradicional, pero permite emular un mecanismo push en circunstancias donde un push real no es posible, como sitios con políticas de seguridad que requieren el rechazo de solicitudes HTTP entrantes.
En el sondeo largo, el cliente solicita más información del servidor exactamente como en el sondeo normal, pero con la expectativa de que el servidor no responda inmediatamente. Si el servidor no tiene información nueva para el cliente cuando se recibe el sondeo, entonces en lugar de enviar una respuesta vacía, el servidor mantiene abierta la solicitud y espera a que la información de respuesta esté disponible. Una vez que tiene nueva información, el servidor envía inmediatamente una respuesta HTTP al cliente, completando la solicitud HTTP abierta. Al recibir la respuesta del servidor, el cliente a menudo envía inmediatamente otra solicitud al servidor. De esta manera se elimina la latencia de respuesta habitual (el tiempo entre cuando la información está disponible por primera vez y la siguiente solicitud del cliente) asociada de otro modo con el sondeo de clientes. [15]
Por ejemplo, BOSH es una técnica HTTP popular y de larga duración que se utiliza como una alternativa de sondeo prolongado a una conexión TCP continua cuando dicha conexión es difícil o imposible de emplear directamente (por ejemplo, en un navegador web); [16] también es una tecnología subyacente en XMPP , que Apple utiliza para su soporte push de iCloud.
Esta técnica, utilizada por las aplicaciones de chat , hace uso del objeto XML Socket en una película Adobe Flash de un solo píxel. Bajo el control de JavaScript , el cliente establece una conexión TCP con un relé unidireccional en el servidor. El servidor de retransmisión no lee nada de este socket ; en su lugar, envía inmediatamente al cliente un identificador único . A continuación, el cliente realiza una solicitud HTTP al servidor web, incluyendo este identificador con ella. La aplicación web puede entonces enviar mensajes dirigidos al cliente a una interfaz local del servidor de retransmisión, que los retransmite a través del socket Flash. La ventaja de este enfoque es que aprecia la asimetría natural de lectura y escritura que es típica de muchas aplicaciones web, incluido el chat, y como consecuencia ofrece una alta eficiencia. Dado que no acepta datos sobre sockets salientes, el servidor de retransmisión no necesita sondear las conexiones TCP salientes en absoluto , lo que hace posible mantener abiertas decenas de miles de conexiones simultáneas. En este modelo, el límite para escalar es la pila TCP del sistema operativo del servidor subyacente.
En servicios como la computación en la nube , para aumentar la confiabilidad y disponibilidad de los datos, generalmente se envían (replican) a varias máquinas. Por ejemplo, el sistema de archivos distribuidos Hadoop (HDFS) realiza 2 copias adicionales de cualquier objeto almacenado. RGDD se enfoca en transmitir de manera eficiente un objeto desde una ubicación a muchas mientras se ahorra ancho de banda al enviar una cantidad mínima de copias (solo una en el mejor de los casos) del objeto a través de cualquier enlace a través de la red. Por ejemplo, Datacast [17] es un esquema para la entrega a muchos nodos dentro de centros de datos que se basa en topologías regulares y estructuradas y DCCast [18] es un enfoque similar para la entrega a través de centros de datos.
Una notificación push es un mensaje que se "envía" desde un servidor o aplicación back-end a una interfaz de usuario, por ejemplo, aplicaciones móviles [19] o aplicaciones de escritorio. Apple introdujo las notificaciones push para iPhone en 2009, [20] y en 2010 Google lanzó "Google Cloud to Device Messaging" (reemplazado por Google Cloud Messaging y luego por Firebase Cloud Messaging ). [21] En noviembre de 2015, Microsoft anunció que el Servicio de notificaciones de Windows se ampliaría para hacer uso de la arquitectura de la Plataforma universal de Windows, lo que permitiría enviar datos push a Windows 10 , Windows 10 Mobile , Xbox y otras plataformas compatibles mediante llamadas API universales y solicitudes POST. [22]
Las notificaciones push se dividen principalmente en dos enfoques: notificaciones locales y notificaciones remotas. [23] En el caso de las notificaciones locales, la aplicación programa la notificación con el sistema operativo del dispositivo local. En el caso de las notificaciones remotas, la aplicación establece un temporizador en la propia aplicación, siempre que pueda ejecutarse continuamente en segundo plano. Cuando se alcanza la hora programada del evento o se cumple la condición programada del evento, el mensaje se muestra en la interfaz de usuario de la aplicación.
Las notificaciones remotas son manejadas por un servidor remoto. Bajo este escenario, la aplicación cliente necesita estar registrada en el servidor con una clave única (por ejemplo, un UUID ). El servidor luego envía el mensaje contra la clave única para entregarlo al cliente a través de un protocolo cliente/servidor acordado como HTTP o XMPP , y el cliente muestra el mensaje recibido. Cuando llega la notificación push, puede transmitir notificaciones y mensajes cortos, establecer insignias en los íconos de la aplicación, hacer parpadear o encender continuamente el LED de notificación , o reproducir sonidos de alerta para atraer la atención del usuario. [24] Las aplicaciones suelen utilizar las notificaciones push para llamar la atención de los usuarios. El contenido de los mensajes se puede clasificar en las siguientes categorías de ejemplo:
Las notificaciones push en tiempo real pueden plantear problemas de privacidad, ya que pueden utilizarse para vincular identidades virtuales de seudónimos de redes sociales a las identidades reales de los propietarios de teléfonos inteligentes. [26] El uso de notificaciones push innecesarias con fines promocionales ha sido criticado como un ejemplo de robo de atención. [27]