Diagnóstico de Lentidão de Rede com iperf3: Do Cliente ao Servidor

✎ Duarte Spínola  |  2026-07-12

O utilizador liga-se ao servidor e tudo está lento. O ficheiro que demorava 10 segundos a transferir agora demora 5 minutos. O RDP está com lag. A replicação da base de dados não termina. O primeiro reflexo é culpar o servidor — mas na maioria dos casos o problema está na rede entre o cliente e o servidor. O iperf3 é a ferramenta definitiva para medir o throughput real entre dois pontos, isolar o problema à camada de rede, e identificar se o gargalo é bandwidth, latência, packet loss, MTU ou configuração TCP. Referência: iperf.fr — documentação oficial.

O iperf3 mede o throughput entre dois pontos — mas não diz onde o problema está no caminho. Para localizar o salto problemático, combinar com mtr (ver secção 7). Para validar se o problema é de rede ou de aplicação, usar iperf3 primeiro e depois comparar com a velocidade da aplicação.

1. O que Está Lento — Camadas de Diagnóstico

A lentidão de acesso a um servidor pode ter origem em cinco camadas. Antes de testar com iperf3, identificar qual camada está afectada.

Camada Sintoma Ferramenta de diagnóstico
DNS Nome demora a resolver, depois é rápido dig, nslookup, Resolve-DnsName
Rede (bandwidth) Transferência lenta mas latência baixa iperf3 (TCP throughput)
Rede (latência/jitter) RDP lag, VOIP mau, SSH lento iperf3 (UDP), ping, mtr
Rede (packet loss) Conexões cortadas, retransmissões iperf3 (UDP), mtr, Wireshark
Rede (MTU/MSS) Transferências grandes falham, pequenas OK ping -f -l, iperf3 -M
Servidor (CPU/RAM/IO) Rede OK mas aplicação lenta PerfMon, top, iostat
Aplicação Rede e servidor OK mas app lenta Profiler, logs da aplicação

O iperf3 diagnostica as camadas de rede (bandwidth, latência, jitter, packet loss, MTU). Se o iperf3 mostra throughput normal, o problema está no servidor ou na aplicação.

2. Instalar iperf3

2.1 Linux (Debian/Ubuntu)

sudo apt update
sudo apt install iperf3

2.2 Linux (RHEL/Fedora/Rocky)

sudo dnf install iperf3

2.3 Windows

Descarregar de iperf.fr — extrair o .zip e executar iperf3.exe a partir da linha de comandos. Não requer instalação.

2.4 macOS

brew install iperf3

3. Teste Básico — TCP Throughput

O iperf3 funciona em modo cliente/servidor. Primeiro iniciar o servidor num dos pontos (normalmente o servidor de destino), depois correr o cliente a partir do outro ponto (o PC do utilizador).

3.1 Iniciar o servidor (no servidor de destino)

# Iniciar servidor iperf3 na porta padrão (5201)
iperf3 -s

# Ou numa porta específica
iperf3 -s -p 5201

# Em background com timeout
iperf3 -s -D –one-off

3.2 Correr o cliente (no PC do utilizador)

# Teste TCP básico — 10 segundos
iperf3 -c 192.168.1.100

# Especificar duração (60 segundos para resultado mais estável)
iperf3 -c 192.168.1.100 -t 60

# Especificar porta (se o servidor usa porta diferente)
iperf3 -c 192.168.1.100 -p 5201

# Output em JSON (para processamento automático)
iperf3 -c 192.168.1.100 -J

3.3 Interpretar o resultado

Connecting to host 192.168.1.100, port 5201
[ 5] local 192.168.1.50 port 49152 connected to 192.168.1.100 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 112 MBytes 940 Mbits/sec 0 256 KBytes
[ 5] 1.00-2.00 sec 112 MBytes 940 Mbits/sec 0 256 KBytes
[ 5] 2.00-3.00 sec 112 MBytes 940 Mbits/sec 0 256 KBytes
– – – – – – – – – – – – – – – – – – – – – – – – –
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.10 GBytes 940 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 1.10 GBytes 940 Mbits/sec receiver

Colunas importantes:

Coluna Significado Atenção se…
Transfer Bytes transferidos no intervalo Menor que o esperado
Bitrate Velocidade (bits por segundo) Menor que a largura de banda contratada
Retr Retransmissões TCP >0 indica packet loss ou congestionamento
Cwnd TCP congestion window Pequeno e não cresce = congestionamento

3.4 O que é um resultado “bom”

Ligação Throughput esperado (iperf3 TCP)
Ethernet 1 Gbps 900-940 Mbps
Ethernet 10 Gbps 8-9.4 Gbps
Wi-Fi 6 (ax) 500-1200 Mbps
Wi-Fi 5 (ac) 200-600 Mbps
Fibra 200 Mbps (WAN) 180-195 Mbps
VPN site-to-site 50-80% da largura de banda
WAN com CGNAT Variável, tipicamente inferior

