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

  1. 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 ETag armazenado (em If-None-Match) ou a data de Last-Modified (em If-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.
  2. 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.
  3. 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-cache ou must-revalidate ou, no caso de um cache compartilhado como uma CDN, proxy-revalidate ou s-maxage. Quando nenhuma dessas diretivas se aplica, a diretiva stale-if-error da 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: com max-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 aplica stale-if-error quando 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.
  4. 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 Vary só 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 continha Authorization, a menos que a resposta permita isso explicitamente. Uma CDN não necessariamente aplica a regra de Vary como está escrita: a Cloudflare documenta que, por padrão, não considera os valores de Vary nas decisões de cache e só os respeita para Vary: Accept-Encoding ou quando uma configuração de Vary foi definida. Portanto, confirme se sua CDN respeita os cabeçalhos indicados em Vary ou 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.
  5. 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.

Explore os recursos de entrega da Transloadit

Fontes

Transforme conhecimento sobre mídia em um pipeline funcional

Conecte uploads, processamento, IA, armazenamento e entrega por meio de uma única API declarativa, com o stack de codificação, o ajuste de escala e as constantes mudanças de formatos gerenciados para você.

Experimente a Transloadit gratuitamente