TCP e UDP para administração de servidores: handshake, retransmissão e latência

TCP e UDP vistos pela ótica de sintomas em aplicações

Ao administrar servidores, você raramente “vê” TCP e UDP diretamente; você vê efeitos: API que fica lenta sem aumentar CPU, consultas DNS que falham de forma intermitente, streaming que “engasga”, logs que somem. Entender como TCP e UDP se comportam ajuda a transformar sintomas em hipóteses testáveis com métricas e capturas simples.

Quando pensar em TCP vs UDP

• TCP: orientado a conexão, entrega confiável e ordenada. Quando há perda, o TCP tenta recuperar (retransmitir), o que pode aumentar latência e reduzir vazão. Sintomas comuns: lentidão, timeouts, conexões que demoram a abrir, throughput baixo em presença de perda.
• UDP: sem conexão e sem garantia de entrega. A aplicação decide como lidar com perda/ordem. Sintomas comuns: perda tolerada (áudio/vídeo com artefatos), intermitência (DNS), mensagens faltando (telemetria/logs), mas geralmente sem “travamento” por retransmissão no transporte.

TCP na prática: handshake, janelas e retransmissões

3-way handshake (abertura de conexão) e sintomas

Para iniciar uma conexão TCP, cliente e servidor fazem o 3-way handshake:

1. SYN: cliente pede para abrir conexão.
2. SYN-ACK: servidor aceita e responde.
3. ACK: cliente confirma; a conexão está pronta para enviar dados.

Sintomas observáveis quando algo dá errado nessa fase:

• Bloqueio de porta / firewall: o cliente envia SYN e não recebe resposta (SYN “some”). Resultado: tentativas repetidas e timeout. Em ferramentas, você vê “Connection timed out”.
• Porta fechada: o servidor responde com RST (reset). Resultado: falha imediata (“Connection refused”).
• Latência alta: handshake completa, mas demora. Resultado: “tempo para conectar” alto (TTFB pode aumentar se o app só responde após conectar).

Janelas, ACKs e por que perda vira lentidão

TCP controla quanto pode estar “em voo” sem confirmação usando janelas. Em alto nível:

• Janela de recepção (rwnd): quanto o receptor consegue receber (buffer).
• Janela de congestionamento (cwnd): quanto o emissor “se permite” enviar baseado em sinais de congestionamento/perda.

Quando há perda, o TCP interpreta como possível congestionamento e reduz a taxa de envio (cwnd diminui). Mesmo uma perda pequena pode causar grande impacto em fluxos de alta latência (RTT alto), porque a recuperação depende de tempo e de confirmações.

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

Retransmissões: o sinal clássico de perda (ou reordenação)

Se um segmento TCP não é confirmado (ACK) dentro do esperado, o emissor retransmite. Isso pode acontecer por:

• Perda real no caminho.
• Congestionamento (filas cheias derrubam pacotes).
• Reordenação (pacotes chegam fora de ordem; pode gerar “dup ACK” e retransmissão rápida).
• Problemas de MTU/fragmentação em algum ponto (pode causar perda de pacotes maiores, gerando retransmissões e stalls).

Sintoma em aplicação: a requisição “anda aos trancos”, com picos de latência e throughput baixo, mesmo com CPU e disco normais. Em HTTP, isso aparece como aumento de tempo de resposta e, às vezes, timeouts.

Controle de congestionamento (visão operacional)

Você não precisa decorar algoritmos, mas precisa reconhecer o comportamento:

• Sem perda: a taxa sobe até um limite (cwnd cresce), a transferência fica estável.
• Com perda: o TCP reduz a taxa e cresce novamente. Se a perda é contínua, a taxa fica “serrilhada” e a latência percebida aumenta.

Em links com buffer grande (bufferbloat), pode ocorrer latência alta sem perda: filas crescem, RTT aumenta, e a aplicação fica lenta mesmo sem retransmissões significativas.

