Optimização TCP/IP no Windows Server por Carga de Trabalho: Guia 2026

A stack TCP/IP do Windows Server evoluiu significativamente, mas raramente as definições padrão são ideais para todos os cenários. Este guia explica como optimizar o TCP/IP por tipo de carga de trabalho — servidor de ficheiros, IIS, SQL Server, Hyper-V e backup — com base na documentação oficial da Microsoft sobre desempenho TCP/IP.

1. Introdução

A desempenho TCP/IP no Windows Server não é um valor absoluto — é uma comparação. Deve ser medida com endpoints idênticos (hardware, rede e sistema operativo) para produzir resultados significativos. A Microsoft publica uma série de três artigos sobre o tema: Overview, Underlying Network Issues e Known Issues.

Cada tipo de carga de trabalho coloca exigências diferentes na stack de rede. Um servidor de ficheiros beneficia de jumbo frames e RSC; um servidor web precisa de TCP autotuning e limites de ligações; um hospedeiro Hyper-V deve activar VMQ em vez de RSS. Aplicar configurações genéricas sem considerar a carga de trabalho resulta em sub-utilização da largura de banda ou em instabilidade.

Este guia cobre os três pilares da optimização: TCP Receive Window Autotuning, algoritmos de congestão, e capacidades avançadas da NIC (RSS, VMQ, RSC, offloads, jumbo frames), culminando numa tabela de recomendações por carga de trabalho.

2. TCP Receive Window Autotuning

O TCP Receive Window Autotuning escala automaticamente a janela de recepção TCP para maximizar a utilização da largura de banda em redes de alta latência. Sem autotuning, a janela é fixa e pequena, limitando o taxa de transferência em ligações com BDP (Bandwidth-Delay Product) elevado.

Existem cinco níveis de autotuning, do mais conservador ao mais agressivo:

Para verificar o nível actual:

netsh int tcp show global

Para definir como normal (recomendado):

netsh int tcp set global autotuninglevel=normal

Alternativamente via PowerShell:

Get-NetTCPSetting | Format-List SettingName,Autotuninglevel*
Get-NetTCPSetting | Set-NetTCPSetting -AutoTuningLevelLocal Normal

3. Algoritmos de Congestão

O algoritmo de congestão determina como o TCP calcula o BDP (Bandwidth-Delay Product) e escala a janela de congestão. O Windows Server suporta vários algoritmos, cada um com características próprias:

CUBIC — algoritmo padrão no Windows Server moderno, optimizado para redes de alta largura de banda e alta latência. Usa uma função cúbica para ajustar a janela, permitindo recuperação mais rápida após perda de pacotes.

NewReno — algoritmo clássico, adequado para redes com perda de pacotes moderada. Melhora o Reno original ao lidar com múltiplas perdas na mesma janela.

Compound TCP (CTCP) — combina um algoritmo baseado em atraso com um baseado em perda, mantendo uma janela de congestão paralela. Eficaz em redes de alto BDP onde CUBIC pode ser conservador.

Para verificar as definições TCP via PowerShell:

Get-NetTCPSetting | Format-List SettingName,CongestionProvider*

Para visualizar ligações TCP activas:

Get-NetTCPConnection | Format-Table LocalAddress,LocalPort,RemoteAddress,RemotePort,State

4. RSS, VMQ e RSC

Em servidores multi-core, o processamento de interrupções de rede num único núcleo cria um gargalo. Três tecnologias resolvem este problema em contextos diferentes:

Receive Side Scaling (RSS) — distribui o processamento de pacotes recebidos por múltiplos núcleos CPU. Essencial em servidores físicos com tráfego elevado. Sem RSS, todo o processamento cai num único núcleo (CPU 0 pico), limitando o taxa de transferência.

Virtual Machine Queue (VMQ) — equivalente ao RSS para hospedeiros Hyper-V. Em vez de distribuir por núcleos do host, distribui por filas atribuídas a VMs específicas. Num hospedeiro Hyper-V, deve usar-se VMQ em vez de RSS.

Receive Segment Coalescing (RSC) — combina múltiplos segmentos TCP recebidos num único segmento maior antes de os entregar ao OS. Reduz a sobrecarga de processamento de cabeçalhos, sendo particularmente eficaz em servidor de ficheiros e servidor de backups.

Activar RSS numa NIC física:

netsh int tcp set global rss=enabled
Set-NetAdapterRss -Name "Ethernet" -Enabled $True

Verificar propriedades RSS da NIC:

Get-NetAdapterAdvancedProperty | Where-Object -Property RegistryKeyword -Like *rss*

Activar RSC:

