Ajuste de desempenho do TCP/IP para as VMs do Azure

2025-06-15

Este artigo discute técnicas comuns de otimização de desempenho TCP/IP e algumas coisas a considerar ao utilizá-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 TCP/IP

MTU, fragmentação, e descarregamento de envio grande

MTU

A unidade de transmissão máxima (MTU) é o quadro de maior tamanho (pacote mais cabeçalhos de acesso à rede) especificado em bytes que podem ser enviados através de uma interface de rede. A MTU é uma configuração ajustável. O MTU padrão utilizado nas VMs do Azure, e a configuração padrão na maioria dos dispositivos de rede globalmente, é de 1.500 bytes.

Fragmentação

A fragmentação ocorre quando um pacote é enviado e excede o MTU de uma interface de rede. A pilha TCP/IP fragmenta o pacote em partes menores (fragmentos) que se ajustam ao MTU da interface. A fragmentação ocorre na camada IP e é independente do protocolo subjacente (como o TCP). Quando um pacote de 2.000 bytes é enviado através de uma interface 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 fonte e um destino podem ou descartar pacotes que excedem o MTU ou fragmentar o pacote em peças menores.

O bit "Não Fragmentar" num pacote IP

O bit de Não Fragmentar (DF) é 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. Este bit pode ser configurado por várias razões. (Consulte a seção "Descoberta do MTU do Caminho" deste artigo para um exemplo.) Quando um dispositivo de rede recebe um pacote com o bit “Não Fragmentar” ativado, e esse pacote excede o MTU da interface do dispositivo, o comportamento padrão é que o dispositivo descarte o pacote. O dispositivo envia uma mensagem ICMP de "Fragmentation Needed" de volta à origem original do pacote.

Implicações de desempenho da fragmentação

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

O mesmo acontece quando o pacote é remontado. O dispositivo de rede deve armazenar todos os fragmentos até que sejam recebidos, para que possam ser remontados no pacote original.

Azure e fragmentação

O Azure não processa pacotes fragmentados com a Rede Acelerada. Quando uma VM recebe um pacote fragmentado, o caminho não acelerado o processa. Como resultado, os pacotes fragmentados perdem os benefícios da Rede Acelerada, como latência mais baixa, jitter reduzido e pacotes mais altos por segundo. Por esta razão, 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 outras WANs grandes.

Ajustar o MTU

Você pode melhorar a taxa de transferência interna da Rede Virtual aumentando a MTU para o tráfego da sua VM. No entanto, se a VM se comunicar com destinos fora da Rede Virtual que tenham 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 Envios Grandes

O LSO (Large Send Offload) pode melhorar o desempenho da rede transferindo a segmentação de pacotes no 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 que estão em conformidade com a MTU e descarregar esse processamento para o hardware de interface ethernet. Para saber mais sobre os benefícios do LSO, consulte Supporting large send offload.

Quando o LSO está habilitado, os clientes do Azure podem notar grandes tamanhos de quadros durante as capturas de pacotes. Estes tamanhos de quadros grandes podem levar alguns clientes a pensar que a fragmentação está a ocorrer ou que um MTU grande está a ser utilizado, quando na realidade não está. Com LSO, o adaptador ethernet pode anunciar um tamanho máximo de segmento (MSS) maior para a pilha TCP/IP, permitindo assim a criação de pacotes TCP maiores. Em seguida, o adaptador ethernet divide todo esse quadro 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.

Escalamento de janela TCP MSS e PMTUD

tamanho máximo do segmento TCP

O tamanho máximo do segmento TCP (MSS) é uma configuração que limita o tamanho dos segmentos TCP, o que evita a fragmentação dos pacotes TCP. Os sistemas operativos normalmente utilizam esta 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 um, totalizando 40 bytes. Uma interface com uma MTU de 1.500 tem um MSS de 1.460. O MSS é configurável.

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

Tenha em mente que os MTUs da origem e do destino não são os únicos fatores que determinam o valor do MSS. Dispositivos intermediários de rede, como gateways VPN, incluindo o Azure VPN Gateway, podem ajustar o MTU independentemente da origem e do destino para garantir um desempenho de rede ideal.

Descoberta do MTU de caminho

