Como os Pacotes Viajam na Internet: Handshake TCP/IP, Fragmentação MTU e Diagnósticos com mtr Explicados

A Realidade Física da Internet: Para Lá da Ilusão da Nuvem

Passamos grande parte da nossa vida de desenvolvimento no topo do modelo OSI. Escrevemos código em TypeScript, criamos resolvers de GraphQL, configuramos contentores Docker e gerimos ficheiros JSON. É tentador olhar para a rede como um tubo mágico perfeito onde os bits viajam de forma instantânea sem atrito.

Até ao dia em que um cliente num escritório em Lisboa ou no Porto avisa que o site fica com o ecrã em branco durante 30 segundos. Ou quando uma rota da tua API responde em milissegundos para pequenas consultas, mas bloqueia e dá timeout no momento em que tentas descarregar um ficheiro com mais de 1.400 bytes.

O MISTÉRIO DO SITE QUE CONGELA EM DADOS PESADOS

• Browser do Teu Cliente SYN (64 Bytes) → Servidor (OK)
• Browser do Teu Cliente → SYN-ACK (64 Bytes) Servidor (OK)
• Browser do Teu Cliente ACK (64 Bytes) → Servidor (OK)
• Browser do Teu Cliente GET /api/v1/user (Pedido Curto) → Servidor (OK)
• Browser do Teu Cliente → Resposta JSON (300 Bytes) Servidor (OK)
• Browser do Teu Cliente GET /api/v1/relatorio (Ficheiro) → Servidor
• O Servidor Envia um Pacote de 1500 Bytes (DF Ativo) → Router no Caminho
• O Router Descarta o Pacote! (Túnel tem MTU de 1420)
• O Router Tenta Enviar ICMP de Fragmentação → Bloqueado por uma Firewall!
• Resultado: A ligação fica congelada em silêncio até rebentar por timeout!

Para resolveres este tipo de avaria com autoridade técnica, tens de compreender a física dos pacotes: como o handshake em 3 passos do TCP sincroniza o estado, como o Maximum Transmission Unit (MTU) dita o tamanho dos blocos de dados e como falhas de Path MTU Discovery silenciam serviços na web.

Na nossa equipa desenhamos websites de alta performance e prestamos consultoria técnica que resolve estes estrangulamentos até ao nível do kernel no Debian GNU/Linux.

O Handshake TCP em Três Passos: Como Funciona e Porque Cria Latência

Antes de o navegador do teu utilizador poder enviar o primeiro byte de um pedido HTTP ou negociar certificados TLS 1.3, tem de estabelecer uma ligação de confiança com o servidor através do Three-Way Handshake.

O PROTOCOLO TCP THREE-WAY HANDSHAKE

• Browser do Cliente (ex: 198.51.100.12)
• O Teu Servidor (ex: 203.0.113.80)
• SYN (Seq = 1000, MSS = 1460, Opções SACK) → Estado: SYN-RCVD
• SYN-ACK (Seq = 5000, Ack = 1001, MSS = 1460)
• Estado: ESTABLISHED
• ACK (Seq = 1001, Ack = 5001) → Estado: ESTABLISHED
• LIGAÇÃO ESTABELECIDA (Perdeste 1 Ciclo RTT de Espera)
• Envio de Dados Reais / Início do TLS Handshake

O Que Acontece em Cada Passo:

1. SYN (Sincronização): O cliente gera um número inicial aleatório de sequência (Seq = 1000) e anuncia as capacidades da sua placa: o tamanho máximo de segmento (MSS = 1460) e suporte a confirmações seletivas (SACK).
2. SYN-ACK (Confirmação do Servidor): O teu servidor reserva espaço na memória, gera o seu próprio número de sequência (Seq = 5000) e confirma a receção do cliente somando 1 ao valor (Ack = 1001).
3. ACK (Confirmação Final): O cliente confirma a mensagem do servidor (Ack = 5001). Ambos os lados entram em estado ESTABLISHED.

Este processo demora uma volta completa de ida e volta na rede (Round-Trip Time ou RTT). Se o teu servidor estiver alojado na Alemanha e o teu cliente estiver em Portugal com uma latência de 45ms, o utilizador espera 45ms apenas para abrir o socket, mais 45ms para o handshake TLS, antes de ver qualquer letra no ecrã. É por isso que redes como a Cloudflare são tão valiosas para aproximar a terminação TCP dos teus visitantes.

MTU vs. MSS: A Anatomia Matemática de um Pacote Ethernet

Cada ligação de rede física impõe um limite máximo ao tamanho de cada pacote de dados que consegue transportar. Esse limite chama-se Maximum Transmission Unit (MTU).

Numa rede Ethernet vulgar, o valor padrão de MTU é de 1.500 bytes.

DIVISÃO INTERNA DE UM PACOTE ETHERNET Tamanho Total MTU da Trama Ethernet: 1.500 Bytes

• Cabeçalho IP (20 Bytes)
• Cabeçalho TCP (20 Bytes)
• Carga Útil de Dados TCP (MSS) (1.460 Bytes de Informação Real)

Quando adicionas tecnologias de encapsulamento—como túneis VPN em WireGuard, ligações de fibra PPPoE residenciais ou redes virtuais VXLAN na nuvem—o espaço útil encolhe:

• Rede Ethernet Comum: 1.500 bytes (MSS = 1.460 bytes)
• Ligações Fibra/ADSL com PPPoE: 1.492 bytes (MSS = 1.452 bytes)
• Túneis VPN com WireGuard: 1.420 bytes (MSS = 1.380 bytes)
• Redes Virtuais em Nuvem (AWS/GCP): 1.450 bytes (MSS = 1.410 bytes)

