TCP vs UDP: diferenças e aplicações

Você abre um chamado porque "a chamada de vídeo trava, mas o download funciona". O time de rede diz que está tudo no ar. Os dois usam a mesma infraestrutura, o mesmo IP, o mesmo cabo — então por que um sofre e o outro não? A resposta quase nunca está no link físico. Está na camada de transporte: TCP e UDP resolvem o mesmo problema (levar bytes de um processo a outro através da rede) com filosofias opostas, e essa diferença define o que quebra e como quebra.

Este texto explica o que cada protocolo garante, o que ele cobra por essa garantia e como escolher entre os dois sem cair no chavão de "TCP é seguro, UDP é rápido".

O que TCP entrega — e o preço

TCP é orientado a conexão. Antes de qualquer dado trafegar, os dois lados executam o handshake de três vias (SYN, SYN-ACK, ACK), que sincroniza números de sequência e confirma que ambos estão prontos. A partir daí o TCP promete três coisas: entrega confiável (cada segmento perdido é detectado e reenviado via retransmission), ordem garantida (os bytes chegam à aplicação na mesma sequência em que saíram) e congestion control (o emissor reduz o ritmo quando a rede dá sinais de saturação, em vez de inundar o caminho).

Esse conjunto de garantias é o que torna o TCP a base de HTTP, e-mail (SMTP/IMAP) e transferência de arquivo. Quando você baixa um instalador de 800 MB, não tolera um único byte fora de lugar — e é exatamente isso que o TCP entrega.

O preço é latência. O handshake custa pelo menos um round trip antes do primeiro byte útil. Pior: a ordem garantida cria o problema de head-of-line blocking. Se o segmento 5 se perde, os segmentos 6, 7 e 8 podem já ter chegado, mas a aplicação não os recebe até o 5 ser retransmitido e remontado. Para um download isso é irrelevante; para áudio ao vivo, é o congelamento que gera o chamado.

O que UDP NÃO entrega — de propósito

UDP é o oposto: sem conexão, "atira e esquece". Não há handshake, não há números de sequência, não há retransmission, não há congestion control embutido. Você empacota um datagram, manda para um IP e uma porta, e o protocolo não promete que ele chega, nem que chega na ordem, nem que chega uma vez só.

Isso soa como um defeito até você olhar o header. O cabeçalho UDP tem 8 bytes (porta de origem, porta de destino, tamanho, checksum). O do TCP tem no mínimo 20 e carrega todo o estado de sequência, ACK e janela. Menos overhead por pacote, zero round trips de setup, nenhuma fila esperando retransmission. Latência mínima.

A troca fica explícita assim:

              TCP                         UDP
setup         handshake 3 vias            nenhum
entrega       garantida + retransmit      best effort
ordem         garantida (HOL blocking)    nenhuma
header        >= 20 bytes                 8 bytes
controle      congestion control          nada (fica na aplicação)
melhor para   arquivo, HTTP, e-mail       DNS, jogos, voz, vídeo ao vivo

UDP brilha exatamente onde um pacote atrasado é pior que um pacote perdido. Em voz e vídeo em tempo real, retransmitir um quadro de áudio de 200 ms atrás é inútil — a conversa já seguiu. Melhor descartar e tocar o próximo. Jogos online preferem perder uma atualização de posição e receber a próxima fresca do que esperar a antiga. Streaming ao vivo tem a mesma lógica. A perda existe, mas a aplicação decide o que fazer com ela — esconder, interpolar, ignorar — em vez de deixar o transporte travar tudo.

DNS: o caso que usa os dois

DNS é o exemplo didático de por que UDP faz sentido. Uma consulta de nome é tipicamente uma pergunta curta e uma resposta curta: "qual o IP de exemplo.com?" → "203.0.113.10". Abrir um handshake TCP para isso seria absurdo — três pacotes de cerimônia para trocar dois pacotes de conteúdo. Por isso o DNS nasceu sobre UDP na porta 53: uma pergunta, uma resposta, latência mínima. Se a resposta se perde, o resolver simplesmente pergunta de novo.

