ENUNCIADO

Método de reducción del tiempo de descarga de páginas Web.

CAMPO DE LA INVENCIóN La presente invención se engloba dentro del campo de las redes de ordenadores; más concretamente, se proporciona un método para mejorar los tiempos de descarga de páginas Web.

ANTECEDENTES DE LA INVENCIóN Desde Ia aparición de Ia Web se han realizado numerosos esfuerzos para reducir el tiempo de descarga de las páginas Web. La Web funciona siguiendo Ia filosofía tradicional de cliente-servidor por medio del protocolo HTTP. La figura 1 muestra un ejemplo de cómo se realiza Ia comunicación entre ambas partes. En este ejemplo, un cliente solicita al servidor www.myserver.com Ia página A.html. Generalmente las páginas suelen estar compuestas de varios objetos como imágenes, etc. En el ejemplo, Ia página A.html contiene Ia imagen img1.gif, que se solicita al servidor tras haber recibido el documento principal (A.html). La latencia percibida por el usuario (tiempo de descarga de Ia página) viene dada principalmente por el tamaño de los objetos solicitados, el ancho de banda disponible entre el cliente y el servidor, el tiempo de procesamiento de cada petición por el servidor y el tiempo que tarda Ia señal en propagarse desde el cliente al servidor.

Una página web suele estar formada por múltiples objetos. De esta forma, el tiempo de descarga de Ia página web está directamente relacionado con el tiempo de descarga de cada uno de estos objetos que Ia forman. Se pueden distinguir dos componentes principales del tiempo de descarga de un objeto web: por una parte el tiempo que tarda Ia señal en ir del cliente al servidor y volver (conocido como RTT) y por otra el tiempo de transferencia del objeto (que depende del ancho de banda entre cliente y servidor). El desarrollo tecnológico ha permitido reducir ambos tiempos, especialmente el dedicado a Ia transferencia del objeto. Esto ha hecho que el peso de ambos componentes haya variado sensiblemente a Io largo de los

años.

Como ejemplo, supongamos que un cliente va a descargar un archivo de 1OKB. Teniendo en cuenta los datos que ofrece Ia bibliografía sobra las conexiones a internet en 1996, un valor típico de ancho de banda sería 33Kbps, mientras que para el RTT sería de 1.130 ms. Descargar 10KB a través de una conexión de 33Kbps, suponiendo que no hay sobrecarga de ningún tipo, tardaría 2.483 ms. Por Io tanto, Ia latencia total de descarga del objeto sería de 1.130 + 2.483 = 3.613 ms. En esta situación, el tiempo de transferencia supone el 2483/3616 = 69% de Ia latencia total. En Ia situación actual, nos encontramos con un ancho de banda típico de 4Mbps y un RTT de 120 ms. El tiempo de transferencia de un objeto de 10KB con Ia conexión moderna sería de 20 ms que, sumado a los 120 ms del RTT, nos daría una latencia total de objeto de 140 ms. En esta situación, el tiempo de transferencia sólo supone el 20/140 = 14% de Ia latencia total. Las principales técnicas desarrolladas hasta ahora para Ia reducción de latencia son las Redes de Distribución de Contenido (CDN, por sus siglas en inglés), el Web Caching y Ia prebúsqueda web. La primera consiste en hacer copias del servidor y situar cada una de estas copias cerca de un grupo de usuarios finales, de tal forma que se reduce el tiempo que tarda Ia señal en propagarse desde el cliente al servidor y, por Io tanto, Ia latencia percibida por el usuario. Existe una amplia implantación de esta técnica en el mercado, donde destacan empresas con un gran volumen de negocio como Akamai, Amazon S3, BitGravity, etc.

El Web Caching se fundamenta en el hecho de que los usuarios suelen acceder a páginas que habían accedido previamente. En esta técnica, el cliente almacena en su disco duro de forma automática copias las páginas accedidas para poderlas utilizar en el futuro. La reducción de Ia latencia se consigue por medio de servir el contenido del objeto solicitado de forma local, que es significativamente más rápido que pedirlo al servidor. Para asegurarse de que sólo ser sirven objetos frescos (o no caducados) desde Ia caché, a cada objeto se Ie asigna una fecha de caducidad. Generalmente, cuando se solicita un objeto web, el servidor