O MSS é negociado, mas pode não indicar o MSS real que pode ser utilizado. Outros dispositivos de rede no caminho entre a origem e o destino podem ter um valor de MTU menor do que a origem e o destino. Neste caso, o dispositivo cuja MTU é menor do que o pacote deixa cair o pacote. O dispositivo envia de volta uma mensagem ICMP Fragmentation Needed (Tipo 3, Código 4) que contém sua MTU. Esta mensagem ICMP permite que o host de origem reduza adequadamente o seu MTU do caminho. O processo é chamado Descoberta do MTU de Caminho (PMTUD).

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 permanecerá inconsciente da necessidade de reduzir o MSS e repetidamente retransmitirá o pacote. Por esse motivo, desaconselhamos o aumento da MTU da VM do Azure.

VPN e MTU

Se você usar VMs que executam encapsulamento (como VPNs IPsec), há algumas outras considerações sobre o tamanho do pacote e 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 que defina o ajuste de TCP MSS para 1.350 bytes e o MTU da interface de túnel para 1.400. Para mais informações, consulte a página de dispositivos VPN e parâmetros IPsec/IKE.

Latência, tempo de ida e volta, e escalonamento de janela TCP

Latência e tempo de ida e volta

A velocidade da luz determina a latência da rede através de uma rede de fibra ótica. O tempo de ida e volta (RTT) entre dois dispositivos de rede controla a taxa de transferência da rede TCP.

Rota	Distância	Tempo unidirecional	RTT
De Nova Iorque para São Francisco	4.148 quilômetros	21 ms	42 ms
Nova Iorque para Londres	5.585 quilômetros	28 ms	56 ms
Nova Iorque para Sydney	15.993 quilômetros	80 ms	160 ms

Esta tabela mostra a distância em linha reta entre dois locais. Nas redes, a distância é tipicamente maior do que a distância em linha reta. Aqui está uma fórmula simples para calcular o RTT mínimo, conforme rege a velocidade da luz:

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

Pode usar 200 para a velocidade de propagação. A velocidade de propagação é a distância, em quilómetros, que a luz percorre em 1 milissegundo.

Tomemos Nova Iorque para São Francisco como exemplo. A distância em linha reta é de 4.148 km. A introdução desse valor na equação resulta na seguinte equação:

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

A saída da equação é em milissegundos.

Se quiser obter o melhor desempenho da rede, a opção lógica é selecionar destinos com a menor distância entre eles. Deve também desenhar a sua rede virtual para otimizar o percurso do tráfego e reduzir a latência. Para mais informações, consulte a secção "Considerações sobre o design da rede" deste artigo.

Efeitos da latência e do tempo de ida e volta no TCP

O tempo de ida e volta tem um efeito direto no débito máximo do TCP. No protocolo TCP, o tamanho da janela é a quantidade máxima de tráfego que pode ser enviada através de uma conexão TCP antes que o remetente precise receber a confirmação do recetor. Se o TCP MSS 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 recetor. Se o remetente não receber a 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 de "aguardando reconhecimento", 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 espera pela confirmação, mais tempo ele precisa esperar antes de enviar mais dados.

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

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

Esta tabela mostra o máximo de megabytes por segundo em termos de capacidade de uma única ligação TCP. (Para facilitar a leitura, é usado o megabytes como unidade de medida.)

Tamanho da janela TCP (bytes)	Latência RTT (ms)	Máximo rendimento em megabytes/segundo	Capacidade máxima de megabit/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	cento e vinte	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.

Redimensionamento da janela TCP

O dimensionamento de janelas 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 que uma confirmação fosse necessária. Se você aumentar o número de pacotes que podem ser enviados antes que uma confirmação seja necessária, estará reduzindo o número de vezes que um remetente está aguardando confirmação.

Esta tabela ilustra essas relações.

Tamanho da janela TCP (bytes)	Latência RTT (ms)	Máximo rendimento em megabytes/segundo	Capacidade máxima de megabit/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

O valor do cabeçalho TCP para o tamanho da janela TCP tem apenas 2 bytes, o que significa que o valor máximo para uma janela de receção é 65,535. Para aumentar o tamanho máximo da janela, foi introduzido um fator de escala de janela TCP.

O fator de escala é também uma configuração que pode ser ajustada num sistema operativo. Eis a fórmula para calcular o tamanho da janela TCP usando fatores de escala:

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

