ES2317348T3

ES2317348T3 - Prioridades de transferencia de objeto en una red de comunicaciones.

Info

Publication number: ES2317348T3
Application number: ES06000930T
Authority: ES
Inventors: Daniel Schaffrath; Raphael Quinet
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2002-04-05
Filing date: 2002-04-05
Publication date: 2009-04-16
Anticipated expiration: 2022-04-05
Also published as: AU2002257754A1; CN100531186C; ATE413763T1; PT1493257E; ATE316312T1; EP1650931B1; CN1625877A; DE60208786D1; IL163889A0; EP1493257B1; ES2257543T3; DE60208786T2; US7721294B2; IL163889A; IL189779A; EP1650931A1; US20090077205A1; EP1493257A1; PT1650931E; WO2003085924A1

Abstract

Un método de operar un servidor proxy, en el que se asigna o ajusta una prioridad de un objeto a enviarse a un cliente, cuando se encuentre una referencia a dicho objeto en un objeto previo que se va a despachar al cliente.

Description

Prioridades de transferencia de objeto en una red de comunicaciones.

Antecedentes del invento 1. Campo técnico de aplicación

El invento se refiere en general al campo de las redes de comunicaciones, y más particularmente a una transferencia de objeto desde un primer componente de red a través de un componente intermediario a un segundo componente de red, cuyo segundo componente de red está distante del primer componente de red.

2. Descripción de la técnica anterior

La transferencia de información sobre redes de comunicaciones con módem como la red pública de Internet o las redes internas se basa en unos protocolos específicos de transferencia. La World Wide Web (en adelante WWW) por ejemplo, que constituye un aspecto importante de la Internet, usa el protocolo de transferencia de hipertexto (en adelante HTTP) para intercambiar archivos que comprenden imágenes de texto, sonido, vídeo, y otros contenidos.

Cualquier servidor de WWW contiene, además de los archivos que puede servir, un componente de HTTP que se ha diseñado para esperar por solicitudes de HTTP y para gestionarlas cuando llegan. Un explorador de WWW se puede considerar como un cliente de HTTP que está configurado para enviar solicitudes de HTTP a servidores de WWW. Cuandoquiera que un usuario del explorador introduce una solicitud de archivo, bien sea "abriendo" un archivo de WWW (tecleando en un localizador uniforme de recursos (en adelante URL)) o bien haciendo "clic" sobre un vínculo de hipertexto, el explorador acumula una solicitud correspondiente de HTTP para el archivo y la envía a la dirección de destino. El componente de HTTP del servidor de destino recibe la solicitud de HTTP y devuelve el archivo solicitado.

El archivo solicitado se podría constituir mediante una página de lenguaje de marca de hipertexto (en adelante HTML) que incluya código de HTML. Cuando el explorador recibe la página de HTML del servidor y detecta que el código de HTML, que se puede considerar como un objeto en sí mismo, incluye objetos adicionales tales como imágenes (de fondo), sonidos, secuencias de comandos, o tramos de HTML, el explorador emite solicitudes adicionales de HTTP al servidor con el fin de buscar los objetos adicionales que estén incluidos en el código HTML. Tras recibir las solicitudes adicionales de HTTP, el servidor envía al explorador las respuestas de HTTP incluyendo los objetos solicitados como imágenes. Como resulta evidente en la Figura 1, las respuestas de HTTP se envían desde el servidor al explorador que funciona sobre el cliente en el mismo orden que el explorador ha emitido las solicitudes de HTTP.

El orden en que cualesquiera objetos adicionales incluidos en el código de HTML de la página de HTML son solicitados por el explorador depende usualmente de cómo se haya escrito la página de HTML. Por ejemplo, un objeto que se haya incluido en el principio del código de HTML no se presenta en forma visual necesariamente en la parte superior de la página de HTML porque características tales como tablas, estratos y tramos permiten al autor del HTML usar disposiciones generales complejas. Además, el orden en que un explorador emite solicitudes de HTTP depende también de algoritmos internos del explorador. Por ejemplo, algunos exploradores usan una heurística compleja para generar las solicitudes de HTTP comenzando por solicitar los cuatro primeros objetos tal como aparecen en el código de HTML de la página. Después que se han solicitado los cuatro primeros objetos, se solicitan cada dos objetos comenzando por la parte superior del área que está visible actualmente al usuario, luego cada cuatro objetos, y así sucesivamente. Otros exploradores usan un algoritmo más sencillo que solicita los objetos uno por uno según aparecen en el código de HTML. De lo anteriormente expuesto, resulta evidente que usualmente es difícil predecir el orden en que se generan solicitudes de HTTP para objetos a los que se haya hecho referencia en un código de HTML

Más aún, es difícil predecir el orden en que los objetos solicitados son recibidos por el explorador. Aunque la norma actual de HTTP (HTTP/1.1) requiere que en cada conexión de protocolo de control de transferencia (en adelante TCP) las respuestas de HTTP se envíen desde el servidor al explorador en el mismo orden que las solicitudes de HTTP son recibidas por el servidor, el orden en que las respuestas de HTTP son recibidas se vuelve imprevisible en cuanto se abre más de una conexión al servidor. Por tanto, la razón es el hecho de que, debido a condiciones variables de red y a diferentes tiempos de tratamiento de las solicitudes, algunas conexiones podrían transferir respuestas de HTTP más deprisa que otras.

El documento US 5987466 describe un método de explorar la WWW de la Internet y de presentar los elementos de una página web a un usuario. El explorador de web solicita un HTML deseado y luego solicita otros elementos de la página basándose en niveles de prioridad definidos por el usuario. Los elementos se presentan al usuario en secuencia de prioridad tan pronto como se reciben.

En el documento US-A-6 144 996 se describe un servidor proxy para acelerar la transferencia de objetos web mediante la entrega retardada de una página web si el contenido de la página no está localmente almacenada en su totalidad en el proxy.

Se necesita un método y un dispositivo que habilite una transferencia perfeccionada de objetos desde un primer componente de red a un segundo componente de red que está distante del primer componente de red.

Sumario del invento

Esta necesidad se satisface mediante la enseñanza de las reivindicaciones independientes. En las reivindicaciones subordinadas se describen realizaciones adicionales preferidas.

De acuerdo con un aspecto del invento, esta necesidad se satisface mediante un método de controlar, en una red de comunicaciones, una transferencia de objeto desde un primer componente por medio de un componente intermedio (de hardware o de software) a un segundo componente que está distante del primer componente, en el que la transferencia de objeto se basa en una pluralidad de solicitudes de objeto a los que se hace referencia en uno o más códigos que se van a procesar mediante el segundo u otro componente de la red de comunicaciones; el componente intermedio realiza las etapas de enviar una solicitud de objeto al primer componente, recibir del primer componente el objeto solicitado, al menos la de establecer y/o actualizar una prioridad del objeto solicitado, en el que se ha asignado una prioridad inicial al objeto solicitado basándose en un análisis de al menos uno de la solicitud de objeto y del código que se refiere al objeto solicitado, y, con independencia de la prioridad del objeto solicitado, retardar el objeto solicitado o enviar el objeto solicitado al segundo componente. Un objeto podría comprender en sí mismo partes de código referentes a uno o más objetos adicionales. Además, un código podría comprender por sí mismo un objeto (por ejemplo, solicitado previamente).

Mediante el retardo intencionado de la transferencia de un objeto basándose en una prioridad asignada, se mejora la transferencia global de objetos desde un punto de vista del usuario (incluso si no se ha disminuido la cantidad total de objetos a transferir), porque los objetos importantes se transfieren con carácter preferencial. Además, mediante la implementación de esquemas apropiados de asignación de prioridad se hace más previsible la transferencia de objetos desde el primer componente de red al segundo componente de red. Por ejemplo, a los objetos que tengan una significación mayor para el usuario se les puede asignar una prioridad más alta y de ese modo se podrían transmitir preferencialmente al segundo componente. Por el contrario, los objetos que tengan una significación menor se podrían retardar. En el caso extremo, un objeto que tuviese poca significación se podría retardar hasta un grado tal que no se transmitiese en absoluto al segundo componente. Esto permite controlar el orden en que los objetos son recibidos por el segundo componente.

La asignación de prioridades absolutas o relativas a los objetos (o a clases de objetos) se podría realizar de un modo dinámico. Una vez que se ha asignado inicialmente una prioridad, esta prioridad se puede establecer con respecto a valores absolutos específicos como umbrales o con respecto a prioridades de otros objetos. Basándose en el establecimiento, se puede decidir si se va a retardar o no un objeto. Antes del establecimiento, se podría evaluar de nuevo una prioridad asignada inicialmente a un objeto con el fin de determinar si la prioridad inicial tiene que actualizarse.

El componente intermedio se podría operar para reordenar objetos recibidos del primer componente. De ese modo, el retardo de los objetos se realiza preferiblemente de tal manera que el orden en que el componente intermedio recibe los objetos del primer componente difiera del orden en que los objetos se transmiten al segundo componente. La reordenación se podría basar en las prioridades de los objetos a transferir. Durante la reordenación, podría surgir la situación en la que, debido al retardo de algunos objetos, se acelerase realmente la transferencia de otros objetos.

