ES2585387T3 - Método y sistema de almacenamiento en caché web para una red de distribución de contenido (CDN) - Google Patents

Método y sistema de almacenamiento en caché web para una red de distribución de contenido (CDN) Download PDF

Info

Publication number
ES2585387T3
ES2585387T3 ES13741781.2T ES13741781T ES2585387T3 ES 2585387 T3 ES2585387 T3 ES 2585387T3 ES 13741781 T ES13741781 T ES 13741781T ES 2585387 T3 ES2585387 T3 ES 2585387T3
Authority
ES
Spain
Prior art keywords
content
ttl
cached
pseudo
caching
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES13741781.2T
Other languages
English (en)
Inventor
Xiaoyuan Yang
Martín IVÁN LEVI
Carmelo Alexis ACOSTA OJEDA
Eguzki ASTIZ LEZAUN
Armando Antonio GARCIA SANCHEZ MENDOZA
Pablo Rodriguez Rodriguez
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonica SA
Original Assignee
Telefonica SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonica SA filed Critical Telefonica SA
Application granted granted Critical
Publication of ES2585387T3 publication Critical patent/ES2585387T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/17—Details of further file system functions
    • G06F16/172—Caching, prefetching or hoarding of files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/951—Indexing; Web crawling techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/957—Browsing optimisation, e.g. caching or content distillation
    • G06F16/9574—Browsing optimisation, e.g. caching or content distillation of access to content, e.g. by caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H04L67/5682—Policies or rules for updating, deleting or replacing the stored data

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Un método de almacenamiento en caché de web para una red de distribución de contenido (CDN), comprendiendo dicha red de distribución una pluralidad de nodos de almacenamiento en caché y en el que el contenido web se ha identificado estáticamente como contenido que no puede almacenarse en caché y originado en un servidor de origen, comprendiendo el método: - establecer un valor de periodo de tiempo de vida, TTL, para dicho contenido que no puede almacenarse en caché basándose en peticiones de usuarios; y - responder a dichas peticiones de usuarios enviando a al menos un usuario de CDN dicho contenido que no puede almacenarse en caché dentro de dicho valor de periodo de TTL, caracterizado por que cada uno de dicha pluralidad de nodos de almacenamiento en caché en dicha red de distribución incluye un gestor de almacenamiento en caché de contenido y un predictor de TTL de contenido pseudo15 dinámico y por que dicho método comprende las siguientes etapas: a) poner en contacto cada uno de dicha pluralidad de nodos con un repositorio centralizado, con el fin de descargar un archivo de configuración de una pluralidad de dichos usuarios de CDN. b) identificar, por parte de dicho gestor de almacenamiento en caché de contenido de cada nodo de almacenamiento en caché, el contenido que no puede almacenarse en caché como contenido pseudo-dinámico; c) predecir, por parte de un predictor de TTL de contenido pseudo-dinámico de dicho nodo de almacenamiento en caché, dicho valor de periodo de TTL en el que no se modificará el contenido que no puede almacenarse en caché, prediciéndose el valor de periodo de TTL por medio del predictor de TTL de contenido pseudo-dinámico al menos considerando: - un identificador que identifica el contenido que no puede almacenarse en caché, - estructura de datos que contiene historial de predicción anterior y que se requiere para producir el valor de periodo de TTL, y - dos parámetros, p y M, proporcionados mediante un modulador de contenido pseudo-dinámico, que modulan confianza de la predicción, modulando dicho parámetro p la posibilidad de especulación de la predicción de TTL y especificando dicho parámetro M la confianza máxima para valores de TTL especulados; y d) almacenar en caché, por parte de cada uno de dicha pluralidad de nodos, el contenido que no puede almacenarse en caché durante dicho valor de periodo de TTL predicho.

Description