Aqui está o cálculo para um fator de escala de janela de 3 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 da janela TCP de 14 (o deslocamento máximo permitido). O tamanho da janela TCP é 1.073.725.440 bytes (8,5 gigabits).

Suporte para ampliação de janela TCP

O Windows pode definir diferentes fatores de escala para diferentes tipos de ligação. (As classes de ligações incluem datacenter, internet, e assim por diante.) Pode usar o comando Get-NetTCPConnection PowerShell para visualizar o tipo de ligação de escala de janela:

Get-NetTCPConnection

Pode usar o comando Get-NetTCPSetting PowerShell para ver os valores de cada classe.

Get-NetTCPSetting

Pode definir o tamanho inicial da janela TCP e o fator de escala TCP no Windows utilizando o comando PowerShell Set-NetTCPSetting. Para mais informações, veja Set-NetTCPSetting.

Set-NetTCPSetting

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

Nível de Autoajuste	Fator de escala	Multiplicador de escala	Fórmula to calcular o tamanho máximo da janela
Desativado	Nenhum	Nenhum	Tamanho da janela
Restrito	4	2^4	Tamanho da janela * (2^4)
Altamente restrito	2	2^2	Tamanho da janela * (2^2)
Normal	8	2^8	Tamanho da janela * (2^8)
Experimentais	14	2^14	Tamanho da janela * (2^14)

Estas definições são as mais prováveis de afetar o desempenho do TCP, mas tenha em mente que muitos outros fatores na internet, fora do controle da Azure, também podem afetar o desempenho do TCP.

Rede acelerada e distribuição do processamento de receção

Rede acelerada

Historicamente, as funções de rede da máquina virtual consomem muita 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 da 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 afetem a taxa de transferência e a latência da rede. O Azure resolve este problema com redes aceleradas.

A rede acelerada oferece uma latência de rede ultrabaixa e consistente através do hardware programável interno da Azure e de tecnologias como SR-IOV. A rede acelerada desloca grande parte da pilha de rede definida por software do Azure dos CPUs para SmartNICs baseados 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 os desvios e a inconsistência na latência. Por outras palavras, o desempenho pode ser mais previsível.

A rede acelerada melhora o desempenho ao permitir que a VM convidada ignore o anfitrião e estabeleça um caminho de dados diretamente com o SmartNIC do anfitrião. Aqui estão alguns benefícios da rede acelerada:

Menor latência / maior número de pacotes por segundo (pps): Remover o switch virtual do caminho de dados elimina o tempo que os pacotes passam no host para o processamento de políticas e aumenta o número de pacotes que podem ser processados na VM.
Redução de jitter: O processamento do switch virtual depende da quantidade de políticas que precisam ser aplicadas e da carga de trabalho da CPU que está a realizar o processamento. Transferir a aplicação da política para o hardware elimina essa variabilidade ao enviar pacotes diretamente para a máquina virtual, eliminando a comunicação entre o anfitrião e a máquina virtual e todas as interrupções de software e trocas de contexto.
Redução na utilização da CPU: Contornar o switch virtual no host leva a uma menor utilização da CPU para o processamento do tráfego de rede.

Para utilizar a rede acelerada, é necessário ativá-la explicitamente em cada máquina virtual aplicável. Consulte Criar uma máquina virtual Linux com Rede Acelerada para instruções.

Escalonamento do lado de receção

Receive side scaling (RSS) é uma tecnologia de driver de rede que distribui a receção de tráfego de rede de forma mais eficiente, distribuindo o processamento de receção por múltiplas CPUs num sistema multiprocessador. Em termos simples, o RSS permite que um sistema processe mais tráfego recebido porque utiliza todos os CPUs disponíveis em vez de apenas um. Para uma discussão mais técnica sobre RSS, consulte Introduction to receive side scaling.

Para obter o melhor desempenho quando a rede acelerada está ativada numa VM, é necessário ativar o RSS. RSS também pode oferecer benefícios em VMs que não usam rede acelerada. Para obter uma visão geral sobre como determinar se o RSS está ativado e como ativá-lo, consulte Otimizar o rendimento da rede para máquinas virtuais do Azure.

TCP TIME_WAIT e assassinato de TIME_WAIT

