Ajuste de desempenho de TCP/IP em VMs do Azure

2025-06-16

Este artigo discute técnicas comuns de ajuste de desempenho de TCP/IP e algumas coisas a serem consideradas ao usá-las para máquinas virtuais em execução no Azure. Ele fornece uma visão geral básica das técnicas e explorou como as máquinas virtuais podem ser ajustadas.

Técnicas comuns de ajuste de TCP/IP

MTU, fragmentação e descarregamento de envio grande

MTU

A unidade de transmissão máxima (MTU) é o maior tamanho de quadro (pacote mais cabeçalhos de acesso à rede) especificado em bytes que pode ser enviado por meio de uma interface de rede. A MTU é um ajuste configurável. A MTU padrão usada nas VMs do Azure e a configuração padrão usada na maioria dos dispositivos de rede globalmente é de 1.500 bytes.

Fragmentação

A fragmentação ocorre quando um pacote enviado excede a MTU de um adaptador de rede. A pilha TCP/IP divide o pacote em partes menores (fragmentos) que estejam em conformidade com a MTU da interface. A fragmentação ocorre na camada de IP e é independente do protocolo subjacente (como TCP). Quando um pacote de 2.000 bytes é enviado por um adaptador de rede com uma MTU de 1.500, o pacote é dividido em um pacote de 1.500 bytes e um pacote de 500 bytes.

Os dispositivos de rede no caminho entre uma origem e um destino podem descartar os pacotes que excedem a MTU ou fragmentar em pacotes menores.

O bit Não fragmentar em um pacote IP

O bit DF (Don’t Fragment) é um sinalizador no cabeçalho do protocolo IP. O bit DF indica que os dispositivos de rede no caminho entre o remetente e o destinatário não devem fragmentar o pacote. Esse bit poderia ser definido por vários motivos. (Consulte a seção "descoberta de MTU de caminho" deste artigo para ver um exemplo.) Quando um dispositivo de rede recebe um pacote com o conjunto de bits DF e esse pacote excede a MTU da interface do dispositivo, o comportamento padrão é que o dispositivo descarte o pacote. O dispositivo envia uma mensagem de Fragmentação de ICMP necessária de volta para a fonte original do pacote.

Implicações de desempenho da fragmentação

A fragmentação pode ter implicações negativas de desempenho. Um dos principais motivos para o efeito sobre o desempenho é o efeito de CPU/memória da fragmentação e da remontagem de pacotes. Quando um dispositivo de rede precisa fragmentar um pacote, ele precisa alocar recursos de CPU/memória para executar a fragmentação.

A mesma coisa acontece quando o pacote é remontado. O dispositivo de rede deve armazenar todos os fragmentos até que eles sejam recebidos para que ele possa remontá-los no pacote original.

O Azure e a fragmentação

O Azure não processa pacotes fragmentados com Rede Acelerada. Quando uma VM recebe um pacote fragmentado, o caminho não desacelerado o processa. Como resultado, os pacotes fragmentados perdem os benefícios da Rede Acelerada, como latência mais baixa, tremulação reduzida e pacotes mais altos por segundo. Por esse motivo, recomendamos evitar a fragmentação, se possível.

O Azure, por padrão, descarta pacotes fragmentados que chegam à VM fora de ordem, o que significa que os pacotes não correspondem à sequência de transmissão do ponto de extremidade de origem. Esse problema pode ocorrer quando os pacotes viajam pela Internet ou outros WANs grandes.

Ajustar a MTU

Você pode melhorar a taxa de transferência interna da Rede Virtual aumentando a MTU para o tráfego da VM. No entanto, se a VM se comunicar com destinos fora da Rede Virtual que têm uma MTU diferente, a fragmentação poderá ocorrer e reduzir o desempenho.

Para obter mais informações sobre como definir a MTU em VMs do Azure, consulte Configurar MTU (Unidade de Transmissão Máxima) para máquinas virtuais no Azure.

Descarregamento de envio grande