La solicitud de objeto que se ha enviado al primer componente podría ser generada por el componente intermedio. Cuando el objeto solicitado es recibido por el componente intermedio, éste lo "impulsa" al segundo componente, sin haber recibido una solicitud explícita de objeto del segundo componente. Alternativamente, la solicitud de objeto podría ser generada por el segundo componente y enviarse al componente intermedio. Tras la recepción de la solicitud de objeto del segundo componente, se podría procesar por el componente intermedio y enviarse al primer componente.

Cuando el componente intermedio recibe del primer componente el objeto solicitado, el objeto recibido podría o bien retardarse o bien enviarse directamente al segundo componente. Existen diversas posibilidades en la forma en que se podría retardar el objeto solicitado que es recibido por el componente intermedio. El retardo del objeto solicitado puede incluir, por ejemplo, al menos una de las operaciones de dar instrucciones al segundo componente para que repita la solicitud de objeto, suspender una conexión al segundo componente de red por medio del cual se va a enviar el objeto solicitado, e informar al segundo componente de que el objeto solicitado se enviará automáticamente (por ejemplo, sin ninguna solicitud adicional de objeto del segundo componente) al segundo componente en un instante posterior.

Si el retardo del objeto solicitado incluye dar instrucciones al segundo componente de repetir la solicitud de objeto, el componente intermedio podría realizar las etapas de asignar un atributo específico al objeto a retardar, informar del atributo al segundo componente, recibir una referencia al atributo (por ejemplo, el propio atributo o una referencia no ambigua obtenida del atributo) del segundo componente y, después de recibir la referencia al atributo, enviar el objeto retardado al segundo componente o retardar más el objeto retardado. La decisión de si un objeto retardado tiene que enviarse al segundo componente o retardarse adicionalmente se podría basar en la prioridad relativa recientemente establecida del objeto solicitado repetidamente.

El atributo se puede considerar como un denominador común que permite que el componente intermedio y el segundo componente decidan sobre la transferencia del objeto al que se ha asignado el atributo. Usualmente, la forma del atributo depende de las características del protocolo de transferencia que se haya usado para la transferencia del objeto. Por ejemplo, en el caso del HTTP, el atributo podría estar constituido por un URL virtual creado por el componente intermedio. Debe hacerse notar que el plan de retardo basado en un atributo de dar instrucciones al segundo componente para repetir la solicitud de objeto se puede usar generalmente para retardar objetos, y no requiere necesariamente que se hayan asignado prioridades a los objetos a transferir.

En el esquema de retardo basado en la asignación de un atributo, el objeto se podría enviar desde el componente intermedio al segundo componente en respuesta a una solicitud de objeto recibida del segundo componente o de acuerdo con un plan de impulsión, es decir, independientemente de dicha solicitud de objeto desde el segundo componente. Si el esquema de retardo se basa en una solicitud de objeto recibida del segundo componente, el segundo componente podría ser informado sobre el atributo en contexto con una instrucción para repetir la solicitud de objeto. En tal caso, la referencia al atributo podría ser recibida por el componente intermedio en contexto con una solicitud repetida de objeto procedente del segundo componente.

Los objetos a transferir al segundo componente se pueden transmitir al segundo componente por medio de una sola conexión o mediante una pluralidad de conexiones entre el componente intermedio y el segundo componente. En el caso de las múltiples conexiones, las seleccionadas de las conexiones al segundo componente se podrían suspender, dependiendo de las prioridades (inicial o actualizada) de los objetos solicitados que se van a enviar por medio de las seleccionadas de las conexiones al segundo componente. Así, el componente intermedio podría suspender una o más conexiones, de tal manera que los objetos que tengan una prioridad alta puedan hacer uso del ancho de banda adicional que se libera en el vínculo entre el componente intermedio y el segundo componente. Con el fin de no desperdiciar el ancho de banda disponible, el componente intermedio se configura preferiblemente de tal manera que asegure que un vínculo formado por una o más conexiones se usa totalmente antes de suspender una o más conexiones del mismo.

Existen varias técnicas para suspender una conexión. Por ejemplo, se podría bloquear la transmisión sobre la conexión durante un período de tiempo específico mientras se deja la conexión como tal (estado intermedio = abierta). Alternativamente, la conexión se podría cerrar (estado intermedio = cerrado) mientras se guarda el estado de la conexión. En tal caso, la conexión se podría volver a abrir en un instante posterior en el mismo estado en el que se ha cerrado. De acuerdo con una tercera posibilidad, la conexión se podría cerrar por completo sin guardar ninguna información sobre el estado de la conexión. En cualquier caso, se puede informar al segundo componente que el objeto o los objetos que se van a transmitir a través de la conexión cerrada se enviarán posteriormente, bien en respuesta a o independientemente de una solicitud de objeto (repetida).

En lugar de o además de suspender conexiones individuales, la transferencia de objeto se podría retardar también mediante un ajuste basado en la prioridad de la velocidad de transferencia. En este sentido, se podría asignar dinámicamente una participación específica de posibilidades de tratamiento a cada objeto o a cada conexión. En el caso de conexiones múltiples, todas las conexiones o al menos algunas conexiones obtienen una participación del tiempo de unidad central de tratamiento (en adelante CPU), es decir, una participación en el ancho de banda de red. La participación de las posibilidades de tratamiento asignada a una conexión específica se podría cambiar (por ejemplo disminuyéndola constantemente) mientras uno o más objetos son transferidos por medio de la conexión respectiva.

Se ha mencionado anteriormente que la transferencia de objeto se basa en una pluralidad de solicitudes de objeto relacionada con objetos a los que se ha hecho referencia en uno o más códigos. De acuerdo con una primera variante del invento, se dispone fácilmente de un código para al menos uno del segundo componente y del componente intermedio. De acuerdo con una segunda variante del invento, el código tiene todavía que cargarse por uno cualquiera del segundo componente y del componente intermedio. En éste último caso, el componente intermedio podría enviar una solicitud de código que se ha generado por el segundo componente o por el componente intermedio al primer componente o a un tercer componente que sea diferente del primer componente. Cuando se recibe del primer componente o del tercer componente el código solicitado, podría ser analizado por el componente intermedio con respecto a referencias a objetos comprendidos dentro del código. Entonces, se podrían establecer cualesquiera referencias a objetos contenidos en el código con el fin de asignar prioridades (iniciales) a los objetos a los que se haya hecho referencia en el código recibido. El código recibido del primer o del tercer componente se podría enviar eventualmente por el componente intermedio al segundo componente.

Tras recibir una respuesta del primer componente, el objeto solicitado contenido en la respuesta se podría evaluar con respecto a la prioridad del objeto recibido. Por ejemplo, en ese sentido se podrían analizar al menos uno del tamaño del objeto, contenido del objeto y un encabezamiento de la respuesta. Luego, se puede determinar si tiene que actualizarse o no una prioridad inicial de un objeto recibido.

Preferiblemente, al menos alguna información sobre cada objeto o cada clase de objeto se guarda, por ejemplo, mediante el componente intermedio. La información guardada podría comprender información de prioridad para objetos individuales o clases de objetos, en la forma de una lista de prioridades. Esta lista de prioridades se podría establecer en repetidas ocasiones. Este establecimiento se podría relacionar al menos con una operación de actualizar la información de prioridad y de suprimir objetos o clases de objetos de la lista de prioridades.

El invento se podría realizar como una solución de hardware o como una solución de software. En el caso de una solución de hardware, el invento se podría realizar en la forma de un producto de programa de ordenador que comprenda partes de código de programa para llevar a cabo las etapas individuales del invento. El producto de programa de ordenador se podría guardar en un medio de almacenamiento legible por ordenador.

De acuerdo con una realización preferida del invento, el componente intermedio se implementa como un componente proxy (filtro) en la forma de una parte de software que se ejecuta sobre el primero o el segundo componente de la red de comunicaciones. Si el invento se va a implementar como una solución de hardware, el componente intermedio podría estar constituido por una parte separada de hardware como un servidor proxy dispuesto entre los componentes primero y segundo en la red de comunicaciones. El componente intermedio podría incluir una o más interfaces de comunicación apropiadamente configuradas para comunicar con al menos el primero y el segundo componente de la red de comunicaciones, así como por una unidad para realizar el tratamiento en contexto con el retardo de objetos.

En la red de comunicaciones existe un primer vínculo entre el componente intermedio y el primer componente y un segundo vínculo entre el componente intermedio y el segundo componente. Preferiblemente, el primer vínculo y el segundo vínculo tienen diferentes tasas de transferencia. Por ejemplo, se podría proveer un vínculo rápido entre el componente intermedio y el primer componente, y un vínculo comparativamente más lento entre el componente intermedio y el segundo componente. Esta situación se presenta usualmente cuando el primer componente es un servidor de red, el segundo componente es un cliente de red y el componente intermedio está situado en las proximidades de (en cuanto a vínculos de red) o en el servidor de red. No obstante, el componente intermedio podría también estar situado muy cerca (en cuanto a vínculos de red) o en el cliente de red. En tal caso, el vínculo entre el componente intermedio y el segundo componente (el cliente de red) tiene una capacidad mucho mayor y un estado latente mucho menor que el vínculo entre el componente intermedio y el primer componente (el servidor de red).

Debe hacerse notar que el invento no está restringido al caso en que el primer componente actúa como un servidor de red y el segundo componente actúa como un cliente de red. En particular, el componente intermedio se podría usar también para mejorar la transferencia de objetos entre dos clientes de red o dos servidores de red.

