O que são múltiplos domínios de CDN?

O uso de vários domínios de CDN distribui URLs de recursos entre nomes de host distintos para separação, migração, identidade de marca ou roteamento. Cada nome de host pode usar certificados, políticas de cache ou origens diferentes.

A distribuição de recursos entre nomes de host começou como uma técnica de desempenho chamada fragmentação de domínios. Os navegadores limitam o número de conexões simultâneas por domínio, então servir recursos de vários subdomínios permitia que uma página baixasse mais arquivos em paralelo. HTTP/2 e HTTP/3 transportam muitas solicitações em uma única conexão, o que elimina essa justificativa, e a MDN agora descreve o uso de vários domínios como um antipadrão de desempenho, pois cada um pode acrescentar uma consulta DNS e o estabelecimento de uma conexão. Restam os usos que não têm relação com downloads paralelos: um nome de host por cliente, por limite de segurança, por categoria de mídia ou por CDN durante uma migração. Para um navegador, cada nome de host é uma origem separada e, na CDN, cada um precisa de seu próprio registro DNS, cobertura de certificado e roteamento, mesmo quando todos levam à mesma CDN e ao mesmo servidor de origem.

Nomes de host adicionais ainda aceleram o carregamento de páginas? Em geral, não com HTTP/2 ou HTTP/3. A fragmentação de domínios contornava o limite de conexões por domínio do navegador; a MDN a considera obsoleta quando HTTP/2 está habilitado, pois cada nome de host adicional pode exigir uma consulta DNS e uma nova conexão. Um navegador só pode reutilizar uma conexão existente para um segundo nome de host quando o servidor tem autoridade sobre esse nome. Em HTTP/2, a RFC 9113 condiciona a reutilização à resolução do nome de host para o mesmo endereço IP e, para recursos https, também a um certificado válido para esse nome de host; a RFC 9110 acrescenta que um servidor pode dispensar a verificação de DNS enviando um quadro ORIGIN. Em HTTP/3, o cliente deve validar o certificado do servidor para o novo nome de host. Um servidor pode recusar a reutilização com uma resposta 421 (Misdirected Request).
Um navegador trata um segundo nome de host que possuo como a mesma origem? Não. Uma origem é a combinação de esquema, host e porta, e a RFC 9110 estabelece que duas origens são distintas se diferirem em qualquer um desses três componentes, mesmo quando a mesma entidade controla ambas. Uma página em www.example.com que chama fetch() para acessar media.example.com, ou carrega uma fonte web desse endereço, precisa de cabeçalhos CORS do nome de host de mídia. Uma imagem que é apenas exibida carrega sem autorização por CORS, mas desenhá-la em um canvas torna esse canvas contaminado, e ler os dados do canvas depois disso lança um SecurityError.
Os cookies chegarão a um nome de host de mídia separado? Somente se o escopo deles o abranger, e o escopo por si só não garante a entrega. Um cookie definido com Domain=example.com pode ser enviado para example.com e seus subdomínios, como media.example.com. Um cookie definido sem um atributo Domain é devolvido apenas ao host que o definiu. Nenhum cookie com escopo em example.com é enviado a um nome de host em outro domínio. Dentro desse escopo, a solicitação ainda precisa incluir credenciais: uma chamada fetch() entre origens diferentes não envia cookies, a menos que sua opção credentials esteja definida como include, e a MDN observa que as políticas de cookies de terceiros podem impedir o envio de cookies mesmo assim. Verifique os dois aspectos antes de depender de um controle de acesso baseado em cookies no nome de host de mídia.
O que cada nome de host adicional exige na CDN? Um certificado que o cubra, um registro DNS que o encaminhe e uma configuração que o aceite. O Amazon CloudFront, por exemplo, adiciona um nome de domínio alternativo somente se o certificado associado o cobrir em seus nomes alternativos do titular e rejeita um nome que já exista em outra distribuição. Ele associa um certificado por vez a uma distribuição, então esse certificado precisa cobrir todos os nomes de host da distribuição. O registro de roteamento normalmente é um CNAME, e o CloudFront exige permissão para criá-lo no provedor DNS do domínio. Portanto, para um nome de host pertencente a um cliente, o cliente precisa criar esse registro ou conceder esse acesso a você. O DNS não permite um CNAME na raiz de um domínio (o ápice da zona), então isso funciona para um subdomínio como media.example.net, mas não para o próprio example.net; para o ápice, a documentação do CloudFront indica um registro de alias no Amazon Route 53 ou, com outro provedor DNS, endereços IP estáticos Anycast. Você precisa monitorar e renovar os certificados importados de uma autoridade terceirizada. O AWS Certificate Manager renova os certificados que emite, mas não incondicionalmente: um certificado validado por DNS é renovado automaticamente desde que esteja em uso por um serviço da AWS e seus registros CNAME de validação permaneçam no DNS público; já um certificado validado por e-mail exige uma ação do proprietário do domínio. Para domínios pertencentes a clientes, combine quem manterá esses registros e monitore a expiração de cada nome de host, não apenas do principal.
Um arquivo é armazenado em cache uma única vez ou uma vez por nome de host? Isso depende da chave de cache da CDN. A chave padrão da Cloudflare inclui o host, então o mesmo caminho solicitado por meio de dois nomes de host gera duas entradas de cache. O CloudFront documenta sua chave padrão como o nome de domínio da distribuição mais o caminho da URL e informa que nenhum outro valor da requisição do visitante é incluído por padrão. Isso importa nos dois sentidos. Se todos os nomes de host servem a mesma biblioteca, uma chave que separa os nomes de host armazena duplicatas, e o CloudFront alerta que objetos duplicados reduzem a taxa de acertos e aumentam as requisições ao servidor de origem. Se a resposta varia conforme o nome de host, como quando há um nome de host por locatário, a chave precisa distinguir os nomes de host, pois requisições que produzem a mesma chave recebem o mesmo objeto em cache. A regra do CloudFront é incluir na chave qualquer valor da requisição que determine a resposta do servidor de origem.