O descarregamento de envio grande (LSO) pode melhorar o desempenho da rede descarregando a segmentação de pacotes para o adaptador ethernet. Quando o LSO está habilitado, a pilha TCP/IP cria um pacote TCP grande e o envia para o adaptador ethernet para segmentação antes de encaminhá-lo. O benefício do LSO libera a CPU de segmentar pacotes em tamanhos em conformidade com a MTU e descarregar esse processamento para o hardware da interface ethernet. Para saber mais sobre os benefícios do LSO, consulte Suporte ao descarregamento de envio grande.

Quando o LSO está habilitado, os clientes do Azure podem perceber tamanhos de quadro grandes durante capturas de pacotes. Esses tamanhos de quadro grandes podem levar alguns clientes a supor que está ocorrendo fragmentação ou que uma MTU grande está sendo usada quando não está. Com o LSO, o adaptador ethernet pode anunciar um tamanho máximo de segmento (MSS) maior para a pilha TCP/IP criar um pacote TCP maior. Em seguida, o adaptador ethernet divide esse quadro inteiro não segmentado em muitos quadros menores de acordo com sua MTU, que são visíveis em uma captura de pacote realizada na VM.

PMTUD e escala da janela de MSS do TCP

Tamanho máximo de segmento do TCP

O MSS (tamanho máximo de segmento) do TCP é uma configuração que limita o tamanho dos segmentos do TCP, evitando a fragmentação dos pacotes. Normalmente, os sistemas operacionais usam essa fórmula para definir o MSS:

MSS = MTU - (IP header size + TCP header size)

O cabeçalho IP e o cabeçalho TCP têm 20 bytes cada, ou 40 bytes ao todo. Uma interface com uma MTU de 1.500 tem um MSS de 1.460. O MSS é configurável.

Essa configuração é definida no handshake de três vias do TCP, quando sua sessão é configurada entre uma origem e um destino. Ambos os lados enviam um valor de MSS, e o menor dos dois é usado para a conexão do TCP.

As MTUs da origem e do destino não são os únicos fatores que determinam o valor do MSS. Os dispositivos de rede intermediários, como Gateways de VPN, incluindo o Gateway de VPN do Azure, podem ajustar a MTU independentemente da origem e do destino, garantindo o desempenho ideal da rede.

PMTUD (Descoberta de MTU do caminho)

O MSS é negociado, mas pode não indicar o MSS real a ser usado. Outros dispositivos de rede no caminho entre a origem e o destino podem ter um MTU menor do que o da origem e o destino. Nesse caso, o dispositivo cuja MTU é menor que o pacote descarta o pacote. O dispositivo envia de volta uma mensagem ICMP “Fragmentation Needed” (Tipo 3, Código 4) que informa sua MTU. Essa mensagem ICMP permite que o host de origem reduza corretamente a MTU do seu caminho. O processo é chamado de PMTUD (Descoberta de MTU do caminho).

O processo PMTUD reduz o desempenho da rede devido à sua ineficiência. Quando a MTU de um caminho de rede é excedida, os pacotes devem ser retransmitidos com um MSS inferior. Se um firewall de rede bloquear a mensagem ICMP Fragmentation Needed, o remetente não ficará ciente da necessidade de reduzir o MSS e continuará retransmitindo o pacote repetidamente. Por esse motivo, aconselhamos a não aumentar a MTU da VM do Azure.

VPN e MTU

Se você usar VMs que executam encapsulamento (como VPNs IPsec), haverá algumas outras considerações sobre o tamanho do pacote e a MTU. As VPNs adicionam mais cabeçalhos aos pacotes. Os cabeçalhos adicionados aumentam o tamanho do pacote e exigem um MSS menor.

Para o Azure, recomendamos definir o MSS do TCP em 1.350 bytes e a MTU da interface de túnel em 1.400. Para obter mais informações, consulte a página Dispositivos VPN e parâmetros de IPsec/IKE.

Latência, tempo de ida e volta e escala da janela do TCP

Latência e tempo de ida e volta

A velocidade da luz determina a latência de rede em uma rede de fibra óptica. O RTT (tempo de ida e volta) entre dois dispositivos de rede rege a taxa de transferência de rede TCP.

Rota	Distância	Tempo unidirecional	RTT
Nova York a São Francisco	4\.148 km	21 ms	42 ms
Nova York para Londres	5\.585 km	28 ms	56 ms
Nova York para Sydney	15.993 km	80 ms	160 ms

