MIT 18.996: Tópico da Teoria da Ciência da Computação: Problemas de Pesquisa na Internet – Segundo Trimestre 2002
Aula 1 | 6 de fevereiro de 2002
Palestrante: Tom Leighton Redatores: Omar Aftab, Eamon Walsh
1.1 Introdução
Esta lição tratará de vários problemas de pesquisa relacionados à Internet. Cada aula tratará de:
• Como um determinado componente ou tecnologia da Internet trabalha hoje em dia. • Questões e problemas com a tecnologia atual.
• Novas linhas de pesquisa em potencial.
• Formulação de problemas e soluções concretos.
Começamos analisando como a Web funciona nos dias de hoje, quais as questões com sua arquitetura atual e como os serviços da Akamai estão mudando esse panorama.
Analisaremos em seguida os desafios tecnológicos e concluiremos com as futuras linhas de pesquisa nessa área.
A maioria das aulas incluirá o exemplo de um problema teórico que veio à tona com a pesquisa na Akamai. O exemplo de hoje, que veremos posteriormente, está relacionado à otimização de custos: o problema da atribuição de cada usuário a um servidor ótimo, ao mesmo tempo minimizando os custos totais de largura de banda.
1.2 Como a Web Funciona Hoje em Dia
A Web, quando vista de fora, simplesmente conecta fornecedores de conteúdo a usuários finais.
O interessante da Web é que um público mundial pode ser conectado ao conteúdo sem taxas de licenciamento de qualquer natureza. Qualquer pessoa pode publicar um site da Web e centenas de milhões de pessoas podem vê-lo. Isso não tem precedentes na história do homem.
Apesar de a Internet fornecer conectividade sem precedentes, ela também sofre de instabilidade e apresenta desempenho imprevisível. E, à medida que o número de sites aumenta, esses problemas crescem drasticamente.
1.2.1 Arquitetura da Web: uma Rede de Redes
A Internet é uma rede de redes: hoje em dia, ela consiste em mais de 9.000 redes
individuais, que se comunicam usando o protocolo IP. Essas redes incluem redes grandes de camada única, como UUnet e PSINet, assim como vários provedores (ISPs) pequenos. Para que a Internet aja como uma rede realmente global que conecta todas as pessoas, essas redes individuais devem ser interconectadas usando conexões chamadas de pontos de ‘rede não-hierárquica’.
1-1
Um ponto de rede não-hierárquica é essencialmente uma conexão entre dois roteadores localizados em diferentes redes.
Para os dados passarem de uma rede para outra, eles devem atravessar essa conexão. Na verdade, há muitos milhares desses pontos de rede não-hierárquica na Web e, para que os dados cheguem ao usuário final, eles devem passar por muitas redes e pontos de rede não-hierárquica individuais.
Dois diferentes tipos de protocolos ajudam a direcionar o tráfego na Web hoje em dia. Os protocolos IGP (Interior Gateway Protocols), como o RIP, roteiam dados em uma rede individual. O mais importante para nós é o EGP (Exterior Gateway Protocol) BGP, usado para rotear dados entre redes. Enquanto os IGPs usam uma ampla variedade de métodos sofisticados para determinar o caminho de roteamento ótimo – incluindo topologia, largura de banda e congestionamento -, o BGP não faz isso.
Na verdade, o BGP determina as rotas simplesmente minimizando o número de redes individuais que os dados devem atravessar. Essa abordagem, apesar de escalável, não lida bem com o congestionamento.
A arquitetura atual da Internet aprimora muito a escalabilidade da Web e permitiu que ela expandisse rapidamente. No entanto, inerente a essa arquitetura, existem quatro diferentes estrangulamentos que, com o crescimento da Web, podem afetar drasticamente o
desempenho. Esses estrangulamentos são representados na figura abaixo (Figura 1.1) e serão analisados individualmente.
Figura 1.1. Problemas com a arquitetura da Internet nos dias de hoje
Problema da Última Milha Problema da Primeira Milha
Usuário Final Problema de Rede Não-Hierárquica Internet Problema de Backbone Servidor Host
O Estrangulamento de Primeira Milha
O primeiro estrangulamento é uma conseqüência direta do fato de que, com 400 milhões de usuários, a centralização simplesmente não funciona. O conteúdo conectado à Web em um ponto pode rapidamente se sobrecarregar quando demandado por um público grande e mundial. Tradicionalmente, cada fornecedor de conteúdo monta um site da Web central em um único local. Esse site fornece dados para o mundo todo. Isso significa que a
conectividade de primeira milha – a capacidade de largura de banda do site central – limitará o desempenho.
1-2
Para se adaptar a um número crescente de usuários, o fornecedor de conteúdo deve adquirir cada vez mais largura de banda de seu provedor de acesso (ISP), porém, mais importante que isso, o ISP também deve expandir continuamente sua própria capacidade de rede – e seus pares também! Assim, a solução centralizada é claramente não-escalável.
Figura 1.2. O estrangulamento de primeira milha.
Um exemplo desse problema é o Victoria’s Secret Online Fashion Show, que foi muito anunciado no Super Bowl de 1999. No momento em que mais de um milhão de assinantes tentaram acessar a webcast simultaneamente, os servidores da central não suportaram, sobrecarregando o site e impedindo praticamente todos os visitantes de ver a webcast. Outros exemplos incluem os sites não-Akamai que contêm os trailers de Guerra nas Estrelas e o site da NASA que transmite conteúdo sobre o Mars Rover. Em cada caso, a demanda de conteúdo foi maior do que a capacidade de primeira milha do site da Web, atrapalhando o desempenho.
O Problema da Rede Não-Hierárquica
A Internet hoje em dia é uma rede de redes, com pontos de rede não-hierárquica entre elas (Figura 1.2).
Para atravessar a Internet, o tráfego deve passar por muitos pontos de rede não-hierárquica entre essas redes individuais. Mesmo que a largura de banda das duas redes seja grande internamente, o estrangulamento muitas vezes é o ponto de acesso entre elas.
Há uma concepção errada comum de que “grandes jogadores” controlam grandes partes do tráfego da Internet. Se uma única rede fosse ser responsável pela maior parte do tráfego da Internet, a maioria dos destinos poderia ser alcançada dentro dessa rede e nenhum ponto de rede não-hierárquica precisaria ser atravessado. No entanto, não é isso o que ocorre. Na realidade, não há uma única rede que controle mais de 6% do tráfego da Internet.1. Como o tráfego é regularmente distribuído pelos milhares de redes, a maior parte deve trafegar por diversas redes e, conseqüentemente, vários pontos de rede não-hierárquica – que são uma fonte de congestionamento.
1Por tráfego entendemos o número de bits transferidos, e não o número de usuários. Um grande número de assinantes pode produzir apenas uma pequena quantidade de tráfego, caso suas conexões sejam lentas, como no caso da AOL. O serviço de banda larga, o Excite@Home, por exemplo, produz aproximadamente o mesmo tráfego de Internet que a AOL, apesar de ter muito menos assinantes.
1-3
Figura 1.3. Muitas redes dentro da Internet
Fornecedores de conteúdo Usuários finais
Há três questões principais com relações de rede não-hierárquica entre redes: Economia
Muitos ISPs restringem deliberadamente seus pontos de rede não-hierárquica para afastar grandes volumes de tráfego externo. Freqüentemente ocorrem discussões sobre
pagamento; provedores grandes tradicionalmente cobram dos menores o uso de seus backbones, mas as empresas maiores, de “Nível 1”, tradicionalmente não fazem cobranças entre si. Como as redes menores devem pagar às maiores pelo uso do backbone, elas tendem a adquirir somente capacidade suficiente para lidar com o tráfego atual. Isso
significa que as conexões de rede não-hierárquica operam em capacidade quase total, o que resulta em perdas e atrasos de pacotes. As redes maiores, por razões econômicas
semelhantes, tendem a não querer se conectar com outras redes maiores, visto que não são pagas para isso. As forças da economia ocasionalmente fazem o sistema fracassar. A Cable & Wireless uma vez negou serviço a diversas redes, exigindo pagamento. Entre elas estava a PSINet, outro backbone da Camada 1, que se recusou a pagar. Essa ação fragmentou a Internet por três dias; os assinantes da PSINet não puderam ter acesso ao conteúdo oferecido pela C&W e vice-versa. O serviço foi restaurado somente quando a divisão de hospedagem da C&W ficou sobrecarregada de reclamações dos clientes cujos sites estavam inacessíveis a clientes da PSINet.
Protocolos de Roteamento
Conforme dito, os protocolos EGP (Exterior Gateway Protocols), como o BGP, usam algoritmos tradicionais do caminho mais curto para determinar rotas ótimas, ignorando o congestionamento – ainda que informações como tamanhos de fila estejam disponíveis para os roteadores. Conseqüentemente, quando conexões de redes não hierárquicas ficam congestionadas, o BGP continua enviando o tráfego para elas, exacerbando o problema. Erro Humano
Os protocolos de roteamento também recebem instruções de operadores humanos, o que pode levar à perda acidental de rotas ou à introdução de rotas incorretas. Por exemplo, os operadores de sistemas são responsáveis por definir o número de hops falsamente anunciados para outras redes. Os jogos são muitas vezes jogados quando os hops são anunciados falsamente, com o objetivo de desviar o tráfego para redes concorrentes etc. Isso pode causar um desastre, como no caso em que um Engenheiro Nível 3 anunciou inadvertidamente rotas com um custo de -∞ para todos os pontos. Uma quantidade enorme
1-4
de tráfego foi então roteado através do Nível 3, criando um congestionamento imenso. Conforme mencionado, o BGP ignora o congestionamento ao determinar rotas ótimas, e o problema rapidamente afetou três quartos do tráfego da Internet. A interrupção durou 45 minutos.
O problema com a rede não-hierárquica é inerente à arquitetura da Web. Apesar de se ter argumentado que os problemas com a rede não-hierárquica deveriam diminuir à medida que as empresas de telecomunicações se consolidassem e as redes se fundissem, não há sinais de que isso esteja ocorrendo. O número de diferentes redes está, na verdade, aumentando. Backbone da Internet
Outro estrangulamento é a capacidade das redes grandes, de longa distância, que incluem o backbone da Internet. No modelo centralizado de servidor de página da Web, quase todas as solicitações acabam atravessando uma rede de backbone do usuário final ao servidor central. Isso significa que as redes principais (core) devem gerenciar todo o tráfego na Web hoje em dia. Atualmente, isso é apenas uma questão para os países estrangeiros e o acesso global. À medida que o tráfego na Internet crescer, essa questão se tornará mais urgente. A Última Milha
A maioria dos usuários de Internet está familiarizada com o estrangulamento de última milha: a velocidade de 56 KB do modem para o provedor. Uma concepção errada, no entanto, é a de que a introdução da DSL de banda larga resolveria todas as questões de desempenho. Não foi assim. Problemas de upstream continuarão causando quedas de desempenho: a qualidade da conexão depende do link mais fraco. Na verdade, a velocidade limitada dos modems está salvando a Internet de uma completa interrupção: se todos os usuários pudessem solicitar conteúdo a taxas de banda larga, haveria tanto
congestionamento nos outros três tipos de estrangulamentos que o tráfego na Internet seria paralisado. Na verdade, a Internet hoje em dia está sendo executada perto do limite da sua capacidade: as outras questões devem ser consideradas antes de se sujeitar a arquitetura a milhões de usuários adicionais da banda larga.
1.2.2 Implicações do Estrangulamento
A arquitetura atual da Internet exige que todo o tráfego passe por várias redes até atingir os fornecedores de conteúdo centrais. Quando se faz isso, é provável que se enfrentem os quatro tipos de estrangulamentos antes de atingir seu destino. Isso traz sérias implicações: Downloads Lentos
O conteúdo deve atravessar vários backbones, pontos de rede não-hierárquica freqüentemente congestionados e longas distâncias para chegar ao usuário final. O desempenho é, assim, freqüentemente lento.
Desempenho Pouco Confiável
Muitas vezes, o conteúdo pode ser bloqueado como resultado de um congestionamento ou por problemas de rede não-hierárquica. Um site que esteja funcionando perfeitamente em um minuto pode ficar inacessível no seguinte.
1-5
Falta de Escalabilidade
Como cada usuário deve recuperar dados diretamente de um servidor central, existem vários problemas sérios de escalabilidade. O uso é limitado pela largura de banda presente no site central.
Qualidade Inferior de Streaming
O streaming multimídia, que é a principal meta dos fornecedores de conteúdo, é inviável no modelo de servidor central. A perda de pacotes, o congestionamento e pipes estreitos servem para diminuir a qualidade do streaming, tornando o vídeo de alta resolução sob encomenda uma tarefa impossível.
Banda Larga No Silver Bullet
Conforme discutido, a banda larga não é uma solução para os estrangulamentos
mencionados – na verdade, ela só servirá para exacerbar o congestionamento de primeira milha, questões de rede não-hierárquica e o congestionamento de backbone à medida que cresce o número de pessoas que tentam downloads maiores.
1.3 Solução da Akamai: Entrega de Ponta
A solução da Akamai é evitar os estrangulamentos da Internet fornecendo conteúdo diretamente de seus servidores para o usuário final pela última milha. Essa alternativa para a distribuição centralizada é chamada de “edge delivery”. Nesse modelo, o conteúdo de cada site da Web está disponível a partir de servidores localizados na ponta da Internet: o ideal é que o usuário possa encontrar todo o conteúdo solicitado em um servidor Akamai localizado na sua rede doméstica. Com aproximadamente 15.000 servidores distribuídos por mais de 60 países pelo mundo, há grandes possibilidades de que todo usuário de Internet possua um servidor Akamai nas proximidades.
Figura 1.4. Edge delivery
1-6
1.3.1 Vantagens
O modelo da Akamai possui diversas vantagens em relação ao status quo. A solução da Akamai evita o estrangulamento de primeira milha eliminando o ponto central a partir do qual todos os dados foram acessados. O conteúdo está em servidores próximos ao usuário final, e não em um servidor central geograficamente distante e freqüentemente
congestionado, como mostra a Figura 1.4. Como o conteúdo de cada site agora está disponível em vários servidores, sua capacidade não é mais limitada pela velocidade da única conexão de rede. O sistema também é mais confiável, visto que não há um só ponto de falha. Se um servidor Akamai falhar, seus usuários serão automaticamente direcionados para outro.
A edge delivery também resolve o problema da rede não-hierárquica. Os dados não precisam mais passar por várias redes e pontos congestionados de rede não-hierárquica. Eles podem ser recuperados diretamente da rede doméstica, o que resulta em downloads mais rápidos. É claro que isso significa que toda ou quase toda a rede deve ter seu servidor Akamai local. Além disso, como o conteúdo é entregue da ponta da rede, a demanda de capacidade de backbone também reduz muito.
Evidentemente, a edge delivery não resolve o problema da última milha diretamente. Porém, entregando o conteúdo mais perto dos usuários finais e resolvendo os problemas de upstream, ela permite a introdução bem-sucedida da banda larga.
A melhora no desempenho proporcionada pela Akamai pode ser vista na Figura 1.5. O gráfico mostra a média dos tempos de acesso globais para um site da Web com e sem a Akamai. Observe em primeiro lugar que os tempos de acesso são significativamente mais altos durante as horas comerciais em dias de semana, devido à carga de LANs corporativas com largura de banda alta. É claro que hospedar um site com a Akamai apresenta duas vantagens distintas. Primeiro, a média do tempo de acesso geral é reduzida: em alguns casos, até 800%.
Segundo, o desempenho do site da Web é muito mais regular durante toda a semana.
Figura 1.5. Desempenho do Site da Web: Melhoras Típicas com a Akamai
Objeto da Web entregue sem a Akamai Objeto da Web entregue pela Akamai
1-7
1.3.2 Ofertas de Serviço da Akamai
• O FreeFlow era o Serviço de Entrega de Conteúdo original da Akamai para objetos estáticos da Web, como banners e imagens. Como o EdgeSuite, o atual produto agship da Akamai, o FreeFlow fornece conteúdo dos servidores da Akamai distribuídos na ponta da rede para o usuário final. Isso é feito através da modificação do código HTML original do site para o redirecionamento do usuário final para um servidor Akamai apropriado, usando-se algoritmos de rede sofisticados que levam em conta o congestionamento e a topologia da rede. O servidor Akamai fornece, então, a maior parte dos dados necessários para o download da página. Isso reduz drasticamente a comunicação entre o usuário final e o servidor central do fornecedor de conteúdo, garantindo, assim downloads rápidos.
• O FreeFlow Streaming utiliza as vantagens da edge delivery para fornecer conteúdo de streaming para visitantes de todo o mundo, com grandes melhorias em qualidade e
confiabilidade. No caso do streaming sob demanda, a Akamai armazena cópias de difusão de mídia em seus servidores de ponta, melhorando o desempenho, assegurando que os streams sejam entregues aos usuários finais por servidores próximos a eles. Para dar suporte ao live streaming, a Akamai transmite vários streams para sua rede de servidores de mídia
localizados na ponta da Web. O evento é então remontado no servidor de ponta e retransmitido diretamente para o usuário final – evitando problemas de qualidade na transmissão e congestionamento. A Akamai também utiliza essa tecnologia para oferecer aplicações de streaming, como o Akamai Conference e o Akamai Forum.
• O Akamai Conference usa a mídia de streaming para ampliar o alcance e a funcionalidade da chamada em conferência padrão. Ele oferece live streaming de áudio e vídeo e outros recursos interativos.
• O Akamai Forum é uma solução que gerencia todo os processo de produção e difusão de eventos de mídia de streaming. Ele permite que as empresas produzam webcasts interativas ao vivo. O fórum não requer software especial do lado cliente, permite contato e participação ao vivo do público e apresenta slides de apresentação sincronizados.
• O FirstPoint é um serviço de gerenciamento de tráfego global para fornecedores de conteúdo com vários sites espelhados. O FirstPoint monitora o tráfego e o congestionamento da rede e conecta os usuários finais ao melhor site espelhado usando DNS. O FirstPoint foi projetado para interoperar com outros serviços da Akamai.
• O EdgeScape permite que os fornecedores de conteúdo customizem o conteúdo do site deles com base na largura de banda da conexão, no endereço IP do usuário e em sua localização geográfica. Por exemplo, os sites podem ajustar automaticamente seu conteúdo à largura de banda disponível ao usuário, anunciar produtos e serviços locais e eliminar a necessidade do usuário de especificar sua localização. O sistema EdgeScape consiste em bancos de dados locais em servidores por toda a rede Akamai. Esses servidores customizam as páginas da Web com base nos dados coletados sobre o usuário: novamente a entrega do conteúdo é de ponta – os servidores tratam das solicitações do usuário diretamente e só entram em contato com o servidor central do fornecedor de conteúdo para atualizar seus bancos de dados. • O DPS (Digital Parcel Service): muitos fornecedores hoje em dia se preocupam em colocar
conteúdo on-line por medo de que ele seja utilizado sem que o pagamento por esse serviço seja efetuado. O DPS permite que somente usuários autorizados e que tenham efetuado o pagamento acessem o material on-line. É uma solução completa de distribuição digital, relatórios e administração de direitos.
1-8
• O Reporter & Traffic Analyzer fornece dados históricos e em tempo real de uso em sites da Web. Essas excelentes ferramentas permitem data mining customizados e exibição em tempo real do tráfego do cliente. Isso permite ao cliente avaliar a eficácia de sua propaganda e das promoções de marketing, a popularidade de seus eventos de streaming etc.
• O Akamai Content Storage: é um serviço que permite aos clientes armazenar arquivos em servidores Akamai localizados estrategicamente. Esses arquivos são depois entregues ao usuário final pelo Digital Parcel Service, pelo FreeFlow, pelo FreeFlow Streaming etc.
• O EdgeSuite é a próxima geração do serviço “edge delivery”; a maioria do serviços da Akamai é empacotada e incorporada ao EdgeSuite. Lançado em 2001, o
EdgeSuite fornece serviços de organização de conteúdo, entrega e gerenciamento da ponta da rede. Ele permite que um servidor de ponta reúna e hospede páginas de um conjunto de elementos variáveis, direcionando exclusivamente cada página para a pessoa que solicitou os dados. À medida que os sites vão ficando mais
customizados e interativos, a capacidade de organizar as páginas da Web na ponta da rede sem precisar se reportar continuamente ao servidor central vai se tornando cada vez mais importante: isso alivia a carga no fornecedor de conteúdo central e melhora o desempenho para o usuário final.
No caso das primeiras soluções de conteúdo, como o FreeFlow, todos os processos de aplicação ocorriam no servidor central: os servidores no núcleo executavam aplicativos e montavam o HTML para transmissão ao usuário final. O aumento de velocidade foi obtido pela recuperação de objetos maiores e pesados, como imagens gráficas e mídia dos servidores de ponta.
As soluções de entrega de conteúdo de montagem de ponta, por sua vez, possibilitam que grande parte de um aplicativo Internet tenha seu cache e servidor na ponta, o que permite a customização dinâmica, a individualização e até mesmo um desempenho mais alto. Usando a montagem de ponta, o servidor armazena em cache os resultados das consultas a bancos de dados, o que reduz muito a carga nos servidores centrais. Suponha, por exemplo, que um site possua informações sobre o tempo. Essas informações podem ser armazenadas em cache por até 15 minutos sem ficarem obsoletas. Esse tempo após o qual cada dado em cache se torna inválido e precisa ser atualizado é chamado de “Tempo de Vida” (“Time To Live”). Quando um usuário solicitar informações sobre o tempo em Boston, o conteúdo será recuperado do servidor central e armazenado em cache no servidor de ponta que respondeu a essa solicitação. Quando outro usuário solicitar informações sobre o tempo em Nova York, esse conteúdo
também será armazenado em cache. Se um terceiro usuário vier a solicitar informações sobre o tempo em Nova York ou Boston, o servidor de ponta não terá que entrar em contato com o servidor central, mas poderá organizar uma página apropriada e
responder diretamente. Com vários usuários, essa técnica pode reduzir muito a carga no servidor central. Somente quando o TTL (Tempo de Vida) tiver expirado, o servidor de ponta precisará entrar em contato com o banco de dados central.
Assim como fez o FreeFlow, o EdgeSuite melhora o desempenho do site da Web hospedando conteúdo da ponta da rede. No entanto, usando o EdgeSuite, muito mais conteúdo é reunido e entregue pela ponta, fornecendo um desempenho ainda melhor.
1-9
1.4 Visão Geral da Tecnologia
Fornecemos uma ampla visão de como o sistema Akamai funciona. Vamos considerar os detalhes da tecnologia e as questões associadas a ela nas aulas seguintes. Começaremos comparando como um site é acessado com e sem a vantagem dos serviços da Akamai. 1.4.1 Baixando um Site da Web da Maneira Tradicional
Quando um usuário solicita um site da Web como o web.mit.edu, uma série de eventos ocorre por trás da tela do navegador. O navegador precisa primeiro resolver o endereço IP de web.mit.edu. Essa resolução é feita pelo DNS (Domain Name Service), que funciona como as “páginas em branco” da Internet. Em um nível alto, o DNS mapeia o endereço familiar web.mit.edu para o endereço IP 18.7.21.77. Depois que o serviço DNS retorna o endereço IP, o navegador contata o servidor nesse endereço e solicita a página. O servidor da Web retorna o HTML, que inclui ele mesmo links incorporados para outros objetos, como imagens. O navegador deve, então, repetir o processo de pesquisa para cada objeto incorporado, solicitá-lo e recuperá-lo. Na prática, os navegadores podem abrir várias
conexões simultâneas para recuperar páginas inteiras – objetos, como imagens, são muitas vezes vistos aparecendo na página na ordem em que foram recuperados.
Figura 1.6. Recuperando uma página da Web do modo convencional.
Servidor da Web do Cliente
1. O DNS procura www.xyz.com.
2. O endereço IP de www.xyz.com é retornado.
3. O navegador solicita o HTML do servidor no endereço IP 10.10.123.8. 4. O servidor retorna o HTML, incluindo links incorporados.
5. O navegador faz pesquisas de objetos incorporados no DNS. 6. O navegador solicita o objeto incorporado do servidor. 7. O servidor retorna o objeto incorporado para o navegador.
1-10
1.4.2 Pesquisas de DNS da Maneira Tradicional
O processo de pesquisa de DNS em si consiste em várias etapas. É importante entender esse processo porque o sistema EdgeSuite da Akamai trabalha modificando-o.
Quando confrontado com um endereço como web.mit.edu, o navegador primeiro consulta seu próprio cache para determinar se ele já identificou o nome. Em caso negativo, o sistema operacional, que também mantém um cache, é atualizado. Se isso também não der certo, o navegador deverá fazer uma conexão com seu servidor de nome local e solicitar um endereço IP para mit.edu.
O servidor de nome local mantém um registro dos endereços que ele já identificou. Se mit.edu for um deles (e a entrada não tiver expirado), ele simplesmente retornará o registro local. Caso contrário, o servidor de nome local deverá procurar uma autoridade superior, fazendo uma pesquisa recursiva. A pesquisa pode acabar atingindo a mais alta autoridade: um servidor DNS raiz mantido pelo InterNIC. O servidor InterNIC mantém um registro de cada nome de domínio registrado na Web e, conseqüentemente, resolve o mit.edu. Essa resolução fornece o endereço IP do servidor DNS para o domínio mit.edu.
O servidor DNS local agora entra em contato com o servidor DNS de mit.edu para obter a resolução para web.mit.edu. Ele recebe um endereço IP, o qual poderá ser armazenado em seu cache e retornado ao sistema operacional da máquina original, que o passa, finalmente, de volta para o navegador.
Figura 1.7. Fazendo uma pesquisa de DNS da maneira tradicional.
Raiz .net (InterNIC) Servidor de Nome Local
TTL: 1 dia TTL: 30 minutos Servidores DNS xyz.com
Cache do Navegador Sistema Operacional
1. O navegador procura www.xyz.com no cache.
2. A consulta é dirigida ao cache do sistema operacional. 3. O servidor de nome local é contatado.
1-11
4. O servidor de nome local faz uma chamada recursiva, acabando em um servidor de nome raiz.
5. O servidor de nome raiz retorna o endereço IP para o servidor DNS de xyz.com. 6. O servidor de nome local entra em contato com o servidor DNS de xyz.com. 7. O servidor DNS de xyz.com retorna o endereço IP de www.xyz.com.
8. O endereço IP retorna ao sistema operacional da máquina do usuário. 9. O endereço IP é retornado ao navegador, que atualiza seu cache. 10. A solicitação de HTML é iniciada.
1.4.3 Baixando um Site da Web como a Akamai Faz
Quando um usuário solicita um site da Web da Akamai, como o www.yahoo.com, ocorre uma série de eventos um pouco diferentes. Como antes, o navegador, primeiro resolve o endereço IP usando o DNS. Nesse caso, porém, o endereço DNS retornado é o de um servidor Akamai ótimo. O navegador contata então o servidor Akamai para solicitar o HTML. O servidor Akamai organiza a página da Web, fazendo conexões com o servidor Yahoo! central para obter conteúdo dinâmico, como individualizações, caso necessário. O HTML é então retornado ao navegador.
Como antes, esse HTML pode incluir links para objetos incorporados. O navegador obtém os endereços IP para esses objetos incorporados: como antes, o serviço DNS retorna os endereços do servidor Akamai ótimo que hospeda cada objeto. Por fim, o navegador recupera os objetos incorporados dos servidores ótimos.
Figura 1.8. Recuperando uma página da Web como a Akamai Faz.
Servidor da Web do Cliente
1. O DNS procura www.xyz.com.
2. O endereço IP do servidor Akamai ótimo é retornado. 3. O navegador solicita o HTML do servidor Akamai ótimo.
4. O servidor Akamai contata o servidor xyz.com central pela Internet, caso necessário.
1-12
5. O servidor Akamai reúne o HTML e retorna para o navegador.
6. O navegador resolve os links incorporados, obtendo endereços IP para servidores Akamai ótimos que hospedam esses objetos.
7. O navegador recupera os objetos.
Pela abordagem da Akamai, há três questões principais. O serviço DNS deve ser modificado para retornar o endereço do servidor Akamai ótimo de cada usuário específico. Cada
servidor Akamai deve poder conectar-se ao servidor central de um dado site da Web para acesso a registros de bancos de dados etc., mas, como essa conexão é feita pela Internet do modo tradicional, teremos de levar em conta todas as questões e problemas discutidos anteriormente. Por fim, o servidor Akamai deve organizar e entregar a página. Essas questões serão analisadas a seu tempo.
1.4.4 Pesquisas de DNS como a Akamai Faz
Pela abordagem da Akamai, o serviço DNS deve retornar o endereço do servidor Akamai ótimo. Isso requer mudanças no sistema DNS existente. Especificamente, o endereço www.xyz.com não deve se traduzir diretamente para 18.7.21.70, e sim ter um nome
alternativo (alias) para um endereço Akamai intermediário; por exemplo, a212.g.akamai.net, que posteriormente será resolvido para um servidor ótimo.
Vamos examinar o processo de pesquisa de DNS no sistema Akamai. As etapas iniciais da pesquisa são exatamente as mesmas. Como antes, o servidor de nome local é
posteriormente direcionado para o servidor DNS xyz.com. Desta vez, porém, em resposta à sua solicitação relativa a www.xyz.com, o servidor de nome local recebe um alias, que é conhecido no DNS como “CNAME". Esse alias não é um endereço IP, mas um nome de DNS intermediário que resolverá o endereço IP de www.xyz.com. Um exemplo de CNAME no modelo Akamai seria a212.g.akamai.net.
O servidor de nome local agora é confrontado com a tarefa usual de resolver um endereço DNS. Ele faz sua consulta recursiva de DNS em akamai.net, recebendo o endereço IP de um servidor DNS de alto nível da Akamai. Esse servidor é contatado para resolver g.akamai.net. Nesse ponto, o servidor DNS de alto nível faz cálculos geográficos básicos para determinar qual endereço IP deve ser resolvido a partir de g.akamai.net. Esse endereço IP não é o endereço IP de um servidor da Web, mas o endereço de um servidor DNS de nível baixo da Akamai. Esse servidor DNS de nível baixo executará um algoritmo em tempo real mais sofisticado, levando em conta o congestionamento da rede, condições da rede local, carga do servidor etc., e determinará qual o servidor da Web ótimo para o usuário.
O servidor de nome local agora entra em contato com esse servidor DNS de nível baixo para solicitar a resolução de a212.g.akamai.net e finalmente recebe o endereço IP do servidor Akamai ótimo que hospeda o conteúdo do site da Web que está sendo solicitado. 1. O navegador procura www.xyz.com no cache.
2. A consulta é direcionada ao cache do sistema operacional. 3. O servidor de nome local é contatado.
4. O servidor de nome local faz chamada recursiva, acabando em um servidor de nome raiz
1-13
Figura 1.9. Fazendo uma Pesquisa de DNS como a Akamai Faz
Servidor de nome da xyz.com Raiz .net Servidores DNS de Alto Nível da Akamai Servidores DNS de Nível Baixo da Akamai Usuário Final Servidor de Nome Local
Cache do Navegador
5. O servidor de nome raiz retorna o endereço IP do servidor DNS de xyz.com. 6. O servidor de nome local contata o servidor DNS de xyz.com.
7. O servidor DNS de xyz.com retorna o alias CNAME de a212.g.akamai.net. 8. O servidor de nome local faz chamada recursiva para procurar akamai.net. 9. A consulta resolve akamai.net como 15.15.125.6.
10. O servidor de nome local entra em contato com o servidor DNS de alto nível da Akamai em 15.15.125.6 para resolver g.akamai.net.
11. O HLDNS da Akamai faz cálculos geográficos e reporta o servidor de nome local para um servidor DNS de nível baixo e geograficamente ótimo em 20.20.123.56.
12. O servidor de nome local contata o servidor DNS de nível baixo da Akamai para solicitar a resolução de a212.g.akamai.net.
13. O LLDNS retorna o endereço IP do servidor Akamai ótimo que faz a hospedagem. 14. O endereço IP é retornado ao sistema operacional da máquina do usuário.
15. O endereço IP é retornado ao navegador, que atualiza o cache. 16. A solicitação de HTML tem início.
1-14
1.4.5 Hierarquia de Servidores/Tempo de Vida
Mencionamos anteriormente que os registros de DNS armazenados em cache expiram após determinado “tempo de vida” (TTL).
Um TTL mais longo significa menos pesquisas de DNS recursivas, pois as informações de cache valerão por mais tempo. O perigo de um TTL longo é que, se o endereço IP de um site da Web mudar, ele poderá ficar inacessível até que os endereços armazenados em cache expirem.
No sistema Akamai, só é possível ter alguns servidores DNS de alto nível (HLDNS), devido às restrições do InterNIC. Como todas as solicitações de usuário da Akamai devem ser tratadas
inicialmente por esses servidores, eles estão sob muita carga. Se esses servidores DNS tivessem de determinar o servidor da Web ótimo para cada usuário, levando em consideração as condições da rede em tempo real, eles ficariam sobrecarregados. Na verdade, o servidor DNS de alto nível faz cálculos geográficos preliminares e remete o usuário a um servidor DNS de nível baixo (LLDNS), que então realiza as tarefas intensivas computacionais de determinar o servidor da Web ótimo. Com milhares de servidores DNS de nível baixo, a carga é então bem distribuída.
É provável que seja aceitável para determinado usuário, pelo menos em parte do dia, um servidor DNS de nível baixo, visto que os parâmetros de rede geográficos e de alto nível não variam rapidamente. Assim, quando um usuário é direcionado para determinado servidor LLDNS, seu endereço IP é armazenado em cache por até uma hora. Isso reduz ainda a carga nos servidores HLDNS.
Os servidores DNS de nível baixo, por sua vez, devem determinar o servidor da Web ótimo para cada cliente, levando em conta condições em tempo real, como congestionamento da rede e carga do servidor em uma região geográfica. Como essas condições variam rapidamente, uma vez que um servidor LLDNS direciona um cliente para um servidor da Web específico, o endereço só fica armazenado em cache por alguns segundos. Isso garante que o sistema responda rapidamente a condições variáveis; todo usuário será mapeado para seu servidor ótimo atual.
1.4.6 Mapas de DNS
Os servidores DNS Akamai são responsáveis por determinar de qual servidor o usuário acabará recebendo conteúdo. Tomando essas decisões, os algoritmos levam em conta localização geográfica, congestionamento da Internet, cargas do sistema, status do servidor e demandas do usuário. Os mapas, criados levando-se em conta todos esses fatores, são recalculados constantemente com base nos tempos de vida discutidos anteriormente – a cada hora para os servidores HLDNS e de poucos em poucos segundos para os servidores LLDNS.
1.4.7 Montagem de Ponta do Conteúdo Dinâmico
Conforme analisado anteriormente, o EdgeSuite da Akamai objetiva gerar conteúdo dinâmico na ponta da rede, em vez de se remeter continuamente de volta ao servidor central. Hoje em dia, os
Webdesigners continuam a incluir conteúdo dinâmico – como notícias, preços, temperatura,
customizações etc. – em seus sites. Para fazer isso, eles usam a tecnologia ASP (Active Server Pages) ou similares, que permitem um conteúdo de site da Web rico e individualizado.
No entanto, esse tipo de conteúdo dinâmico causa sérios problemas para a entrega de conteúdo: o esforço de entregar milhares de páginas da Web customizadas, construídas rapidamente, pode atolar seriamente o servidor central – que deve não só gerar o conteúdo mas armazená-lo. A entrega de páginas da Web customizadas da ponta da rede também é desafiante, pois o banco de dados continua no servidor central. Observamos como o EdgeSuite da Akamai lida com essa questão, armazenando em cache elementos de página distintos chamados de fragmentos de conteúdo e os organiza
automaticamente com base em informações de bancos de dados, a fim de formar uma página da Web individualizada para o usuário final.
1-15
Figura 1.10. Comparação de acesso ao servidor tradicional com a montagem de ponta. O EdgeSuite faz isso usando o “EdgeSide Includes" – uma linguagem de marcação aberta cujos pioneiros foram a Oracle e a Akamai. O ESI divide as páginas da Web em fragmentos distintos, cada qual com seu perfil de cache. (No contexto do nosso exemplo anterior, o clima em Boston poderia ser um fragmento desses, armazenado em cache com um tempo de vida de 15 minutos.) Esses fragmentos residem nos servidores de ponta nas redes Akamai e são reunidos em páginas da Web nos servidores de ponta quando solicitado pelos usuários. A capacidade de organizar páginas dinâmicas a partir de fragmentos individuais na ponta da rede significa que somente elementos expirados ou que não podem ser armazenados em cache precisam ser buscados no servidor da Web central. Além disso, a organização das páginas pode ser condicional, baseada em cookies do usuário final ou em cabeçalhos de solicitação de HTTP. Em essência, o ESI evita ter de recuperar páginas completas do servidor central, reduzindo muito a carga que ele deve gerenciar. 1.4.8 Conexões da Ponta à Origem
Vimos anteriormente que os servidores Akamai organizam páginas para o usuário final. Esse processo pode requerer informações do servidor central do site que está sendo hospedado: informações individualizadas, preferências do usuário etc. O servidor Akamai na ponta da rede precisa, assim, estar em contato com o servidor central do site. Fazendo isso, ele deve lidar com toda a gama de questões de conectividade da Internet que
analisamos anteriormente: congestionamento da rede, questões de rede não-hierárquica etc.
1-16
Como a Akamai lida com esse problema? A resposta reside nas Redes de Roteamento de Superposição, ou “Akaroutes", como são chamadas na Akamai. O conceito é simples: uso do conjunto de cerca de 15.000 servidores Akamai geograficamente distribuídos para oferecer vários caminhos alternativos pela interconexão.
Em vez de enviar dados diretamente do servidor de ponta Akamai para o servidor central do site pela Internet, o sistema considera um conjunto com vários caminhos através de vários servidores Akamai e escolhe o mais rápido. Por exemplo, uma maneira de obter o site X do servidor A seria passar pelos servidores C e D, em vez de fazer a conexão diretamente de X para A. De certa forma surpreendente, essa abordagem indireta realmente melhora o desempenho.
A razão disso é que o sistema mantém dados de desempenho do caminho e compara muitos caminhos possíveis para encontrar um ótimo. Ele considera o congestionamento e o tráfego, o que a Internet como um todo não faz. Apesar de os pacotes de um servidor Akamai para o seguinte serem enviados pela Internet e estarem sujeitos a caprichos do BGP, os complexos algoritmos de roteamento da Akamai garantem que são escolhidos os melhores hops possíveis – o que resulta em uma conexão rápida e confiável entre o servidor de ponta e seu servidor central de sites.
Esse método de superposição serve para eliminar o problema de rede não-hierárquica causado pela recusa de uma dada rede em executar o tráfego em seu backbone. Como todas as conexões de encapsulamento são vistas como dados Akamai, e a Akamai possui todos os direitos sobre todas as redes que ela utiliza, essas redes não podem recusar o tráfego.
Por fim, se o servidor central de um site por alguma razão for completamente inatingível, o serviço ACS da Akamai recuperará uma página padrão de dentro do sistema Akamai. Assim, mesmo que o servidor central de um site esteja desativado, os usuários continuarão
recebendo conteúdo no endereço da Web. 1.4.9 Uma Observação sobre Live Streaming
O streaming de conteúdo ao vivo, como vídeo e áudio, apresenta seu próprio conjunto de desafios. Conforme discutido anteriormente, as limitações impostas pela Internet tradicional são tantas que é praticamente impossível conseguir um streaming confiável e de qualidade. Os recursos de roteamento distribuído e otimizado da Akamai servem para aprimorar as condições do live streaming, reduzindo a carga em qualquer servidor e aumentando a qualidade das conexões que transmitem o stream. A Akamai emprega um mecanismo adicional para evitar problemas causados por pacotes perdidos. Uma vez que um stream é codificado e direcionado para a rede Akamai, ele é duplicado imediatamente e dividido em uma série de substreams independentes. Esses substreams são então enviados por vários caminhos para clusters de máquinas localizados que armazenam o stream para a sua área local. Somente uma cópia de cada substream se faz necessária à reconstituição do stream inteiro, mas, como várias cópias de cada substream são enviadas a cada cluster, algumas delas podem se perder ou ser danificadas sem impedir que os clusters locais recebam o stream. Essa estrutura de distribuição de stream, combinada com os mecanismos descritos anteriormente, torna a entrega do stream da Akamai significativamente mais confiável e de mais alta qualidade.
1.5 Desafios Tecnológicos
A construção do sistema Akamai lançou vários desafios tecnológicos aos seus projetistas. Alguns foram vencidos, ao passo que outros permanecem áreas ativas de pesquisa. Agora trataremos desses desafios.
1-17
1.5.1 Implantação e Gerenciamento
Para que a edge delivery funcione, devem ser implantados servidores de ponta em milhares de redes. Além disso, esses servidores devem ser geograficamente distribuídos para desempenho e confiabilidade ótimos. O conteúdo deve fluir totalmente do fornecedor de conteúdo para cada um desses servidores de ponta, e o serviço deve ser capaz de gerenciar o conteúdo à medida que ele atravessa várias redes – isso requer algoritmos complexos, um mapeamento detalhado da topologia da Web e levanta problemas complexos de
rastreamento. 1.5.2 Mapeamento
Quando um usuário solicita uma página da Web do sistema Akamai, o sistema precisa decidir qual servidor utilizará. Isso apresenta várias dificuldades, devido à complexidade da decisão.
• Uma questão é simplesmente a escala: há centenas de milhões de usuários, dezenas de milhares de servidores, milhares de localizações geográficas e milhares de sites da Web hospedados; assim, os algoritmos devem ser executados em um tempo próximo ao linear.
• As condições da Internet devem ser constantemente monitoradas e qualquer alteração deve ser resolvida imediatamente, para manter o desempenho ótimo. O problema é exacerbado porque o congestionamento e as falhas na Internet são espalhados e imprevisíveis.
• O sistema deve equilibrar uma carga de tráfego muito variável e otimizar vários recursos, ao mesmo tempo minimizando o custo.
• O sistema deve ser flexível e capaz de tolerar um grande número de falhas condizentes (no máximo 1.000 servidores desativados de cada vez) e ao mesmo tempo manter um serviço confiável e constante.
• Os algoritmos de controle devem ser distribuídos pela rede e trabalhar com informações imperfeitas.
• As respostas de DNS devem ser dadas em milissegundos. Isso é especialmente importante porque o sistema Akamai introduz um segundo nível de consultas de DNS.
1.5.3 Logging, Relatórios e Bilhetagem
Um outro desafio complexo está relacionado a negócios: o logging, os relatórios e a
bilhetagem dos mais de 10 bilhões de hits por dia que o sistema Akamai recebe. O problema é especialmente complexo porque os dados são distribuídos por mais de 15.000 servidores em 60 países e devem ser recuperáveis em tempo real para uso pelos clientes. Deve existir suporte para os relatórios de dados em tempo real, para o monitoramento de desempenho em tempo real e para as consultas SQL em tempo real. A Akamai mantém um Centro de Controle Operacional da Rede (NOCC) em sua sede para monitorar constantemente o status de todo o sistema. Os mecanismos originais de relatório de falhas eram relativamente simples, mas, com o número crescente de servidores no sistema, precisam ser projetados sistemas de relatórios cada vez mais complexos.
1-18
1.5.4 Operações
Ainda uma outra questão é que o enorme sistema Akamai distribuído deve estar sempre funcionando. Ele não pode sair do ar nem mesmo para manutenção e, na verdade, deve ser capaz de fazer atualizações de software rapidamente. Além disso, o sistema deve ser protegido de ataques mal-intencionados assim como de softwares de terceiros com erros. A dificuldade de se fazer isso é ilustrada pelo exemplo de um roteador malásio que cometeu um erro obscuro no sistema operacional Linux, fazendo com que vários servidores Akamai travassem.
1.5.5 Atualização e Precisão de Conteúdo
A Akamai tem o compromisso de fornecer conteúdo atualizado o tempo todo. Conteúdo desatualizado nunca deve ser divulgado. O sistema deve fornecer um meio de desfazer rapidamente os erros dos clientes e de atualizar o conteúdo.
Por fim, o sistema deve proporcionar flexibilidade e facilidade relativa por parte do cliente sobre o conteúdo. Isso é uma faca de dois gumes, pois, ao mesmo tempo, a Akamai deve proteger-se de erros dos clientes, não permitindo que eles se propaguem pelo sistema. 1.5.6 Gerenciamento do Live Streaming e da Webcast
À medida que a webcast e o live streaming forem se tornando mais importantes, o sistema deverá fornecer opções especializadas para gerenciá-los. Deve haver capacidade de utilização e divulgação de informações para que se possa lidar de forma inteligente com a perda de pacotes. O sistema deve otimizar a velocidade da conexão escolhendo
constantemente o melhor caminho dentre um conjunto de possibilidades. A comunicação deve ser bidirecional, à medida que sessões de mensagens e perguntas e respostas interativas são muitas vezes de interesse do cliente. Agregação de dados e consultas seqüenciais também são necessárias, assim como as entregas de áudio, vídeo e slides corretamente sincronizadas.
1.6 A Internet é um Triunfo da Teoria
Assistimos a uma apresentação do Akamai Forum transmitido por uma Rede Privada Virtual (VPN) em um laptop na sala de aula. Por trás dessa tecnologia há diversos algoritmos importantes. Vale a pena enumerar alguns deles; fazendo isso, percebemos quanto de impacto a pesquisa teórica teve sobre a Web de hoje.
1. Algoritmos de Rede
Ethernet: CSMA (Carrier-Sense Multiple Access) TCP: backoff exponencial
IP: hierarquia de endereços
1-19
Expansão de Árvore Mínima: usada por switches para evitar ciclos em LANs BGP: usado para roteamento na Internet
2. VPN PPTP (Point-to-Point Tunneling Protocol) Hash de Senha e Criptografia: proporciona privacidade Autenticação: confirma a identidade
3. Codificação e Decodificação
Codec: codifica streams de vídeo e áudio
Compressão: reduz o consumo da largura de banda Códigos de Correção de Erros: aumenta a confiabilidade Renderização: exibe o conteúdo na tela
4. Akamai
Seleção do Melhor Servidor: requer otimização complexa
Bilhetagem e Relatórios: requer acesso em tempo real a dados distribuídos Et Cetera
1.7 Problema do Dia – Otimização de Custos
Uma importante questão de pesquisa para a Akamai em termos de lucros é a otimização de custos. A tarefa é conectar cada usuário a um servidor apropriado, ao mesmo tempo minimizando os custos gerais. Cada usuário possui um conjunto de servidores aceitáveis aos quais podem ser direcionados, e cada servidor tem um custo associado a essa utilização.
Tome como exemplo o problema adaptado a seguir: há cerca de um milhão de fontes de carga e milhares de depósitos. Cada origem possui um conjunto de depósitos aceitáveis. Há também um custo por unidade de carga associada a cada depósito. O problema é depositar todas as cargas e, ainda assim, minimizar o custo.
A solução simples é um algoritmo greedy. Para cada origem, escolha o depósito mais barato aceitável. Isso garante que todas as cargas se satisfaçam com um custo total mínimo. No nosso exemplo acima, os depósitos mais baratos para ambas as origens coloridas têm um custo de US$1. Assim, o custo total é
20 * US$1 + 10 * US$1 = US$30.
Mas agora considere uma variante mais complexa do problema. Suponha que haja
economias de escala: o custo do uso de um depósito diminui por unidade de carga. Como a carga aqui na realidade é a largura de banda, essa suposição é mais realista. O algoritmo greedy analisado anteriormente não funciona mais nesse caso, conforme ilustra o exemplo a seguir.
1-20
Figura 1.11. Exemplo Simples 10 unidades 20 unidades US$1/unidade de carga US$1/unidade de carga US$2/unidade de carga Depósitos Fontes de Carga
(~ 1M) US$2/unidade de carga US$5/unidade de carga
Figura 1.12. Falhas do Algoritmo Greedy
Depósitos Fontes de Carga 1 unidade US$1, US$1 US$1,01, US$0 US$1, US$1 1 unidade 1-21
O custo aqui tem duas etapas. O depósito central tem um custo de US$1,01 para a primeira unidade e depois passa a ser gratuito para as unidades seguintes. Os outros depósitos custam US$1 para todas as unidades. Vemos que o algoritmo greedy seleciona os
depósitos, tendo um custo de US$1 para ambas as fontes, como antes. Isso resulta em um custo total de US$2. No entanto, um custo de apenas US$1,01 pode ser conseguido
atribuindo-se ambas as fontes ao depósito central.
Pode-se encontrar um algoritmo ótimo viável para resolver essa minimização de custos? A resposta, infelizmente, é não. Esse problema é NP-hard (NP difícil) e pode ser reduzido a um problema de cobertura do vértice k.
Um esquema conceitual da redução é apresentado a seguir. 1.7.1 O Problema de Cobertura do Vértice
Tome como exemplo o gráfico da Figura 1.13 a seguir. Os vértices marcados B e D na figura têm a propriedade de, juntos, tocarem todas as margens do gráfico. Desses dois vértices, qualquer outro nó no gráfico pode ser alcançado diretamente. Diz-se que esse gráfico tem uma cobertura de 2 vértices. O problema da cobertura do vértice k é de determinação se um dado gráfico possui um conjunto de, no máximo, k vértices de forma que todas as margens do gráfico toquem um vértice no conjunto. Esse problema é conhecido como NP-complete.
Figura 1.13. Exemplo de Gráfico 1.7.2 Resumo sobre a Redução
O problema de minimização de custos pode ser reduzido ao problema de cobertura do vértice k da seguinte maneira. Suponha que tenhamos um algoritmo A que, quando fornecida uma instância do problema de otimização de custo, retorna a solução ótima no tempo polinomial. Mostraremos que, se isso fosse verdade, poderíamos também resolver o problema de cobertura do vértice k, que é NP hard – no tempo polinomial.
Reduzimos o problema de cobertura do vértice k para um gráfico G ao problema de otimização de custos da seguinte maneira:
1. Criar um conjunto de fontes que correspondam a cada margem em G. 2. Criar um conjunto de depósitos que correspondam a cada vértice em G.
1-22
3. Para cada depósito x, adicionar uma margem à fonte y se e somente se o vértice correspondente a x em G tocar a margem correspondente a y em G.2.
4. Definir uma quantidade de carga produzida por cada fonte como 1 unidade.
5. Definir o custo de cada depósito como US$1 para a primeira unidade de carga e daí por diante como US$0.
Chamar esse gráfico de H. H é claramente um exemplo do problema de custo de otimização, conforme descrevemos.
Um exemplo dessa transmissão é diagramado na Figura 1.14, a seguir, para o gráfico de exemplo mostrado anteriormente.
Figura 1.14. Exemplo de Redução
Fontes de Carga (1 unidade)
Depósitos (US$1, US$0, US$0...)
Lembre-se de que o custo de usar um depósito em H é US$1 para a primeira unidade e daí por diante US$0. Assim, o ideal para o local é direcionar toda a carga de uma fonte para um único depósito, sem perda de generalidade. Suponha que uma fonte tenha sua primeira unidade de carga direcionada para o depósito A. Depois, toda a outra carga que vem dessa fonte pode ser direcionada para A com um custo total adicional de 0, preservando uma solução ótima para o local.
Observe que, se H puder ser solucionado com custo de US$k, todas as fontes de H deverão ser atribuídas a exatamente k depósitos. Para ver isso, observe que cada depósito usado custa US$1 – independentemente de quanta carga for atribuída a ele. Portanto, se H puder ser solucionado usando US$k, k depósitos deverão ter sido usados.
Pela definição do problema de otimização de custos, a todas as fontes de carga deve ser atribuído um depósito para formar uma solução. Descobrimos que k depósitos são suficientes para gerenciar toda a carga em H. Assim, esses k depósitos devem ser conectados a cada fonte em H.
2O “conjunto aceitável” de depósitos para uma fonte é representado aqui pelos depósitos conectados a essa fonte pelas margens.
1-23
Lembre-se de que cada depósito em H corresponde a um vértice em G, ao passo que cada fonte corresponde a uma margem. Mas, se k depósitos forem conectados a cada fonte em H, isso significa que k vértices em G são conectados a cada margem em G – o que significa que G possui uma cobertura do vértice k!
Assim, podemos definir um algoritmo B, que, quando fornecida uma instância G do
problema do vértice k, construa o problema de otimização de custos usando as etapas de 1 a 5 acima, aplique A para obter uma solução e verifique se k ou menos depósitos são utilizados. Em caso afirmativo, B sabe que G possui uma cobertura do vértice k. Mas, se A for executado em tempo polinomial, B também o será. Como o problema de cobertura do vértice é NP-hard, não existe (não se conhece) esse algoritmo A. Isso completa a redução3.
3A redução reversa é relativamente óbvia. Se G tem uma cobertura do vértice k, isso significa que há um conjunto de k vértices conectados a cada margem em G. De forma correspondente, isso significa que há um conjunto de k depósitos conectados a cada fonte em H. Como cada depósito custa U$1 para ser usado, independentemente da carga que gerencia, há uma solução para H com custo US$k.
1-24
Bibliografia
[1] Akamai Whitepaper: “Internet Bottlenecks: the Case for Edge Delivery Services". 2000, Cambridge, MA. URL disponível: http://www.akamai.com/en/html/services/ white paper library.html
[2] Janiga, M; Dibner, G. & Governali. F. \Akamai & Internet Infrastructure: Content Delivery. " 2001, Goldman Sachs Equity Research.
[3] Leighton, Tom. Apresentação: “The Challenges of Delivering Content on the Internet". 2002, Cambridge, MA.
1-26
