BR112013029001B1 - Método para resolução de dns de solicitações de conteúdo em um serviço de cdn - Google Patents

Método para resolução de dns de solicitações de conteúdo em um serviço de cdn Download PDF

Info

Publication number
BR112013029001B1
BR112013029001B1 BR112013029001-3A BR112013029001A BR112013029001B1 BR 112013029001 B1 BR112013029001 B1 BR 112013029001B1 BR 112013029001 A BR112013029001 A BR 112013029001A BR 112013029001 B1 BR112013029001 B1 BR 112013029001B1
Authority
BR
Brazil
Prior art keywords
dns
region
endpoint
content
request
Prior art date
Application number
BR112013029001-3A
Other languages
English (en)
Other versions
BR112013029001A2 (pt
Inventor
Armando Antonio García Mendoza
Alvaro SAURÍN PARRA
Parminder Chhabra
Carmelo ACOSTA OJEDA
Pedro Rodríguez Rodríguez
Original Assignee
Telefonica S.A.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonica S.A. filed Critical Telefonica S.A.
Publication of BR112013029001A2 publication Critical patent/BR112013029001A2/pt
Publication of BR112013029001B1 publication Critical patent/BR112013029001B1/pt

Links

Images

Classifications

    • 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/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • 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)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

MÉTODO PARA RESOLUÇÃO DE DNS DE SOLICITAÇÕES DE CONTEÚDO EM UM SERVIÇO DE CDN. Um método para resolução de DNS de solicitações de conteúdo em um serviço de CDN Compreende a identificação de um ponto terminal ou servidor de conteúdo que pode servir melhor um usuário final que enviou uma solicitação de DNS a um resolvedor de DNS de IPS, dada uma rede geograficamente distribuída de pontos terminais. Em particular, o método ainda compreende a utilização dos pontos terminais por si só e um rastreador para identificar e notificar ao usuário final os endereços de IP dos pontos terminais menos carregados e mais próximos que podem servir melhor a solicitação de conteúdo.

Description

