ES2830598T3 - Sistema de comunicación en red con protocolo push web - Google Patents

Sistema de comunicación en red con protocolo push web Download PDF

Info

Publication number
ES2830598T3
ES2830598T3 ES17155705T ES17155705T ES2830598T3 ES 2830598 T3 ES2830598 T3 ES 2830598T3 ES 17155705 T ES17155705 T ES 17155705T ES 17155705 T ES17155705 T ES 17155705T ES 2830598 T3 ES2830598 T3 ES 2830598T3
Authority
ES
Spain
Prior art keywords
proxy device
response
request
proxy
computer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES17155705T
Other languages
English (en)
Inventor
Claudio Vignali
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Global Eagle Entertainment Inc
Original Assignee
Global Eagle Entertainment Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Global Eagle Entertainment Inc filed Critical Global Eagle Entertainment Inc
Application granted granted Critical
Publication of ES2830598T3 publication Critical patent/ES2830598T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/2895—Intermediate processing functionally located close to the data provider application, e.g. reverse proxies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B7/00—Radio transmission systems, i.e. using radiation field
    • H04B7/14—Relay systems
    • H04B7/15—Active relay systems
    • H04B7/185—Space-based or airborne stations; Stations for satellite systems
    • H04B7/1851—Systems using a satellite or space-based relay
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/2876—Pairs of inter-processing entities at each side of the network, e.g. split proxies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/289—Intermediate processing functionally located close to the data consumer application, e.g. in same machine, in same home or in same sub-network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H04L67/5681—Pre-fetching or pre-delivering data based on network characteristics

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Astronomy & Astrophysics (AREA)
  • Aviation & Aerospace Engineering (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)

Abstract

Un sistema para comunicar datos (200) desde un primer ordenador (210) a un segundo ordenador (240) ubicado remotamente del primer ordenador (210), comprendiendo el sistema (200): un primer dispositivo proxy (220) configurado para recibir una solicitud desde el primer ordenador (210) y transmitir la solicitud a través de un enlace por satélite; y un segundo dispositivo proxy (230) configurado para recibir la solicitud desde el primer dispositivo proxy (220) a través del enlace por satélite y transmitir la solicitud al segundo ordenador (240) a través de una conexión de alta velocidad, recibiendo dicho segundo dispositivo proxy (230) una respuesta desde el segundo ordenador (240) y transmitiendo la respuesta a través del enlace por satélite; estando dicho primer dispositivo proxy (220) configurado además para recibir la respuesta desde el segundo dispositivo proxy (240) a través del enlace por satélite y transmitir la respuesta al primer ordenador (210); un rastreador y multidifusor (250), en comunicación con el segundo dispositivo proxy (230), configurado para revisar la solicitud y comparar los datos buscados por la solicitud con una base de datos de solicitudes populares y, cuando la solicitud busca datos que aparecen en la base de datos de solicitudes populares, indicar al segundo dispositivo proxy (230) que transmita la respuesta desde el segundo dispositivo proxy (230) a varios primeros dispositivos proxy (220) utilizando multidifusión, en el que el primer dispositivo proxy (220) está configurado además para: determinar si el enlace por satélite falla durante la transmisión de la respuesta; en respuesta a determinar que el enlace satelital falló, monitorizar cuándo se restablecen las conexiones estáticas entre el primer dispositivo proxy (220) y el segundo dispositivo proxy (230) a través del enlace por satélite y enviar una señal de reanudación con un último byte recibido al segundo dispositivo proxy (230); y en respuesta a cerrar una conexión desde el primer ordenador (210) al primer dispositivo proxy (220) antes de restablecer las conexiones estáticas, no enviar la señal de reanudación al segundo dispositivo proxy (230), en el que el segundo dispositivo proxy (230) está configurado además para: determinar si el enlace por satélite falla durante la transmisión de la respuesta; en respuesta a la determinación de que el enlace por satélite falló, reducir la velocidad de recepción de la respuesta desde el segundo ordenador (240) para mantener una conexión establecida con el segundo ordenador (240) y guardar la respuesta en un dispositivo de almacenamiento durante un período de tiempo predeterminado; recibir la señal de reanudación desde el primer dispositivo proxy (220); en respuesta a recibir la señal de reanudación, continuar transmitiendo la respuesta al primer dispositivo proxy (220); y descartar la respuesta en el dispositivo de almacenamiento si la señal de reanudación no se recibe dentro del período de tiempo predeterminado.

Description

