ES2425626B1 - Método para la resolución de dns de peticiones de contenido en un servicio cdn - Google Patents

Método para la resolución de dns de peticiones de contenido en un servicio cdn Download PDF

Info

Publication number
ES2425626B1
ES2425626B1 ES201130754A ES201130754A ES2425626B1 ES 2425626 B1 ES2425626 B1 ES 2425626B1 ES 201130754 A ES201130754 A ES 201130754A ES 201130754 A ES201130754 A ES 201130754A ES 2425626 B1 ES2425626 B1 ES 2425626B1
Authority
ES
Spain
Prior art keywords
dns
region
content
request
end user
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.)
Withdrawn - After Issue
Application number
ES201130754A
Other languages
English (en)
Other versions
ES2425626A2 (es
ES2425626R1 (es
Inventor
Parminder Chhabra
Armando Antonio GARCIA MENDOZA
Carmelo ACOSTA OJEDA
Pablo Rodriguez Rodriguez
Alvaro SAURÍN PARRA
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
Priority to ES201130754A priority Critical patent/ES2425626B1/es
Application filed by Telefonica SA filed Critical Telefonica SA
Priority to PCT/EP2012/058395 priority patent/WO2012152765A1/en
Priority to ES12725641.0T priority patent/ES2550674T3/es
Priority to US14/117,191 priority patent/US9565157B2/en
Priority to EP12725641.0A priority patent/EP2708013B1/en
Priority to BR112013029001-3A priority patent/BR112013029001B1/pt
Priority to ARP120101646A priority patent/AR086336A1/es
Publication of ES2425626A2 publication Critical patent/ES2425626A2/es
Publication of ES2425626R1 publication Critical patent/ES2425626R1/es
Priority to CL2013003221A priority patent/CL2013003221A1/es
Application granted granted Critical
Publication of ES2425626B1 publication Critical patent/ES2425626B1/es
Withdrawn - After Issue legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40Support for services or applications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/45Network directories; Name-to-address mapping
    • H04L61/4505Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/45Network directories; Name-to-address mapping
    • H04L61/4552Lookup mechanisms between a plurality of directories; Synchronisation of directories, e.g. metadirectories
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004Server selection for load balancing
    • H04L67/1023Server selection for load balancing based on a hash applied to IP addresses or costs
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/563Data redirection of data network streams
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00Indexing scheme associated with group H04L61/00
    • H04L2101/60Types of network addresses
    • H04L2101/69Types of network addresses using geographic information, e.g. room number
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Método para la resolución de DNS de peticiones de contenido en un servicio CDN.#Comprende identificar un nodo de extremo o servidor de contenido que puede dar servicio de la mejor manera a un usuario final que envía una petición de DNS a un sistema de resolución de DNS de ISP, dada una red geográficamente distribuida de nodos de extremo. En particular, el método comprende además usar los propios nodos de extremo y un rastreador para identificar y notificar al usuario final las direcciones IP de los nodos de extremo menos cargados y más próximos que pueden proporcionar de la mejor manera la petición de contenido.

Description

Método para la resolución de DNS de peticiones de contenido en un servicio CDN.
Campo de la técnica
La presente invención se refiere en general a un método para la resolución de DNS de peticiones de contenido en un servicio CDN, que comprende identificar un nodo de extremo o servidor de contenido que puede dar servicio de la mejor manera a un usuario final, y más particularmente a un método en el que los propios nodos de extremo colaboran en dicha resolución de DNS.
Estado de la técnica anterior
A continuación, se incluyen la terminología y las definiciones que pueden ser útiles para entender la presente invención.
PoP: Un punto de presencia es una demarcación artificial o punto de interfaz entre dos entidades de comunicación. Es un punto de acceso a Internet que aloja servidores, conmutadores, encaminadores y agregadores de llamadas. Los ISP normalmente tienen múltiples PoP.
Sistema autónomo (AS): Un sistema autónomo es una recopilación de prefijos de encaminamiento de IP que están bajo el control de uno o más operadores de red y presenta una política de encaminamiento común, claramente definida, para Internet.
OB (operating business, unidad de negocio): Una OB es un área geográfica arbitraria en la que está instalada la CDN del proveedor de servicios. Una OB puede operar en más de una región. Una región es un área geográfica arbitraria y puede representar un país, o parte de un país o incluso un conjunto de países. Una OB puede estar compuesta por más de una región. Una OB puede estar compuesta por uno o más ISP. Una OB tiene exactamente una instancia de servidor de topología.
PID (partition ID, ID de partición): Esto es meramente una correlación de prefijos de IP a nivel de AS con números enteros. Se trata de una correlación uno a uno. Es una partición muy basta de prefijos de IP.
DNS (servicio de nombres de dominio): DNS es un servicio que traduce nombres de dominio en direcciones IP. La resolución de DNS es jerárquica. Si un servidor DNS no sabe cómo traducir un nombre de dominio, pregunta a otros servidores DNS comenzando con el servidor DNS raíz hasta que encuentra el servidor DNS que puede resolver el nombre de dominio.
Red de distribución de contenido (CDN): Esto se refiere a un sistema de nodos (u ordenadores) que contienen copias de contenido de cliente que está almacenado y situado en diversos puntos en una red (o Internet pública). Cuando se replica contenido en diversos puntos en la red, el ancho de banda se utiliza mejor a lo largo de la red y los usuarios tienen tiempos de acceso más rápidos al contenido. De este modo, el servidor original que contiene la copia original del contenido no experimenta atascos.
Redirección de DNS: Esto es la práctica de redireccionar la resolución de los nombres del sistema de nombres de dominio a otros servidores DNS. En una CDN, esta práctica se usa para dirigir peticiones de usuario final a nodos de extremo que están en estrecha proximidad a los usuarios finales solicitantes.
Sistema de resolución de DNS de ISP: Los usuarios residenciales se conectan a un ISP. Cualquier petición para resolver una dirección se envía a un sistema de resolución de DNS mantenido por el ISP. El sistema de resolución de DNS de ISP enviará la petición de DNS a uno o más servidores DNS dentro del dominio administrativo del ISP.
URL: En términos sencillos, el localizador uniforme de recursos (URL) es la dirección de una página web en la world wide web. No hay dos URL idénticos. Si son idénticos, apuntan al mismo recurso.
Redirección URL (o HTTP): La redirección URL también se conoce como reenvío URL. Una página puede necesitar una redirección si su nombre de dominio ha cambiado, creando alias significativos para URL largos o que cambian con frecuencia, errores tipográficos del usuario al escribir un nombre de dominio, si se manipula a los visitantes, etc. Para los fines de la presente invención, un servicio de redirección típico es uno que redirecciona a los usuarios al contenido deseado. Un enlace de redirección puede usarse como dirección permanente para contenido que cambia frecuentemente de anfitrión (host) (casi como de DNS).
Contenedor: Un contenedor es un recipiente lógico para un cliente que contiene el contenido de cliente CDN. Un contenedor o bien establece un enlace entre el URL del servidor original y el URL de la CDN o bien puede contener el propio contenido (que se carga en el contenedor en el punto de entrada). Un nodo de extremo replicará
ES 2 425 626 A2
archivos desde el servidor original a archivos en el contenedor. Cada archivo en un contenedor puede correlacionarse exactamente con un archivo en el servidor original. Un contenedor tiene varios atributos asociados con él (el tiempo desde y el tiempo hasta que el contenido es válido, geobloqueo de contenido, etc.). También se utilizan mecanismos para garantizar que se transmitan automáticamente nuevas versiones del contenido en el servidor original al contenedor en los nodos de extremo y se eliminen versiones antiguas.
Un cliente CDN de proveedor de servicios puede crear tantos contenedores como desee. Un contenedor es realmente un directorio que contiene archivos de contenido. Un contenedor puede contener subdirectorios y archivos de contenido dentro de cada uno de los subdirectorios.
Geolocalización: Es la identificación de ubicaciones geográficas reales de un dispositivo conectado a Internet. El dispositivo puede ser un ordenador, dispositivo móvil o un aparato que permita la conexión a Internet para un usuario final. Los datos de geolocalización de la dirección IP pueden incluir información tal como país, región, ciudad, código postal, latitud/longitud de un usuario.
Aplicación de función hash (hashing) consistente: Este método proporciona la funcionalidad de una tabla hash de modo que la adición o eliminación de una ranura no altera significativamente la correlación de llaves con ranuras. La aplicación de función hash consistente es un modo de distribuir peticiones entre una población grande y cambiante de servidores web. La adición o eliminación de un servidor web no altera significativamente la carga en los otros servidores.
MD5: En criptografía, MD5 es una función criptográfica ampliamente usada con un valor de hash de 128 bits. MD5 se usa ampliamente para probar la integridad de los archivos. MD5 se expresa normalmente como un número hexadecimal.
DSLAM: Un DSLAM es un dispositivo de red que reside en un intercambio telefónico de un proveedor de servicios. Conecta múltiples líneas de abonado digitales (DSL) de cliente a una red principal de Internet de alta velocidad usando multiplexación. Esto permite que las líneas telefónicas realicen una conexión más rápida a Internet. Normalmente, un DSLAM da servicio a varios cientos de residentes (como máximo no más de a algunos miles de residentes).
Por otro lado, DNS es un convenio de nomenclatura jerárquico para ordenadores, servicios o cualquier recurso conectado a Internet [1]. El sistema de nombres de dominio distribuye la responsabilidad de asignar nombres de dominio a grupos de usuarios y organizaciones independientemente de su ubicación física de una manera significativa. Lo hace designando servidores de nombres autorizados para cada dominio (por ejemplo, com, edu, net, etc.). Estos servidores de nombres autorizados pueden designar otros servidores autorizados para sus subdominios [1]. Esto hace tanto que los DNS estén distribuidos como que sean tolerantes a defectos.
Otra funcionalidad clave de DNS es que traduce nombres de anfitrión de ordenador sencillos en direcciones IP. Cualquier servicio CDN usa DNS como manera de localizar sus servidores de contenido en respuesta a peticiones de usuario final. DNS tiene sus limitaciones al diseñar una solución de distribución de contenido ya que, de manera ideal, la infraestructura CDN tiene que identificar el servidor de contenido que está más próximo al usuario final y no está muy cargado.
El principal inconveniente es que la aplicación de función hash consistente se usa comúnmente como una manera de distribuir contenido entre máquinas en un centro de datos. La aplicación de función hash consistente, al igual que la aplicación de función hash naïve, extiende un diccionario distribuido de manera bastante uniforme a lo largo de un grupo. Sin embargo, al contrario que la aplicación de función hash naïve, la aplicación de función hash consistente sólo requiere mover una pequeña cantidad de datos en el caso de añadir / retirar máquinas de un grupo [1][7][8].
Localizar el servidor de contenido más próximo y menos cargado para un usuario final solicitante para entregar contenido es un problema bien conocido. Soluciones típicas incluyen usar una jerarquía de servidores DNS junto con una geobase de datos de IP para identificar al servidor de contenido más próximo (como en [1][2]) a un usuario final solicitante y usar ese servidor para entregar el contenido.
Por ejemplo, una empresa xyz.com que es un cliente de un proveedor CDN, Akamai puede resolverse como a123.g.akamai.net en el servidor de nombres del proveedor CDN. Por tanto, una consulta de akamai.net por el sistema de resolución de DNS de ISP devuelve una dirección IP para el dominio de nivel superior (TLD) de akamai.net. A continuación, una consulta de g.akamai.net devuelve una IP para el servidor DNS de segundo nivel más próximo al sistema de resolución de DNS de ISP del usuario final. Entonces, el sistema de resolución de DNS de ISP consulta a123.g.akamai.net. Esta consulta devuelve la dirección IP del servidor de contenido que puede proporcionar el contenido solicitado al usuario final. La resolución de DNS consiste en dos etapas. En la primera etapa, el servidor DNS de TLD identifica la región o el país al que pertenece el sistema de resolución de DNS de ISP. Devuelve la dirección IP del servidor DNS más próximo (DNS de segundo nivel). La segunda petición de DNS
3
ES 2 425 626 A2
(al servidor DNS de dominio de segundo nivel) identifica el nodo de extremo (o servidor de contenido) que puede proporcionar de la mejor manera el contenido solicitado. Esta solución CDN puede desplegarse profundamente dentro de una red ISP. El proveedor de servicios CDN puede estar limitado por la profundidad en la red a la que un ISP está dispuesto a permitir que se despliegue un sistema de este tipo (y puede estar limitado al despliegue en los puntos de intercambio de tráfico directo (peering) o dentro de un AS o en una o dos ubicaciones en un país). Por tanto, el contenido puede tener que pasar a través de varios saltos dentro del país antes de alcanzar al usuario final solicitante.
Otras soluciones como [1][3] se basan en un pequeño número de grandes centros de datos o [1][6] un gran número de pequeños centros de datos conectados mediante una red privada bien provista para identificar en primer lugar un centro de datos que está más próximo al usuario final solicitante. Una vez identificado el centro de datos, se identifica un nodo de extremo en el centro de datos para entregar el contenido. Ya que estos centros de datos se conectan a Internet en un número pequeño de puntos de intercambio directo de tráfico, el contenido todavía tiene que pasar a través de varios saltos antes de alcanzar a un usuario final solicitante. Además, [5] se basa en una infraestructura de almacenamiento extensivo y de almacenamiento en caché en los puntos de intercambio directo de tráfico principales. Amazon [4] proporciona servicio CDN usando Amazon Cloudfront junto con su servicio de almacenamiento sencillo permitiendo a los usuarios finales obtener datos de diversas ubicaciones de borde de Internet con las que Amazon intercambia tráfico directamente.
Entre las soluciones anteriores, [2] y [3] se basan estrictamente en una jerarquía de servidores DNS para identificar el nodo de extremo que puede proporcionar contenido a un usuario final solicitante. Sin embargo, Limelight se diferencia de Akamai en que permite a sus clientes usar directamente nombres de anfitrión de Limelight en sus sitios web. Por ejemplo en [1][9], Amazon incrusta directamente los subnombres de anfitrión de Limelight de la forma amazon-xxx.vo.llnwd.net (xxx es un número entero). El contenedor amazon-xxx (que contiene el contenido de Amazon) puede replicarse en diferentes nodos dentro del mismo centro de datos y en múltiples centros de datos en la red de Limelight. Las otras soluciones ([4] - [6] tal como se comentaron anteriormente) usan una combinación de DNS y redirección para identificar el servidor de contenido. La redirección puede adoptar la forma o bien de redirección DNS o bien de redirección HTTP. En el primer caso, supone redireccionar la petición de DNS a otros servidores DNS. En el segundo caso, se envía una nueva dirección de redirección como parte de la respuesta HTTP.
Todas las soluciones comentadas hasta el momento ([2] y [3]-[6]) para identificar el nodo de extremo para proporcionar contenido usan equilibradores de carga de hardware para equilibrar la carga de DNS en el DNS de segundo nivel. Además, en dichas soluciones los nodos de extremo no participan en el proceso de identificar el nodo de extremo que está mejor ubicado para entregar contenido.
Por tanto, todas las soluciones mencionadas tienen los inconvenientes o las limitaciones de DNS de no permitir identificar rápidamente el nodo de extremo (o servidor de contenido) que puede dar servicio de la mejor manera a un usuario final dada una red geográficamente distribuida de nodos de extremo.
Descripción de la invención
Es necesario ofrecer una alternativa al estado de la técnica que cubra las lagunas encontradas en la misma, particularmente se superan las relacionadas con las limitaciones de DNS de identificar rápidamente el nodo de extremo (o servidor de contenido) que puede dar servicio de la mejor manera a un usuario final dada una red geográficamente distribuida de nodos de extremo.
Con ese fin, la presente invención se refiere a un método para la resolución de DNS de peticiones de contenido en un servicio CDN, que comprende identificar un nodo de extremo o servidor de contenido que puede dar servicio de la mejor manera a un usuario final que ha enviado una petición de DNS a un sistema de resolución de DNS de ISP, dada una red geográficamente distribuida de nodos de extremo.
De manera diferente a las propuestas convencionales, en el método de la invención la resolución de DNS se lleva a cabo, de manera característica, realizando:
I) una fase de resolución de DNS, que comprende realizar las siguientes etapas:
a) enviar, dicho sistema de resolución de DNS de ISP, la petición de DNS recibida a un servidor DNS autorizado de una subzona, o bien conocida previamente o bien identificada enviando una petición al servidor DNS raíz del dominio solicitado;
b) reenviar, dicho servidor DNS autorizado de subzona una vez identificada, dicha petición de DNS al rastreador que funciona en dicha subzona, y reenviar, dicho rastreador, la petición de DNS a uno de dichos nodos de extremo que participan en dicha fase de resolución de DNS;
4
ES 2 425 626 A2
y
II) una redirección HTTP, que comprende realizar las siguientes etapas:
c) resolver, dicho nodo de extremo que participa en dicha fase de resolución de DNS, la ubicación del sistema de resolución de DNS de ISP mediante una base de datos de ID de partición para identificar:
-
el centro de datos que puede proporcionar de la mejor manera el contenido; o
-
al menos un nodo de extremo en el mismo centro de datos que puede proporcionar el contenido; y
d) realizar, dicho nodo de extremo que participa en dicha fase de resolución de DNS, una función hash consistente sobre el URL solicitado asociado con dicha petición de DNS, construir una dirección usando una subcadena de la función hash MD5 de petición de contenido y la ubicación de dicho centro de datos que puede proporcionar de la mejor manera el contenido o la ubicación de dicho al menos un nodo de extremo en el mismo centro de datos que puede proporcionar el contenido, y enviar dicha dirección al usuario final, directamente o a través de entidades intermedias, usando un mensaje de redirección.
Para una realización, el método de la invención se aplica a una resolución de DNS a través de sólo una región de una unidad de negocio (OB), dicha subzona es dicha región, dicha fase de resolución de DNS de I) es una primera fase de resolución de DNS, siendo dicho mensaje de redirección un mensaje de redirección HTTP, y comprendiendo el método además una segunda fase de resolución de DNS que comprende realizar las siguientes etapas:
e) realizar, el usuario final, una petición de resolución de dirección, para dicha dirección recibida, a dicho sistema de resolución de DNS de ISP;
f) reenviar, el servidor DNS de ISP, dicha petición de resolución de dirección a dicho servidor DNS autorizado de subzona;
g) identificar, el servidor DNS autorizado de subzona, al menos dicho centro de datos que puede proporcionar de la mejor manera el contenido indicado en dicha dirección y un rastreador que puede resolver la dirección recibida, y envía la petición de resolución de dirección a dicho rastreador;
h) realizar, dicho rastreador, una función hash consistente sobre dicha subcadena de la función hash de URL para obtener el nodo de extremo o nodos de extremo, dentro de dicho centro de datos, que pueden atender de la mejor manera la petición;
i) enviar, el rastreador, una respuesta que incluye la dirección de al menos uno de dichos nodos de extremo obtenidos al servidor DNS autorizado de subzona;
j) enviar, el servidor DNS autorizado de subzona, dicha respuesta de rastreador al sistema de resolución de DNS de ISP; y
k) enviar, el sistema de resolución de DNS de ISP, dicha respuesta de rastreador al usuario final.
Para una realización, dicha etapa h) comprende además identificar, el rastreador, el nodo de extremo menos cargado en dicho centro de datos más próximo, usando información sobre la carga actual en dichos nodos de extremo obtenidos, como el nodo de extremo que puede proporcionar de la mejor manera el contenido, e incluir sólo la dirección de dicho nodo de extremo menos cargado en dicha respuesta de rastreador enviada en la etapa i).
Mediante el método de la invención, el rastreador actúa como equilibrador de carga cuando se distribuye carga a nodos de extremo, participando este último en el proceso de identificar el nodo de extremo que está mejor ubicado para entregar contenido.
Una vez que el usuario final ha recibido la respuesta de rastreador, el método comprende, tras dicha etapa j), intentar, el usuario final, conectarse directamente a dicho nodo de extremo menos cargado cuya dirección se incluye en la respuesta de rastreador, enviando una petición de conexión al mismo, en forma de una dirección URL, incluyendo dicha dirección construida y un identificador del contenido solicitado.
Para una realización del método de la invención, dicha etapa b) comprende usar, dicho rastreador, al menos un esquema round-robin o un esquema de geolocalización de mejor esfuerzo para hacer coincidir la petición de DNS con el nodo de extremo que participa en dicha fase de resolución de DNS a partir de dichos nodos de extremo.
En lo que se refiere a la identificación previa del servidor DNS autorizado de dicha subzona mencionada anteriormente, dicha identificación se realiza, para una realización, mediante una geobúsqueda de IP.
5
ES 2 425 626 A2
Según una realización, dicha geobúsqueda de IP se lleva a cabo en un servidor DNS autorizado para un dominio de segundo nivel, tal como realizando las siguientes etapas:
-
consultar, dicho sistema de resolución de DNS de ISP, a un servidor DNS de dominio de nivel superior para resolver un dominio de segundo nivel de la dirección de dicha petición de DNS;
-
resolver, el servidor DNS de dominio de nivel superior, la consulta de DNS de ISP con la dirección IP de dicho servidor DNS autorizado para dicho dominio de segundo nivel;
-
consultar, el sistema de resolución de DNS de ISP, a dicho servidor DNS autorizado para dicho dominio de segundo nivel para resolver dicha petición de DNS; y
-
resolver, el servidor DNS autorizado para dicho dominio de segundo nivel, la subzona mediante dicha geobúsqueda de IP, y responder al sistema de resolución de DNS de ISP con la dirección de dicha subzona.
Para una realización, la respuesta de rastreador contiene una lista de direcciones de parte o la totalidad de los nodos de extremo incluidos en dicho centro de datos más próximo.
Dicha etapa h) comprende además, para una realización, identificar, el rastreador, nodos de extremo de reserva, fuera de dicho centro de datos más próximo, que pueden atender la petición si es necesario, conteniendo además dicha lista de dicha respuesta de rastreador direcciones de dichos nodos de extremo de reserva.
Dicho centro de datos más próximo es un centro de datos local, y dichos nodos de extremo de reserva pertenecen a centros de datos nacionales y/o globales, según una realización.
Para dichas realizaciones en las que la respuesta de rastreador incluye dicha lista de nodos de extremo, el método comprende, tras la etapa j), intentar, el usuario final, conectarse directamente a uno de los nodos de extremo del centro de datos más próximo, y si no puede conseguir el contenido a partir del mismo, intentar conectarse a uno de los nodos de extremo de reserva incluidos en dicha lista.
Otras realizaciones del método de la invención se describen con referencia a las reivindicaciones adjuntas 13 a 21, y en una sección posterior relacionada con la descripción detallada de varias realizaciones, incluyendo realizaciones referentes a redirecciones interregionales e intrarregionales en las que la segunda fase de resolución de DNS mencionada anteriormente se lleva a cabo mediante etapas diferentes de las descritas anteriormente para la realización relacionada con una resolución de DNS a través de sólo una región de una OB.
Breve descripción de los dibujos
Las ventajas y características anteriores y otras se entenderán más completamente a partir de la siguiente descripción detallada de realizaciones, con referencia a los dibujos adjuntos, que deben considerarse de una manera ilustrativa y no limitativa, en los que:
la figura 1 muestra la resolución de DNS del método de la invención, para una realización relacionada con una resolución de DNS a través de sólo una región de una OB. Una vez resuelta la DNS al servidor DNS autorizado para el subdominio “es”, el proceso de resolución de dirección conlleva dos búsquedas de DNS y una redirección HTTP;
la figura 2 muestra otra realización del método de la invención, para un escenario de ejemplo de resolución de DNS que supone una jerarquía de tres niveles de centros de datos;
la figura 3 muestra un anillo de función hash en donde se correlaciona contenido (URL) y recursos (máquinas) con un círculo unitario. El contenido luego se correlaciona con máquinas ejecutando un recorrido en sentido horario hasta que identificar los servidores primario, secundario y terciario;
la figura 4 muestra la resolución de DNS del método de la invención para una realización referente a una resolución de DNS con redirección interregional entre dos unidades de negocio,
la figura 5 muestra otra realización del método de la invención, para un escenario de ejemplo de resolución de DNS con redirección interregional entre dos regiones de la misma unidad de negocio; y
la figura 6 muestra la resolución de DNS del método de la invención para una realización referente a una resolución de DNS con redirección intrarregional entre centros de datos de la misma OB.
Descripción detallada de varias realizaciones
Ahora se describirá en detalle el funcionamiento del DNS de un proveedor de servicios CDN. Los servidores de contenido se encuentran normalmente en centros de datos que están dispuestos de manera jerárquica. En el
6
ES 2 425 626 A2
nivel inferior, un proveedor CDN proporciona contenido mediante centros de datos a nivel o bien de ciudad o bien de región (por ejemplo, un centro de datos en Madrid para dar servicio a todo Madrid, un centro de datos en Barcelona para dar servicio a toda Cataluña), a nivel de país (por ejemplo, un centro de datos en Madrid que actúa como reserva para todo el contenido en España) y finalmente a nivel global (por ejemplo, un centro de datos en Londres que actúa como reserva para todo el contenido para el proveedor de servicios CDN). Alternativamente, otro ejemplo de una jerarquía puede ser tal como sigue: para aproximarse más a los usuarios finales, un proveedor CDN puede desplegar nodos de extremo en las mismas instalaciones que alojan los DSLAM a nivel local, proporcionar contenido a partir de un centro de datos a nivel de país (por ejemplo, un centro de datos en Madrid que actúa como reserva a nivel nacional para el contenido proporcionado a partir de los DSLAM en España) y finalmente actuar, un centro de datos en Londres, como centro de datos global.
Si la infraestructura CDN no puede proporcionar contenido a partir de su centro de datos a nivel local, puede retroceder al centro de datos a nivel nacional. Si el centro de datos a nivel nacional no puede proporcionar el contenido solicitado, puede retroceder al centro de datos global para proporcionar el contenido. Un inconveniente de este enfoque es que el operario CDN experimentará un coste temporal para enviar datos desde un centro de datos global.
A continuación se describe cada componente del subsistema del proveedor de servicios CDN. La infraestructura consiste en servidores originales, rastreadores, nodos de extremo, servidor de topología, servidor DNS y punto de entrada.
Punto de publicación (punto de entrada): Cualquier cliente CDN puede interaccionar con la infraestructura del proveedor de servicios CDN únicamente a través del punto de publicación (también denominado a veces punto de entrada para mayor simplicidad). El punto de publicación ejecuta una interfaz de servicios web con usuarios de cuentas registradas para crear/borrar y actualizar contenedores.
Un cliente CDN tiene dos opciones para cargar contenido. El cliente puede o bien cargar archivos en el contenedor o bien dar los URL de los archivos de contenido que residen en el sitio web del cliente CDN. Una vez que la infraestructura CDN descarga el contenido, los archivos se mueven a otro directorio para su posprocesamiento. Las etapas de posprocesamiento implican comprobar la consistencia de los archivos y si hay algún error.
Nodo de extremo: Un nodo de extremo es la entidad que gestiona la comunicación entre usuarios finales y la infraestructura CDN. Esencialmente es un servidor HTTP personalizado.
Además, los nodos de extremo mantienen una geobase de datos de IP y una tabla de una lista de centros de datos.
Rastreador: El rastreador es la entidad clave que permite la inteligencia y coordinación de la infraestructura del proveedor de servicios CDN. Para ello, un rastreador mantiene (1) información detallada acerca del contenido en cada nodo de extremo y (2) recopila estadísticas de uso de recursos periódicamente de cada nodo de extremo. Mantiene información tal como el número de bytes salientes, número de bytes entrantes, número de conexiones activas para cada contenedor, tamaño del contenido proporcionado, etc.
Cuando un usuario final realiza una petición de contenido, el rastreador usa la información estadística a su disposición para determinar si (1) el contenido puede proporcionarse al usuario final solicitante y si es así, (2) determina el nodo de extremo más próximo y uno con la menor carga para dar servicio a un usuario final. Así, el rastreador actúa como equilibrador de carga para la infraestructura CDN.
Servidor original: Éste es el/los servidor(es) en la infraestructura del proveedor de servicios CDN que contiene(n) la copia maestra de los datos. Cualquier nodo de extremo que no tenga una copia de los datos puede solicitarla del servidor original. El cliente CDN no tiene acceso al servidor original. La infraestructura del proveedor de servicios CDN mueve los datos desde el punto de publicación al servidor original tras realizar comprobaciones de seguridad en los datos descargados.
Servidor de topología: La información sobre la topología de red de una OB se mantiene en su servidor de topología. La topología de red es realmente una matriz de costes a través de trayectorias de red. La matriz de costes se usa por la CDN en la elección de la trayectoria al entregar contenido al nodo de extremo.
Servidor DNS: El servidor DNS de TLD está autorizado para el espacio de nombre de la CDN del proveedor de servicios, t-cdn.net. Además, cada región en la CDN del proveedor de servicios tiene un servidor DNS que está autorizado para su región.
Divisor en tiempo real: Cuando el cliente crea un contenedor para un canal (o acontecimiento) en “tiempo real”, se pasa al divisor en tiempo real. El divisor en tiempo real sirve como servidor original para un flujo continuo en
7
ES 2 425 626 A2
tiempo real. El divisor en tiempo real se encarga de obtener un flujo continuo en tiempo real, dividir el flujo continuo en tiempo real recibido y usar un segmentador para crear una lista de reproducción. La lista de reproducción generada se envía a nodos de extremo que pueden proporcionar contenido en tiempo real.
Por otro lado, para la aplicación de la función hash consistente, para una realización del método de la invención, para identificar algunas máquinas o nodos de extremo, dada una clave (en este caso, MD5(URL) del recurso que necesita un usuario final), es necesario encontrar los servidores primario, secundario y terciario para el contenido solicitado.
Para ello, en primer lugar 1 se correlacionan recursos (servidores de contenido) con puntos en el círculo unitario (Figura 3). Si un servidor tiene el doble de almacenamiento que los otros, se crean dos recursos a partir de ese servidor y ambos se correlacionan con el círculo unitario. El siguiente procedimiento se usa para correlacionar servidores con un círculo unitario:
En el caso de disponer de N máquinas (1,…, N), si la función hash usada tiene un intervalo [0, R), el resultado de la función hash vuelve a ajustarse a escala mediante r -> h(r) / R de modo que la función hash se correlaciona con el intervalo [0,1), es decir, en un círculo unitario.
Seguidamente 2. Al igual que en (1.), se correlacionan URL de contenido con el mismo círculo unitario descrito anteriormente. Se usa una función hash que correlaciona números hexadecimales con números enteros. Posteriormente, el resultado de la función hash vuelve a ajustarse a escala como en (1.) con el mismo círculo unitario.
La infraestructura CDN aplica la función hash sobre el URL de contenido. Toma los primeros bytes de MD5 (URL) y los correlaciona con el círculo unitario. Se correlaciona el contenido con el servidor que está más próximo al mismo en el círculo unitario (el servidor primario). Correlacionando el contenido con más de un servidor, se crean los servidores secundario y terciario para el contenido solicitado.
Luego 3. se dispone la infraestructura CDN en una jerarquía de centros de datos, a nivel de ciudad (o región), nacional y global. Al realizar la correlación usando (2.), se identifican los servidores primario y secundario (y terciario) que almacenarán contenido en cada una de las jerarquías.
Finalmente 4. se asocian al menos dos servidores en el centro de datos primario que contienen la correlación entre contenido de cliente (URL) y los servidores de contenido (o nodos de extremo). Igualmente, se asocia el contenido con al menos un servidor en cada uno de los centros de datos secundario y terciario.
Hay varias maneras de correlacionar URL con máquinas: Comenzar con una correlación de URL en un círculo unitario y ejecutar un recorrido en sentido horario o antihorario en el círculo unitario. En cualquier caso, se detiene una vez que se encuentran máquinas en los centros de datos local, nacional y global que pueden proporcionar el contenido. Esto garantiza que máquinas en estrecha proximidad a los URL contendrán el contenido al que apuntan los URL. Otras técnicas incluyen el uso de una métrica basada en la distancia que correlaciona sólo las máquinas con el URL que están en la proximidad inmediata de la correlación de URL (o URL que se han correlacionado con el círculo unitario).
Tal como se muestra en la figura 3, url1, url2 y url3 son tres URL diferenciados de archivos de vídeo. Entonces se correlacionan los primeros bytes del MD5 de los URL con el círculo unitario.
BCN1, BCN2, BCN2, BCN3 y BCN4 son cuatro máquinas en el centro de datos de Barcelona. En este caso, la máquina BCN2 tiene el doble de memoria que BCN1, BCN3 y BCN4. Por tanto, se aplica la función hash sobre la máquina BCN2 dos veces en este anillo usando dirección_IP-1 y dirección_IP-2 para proporcionar BCN2-1 y BCN2
2. Todas las demás máquinas tienen un sufijo “-1” en su nombre (o dirección IP).
MAD1, MAD2 y MAD3 son tres máquinas en el centro de datos de Madrid. De manera similar, GLB1 y GLB2 son dos máquinas ejecutadas por el proveedor CDN en un centro de datos global. También se aplica la función hash sobre las máquinas en el centro de datos de Madrid y global con el anillo de función hash consistente tal como se observa en la figura 3.
Asociando máquinas en diversos centros de datos con los url del contenido, el rastreador conoce las máquinas en el centro de datos asociadas con el URL. En el ejemplo anterior, el MD5 de URL1 se correlaciona con un punto en el círculo unitario. Hay varias maneras mediante las que puede correlacionarse el URL con las máquinas en el centro de datos que alojarán el contenido (por ejemplo, distancia más corta entre la correlación de URL y la(s) máquinas(s), ejecución de recorrido en sentido horario o antihorario en el círculo unitario). En cualquier caso, según el método de la invención, se detiene una vez encontradas máquinas en los centros de datos local, nacional y global. En el ejemplo anterior, se escogen máquinas moviéndose en un sentido horario. Moviéndose en un sentido horario, los siguientes anfitriones se asociarán con el archivo de contenido de URL1; BCN1-1, MAD2-1,
8
ES 2 425 626 A2
BCN2-1, y GLB2-1. Con el mismo razonamiento, BCN3-1, BCN2-2, MAD3-1 y GLB1-1 se escogen para alojar contenido para URL2.
Cuando se añade o elimina un contenedor, se reasignan artículos. La mayoría de las correlaciones de URL con máquina no se ven afectadas. Si se elimina una máquina, las correlaciones de URL de la máquina eliminada se distribuyen a otras máquinas en el entorno de los URL. El número de URL que es necesario mover es normalmente una pequeña fracción del número total de correlaciones de URL. De manera similar, sólo una pequeña fracción de correlaciones de URL se ve afectada cuando se añade una máquina.
Las soluciones mencionadas en la sección del estado de la técnica anterior usan un “contenedor” como unidad que representa todo el contenido de un cliente. Desafortunadamente, esto supone que la distribución de contenido para un cliente es una tarea basta (tosca) ya que todo el contenido de un cliente (un contenedor) se almacena en uno o más servidores de contenido. Según algunas realizaciones de la presente invención, el método comprende usar la noción de un contenedor como punto de partida, en la que contenedor es meramente una unidad de almacenamiento para una parte del contenido de un cliente. Esto proporciona una mejor granularidad de almacenamiento y distribución del contenido en nodos de extremo.
A continuación, se proporcionan dos realizaciones alternativas del método de la invención, para diferentes infraestructuras, con referencia a las figuras 1 y 2, teniendo ambas en común que comprenden las etapas a) a k) descritas anteriormente del método de la invención.
Para ambas realizaciones, cualquier centro de datos que aloja contenido CDN puede almacenarlo en una o más máquinas. El objetivo es encontrar la máquina que puede conseguir más fácilmente datos para el usuario final solicitante.
Empezando con la realización de la figura 1, en ese caso el sistema de resolución de DNS de ISP está configurado con una dirección conocida de servidores raíz. Una consulta a uno de los servidores raíz devolverá el servidor autorizado para el dominio de nivel superior (TLD). En el método de la invención, el servidor DNS raíz devolverá el servidor autorizado para el dominio .net. Como siguiente etapa, se consulta al servidor DNS de TLD para el servidor autorizado para el dominio de segundo nivel (en el presente ejemplo, éste es el dominio t-cdn.net). La consulta y las respuestas se etiquetan. Una descripción detallada etapa por etapa de la resolución de DNS es tal como sigue:
Una primera petición de DNS, denominada anteriormente primera fase de resolución de DNS:
(0)
El usuario realiza una petición de un video bucket_id.t-cdn.net/bucket_id/video01.flv. Por motivos de sencillez de explicación, se fija bucket_id = 87. Ahora la petición tendrá el aspecto 87.t-cdn.net/87/video01.flv.
(1)
El sistema de resolución de DNS de ISP consulta al servidor DNS de TLD para el dominio .net para resolver el dominio t-cdn.net.
(2)
El servidor de nombres .net responde con la dirección IP de servidor autorizado para el dominio tcdn.net. t-cdn.net es el servidor DNS raíz de la CDN del proveedor de servicios.
(3)
El servidor DNS autorizado para el dominio de segundo nivel, t-cdn.net infiere en primer lugar que 87.tcdn.net es un alias para 87.g.t-cdn.net. Por tanto, se realizará una consulta para el dominio g.t-cdn.net.
(4)
Para resolver la subzona, usa su geobase de datos de IP. La geobase de datos de IP mantiene una correlación de prefijos de IP con una subzona, representada por un número entero o una cadena.
(5)
El servidor DNS autorizado para el dominio t-cdn.net resuelve la subzona de sistema de resolución de DNS de ISP. En el ejemplo, el servidor DNS autorizado para el dominio de segundo nivel responde con la subzona del cliente como “es” (para España). En este caso, “es” representa el número entero 34. El servidor DNS resuelve que la dirección IP de ISP en la subzona es es.t-cdn.net o 34.t-cdn.net.
(6)
El servidor DNS 34.t-cdn.net es el servidor DNS autorizado para la subzona “es”. Entonces, el sistema de resolución de DNS de ISP intentará resolver 87.34.t-cdn.net consultando al servidor DNS autorizado en la subzona.
(7)
El servidor DNS autorizado en la subzona tiene una lista de todos los nodos de extremo. Además, tiene la dirección del rastreador que funciona en la misma región (o subzona) que el servidor DNS. Por tanto, se reenvía una petición en la forma 87.34.t-cdn.net al rastreador.
(8) El rastreador reenvía la petición a uno cualquiera de los nodos de extremo usando o bien un esquema round-robin o bien un esquema de geolocalización de mejor esfuerzo que intenta hacer coincidir la petición con el nodo de extremo más próximo de {nodo de extremo 1, nodo de extremo 2, nodo de extremo 3,…, nodo de extremo
9
ES 2 425 626 A2
N}. El nodo de extremo 2 recibe la petición. El nodo de extremo realiza una búsqueda de PID en la dirección IP del sistema de resolución de DNS de ISP (por ejemplo Barcelona) e identifica el centro de datos BCN como uno que puede proporcionar de la mejor manera el contenido.
Una redirección HTTP:
(9) El nodo de extremo 2 realiza una función hash consistente sobre el URL solicitado (en este caso, “87/video01.flv”). A continuación, el nodo de extremo 2 devuelve HTTP 302, ubicación movida 87-p9-habf8.34.tcdn.net en la que abf8 = subcadena (MD5(URL)) y con el prefijo h, el PID identificado como 9 con el prefijo p. La respuesta HTTP se devuelve al usuario final.
Una segunda petición de DNS, denominada anteriormente segunda fase de resolución de DNS:
(10)
El usuario final envía una petición de resolución de dirección para 87-p9-habf8.34.t-cdn.net.
(11)
El sistema de resolución de DNS de ISP reenvía la petición de resolución de dirección desde el cliente
al sistema de resolución de DNS en la subzona “es” (región 34).
(12)
Se identifica el centro de datos / PoP como 9 (centro de datos en BCN). La petición de resolución de dirección se envía ahora al rastreador.
(13)
El rastreador realiza la aplicación de función hash consistente sobre abf8 para obtener {nodo de extremo 1, nodo de extremo 3, y nodo de extremo N} como nodos de extremo que pueden atender de la mejor manera la petición. El rastreador tiene en cuenta la carga actual en los nodos de extremo e identifica que el nodo de extremo 3 es el más adecuado para proporcionar contenido.
(14) Se devuelve la respuesta del rastreador que identifica la lista de nodos de extremo en el orden {nodo de extremo 3, nodo de extremo 1, y nodo de extremo N} al sistema de resolución de DNS autorizado en la subzona “es”.
(15)
El sistema de resolución de DNS de subzona “es” reenvía la respuesta al sistema de resolución de DNS de ISP.
(16) El sistema de resolución de DNS de ISP devuelve la respuesta al usuario final solicitante.
(17)
El usuario final se conectará ahora directamente al nodo de extremo 3, el primer nodo de extremo en su lista devuelta con una petición en la forma 87-p9-habf8.34.t-cdn.net/87/video01.flv. Si la conexión con el nodo de extremo 3 no es satisfactoria, el usuario final intentará obtener el contenido a partir del nodo de extremo 1, etcétera.
En resumen, la resolución de contenido conlleva dos peticiones de DNS y una redirección HTTP (ubicación movida HTTP). La primera resolución de DNS identifica el centro de datos geográficamente más próximo al DNS de ISP de cliente solicitante y da como resultado una redirección HTTP tras una función hash consistente sobre el URL solicitado mediante un nodo de extremo. La segunda resolución de DNS da como resultado que el rastreador identifique la máquina (en el centro de datos más próximo al DNS de ISP de cliente) que puede proporcionar de la mejor manera el contenido tras realizar una función hash consistente sobre el URL solicitado.
Según la figura 2, se describe otra realización del método de la invención, que se implementa en un escenario de resolución de DNS que implica una jerarquía de tres niveles de centros de datos, uno a nivel de región, y otro a nivel nacional, y finalmente un centro de datos global operado por el operador CDN que puede residir en el mismo país o no.
A nivel regional, un operador CDN puede tener un centro de datos en Barcelona que da servicio a toda Cataluña, por ejemplo. El centro de datos a nivel nacional puede estar en Madrid y el centro de datos global puede estar o bien en Londres o bien en el propio Madrid (no ubicado conjuntamente con el centro de datos nacional).
En las mismas líneas, puede considerarse otro ejemplo: a nivel regional, un operador CDN puede tener un centro de datos en San Francisco que da servicio a toda California, un centro de datos nacional en Portland, Oregón, que da servicio como reserva para todos los centros de datos regionales en los EE.UU. y un centro de datos global en Boise, Idaho.
Se considera el siguiente esquema de centros de datos jerárquicos: un centro de datos regional en Barcelona (BCN) que contiene las máquinas {BCN1, BCN2, BCN3 y BCN4}. El centro de datos nacional en Madrid (MAD) contiene las máquinas {MAD1, MAD2 y MAD3}. El centro de datos global, también en Madrid (pero no ubicado conjuntamente con el centro de datos nacional) contiene las máquinas {GLB1 y GLB2}.
10
ES 2 425 626 A2
En este ejemplo de la figura 2, no se muestra la interacción entre el sistema de resolución de DNS de ISP y el servidor de nombres .net, al contrario que en la figura 1. Además, tampoco se muestra la interacción entre el sistema de resolución de DNS de ISP y el servidor de nombres t-cdn.net para resolver la región del DNS de ISP. Por motivos de sencillez, se muestra que la consulta se envía directamente al servidor DNS autorizado para la subzona “es” (región 34).
Las etapas del método para esta realización son las siguientes:
Una primera petición de DNS, o primera fase de resolución de DNS:
(0) Aquí, un usuario final en Gerona (una ciudad de Cataluña) realiza una petición para un video 87.tcdn.net/87/video01.flv.
(1) Según la suposición simplificada, el sistema de resolución de DNS de ISP envía directamente la
consulta al servidor DNS autorizado para la subzona “es” (región 34). Por tanto, el DNS de ISP reenvía una petición
en la forma 87.34.t-cdn.net/87/video01.flv.
(2) El servidor DNS autorizado para la región 34 reenvía la petición recibida al rastreador de la región 34.
(3)
El rastreador en la subzona “es” usa el conjunto de direcciones IP {BCN2, BCN3, BCN4, MAD2, MAD3, GLB2} y un esquema round-robin o un esquema de geolocalización de mejor esfuerzo que intenta hacer coincidir la petición con el nodo de extremo más próximo para identificar la siguiente máquina a la que debe enviar la petición de resolución. En el conjunto anterior, no se incluyen máquinas que ya están sometidas a un gran uso {BCN1, MAD1 y GLB1}. En este ejemplo, la petición se reenvía al nodo de extremo MAD2. 4. El usuario final realiza una petición de resolución de dirección para abf8.bcn.es.t-cdn.net.
Una redirección HTTP:
(4)
El nodo de extremo MAD2 realiza una búsqueda en el PID de la IP de sistema de resolución de DNS de ISP. El nodo de extremo MAD2 identifica que el PID del DNS de ISP es BCN (9, para Barcelona) y también realiza un MD5 sobre el URL (en este caso, “87/video01.flv”). En este caso, abf8 = Subcadena (MD5(URL)). El nodo de extremo MAD2 devuelve HTTP 302, ubicación movida 87-p9-habf8.34.t-cdn.net. Esta respuesta se devuelve al usuario final.
(5) Una segunda petición de DNS, o segunda fase de resolución de DNS:
(6)
El usuario final realiza una petición de resolución de dirección para 87-p9-habf8.34.tcdn.net/87/video01.flv.
(7) El sistema de resolución de DNS de ISP reenvía la petición del usuario final al servidor DNS autorizado
en la subzona “es”.
(8)
El servidor DNS autorizado en la subzona “es” recibe la petición del servidor DNS de ISP. El servidor DNS reenvía la petición al rastreador de la subzona “es” (región 34).
(9)
Al recibir la petición del servidor DNS de la región, el rastreador identifica PID 9, centro de datos BCN como el que está más próximo al usuario final solicitante. El rastreador realiza la aplicación de función hash consistente sobre abf8 para obtener los nodos de extremo dentro del centro de datos BCN que puede atender de la mejor manera la petición. El rastreador también identifica los nodos de reserva (fuera del centro de datos BCN) que pueden atender la petición si es necesario. En este ejemplo, el rastreador identifica {BCN4, BCN2, MAD2 y GLB2} como nodos de extremo (en ese orden) que pueden atender de la mejor manera la petición. Por tanto, se tienen dos nodos de extremo locales, uno a nivel nacional y otro como posición de retirada global.
(10)
La respuesta, que indica la lista de direcciones IP de las cuatro máquinas, se devuelve al servidor DNS autorizado en la subzona “es” (región 34).
(11) El servidor DNS en la subzona “es” (región 34) reenvía la respuesta al sistema de resolución de DNS
de ISP.
(12) El sistema de resolución de DNS de ISP reenvía la respuesta que contiene las cuatro direcciones IP al usuario final.
(13) El usuario final intentará ahora conectarse directamente al nodo de extremo BCN4.
En la etapa 10, el sistema de resolución de DNS de ISP tiene cuatro direcciones IP que corresponden al contenido de vídeo 87.34.t-cdn.net/87/video01.flv. Esta información permanece en la memoria caché hasta que
11
ES 2 425 626 A2
caduca el TTL para la memoria caché de DNS. El servidor DNS puede atender a peticiones posteriores para el mismo contenido por otros usuarios finales sin tener que pasar de nuevo por el proceso de resolución de DNS.
El proceso implica dos consultas de resolución de DNS y una redirección (ubicación movida HTTP). El nodo de extremo obtiene una lista de direcciones IP que puede proporcionar de la mejor manera el contenido. En el ejemplo anterior, si el usuario final no puede conseguir el contenido a partir o bien de BCN4 o bien de BCN2, se retirará al nodo de extremo MAD2 en el centro de datos a nivel nacional y si vuelve a no ser satisfactorio, se retirará a GLB2, al centro de datos global.
Explicación de redirecciones en la CDN de proveedor de servicios:
A continuación se describen tres realizaciones del método de la invención con referencia a las figuras 4, 5 y 6, que aclaran dos clases diferentes de redirección que pueden producirse en una CDN de proveedor de servicios:
(1) redirección interregional, o bien dentro de la misma OB (figura 5) o bien entre OB (figura 4) y (2) redirección intrarregional que se produce entre centros de datos en la misma región de una OB (figura 6).
Dichas figuras 4, 5 y 6 muestran dos aspectos de la CDN: (1) Muestran cómo se mueve contenido en la CDN desde el punto de publicación mediante un propietario de contenido (cliente CDN) hasta los nodos de extremo que proporcionan el contenido y (2) cuando un usuario final realiza una petición de contenido, la CDN dirige la petición de contenido a un nodo de extremo que es tanto el menos cargado como el más próximo geográficamente al usuario final. Esta resolución de petición de contenido forma el núcleo de esta invención.
-
Redirección interregional:
Se consideran dos ejemplos de redirección interregional. En el primer caso, se muestra un ejemplo de redirección interregional entre dos unidades de negocio, OB1 y OB2. En el segundo ejemplo, se muestra la redirección interregional entre dos regiones de la misma unidad de negocio, OB1.
Redirección interregional entre OB:
En este ejemplo, se consideran dos OB, OB1 y OB2. Cada una de las dos OB tiene exactamente una región. Las OB también se conectan a un servidor de nombres t-cdn.net global. Usando la configuración en la figura 4 como ejemplo, se describe cómo funciona la redirección interregional de una petición de contenido cuando el sistema de resolución de DNS de ISP no está en la misma OB (y por tanto, no en la misma región) que un usuario final solicitante.
Las etapas del método para esta realización son las siguientes:
Una primera petición de DNS, o primera fase de resolución de DNS:
(1)
El usuario final en OB1 realiza una petición para video01.flv. La petición tendrá ahora el aspecto 87.tcdn.net/87/video01.flv.
(2)
El sistema de resolución de DNS de ISP consulta al servidor DNS autorizado para el dominio t-cdn.net para resolver la petición del usuario final.
(3)
El servidor de nombres t-cdn.net infiere que 87.t-cdn.net es un alias para 87.g.t-cdn.net. Por tanto, se realizará la consulta para el dominio g.t-cdn.net. El servidor de nombres t-cdn.net busca en la región del DNS de ISP usando su geobase de datos de IP y responde con la dirección IP del servidor DNS autorizado para la región del DNS de ISP, 87.44.t-cdn.net.
(4)
El sistema de resolución de DNS de ISP intentará entonces resolver 87.44.t-cdn.net consultando al servidor DNS autorizado en la subzona, que es la región 44 en OB2.
(5)
El servidor DNS autorizado DNS-OB2 reenvía la petición al rastreador en la misma región (rastreador-OB2).
(6)
El rastreador en la región 44, rastreador-OB2, tiene una lista de todos los nodos de extremo. Reenvía la petición a uno cualquiera de los nodos de extremo usando o bien un esquema round-robin o bien un esquema de geolocalización de mejor esfuerzo que intenta para hacer coincidir la petición con el nodo de extremo más próximo de {nodo de extremo 1, nodo de extremo 2}.
Una redirección HTTP:
(7)
El nodo de extremo NE-2-OB2 recibe la petición. El nodo de extremo realiza una búsqueda de PID en la dirección IP del sistema de resolución de DNS de ISP e identifica NE-1-OB2 como el nodo de extremo que puede
12
ES 2 425 626 A2
proporcionar el contenido solicitado. El nodo de extremo NE-2-OB2 también realiza un MD5 sobre el URL,
“87/video01.flv”. Se toma una subcadena del URL (en este caso, “87/video01.flv”). En este caso, abf8 = Subcadena
(MD5(URL)). Para resolver el PID de la dirección IP, busca la base de datos de PID para construir el URL 87-p1habf8.44.t-cdn.net/87/video01.flv. El URL 87-p1-habf8.44.t-cdn.net/87/video01.flv junto con las direcciones IP de los nodos de extremo {NE-1-OB2, NE-2-OB2} que son los más adecuados para proporcionar contenido en ese orden se devuelven al usuario final.
En realidad, el nodo de extremo NE-2-OB2 devuelve los nodos de extremo sin un orden al rastreador. Ya que el rastreador mantiene información estadística sobre la carga en cada nodo de extremo, el rastreador realiza el ordenamiento y devuelve el resultado al servidor DNS autorizado para la subzona. El resultado se devuelve al sistema de resolución de DNS de ISP y después al usuario final. Por motivos de claridad, las últimas etapas no se muestran en la figura 4.
(8)
El usuario final se conectará directamente al NE-1-OB2 con el URL 87-p1-habf8.44.tcdn.net/87/video01.flv.
(9)
El nodo de extremo NE-1-OB2 recibe la petición y verifica la información de región basándose en la dirección IP del usuario final. El nodo de extremo identifica que la región es la de la región 34 OB1 y que la partición es 1. Por tanto, el nodo de extremo NE-1-OB2 devuelve un mensaje de redirección HTTP 302 con el URL 87-p1habf8.34.t-cdn.net/-87/video01.flv.
Una segunda petición de DNS:
(10)
A continuación, el usuario final envía una petición 87-p1-habf8.34.t-cdn.net/+87/video01.flv al sistema de resolución de DNS de ISP.
(11)
El sistema de resolución de DNS de ISP consulta al servidor DNS autorizado del dominio t-cdn.net para resolver 34.t-cdn.net.
(12)
El servidor de nombres t-cdn.net busca en la región del dominio 34.t-cdn.net usando su geobase de datos de IP y responde con la dirección IP del servidor DNS autorizado para la región 34.t-cdn.net.
(13)
El sistema de resolución de DNS de ISP consulta ahora al servidor autorizado para la subzona (región 34) para resolver 87-p1-habf8.34.t-cdn.net/+87/video01.flv. El servidor DNS-OB1 recibe la petición.
(14)
El servidor DNS autorizado en la región 34 en OB1 tiene una lista de todos los nodos de extremo (NE1-OB1, NE-2-OB1) y el rastreador en la región. El servidor DNS-OB1 recibe la petición y la reenvía al rastreador de la región 34, rastreador-OB1.
(15)
El rastreador en la rastreador-OB1 de subzona tiene una lista de todos los nodos de extremo. El rastreador reconoce que la petición es una petición de redirección. El rastreador identifica que abf8 es el MD5 de la subcadena del URL “87/video01.flv”. También reconoce que el PID de la petición es 1. Usa esta información para identificar los nodos de extremo que están más próximos al usuario final solicitante de la lista {NE-1-OB1, NE-2-OB1}. El rastreador, rastreador-OB1 devuelve los nodos de extremo {NE-1-OB1, NE-2-OB1} en ese orden al servidor DNS de la región, DNS-OB1.
(16)
El conjunto de nodos de extremo se devuelve desde el DNS-OB1 al sistema de resolución de DNS de ISP.
(17)
El conjunto de nodos de extremo se devuelve desde el sistema de resolución de DNS de ISP al usuario final.
(18)
El usuario final envía la petición de contenido al nodo de extremo NE-1-OB1 mediante el URL 87-p1habf8.34.t-cdn.net/+87/video01.flv.
(19)
El nodo de extremo NE-1-OB1 proporciona el archivo solicitado video01.flv. El nodo de extremo obtiene el archivo de contenido a partir del servidor original OB1 si es necesario.
El nodo de extremo NE-1-OB recibe la petición. El nodo de extremo realiza una búsqueda de PID en la dirección IP del usuario final (por ejemplo, Barcelona) y se identifica a sí mismo como que está en el mismo PID (centro de datos BCN) que puede proporcionar de la mejor manera el contenido. El nodo de extremo proporciona entonces el contenido al usuario final si ya tiene video01.flv. Si no, consigue el contenido de otro nodo de extremo en el mismo centro de datos o vuelve al servidor original OB1 antes de dar servicio al usuario final.
Redirección interregional entre regiones de la misma OB:
13
ES 2 425 626 A2
En este ejemplo, se considera una OB con dos regiones diferenciadas. Cada región tiene su propio punto de publicación, servidor DNS autorizado para esa región y un rastreador.
La figura 5 muestra el escenario de redirección que consiste en una unidad de negocio, OB1. La figura también muestra dos regiones, región 1 y región 2. Cada región tiene un servidor DNS que está autorizado en su región y un rastreador. Ya que ambas regiones pertenecen a la misma OB, sólo hay un servidor original.
Las etapas del método para esta realización son las siguientes:
Una primera petición de DNS, o primera fase de resolución de DNS:
(1)
El usuario final en OB1 realiza una petición para video01.flv. La petición tendrá ahora el aspecto 87.tcdn.net/87/video01.flv.
(2)
El sistema de resolución de DNS de ISP consulta al servidor DNS autorizado para el dominio t-cdn.net para resolver la petición del usuario final.
(3)
El servidor de nombres t-cdn.net infiere que 87.t-cdn.net es un alias para 87.g.t-cdn.net. Por tanto, se realizará una consulta para el dominio g.t-cdn.net. El servidor de nombres t-cdn.net busca en la región del DNS de ISP usando su geobase de datos de IP y responde con la dirección IP del servidor DNS autorizado para la región del DNS de ISP, 87.2.t-cdn.net.
(4)
El sistema de resolución de DNS de ISP intentará entonces resolver 87.2.t-cdn.net consultando al servidor DNS autorizado en la subzona, que es la región 2 en OB1.
(5)
El rastreador en la región 2 tiene una lista de todos los nodos de extremo. Reenvía la petición a uno cualquiera de los nodos de extremo usando o bien un esquema round-robin o bien un esquema de geolocalización de mejor esfuerzo que intenta hacer coincidir la petición con el nodo de extremo más próximo de {nodo de extremo 1, nodo de extremo 2}.
Una redirección HTTP:
(6) El nodo de extremo NE-2-R2 recibe la petición. El nodo de extremo realiza una búsqueda de PID en la dirección IP del sistema de resolución de DNS de ISP e identifica NE-1-R2 como el nodo de extremo que puede proporcionar el contenido solicitado. El nodo de extremo NE-2-R2 también realiza un MD5 sobre el URL, “87/video01.flv”. Se toma una subcadena del URL (en este caso, “87/video01.flv”). En este caso, abf8 = Subcadena (MD5(URL)). Para resolver el PID de la dirección IP, busca en la base de datos de PID para construir el URL b87-p1habf8.2.t-cdn.net/87/video01.flv.
(7) El URL 87-p1-habf8.2.t-cdn.net/87/video01.flv junto con las direcciones IP de los nodos de extremo {NE1-R2, NE-2-R2} que son más adecuados para proporcionar contenido en ese orden se devuelven al usuario final.
En realidad, el nodo de extremo NE-2-R2 devuelve los nodos de extremo sin un orden al rastreador de la región 2. Ya que el rastreador mantiene información estadística sobre la carga en cada nodo de extremo, el rastreador realiza el ordenamiento y devuelve el resultado al servidor DNS autorizado para la subzona. El resultado se devuelve al sistema de resolución de DNS de ISP y después al usuario final. Por motivos de claridad de la figura, no se muestran las últimas etapas en la figura 5.
(8) El usuario final se conectará directamente a NE-1-R2 con el URL 87-p1-habf8.2.t-cdn.net/87/video01.flv.
(9)
El nodo de extremo NE-1-R2 recibe la petición y verifica la información de región basándose en la dirección IP del usuario final. El nodo de extremo identifica que la región es la de la región 1 en OB1. Por tanto, el nodo de extremo NE-1-R2 devuelve un mensaje de redirección HTTP 302 con el URL 87-p1-habf8.1.t-cdn.net/87/video01.flv.
Una segunda petición de DNS, o segunda petición de resolución:
(10)
El usuario final recibe la respuesta. A continuación, el usuario final envía una petición 87-p1-habf8.1.tcdn.net/+87/video01.flv al sistema de resolución de DNS de ISP.
(11)
El sistema de resolución de DNS de ISP consulta al servidor DNS autorizado del dominio t-cdn.net para resolver 1.t-cdn.net.
(12)
El servidor de nombres t-cdn.net busca en la región del DNS de ISP usando su geobase de datos de IP y responde con la dirección IP del servidor DNS autorizado para la región 1.t-cdn.net.
(13)
El servidor DNS de ISP consulta ahora al servidor autorizado en la región 1 para resolver 87-p1habf8.1.t-cdn.net/+87/video01.flv. El servidor DNS DNS-R1 recibe la petición.
(14)
El servidor DNS autorizado en la región 1 en OB1 tiene una lista de todos los nodos de extremo (NE-2-R1, NE-1-R1) y el rastreador en la región. El servidor DNS-R1 recibe la petición y la reenvía al rastreador de la región 1, rastreador-R1.
(15)
El rastreador en la región 1, rastreador-R1 tiene una lista de todos los nodos de extremo. El rastreador reconoce que la petición es una petición de redirección. El rastreador identifica que abf8 es el MD5 de la subcadena del URL “87/video01.flv”. También reconoce que el PID de la petición es 1. Usa esta información para identificar los nodos de extremo que están más próximos al usuario final solicitante de la lista {NE-2-R1, NE-1-R1}. El rastreador, rastreador-R1 devuelve los nodos de extremo {NE-2-R1, NE-1-R1} en ese orden al servidor DNS de la región, DNS-R1.
(16)
El conjunto de nodos de extremo se devuelve desde el DNS-R1 al sistema de resolución de DNS de ISP.
(17)
El conjunto de nodos de extremo se devuelve desde el sistema de resolución de DNS de ISP al usuario final.
(18)
El usuario final envía la petición de contenido al nodo de extremo NE-2-R1 mediante el URL 87-p1habf8.1.t-cdn.net/+87/video01.flv.
(19)
El nodo de extremo NE-2-R1 proporciona el archivo solicitado video01.flv. El nodo de extremo consigue el archivo de contenido del servidor original OB1 si es necesario.
14
ES 2 425 626 A2
El nodo de extremo NE-2-R1 recibe la petición. El nodo de extremo realiza una búsqueda de PID en la dirección IP del usuario final y se identifica a sí mismo como que está en el mismo PID. El nodo de extremo NE-2-R1 proporciona entonces el contenido al usuario final si ya tiene video01.flv. Si no, consigue el contenido de otro nodo de extremo en el mismo centro de datos (mismo PID) o vuelve al servidor original OB1 antes de dar servicio al usuario final.
Ambos ejemplos anteriores muestran que hay pocas diferencias en el mecanismo de redirección a nivel interregional ya se produzca la redirección entre dos OB diferenciadas o dentro de dos regiones de la misma OB.
En los ejemplos anteriores, no se muestra la interacción entre el sistema de resolución de DNS de ISP y el servidor de nombres .net como en la figura 1, por motivos de sencillez. Se supone que el sistema de resolución de DNS de ISP conoce la dirección del servidor de nombres t-cdn.net para resolver la región del DNS de ISP.
-
Redirección intrarregional
En esta sección se explica, con un ejemplo, cómo funciona una redirección intrarregional en una CDN del proveedor de servicios. La figura 6 muestra algunos de los componentes de una OB. En este caso, una unidad de negocio OB1 mostrada en la figura consiste en:
-
una región, región 1
-
tres centros de datos en la región 1
-
cada uno de los centros de datos tiene varios nodos de extremo que proporcionan contenido a usuarios finales solicitantes.
La figura muestra cómo se mueve contenido dentro de la CDN desde el punto de publicación al servidor original y después a los nodos de extremo. Los nodos de extremo en el mismo centro de datos pueden intercambiar contenido entre sí de una manera P2P. La figura 6 que sólo muestra tres centros de datos puede generalizarse a varios centros de datos y no debe considerarse limitativa del alcance de la invención.
Las etapas del método para esta realización son las siguientes:
Una primera petición de DNS, o primera fase de resolución de DNS:
(1)
El usuario final en OB1 realiza una petición para video01.flv. La petición tendrá ahora el aspecto 87.tcdn.net/87/video01.flv.
(2)
El sistema de resolución de DNS de ISP consulta al servidor DNS autorizado para el dominio t-cdn.net para resolver la petición del usuario final.
(3)
El servidor de nombres t-cdn.net infiere que 87.t-cdn.net es un alias para 87.g.t-cdn.net. Por tanto, se realizará una consulta para el dominio g.t-cdn.net. El servidor de nombres t-cdn.net busca en la región del DNS de ISP usando su geobase de datos de IP y responde con la dirección IP del servidor DNS autorizado para la región del DNS de ISP, 87.1.t-cdn.net.
(4)
El sistema de resolución de DNS de ISP intentará entonces resolver 87.1.t-cdn.net consultando al servidor DNS autorizado en la subzona, que es la región 1 en OB1.
(5)
El rastreador en región 1 tiene una lista de todos los nodos de extremo. Reenvía la petición a uno cualquiera de los nodos de extremo usando o bien un esquema round-robin o bien un esquema de geolocalización de mejor esfuerzo que intenta hacer coincidir la petición con el nodo de extremo más próximo de {D1-1-R1, D1-2-R1, D2-1-R1, D2-2-R1, D3-1-R1, D3-2-R1}.
15
ES 2 425 626 A2
Una redirección HTTP:
(6) El nodo de extremo D3-1-R1 recibe la petición. El nodo de extremo realiza una búsqueda de PID en la dirección IP del sistema de resolución de DNS de ISP e identifica D3-2-R1 como el nodo de extremo que puede proporcionar el contenido solicitado. El nodo de extremo D3-1-R1 también realiza un MD5 sobre el URL, “87/video01.flv”. Se toma una subcadena del URL (en este caso, “87/video01.flv”). En este caso, abf8 = Subcadena (MD5(URL)). Para resolver el PID de la dirección IP, busca en la base de datos de PID para construir el URL 87-p2habf8.1.t-cdn.net/87/video01.flv. En este caso, PID 1 identifica el centro de datos 2 como el más adecuado para proporcionar contenido.
(7) El URL 87-p2-habf8.2.t-cdn.net/87/video01.flv junto con las direcciones IP de los nodos de extremo {D32-R1, D3-1-R1} que son los más adecuados para proporcionar contenido en ese orden se devuelven al usuario final.
Tal como se comentó en los casos anteriores, el nodo de extremo D3-1-R1 devuelve los nodos de extremo sin un orden al rastreador de región 1. Ya que el rastreador mantiene información estadística sobre la carga en cada nodo de extremo, el rastreador realiza el ordenamiento y devuelve el resultado al servidor DNS autorizado para la subzona. El resultado se devuelve al sistema de resolución de DNS de ISP y después al usuario final. Por motivos de claridad y facilidad de explicación, las últimas etapas no se detallan en la figura 6.
(8) El usuario final se conectará directamente a D3-2-R1 con el URL 87-p2-habf8.2.t-cdn.net/87/video01.flv.
(9)
El nodo de extremo D3-2-R1 recibe la petición y verifica la información de región basada en la dirección IP del usuario final. El nodo de extremo identifica el PID 1 como que puede dar servicio de mejor manera al usuario final. Por tanto, el nodo de extremo D3-2-R1 devuelve un mensaje de redirección HTTP 302 con el URL 87-p1habf8.1.t-cdn.net/_87/video01.flv (el símbolo de guión bajo significa redirección intrarregional).
Una segunda petición de DNS, o segunda fase de resolución de DNS:
(10)
El usuario final recibe la respuesta. A continuación, el usuario final envía una petición 87-p1-habf8.1.tcdn.net/_87/video01.flv al sistema de resolución de DNS de ISP.
(11)
El sistema de resolución de DNS de ISP identifica que la petición es para la región 1 y consulta al servidor DNS autorizado en la región 1. Se reenvía la consulta al servidor DNS DNS-R1 (región 1 de OB1).
(12) El DNS-R1 reenvía la consulta al rastreador de la región 1, rastreador-R1.
(13)
El rastreador identifica que la consulta es una redirección intrarregional. El rastreador identifica el PID y determina los nodos de extremo en el centro de datos 1 que están mejor situados para proporcionar el contenido. El rastreador devuelve entonces una lista ordenada de nodos de extremo al usuario final {D1-2-R1, D1-1-R1}.
(14)
El usuario final se conecta directamente al nodo de extremo D1-2-R1 con el URL 87-p1-habf8.1.tcdn.net/_87/video01.flv.
(15) El nodo de extremo D1-2-R1 proporcionará ahora el contenido al usuario final solicitante.
Esta invención presenta las siguientes ventajas, dependiendo de la realización:
-
Ejecutando la aplicación de función hash consistente sobre el URL, es posible realizar un equilibrado de carga a nivel de archivos.
-
En un servicio CDN, dado que el contenido puede residir en algunos cientos (o miles de servidores), la invención supera la limitación del DNS de poder identificar rápidamente el servidor de contenido que puede dar servicio al usuario final solicitante.
16
ES 2 425 626 A2
Invocando nodos de extremo en la resolución de contenido, se garantiza que se llega rápidamente al nodo de extremo más adecuado para entregar contenido a un usuario final solicitante.
La técnica presentada en el presente documento garantiza que se proporcionan datos preferiblemente por nodos de extremo más próximos al usuario final solicitante. Si los nodos de extremo más próximos no pueden
5 proporcionar el contenido (porque están sobrecargados), la responsabilidad de proporcionar contenido recae sobre nodos de extremo que residen en el centro de datos nacional. Si el centro de datos nacional tampoco puede entregar el contenido solicitado, sólo entonces recae la responsabilidad de proporcionar contenido sobre nodos de extremo en el centro de datos global. Esto garantiza una entrega rápida de contenido a usuarios finales solicitantes siempre que sea posible.
10 - La CDN diseñada para un ISP puede desplegarse tan profundamente como sea necesario dentro de una red de ISP.
Dado que el sistema de resolución de DNS de ISP guarda (para la realización de la figura 2) la dirección IP del nodo de extremo que proporcionará el contenido solicitado hasta que caduca su TTL en la memoria caché de DNS, nuevos usuarios finales que soliciten el mismo contenido pueden obtener la ubicación del nodo de extremo
15 que puede proporcionar el contenido de la memoria caché del DNS de ISP (y por tanto, no tener que realizar la resolución de DNS para cada petición).
-
La solución propuesta elimina la necesidad de equilibradores de carga de hardware para responder a consultas en el DNS de segundo nivel ya que el rastreador actúa como equilibrador de carga para consultas a los nodos de extremo.
20 Un experto en la técnica puede introducir cambios y modificaciones en las realizaciones descritas sin apartarse del alcance de la invención tal como se define en las reivindicaciones adjuntas.
17
ES 2 425 626 A2
SIGLAS Y ABREVIATURAS
ADSL
ASYMMETRIC DIGITAL SUBSCRIBER LINE; LÍNEA DE ABONADO DIGITAL ASIMÉTRICA
AS
AUTONOMOUS SYSTEM; SISTEMA AUTÓNOMO
CDN
CONTENT DISTRIBUTION NETWORK; RED DE DISTRIBUCIÓN DE CONTENIDO
5
DNS DOMAIN NAME SERVICE; SERVICIO DE NOMBRES DE DOMINIO
POP
POINT OF PRESENCE; PUNTO DE PRESENCIA
TLD
TOP LEVEL DOMAIN; DOMINIO DE NIVEL SUPERIOR
FTP
FILE TRANSFER PROTOCOL; PROTOCOLO DE TRANSFERENCIA DE ARCHIVOS
10
HTTP HYPERTEXT HIPERTEXTO TRANSFER PROTOCOL; PROTOCOLO DE TRANSFERENCIA DE
MD5
MESSAGE-DIGEST ALGORITHM 5; ALGORITMO DE RESUMEN DEL MENSAJE 5
URL
UNIFORM RESOURCE LOCATOR; LOCALIZADOR UNIFORME DE RECURSOS
ISP
INTERNET SERVICE PROVIDER; PROVEEDOR DE SERVICIOS DE INTERNET
TTL
TIME TO LIVE; TIEMPO DE VIDA
15
DSLAM DIGITAL SUBSCRIBER LINE ACCESS MULTIPLEXER; MULTIPLEXADOR DE ACCESO DE LÍNEA DE ABONADO DIGITAL
18
ES 2 425 626 A2
BIBLIOGRAFÍA
[1] Definición de sistema de nombres de dominio: http://en.wikipedia.org/wiki/Domain_Name_System
[2] Akamai: http://www.akamai.com 5 [3] Limelight Networks: http://www.limelightnetworks.com
[4] Amazon Cloudfront: http://aws.amazon.com/cloudfront/
[5] Edgecast: http://www.edgecast.com
[6] Highwinds Network Group: http://www.highwinds.com
[7] Definición de aplicación de función hash consistente: http://en.wikipedia.org/wiki/Consistent_hashing
10 [8] D. Karger, E. Lehman, T. Leighton, M. Levine, D. Lewin y R. Panigraphy, “Consistent Hashing and Random TreesL Distributed Caching Protocols for Retrieving Hot Spots on the World Wide Web”. En ACM Symposium on Theory of Computing, 1997.
[9] C. Huang, J. Li, Angela Wang y K. W. Ross, Understanding Hybrid CDN-P2P: Why Limelight Need its Own Red Swoosh, NOSSDAV, Braunschweig, Alemania, 2008.
19
ES 2 425 626 A2

