TLS, DNS, proxy reverso, cache (ETag, Cache-Control), CDN

A ideia que organiza o assunto

Uma requisição web não vai do navegador ao servidor: ela atravessa uma cadeia de intermediários, e cada um deles resolve um problema diferente. Antes de qualquer conexão, é preciso descobrir para onde ir — e isso é o DNS. Depois é preciso abrir um canal em que ninguém leia nem altere o que passa — e isso é o TLS. No caminho há intermediários que falam pelos dois lados — os proxies. E, no fim, a melhor requisição é a que não precisa acontecer — e isso é cache.

Por isso, diante de qualquer item do tópico, a pergunta é sempre a mesma: quem faz isso, e em que ponto da cadeia? A banca quase nunca inventa uma função; ela pega uma função verdadeira e a atribui ao elo errado — dá ao CDN o papel do servidor de aplicação, dá ao TLS uma posição entre camadas que não é a dele, nega ao Apache uma capacidade que ele tem.

Dentro dessa cadeia, uma distinção decide sozinha uma boa parte dos itens: o proxy direto trabalha para o cliente; o proxy reverso trabalha para o servidor. O primeiro fica na saída da organização, guarda o que os usuários acessaram e é ele quem aparece para a Internet — os clientes sabem que ele existe, o servidor de destino não. O segundo fica na frente dos servidores web: o cliente acha que está falando com a aplicação, e é o proxy reverso quem recebe a conexão, encerra o TLS, distribui carga, guarda cache e audita o tráfego. Mesma tecnologia, sentido oposto, e é o sentido que a prova cobra.

Por que se usa (e o que custa)

Cada elo dessa cadeia compra algo e cobra algo, e os custos explicam os itens.

O DNS compra nomes memorizáveis e a liberdade de trocar o endereço IP sem avisar ninguém. Paga com dependência e com cache: enquanto o TTL não expira, o mundo continua indo ao endereço antigo, e um cache envenenado manda o usuário para o servidor do atacante sem que nada, na barra de endereço, mude. Distribuir o serviço em vários servidores com autoridade sobre a mesma zona é o preço que se paga em sincronização para não perder o serviço inteiro quando um deles cai.

O TLS compra confidencialidade, integridade e autenticação do servidor. Paga em custo de estabelecimento — há um aperto de mão com criptografia assimétrica antes do primeiro byte útil — e em cegueira dos intermediários: o conteúdo cifrado não pode ser inspecionado nem armazenado em cache por quem está no meio, a menos que o TLS seja encerrado ali.

O proxy reverso e o cache compram latência e escala: conteúdo servido da borda não consome o servidor de origem nem a travessia da rede. O que se paga é consistência — todo cache corre o risco de entregar conteúdo velho, e é por isso que existe todo o aparato de expiração e validação: max-age, ETag, Last-Modified, revalidação condicional. A pergunta que o protocolo responde não é “guardar ou não”, é “por quanto tempo posso usar sem perguntar, e como pergunto barato quando o prazo acabar”.

Como funciona

DNS. É um banco de dados distribuído e hierárquico que mapeia nomes em endereços IP. A hierarquia vai da raiz aos domínios de topo e destes aos domínios delegados; a delegação é o que permite que ninguém precise conhecer tudo. O resolvedor recursivo pergunta em nome do cliente e guarda a resposta pelo tempo do TTL; os servidores com autoridade sobre a zona são a fonte da verdade, e ter mais de um evita que a falha de um servidor derrube o serviço de nomes do domínio. Registros que caem: A e AAAA (nome para IPv4 e IPv6), CNAME (apelido), MX (correio), NS (delegação), SOA (dados da zona), PTR (a resolução reversa, do IP para o nome, em in-addr.arpa). O serviço usa a porta 53, em UDP para consultas normais e em TCP para respostas grandes e transferência de zona. No cliente também há cache: no Windows, ipconfig /displaydns mostra e ipconfig /flushdns limpa a tabela local que associa nomes visitados a endereços.

Do lado do ataque, o envenenamento de cache DNS insere uma resposta falsa no cache de um resolvedor, e a partir daí todos os clientes que dependem dele são desviados. O DNS também é instrumento de ataques de negação de serviço distribuída: consultas com origem forjada fazem servidores legítimos responderem à vítima, com amplificação — o mesmo protocolo aparece ora como alvo, ora como arma.