De acuerdo con una realización especialmente preferida del invento, el componente intermedio es parte de una red de comunicaciones inalámbricas como una red celular GSM, GPRS, etc. En dicha red, el segundo componente podría estar constituido por un terminal móvil.

Breve descripción de los dibujos

Los aspectos y ventajas adicionales del invento resultarán evidentes tras la lectura de la siguiente descripción detallada de realizaciones preferidas del invento y con referencia a los dibujos, en los que:

La Figura 1 es un diagrama esquemático que ilustra una transferencia de objeto entre un servidor de red y un cliente de red de acuerdo con el HTTP;

La Figura 2 es un diagrama de bloques de un sistema de red que comprende un componente intermedio en la forma de un servidor proxy de HTTP de acuerdo con el invento;

La Figura 3 es un diagrama de bloques del servidor proxy de HTTP de la Figura 2;

La Figura 4 es un diagrama esquemático que representa un retardo de objeto basado en redirección en el sistema de red dibujado en la Figura 2;

La Figura 5 es un diagrama de flujo que refleja las etapas que preceden a un retardo de objeto;

La Figura 6 es un diagrama de flujo que presenta las decisiones implicadas en una transferencia de objeto de acuerdo con el invento; y

La Figura 7 es un diagrama de bloques que representa un componente proxy de acuerdo con el invento situado en un cliente de red.

Descripción de una realización preferida

Aunque el presente invento se puede llevar a la práctica en cualquier red de comunicaciones en la que se realice una transferencia de objeto basada en solicitudes a través de un componente intermedio, la descripción que sigue de realizaciones preferidas se expone a título de ejemplo con respecto a la transferencia de código HTML de acuerdo con el protocolo HTTP sobre la WWW. En principio, se podrían usar también protocolos de transferencia diferentes del HTTP, como el protocolo de transporte inalámbrico WAP o algunos mecanismos de llamada de procedimiento distante (en adelante RPC), y códigos diferentes del HTML, por ejemplo el lenguaje WAP (en adelante WML) o cualesquiera derivaciones del lenguaje extensible (en adelante XML). Además, aunque la descripción siguiente concierne principalmente a una transferencia de objeto de un servidor a un cliente, la transferencia de objeto se podría realizar también entre cualesquiera de dos o más componentes de red.

En la Figura 2 se ha representado un diagrama de bloques de un sistema de red 10 de acuerdo con el invento. Como resulta evidente a partir de esta Figura, el sistema 10 de red comprende un primer componente en la forma de un servidor 20, un componente intermedio en la forma de un servidor proxy 30 de HTTP y un segundo componente en la forma de un cliente 40. El servidor proxy 30 está dispuesto en el sistema 10 de red de tal manera que tiene un vínculo rápido 12 hacia el servidor 20 y un vínculo 14 comparativamente más lento hacia el cliente 40. Cada vínculo 12, 14 está constituido por una pluralidad de conexiones de protocolo de control de transmisión (en adelante TCP) 50. Cada conexión 50 de TCP está configurada para permitir la transferencia de las solicitudes de HTTP y las respuestas de HTTP entre el servidor 20 y el cliente 40.

El servidor proxy 30 realiza algunas funciones tradicionales de filtración tales como acumular y filtrar objetos. Adicionalmente, el servidor proxy 30 está configurado para retardar artificialmente un objeto que se recibe del servidor 20 y que tiene que enviarse al cliente 40. Esto se hace mediante el uso de una combinación de suspensión temporal de transferencia de datos en algunas conexiones 50 y de mensajes de redirección de HTTP que fuerzan a un explorador que funciona sobre el cliente 40 a repetir un objeto solicitado después de un período determinado de tiempo. Mediante el uso de estos mecanismos, el servidor proxy 30 reordena las respuestas de HTTP recibidas del servidor 20 de tal manera que los objetos que tengan una prioridad mayor se descarguen primero al cliente 40. Para este fin, el servidor proxy 20 asigna dinámicamente prioridades a los objetos que se van a enviar al cliente 40. Con el fin de asegurar que el retardo de los objetos menos importantes no dé lugar a que el vínculo 14 entre el servidor proxy 30 y el cliente 40 llegue a trabajar en vacío, el servidor proxy 30 vigila continuamente o al menos repetidamente el tráfico en este vínculo 14.

En la Figura 3 se ha representado con más detalle la construcción del servidor proxy 30. Como se puede ver evidentemente en la Figura 3, el servidor proxy 20 comprende una interfaz 32 de comunicaciones acoplada entre el primer vínculo 12 al servidor 20 y el segundo vínculo al cliente 40. La interfaz 32 de comunicaciones está configurada de tal manera que permite el envío de solicitudes de objeto para finalizar la recepción de los objetos solicitados del servidor 20. Una unidad 34 de tratamiento del servidor proxy 30 comunica con la interfaz 32 de comunicaciones. La unidad 34 de tratamiento permite establecer y/o adaptar la prioridad de cualquier objeto recibido del servidor 20 por medio del primer vínculo 12. Adicionalmente, la unidad 34 de tratamiento permite asignar una prioridad inicial a un objeto solicitado basándose en un análisis de al menos uno de la solicitud de objeto y del código que se refiere al objeto solicitado. Más adelante se describen con más detalle esquemas posibles de asignación.

Dependiendo de la prioridad inicial o actualizada de un objeto solicitado, la unidad 34 de tratamiento controla la interfaz 32 de comunicaciones de tal manera que un objeto solicitado recibido del servidor 30 es retardado o enviado a través del segundo vínculo 14 al cliente 40. Si un objeto solicitado recibido del servidor 20 tiene que retardarse, se guarda provisionalmente en una memoria intermedia 36 a la que se puede acceder tanto por medio de la interfaz 32 de comunicaciones como por la unidad 34 de tratamiento. Alternativa o adicionalmente, la memoria intermedia 36 se puede implementar como un componente de software o de hardware de la unidad 34 de tratamiento.

Además de las tareas anteriormente descritas, la unidad 34 de tratamiento está configurada adicionalmente de tal manera que permita asignar un atributo específico a un objeto que tiene que retardarse (un formato ejemplar de este atributo se describe más adelante con mayor detalle). La unida 34 de tratamiento permite controlar la interfaz 32 de comunicaciones de tal manera que la interfaz 32 de comunicaciones informe al cliente 40 sobre este atributo. Si la interfaz 32 de comunicaciones recibe del cliente 40 una referencia al atributo, la unidad 34 de tratamiento evalúa esta referencia y controla la interfaz 32 de comunicaciones de tal manera que el objeto retardado al que se ha asignado previamente este atributo y que actualmente está guardado en la memoria intermedia 36, o bien es enviado al cliente 40, o bien se retarda adicionalmente. Podría llegar a ser necesario un retardo adicional del objeto guardado en la memoria intermedia 36 si deben enviarse primero al cliente 40 objetos de una prioridad más alta.

A continuación se describe, a título de ejemplo, un modo operativo preferido del sistema 10 de red mostrado en la Figura 2.

Cuando un usuario entra en un URL, hace clic en un vínculo o sigue una señal, el explorador que se ejecuta sobre el cliente 40 emite una solicitud de HTTP para la correspondiente página de HTML que incluye el código de HTML. La solicitud de HTTP emitida por el explorador es recibida por el servidor proxy 30 a través del vínculo 14 y enviada a través del vínculo 12 al servidor de destino 20. El servidor 20 contesta enviando el código de HTML para la página solicitada al servidor proxy 30, el cual analiza el código de HTML recibido del servidor 20 para asignar una prioridad inicial a cualquier clase de objetos como vínculos, tramos, secuencias de comandos, imágenes, etc, a los que se haya hecho referencia en el código de HTML (fase de primer análisis).

Independientemente de este análisis del código HTML, el servidor proxy 30 envía el código de HTML a través del vínculo 14 al cliente 40. Cuando el explorador que se ejecuta sobre el cliente 40 recibe la página de HTML que incluye el código de HTML, procesa el código de HTML. Si el explorador detecta que el código de HTML incluye objetos adicionales, emite solicitudes adicionales de HTTP para los objetos a los que se haya hecho referencia en el código de HTML. Estas solicitudes de HTTP para objetos adicionales se reciben y evalúan mediante el servidor proxy 30. Para la mayor parte de los objetos solicitados, se habrá asignado ya una prioridad inicial durante el análisis previo por parte del servidor proxy 30 del código de HTML que se haya enviado al servidor 30. Sin embargo, en esta segunda fase de análisis el servidor proxy 30 o bien asigna prioridades iniciales a los objetos a los que no se haya asignado aún una prioridad, o bien actualiza la prioridad de dichos objetos a los que ya se haya asignado una prioridad. La prioridad se actualiza basándose en la información disponible en la solicitud de HTTP recibida del cliente 40.

El servidor proxy 30 envía al servidor 20 cualesquiera solicitudes HTTP de objetos adicionales recibidas del cliente 40. El servidor 20 responde enviando los objetos solicitados al servidor proxy 30. El servidor proxy 30 analiza las respuestas de HTTP (incluyendo los objetos solicitados) del servidor 20 en una tercera fase de análisis y actualiza - si es necesario - las prioridades de los objetos comprendidos en la respuesta de HTTP. Adicionalmente, el servidor proxy 30 establece la prioridad relativa de cualquier objeto recibido con respecto a la prioridad de objetos recibidos previamente que todavía estén guardados en la memoria intermedia 36 (véase Figura 3) y las prioridades de los objetos que se esperan pronto. La información relativa a los objetos que se recibirán pronto del servidor 20 se puede obtener del código de HTML que haya sido enviado previamente al cliente 40 o de las solicitudes de HTML del cliente 40 para las que los objetos correspondientes no se hayan recibido todavía del servidor 20. Alternativa o adicionalmente, el servidor proxy 30 podría configurarse de tal manera que compare una prioridad de un objeto que se acabe de recibir del servidor 40 con un valor absoluto como un umbral de prioridad.