CAMPO DA TÉCNICA
A presente invenção se refere, de modo geral, a um método para resolução de DNS de solicitações de conteúdo em um serviço de CDN, compreendendo a identificação de um ponto terminal ou servidor de conteúdo que pode servir melhor um usuário final e, mais particularmente, a um método no qual os pontos terminais por si só colaboram na dita resolução de DNS.
TÉCNICA ANTERIOR
A seguir, a terminologia e definições que poderiam ser úteis para entender a presente invenção são incluídas.
PoP: Um ponto de presença é uma demarcação artificial ou ponto de interface entre duas entidades de comunicação. É um ponto de acesso à Internet que hospeda servidores, alternadores, roteadores e agregadores de chamada. ISPs têm tipicamente múltiplos PoPs.
Sistema Autônomo (AS): Um sistema autônomo é uma coleção de prefixos de roteamento de IP que estão sob o controle de um ou mais operadores de rede e apresentam uma política de roteamento claramente definida, comum para a Internet.
OB (Entidade operacional): Uma OB é uma área geográfica arbitrária na qual a CDN de provedor de serviços é instalada. Uma OB pode operar em mais de uma região. Uma região é uma área geográfica arbitrária e pode representar um país, ou parte de um país ou mesmo um conjunto de países. Uma OB pode consistir em mais de uma região. Uma OB pode ser composta de um ou mais ISPs. Uma OB tem exatamente um caso de Servidor de Topologia. PID (ID de partição): Isso é meramente um mapeamento de prefixos de IP no nível de AS em inteiros.
Esse é um mapeamento um a um. Esse é uma partição muito grosseira dos prefixos de IP. DNS (Serviço de Nome de Domínio): DNS é um serviço que traduz nomes de domínio em endereços de IP. A resolução de DNS é hierárquica. Se um servidor de DNS não souber como traduzir um nome de domínio, ele solicita que outros servidores de DNS iniciem com o servidor de DNS raiz até que encontre o servidor de DNS que pode resolver o nome de domínio.
Rede de Liberação de Conteúdo (CDN): Isso se refere a um sistema de nós (ou computadores) que contém cópias de conteúdo de cliente que é armazenado e colocado em diversos pontos em uma rede (ou Internet pública). Quando o conteúdo for replicado em diversos pontos na rede, amplitude de banda é mais bem utilizada ao longo de toda a rede e os usuários têm tempos de acesso mais rápidos para o conteúdo. Dessa forma, o servidor de origem que mantém a cópia original do conteúdo não é um afunilamento.
Redirecionamento de DNS: Essa é uma prática de redirecionamento da resolução dos nomes do Sistema de Nome de Domínio para outros servidores de DNS. Em uma CDN, essa prática é utilizada para direcionar as solicitações de usuário final aos pontos terminais que estão em proximidade estrita aos usuários finais solicitantes.
Resolvedor de DNS de ISP: Os usuários residenciais se conectam a um ISP. Qualquer solicitação para resolver um endereço é enviada a um resolvedor de DNS mantido pelo ISP. O resolvedor de DNS de IPS enviará a solicitação de DNS a um ou mais servidores de DNS dentro do domínio administrativo de ISP.
URL: Colocado Simplesmente, Localizador de Recurso Uniforme (URL) é o endereço de uma página da web na web mundial. Nenhum de dois URLs são exclusivos. Se forem idênticos, eles apontam para o mesmo recurso.
Redirecionamento de URL (ou HTTP): O redirecionamento de URL também é conhecido como encaminhamento de URL. Uma página pode precisar de redirecionamento, se seu nome de domínio mudou, criando pseudônimos significativos para URLs longos ou que mudam frequentemente, soletrando erros do usuário ao digitar um nome de domínio, manipulando visitantes etc. Para o objetivo da presente invenção, um serviço de redirecionamento típico é um que redireciona os usuários ao conteúdo desejado. Um link de redirecionamento pode ser utilizado como um endereço permanente para o conteúdo que muda frequentemente de sistemas centrais (muito como DNS)...
Bucket: Um bucket é um contentor lógico para um cliente que mantém o conteúdo do cliente de CDN. Um bucket faz uma ligação entre o URL de servidor de origem e URL de CDN ou pode conter o conteúdo por si só (que é feito upload no bucket no ponto de entrada). Um ponto terminal replicará arquivos do servidor de origem em arquivos no bucket. Cada arquivo em um bucket pode ser mapeado exatamente em um arquivo no servidor de origem. Um bucket tem diversos atributos associados a ele - momento inicial e momento até o conteúdo ser válido, bloqueamento geográfico do conteúdo etc. Mecanismos também são implementados para garantir que novas versões do conteúdo no servidor de origem sejam colocados no bucket nos pontos terminais e versões antigas sejam removidas.
Um cliente de CDN de provedor de serviços pode criar quantos buckets desejar. Um bucket é, na realidade, um diretório que contém arquivos de conteúdo. Um bucket pode conter subdiretórios e arquivos de conteúdo dentro de cada um dos subdiretórios.
Localização geográfica: É a identificação da localização geográfica do mundo real de um dispositivo conectado à Internet. O dispositivo pode ser um computador, dispositivo móvel ou um mecanismo que permite a conexão à Internet para um usuário final. Os dados de localização geográfica de endereço de IP podem incluir informações, como país, região, cidade, código postal, latitude/longitude de um usuário.
Função hash consistente: Esse método provê funcionalidade de tabela hash de modo que a adição ou remoção de uma abertura não altera significativamente o mapeamento de chaves para as aberturas. A função hash consistente é uma maneira de distribuir solicitações entre uma população grande e alternante de servidores da web. A adição ou remoção de um servidor da web não altera significativamente a carga dos outros servidores.
MD5: Em criptografia, MD5 é uma função criptográfica amplamente utilizada com um valor de hash de 128 bits. MD5 é amplamente utilizada para testar a integridade dos arquivos. MD5 é tipicamente expressa como um número hexadecimal.
DSLAM: Um DSLAM é um dispositivo de rede que reside em uma troca telefônica de um provedor de serviços. Ele conecta múltiplas Linhas de Assinatura Digital (DSLs) de cliente a um sistema central de Internet de alta velocidade utilizando multiplexagem. Isso permite que as linhas telefônicas façam uma conexão mais rápida à Internet. Tipicamente, um DSLAM serve diversas centenas de residentes (não mais que poucos milhares de residentes no máximo).
DNS é uma convenção de nomeação hierárquica para computadores, serviços ou qualquer recurso conectado à Internet [1]. O Sistema de Nome de Domínio distribui a responsabilidade de atribuir nomes de domínio a grupos de usuários e organizações independente de sua localização física de maneira significativa. Isso se faz ao designar servidores de nome de autoridade para cada domínio (por exemplo, com, edu, net etc.). Esses servidores de nome de autoridade podem designar outros servidores de autoridade para seus subdomínios [1]. Isso torna o DNS distribuído e tolerante à falhas.
Outra funcionalidade principal do DNS é que ele traduz nomes de computador de hospedagem comuns aos humanos em endereços de IP. Qualquer serviço de CDN utiliza DNS como uma maneira de localizar seus servidores de conteúdo em resposta às solicitações de usuário final. O DNS tem suas limitações ao designar uma solução de distribuição de conteúdo uma vez que, de maneira ideal, a infraestrutura de CDN não tem de identificar o servidor de conteúdo que está mais próximo ao usuário final e não é muito carregado.
A função hash consistente é comumente utilizada como uma maneira de distribuir conteúdo entre máquinas em um centro de dados. A função hash consistente, como função de hash simples, difunde um dicionário distribuído de maneira bastante uniforme em um cluster. Entretanto, diferente da função hash simples, a função hash consistente precisa somente que uma pequena quantidade de dados seja movimentada no caso de adição/remoção de máquinas de um cluster [1][7][8].
A localização do servidor de conteúdo mais próximo e menos carregado para um usuário final solicitante liberar o conteúdo é um problema bem conhecido. As soluções típicas incluem a utilização de uma hierarquia de servidores de DNS junto a uma base de dados de IP geográfico para identificar o servidor de conteúdo mais próximo (como em [1][2]) a um usuário final solicitante e utilizar o servidor para liberar o conteúdo. Por exemplo, uma empresa xyz.com que é um cliente de um provedor de CDN, Akamai, pode resolver para a123.g.akamai.net no servidor de nomes do provedor de CDN. Assim, uma busca por akamai.net pelo resolvedor de DNS de IPS retorna um endereço de IP para o domínio de nível superior (TLD) de akamai.net. Depois, uma busca por g.akamai.net retorna um IP para o servidor de DNS de segundo nível, mais próximo ao resolvedor de DNS de IPS do usuário final. O resolvedor de DNS de IPS então busca por a123.g.akamai.net. Essa busca retorna o endereço de IP do servidor de conteúdo que pode servir o conteúdo solicitado ao usuário final. A resolução de DNS consiste em duas etapas. Na primeira etapa, o servidor de DNS de TLD identifica a região ou país ao qual o resolvedor de DNS de IPS pertence. Ele retorna o endereço de IP do servidor de DNS mais próximo (DNS de segundo nível). A segunda solicitação de DNS (ao domínio de segundo nível servidor de DNS) identifica o ponto terminal (ou servidor de conteúdo) que pode servir melhor o conteúdo solicitado. Essa solução de CDN pode ser implementada profundamente em uma rede de ISP. O serviço de provedor de CDN pode ser limitado por quão profundo na rede um ISP está desejando permitir que esse sistema seja implementado (e pode ser restrito à implementação nos pontos de troca de tráfego ou dentro de um AS ou em uma ou mais localizações em um país). Assim, o conteúdo pode ter de passar através de diversos saltos dentro de um país antes de atingir o usuário final solicitante.
Outras soluções, como [1][3], contam com um pequeno número de grandes centros de dados ou [1][6] um grande número de pequenos centros de dados conectados por uma rede provada bem provisionada para primeiro identificar um centro de dados que está mais próximo ao usuário final solicitante. Uma vez que o centro de dados é identificado, um ponto terminal no centro de dados é identificado para liberar o conteúdo. Uma vez que esses centros de dados se conectam à Internet em um pequeno número de pontos de troca de tráfego, o conteúdo ainda tem de passar através de diversos saltos antes de atingir um usuário final solicitante. Ainda, [5] contam com armazenamento extensivo e infraestrutura de cache nos pontos de troca de tráfego mais importantes. Amazon [4] provê serviço de CDN utilizando o Amazon Cloudfront junto a seu serviço de armazenamento simples, permitindo que os usuários finais obtenha dados de diversas localizações de margem da Internet com as quais a Amazon troca de tráfego.
Dentre as soluções acima, [2] e [3] contem estritamente com uma hierarquia de servidores de DNS para identificar o ponto terminal que pode servir o conteúdo a um usuário final solicitante. Entretanto, Limelight difere de Akamai em que ele deixa seus clientes utilizarem diretamente nomes de computador de hospedagem da Limelight em seus próprios sites da web. Por exemplo, em [1][9], Amazon incorpora diretamente os subnomes de computador de hospedagem de Limelight da forma amazon-xxx.vo.llnwd.net (xxx é um inteiro). O bucket amazon-xxx (que mantém o conteúdo da Amazon) pode ser replicado em diferentes nós dentro do mesmo centro de dados e em múltiplos centros de dados na rede da Limelight. As outras soluções ([4] - [6], conforme discutido acima) utilizam uma combinação de DNS e redirecionamento para identificar o servidor de conteúdo. O redirecionamento pode ter a forma de redirecionamento de DNS ou redirecionamento de HTTP. No primeiro caso, envolve redirecionar a solicitação de DNS a outros servidores de DNS. No último caso, um novo endereço de redirecionamento é enviado como parte da resposta de HTTP.
Todas as soluções discutidas até o momento ([2] e [3]-[6]) na identificação do ponto terminal para servir conteúdo utilizam balanceadores de carga de hardware para balancear a carga de DNS no DNS de segundo nível. Além disso, nas ditas soluções, os pontos terminais não são envolvidos no processo de identificação do ponto terminal que está mais bem localizado para liberar o conteúdo.
Assim, todas as ditas soluções têm as desvantagens ou as limitações de DNS, de não permitir identificar rapidamente o ponto terminal (ou servidor de conteúdo) que pode servir melhor um usuário final, dada uma rede geograficamente distribuída de pontos terminais, são superadas.
DESCRIÇÃO DA INVENÇÃO
É necessário oferecer uma alternativa à técnica anterior que cubra as lacunas nela encontradas, particularmente, que as relacionadas às limitações de DNS de identificar rapidamente o ponto terminal (ou servidor de conteúdo) que pode servir melhor um usuário final, dada uma rede geograficamente distribuída de pontos terminais, sejam superadas. Para este fim, a presente invenção se refere a um método para resolução de DNS de solicitações de conteúdo em um serviço de CDN, compreendendo a identificação de um ponto terminal ou servidor de conteúdo que pode servir melhor um usuário final que enviou uma solicitação de DNS a um resolvedor de DNS de IPS, dada uma rede geograficamente distribuída de pontos terminais.
De maneira diferente das propostas convencionais, no método da invenção, a resolução de DNS é realizada, de maneira característica, ao realizar: I) um estágio de resolução de DNS, compreendendo a realização das seguintes etapas: a) o dito resolvedor de DNS de IPS enviando a solicitação de DNS recebida a um servidor de DNS de autoridade de uma subzona, seja previamente conhecido ou identificado ao enviar uma solicitação ao servidor de DNS raiz do domínio solicitado; b) o dito servidor de DNS de autoridade de subzona, uma vez identificado, encaminhando a dita solicitação de DNS ao rastreador que opera na dita subzona, e o dito rastreador encaminhando a solicitação de DNS a um dos ditos pontos terminais que participam no dito estágio de resolução de DNS; e 11) um redirecionamento de HTTP, compreendendo a realização das seguintes etapas: c) resolução, pelo dito ponto terminal que participa no dito estágio de resolução de DNS, da localização do resolvedor de DNS de IPS por meio de uma base de dados de ID de partição para identificar: - o centro de dados que pode servir melhor o conteúdo; ou - pelo menos um ponto terminal no mesmo centro de dados que pode servir o conteúdo; e d) realização, pelo dito ponto terminal que participa no dito estágio de resolução de DNS, de um hash consistente no URL solicitado associado à dita solicitação de DNS, construindo um endereço utilizando um sub-sequência de comando da MD5 de hash da solicitação de conteúdo e a localização do dito centro de dados que pode servir melhor o conteúdo ou a localização do dito pelo menos um ponto terminal no mesmo centro de dados que pode servir o conteúdo, e enviando o dito endereço ao usuário final, diretamente ou por meio de entidades intermediárias, utilizando uma mensagem de redirecionamento.
Para uma realização, o método da invenção é aplicado a uma resolução de DNS ao longo de somente uma região de uma Entidade operacional (OB), a dita subzona é a dita uma região, o dito estágio de resolução de DNS de I) é um primeiro estágio de resolução de DNS, a dita mensagem de redirecionamento sendo uma mensagem de redirecionamento de HTTP, e o método ainda compreendendo um segundo estágio de resolução de DNS compreendendo a realização das seguintes etapas: e) fazer, pelo usuário final, uma solicitação de resolução de endereço, para o dito endereço recebido, ao dito resolvedor de DNS de IDP; f) encaminhar, pelo servidor de DNS de ISP, a dita solicitação de resolução de endereço ao dito servidor de DNS de autoridade de subzona; g) identificar, pelo servidor de DNS de autoridade de subzona, pelo menos o dito centro de dados que pode servir melhor o conteúdo indicado no dito endereço e um rastreador que pode resolver o endereço recebido, e envia a solicitação de resolução de endereço ao dito rastreador; h) realizar, pelo dito rastreador, um hash consistente no dito sub-sequência de comando do hash de URL para obter o ponto terminal ou pontos terminais, dentro do dito centro de dados, que pode servir melhor a solicitação; i) enviar, pelo rastreador, uma resposta incluindo um endereço de pelo menos um dos ditos pontos terminais obtidos ao servidor de DNS de autoridade de subzona; j) enviar, pelo servidor de DNS de autoridade de subzona, a dita resposta de rastreador ao resolvedor de DNS de IPS; e k) enviar, pelo resolvedor de DNS de IPS, a dita resposta de rastreador ao usuário final.
Para uma realização, a dita etapa h) ainda compreende a identificação, pelo rastreador, do ponto terminal menos carregado no dito centro de dados mais próximo, ao utilizar informações sobre a carga atual nos ditos pontos terminais obtidos, como o ponto terminal que pode servir melhor o conteúdo, e incluindo endereço somente do dito ponto terminal menos carregado na dita resposta de rastreador enviada na etapa i).
Por meio do método da invenção, o rastreador age como um balanceador de carga ao distribuir carga aos pontos terminais, o último sendo envolvido no processo de identificação do ponto terminal que está mais bem localizado para liberar o conteúdo.
Uma vez que o usuário final recebeu a resposta de rastreador, o método compreende, após a dita etapa j), a tentativa, pelo usuário final, de se conectar diretamente ao dito ponto terminal menos carregado esse endereço é incluído na resposta de rastreador, ao enviar uma solicitação de conexão a ele, na forma de um endereço de URL, incluindo o dito endereço construído e um identificador do conteúdo solicitado.
Para uma realização do método da invenção, a dita etapa b) compreende o dito rastreador utilizar pelo menos um esquema em sequência ou um esquema de geolocalização de melhor desempenho para corresponder à solicitação de DNS com o ponto terminal que participa no dito estágio de resolução de DNS dos ditos pontos terminais.
Como a identificação prévia, mencionada acima, do servidor de DNS de autoridade da dita subzona é tratada, a dita identificação é realizada, para uma realização, por meio de uma pesquisa geográfica de IP.
De acordo com uma realização, a dita pesquisa geográfica de IP é realizada em um servidor de DNS de autoridade para um domínio de segundo nível, como ao realizar as seguintes etapas: servidor de DNS de domínio de nível superior para resolver um domínio de segundo nível do endereço da dita solicitação de DNS; - o servidor de DNS de domínio de nível superior resolvendo a consulta de DNS de ISP com o endereço de IP do dito servidor de DNS de autoridade para o dito domínio de segundo nível; - o resolvedor de DNS de IPS buscando o dito servidor de DNS de autoridade para o dito domínio de segundo nível resolver a dita solicitação de DNS; e - o servidor de DNS de autoridade para o dito domínio de segundo nível resolvendo a subzona por meio da dita pesquisa geográfica de IP, e respondendo ao resolvedor de DNS de IPS com o endereço da dita subzona.
Para uma realização, a resposta de rastreador contém uma lista de endereços de parte ou de todos os pontos terminais incluídos no dito centro de dados mais próximo.
A dita etapa h) ainda compreende, para uma realização, a identificação, pelo rastreador, de pontos terminais de backup, fora do dito centro de dados mais próximo, que podem servir a solicitação, se necessário, a dita lista da dita resposta de rastreador também contendo endereços dos ditos pontos terminais de backup.
O dito centro de dados mais próximo é um centro de dados local e os ditos pontos terminais de backup pertencem a centros de dados nacionais e/ou global, de acordo com uma realização.
Para as ditas realizações nas quais a resposta de rastreador inclui a dita lista de pontos terminais, o método compreende, após a etapa j), tentativa, pelo usuário final, de conectar diretamente a um dos pontos terminais do centro de dados mais próximo e se não puder obter conteúdo dele, tentativa de se conectar a um dos pontos terminais de backup incluídos na dita lista.
Outras realizações do método da invenção são descritos com referência às reivindicações anexas 13 a 21 e, em uma seção subsequente relacionada à descrição detalhada de diversas realizações, incluindo realizações referente a redirecionamentos inter-região e intra-região, onde o segundo estágio de resolução de DNS mencionado acima é realizado por meio de etapas diferentes das descritas acima para a realização relacionada a uma resolução de DNS ao longo de somente uma região de uma OB.
BREVE DESCRIÇÃO DOS DESENHOS
As vantagens e aspectos anteriores e outros se tornarão mais completamente entendidos a partir da seguinte descrição detalhada das realizações, com referência aos desenhos anexos, que devem ser considerados de maneira ilustrativa e não limitante, nos quais:
A Figura 1 apresenta a resolução de DNS do método da invenção, para uma realização relacionada a uma resolução de DNS ao longo de somente uma região de uma OB. Uma vez que o DNS é resolvido ao servidor de DNS de autoridade para o subdomínio “es”, o processo de resolução de endereço vincula duas pesquisas de DNS e um redirecionamento de HTTP.
A Figura 2 apresenta outra realização do método da invenção, para um cenário de exemplo da resolução de DNS que envolve uma hierarquia de três níveis de centros de dados.
A Figura 3 apresenta um toque de hash consistente que mapeia conteúdo (URLs) e recursos (máquinas) a um circulo de unidade. O conteúdo é mapeado às máquinas ao executar uma trajetória anti-horário até que servidores primários, secundários e terciários sejam identificados.
A Figura 4 apresenta a resolução de DNS do método da invenção para uma realização referente a uma resolução de DNS com redirecionamento entre regiões entre duas Entidades Operacionais;
A Figura 5 apresenta outra realização do método da invenção, para um cenário de exemplo de resolução de DNS com redirecionamento entre regiões entre duas regiões da mesma entidade operacional; e
A Figura 6 apresenta a resolução de DNS do método da invenção para uma realização referente a uma resolução de DNS com redirecionamento intra-região entre os centros de dados da mesma OB.
DESCRIÇÃO DETALHADA DAS DIVERSAS REALIZAÇÕES
O funcionamento do DNS de um serviço de provedor de CDN será, agora, descrito em detalhes. Servidores de conteúdo são tipicamente colocados em centros de dados que são dispostos de maneira hierárquica. No nível mais baixo, um provedor de CDN serve conteúdo por meio de centros de dados no nível da cidade ou região (por exemplo, um centro de dados em Madri para servir todos de Madri, um centro de dados em Barcelona para servir todos da Catalunha), no nível de país (por exemplo, um centro de dados em Madri que age como uma cópia de segurança de todo o conteúdo na Espanha) e, por fim, no nível global (por exemplo, um centro de dados em Londres que age como uma cópia de segurança para todo o conteúdo para o serviço de provedor de CDN). De maneira alternativa, outro exemplo de uma hierarquia pode ser como segue: ser mais próximo aos usuários finais, um provedor de CDN pode implementar pontos terminais nas mesmas premissas que o computador de hospedagem dos DSLAMs no nível de local, servir conteúdo de um centro de dados no nível de país (por exemplo, um centro de dados em Madri que age como uma cópia de segurança no nível nacional para o conteúdo servido dos DSLAMs na Espanha) e, por fim, um centro de dados em Londres agindo como um centro de dados global.
Se a infraestrutura de CDN for incapaz de servir o conteúdo de seu centro de dados no nível de local, ela pode volta atrás no centro de dados no nível nacional. Se o centro de dados no nível nacional for incapaz de servir o conteúdo solicitado, ele pode voltar atrás no centro de dados global para servir o conteúdo. Uma desvantagem dessa abordagem é que o operador de CDN ficará sujeito a um custo de tráfego para enviar dados de um centro de dados global.
Cada componente do subsistema do serviço de provedor de CDN é descrito a seguir. A infraestrutura consiste em Servidores de Origem, Rastreadores, Pontos Terminais, Servidor de Topologia, servidor de DNS e Ponto de entrada.
Ponto de Publicação (Ponto de entrada): Qualquer cliente de CDN pode interagir com a infraestrutura de serviço de provedor de CDN somente por meio do ponto de publicação (algumas vezes, também mencionado como ponto de entrada para simplicidade). O ponto de publicação executa em uma interface de serviços da web com os usuários de contas registradas para criar/apagar e atualizar os buckets.
Um cliente de CDN tem duas opções para atualizar o conteúdo. O cliente pode fazer upload de arquivos no bucket ou dar URLs dos arquivos de conteúdo que residem no site da web do cliente de CDN. Uma vez que o conteúdo é baixado pela infraestrutura de CDN, os arquivos são movimentados para outro diretório para processamento posterior. As etapas de processamento posterior envolvem a verificação dos arquivos para consistência e quaisquer erros...
Ponto terminal: Um ponto terminal é a entidade que administra a comunicação entre usuários finais e a infraestrutura de CDN. É essencialmente um servidor de HTTP pessoal. Além disso, os pontos terminais mantêm uma base de dados de IP geográfico e tabela de uma lista de centros de dados.
Rastreador: O rastreador é a entidade principal que permite a inteligência e coordenação da infraestrutura de serviço de provedor de CDN. A fim de fazer isso, um rastreador mantém (1) informações sobre o conteúdo de cada ponto terminal e (2) coleta dados estatísticos de uso de recurso periodicamente de cada ponto terminal. Mantém informações como número de bytes de saída, número de bytes de entrada, número de conexões ativas para cada bucket, tamanho de conteúdo sendo servido etc.
Quando um usuário final fizer uma solicitação para conteúdo, o rastreador utiliza as informações estatísticas a sua disposição para determinar se (1) o conteúdo pode ser servido ao usuário final solicitante e se sim, (2) determinar o ponto terminal mais próximo e um com menos carga para servir um usuário final. Assim, o rastreador age como um balanceador de carga para a infraestrutura de CDN.
Servidor de origem: Esse é o(s) servidor(es) na infraestrutura de serviço de provedor de CDN que contém a cópia mestre dos dados. Qualquer ponto terminal que não tenha uma cópia dos dados pode solicitá-lo do servidor de origem. O cliente de CDN não tem de ter acesso ao servidor de origem. A infraestrutura de serviço de provedor de CDN movimenta dados do ponto de publicação ao servidor de origem após a realização de verificações de moderação nos dados baixados.
Servidor de Topologia: As informações sobre a topologia de rede de uma OB são mantidas em seu servidor de topologia. A topologia de rede é, na realidade, uma matriz de custo nos caminhos da rede. A matriz de custo é utilizada pela CDN na escolha do caminho ao liberar o conteúdo ao ponto terminal.
Servidor de DNS: O servidor de DNS de TLD é de autoridade para o espaço de nomes da CDN de provedor de serviços, t-cdn.net. Além disso, cada região na CDN de provedor de serviços tem um servidor de DNS que é de autoridade para sua região.
Divisor Ao Vivo: Quando o cliente criar um bucket para um canal (ou evento) “ao vivo”, ele é passado ao divisor ao vivo. O divisor ao vivo serve como um servidor de origem para um fluxo ao vivo. O divisor ao vivo é responsável por obter um fluxo ao vivo, dividindo o fluxo ao vivo recebido e utilizando um segmentador para criar uma lista de reprodução. A lista de reprodução gerada é enviada aos pontos terminais que servem o conteúdo ao vivo.
Com referência à Figura 2, a função hash consistente é revelada, para uma realização do método da invenção, para a identificação de algumas máquinas ou pontos terminais.
Função hash consistente: dada uma chave (aqui, MD5(URL) do recurso que um usuário final precisa), é necessário encontrar os servidores primário, secundário e terciário para o conteúdo solicitado. 1. Recursos (servidores de conteúdo) são mapeados em pontos no círculo de unidade. Se um servidor tiver duas vezes o armazenamento que os outros, dois recursos são criados desse servidor e ambos são mapeados ao círculo de unidade. O procedimento a seguir é utilizado para mapear servidores a um círculo de unidade.
No caso de N máquinas (1, ..., N), se a função hash utilizada tiver uma variação [0, R), o resultado da função hash é novamente escalado por meio de r -> h(r)/R, de modo que a função hash mapeia para a variação [0,1), isto é, em um círculo de unidade. 2. Como em (1.), os URLs de conteúdo são mapeados ao mesmo círculo de unidade descrito acima. É utilizada uma função hash que mapeia números hexadecimais em Inteiros. Subsequentemente, o resultado da função hash é novamente escalado como em (1.) ao mesmo círculo de unidade.
A infraestrutura de CDN confunde o URL do conteúdo.
Obtém os primeiros poucos bytes de MD5 (URL) e mapeia ao círculo de unidade. Os conteúdos são mapeados ao servidor que está mais próximo a ele no círculo de unidade (o servidor primário). Ao mapear o conteúdo a mais de um servidor, os servidores secundário e terciário são criados para o conteúdo solicitado. 3. A infraestrutura de CDN é disposta em uma hierarquia de centros de dados, no nível de cidade (ou região), nacional e global. Ao fazer o mapeamento utilizando (2.), os servidores primário e secundário (e terciário) que armazenarão o conteúdo em cada uma das hierarquias são identificados. 4. Pelo menos dois servidores são associados no centro de dados primário que contém o mapeamento entre o conteúdo de cliente (URLs) e os servidores de conteúdo (ou pontos terminais). Da mesma forma, associamos o conteúdo com pelo menos um servidor em cada um dos centros de dados secundário e terciário.
Há diversas maneiras de mapear os URLs para as máquinas: Começa com um mapeamento de URL em um círculo de unidade e faz o percurso no sentido horário ou anti-horário em um círculo de unidade. Em ambos os casos, para uma vez que encontramos máquinas nos centros de dados local, nacional e global que podem servir o conteúdo. Isso garante que as máquinas em proximidade estrita dos URLs conterão o conteúdo sinalizado pelos URLs. Outras técnicas incluem o uso de uma métrica com base em distância que mapeia somente as máquinas ao URL que estão na proximidade imediata do mapeamento de URL (ou URLs que foram mapeados ao círculo de unidade).
Conforme apresentado na Figura 3, url1, url2 e url3 são três URLs diferentes de arquivos de vídeo. Os primeiros poucos bytes da MD5 dos URLs são, então, mapeados ao círculo de unidade.
BCN1, BCN2, BCN2, BCN3 e BCN4 são quatro máquinas no centro de dados de Barcelona. Aqui, a máquina BCN2 tem duas vezes a memória de BCN1, BCN3 e BCN4. Com isso, a máquina BCN2 é verificada por hash duas vezes em seu toque utilizando IP_address-1 e IP_address-2 para nos dar BCN2-1 e BCN2-2. Todas as outras máquinas têm um sufixo “-1” em seu nome (ou endereço de IP).
MAD1, MAD2 e MAD3 são três máquinas no centro de dados de Madri. De maneira semelhante, GLB1 e GLB2 são duas máquinas executadas pelo provedor de CDN em um centro de dados global. As máquinas no centro de dados de Madri e global também são verificados por hash ao toque de hash consistente, conforme visto na Figura 3.
Ao associar máquinas em diversos centros de dados com os URLs do conteúdo, o rastreador sabe as máquinas no centro de dados associadas ao URL. No exemplo acima, a MD5 de URL1 mapeia a um ponto no círculo de unidade. Há diversas maneiras pelas quais se pode mapear o URL para as máquinas no centro de dados que hospedará o conteúdo (distância mais curta entre o mapeamento de URL e a(s) máquinas(s), percorrendo em sentido horário ou sentido anti-horário no círculo de unidade). Em ambos os casos, de acordo com o método da invenção, para uma vez que as máquinas foram encontradas no centro de dados local, nacional e global. No exemplo acima, as máquinas são selecionadas ao movimentar em uma direção de sentido horário. Ao movimentar em uma direção em sentido horário, os computadores de hospedagem seguintes serão associados ao arquivo de conteúdo de URL1; BCN1-1,
MAD2-1, BCN2-1 e GLB2-1. Pela mesma justificativa, BCN3-1, BCN2-2, MAD3-1 e GLB1-1 são selecionados para hospedar o conteúdo for URL2.
Quando um bucket for adicionado ou removido, os itens são novamente atribuídos. A maioria dos mapeamentos de URL para máquina não são afetados. Se uma máquina for removida, os mapeamentos de URL da máquina removidos são distribuídos a outras máquinas na proximidade dos URLs. o número de URLs que precisa ser movimentado é tipicamente uma pequena fração do número total de mapeamentos de URL. De maneira semelhante, somente uma pequena fração de mapeamentos de URL é afetada quando uma máquina for adicionada.
As soluções mencionadas na seção de TÉCNICA ANTERIOR, utilizam um ‘bucket’ como uma unidade que representa todo o conteúdo de um cliente. Infelizmente, isso implica que a distribuição de conteúdo para um cliente é grosseira, uma vez que todo o conteúdo de um cliente (um bucket) é armazenado em um ou mais servidores de conteúdo. De acordo com algumas realizações da presente invenção, o método compreende a utilização do conceito de um bucket como um ponto inicial, onde um bucket é meramente uma unidade de armazenamento para um pedaço do conteúdo para um cliente. Isso dá granularidade melhor de armazenamento e distribuição de conteúdo em pontos terminais.
Depois, duas realizações alternativas do método da invenção são dadas, para diferentes infraestruturas, com referência às Figuras 1 e 2, ambas delas tendo em comum que compreendem as etapas descritas acima a) a k) do método da invenção.
Para ambas as realizações, qualquer centro de dados que hospeda o conteúdo de CDN pode armazená-lo em uma ou mais máquinas. O objetivo é chegar a uma máquina que tem mais facilidade de obter dados ao usuário final solicitante.
Começando pela realização da Figura 1, nela, o resolvedor de DNS de IPS é configurado com endereço conhecido de servidores raiz. Uma consulta a um dos servidores raiz retornará o servidor de autoridade para o domínio de nível superior (TLD). No método da invenção, o servidor de DNS raiz retornará o servidor de autoridade para o domínio .net. Como uma etapa seguinte, o servidor de DNS de TLD é consultado em relação ao servidor de autoridade para o domínio de segundo nível (no presente exemplo, esse é o domínio t-cdn.net). A consulta e as respostas são marcadas. Uma descrição de etapa por etapa detalhada da resolução de DNS é como segue:
Uma primeira solicitação de DNS, mencionada acima como estágio de resolução de DNS: (0) O usuário faz uma solicitação para um vídeo bucket_id.t-cdn.net/bucket_id/video01.flv. Para simplicidade de explicação, deixemos ajustado bucket_id = 87. A solicitação, agora, aparecerá como b87.t- cdn.net/87/video01.flv. (1) O resolvedor de DNS de IPS consulta o servidor de DNS de TLD para o domínio .net para resolver o domínio t- cdn.net. (2) O servidor de nome .net responde com o endereço de IP de servidor de autoridade para o domínio t-cdn.net. O t-cdn.net é o servidor de DNS raiz da CDN de provedor de serviços. (3) O servidor de DNS de autoridade para domínio de segundo nível, t-cdn.net, primeiro deduz b87.t-cdn.net para ser um pseudônimo para b87.g.t-cdn.net. Assim, uma consulta para o domínio g.t-cdn.net será realizada. (4) Para resolver a subzona, utiliza sua base de dados de IP geográfico. A base de dados de IP geográfico mantém um mapeamento de prefixos de IP a uma subzona, representado por um inteiro ou um sequência de comando. (5) O servidor de DNS de autoridade para o domínio t-cdn.net resolve a subzona do resolvedor de DNS de IPS. Em nosso exemplo, o servidor de DNS de autoridade para o domínio de segundo nível responde com a subzona do cliente como “es” (para Espanha). Aqui, “es” significa o inteiro 34. O servidor de DNS resolve o endereço de IP de ISP na subzona para ser es.t-cdn.net ou 34.t-cdn.net. (6) O servidor de DNS 34.t-cdn.net é o servidor de DNS de autoridade para a subzona “es”. O resolvedor de DNS de IPS, então, tentará resolver b87.34.t-cdn.net ao consultar o servidor de DNS de autoridade na subzona. (7) O servidor de DNS de autoridade na subzona tem uma lista de todos os pontos terminais. Além disso, tem o endereço do rastreador que opera na mesma região (ou subzona) que o servidor de DNS. Assim, uma solicitação da forma b87.34.t-cdn.net é encaminhada ao rastreador. (8) O rastreador encaminha a solicitação a qualquer um dos pontos terminais utilizando um esquema em sequência ou um esquema de geolocalização de melhor desempenho que tente corresponder à solicitação com o ponto terminal mais próximo de {Ponto terminal 1, Ponto terminal 2, Ponto terminal 3, ... , Ponto terminal N}. Ponto terminal 2 recebe a solicitação. O ponto terminal realiza uma pesquisa de PID no endereço de IP do resolvedor de DNS de IPS (quer dizer, Barcelona) e identifica o centro de dados de BCN como um que pode servir melhor o conteúdo.
Um redirecionamento de HTTP: (9) O ponto terminal 2 realiza um hash consistente no URL solicitado (aqui, “87/video01.flv”). Depois, o Ponto terminal 2 retorna HTTP 302, Localização Movimentada b87-p9- habf8.34.t-cdn.net, onde abf8 = sub-sequência de comando(MD5(URL)) e tem o prefixo h, a PID identificada como 9 com prefixo de p. A resposta de HTTP é retornada ao usuário final.
Uma segunda solicitação de DNS, mencionada acima como um segundo estágio de resolução de DNS: (10) O usuário final envia uma solicitação de resolução de endereço para b87-p9-habf8.34.t-cdn.net. (11) O resolvedor de DNS de IPS encaminha a solicitação de resolução de endereço do cliente ao resolvedor de DNS na subzona “es” (região 34). (12) O centro de dados/PoP é identificado como 9 (centro de dados em BCN). A solicitação de resolução de endereço é, agora, enviada ao rastreador. (13) O rastreador realiza a função hash consistente em abf8 para obter {Ponto terminal 1, Ponto terminal 3, e Ponto terminal N} como pontos terminais que podem servir melhor a solicitação. O rastreador leva em consideração a carga atual nos pontos terminais e identifica o ponto terminal 3 como sendo o melhor adequado para servir o conteúdo. (14) A resposta do rastreador que identifica a lista de pontos terminais em ordem {Ponto terminal 3, Ponto terminal 1, e Ponto terminal N} é retornada ao resolvedor de DNS de autoridade na subzona “es”. (15) O resolvedor de DNS de subzona “es” encaminha a resposta ao resolvedor de DNS de IPS. (16) O resolvedor de DNS de IPS retorna a resposta ao usuário final solicitante. (17) O Usuário final, agora, se conectará diretamente ao ponto terminal 3, o primeiro ponto terminal em sua lista retornada com uma solicitação da forma b87-p9- habf8.34.t-cdn.net/87/video01.flv. Se a conexão com o ponto terminal 3 não tiver sucesso, o usuário final tentará obter o conteúdo do ponto terminal 1 e assim por diante.
Em suma, a resolução de conteúdo vincula duas solicitações de DNS e um redirecionamento de HTTP (localização movimentada de HTTP). A primeira resolução de DNS identifica o centro de dados geograficamente mais próximo ao DNS de ISP do cliente solicitante e resulta em um redirecionamento de HTTP após um hash consistente no URL solicitado por um ponto terminal. A segunda resolução de DNS resulta em o rastreador identificar a máquina (no centro de dados mais próximo ao DNS de ISP de cliente) que pode servir melhor o conteúdo após a realização de um hash consistente no URL solicitado.
De acordo com a Figura 2, outra realização do método da invenção é descrita, que é implementada em um cenário de resolução de DNS que envolve uma hierarquia de três níveis de centros de dados, um no nível de região e outro no nível nacional e, por fim, um centro de dados global operado pelo operador de CDN que pode ou não residir no mesmo país.
No nível regional, um operador de CDN poderia ter um centro de dados em Barcelona que serviu toda a Catalunha, por exemplo. O centro de dados de nível nacional poderia ser em Madri e o centro de dados global pode ser em Londres ou em Madri mesmo (não co-localizado com o centro de dados nacional).
Ao longo das mesmas linhas, outro exemplo poderia ser considerado: No nível regional, um operador de CDN poderia ter um centro de dados em São Francisco que serviu toda a Califórnia, um centro de dados nacional em Portland, Oregon, que serviu como uma cópia de segurança para todos os centros de dados regionais nos EUA e um centro de dados global em Boise, Idaho.
Considere o seguinte layout de centro de dados hierárquico: Um centro de dados regional em Barcelona (BCN) que contém as máquinas {BCN1, BCN2, BCN3 e BCN4}. O centro de dados nacional em Madri (MAD) contém máquinas {MAD1, MAD2 e MAD3}. O centro de dados global, também em Madri (mas não co-localizado com o centro de dados nacional) contém as máquinas {GLB1 e GLB2}.
Nesse exemplo da Figura 2, a interação entre o resolvedor de DNS de IPS e o servidor de nome .net não é apresentada, ao contrário da Figura 1. Também, a interação entre o resolvedor de DNS de IPS e o servidor de nome t- cdn.net para resolver a região do DNS de ISP também não é apresentada. Para simplicidade, é apresentado que a consulta é diretamente enviada ao servidor de DNS de autoridade para a subzona “es” (região 34)...
As etapas do método para essa realização são as seguintes: Uma primeira solicitação de DNS ou primeiro estágio de resolução de DNS: (0) Aqui, um Usuário final em Gerona (uma cidade na Catalunha) faz uma solicitação para um vídeo b87.t- cdn.net/87/video01.flv. (1) de acordo com a nossa hipótese simplificadora, o resolvedor de DNS de IPS envia diretamente a consulta ao servidor de DNS de autoridade para a subzona “es” (região 34). Portanto, o DNS de ISP encaminha uma solicitação na forma b87.34.t-cdn.net/87/video01.flv. (2) O servidor de DNS de autoridade para a região 34 encaminha a solicitação recebida ao rastreador da região 34. (3) O rastreador na subzona “es” utiliza o conjunto de endereços de IP {BCN2, BCN3, BCN4, MAD2, MAD3, GLB2} e um esquema em sequência ou um esquema de geolocalização de melhor desempenho que tenta corresponder à solicitação com o ponto terminal mais próximo para identificar a próxima máquina a qual deve enviar a solicitação de resolução. No conjunto acima, não se incluem máquinas que estão sob utilização pesada {BCN1, MAD1 e GLB1}. Nesse exemplo, a solicitação é encaminhada ao ponto terminal MAD2. 4. O usuário final faz uma solicitação de resolução de endereço para abf8.bcn.es.t-cdn.net.
Um redirecionamento de HTTP: (4) O ponto terminal MAD2 realiza uma pesquisa na PID do IP de resolvedor de DNS de IPS. O ponto terminal MAD2 identifica a PID do DNS de ISP para ser BCN (9, para Barcelona) e também realiza uma MD5 no URL (aqui, “87/video01.flv”). Aqui, abf8 = Sub-sequência de comando(MD5(URL)). O ponto terminal MAD2 retorna HTTP 302, Localização Movimentada b87-p9-habf8.34.t-cdn.net. Essa resposta é retornada ao usuário final. (5) Uma segunda solicitação de DNS ou segundo estágio de resolução de DNS: (6) O usuário final faz uma solicitação de resolução de endereço para b87-p9-habf8.34.t- cdn.net/87/video01.flv. (7) O resolvedor de DNS de IPS encaminha a solicitação de usuário final ao servidor de DNS de autoridade na subzona “es”. (8) O servidor de DNS de autoridade na subzona “es” recebe a solicitação do servidor de DNS de ISP. O servidor de DNS encaminha a solicitação ao rastreador da subzona “es” (região 34). (9) Na recepção da solicitação do servidor de DNS de região, o rastreador identifica a PID 9, o centro de dados BCN como um que está mais próximo ao usuário final solicitante. O rastreador realiza a função hash consistente em abf8 para obter os pontos terminais dentro do centro de dados BCN que pode servir melhor a solicitação. O rastreador também identifica os nós de cópia de segurança (fora do centro de dados BCN) que podem servir a solicitação se necessário. Nesse exemplo, o rastreador identifica {BCN4, BCN2, MAD2 e GLB2} como pontos terminais (nessa ordem) que podem servir melhor a solicitação. Assim, temos dois pontos terminais locais, um no nível nacional e outro como um fallback global. (10) A resposta, que lista os endereços de IP das quatro máquinas é retornada ao servidor de DNS de autoridade na subzona “es” (região 34). (11) O servidor de DNS na subzona “es” (região 34) encaminha a resposta ao resolvedor de DNS de IPS. (12) O resolvedor de DNS de IPS encaminha a resposta contendo os quatro endereços de IP ao Usuário final. (13) O Usuário final, agora, tentará se conectar diretamente ao ponto terminal BCN4.
Na etapa 10, o resolvedor de DNS de IPS tem quatro endereços de IP que correspondem ao vídeo de conteúdo b87.34.t-cdn.net/87/video01.flv. Essas informações permanecem em cache até que TTL para o cache de DNS expire. O servidor de DNS pode servir solicitações subsequentes para o mesmo conteúdo por outros usuários finais sem ter de ir por meio do processo de resolução de DNS novamente.
O processo envolve duas consultas de resolução de DNS e um redirecionamento (Localização Movimentada de HTTP). O ponto terminal obtém uma lista de endereços de IP que pode servir melhor o conteúdo. No exemplo acima, se o usuário final não puder obter o conteúdo de BCN4 ou BCN2, ele voltará atrás no ponto terminal MAD2 no centro de dados no nível nacional e, se não tiver sucesso novamente, voltará atrás em GLB2, no centro de dados global.
Explicação de redirecionamentos na CDN do Provedor de serviços: A seguir, três realizações do método da invenção são descritas com referência às Figuras 4, 5 e 6, que elucidam dois tipos diferentes de redirecionamento que podem ocorrer em uma CDN de provedor de serviços: (1) redirecionamento entre regiões, dentro da mesma OB (Figura 5) ou entre OBs (Figura 4) e (2) redirecionamento intra- região que ocorre entre centros de dados na mesma região de uma OB (Figura 6).
As ditas Figuras 4, 5 e 6 apresentam dois aspectos da CDN: (1) Elas apresentam como o conteúdo é movimentado na CDN do ponto de publicação por um proprietário de conteúdo (cliente de CDN) todo o caminho até os pontos terminais que servem o conteúdo e (2) Quando um usuário final fizer uma solicitação de conteúdo, a CDN direciona a solicitação de conteúdo a um ponto terminal que é tanto menos carregado quanto geograficamente mais próximo ao usuário final. Essa resolução de solicitação de conteúdo forma o centro dessa invenção. - Redirecionamento entre regiões:
Dois exemplos de redirecionamento entre regiões são considerados. No primeiro caso, um exemplo de redirecionamento entre regiões entre duas Entidades operacionais, OB1 e OB2 é apresentado. No segundo exemplo, o redirecionamento entre regiões entre duas regiões da mesma entidade operacional, OB1, é apresentado.
Redirecionamento entre regiões entre OBs: Nesse exemplo, duas OBs, OB1 e OB2, são consideradas. Cada uma das duas OBs tem exatamente uma região. As OBs também se conectam a um servidor de nome t- cdn.net global. Utilizando a configuração na Figura 4 como um exemplo, é descrito como o redirecionamento entre regiões de uma solicitação de conteúdo funciona quando o resolvedor de DNS de IPS não estiver na mesma OB (e, com isso, nem na mesma região) como um usuário final solicitante.
As etapas do método para essa realização são as seguintes: Uma primeira solicitação de DNS ou primeiro estágio de resolução de DNS: (1) O usuário final na OB1 faz uma solicitação para video01.flv. A solicitação, agora, aparecerá como b87.t- cdn.net/87/video01.flv. (2) O resolvedor de DNS de IPS consulta o servidor de DNS de autoridade para o domínio t-cdn.net para resolver a solicitação do usuário final. (3) O servidor de nome t-cdn.net deduz b87.t- cdn.net para ser um pseudônimo para b87.g.t-cdn.net. Assim, uma consulta para o domínio g.t-cdn.net será realizada. O servidor de nome t-cdn.net pesquisa a região do DNS de ISP utilizando sua base de dados de IP geográfico e responde com o endereço de IP do servidor de DNS de autoridade para a região do DNS de ISP, b87.44.t-cdn.net. (4) O resolvedor de DNS de IPS, então, tentará resolver b87.44.t-cdn.net ao consultar o servidor de DNS de autoridade na subzona, que é a região 44 na OB2. (5) O servidor de DNS de autoridade OB2-DNS encaminha a solicitação ao rastreador na mesma região (Rastreador OB2). (6) O rastreador na região 44, Rastreador OB2 tem uma lista de todos os pontos terminais. Ele encaminha a solicitação a qualquer um dos pontos terminais utilizando um esquema em sequência ou um esquema de geolocalização de melhor desempenho que tente corresponder à solicitação com o ponto terminal mais próximo dentre {Ponto terminal 1, Ponto terminal 2}.
Um redirecionamento de HTTP: (7) Ponto terminal OB2-EP-2 recebe a solicitação. O ponto terminal realiza uma pesquisa de PID no endereço de IP do resolvedor de DNS de IPS e identifica OB2-EP-1 como o ponto terminal que pode servir o conteúdo solicitado. O ponto terminal OB2-EP-2 também realiza uma MD5 no URL, “87/video01.flv.” Obtemos uma sub-sequência de comando do URL (aqui, “87/video01.flv”). Aqui, abf8 = Sub-sequência de comando(MD5(URL)). Para resolver a PID do endereço de IP, pesquisa a base de dados de PID para construir o URL b87-p1- habf8.44.t-cdn.net/87/video01.flv. O URL b87-p1-habf8.44.t- cdn.net/87/video01.flv junto aos endereços de IP dos pontos terminais {OB2-EP-1, OB2-EP-2} que são melhores adequados para servir o conteúdo nessa ordem são retornados ao usuário final.
Na realidade, o ponto terminal OB2-EP-2 retorna os pontos terminais sem uma ordenação do rastreador. Uma vez que o rastreador mantém informações estatísticas sobre a carga em cada ponto terminal, o rastreador faz a ordenação e retorna o resultado ao servidor de DNS de autoridade para a subzona. O resultado é retornado ao resolvedor de DNS de IPS e, então, ao usuário final. Para clareza, as últimas etapas não são apresentadas na Figura 4. (8) O usuário final se conectará diretamente a OB2- EP-1 com o URL b87-p1-habf8.44.t-cdn.net/87/video01.flv. (9) O ponto terminal OB2-EP-1 recebe a solicitação e verifica as informações de região com base no endereço de IP do usuário final. O ponto terminal identifica a região para ser aquela da região 34 OB1 e a partição para ser 1. Assim, o ponto terminal OB2-EP-1 retorna uma mensagem de redirecionamento HTTP 302 com o URL b87-p1-habf8.34.t- cdn.net/-87/video01.flv.
Uma segunda solicitação de DNS: (10) Depois, o usuário final envia uma solicitação b87-p1-habf8.34.t-cdn.net/+87/video01.flv ao resolvedor de DNS de IPS. (11) O resolvedor de DNS de IPS consulta o servidor de DNS de autoridade do domínio t-cdn.net para resolver 34.t-cdn.net. (12) O servidor de nome t-cdn.net pesquisa a região do domínio 34.t-cdn.net utilizando sua base de dados de IP geográfico e responde com o endereço de IP do servidor de DNS de autoridade para a região 34.t-cdn.net. (13) O resolvedor de DNS de IPS, agora, consulta o servidor de autoridade para a subzona (região 34) para resolver b87-p1-habf8.34.t-cdn.net/+87/video01.flv. O servidor OB1-DNS recebe a solicitação. (14) O servidor de DNS de autoridade na região 34 na OB1 tem uma lista de todos os pontos terminais (OB1-EP-1, OB1-EP-2) e o rastreador na região. O servidor de DNS OB1 recebe a solicitação e a encaminha ao rastreador da região 34, Rastreador OB1. (15) O rastreador na subzona, Rastreador OB1, tem uma lista de todos os pontos terminais. O rastreador reconhece que a solicitação é uma solicitação de redirecionamento. O rastreador identifica abf8 para ser a MD5 da sub-sequência de comando do URL “87/video01.flv.” Também reconhece a PID da solicitação para ser 1. utiliza essas informações para identificar os pontos terminais que estão mais próximos ao usuário final solicitante da lista {OB1-EP-1, OB1-EP-2}. O rastreador, Rastreador OB1, retorna os pontos terminais {OB1-EP-1, OB1-EP-2} nessa ordem ao servidor de DNS região, OB1-DNS. (16) O conjunto de pontos terminais retornado de OB1-DNS ao resolvedor de DNS de IPS. (17) O conjunto de pontos terminais é retornado do resolvedor de DNS de IPS ao usuário final. (18) O usuário final envia a solicitação de conteúdo ao ponto terminal OB1-EP-1 por meio do URL b87-p1- habf8.34.t-cdn.net/+87/video01.flv. (19) O ponto terminal OB1-EP-1 serve o arquivo solicitado video01.flv. O ponto terminal obtém o arquivo de conteúdo do servidor de origem OB1, se necessário. O ponto terminal OB-EP-1 recebe a solicitação. O ponto terminal realiza uma pesquisa de PID no endereço de IP do usuário final (digamos que seja Barcelona) e identifica por si só para estar na mesma PID (centro de dados BCN) que pode servir melhor o conteúdo. O ponto terminal, então, serve o conteúdo ao usuário final se já tiver o video01.flv. Se não, ele obtém o conteúdo de outro ponto terminal no mesmo centro de dados ou reverte para o servidor de origem OB1 antes de servir o usuário final.
Redirecionamento entre regiões entre regiões da mesma OB: Nesse exemplo, uma OB com duas regiões diferentes é considerada. Cada região tem seu próprio ponto de publicação, servidor de DNS de autoridade para aquela região e um rastreador.
A Figura 5 apresenta o cenário de redirecionamento que consiste em uma entidade operacional, OB1. A figura também apresenta duas regiões, região 1 e região 2. Cada região tem um servidor de DNS que é de autoridade em sua região e um rastreador. Uma vez que ambas as regiões pertencem à mesma OB, há somente um servidor de origem.
As etapas do método para essa realização são as seguintes: Uma primeira solicitação de DNS ou primeiro estágio de resolução de DNS: (1) O usuário final na OB1 faz uma solicitação para video01.flv. A solicitação, agora, aparecerá como b87.t- cdn.net/87/video01.flv. (2) O resolvedor de DNS de IPS consulta o servidor de DNS de autoridade para o domínio t-cdn.net para resolver a solicitação do usuário final. (3) O servidor de nome t-cdn.net deduz b87.t- cdn.net para ser um pseudônimo para b87.g.t-cdn.net. Assim, uma consulta para o domínio g.t-cdn.net será realizada. O servidor de nome t-cdn.net pesquisa a região do DNS de ISP utilizando sua base de dados de IP geográfico e responde com o endereço de IP do servidor de DNS de autoridade para a região do DNS de ISP, b87.2.t-cdn.net. (4) O resolvedor de DNS de IPS, então, tentará resolver b87.2.t-cdn.net ao consulta o servidor de DNS de autoridade na subzona, que é a região 2 em OB1. (5) O rastreador na região 2 tem uma lista de todos os pontos terminais. Ele encaminha a solicitação a qualquer um dos pontos terminais utilizando um esquema em sequência ou um esquema de geolocalização de melhor desempenho que tente corresponder à solicitação com o ponto terminal mais próximo dentre {Ponto terminal 1, Ponto terminal 2}.
Um redirecionamento de HTTP: (6) O ponto terminal R2-EP-2 recebe a solicitação. O ponto terminal realiza uma consulta de PID no endereço de IP do resolvedor de DNS de IPS e identifica R2-EP-1 como o ponto terminal que pode servir o conteúdo solicitado. O ponto terminal R2-EP-2 também realiza uma MD5 no URL, “87/video01.flv”. Obtemos uma sub-sequência de comando do URL (aqui, “87/video01.flv”). Aqui, abf8 = Sub-sequência de comando(MD5(URL)). Para resolver a PID do endereço de IP, consulta a base de dados de PID para construir o URL b87-p1- habf8.2.t-cdn.net/87/video01.flv. (7) O URL b87-p1-habf8.2.t-cdn.net/87/video01.flv junto aos endereços de IP dos pontos terminais {R2-EP-1, R2- EP-2} que são mais bem adequados para servir o conteúdo na ordem em que são retornados ao usuário final.
Na realidade, o ponto terminal R2-EP- retorna os pontos terminais sem uma ordenação do rastreador da região 2. Uma vez que o rastreador mantém informações estatísticas sobre a carga em cada ponto terminal, o rastreador faz a ordenação e retorna o resultado ao servidor de DNS de autoridade para a subzona. O resultado é retornado ao resolvedor de DNS de IPS e, então, ao usuário final. Para clareza da figura, as últimas etapas são puladas na Figura 5. (8) O usuário final se conectará diretamente a R2- EP-1 com o URL b87-p1-habf8.2.t-cdn.net/87/video01.flv. (9) O ponto terminal R2-EP-1 recebe a solicitação e verifica as informações de região com base no endereço de IP do usuário final. O ponto terminal identifica a região para ser aquela da região 1 na OB1. Assim, o ponto terminal R2- EP-1 retorna uma mensagem de redirecionamento de HTTP 302 com o URL b87-p1-habf8.1.t-cdn.net/-87/video01.flv.
Uma segunda solicitação de DNS ou segunda solicitação de resolução: (10) O usuário final recebe a resposta. Depois, o usuário final envia uma solicitação b87-p1-habf8.1.t- cdn.net/+87/video01.flv ao resolvedor de DNS de IPS. (11) O resolvedor de DNS de IPS consulta o servidor de DNS de autoridade do domínio t-cdn.net para resolver 1.t- cdn.net. (12) O servidor de nome t-cdn.net pesquisa a região do DNS de ISP utilizando sua base de dados de IP geográfico e responde com o endereço de IP do servidor de DNS de autoridade para a região 1.t-cdn.net. (13) O servidor de DNS de ISP, agora, consulta o servidor de autoridade na região 1 para resolver b87-p1- habf8.1.t-cdn.net/+87/video01.flv. O servidor de DNS R1-DNS recebe a solicitação. (14) O servidor de DNS de autoridade na região 1 na OB1 tem uma lista de todos os pontos terminais (R1-EP-2, R1- EP-1) e o rastreador na região. O servidor de DNS R1 recebe a solicitação e a encaminha ao rastreador da região 1, R1- Rastreador. (15) O rastreador na região 1, Rastreador R1 tem uma lista de todos os pontos terminais. O rastreador reconhece que a solicitação é uma solicitação de redirecionamento. O rastreador identifica abf8 para ser a MD5 da sub-sequência de comando do URL “87/video01.flv.” Ele também reconhece a PID da solicitação para ser 1. Utiliza essas informações para identificar os pontos terminais que estão mais próximos ao usuário final solicitante da lista {R1-EP-2, R1-EP-1}. O rastreador, Rastreador R1, retorna os pontos terminais {R1-EP-2, R1-EP-1} nessa ordem ao servidor de DNS de região, R1-DNS... (16) O conjunto de pontos terminais retornados de R1-DNS ao resolvedor de DNS de IPS. (17) O conjunto de pontos terminais é retornado do resolvedor de DNS de IPS ao usuário final. (18) O usuário final envia a solicitação de conteúdo ao ponto terminal R1-EP-2 por meio do URL b87-p1- habf8.1.t-cdn.net/+87/video01.flv. (19) O ponto terminal R1-EP-2 serve o arquivo solicitado video01.flv. O ponto terminal obtém o arquivo de conteúdo do servidor de origem de OB1, se necessário.
O ponto terminal R1-EP-2 recebe a solicitação. O ponto terminal realiza uma pesquisa de PID no endereço de IP do usuário final e identifica por si só para ser a mesma PID. O ponto terminal R1-EP-2, então, serve o conteúdo ao usuário final se ele já tiver o video01.flv. Se não, ele obtém o conteúdo de outro ponto terminal no mesmo centro de dados (mesma PID) ou reverte ao servidor de origem de OB1 antes de servir o usuário final.
Ambos os exemplos acima apresentam que há pouca diferença no mecanismo de redirecionamento no nível de inter-região se o redirecionamento ocorrer entre duas OBs distintas ou dentro de duas regiões da mesma OB.
Nos exemplos acima, não apresentamos a interação entre o resolvedor de DNS de IPS e o servidor de nome .net como na Figura 1 para simplicidade. Presumimos que o resolvedor de DNS de IPS conhece o endereço do servidor de nome t-cdn.net para resolver a região do DNS de ISP. - Redirecionamento intra-região
Nessa seção, é explicado, com um exemplo, como um redirecionamento intra-região funciona em uma CDN de provedor de serviços. A Figura 6 apresenta alguns dos componentes de uma OB. Aqui, a entidade operacional OB1 apresentada na figura consiste em: - uma região, Região 1 - três centros de dados na Região 1 - cada um dos centros de dados tem diversos pontos terminais que servem conteúdo aos usuários finais solicitantes
A figura apresenta como o conteúdo é movimentado dentro da CDN do ponto de publicação para o servidor de origem e, então, aos pontos terminais. Os pontos terminais no mesmo centro de dados podem trocar conteúdo entre si de uma maneira posto a posto. A Figura 6 que apresenta somente três centros de dados pode ser generalizada por ter diversos centros de dados e não deve ser vista como limitante do escopo da invenção.
As etapas do método para essa realização são as seguintes: Uma primeira solicitação de DNS ou primeiro estágio de resolução de DNS: (1) O usuário final na OB1 faz uma solicitação para video01.flv. A solicitação, agora, aparecerá como b87.t- cdn.net/87/video01.flv. (2) O resolvedor de DNS de IPS consulta o servidor de DNS de autoridade para o domínio t-cdn.net para resolver a solicitação do usuário final. (3) O servidor de nome t-cdn.net deduz b87.t- cdn.net para ser um pseudônimo para b87.g.t-cdn.net. Assim, uma consulta para o domínio g.t-cdn.net será realizada. O servidor de nome t-cdn.net pesquisa a região do DNS de ISP utilizando sua base de dados de IP geográfico e responde com o endereço de IP do servidor de DNS de autoridade para a região do DNS de ISP, b87.1.t-cdn.net. (4) O resolvedor de DNS de IPS, então, tentará resolver b87.1.t-cdn.net ao consultar o servidor de DNS de autoridade na subzona, que é a região 1 na OB1. (5) O rastreador na região 1 tem uma lista de todos os pontos terminais. Ele encaminha a solicitação a qualquer um dos pontos terminais utilizando um esquema em sequência ou um esquema de geolocalização de melhor desempenho que tente corresponder à solicitação com o ponto terminal mais próximo de {R1-D1-1, R1-D1-2, R1-D2-1, R1-D2-2, R1-D3-1, R1- D3-2}.
Um redirecionamento de HTTP: (6) O ponto terminal R1-D3-1 recebe a solicitação. O ponto terminal realiza uma pesquisa de PID no endereço de IP do resolvedor de DNS de IPS e identifica R1-D3-2 como o ponto terminal que pode servir o conteúdo solicitado. O ponto terminal R1-D3-1 também realiza uma MD5 no URL, “87/video01.flv”. Obtemos uma sub-sequência de comando do URL (aqui, “87/video01.flv”). Aqui, abf8 = Sub-sequência de comando(MD5(URL)). Para resolver a PID do endereço de IP, ele pesquisa a base de dados de PID para construir o URL b87-p2-habf8.1.t-cdn.net/87/video01.flv. Aqui, PID 1 identifica o centro de dados 2 como o mais bem adequado para servir o conteúdo. (7) O URL b87-p2-habf8.2.t-cdn.net/87/video01.flv junto aos endereços de IP dos pontos terminais {R1-D3-2, R1- D3-1} que são melhores para servir o conteúdo nessa ordem são retornados ao usuário final.
Conforme discutido nos casos anteriores, o ponto terminal R1-D3-1 retorna os pontos terminais sem uma ordenação ao rastreador da região 1. Uma vez que o rastreador mantém informações estatísticas sobre a carga em cada ponto terminal, o rastreador faz a ordenação e retorna o resultado ao servidor de DNS de autoridade para a subzona. O resultado é retornado ao resolvedor de DNS de IPS e, então, ao usuário final. Para clareza e facilidade de explicação, as últimas etapas não são detalhadas na Figura 6. (8) O usuário final se conectará diretamente a R1- D3-2 com a URL b87-p2-habf8.2.t-cdn.net/87/video01.flv. (9) O ponto terminal R1-D3-2 recebe a solicitação e verifica as informações de região com base no endereço de IP do usuário final. O ponto terminal identifica a PID 1 como a mais capaz de servir o usuário final. Assim, o ponto terminal R1-D3-2 retorna uma mensagem de redirecionamento de HTTP 302 com o URL b87-p1-habf8.1.t-cdn.net/_87/video01.flv (o símbolo sublinhado significando redirecionamento intra- região).
Uma segunda solicitação de DNS ou segundo estágio de resolução de DNS: (10) O usuário final recebe a resposta. A seguir, o usuário final envia uma solicitação b87-p1-habf8.1.t- cdn.net/_87/video01.flv ao resolvedor de DNS de IPS. (11) O resolvedor de DNS de IPS identifica a solicitação como sendo para a região 1 e consulta o servidor de DNS de autoridade na região 1. A consulta é encaminhada ao servidor de DNS R1-DNS (região 1 da OB1). (12) O R1-DNS encaminha a consulta ao rastreador da região 1, R1-Rastreador. (13) O rastreador identifica a consulta como sendo um redirecionamento intra-região. O rastreador identifica a PID e determina os pontos terminais no centro de dados 1 que são mais bem posicionados para servir o conteúdo. O rastreador, então, retorna uma lista ordenada de pontos terminais ao usuário final {R1-D1-2, R1-D1-1}. (14) O usuário final se conecta diretamente ao ponto terminal R1-D1-2 com o URL b87-p1-habf8.1.t- cdn.net/_87/video01.flv. (15) O ponto terminal R1-D1-2, agora, servirá o conteúdo ao usuário final solicitante.
Essa invenção apresenta as seguintes vantagens, dependendo da realização: - Ao executar a função hash consistente no URL, é possível fazer o balanceamento de carga no nível de arquivo. - Em um serviço de CDN, dado que o conteúdo pode residir em poucas centenas (ou milhares de servidores), a invenção supera a limitação de DNS de ser capaz de identificar rapidamente o servidor de conteúdo que pode servir o usuário final solicitante.
Ao contatar os pontos terminais na resolução de conteúdo, é garantido que o ponto terminal mais bem adequado para liberar o conteúdo a um usuário final solicitante é chegado rapidamente.
A técnica aqui apresentada garante que os dados sejam preferencialmente servidos por pontos terminais mais próximos ao usuário final solicitante. Se os pontos terminais mias próximos forem incapazes de servir o conteúdo (devido a estarem sobrecarregados), a responsabilidade de servir o conteúdo volta para os pontos terminais que residem no centro de dados nacional. Se o centro de dados nacional também for incapaz de liberar o conteúdo solicitado, então, tem somente a responsabilidade de servir o conteúdo existente nos pontos terminais no centro de dados global. Isso garante a liberação rápida do conteúdo aos usuários finais solicitantes sempre que possível. - A CDN designada para um ISP pode ser implementada tão profundamente quanto necessário dentro de uma rede de ISP.
Uma vez que o resolvedor de DNS de IPS salva (para a realização da Figura 2) o endereço de IP do ponto terminal que servirá o conteúdo solicitado até que sua TTL expire no cache de DNS, novos usuários finais que solicitam o mesmo conteúdo podem obter a localização do ponto terminal que pode servir o conteúdo do cache de DNS de ISP (e, assim, não têm de fazer a resolução de DNS para cada solicitação). - A solução proposta remove a necessidade de balanceadores de carga de hardware para responder às consultas no DNS de segundo nível, uma vez que nosso rastreador age como um balanceador de carga para consultas aos pontos terminais.
Um técnico no assunto poderia introduzir alterações e modificações nas realizações descritas sem desviar-se do escopo da invenção, conforme é definido nas reivindicações anexas. ACRÔNIMOS E ABREVIAÇÕES ADSL LINHA DE ASSINATURA DIGITAL ASSIMÉTRICA AS SISTEMA AUTÔNOMO CDN REDE DE DISTRIBUIÇÃO DE CONTEÚDO DNS SERVIÇO DE NOME DE DOMÍNIO POP PONTO DE PRESENÇA TLD DOMÍNIO DE NÍVEL SUPERIOR FTP PROTOCOLO DE TRANSFERÊNCIA DE ARQUIVO HTTP PROTOCOLO DE TRANSFERÊNCIA DE HIPERTEXTO MD5 ALGORITMO DE SINOPSE DE MENSAGEM 5 URL LOCALIZADOR DE RECURSO UNIFORME ISP PROVEDOR DE SERVIÇOS DA INTERNET TTL TEMPO DE VIDA DSLAM MULTIPLEXADOR DE ACESSO DE LINHA DE ASSINATURA DIGITAL REFERÊNCIAS [1] Domain Name System definition: http://en.wikipedia.org/wiki/Domain_Name_System [2] Akamai: http://www.akamai.com [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] Consistent Hashing definition: http://en.wikipedia.org/wiki/Consistent_hashing [8] D. Karger, E. Lehman, T. Leighton, M. Levine, D. Lewin and R. Panigraphy, “Consistent Hashing and Random TreesL Distributed Caching Protocols for Retrieving Hot Spots on the World Wide Web”. In ACM Symposium on Theory of Computing, 1997. [9] C. Huang, J. Li, Angela Wang and K. W. Ross, Understanding Hybrid CDN-P2P: Why Limelight Need its Own Red Swoosh, NOSSDAV, Braunschweig, Germany, 2008.