Claims (20)

  1. REIVINDICACIONES
    1. Método para la resolución de DNS de peticiones de contenido en un servicio CDN, que comprende identificar un nodo de extremo o servidor de contenido que da servicio a un usuario final que ha enviado una petición de DNS a un sistema de resolución de DNS de ISP, dada una red geográficamente distribuida de nodos de extremo, caracterizado porque dicha resolución de DNS se lleva a cabo realizando al menos:
    I) una fase de resolución de DNS, que comprende realizar las siguientes etapas:
    a) enviar, dicho sistema de resolución de DNS de ISP, la petición de DNS recibida a un servidor DNS autorizado de una subzona, o bien conocida previamente o bien identificada enviando una petición al servidor DNS raíz del dominio solicitado;
    b) reenviar, dicho servidor DNS autorizado de dicha subzona, dicha petición de DNS al rastreador que funciona en dicha subzona, y reenviar, dicho rastreador, la petición de DNS recibida a uno de dichos nodos de extremo que participan en dicha fase de resolución de DNS, dicho rastreador que funciona en dicha subzona usando al menos un esquema round-robin o un esquema de geolocalización de mejor esfuerzo para hacer coincidir la petición de DNS con el nodo de extremo que participa en dicha fase de resolución de DNS; y
    II) una fase de re-direccionamiento HTTP, que comprende realizar las siguientes etapas:
    c) resolver, dicho nodo de extremo que participa en dicha fase de resolución de DNS, la ubicación del sistema de resolución de DNS de ISP mediante consulta a una base de datos de ID de partición para identificar:
    -
    el centro de datos que puede proporcionar el contenido; o
    -
    al menos un nodo de extremo en el mismo centro de datos que puede proporcionar el contenido; y
    d) realizar, dicho nodo de extremo que participa en dicha fase de resolución de DNS una función hash consistente sobre el URL solicitado asociado con dicha petición de DNS, construir una dirección URL usando una subcadena de la función hash MD5 de petición de contenido y la ubicación de dicho centro de datos que puede proporcionar el contenido o la ubicación de dicho al menos un nodo de extremo en el mismo centro de datos que puede proporcionar el contenido, y enviar dicha dirección al usuario final, directamente o a través de entidades intermedias, usando un mensaje de redirección,
  2. 2. Método según la reivindicación 1, en el que cuando se aplica a la resolución de DNS a través de sólo una región de una unidad de negocio, dicha subzona es dicha región, siendo dicha fase de resolución de DNS de I) una primera fase de resolución de DNS, siendo dicho mensaje de redirección un mensaje de redirección HTTP, y comprendiendo el método además una segunda fase de resolución de DNS que comprende realizar las siguientes etapas:
    e) realizar, el usuario final, una petición de resolución de dirección para dicha dirección URL recibida a dicho sistema de resolución de DNS de ISP;
    f) reenviar, el servidor DNS de ISP, dicha petición de resolución de dirección a dicho servidor DNS autorizado de subzona;
    g) reenviar, el servidor DNS autorizado de subzona, el URL recibido al rastreador de la región para resolver la dirección recibida;
    h) realizar, dicho rastreador en la región, una función hash consistente sobre dicha subcadena de la función hash de URL para obtener el nodo de extremo o nodos de extremo dentro de dicho centro de datos que puede proporcionar la petición de contenido;
    i) enviar, el rastreador, una respuesta que incluye la dirección de al menos uno de dichos nodos de extremo obtenidos al servidor DNS autorizado de subzona;
    j) reenviar, el servidor DNS autorizado de subzona, dicha respuesta de rastreador al sistema de resolución de DNS de ISP; y
    k) reenviar, el sistema de resolución de DNS de ISP, dicha respuesta recibida desde el servidor autorizado de la subzona al usuario final.
    20
    ES 2 425 626 A2
  3. 3.
    Método según la reivindicación 2, en el que dicha etapa h) comprende además identificar, el rastreador, el nodo de extremo menos cargado en dicho centro de datos que puede proporcionar el contenido usando información sobre la carga actual en dichos nodos de extremo e incluir la dirección únicamente de dicho nodo de extremo menos cargado en dicha respuesta de rastreador enviada en la etapa i).
  4. 4.
    Método según la reivindicación 3, que comprende, tras dicha etapa j), conectarse directamente, el usuario final, a dicho nodo de extremo menos cargado enviando una petición de conexión al mismo, con una dirección URL que es dicha dirección construida que identifica el archivo de contenido solicitado.
  5. 5.
    Método según cualquiera de las reivindicaciones anteriores, en el que dicho servidor DNS autorizado de dicha subzona se identifica previamente mediante una geobúsqueda de IP.
  6. 6.
    Método según la reivindicación 1, en el que dicha geobúsqueda de IP se lleva a cabo en un servidor DNS autorizado para un dominio de segundo nivel.
  7. 7.
    Método según la reivindicación 6, que comprende:
    -
    consultar, el sistema de resolución de DNS de ISP, a un servidor DNS de dominio de nivel superior para resolver un dominio de segundo nivel de la dirección de dicha petición de DNS;
    -
    responder, el servidor DNS de dominio de nivel superior, al sistema de resolución de DNS de ISP con la dirección IP de dicho servidor DNS autorizado de dicho dominio de segundo nivel;
    -
    consultar, el sistema de resolución de DNS de ISP, a dicho servidor DNS autorizado de dicho dominio de segundo nivel para resolver dicho dominio de segundo nivel de la dirección de dicha petición de DNS; y
    -
    resolver, el servidor DNS autorizado de dicho dominio de segundo nivel, dicha subzona mediante dicha geobúsqueda de IP, y responder al sistema de resolución de DNS de ISP con la dirección de dicha subzona mediante dicha geobúsqueda de IP.
  8. 8.
    Método según la reivindicación 2, en el que dicha respuesta de rastreador contiene una lista de direcciones de al menos algunos de los nodos de extremo en dicho centro de datos que proporciona el contenido.
  9. 9.
    Método según la reivindicación 8, en el que dicha etapa h) comprende además identificar, el rastreador, nodos de extremo de reserva fuera de dicho centro de datos que puede proporcionar el contenido, que pueden atender la petición si es necesario, conteniendo dicha lista de dicha respuesta de rastreador direcciones de dichos nodos de extremo de reserva.
  10. 10.
    Método según la reivindicación 9, en el que dicho centro de datos que puede proporcionar el contenido es un centro de datos local, y dichos nodos de extremo de reserva pertenecen a centros de datos nacionales y/o globales.
  11. 11.
    Método según cualquiera de las reivindicaciones anteriores 9 u 8, que comprende, tras dicha etapa j), conectarse directamente, el usuario final, a uno de los nodos de extremo de dicho centro de datos que puede proporcionar el contenido, y si no puede conseguir el contenido a partir de dicho nodo de extremo, conectarse a uno de los nodos de extremo de reserva incluidos en dicha lista.
  12. 12.
    Método según la reivindicación 1, que comprende una redirección interregional entre al menos dos regiones (región 1, región 2) de dos unidades de negocio (OB1, OB2), estando dicho servidor DNS de subzona (DNS-OB2) en una (región 2) de dichas al menos dos regiones (región 1, región 2), en el que:
    -
    dicho usuario final se encuentra en una región (región 1), o región de destino, de una primera (OB1) de dichas dos unidades de negocio (OB1, OB2),
    -
    siendo dicha subzona una región (región 2) de una segunda (OB2) de dichas dos unidades de negocio (OB1, OB2),
    -
    encontrándose dicho sistema de resolución de DNS de ISP en dicha segunda unidad de negocio (OB2),
    -
    siendo dicho servidor DNS autorizado para dicho dominio de segundo nivel el servidor DNS autorizado para ambas unidades de negocio (OB1, OB2), y
    -siendo dicho al menos un nodo de extremo que puede proporcionar el contenido un nodo de extremo (NE1-OB2) que se encuentra en dicha segunda unidad de negocio (OB2).
  13. 13.
    Método según la reivindicación 12, en el que dicha fase de resolución de DNS de I) es una primera fase de resolución de DNS, dicha etapa d) comprende además enviar además, dicho nodo de extremo que
    21
    ES 2 425 626 A2
    participan en dicha primera fase de resolución de DNS (NE-2-OB2), al usuario final, mediante el rastreador (rastreador-OB2) de la región (región 2) en dicha segunda unidad de negocio (OB2), junto con la dirección construida, la dirección IP de al menos dicho al menos un nodo de extremo (NE-1-OB2) que puede proporcionar el contenido.
  14. 14. Método según la reivindicación 13, en el que dicha redirección HTTP de II) comprende además, tras dicha etapa d):
    -
    conectarse directamente, el usuario final, a dicho al menos un nodo de extremo (NE-1-OB2) que puede proporcionar el contenido enviando una petición de conexión al mismo, en forma de un URL que incluye dicha dirección construida que también identifica el contenido solicitado; y
    -
    recibir, el al menos un nodo de extremo (NE-1-OB2) que puede proporcionar el contenido, dicha dirección URL de petición de conexión, verificar la información de región basándose en la dirección IP del usuario final, modificar dicha dirección URL incluyendo dicha información de región de usuario final en la misma, y enviar dicha dirección URL modificada al usuario final usando un mensaje de redirección HTTP;
    y comprendiendo el método además una segunda fase de resolución de DNS que comprende realizar las siguientes etapas:
    -
    enviar, el usuario final, una petición de DNS modificada, basada en dicha dirección URL modificada, al el sistema de resolución de DNS de ISP;
    -
    consultar, el sistema de resolución de DNS de ISP, al servidor DNS autorizado para resolver un dominio de segundo nivel de dicha dirección URL modificada de dicha petición de DNS modificada;
    -
    el servidor DNS autorizado del dominio de segundo nivel conoce la región de destino mediante la petición URL y resuelve la petición del sistema de resolución de DNS de ISP con la dirección IP del servidor DNS (DNS-OB1) autorizado para la región de destino (región 1);
    -
    consultar, el sistema de resolución de DNS de ISP, a dicho servidor DNS (DNS-OB1) autorizado para la región de destino (región 1) para resolver dicha petición de DNS modificada;
    -
    recibir, el servidor DNS (DNS-OB1) autorizado para la región de destino (región 1), dicha petición de DNS modificada y reenviarla al rastreador (rastreador-OB1) de la región de destino (región 1);
    -
    reconocer, dicho rastreador (rastreador-OB1) de la región de destino (región 1), que la petición es una petición de redirección, identificar el nodo de extremo o nodos de extremo (NE-1-OB1, NE-2-OB1) que están más próximos al usuario final solicitante, y devolver una lista que hace referencia a dichos nodos de extremo (NE-1-OB1, NE-2-OB1) al servidor DNS (DNS-OB1) autorizado para la región de usuario final, siendo dicha lista una lista ordenada que comienza con el nodo de extremo menos cargado (NE-1-OB1);
    -
    el servidor DNS (DNS-OB1) autorizado para la región de destino (región 1) devuelve la lista de nodos de extremo (NE-1-OB1, NE-2-OB1) al sistema de resolución de DNS de ISP;
    -
    el sistema de resolución de DNS de ISP reenvía la lista de nodos de extremo recibida (NE-1-OB1, NE-2-OB1) al usuario final solicitante;
    -
    enviar, el usuario final, una petición de contenido al nodo de extremo más próximo y menos cargado (NE1-OB1) según se indica en dicha lista de nodos de extremo (NE-1-OB1, NE-2-OB1) junto con el URL modificado que contiene la función hash del contenido, el ID de partición del usuario final y el ID de contenedor del contenido; y
    -
    proporcionar, dicho nodo de extremo más próximo y menos cargado (NE-1-OB1), el contenido solicitado al usuario final.
  15. 15. Método según la reivindicación 1, que comprende una redirección interregional entre al menos dos regiones (región 1, región 2) de la misma unidad de negocio (OB1), dicha unidad de negocio (OB1) estando conectada a un servidor de nombres global, en el que:
    -
    dicho usuario final se encuentra en una primera región (región 1), o región de destino, de dichas al menos dos regiones (región 1, región 2) de dicha unidad de negocio (OB1),
    -
    dicho servidor DNS autorizado para la subzona está en una segunda región (región 2) de dichas al menos dos regiones (región 1, región 2),
    -
    dicho sistema de resolución de DNS de ISP se encuentra en dicha segunda región (región 2),
    ES 2 425 626 A2
    -
    dicho servidor DNS autorizado para el dominio de segundo nivel está autorizado para todas las regiones definidas (región 1, región 2), y
    -
    dicho al menos un nodo de extremo que puede proporcionar el contenido es un nodo de extremo (NE-1-R2) que se encuentra en dicha segunda región (región 2).
  16. 16.
    Método según la reivindicación 15, en el que dicha fase de resolución de DNS de I) es una primera fase de resolución de DNS, dicha etapa d) comprende además enviar además, dicho nodo de extremo que participa en dicha primera fase de resolución de DNS (NE-2-R2), al usuario final, mediante un rastreador (rastreador-R2) de dicha segunda región (región 2), la dirección URL modificada, y una lista ordenada de direcciones IP de nodos de extremo (NE-1-R2, NE-2-R2) con al menos dicho al menos un nodo de extremo (NE-1-R2) que puede proporcionar el contenido.
  17. 17.
    Método según la reivindicación 16, en el que dicha redirección HTTP de II) comprende además, tras dicha etapa d):
    -
    conectarse directamente, el usuario final, a dicho al menos un nodo de extremo (NE-1-R2) que puede proporcionar el contenido enviando una petición de conexión al mismo, y la dirección URL recibida;
    -
    recibir, el al menos un nodo de extremo (NE-1-R2) que puede proporcionar el contenido, dicha petición de URL, verificar el ID de partición del usuario final, modificar dicha dirección URL incluyendo dicha información de PID de usuario final en la misma, y devolver dicha dirección URL modificada al usuario final usando un mensaje de redirección HTTP;
    y comprendiendo el método además una segunda fase de resolución de DNS que comprende realizar las siguientes etapas:
    -
    enviar, el usuario final, una petición de DNS modificada, basada en dicha dirección URL modificada al sistema de resolución de DNS de ISP;
    -
    consultar, el sistema de resolución de DNS de ISP, al servidor DNS autorizado para resolver un dominio de segundo nivel de dicha dirección URL modificada de dicha petición de DNS modificada;
    -
    resolver, el servidor DNS autorizado del dominio de segundo nivel, dicha región de usuario final (región 1) a partir de el URL recibido y realizar una búsqueda en su base de datos y responder al sistema de resolución de DNS de ISP con la dirección IP del servidor DNS (DNS-R1) autorizado para la región de destino (región 1);
    -
    consultar, el sistema de resolución de DNS de ISP, a dicho servidor DNS (DNS-R1) autorizado para la región de destino (región 1) para resolver el URL recibido;
    -
    recibir, el servidor DNS (DNS-R1) autorizado para la región de destino (región 1), dicha petición de DNS modificada y reenviar dicha petición de DNS modificada al rastreador (rastreador-R1) de la región de usuario final (región 1);
    -
    reconocer, dicho rastreador (rastreador-R1) de la región de destino (región 1), que la petición es una petición de redirección, identificar una lista ordenada de nodos de extremo (NE-2-R1, NE-1-R1) que están menos cargados y más próximos al usuario final solicitante, y enviar dicha lista de nodos de extremo (NE-2-R1, NE-1-R1) al servidor DNS (DNS-R1) autorizado para la región de destino (región 1);
    -
    reenviar, el servidor DNS (DNS-R1) autorizado para la región de usuario final (región 1), la lista de nodos de extremo (NE-2-R1, NE-1-R1) recibida al sistema de resolución de DNS de ISP;
    -
    devolver, el sistema de resolución de DNS de ISP, la lista de nodos de extremo (NE-2-R1, NE-1-R1) al usuario final solicitante;
    -
    enviar, el usuario final, la petición de contenido como dicho URL modificado al nodo de extremo más próximo y menos cargado (NE-2-R1) según se indica en dicha lista de nodos de extremo (NE-2-R1, NE-1-R1), conteniendo el URL modificado la función hash del contenido, el ID de partición del usuario final y el ID de contenedor del contenido; y
    -
    proporcionar, dicho nodo de extremo más próximo y menos cargado (NE-2-R1), el contenido solicitado al usuario final.
  18. 18. Método según la reivindicación 1, que comprende una redirección intrarregional entre al menos dos centros de datos (centro de datos 1, centro de datos 2, centro de datos 3) en la misma región (región 1) de una
    23
    ES 2 425 626 A2
    unidad de negocio (OB1), dicha unidad de negocio (OB1) estando conectada a un servidor de nombres global, en el que:
    -
    dicho usuario final está geográficamente próximo a un primer centro de datos (centro de datos 1) de dichos al menos dos centros de datos (centro de datos 1, centro de datos 2, centro de datos 3),
    -
    siendo dicha subzona dicha región (región 1) en dicha unidad de negocio (OB1),
    -
    comprendiendo cada centro de datos (centro de datos 1, centro de datos 2, centro de datos 3) uno o más nodos de extremo (D1-1-R1, D1-2-R1; D2-1-R1, D2-2-R1; D3-1-R1, D3-2-R1);
    -
    dicho sistema de resolución de DNS de ISP está en dicha región (región 1), y
    -
    dicho al menos un nodo de extremo que puede proporcionar el contenido es un nodo de extremo (D3-2-R1) que se encuentra en dicha región (región 1) que está en dicho primer centro de datos (centro de datos 1).
  19. 19.
    Método según la reivindicación 18, en el que dicha fase de resolución de DNS de I) es una primera fase de resolución de DNS, dicha etapa d) comprende además enviar además, dicho nodo de extremo que participa en dicha primera fase de resolución de DNS (D3-1-R1), al usuario final, junto con una dirección URL modificada, las direcciones IP de al menos dicho al menos un nodo de extremo (D3-2-R1) que puede proporcionar el contenido según el orden del rastreador (rastreador-R1).
  20. 20.
    Método según la reivindicación 19, en el que dicha redirección HTTP de II) comprende además, tras dicha etapa d):
    -
    conectarse directamente, el usuario final, a dicho nodo de extremo (D3-2-R1) que puede proporcionar el contenido enviando una petición de conexión al mismo, con una dirección URL modificada que también identifica el contenido solicitado;
    -
    recibir, el nodo de extremo (D3-2-R1) que puede proporcionar el contenido, dicha dirección URL de petición de conexión, verificar el ID de partición basándose en la dirección IP del usuario final, modificar dicha dirección URL incluyendo dicho ID de partición de usuario final, y devolver dicha dirección URL modificada al usuario final como un mensaje de redirección HTTP;
    y comprendiendo el método además una segunda fase de resolución de DNS que comprende realizar las siguientes etapas:
    -
    enviar, el usuario final, una petición de DNS modificada que es la dirección URL modificada al sistema de resolución de DNS de ISP;
    -
    identificar, el sistema de resolución de DNS de ISP, dicha petición de DNS modificada destinada a dicha región (región 1) y consultar al servidor DNS autorizado (DNS-R1) en dicha región (región 1) para resolver el dominio de segundo nivel del URL recibido;
    -
    reenviar, dicho servidor DNS autorizado (DNS-R1), dicha petición de DNS modificada al rastreador (rastreador-R1) de dicha región (región 1);
    -
    reconocer, dicho rastreador de región de usuario final (rastreador-R1), que la petición es una petición de redirección intrarregional, identificar el nodo de extremo o nodos de extremo (D1-2-R1, D1-1-R1) que están mejor ubicados para proporcionar el contenido al usuario final solicitante, y enviar una lista ordenada que hace referencia a dichos nodos de extremo (D1-2-R1, D1-1-R1) al usuario final;
    -
    conectarse directamente, el usuario final, al nodo de extremo (D1-2-R1) menos cargado y más próximo al usuario final según se indica en dicha lista de nodos de extremo (D1-2-R1, D1-1-R1); y
    -
    proporcionar, dicho nodo de extremo menos cargado y más próximo (D1-2-R1), el contenido solicitado al usuario final.
    24
    ES 2 425 626 A2
    ES 2 425 626 A2
    ES 2 425 626 A2
    ES 2 425 626 A2
    ES 2 425 626 A2
    ES 2 425 626 A2
    FIG. 6