Basándose en la evaluación de la prioridad absoluta o relativa de un objeto y en el tráfico actual y/o previsto en el vínculo 14, el servidor proxy 30 decide si hay que retrasar este objeto, por ejemplo, si este objeto se va a guardar provisionalmente en la memoria intermedia 36 o si la correspondiente solicitud de HTTP no se va a enviar todavía al servidor 20, o si el objeto se va a enviar inmediatamente al cliente 40.

El retardo intencionado de los objetos individuales mejora la transferencia total de objetos desde el punto de vista de un usuario. Por ejemplo, es bien sabido que la importancia relativa de los diversos objetos incluidos en una página web varía enormemente: una imagen que se use para construir un menú gráfico podría ser esencial para la navegación de un sitio, mientras que una imagen de fondo simplemente hace que la página parezca más bonita. Por tanto, el invento se puede emplear para proporcionar al usuario en primer lugar la información más importante. Tan pronto como haya suficiente información de una página web presentada visualmente en la pantalla de un usuario, éste puede decidir hacer clic en un vínculo y solicitar otra página web sin tener que esperar por las partes restantes (menos importantes) de la página web anterior que todavía se está transfiriendo. Como resultado, el usuario ya no está obligado a esperar hasta que sean transferidos algunos objetos no interesantes antes de poder ver los importantes. Esto es especialmente útil conjuntamente con la Internet móvil, que usualmente es más lenta y más cara que la Internet fija.

Asignación y ajuste de prioridades

Como ha resultado evidente a partir de lo anteriormente expuesto, el servidor proxy 30 puede asignar o ajustar la prioridad de un objeto a enviar al cliente 20 durante tres fases diferentes, a saber, cuando se ha encontrado en un código de HTML una referencia a ese objeto (es decir, en un objeto previo) que tenga que enviarse al cliente 40, cuando el explorador que ejecuta sobre el cliente 40 emite una solicitud de HTTP relacionada con dicho objeto, o cuando la respuesta correspondiente HTTP que contiene el objeto solicitado se recibe del servidor 20.

En lo que sigue se describen a título de ejemplo varios planes para asignar o actualizar prioridades durante cada una de estas tres fases. Durante cualquiera de las tres fases, se genera o actualiza una lista de prioridades que contiene información de prioridad para objetos individuales o clases de objetos. En la lista de prioridades, los objetos individuales o clases de objetos se ordenan con respecto a una prioridad creciente o decreciente. El orden de los objetos en la lista de prioridades se puede considerar así como información de prioridad. Sin embargo, la información adicional de prioridad como los valores (números) absolutos o relativos de prioridad podría alternativa o adicionalmente formar parte de la lista de prioridades.

La prioridad exacta asignada a objetos o clases de objetos específicas depende de la implementación, y, en la realización ejemplar, es configurable por el operador del servidor proxy 30 o por un usuario del explorador que funciona sobre el cliente 40. Por ejemplo, con el fin de permitir que el operador del servidor proxy 20 tenga más control sobre la prioridad de algunos objetos, podrían existir una o varias listas de URL (usando conjugación de patrones) que permitan que el operador aumente o disminuya la prioridad de los objetos que aparezcan en estas listas. Por ejemplo, un operador podría decidir aumentar o disminuir la prioridad de todas las imágenes descargadas de una compañía de publicidad. Las mismas posibilidades se podrían poner a la disposición del usuario. Por ejemplo, el usuario podría enviar sus preferencias al servidor proxy 30. Esto puede hacerse mediante un software específico que se ejecute sobre el cliente 40 o bien utilizando páginas web designadas provistas directamente por el servidor proxy 30 y que permitan al usuario ajustar sus preferencias.

En la primera fase de análisis, el servidor proxy 30 puede asignar una prioridad inicial a un objeto mediante el análisis de un código de HTML que haya sido solicitado del servidor 20 por el cliente 40. En particular, se podrían establecer en ese sentido referencias a objetos a los que se haya hecho referencia en el código de HTML. De este modo, se podría generar una lista de prioridades que relacione objetos individuales a los que se haya hecho referencia en el código de HTML en el orden siguiente (los objetos con la máxima prioridad se mencionan en primer lugar):

- vínculos con otras páginas

- tramos de datos

- imágenes en línea (si la etiqueta IMG incluye información de anchura y altura, esta información se puede usar para realinear la prioridad de las imágenes dependiendo de las dimensiones previstas, de tal manera que las imágenes más pequeñas tengan una prioridad más alta que las imágenes grandes).

- hojas de estilo

- secuencias de comandos (JavaScript, VBScript, etc.), objetos empotrados y subprogramas

