Benefícios de desempenho

Introdução: causas e mitigações da latência do DNS

À medida que as páginas da Web se tornam mais complexas, fazendo referência a recursos de vários domínios, as pesquisas DNS podem se tornar um gargalo significativo na experiência de navegação. Sempre que um cliente precisa consultar um resolvedor de DNS na rede, a latência introduzida pode ser significativa, dependendo da proximidade e do número de servidores de nomes que o resolvedor tem que consultar (mais de dois é raro, mas pode acontecer). Por exemplo, a captura de tela a seguir mostra os tempos informados pela ferramenta de medição de desempenho da Web Velocidade da página. Cada barra representa um recurso referenciado na página, e os segmentos pretos indicam buscas DNS. Nesta página, são feitas 13 pesquisas nos primeiros 11 segundos em que a página é carregada. Embora várias das pesquisas sejam feitas em paralelo, a captura de tela mostra que são necessários cinco tempos de pesquisa serial, contabilizando vários segundos do total de 11 segundos de carregamento da página.

Há dois componentes na latência do DNS:

  • Latência entre o cliente (usuário) e o servidor de resolução de DNS. Na maioria dos casos, isso se deve em grande parte às restrições normais de tempo de retorno (RTT) em sistemas em rede: distância geográfica entre máquinas clientes e servidores, congestionamento de rede, perda de pacotes e atrasos de retransmissão longa (um segundo em média), servidores sobrecarregados, ataques de negação de serviço e assim por diante.
  • Latência entre a resolução de servidores e outros servidores de nomes. Essa fonte de latência é causada principalmente pelos seguintes fatores:
    • Ausências no cache. Se uma resposta não puder ser exibida a partir do cache de um resolvedor, mas exigir a consulta recursiva de outros servidores de nomes, a latência de rede adicional será considerável, especialmente se os servidores autoritativos forem geograficamente remotos.
    • Subprovisionamento. Se os resolvedores de DNS estiverem sobrecarregados, eles precisarão enfileirar as solicitações e respostas de resolução de DNS e poderão começar a descartar e retransmitir pacotes.
    • Tráfego malicioso. Mesmo que um serviço DNS seja provisionado em excesso, o tráfego de DoS pode colocar uma carga indevida nos servidores. Da mesma forma, os ataques no estilo Kaminsky podem envolver resolvedores de inundação com consultas que têm garantia de ignorar o cache e exigem solicitações de saída para resolução.

Acreditamos que o fator de ausência no cache é a causa mais dominante de latência do DNS. Discutimos esse fator mais adiante.

Ausências no cache

Mesmo que um resolvedor tenha abundantes recursos locais, os atrasos fundamentais associados à comunicação com servidores de nomes remotos são difíceis de evitar. Em outras palavras, supondo que o resolvedor seja provisionado bem o suficiente para que as ocorrências em cache levem zero tempo no lado do servidor, as ausências no cache permanecerão muito caras em termos de latência. Para processar uma ausência, um resolvedor precisa se comunicar com pelo menos um e, geralmente, dois ou mais servidores de nomes externos. Usando o rastreador da Web Googlebot, observamos um tempo médio de resolução de 130 ms para servidores de nomes que respondem. No entanto, cerca de 4 a 6% das solicitações expiram devido à perda de pacotes UDP e os servidores estarem inacessíveis. Se levarmos em conta falhas como perda de pacotes, servidores de nomes inativos, erros de configuração de DNS etc., o tempo médio de resolução real de ponta a ponta é de 300 a 400 ms. No entanto, há alta variação e uma cauda longa.

Embora a taxa de ausência de cache possa variar entre os servidores DNS, elas são fundamentalmente difíceis de evitar pelos seguintes motivos:

  • Tamanho e crescimento da Internet. Simplesmente, à medida que a Internet cresce, tanto com a adição de novos usuários quanto de novos sites, a maior parte do conteúdo é marginalmente relevante. Embora alguns sites (e, consequentemente, nomes DNS) sejam muito conhecidos, a maioria deles interessa apenas a alguns usuários e é acessada raramente. Portanto, a maioria das solicitações resulta em ausências no cache.
  • Valores de time to live (TTL) baixos. A tendência de valores de TTL de DNS mais baixos significa que as resoluções precisam de pesquisas mais frequentes.
  • Isolamento de cache. Normalmente, os servidores DNS são implantados atrás de balanceadores de carga, que atribuem consultas a diferentes máquinas de maneira aleatória. Assim, cada servidor mantém um cache separado, em vez de reutilizar as resoluções armazenadas em um pool compartilhado.

Mitigações