ES201130754A 2011-05-12 2011-05-12 Método para la resolución de dns de peticiones de contenido en un servicio cdn Withdrawn - After Issue ES2425626B1 (es)

Priority Applications (8)

Application Number Priority Date Filing Date Title
ES201130754A ES2425626B1 (es) 2011-05-12 2011-05-12 Método para la resolución de dns de peticiones de contenido en un servicio cdn
ES12725641.0T ES2550674T3 (es) 2011-05-12 2012-05-07 Método para la resolución de DNS de peticiones de contenido en un servicio CDN
US14/117,191 US9565157B2 (en) 2011-05-12 2012-05-07 Method for DNS resolution of content requests in a CDN service
EP12725641.0A EP2708013B1 (en) 2011-05-12 2012-05-07 A method for DNS resolution of content requests in a CDN service
PCT/EP2012/058395 WO2012152765A1 (en) 2011-05-12 2012-05-07 A method for dns resolution of content requests in a cdn service
BR112013029001-3A BR112013029001B1 (pt) 2011-05-12 2012-05-07 Método para resolução de dns de solicitações de conteúdo em um serviço de cdn
ARP120101646A AR086336A1 (es) 2011-05-12 2012-05-10 Metodo para la resolucion de dns de peticiones de contenido en un servicio cdn
CL2013003221A CL2013003221A1 (es) 2011-05-12 2013-11-11 Metodo para la resolucion de dns de peticiones de contenido en un servicio cdn.

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
ES201130754A ES2425626B1 (es) 2011-05-12 2011-05-12 Método para la resolución de dns de peticiones de contenido en un servicio cdn