Se o iperf3 mostra 900+ Mbps numa ligação local de 1 Gbps, a rede está saudável. Se mostra 50 Mbps numa ligação de 1 Gbps, há um problema.

4. Teste UDP — Latência, Jitter e Packet Loss

O modo TCP mede throughput mas não mostra latência nem packet loss directamente. O modo UDP mede这三 três métricas simultaneamente.

# Teste UDP com 100 Mbps durante 30 segundos
iperf3 -c 192.168.1.100 -u -b 100M -t 30

# Teste UDP com 1 Gbps (para detectar packet loss em ligações rápidas)
iperf3 -c 192.168.1.100 -u -b 1G -t 30

# Teste UDP bidireccional (upload e download simultâneos)
iperf3 -c 192.168.1.100 -u -b 100M -t 30 –bidir

Output:

[ 5] 0.00-10.00 sec 119 MBytes 100 Mbits/sec 0.023 ms 0/84952 (0%) sender
[ 5] 0.00-10.00 sec 119 MBytes 99.8 Mbits/sec 0.025 ms 0/84996 (0.04%) receiver
Métrica Significado Valor aceitável Problema se…
Bitrate Throughput UDP Próximo do -b especificado Significativamente inferior ao pedido
Jitter Variação de latência entre pacotes <5 ms (LAN), <30 ms (WAN) >50 ms causa problemas em VOIP/VDI
Lost/Total Pacotes perdidos 0% (ideal), <0.1% >1% indica problema de rede
% Percentagem de packet loss 0% >1% é inaceitável para produção

Interpretação de packet loss

Packet loss Impacto Causa provável
0% Nenhum Rede saudável
0.01-0.1% Negligenciável Evento transitório
0.1-1% Atenção Congestionamento, buffer small
1-5% Problema sério Congestionamento, cabo mau, switch faulty
>5% Crítico Cabo danificado, duplex mismatch, interference

5. Testes Avançados para Isolar o Problema

5.1 Teste bidireccional (upload vs download)

Muitas vezes o download está bom mas o upload está lento (ou vice-versa). Testar ambos:

# Download do servidor para o cliente (reversed)
iperf3 -c 192.168.1.100 -R -t 30

# Upload do cliente para o servidor (normal)
iperf3 -c 192.168.1.100 -t 30

# Bidireccional simultâneo
iperf3 -c 192.168.1.100 –bidir -t 30

Se o upload é 900 Mbps e o download é 50 Mbps (ou vice-versa), há um problema de duplex ou QoS que afecta apenas uma direcção.

5.2 Teste com múltiplas ligações paralelas

Uma única ligação TCP pode não conseguir saturar uma ligação de alta velocidade devido ao TCP window size. Usar ligações paralelas:

# 8 ligações paralelas — útil para ligações >1 Gbps ou WAN com latência alta
iperf3 -c 192.168.1.100 -P 8 -t 30

Se uma ligação atinge 50 Mbps mas 8 ligações paralelas atingem 800 Mbps, o problema é TCP window size ou latência alta (ver secção 6).

5.3 Teste com tamanhos de janela diferentes

O TCP window size determina quanta data não confirmada o remetente pode enviar. Em ligações de alta latência, um window pequeno limita o throughput.

# Window de 256 KB (útil em WAN com latência alta)
iperf3 -c 192.168.1.100 -w 256K -t 30

# Window de 1 MB
iperf3 -c 192.168.1.100 -w 1M -t 30

# Window automático (deixar o TCP decidir)
iperf3 -c 192.168.1.100 -t 30

5.4 Teste com diferentes tamanhos de pacote (MTU)

Problemas de MTU causam lentidão em transferências grandes mas não em pequenas (o small packet passa mas o large packet fragmenta ou é dropped).

# Testar com MSS de 1400 (MTU ~1440) — detecta problemas de PMTU
iperf3 -c 192.168.1.100 -M 1400 -t 30

# Comparar com MSS padrão (1460 = MTU 1500)
iperf3 -c 192.168.1.100 -M 1460 -t 30

Se o throughput com MSS 1400 é significativamente melhor que com MSS 1460, há um problema de MTU/PMTU no caminho.

6. Tuning TCP para Diagnóstico

Quando o iperf3 mostra throughput baixo numa ligação de alta velocidade e baixa latência, o problema pode ser configuração TCP do sistema operativo.

6.1 Verificar BDP (Bandwidth-Delay Product)

O BDP determina o TCP window necessário para saturar uma ligação:

BDP = bandwidth × RTT

Exemplo: 1 Gbps × 10ms RTT
BDP = 1,000,000,000 × 0.01 = 10,000,000 bits = 1.25 MB