Set-NetAdapterRsc -Name "Ethernet" -Enabled $True
Get-NetAdapterOffload

5. NIC Offloads e Jumbo Frames

As capacidades de offload da NIC transferem processamento de rede da CPU para o hardware da placa de rede, reduzindo sobrecarga e libertando ciclos de CPU. As propriedades avançadas da NIC devem ser activadas sempre que a rede subjacente não apresentar perda de pacotes.

Large Send Offload (LSO) — permite que a NIC segmente pacotes TCP grandes em segmentos MTU-size, reduzindo o trabalho da CPU no envio.

Checksum Offload — a NIC calcula checksums TCP/IP em hardware, eliminando o cálculo por software para cada pacote.

Jumbo Frames — aumenta o MTU de 1500 para 9000 bytes, reduzindo o sobrecarga de cabeçalhos por payload. Requer suporte end-to-end (switches, routers, destino). Ideal para servidor de ficheiros e servidor de backups em redes isoladas.

Activar jumbo frames (frame size 9000):

Enable-NetAdapterJumboFrame -Name "Ethernet" -FrameSize 9000

Verificar offloads disponíveis:

Get-NetAdapterOffload | Format-List Name,LSO,VMMQ,IPsecOffload

6. Optimização por Carga de Trabalho

Cada carga de trabalho tem requisitos distintos. A tabela seguinte resume as recomendações para os cinco cenários mais comuns em Windows Server 2026:

Servidor de Ficheiros (SMB): Jumbo frames reduzem sobrecarga em transferências de ficheiros grandes. RSS distribui o processamento por núcleos. RSC funde segmentos, reduzindo interrupções.

Web Server (IIS): TCP autotuning normal é essencial — clientes têm latências variáveis. RSS é crítico devido ao elevado número de ligações concorrentes. Jumbo frames geralmente não aplicável (tráfego via Internet).

SQL Server: Combina RSS, RSC e jumbo frames para maximizar taxa de transferência em consultas que transferem grandes volumes de dados. TCP autotuning normal adapta-se a clientes com latências diferentes.

Hospedeiro Hyper-V: Usar VMQ em vez de RSS — VMQ distribui tráfego por filas atribuídas a VMs específicas. Se disponível, activar SR-IOV para bypass da stack de virtualização de rede.

Servidor de Backup: Maximizar taxa de transferência com jumbo frames, RSC, RSS e todos os offloads disponíveis. O tráfego de backup é predominantemente intra-centro de dados, onde a latência é baixa e a largura de banda é elevada.

7. Teste e Troubleshooting

Antes de optimizar, é fundamental estabelecer um linha de base — medir o taxa de transferência actual com ferramentas adequadas. A Microsoft recomenda duas ferramentas oficiais:

NTttcp.exe — ferramenta clássica para testes de taxa de transferência TCP, suportando múltiplas linhas de execução e ligações.

ctsTraffic.exe — ferramenta moderna com padrões de teste flexíveis. Exemplo de comando para 8 ligações em modo pull, 10 iterações:

# No servidor (listener)
ctsTraffic -listen:*

# No cliente (sender)
ctsTraffic -target:192.168.1.10 -pattern:pull -connections:8 -iterations:10

O Performance Monitor deve ser usado para identificar gargalos de CPU e armazenamento durante os testes. Se o taxa de transferência não escala, verificar primeiro CPU, depois disco, depois rede.

Os problemas conhecidos mais comuns e as suas soluções:

Para criar um linha de base de desempenho, seguir estes passos:

# 1. Verificar configuração TCP global
netsh int tcp show global

# 2. Verificar definições por perfil TCP
Get-NetTCPSetting | Format-List SettingName,Autotuninglevel*,CongestionProvider*

# 3. Verificar propriedades da NIC
Get-NetAdapterAdvancedProperty | Format-Table Name,DisplayName,DisplayValue
Get-NetAdapterOffload | Format-List Name,LSO,IPsecOffload
Get-NetAdapterRss | Format-List Name,Enabled,NumberOfReceiveQueues

# 4. Medir throughput com ctsTraffic (sem packet logs!)
ctsTraffic -target:192.168.1.10 -pattern:pull -connections:8 -iterations:10

# 5. Monitorizar CPU/storage durante os testes
perfmon /report

Os recursos de segurança devem ser configurados com base em requisitos reais. O IPsec adiciona sobrecarga a cada pacote — se for necessário, preferir o modo integrity em vez do modo protection para reduzir o impacto no taxa de transferência.

Artigos Relacionados

• Diagnóstico de Conectividade no Windows Server 2026
• Linux Server Hardening