Publications (3)

Publication Number Publication Date
ES2425626A2 ES2425626A2 (es) 2013-10-16
ES2425626R1 ES2425626R1 (es) 2013-10-22
ES2425626B1 true ES2425626B1 (es) 2014-06-05

Family

ID=46208439

Family Applications (2)

Application Number Title Priority Date Filing Date
ES201130754A Withdrawn - After Issue ES2425626B1 (es) 2011-05-12 2011-05-12 Método para la resolución de dns de peticiones de contenido en un servicio cdn
ES12725641.0T Active ES2550674T3 (es) 2011-05-12 2012-05-07 Método para la resolución de DNS de peticiones de contenido en un servicio CDN

Family Applications After (1)

Application Number Title Priority Date Filing Date
ES12725641.0T Active ES2550674T3 (es) 2011-05-12 2012-05-07 Método para la resolución de DNS de peticiones de contenido en un servicio CDN

Country Status (7)

Country Link
US (1) US9565157B2 (es)
EP (1) EP2708013B1 (es)
AR (1) AR086336A1 (es)
BR (1) BR112013029001B1 (es)
CL (1) CL2013003221A1 (es)
ES (2) ES2425626B1 (es)
WO (1) WO2012152765A1 (es)

Families Citing this family (104)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7991910B2 (en) 2008-11-17 2011-08-02 Amazon Technologies, Inc. Updating routing information based on client location
US8028090B2 (en) 2008-11-17 2011-09-27 Amazon Technologies, Inc. Request routing utilizing client location information
US8447831B1 (en) 2008-03-31 2013-05-21 Amazon Technologies, Inc. Incentive driven content delivery
US8321568B2 (en) 2008-03-31 2012-11-27 Amazon Technologies, Inc. Content management
US7970820B1 (en) 2008-03-31 2011-06-28 Amazon Technologies, Inc. Locality based content distribution
US8601090B1 (en) 2008-03-31 2013-12-03 Amazon Technologies, Inc. Network resource identification
US8606996B2 (en) 2008-03-31 2013-12-10 Amazon Technologies, Inc. Cache optimization
US8533293B1 (en) 2008-03-31 2013-09-10 Amazon Technologies, Inc. Client side cache management
US7962597B2 (en) 2008-03-31 2011-06-14 Amazon Technologies, Inc. Request routing based on class
US9912740B2 (en) 2008-06-30 2018-03-06 Amazon Technologies, Inc. Latency measurement in resource requests
US9407681B1 (en) 2010-09-28 2016-08-02 Amazon Technologies, Inc. Latency measurement in resource requests
US8073940B1 (en) 2008-11-17 2011-12-06 Amazon Technologies, Inc. Managing content delivery network service providers
US8122098B1 (en) 2008-11-17 2012-02-21 Amazon Technologies, Inc. Managing content delivery network service providers by a content broker
US8756341B1 (en) 2009-03-27 2014-06-17 Amazon Technologies, Inc. Request routing utilizing popularity information
US8688837B1 (en) 2009-03-27 2014-04-01 Amazon Technologies, Inc. Dynamically translating resource identifiers for request routing using popularity information
US8412823B1 (en) 2009-03-27 2013-04-02 Amazon Technologies, Inc. Managing tracking information entries in resource cache components
US8782236B1 (en) 2009-06-16 2014-07-15 Amazon Technologies, Inc. Managing resources using resource expiration data
US8397073B1 (en) 2009-09-04 2013-03-12 Amazon Technologies, Inc. Managing secure content in a content delivery network
US8433771B1 (en) 2009-10-02 2013-04-30 Amazon Technologies, Inc. Distribution network with forward resource propagation
US9495338B1 (en) 2010-01-28 2016-11-15 Amazon Technologies, Inc. Content distribution network
US8468247B1 (en) 2010-09-28 2013-06-18 Amazon Technologies, Inc. Point of presence management in request routing
US10958501B1 (en) 2010-09-28 2021-03-23 Amazon Technologies, Inc. Request routing information based on client IP groupings
US9003035B1 (en) 2010-09-28 2015-04-07 Amazon Technologies, Inc. Point of presence management in request routing
US9712484B1 (en) 2010-09-28 2017-07-18 Amazon Technologies, Inc. Managing request routing information utilizing client identifiers
US10097398B1 (en) 2010-09-28 2018-10-09 Amazon Technologies, Inc. Point of presence management in request routing
US8452874B2 (en) 2010-11-22 2013-05-28 Amazon Technologies, Inc. Request routing processing
US10467042B1 (en) 2011-04-27 2019-11-05 Amazon Technologies, Inc. Optimized deployment based upon customer locality
CN104011701B (zh) 2011-12-14 2017-08-01 第三雷沃通讯有限责任公司 内容传送网络系统和能够在内容传送网络中操作的方法
US10021179B1 (en) 2012-02-21 2018-07-10 Amazon Technologies, Inc. Local resource delivery network
US10623408B1 (en) 2012-04-02 2020-04-14 Amazon Technologies, Inc. Context sensitive object management
US9154551B1 (en) 2012-06-11 2015-10-06 Amazon Technologies, Inc. Processing DNS queries to identify pre-processing information
US9323577B2 (en) 2012-09-20 2016-04-26 Amazon Technologies, Inc. Automated profiling of resource usage
US10701149B2 (en) 2012-12-13 2020-06-30 Level 3 Communications, Llc Content delivery framework having origin services
US9634918B2 (en) 2012-12-13 2017-04-25 Level 3 Communications, Llc Invalidation sequencing in a content delivery framework
US9847917B2 (en) 2012-12-13 2017-12-19 Level 3 Communications, Llc Devices and methods supporting content delivery with adaptation services with feedback
US10791050B2 (en) 2012-12-13 2020-09-29 Level 3 Communications, Llc Geographic location determination in a content delivery framework
US10701148B2 (en) 2012-12-13 2020-06-30 Level 3 Communications, Llc Content delivery framework having storage services
US10652087B2 (en) 2012-12-13 2020-05-12 Level 3 Communications, Llc Content delivery framework having fill services
US20140337472A1 (en) 2012-12-13 2014-11-13 Level 3 Communications, Llc Beacon Services in a Content Delivery Framework
ES2552360T3 (es) 2012-12-19 2015-11-27 Telefónica, S.A. Método de comprobación de funcionamiento distribuido para almacenamiento en memoria caché web en una red de telecomunicaciones
US10205698B1 (en) 2012-12-19 2019-02-12 Amazon Technologies, Inc. Source-dependent address resolution
US10177967B2 (en) * 2013-03-15 2019-01-08 Jesse Lakes Redirection service resource locator mechanism
US9294391B1 (en) 2013-06-04 2016-03-22 Amazon Technologies, Inc. Managing network computing components utilizing request routing
US9722885B2 (en) 2013-08-08 2017-08-01 Level 3 Communications, Llc Content delivery methods and systems
US9380019B2 (en) * 2013-08-26 2016-06-28 Verisign, Inc. Command performance monitoring
CN103441906B (zh) * 2013-09-25 2016-08-24 哈尔滨工业大学 基于自主计算的代理缓存集群异常检测系统
US10530738B2 (en) * 2014-08-07 2020-01-07 Citrix Systems, Inc. DNS resolution replay for bare domain names that map to “A” records
US10769671B2 (en) * 2014-10-13 2020-09-08 Time Warner Cable Enterprises Llc Methods and apparatus for cross platform monitoring and customer targeting
US10097448B1 (en) 2014-12-18 2018-10-09 Amazon Technologies, Inc. Routing mode and point-of-presence selection service
US10091096B1 (en) 2014-12-18 2018-10-02 Amazon Technologies, Inc. Routing mode and point-of-presence selection service
US10033627B1 (en) 2014-12-18 2018-07-24 Amazon Technologies, Inc. Routing mode and point-of-presence selection service
DE102015101742B3 (de) * 2015-02-06 2016-06-09 Bundesdruckerei Gmbh Netzwerksystem und Verfahren zur Namensauflösung in einem Netzwerksystem
US10225326B1 (en) 2015-03-23 2019-03-05 Amazon Technologies, Inc. Point of presence based data uploading
US9887931B1 (en) 2015-03-30 2018-02-06 Amazon Technologies, Inc. Traffic surge management for points of presence
US9819567B1 (en) 2015-03-30 2017-11-14 Amazon Technologies, Inc. Traffic surge management for points of presence
US9887932B1 (en) 2015-03-30 2018-02-06 Amazon Technologies, Inc. Traffic surge management for points of presence
US9832141B1 (en) 2015-05-13 2017-11-28 Amazon Technologies, Inc. Routing based request correlation
US10616179B1 (en) 2015-06-25 2020-04-07 Amazon Technologies, Inc. Selective routing of domain name system (DNS) requests
US10097566B1 (en) 2015-07-31 2018-10-09 Amazon Technologies, Inc. Identifying targets of network attacks
US9900744B2 (en) * 2015-08-03 2018-02-20 At&T Intellectual Property I, L.P. Location based provisioning and broadcasting of content utilizing a multimedia broadcast service
US9774619B1 (en) 2015-09-24 2017-09-26 Amazon Technologies, Inc. Mitigating network attacks
US9794281B1 (en) 2015-09-24 2017-10-17 Amazon Technologies, Inc. Identifying sources of network attacks
US10270878B1 (en) 2015-11-10 2019-04-23 Amazon Technologies, Inc. Routing for origin-facing points of presence
US10049051B1 (en) 2015-12-11 2018-08-14 Amazon Technologies, Inc. Reserved cache space in content delivery networks
US10257307B1 (en) 2015-12-11 2019-04-09 Amazon Technologies, Inc. Reserved cache space in content delivery networks
US10348639B2 (en) 2015-12-18 2019-07-09 Amazon Technologies, Inc. Use of virtual endpoints to improve data transmission rates
EP3391628B1 (en) * 2015-12-18 2021-08-25 Amazon Technologies, Inc. Use of virtual endpoints to improve data transmission rates
US10728301B1 (en) * 2015-12-21 2020-07-28 Highwinds Holdings, Inc. Cryptographic content delivery network
US10015086B2 (en) * 2016-04-29 2018-07-03 Intuit Inc. Multi GTM based routing to avoid latencies
US10075551B1 (en) 2016-06-06 2018-09-11 Amazon Technologies, Inc. Request management for hierarchical cache
US10110694B1 (en) 2016-06-29 2018-10-23 Amazon Technologies, Inc. Adaptive transfer rate for retrieving content from a server
US10375154B2 (en) 2016-07-29 2019-08-06 Microsoft Technology Licensing, Llc Interchangeable retrieval of content
US9992086B1 (en) 2016-08-23 2018-06-05 Amazon Technologies, Inc. External health checking of virtual private cloud network environments
US10033691B1 (en) 2016-08-24 2018-07-24 Amazon Technologies, Inc. Adaptive resolution of domain name requests in virtual private cloud network environments
CN106372155A (zh) * 2016-08-30 2017-02-01 福建中金在线信息科技有限公司 一种过滤网页链接的方法及装置
US10693947B2 (en) 2016-09-09 2020-06-23 Microsoft Technology Licensing, Llc Interchangeable retrieval of sensitive content via private content distribution networks
US10469513B2 (en) 2016-10-05 2019-11-05 Amazon Technologies, Inc. Encrypted network addresses
US10320817B2 (en) * 2016-11-16 2019-06-11 Microsoft Technology Licensing, Llc Systems and methods for detecting an attack on an auto-generated website by a virtual machine
US10831549B1 (en) 2016-12-27 2020-11-10 Amazon Technologies, Inc. Multi-region request-driven code execution system
US10372499B1 (en) 2016-12-27 2019-08-06 Amazon Technologies, Inc. Efficient region selection system for executing request-driven code
US10938884B1 (en) 2017-01-30 2021-03-02 Amazon Technologies, Inc. Origin server cloaking using virtual private cloud network environments
US10728206B2 (en) 2017-03-22 2020-07-28 Citrix Systems, Inc. Method for DNS response reordering based on path quality and connection priority for better QOS
US10503613B1 (en) 2017-04-21 2019-12-10 Amazon Technologies, Inc. Efficient serving of resources during server unavailability
US11075987B1 (en) 2017-06-12 2021-07-27 Amazon Technologies, Inc. Load estimating content delivery network
US10447648B2 (en) 2017-06-19 2019-10-15 Amazon Technologies, Inc. Assignment of a POP to a DNS resolver based on volume of communications over a link between client devices and the POP
CN107517248B (zh) * 2017-08-09 2021-01-29 苏州驰声信息科技有限公司 基于sdk的网络连接方法及装置
US10924579B2 (en) * 2017-08-14 2021-02-16 Level 3 Communications, Llc System and method for metro mid-tier mapping in a content delivery network
US10742593B1 (en) 2017-09-25 2020-08-11 Amazon Technologies, Inc. Hybrid content request routing system
WO2019061522A1 (zh) * 2017-09-30 2019-04-04 深圳前海达闼云端智能科技有限公司 域名解析方法、客户端、边缘节点及域名解析系统
US10536429B2 (en) * 2017-10-09 2020-01-14 Level 3 Communications, Llc Conveying information in hostname in a content delivery network (CDN)
CN108234639A (zh) * 2017-12-29 2018-06-29 北京奇虎科技有限公司 一种基于内容分发网络cdn的数据访问方法和装置
CN108093078B (zh) * 2017-12-29 2020-10-16 北京长御科技有限公司 一种文档的安全流转方法
US10592578B1 (en) 2018-03-07 2020-03-17 Amazon Technologies, Inc. Predictive content push-enabled content delivery network
US11025589B1 (en) * 2018-08-31 2021-06-01 Cisco Technology, Inc Location-independent data-object name mapping
US10862852B1 (en) 2018-11-16 2020-12-08 Amazon Technologies, Inc. Resolution of domain name requests in heterogeneous network environments
US11025747B1 (en) 2018-12-12 2021-06-01 Amazon Technologies, Inc. Content request pattern-based routing system
FR3091097A1 (fr) * 2018-12-19 2020-06-26 Orange Procédé d’acquisition d’une chaîne de délégation relative à la résolution d’un identifiant de nom de domaine dans un réseau de communication
US11102136B2 (en) * 2019-07-15 2021-08-24 International Business Machines Corporation Automated cache buckets using mirrors for content distribution networks (CDN)
US10812442B1 (en) 2019-09-23 2020-10-20 Citrix Systems, Inc. Intelligent redirector based on resolver transparency
CN110636150B (zh) * 2019-10-24 2023-04-18 北京小米移动软件有限公司 域名解析方法、域名解析装置及存储介质
CN111147546B (zh) * 2019-11-29 2021-05-14 中科院计算技术研究所大数据研究院 一种边缘集群资源的处理方法及系统
CN112149008B (zh) * 2020-09-18 2022-09-23 四川工商学院 一种文档版本集合的计算方法
CN112491639B (zh) * 2020-09-29 2022-10-18 南京大学 一种基于域名解析的任播区域划分测量方法
US12003600B2 (en) 2022-06-21 2024-06-04 Oxylabs, Uab Network coordination between proxy servers

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7143170B2 (en) * 2003-04-30 2006-11-28 Akamai Technologies, Inc. Automatic migration of data via a distributed computer network
US20100223364A1 (en) * 2009-02-27 2010-09-02 Yottaa Inc System and method for network traffic management and load balancing
US20110078230A1 (en) * 2009-09-25 2011-03-31 Emilio Sepulveda Method and system for providing a cdn with granular quality of service
DE102015101742B3 (de) * 2015-02-06 2016-06-09 Bundesdruckerei Gmbh Netzwerksystem und Verfahren zur Namensauflösung in einem Netzwerksystem