UDP na prática: sem conexão, perda tolerada e efeitos colaterais

Sem conexão: o que muda no diagnóstico

UDP não tem handshake, não confirma entrega e não retransmite. Isso traz duas consequências operacionais:

• Falhas podem ser “silenciosas”: se um datagrama se perde, não há retransmissão automática. A aplicação pode apenas “não receber”.
• Latência pode ser menor em cenários onde a aplicação tolera perda e prefere “seguir em frente” (ex.: áudio/vídeo em tempo real, telemetria).

Perda em UDP: sintomas típicos

• DNS intermitente: consultas UDP que às vezes não retornam; o cliente pode tentar outro servidor, repetir a consulta ou cair para TCP (dependendo do caso).
• Streaming/voz: artefatos, cortes, “engasgos”, mas sem necessariamente travar esperando retransmissão.
• Logs/telemetria via UDP: lacunas em eventos; contadores no destino não batem com o emitido.

Diferenciando: latência, perda e bloqueio de porta (checklist operacional)

1) Bloqueio de porta vs porta fechada (TCP)

Objetivo: saber se o problema é rede/ACL/firewall ou serviço.

• Porta fechada (serviço não escutando): falha imediata com RST. Sintoma: “connection refused”.
• Porta bloqueada (firewall drop): SYN sem resposta. Sintoma: “connection timed out”, demora até falhar.

Passo a passo prático (do cliente):

# Teste TCP simples (substitua host/porta)  nc -vz -w 3 api.exemplo.com 443  # Alternativa com timeout explícito  timeout 3 bash -c 'cat < /dev/null > /dev/tcp/api.exemplo.com/443'  # Se houver TLS/HTTPS, verifique tempo de conexão e handshake TLS  curl -vk --connect-timeout 3 https://api.exemplo.com/health

Como interpretar:

• Connection refused rápido: rota ok, host respondeu, mas serviço/porta não está aceitando.
• timed out: suspeite de firewall/ACL/security group, rota assimétrica, ou host inacessível.
• Connected mas curl demora no TTFB: conexão abriu, problema pode ser latência/perda durante transferência ou lentidão no app.

2) Latência alta (sem perda) vs perda (com retransmissão) em TCP

Latência alta é aumento de RTT. Pode vir de distância, roteamento, filas (bufferbloat) ou saturação. Perda tende a gerar retransmissões e queda de throughput.

Sinais práticos:

• Latência alta sem perda: RTT alto e relativamente estável; poucas retransmissões; a aplicação é lenta mas “contínua”.
• Perda: retransmissões, “buracos” no fluxo, variação grande de tempo; a aplicação pode parecer “travada” e depois “destravar”.

Passo a passo prático (métricas e testes):

# RTT e variação (jitter)  ping -c 20 servidor.exemplo.com  # Rota e saltos com latência por hop (útil para achar onde cresce)  traceroute servidor.exemplo.com  # Em Linux moderno, mtr combina ping+traceroute  mtr -rwzc 50 servidor.exemplo.com

Correlacione com métricas:

• Em um proxy/load balancer: tempo de conexão, TTFB, tempo total.
• No servidor: taxa de retransmissão TCP, conexões em SYN-SENT/SYN-RECV, fila de accept, erros de socket.

Exemplos de métricas úteis (nomes variam por stack):

• tcp_retrans_segs, tcp_out_segs (para calcular proporção de retransmissões)
• ListenOverflows/ListenDrops (backlog estourando pode parecer “rede lenta”)
• TCPSynRetrans (SYN retransmitido sugere bloqueio/perda no handshake)

3) UDP: diferenciar “porta bloqueada” de “perda normal”

Em UDP, não existe “conexão”, então o cliente pode não saber se a porta está bloqueada ou se apenas perdeu um datagrama. Alguns protocolos têm resposta (DNS), outros são unidirecionais (syslog UDP).