imagen1
Método y sistema de almacenamiento en caché web para una red de distribución de contenido (CDN)
DESCRIPCIÓN
5
Campo de la técnica
La presente invención se refiere, en general, al almacenamiento en caché de contenido de páginas web en Internet, y más específicamente, en un primer aspecto, a un método de almacenamiento en caché de web para una red de
10 distribución de contenido.
Un segundo aspecto de la invención se refiere a un sistema dispuesto para implementar el método del primer aspecto.
15 Estado de la técnica anterior
La entrega del contenido web complejo actual a los usuarios finales es un desafío y a este respecto las redes de distribución de contenido (CDN) han desempeñado un papel clave. Mediante replicación/almacenamiento en caché de contenido web en nodos distribuidos geográficamente, las CDN permiten que aplicaciones en línea accedan a
20 contenido web mucho más rápido, proporcionando una experiencia de mayor calidad a sus usuarios. Las CDN también constituyen una clave para que la infraestructura de Internet evite congestiones en enlaces críticos aislando el tráfico de red en múltiples áreas locales separadas. Esta última característica de las CDN es extremadamente importante para el crecimiento de la infraestructura de interconexión de redes, donde el coste de nuevos enlaces físicos es significativo.
25 Lo buena que sea una CDN en aceleración de acceso a contenido y aislamiento de tráfico de red depende considerablemente de la capacidad de almacenar en caché el contenido web. Si un contenido web no puede almacenarse en caché, todas las peticiones tendrán que cruzar necesariamente enlaces críticos de vuelta al origen, introduciendo retardos adicionales y consumiendo mayores recursos de red.
30 La mala noticia es que la baja capacidad de almacenar en caché es una de las características naturales de la web
2.0. Por ejemplo, el 55 % del contenido web ya se indicó potencialmente como sin posibilidad de almacenarse en caché en 2011. Los usuarios de Twitter y Facebook están accediendo a páginas web con información generada de manera constante por otros usuarios en su propia red social en línea. En este escenario, el contenido para cada 35 usuario tiene que etiquetarse como sin posibilidad de almacenarse en caché, puesto que es imposible que los extremos traseros prevean las interacciones de los usuarios finales. Los minoristas en línea tales como eBay [6] cambian el precio del producto según un mecanismo de subasta en el que cada usuario final puede aumentar/reducir el precio final. Como es imposible anticiparse a las subastas en línea, el precio del producto tiene que indicarse como sin posibilidad de almacenarse en caché y los usuarios finales tienen que actualizar
40 constantemente la página web con los detalles del producto para obtener el precio final.
Sin embargo, un objeto web etiquetado como sin posibilidad de almacenarse en caché, no genera necesariamente un contenido diferente en cada petición de usuario. En el caso de eBay, por ejemplo, el precio del producto no cambia si no hay ningún otro usuario que suba el precio durante la subasta. En el caso de Facebook, el muro del
45 usuario no cambia si ningún amigo publica un mensaje. Además, el 46 % del contenido potencialmente que no puede almacenarse en caché no cambia durante 14 días, según algunos estudios.
El contenido pseudodinámico puede definirse como todo aquel contenido web que no puede almacenarse en caché que sólo cambia en periodos no determinísticos, dada un área geográfica específica. Sin embargo, no todo el
50 contenido que no puede almacenarse en caché es necesariamente contenido pseudodinámico.
Estudios han demostrado que partes significativas del contenido actual que no puede almacenarse en caché es contenido realmente estático. Este contenido se etiqueta como sin posibilidad de almacenarse en caché debido a una mala configuración en el servidor web o a una falta de conocimiento de impacto de rendimiento de los 55 administradores del sistema web. Ya existen soluciones muy buenas para contenido estático que no puede almacenarse en caché en CDN. En la mayoría de las CDN, los clientes pueden especificar valores de TTL fijos para este tipo de contenido. Una vez que un nodo de CDN descarga el contenido del origen, se almacenará en caché durante el periodo de TTL especificado. También existen propuestas como el documento US 2003/0187917 A1 para maximizar la utilidad del contenido almacenado en caché seleccionando la mejor fuente de contenido que se espera
60 que esté actualizado durante más tiempo. El método propuesto en el documento US 2003/0187917 A1 requiere la existencia de múltiples fuentes, por ejemplo múltiples intermediarios y sin embargo, sólo es aplicable para contenido que puede almacenarse en caché.
También existe contenido que no puede almacenarse en caché que es contenido dinámico realmente puro. Por ejemplo, un contador que indica el número de visitantes de la página web es claramente un contenido dinámico puro. Para cada petición, el contador se incrementará. A pesar de que gran cantidad de contenido que no puede almacenarse en caché es estático o dinámico puro, una parte significativa de este contenido es contenido pseudodinámico cuyo evento de cambio no puede anticiparse.
imagen2
5 Como respuesta a la explosión de contenido web que no puede almacenarse en caché, se ha propuesto un conjunto de nuevas técnicas de aceleración web. Existen técnicas significativas que suponen que todo el contenido que no puede almacenarse en caché es dinámico puro y contienen diferentes mecanismos de optimización para reducir el tiempo de comunicación con el servidor de origen. Según la característica de mecanismos de optimización, todas las
10 técnicas existentes pueden clasificarse en 3 grupos.
El primer grupo contiene las técnicas que reducen el tráfico de red. Técnicas tales como minimización JS/CSS, optimización de estructura HTML y compresión sobre la marcha pertenecen a esta categoría. En el mismo grupo están aquellas técnicas que pueden detectar duplicidades de contenido web parciales y eliminar parte del tráfico de
15 red enviando sólo mensajes de control.
El segundo grupo incluye todas las técnicas asociadas con la optimización de canales de transmisión, tales como optimización TCP [1], conexiones TCP persistentes [2] y optimización de encaminamiento. El objetivo de estas técnicas es mejorar el rendimiento global de los canales TCP: 1) reduciendo el inicio lento, 2) evitando el retardo de
20 toma de contacto, 3) proporcionando la estabilidad de canal y 4) mejorando el rendimiento global de TCP.
En el tercer grupo están todas aquellas técnicas basadas en la captura previa de contenido del origen. La idea, en este caso, es que los nodos de CDN capturan contenido del servidor de origen al mismo tiempo que se entrega otro contenido al usuario final.
25 También existen otras técnicas que pueden complementar a todas las técnicas mencionadas anteriormente. La optimización DNS, por ejemplo, forma parte de todas las soluciones de aceleración web, tanto para contenido que puede almacenarse en caché como para el que no. Los administradores web también desempeñan un papel importante en la aceleración de páginas aplicando diferentes técnicas, tales como simplificación DOM y HTML/JS,
30 haciendo que las peticiones AJAX puedan almacenarse en caché, etc.
También existen trabajos en marcha para cambiar el protocolo TCP/HTTP, tal como el protocolo SPDY que incluye una gran cantidad de características para la aceleración de sitios web. También existen técnicas específicas para el espacio móvil. Soluciones tales como Bytemobile proporcionan una transformación de contenido sobre la marcha
35 para adaptar imágenes a pantallas de dispositivos.
Problemas con las soluciones existentes:
Aunque la mayoría de las técnicas de aceleración existentes pueden reducir el tiempo de comunicación con el
40 origen, no pueden eliminar completamente la interacción con el servidor de origen. La noción de contenido pseudodinámico no se tiene en cuenta en todas las técnicas existentes. Si el contenido se etiqueta como sin posibilidad de almacenarse en caché, todas las peticiones para este contenido requerirán una petición de red de vuelta al origen. En este sentido, la mayoría de las técnicas existentes suponen que el contenido que no puede almacenarse en caché es todo dinámico puro.
45 Tiempo de ida y vuelta: el requisito de una interacción con el servidor de origen en cada petición limita considerablemente la capacidad de la CDN para reducir el tiempo de respuesta para los usuarios finales. En el mejor de los casos, la CDN seguirá requiriendo un tiempo de ida y vuelta (RTT) completo desde el usuario final al servidor de origen para entregar el contenido solicitado.
50 Aunque el RTT promedio en Internet actual está disminuyendo con las nuevas infraestructuras de red, la tecnología existente aún requiere 930 ms en las comunicaciones de redes locales y 60200 ms en los enlaces entre países. Como consecuencia, el tiempo de respuesta del contenido que no puede almacenarse en caché puede ser un orden de magnitud superior que el contenido que puede almacenarse en caché en las CDN.
55 Protocolo TCP: el protocolo TCP se basa en una ventana de congestión (W) [3] [4] para evitar saturaciones sobre enlaces de red. En cada ciclo de transmisión, el emisor envía W paquetes y espera a un paquete de ACK antes de comenzar el siguiente ciclo. El protocolo TCP se optimiza para adaptar la condición de red cambiando dinámicamente el valor de W.
60 Además, los ciclos de transmisión pueden solaparse, de modo que el nuevo ciclo de transmisión normalmente no se bloquea por el paquete de ACK del ciclo anterior.
La existencia de la ventana de congestión determina la cantidad de datos que pueden enviarse en cada ciclo de transmisión. Aumentando la ventana de congestión, el emisor puede enviar potencialmente todos los datos en sólo un ciclo. Sin embargo, una ventana de congestión grande puede aumentar potencialmente la tasa de error e implica RTT adicionales para la recuperación de datos. Según [1], una ventana de congestión inicial de 10 paquetes consigue un buen equilibro entre tasa de error y rendimiento. Para contenido web que requiere más de 10 paquetes,
imagen3
5 todavía se requieren múltiples ciclos de transmisión. La figura 1 muestra el tiempo de entrega promedio (en RTT) según el tamaño de objeto cuando la latencia de red es de 160 ms. La figura muestra los resultados del protocolo TCP tanto optimizado (inicial W=10) como no optimizado (inicial W = 3). Como puede observarse, la reducción de RTT es significativa para contenido pequeño. Para contenido web grande, la mejora conseguida aumentando la ventana de congestión es sin embargo despreciable.
10 Reducción de tráfico de red: el rendimiento de las técnicas de reducción de tráfico de red depende de la existencia de redundancia de información. La figura 2 muestra la tasa de compresión de la técnica de compresión sobre la marcha sobre diferentes tipos de contenido web. Según los resultados, la tasa de compresión cambia, según lo esperado, según el tipo de contenido. Por ejemplo, el contenido ya comprimido (que corresponde al 50 % del
15 contenido web), tal como jpeg o gzip, no puede comprimirse más del 10 %. Como consecuencia, el rendimiento de las técnicas de reducción de tráfico de red está limitado.
Todas las limitaciones físicas anteriores más la estabilidad de enlace de red actual determinan el límite superior de las técnicas de aceleración de contenido web existentes que no pueden eliminar por completo la comunicación de
20 red con el servidor de origen.
El documento US 2004/0128346 A1, propone un método para establecer el valor de tiempo de vida (TTL) del contenido que no puede almacenarse en caché basándose en la tasa de petición de usuario para controlar la tasa de error bajo un umbral de probabilidades. Como el método del documento US 2004/0128346 A1, la presente
25 invención también establece valores de TTL a contenido que no puede almacenarse en caché, sin embargo, el diseño de la presente invención difiere del documento US 2004/0128346 A1 en múltiples aspectos. En primer lugar, los proveedores de contenido no son escépticos frente al sistema. Los valores de TTL se ajustan al contenido que no puede almacenarse en caché según las peticiones de los proveedores de contenido. En segundo lugar, los valores de TTL no se calculan según el tiempo promedio entre cambios. En su lugar, se usan predictores de valor
30 para detectar patrones de cambio. En tercer lugar, no elimina por completo la petición al origen convirtiendo el contenido que no puede almacenarse en caché como con posibilidad de almacenarse en caché. En su lugar, todas las peticiones al origen se difieren y el patrón de cambio de contenido puede detectarse rápidamente.
El documento US 2009/150518 A1 propone un método que tiene la capacidad de ensamblar dinámicamente
35 contenido en el límite de Internet, por ejemplo, en servidores de límite de CDN. Para proporcionar esta capacidad, preferentemente el proveedor de contenido aprovecha un lenguaje de guiones de lado del servidor (u otra funcionalidad basada en servidor) para definir fragmentos de página web para ensamblaje dinámico en el límite. En el método propuesto en el documento US 2009/15518, a diferencia de la presente invención, la información que indica si un contenido puede almacenarse o no en caché y durante cuánto tiempo (tiempo equivalente al valor de
40 TTL de la presente invención) se define mediante las cabeceras de HTTP o mediante otras propiedades, por ejemplo definidas mediante metadatos, y por lo tanto se establece estáticamente. En la presente invención, los valores de TTL se adaptan dinámicamente según las peticiones de los usuarios y en consecuencia no están predeterminados.
45 Sumario de la invención
El objeto de la presente invención es proporcionar un método y un sistema para almacenamiento en caché de web para una red de distribución de contenido con el fin de reducir la comunicación de red con el origen para contenido que no puede almacenarse en caché.
50 El concepto de contenido pseudodinámico debe entenderse como todo contenido web que no puede almacenarse en caché que sólo cambia en periodos no determinísticos, dada un área geográfica específica. El contenido para todas las peticiones que pertenecen al mismo periodo y a la misma área geográfica es idéntico. Sin embargo, los servidores web no pueden anticipar cuándo cambiará el contenido, por tanto, el servidor se ve obligado a indicar el
55 contenido como sin posibilidad de almacenarse en caché.
La presente invención proporciona un método de almacenamiento en caché de web para una red de distribución de contenido (CDN), en el que la red de distribución tiene una pluralidad de nodos de almacenamiento en caché y en el que el contenido web se ha identificado estáticamente como contenido que no puede almacenarse en caché y
60 originado en un servidor de origen, como se conoce comúnmente en este campo, comprendiendo el método:
establecer un valor de periodo de tiempo de vida, TTL, para dicho contenido que no puede almacenarse en caché basándose en peticiones de usuarios; y
responder a dichas peticiones de usuarios enviando a al menos un usuario de CDN dicho contenido que no
imagen4
puede almacenarse en caché dentro de dicho valor de periodo de TTL.
En el método, a diferencia de las propuestas conocidas, cada uno de dicha pluralidad de nodos de almacenamiento en caché en dicha red de distribución incluye un gestor de almacenamiento en caché de contenido y un predictor de 5 TTL de contenido pseudodinámico y dicho método comprende además realizar las siguientes etapas:
a) poner en contacto cada uno de dicha pluralidad de nodos con un repositorio centralizado, con el fin de descargar el archivo de configuración de una pluralidad de dichos usuarios de CDN. b) identificar, por parte de dicho gestor de almacenamiento en caché de contenido de cada nodo de
10 almacenamiento en caché, el contenido que no puede almacenarse en caché como contenido pseudodinámico; c) predecir, por parte de un predictor de TTL de contenido pseudodinámico de dicho nodo de almacenamiento en caché, dicho valor de periodo de TTL en el que no se modificará el contenido que no puede almacenarse en caché; y d) almacenar en caché, por parte de cada uno de dicha pluralidad de nodos, el contenido que no puede
15 almacenarse en caché durante dicho valor de periodo de TTL predicho.
Según la invención, dicha etapa c) se realiza para cada uno de dicha pluralidad de usuarios de CDN y se da servicio a todas de dichas peticiones de usuario de dicho contenido pseudodinámico usando una copia local del archivo de configuración en dicho repositorio centralizado.
20 En caso de que dicho contenido que no puede almacenarse en caché no sea pseudodinámico, dicho contenido que no puede almacenarse en caché se retransmite a dicho usuario de CDN sin almacenarlo en dicho repositorio centralizado.
25 El método de almacenamiento en caché de web también comprende generar una petición diferida para dicho servidor de origen para cada petición de usuario de dicho contenido pseudodinámico con el fin de separar la descarga de contenido pseudodinámico.
Entonces, dichas peticiones diferidas se planifican independientemente y múltiples de las peticiones diferidas se 30 fusionan en una única petición diferida de vuelta para dicho servidor de origen.
El resultado de dichas peticiones diferidas generadas se usa para entrenar a dicho predictor de TTL de contenido pseudodinámico usando, en una realización, los últimos valores de TTL de dichas peticiones diferidas generadas.
35 En una realización, cada predicción de TTL descarga además el contenido que no puede almacenarse en caché para determinar si dicho contenido que no puede almacenarse en caché es realmente estable, y lo compara con la copia local para determinar el último resultado de predicción de TTL.
En otra realización, el valor de periodo de TTL se establece dependiendo de las peticiones de los proveedores de 40 contenido.
Finalmente, el método define etiquetas de versión con el fin de representar diferentes versiones del mismo contenido que no puede almacenarse en caché.
45 Un segundo aspecto de la invención proporciona un sistema de almacenamiento en caché de web para una red de distribución de contenido (CDN), comprendiendo dicha red de distribución una pluralidad de nodos de almacenamiento en caché y en el que un contenido web se identifica estáticamente como contenido que no puede almacenarse en caché y originado en un servidor de origen, comprendiendo dicho sistema, como es común en este campo:
50
un repositorio centralizado, para descargar el archivo de configuración de una pluralidad de usuarios de CDN; y
medios para establecer un valor de periodo de tiempo de vida (TTL) para dicho contenido que no puede almacenarse en caché basándose en peticiones de usuarios de dicha pluralidad de usuarios de CDN.
55 A diferencia de las propuestas conocidas, en el sistema de la invención cada nodo de almacenamiento en caché de dicha pluralidad de nodos de almacenamiento en caché en dicha red de distribución comprende:
un gestor (1) de almacenamiento en caché de contenido dispuesto para identificar dicho contenido que no puede almacenarse en caché como contenido pseudodinámico; y
60 un predictor (3) de TTL de contenido pseudodinámico dispuesto para predecir dicho valor de periodo de TTL en el que no se modificará el contenido que no puede almacenarse en caché,
en el que el contenido que no puede almacenarse en caché se almacena en caché durante dicho valor de periodo de TTL predicho para cada nodo de almacenamiento en caché.
imagen5
Según la invención, un gestor (4) de peticiones de contenido diferidas está dispuesto para enviar una petición diferida a dicho servidor de origen para cada petición de usuario de dicho contenido pseudodinámico.
5 Además, comprende un elemento (11) de contracción de cola dispuesto para fusionar múltiples de dichas peticiones diferidas en una única petición diferida y un colector (22) de resultados dispuesto para validar el contenido pseudodinámico una vez que dicha petición diferida se ha descargado desde dicho servidor de origen.
El sistema del segundo aspecto de la invención implementa el método del primer aspecto de la presente invención. 10
Breve descripción de los dibujos
Las ventajas y características anteriores y otras se entenderán mejor a partir de la siguiente descripción detallada de realizaciones, con referencia a lo que se adjunta, que debe considerarse de una manera ilustrativa y no limitativa, 15 donde:
La figura 1 muestra el tiempo de transmisión de contenido web dependiendo del tamaño del contenido y optimizaciones TCP. La figura 2 muestra la tasa de compresión de la técnica de compresión sobre la marcha dependiendo del tipo de
20 contenido. La figura 3 representa los componentes principales usados en la presente invención, según una realización. La figura 4 es un flujo de trabajo para una petición de contenido nuevo de un usuario final, según una realización. La figura 5 es un flujo de trabajo para un contenido descargado nuevo del servidor de origen, según una realización.
25 La figura 6 es el gestor de peticiones de contenido diferidas de la presente invención. La figura 7 es un flujo de trabajo para el colector de resultados tras descargar el contenido de una petición diferida, según una realización. La figura 8 muestra el predictor de TTL de contenido pseudodinámico de la presente invención. La figura 9 muestra un diagrama de bloques de la implementación de predictor de valor para la predicción de TTL
30 de contenido, según una realización. La figura 10 es un flujo de trabajo para que los clientes de la CDN creen un archivo de patrón de contenido pseudodinámico, según una realización.
Descripción detallada de varias realizaciones
35 La invención se refiere a un sistema de almacenamiento en caché de web para una CDN que puede reducir significativamente la comunicación de red con el origen para contenido que no puede almacenarse en caché. En particular, los eventos de cambio de contenido que no pueden almacenarse en caché se predicen de manera especulativa, así, la CDN puede entregar este contenido sin interactuar con el origen. Como consecuencia, el tiempo
40 de respuesta del contenido que no puede almacenarse en caché se acelera considerablemente y el tráfico de red en el servidor de origen se reduce de manera eficaz.
La invención incluye mecanismos para permitir a los clientes de la CDN especificar la existencia de contenido pseudodinámico. Entonces se usa un mecanismo de predicción para estimar el periodo de cambio de contenido del 45 contenido pseudodinámico. Además, la predicción se entrena de manera constante con valores reales, de modo que el sistema puede adaptarse a los patrones de cambio de contenido real.
Se implementa un nuevo mecanismo de almacenamiento en caché de web en una solución de CDN que se compone de múltiples nodos de almacenamiento en caché. Cada nodo de almacenamiento en caché de web entra 50 en contacto con un repositorio centralizado para descargar el archivo de configuración para múltiples clientes de la CDN. Para cada cliente, los nodos de almacenamiento en caché de web ejecutan de manera independiente el mecanismo de predicción para estimar el periodo de cambio del contenido pseudodinámico. Una vez que se estima el periodo de cambio, el contenido web se considera como que puede almacenarse en caché para el siguiente periodo predicho. Durante el periodo siguiente, los nodos de almacenamiento en caché darán servicio a todas las
55 peticiones del contenido pseudodinámico usando la copia local en el almacenamiento. Además, se genera una petición diferida al servidor de origen para cada petición de usuario final de un contenido pseudodinámico. El resultado de la petición diferida se usa entonces para entrenar al mecanismo de predicción.
La figura 3 muestra los componentes principales de la invención. El sistema de almacenamiento en caché de
60 contenido pseudodinámico se compone de 4 componentes principales: gestor (1) de almacenamiento en caché de contenido, modulador (2) de contenido pseudodinámico, predictor (3) de TTL de contenido pseudodinámico y gestor (4) de peticiones de contenido diferidas.
Los componentes se complementan con 3 estructuras de datos (archivo (5) de configuración de patrón pseudodinámico, contenido (6) pseudodinámico almacenado en caché e historial (7) de predicción de TTL de contenido pseudodinámico) que proporcionan tanto la configuración como el estado para el contenido pseudodinámico.
imagen6
La descripción detallada de todos los módulos se describirá en las siguientes secciones. 5 Dar servicio a una petición de contenido de un usuario final:
La figura 4 muestra el flujo de trabajo para el nodo de almacenamiento en caché de web para dar servicio a una petición nueva de un usuario final. La primera acción para el nodo de almacenamiento en caché de web es 10 comprobar si el contenido solicitado ya está almacenado en caché en el almacenamiento (2) local. Si el contenido no está almacenado en caché, el nodo de almacenamiento en caché de web lanzará una nueva petición de descarga desde el origen (3). No se realizará ninguna acción más hasta que el origen responda a la petición. En caso de que el contenido esté almacenado en caché, el nodo proporciona el contenido directamente desde el almacenamiento (4) local. Si el contenido almacenado en caché proporcionado es un contenido (5)
15 pseudodinámico, se introducirá una nueva petición diferida en el gestor (6) de peticiones de contenido diferidas. De otro modo, no se requerirán más acciones.
Gestor de almacenamiento en caché de contenido:
20 El componente principal es el gestor de almacenamiento en caché de contenido (CCM). Este componente se encarga de coordinar todo el trabajo de almacenamiento en caché para un contenido descargado nuevo desde el servidor de origen.
La figura 5 muestra el flujo de trabajo de todas las acciones requeridas en el CCM tras descargar un contenido
25 nuevo desde el servidor de origen. En primer lugar, el CCM comprueba la posibilidad de almacenar en caché del contenido nuevo en (2). Si puede almacenarse en caché, se almacenará en caché en el almacenamiento (5) local y el proceso finaliza. En caso de un contenido que no puede almacenarse en caché, el CCM verificará si el contenido es pseudodinámico (3). Si no es pseudodinámico, el contenido sólo se retransmitirá al usuario final sin almacenarlo en el disco local. Si es un contenido pseudodinámico, el CCM llamará al predictor de TTL de contenido pseudo
30 dinámico para estimar el siguiente TTL (4). El TTL predicho se usará para almacenar en caché el contenido en el almacenamiento.
Para cada contenido pseudodinámico almacenado en caché, se incluirá una entrada en la estructura de datos de contenido pseudodinámico almacenado en caché (6 en la figura 3). Cada entrada incluye los siguientes campos:
35
1.
Identificador de contenido pseudodinámico: este identificador da un nombre único a cada contenido pseudodinámico descargado.
2.
Tiempo almacenado en caché: es el tiempo en el que el contenido se almacena en caché.
3.
Tiempo de vencimiento: una marca de fecha y hora que indica cuándo vencerá un contenido. El contenido
40 vencido debe descargarse de vuelta desde el servidor de origen para dar servicio a una nueva petición de usuario final.
Cuando se elimina un contenido pseudodinámico de la caché, el CCM también se encarga de eliminar la entrada relacionada de la estructura de datos de contenido pseudodinámico almacenado en caché.
45 Modulador de contenido pseudodinámico:
Este módulo identifica si un contenido que no puede almacenarse en caché es o bien un contenido pseudodinámico o bien un contenido dinámico puro. El objetivo del diseño de este módulo es proporcionar un
50 mecanismo flexible a los clientes de la CDN para minimizar la probabilidad de identificaciones erróneas de contenido pseudodinámico. Con el fin de conseguir este objetivo, se define una estructura de datos simple: archivo de configuración de patrón pseudodinámico.
El archivo de configuración de patrón pseudodinámico contiene una lista de [P, p, M]. P es una expresión regular
55 que representa el patrón para el identificador de recursos uniforme (URI) de contenido descargado. El segundo elemento de la entrada, p∈[0,1], indica la probabilidad de tener un contenido pseudodinámico para todo aquel contenido cuyo URI coincide con el patrón P. El contenido dinámico puro son todos los URI que coinciden con P donde p=0. El tercer elemento es M y representa el valor máximo para el TTL predicho en segundos.
60 El parámetro p modulará la posibilidad de especulación de la predicción de TTL. Con el parámetro M, los clientes de la CDN pueden especificar la confianza máxima para los valores de TTL especulados. El parámetro p y M se usarán como entrada para que el predictor de TTL coordine/module todo el proceso de predicción.
Gestor de peticiones de contenido diferidas: El objetivo del gestor de peticiones de contenido diferidas (DCRM) es separar la descarga de contenido pseudodinámico (desde el servidor de origen) del servicio a la petición de usuario final, reduciendo así el tiempo de respuesta para contenido pseudodinámico.
imagen7
5 Para cada acierto de caché de contenido pseudodinámico, se genera una petición diferida de vuelta al origen. El módulo de DCRM planifica la ejecución de todas las peticiones diferidas independientemente y puede fusionar múltiples peticiones en una única petición de vuelta al origen. El contenido descargado se compara con el almacenado en caché para determinar el valor de TTL real. El TTL real se usa entonces para entrenar al predictor de
10 TTL para mejores predicciones futuras.
El diseño del DCRM se muestra en una realización en la figura 6. En primer lugar se inserta una nueva petición (7) diferida en la cola (4) de peticiones diferidas. El elemento (1) de contracción de cola se encarga de fusionar múltiples peticiones en una única petición. El elemento (1) de contracción hace esto retardando todas las peticiones en la cola
15 (5) de peticiones contraídas. Para cada petición nueva, el elemento (1) de contracción comprueba en primer lugar si ya hay otra petición en la cola (5) de peticiones contraídas. Si hay otra petición del mismo contenido, la petición nueva se combinará con peticiones previas. Todas las peticiones en la cola (5) de peticiones contraídas se planifican eventualmente mediante un lanzador (3) de peticiones. Se usan múltiples colas en la cola (6) de peticiones en marcha para lanzar la petición de contenido en paralelo. Estableciendo el número de colas de peticiones en marcha,
20 los clientes de la CDN pueden limitar el número máximo de peticiones al origen. Una vez que se descarga el resultado de una petición desde el origen, el colector (2) de resultados notifica el resultado a otros módulos para validar el contenido pseudodinámico almacenado en caché. Obsérvese que si se fusionan múltiples peticiones en una petición, se notificarán múltiples resultados de petición al predictor de TTL con el fin de entrenamiento.
25 La figura 7 muestra más detalles acerca del colector (2) de resultados después de haber finalizado una petición diferida. En primer lugar, se comparará el contenido descargado con el contenido almacenado en caché con el mismo ID pseudodinámico. Si no ha cambiado el contenido, el colector (2) de resultados notificará al predictor de TTL de contenido para una predicción (3) positiva. Además, se generará un valor de TTL nuevo mediante el predictor (4) y se actualizará el contenido almacenado en caché con el valor (5) de TTL nuevo. En caso de que el
30 contenido haya cambiado, el colector de resultados notificará en primer lugar al predictor y a continuación invalidará el contenido almacenado en caché actual. El gestor de almacenamiento en caché de contenido insertará el contenido descargado nuevo siguiendo el flujo de trabajo en la figura 5.
Predictor de TTL de contenido pseudodinámico:
35 Dado un contenido pseudodinámico, el objetivo de este módulo es predecir el valor del TTL siguiente. Esta es la cantidad de tiempo que se considera un contenido que no puede almacenarse en caché como con posibilidad de almacenarse en caché. El núcleo de este módulo es un predictor [5] [6] [7] de valor. Las entradas de este predictor de valor son:
40
1.
El ID de contenido pseudodinámico: que identifica el contenido de manera unívoca.
2.
Historial de predicción de TTL de contenido pseudodinámico: que contiene toda la estructura de datos requerida para producir el TTL siguiente. En la sección de implementación se proporcionará más información.
3.
El valor p y M: son parámetros proporcionados por el modulador de contenido pseudodinámico. Estos dos
45 valores modulan la confianza del sistema para producir una predicción para un contenido dado. Si p=0,0, el predictor considerará el contenido puro dinámico y siempre producirá TTL=0. Cuando p=1,0, por otro lado, el predictor confiará completamente en el mecanismo de predicción y producirá valores más optimistas para TTL.
50 El predictor se entrenará de manera constante mediante los últimos valores de TTL del gestor de peticiones de contenido diferidas. En caso de una predicción errónea, el predictor reducirá el TTL siguiente predicho. De otro modo, se aumentará el TTL siguiente. El parámetro M también modula la predicción limitando el valor máximo del TTL predicho.
55 Según una realización preferida de la presente invención, esto se implementa con el fin de crear la solución de CDN.
Detalle de implementación de gestor de almacenamiento en caché de contenido:
La solución de almacenamiento en caché de web incluye una lógica para decidir si un contenido nuevo puede 60 almacenarse en caché.
La implementación actual decide si el contenido puede almacenarse o no en caché basándose en los siguientes criterios:
imagen8
1.
Si la petición tiene determinadas cabeceras que evitan la posibilidad de almacenar en caché (es decir, control de caché: no almacenar, etc.), el contenido no se almacena en caché.
2.
Si la respuesta tiene un código de estado http diferente de 200, 203, 206, 300, 301, 410, el contenido no se almacena en caché, a menos que las cabeceras de control de caché o vencimiento lo especifiquen.
5 3. Si la respuesta tiene determinadas directivas de control de caché (privada, no almacenar, no caché), el contenido no se almacena.
4.
Si la respuesta tiene determinadas directivas de control de caché (smaxage, maxage, pública), el contenido se almacena en caché.
5.
Si la respuesta tiene cabeceras de vencimiento, el contenido se almacena en caché.
10 6. En este momento, en ausencia de cabeceras de control de caché y vencimiento, el contenido puede almacenarse en caché con la fecha de vencimiento calculada por los validadores (cabeceras de modificados en último lugar).
Con el fin de soportar contenido específico de usuarioagente, la implementación actual define etiquetas de versión
15 para representar diferentes versiones del mismo contenido. Si el contenido no puede almacenarse en caché, el mecanismo de etiquetas de versión garantiza que la etiqueta para cada petición es diferente.
Detalle de implementación de predictor de TTL de contenido pseudodinámico:
20 La parte principal del predictor de TTL de contenido pseudodinámico es el predictor de valor. La implementación actual está inspirada por predictores [5] [6] [7] [9] de intervalo. La idea principal es predecir la cantidad de tiempo que no cambia un contenido pseudodinámico, basándose en el historial previo.
En la figura 9 se muestra un diagrama de bloques de la implementación del predictor de valor. La parte principal del
25 predictor es el historial (2) de predicción de TTL de contenido pseudodinámico. Habrá una entrada en esta tabla para cada contenido pseudodinámico almacenado en caché. Cuando se halla un contenido pseudodinámico por primera vez, se inserta una nueva entrada en (2). El campo de valor de TTL y n.º de peticiones de la nueva entrada se pone a 0. El campo de factor p y factor M se establece a la probabilidad de contenido pseudodinámico correspondiente y el valor máximo para el TTL predicho, como se proporciona por el modulador de contenido
30 pseudodinámico. El campo de intervalo de la nueva entrada se pone a 0.
Por defecto, cada contenido pseudodinámico almacenado en caché se predice de manera especulativa como estable (es decir, el contenido es el mismo que el almacenado en caché). Para cada predicción, se requiere una descarga de contenido con el fin de determinar si el contenido es realmente estable (o si se ha predicho de manera 35 errónea). Esta descarga de contenido se retarda por como máximo el TTL predicho. Una vez descargado el contenido, se compara con la copia almacenada en caché para determinar el último resultado de predicción: acierto
o error. Usando esta información, la lógica de entrenamiento actualiza el intervalo y valor correspondiente. Los aciertos de predicción aumentan el valor de predicción mientras que los errores lo disminuyen. El valor de predicción se aumenta o disminuye según el intervalo correspondiente. El intervalo se modifica según el factor p, factor M
40 correspondiente y los últimos resultados de predicción. Los valores de factor p elevados aumentan o disminuyen el intervalo más rápidamente que los valores de factor p bajos. El campo de n.º de petición cuenta el número de petición del contenido. Este campo se usa para controlar las primeras predicciones cuando el predictor de valor todavía no tiene ningún historial acerca del contenido pseudodinámico. Si el n.º de petición <3, el valor de TTL predicho siempre es 0.
45 Es posible incorporar estimadores de confianza, tal como se indica en [10], con el fin de mejorar el tiempo de entrenamiento de predicción.
Detalle de implementación de gestor de peticiones de contenido diferidas:
50 Cada elemento en cola de peticiones diferidas contiene toda la información necesaria para generar una petición al origen que incluye:
1. URL: para el contenido web que va a solicitarse.
55 2. Cabeceras de petición: todas las cabeceras en la petición de HTTP de usuario, incluyendo las cookies y otras cabeceras en la norma HTTP [8].
3.
Dirección IP: del usuario final.
4.
Tiempo de petición: una marca de fecha y hora que indica cuándo se realiza la petición.
60 La estructura de datos para los elementos en cola de peticiones contraídas es una lista de elementos en la cola de peticiones diferidas, clasificados por el tiempo de petición. El lanzador de peticiones inicia una petición al origen cuando la primera petición de usuario final se ha puesto en cola en la cola de peticiones contraídas durante más de min(TTL, Q) segundos. En la implementación actual, usa Q=5 segundos fijos, aunque puede extenderse hasta un valor dinámico en implementaciones futuras. Un valor dinámico podrá adaptarse a la tasa de petición para conseguir
imagen9
un buen equilibrio entre el tráfico en origen y la precisión de predicción de TTL.
En la implementación actual, el cliente de CDN proporciona la capacidad para configurar un número máximo de peticiones en marcha en la cola de peticiones en marcha. El valor por defecto se fija en 50. El cliente tiene la 5 posibilidad de limitar el número máximo de peticiones paralelas desde cada nodo de almacenamiento en caché de web.
Ventajas de la invención:
10 La presente invención aprovecha de manera eficaz la existencia de contenido pseudodinámico en Internet actual para reducir la carga en el servidor de origen así como proporcionar un tiempo de respuesta extraordinariamente bajo a los usuarios finales.
Tiempo de respuesta bajo: en comparación con otras técnicas de aceleración para contenido que no puede
15 almacenarse en caché, la invención proporciona un enfoque completamente nuevo para reducir el tiempo de respuesta en la entrega de contenido web. En lugar de centrarse en reducir el RTT de la red y el número de ciclos de transferencia en el protocolo TCP, el enfoque de la invención proporciona el mecanismo para separar la dependencia de los datos convirtiendo el contenido que no puede almacenarse en caché en contenido que puede almacenarse en caché. Como resultado, el enfoque de la invención puede eliminar por completo todos los retardos
20 de red asociados con la primera milla, siendo la primera milla la red entre el servidor de origen y el nodo de almacenamiento en caché de web.
La proporción de reducción del tiempo de respuesta de la invención, en comparación con la mejor técnica de aceleración existente para contenido pseudodinámico muestra que la mejor técnica existente puede enviar de 25 manera ideal el contenido al usuario final en sólo un RTT (retardo de primera milla + retardo de última milla). La presente invención, por otro lado, puede eliminar completamente el retardo en la primera milla, dando como resultado una gran proporción de reducción del tiempo de respuesta. Por ejemplo, si el servidor de origen está en EE.UU., el nodo de almacenamiento en caché de web en la UE puede reducir el tiempo de respuesta a la UE, en este caso el retardo de primera milla es de aproximadamente 170 ms y el retardo de última milla es de
30 aproximadamente 40 ms, de los usuarios finales aproximadamente en un 80 %.
Baja carga de red en servidor de origen: la separación de la dependencia de los datos permite al sistema diferir la petición de datos a los servidores de origen. Entonces, pueden fusionarse múltiples peticiones diferidas en una única petición en el gestor de peticiones de contenido diferidas, dando como resultado una reducción de carga significativa
35 en el servidor de origen.
Alta flexibilidad: el archivo de patrón de contenido pseudodinámico proporciona un mecanismo extremadamente flexible para que los clientes de la CDN usen el presente sistema de almacenamiento en caché de web especulativo. Los clientes pueden conectar/desconectar potencialmente los mecanismos de predicciones de TTL para cada
40 contenido web. La sintaxis del archivo de configuración de la invención es simple para los clientes y tanto el parámetro p como M pueden determinarse fácilmente teniendo en cuenta la lógica de aplicación.
La figura 12 muestra el flujo de trabajo para que los clientes de la CDN creen el archivo de patrón de contenido pseudodinámico inicial. La idea básica es separar en primer lugar todo el contenido (1)(2) dinámico puro y a 45 continuación agrupar otro contenido pseudodinámico según el TTL (3) promedio esperado. Para cada grupo, fijar el parámetro M para que sea el TTL (5) promedio y calcular el valor para p según alguna métrica (6) de variación de TTL esperada. Dado el archivo de patrón inicial, el cliente puede ajustar el sistema subdividiendo grupos según variaciones de TTL. Por ejemplo, los clientes pueden separar todo el contenido pseudodinámico con un periodo de cambio muy predecible de todo aquél con el mismo TTL promedio y configurar un valor muy alto para el parámetro
50 p.
Alta precisión en predicción de TTL: el predictor de valor es muy eficaz para predecir el TTL para contenido pseudodinámico. El comportamiento del predictor de TTL depende del parámetro p. Por ejemplo, en una realización, el TTL del contenido pseudodinámico se muestra como siguiendo un patrón de 3 etapas, donde el contenido es dinámico 55 puro de 8 a.m. a 10 a.m. El predictor de TTL puede adaptar la tendencia de variación de TTL en las 3 etapas. Esto es posible porque el predictor de intervalo puede representar las tendencias de variación de valor. Usando el parámetro p, puede cambiarse de manera eficaz el comportamiento del predictor de TTL. Usando un factor p mayor, el predictor de valor produce resultados más especulativos, mientras que un factor p bajo hace que el predictor de valor sea más conservativo. El parámetro M también permite que la invención limite el TTL predicho para que sea
60 menos de 200 segundos.
Siglas
CDN Content Distribution Network; red de distribución de contenido
imagen10
HTTP Hypertext Transfer Protocol; protocolo de transferencia de hipertexto TTL Time to Live; tiempo de vida URI Uniform Resource Identifier; identificador de recursos uniforme URL Uniform Resource Locator; localizador de recursos uniforme
5 Bibliografía
[1] Dukkipati, N. e. (julio de 2010). An Argument for Increasing TCP's Initial Congestion Window. ACM Computer Communication Review.
10 [2] Abhinav Pathak, Y. A. (2010). Measuring and evaluating TCP Splitting for Cloud Services. In Proceedings of the 11th Passive and Active Measurement Conference (PAM 2010) [3 Vinton G. Cerf, Robert E. Kahn, (mayo de 1974). “A Protocol for Packet Network Intercommunication”. IEEE Transactions on Communications 22 (5): 637648.
[4] RFC 793
15 [5] JeanLoup Baer y TienFu Chen. 1995. Effective HardwareBased Data Prefetching for HighPerformance Processors. IEEE Trans. Comput. 44, 5 (mayo de 1995), 609623.
[6] Yiannakis Sazeides y James E. Smith. 1997. The predictability of data values. In Proceedings of the 30th annual ACM/IEEE international symposium on Microarchitecture (MICRO 30). IEEE Computer Society, Washington, DC, Estados Unidos, 248258.
20 [7] Srikanth T. Srinivasan y Alvin R. Lebeck. 1998. Load latency tolerance in dynamically scheduled processors. In Proceedings of the 31st annual ACM/IEEE international symposium on Microarchitecture (MICRO 31). IEEE Computer Society Press, Los Alamitos, CA, Estados Unidos, 148159.
[8] RFC 2616
[9] Gabbay, F., Mendelson, A.: Speculative Execution Based on Value Prediction. Technical, Informe N.º 1080, 25 Technion, Electrical Engineering Department. (1996)
[10] Aragon, J.L., Gonzalez, J., García, J.M., Gonzalez, A. : Confidence Estimation for Branch Prediction Reversal. In Proc. of the Int. Conference on High Performance Computing (2001).

Claims (12)

  1. imagen1
    REIVINDICACIONES
    1. Un método de almacenamiento en caché de web para una red de distribución de contenido (CDN), comprendiendo dicha red de distribución una pluralidad de nodos de almacenamiento en caché y en el que el
    5 contenido web se ha identificado estáticamente como contenido que no puede almacenarse en caché y originado en un servidor de origen, comprendiendo el método:
    establecer un valor de periodo de tiempo de vida, TTL, para dicho contenido que no puede almacenarse en caché basándose en peticiones de usuarios; y
    10 responder a dichas peticiones de usuarios enviando a al menos un usuario de CDN dicho contenido que no puede almacenarse en caché dentro de dicho valor de periodo de TTL,
    caracterizado por que cada uno de dicha pluralidad de nodos de almacenamiento en caché en dicha red de distribución incluye un gestor de almacenamiento en caché de contenido y un predictor de TTL de contenido pseudo15 dinámico y por que dicho método comprende las siguientes etapas:
    a) poner en contacto cada uno de dicha pluralidad de nodos con un repositorio centralizado, con el fin de descargar un archivo de configuración de una pluralidad de dichos usuarios de CDN. b) identificar, por parte de dicho gestor de almacenamiento en caché de contenido de cada nodo de
    20 almacenamiento en caché, el contenido que no puede almacenarse en caché como contenido pseudodinámico; c) predecir, por parte de un predictor de TTL de contenido pseudodinámico de dicho nodo de almacenamiento en caché, dicho valor de periodo de TTL en el que no se modificará el contenido que no puede almacenarse en caché, prediciéndose el valor de periodo de TTL por medio del predictor de TTL de contenido pseudodinámico al menos considerando:
    25
    un identificador que identifica el contenido que no puede almacenarse en caché,
    estructura de datos que contiene historial de predicción anterior y que se requiere para producir el valor de periodo de TTL, y
    dos parámetros, p y M, proporcionados mediante un modulador de contenido pseudodinámico, que
    30 modulan confianza de la predicción, modulando dicho parámetro p la posibilidad de especulación de la predicción de TTL y especificando dicho parámetro M la confianza máxima para valores de TTL especulados; y
    d) almacenar en caché, por parte de cada uno de dicha pluralidad de nodos, el contenido que no puede 35 almacenarse en caché durante dicho valor de periodo de TTL predicho.
  2. 2. El método de almacenamiento en caché de web según la reivindicación 1, caracterizado por que dicha etapa c) se realiza para cada uno de dicha pluralidad de usuarios de CDN.
    40 3. El método de almacenamiento en caché de web según la reivindicación 2, caracterizado por que comprende dar servicio a todas de dichas peticiones de dichos usuarios de dicho contenido pseudodinámico usando una copia local del archivo de configuración en dicho repositorio centralizado.
  3. 4. El método de almacenamiento en caché de web según cualquiera de las reivindicaciones anteriores,
    45 caracterizado por que comprende retransmitir dicho contenido que no puede almacenarse en caché a dicho usuario de CDN sin almacenarlo en dicho repositorio centralizado si dicho contenido que no puede almacenarse en caché no es pseudodinámico.
  4. 5. El método de almacenamiento en caché de web según la reivindicación 1 o 3, caracterizado por que comprende
    50 además generar, por parte de un gestor de peticiones de contenido diferidas, una petición diferida para dicho servidor de origen para cada petición de usuario de dicho contenido pseudodinámico con el fin de separar la descarga de contenido pseudodinámico.
  5. 6. El método de almacenamiento en caché de web según la reivindicación 5, caracterizado por que comprende
    55 además planificar de manera independiente dichas peticiones diferidas y fusionar múltiples de dichas peticiones diferidas en una única petición diferida de vuelta para dicho servidor de origen.
  6. 7. El método de almacenamiento en caché de web según la reivindicación 6, caracterizado por que comprende
    usar el resultado de dichas peticiones diferidas generadas para entrenar dicho predictor de TTL de contenido 60 pseudodinámico.
  7. 8.
    El método de almacenamiento en caché de web según la reivindicación 7, caracterizado por que comprende entrenar el predictor de TTL de contenido pseudodinámico con los últimos valores de TTL de dichas peticiones diferidas generadas.
  8. 9.
    El método de almacenamiento en caché de web según las reivindicaciones anteriores, caracterizado por que para cada predicción de TTL comprende además descargar el contenido que no puede almacenarse en caché para determinar si dicho contenido que no puede almacenarse en caché es realmente estable, y compararlo con la copia
    12
    imagen2
    5 local para determinar el último resultado de predicción de TTL.
  9. 10. El método de almacenamiento en caché de web según la reivindicación 1, caracterizado por que comprende establecer dicho valor de TTL dependiendo de las peticiones de los proveedores de contenido.
    10 11. El método de almacenamiento en caché de web según la reivindicación 1, caracterizado por que define etiquetas de versión con el fin de representar diferentes versiones del mismo contenido que no puede almacenarse en caché.
  10. 12. Un sistema de almacenamiento en caché de web para una red de distribución de contenido (CDN),
    15 comprendiendo dicha red de distribución una pluralidad de nodos de almacenamiento en caché y en el que un contenido web se identifica estáticamente como contenido que no puede almacenarse en caché y origina en un servidor de origen, comprendiendo dicho sistema:
    un repositorio centralizado, para descargar el archivo de configuración de una pluralidad de usuarios de CDN; y
    20 medios para establecer un valor de periodo de tiempo de vida (TTL) para dicho contenido que no puede almacenarse en caché basándose en peticiones de usuarios de dicha pluralidad de usuarios de CDN,
    caracterizado por que cada nodo de almacenamiento en caché de dicha pluralidad de nodos de almacenamiento en caché en dicha red de distribución comprende:
    25
    un gestor (1) de almacenamiento en caché de contenido dispuesto para identificar dicho contenido que no puede almacenarse en caché como contenido pseudodinámico; y
    un predictor (3) de TTL de contenido pseudodinámico dispuesto para predecir dicho valor de periodo de TTL
    en el que no se modificará el contenido que no puede almacenarse en caché por medio de considerar al menos: 30
    un identificador que identifica el contenido que no puede almacenarse en caché,
    estructura de datos que contiene historial de predicción anterior y que se requiere para producir el valor de periodo de TTL, y
    dos parámetros, p y M, proporcionados mediante un modulador de contenido pseudodinámico, que
    35 modulan la confianza de la predicción, modulando dicho parámetro p la posibilidad de especulación de la predicción de TTL y especificando dicho parámetro M la confianza máxima para valores de TTL especulados; y
    en el que el contenido que no puede almacenarse en caché se almacena en caché durante dicho valor de 40 periodo de TTL predicho para cada nodo de almacenamiento en caché.
  11. 13. El sistema de almacenamiento en caché de web según la reivindicación 12, caracterizado por que comprende un gestor (4) de peticiones de contenido diferidas dispuesto para enviar una petición diferida a dicho servidor de origen para cada petición de usuario de dicho contenido pseudodinámico.
    45
  12. 14. El sistema de almacenamiento en caché de web según la reivindicación 13, caracterizado por que comprende un elemento (11) de contracción de cola dispuesto para fusionar múltiples de dichas peticiones diferidas en una única petición diferida.
    50 15. El sistema de almacenamiento en caché de web según la reivindicación 14, caracterizado por que comprende además un colector (22) de resultados dispuesto para validar el contenido pseudodinámico una vez que dicha petición diferida se ha descargado desde dicho servidor de origen.
    13