A TIME_WAIT TCP é outra configuração comum que afeta o desempenho da rede e do aplicativo. Frequentemente, as VMs ocupadas abrem e fecham muitos soquetes, quer 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 que ele seja fechado. Como resultado, as pilhas TCP/IP normalmente impedem a reutilização do soquete descartando o pacote TCP SYN do cliente silenciosamente.

Você pode configurar quanto tempo um soquete permanece no estado TIME_WAIT. A duração pode variar de 30 segundos a 240 segundos. Os 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 os 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 do intervalo de portas para soquetes de saída é configurável dentro da pilha TCP/IP de um sistema operacional. O mesmo se aplica às definições de TCP TIME_WAIT e à reutilização de sockets. Alterar estes números pode potencialmente melhorar a escalabilidade. No entanto, dependendo da situação, essas alterações podem causar problemas de interoperabilidade. Deve ter cuidado se alterar estes valores.

Pode usar a técnica de eliminação no estado TIME_WAIT para resolver esta limitação de escalonamento. A técnica de assassinato TIME_WAIT permite que um socket seja reutilizado em certas 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 operativo permite que a nova conexão seja estabelecida (ele aceita o novo SYN/ACK) e força o encerramento da conexão anterior que estava em estado de TIME_WAIT. Esta capacidade é suportada em VMs Windows no Azure. Para saber mais sobre suporte em outras VMs, consulte o fornecedor do sistema operativo.

Para saber mais sobre a configuração das definições TCP TIME_WAIT e do 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

Largura de banda 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 capacidades é a taxa de transferência da rede (ou largura de banda), que é medida em megabits por segundo (Mbps). Como as máquinas virtuais são hospedadas em hardware compartilhado, a capacidade de rede precisa ser distribuída de forma justa entre as máquinas virtuais que utilizam o mesmo hardware. Máquinas virtuais maiores recebem mais largura de banda do 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 sai da máquina virtual é contabilizado 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 for destinado a outra máquina virtual na mesma rede virtual ou fora do Azure.

O ingresso não é medido ou limitado diretamente. No entanto, existem outros fatores, como os limites de CPU e armazenamento, que podem afetar a capacidade de uma máquina virtual de processar dados recebidos.

A rede acelerada é projetada para melhorar o desempenho da rede, incluindo latência, capacidade de transferência e utilização da CPU. A rede acelerada pode melhorar a capacidade de processamento de uma máquina virtual, mas só consegue fazê-lo até ao limite da largura de banda atribuída à máquina virtual.

As máquinas virtuais do Azure têm pelo menos uma interface de rede ligada a elas. Eles podem ter vários. A largura de banda atribuída a uma máquina virtual é a soma de todo o tráfego de saída através de todas as interfaces de rede ligadas à máquina. Por outras palavras, a largura de banda é alocada por máquina virtual, independentemente de quantas interfaces de rede estejam ligadas à máquina.

O esperado rendimento de saída e o número de interfaces de rede suportadas por cada tamanho de VM são detalhados em Tamanhos para máquinas virtuais Windows no Azure. Para ver o máximo de débito, selecione um tipo, como Uso geral, e depois encontre 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 as especificações de rede na última coluna, que tem o título "NICs Máximas / Largura de Banda de Rede Esperada (Mbps)."

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

Número de interfaces de rede: O limite de largura de banda aplica-se à soma de todo o tráfego de saída da máquina virtual.
Rede acelerada: Embora esta funcionalidade possa ser útil para atingir o limite publicado, não altera o limite.
Destino de tráfego: Todos os destinos contribuem para o limite de saída.
Protocolo: Todo o tráfego de saída em todos os protocolos conta para o limite.

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

Otimização de máquinas virtuais (VMs) Linux

Os kernels Linux modernos têm recursos que podem ajudar a alcançar consistência e desempenho, às vezes exigidos por certas cargas de trabalho.

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

Considerações sobre o desempenho da Internet

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

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

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

Considerações sobre o design da rede

Juntamente com as considerações discutidas anteriormente neste artigo, a topologia de uma rede virtual pode afetar o desempenho da rede. Por exemplo, um design hub-and-spoke que redireciona o tráfego em escala global para uma rede virtual com um único ponto central introduz latência de rede, o que afeta o desempenho geral da rede.

