Unidade de transmissão máxima
A unidade de transmissão máxima (MTU) é o tamanho, em bytes, do maior pacote IP possível, incluindo cabeçalhos IP, cabeçalhos de protocolo da camada 4 e dados da camada 4, que podem caber num frame Ethernet.
Tamanhos de MTU da rede VPC válidos
As redes da nuvem privada virtual (VPC) usam uma MTU predefinida de 1460 bytes. Pode definir a MTU de uma rede VPC para qualquer valor entre 1300 bytes e 8896 bytes (inclusive). Os tamanhos de MTU personalizados comuns são 1500 bytes (Ethernet padrão) ou 8896 bytes (o máximo possível). Recomendamos que configure a MTU para cada interface de rede (NIC) da instância da máquina virtual (VM) de modo a corresponder à MTU da rede VPC à qual está ligada. Para mais informações, consulte o artigo VMs e definições de MTU.
Comunicação entre Google Cloud VMs em redes da VPC
Quando o envio e a receção de VMs usam a mesma rede da VPC ou redes da VPC em intercâmbio com MTUs idênticos, é possível enviar pacotes IP até ao tamanho do MTU entre as duas VMs, se as interfaces de ambas as VMs estiverem configuradas para usar o MTU da rede da VPC.
Para evitar problemas de incompatibilidade de MTU, recomendamos que use a mesma MTU para todas as suas redes VPC ligadas. Embora seja a prática recomendada, não é obrigado a ter MTUs idênticas entre as redes VPC ligadas. Para ver detalhes sobre como os protocolos processam situações em que existe uma incompatibilidade de MTU entre redes da VPC, consulte o artigo MTUs incompatíveis, restrição de MSS e deteção de MTU do caminho.
Na perspetiva de uma VM de envio, os caminhos para os seguintes destinos representam tráfego de VM para VM encaminhado numa rede VPC:
- Um endereço IPv4 interno regional num intervalo de endereços IPv4 primários ou secundários da sub-rede, incluindo intervalos de endereços IPv4 privados e intervalos de endereços IPv4 públicos usados de forma privada, usado por estes recursos de destino:
- O endereço IPv4 interno principal da interface de rede (NIC) de uma VM de receção.
- Um endereço IPv4 interno num intervalo de IPs de alias da NIC de uma VM de receção.
- Um endereço IPv4 interno de uma regra de encaminhamento interno para o encaminhamento de protocolos ou para um balanceador de carga de rede de passagem interna.
- Intervalos de endereços de sub-rede IPv6 internos usados por
estes recursos de destino:
- Um endereço IPv6 do
/96intervalo de endereços IPv6 atribuído à NIC de uma VM de receção. - Um endereço IPv6 do
/96intervalo de endereços IPv6 de uma regra de encaminhamento interno para o encaminhamento de protocolos ou para um balanceador de carga de rede de passagem interna.
- Um endereço IPv6 do
- Intervalos de endereços de sub-rede IPv6 externos usados por estes recursos de destino quando os pacotes são encaminhados através de trajetos de sub-rede ou trajetos de sub-rede de peering na rede VPC:
- Um endereço IPv6 do
/96intervalo de endereços IPv6 atribuído à NIC de uma VM de receção. - Um endereço IPv6 do
/96intervalo de endereços IPv6 de uma regra de encaminhamento externo para o encaminhamento de protocolos ou para um Network Load Balancer de passagem externa.
- Um endereço IPv6 do
Os seguintes caminhos de VM para VM são tratados da mesma forma que a comunicação com destinos fora de uma rede VPC:
- Se o destino do pacote for um endereço IPv4 externo da placa NIC de uma VM de receção.Google Cloud
- Se o destino do pacote for um endereço IPv4 externo de um balanceador de carga de rede de encaminhamento externo.
- Se o destino do pacote for um endereço IPv4 externo de uma regra de encaminhamento para o encaminhamento de protocolos
- Se o destino do pacote for um endereço IPv6 externo de uma NIC de VM, de um equilibrador de carga de rede de passagem externo ou de uma regra de encaminhamento para encaminhamento de protocolo externo e a rota aplicável na rede da VPC usar um salto seguinte do gateway de Internet predefinido. Google CloudNeste cenário, as VMs de receção não estão na mesma rede da VPC que a VM de envio nem numa rede da VPC ligada à rede da VPC da VM de envio através do intercâmbio das redes da VPC.
Comunicação com destinos fora de uma rede da VPC
Google Cloud processa pacotes enviados para destinos fora da rede VPC da VM de envio, conforme mostrado na tabela seguinte. Os destinos fora da rede VPC de uma VM de envio incluem endereços IP encaminháveis publicamente para recursos fora de Google Cloud e endereços IP externos utilizáveis pelo cliente dentro de Google Cloud.
Uma vez que a Internet usa geralmente uma MTU de 1500 bytes, manter o tamanho do pacote IP em 1500 bytes ou menos evita normalmente a perda de pacotes relacionada com a MTU.
| Situação | Comportamento |
|---|---|
| Pacotes TCP SYN e SYN-ACK | Google Cloud executa a restrição de MSS, se necessário, alterando o MSS para garantir que os pacotes se encaixam na MTU. |
| MTU de pacotes IP entre 1300 bytes e 1600 bytes (inclusive) | Google Cloud não faz alterações ao pacote, exceto aos pacotes SYN e SYN-ACK, conforme abordado na primeira linha. |
| Pacote IP superior a 1600 bytes | Google Cloud elimina o pacote e envia uma mensagem Fragmentation Needed (ICMP sobre IPv4) ou Packet Too Big (ICMPv6) quando o bit DF está ativado e também quando o bit DF está desativado. |
Comunicação com as APIs e os serviços Google
As VMs que usam qualquer tamanho de MTU de rede VPC válido podem enviar pacotes para APIs e serviços Google, incluindo a utilização do acesso privado à Google e do Private Service Connect para APIs Google. Os detalhes nesta secção também se aplicam a recursos no local que enviam pacotes para as APIs e os serviços Google através do acesso privado da Google para anfitriões no local.
O caminho do tráfego para as APIs e os serviços Google descritos nesta secção é implementado pelas interfaces de utilizador da Google (GFEs). Estes GFEs usam MTUs fixas não configuráveis. O tráfego de Google Cloud para as APIs e os serviços Google usa sempre o protocolo TCP: se uma VM se ligar às APIs e aos serviços Google a partir de uma rede VPC cuja MTU não corresponda à MTU do GFE, o tamanho do segmento é negociado através do anúncio MSS do TCP, conforme descrito em MTUs, MSS clamping, path MTU discovery em incompatibilidade.
| Origem do pacote | Destino do pacote |
|---|---|
Qualquer endereço IPv4 interno: endereço IPv4 interno principal ou endereço IPv4 interno de um intervalo de IPs de alias da NIC da VM Um endereço IPv4 externo atribuído à NIC da VM através de uma configuração de acesso NAT 1-1: nesta situação,o Google Cloud Google Cloud realiza NAT 1-1 na saída, convertendo um endereço IPv4 interno principal de origem original num endereço IPv4 externo de origem especificado na configuração de acesso. |
|
| Endereço IPv6 externo ou interno para VMs de pilha dupla ou apenas IPv6 |
|
Comunicação através de túneis do Cloud VPN
A VPN na nuvem tem um MTU de gateway para pacotes encapsulados e um MTU de carga útil para pacotes antes e depois da encapsulagem.
Para ver valores de MTU de payload precisos e outras informações de MTU da Cloud VPN, consulte as considerações sobre a MTU na documentação da Cloud VPN.
Comunicação através de associações do Cloud Interconnect (VLAN)
Recomendamos que use a mesma MTU para todas as associações de VLAN que estão ligadas à mesma rede VPC e que defina a MTU da rede VPC para o mesmo valor. Para ver detalhes sobre as MTUs de anexos de VLAN do Cloud Interconnect, consulte o artigo MTU do Cloud Interconnect.
Suporte de frames jumbo
A tabela seguinte resume o suporte de frames jumbo entre os produtos e as funcionalidades do Google Cloud:
| Produto ou funcionalidade | Suporte de frames jumbo |
|---|---|
| Compute Engine | Sim |
| Cloud Interconnect | Sim |
| Cloud VPN | Não |
| APIs Google | Não |
Definições de VMs e MTU
Como prática recomendada, faça corresponder a MTU da NIC de uma VM à MTU da rede VPC à qual a NIC está ligada:
O MTU de cada NIC para uma VM Linux baseada numa imagem de SO pública é automaticamente definido para o MTU da rede VPC respetiva através da opção DHCP 26.
Cada MTU da NIC para uma VM do Windows baseada numa imagem do SO pública está configurada com uma MTU fixa de
1,460bytes. Se alterar a MTU de uma rede VPC que contenha VMs Windows baseadas em imagens de SO públicas, tem de alterar a definição de MTU de uma VM Windows.Se usar imagens de SO convidadas personalizadas, tem de configurar os MTUs da NIC ou verificar se o SO convidado aceita o MTU da rede VPC através da opção 26 do DHCP.
Se uma VM tiver várias interfaces de rede, defina a MTU de cada NIC para a MTU da rede VPC respetiva.
Se o MTU da NIC tiver de ser diferente do MTU da rede da VPC, defina o MTU da NIC para um valor inferior ao MTU da rede da VPC. Diminuir forçadamente a MTU da NIC é vantajoso para alguns cenários de redes avançadas.
Alterar a MTU de uma rede de VPC
Se alterar a MTU de uma rede VPC com VMs em execução, tenha em atenção as seguintes considerações:
Se reduzir a MTU da rede VPC, tem de parar e iniciar cada VM. O reinício de uma VM a partir do respetivo sistema operativo convidado não atualiza a respetiva MTU.
Se aumentar a MTU da rede VPC, as VMs que usam a rede VPC não tiram partido da MTU da rede VPC aumentada até serem paradas e iniciadas. Até que cada VM seja parada e reiniciada, a VM continua a usar o valor de MTU anterior (inferior).
Para ver instruções, consulte o artigo Altere a definição de MTU de uma rede VPC.
Definições do GKE e MTU
A MTU selecionada para uma interface de pod depende da interface de rede do contentor (CNI) usada pelos nós do cluster e da definição de MTU da VPC subjacente. Para mais informações, consulte o artigo Pods.
O valor MTU da interface do pod é 1460 ou herdado da interface principal do nó.
| CNI | MTU | GKE Standard |
|---|---|---|
| kubenet | 1460 | Predefinição |
|
kubenet (GKE versão 1.26.1 e posterior) |
Herdado | Predefinição |
| Calico | 1460 |
Ativada através da utilização da funcionalidade Para ver detalhes, consulte o artigo Controle a comunicação entre Pods e serviços através de políticas de rede. |
| netd | Herdado | Ativada através de qualquer uma das seguintes opções: |
| GKE Dataplane V2 | Herdado |
Ativada através da utilização da funcionalidade Para obter detalhes, consulte o artigo Usar o GKE Dataplane V2. |
MTUs sem correspondência, restrição de MSS, deteção de MTU do caminho
Esta secção descreve como os protocolos TCP e não TCP processam MTUs em conflito.Protocolo TCP
O protocolo TCP processa automaticamente as incompatibilidades de MTU. O cliente e o servidor calculam individualmente os seus próprios valores de tamanho máximo do segmento (MSS) de TCP efetivo sempre que é aberta uma ligação TCP. O cliente e o servidor não têm de concordar com um valor MSS efetivo idêntico.
Tamanho máximo do segmento (MSS) de TCP efetivo do cliente: a maior quantidade de dados transmissíveis num segmento de TCP enviado de um cliente para um servidor é o mínimo dos seguintes dois valores:
O valor do campo MSS no pacote SYN-ACK recebido pelo cliente do servidor durante o estabelecimento da ligação TCP.
A MTU da interface de rede do cliente, menos 40 bytes. Os 40 bytes subtraídos incluem 20 bytes para o cabeçalho IP e 20 bytes para o cabeçalho TCP base.
Tamanho máximo do segmento (MSS) de TCP efetivo do servidor: a maior quantidade de dados transmissíveis num segmento de TCP enviado de um servidor para um cliente é o mínimo dos dois valores seguintes:
O valor do campo MSS no pacote SYN recebido pelo servidor do cliente durante o estabelecimento da ligação TCP.
A MTU da interface de rede do servidor, menos 40 bytes. Os 40 bytes subtraídos incluem 20 bytes para o cabeçalho IP e 20 bytes para o cabeçalho TCP base.
Limitação de MSS TCP
A restrição de MSS do TCP é um processo em que um dispositivo de rede entre um cliente e um servidor altera os valores de MSS em pacotes SYN e SYN-ACK à medida que encaminha os pacotes entre o cliente e o servidor.O Google Cloud usa a restrição de MSS sempre que envia pacotes para destinos fora de uma rede da VPC.
Os túneis de Cloud VPN e as associações de VLAN do Cloud Interconnect também usam a restrição de MSS. Para mais informações, consulte os artigos Encapsulamento e processamento de pacotes na documentação do Cloud VPN e MTU do Cloud Interconnect.
As redes VPC não realizam a restrição de MSS para pacotes encaminhados pelos saltos seguintes numa rede VPC porque o protocolo TCP em si é suficiente.
Protocolos não TCP
Outros protocolos, como o UDP, requerem cuidados especiais quando estão envolvidas duas MTUs de rede VPC diferentes. É da responsabilidade de um sistema de envio emitir pacotes que se enquadrem na MTU da respetiva interface de rede, na MTU da interface de rede do sistema de receção e na MTU de todas as redes intermédias. Google Cloud não realiza a fragmentação de IP para pacotes encaminhados pelos saltos seguintes numa rede VPC.
Quando um pacote IP é demasiado grande para ser entregue, por exemplo, quando o pacote excede a MTU da rede VPC onde se encontra a NIC da VM de receção, o Google Cloud rejeita o pacote. Se o pacote tiver o bit DF definido, Google Cloud também envia uma mensagem Fragmentation Needed (ICMP over IPv4) ou Packet Too Big (ICMPv6) de volta para o remetente.
Google Cloud envia uma mensagem de fragmentação necessária ou pacote demasiado grande
nas seguintes circunstâncias, mesmo quando um bit DF está desativado:
- Se a MTU da rede da VPC for inferior a 1600 bytes e o pacote que está a ser enviado exceder a MTU da rede da VPC.
- Se a MTU da rede VPC for de 1600 bytes ou mais e o pacote enviado exceder os 1600 bytes.
As mensagens ICMP Fragmentation Needed ou Packet Too Big são necessárias para uma VM que esteja a enviar pacotes para usar a Path MTU discovery (PMTUD). Para ilustrar como funciona a PMTUD, considere o seguinte exemplo com duas VMs em redes VPC diferentes que estão ligadas através do peering de redes VPC:
- A VM de envio tem uma NIC numa rede VPC cuja MTU é de 8896 bytes.
- A VM de receção tem uma NIC numa rede de VPC cuja MTU é de 1460 bytes.
- A VM de envio emite um pacote IP de 8000 bytes cujo bit Don't Fragment (
DF) está definido. Uma vez que o pacote é demasiado grande para ser entregue à VM de receção, a VM de envio envia uma mensagem de fragmentação necessária ou pacote demasiado grande para a VM de envio.Google Cloud Esta mensagem indica o maior tamanho possível do pacote IP que o remetente pode usar quando tenta retransmitir pacotes para a ligação. - O sistema operativo da VM de envio usa estas informações para reduzir o tamanho do pacote IP quando envia pacotes subsequentes para a VM de receção.
O PMTUD tem os seguintes requisitos adicionais porque os pacotes Fragmentation Needed ou Packet Too Big gerados pelo PMTUD usam o protocolo ICMP e têm origens que correspondem ao destino de um pacote original:
- Tem de configurar as regras da firewall da VPC de autorização de entrada ou as regras nas políticas de firewall de modo que o ICMP (para IPv4) ou o ICMPv6 (para IPv6) sejam permitidos a partir de origens que correspondam aos destinos dos pacotes originais. Para simplificar a configuração da firewall, considere permitir ICMP e ICMPv6 de todas as origens.
- As regras de encaminhamento para o balanceador de carga de rede de passagem interno e o encaminhamento de protocolos interno têm de usar o protocolo
L3_DEFAULTpara processarem o ICMP para PMTUD e o protocolo usado pelo pacote original.
O que se segue?
- Para ver uma MTU diferente a funcionar, consulte o artigo Crie e valide uma rede de MTU de jumbo frame.
- Crie uma rede VPC com um MTU especificado.
- Altere a definição de MTU de uma rede VPC.
Experimente
Se está a usar o Google Cloud pela primeira vez, crie uma conta para avaliar o desempenho da VPC em cenários reais. Os novos clientes também recebem 300 USD em créditos gratuitos para executar, testar e implementar cargas de trabalho.
Experimente a VPC gratuitamente