Esta tabela mostra a distância em linha reta entre dois locais. Normalmente, a distância em redes é maior do que a distância de linha reta. Esta é uma fórmula simples para calcular o mínimo de RTT conforme definido pela velocidade da luz:

minimum RTT = 2 * (Distance in kilometers / Speed of propagation)

É possível usar 200 para a velocidade de propagação. A velocidade da propagação é a distância, em quilômetros, que a luz viaja em 1 milissegundo.

Vejamos o exemplo de Nova York a San Francisco. A distância em linha reta é de 4.148 km. Inserir esse valor na equação resulta na seguinte equação:

Minimum RTT = 2 * (4,148 / 200)

A saída da equação está em milissegundos.

Se quiser obter o melhor desempenho de rede, a opção lógica é selecionar os destinos com a distância mais curta. Crie também sua rede virtual para otimizar o caminho do tráfego e reduzir a latência. Para obter mais informações, consulte a seção "Considerações de criação de rede" deste artigo.

Latência e efeitos do tempo de ida e volta no TCP

O tempo de ida e volta tem um efeito direto na taxa de transferência máxima do TCP. No protocolo TCP, o tamanho da janela é a quantidade máxima de tráfego que pode ser enviado por uma conexão TCP antes que o remetente precise receber a confirmação do receptor. Se o MSS TCP estiver definido como 1.460 e o tamanho da janela TCP estiver definido como 65.535, o remetente poderá enviar 45 pacotes antes da confirmação do receptor. Se o remetente não receber confirmação, ele retransmite os dados. Aqui está a fórmula:

TCP window size / TCP MSS = packets sent

Neste exemplo, 65.535/1.460 é arredondado para 45.

Esse estado "aguardando confirmação", um mecanismo para garantir a entrega confiável de dados, é o que faz com que o RTT afete a taxa de transferência TCP. Quanto mais tempo o remetente aguardar a confirmação, mais tempo ele precisará esperar antes de enviar mais dados.

Veja a fórmula para calcular a taxa de transferência máxima de uma única conexão do TCP:

Window size / (RTT latency in milliseconds / 1,000) = maximum bytes/second

Esta tabela mostra a taxa de transferência máxima em megabytes/segundo de uma única conexão do TCP. (Para facilitar a leitura, a unidade de medida usada é megabytes.)

Tamanho da janela do TCP (bytes)	Latência do RTT (ms)	Taxa de transferência máxima de megabytes/segundo	Taxa de transferência máxima de megabits/segundo
65.535	1	65.54	524.29
65.535	30	2.18	17.48
65.535	60	1.09	8.74
65.535	90	0.73	5.83
65.535	120	0.55	4.37

Se os pacotes forem perdidos, a taxa de transferência máxima de uma conexão TCP será reduzida enquanto o remetente retransmite os dados enviados.

Escala da janela do TCP

O dimensionamento da janela TCP é uma técnica que aumenta dinamicamente o tamanho da janela TCP para permitir que mais dados sejam enviados antes que uma confirmação seja necessária. No exemplo anterior, 45 pacotes seriam enviados antes de uma confirmação ser necessária. Se você aumentar o número de pacotes que podem ser enviados antes que uma confirmação seja necessária, você está reduzindo o número de vezes que um remetente está aguardando confirmação.

Esta tabela ilustra essas relações:

Tamanho da janela do TCP (bytes)	Latência do RTT (ms)	Taxa de transferência máxima de megabytes/segundo	Taxa de transferência máxima de megabits/segundo
65.535	30	2.18	17.48
131.070	30	4.37	34.95
262.140	30	8.74	69.91
524.280	30	17.48	139.81

Mas o valor do cabeçalho para o tamanho da janela do TCP é de apenas 2 bytes, o que significa que o valor máximo para uma janela de recepção é de 65.535. Para aumentar o tamanho máximo da janela, foi definido um fator de escala de janela do TCP.

O fator de escala também é uma configuração que pode ser feita em um sistema operacional. Aqui está a fórmula para calcular o tamanho da janela do TCP usando fatores de escala:

TCP window size = TCP window size in bytes * (2^scale factor)

Este é o cálculo de um fator de escala de 3 para a janela e um tamanho de janela de 65.535:

65,535 * (2^3) = 524,280 bytes

Um fator de escala de 14 resulta em um tamanho de janela do TCP de 14 (o deslocamento máximo permitido). O tamanho da janela TCP é de 1.073.725.440 bytes (8,5 gigabits).

Suporte para escala de janela do TCP

O Windows pode definir fatores de escala diferentes para tipos de conexão diferentes. (As classes de conexões incluem datacenter, Internet e assim por diante.) Use o Get-NetTCPConnection comando do PowerShell para exibir o tipo de conexão de escala da janela:

Get-NetTCPConnection

É possível usar o comandoGet-NetTCPSetting do PowerShell para exibir os valores de cada classe:

Get-NetTCPSetting

Defina o tamanho inicial da janela do TCP e o fator de escala do TCP no Windows usando o Set-NetTCPSetting comando do PowerShell. Para obter mais informações, consulte Set-NetTCPSetting.

Set-NetTCPSetting

Os seguintes valores são as configurações TCP efetivas para AutoTuningLevel:

AutoTuningLevel	Fator de escala	Multiplicador de escala	Fórmula para calcular o tamanho máximo da janela
Desabilitado	Nenhum	Nenhum	Tamanho da janela
Restritos	4	2^4	Tamanho da janela * (2^4)
Altamente restrito	2	2^2	Tamanho da janela * (2^2)
Normal	oito	2^8	Tamanho da janela * (2^8)
Habilitação	14	2^14	Tamanho da janela * (2^14)

É mais provável que essas configurações afetem o desempenho do TCP, mas muitos outros fatores na Internet, fora do controle do Azure, também podem afetar o desempenho do TCP.

Rede acelerada e recebimento de escala lateral

Redes aceleradas

As funções de rede de máquina virtual historicamente são intensivas em CPU na VM convidada e no hipervisor/host. A CPU do host processa no software todos os pacotes que transitam pelo host, incluindo todo o encapsulamento e descapsulação de rede virtual. Quanto mais tráfego passar pelo host, maior será a carga da CPU. Se a CPU do host estiver ocupada com outras operações que afetam a taxa de transferência e a latência da rede. O Azure resolve esse problema com a rede acelerada.

A rede acelerada fornece latência de rede ultralow consistente por meio do hardware programável interno do Azure e de tecnologias como SR-IOV. A rede acelerada move grande parte da pilha de rede definida pelo software do Azure para fora das CPUs e para o SmartNICs baseado em FPGA. Essa alteração permite que os aplicativos do usuário final recuperem ciclos de computação que colocam menos carga na VM diminuindo o tremulação e a inconsistência na latência. Em outras palavras, o desempenho pode ser mais determinístico.

A rede acelerada melhora o desempenho, permitindo que a VM convidada ignore o host e estabeleça um DataPath diretamente com o SmartNIC de um host. Aqui estão alguns benefícios da rede acelerada:

Latência menor/mais pps (pacotes por segundo): remover o comutador virtual do caminho de dados elimina o tempo que os pacotes gastam no host para processamento da política e aumenta o número de pacotes que podem ser processados na VM.
Tremulação reduzida: processamento de comutador virtual depende da quantidade de política que precisa ser aplicada e da carga de trabalho da CPU que está fazendo o processamento. O descarregamento da imposição de política para o hardware remove essa variabilidade ao entregar pacotes diretamente à VM, removendo a comunicação do host para a VM e todas as interrupções e mudanças de contexto de software.
Menor utilização da CPU: ignorar o comutador virtual no host resulta em menor utilização da CPU para processar o tráfego de rede.

Para usar a rede acelerada, você precisa habilitá-la explicitamente em cada VM aplicável. Veja instruções em Criar uma máquina virtual Linux com a rede acelerada.

Recebimento de escala lateral

O RSS (recebimento de escala lateral) é uma tecnologia de driver de rede que distribui o recebimento de tráfego de rede com mais eficiência, distribuindo o processamento de recebimento entre várias CPUs em um sistema multiprocessador. Em resumo, o RSS permite que um sistema processe mais tráfego recebido porque usa todas as CPUs disponíveis em vez de apenas uma. Para uma discussão mais técnica sobre o RSS, consulte Introdução ao recebimento da escala lateral.