Claims (21)

1. MÉTODO PARA RESOLUÇÃO DE DNS DE SOLICITAÇÕES DE CONTEÚDO EM UM SERVIÇO DE CDN, compreendendo a identificação de um ponto terminal ou servidor de conteúdo que pode servir 5 melhor um usuário final que enviou uma solicitação de DNS a um resolvedor de DNS de ISP, dada uma rede geograficamente distribuída de pontos terminais, caracterizado pela dita resolução de DNS ser realizada ao realizar: I) um estágio de resolução de DNS, compreendendo a 10 realização das seguintes etapas: a) o dito resolvedor de DNS de IPS enviando a solicitação de DNS recebida a um servidor de DNS de autoridade de uma subzona, previamente conhecido ou identificado ao enviar uma solicitação ao servidor de DNS 15 raiz do domínio solicitado; b) o dito servidor de DNS de autoridade da dita subzona encaminhando a dita solicitação de DNS ao rastreador que opera na dita subzona, e o dito rastreador encaminhando a solicitação de DNS recebida a um (Ponto terminal 2; MAD2; 20 OB2-EP-2; R2-EP-2; R1-D3-1) dos ditos pontos terminais que participam no dito estágio de resolução de DNS; e II) um redirecionamento de HTTP, compreendendo a realização das seguintes etapas: 25 c) o dito ponto terminal participando no dito estágio de resolução de DNS (Ponto terminal 2; MAD2; OB2-EP- 2; R2-EP-2; R1-D3-1) que resolve a localização do resolvedor de DNS de IPS por meio de uma base de dados de ID de partição para identificar: 30 - o centro de dados (BCN) que pode servir melhor o conteúdo; ou - pelo menos um ponto terminal (OB2-EP-1; R2-EP-1; R1-D3-2) no mesmo centro de dados que pode servir o conteúdo; e d) o dito ponto terminal participando no dito estágio de resolução de DNS (Ponto terminal 2; MAD2; OB2-EP- 2; R2-EP-2; R1-D3-1) realizando um hash consistente na URL 5 solicitada associada à dita solicitação de DNS, construindo um endereço de URL utilizando uma substring do hash MD5 da solicitação de conteúdo e a localização do dito centro de dados (BCN) que pode servir melhor o conteúdo ou a localização do dito pelo menos um ponto terminal (OB2-EP-1; 10 R2-EP-1; R1-D3-2) no mesmo centro de dados que pode servir o conteúdo, e envio do dito endereço ao usuário final, diretamente ou por meio de entidades intermediárias, utilizando uma mensagem de redirecionamento.
2. MÉTODO, de acordo com a reivindicação 1, em que, 15 quando aplicada para uma resolução de DNS ao longo de somente uma região de umas entidades operacionais, a dita subzona é a dita região, com o dito estágio de resolução de DNS de I) sendo um primeiro estágio de resolução de DNS, a dita mensagem de redirecionamento sendo uma mensagem de 20 redirecionamento de HTTP, e o método é caracterizado por ainda compreender um segundo estágio de resolução de DNS compreendendo a realização das seguintes etapas: e) o usuário final que faz uma solicitação de resolução de endereço para o dito endereço de URL recebido 25 ao dito resolvedor de DNS de IDP; f) o servidor de DNS de ISP encaminhando a dita solicitação de resolução de endereço ao dito servidor de DNS de autoridade de subzona; g) o servidor de DNS de autoridade de subzona 30 encaminhando a URL recebida ao rastreador da região para resolver o endereço recebido; h) o dito rastreador na região realizando um hash consistente na dita substring do hash de URL para obter o ponto terminal ou pontos terminais ({Ponto terminal 3, Ponto terminal 1, Ponto terminal n}; {BCN4, BCN2}) dentro do dito centro de dados (BCN) que pode servir melhor a solicitação de conteúdo; 5 i) o rastreador enviando uma resposta que inclui o endereço de pelo menos um dos ditos pontos terminais obtidos ({Ponto terminal 3, Ponto terminal 1, Ponto terminal n}; {BCN4, BCN2}) ao servidor de DNS de autoridade de subzona; j) o servidor de DNS de autoridade de subzona 10 encaminhando a dita resposta de rastreador ao resolvedor de DNS de IPS; e k) o resolvedor de DNS de IPS encaminhando a dita resposta recebida do servidor de autoridade da subzona ao usuário final.
3. MÉTODO, de acordo com a reivindicação 2, caracterizado pela dita etapa h) ainda compreender o rastreador identificando o ponto terminal menos carregado no dito centro de dados (BCN) que pode servir melhor o conteúdo ao utilizar informações sobre a carga atual nos ditos pontos 20 terminais ({Ponto terminal 3, Ponto terminal 1, Ponto terminal n}; {BCN4, BCN2}) e incluindo o endereço somente do ponto terminal menos carregado (Ponto terminal 3, BCN4) na dita resposta de rastreador enviada na etapa i).
4. MÉTODO, de acordo com a reivindicação 3, 25 caracterizado por compreender, após a dita etapa j), o usuário final se conectar diretamente ao dito ponto terminal menos carregado (Ponto terminal 3, BCN4) ao enviar uma solicitação de conexão a ele, com um endereço de URL que é o dito endereço construído que identifica o arquivo de 30 conteúdo solicitado.
5. MÉTODO, de acordo com qualquer uma das reivindicações de 1 a 4, caracterizado pela dita etapa b) compreender o dito rastreador utilizando pelo menos um esquema em sequência ou um esquema de geolocalização de melhor desempenho para corresponder à solicitação de DNS com o ponto terminal participando no dito estágio de resolução de DNS (Ponto terminal 2; MAD2; OB2-EP-2; R2-EP-2; R1-D3-1) 5 dos ditos pontos terminais.
6. MÉTODO, de acordo com qualquer uma das reivindicações de 1 a 5, caracterizado pelo dito servidor de DNS de autoridade da dita subzona ser previamente identificado por meio de uma pesquisa geográfica de IP.
7. MÉTODO, de acordo com a reivindicação 6, caracterizado pela dita pesquisa geográfica de IP ser realizada em um servidor de DNS de autoridade para um domínio de segundo nível.
8. MÉTODO, de acordo com a reivindicação 7, 15 caracterizado por compreender: - resolvedor de DNS de IPS que consulta um servidor de DNS de domínio de nível superior para resolver um domínio de segundo nível do endereço da dita solicitação de DNS; - o servidor de DNS de domínio de nível superior 20 respondendo ao resolvedor de DNS de IPS com o endereço de IP do dito servidor de DNS de autoridade do dito domínio de segundo nível; - o resolvedor de DNS de IPS que consulta o dito servidor de DNS de autoridade do dito domínio de segundo 25 nível para resolver o dito domínio de segundo nível do endereço da dita solicitação de DNS; e - o servidor de DNS de autoridade do dito domínio de segundo nível resolvendo a dita subzona por meio da dita pesquisa geográfica de IP, e respondendo ao resolvedor de 30 DNS de IPS com o endereço da dita subzona por meio da dita pesquisa geográfica de IP.
9. MÉTODO, de acordo com a reivindicação 2, caracterizado pela dita resposta de rastreador conter uma lista de endereços de pelo menos algum dos pontos terminais no dito centro de dados (BCN) que pode servir melhor o conteúdo.
10. MÉTODO, de acordo com a reivindicação 9, 5 caracterizado pela dita etapa h) ainda compreender o rastreador identificando pontos terminais de backup (MAD2, GLB2) fora do dito centro de dados (BCN) que pode servir melhor o conteúdo, onde pode servir a solicitação se necessário, a dita lista dos ditos endereços contendo 10 resposta de rastreador dos ditos pontos terminais de backup (MAD2, GLB2).
11. MÉTODO, de acordo com a reivindicação 10, caracterizado pelo centro de dados (BCN) que pode servir melhor o conteúdo ser um centro de dados local, e os ditos 15 pontos terminais de backup (MAD2, GLB2) pertencem a centros de dados nacionais e/ou global.
12. MÉTODO, de acordo com qualquer uma das reivindicações 10 ou 11, caracterizado por compreender, após a dita etapa j), o usuário final conectando-se diretamente a 20 um dos pontos terminais ({Ponto terminal 3, Ponto terminal 1, Ponto terminal n}; {BCN4, BCN2}) do dito centro de dados (BCN) que pode servir melhor o conteúdo, e se incapaz de obter o conteúdo do dito ponto terminal, conectando-se a um dos pontos terminais de backup (MAD2, GLB2) incluídos na 25 dita lista.
13. MÉTODO, de acordo com a reivindicação 1, caracterizado por compreender um redirecionamento entre regiões entre pelo menos duas regiões (Região 1, Região 2) de duas Entidades operacionais (OB1, OB2), o dito servidor 30 de DNS de subzona (OB2-DNS) estando em uma (Região 2) das ditas pelo menos duas regiões (Região 1, Região 2), em que: - o dito usuário final é colocado em uma região (Região 1), ou região de destino, de uma primeira (OB1) dentre as ditas duas Entidades operacionais (OB1, OB2), - a dita subzona sendo uma região (Região 2) de uma segunda (OB2) das ditas duas Entidades operacionais (OB1, OB2), 5 - o dito resolvedor de DNS de IPS sendo colocado na dita segunda entidade operacional (OB2), - o dito servidor de DNS de autoridade para o dito domínio de segundo nível sendo o servidor de DNS de autoridade para ambas as Entidades operacionais (OB1, OB2), 10 e - o dito pelo menos um ponto terminal que pode servir o conteúdo é um ponto terminal (OB2-EP-1) colocado na dita segunda entidade operacional (OB2).
14. MÉTODO, de acordo com a reivindicação 13, 15 caracterizado pelo dito estágio de resolução de DNS de I) ser um primeiro estágio de resolução de DNS, a dita etapa d) ainda compreende o dito ponto terminal participando do dito primeiro estágio de resolução de DNS (OB2-EP-2) enviando também ao usuário final, por meio do rastreador (OB2- 20 Rastreador) da região (Região 2) na dita segunda entidade operacional (OB2), junto ao endereço construído, o endereço de IP do pelo menos dito pelo menos um ponto terminal (OB2- EP-1) que pode servir o conteúdo.
15. MÉTODO, de acordo com a reivindicação 14, 25 caracterizado pelo dito redirecionamento de HTTP de II) ainda compreender, após a dita etapa d): - o usuário final se conectar diretamente ao dito pelo menos um ponto terminal (OB2-EP-1) que pode servir o conteúdo ao enviar uma solicitação de conexão a ele, na 30 forma de uma URL que inclui o dito endereço construído que também identifica o conteúdo solicitado; e - o pelo menos um ponto terminal (OB2-EP-1) que pode servir o conteúdo que recebe a dita solicitação de conexão endereço de URL, verificando as informações da região com base no endereço de IP do usuário final, modificando o dito endereço de URL ao incluir as ditas informações de região de usuário final nele, e enviando o 5 dito endereço de URL modificado ao usuário final utilizando uma mensagem de redirecionamento de HTTP; e em que o método ainda compreende um segundo estágio de resolução de DNS compreendendo a realização das seguintes etapas: 10 - o usuário final enviando uma solicitação de DNS modificada, com base no dito endereço de URL modificado, ao resolvedor de DNS de IPS; - o resolvedor de DNS de IPS consultando o servidor de DNS de autoridade para resolver um domínio de segundo 15 nível do dito endereço de URL modificado da dita solicitação de DNS modificada; - o servidor de DNS de autoridade do domínio de segundo nível conhece a região de destino por meio da URL de solicitação e resolve a solicitação do resolvedor de DNS de 20 IPS com o endereço de IP do servidor de DNS (OB1-DNS) de autoridade para a região de destino (Região 1); - o resolvedor de DNS de IPS consultando o dito servidor de DNS (OB1-DNS) de autoridade para a região de destino (Região 1) para resolver a dita solicitação de DNS 25 modificada; - o servidor de DNS (OB1-DNS) de autoridade para a região de destino (Região 1) recebendo a dita solicitação de DNS modificada e a encaminhando ao rastreador (OB1- Rastreador) da região de destino (Região 1); 30 - o dito rastreador (OB1-Rastreador) da região de destino (Região 1) reconhecendo a solicitação por ser uma solicitação de redirecionamento, identificando o ponto terminal ou pontos terminais (OB1-EP-1, OB1-EP-2) que estão mais próximos ao usuário final solicitante, e retornando uma lista referentes aos ditos pontos terminais (OB1-EP-1, OB1- EP-2) ao servidor de DNS (OB1-DNS) de autoridade para a região do usuário final, a dita lista sendo uma lista 5 ordenada, começando com o ponto terminal menos carregado (OB1-EP1); - o servidor de DNS (OB1-DNS) de autoridade para a região de destino (Região 1) retorna a lista de pontos terminais (OB1-EP-1, OB1-EP-2) ao resolvedor de DNS de IPS; 10 - o resolvedor de DNS de IPS encaminha a lista de pontos terminais (OB1-EP-1, OB1-EP-2) recebida ao usuário final solicitante; - o usuário final enviando uma solicitação de conteúdo ao ponto terminal mais próximo e menos carregado 15 (OB1-EP-1), conforme indicado na dita lista de pontos terminais (OB1-EP-1, OB1-EP-2) junto à URL modificada contendo o hash do conteúdo, a ID de partição do usuário final e a ID de categoria do conteúdo; e - o dito ponto terminal mais próximo e menos 20 carregado (OB1-EP-1) servindo o conteúdo solicitado ao usuário final.
16. MÉTODO, de acordo com a reivindicação 1, caracterizado por compreender um redirecionamento entre pelo menos duas regiões (Região 1, Região 2) da mesma Entidade 25 operacional (OB1), em que: - o dito usuário final é colocado em uma primeira região (Região 1), ou região de destino, das ditas pelo menos duas regiões (Região 1, Região 2) da dita entidade operacional (OB1), 30 - o dito servidor de DNS de autoridade para a subzona está em uma segunda região (Região 2) das ditas pelo menos duas regiões (Região 1, Região 2), - o dito resolvedor de DNS de IPS é colocado na dita segunda região (Região 2), - o dito servidor de DNS de autoridade para o domínio de segundo nível é de autoridade para todas as regiões definidas (Região 1, Região 2), e 5 - o dito pelo menos um ponto terminal que pode servir o conteúdo é um ponto terminal (R2-EP-1) colocado na dita segunda região (Região 2).
17. MÉTODO, de acordo com a reivindicação 16, caracterizado pelo dito estágio de resolução de DNS de I) e 10 um primeiro estágio de resolução de DNS, a dita etapa d) ainda compreender o dito ponto terminal participando no dito primeiro estágio de resolução de DNS (R2-EP-2) também enviando ao usuário final, por meio de um rastreador (R2- Rastreador) da dita segunda região (Região 2), o endereço de 15 URL modificado, e uma lista ordenada de endereços de IP de pontos terminais (R2-EP-1, R2-EP-2) com pelo menos o dito pelo menos um ponto terminal (R2-EP-1) que pode servir o conteúdo.
18. MÉTODO, de acordo com a reivindicação 17, 20 caracterizado pelo dito redirecionamento de HTTP de II) ainda compreender, após a dita etapa d): - o usuário final conectando-se diretamente ao dito pelo menos um ponto terminal (R2-EP-1) que pode servir o conteúdo ao enviar uma solicitação de conexão a ele, e o 25 endereço de URL recebido; - o pelo menos um ponto terminal (R2-EP-1) que pode servir o conteúdo recebendo a dita solicitação de URL, verificando a ID de partição do usuário final, modificando o dito endereço de URL ao incluir as ditas informações de PID 30 de usuário final PID nele, e retornando o dito endereço de URL modificado ao usuário final utilizando uma mensagem de redirecionamento de HTTP; e em que o método ainda compreende um segundo estágio de resolução de DNS compreendendo a realização das seguintes etapas: - o usuário final enviando uma solicitação de DNS modificada, com base no dito endereço de URL modificado ao 5 resolvedor de DNS de IPS; - o resolvedor de DNS de IPS consultando o servidor de DNS de autoridade para resolver um domínio de segundo nível do dito endereço de URL modificado da dita solicitação de DNS modificada; 10 - o servidor de DNS de autoridade do domínio de segundo nível resolvendo a dita região do usuário final (Região 1) da URL recebida e realizando uma pesquisa em sua base de dados e respondendo ao resolvedor de DNS de IPS com o endereço de IP do servidor de DNS (R1-DNS) de autoridade 15 para a região de destino (Região 1); - o resolvedor de DNS de IPS consultando o dito servidor de DNS (R1-DNS) de autoridade para a região de destino (Região 1) para resolver a URL recebida; - o servidor de DNS (R1-DNS) de autoridade para a 20 região de destino (Região 1) recebendo a dita solicitação de DNS modificada e encaminhando a dita solicitação de DNS modificada ao rastreador (R1-Rastreador) da região de usuário final (Região 1); - o dito rastreador (R1-Rastreador) da região de 25 destino (Região 1) reconhecendo a solicitação para ser uma solicitação de redirecionamento, identificando uma lista ordenada de pontos terminais (R1-EP-2, R1-EP-1) que são menos carregados e mais próximos ao usuário final solicitante, e enviando a dita lista de pontos terminais 30 (R1-EP-2, R1-EP-1) ao servidor de DNS (R1-DNS) de autoridade para a região de destino (Região 1); - o servidor de DNS (R1-DNS) de autoridade para a região de usuário final (Região 1) encaminhando a lista recebida de pontos terminais (R1-EP-2, R1-EP-1) ao resolvedor de DNS de IPS; - o resolvedor de DNS de IPS retornando a lista de pontos terminais (R1-EP-2, R1-EP-1) ao usuário final 5 solicitante; - o usuário final enviando a solicitação de conteúdo como a dita URL modificada ao ponto terminal mais próximo e menos carregado (R1-EP-2), conforme indicado na dita lista de pontos terminais (R1-EP-2, R1-EP-1), a URL 10 modificada contendo o hash do conteúdo, a ID de partição do usuário final e a ID de categoria do conteúdo; e - o dito ponto terminal mais próximo e menos carregado (R1-EP-2) servindo o conteúdo solicitado ao usuário final.
19. MÉTODO, de acordo com a reivindicação 1, caracterizado por compreender um redirecionamento intraregião entre pelo menos dois centros de dados (Centro de dados 1, Centro de dados 2, Centro de dados 3) na mesma região (Região 1) de uma entidade operacional (OB1), em que: 20 - o dito usuário final está geograficamente próximo a um primeiro centro de dados (Centro de dados 1) dos ditos pelo menos dois centros de dados (Centro de dados 1, Centro de dados 2, Centro de dados 3), - a dita subzona sendo a dita região (Região 1) na 25 dita entidade operacional (OB1), - cada centro de dados (Centro de dados 1, Centro de dados 2, Centro de dados 3) compreendendo um ou mais pontos terminais (R1-D1-1, R1-D1-2; R1-D2-1, R1-D2-2; R1-D3- 1, R1-D3-2); 30 - o dito resolvedor de DNS de IPS está na dita região (Região 1), e - o dito pelo menos um ponto terminal que pode servir o conteúdo é um ponto terminal (R1-D3-2) colocado na dita região (Região 1) está no dito primeiro centro de dados (Centro de dados 1).
20. MÉTODO, de acordo com a reivindicação 19, caracterizado pelo dito estágio de resolução de DNS de I) 5 ser um primeiro estágio de resolução de DNS, a dita etapa d) ainda compreende o dito ponto terminal que participa no dito primeiro estágio de resolução de DNS (R1-D3-1) também enviando ao usuário final, junto a um endereço de URL modificado, os endereços de IP de pelo menos o dito pelo 10 menos um ponto terminal (R1-D3-2) que pode servir o conteúdo conforme pedido pelo rastreador (R1-Rastreador).
21. MÉTODO, de acordo com a reivindicação 20, caracterizado pelo dito redirecionamento de HTTP de II) ainda compreender, após a dita etapa d): 15 - o usuário final se conectar diretamente ao dito ponto terminal (R1-D3-2) que pode servir o conteúdo ao enviar uma solicitação de conexão a ele, com um endereço de URL modificado que também identifica o conteúdo solicitado; - o ponto terminal (R1-D3-2) que pode servir o 20 conteúdo recebendo a dita solicitação de conexão endereço de URL, verificando a ID de partição com base no endereço de IP do usuário final, modificando o dito endereço de URL ao incluir a dita ID de partição de usuário final, e retornando o dito endereço de URL modificado ao usuário final como uma 25 mensagem de redirecionamento de HTTP; e em que o método ainda compreende um segundo estágio de resolução de DNS compreendendo a realização das seguintes etapas: - o usuário final enviando uma solicitação de DNS 30 modificada, que é o endereço de URL modificado, ao resolvedor de DNS de IPS; - o resolvedor de DNS de IPS identificando a dita solicitação de DNS modificada como destinada para a dita região (Região 1) e consultando o servidor de DNS de autoridade (R1-DNS) na dita região (Região 1) para resolver o domínio de segundo nível da URL recebida; - o dito servidor de DNS de autoridade (R1-DNS) 5 encaminhando a dita solicitação de DNS modificada ao rastreador (R1-Rastreador) da dita região (Região 1); - o dito rastreador de região de usuário final (R1- Rastreador) reconhecendo que a solicitação é uma solicitação de redirecionamento intra-região, identificando o ponto 10 terminal ou pontos terminais (R1-D1-2, R1-D1-1) que são mais bem posicionados para servir o conteúdo ao usuário final solicitante, e enviando uma lista ordenada referente aos ditos pontos terminais (R1-D1-2, R1-D1-1) ao usuário final; - o usuário final conectando-se diretamente ao 15 ponto terminal (R1-D1-2) menos carregado e mais próximo ao usuário final, conforme indicado na dita lista de pontos terminais (R1-D1-2, R1-D1-1); e - o dito ponto terminal menos carregado e mais próximo (R1-D1-2) servindo o conteúdo solicitado ao usuário 20 final.
BR112013029001-3A 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 BR112013029001B1 (pt)