TLS. O HTTPS não é um protocolo novo: é HTTP sobre TLS, o antigo SSL, na porta 443. A camada de segurança é inserida entre a camada de aplicação e a de transporte — a aplicação entrega o dado ao TLS, que cifra e passa ao TCP. É por isso que o TLS protege o conteúdo HTTP sem que o HTTP saiba dele e sem alterar o roteamento IP. No estabelecimento da sessão, o servidor apresenta o seu certificado digital, assinado por uma autoridade certificadora em que o cliente confia; o cliente valida a cadeia, e as partes combinam uma chave simétrica de sessão usando criptografia assimétrica. Daí em diante o tráfego é cifrado com a chave simétrica, que é muito mais rápida. O certificado do cliente é opcional e só existe quando se exige autenticação mútua — o caso comum tem certificado de um lado só.

Proxy direto e proxy reverso. O proxy direto intermedia a saída dos clientes: armazena o conteúdo web recuperado recentemente e o compartilha entre todos os clientes da rede, o que reduz banda e acelera o acesso repetido, além de permitir filtragem e registro de navegação. O proxy reverso faz o inverso: apresenta-se como se fosse o servidor. Como todo o tráfego passa por ele, ele faz cache, acelera a exibição das páginas, audita toda a navegação, encerra o TLS, equilibra carga entre servidores de origem e serve de ponto para filtragem de aplicação. Apache e Nginx fazem os dois papéis — não há exclusividade de nenhum deles nessa função.

As diretivas que a prova cobra. No Apache, o proxy vive no mod_proxy: ProxyPass encaminha a requisição para o servidor de origem e ProxyPassReverse faz o caminho de volta, reescrevendo os cabeçalhos da resposta — Location, Content-Location e URI — para que as URLs vistas pelo cliente apontem para o proxy e não para o servidor interno. O mod_cache cuida do cache e é independente: funciona com conteúdo servido localmente ou por proxy. HostNameLookups On faz o servidor resolver por DNS reverso cada conexão de entrada, obtendo o nome do cliente a partir do IP — útil para registro, caro em desempenho, e por isso desativado por padrão. No Nginx, o bloco location escolhe o tratamento pelo prefixo da URL: com root, a requisição é mapeada em arquivo dentro do diretório indicado; com proxy_pass, ela é encaminhada ao endereço e porta de destino — o par clássico é location / com proxy_pass http://localhost:8080 e location /images/ com root /data.

Cache HTTP: expiração e validação. São dois mecanismos encadeados. Enquanto o conteúdo está fresco, o cache responde sozinho: quem define o prazo é o Cache-Control, com max-age em segundos (e s-maxage para caches compartilhados). Vencido o prazo, o cache não descarta o conteúdo — ele revalida: envia uma requisição condicional com If-None-Match, carregando o valor do ETag que recebeu, ou com If-Modified-Since, carregando a data do Last-Modified. Se nada mudou, o servidor responde 304 Not Modified, sem corpo, e o cache reaproveita o que já tinha — a economia está aí. As diretivas que a banca confunde: no-cache não proíbe armazenar, obriga a revalidar antes de usar; quem proíbe armazenar é no-store; private autoriza apenas o cache do navegador, public autoriza também os compartilhados; e must-revalidate proíbe servir conteúdo vencido quando a origem está inacessível. O ETag é um identificador opaco da versão do recurso, mais preciso que a data porque não depende de relógio nem de granularidade de segundo.

CDN. Rede de servidores distribuídos geograficamente que guardam cópias do conteúdo perto do usuário. Ela reduz latência e carga na origem, absorve picos e ajuda a mitigar negação de serviço. O que ela não faz é executar a aplicação: renderização do lado do servidor é papel do servidor de aplicação ou do framework, não da rede de distribuição de conteúdo.

O que decide os itens

Proxy direto × proxy reverso — a distinção de maior rendimento:

	proxy direto	proxy reverso
trabalha para	o cliente	o servidor
fica	na saída da rede do usuário	na frente dos servidores web
quem sabe que ele existe	o cliente (é configurado nele)	ninguém do lado do cliente
usos típicos	cache compartilhado, filtragem, controle de navegação, anonimato do cliente	cache, balanceamento, encerramento de TLS, auditoria, WAF