Se o teu servidor enviar um pacote de 1.500 bytes para dentro de um túnel WireGuard configurado para 1.420 bytes, o router terá de partir o pacote em dois ou descartá-lo. Como os servidores web modernos ativam a opção Don’t Fragment (DF) para não sobrecarregar o processador, o router deita o pacote fora e depende do mecanismo de Path MTU Discovery (PMTUD) para avisar o emissor.

O Desastre do Buraco Negro de PMTUD e a Correção com MSS Clamping

Quando um router intermédio deita fora um pacote que não cabe na linha, emite um pacote de aviso: ICMP Tipo 3, Código 4 (Fragmentação Necessária mas flag DF ativa). O sistema operativo do teu servidor recebe essa mensagem e baixa o MSS para essa ligação.

A catástrofe acontece quando administradores de redes paranoicos bloqueiam todo o tráfego ICMP nas firewalls, achando erradamente que “desligar o ping torna o servidor invisível”.

O DESASTRE DO BURACO NEGRO DE PACOTES ICMP

• O Teu Servidor (MTU 1500) → [Pacote: 1500B] → Router (Túnel MTU 1420)
• Pacote DESCARTADO!
• O Teu Servidor → [FIREWALL BLOQUEOU!] → ICMP Fragmentação Necessária
• Resultado: O teu servidor retransmite o pacote 5 vezes à espera de resposta, não recebe nada e a ligação morre por timeout. O teu cliente vê o site parado!

A Solução: MSS Clamping no Kernel Linux

Se geres routers ou firewalls em Linux, podes curar este problema de vez forçando o ajuste do MSS durante o handshake inicial com o nftables ou iptables:

# Ajusta automaticamente o MSS ao MTU do caminho com nftables
nft add table ip filter
nft add chain ip filter forward { type filter hook forward priority 0 \; }
nft add rule ip filter forward tcp flags syn tcp option maxseg size set rt mtu

# Ou usando o iptables clássico em servidores Debian:
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

Esta regra interceta os pacotes de abertura de ligação e reduz o valor anunciado do MSS de forma cirúrgica, impedindo que qualquer ponta tente enviar pacotes maiores do que o canal suporta.

Diagnóstico Real com o Utilitário mtr (My Traceroute)

Quando alguém se queixa de que a ligação está instável ou o site falha aleatoriamente, usar apenas o ping ou o traceroute não chega. O ping não te diz em que ponto da rota os pacotes se perdem e o traceroute envia apenas 3 sondas por salto, deixando escapar micro-perdas na linha.

A ferramenta obrigatória para qualquer administrador de sistemas é o mtr (My Traceroute), mantido no GitHub.

Como Fazer um Teste Diagnóstico Completo

Instala e corre o mtr em modo de relatório ao longo de 100 ciclos seguidos:

# Instala o mtr no teu Debian ou Ubuntu
apt update && apt install -y mtr-tiny

# Executa 100 sondas consecutivas sem resolução reversa de DNS
mtr --report --report-cycles 100 --no-dns 203.0.113.80

COMO INTERPRETAR O RELATÓRIO DO MTR

• Host: 1. 192.168.1.1 • 2. 10.0.0.1 • 3. 195.23.0.45 • 4. 84.16.12.9 • 5. 130.117.0.22 • 6. 198.51.100.1 • 7. 203.0.113.80
• Loss% Snt Last Avg Best Wrst StDev: 0.0% 100 0.8 0.9 0.6 2.1 0.3 • 0.0% 100 4.2 4.5 3.9 8.1 0.7 • 0.0% 100 12.1 12.4 11.8 16.5 1.1 • 65.0% 100 14.2 14.5 13.9 19.2 1.4 → (Apenas Rate Limit) • 0.0% 100 22.4 22.8 22.1 28.9 1.2 • 0.0% 100 24.1 24.5 23.8 31.2 1.5 • 0.0% 100 24.3 24.6 24.0 30.5 1.3

Como Ler os Dados Sem Cometer Erros de Amador:

• Repara no Salto 4: Apresenta 65.0% de pacotes perdidos. Um administrador inexperiente pensaria que a linha avariou ali. No entanto, repara nos saltos 5, 6 e 7: o destino final tem 0.0% de perda! O router no salto 4 está simplesmente a limitar a resposta a pacotes ICMP para poupar processamento, continuando a encaminhar o tráfego normal perfeitamente.
• Perda de Pacotes Verdadeira: Se o salto 4 apresentasse 20% de perda e essa perda se mantivesse nos saltos 5, 6 e 7, então terias identificado uma avaria real de hardware ou saturação de fibra nesse operador.

Ao dominares a física do TCP/IP, ganhas o poder de diagnosticar e resolver falhas de rede complexas que parecem problemas da aplicação. Apoiando a tua infraestrutura com o nosso serviço de alojamento gerido, garantes que os teus sites operam com parâmetros de rede perfeitos e estabilidade garantida.

No terreno, em conjunto com a experiência acumulada na Webxtek Studio, aplicamos exatamente estes padrões operacionais em setores exigentes como especialistas em devops e arquitetura cloud e provedores de cloud computing e iaas. Quando alinhas a tua estrutura através de websites de alta performance e consultoria técnica antes de construir, transformas boas práticas técnicas numa vantagem competitiva real e mensurável para o teu negócio.