Applications Claiming Priority (3)

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
ESP201130754 2011-05-12
PCT/EP2012/058395 WO2012152765A1 (en) 2011-05-12 2012-05-07 A method for dns resolution of content requests in a cdn service

Publications (2)

Publication Number Publication Date
BR112013029001A2 BR112013029001A2 (pt) 2017-01-17
BR112013029001B1 true BR112013029001B1 (pt) 2022-11-22

Family

ID=46208439

Family Applications (1)

Application Number Title Priority Date Filing Date
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

Country Status (7)

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

Families Citing this family (104)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8028090B2 (en) 2008-11-17 2011-09-27 Amazon Technologies, Inc. Request routing utilizing client location information
US7991910B2 (en) 2008-11-17 2011-08-02 Amazon Technologies, Inc. Updating routing information based on client location
US7970820B1 (en) 2008-03-31 2011-06-28 Amazon Technologies, Inc. Locality based content distribution
US8533293B1 (en) 2008-03-31 2013-09-10 Amazon Technologies, Inc. Client side cache management
US8606996B2 (en) 2008-03-31 2013-12-10 Amazon Technologies, Inc. Cache optimization
US8601090B1 (en) 2008-03-31 2013-12-03 Amazon Technologies, Inc. Network resource identification
US7962597B2 (en) 2008-03-31 2011-06-14 Amazon Technologies, Inc. Request routing based on class
US8321568B2 (en) 2008-03-31 2012-11-27 Amazon Technologies, Inc. Content management
US8447831B1 (en) 2008-03-31 2013-05-21 Amazon Technologies, Inc. Incentive driven content delivery
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
US8412823B1 (en) 2009-03-27 2013-04-02 Amazon Technologies, Inc. Managing tracking information entries in resource cache components
US8688837B1 (en) 2009-03-27 2014-04-01 Amazon Technologies, Inc. Dynamically translating resource identifiers for request routing using popularity information
US8756341B1 (en) 2009-03-27 2014-06-17 Amazon Technologies, Inc. Request routing utilizing popularity information
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
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
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
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
EP3249546B1 (en) 2011-12-14 2022-02-09 Level 3 Communications, LLC Content delivery network
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
US10791050B2 (en) 2012-12-13 2020-09-29 Level 3 Communications, Llc Geographic location determination in a content delivery framework
US20140337472A1 (en) 2012-12-13 2014-11-13 Level 3 Communications, Llc Beacon Services in a Content Delivery Framework
US10652087B2 (en) 2012-12-13 2020-05-12 Level 3 Communications, Llc Content delivery framework having fill services
US9634918B2 (en) 2012-12-13 2017-04-25 Level 3 Communications, Llc Invalidation sequencing in a content delivery framework
US10931541B2 (en) 2012-12-13 2021-02-23 Level 3 Communications, Llc Devices and methods supporting content delivery with dynamically configurable log information
US10701148B2 (en) 2012-12-13 2020-06-30 Level 3 Communications, Llc Content delivery framework having storage services
US10205698B1 (en) 2012-12-19 2019-02-12 Amazon Technologies, Inc. Source-dependent address resolution
EP2747379B1 (en) 2012-12-19 2015-08-05 Telefonica, S.A. A distributed health-check method for web caching in a telecommunication network
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
US9391847B2 (en) 2013-08-08 2016-07-12 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
US9819567B1 (en) 2015-03-30 2017-11-14 Amazon Technologies, Inc. Traffic surge management for points of presence
US9887931B1 (en) 2015-03-30 2018-02-06 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
EP3391628B1 (en) * 2015-12-18 2021-08-25 Amazon Technologies, Inc. Use of virtual endpoints to improve data transmission rates
US10348639B2 (en) 2015-12-18 2019-07-09 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
US10505961B2 (en) 2016-10-05 2019-12-10 Amazon Technologies, Inc. Digitally signed network address
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的网络连接方法及装置
CA3072956C (en) * 2017-08-14 2024-06-11 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
EP2708013A1 (en) 2014-03-19
ES2425626A2 (es) 2013-10-16
AR086336A1 (es) 2013-12-04
ES2550674T3 (es) 2015-11-11
US20150288647A1 (en) 2015-10-08
BR112013029001A2 (pt) 2017-01-17
CL2013003221A1 (es) 2014-08-01
ES2425626B1 (es) 2014-06-05
US9565157B2 (en) 2017-02-07
ES2425626R1 (es) 2013-10-22
EP2708013B1 (en) 2015-07-22
WO2012152765A1 (en) 2012-11-15