ES13741781.2T 2012-08-02 2013-07-29 Método y sistema de almacenamiento en caché web para una red de distribución de contenido (CDN) Active ES2585387T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
ES201231263A ES2441490B1 (es) 2012-08-02 2012-08-02 Método y sistema de almacenamiento en caché de web para una red de distribución de contenido (cdn)
ES201231263 2012-08-02
PCT/EP2013/065873 WO2014019970A2 (en) 2012-08-02 2013-07-29 Web caching method and system for content distribution network (cdn)

Publications (1)

Publication Number Publication Date
ES2585387T3 true ES2585387T3 (es) 2016-10-05

Family

ID=48875068

Family Applications (2)

Application Number Title Priority Date Filing Date
ES201231263A Withdrawn - After Issue ES2441490B1 (es) 2012-08-02 2012-08-02 Método y sistema de almacenamiento en caché de web para una red de distribución de contenido (cdn)
ES13741781.2T Active ES2585387T3 (es) 2012-08-02 2013-07-29 Método y sistema de almacenamiento en caché web para una red de distribución de contenido (CDN)

Family Applications Before (1)

Application Number Title Priority Date Filing Date
ES201231263A Withdrawn - After Issue ES2441490B1 (es) 2012-08-02 2012-08-02 Método y sistema de almacenamiento en caché de web para una red de distribución de contenido (cdn)