O número de dispositivos de rede pelos quais o tráfego de rede passa também pode afetar a latência geral. Em um design hub-and-spoke, se o tráfego passar por um dispositivo virtual de rede spoke e um dispositivo virtual de hub antes de transitar para a Internet, os dispositivos virtuais de rede introduzirão alguma latência.

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

As regiões do Azure são compostas por múltiplos centros de dados que existem dentro de uma área geográfica geral. Esses centros de dados podem não estar fisicamente próximos uns dos outros. Em alguns casos, eles estão separados por até 10 quilômetros. A rede virtual é uma sobreposição lógica sobre a rede física do centro de dados da Azure. Uma rede virtual não implica qualquer topologia de rede específica dentro do centro de dados.

Por exemplo, duas máquinas virtuais que estão na mesma rede virtual e sub-rede podem estar em racks, filas ou até mesmo centros de dados diferentes. Eles podem ser separados por pés de cabo de fibra ótica ou por quilômetros de cabo de fibra ótica. Esta variação pode introduzir latência variável (diferença de alguns milissegundos) entre diferentes Máquinas Virtuais.

O posicionamento geográfico das VMs e a latência resultante potencial entre duas VMs é influenciado pela configuração de conjuntos de disponibilidade, grupos de posicionamento de proximidade e zonas de disponibilidade. No entanto, a distância entre os centros de dados numa região é específica da região e é principalmente influenciada pela topologia dos centros de dados na região.

Exaustão de portas NAT de origem

Uma implementação no Azure pode comunicar-se com endpoints fora do Azure na internet pública e/ou no espaço de IP público. Quando uma instância inicia uma ligação de saída, o Azure mapeia dinamicamente o endereço IP privado para um endereço IP público. Após a Azure criar este mapeamento, o tráfego de retorno para o fluxo de origem de saída também pode alcançar o endereço IP privado onde o fluxo se originou.

Para cada ligação de saída, o Load Balancer do Azure precisa manter este mapeamento por algum período de tempo. Devido à natureza de múltiplos inquilinos do Azure, manter este mapeamento para cada fluxo de saída de cada VM pode consumir muitos recursos. Existem limites que são 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 são atingidos, a VM não faz mais conexões de saída.

Este comportamento é configurável. Para mais informações sobre SNAT e exaustão de portas SNAT, consulte este artigo.

Medir o desempenho da rede no Azure

Muitos dos máximos de desempenho neste artigo estão relacionados à latência de rede / tempo de ida e volta (RTT) entre duas VMs. Esta secçã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 VMs. Pode ajustar e testar o desempenho dos valores de TCP/IP e rede discutidos anteriormente utilizando as técnicas descritas nesta seção. Insira valores de latência, MTU, MSS e tamanho de 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 fortemente de RTT e perda de pacotes. O utilitário PING disponível no Windows e Linux oferece a maneira mais fácil de medir o RTT e a perda de pacotes. A saída de PING mostra a latência mínima/máxima/média entre uma origem e um destino. Ele mostra a perda de pacotes. PING usa o protocolo ICMP por padrão. Pode utilizar o PsPing para testar o RTT TCP. Para mais informações, consulte PsPing.

Os pings ICMP e TCP não medem o datapath de rede acelerada. Para medir o caminho de dados, leia sobre Latte e SockPerf neste 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 orientações.

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

Detetar comportamentos ineficientes de TCP

Em capturas de pacotes, os clientes da Azure podem ver pacotes TCP com flags TCP (SACK, DUP ACK, RETRANSMIT e FAST RETRANSMIT) que podem indicar problemas de desempenho da rede. Estes pacotes indicam especificamente ineficiências na rede que resultam de perdas de pacotes. Mas a perda de pacotes não é necessariamente causada por problemas de desempenho do Azure. Problemas de desempenho podem ser o resultado de aplicações, sistema operativo ou outros problemas que podem não estar diretamente relacionados com a plataforma Azure.

Além disso, tenha em mente que algumas retransmissões e ACKs duplicados são normais numa rede. Os protocolos TCP foram criados para serem fiáveis. Evidências desses pacotes TCP em uma captura de pacotes não indicam necessariamente um problema sistémico na rede, a menos que sejam excessivas.

Ainda assim, estes tipos de pacotes são indicações de que o rendimento do TCP não está a alcançar o seu máximo desempenho, por razões discutidas noutras secções deste artigo.

Próximos passos

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.