Quem faz o quê na cadeia:

função	quem
traduzir nome em endereço IP	DNS
traduzir endereço IP em nome	DNS reverso (registro PTR)
cifrar o conteúdo HTTP	TLS, entre aplicação e transporte
guardar cópia perto do usuário	CDN / proxy / cache do navegador
reescrever cabeçalhos da resposta do backend	ProxyPassReverse (Apache)
encaminhar a requisição ao backend	ProxyPass (Apache), proxy_pass (Nginx)
renderizar a página no servidor	servidor de aplicação, nunca o CDN

Cache: diretiva → efeito:

max-age=N	conteúdo fresco por N segundos; nesse prazo o cache responde sem perguntar
s-maxage=N	o mesmo, mas só para caches compartilhados
no-cache	pode armazenar, mas precisa revalidar antes de usar
no-store	não pode armazenar em lugar nenhum
private / public	só cache do navegador / também caches compartilhados
ETag + If-None-Match	validação por versão do recurso
Last-Modified + If-Modified-Since	validação por data de modificação
304 Not Modified	resposta sem corpo: use o que você já tem

Fronteiras que a banca repete: o TLS fica entre aplicação e transporte, nunca entre transporte e rede; no estabelecimento comum só o servidor apresenta certificado, o do cliente é opcional; Apache e Nginx fazem proxy, cache e proxy reverso — nenhum recurso é exclusivo de um deles; mod_cache não depende de mod_proxy; CDN distribui conteúdo, não renderiza aplicação; ter mais de um servidor com autoridade sobre a zona é redundância, não redundância de cache; e envenenamento de cache DNS pode compor um ataque de negação de serviço, além de servir a desvio de tráfego.

Números que caem

DNS	porta 53 (UDP nas consultas, TCP em resposta grande e transferência de zona)
HTTP / HTTPS	portas 80 / 443
posição do TLS	entre a camada de aplicação e a de transporte
resposta de revalidação bem-sucedida	304 Not Modified
resolução reversa	registro PTR, domínio in-addr.arpa
servidores com autoridade por zona	mais de um, para não perder o serviço em falha
Nginx do exemplo clássico	proxy_pass para a porta 8080 do localhost

Como a CEBRASPE derruba você aqui

Medido sobre os 23 itens do assunto: 8 são Errados, e metade deles cai no mesmo rótulo — atribuição errada 4, e generalização, inversão, troca de termo e relação causal com 1 cada. Duas observações antes dos padrões.

O peso do assunto não está onde o título sugere. O título abre com TLS, e TLS aparece em 3 dos 23 itens. Quem domina é o intermediário — proxy direto, proxy reverso e a configuração de Apache e Nginx somam 11 dos 23; DNS vem em 5. E 3 dos 23 itens não são deste assunto: MVC, REST e domain-driven design entraram porque dividiam o enunciado com um item de proxy reverso. Se aparecer um item de camada de modelo ou de statelessness no meio do bloco, não é erro de leitura sua.

6 dos 8 itens errados perguntam a mesma coisa: o que o intermediário faz. Proxy reverso, cache, CDN e módulo de servidor web concentram o erro; os outros dois são de TLS. E dentro desses seis há um formato que se repete mais que qualquer rótulo: o item nega, estreita ou condiciona uma capacidade que existe — 3 dos 8. Essa é a primeira verificação.

Negar ou estreitar uma capacidade real — 3 dos 8. “O Nginx suporta atuar como um proxy de páginas HTTP, capacidade que o Apache não possui”: a primeira metade é verdadeira e serve de isca, a segunda inventa uma exclusividade — o mod_proxy faz isso no Apache desde sempre. “Um proxy reverso não é adequado para ofertar conteúdo estático, mas, sim, dinâmico”: ele serve os dois, e estático com cache é justamente o que ele faz melhor. “O mod_cache […] mas depende da associação com o funcionamento do módulo mod_proxy”: os dois nomes existem, o cenário é plausível e a dependência é inventada — o mod_cache funciona também sobre conteúdo servido localmente. Defesa: as diferenças reais entre Apache e Nginx são de arquitetura e desempenho, não de existência de função; e relação de dependência entre componentes é barata de inventar e difícil de refutar por impressão. Marque “não possui”, “não é adequado” e “depende de” e trate cada um como afirmação a provar.