Country Status (5)

Country Link
US (1) US10171610B2 (es)
EP (1) EP2880839B1 (es)
BR (1) BR112015002260A2 (es)
ES (2) ES2441490B1 (es)
WO (1) WO2014019970A2 (es)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10261938B1 (en) * 2012-08-31 2019-04-16 Amazon Technologies, Inc. Content preloading using predictive models
US8819187B1 (en) 2013-10-29 2014-08-26 Limelight Networks, Inc. End-to-end acceleration of dynamic content
US9871850B1 (en) 2014-06-20 2018-01-16 Amazon Technologies, Inc. Enhanced browsing using CDN routing capabilities
US11070608B2 (en) * 2015-06-17 2021-07-20 Fastly, Inc. Expedited sub-resource loading
US11895212B2 (en) * 2015-09-11 2024-02-06 Amazon Technologies, Inc. Read-only data store replication to edge locations
US10848582B2 (en) 2015-09-11 2020-11-24 Amazon Technologies, Inc. Customizable event-triggered computation at edge locations
CN106020732A (zh) * 2016-05-27 2016-10-12 乐视控股（北京）有限公司 节点的磁盘空间确定方法及系统
US10346303B1 (en) * 2017-06-26 2019-07-09 Amazon Technologies, Inc. Origin server cache eviction system
CN107707621B (zh) * 2017-08-30 2018-07-20 贵州白山云科技有限公司 一种实现智能缓存的方法及装置
CN109561027A (zh) * 2017-09-26 2019-04-02 中兴通讯股份有限公司 透明缓存的流量优化方法、负载均衡器及存储介质
US10715615B1 (en) * 2018-08-01 2020-07-14 The Government Of The United States Of America As Represented By The Secretary Of The Air Force Dynamic content distribution system and associated methods

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002017082A1 (en) * 2000-08-22 2002-02-28 Akamai Technologies, Inc. Dynamic content assembly on edge-of-network servers in a content delivery network
US20040128346A1 (en) 2001-07-16 2004-07-01 Shmuel Melamed Bandwidth savings and qos improvement for www sites by catching static and dynamic content on a distributed network of caches
US7363035B2 (en) * 2002-02-07 2008-04-22 Qualcomm Incorporated Method and apparatus for providing content to a mobile terminal
US8650266B2 (en) 2002-03-26 2014-02-11 At&T Intellectual Property Ii, L.P. Cache validation using smart source selection in a data network
US8447837B2 (en) * 2005-12-30 2013-05-21 Akamai Technologies, Inc. Site acceleration with content prefetching enabled through customer-specific configurations
US7953392B2 (en) * 2006-12-19 2011-05-31 International Business Machines Corporation Method for controlling and calibrating access to a wireless access point
US20080183828A1 (en) * 2007-01-30 2008-07-31 Amit Sehgal Communication system
US7975025B1 (en) * 2008-07-08 2011-07-05 F5 Networks, Inc. Smart prefetching of data over a network
US8000259B2 (en) * 2009-09-04 2011-08-16 Viasat, Inc. Distributed cache—adaptive multicast architecture for bandwidth reduction
US8576868B2 (en) * 2009-11-30 2013-11-05 Telefonaktiebolaget L M Ericsson (Publ) Media transport protocol selection
US8209491B2 (en) * 2010-04-27 2012-06-26 Symantec Corporation Techniques for directory server integration
US9906488B2 (en) * 2010-10-26 2018-02-27 Cedexis, Inc. Surrogate name delivery network