Para obter o melhor desempenho quando as rede acelerada estão habilitada em uma VM, habilite o RSS. O RSS também pode fornecer benefícios para VMs que não usam rede acelerada. Para ter uma visão geral sobre como determinar se o RSS está habilitado e como habilitá-lo, consulte Otimizar a taxa de transferência da rede para máquinas virtuais do Azure.

TIME_WAIT do TCP e TIME_WAIT Assassination

O TIME_WAIT TCP é outra configuração comum que afeta o desempenho da rede e do aplicativo. VMs ocupadas abrem e fecham muitos soquetes com frequência, seja como clientes ou servidores. Durante operações TCP normais, um soquete geralmente entra no estado TIME_WAIT e permanece lá por um longo período. Esse estado garante a entrega de todos os dados restantes no soquete antes de ele ser fechado. Como resultado, as pilhas TCP/IP geralmente impedem a reutilização de soquetes descartando silenciosamente o pacote TCP SYN do cliente.

Você pode configurar por quanto tempo um soquete permanece no estado TIME_WAIT. A duração pode variar de 30 segundos a 240 segundos. Soquetes são um recurso finito e sua disponibilidade é configurável. Normalmente, cerca de 30.000 soquetes estão disponíveis para uso a qualquer momento. Se o sistema consumir todos os soquetes disponíveis ou se clientes e servidores usarem configurações de TIME_WAIT incompatíveis, a VM poderá tentar reutilizar um soquete ainda no estado TIME_WAIT. Nesses casos, novas conexões falham porque os pacotes TCP SYN são descartados silenciosamente.

O valor para intervalo de portas para soquetes de saída é configurável na pilha TCP/IP de um sistema operacional. O mesmo ocorre para configurações de TIME_WAIT do TCP e reutilização de soquete. Alterar esses números pode melhorar a escalabilidade. Mas, dependendo da situação, essas alterações podem causar problemas de interoperabilidade. Tenha cuidado ao alterar esses valores.

Use TIME_WAIT Assassination para resolver essa limitação de escala. TIME_WAIT Assassination permite que um soquete seja reutilizado em determinadas situações, como quando o número de sequência no pacote IP da nova conexão excede o número de sequência do último pacote da conexão anterior. Nesse caso, o sistema operacional permite que a nova conexão seja estabelecida (aceita o novo SYN/ACK) e força o fechamento da conexão anterior que estava no estado TIME_WAIT. Esse recurso é compatível com as VMs do Windows no Azure. Para saber mais sobre a compatibilidade com outras VMs, verifique com o fornecedor do sistema operacional.

Para saber mais sobre como configurar o estado de TIME_WAIT do TCP e o intervalo de portas de origem, consulte Configurações que podem ser modificadas para melhorar o desempenho da rede.

Fatores de rede virtual que podem afetar o desempenho

Taxa de transferência máxima de saída da VM

O Azure fornece vários tamanhos e tipos de VM, cada um com uma combinação diferente de recursos de desempenho. Uma dessas funcionalidades de desempenho está a taxa de transferência de rede (ou largura de banda), medida em megabits por segundo (Mbps). Como as máquinas virtuais são hospedadas em um hardware compartilhado, a capacidade de rede deve ser compartilhada adequadamente entre as máquinas virtuais que usam o mesmo hardware. Máquinas virtuais maiores recebem mais largura de banda que máquinas virtuais menores.

A largura de banda de rede alocada para cada máquina virtual é medida no tráfego de saída (saída) da máquina virtual. Todo o tráfego de rede que deixa a máquina virtual é contado para o limite alocado, independentemente do destino. Se uma máquina virtual tiver um limite de 1.000 Mbps, esse limite se aplicará se o tráfego de saída é destinado a outra máquina virtual na mesma rede virtual ou uma fora do Azure.

A entrada não é medida nem limitada diretamente. Mas há outros fatores, como limites de CPU e armazenamento, que podem afetar a capacidade de uma máquina virtual de processar dados de entrada.

A rede acelerada foi criada para melhorar o desempenho de rede, incluindo latência, taxa de transferência e utilização da CPU. A rede acelerada possa melhorar a taxa de transferência de uma máquina virtual, mas ela poderá fazer isso somente até a largura de banda alocada da máquina virtual.