Dar a um elo a função de outro — 2 dos 8. O CDN que “serve para fornecer renderização do lado do servidor para aplicativos da Web” está descrevendo o servidor de aplicação: CDN guarda e entrega cópia, não executa a aplicação. E o proxy reverso que “busca a melhor forma de interconectar as requisições da porta 80 para Internet” inverte o sentido da cadeia — quem encaminha requisição para a Internet é o proxy direto; o reverso recebe da Internet e entrega aos servidores internos. Defesa: leia a função, decida sozinho de quem ela é, e só então olhe o nome que o item escreveu. Em proxy, a pergunta é sempre de quem ele é procurador.

Deslocar a camada, e generalizar o aperto de mão — 2 dos 8, os dois itens de TLS, e os dois com a frase quase inteira correta. O HTTPS implementado “introduzindo-se uma nova camada no modelo TCP/IP (camada SSL/TLS), posicionada entre as camadas de transporte e de rede”: a camada existe, o nome está certo, o modelo está certo, a posição é a do vizinho — se o TLS estivesse abaixo do TCP, cifraria os cabeçalhos que o roteamento precisa ler. E “o protocolo SSL/TLS funciona por meio da troca de certificados assinados digitalmente entre o computador do usuário e o servidor da aplicação”: transforma em regra o que é exceção, porque no HTTPS comum quem apresenta certificado é só o servidor. Defesa: em item de camada, desenhe a pilha e pergunte quem entrega a quem; em item de handshake, conte quantos certificados a frase exige.

O lado Certo quase nunca restringe. Nenhum dos 15 itens Certos limita por conta própria o que um componente pode fazer: eles descrevem ou autorizam — “pode ser usado para o compartilhamento desse conteúdo entre todos os clientes”, “permite que se faça cache de dados e acelere a exibição de páginas”, “tem a vantagem de evitar a perda do serviço”. As duas negações que aparecem em itens Certos pertencem à definição, não ao elaborador: o proxy reverso que “normalmente não gera ou hospeda os dados” e o REST em que o servidor “não mantém contexto de cliente”. Quando a restrição é do elaborador, ela é o erro; quando é da definição, é o gabarito.

O que ainda não foi medido. Nenhum item deste corpus cobrou cabeçalho de cache HTTP: Cache-Control, max-age, no-cache × no-store, ETag, Last-Modified e o 304 aparecem zero vezes em 23 itens, assim como a porta 53, a porta 443 e o TTL do DNS. O bloco continua na nota porque é o conteúdo canônico do tema e a banca o cobra em outros assuntos de HTTP — mas, neste recorte, é estudo de reserva. O que rende aqui é a cadeia de intermediários.

Erros clássicos

Achar que proxy reverso e proxy direto são o mesmo com nomes diferentes. Pergunte de quem o intermediário é procurador: se ele representa o cliente diante da Internet, é direto; se representa o servidor diante do cliente, é reverso. Cache, filtragem e registro existem nos dois — o que muda é o lado.

Confundir no-cache com no-store. no-cache permite guardar e obriga a perguntar antes de usar; no-store proíbe guardar. Item que trate no-cache como proibição de armazenamento está errado.

Achar que o 304 devolve o recurso. A resposta 304 é justamente a que não traz corpo: ela autoriza o cache a reutilizar a cópia que já tem. É daí que vem a economia da revalidação condicional.

Tratar ETag como data. ETag é identificador de versão, comparado com If-None-Match; a data é o Last-Modified, comparado com If-Modified-Since. Trocar os pares é a confusão mais comum do bloco de cache.

Supor que o TLS impede o cache. Não impede: impede que intermediários que não encerram o TLS vejam o conteúdo. O navegador guarda normalmente, e o proxy reverso que encerra a sessão também.

Esquecer que o DNS é hierárquico e distribuído. Não existe servidor único que saiba tudo, e é por isso que há delegação, TTL, cache em cada nível e mais de um servidor com autoridade por zona. Quase todo item de DNS se decide lembrando disso.