O que é um servidor de borda?

Um servidor de borda atende a solicitações perto dos usuários finais, em vez de atendê-las apenas em uma origem central. Ele pode armazenar conteúdo em cache ou realizar roteamento, transformação, autenticação e computação em um ponto distribuído da rede.

Em termos de HTTP, um servidor de borda é um proxy reverso, que a RFC 9110 chama de gateway: para o cliente, ele atua como servidor de origem e encaminha a outro servidor as solicitações que não consegue atender por conta própria. Os operadores de CDN mantêm muitos desses servidores, agrupados em localidades que a Fastly chama de pontos de presença (POPs) e a Cloudflare chama de data centers. Um cliente chega a uma dessas localidades porque o DNS retorna um endereço escolhido para ele ou porque o mesmo endereço anycast é anunciado em todas as localidades e o roteamento da rede seleciona uma delas. O servidor de borda então responde a partir do cache, executa a lógica configurada para as solicitações ou encaminha a solicitação em direção à origem. Uma resposta armazenada no cache de uma localidade não é automaticamente armazenada nas demais. Quando há uma ausência no cache, o próximo destino da solicitação depende da CDN e de sua configuração: diretamente a origem ou, primeiro, um cache de camada superior, como um POP de proteção da Fastly, uma camada superior do Tiered Cache da Cloudflare ou um cache regional de borda do Amazon CloudFront.

O servidor de borda mais próximo sempre atende à solicitação? Não. Com anycast, o sistema de roteamento escolhe a localidade com base na topologia da rede, e a RFC 4786 observa que a proximidade topológica não tem, em geral, correlação com o desempenho no percurso de ida e volta. Na seleção baseada em DNS, o servidor DNS autoritativo da CDN vê o endereço do resolvedor recursivo (o servidor DNS que consulta nomes em nome do usuário), em vez do endereço do próprio usuário, a menos que o resolvedor encaminhe uma sub-rede do cliente, que é uma forma truncada do endereço do usuário. Assim, alguém que usa um resolvedor distante pode ser direcionado a uma localidade próxima do resolvedor.
Uma resposta armazenada no cache de uma localidade de borda fica disponível em todas elas? Não automaticamente: uma localidade que não armazenou a resposta tem uma ausência no cache, e o próximo destino da solicitação depende da CDN e de sua configuração. Os POPs da Fastly encaminham solicitações à origem de forma independente, a menos que a proteção de origem as faça passar por um único POP de proteção. Já o Tiered Cache da Cloudflare faz um data center de camada inferior consultar uma camada superior antes de consultar a origem. O Amazon CloudFront tem uma camada desse tipo por padrão: um POP com uma ausência no cache normalmente consulta um cache regional de borda, que já pode conter o objeto. Nenhuma dessas camadas garante o que chega à origem. A Cloudflare aplica o Tiered Cache apenas a solicitações elegíveis para armazenamento em cache, o CloudFront envia solicitações dinâmicas e métodos como POST do POP diretamente à origem, e a Fastly recomenda que o código do Compute recorra à origem quando o POP de proteção estiver indisponível.
Que código pode ser executado em um servidor de borda? Isso depende do produto e da etapa da solicitação à qual o código está associado, então confira essas condições antes de basear seu projeto nessa capacidade. O Amazon CloudFront documenta duas opções: CloudFront Functions para operações leves, como normalização de chaves de cache, alterações de cabeçalhos, redirecionamentos e validação de tokens, sem acesso à rede nem ao corpo da solicitação; e Lambda@Edge para funções que precisam de acesso à rede, bibliotecas de terceiros ou do corpo da solicitação. A organização em camadas também pode mudar a frequência de execução do código: com a proteção de origem da Fastly, o código de borda normalmente é executado duas vezes, uma no primeiro POP e outra no POP de proteção. Por isso, a lógica que reescreve uma solicitação ou adiciona um cabeçalho precisa poder ser executada duas vezes com segurança.
Validar uma URL assinada na borda protege a origem? Apenas para requisições que passam pela borda. O CloudFront documenta dois controles separados: URLs assinadas ou cookies assinados restringem o acesso a arquivos nos caches de borda, enquanto a origem precisa ser protegida separadamente para que os clientes não possam contornar a CDN e buscar arquivos diretamente nela. Para uma origem S3, isso significa conceder a um controle de acesso à origem permissão para ler o bucket e remover a permissão de todos os demais para ler os arquivos por meio de URLs do S3. Para uma origem personalizada, significa usar um cabeçalho personalizado que o CloudFront adiciona às requisições à origem e que a origem exige, com HTTPS tanto na conexão do cliente quanto na conexão com a origem, para que o cabeçalho seja criptografado em trânsito. A orientação da AWS para origens com balanceadores de carga acrescenta que isso funciona apenas enquanto o nome e o valor do cabeçalho permanecerem secretos e recomenda fazer a rotação de ambos. Separadamente, se os clientes se autenticarem com um cabeçalho Authorization em vez de uma URL assinada, a RFC 9111 proíbe que um cache compartilhado reutilize a resposta para uma requisição posterior, a menos que a resposta permita isso com public, s-maxage ou must-revalidate.

Os servidores de borda são mais importantes quando muitos clientes distantes da origem solicitam a mesma resposta: um acerto de cache é respondido na localidade de borda e nunca chega à origem. Uma requisição que a borda não consegue responder com uma resposta armazenada é processada quando chega, seja pela origem, caso em que a requisição ainda segue até ela, seja pela lógica de borda que gera a própria resposta. Nesse caso, a borda contribui com roteamento, filtragem ou lógica de requisições, em vez de uma cópia armazenada. Ao projetar uma solução que use um servidor de borda, planeje o fluxo em caso de ausência de um resultado no cache, considere que os caches são preenchidos separadamente em cada localidade e preveja requisições que chegam à origem sem passar pela borda.

O Smart CDN da Transloadit coloca o cache de borda à frente do processamento sob demanda. Uma requisição a uma URL tlcdn.com é respondida pela borda quando existe uma cópia em cache. Na ausência de um resultado no cache, a requisição executa seu Template como uma Assembly, o Robot /file/serve seleciona o resultado a ser retornado e define seu cabeçalho Cache-Control, e /tlcdn/deliver armazena esse resultado em cache e o entrega perto dos seus usuários.

As páginas vinculadas descrevem o armazenamento em cache e a entrega na borda, além do processamento em uma Assembly. Elas não documentam um ambiente de execução para executar seu próprio código na borda. Uma URL do Smart CDN pode incluir opcionalmente um horário de expiração e uma assinatura; se a URL ou seus parâmetros forem alterados depois, a assinatura deixa de corresponder. Isso impede que terceiros alterem a URL apenas quando requisições sem assinatura são recusadas, e as páginas vinculadas também não dizem como uma requisição sem assinatura ao mesmo Template é tratada, portanto teste esse comportamento no seu próprio Workspace antes de depender dele. A Transloadit descreve o Smart CDN como uma camada de transformação e entrega que não substitui a política de autorização da sua aplicação.

Explore os recursos de entrega da Transloadit

O que é um servidor de borda?

Como funcionam os servidores de borda

Informações essenciais

Quando os servidores de borda são importantes

Como a Transloadit ajuda com servidores de borda

Fontes

Transforme conhecimento sobre mídia em um pipeline funcional