- imagen de fondo (fondo de página, fondo de mesa, hoja de estilo, etc.

- cualquier objeto que ya se haya enviado al cliente 40 obtiene la prioridad mínima.

Además, se puede disminuir la prioridad de un objeto específico si el objeto no está situado en el mismo servidor 20 o en el mismo dominio que la página actual de HTML.

Se produce una posibilidad adicional para asignar o ajustar la prioridad de un objeto cuando el explorador emite una solicitud para ese objeto y dicha solicitud es recibida por el servidor proxy 30. En tal caso, el servidor proxy 30 puede analizar la solicitud de HTTP en un contexto de URL (segunda fase de análisis). Puesto que ya se han asignado las prioridades iniciales durante el análisis del código de HTML que condujo a esa solicitud de HTTP, el análisis de la solicitud de HTTP resultará usualmente en un ajuste de la prioridad inicial. Sin embargo, en algunos casos se podrían asignar también prioridades iniciales (véase descripción anterior).

El ajuste o la asignación de prioridades iniciales en la segunda fase de análisis se pueden realizar dependiendo de la información adicional disponible, por ejemplo, en el encabezamiento de la solicitud de HTTP. Se podrían implementar una o más de las reglas siguientes para actualizar las prioridades:

-: El análisis conduce al resultado de que el explorador ya ha solicitado una vez el mismo objeto. A dicho objeto usualmente se le asigna una prioridad muy alta, con el fin de evitar los bucles infinitos causados por exploradores que no cumplan la norma HTTP/1 e ignoren el encabezamiento "Reintentar- Después de" (este encabezamiento se describe con más detalle a continuación).

-: El objeto no tiene todavía una prioridad, pero la extensión parece como HTML (HTML), "HTM", o XML ("XML") o parece como un índice de directorio (finales en "/"). Esta asignación de prioridad asegura que una página de HTML solicitada de las señales o tecleada directamente se solicitará con una prioridad alta.

- El explorador hace una solicitud condicional de HTTP para un objeto, usando condiciones si-modificada-desde o condiciones similares. Esto indica que el explorador ha guardado probablemente una copia del objeto. Se espera que la respuesta sea pequeña si la copia guardada todavía es válida (código de HTML de respuesta "304 no modificado").

- Se encontró el URL del objeto solicitado mientras se analizaba una página de HTML anterior.

- Cualquier objeto que no se hubiese insertado en la lista mientras se analizaban las etiquetas de HTML de una página anterior se solicitó probablemente de un modo indirecto mediante una secuencia de comandos, y debería obtener una prioridad menor que la mayor parte de los objetos solicitados.

En la tercera fase de análisis, el ajuste de las prioridades de los objetos se basó en un análisis de la respuesta de HTTP del servidor 20. El ajuste de las prioridades en la tercera fase de análisis (así como en la segunda fase de análisis anteriormente mencionada) se puede calcular como una suma ponderada de varios criterios. Los pesos relativos podrían ser configurables por el operador del servidor proxy 30 o por el usuario del explorador que funciona sobre el cliente 40.

En la tercera fase de análisis, todos los objetos tendrán probablemente una prioridad asignada a ellos. Sin embargo, esta prioridad se puede actualizar antes de enviar los objetos solicitados al cliente 40. Para ajustar las prioridades, se podrían establecer los encabezamientos y contenidos de las respuestas HTTP recibidas del servidor 20. Luego se podrían ajustar las prioridades de acuerdo con una o más de las reglas siguientes.

- Establecimiento del código de respuesta: la prioridad relativa de las respuestas de HTTP depende del primer dígito del código de respuesta. Los códigos de error (4xx.5xx) deberían tener una prioridad más alta que las respuestas normales (2xx).

- Establecimiento del tipo de contenido: un código de HTML debería tener una prioridad mayor que cualquier imagen.

- Establecimiento del tamaño de los objetos (obtenido de la longitud del contenido si se ha especificado en los encabezamientos, o del tamaño total si el objeto ya se ha guardado): los objetos más pequeños deberían tener una prioridad un poco mayor que los grandes.

- Análisis del contenido: por ejemplo, a las imágenes animadas se les puede asignar una prioridad menor que a las imágenes estáticas. El análisis del contenido puede también constituir la base para estimar el tamaño del objeto si no se dispone de esta información en el encabezamiento de HTTP y el objeto no se ha guardado todavía.

- Si el código de respuesta es una redirección permanente o provisional (3xx) que especifique una nueva localización para el objeto solicitado, entonces esta nueva localización obtiene la misma prioridad que el objeto original.

En las tres fases de análisis anteriormente descritas, el servidor proxy 30 establece y actualiza las prioridades de los objetos que se van a transferir al cliente 40. De ese modo, el servidor proxy 30 mantiene cierta información sobre cada objeto como el URL de objetos, prioridad, hora de la última solicitud y, si se requiere, algunos parámetros adicionales. Sin embargo, esta información no se puede mantener indefinidamente, porque de lo contrario el servidor proxy 30 funcionaría fuera de memoria. Además, si a un objeto al que se haya asignado una prioridad alta nunca se le solicita, se toma preferiblemente la medida de que no impida que se transfieran otros objetos.

Por estas razones, se implementa una rutina que asegure que se suprima la información que ya no esté actualizada o que ya no se necesite. Para ello, se podrían usar uno o más de los mecanismos siguientes:

- Cualquier objeto que se haya transferido de forma satisfactoria al cliente es marcado como que se ha enviado o se traslada a una lista separada de objetos que se han enviado al cliente 40.

- Se establece un tamaño máximo para una o más listas que contengan información relevante y se configura que los objetos más antiguos o los objetos con la mínima prioridad caduquen primero.

- Siempre que el cliente reconfigura una conexión de TCP antes de que el objeto se haya transferido totalmente (lo que significa que el usuario ha detenido la descarga y podría haber seleccionado otra página), aclarar la información de los objetos a enviar.

- Como una alternativa a la solución anterior, mantener contrarreferencias para cada objeto con el fin de asociar cada página de HTML con los objetos que contiene, y viceversa. Cuando el cliente 40 reconfigura una conexión de TCP, retirar solamente los objetos que están incluidos en la misma página de HTML.

- La prioridad de todos los objetos se puede disminuir después de un período de tiempo especificado o después que se han tratado algún número de solicitudes de HTTP o de respuestas de HTTP.

\vskip1.000000\baselineskip

Reordenación de objetos

En el capítulo anterior se han descrito la generación de una lista de prioridades para los objetos solicitados que se van a transferir al cliente 40, así como posibles mecanismos de actualización para esta lista de prioridades. Usualmente, los objetos solicitados serán recibidos por el servidor proxy 30 del servidor 20 en un orden que es diferente del orden indicado en la lista de prioridades. Por consiguiente, el servidor proxy 30 tiene que reordenar los objetos recibidos del servidor 20 de tal manera que se envíen desde el servidor proxy 30 al cliente 40 en un orden que refleje el orden en la lista de prioridades con la mayor aproximación posible. El servidor proxy 30 reordena los objetos recibidos del servidor 20 mediante el retardo intencionado de los objetos que tienen una prioridad inferior y mediante el envío al cliente 40 de los objetos que tengan una prioridad más alta sin ningún retardo sustancial.

El servidor proxy 30 usa una combinación de diferentes mecanismos de retardo para reordenar los objetos recibidos del servidor 20. En lo que sigue se describirán con más detalle a título de ejemplo dos de estos mecanismos de retardo, a saber, la suspensión de las conexiones de TCP, por una parte, y las redirecciones de HTTP por otra parte.

\vskip1.000000\baselineskip

Suspensión de las conexiones de TCP

Como resulta evidente en la Figura 2, el vínculo 14 entre el servidor proxy 30 y el cliente 40 está constituido por una pluralidad de conexiones 50 de TCP. Dependiendo de las prioridades de los objetos solicitados que se van a enviar por medio de conexiones individuales de las conexiones 50, una o más de las conexiones 50 que están destinadas para la transferencia de objetos que tienen una prioridad baja están suspendidas. Esta suspensión de conexiones individuales libera cierto ancho de banda en el vínculo 14 que ahora está disponible para transferir con preferencia objetos que tengan una prioridad más alta. Por consiguiente, los objetos que tengan una prioridad más alta se descargarán antes que los objetos que tengan una prioridad más baja.

La suspensión de una conexión individual 50 se realiza de tal manera que la conexión 50 se deja abierta sin transferir objetos durante un período determinado de tiempo. Alternativamente, la suspensión de una conexión 50 se podría efectuar cerrando la conexión 50 con o sin guardar el estado de la conexión 50 antes de su suspensión. Cuando el estado de la conexión suspendida se guarda, se puede abrir en un momento posterior en el mismo estado en que se ha suspendido (es decir, cerrado).

La suspensión de una conexión 50 tiene la ventaja de que no hay que enviar datos extraordinarios a través del vínculo 14. Preferiblemente, una conexión 50 se suspende sólo si el ancho de banda liberado se puede usar totalmente por algunas otras conexiones 50 para la transferencia de objetos que tengan una prioridad alta.

Por tanto, el servidor proxy 30 está configurado de tal manera que comprueba que el vínculo 14 se ha usado totalmente antes de suspender una conexión 50, a fin de no desperdiciar ancho de banda disponible. Una rutina posible para predecir si el vínculo 14 está o estará parcialmente vacío incluye comparar la salida promedio (durante los N últimos segundos) de todas las conexiones que van al cliente 40 con la cantidad de datos que actualmente se estén acumulando o guardando en la memoria intermedia 36 del servidor proxy 30 (véase Figura 3) y están listos para ser enviados. Se podrían implementar otras técnicas y en particular más sencillas para estimar la utilización del vínculo 14, así como, especialmente, si se conoce por otros medios el ancho de banda disponible en el vínculo 14.

Redirecciones de HTTP

Si el servidor proxy 30 espera que los objetos que tienen una prioridad alta tendrán que transferirse pronto al cliente 40 (por ejemplo, porque el servidor proxy 30 ha detectado previamente vínculos a estos objetos mientras enviaba un código de HTML de una página de HTML al cliente 40), y la suspensión de una conexión 50 desperdiciaría algo de ancho de banda porque actualmente no habría nada más para transferir en las otras conexiones 50, entonces el servidor proxy 30 podría utilizar otro plan de retardo. Un plan posible de retardo que se podría aplicar en tal caso incluye dar instrucciones al cliente para repetir una solicitud de objeto en un momento posterior.

Aunque el HTTP especifica que cualesquiera respuestas de HTTP deben enviarse al cliente 40 en el mismo orden con que el explorador que funciona sobre el cliente 40 ha emitido las solicitudes de HTTP, es posible dar instrucciones al explorador para reintentar más tarde una solicitud de HTTP. Esto se puede hacer enviando una respuesta de HTTP con el código de estado "302" al cliente 40, junto con el campo de encabezamiento "Reintentar-Después de". Este campo del encabezamiento comunica al cliente 40 que reintente su solicitud de HTTP después de un período de tiempo especificado. En respuesta a la recepción del código de estado "302" (posiblemente incluyendo el campo de encabezamiento "Reintentar-Después de"), los exploradores actuales reprograman la solicitud HTTP después que se han procesado todas las solicitudes de HTTP pendientes.

El código de estado "302", según se ha especificado en la norma HTTP 1.1,comunica al explorador que un objeto determinado se puede encontrar (provisionalmente) en una localización que es diferente de la que se ha solicitado. La respuesta de HTTP enviada al cliente 40 incluye la nueva localización del objeto. Este mecanismo se usa para implementar el plan de retardo de acuerdo con el invento.

De acuerdo con el invento, el servidor proxy 30 genera un atributo en la forma de un nuevo URL (virtual) para el objeto a retardar. El servidor proxy 30 entonces da instrucciones al explorador que funciona sobre el cliente 40 de intentar otra vez la solicitud de HTTP, usando este atributo provisional (es decir, URL) como la nueva localización del objeto. De ese modo, el explorador ha recibido instrucciones para reprogramar la solicitud de HTTP en un momento posterior. Cuando el explorador repite la solicitud de HTTP (incluyendo el atributo provisional, es decir el URL virtual), el servidor proxy 30 convierte el atributo al URL original, y envía la solicitud de HTTP al servidor 20. Alternativamente, la solicitud original de HTTP se podría haber enviado al servidor 20 después de su recepción por el servidor proxy 30 En tal caso, la respuesta de HTTP recibida del servidor 20 se guarda provisionalmente por el servidor proxy 30 hasta que recibe del cliente 40 la solicitud repetida de HTTP.

En lo que sigue, se describe a título de ejemplo con más detalle el mecanismo de retardo del invento con referencia a las Figuras 4 y 5. Se supondrá que la solicitud de HTTP recibida por el servidor proxy 30 del cliente 40 se refiere a un objeto que el servidor proxy 30 considera de baja prioridad.

En una primera etapa 402 de la Figura 4, el servidor proxy 30 recibe una solicitud de HTTP del cliente 40 por medio del vínculo 14. En el caso ejemplar de HTTP, esta primera solicitud del cliente tiene el siguiente formato:

: GET htp://ejemplo.com/some/image.png HTTP/1.1

: Central: ejemplo.com

: Agente de usuario: Moxilla/5.0 (X11; Linux 686; en-US; rv: 0.9.9

: Gecko/20020311

: Conexión: muy próxima

\vskip1.000000\baselineskip

En respuesta a la solicitud de HTTP recibida en la etapa 402 del cliente 40, el servidor proxy 30 redirige al cliente 40 en la etapa 304 a una nueva localización (virtual) y da instrucciones al cliente 40 para esperar un período determinado de tiempo (retardo) antes de volver a intentar la solicitud de HTTP. El mensaje de redirección procedente del servidor proxy 30 basándose en el código de estado "302" según se ha especificado en la norma HTTP 1.1 puede tener el siguiente formato:

: HTTP /1.1 302 encontrado

: Fecha: martes, 21 marzo 2002 15:12:47

: Servidor: PrioTest/0.9

: Localización: HTTP//example.com /some/() image (0001.png

: Reintentar-después de: 5

: Conexión: muy próxima

: Transferencia-Codificación: fragmentada

: Tipo de contenido: texto/html: conjunto de caracteres = iso-8859-1

\vskip1.000000\baselineskip

: (sigue algún texto humano legible)

\vskip1.000000\baselineskip

El servidor proxy 30 puede ahora solicitar del servidor 20 el objeto en cualquier momento tras la recepción de la solicitud inicial de HTTP del cliente 40 (etapa 402) y el momento en el que decide descargar el objeto al cliente 40 (etapas 406 y 408).

Después de recibir el mensaje de redirección anteriormente expuesto, el cliente 40 espera durante un período de tiempo especificado en el mensaje de redirección, es decir, cinco segundos (o hasta que se hayan transferido todos los demás objetos). En la etapa 412, el cliente 40 repite entonces la solicitud de HTTP que indica la nueva localización (virtual) del modo siguiente:

\vskip1.000000\baselineskip

: GET HTTP: //example.com/some /() image (00001). png HTTP/1.1

: Central: example.com

: Agente de usuario: Mozilla/5.0 (X11; Linux i686; en-US; rv:0.9.9)

: Gecko/20020311

: Conexión: muy próxima

\vskip1.000000\baselineskip

Tras recibir del cliente la solicitud repetida de HTTP, el servidor proxy 30 decide si retarda adicionalmente el objeto solicitado (por ejemplo, mediante la suspensión de una conexión 50 o mediante un mensaje adicional de redirección) o si envía el objeto retardado al cliente 40. Si el servidor proxy 30 decide enviar el objeto retardado sin ningún retardo adicional, esta operación se puede hacer en el siguiente formato:

: HTTP/1.1 200 OK

: Fecha: martes, 21 de marzo 2002 15:12:50

: Servidor: Apache/1.3.23 (Unís)

: Tipo de contenido: imagen/png

\vskip1.000000\baselineskip

: Longitud de contenido: 1520

\vskip1.000000\baselineskip

: (sigue el contenido de la imagen)

\vskip1.000000\baselineskip

A continuación se explican las decisiones tomadas por el servidor proxy 30 en el transcurso de la rutina de redirección anteriormente descrita con referencia a la Figura 5.

En la etapa 502, el servidor proxy 30 recibe la solicitud de HTTP del cliente 40. En la etapa siguiente 504 el servidor proxy 30 determina si el URL incluido en la solicitud de HTTP es un URL modificado, es decir, el resultado de una redirección anterior. Si es así, el servidor proxy 30 descodifica el URL y restablece la localización original en la etapa 506 y se desplaza a través del nodo 508 a la etapa 510. De lo contrario, el método directamente se desplaza desde la etapa 504 por medio del nodo 508 a la etapa 510.

En la etapa 510, el servidor proxy 30 determina si el objeto solicitado por medio de la solicitud de HTTP ya está disponible, es decir, guardado en la memoria intermedia 36 del servidor proxy 30 (véase Figura 3). Si el objeto no se ha guardado, el servidor proxy 30 solicita del servidor 20 el objeto, o lo marca para una recuperación posterior en la etapa 514. Desde la etapa 514, el método se desplaza por medio del nodo 512 a la etapa 516. La etapa 516 se puede alcanzar también directamente desde la etapa 510 a través del nodo 512 en el caso de que ya esté disponible el objeto solicitado por el cliente 40.

En la etapa 516, la respuesta de HTTP que incluye el objeto solicitado ya está lista para enviarse al cliente 40. Esto corresponde a la primera etapa en el diagrama de flujo de la Figura 6, que se describe más adelante.

En principio, el mensaje de redirección (etapa 504 en la Figura 4) se puede enviar al cliente 40 en cualquier momento mientras se realizan las etapas 502 a 516 o después de la etapa 516. Debe hacerse notar que la disponibilidad de un objeto (es decir, si un objeto solicitado ya está guardado, actualmente en transferencia o si el objeto todavía no ha sido solicitado) es un factor adicional que influye en la prioridad inicial de un objeto solicitado.

Decisiones de reordenación

Una vez que la respuesta de HTTP está lista para enviarse al cliente 40 (etapa 516 de la Figura 5), hay que decidir si un objeto comprendido en la respuesta de HTTP debería realmente descargarse al cliente 40, si el cliente 40 debería redirigirse o si debería suspenderse la conexión 50 a través de la cual este objeto se va a enviar al cliente 40. En la Figura 6 se ha representado un diagrama de flujo que presenta un plan de decisión a título de ejemplo.

En la etapa 602, la respuesta de HTTP está lista para enviarse al cliente. En la etapa siguiente 604 se evalúa la prioridad de este objeto con respecto al hecho de si hay que actualizar o no la prioridad. Si tiene que actualizarse la prioridad del objeto, el ajuste de prioridad se realiza en la etapa 604.

En la etapa siguiente 606 se establece la prioridad actual del objeto para averiguar si tiene la máxima prioridad de todos los objetos que se están transfiriendo o que se espera transferir pronto. Si en la etapa 606 se determina que el objeto solicitado realmente tiene la máxima prioridad, el método se desplaza a través del nodo 610 a la etapa 612. En la etapa 612, el objeto solicitado se envía al cliente 40.

Si la comparación entre la prioridad del objeto solicitado actualmente y la prioridad de otros objetos, realizada en la etapa 606, conduce al resultado de que el objeto actualmente solicitado no tiene la máxima prioridad, el método continúa con la etapa 514. Con respecto a la etapa 606, debe hacerse notar que, en lugar de comparar la prioridad del objeto solicitado actualmente con las prioridades de otros objetos, también es posible comparar la prioridad del objeto actualmente solicitado con un umbral fijo o añadir una desviación en la comparación para que dos prioridades tengan que diferir en más de un umbral predefinido antes de que la diferencia se considere bastante significativa.

En la etapa 614, el servidor proxy 30 estima si el vínculo 14 al cliente 40 está o estará vacío. Como se ha explicado anteriormente, hay varias formas de hacerlo. Una de ellas consiste en calcular un promedio de funcionamiento de la máxima cantidad de datos que se han enviado y de la que se ha acusado recibo durante los N últimos segundos sobre todas las conexiones 50 que van al mismo cliente 40. Esto da una estimación de la máxima capacidad de ejecución disponible.

El resultado así obtenido se compara luego con la cantidad de datos que están listos para enviarse sobre las conexiones 50 que no están suspendidas. Si el servidor proxy 30 detecta que no tiene datos suficientes para enviar con el fin de llenar el vínculo durante al menos una vez de ida y vuelta completa, entonces considera que existe alguna parte de reserva de ancho de banda en el vínculo 14 hacia el cliente 40, y continúa con la etapa 615.

En la etapa 616 se realiza una comparación similar a la de la etapa 606. Si en la etapa 616 se determina que el objeto solicitado actualmente tiene una prioridad mayor que todos los objetos esperados pronto, el servidor proxy 30 continúa a través del nodo 610 con la etapa 612 y envía el objeto actualmente solicitado de forma inmediata al cliente 40. De lo contrario, el método continúa con la etapa 618 y se envía un mensaje de redirección (código de estado "302") al cliente 40 según se ha expuesto anteriormente en relación con la Figura 4.

La decisión tomada en la etapa 616 podría estar influida por el tamaño del objeto solicitado actualmente (si ya es conocido). Si se sabe que el objeto es pequeño (por ejemplo, menor que el doble del tamaño de un mensaje de redirección), entonces el servidor proxy enviará siempre el objeto en lugar de enviar un mensaje de redirección, incluso si hasta entonces al objeto se le ha asignado una prioridad muy baja (esto puede considerarse como una forma de actualizar la prioridad).

Si, en la etapa 614, se determina que hay datos suficientes para enviar con el fin de llenar el vínculo 14, el método continúa con la etapa 620 y suspende la conexión 50 al cliente a través de la cual se vaya a transferir el objeto actualmente solicitado

Desde una cualquiera de las etapas 612, 618 y 620 el método continúa con la etapa 622. En la etapa 622, el servidor proxy 30 re-evalúa todas las conexiones suspendidas para averiguar si una cualquiera de las conexiones suspendidas 50 tiene que volverse a abrir.

El protocolo HTTP/1.1 soporta la opción de canalización, que permite al cliente 40 enviar varias solicitudes al servidor 20 o al servidor proxy 30 sobre la misma conexión de TCP sin esperar por las respuestas previas. En el caso de que se use la canalización, se podría enviar más de un objeto que esté listo para ser enviado sobre la misma conexión 50 hacia el cliente 40. Es evidente que en ese caso, un objeto que tenga una prioridad baja podría bloquear a un segundo objeto que tenga una prioridad alta que se vaya a enviar sobre la misma conexión 50. Si hay varios objetos a la espera sobre la misma conexión 50, se podría determinar la prioridad máxima o media de estos objetos y considerarse en las etapas 606 y 616. Esto asegura que los objetos de prioridad inferior no bloqueen a objetos de prioridad superior.

Extensiones posibles

Se podrían implementar varias extensiones, algunas de las cuales se han descrito ya brevemente, a la realización ejemplar descrita con referencia a las Figuras 1 a 6.

Una de estas extensiones se refiere a restringir la velocidad de transferencia sobre el vínculo 14, dependiendo de la prioridad de los objetos que se vayan a transferir. Esto podría hacerse, por ejemplo, mediante la asignación de una participación específica de posibilidades de proceso a cada conexión 50 dependiendo de la prioridad de los objetos a transferir. La prioridad de los objetos individuales se disminuye mientras el proceso está ejecutándose. Si el servidor proxy 30 procesa conexiones 50 en una modalidad con retorno al punto de origen, esta característica se implementaría mediante la limitación de la cantidad de datos transmitidos por turno sobre cada conexión 50 mediante un número que se obtiene a partir de la prioridad de ese objeto. La asignación dinámica de posibilidades de proceso se puede combinar ventajosamente con los mecanismos de suspensión y redirección anteriormente descritos. Las posibilidades de proceso pueden incluir también cualquier transformación de los objetos o códigos que se transfieren.

De acuerdo con una extensión adicional del invento, las prioridades se asignan directamente por el explorador que trabaja sobre el cliente 40. El explorador puede entonces programar las solicitudes de HTTP para objetos individuales de acuerdo con su prioridad. Si el explorador asigna directamente las prioridades, hay varios factores adicionales que se pueden usar para refinar la prioridad de cada objeto:

- situación del objeto en la página (coordenadas)

- situación relativa del área visible (los objetos que están fuera del área visible tienen una prioridad inferior)

- si la carga de imágenes o la ejecución de secuencias de comandos están inhabilitadas, el explorador sabe inmediatamente que no es necesario asignar una prioridad a estos objetos.

Adicionalmente, el explorador sabe cuándo un usuario selecciona una nueva página de HTML a partir de las señales o tecleando un nuevo URL. De ese modo, el explorador puede aclarar la lista de objetos que ya no son necesarios.

Una extensión adicional del invento se refiere a un componente proxy que esté situado en el mismo ordenador (cliente) que el explorador o muy cerca de este ordenador en cuanto a vínculos de red. Esta situación se ha representado en la Figura 7.

Como resulta evidente en la Figura 7, el cliente 40 no sólo comprende un componente de explorador 42, sino un componente proxy adicional 30 (que tiene la estructura mostrada en la Figura 3) en comunicación con el componente de explorador 42. En tal caso, el vínculo 14 entre el componente proxy 30 y el componente de explorador 42 tiene una capacidad mucho mayor y un estado latente menor que el vínculo 12 entre el componente proxy 30 y el servidor 20 (no representado en la Figura 7).

Como resultado, el componente proxy 30 del lado cliente influye en la corriente de solicitudes porque no puede hacer mucho sobre la corriente de respuestas. Basándose en la información de prioridades obtenida de la solicitud actual de HTTP y de las respuestas anteriores de HTTP (por ejemplo, códigos anteriores de HTML que se refieran a objetos adicionales) así como en una estimación de la disponibilidad de vínculo, el componente proxy 30 del lado cliente decidirá si se debe enviar al servidor una solicitud de HTTP y/o si debería contestar inmediatamente con un mensaje de redirección.

Las decisiones a tomar son más sencillas de lo que se ha representado en el diagrama de flujo de la Figura 6. Más particularmente, las decisiones se pueden limitar a evaluar si el objeto solicitado actualmente tiene una prioridad más baja que algunos de los objetos que se están transfiriendo o que se espera que se transfieran pronto, y si el vínculo ya se ha usado por completo. Si se dan ambas condiciones, entonces se envía un mensaje de redirección al componente de explorador 42. En todos los demás casos, la solicitud de HTTP se envía inmediatamente al servidor.

Si se usa la canalización de HTTP sobre una conexión específica y se están procesando algunas solicitudes anteriores de HTTP, entonces el componente proxy 30 del lado cliente puede suspender la solicitud de HTTP hasta que pueda tomar la decisión. Tendrá que tomar una decisión lo más tarde cuando se hayan recibido totalmente los objetos anteriores.

Todavía una extensión más del invento se refiere al bloqueo de descargas para algunos objetos basándose en su prioridad. Esto significa que la prioridad que se asigne a los objetos se puede usar también para bloquearlos completamente. Si se ha establecido un umbral sobre la prioridad, todo objeto que tenga una prioridad que sea inferior a este umbral no se enviará al cliente 40. En este caso, el servidor proxy (o el componente proxy) 30 simplemente devolvería al cliente 40 uno de los códigos de estado "4xx" ó "5xx" definidos en la norma HTTP 1.1 cuando detectase dicho objeto. Son códigos de estado posibles "403 prohibido", "409 conflicto" o "servicio 503 no disponible".

Como una extensión adicional, se podrían usar las prioridades asignadas a los objetos para efectuar una prebúsqueda. Un mecanismo de prebúsqueda permite al servidor proxy 30 llenar su memoria intermedia 36 (véase Figura 3) con algunos objetos antes de que el cliente 40 los solicite realmente. Dicho mecanismo de pre-búsqueda se podría basar, por ejemplo, en el análisis de un código de HTML que se envíe desde el servidor proxy 30 al cliente 40 y que incluya referencias a objetos adicionales. Basándose en el análisis de las referencias a los objetos, el componente proxy 30 asigna prioridades a los objetos individuales y, basándose en esta asignación, se define qué objetos se van a buscar previamente y en qué orden. Preferiblemente, los objetos se buscan previamente empezando con los objetos que tengan la prioridad máxima.

De acuerdo con todavía otra extensión adicional que se puede combinar con el mecanismo de prebúsqueda descrito anteriormente, se implementan planes específicos de impulsión que permiten transferir objetos desde el servidor proxy 30 al cliente 40 sin haber recibido del cliente 40 una solicitud explícita de objeto

Una realización del invento se refiere a controlar, en una red de comunicaciones, una transferencia de objeto desde un primer componente a través de un componente intermediario a un segundo componente que está distante del primer componente, en la que la transferencia de objeto se basa en una pluralidad de solicitudes de objeto que están relacionadas con objetos a los que se hace referencia en uno o más códigos para que sean procesados por el segundo u otro componente de la red de comunicaciones. El componente intermediario realiza las etapas de enviar una solicitud de objeto al primer componente; recibir del primer componente (20) el objeto solicitado; establecer y/o actualizar una prioridad del objeto solicitado. Se ha asignado una prioridad inicial al objeto solicitado basándose en un análisis de al menos uno de entre la solicitud de objeto y del código que se refiere al objeto solicitado. Dependiendo de la prioridad del objeto solicitado, el objeto solicitado se retarda, o bien el objeto solicitado se despacha al segundo componente.

En una realización del invento, el retardo se realiza de tal manera que el orden en que los objetos se reciben del primer componente difiera del orden en el que los objetos se despachen al segundo componente.

En una realización del invento, la solicitud de objeto se recibe del segundo componente o se genera por el componente intermediario.

En una realización del invento, el retardo del objeto solicitado incluye al menos una de entre las operaciones de dar instrucciones al segundo componente para repetir la solicitud de objeto, suspender una conexión al segundo componente a través de la cual se va a despachar el objeto solicitado, e informar al segundo componente que el objeto solicitado se despachará automáticamente en un punto posterior en el tiempo.

En una realización del invento, la operación de dar instrucciones al segundo componente para repetir la solicitud de objeto incluye asignar un atributo específico al objeto a retardar; informar del atributo al segundo componente; recibir del segundo componente una referencia al atributo; y, tras la recepción de la referencia al atributo, enviar el objeto retardado al segundo componente o retardar adicionalmente el objeto retardado.

En una realización del invento, los objetos solicitados se despachan al segundo componente a través de una pluralidad de conexiones al segundo componente.

En una realización del invento, las conexiones seleccionadas de entre las conexiones al segundo componente se suspenden dependiendo de las prioridades de los objetos solicitados que se recibieron del primer componente y que se vayan a despachar a través de las seleccionadas de entre las conexiones.

En una realización del invento, hay para cada conexión una participación específica de posibilidades de tratamiento asignadas dinámicamente.

Una realización del invento comprende las etapas de: enviar una solicitud de código al primero o a un tercer componente; recibir del primero o del tercer componente el código solicitado; analizar el código recibido con respecto a referencias a objetos; y establecer las referencias a objetos con el fin de asignar prioridades iniciales a los objetos a los que se haya hecho referencia en el código recibido.

En una realización del invento, se evalúa una respuesta tras la recepción de la respuesta que contiene el objeto solicitado del primer componente. La respuesta se evalúa con respecto a la prioridad del objeto recibido con el fin de determinar si hay que actualizar - o no - la prioridad inicial del objeto recibido.

En una realización del invento, se genera una lista de prioridades que contiene información de prioridad para objetos individuales o clases individuales de objetos.

En una realización del invento, se establece repetidamente una lista de prioridades con respecto a como mínimo una de las operaciones de actualizar la información de prioridad y eliminar objetos o clases, o la información correspondiente, de la lista de prioridades.

En una realización del invento, las etapas se realizan mediante un componente proxy situado en el primer componente, en el segundo componente o configurado como un componente separado de hardware de la red de comunicaciones.

Una realización del invento se refiere al retardo, en una red de comunicaciones, de una transferencia de objeto desde un primer componente a través de un componente intermediario a un segundo componente que está distante del primer componente, en donde la transferencia de objeto se basa en una pluralidad de solicitudes de objeto relativas a objetos a los que se ha hecho referencia en uno o más códigos que se van a procesar por el segundo u otro componente de la red de comunicaciones. El componente intermediario realiza las etapas de: asignar un atributo específico a un objeto que se va a retardar; informar al segundo componente sobre el atributo; recibir del segundo componente una referencia al atributo; y, tras la recepción de la referencia al atributo, enviar el objeto retardado al que se ha asignado el atributo al segundo componente o retardar adicionalmente el objeto retardado.

En una realización del invento, el objeto se envía al segundo componente de acuerdo con un plan de impulsión o en respuesta a una solicitud de objeto recibida del segundo componente.

En una realización del invento, se informa al segundo componente sobre el atributo en contexto con una instrucción para repetir la solicitud de objeto. La referencia al atributo se recibe del segundo componente en contexto con una solicitud repetida de objeto.

Una realización del invento se refiere a un producto de programa de ordenador que comprende unas partes de código de programa para realizar las etapas de las realizaciones anteriormente descrita, cuando el producto de programa de ordenador se ejecute en un sistema de ordenador.

En una realización del invento, el producto de programa de ordenador se guarda en un medio de memoria que pueda leerse con ordenador.

Una realización del invento se refiere a un componente intermediario para controlar, en una red de comunicaciones, una transferencia de objeto desde un primer componente, a través del componente intermediario, hasta un segundo componente que está distante del primer componente, en la que la transferencia de objeto se basa en una pluralidad de solicitudes de objeto relacionadas con objetos a los que se hace referencia en uno o más códigos para tratarse mediante el segundo u otro componente de la red de comunicaciones. El componente intermediario comprende una interfaz de comunicación para enviar una solicitud de objeto al primer componente y para recibir del primer componente el objeto solicitado, una unidad de tratamiento para establecer y/o actualizar una prioridad del objeto solicitado, en donde se ha asignado una prioridad inicial al objeto solicitado basándose en un análisis de al menos uno de entre la solicitud de objeto y el código que se refiere al objeto solicitado, y en la que la unidad de tratamiento, dependiendo de la prioridad del objeto solicitado, retarda el objeto solicitado o controla la interfaz de comunicación para despachar el objeto solicitado al segundo componente.

Una realización del invento se refiere a un componente intermediario para retardar, en una red de comunicaciones, una transferencia de objeto desde un primer componente, a través del componente intermediario, a un segundo componente que está distante del primer componente, en la que la transferencia de objeto se basa en una pluralidad de solicitudes de objeto relacionadas con objetos a los que se hace referencia en uno o más códigos a tratarse por el segundo u otro componente de la red de comunicaciones. El componente intermediario comprende una unidad de tratamiento para asignar un atributo específico a un objeto que se va a retardar y una interfaz de comunicaciones para informar al segundo componente sobre el atributo, para recibir del segundo componente una referencia al atributo y, tras la recepción de la referencia al atributo, enviar el objeto retardado al que se ha asignado el atributo al segundo componente o retardar adicionalmente el objeto retardado.

Una realización del invento se refiere a un componente intermediario según se ha descrito en las dos secciones anteriores, configurado como un servidor proxy.

Una realización del invento se refiere a un sistema de red que comprende como mínimo uno de los componentes descritos en las tres secciones anteriores.

En una realización, el sistema de red comprende un primer vínculo entre el componente intermediario y el primer componente y un segundo vínculo entre el componente intermediario y el segundo componente El primer vínculo y el segundo vínculo tienen diferentes tasas de transferencia.

En una realización, el sistema de red comprende un segundo componente en la forma de un terminal móvil.

Son posibles diversas modificaciones de la realización preferida sin apartarse del alcance del presente invento. Aunque se ha descrito el invento en relación con una realización preferida, se entenderá que esta descripción no tiene carácter limitativo al mismo. Más bien, el invento está destinado a cubrir todas las modificaciones y/o adiciones a la descripción anteriormente mencionada, sin apartarse del alcance del invento.

Claims

1. Un método de operar un servidor proxy, en el que se asigna o ajusta una prioridad de un objeto a enviarse a un cliente, cuando se encuentre una referencia a dicho objeto en un objeto previo que se va a despachar al cliente.

2. Un método de acuerdo con la reivindicación 1, en el que el objeto previo comprende código de HTML.

3. Un método de acuerdo con la reivindicación 1 o con la reivindicación 2, que comprende la etapa de generar una lista de prioridades en la que se da una relación de objetos individuales, a los que se hace referencia en el objeto previo, de acuerdo con su prioridad.

4. Un método de acuerdo con las reivindicaciones 1, 2 ó 3, en el que la prioridad del objeto se determina dependiendo del orden siguiente de prioridad decreciente de un tipo de objeto: un vínculo a otra página, un tramo de datos, una imagen en línea, una hoja de estilo, la misma prioridad para una secuencia de comandos o un objeto empotrado o un subprograma, menor prioridad para una imagen de fondo, mínima prioridad para un objeto que ya se envió al cliente.

5. Un método de acuerdo con cualquiera de las reivindicaciones precedentes, en el que la prioridad del objeto a enviar a un cliente se asigna o ajusta, cuando se recibe una solicitud, que es emitida por un explorador que funciona en el cliente, relacionada con dicho objeto.

6. Un método de acuerdo con la reivindicación 5, en el que la solicitud es una solicitud de HTTP.

7. Un método de acuerdo con la reivindicación 6, que comprende la etapa de analizar la solicitud en un contexto de URL.

8. Un método de acuerdo con las reivindicaciones 6 ó 7, en el que la prioridad se ajusta o asigna dependiendo de información en el encabezamiento de la solicitud de HTTP.

9. Un método de acuerdo con cualquiera de las reivindicaciones 5 a 8, que comprende las etapas de determinar si el objeto ha sido - o no- solicitado ya una vez por el explorador, en el que el objeto obtiene una alta prioridad asignada si el explorador ya ha solicitado el objeto.

10. Un método de acuerdo con cualquiera de las reivindicaciones 5 a 9, en el que el objeto obtiene una prioridad alta asignada si el objeto no tiene todavía una prioridad y la extensión de archivo indica uno de entre un archivo de HTML, un archivo de XML o un índice de directorio.

11. Un método de acuerdo con cualquiera de las reivindicaciones 5 a 10, en el que la prioridad, que se asigna o ajusta en respuesta a la solicitud recibida, depende de si la solicitud es una solicitud condicional de HTTP.

12. Un método de acuerdo con cualquiera de las reivindicaciones 5 a 11, en el que la prioridad, cuando se asigna o ajusta en respuesta a la solicitud recibida, es menor que para la mayoría de otros objetos solicitados, si el objeto se solicitó indirectamente mediante una secuencia de comandos.

13. Un método de acuerdo con cualquiera de las reivindicaciones precedentes, en el que la prioridad del objeto a enviar a un cliente se asigna o ajusta, cuando se reciba una respuesta correspondiente a una solicitud del objeto, en donde dicha respuesta contiene el objeto.

14. Un método de acuerdo con la reivindicación 13, en el que la respuesta es una respuesta de HTTP.

15. Un método de acuerdo con la reivindicación 14, en el que se establece un encabezamiento o un contenido de la respuesta de HTTP para ajustar la prioridad.

16. Un método de acuerdo con las reivindicaciones 14 ó 15, en el que se establece un código de réplica para ajustar la prioridad, y en el que se asigna una prioridad mayor si el establecimiento del código de réplica indica un código de error que si el establecimiento del código de réplica indica una réplica normal.

17. Un método de acuerdo con las reivindicaciones 14, 15 ó 16, en el que se establece un tipo de contenido para ajustar la prioridad, y en el que se asigna una prioridad mayor si el establecimiento de tipo de contenido indica un código HTML que si el establecimiento del código de réplica indica una imagen.

18. Un método de acuerdo con cualquiera de las reivindicaciones 14 a 17, en el que se establece un tamaño del objeto, y en el que un objeto de menor tamaño obtiene una prioridad mayor que un objeto de mayor tamaño.

19. Un método de acuerdo con cualquiera de las reivindicaciones 14 a 18, en el que se analiza un contenido del objeto para ajustar la prioridad.

20. Un método de acuerdo con la reivindicación 19, en el que una imagen animada obtiene una prioridad menor que una imagen estática.

21. Un método de acuerdo con cualquiera de las reivindicaciones 14 a 20, en el que, si un código de respuesta es una redirección que especifica una nueva ubicación para el objeto solicitado, dicha nueva ubicación obtiene la misma prioridad que el objeto original.

22. Un método de acuerdo con cualquiera de las reivindicaciones precedentes, en el que la prioridad de todos los objetos se disminuye después de una magnitud especificada de tiempo o después que se han procesado varias solicitudes de HTTP o respuestas de HTTP.

23. Un servidor proxy, que tiene medios destinados a realizar el método de acuerdo con las reivindicaciones 1 a 22.

24. Un programa de ordenador que comprende unas partes de código de programa para realizar las etapas de las reivindicaciones 1 a 22 cuando el programa de ordenador se ejecuta en un sistema (30) de ordenador.

25. Un medio de memoria legible por ordenador, que guarda un programa de ordenador de la reivindicación 24.