No DNS público do Google, implementamos várias abordagens para acelerar os tempos de busca DNS. Algumas dessas abordagens são bastante padrão, outras são experimentais:

  • Provisionar servidores adequadamente para lidar com a carga do tráfego do cliente, incluindo tráfego malicioso.
  • Evitar ataques DoS e de amplificação. Embora isso seja principalmente um problema de segurança e afete os resolvedores fechados menos do que os abertos, impedir ataques DoS também beneficia o desempenho, eliminando a carga de tráfego extra colocada nos servidores DNS. Para ver informações sobre as abordagens que estamos usando para minimizar a chance de ataques, consulte a página sobre benefícios de segurança.
  • Balanceamento de carga para armazenamento em cache compartilhado: para melhorar a taxa de ocorrência em cache agregada em todo o cluster de exibição.
  • Oferecer cobertura global para proximidade a todos os usuários.

Como provisionar clusters de exibição adequadamente

Os resolvedores de DNS em cache precisam executar operações mais caras do que os servidores de nomes autoritativos, já que muitas respostas não podem ser disponibilizadas pela memória. Em vez disso, eles exigem comunicação com outros servidores de nomes e, portanto, exigem muita entrada/saída da rede. Além disso, os resolvedores abertos são altamente vulneráveis a tentativas de envenenamento do cache, que aumentam a taxa de ausência do cache (como ataques enviam especificamente solicitações de nomes falsos que não podem ser resolvidos pelo cache) e a ataques DoS, que aumentam a carga de tráfego. Se os resolvedores não forem provisionados corretamente e não puderem acompanhar a carga, isso poderá ter um impacto muito negativo no desempenho. Os pacotes são descartados e precisam ser retransmitidos, as solicitações do servidor de nomes precisam ser colocadas em fila, e assim por diante. Todos esses fatores aumentam os atrasos.

Portanto, é importante que os resolvedores de DNS sejam provisionados para entrada/saída de alto volume. Isso inclui lidar com possíveis ataques DDoS, para os quais a única solução eficaz é provisionar em excesso com muitas máquinas. No entanto, ao mesmo tempo, é importante não reduzir a taxa de ocorrência em cache ao adicionar máquinas. Isso exige a implementação de uma política de balanceamento de carga eficaz, que discutimos abaixo.

Balanceamento de carga para armazenamento em cache compartilhado

O escalonamento da infraestrutura do resolvedor com a adição de máquinas pode dar errado e reduzir a taxa de ocorrência em cache se o balanceamento de carga não for feito corretamente. Em uma implantação típica, várias máquinas ficam atrás de um balanceador de carga que distribui igualmente o tráfego para cada máquina, usando um algoritmo simples, como o round-robin. Como resultado, cada máquina mantém o próprio cache independente, para que o conteúdo armazenado em cache seja isolado nas máquinas. Se cada consulta recebida for distribuída para uma máquina aleatória, dependendo da natureza do tráfego, a taxa efetiva de ausências no cache poderá ser aumentada proporcionalmente. Por exemplo, para nomes com TTLs longos que são consultados repetidamente, a taxa de ausência no cache pode ser aumentada pelo número de máquinas no cluster. Para nomes com TTLs muito curtos, que são consultados com pouca frequência ou que resultam em respostas não armazenáveis em cache (0 TTL e erros), a taxa de ausência no cache não é realmente afetada pela adição de máquinas.

Para aumentar a taxa de ocorrências de nomes armazenáveis em cache, é importante balancear a carga dos servidores para que o cache não seja fragmentado. No DNS público do Google, há dois níveis de armazenamento em cache. Em um pool de máquinas, muito próximo do usuário, um pequeno cache por máquina contém os nomes mais conhecidos. Quando uma consulta não pode ser atendida a partir desse cache, ela é enviada para outro pool de máquinas que particionam o cache por nomes. Para esse cache de segundo nível, todas as consultas com o mesmo nome são enviadas para a mesma máquina, onde o nome é armazenado em cache ou não.

Distribuição de clusters de exibição para ampla cobertura geográfica

Para resolvedores fechados, isso não é um problema. Para resolvedores abertos, quanto mais próximos os servidores estiverem localizados dos usuários, menor será a latência que eles encontrarão no lado do cliente. Além disso, ter cobertura geográfica suficiente pode melhorar indiretamente a latência de ponta a ponta, porque os servidores de nomes geralmente retornam resultados otimizados para o local do resolvedor de DNS. Ou seja, se um provedor de conteúdo hospedar sites espelhados em todo o mundo, os servidores de nomes desse provedor retornarão o endereço IP mais próximo do resolvedor de DNS.

O DNS público do Google é hospedado em data centers em todo o mundo e usa roteamento anycast para enviar usuários ao data center geograficamente mais próximo.

Além disso, o DNS público do Google oferece suporte à sub-rede de cliente EDNS (ECS, na sigla em inglês), uma extensão de protocolo DNS para que os resolvedores encaminhem a localização do cliente para os servidores de nomes, que podem retornar respostas sensíveis ao local otimizadas para o endereço IP real do cliente, em vez do endereço IP do resolvedor. Leia estas perguntas frequentes para saber mais detalhes. O DNS público do Google detecta automaticamente servidores de nomes compatíveis com a sub-rede de cliente EDNS.