DESCRIPCIÓN
Sistema de comunicación en red con protocolo push web
Antecedentes de la invención
Solicitud relacionada
Esta solicitud reivindica el beneficio de la Solicitud Provisional de Estados Unidos n.° 62/295.399, presentada el 15 de febrero de 2016.
Campo de la invención
La presente invención se refiere a comunicaciones en red. Más particularmente, la presente invención se refiere a la comunicación de información de sitios web e Internet por satélite.
Antecedentes de la técnica relacionada
Los dispositivos de cliente llamados "navegadores web" a menudo reciben y solicitan información desde dispositivos de servidor en redes informáticas. El uso de la World Wide Web es un ejemplo común de interacción cliente-servidor. Al utilizar la Web, el cliente o "navegador web" incrustará objetos de red desde un servidor web (sitio web) y también solicitará páginas web.
La figura 2 muestra la operación general para que un terminal de usuario 110 solicite y reciba información desde un servidor web 120. Comenzando en el tiempo T0, el usuario ingresa a un sitio web, tal como ingresando un nombre de dominio (por ejemplo, www.EMCSatcom.com) en el cuadro de entrada de dirección de dominio de un navegador web o haciendo clic en un enlace a un dominio determinado. En respuesta, el terminal 110 realiza una búsqueda en el Sistema de Nombres de Dominio (DNS), por lo que el terminal 110 determina la dirección IP asociada con el nombre de dominio solicitado. El tiempo desde T0 a T1 representa la búsqueda de DNS y el tiempo de conexión.
En el tiempo T1, el terminal 110 tiene la dirección IP y está conectado al servidor web, y envía un comando OBTENER HTTP 112 al servidor web 120. El comando OBTENER HTTP 112 (por ejemplo, "OBTENER www.emcsatcom.com") solicita ciertos datos desde el servidor web 120, por ejemplo, la página de inicio de un sitio web particular. En el tiempo T2 , el servidor 120 recibe el comando 112 en el servidor web 120. El período de tiempo desde T1 a T2 es la latencia inicial del sistema, que es de aproximadamente 300 ms para satélite (600 ms RTT de ida y vuelta). En el tiempo T3, el servidor web 120 ha procesado la información y transmite una respuesta al comando 112 con una RESPUESTA HTML 122 al servidor. En el tiempo T4, el terminal 110 recibe la RESPUESTA HTML 122, y en el tiempo T5 ha analizado el HTML y el terminal 110 comienza a enviar comandos de solicitud en la señal 114 para obtener la información necesaria para el sitio web al que se accede, tal como imágenes, javascripts y CSS (hoja de estilo en cascada) (que se denomina colectivamente aquí como "objetos" y está representado por los objetos 1-6 en las figuras).
El navegador abre una serie de conexiones paralelas para la cantidad de objetos en una página (generalmente alrededor de seis) y envía una solicitud para cada objeto. En el tiempo Te, el servidor 120 recibe las solicitudes 114, y en el tiempo T7 envía los objetos solicitados 124. En el tiempo T8, el terminal 110 recibe las imágenes iniciales 1-6, y en el tiempo T9 envía una segunda solicitud de órdenes por lotes en la señal 116 para los objetos finales (objetos 7­ 12 en el ejemplo mostrado). En el tiempo T10, el servidor 120 recibe la señal 116, y en el tiempo T11 envía los objetos 126 al terminal 110. Finalmente en el tiempo T12, el terminal 110 recibe los objetos finales y se completa la carga de la página.
Por tanto, la diferencia entre T0 y T12 representa el tiempo total para completar la transacción de una página web con solo 12 objetos. Las señales de comando 112, 114, 116 se transmiten todas a través del satélite 300 desde el terminal 110 al servidor 120. Y, las señales de respuesta 122, 124, 126 se transmiten a través del satélite 300 desde el servidor 120 al terminal 110.
Un problema conocido de los clientes web que utilizan tecnologías de Internet por satélite es el retraso que experimenta el usuario. En el ejemplo de la figura 2, la mayor parte del tiempo para completar la solicitud del sitio web se debe a la latencia en el satélite 300. Puede haber una latencia significativa entre el tiempo que tarda en solicitarse la página web al servidor y el tiempo en que el navegador web presenta la página web al usuario. Este tipo de retraso generalmente se debe a la distancia de la red al servidor web, el tamaño de la página web, la carga del servidor web u otros factores. Sería beneficioso reducir la latencia y el tiempo de espera que experimentan los usuarios de Internet por satélite para que las páginas web se entreguen y presenten desde el servidor web.
En lugares donde la única opción para tener acceso a las tecnologías inalámbricas de Internet es el satélite, la experiencia de navegación del usuario se reduce, independientemente del ancho de banda. La razón es porque la latencia, también llamada tiempo de ida y vuelta (RTT), causa este retraso. RTT está relacionado con la larga distancia que los paquetes necesitan para viajar desde la ubicación remota hasta el satélite en el espacio, después a la estación base (telepuerto) y hacia atrás. La figura 1(a) muestra el efecto de un RTT alto para una carga de página donde el ancho de banda no es un problema y cómo el tiempo de carga de la página se ve afectado por el RTT.
Por el contrario, la figura 1(b) muestra el bajo impacto que aumenta el ancho de banda después de superar el ancho de banda mínimo necesario para no saturar un enlace con una solicitud de página web:
Uno de los métodos comúnmente utilizados para resolver este problema es proporcionar un caché en los dispositivos locales para el usuario, o tener un dispositivo separado en la red local que pueda proporcionar caché a múltiples usuarios.
El problema con este enfoque común es que es limitado. Solo se puede optimizar contenido específico con un sistema de caché porque para aumentar la velocidad de entrega de las páginas web, el contenido debe ser solicitado previamente por otros usuarios o el mismo usuario.
Además, el sistema de caché web estándar solo puede almacenar en caché lo que los desarrolladores web indican que puede ser caché usando etiquetas en los encabezados HTTP. Sin embargo, algunos sistemas de caché son capaces de detectar datos que se pueden almacenar en caché a nivel de bytes, pero normalmente requieren muchos recursos para detectar algunas variaciones en los datos.
Además, la información cifrada no se puede almacenar en caché. Aproximadamente del 40 % al 80 % del tráfico web actual se cifra mediante el protocolo HTTPS. Debido a esto, los sistemas de caché son ciegos y no pueden almacenar en caché este tipo de información.
Las soluciones existentes son muy útiles, pero solo efectivas si un usuario ha solicitado previamente la misma página web pública. Con base en esta premisa, cuantas más personas usen el mismo dispositivo de caché, aumentará la probabilidad de acceder al caché, reduciendo así la latencia para que se cargue una página web. Por lo tanto, las soluciones de almacenamiento en caché funcionan y tienen mejores resultados en lugares donde más personas usan el sistema y son menos efectivas cuando hay menos personas que lo usan.
En otros mercados premium donde el costo del ancho de banda no es una limitación, surge un problema diferente. Independientemente de la cantidad de ancho de banda disponible para un usuario en un tiempo dado, debido a la latencia y a la forma en que funciona el protocolo TCP y HTTP, los usuarios no pueden recibir el ancho de banda máximo por el que están pagando mientras navegan por Internet. Por ejemplo, si un usuario tiene un enlace con más de 5 mbps disponibles y solicita una página web o está descargando un archivo, el rendimiento típico sin ninguna optimización será de alrededor de 1-2 mbps solo debido al efecto que tiene la latencia en el protocolo TCP.
Otros métodos que ayudan a solucionar el problema de RTT elevado son protocolos como Spdy, QUIC o HTTP 2.0. Algunos de los problemas relacionados con la latencia se reducen porque el servidor web ahora puede enviar objetos sin la necesidad de esperar una solicitud, sin embargo, la adopción de estas tecnologías no ha sido lo suficientemente rápida debido a las complejidades de compensación para los desarrolladores que desean usarlo. Estos protocolos pueden ayudar con los problemas de latencia, pero esto es solo una pequeña parte del problema cuando los enlaces de Internet están saturados, porque pulsar objetos por adelantado solo funcionará si el enlace es libre para enviarlo al usuario final.
El documento US 6907429 B2 se refiere a la transferencia de datos digitales a través de una red digital. En un sistema de acceso a Internet que incluye un enlace por satélite, se proporciona un servidor proxy distribuido que reduce un retraso asociado con la recuperación de objetos en línea de páginas web. El servidor proxy distribuido incluye un componente de punto de acceso y un componente de puerta de enlace de satélite. El componente de punto de acceso se ejecuta en el lado del cliente (navegador) del enlace satelital y se comunica con los navegadores web. El componente de puerta de enlace de satélite se ejecuta en el lado de Internet del enlace de satélite y se comunica con los servidores web. A medida que se recupera una página web a través del enlace de satélite, el componente de la puerta de enlace de satélite analiza el componente de archivo base de la página web para identificar cualquier referencia a los objetos en línea de la página web y precarga cada uno de dichos objetos en línea. Los objetos capturados previamente se transmiten a través del enlace de satélite al componente de punto de acceso, que a su vez almacena los objetos capturados previamente en un caché de objetos. Cuando un navegador web solicita un objeto en línea, el componente de punto de acceso verifica el caché y, si el objeto reside en el mismo, devuelve el objeto al navegador sin reenviar la solicitud del objeto a través del enlace de satélite.
El documento US 2005/108517 A1 se refiere a la recuperación de contenido web seguro utilizando servidores proxy. Las solicitudes de contenido seguro se reescriben antes de entregar el contenido seguro a un cliente. Las solicitudes reescritas incluyen el contenido de información de la solicitud original con la adición de un dominio predeterminado. El dominio puede corresponder a un agente de confianza que actúa como proxy para todas las solicitudes seguras del cliente. Debido a la solicitud reescrita, el cliente se comunica con el agente de confianza para obtener el contenido seguro. El agente de confianza puede entonces de forma transparente (desde el punto de vista del cliente) recuperar y reenviar el contenido seguro al cliente.
El documento US 6 658 463 B1 divulga un proxy descendente que filtra las transmisiones multidifusión de URL y almacena un subconjunto de las URL para su transmisión posterior, donde se usa la popularidad relativa para determinar si se almacena una URL multidifusión.
El documento US 2002/073167 A1 divulga un sistema y un método que acelera la distribución de contenido digital de una red de comunicaciones global. Un proxy central selecciona objetos digitales populares para su transmisión a través de un medio de comunicación para proporcionar el llenado de contenido de bases de datos de caché que atienden a servidores proxy locales.
Sumario de la invención
La divulgación en cuestión se refiere a un sistema para comunicar datos desde un primer ordenador a un segundo ordenador ubicado de forma remota del primer ordenador que tiene las características definidas en la reivindicación 1. Las reivindicaciones dependientes definen realizaciones del sistema.
En consecuencia, un sistema de comunicación incluye un dispositivo proxy remoto y un dispositivo proxy periférico. El proxy remoto recibe una solicitud de un sitio web desde un terminal de usuario y transmite la solicitud al proxy periférico por satélite. El proxy periférico recibe la solicitud y la transmite a un servidor web a través de una conexión de alta velocidad. El proxy periférico recibe la respuesta del servidor web y transmite la respuesta al proxy remoto por satélite, que luego transmite la respuesta al terminal de usuario. El proxy periférico también revisa la respuesta y solicita objetos para el sitio web desde el servidor web, y transmite los objetos al proxy remoto, que luego los transmite al terminal de usuario.
Estos y otros objetos de la invención, así como muchas de las ventajas que se pretenden de la misma, resultarán más evidentes cuando se haga referencia a la siguiente descripción, tomada junto con los dibujos adjuntos.
Breve descripción de las figuras
La figura 1(a) es un gráfico que muestra el tiempo de carga de la página a medida que disminuye el RTT;
La figura 1(b) es un gráfico que muestra la latencia por ancho de banda;
La figura 2 es un diagrama de tiempo que muestra las comunicaciones realizadas para entregar contenido web vía satélite en un sistema convencional;
La figura 3 es un diagrama de tiempo que muestra las comunicaciones realizadas para entregar contenido web vía satélite de acuerdo con el sistema y método de la presente invención;
La figura 4 es un diagrama de bloques que ilustra el sistema de la presente invención utilizado para entregar contenido web vía satélite;
La figura 5 es un diagrama de tiempo que ilustra el uso de la corrección de errores sobre HTTP en la presente invención debido a una solicitud fallida del proxy remoto al proxy periférico, y una respuesta fallida del proxy periférico al proxy remoto; y
La figura 6 es un diagrama de tiempo que ilustra el uso de la corrección de errores debido a un enlace fallido.
Descripción detallada de las realizaciones preferidas
Al describir una realización preferida de la invención ilustrada en los dibujos, se recurre a terminología específica por motivos de claridad. Sin embargo, la invención no pretende estar limitada a los términos específicos así seleccionados, y debe entenderse que cada término específico incluye todos los equivalentes técnicos que operan de manera similar para lograr un propósito similar. Varias realizaciones preferidas de la invención se describen con fines ilustrativos, entendiéndose que la invención puede realizarse de otras formas que no se muestran específicamente en los dibujos.
Volviendo a la figura 3, se muestra un sistema de comunicación 200 para implementar un protocolo push de acuerdo con la invención. Como se muestra, el sistema 200 incluye un proxy remoto 220 y un proxy periférico 230. El proxy remoto 220 y el proxy periférico 230 se colocan entre el terminal de usuario 210 y el servidor web 240. Aunque solo se muestran un proxy remoto 220 y un proxy periférico 230, se pueden proporcionar varios proxies remotos 220 y varios proxies periféricos 230. Aunque solo se muestran un terminal de usuario 210 y un servidor web 240 en la figura 3, se apreciará que cada proxy remoto 220 puede comunicarse con múltiples terminales de usuario 210 en la misma Red de Área Local (LAN), y cada proxy periférico 230 puede comunicarse con múltiples servidores web 240, como se muestra en la figura 4. En una realización, los proxies remotos 220 y los proxies periféricos 230 se pueden proporcionar cada uno en un área geográfica diferente.
El terminal de usuario 210 se comunica con el proxy remoto 220 y todas las comunicaciones desde el terminal de usuario 210 pasan por el proxy remoto 220. Además, el proxy periférico 230 se comunica con el servidor web 240 a través de una conexión a Internet de alta velocidad, y todas las comunicaciones con el servidor web 240 pasan por el proxy periférico 230. El proxy remoto 220 se comunica con el proxy periférico 230 a través del satélite 300.
Como se muestra además en la figura 4, el sistema puede incluir además un rastreador y multidifusor 250. El rastreador y multidifusor 250 está en comunicación con el proxy periférico 230 y puede ser parte del proxy periférico 230 o un componente separado que está ubicado en el mismo sitio que el proxy periférico 230 o ubicado en un lugar remoto del proxy periférico 230. Las comunicaciones entre el proxy remoto 220 y el proxy periférico 230 se pueden realizar en modo de unidifusión a través de un satélite de unidifusión 300b, y también en modo de multidifusión a través de un satélite de multidifusión 300a y el rastreador y multidifusor 250. El satélite de unidifusión 300b puede ser igual o diferente al satélite de multidifusión 300a. Cuando los satélites 300a, b son los mismos, las comunicaciones de unidifusión pueden realizarse a través de diferentes canales como las comunicaciones de multidifusión.
Las comunicaciones de multidifusión pueden incluir, por ejemplo, objetos de tendencia tales como videos o imágenes de sitios web populares solicitados para un terminal de usuario particular 210 en un sitio. Entonces, en lugar de enviarlo por unidifusión, se envía por multidifusión y se almacena en caché en todos los proxy remotos 220. Mientras que las comunicaciones de unidifusión pueden incluir, por ejemplo, solicitudes de sitios web menos populares o información que el proxy periférico 230 envía a un proxy remoto 220 para un terminal de usuario 210.
El Protocolo Push
La figura 3 muestra una operación ilustrativa, no limitativa, del sistema 200, mediante la cual el usuario desea mostrar un sitio web particular en el terminal de usuario 210. Comenzando en el tiempo T0 , el usuario ingresa una dirección de sitio en el terminal de usuario 210, tal como ingresando el dominio o haciendo clic en un enlace para un dominio. En particular, el terminal de usuario 210 no necesita realizar una búsqueda de DNS. El terminal 210 transmite una señal de comando OBTENER HTTP 212 al proxy remoto 220, que se recibe casi instantáneamente en tiempo real en el proxy remoto 220. En respuesta, el proxy remoto 220 transmite inmediatamente la señal de comando OBTENER HTML 222 al proxy periférico 230 a través del satélite 300. En el tiempo T1, el proxy periférico 230 recibe la señal de comando OBTENER HTTP 222 y transmite la señal de comando OBTENER HTTP 232 al servidor web 240. En el tiempo T2 , el servidor web 240 recibe la señal de comando 232 y envía instantáneamente una señal de respuesta HTML 242 al proxy periférico 230.
En el tiempo T3, el proxy periférico 230 recibe la señal de respuesta HTML e inmediatamente transmite una señal de respuesta HTML 234 al proxy remoto 220 a través del satélite 300. Al mismo tiempo o inmediatamente después en el tiempo T4, el proxy periférico 230 procesa el HTML recibido desde el servidor web 240 para obtener todos los objetos (por ejemplo, imágenes, CSS, JavaScripts) que se necesitan para el sitio web solicitado, y comienza a solicitar esos objetos desde el servidor web 240. Por lo tanto, el proxy periférico 230 transmite una señal de solicitud 236 al servidor web 240, solicitando los objetos/imágenes en el dominio. En el tiempo T5 , el servidor web 240 recibe la señal de solicitud 236, y en el tiempo T6 el servidor web 240 transmite todos los objetos al proxy periférico 230 a través de una señal de respuesta 244. En el tiempo T7, el proxy periférico 230 ha recibido todos los datos del objeto de la señal de respuesta 244.
Dado que las señales de comando 232, 236 se transmiten a través de una conexión a Internet de alta velocidad, el servidor web 240 las recibe y procesa casi instantáneamente. Además, dado que las señales de respuesta 242, 244 del servidor web 240 también se transmiten a través de una conexión de alta velocidad, el proxy periférico 230 las recibe y procesa casi instantáneamente. Por lo tanto, el período de tiempo para que el proxy periférico 230 solicite inicialmente la información desde el servidor web 240 (en el tiempo T1) hasta que posteriormente reciba toda la información solicitada para ese dominio (en el tiempo T7), es relativamente corto (por ejemplo, para una página que normalmente puede tardar 40 segundos en cargarse en la figura 1, puede cargarse en menos de 3 segundos).
Refiriéndonos nuevamente al tiempo T3, el proxy periférico 230 ha transmitido una señal de RESPUESTA HTML 234 al proxy remoto 220 a través del satélite 300. Al mismo tiempo que la señal de RESPUESTA HTML 234 se comunica a través del satélite 300, el proxy periférico 230 se comunica con el servidor web 240 para recibir todos los datos del objeto en la señal de respuesta 244. En el tiempo T8, el proxy remoto 220 ha recibido la señal de RESPUESTA HTML 234, y transmitido una señal de RESPUESTA HTML 224 al terminal de usuario 210. Esa señal de respuesta 224 es recibida casi instantáneamente por el terminal de usuario 210.
Cuando el terminal de usuario 210 recibe la respuesta 224, el navegador procesará e1HTML de la misma manera que el proxy periférico 230 lo había procesado cuando el proxy periférico 230 recibió la misma respuesta HTML 242. El terminal de usuario 210 comienza a solicitar todos los objetos en la página web solicitada. Sin embargo, la mayoría de los objetos ya están en el proxy remoto 220 y almacenados en el caché 221, porque ya han sido enviados por la señal 238, que está antes de que el navegador en el terminal de usuario 210 los solicite. En el tiempo T10 el navegador recibe todos los objetos. El tiempo entre T8 y T10 es típicamente el tiempo necesario para que el proxy remoto local 220 reciba todos los objetos enviados a través del satélite 300 desde el proxy periférico 230, y será proporcional al ancho de banda asignado a ese proxy remoto 220. Por lo tanto, cuanto mayor sea el ancho de banda, menos tiempo tomará descargar todos los objetos dentro de la página web en el terminal de usuario 210.
Las comunicaciones entre el terminal de usuario 110 y el servidor web 120 de la figura 2 ahora se realizan entre el terminal de usuario 210 y el proxy remoto 220 en la figura 3. En el tiempo T8, el terminal de usuario 210 solicita todos los objetos del proxy remoto 220. En particular, el terminal de usuario 210 no se comunica directamente con el servidor web 240 en absoluto. En cambio, el proxy periférico 230 gestiona todas las solicitudes de datos de objetos y cualquier otro dato necesario. Entonces, para cuando el terminal de usuario 210 solicita los objetos (después de T8), ellos han sido enviados por el proxy remoto 2 2 0 al terminal de usuario 2 1 0 (o al proxy remoto 2 2 0 y almacenados en el caché 221). Por lo tanto, el terminal de usuario 210 tendrá los objetos solicitados, o los objetos solicitados pueden ser enviados desde el caché 221 por el proxy remoto 2 2 0.
Como se señaló en el tiempo T7, el proxy periférico 230 ha recibido todos los datos del objeto necesarios para el dominio solicitado por el usuario. En el tiempo T9, el proxy periférico transmite los datos del último objeto en una señal de respuesta 238 al proxy remoto a través del satélite 300. Cabe señalar que la velocidad típica de las comunicaciones de Internet de alta velocidad entre el proxy periférico 230 y el servidor web 240 puede ser de aproximadamente 1 Gbps (Gigabits por segundo), mientras que la velocidad típica de un enlace por satélite puede ser de 5 Mbps (Megabits por segundo). En consecuencia, puede haber un retraso desde el tiempo T7 cuando el proxy periférico 23 ha recibido todos los datos del objeto, al tiempo T9 cuando los datos del último objeto se transmiten al satélite 300 como señal 238. El tiempo real desde T7 a T9 depende de la cantidad de datos que se van a transmitir, el ancho de banda para el enlace por satélite y el ancho de banda en el telepuerto. Como se muestra, esa señal de transmisión 238 son todos los datos del objeto necesarios para el sitio web, no solo parte de los datos del objeto.
Como se representa además, esa señal de transmisión 238 se envía sin que el terminal de usuario 210 o el proxy remoto 220 tengan que enviar una solicitud porque el proxy periférico 230 había solicitado la información con anticipación y sin recibir una solicitud desde el terminal de usuario 210 o el proxy remoto 220. De esta manera, el sistema 200 acelera la entrega de los datos del objeto al hacer que la solicitud realizada por el proxy periférico 230 a través de la conexión más rápida en el sistema 200, es decir, a través de la conexión a Internet de alta velocidad entre el proxy periférico 230 y el servidor web 240.
Finalmente, en el tiempo T10, el proxy remoto 220 recibe todos los datos del objeto de la señal de respuesta 238 y los envía al terminal de usuario 210 a través de la señal de respuesta 226. En consecuencia, en T10, el terminal de usuario 210 tiene toda la información para la página web solicitada y puede representar una versión completa de la página web. El período de tiempo completo desde la solicitud inicial en el tiempo T0 hasta que toda la información se reciba en el tiempo T10, es mucho más corto que el tiempo requerido por el sistema convencional de la figura 3, representado por el tiempo T12 (figura 2). Como se ilustra en la figura 3, el único retraso se debe a la capacidad de ancho de banda del satélite 300, mientras que en la figura 2, el retraso se debe a que la latencia del sistema tiene que transmitir un mayor número de señales de ida y vuelta a través del satélite 300. La presente invención reduce la cantidad de información que se transmite a través del satélite 300, lo que a su vez reduce la latencia general.
Un objetivo del protocolo Push de la figura 3 es reducir el efecto de las redes de alta latencia. Por ejemplo, el sistema 200 reduce la cantidad de comunicación que se transmite por el satélite 300.
Como se muestra además en la figura 3, el proxy remoto 220 tiene o está en comunicación con un caché 221. El proxy remoto 220 almacena en el caché 221, los datos recibidos desde la señal de respuesta HTML 234 y todos los datos del objeto en la señal de respuesta 238. Por consiguiente, si el terminal de usuario 210 solicita ese mismo sitio web nuevamente, recuperará la información solicitada del caché 221 y no enviará ninguna solicitud al proxy periférico 230. El proxy remoto 220 puede determinar qué información almacenar en el caché 221 y con qué frecuencia se actualizará esa información.
El sistema 200 proporciona conexiones preestablecidas en el proxy periférico 230. Cuando se inicia el proxy remoto 220, establece desde el principio varias conexiones con el proxy periférico 230 para HTTP y HTTPS. Las conexiones preestablecidas reducen el tiempo de conexión sobre el satélite 300. Por lo tanto, cuando se necesita enviar una solicitud, se puede usar una conexión preestablecida en lugar de tener que conectarse al proxy periférico 230 (es decir, al servidor web 240). La cantidad de conexiones preestablecidas depende del ancho de banda y la cantidad estimada de usuarios concurrentes. Las conexiones preestablecidas pueden ser, por ejemplo, 50 HTTP y 50 HTTPS (es decir, tomas TCP), aunque se puede utilizar cualquier número adecuado. Todas las solicitudes web generadas por todos los usuarios pasarán por estas conexiones estáticas y lo mismo para respuesta a los usuarios.
El sistema 200 (específicamente las conexiones estáticas entre el proxy remoto 220 y el proxy periférico 230) elimina la sobrecarga de establecer una conexión TCP que de otro modo iría desde el navegador al servidor web 240 porque las conexiones se están estableciendo entre el navegador y el proxy remoto 220 localmente y las conexiones preestablecidas se utilizan entre el proxy remoto 220 y el proxy periférico 230 para comunicarse con el servidor web 240. Por lo tanto, cuando un navegador solicita una página web, el terminal de usuario 210 se conectará directamente al servidor proxy remoto local 220 sin latencia en la LAN, y la solicitud se enviará al servidor web 240 utilizando las conexiones preestablecidas desde el servidor proxy remoto 220 al proxy periférico 230 y debido a esto, el sistema 200 ahorra el tiempo de conexión (aproximadamente 250 ms por conexión).
Más importante aún, estas conexiones preestablecidas se utilizan en el proxy periférico 230 para utilizar todos los canales disponibles al máximo rendimiento, por ejemplo, multiplexando las señales. Cada conexión (es decir, toma TCP) tiene un límite de rendimiento natural en redes de alta latencia que la presente invención evita al tener estas conexiones preestablecidas; porque en lugar de enviar el objeto a través de una sola conexión, el sistema utiliza las conexiones preestablecidas para multiplexar el objeto y aumentar el rendimiento total del sistema. Cuando se recibe una solicitud en el proxy periférico 230 desde el proxy remoto 220, se pone en cola en el proxy remoto 220 para ser procesada (por ejemplo, por hilos de trabajo). Y cuando llega una respuesta al proxy periférico 230 desde el servidor web 240, el proxy periférico 230 (por ejemplo, hilos de trabajo) utilizan cualquier conexión preestablecida disponible para enviarlo al proxy remoto 220.
Todas las conexiones preestablecidas se utilizan a la capacidad máxima todo el tiempo, incluso si hay una respuesta retrasada en un servidor web 240 particular para un sitio web particular, ya que el proxy periférico 230 puede procesar otras respuestas mientras espera la respuesta retrasada. El hilo de trabajo en el proxy periférico 230 controla las conexiones al servidor web 240. El hilo de trabajo espera respuestas (es decir, señales 242, 244) desde el servidor web 240, lo que puede tardar varios segundos. El proxy periférico 230 (hilo de trabajo) sabe si una conexión preestablecida está inactiva o activa. Por lo tanto, cuando llega una respuesta, el hilo de trabajo (en el proxy periférico 23) solicita una conexión preestablecida disponible (es decir, inactiva) y transmite la respuesta (es decir, 234, 238) al proxy remoto 220 a través de la conexión preestablecida identificada.
Además, la búsqueda de DNS se realiza en el proxy periférico 230. En un escenario normal, la búsqueda de DNS puede tardar varios segundos en una red de alta latencia. Pero en la presente invención, la búsqueda de DNS se realiza en el proxy periférico 230 a muy alta velocidad. En muchas redes, los DNS se encuentran en la WAN, y para solicitar la IP de un nuevo dominio se requiere un mensaje de ida y vuelta a través del enlace con alta latencia. En el sistema 200 de la presente invención, la solicitud de una página web (OBTENER dominio.com) irá al proxy periférico 230 utilizando las conexiones preestablecidas, y el proxy periférico 230 realiza la búsqueda de DNS en una conexión a Internet de alta velocidad con baja latencia. El proxy periférico 230 puede realizar solicitudes de DNS de varios servidores web 240 antes de T1. En consecuencia, cuando el proxy periférico 230 recibe la señal de comando OBTENER HTTP 222 desde el proxy remoto 220, el proxy periférico 230 realiza una consulta de DNS (que es muy rápida en la conexión a Internet de alta velocidad, a menudo menos de 20 ms).
El sistema 200 también procesa contenido HTML y búsquedas previas. Cuando se solicita una página web y se recibe la respuesta en el proxy periférico 230, el proxy periférico 230 analiza e1HTML para obtener todos los objetos que el navegador va a solicitar cuando reciba el mismo HTML. Entonces, en lugar de esperar a que el navegador en el terminal de usuario 210 reciba el HTML y lo procese para comenzar a solicitar todos los objetos, el proxy periférico 230 procesa todas las solicitudes por adelantado para enviarlas al proxy remoto 220 incluso antes de que el navegador del terminal de usuario 210 solicite esa información.
En consecuencia, el sistema 200 es una solución completa para entornos de alta latencia como satélite con o sin restricciones de ancho de banda que puede corregir inmediatamente el efecto de la alta latencia, mejorando la experiencia de navegación. Colocando un dispositivo de caché 221 en el proxy remoto 220 y un proxy periférico 230 con alto ancho de banda y baja latencia a Internet. El proxy periférico 230 puede descargar y procesar todas las solicitudes para el proxy remoto 220 muy rápido y aplicar reglas para optimizar el uso del ancho de banda.
El dispositivo de caché 221 puede almacenar todos los datos de caché relacionados con el comportamiento de un usuario, pero lo que es más importante, el caché local 221 puede recibir por adelantado todos los objetos relacionados con una solicitud de página realizada por el usuario. El proxy periférico 230 puede procesar muy rápidamente una solicitud de página web y puede obtener todos los objetos y enviarlos por adelantado antes de que el navegador del usuario los solicite. Debido al alto RTT, la mayoría de los objetos necesarios para comenzar la representación de la página web ya estarán disponibles en el caché local 221 cuando el navegador los solicite y se enviarán inmediatamente al terminal de usuario 210.
Corrección de errores HTTP y protección contra descargas
El protocolo interno entre el proxy remoto 220 y el proxy periférico 230 permite que el sistema 200 implemente varios mecanismos para garantizar una navegación más fiable, incluyendo la corrección de errores HTTP y la protección contra descargas. HTTP estándar no tiene corrección de errores y, en muchos casos, cuando un enlace falla o está saturado, muchas solicitudes se descartan y las respuestas nunca llegan al navegador.
Para corregir los problemas que pueden ocurrir cuando un usuario solicita una página web o está descargando un archivo grande a través de Internet, se proporciona un protocolo NACK (sin reconocimiento) para notificar cuando no se recibió una respuesta en un período de tiempo determinado, por lo que la solicitud es enviada de nuevo de forma transparente al terminal de usuario 210. Refiriéndose a la figura 5, se muestra un primer ejemplo ilustrativo donde la primera solicitud REQ1 (tal como la señal de comando OBTENER HTTP 222 (figura 3)) transmitida desde el proxy remoto 220 falla y no es recibida por el proxy periférico 230. El proxy remoto 220 espera recibir una respuesta dentro de un cierto período de tiempo predeterminado (por ejemplo, el tiempo Te en la figura 3). Si no se recibe una respuesta dentro de ese período de tiempo predeterminado, el proxy remoto 220 reenviará automáticamente la misma solicitud REQ1 y esperará la respuesta.
En otro ejemplo del protocolo NACK, el proxy remoto 220 envía un segundo comando REQ2, que se transmite con éxito al proxy periférico 230. El proxy periférico 230 envía una respuesta RESP2, pero el proxy remoto 220 nunca recibe la respuesta. En consecuencia, el proxy remoto 220 espera recibir una respuesta dentro de un cierto período de tiempo predeterminado. Si el proxy remoto 220 no recibe una respuesta dentro de ese período de tiempo predeterminado, el proxy remoto 220 reenvía su comando REQ2 y el proxy periférico 230 reenvía su respuesta RESP2. En un ejemplo, el período de tiempo predeterminado puede ser de 3 segundos; sin embargo, se puede utilizar cualquier tiempo adecuado mayor o menor de 3 segundos.
De acuerdo con el protocolo NACK, si se atienden todas las solicitudes y se reciben todas las respuestas para esas solicitudes, no es necesario enviar ningún NACK, por lo que no se agrega una sobrecarga adicional. El protocolo solo actúa cuando es necesario para que no se agregue ninguna sobrecarga adicional que pueda afectar el consumo de ancho de banda o el rendimiento en la red.
En una realización de la invención, cada solicitud que es transmitida por el proxy remoto 220 puede tener un número incremental secuencial que el proxy remoto 220 incluye en el encabezado. El encabezado puede ser un encabezado de protocolo interno que se agrega además del encabezado HTTP normal. El encabezado puede indicar otra información, tal como el tipo de mensaje y el ID de secuencia, así como indicar si un mensaje es un mensaje NACK, una solicitud o una respuesta. El proxy remoto 220 rastrea cada solicitud hasta que el proxy remoto 220 recibe una respuesta satisfactoria y la envía al navegador en el terminal de usuario 210. El proxy periférico 230 es consciente de todas las secuencias y también puede detectar rápidamente una solicitud fuera de secuencia o una solicitud duplicada. Por ejemplo, el número secuencial puede incrementarse automáticamente en uno con cada mensaje (por ejemplo, cada mensaje recibe un número secuencial que es uno mayor que el último mensaje). Cuando se detecta una secuencia fuera de secuencia, el proxy periférico 230 esperará unos segundos para asegurarse de que la secuencia no esté fuera de orden. Si la secuencia perdida nunca llega, el proxy periférico 230 notificará al proxy remoto 220 que envíe nuevamente la secuencia perdida, por ejemplo, mediante un mensaje de reconocimiento negativo (NACK).
Por otro lado, si el proxy remoto 220 no recibe una señal NACK o una respuesta dentro de un período de tiempo predeterminado, el proxy remoto 220 volverá a enviar la solicitud. Sin embargo, hay dos escenarios posibles, como se muestra en la figura 5. Primero, la solicitud REQ1 nunca se recibió en el proxy periférico 230 y, como resultado, el proxy periférico 230 no transmite una respuesta RESP1 y no envía un NACK al proxy remoto 220. En ese caso, se transmite una nueva solicitud REQ1 desde el proxy remoto 220, que es recibida por el proxy periférico 230, y se envía una respuesta RESP1 al proxy remoto 220. El proceso se puede repetir hasta 3 veces, de modo que el proxy remoto 220 pueda esperar un período de tiempo predeterminado (por ejemplo, casi 2 minutos) para recibir la respuesta RESP1 antes de notificar al navegador en el terminal de usuario 210 con un mensaje de error HTTP.
En el segundo escenario mostrado en la figura 5, la solicitud REQ2 es transmitida por el proxy remoto 220 y recibida por el proxy periférico 230. El proxy periférico 230 envía una respuesta RESP2, pero la respuesta RESP2 se pierde o no la recibe el proxy remoto 220. Esto se trata de la misma manera que en el caso anterior, donde el proxy remoto 230 es responsable de reenviar la solicitud REQ2 después de un período de tiempo predeterminado y esperar la respuesta.
Refiriéndose a la figura 6, se proporciona un protocolo de recuperación de descarga. El protocolo de descarga actuará solo cuando los objetos sean más grandes que un cierto tamaño. Si los archivos son pequeños (por ejemplo, menos de 4 mb) puede ser mejor permitir que el protocolo NACK actúe y solicitar el archivo nuevamente. Pero si los archivos son más grandes que un tamaño predeterminado y la descarga ya se inició, se utilizará el protocolo de descarga. Como se muestra, si el enlace falla durante la descarga, el protocolo de descarga está implementado para permitir que la descarga se reanude sin perder ningún dato. Cuando se interrumpe una descarga porque falla el enlace, y detectamos que las conexiones estáticas están cerradas o que no se reciben datos en algún tiempo, ambos extremos (es decir, el proxy remoto 220 y el proxy periférico 230) activa automáticamente algunas acciones.
Primero, el proxy periférico 230 en lugar de abortar la descarga, reducirá la velocidad de la descarga para mantener la conexión establecida con el servidor web y guardará el archivo en un archivo local. En segundo lugar, el proxy remoto 220 monitorizará cuando se restablezcan las conexiones estáticas y enviará un resumen con el último byte recibido. En tercer lugar, el proxy periférico 230 guardará (por ejemplo, en un dispositivo de almacenamiento como una base de datos o memoria) el archivo durante un período de tiempo predeterminado (por ejemplo, 30 min por defecto) y cuando se reciba la señal de reanudación de la descarga desde el proxy remoto 220, el proxy periférico 230 continuará enviando los datos al proxy remoto 220. En cuarto lugar, si el navegador cierra la conexión de descarga al proxy remoto 220 antes de que el proxy remoto 220 pueda restablecer la conexión, el proxy remoto 220 no enviará una señal de comando de reanudación al proxy periférico 230 y el archivo se descartará. Por supuesto, se pueden proporcionar realizaciones alternativas. Por ejemplo, en lugar de que el proxy remoto 220 determine que se ha restablecido una conexión, el proxy periférico 230 puede determinar que la conexión se ha restablecido y continuar la transmisión de la descarga e indicar el último byte transmitido (o repetir varios bytes que se transmitieron justo antes de la conexión fallida).
Optimización HTTPS
Dado que HTTPS representa más del 60 % del tráfico web, es muy importante optimizar este tráfico de la misma manera que lo hacemos para HTTP. Sin embargo, esto no se puede hacer sin el permiso explícito del usuario. Los usuarios deben aceptarnos como proxy de confianza para interceptar el tráfico HTTPS con la única intención de optimizarlo. Por esa razón, se necesita una aplicación en el dispositivo del usuario para instalar un certificado raíz que permita a cualquier aplicación que use HTTPS confiar en certificados SSL generados por nosotros y solicitar la autorización del usuario para enviar todo el tráfico HTTPS a través de nuestro proxy.
Por lo tanto, para optimizar el tráfico HTTPS, los usuarios finales deberán instalar pequeñas aplicaciones en sus dispositivos móviles (teléfonos inteligentes, etc.) y leer y aceptar nuestro descargo de responsabilidad. Otra función de esta aplicación será la de detectar automáticamente nuestro proxy y configurarlo en los ajustes del sistema del dispositivo. La aplicación puede detectar el proxy utilizando un protocolo de difusión en la LAN para anunciar la presencia del proxy, o solicitar la IP del proxy llamando a una API en una consola web central que conoce las ubicaciones de todos los proxies remotos aprovisionados.
Para HTTPS, no se almacenan en el caché 221 datos privados identificados en los encabezados HTTP como parte del protocolo HTTP. Los datos privados son parte de los estándares HTTP y la decisión de qué datos son privados o públicos la toma el desarrollador web del sitio web recibido desde el servidor web 240. Los datos privados se reciben en el encabezado de respuesta HTTP y se marcan como privados. Los datos privados pueden incluir JavaScript, imágenes y videos comunes. Y toda la información se cifrará durante la transmisión de un extremo a otro desde el servidor web 240 al terminal de usuario 210 y de regreso al servidor web 240 utilizando estándares de cifrado.
HTTP de multidifusión
Volviendo a las figuras 3 y 4, el sistema 200 tiene un modo de funcionamiento de unidifusión y un modo de funcionamiento de multidifusión (aunque también pueden proporcionarse opcionalmente otros modos adecuados, tal como un modo de difusión). Esos modos pueden ser los mismos que los discutidos en la patente de Estados Unidos n.° 8.954.600. En el modo de unidifusión, el usuario ha solicitado datos de unidifusión (por ejemplo, sitios web menos populares o sitios web que tienen información altamente personalizada por el usuario) en el navegador, que no son datos de difusión y, por lo tanto, no se han difundido previamente al ordenador del usuario ni se han almacenado en el caché local 221. En cambio, el usuario solicita la única página web deseada desde el proxy remoto 220.
Por ejemplo, el modo de multidifusión se puede utilizar para enviar información a la que accede un gran subconjunto de usuarios desde un único sitio web a un gran subconjunto de terminales de usuario 210, tal como sitios web o información populares. La información se actualiza y se difunde de forma continua o periódica de modo que esté disponible inmediatamente en los ordenadores 210 del usuario cuando el usuario la solicite posteriormente.
Todas las comunicaciones (es decir, la señal de comando 222 y las señales de respuesta 234, 238) entre el proxy remoto 220 y el proxy periférico 230 pueden transmitirse a través del satélite 300 en el modo de unidifusión.
Como se mencionó, el caché 221 se utiliza si la misma información se ha solicitado y almacenado previamente en el dispositivo de caché 221. Entonces, para aumentar el rango de pluralidad de usuarios, no solo estamos recibiendo las solicitudes de un grupo de usuarios en la misma ubicación o red. La memoria caché 221 también puede cubrir la huella completa del satélite en un área geográfica particular del mundo en bandas C/Ku para continentes u océanos o ciudades con bandas Ka, como se ilustra en la figura 4.
Conociendo el comportamiento de los usuarios en todos los controles remotos que están usando el sistema 200 ubicado en las mismas huellas que las redes de multidifusión (es decir, transmisiones a través del satélite de multidifusión 300a, que puede ser igual o diferente del satélite de unidifusión 300b), el sistema 200 puede determinar el sitio web más popular o las URL solicitadas de tendencia con un algoritmo inteligente que detectará si los sitios web son para el público y si tendrán un impacto en la búsqueda previa de esos sitios para enviarlos a todos los dispositivos de caché 221 en la misma red de multidifusión cubierta para la misma huella en la misma área. Todos los proxies remotos 220 pueden conectarse a un solo satélite de red de multidifusión 300a disponible en una huella de satélite particular. Cuando un sitio remoto con el sistema 200 es capaz de conectarse a una multidifusión particular, todo el comportamiento del usuario se contabilizará para esa multidifusión particular para determinar el sitio web popular.
En caso de que el sitio web cumpla con las condiciones necesarias para tener una buena probabilidad de ser accedido por el mecanismo de caché, determinamos la frecuencia con la que un sitio web popular particular debe actualizarse en función de la frecuencia con la que los usuarios solicitan las páginas web y la frecuencia con la que el contenido de las páginas web cambia. Las condiciones definidas para determinar si una página web debe estar en la lista popular de sitios web son: (1) Frecuencia de la página de inicio que es accedida por los usuarios. (2) Cantidad de diferentes usuarios que acceden al mismo dominio. (3) Cantidad de diferentes solicitudes de páginas dentro de un mismo dominio.
El nivel de navegación se determina en función de la cantidad de páginas diferentes solicitadas por los usuarios. El proxy periférico 230 recibe las solicitudes del usuario del satélite de unidifusión 300b y almacena esa información en la base de datos como datos sin procesar compuestos por todos los detalles como dominios, cantidad de usuarios, solicitud total y mucho más hecho en una hora. El servidor de rastreo/multidifusión 250 recibe la consulta de los datos sin procesar desde los distintos proxies periférico 230 (por ejemplo, cada 30 minutos) y determina diversa información estadística y no estadística, tal como calcular la frecuencia y la importancia en función de la cantidad de personas que utilizan repetidamente el sitio web. Esa información puede entonces ser utilizada por el servidor de rastreo y multidifusión 250 (figura 4), por ejemplo, el servidor de multidifusión 250 puede transmitir los sitios más populares a uno o más proxies remotos 220 a través del satélite de multidifusión 300a. Para un dominio de sitio web particular, el rastreador 250 navega a esa página a través del servidor 240, obtiene todos los objetos (imágenes, videos, etc.), crea un paquete comprimido y lo envía a través del satélite de red de multidifusión 300a (que puede diferir de la red de unidifusión 300b para esa área particular cubierta por la huella del satélite). Los paquetes serán recibidos en el proxy remoto 220 escuchando esa multidifusión particular que está asignada para esa huella y una vez que lleguen los datos serán almacenados en el caché 221 en el proxy remoto 220.
Los servidores de rastreo y multidifusión 250 pueden cargarse con cientos de navegadores reales (figura 4) que generan esos paquetes navegando página por página como una araña de búsqueda y determinando inteligentemente las páginas más importantes que deben ser navegadas, por ejemplo, páginas de inicio, secciones y páginas relevantes dentro de esas secciones. Este proceso se realiza con al menos una frecuencia predeterminada. Los paquetes tienen información incremental, lo que significa que solo se agregará información nueva desde que se generó el último paquete en el nuevo paquete. Eso mantiene el tamaño de los paquetes proporcionalmente pequeño a los cambios en el sitio web.
Se puede proporcionar un componente de cliente de multidifusión en el proxy remoto 220. El cliente de multidifusión puede estar conectado a una red de multidifusión específica (comunicaciones a través de los canales de multidifusión del satélite 300a). El cliente de multidifusión puede recibir todos los paquetes generados por los rastreadores con todos los objetos recopilados por el rastreador 250 y almacenar los objetos almacenados en caché en los dispositivos de caché 221 en el proxy remoto 220. Así, cuando el terminal de usuario 210 solicita información de las páginas precargadas por el rastreador 250, puede ser recuperada del caché 221 en el proxy remoto 220 y no es necesario transmitir la solicitud al proxy periférico 230. Por ejemplo, un cliente de multidifusión en el proxy remoto 220 puede estar asociado con América del Norte, y un cliente de multidifusión en un proxy remoto 220 diferente puede estar asociado con América del Sur. El cliente de multidifusión conoce su ubicación basándose en el satélite 300 con el que se comunica.
Se implementa un protocolo de multidifusión real para contenido de tendencia, que generalmente son sitios web con una naturaleza dinámica que no se pueden recuperar previamente, pero aún son muy populares y dentro de los mismos tienen contenido público que se puede reutilizar como imágenes y videos. Este es el caso de las redes sociales. El objetivo de esta multidifusión en tiempo real es ser un medio alternativo para enviar contenido de tendencia sobre multidifusión en lugar de unidifusión. Entonces, cuando un usuario solicita un objeto que está clasificado como contenido de tendencia, el objeto se enviará usando multidifusión en tiempo real y el usuario lo recibirá de manera transparente como una respuesta normal de unidifusión, pero con la ventaja de que estos objetos en particular se pueden almacenar en caché en miles de dispositivos al mismo tiempo cuando se envía, y también, ahorrando ancho de banda de unidifusión.
El proceso es el siguiente:
(a) El rastreador 250 clasifica los sitios web como populares debido a la información estadística almacenada por el proxy periférico 230. Sin embargo, los sitios pueden ser dinámicos e incluir información privada como FACEBOOK® o TWITTER® (que son contenido generado solo para el usuario), aunque los objetos en su interior (como imágenes y videos) se pueden marcar como un objeto público en el encabezado HTTP.
(b) El terminal 210 solicita un objeto, esa solicitud se envía al proxy remoto 220 y se envía al proxy periférico 230 para determinar si el sitio es popular utilizando la información estadística, y se recibe una respuesta desde el servidor web 240. Si el encabezado HTTP en la respuesta indica que el objeto es público, entonces los datos se pueden almacenar en caché y pueden ser multidifusión. Por consiguiente, el objeto es multidifusión sobre el satélite 300.
(c) Para realizar la multidifusión del objeto, el proxy periférico 230 llama a una API del multidifusor 250 (figura 4) para solicitar enviar ese objeto a través de la multidifusión en tiempo real. Según la carga de la red de multidifusión que tiene una cantidad finita de ancho de banda, el multidifusor 250 aceptará o negará ese objeto.
(d) Si se niega el objeto, el proxy periférico 230 envía la respuesta normalmente al proxy remoto 220.
(e) El multidifusor pone en cola todas las respuestas que fueron aceptadas para ser enviadas por multidifusión y utilizando un canal priorizado sobre la misma red de multidifusión enviará uno por uno todos los objetos en la cola. Los paquetes generados por el rastreador pueden retrasarse porque nadie los está esperando, pero la multidifusión en tiempo real debe enviar la respuesta al objeto lo más rápido posible porque una persona lo está esperando.
En una realización de la invención, el sistema 200 incluye el funcionamiento mediante uno o más dispositivos de procesamiento, incluyendo el proxy remoto 220 y el proxy periférico 230. Y los dispositivos con los que se comunican también incluyen dispositivos de procesamiento, tal como el terminal de usuario 210 y el servidor web 240. Se observa que los dispositivos de procesamiento de cada uno de esos dispositivos pueden ser cualquier dispositivo adecuado, tal como un servidor, procesador, microprocesador, PC, tableta, teléfono inteligente, ordenador central o similar. Los dispositivos de procesamiento se pueden usar en combinación con otros componentes adecuados, tal como un dispositivo de visualización (monitor, pantalla LED, pantalla digital, etc.), dispositivo de memoria o almacenamiento, dispositivo de entrada (pantalla táctil, teclado, dispositivo señalador tal como un ratón), módulo inalámbrico (para RF, Bluetooth, infrarrojos, WiFi, Zigbee, etc.). La información puede almacenarse en un disco duro de ordenador, en un disco CD ROM o en cualquier otro dispositivo de almacenamiento de datos apropiado, que puede estar ubicado en o en comunicación con el dispositivo de procesamiento. Todo el proceso es realizado automáticamente por el dispositivo de procesamiento y sin ninguna interacción manual. En consecuencia, las comunicaciones y las operaciones pueden producirse sustancialmente en tiempo real sin retrasos.
Dentro de esta memoria descriptiva, se han descrito realizaciones de una manera que permite escribir una memoria descriptiva clara y concisa, pero se pretende y se apreciará que las realizaciones se pueden combinar o separar de diversas formas sin apartarse del espíritu y del alcance de la invención. Por ejemplo, aunque la realización de la figura 3 muestra la respuesta HTML 224 transmitida antes de la respuesta 226 de los objetos, el proxy periférico 230 o el proxy remoto 220 pueden esperar hasta que se reciban todos los objetos antes de transmitir la respuesta HTML al proxy remoto 220 o al terminal de usuario 210, respectivamente.