As máquinas virtuais do Azure têm pelo menos um adaptador de rede anexado. Elas podem ter vários. A largura de banda alocada a uma máquina virtual é a soma de todo o tráfego de saída em todos os adaptadores de rede anexados à máquina. Em outras palavras, a largura de banda é alocada por máquina virtual, independentemente de quantos adaptadores de rede estão anexados à máquina.

A taxa de transferência de saída esperada e o número de interfaces de rede com suporte em cada tamanho de VM são detalhados em Tamanhos das máquinas virtuais do Windows no Azure. Para ver a taxa de transferência máxima, selecione um tipo, como uso geral, e localize a seção sobre a série de tamanhos na página resultante (por exemplo, "série Dv2"). Para cada série, há uma tabela que fornece especificações de rede na última coluna, intitulada "Máximo de NICs/largura de banda de rede esperada (Mbps)".

O limite de taxa de transferência se aplica à máquina virtual. A taxa de transferência não é afetada por esses fatores:

Número de adaptadores de rede: o limite de largura de banda se aplica à soma de todo o tráfego de saída da máquina virtual.
Rede acelerada: embora o recurso possa ser útil para alcançar o limite publicado, ele não altera o limite.
Destino do tráfego: todos os destinos contam para o limite de saída.
Protocolo: todo o tráfego de saída em todos os protocolos contam para o limite.

Para obter mais informações, consulte a Largura de banda da rede de máquina virtual.

Otimização de VMs (Máquinas Virtuais) do Linux

Os kernels modernos do Linux têm recursos que podem ajudar a obter consistência e desempenho, às vezes exigidos por determinadas cargas de trabalho.

Para obter mais informações, consulte Otimizar largura de banda de rede em VMs do Azure

Considerações sobre o desempenho da Internet

Conforme discutido no artigo, fatores na Internet e fora do controle do Azure podem afetar o desempenho da rede. Aqui estão alguns desses fatores:

Latência: o tempo de ida e volta entre dois pontos de extremidade é afetado por problemas em redes intermediárias, pelo tráfego que não usa o caminho de distância "mais curto" e por caminhos de emparelhamento abaixo do ideal.
Perda de pacote: a perda de pacotes é causada por congestionamento de rede, problemas de caminho físico e dispositivos de rede com baixo desempenho.
Tamanho/fragmentação de MTU: a fragmentação ao longo do caminho pode levar a atrasos na chegada de dados ou em pacotes que chegam fora de ordem, o que pode afetar a entrega dos pacotes.

O Rastreamento de rotas é uma boa ferramenta para medir as características de desempenho da rede (como latência e perda de pacotes) ao longo de cada caminho de rede entre um dispositivo de origem e um dispositivo de destino.

Considerações sobre a criação da rede virtual

Junto com as considerações discutidas anteriormente neste artigo, a topologia de uma rede virtual pode afetar o desempenho da rede. Por exemplo, um projeto de hub e spoke que redireciona o tráfego globalmente para uma única rede virtual de hub introduz latência da rede, o que afeta o desempenho geral da rede.

O número de dispositivos de rede que o tráfego de rede atravessa também pode afetar a latência geral. Em um projeto de hub e spoke, se o tráfego passar por uma solução de virtualização de rede de spoke e uma solução de virtualização de hub antes de transitar para a internet, as soluções de virtualização de rede introduzem alguma latência.

Regiões do Azure, redes virtuais e latência

As regiões do Azure são formadas por vários datacenters dentro de uma área geográfica geral. Esses datacenters podem não estar fisicamente próximos um do outro. Em alguns casos, eles são separados por até 10 quilômetros. A rede virtual é uma sobreposição lógica na rede do datacenter físico do Azure. Uma rede virtual não resulta em nenhuma topologia de rede específica no datacenter.

Por exemplo, duas VMs que estão na mesma rede e sub-rede virtual podem estar em diferentes racks, linhas ou até mesmo datacenters. Eles podem ser separados por pés de cabo de fibra óptica ou por quilômetros de cabo de fibra óptica. Essa variação pode apresentar latência variável (diferença de alguns milissegundos) entre VMs diferentes.