incorpora información sobre Ia frescura del objeto (por ejemplo, su edad, Ia marca de tiempo de última modificación o su e-tag), que puede ser utilizada para calcular Ia fecha de caducidad del mismo. Si el usuario accede a un objeto que tiene en caché y está caducado, el navegador debe validar dicho objeto, es decir, debe comprobar que este objeto sigue siendo válido (es decir, que no ha cambiado) antes de servirlo al usuario. Esta validación se realiza mediante una petición condicional al servidor web (utilizando por ejemplo una cabecera 'If-Modified-Since'): el cliente solicita que el servidor Ie devuelva el objeto sólo si no es el mismo que el cliente descargó y almacenó en caché. A esta petición el servidor responde con el objeto si éste ha sido modificado, o bien con una respuesta 'Not Modified' si no ha cambiado desde entonces. Con este modo de actuar Io que se consigue es que, si el objeto no ha cambiado, el usuario se ahorra el tiempo de transferencia del objeto. Teniendo en cuenta Ia formación del tiempo de descarga de los objetos descrita anteriormente, esta técnica puede reducir drásticamente Ia latencia percibida considerando Ia situación de 1996 (un 69% en el ejemplo utilizado). Sin embargo, en Ia situación actual esta reducción de latencia está mucho más limitada (un 14% en el mismo ejemplo).

La elección de Ia fecha de caducidad del objeto es importante ya que si se da una fecha muy lejana, se corre el peligro de que el navegador muestre al usuario una versión anterior de Ia web, mientras que si es muy cercana, se reducen los beneficios del Web caching. En Ia práctica suele primar Ia consistencia de Ia web a los beneficios del caching, por Io que se suelen dar tiempos para los que un objeto es fresco muy reducidos, o incluso nulos.

El Web Caching se utiliza en prácticamente todos los navegadores Web que existen en Ia actualidad, además de ser utilizado de forma más global en Ia mayoría de organizaciones por medio de los servidores proxy. Estos servidores proxy están desarrollados por empresas como Microsoft, Netscape, Sun, etc. y utilizados en grandes organizaciones como Telefónica o Ia Universidad Politécnica de Valencia entre otras muchas.

En un sistema de prebúsqueda como los que existen en Ia

actualidad, el servidor Web mantiene un registro de los accesos realizados para predecir los accesos siguientes de los usuarios. El funcionamiento general de Ia técnica de prebúsqueda web es el siguiente:

1. El navegador web del usuario realiza Ia petición de un objeto web al servidor.

2. El servidor consulta su histórico de accesos y predice cuáles serán los próximos accesos de este usuario. Esta predicción se incorpora a Ia respuesta, junto con el objeto web requerido.

3. Cuando el navegador web del usuario está ocioso, pide por adelantado los objetos predichos por el servidor y se almacenan localmente.

4. Cuando el usuario accede al objeto predicho, se sirve Ia copia local del objeto con Io que se reduce el tiempo de descarga de Ia página.

En Ia patente estadounidense US-6094662 se describe un método para Ia carga y descarga de páginas HTML, donde se utiliza una marca de tiempo para identificar si Ia versión guardada en caché está actualizada o no.

Por otro lado, Ia patente estadounidense US-6182133 describe un método que realiza un prebúsqueda y descarga de ciertos elementos de información de acuerdo con aspectos predefinidos, y se Ie proporciona al usuario una indicación visual que Ie permite identificar dicha descarga previa.

DESCRIPCIóN DE LA INVENCIóN

La invención se refiere a un método de reducción del tiempo de descarga de páginas Web de acuerdo con Ia reivindicación 1. Realizaciones preferidas del método se describen en las reivindicaciones dependientes. A diferencia de los sistemas descritos anteriormente, el método definido en Ia presente invención anticipa los identificadores de frescura de los objetos sin esperar siquiera a Ia petición de algún objeto por parte del cliente.

La invención se refiere a un método de reducción del tiempo de descarga de una página de un servidor Web, en el que el servidor obtiene un identificador de frescura de cada objeto asociado a una URL de una relación de URLs que viene dada bien por el servidor, bien por el cliente.

De acuerdo con un primer aspecto de Ia invención: el servidor pone a disposición de un cliente dicha relación de URLs y los identificadores de frescura de dichos objetos asociados a las URLs antes de que el cliente solicite el objeto correspondiente; y, - el cliente utiliza dichos identificadores de frescura, una vez los reciba del servidor, para actualizar una marca de tiempo de un objeto que se encuentra en una caché del cliente y cuyo objeto tiene asociado una URL para Ia cual el servidor ha proporcionado el identificador de frescura.

