ES2318978B2 - Mecanismos de marcado e identificacion en el nivel de transporte para la gestion de caches de contenidos. - Google Patents
Mecanismos de marcado e identificacion en el nivel de transporte para la gestion de caches de contenidos. Download PDFInfo
- Publication number
- ES2318978B2 ES2318978B2 ES200601958A ES200601958A ES2318978B2 ES 2318978 B2 ES2318978 B2 ES 2318978B2 ES 200601958 A ES200601958 A ES 200601958A ES 200601958 A ES200601958 A ES 200601958A ES 2318978 B2 ES2318978 B2 ES 2318978B2
- Authority
- ES
- Spain
- Prior art keywords
- content
- tcp
- server
- marking
- option
- 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
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
-
- H04L29/06095—
-
- H04L29/08729—
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer And Data Communications (AREA)
Abstract
Mecanismos de marcado e identificación en el
nivel de transporte para la gestión de cachés de contenidos.
El objeto de esta invención es definir los
mecanismos y las características adicionales necesarias para
soportar el despliegue de servicios caché de contenidos basados en
el protocolo de nivel de transporte. Proporciona los mecanismos de
marcado necesarios para la identificación de contenidos en el nivel
de transporte, así como los mecanismos de intercepción que
permitirían el envío de los contenidos en caché por parte de
servidores intermedios. Se propone un diseño específico de estos
mecanismos, empleando el protocolo de transporte TCP. Los
mecanismos propuestos son de aplicación directa en el despliegue de
las redes de comunicaciones, permitiendo la creación de servicios
de caché genéricos, independientes de las aplicaciones que hacen
uso de los mismos.
Description
Mecanismos de marcado e identificación en el
nivel de transporte para la gestión de cachés de contenidos.
La presente invención se refiere a las
características adicionales que se propone incluir en el protocolo
de nivel de transporte para permitir el despliegue de servicios
caché de contenido que se sitúen en dicho nivel. Por tanto resulta
de aplicación para las comunicaciones en redes de ordenadores en
las que se disponga de un protocolo de transporte específico. Un
campo específico de aplicación serán las redes de comunicaciones
que emplean el conjunto de protocolos conocido como TCP/IP (por
ejemplo la red Internet).
La problemática asociada al uso compartido de
una red de acceso a Internet y el uso frecuente de determinados
destinos proveedores de servicios a través de esta red, es un
problema ampliamente conocido. Sin embargo, las soluciones abordadas
para este mismo problema han sido muy dispares en función del tipo
de aplicación y de la naturaleza de la misma. Hasta el momento, las
soluciones planteadas al uso compartido de una misma información
desde diferentes sistemas bajo una misma red de acceso, se han
ubicado en el nivel de aplicación. Seguidamente se muestran tres
diferentes escenarios de uso de caché.
Corresponde a la solución aplicada en entornos
web para el despliegue de cachés de datos, observándose una
solución basada en distintos niveles jerárquicos:
- -
- Caché local: cada usuario tiene en su propio navegador web una caché gestionada por el propio navegador, cuya influencia sobre las peticiones web realizadas es gestionada por la propia aplicación.
- -
- Servidores Proxy corporativos: controlan el acceso a determinadas URLs, e incluyen en la mayoría de los casos el funcionamiento como servidor caché. El navegador es consciente de la existencia de un servidor proxy, ya que realiza las peticiones web a través de él, pero no se encarga de la gestión de la caché.
- -
- Servidores web-caché intermedios: interceptan las peticiones de los usuarios y devuelven automáticamente los datos correspondientes a aquellas peticiones cuyo contenido poseen. La gestión del contenido de la caché y su existencia son completamente transparentes para el navegador cliente.
La solución aplicada a este caso, se ciñe
únicamente al entorno web y al protocolo HTTP, y todos los
elementos que la forman se centran sobre HTTP. Los contenidos se
identifican de forma única, para introducirlos en la caché, a partir
de su URL.
Se trata de un problema similar, resuelto de un
modo parecido al mostrado en el escenario primero y corresponde a
los servicios de noticias (news) en Internet. Las noticias se
organizan según grupos a los que el usuario se suscribe y de los que
se descarga las cabeceras de todas las noticias y el contenido,
únicamente, de aquellas que desea. El contenido de estos grupos de
noticias lo descarga el proveedor de servicios de Internet a un
servidor local al que permite conectarse a sus usuarios. Éste vuelve
a ser un esquema de distribución de información basado en cachés
locales. En este caso se distingue la comunicación entre servidores
de noticias y la comunicación entre los clientes de noticias y los
servidores locales, proporcionando diferentes mecanismos para la
misma.
Este tercer escenario corresponde a la
descripción y establecimiento de mecanismos para el despliegue de
servidores caché bajo protocolos y arquitecturas de compartición de
ficheros (por ejemplo, haciendo uso de NFS). Estos trabajos, en su
mayoría anteriores a los mencionados para HTTP, también resultan en
soluciones muy evolucionadas para el despliegue de cachés asociadas
al protocolo de compartición de ficheros.
En los tres ejemplos citados, y en los ejemplos
conocidos hasta la fecha, el factor común se encuentra en que las
cachés de datos se establecen a partir de información válida para
un protocolo de aplicación determinado, de modo que su despliegue
sólo resulta adecuado para un conjunto de aplicaciones determinado.
En algunos casos incluso, una caché de este tipo situada en el
nivel de aplicación es empleada por un conjunto extendido de
aplicaciones que hace uso del protocolo original para beneficiarse
de la caché de aplicación origen, como ocurre con el uso de los
servidores Proxy-web en redes P2P.
En esta propuesta vamos a plantear el uso de un
mecanismo de caché más genérico que los descritos hasta el momento:
se trata de integrarlo junto con el protocolo de transporte.
El primer problema que hay que resolver a la
hora de proponer un mecanismo de caché con una generalidad mayor a
los descritos, está en la identificación unívoca de los contenidos.
Por ejemplo, en el caso de los servidores caché de web, esta
identificación unívoca la proporciona la URL.
La solución planteada pasa por identificar el
objeto que se inserta en la caché a partir de él mismo. Se propone
calcular un hash del objeto que lo identifique de forma única, tal
y como hacen actualmente las redes P2P para identificar sus
contenidos.
El uso de un identificador que sólo se basa en
el contenido, permite aislar la identificación del contenido del
protocolo de aplicación que lo proporcione. Adicionalmente,
proporciona automáticamente una solución a los problemas de
actualización de contenidos en las cachés jerárquicas.
El segundo problema que hay que resolver es el
marcado de los contenidos que pueden o deben introducirse en el
espacio de caché. Cuando las cachés se sitúan en el protocolo de
aplicación, son las propias aplicaciones, cliente o servidor, las
que se encargan de determinar qué contenidos se pueden cachear. La
traslación al nivel de transporte de la gestión de la caché exigirá
que determinados segmentos de una conexión marquen de forma
específica que contienen fragmentos de un contenido determinado,
cacheable o no. Esto se llevará a cabo mediante el uso de opciones
del protocolo de transporte que reconozcan la porción del contenido
unívocamente identificado que transportan los segmentos.
Como en cualquier sistema básico de caché como
los descritos en el estado de la técnica, se tienen tres
componentes básicos en la arquitectura: el servidor de contenido,
el servidor de caché y el cliente. Esta propuesta basa su
funcionamiento en las siguientes modificaciones sobre cada uno de
los componentes:
- -
- Cliente. No se requiere ninguna modificación sobre las aplicaciones que ejecutan los clientes ni sobre la pila de red en estos sistemas.
- -
- Servidor de contenido. Las aplicaciones que se ejecutan en los servidores de contenido o el hardware de los mismos deben ser responsables de la inclusión del marcado de contenido en los intercambios de información susceptibles de ser almacenados en caché, mediante el protocolo de transporte. Para ello, la pila de red del equipo deberá proporcionar un mecanismo sencillo que permita al servidor identificar los contenidos que deben ser transmitidos, complementario a los mecanismos existentes para el envío de información.
- Para que el mecanismo de cacheado funcione correctamente, este componente debe por lo tanto marcar como cacheable, según los mecanismos de marcado establecidos, los contenidos cuya transmisión pueda ser interceptada.
- -
- Servidor de caché. Las aplicaciones o el hardware en estos servidores deberán intervenir en los intercambios que identifique que transportan contenidos que pueden incluirse en la caché. En los casos en los que se identifique así, este servidor intermedio podrá actuar de dos formas diferentes:
- \circ
- Escuchando. Cuando se identifiquen contenidos que son susceptibles de introducirse en la caché, este servidor podrá escucharlos y almacenarlos.
- \circ
- Interceptando. Las transferencias de contenido que se identifiquen y que el servidor intermedio haya almacenado, pueden ser interceptadas por el mismo. El servidor intermedio proporcionará de forma transparente los contenidos al cliente, y se encargará de informar al servidor de la intercepción para que aborte el envío de información adicional.
El mecanismo descrito posee ciertas ventajas
sobre los descritos en el apartado 2, donde se describía el estado
actual de la técnica:
- -
- No es necesario emplear ningún mecanismo dependiente del protocolo de aplicación para el marcado de los contenidos.
- -
- El marcado de los contenidos depende de estos mismos contenidos, de modo que se resuelve automáticamente la actualización de las cachés ante la renovación de los contenidos.
- -
- El uso de una opción del protocolo de transporte para el marcado de los contenidos permite aprovechar las características de control de flujo y gestión de conexiones del mismo para el propio cacheado de los contenidos.
- -
- La interceptación de la transmisión de los contenidos por parte del servidor intermedio, que implica la existencia de una comunicación previa con el servidor origen, permite un funcionamiento extremo a extremo para el comienzo de la comunicación; únicamente se produce la intercepción una vez que el servidor de contenido ha iniciado la transmisión de un contenido cacheable al destino. Esto permite por tanto que se cumplan requisitos de comunicación extremo a extremo sobre protocolos de transporte y red que así lo exigen.
- -
- El mantenimiento del flujo de confirmaciones entre el cliente y el servidor de contenidos, a pesar de existir un servidor intermedio, permite que el control de flujo entre el servidor de contenido y el cliente siga actuando. Por ello, aunque la transmisión de contenidos haya sido interceptada, hasta que no finalice la transmisión de contenidos por parte del servidor intermedio, el servidor de contenido no comunicará a sus aplicaciones dicha situación.
La figura 1 representa el esquema básico de
funcionamiento de la comunicación cliente-servidor,
mostrando los distintos componentes que intervienen en el esquema de
caché descrito.
El componente (1) representa el servidor de
contenido, que ante las peticiones de los clientes, proporcionará
el contenido a los mismos. Puede tratarse de un servidor de FTP, un
servidor web, o cualquier tipo de servidor. En este componente
deberán insertarse los cambios descritos para el servidor de
contenido descrito en 3.3.
El componente (2) representa el servidor de
caché, que contiene un dispositivo asociado de almacenamiento. Este
será el encargado del almacenamiento intermedio de los contenidos y
de su transmisión/intercepción de comunicación con los clientes tal
y como se ha descrito en 3.3.
El componente (3) representa el cliente que
solicita los contenidos al servidor de contenido (1) y cuya
petición se encuentra en el camino con un servidor de caché (2) que
puede interceptar la transmisión de contenidos. En este componente
no son necesarios cambios, tal y como se describe en 3.3.
Para la descripción de un modo específico de
realización que aquí se expone, se especifican los cambios
necesarios sobre el protocolo de transporte TCP para la inclusión
en el mismo de los mecanismos de caché descritos.
Para identificar de forma única cada uno de los
contenidos que se insertan en la caché de contenidos, se empleará
un algoritmo de cálculo de hash. Se propone emplear un código hash
basado en un resumen largo, como es SHA-1.
El uso de opciones en los segmentos TCP
permitirá identificar qué segmentos contienen información sobre un
determinado contenido. La definición de las opciones que se
necesitarán y el momento en que se incluirán en los segmentos TCP,
van a definir en gran medida el uso que se le quiere dar a las
mismas. Los tres momentos para intercambiar estas opciones son los
siguientes:
- -
- Opción para indicar durante el establecimiento de la conexión que el contenido podrá incluir segmentos con el contenido marcado.
- -
- Opción para el marcado de los segmentos durante la transmisión del contenido cuya inclusión en un servidor de caché se quiere habilitar.
- -
- Opción para indicar la interceptación de la conexión por un servidor intermedio al origen de los contenidos marcados.
Durante el intercambio de los paquetes de
establecimiento de conexión, cada uno de los extremos insertará
esta opción para indicar que a lo largo de la misma, podrá marcar
algún tipo de contenido en la conexión para ser cacheado. Cada uno
de los dos extremos, independientemente de cuál de los dos inicie
la conexión, podrá incluir la opción.
El formato para esta opción será el
siguiente:
- -
- Octeto 1. Tipo de opción. Valor fijo igual a 231.
- -
- Octeto 2. Longitud. Valor fijo igual a 2.
Se ha escogido como identificador único para la
opción de marcado de contenido el valor decimal 231, pero puede ser
sustituido por cualquier otro válido y que no se encuentre en uso
actualmente.
Durante el intercambio de datos en una conexión,
y en cada uno de los dos sentidos de la comunicación, se puede
marcar la transferencia de un contenido en cualquier momento. Cada
segmento individual que incluya un fragmento determinado de un
contenido susceptible de incluirse en caché, incluirá la siguiente
opción:
- -
- Octeto 1. Tipo de opción. Valor fijo igual a 231.
- -
- Octeto 2. Longitud. Valor fijo igual a 30.
- -
- Octetos 3-22. Hash SHA-1 del contenido cacheable.
- -
- Octetos 23-26. Longitud del contenido cacheable.
- -
- Octetos 27-30. Desplazamiento relativo del segmento marcado sobre la longitud total del contenido cacheable.
Cuando un servidor intermedio detecte el inicio
de la transmisión de un contenido, que estará marcado por la opción
descrita en el apartado 5.2.2., puede decidir servir dicho
contenido al destino. En ese caso, debe notificar al servidor origen
de dicha intercepción, para que no continúe enviando información.
Esto se hará mediante una opción TCP como la siguiente:
- -
- Octeto 1. Tipo de opción. Valor fijo igual a 232.
- -
- Octeto 2. Longitud. Valor fijo igual a 30.
- -
- Octetos 3-22. Hash SHA-1 del contenido cacheable.
- -
- Octetos 23-26. Longitud del contenido cacheable.
- -
- Octetos 27-30. Dirección IP del servidor caché que intercepta la conexión.
Se ha escogido como identificador único para la
opción de intercepción el valor decimal 232. pero puede ser
sustituido por cualquier otro válido y que no se encuentre en uso
actualmente.
De igual modo que ocurría con la opción del
contenido, cada uno de los dos sentidos de comunicación de la
conexión TCP puede emplear esta opción de forma independiente.
El equipo que notifica la intercepción de la
conexión haciendo uso de esta opción TCP, asumirá las funciones de
intercepción de la conexión, descritas posteriormente (5.4). El
equipo que recibe la notificación de la interceptación, deberá
gestionar la situación en su pila de red del siguiente modo:
- -
- Se continuará con el proceso de confirmaciones (ACKs) como si estuviera realizando la transmisión de información él mismo. Por tanto, el flujo de estas confirmaciones deberá continuar transmitiéndose hasta el servidor origen de la comunicación interceptada.
- -
- De cara a la aplicación que hace uso de la conexión TCP, la interrupción del envío del contenido debe hacerse de forma transparente para ella. Los envíos de información (hasta la longitud identificada del contenido) entre la aplicación y el destino no se realizarán, pero las llamadas que la aplicación ejecute para su realización, se bloquearán hasta la recepción de las confirmaciones (ACKs) correspondientes al envío realizado.
- -
- Durante el intervalo de tiempo que permanezca suspendido el envío de información hacia el destino (porque se entiende que se trataría del contenido especificado y que no debe hacerse), las confirmaciones (ACKs) que debieran enviarse para confirmar el sentido opuesto de la comunicación se acumularán en segmentos vacíos tal y como define TCP para los casos en los que no hay comunicación con el sentido opuesto.
Este comportamiento ante la recepción de un
segmento TCP con una opción de intercepción, deberán replicarlo el
servidor de contenido y también todos los servidores caché
intermedios, para permitir el correcto funcionamiento ante la
situación en la que aparecen varios servidores caché entre el
servidor de contenido y el cliente.
Los servicios de red que exponga el protocolo de
transporte (en el caso de aplicación propuesto, el protocolo TCP)
al servidor de contenidos deben facilitar el marcado de los
segmentos con el contenido identificado, mediante las opciones
descritas anteriormente. Para ello se proponen los cambios
descritos a continuación sobre la interfaz de llamadas al sistema
del protocolo de transporte.
\vskip1.000000\baselineskip
Tras la creación de un socket dedicado a
conexiones TCP pero con anterioridad al establecimiento de dicha
conexión, se debe establecer si el socket permite o no el envío de
contenidos marcados. Para ello, se define una opción que será
establecida a través de la primitiva:
-
100
Se ha escogido como identificador único para la
opción el valor decimal 14, pero puede ser sustituido por cualquier
otro válido y que no se encuentre en uso actualmente.
Una vez establecida esta opción, su efecto se
verá en las siguientes situaciones:
- -
- Si la aplicación inicia el establecimiento de una conexión, a través de la primitiva CONNECT, en el primer paquete que envíe para este establecimiento (con el bit SYN activado), incluirá la opción de establecimiento descrita en 5.2.1.
- -
- Si la aplicación se prepara para recibir conexiones entrantes, a través de la primitiva ACCEPT, en el primer paquete que envíe para este establecimiento (con los bits SYN+ACK activados en respuesta), incluirá la opción de establecimiento descrita en 5.2.1.
\vskip1.000000\baselineskip
En el contexto de una conexión que se ha
habilitado para la transmisión de contenidos, se debe facilitar una
primitiva que permita el marcado de estos contenidos. Se propone la
siguiente primitiva:
-
101
Se ha escogido como identificador único para la
opción el valor decimal 15, pero puede ser sustituido por cualquier
otro válido y que no se encuentre en uso actualmente.
La definición de la estructura de contenidos TCP
es la siguiente:
-
102
El funcionamiento proporcionado a las
aplicaciones que hacen uso de esta primitiva debe ser el
siguiente:
- -
- La aplicación realiza la llamada anterior para el establecimiento de la opción.
- -
- La aplicación comienza el envío de la información asociada al contenido identificado, mediante la primitiva SEND. Los segmentos TCP enviados incluirán las opciones descritas en 5.2.2.
- Este funcionamiento deberá mantenerse para todas las llamadas SEND que se produzcan hasta que se envíe la cantidad de información indicada en el campo ContentSize de la estructura anterior.
- -
- El comportamiento se ve modificado en aquellos casos en los que, durante el envío de contenidos identificados, se recibe un segmento TCP con la opción descrita en 5.2.3. En ese caso, el comportamiento ante la primitiva SEND deberá ser el siguiente:
- \circ
- La información indicada en la primitiva SEND correspondiente al contenido identificado, no se enviará.
- \circ
- El bloqueo en las llamadas a la primitiva SEND se sincronizará con la recepción de las confirmaciones (ACKs) desde el servidor intermedio, como si realmente se hubiera enviado la información.
\vskip1.000000\baselineskip
El comportamiento del servidor caché intermedio
que realice la intercepción de una conexión se puede describir en
dos fases:
- -
- Fase de almacenamiento. Se cachean aquellos contenidos identificados que se deseen, operando de forma transparente para ambos extremos de la conexión. En estas condiciones, cuando se detecte un segmento que identifica un contenido determinado, y en función de los mecanismos que se quieran emplear para la determinación de los contenidos que deben cachearse, el servidor podrá decidir almacenar el contenido en caché. Esto le permitirá servirlo a los peticionarios en futuras conexiones.
- El cacheado de los contenidos por parte del servidor deberá comprobar, una vez finalizada la transmisión de los mismos, que el resumen SHA-1 del contenido almacenado se corresponde con el indicado en las opciones TCP transmitidas por el origen.
- -
- Fase de intercepción. Se intercepta la conexión que transfiere un contenido identificado, comunicando la situación al origen de dicho contenido y operando de forma transparente para el destino de la información.
- Se transfiere el contenido interceptado desde el servidor intermedio al destino de la información, empleando como dirección origen la dirección del origen inicial de la información, y asumiendo los números de secuencia TCP de la transferencia original.
- La intercepción incluye el proceso de las confirmaciones (ACKs) de la transferencia para reenviar aquellos segmentos que puedan tener problemas en la transferencia. Conviene recalcar, no obstante, que será necesario que el servidor intermedio procese estas confirmaciones (ACKs) aunque no irán dirigidas a él, sino al origen inicial de la información, cuya dirección se incluirá en los paquetes.
- Para la exposición a continuación de la intercepción de la transmisión de un contenido, en el contexto de una conexión TCP establecida entre un origen y un destino determinados, se referenciarán los datos del datagrama IP a partir del que se intercepta la conexión original con la siguiente nomenclatura:
- \circ
- Dirección IP origen: IPA
- \circ
- Dirección IP destino: IPB
- \circ
- Time To Live (TTL): TTLToB
- \circ
- Puerto TCP origen: TCPPortA
- \circ
- Puerto TCP destino: TCPPortB
- \circ
- Número de secuencia TCP origen: TCPSeqA
- \circ
- Número de confirmación (ACK) TCP origen: TCPAckA
- \circ
- Ventana anunciada TCP origen: TCPWindowA
\vskip1.000000\baselineskip
El segmento TCP que el servidor intermedio envía
al origen de los contenidos para notificar la interceptación de los
contenidos contendrá los siguientes valores:
- -
- Dirección IP origen: IPB
- -
- Dirección IP destino: IPA
- -
- Resto de los campos IP por defecto
- -
- Puerto TCP origen: TCPPortB
- -
- Puerto TCP destino: TCPPortA
- -
- Número de secuencia TCP: TCPAckA
- -
- Número de confirmación (ACK) TCP: TCPSeqA o posterior
- -
- Ventana TCP: 0
\vskip1.000000\baselineskip
Las direcciones IP y los puertos TCP indicados
en este segmento TCP permitirán que la pila de red del extremo
origen de los contenidos reconozca el segmento y lo asocie a la
conexión correspondiente. Este segmento TCP no contendrá datos,
únicamente la cabecera con la opción especificada.
\vskip1.000000\baselineskip
Los segmentos con el contenido interceptado por
el servidor caché de contenidos que se transferirán hasta el
destino serán emitidos desde este servidor intermedio. Estos
segmentos incluirán los datos correspondientes al contenido desde el
último segmento enviado desde el origen (sin incluir el contenido
de éste). Las cabeceras de estos segmentos contendrán los
siguientes valores:
- -
- Dirección IP origen: IPA
- -
- Dirección IP destino: IPB
- -
- Time To Live (TTL): TTLToB
- -
- Resto de los campos IP por defecto
- -
- Puerto TCP origen: TCPPortA
- -
- Puerto TCP destino: TCPPortB
- -
- Número de secuencia TCP: Contendrá los valores correspondientes al contenido transferido, partiendo desde el valor TCPSeqA + longitud del segmento origen de la interceptación.
- Este campo deberá contener, en definitiva, los mismos valores secuenciales que contendría si el contenido lo transfiriera el origen real, para permitir que el flujo de los ACKs sea válido para éste.
- -
- Número de confirmación (ACK) TCP: TCPAckA, o si existe, el último valor escuchado para el campo ACK TCP en esta conexión, en el sentido desde el servidor de contenidos al cliente
- -
- Ventana TCP: TCPWindowA, o si existe, el último valor escuchado para el campo ventana TCP en esta conexión, en el sentido desde el servidor de contenidos al cliente.
\vskip1.000000\baselineskip
En los dos últimos campos mostrados, se
manifiesta la intención de mantener actualizada la transferencia de
información interceptada para permitir un flujo bidireccional en la
conexión. El servidor intermedio deberá, aún tras haber efectuado la
intercepción de la comunicación, escuchar el tráfico con
información de control que el servidor origen envíe al cliente
destino. Esto permitirá que los valores de los campos de
confirmación (ACK) y ventana de recepción permanezcan actualizados
en el servidor intermedio.
\vskip1.000000\baselineskip
El uso de los mecanismos de marcado e
identificación de contenido expuestos puede integrarse en las
aplicaciones y en el propio hardware de los sistemas que forman las
redes de comunicaciones.
El establecimiento de dichos mecanismos en las
redes de comunicaciones permitiría a su vez la creación y el
despliegue de servidores de caché intermedios que, haciendo uso de
los mecanismos de intercepción expuestos, puedan proporcionar los
contenidos almacenados en caché a los clientes.
El mecanismo descrito posee ciertas ventajas
sobre los descritos en el apartado 2, donde se describía el estado
actual de la técnica:
- -
- No es necesario emplear ningún mecanismo dependiente del protocolo de aplicación para el marcado de los contenidos. El uso de la solución descrita para el protocolo TCP resulta en un ejemplo de ello.
- -
- El marcado de los contenidos depende de estos mismos contenidos, de modo que cuando se actualiza un contenido, al tener una marca diferente, no es necesario ningún mecanismo de renovación de cachés. El mecanismo de marcado propuesto basado en SHA-1, proporciona la actualización de las cachés ante la renovación de los contenidos.
- -
- El uso de una opción del protocolo de transporte para el marcado de los contenidos permite aprovechar las características de control de flujo y gestión de conexiones del mismo para el propio cacheado de los contenidos.
- -
- La interceptación de la transmisión de los contenidos por parte del servidor intermedio, que implica la existencia de una comunicación previa con el servidor origen, permite un funcionamiento extremo a extremo para el comienzo de la comunicación: únicamente se produce la intercepción una vez que el servidor de contenido ha iniciado la transmisión de un contenido cacheable al destino. Esto permite por tanto que se cumplan los requisitos de comunicación extremo a extremo que rigen las comunicaciones TCP/IP.
- -
- El mantenimiento del flujo de confirmaciones entre el cliente y el servidor de contenidos, a pesar de existir un servidor intermedio, permite que el control de flujo entre el servidor caché intermedio y el cliente sea el que controle los bloqueos en las aplicaciones del servidor de contenido. Por ello, aunque la transmisión de contenidos haya sido interceptada, hasta que no finalice la transmisión de contenidos por parte del servidor intermedio, el servidor de contenido no devolverá el bloqueo de las llamadas SEND hasta que no se hayan recibido todas las confirmaciones de los datos que debían enviarse. El uso del protocolo TCP de este modo, conserva la característica de que se trata de un protocolo confiable, que asegura la entrega de datos, aunque se dispongan servidores caché intermedios.
Claims (4)
1. Mecanismo de marcado e identificación en el
nivel de transporte para la gestión de cachés de contenidos,
caracterizado porque comprende la definición del siguiente
conjunto no separable de opciones adicionales en el protocolo
TCP:
- a)
- La definición de una opción en el nivel de transporte TCP que posibilita el marcado de los contenidos transportados en un segmento de dicha conexión. Dicha opción contiene un identificador único del contenido, su longitud y el desplazamiento del segmento transmitido sobre el contenido.
- b)
- La definición de una opción en el nivel de transporte TCP que posibilita la intercepción del envío de contenidos "cacheables" para ser procesada por el servidor origen que soporta dicha funcionalidad. Dicha opción contiene el identificador único del contenido, su longitud y la dirección IP del servidor intermedio que intercepta la conexión.
2. Mecanismo de marcada e identificación en el
nivel de transporte para la gestión de cachés de contenidos, según
reivindicación 1, caracterizado por la definición de una
opción en el nivel de transporte TCP que notifica, durante el
establecimiento de la conexión, la posibilidad del marcado de
contenidos con las opciones descritas en la reivindicación 1 en
cada uno de los sentidos de la conexión.
3. Mecanismo de marcado e identificación en el
nivel de transporte para la gestión de cachés de contenidos, según
reivindicaciones 1 y 2, que comprende la definición de las
siguientes primitivas de servicio que los sistemas operativos
pondrán a disposición de las aplicaciones que hagan uso del
protocolo TCP y de este mecanismo de caché:
- a)
- La definición de una primitiva de servicio que posibilita la prestación de los servicios definidos en la reivindicación 2) a las aplicaciones que hacen uso del protocolo TCP. Esta primitiva especifica que será necesaria una llamada al sistema antes de establecer la conexión TCP para habilitar el envío de contenidos marcados sobre la misma.
- b)
- La definición de una primitiva de servicio que posibilita el marcado de los contenidos definidos en la reivindicación 1.a) a las aplicaciones que hacen uso del protocolo TCP. Esta primitiva establece que será necesaria una llamada al sistema antes de enviar los datos que se marcarán sobre la conexión TCP. En esta llamada deberá notificarse la longitud y el identificador único del contenido.
4. Mecanismo de marcado e identificación en el
nivel de transporte para la gestión de cachés de contenidos según
reivindicaciones 1, 2 y 3, que comprende la definición del
siguiente modelo de operación:
- a)
- Definición de un modelo de intercepción de conexiones TCP para los servidores intermedios basado en el siguiente conjunto no separable de acciones:
- \sqbullet
- La comunicación del evento de intercepción desde el servidor intermedio al servidor origen de la comunicación, mediante el envío de la opción descrita en la reivindicación 1.b).
- \sqbullet
- El envío de la información desde el servidor intermedio al destino de la información suplantando la identidad del servidor origen.
- \sqbullet
- La interrupción del envío de información desde el servidor origen una vez recibida la notificación de intercepción de la conexión.
- \sqbullet
- La no interrupción de la recepción y el procesamiento de las confirmaciones en el servidor origen, incluyendo el envío de confirmaciones (ACKs).
- \sqbullet
- La escucha y procesamiento de los paquetes de confirmación (ACKs) en el servidor intermedio, tanto enviados desde el servidor origen corno confirmados desde el destino.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| ES200601958A ES2318978B2 (es) | 2006-07-24 | 2006-07-24 | Mecanismos de marcado e identificacion en el nivel de transporte para la gestion de caches de contenidos. |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| ES200601958A ES2318978B2 (es) | 2006-07-24 | 2006-07-24 | Mecanismos de marcado e identificacion en el nivel de transporte para la gestion de caches de contenidos. |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| ES2318978A1 ES2318978A1 (es) | 2009-05-01 |
| ES2318978B2 true ES2318978B2 (es) | 2009-10-07 |
Family
ID=40560355
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES200601958A Active ES2318978B2 (es) | 2006-07-24 | 2006-07-24 | Mecanismos de marcado e identificacion en el nivel de transporte para la gestion de caches de contenidos. |
Country Status (1)
| Country | Link |
|---|---|
| ES (1) | ES2318978B2 (es) |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6606650B2 (en) * | 1999-08-30 | 2003-08-12 | Nortel Networks Limited | Bump in the wire transparent internet protocol |
| US20030093463A1 (en) * | 2001-11-13 | 2003-05-15 | Graf Eric S. | Dynamic distribution and network storage system |
| EP1721438B1 (en) * | 2004-03-02 | 2010-09-08 | Divinetworks Ltd. | Server, method and system for caching data streams |
| US7711799B2 (en) * | 2004-11-22 | 2010-05-04 | Alcatel-Lucent Usa Inc. | Method and apparatus for pre-packetized caching for network servers |
-
2006
- 2006-07-24 ES ES200601958A patent/ES2318978B2/es active Active
Non-Patent Citations (1)
| Title |
|---|
| SPRING et al. "{}A protocol-independent technique for eliminating redundant network traffic"{}. ACM SIGCOMM Computer Communication Review, 2000, Volumen 30, Issue 4 (Octubre 2000), ISSN 0146-4833, páginas 87-95. Todo el documento. * |
Also Published As
| Publication number | Publication date |
|---|---|
| ES2318978A1 (es) | 2009-05-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10291552B2 (en) | Method for providing an information centric network with a software defined network and controller of the software defined network | |
| JP3906204B2 (ja) | コンピューティング装置、コンピューティング装置とリモート・コンピュータ・システムとの間でデータを通信する方法 | |
| EP1593254B1 (en) | Methods and apparatus for traffic management in peer-to.peer networks | |
| US20150281367A1 (en) | Multipath tcp techniques for distributed computing systems | |
| US10158570B2 (en) | Carrying TCP over an ICN network | |
| US10439925B2 (en) | Sandbox environment for testing integration between a content provider origin and a content delivery network | |
| US20050229243A1 (en) | Method and system for providing Web browsing through a firewall in a peer to peer network | |
| US20050117558A1 (en) | Method for reducing data transport volume in data networks | |
| ES2845904T3 (es) | Procedimiento y aparato para procesamiento de datos en clúster | |
| US6731598B1 (en) | Virtual IP framework and interfacing method | |
| US11425086B2 (en) | Using DNS to communicate MC-TCP capability of server devices | |
| US20180034889A1 (en) | System and method for content retrieval from remote network regions | |
| EP2938046A1 (en) | Method for providing content to communication equipment via a mobile backhaul with an information-centric network (ICN) deployed as an overlay over IP and in-network caches | |
| EA018130B1 (ru) | Способ выборочного перехвата сеанса | |
| Kühlewind et al. | Applicability of the QUIC transport protocol | |
| US7660906B1 (en) | Data delivery system and method | |
| WO2017097092A1 (zh) | 缓存集群服务的处理方法及系统 | |
| ES2410654B1 (es) | Sistema y método para gestionar la infraestructura de un servicio de red de distribución de contenido en una red isp | |
| BR102013015341A2 (pt) | Sistema e método para identificação e monitoramento de navegador baseado em cookie | |
| RU2272363C2 (ru) | Устройство, способ и система для усовершенствованной маршрутизации в сети мобильного ip | |
| ES2283428T3 (es) | Dispositivo, metodo y sistema para un encaminamiento mejorado en redes ip movil. | |
| ES2318978B2 (es) | Mecanismos de marcado e identificacion en el nivel de transporte para la gestion de caches de contenidos. | |
| US10361997B2 (en) | Auto discovery between proxies in an IPv6 network | |
| US9578125B2 (en) | Systems, devices, and methods for protecting access privacy of cached content | |
| ES2770652T3 (es) | Sistema y método para interconexión de redes de distribución de contenido |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EC2A | Search report published |
Date of ref document: 20090501 Kind code of ref document: A1 |
|
| FG2A | Definitive protection |
Ref document number: 2318978B2 Country of ref document: ES |