Claims (14)

REIVINDICACIONES
1. Un sistema para comunicar datos (200) desde un primer ordenador (210) a un segundo ordenador (240) ubicado remotamente del primer ordenador (210), comprendiendo el sistema (200):
un primer dispositivo proxy (220) configurado para recibir una solicitud desde el primer ordenador (210) y transmitir la solicitud a través de un enlace por satélite; y
un segundo dispositivo proxy (230) configurado para recibir la solicitud desde el primer dispositivo proxy (220) a través del enlace por satélite y transmitir la solicitud al segundo ordenador (240) a través de una conexión de alta velocidad, recibiendo dicho segundo dispositivo proxy (230) una respuesta desde el segundo ordenador (240) y transmitiendo la respuesta a través del enlace por satélite;
estando dicho primer dispositivo proxy (220) configurado además para recibir la respuesta desde el segundo dispositivo proxy (240) a través del enlace por satélite y transmitir la respuesta al primer ordenador (210);
un rastreador y multidifusor (250), en comunicación con el segundo dispositivo proxy (230), configurado para revisar la solicitud y comparar los datos buscados por la solicitud con una base de datos de solicitudes populares y, cuando la solicitud busca datos que aparecen en la base de datos de solicitudes populares, indicar al segundo dispositivo proxy (230) que transmita la respuesta desde el segundo dispositivo proxy (230) a varios primeros dispositivos proxy (220) utilizando multidifusión,
en el que el primer dispositivo proxy (220) está configurado además para:
determinar si el enlace por satélite falla durante la transmisión de la respuesta;
en respuesta a determinar que el enlace satelital falló, monitorizar cuándo se restablecen las conexiones estáticas entre el primer dispositivo proxy (220) y el segundo dispositivo proxy (230) a través del enlace por satélite y enviar una señal de reanudación con un último byte recibido al segundo dispositivo proxy (230); y en respuesta a cerrar una conexión desde el primer ordenador (210) al primer dispositivo proxy (220) antes de restablecer las conexiones estáticas, no enviar la señal de reanudación al segundo dispositivo proxy (230),
en el que el segundo dispositivo proxy (230) está configurado además para:
determinar si el enlace por satélite falla durante la transmisión de la respuesta;
en respuesta a la determinación de que el enlace por satélite falló, reducir la velocidad de recepción de la respuesta desde el segundo ordenador (240) para mantener una conexión establecida con el segundo ordenador (240) y guardar la respuesta en un dispositivo de almacenamiento durante un período de tiempo predeterminado;
recibir la señal de reanudación desde el primer dispositivo proxy (220);
en respuesta a recibir la señal de reanudación, continuar transmitiendo la respuesta al primer dispositivo proxy (220); y
descartar la respuesta en el dispositivo de almacenamiento si la señal de reanudación no se recibe dentro del período de tiempo predeterminado.
2. El sistema (200) de la reivindicación 1, en el que la solicitud comprende una señal de comando OBTENER HTTP.
3. El sistema (200) de la reivindicación 2, en el que el segundo dispositivo proxy (230) está configurado además para revisar la respuesta y determinar la información adicional necesaria, y transmitir una solicitud adicional al segundo ordenador (240) para obtener la información adicional.
4. El sistema (200) de la reivindicación 2 o 3, en el que el segundo dispositivo proxy (230) está configurado además para recibir una respuesta adicional desde el segundo ordenador (240) y transmitir la respuesta adicional al primer dispositivo proxy (220) vía satélite ( 300), y en el que el primer dispositivo proxy (220) está configurado además para recibir la respuesta adicional a través del satélite (300) y transmitir la información adicional al primer ordenador (210).
5. El sistema (200) de una de las reivindicaciones 1 a 4, en el que la solicitud es para un sitio web.
6. El sistema (200) de una de las reivindicaciones 1 a 5, en el que el primer ordenador (210) es un terminal de usuario y el segundo ordenador (240) es un servidor web.
7. El sistema (200) de una de las reivindicaciones 1 a 6, en el que dicho primer dispositivo proxy (220) está configurado además para determinar si no se recibe una respuesta desde el segundo dispositivo proxy (230) dentro de un periodo de tiempo predeterminado, y retransmitir la solicitud vía satélite (300) si la respuesta no se recibe del segundo dispositivo proxy (230) dentro del periodo de tiempo predeterminado.
8. El sistema (200) de una de las reivindicaciones 1 a 7, que comprende además un caché en comunicación con el primer dispositivo proxy (220), en el que dicho segundo dispositivo proxy (230) está configurado además para determinar sitios web populares y sitios web populares de multidifusión al primer dispositivo proxy (220) a través del satélite (300), estando dicho primer dispositivo proxy (220) configurado para almacenar los sitios web populares en dicho caché, y en el que dicho primer dispositivo proxy (220) está configurado además para determinar si la solicitud desde el primer ordenador (210) corresponde a la información almacenada en el caché, recuperar la información solicitada del caché y transmitir la información solicitada al primer ordenador (210).
9. El sistema (200) de la reivindicación 1, en el que
el primer ordenador (210) es un terminal de usuario,
el segundo ordenador (240) es un servidor web,
el primer dispositivo proxy (220) es un dispositivo proxy remoto configurado para recibir la solicitud que es una solicitud OBTENER HTTP desde el terminal de usuario y transmitir la solicitud OBTENER HTTP a través del satélite (300), estando la solicitud OBTENER HTTP asociada con un sitio web,
el segundo dispositivo proxy (230) es un dispositivo proxy periférico configurado para recibir la solicitud OBTENER HTTP desde el dispositivo proxy remoto a través del satélite (300), transmitir la primera solicitud OBTENER HTTP al servidor web a través de la conexión de alta velocidad, recibir la respuesta que es una respuesta HTML desde el servidor web y transmitir la respuesta HTML por satélite (300),
dicho dispositivo proxy periférico está configurado para revisar la respuesta HTML, determinar objetos para el sitio web, transmitir una solicitud adicional al servidor web para los objetos, recibir los objetos y transmitir los objetos por satélite (300),
dicho dispositivo proxy remoto está configurado además para recibir la respuesta HTML y la respuesta adicional del dispositivo proxy periférico a través del satélite (300) y transmitir la respuesta HTML y la respuesta adicional al terminal de usuario.
10. El sistema (200) de la reivindicación 9, en el que el dispositivo proxy periférico está configurado además para revisar la respuesta y determinar la información adicional necesaria, y transmitir una solicitud adicional al servidor web para obtener información adicional.
11. El sistema (200) de la reivindicación 9 o 10, en el que el dispositivo proxy periférico está configurado además para recibir una respuesta adicional desde el servidor web y transmitir la respuesta adicional al dispositivo proxy remoto a través del satélite (300), y en el que el dispositivo proxy remoto está configurado además para recibir la respuesta adicional a través del satélite (300) y transmitir la información adicional al terminal de usuario.
12. El sistema (200) de una de las reivindicaciones 9 a 11, en el que la solicitud es para un sitio web.
13. El sistema (200) de una de las reivindicaciones 9 a 12, en el que dicho dispositivo proxy remoto está configurado además para determinar si no se recibe una respuesta desde el dispositivo proxy periférico dentro de un periodo de tiempo predeterminado, y retransmitir la solicitud a través del satélite (300) si no se recibe la respuesta desde el dispositivo proxy periférico dentro del periodo de tiempo predeterminado; y/o
en el que el dispositivo proxy periférico transmite la respuesta a través de un enlace por satélite y el dispositivo proxy remoto recibe la respuesta de enlace por satélite, y los dispositivos proxy periféricos remotos están configurados además para determinar si el enlace de satélite falla durante la transmisión de la respuesta y para reanudar la transmisión de la respuesta una vez que se reanude el enlace por satélite.
14. El sistema (200) de una de las reivindicaciones 9 a 13, que comprende además un caché en comunicación con el dispositivo proxy remoto, en el que dicho dispositivo proxy periférico está configurado además para determinar sitios web populares y sitios web populares de multidifusión al dispositivo proxy remoto vía satélite (300), estando dicho dispositivo proxy remoto configurado para almacenar los sitios web populares en dicho caché, y en el que dicho dispositivo proxy remoto está configurado además para determinar si la solicitud desde el terminal de usuario corresponde a la información almacenada en el caché, recuperar la información solicitada desde el caché, y transmitir la información solicitada al terminal de usuario.
ES17155705T 2016-02-15 2017-02-10 Sistema de comunicación en red con protocolo push web Active ES2830598T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201662295399P 2016-02-15 2016-02-15
US15/138,874 US10567541B2 (en) 2016-02-15 2016-04-26 Network communication system and method with web push protocol