Passo a passo prático:

# Teste UDP com netcat (depende de haver algo respondendo do outro lado)  nc -vu -w 2 dns.exemplo.com 53  # Para DNS, use uma consulta real e observe tempo/timeout  dig @dns.exemplo.com exemplo.com A +tries=1 +time=2  # Repita para ver intermitência  for i in $(seq 1 20); do dig @dns.exemplo.com exemplo.com A +tries=1 +time=1 | grep -E 'Query time|timed out'; done

Interpretação:

• Se dig alterna entre respostas rápidas e timeouts: suspeite de perda, overload do servidor DNS, ACL intermitente, ou caminho assimétrico.
• Se sempre dá timeout: pode ser porta bloqueada, servidor fora, ou rota quebrada. Confirme com captura no cliente (ver seção de capturas).

Exemplo 1: API lenta por retransmissão TCP

Cenário e sintomas

• Usuários relatam que a API “às vezes demora 10–30s”.
• CPU do servidor está normal, banco responde rápido localmente.
• Nos logs do app, o tempo total da requisição é alto, mas o tempo de processamento interno é baixo.

Hipótese

Perda no caminho entre cliente e servidor (ou entre proxy e upstream) causando retransmissões TCP e redução de janela, elevando o tempo de transferência/TTFB.

Passo a passo prático

1. Separe tempos de rede vs app: no proxy (Nginx/Envoy/ALB), compare connect time, TTFB e total time. Se o app “processa rápido” mas o total é alto, suspeite de rede.
2. Meça RTT e perda do ponto do proxy até o upstream (ou do cliente até o proxy): use mtr por alguns minutos e observe perda e variação.
3. Capture um caso ruim com tcpdump no servidor (ou no proxy) filtrando a porta da API.

# Captura focada em uma porta TCP (ex.: 443)  sudo tcpdump -i eth0 -nn -s 0 -w api443.pcap 'tcp port 443'  # Se a API estiver atrás de um proxy, capture também a porta upstream (ex.: 8080)  sudo tcpdump -i eth0 -nn -s 0 -w upstream8080.pcap 'tcp port 8080'

O que procurar na análise (em Wireshark/tshark):

• TCP Retransmission / Fast Retransmission.
• Dup ACK (ACKs duplicados sugerem perda/reordenação).
• RTT aumentando durante o fluxo.
• Zero Window (receptor sem buffer; isso é “bloqueio” no destino, não perda na rede).

Diferencial importante: se você vê ZeroWindow e Window Update, o gargalo pode ser o receptor (aplicação lenta lendo socket). Se você vê muitas retransmissões sem ZeroWindow, é mais provável perda/congestionamento no caminho.

Exemplo 2: DNS intermitente (UDP) e queda para TCP

Cenário e sintomas

• Aplicações falham ao resolver nomes “de vez em quando”.
• Erros variam: timeout de resolução, fallback para outro resolvedor, ou lentidão em chamadas externas.

Hipóteses comuns

• Perda de UDP no caminho até o servidor DNS (ou retorno).
• Rate limiting no DNS (responde para alguns, ignora outros).
• MTU/fragmentação afetando respostas maiores (DNS com muitos registros/DNSSEC pode fragmentar em UDP).

Passo a passo prático

1. Teste repetitivo com tempo curto para evidenciar intermitência:

for i in $(seq 1 30); do  dig @10.0.0.53 exemplo.com A +tries=1 +time=1 | grep -E 'Query time|timed out'; done

2. Compare UDP vs TCP no DNS (quando aplicável):

# Força TCP no DNS  dig @10.0.0.53 exemplo.com A +tcp +tries=1 +time=2

Interpretação:

• Se UDP falha e TCP funciona consistentemente: suspeite de perda/filtragem de UDP 53 ou fragmentação UDP.
• Se ambos falham: problema pode ser o servidor DNS, rota, ou bloqueio geral.