Mas o UDP tem um limite prático de tamanho de datagram (historicamente 512 bytes, hoje estendido via EDNS0). Quando a resposta não cabe — muitos registros, DNSSEC, zonas grandes — o servidor sinaliza truncamento e o cliente refaz a consulta sobre TCP, onde a fragmentação e a confiabilidade são tratadas. Ou seja: o DNS usa UDP por padrão e cai para TCP quando o tamanho exige. Se você quer ver esse fluxo em detalhe, escrevi um passo a passo de como uma consulta DNS acontece.

Tanto TCP quanto UDP carregam pacotes entre endereços IP, e parte do trabalho de diagnóstico é saber de onde o tráfego realmente vem. Inspecionar um IP de origem ajuda a separar "o protocolo está errado" de "o destino está errado".

QUIC e HTTP/3: o melhor dos dois

A divisão clássica não é o fim da história. O QUIC, que sustenta o HTTP/3, roda sobre UDP — mas reimplementa, no espaço de usuário, a confiabilidade, a ordem por stream e o congestion control que o TCP traz no kernel. A jogada é esperta: ao usar UDP como base, o QUIC escapa do head-of-line blocking entre streams (uma perda em um stream não trava os outros) e do enrijecimento dos middleboxes que dificultam evoluir o TCP. Você ganha as garantias do TCP sem herdar suas limitações estruturais. É a prova de que "UDP confiável" não é contradição — é uma escolha de onde colocar a complexidade.

Como eu escolho na prática

Minha regra é direta: na dúvida, é TCP. Confiabilidade e ordem são o comportamento que a maioria das aplicações assume sem perceber, e errar para o lado seguro custa apenas latência — algo que você mede e, em geral, tolera. A maior parte do que você constrói (APIs, uploads, integrações) quer TCP e ponto.

Escolha UDP conscientemente, não por reflexo de "quero velocidade". O critério é específico: a latência importa mais que a entrega perfeita, e você aceita lidar com a perda na própria aplicação. Se você não tem um plano para o que fazer quando um pacote some — esconder o glitch, pedir o estado de novo, interpolar — então você não está pronto para UDP, está só abrindo mão das garantias de graça. UDP não é "TCP rápido"; é TCP sem rede de segurança, e a rede de segurança passa a ser sua responsabilidade.

Perguntas frequentes

TCP é sempre mais lento que UDP?

Não em throughput sustentado — em conexões estáveis o TCP transfere muito dado com eficiência. O que o UDP ganha é em latência de setup e em ausência de head-of-line blocking. Para um download grande, o TCP costuma ser igual ou melhor; para um pacote pequeno e sensível ao tempo, o UDP chega antes.

Posso ter confiabilidade usando UDP?

Sim, mas você a implementa por cima. É exatamente o que o QUIC faz: usa UDP como transporte cru e reconstrói retransmission, ordem e congestion control no espaço de usuário. Para projetos comuns, raramente vale reescrever isso à mão — use uma biblioteca ou caia no TCP.

Por que jogos online usam UDP se podem perder pacotes?

Porque numa partida em tempo real um pacote atrasado já está obsoleto quando chega. Uma posição de 100 ms atrás é inútil se a próxima já vem a caminho. O jogo prefere descartar a atualização velha e usar a nova, em vez de esperar uma retransmission que só atrasa tudo.

Como sei qual protocolo um serviço está usando?

Pelo número de porta e pelo tipo de socket. Convenções ajudam: 80/443 (HTTP) são TCP, 53 (DNS) usa ambos, 443 também carrega HTTP/3 sobre UDP via QUIC. Ferramentas como netstat, ss ou um capturador de pacotes mostram explicitamente se a conexão é TCP ou UDP.

O que levar disso

TCP e UDP não competem — dividem trabalho. TCP paga latência para entregar confiabilidade e ordem, e é a escolha padrão correta para quase tudo. UDP abre mão dessas garantias para cortar latência, e vale quando um pacote atrasado machuca mais que um perdido e você tem um plano para a perda. Decida pelo que dói mais quando algo falha: se for byte fora de lugar, TCP; se for atraso, UDP. E lembre que QUIC já borrou a fronteira — a pergunta moderna não é "TCP ou UDP", mas "onde eu quero pagar pela confiabilidade".