Use nomes de host separados para isolar locatários ou classes de ativos, oferecer domínios de entrega com a marca do cliente ou migrar gradualmente entre provedores. Um nome de host separado dá a um locatário sua própria origem no navegador, não suas próprias respostas em cache: o conteúdo específico de cada locatário também precisa de uma chave de cache ou configuração de cache que distinga os nomes de host. Não adicione nomes de host apenas para acelerar o carregamento de páginas em HTTP/2 ou HTTP/3. Cada nome de host adicional traz seu próprio registro DNS, cobertura de certificado, comportamento de CORS, escopo de cookies e configuração de cache.

Dois recursos documentados da Transloadit envolvem o nome de host de entrega. As URLs do Smart CDN são servidas a partir de um nome de host específico do Workspace, [your-workspace].tlcdn.com, então cada Workspace tem seu próprio nome de host de entrega. Quando uma Assembly exporta para seu próprio bucket com o Robot /s3/store, o parâmetro url_prefix define o prefixo da URL retornada no Assembly Status, o que permite distribuir links com um nome de host de CDN que você opera como intermediário de acesso a esse bucket.

url_prefix altera apenas a URL retornada; não altera o bucket nem suas permissões de acesso, e o próprio nome de host precisa ser configurado nos seus provedores de CDN e DNS. As páginas vinculadas aqui não descrevem como servir URLs do Smart CDN a partir de um domínio personalizado.

Explore os recursos de entrega da Transloadit

O que são múltiplos domínios de CDN?

Como funcionam múltiplos domínios de CDN

Informações essenciais

Quando múltiplos domínios de CDN são relevantes

Como a Transloadit ajuda com múltiplos domínios de CDN

Fontes

Transforme conhecimento sobre mídia em um pipeline funcional