Similar Documents

Publication Publication Date Title
BR112013029001B1 (pt) Método para resolução de dns de solicitações de conteúdo em um serviço de cdn
US10706029B2 (en) Content name resolution for information centric networking
Mahadevan et al. CCN-krs: A key resolution service for ccn
CN105959433B (zh) 一种域名解析方法及其域名解析系统
EP2721787B1 (en) Principal-identity-domain based naming scheme for information centric networks
US9712422B2 (en) Selection of service nodes for provision of services
US20140215059A1 (en) Method and a tracker for content delivery through a content delivery network
JP2013538410A (ja) ネットワーク環境における要求ルーティング
WO2002078285A2 (en) Internet protocol (ip) address proximity detection and application to peer provider location
CN103618801B (zh) 一种p2p资源共享的方法、设备及系统
CN105282269B (zh) 一种本地dns根服务器的配置方法和服务方法
JP2014501958A (ja) ネットワークにおけるコンテンツにアクセスする方法および対応するシステム
Afanasyev Addressing operational challenges in Named Data Networking through NDNS distributed database
EP2707997A1 (en) Method for managing the infrastructure of a content distribution network service in an isp network and such an infrastructure
Li et al. CDN-hosted domain detection with supervised machine learning through DNS records
Karakannas et al. Information centric networking for delivering big data with persistent identifiers
Afanasyev et al. Map-and-encap for scaling ndn routing
ES2770652T3 (es) Sistema y método para interconexión de redes de distribución de contenido
Sarddar et al. Edge multilevel edge server co-operation in content delivery network using hierarchical classification
Elbreiki et al. A Comparative Study of Chord and Pastry for the Name Resolution System Implementation in Information Centric Networks
Overeinder et al. Design of a secure and decentralized location service for agent platforms
Spleiß et al. Naming, Assigning and Registering Identifiers in a Locator/Identifier-Split Internet Architecture
Huang et al. SIDMAP: A Service-oriented Mapping System for Loc/ID split Internet Naming.
Yan et al. ISBORD: Internet Searching Based on Resource
Garcia-Luna-Aceves et al. CCN-KRS: A Key Resolution Service for CCN

Legal Events

Date Code Title Description
B06F Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]
B06U Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]
B06A Patent application procedure suspended [chapter 6.1 patent gazette]
B09A Decision: intention to grant [chapter 9.1 patent gazette]
B16A Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]

Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 07/05/2012, OBSERVADAS AS CONDICOES LEGAIS. PATENTE CONCEDIDA CONFORME ADI 5.529/DF, QUE DETERMINA A ALTERACAO DO PRAZO DE CONCESSAO.