Dicho identificador de frescura puede ser Ia fecha de última modificación, Ia edad o Ia etiqueta de entidad o e-tag del objeto.

De esta forma, antes de iniciar una petición de un objeto solicitado por un usuario, el cliente recibe una relación de URLs junto con sus identificadores de frescura actualizados.

El cliente recibe los identificadores de frescura del servidor bien porque los solicita de forma expresa: estableciendo una conexión con el servidor; solicitando al servidor dicha relación de URLs e identificadores de frescura; y el servidor Ie envía al cliente dicha relación de URLs e identificadores de frescura.

O bien el cliente recibe dichos identificadores de frescura porque el servidor Ia proporciona de forma predictiva de Ia siguiente forma: el servidor obtiene, a partir de un algoritmo de predicción, una lista de URLs predichas para cada objeto solicitado por el cliente; - para cada URL predicha de dicha lista, se adjunta el identificador de frescura del objeto asociado a cada URL predicha; y, el servidor envía al cliente, junto con el objeto solicitado, dicha lista de URLs predichas e identificadores de frescura.

Una vez que el cliente dispone de esta información, puede actualizar los identificadores de frescura de los objetos que tiene en caché y las fechas de caducidad de los mismos para que posteriores peticiones a esos objetos tengan mayores probabilidades de encontrarse frescos. Cabe destacar que

con esta forma de proceder alargaríamos el tiempo que un objeto permanece fresco en caché.

Otra forma de actuar con Ia información proporcionada de forma anticipada por el servidor es marcar como prevalidados los objetos de Ia caché que se encuentren en Ia relación suministrada por el servidor, de Ia siguiente forma (se incorpora una parte de predicción): el cliente, para cada objeto que se encuentra en caché y que está asociado a una URL proporcionada por el servidor junto con su identificador de frescura, realiza una comparación del identificador de frescura proporcionado por el servidor con una marca de tiempo de descarga en caché y si el objeto en caché sigue siendo fresco, marca dicho objeto como prevalidado; y cuando un usuario solicita una página Web a través de un cliente, en el cliente se descompone dicha página Web en objetos, y para cada objeto: - se comprueba si el objeto solicitado se encuentra en una caché del cliente, y

- si no se encuentra en caché, se efectúa una petición de dicho objeto al servidor de forma estándar;

- si el objeto se encuentra en Ia caché, dicho objeto tendrá asociada una marca de tiempo (fecha y hora) de caducidad, y se procede a verificar Ia caducidad del mismo, y en caso de que el objeto no esté caducado, el cliente sirve al usuario el objeto de Ia caché. Entonces: si el objeto se encuentra caducado en caché, se comprueba si éste ha sido marcado como prevalidado hace menos de un tiempo preestablecido; y,

- si el objeto ha sido marcado como prevalidado, el cliente sirve al usuario el objeto de Ia caché;

- si el objeto no ha sido marcado como prevalidado, se realiza una petición condicional de dicho objeto al servidor de forma estándar.

Dicha petición del objeto al servidor puede realizarse de Ia siguiente forma:

el cliente envía al servidor Ia petición del objeto incluyendo un identificador (Ia URL) de dicho objeto, e incluyéndose Ia cabecera correspondiente si Ia petición es condicional; en el servidor se ejecuta para dicho objeto peticionado por el cliente un método de predicción de objetos Web según ha sido definido en Io anterior; el servidor envía al cliente el objeto solicitado junto con dicha lista de predicciones y para cada predicción, dicho identificador de frescura.

Y el cliente puede efectuar dicho marcado de un objeto como prevalidado comparando una marca de tiempo de última modificación derivada de dicho identificador de frescura con Ia marca de tiempo de descarga en caché de dicho objeto; y si el objeto no ha sido modificado desde que fue descargado (es decir, si dicha marca de tiempo de descarga coincide o es posterior a Ia marca de tiempo de última modificación proporcionada por el identificador de frescura), se marca dicho objeto como prevalidado.

