La tecnología push, también conocida como push de servidor, 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 ", donde la comunicación la inicia un cliente. [1]
En la tecnología push, los clientes pueden expresar sus preferencias por ciertos tipos de información o datos, generalmente 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 , la tecnología push a veces se simula mediante una técnica llamada sondeo. En estos casos, el cliente consulta periódicamente con el servidor para ver si hay nueva información disponible, en lugar de recibir actualizaciones automáticas.
Las conferencias síncronas 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 descentralizados peer-to-peer (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 (consulte Correo electrónico push ). Sin embargo, el último paso (del servidor de correo a la computadora de escritorio) generalmente utiliza un protocolo de extracción 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 comprobando con frecuencia si hay correo nuevo. El protocolo IMAP incluye el comando IDLE , que permite al servidor avisar al cliente cuando llegan nuevos mensajes. El BlackBerry original fue el primer ejemplo popular de correo electrónico push en un contexto inalámbrico. [ cita necesaria ]
Otro ejemplo es PointCast Network , que tuvo una amplia cobertura en la década de 1990. Entregaba noticias y datos del mercado de valores como salvapantallas. Tanto Netscape como Microsoft integraron la tecnología push a través del formato de definición de canal (CDF) en su software en el apogeo de la guerra de los navegadores , pero nunca fue muy popular. CDF desapareció y fue eliminado de los navegadores de la época, reemplazado en la década de 2000 por RSS (un sistema de extracción).
Otros usos de las aplicaciones web habilitadas para push incluyen distribución de actualizaciones de software ("actualizaciones push"), distribución de datos de mercado (tickers bursátiles), sistemas de chat/mensajería en línea ( chat web ), subastas, apuestas y juegos en línea, resultados deportivos, consolas de monitoreo y Monitoreo de la red de sensores .
La propuesta de envío web del Grupo de Trabajo de Ingeniería de Internet es un protocolo simple que utiliza HTTP versión 2 para entregar eventos en tiempo real, como llamadas o mensajes entrantes, 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 único servicio consolida todos los eventos y los distribuye a las aplicaciones a medida que llegan. Esto requiere solo una sesión, evitando costos generales duplicados. [2]
Las notificaciones web son 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 implementado en Chrome , Firefox y Edge , y parcialmente implementado en Safari a partir de febrero de 2023 [actualizar]. [4] [5]
La inserción del servidor HTTP (también conocida como transmisión HTTP) es un mecanismo para enviar datos no solicitados (asincrónicos) desde un servidor web a un navegador web . La inserción del servidor HTTP se puede lograr mediante cualquiera 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 full-duplex .
Generalmente, el servidor web no finaliza una conexión después de que los datos de respuesta se han entregado a un cliente. El servidor web deja la conexión abierta para que, si ocurre un evento (por ejemplo, un cambio en los datos internos que deben informarse a uno o varios clientes), se pueda enviar inmediatamente; de lo contrario, el evento tendría que ponerse 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 el servidor HTTP Apache ). El mecanismo subyacente de este enfoque es la codificación de transferencia fragmentada .
Otro mecanismo está relacionado con un tipo MIME especial llamado multipart/x-mixed-replace, que fue introducido por Netscape en 1995. Los navegadores web interpretan esto 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 hoy en día, 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 WHATWG Web Applications 1.0 [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 finaliza la respuesta), engañando efectivamente al navegador para que permanezca en modo "cargando" después de que se pueda considerar la carga inicial de la página. completo. Luego, el servidor envía periódicamente fragmentos de JavaScript para actualizar el contenido de la página, logrando así la capacidad de inserción. Al utilizar esta técnica, el cliente no necesita subprogramas de Java u otros complementos para mantener una conexión abierta con el servidor; el cliente recibe notificaciones automáticas sobre nuevos eventos, impulsados por el servidor. [13] [14] Sin embargo, un serio inconveniente 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 agota el tiempo de espera en el extremo del navegador.
Las encuestas largas en sí mismas no son un verdadero impulso; El sondeo largo es una variación de la técnica de sondeo tradicional, pero permite emular un mecanismo de envío en circunstancias en las que un envío real no es posible, como sitios con políticas de seguridad que requieren el rechazo de solicitudes HTTP entrantes.
Con un sondeo largo, el cliente solicita obtener más información del servidor exactamente como en un 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 la encuesta, entonces, en lugar de enviar una respuesta vacía, el servidor mantiene abierta la solicitud y espera a que la información de la 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 suele emitir inmediatamente otra solicitud del servidor. De esta manera, se elimina la latencia de respuesta habitual (el tiempo entre el momento en que la información está disponible por primera vez y la siguiente solicitud del cliente) asociada con los clientes de sondeo. [15]
Por ejemplo, BOSH es una técnica HTTP popular y de larga duración que se utiliza como 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 de iCloud Push.
Esta técnica, utilizada por las aplicaciones de chat , utiliza el 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 a 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. Luego, la aplicación web puede 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 típica de muchas aplicaciones web, incluido el chat, y, como consecuencia, ofrece una alta eficiencia. Dado que no acepta datos en sockets salientes, el servidor de retransmisión no necesita sondear las conexiones TCP salientes , lo que permite mantener abiertas decenas de miles de conexiones simultáneas. En este modelo, el límite de escala es la pila TCP del sistema operativo del servidor subyacente.
En servicios como Cloud Computing , para aumentar la confiabilidad y disponibilidad de los datos, generalmente se envían (replican) a varias máquinas. Por ejemplo, el sistema de archivos distribuido de 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 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 entre centros de datos.
Una notificación push es un mensaje que se "envía" desde una aplicación o servidor back-end a una interfaz de usuario, por ejemplo, aplicaciones móviles [19] o aplicaciones de escritorio. Apple introdujo notificaciones automáticas 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 el uso universal. Llamadas API y solicitudes POST. [22]
Las notificaciones push se dividen principalmente en dos enfoques, notificaciones locales y notificaciones remotas. [23] Para notificaciones locales, la aplicación programa la notificación con el sistema operativo del dispositivo local. Para 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. En este escenario, la aplicación cliente debe registrarse en el servidor con una clave única (por ejemplo, un UUID ). Luego, el servidor 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 automática, puede transmitir notificaciones y mensajes breves, configurar insignias en los íconos de las aplicaciones, parpadear o iluminar continuamente el LED de notificación o reproducir sonidos de alerta para atraer la atención del usuario. [24] [ enlace muerto permanente ] Las aplicaciones suelen utilizar notificaciones automáticas para llamar la atención de los usuarios sobre información. El contenido de los mensajes se puede clasificar en las siguientes categorías de ejemplo:
Las notificaciones automáticas en tiempo real pueden plantear problemas de privacidad, ya que pueden usarse para vincular identidades virtuales de seudónimos de redes sociales con 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]
{{cite journal}}: Citar diario requiere |journal=( ayuda )