O TCP window deve ser pelo menos igual ao BDP. Se for menor, o throughput será limitado.

# Em Linux, verificar configuração TCP actual
sysctl net.ipv4.tcp_window_scaling
sysctl net.ipv4.tcp_rmem
sysctl net.ipv4.tcp_wmem

# Activar TCP window scaling (se desactivado)
sudo sysctl -w net.ipv4.tcp_window_scaling=1

# Ajustar buffers de leitura/escrita TCP
sudo sysctl -w net.ipv4.tcp_rmem=’4096 87380 16777216′
sudo sysctl -w net.ipv4.tcp_wmem=’4096 65536 16777216′

6.2 Activar BBR congestion control (Linux 4.9+)

O BBR (Bottleneck Bandwidth and Round-trip propagation time) é um algoritmo de congestion control do Google que melhora significativamente o throughput em ligações WAN.

# Verificar algoritmo actual
sysctl net.ipv4.tcp_congestion_control

# Activar BBR
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr

# Verificar
sysctl net.ipv4.tcp_congestion_control
# Output esperado: net.ipv4.tcp_congestion_control = bbr

6.3 Em Windows

# Verificar configuração TCP
Get-NetTCPSetting | Select SettingName, AutoTuningLevelLocal

# Activar auto-tuning (se desactivado)
Set-NetTCPSetting -SettingName Internet -AutoTuningLevelLocal Normal

# Verificar MTU
netsh interface ipv4 show subinterfaces

# Alterar MTU (se necessário)
netsh interface ipv4 set subinterface “Ethernet” mtu=1500 store=persistent

7. Combinar iperf3 com Outras Ferramentas

O iperf3 mede o throughput entre dois pontos. Para localizar onde o problema está no caminho, usar:

7.1 mtr — Traceroute em tempo real

O mtr combina traceroute com ping, mostrando latência e packet loss por salto.

# mtr durante 100 ciclos (para estatística fiável)
mtr -c 100 –report 192.168.1.100

# Output:
# Host Loss% Snt Last Avg Best Wrst StDev
# 1. 192.168.1.1 0.0% 100 0.5 0.5 0.4 0.8 0.1
# 2. 10.0.0.1 0.0% 100 2.1 2.0 1.8 2.5 0.1
# 3. 192.168.1.100 20.0% 100 5.0 5.2 4.8 6.0 0.3

Se o salto 3 tem 20% packet loss mas o salto 2 tem 0%, o problema está entre o salto 2 e o salto 3. Referência: mtr.tools.

7.2 ping — Latência base

# Ping com 100 pacotes para estatística
ping -c 100 192.168.1.100

# Windows — tamanho específico para testar MTU
ping -f -l 1472 192.168.1.100
# Se falhar, tentar 1400, 1300, até encontrar o maior que passa

7.3 PSPing — Alternativa Microsoft

O PSPing (Sysinternals) faz ping TCP (não apenas ICMP) e throughput testing. Útil quando ICMP é bloqueado por firewall.

# Ping TCP à porta do servidor
psping -t 192.168.1.100:445

# Teste de throughput TCP (como iperf3)
psping -b -l 8k -n 10000 192.168.1.100:445

7.4 Wireshark — Análise de pacotes

Se o iperf3 mostra retransmissões, o Wireshark pode identificar o tipo exacto de problema:

Filtros úteis:
tcp.analysis.retransmission — retransmissões TCP
tcp.analysis.fast_retransmission — fast retransmit (3 duplicate ACKs)
tcp.analysis.duplicate_ack — duplicate ACKs (indica packet loss)
tcp.analysis.zero_window — receiver não consegue acompanhar
icmp.type == 3 && icmp.code == 4 — ICMP Fragmentation Needed (PMTU problem)

8. Cenários Comuns de Diagnóstico

Cenário 1: WAN lenta (VPN site-to-site)

Sintoma: VPN entre escritório e datacenter a 20 Mbps em vez de 100 Mbps.

# 1. iperf3 TCP sem VPN (baseline)
iperf3 -c 192.168.1.100 -t 30
# Resultado: 940 Mbps (LAN directa OK)

# 2. iperf3 TCP através da VPN
iperf3 -c 10.10.10.100 -t 30
# Resultado: 20 Mbps (VPN é o bottleneck)

# 3. iperf3 UDP para ver packet loss
iperf3 -c 10.10.10.100 -u -b 100M -t 30
# Resultado: 18 Mbps, 5% packet loss, 45ms jitter

# 4. mtr para localizar o salto problemático
mtr -c 100 –report 10.10.10.100
# Resultado: salto 4 (VPN gateway remoto) tem 5% loss

# Conclusão: VPN gateway remoto está a dropping packets.
# Acção: verificar CPU do VPN gateway, MTU da VPN tunnel (reduzir para 1400)