Es decir, si el objeto en caché no ha sido modificado desde que fue descargado, ya no es necesario efectuar Ia petición condicional al servidor de dicho objeto, por Io que el usuario se ahorra el RTT correspondiente a „ esperar Ia respuesta "Not Modified" del servidor. Por su parte, el servidor se ahorra tener que contestar a esta petición, por Io que su carga de trabajo también disminuye. Esto tiene un efecto positivo tanto en el usuario que se ha beneficiado de Ia predicción como indirectamente en el resto de usuarios por Ia disminución de Ia carga del servidor. Es decir, junto con cada respuesta a un objeto solicitado por un cliente, el servidor Web incluye una predicción de cuáles van a ser los próximos objetos que va a pedir el usuario; como es probable que estos objetos ya los tenga el cliente del usuario en su caché, el método de Ia invención propone que el servidor añada junto con cada objeto predicho el identificador de frescura del mismo. Si en un espacio de tiempo preestablecido (definible en el sistema), el usuario trata de acceder al objeto predicho (identificado por Ia pista dada en Ia predicción) y éste se encuentra

caducado en Ia caché, el cliente compara el identificador de frescura recibido junto al objeto con el identificador de frescura del objeto en caché. Si resulta que el objeto no ha sido modificado desde que fue descargado, ya no es necesario efectuar Ia petición condicional al servidor, con el consiguiente ahorro de recursos.

Es decir, el método propuesto en Ia presente invención se diferencia de Ia prebúsqueda tradicional en que, junto con Ia predicción de accesos, el servidor web anticipa otra información adicional -un identificador de frescura- que hace que el cliente sepa de antemano qué peticiones de acceso debe realizar y cuáles son innecesarias. De esta forma, se consigue reducir Ia carga de peticiones que recibe el servidor web y el tiempo de descarga de páginas percibido por el usuario. Todo ello sin incrementar el tráfico de red entre clientes y servidores. Según los estudios realizados, con esta nueva técnica, tanto Ia carga de peticiones del servidor web como el tiempo de descarga se reduce entre un 40% y un 60%.

La invención ha sido descrita para funcionar entre Cliente Web y Servidor Web, pero también puede funcionar entre Cliente Web y Servidor Proxy, entre Servidor Proxy y Servidor Web y entre dos servidores Proxy distintos y entre cualquier otra combinación en Ia que participen al menos dos elementos de Ia Arquitectura.

DESCRIPCIóN DE LOS DIBUJOS

Para complementar Ia descripción que se está realizando y con objeto de ayudar a una mejor comprensión de las características del invento, de acuerdo con un ejemplo preferente de realización práctica del mismo, se acompaña como parte integrante de dicha descripción, un juego de dibujos en donde con carácter ilustrativo y no limitativo, se ha representado Io siguiente:

La figura 1 muestra el funcionamiento básico de comunicación cliente-servidor en http.

La figura 2 muestra el diagrama de flujo de una posible forma de comunicación entre cliente-servidor según Ia presente invención.

La figura 3 muestra el diagrama de flujo de otra posible comunicación entre cliente-servidor según Ia presente invención.

La figura 4 muestra el diagrama de flujo de petición de una página web por parte de un usuario según el método de Ia presente invención. La figura 5 muestra el diagrama de flujo de Ia comunicación entre cliente-servidor según Ia presente invención.

La figura 6 muestra un gráfico de los resultados obtenidos al aplicar Ia invención a Ia web www.elpais.es con el algoritmo de predicción DG.

REALIZACIóN PREFERIDA DE LA INVENCIóN

En Ia figura 2 se muestra el diagrama de flujo de una posible comunicación entre cliente-servidor según Ia presente invención.

El servidor genera una relación de URLs e identificadores de frescura correspondientes y Ia pone a disposición del cliente (300). El cliente, sin que medie una petición por parte del usuario, solicita dicha relación de URLs e identificadores de frescura correspondientes (310). A continuación, el servidor envía esta relación al cliente (320). El cliente, para cada uno de los objetos que se encuentran en Ia caché y en Ia relación proporcionada por el servidor, actualiza Ia información de caducidad de dichos objetos con los identificadores de frescura recibidos (330).

En Ia figura 3 se muestra el diagrama de flujo de otra posibilidad de comunicación entre cliente-servidor según Ia presente invención.

El servidor genera una relación de URLs e identificadores de frescura correspondientes y Ia pone a disposición del cliente (500). El cliente, sin que medie una petición por parte del usuario, solicita los identificadores de frescura para las URLs de aquellos objetos que tuviere caducados en caché (510). A continuación, el servidor genera y envía esta relación al cliente (520). El cliente, para cada uno de los objetos que atendiendo a Ia información proporcionada por el servidor todavía se encuentren frescos, marca en su caché dichos objetos como prevalidados

(530). El cliente utiliza estas marcas de prevalidación según describe Ia figura 4.

A continuación se describe una realización preferida del método de reducción del tiempo de descarga de páginas web de Ia invención:

En Ia figura 4 se muestran los pasos seguidos cuando un usuario solicita una página web a través de un cliente. En el cliente, cuando el usuario solicita una página web, primero Ia descompone en objetos; y para cada objeto solicitado por el usuario (paso 100) se hace Io siguiente:

Se comprueba si el objeto solicitado se encuentra en Ia caché del cliente (decisión 110). Si no se encuentra (111), se efectúa una petición del objeto al servidor (paso 120; ver figura 5).

Si el objeto se encuentra en Ia caché (112), se verifica Ia fecha y hora de caducidad del mismo (decisión 130). En caso de que el objeto no esté caducado (131), el cliente sirve al usuario el objeto de Ia caché (paso 150). Y en caso de que el objeto se encuentre caducado (132), se realiza una comprobación de si éste ha sido prevalidado en los últimos X segundos

(decisión 140). Si ha sido prevalidado en ese tiempo preestablecido (por configuración, por ejemplo), se sirve al usuario el objeto de Ia caché (paso 150). En caso contrario, se realiza una petición condicional al servidor (paso 160; ver figura 5). En Ia figura 5 se muestra el diagrama de flujo de Ia comunicación entre cliente-servidor según Ia presente invención. Así, el cliente inicia una petición al servidor: resolución de nombre de dominio, establecimiento de conexión, etc. (paso 210), proporcionando un identificador de dicho objeto con el método GET de http; si Ia petición es condicional, se incluye Ia cabecera correspondiente.

El servidor obtiene, a partir de un algoritmo de predicción cualquiera, una lista de objetos candidatos a ser solicitados por el cliente próximamente o predicciones (paso 220).

Para cada predicción de Ia lista, el servidor obtiene un identificador de frescura (paso 230), como por ejemplo: marca de tiempo (fecha y hora) de última modificación, e-tag, edad, etc. y adjunta dicho identificador de frescura a Ia lista.

Se obtiene Ia respuesta a Ia petición de Ia forma usual y se adjunta Ia lista de predicciones junto con el identificador de frescura en Ia respuesta http, enviándose Ia respuesta al cliente (paso 240).

En el cliente se realiza una prevalidación para cada objeto de Ia lista de predicciones, y aquél objeto está fresco en Ia caché, se marca como prevalidado en el momento actual (250).

Las novedades del método de descarga propuesto residen en Ia generación de una relación de URLs e identificadores de frescura (pasos 300 y 500), en Ia toma de decisión respecto a si el objeto ha sido o no prevalidado en los últimos X segundos (paso 140), y en los pasos 230 y 250 relativos a añadir información adicional a Ia lista de predicciones y realizar Ia prevalidación para cada predicción, respectivamente.

Los experimentos realizados muestran que las mejoras en Ia latencia percibida por el usuario derivadas del empleo de esta técnica son considerables. Como ejemplo, en Ia figura 6 se puede apreciar que Ia latencia percibida por el usuario se puede reducir un 58% y las peticiones al servidor web un 68%. En este ejemplo se ha considerado el servidor web www.elpais.es y el algoritmo de predicción DG, ampliamente utilizado en el área de investigación. En el eje X está representado el índice Object Traffic Increase, que es el resultado de dividir el número de peticiones al servidor cuando se utiliza Ia técnica por el número de peticiones al servidor cuando no se utiliza. Así pues, un valor de 0.32 significa que se han reducido las peticiones del servidor un 68%. En el eje Y se representa el índice Latency per page ratio, que es el resultado de dividir Ia latencia percibida cuando se utiliza Ia técnica por Ia latencia percibida cuando no se utiliza. De esta forma, un valor de 0.42 significa que se ha reducido Ia latencia percibida por el usuario un 58%. Cada punto en Ia línea del gráfico representa una configuración determinada del algoritmo de predicción, por Io que Ia mejor configuración es Ia del punto representado en Ia esquina inferior izquierda de Ia figura.

La invención ha sido descrita para funcionar entre Cliente Web y

Servidor Web, pero también puede funcionar entre Cliente Web y Servidor Proxy, entre Servidor Proxy y Servidor Web y entre dos servidores Proxy distintos y entre cualquier otra combinación en Ia que participen al menos dos elementos de Ia Arquitectura.

A Ia vista de esta descripción y juego de figuras, el experto en Ia materia podrá entender que las realizaciones de Ia invención que se han descrito pueden ser combinadas de múltiples maneras dentro del objeto de Ia invención.