Publications (1)

Publication Number Publication Date
ES2830598T3 true ES2830598T3 (es) 2021-06-03

Family

ID=58158799

Family Applications (1)

Application Number Title Priority Date Filing Date
ES17155705T Active ES2830598T3 (es) 2016-02-15 2017-02-10 Sistema de comunicación en red con protocolo push web

Country Status (3)

Country Link
US (1) US10567541B2 (es)
EP (1) EP3206376B1 (es)
ES (1) ES2830598T3 (es)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10911370B2 (en) * 2017-09-26 2021-02-02 Facebook, Inc. Systems and methods for providing predicted web page resources
US11190573B2 (en) * 2018-07-25 2021-11-30 Vmware, Inc. Techniques for improving implementation of a remote browser within a local browser
CN113475084B (zh) * 2019-02-27 2024-02-02 英国电讯有限公司 多播辅助传送
US11366862B2 (en) * 2019-11-08 2022-06-21 Gap Intelligence, Inc. Automated web page accessing
US12292937B2 (en) * 2020-08-28 2025-05-06 Aera Technology, Inc. Cognitive automation platform
US20240015162A1 (en) * 2022-07-08 2024-01-11 Citrix Systems, Inc. User Interface Activation in a Secure Network System

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100571059B1 (ko) * 1997-08-06 2006-04-14 태크욘 인코포레이티드 예비 페칭을 위한 분산된 시스템 및 방법
US6658463B1 (en) * 1999-06-10 2003-12-02 Hughes Electronics Corporation Satellite multicast performance enhancing multicast HTTP proxy system and method
US20020073167A1 (en) * 1999-12-08 2002-06-13 Powell Kyle E. Internet content delivery acceleration system employing a hybrid content selection scheme
US6947440B2 (en) * 2000-02-15 2005-09-20 Gilat Satellite Networks, Ltd. System and method for internet page acceleration including multicast transmissions
US7584500B2 (en) 2003-11-19 2009-09-01 Hughes Network Systems, Llc Pre-fetching secure content using proxy architecture
KR100744541B1 (ko) * 2005-12-07 2007-08-01 한국전자통신연구원 멀티모달 인터액션 자동화 장치 및 방법
US20080270686A1 (en) * 2007-04-26 2008-10-30 Grannan Michael F Methods and system to cache content on a vehicle
US20120185783A1 (en) 2011-01-19 2012-07-19 Abel Avellan System and method for zero latency browsing
US9838219B2 (en) * 2014-04-30 2017-12-05 Aruba Networks, Inc. Virtual local area network mismatch detection in networks

