O Media CDN oferece suporte a protocolos de rede modernos do cliente até a borda, aumentando a capacidade e reduzindo a latência geral da rede.
Endereços IP
Cada serviço de armazenamento em cache de borda que você configura tem endereços IPv4 e IPv6 Anycast dedicados, que são associados a cada serviço de armazenamento em cache de borda que você cria e não são compartilhados com outros clientes.
- Depois de configurar um serviço de armazenamento em cache de borda, os endereços IP são atribuídos e disponibilizados.
- Os endereços atribuídos não mudam durante a vida útil de um determinado serviço de armazenamento em cache de borda.
- A criação de um novo serviço de armazenamento em cache de borda emite novos endereços IP com escopo para esse serviço. Os endereços IP não são compartilhados entre seus serviços.
Todos os serviços do Media CDN oferecem suporte a IPv6 entre clientes e cada nó de borda.
Recuperar endereços IP
Para recuperar os endereços IP atribuídos a um serviço de armazenamento em cache próximo dos usuários finais:
gcloud
Use o comando gcloud edge-cache services
.
gcloud edge-cache services describe MY_SERVICE
... ipv4Addresses: ["35.1.1.1"] ipv6Addresses: ["2600:1901:0:fa74::"] ...
Observações:
- O Media CDN emite um endereço IPv4 e um IPv6 por serviço.
- Recomendamos a criação de registros DNS para os dois endereços IP (como registros A e AAAA).
- Configure seus serviços para aceitar o tráfego de qualquer nome de domínio (nome do host) que você esteja usando. Quando o tráfego é recebido para hosts sem
uma entrada
.routing.hostRules[].hosts
, o Media CDN o rejeita com um erro HTTP 404.
Dependendo das regiões geográficas em que os usuários estão, pode haver mais tráfego para um protocolo do que para outro, com base nos dispositivos dos usuários e no suporte a ISPs nessas regiões.
Tempos limite do cliente
Os tempos limite a seguir se aplicam a conexões de clientes:
Tempo limite | Duração máxima | Código de resposta | Descrição |
---|---|---|---|
Maximum request duration | 5 minutos | HTTP 408 (Request Timeout) | A duração máxima de uma única solicitação-resposta. |
Header timeout | 10 segundos | HTTP 408 (Request Timeout) | Quanto tempo o cliente tem para enviar o conjunto completo de cabeçalhos da solicitação. |
Para tempo limite e configuração da origem, consulte a seção failover e tempos limite da documentação da origem.
Limites de solicitações do cliente
Para detalhes sobre os limites de solicitação e resposta do cliente, consulte a documentação sobre cotas e limites.
Suporte a protocolos de rede
O Media CDN é compatível com conexões HTTP/3, HTTP/2 e HTTP/1.1 de
clientes. O Media CDN é compatível com Negociação do protocolo de camada de aplicativo (ALPN, na sigla em inglês)
e com o cabeçalho de resposta HTTP Alt-Svc
(serviço alternativo) para suporte a protocolos
de publicidade.
Protocolo | Compatível | SSL (TLS) obrigatório |
---|---|---|
HTTP/3 (IETF QUIC) | Sim | Sim |
HTTP/2 | Sim | Sim |
HTTPS (HTTP/1.1 sobre TLS) | Sim | Sim |
HTTP/1.1 | Sim | No |
Observações:
- O HTTP/2 (h2) é aceito por padrão.
- Para ativar o HTTP/3 (QUIC), entre em contato diretamente com sua equipe de conta.
- HTTPS, HTTP/2 e HTTP/3 exigem que um certificado SSL (TLS) válido seja anexado ao serviço.
- Clientes sem suporte a HTTP/2 ou versões posteriores se conectam automaticamente por HTTP/1.1
Para suporte ao protocolo de origem, consulte origens e protocolos compatíveis.
Versões de SSL (TLS) compatíveis
Para versões compatíveis de SSL (TLS), consulte a documentação do SSL.
Resolver problemas de conectividade do cliente
- O protocolo HTTP/2 (h2) tem suporte apenas para clientes que se conectam por TLS. Esse protocolo não oferece suporte a conexões de texto simples.
- Os clientes só negociam as conexões compatíveis. Novos protocolos são projetados como ativações para oferecer compatibilidade com versões anteriores.
- Se você tem clientes que têm endereços IPv6, mas se conectam aos serviços do Media CDN por IPv4, talvez seja porque a rede entre um local de borda do Media CDN e seu usuário oferece suporte apenas a IPv4.
- Somente HTTP/1.1 e versões posteriores são compatíveis como protocolos de cliente. As solicitações HTTP/0.9 e HTTP/1.0 são rejeitadas com um erro HTTP 426 (upgrade necessário).