Also Published As

Publication number Publication date
ES2441490A2 (es) 2014-02-04
WO2014019970A2 (en) 2014-02-06
ES2441490B1 (es) 2015-04-13
EP2880839B1 (en) 2016-06-29
EP2880839A2 (en) 2015-06-10
US10171610B2 (en) 2019-01-01
ES2441490R1 (es) 2014-05-06
US20150229733A1 (en) 2015-08-13
WO2014019970A3 (en) 2014-03-27
BR112015002260A2 (pt) 2017-07-04

Similar Documents

Publication Publication Date Title
ES2585387T3 (es) Método y sistema de almacenamiento en caché web para una red de distribución de contenido (CDN)
CN106537880B (zh) 在信息中心网络架构中缓存数据
CN102118263B (zh) 配置信息的发布方法及系统
US7702917B2 (en) Data transfer using hyper-text transfer protocol (HTTP) query strings
EP3035638A1 (en) Interest acknowledgements for information centric networking
KR20160045010A (ko) 캐시에서 데이터 이름 기반 네트워킹 객체들에 순위를 매기기 위한 시스템 및 방법
Ott et al. Dtn-based content storage and retrieval
Moiseenko et al. Consumer/producer communication with application level framing in named data networking
CN108540505B (zh) 一种内容更新方法及装置
JP2016024816A (ja) コンテンツセントリックネットワークにおいてインタレストをキープアライブするための方法およびシステム
JP2016059039A (ja) Ｃｃｎにおける中間ルータにおけるインタレストキープアライブ
US20210044509A1 (en) Intelligent Edge Gateway Device with Path and Response Time Optimization
CN116633934A (zh) 负载均衡方法、装置、节点及存储介质
Paik et al. Scalable signaling protocol for Web real-time communication based on a distributed hash table
CN108718274A (zh) 一种即时通讯消息的防丢失方法
JP2021517767A (ja) ランダム差動リレー及びネットワークコーディングのシステム及び方法
US10812355B2 (en) Record compression for a message system
Dimitriou et al. Sensenet: a wireless sensor network testbed
US20160344838A1 (en) Caching of tracking elements in network content
US20180115601A1 (en) Load balancing
EP3408989B1 (en) Detecting malware on spdy connections
JP5728368B2 (ja) ネットワークシステム、及び通信装置
CN117579288A (zh) 握手复用方法、设备以及计算机可读介质
US20130007369A1 (en) Transparent Cache for Mobile Users
Baldoni et al. Practical uniform peer sampling under churn