Also Published As

Publication number Publication date
EP3206376A1 (en) 2017-08-16
US20170237824A1 (en) 2017-08-17
US10567541B2 (en) 2020-02-18
EP3206376B1 (en) 2020-08-26

Similar Documents

Publication Publication Date Title
ES2830598T3 (es) Sistema de comunicación en red con protocolo push web
US10455046B2 (en) Choreographed caching
US9237210B2 (en) Internet access method, terminal and storage medium
Grigorik High Performance Browser Networking: What every web developer should know about networking and web performance
US10491657B2 (en) Network acceleration method, apparatus and device based on router device
EP3080972B1 (en) A method and network node for caching web content
US9282135B2 (en) Enhanced computer networking via multi-connection object retrieval
US10027781B2 (en) TCP link configuration method, apparatus, and device
US8583053B1 (en) Optimizing TCP traffic for mobile devices using TCP backoff thresholds
US10938935B1 (en) Reduction in redirect navigation latency via speculative preconnection
US20190028548A1 (en) Transport of control data in proxy-based network communications
US10432482B2 (en) Network parameter configuration based on end user device characteristics
US20090016222A1 (en) Methods and systems for implementing time-slice flow control
US20130346552A1 (en) Download method, system, and device for mobile terminal
CN104967613B (zh) 一种移动网络环境下数据传输的系统和方法
WO2019243890A2 (en) Multi-port data transmission via udp
US10700977B2 (en) Preventing TCP from becoming too conservative too quickly
US10382981B2 (en) Cellular network protocol optimizations
US8458327B1 (en) System and method of reducing network latency
WO2015167375A1 (en) Method and tcp proxy for supporting communication between a client device and a server node
Qian Toward mobile-friendly web browsing
Nasr et al. The “droplet”: A new personal device to enable fog computing
EP3435629B1 (en) Transport of control data in proxy-based network communications
Pekkarinen Measurement-based Evaluation of HTTP/3 Deployment
Yuan In-Network Assistance for Secure Transport Protocols