Introdução e soluçoes de cache
O armazenamento de registro é conhecido como o cache de DNS, e o ato de armazenar registros é chamado de cache
Há muitos lugares diferentes onde os caches de DNS existem:
- no seu computador, local
- no seu provedor de acesso a internet
- e até mesmo nos servidores raiz centrais de DNS(Domain Name System)
Esses caches reduzem o número de consultas que precisam de ser resolvidas pelo servidor de nomes.
Às vezes mudamos as informações de DNS, mas a informação antiga é ainda armazenada no cache de DNS em vários níveis. Quando o registro em cache é diferente da mais recente informação no DNS, ele é chamado um erro de cache.
Como faço para corrigir um erro de cache?
Dependendo do seu sistema operacional, existem métodos diferentes de limpar o cache DNS local. Remover todas as suas informações armazenadas DNS é conhecido como limpeza de cache.
Por favor, veja a lista abaixo para obter instruções sobre como limpar seu cache de DNS na maioria dos sistemas operacionais comuns. (Antes de liberar o cache DNS, limpar arquivos temporários do seu navegador e feche todas as janelas do navegador.)
Windows
No Windows 98/2000/ME/XP/(VISTA e 7 aparentemente tambem funciona assim), abra um prompt de comando e digite o seguinte para limpar o Windows DNS Resolver:
ipconfig / flushdns
Unix
Na maioria dos sistemas * nix operacional (Unix, Linux, FreeBSD, etc), digite o seguinte para reiniciar o daemon nscd:
/ Etc / rc.d / init.d / nscd reiniciar
Mac OSX
No Mac OS X, abra um prompt de comando e digite o seguinte para limpar o cache DNS Resolver:
flushcache-dscacheutil
Em versões mais antigas, o comando é:
flushcache-lookupd
Alguns registros são armazenados pelo seu provedor acesso a internet, que são servidores que fazem o “trabalho braçal” das pesquisas em nome dos assinantes. Se um erro de cache ocorre a este nível, limpar o cache local não vai resolver o problema.
Se vc ja limpou a sua cache local, e continua a receber os registros velhos e incorretos, você terá que esperar para os registros expirarem naturalmente.
Valores Comuns TTL (tempo de vida)
O valor padrão ou recomendado para os tipos de registros DNS em nosso Dynamic DNS e serviços personalizados de DNS são:
Tipo TTL Value (segundos)
A (Host), Super Dynamic 20 (20 segundos)
A (Host), Dynamic 60 (1 minuto)
A (Host), Pseudo-Static 600 (10 minutos)
A (Host), Static 14.400 (quatro horas)
A (Host), Static 21.600 (seis horas)
AAAA (IPv6), * Dynamic Super 20
AAAA (IPv6), * Dynamic 60
AAAA (IPv6), * Pseudo-Static 600
AAAA (IPv6), * Static 14400
AAAA (IPv6), * Static 21600
CNAME 43.200 (12 horas)
LOC * 86400 (24 horas)
MX * 43200
NS * 86400
PTR * 86400
SRV * 86400
TXT * 43200
* Tipo de registro indicado apenas disponível na interface personalizada Expert DNS
Se vc administra sites, na interface avançada de DNS do seu site (cpanel, por exemplo), você pode modificar o valor TTL para qualquer tipo de registro.
Se você alterar o TTLs padrão, valores inferiores a 20 não têm nenhum impacto notável no tempo de propagação, e TTL valores superiores a 86.400 (24 horas) são igualmente desnecessário e pode levar a problemas se o registro precisa ser mudado.
Problemas de Caching
Quando um cliente tenta acessar um domínio antes que ele exista, uma informacao de registro “não existe” será salva. O TTL para esses registros varia de servidor para servidor, mas o TTL média é de cerca de 2 horas. Durante este período, a resolução de nomes de domínio não sera possível.
Por que alguns registros vem com TTLs altos?
Como discutido anteriormente, os valores TTL dos registros existem para aliviar a carga de consultas de servidores de nomes. Muitos registros, como registros de MX ou CNAME, espera-se que sejam mudados muito raramente, de modo que normalmente são dadas TTL mais altas para impedir a desnecessárias pesquisas extras. Para outros records, tais como hospedeiros para endereços IP dinâmicos, são dadas TTLs mais baixas, porque se espera que mudem mais frequentemente.
Introdução ²
O que são web caches? “Um web cache é um serviço encontrado entre um servidor web, e um ou mais clientes HTTP. Esse serviço tem por responsabilidade analisar (e na maioria das vezes, fazer uma cópia) das requisições HTTP (páginas HTML, imagens e outros arquivos inclusos).” “Sempre que houver uma outra requisição para a mesma URL, a cópia dos objetos da requisição original pode ser reutilizada, ao invés destes serem solicitados ao servidor web novamente.”
Introdução: Objetivos de uso Há basicamente dois tipos de uso para um web cache: redução de latência: Quando uma requisição é atendida por um cache (que está mais próximo ao cliente) ao invés do servidor HTTP de origem, esta costuma levar menos tempo para ser atendida. Isto faz com que a “web” tenha uma maior sensação de velocidade. redução de tráfego de rede: ao se reutilizar os objetos de uma requisição HTTP, isto reduz a utilização de banda pelo cliente, fazendo com que os custos com uso de banda sejam menores.
Introdução: Tipos de web caches Browser caches: É o cache feito localmente (em disco local), pelo proprio browser. Tem o objetivo de melhorar a sensação de velocidade do browser. Proxy caches: Utilizam o mesmo principio do browser cache, porém, em uma escala muito maior. Utilizam servidores externos para armazenar os objetos em cache. Surrogate caches (ou caches reversos): São caches configurados junto aos servidores web, com objetivo de deixar os sites com uma melhor performance, mais escaláveis e confiáveis.
Proxy Servers - Funcionamento Um ou mais clientes fazem requisições HTTP a partir de uma mesma rede. Sem o uso de uma estrutura de cache, requisições de clientes distintos para um mesmo servidor web são duplicadas. A implementação de um proxy server tem por objetivo consolidar um cache de requisições HTTP entre clientes distintos. Uso clássico: Configura-se um servidor qualquer, com o software “squid” configurado como um proxy server. Todos clientes que tiverem seus web browsers (IE, firefox, outros) configurados para acessar esse proxy, compartilharão o cache “consolidado” no squid.
Proxy Servers – Exemplo de uso
Hierarquias de cache – Como funcionam? O funcionamento de um proxy cache é relativamente simples. Recebe requisições de um cliente HTTP, que verifica se já possui o objeto solicitado em seu cache local. O uso de hierarquias permite que essa funcionalidade seja expandida para vários servidores ao mesmo tempo. Basicamente falando, o uso de hierarquias permite que o cache de um proxy server seja utilizado por outros servidores. Essa comunicação entre servidores costuma utilizar o protocolo ICP (Internet Cache Protocol). Também pode ser utilizado o protocolo HTCP (Hyper Text Caching Protocol).
Hierarquias de cache - sibling
Hierarquias de cache - parent
Caches transparentes - Objetivos Tem por objetivo básico servir como um proxy que atue de forma “transparente” para o usuário. Essa transparência engloba dois itens: não há a necessidade de configurar o browser do usuário para utilizar o cache; o browser do usuário não toma conhecimento da existência do cache. É implementado obrigatóriamente no “caminho” que a requisição HTTP percorre (em um roteador ou firewall). Pode ser um linux ou freebsd (usando iptables, tproxy e outros), ou utilizar o protocolo wccp (Web Cache Communication Protocol) em roteadores ou firewalls que suportem esse protocolo.
Caches transparentes – Prós e contras – Vantagens: • Administração simplificada (não há a necessidade de se configurar o browser do usuário) Controle centralizado (o administrador define se o usuário pode ou não utilizar o cache) – Desvantagens: • Falta de robustez (conexões persistentes podem ser “perdidas”, quando uma rota internet é modificada) • Falta de controle do usuário (forçado a usar um cache) • Dependência dos browsers (precisam implementar o protocolo HTTP corretamente)
Caches transparentes - Exemplos
Web Accelerators - Objetivos Web Accelerators (também chamado de reverse proxies, ou surrogate proxies), apesar de funcionarem de forma semelhante a caches normais, possuem uma característica específica: trabalham no lado oposto da requisição HTTP. Essa configuração de caches tem por objetivos: • reduzir a carga nos servidores WWW, fazendo cache de requisições “pesadas” (e cacheáveis) • aumentar a escalabilidade dos servidores WWW (sem aumentar a complexidade do serviço) • Distribuir o conteúdo de forma global, em caches locais (CDN, content delivery networks)
REQUERIMENTOS DO JOGO
Responder com Citação