A RFC de multimédia suporta protocolos de rede modernos do cliente para a extremidade, o que aumenta o débito e reduz a latência geral da rede.
Endereçamento IP
Cada serviço de cache na extremidade que configurar tem endereços IPv4 e IPv6 anycast dedicados, que estão associados a cada serviço de cache na extremidade que criar e não são partilhados com outros clientes.
- Depois de configurar um serviço de cache edge, os endereços IP são atribuídos e ficam disponíveis.
- Os endereços atribuídos não mudam durante a vida útil de um determinado serviço de cache edge.
- A criação de um novo serviço de cache edge emite novos endereços IP com âmbito nesse serviço. Os endereços IP não são partilhados entre os seus serviços.
Todos os serviços de CDN de multimédia suportam IPv6 entre os clientes e cada nó de limite.
Recupere endereços IP
Para obter os endereços IP atribuídos a um serviço de cache edge:
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::"] ...
Notas:
- A RFC 6145 define o IPv4/IPv6 Translation (NAT64).
- Recomendamos que crie registos DNS para ambos os endereços IP (como registos A e AAAA).
- Configure os seus serviços para aceitarem tráfego para quaisquer nomes de domínio (nomes de anfitrião) que esteja a usar. Quando é recebido tráfego para anfitriões sem uma entrada
.routing.hostRules[].hosts, a RFC rejeita o tráfego com um erro HTTP 404.
Consoante as geografias em que os seus utilizadores se encontram, pode ver mais tráfego para um protocolo do que para outro, com base nos dispositivos dos utilizadores e no apoio técnico do ISP nessas geografias.
Limites de tempo do cliente
Os seguintes limites de tempo aplicam-se às ligaçõ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) | O tempo que o cliente tem para enviar o conjunto completo de cabeçalhos de pedidos. |
Para ver informações sobre os limites de tempo e a configuração da origem, reveja a secção Failover e limites de tempo da documentação da origem.
Limites de pedidos do cliente
Para ver detalhes sobre os limites de pedidos e respostas de clientes, consulte a documentação sobre quotas e limites.
Compatibilidade com protocolos de rede
A RFC de multimédia suporta ligações HTTP/3, HTTP/2 e HTTP/1.1 de clientes. A RFC de multimédia suporta ALPN (Application Layer Protocol Negotiation),
bem como o cabeçalho de resposta HTTP Alt-Svc (serviço alternativo) para
suporte do protocolo de publicidade.
| Protocolo | Suportado | SSL (TLS) necessário |
|---|---|---|
| HTTP/3 (IETF QUIC) | Sim | Sim |
| HTTP/2 | Sim | Sim |
| HTTPS (HTTP/1.1 através de TLS) | Sim | Sim |
| HTTP/1.1 | Sim | Não |
Notas:
- O HTTP/2 (h2) é suportado por predefinição.
- Para ativar o HTTP/3 (QUIC), contacte diretamente a equipa da sua conta.
- O HTTPS, o HTTP/2 e o HTTP/3 requerem que seja anexado um certificado SSL (TLS) válido ao seu serviço.
- Os clientes que não suportam HTTP/2 ou posterior estabelecem ligação automaticamente através de HTTP/1.1
Para saber mais sobre o suporte de protocolos de origem, consulte as origens e os protocolos suportados.
Versões de SSL (TLS) suportadas
Para ver as versões SSL (TLS) suportadas, consulte a documentação do SSL.
Resolva problemas de conetividade do cliente
- O protocolo HTTP/2 (h2) só é suportado para clientes que se ligam através de TLS. Este protocolo não suporta ligações de texto simples.
- Os clientes só negociam ligações que suportam. Os novos protocolos são concebidos como opcionais para oferecer compatibilidade com versões anteriores.
- Se tiver clientes com endereços IPv6, mas que estão a estabelecer ligação aos seus serviços de Media CDN através de IPv4, tal pode dever-se ao facto de a rede entre uma localização periférica do Media CDN e o utilizador suportar apenas IPv4.
- Apenas o HTTP/1.1 e posterior são suportados como protocolos de cliente. Os pedidos HTTP/0.9 e HTTP/1.0 são rejeitados com um erro HTTP 426 (Upgrade Required).