O posicionamento geográfico de VMs e a latência potencial resultante entre duas VMs são influenciados pela configuração de conjuntos de disponibilidade, grupos de posicionamento por proximidade e zonas de disponibilidade. Mas a distância entre os datacenters em uma região é específica da região e influenciada principalmente pela topologia do datacenter na região.

Esgotamento de porta NAT de origem

Uma implantação no Azure pode se comunicar com pontos de extremidade fora do Azure, na internet pública ou no espaço de endereços IP público. Quando uma instância inicia uma conexão de saída, o Azure mapeia dinamicamente o endereço IP privado para um endereço IP público. Depois que o Azure cria esse mapeamento, o tráfego de retorno para o fluxo de saída originado também pode alcançar o endereço IP privado onde o fluxo foi originado.

Para cada conexão de saída, o Azure Load Balancer precisa manter o mapeamento por um período de tempo. Com a natureza de multilocatário do Azure, manter esse mapeamento para cada fluxo de saída de todas as VMs pode consumir muitos recursos. Portanto, há limites definidos e baseados na configuração da rede virtual do Azure. Ou, para dizer que, mais precisamente, uma VM do Azure só pode fazer algumas conexões de saída em um determinado momento. Quando esses limites forem atingidos, a VM não fará mais conexões de saída.

Mas esse comportamento pode ser configurado. Para obter mais informações sobre SNAT e esgotamento de porta SNAT, consulte este artigo.

Medir o desempenho de rede no Azure

Muitos dos máximos de desempenho neste artigo estão relacionados à latência de rede/RTT (tempo de ida e volta) entre duas VMs. Esta seção fornece algumas sugestões sobre como testar a latência/RTT e como testar o desempenho do TCP e o desempenho da rede de VM. Ajuste e teste o desempenho dos valores do TCP/IP e de rede discutidos anteriormente usando as técnicas descritas nesta seção. Insira valores de latência, MTU, MSS e tamanho da janela nos cálculos fornecidos anteriormente e compare os máximos teóricos com os valores reais observados durante o teste.

Medir o tempo de ida e volta e a perda de pacotes

O desempenho do TCP depende muito do RTT e da perda de pacotes. O utilitário PING disponível no Windows e no Linux fornece a maneira mais fácil de medir a perda de RTT e de pacotes. A saída do PING mostra a latência mínima/máxima/média entre uma origem e um destino. Mostra a perda de pacotes. O PING usa o protocolo ICMP por padrão. Use PsPing para testar o RTT do TCP. Para saber mais, consulte PsPing.

Os pings ICMP e TCP não medem o caminho de dados da rede acelerada. Para medir o caminho de dados, leia sobre Latte e SockPerf nesse artigo.

Medir a largura de banda real de uma máquina virtual

Para medir com precisão a largura de banda das VMs do Azure, siga estas diretrizes.

Para obter mais informações sobre como testar outros cenários, consulte estes artigos:

Detectar comportamentos ineficientes do TCP

Em capturas de pacotes, os clientes do Azure podem ver pacotes do TCP com sinalizadores (SACK, confirmação de DUP, retransmissão e retransmissão rápida) que podem indicar problemas de desempenho da rede. Esses pacotes indicam especificamente as ineficiências de rede que resultam da perda de pacotes. Mas a perda de pacotes não é necessariamente causada por problemas de desempenho do Azure. Problemas de desempenho podem ser resultado de problemas de aplicativo, sistema operacional ou outros que podem não estar diretamente relacionados à plataforma do Azure.

Além disso, é normal ter algumas confirmações duplicadas e de retransmissão em uma rede. Os protocolos do TCP foram criados para serem confiáveis. A evidência desses pacotes do TCP em uma captura de pacotes não indica necessariamente problemas na rede do sistema, a menos que eles sejam excessivos.

Ainda assim, esses tipos de pacotes indicam que a taxa de transferência do TCP não está atingindo seu desempenho máximo, por motivos discutidos em outras seções deste artigo.

Próximas etapas

Agora que você aprendeu sobre o ajuste de desempenho de TCP/IP para VMs do Azure, considere explorar outros fatores para planejar redes virtuais. Você também pode saber mais sobre como conectar e configurar redes virtuais.