Cenário 2: Transferência de ficheiros lenta

Sintoma: SMB copy a 5 MB/s em ligação de 1 Gbps.

# 1. iperf3 TCP (testar rede isolada de SMB)
iperf3 -c 192.168.1.100 -t 30
# Resultado: 940 Mbps (rede OK)

# 2. PSPing TCP à porta 445 (SMB)
psping -t 192.168.1.100:445
# Resultado: 20ms latency (esperado <1ms em LAN)

# 3. iperf3 com ligações paralelas (testar SMB multichannel)
iperf3 -c 192.168.1.100 -P 4 -t 30
# Resultado: 4 × 940 Mbps = 3.7 Gbps

# Conclusão: rede OK, problema é SMB.
# Acção: verificar SMB version (SMB1 é lento), SMB signing, e antivirus a scanar tráfego

Cenário 3: RDP lag em WAN

Sintoma: RDP para servidor remoto com lag e cortes.

# 1. Ping para baseline de latência
ping -c 100 servidorremoto.exemplo.pt
# Resultado: avg 35ms, 0% loss (latência OK para RDP)

# 2. iperf3 UDP para jitter
iperf3 -c servidorremoto -u -b 10M -t 60
# Resultado: 8 Mbps, 15ms jitter, 2% loss

# Conclusão: packet loss e jitter causam lag no RDP.
# Acção: verificar QoS no router, priorizar RDP (UDP 3389 em 2022+)

Cenário 4: MTU / Fragmentação

Sintoma: Transferências pequenas OK, transferências grandes timeout.

# 1. iperf3 TCP normal
iperf3 -c 192.168.1.100 -t 10
# Resultado: 940 Mbps (OK com pacotes pequenos)

# 2. iperf3 com MSS grande (forçar pacotes grandes)
iperf3 -c 192.168.1.100 -M 1460 -t 30
# Resultado: 50 Mbps, muitas retransmissões

# 3. iperf3 com MSS pequeno
iperf3 -c 192.168.1.100 -M 1300 -t 30
# Resultado: 940 Mbps (OK)

# Conclusão: MTU problem no caminho.
# Acção: verificar PMTU, reduzir MTU na interface ou tunnel

9. Erros Comuns a Evitar

  • Testar com apenas 10 segundos — em ligações WAN com latência alta, 10 segundos não é suficiente para o TCP window crescer. Usar -t 60 no mínimo.
  • Esquecer de testar UDP — TCP esconde packet loss através de retransmissões. Só o UDP mostra o packet loss real.
  • Correr iperf3 em horas de pico — o throughput vai ser afectado por outro tráfego. Testar fora de horas de pico para obter baseline.
  • Não testar em ambos os sentidos — muitas vezes só se testa upload. Usar -R para testar download e --bidir para ambos.
  • Confiar apenas no iperf3 — o iperf3 mede a rede entre dois pontos. Se o problema é DNS, aplicação, ou servidor, o iperf3 não detecta.
  • Correr servidor iperf3 sem firewall — o iperf3 -s abre a porta 5201 a toda a rede. Restringir com firewall: iptables -A INPUT -p tcp --dport 5201 -s 192.168.1.0/24 -j ACCEPT.
  • Usar iperf (v2) em vez de iperf3 — o iperf2 é a versão antiga. iperf3 tem melhores features (JSON output, UDP bidir, múltiplas ligações paralelas).
  • Ignorar retransmissões — se o iperf3 mostra 940 Mbps mas com 500 retransmissões, a rede não está saudável. Investigar o packet loss com mtr.

10. Checklist de Diagnóstico

  1. Identificar a camada — DNS, rede, servidor ou aplicação (tabela da secção 1)
  2. Instalar iperf3 em cliente e servidor
  3. Iniciar servidor — iperf3 -s no servidor de destino
  4. Teste TCP — iperf3 -c <IP> -t 60 para throughput base
  5. Verificar retransmissões — coluna Retr no output
  6. Teste UDP — iperf3 -c <IP> -u -b <bandwidth> -t 30 para jitter e packet loss
  7. Teste bidireccional — iperf3 -c <IP> -R para download, iperf3 -c <IP> para upload
  8. Teste paralelo — iperf3 -c <IP> -P 8 se uma ligação não satura a largura de banda
  9. Teste MTU — iperf3 -c <IP> -M 1400 vs -M 1460 para detectar fragmentação
  10. mtr — mtr -c 100 --report <IP> para localizar o salto problemático
  11. PSPing (Windows) — psping <IP>:<porta> para latência TCP se ICMP bloqueado
  12. Wireshark — se packet loss detectado, captura para analisar o tipo de problema
  13. Acção — baseado no diagnóstico, aplicar a correção (QoS, MTU, VPN tuning, BBR, etc.)

11. Artigos Relacionados