3. Capture apenas DNS para confirmar se a resposta volta:

sudo tcpdump -i eth0 -nn -s 0 -w dns.pcap 'udp port 53 or tcp port 53'

O que procurar:

• Consulta saindo e ausência de resposta (perda/bloqueio no caminho de volta).
• Respostas com TC (truncated) indicando que o cliente deve repetir em TCP.
• Respostas grandes e fragmentação IP (pode falhar em alguns firewalls).

Exemplo 3: streaming e logs via UDP (perda tolerada vs perda inaceitável)

Streaming/telemetria em tempo real

Em streaming/tempo real, a prioridade costuma ser latência baixa em vez de entrega perfeita. UDP permite que o receptor use o que chegou e descarte o que perdeu, evitando “paradas” por retransmissão.

Sintomas de perda:

• Áudio com cortes, vídeo com macroblocos, telemetria com pontos faltando.
• Sem “timeout” clássico; o fluxo continua, mas degradado.

Logs via UDP (ex.: syslog) e como detectar lacunas

Logs via UDP são comuns por simplicidade, mas podem perder mensagens em congestionamento. Se para você cada evento importa, UDP pode ser inadequado sem mecanismos adicionais (buffer local, reenvio, ou troca para TCP).

Passo a passo prático:

1. Instrumente contadores: no emissor, conte mensagens enviadas; no coletor, conte recebidas. Compare por janela de tempo.
2. Observe drops no host: quedas podem ocorrer no kernel (buffers UDP) antes da aplicação ler.
3. Capture por amostragem em momentos de pico para ver se o tráfego chega ao coletor.

# Captura UDP em uma porta típica de syslog (514)  sudo tcpdump -i eth0 -nn -s 0 -w syslog_udp.pcap 'udp port 514'

Correlações úteis:

• Picos de uso de rede e aumento de drops no host/coletor.
• Fila/buffer do coletor saturando (aplicação não consumindo rápido).
• Se o tráfego chega na interface (pcap mostra pacotes) mas não aparece no app: gargalo é local (socket buffer, processamento, fila interna).

Capturas simples: como coletar evidência sem “virar especialista em Wireshark”

Estratégia mínima de captura

• Capture no ponto certo: se há proxy, capture no proxy e no upstream. Se há dúvida de firewall, capture no lado que você controla (cliente/servidor) para ver se o pacote sai/entra.
• Filtre bem: porta e host para reduzir ruído.
• Capture durante o problema: 30–120s no momento do sintoma costuma bastar.

Comandos práticos (TCP e UDP)

# TCP: capture handshake e dados de uma porta  sudo tcpdump -i eth0 -nn -s 0 -w cap.pcap 'host 203.0.113.10 and tcp port 443'  # UDP: capture DNS ou outro serviço  sudo tcpdump -i eth0 -nn -s 0 -w cap_dns.pcap 'udp port 53'  # Ver resumo rápido sem abrir GUI  tcpdump -nn -r cap.pcap | head  # Estatísticas básicas (tshark)  tshark -r cap.pcap -q -z io,stat,1

Leitura rápida de sinais em TCP (o que procurar)

Mapa mental de diagnóstico (aplicação → transporte → evidência)

Se a aplicação “não conecta”

• TCP: diferencie refused (porta fechada) vs timeout (bloqueio/perda/rota).
• Capture: procure SYN saindo e resposta (SYN-ACK/RST) voltando.

Se a aplicação conecta, mas “fica lenta”

• Verifique se é TTFB alto (rede/servidor) ou transferência lenta (perda/janelas).
• Capture: procure retransmissões, dup ACK, RTT variando, zero window.

Se é UDP e “às vezes funciona”

• Teste repetitivo (dig/consultas) para quantificar intermitência.
• Capture: confirme se a resposta chega; se não chega, é perda/bloqueio no caminho.
• Compare com TCP quando o protocolo permitir (DNS).