Also Published As

Publication number Publication date
CL2013003221A1 (es) 2014-08-01
US9565157B2 (en) 2017-02-07
BR112013029001B1 (pt) 2022-11-22
US20150288647A1 (en) 2015-10-08
WO2012152765A1 (en) 2012-11-15
ES2550674T3 (es) 2015-11-11
EP2708013A1 (en) 2014-03-19
ES2425626A2 (es) 2013-10-16
AR086336A1 (es) 2013-12-04
BR112013029001A2 (pt) 2017-01-17
ES2425626R1 (es) 2013-10-22
EP2708013B1 (en) 2015-07-22

Similar Documents

Publication Publication Date Title
ES2425626B1 (es) Método para la resolución de dns de peticiones de contenido en un servicio cdn
ES2425627B1 (es) Método y rastreador para distribución de contenido a través de una red de distribución de contenido
US10706029B2 (en) Content name resolution for information centric networking
D'Ambrosio et al. MDHT: A hierarchical name resolution service for information-centric networks
EP2721787B1 (en) Principal-identity-domain based naming scheme for information centric networks
US7339937B2 (en) Wide-area content-based routing architecture
Dannewitz et al. Hierarchical DHT-based name resolution for information-centric networks
CN103618801B (zh) 一种p2p资源共享的方法、设备及系统
ES2410654B1 (es) Sistema y método para gestionar la infraestructura de un servicio de red de distribución de contenido en una red isp
ES2770652T3 (es) Sistema y método para interconexión de redes de distribución de contenido
Shue et al. An Internet without the Internet protocol
Menth et al. Mapping systems for Loc/ID split Internet routing
Sarddar et al. Edge multilevel edge server co-operation in content delivery network using hierarchical classification
Sudrajat The state of adoption of DNS ECS extension on the internet
EP3123690B1 (en) Data retrieval
Elbreiki et al. A Comparative Study of Chord and Pastry for the Name Resolution System Implementation in Information Centric Networks
Kondo et al. ZINK: An efficient information centric networking utilizing layered network architecture
Shue A better internet without ip addresses
Hartmann A Survey of Mapping Systems for Locator/Identifier Split Internet Routing

Legal Events

Date Code Title Description
FG2A Definitive protection

Ref document number: 2425626

Country of ref document: ES

Kind code of ref document: B1

Effective date: 20140605

FA2A Application withdrawn

Effective date: 20141014