O que são servidores de origem?
Servidores de origem armazenam ou geram a versão autoritativa do conteúdo. Caches e redes de distribuição de conteúdo obtêm esse conteúdo do servidor de origem quando não conseguem atender a uma requisição localmente.
Como funcionam os servidores de origem
O HTTP define um servidor de origem como um programa capaz de gerar respostas autoritativas para um determinado recurso de destino. Em uma arquitetura de entrega, ele é o componente a montante que uma CDN ou um proxy reverso contata quando não tem uma resposta armazenada que possa reutilizar: um armazenamento de objetos, um servidor web, um empacotador que monta manifestos ou um serviço que gera derivados sob demanda. Para o cliente, a própria CDN parece ser o servidor de origem; o HTTP chama esse intermediário de gateway ou proxy reverso. Prazos de validade, validadores, chaves de cache e suporte a intervalos determinam quantas requisições chegam ao servidor de origem, e um objeto muito solicitado que expira ou que nunca foi armazenado em cache pode concentrar essas requisições nele. O termo não tem relação com uma origem web, a combinação de esquema, host e porta que os navegadores usam para a política de mesma origem e o CORS.
Informações essenciais
- Todo objeto expirado precisa ser baixado novamente da origem? Não, se a origem enviar validadores. Um cache que mantém uma resposta desatualizada pode fazer uma requisição condicional usando o
ETagarmazenado (emIf-None-Match) ou a data deLast-Modified(emIf-Modified-Since), e uma origem cujo conteúdo não mudou responde com 304 (Not Modified) sem enviar a representação novamente. A origem ainda precisa receber e responder a cada requisição de validação encaminhada a ela, portanto os validadores reduzem os bytes transferidos, mas não reduzem, por si só, o número de requisições. - Como evito que vários pontos de presença de borda busquem o mesmo objeto individualmente? Encaminhe as requisições que não encontram o objeto no cache por uma camada de cache compartilhada à frente da origem. Sem ela, cada ponto de cache que não encontra o objeto pode enviar sua própria requisição para o mesmo conteúdo. O Amazon CloudFront Origin Shield, a proteção da origem da Fastly e o Cloudflare Smart Tiered Cache concentram essas requisições em uma camada superior designada; já a topologia Generic Global da Cloudflare seleciona camadas superiores de conjuntos regionais. O CloudFront e a Fastly também agrupam requisições simultâneas para o mesmo objeto ausente do cache, podendo reduzi-las a uma única requisição à origem. A Fastly aponta uma limitação: se a resposta não puder ser armazenada em cache, por exemplo, por ser privada de um usuário, cada requisição em espera deverá então ser enviada à origem de forma independente. A AWS afirma que o Origin Shield pode não ser adequado para conteúdo dinâmico encaminhado por proxy à origem, conteúdo com baixa capacidade de armazenamento em cache ou conteúdo solicitado com pouca frequência, e que ele é cobrado separadamente.
- O que os usuários recebem enquanto a origem está indisponível? As respostas que ainda estão válidas em um cache continuam sendo servidas. Para as desatualizadas, a regra do HTTP é que um cache não pode servi-las, a menos que esteja desconectado ou tenha recebido permissão explícita para isso, e não pode servi-las em hipótese alguma quando a resposta contém
no-cacheoumust-revalidateou, no caso de um cache compartilhado como uma CDN,proxy-revalidateous-maxage. Quando nenhuma dessas diretivas se aplica, a diretivastale-if-errorda RFC 5861 concede essa permissão quando a origem retorna 500, 502, 503 ou 504, ou não pode ser alcançada. Seu valor limita o tempo de desatualização permitido para a resposta, contado a partir do momento em que ela expirou, e não do início da indisponibilidade: commax-age=600, stale-if-error=1200, a resposta pode ser usada em caso de erro até atingir a idade total de 1800 segundos. Para cobrir uma manutenção planejada, o valor precisa abranger o tempo desde a expiração mais o período de indisponibilidade. O comportamento das CDNs varia nos detalhes: o CloudFront documenta que aplicastale-if-errorquando a origem está inacessível ou retorna um status 5xx, até o limite do valor da diretiva ou de seu TTL máximo, o que for menor, e que, mesmo sem a diretiva, continua servindo um objeto expirado que mantém em cache quando a origem retorna um status 5xx. Nenhuma configuração ajuda no caso de um objeto que nunca foi armazenado em cache ou já não está no cache, e o CloudFront informa que pode remover do cache um objeto pouco solicitado enquanto a origem ainda apresenta falhas. - Uma origem funcionando corretamente ainda pode entregar a variante errada por meio de uma CDN? Sim, quando a resposta depende de algo que o cache não inclui na chave. O HTTP estabelece duas regras: uma resposta armazenada com um cabeçalho
Varysó pode ser reutilizada para requisições cujos campos de cabeçalho indicados coincidam, e um cache compartilhado não pode reutilizar a resposta a uma requisição que continhaAuthorization, a menos que a resposta permita isso explicitamente. Uma CDN não necessariamente aplica a regra deVarycomo está escrita: a Cloudflare documenta que, por padrão, não considera os valores deVarynas decisões de cache e só os respeita paraVary: Accept-Encodingou quando uma configuração de Vary foi definida. Portanto, confirme se sua CDN respeita os cabeçalhos indicados emVaryou adicione-os à chave de cache por conta própria. O mesmo vale para qualquer outra entrada que altere a resposta, como um cookie ou um parâmetro de consulta que a CDN esteja configurada para ignorar: adicione essa entrada à chave de cache ou marque a resposta como não armazenável em cache. - Os clientes podem ignorar a CDN e fazer requisições diretamente à origem? Podem, se a origem estiver acessível publicamente e seu endereço se tornar conhecido, contornando o cache e as proteções da CDN. A orientação da Cloudflare lista as opções: permitir acesso apenas a partir das faixas de IP da CDN (opção que ela classifica como moderadamente segura e vulnerável à falsificação de IP), exigir um cabeçalho secreto na requisição, autenticar a CDN com um certificado de cliente TLS (Authenticated Origin Pulls) ou conectar por meio de um túnel que permite apenas conexões de saída, de modo que a origem não tenha um endereço publicamente roteável. Para origens no Amazon S3, a AWS lista três tarefas: criar um controle de acesso à origem do CloudFront, que assina as requisições do CloudFront ao bucket, e associá-lo à distribuição; conceder a ele permissão para ler os arquivos, o que a documentação faz com uma política de bucket restrita àquela distribuição; e remover a permissão de leitura dos arquivos por URLs do Amazon S3 para todos os demais. A assinatura, por si só, mantém acessível um bucket com leitura pública.
Quando os servidores de origem são importantes
Configure uma origem para expor apenas os recursos e as operações exigidos pela CDN. A lentidão ou as interrupções na origem atrasam as respostas a solicitações sem resultado em cache, as revalidações e a entrega de conteúdo que não pode ser armazenado em cache, pois os caches de borda não conseguem responder a essas solicitações localmente. Objetos cujo prazo de validade no cache de borda ainda não expirou podem continuar sendo servidos.
Como a Transloadit ajuda com servidores de origem
Com o Smart CDN da Transloadit, há duas camadas a montante. Seus arquivos originais ficam no seu próprio armazenamento, como um bucket do Amazon S3, e um Template os importa de lá. Quando a CDN não tem uma cópia em cache para a URL solicitada, a Transloadit executa o Template e o Robot /file/serve entrega o resultado à CDN, de modo que a execução do Template serve de origem para tlcdn.com e seu bucket é a fonte por trás dela. /file/serve define o cabeçalho Cache-Control nessa resposta; seu parâmetro cache_duration define tanto max-age quanto s-maxage, o que determina com que frequência as solicitações voltam ao Template e ao seu armazenamento.
A documentação de /file/serve desaconselha seu uso sem uma CDN à frente, pois cada solicitação sem resultado em cache executaria a transformação novamente. As páginas vinculadas aqui não descrevem o que é servido quando seu armazenamento está inacessível e não há resultado em cache, nem se um resultado expirado ainda pode ser servido.
Fontes
- RFC 9110: semântica do HTTP (servidor de origem, seção 3.6; intermediários, seção 3.7; 304 Not Modified, seção 15.4.5)
- RFC 9111: cache HTTP (Vary, requisições autenticadas, respostas desatualizadas, validação)
- RFC 5861: extensões de Cache-Control do HTTP para conteúdo desatualizado
- Amazon CloudFront: Origin Shield
- Fastly: proteção da origem
- Fastly: agrupamento de requisições
- Cloudflare: Tiered Cache
- Amazon CloudFront: como os códigos de status HTTP 4xx e 5xx da origem são processados
- Amazon CloudFront: expiração do cache e entrega de conteúdo desatualizado
- Cloudflare: Origin Cache Control (como Vary é tratado por padrão)
- Amazon CloudFront: entender a chave de cache
- Cloudflare: proteger seu servidor de origem
- Cloudflare: Authenticated Origin Pulls (mTLS)
- Amazon CloudFront: restringir o acesso a uma origem no Amazon S3
- Amazon CloudFront: restringir o acesso a arquivos (as três tarefas para um bucket do Amazon S3)