TCP vs UDP

Como TCP funciona: handshake e garantia de entrega

TCP (Transmission Control Protocol) foi definido na RFC 793 em 1981 e atualizado mais recentemente pela RFC 9293 (2022). Opera na Camada 4 do modelo OSI e é orientado a conexão: antes de trocar um único byte de dado, os dois lados precisam completar o handshake de três vias.

O handshake de três vias (SYN-SYN/ACK-ACK)

Cliente envia SYN (synchronize) com um número de sequência inicial aleatório. Servidor responde com SYN/ACK, confirmando o SYN do cliente e enviando seu próprio número de sequência. Cliente responde com ACK, confirmando o SYN do servidor. Só então a conexão está estabelecida e dados podem fluir.

Esse handshake custa pelo menos um RTT (Round-Trip Time) antes de qualquer dado. Para uma conexão com 50ms de RTT, o overhead inicial é de 50ms só para estabelecer a sessão.

Garantia de entrega e controle de sequência

Cada segmento TCP carrega um número de sequência. O receptor confirma com ACK (acknowledgment) o que recebeu. Se o ACK não chega dentro do tempo de retransmissão (RTO), o emissor reenvia o segmento. Isso garante que os dados cheguem, mas introduz latência variável quando há perda.

TCP também reordena segmentos que chegam fora de ordem: se o pacote 3 chega antes do pacote 2, o receptor aguarda o 2 antes de entregar os dados à aplicação. Isso é o head-of-line blocking. Num único fluxo faz sentido. Em múltiplos fluxos multiplexados na mesma conexão TCP (como no HTTP/2), a perda de um pacote de um fluxo congela todos os outros.

Controle de congestionamento

TCP reduz automaticamente a taxa de envio quando detecta congestionamento. Os algoritmos principais usados em 2026 são CUBIC (padrão no Linux desde kernel 2.6.19) e BBR (Bottleneck Bandwidth and Round-trip propagation time), desenvolvido pelo Google. BBR mede o bandwidth e o RTT diretamente em vez de inferir congestionamento por perda, o que melhora o desempenho em enlaces com perda não relacionada ao congestionamento, como fibras com ruído ou conexões via satélite.

Como UDP funciona: velocidade sem garantia

UDP (User Datagram Protocol) está definido na RFC 768 em apenas três páginas. É deliberadamente simples: envia datagramas sem estabelecimento de conexão, sem confirmação de recebimento, sem reordenação e sem controle de fluxo.

O cabeçalho UDP tem exatos 8 bytes: porta de origem (2 bytes), porta de destino (2 bytes), comprimento (2 bytes) e checksum (2 bytes). Para comparação, o cabeçalho TCP mínimo tem 20 bytes e pode chegar a 60 bytes com opções. Menos overhead por pacote significa mais espaço para dados e menos processamento por datagrama.

O que "sem garantia" significa na prática

UDP entrega ou não entrega. Se um datagrama se perde no caminho, o UDP não sabe e não tenta recuperar. A aplicação que usa UDP precisa decidir o que fazer com pacotes perdidos, reordenados ou duplicados. Alguns ignoram. Outros implementam sua própria camada de confiabilidade acima do UDP, como o QUIC faz.

Tabela comparativa: 12 dimensões

Qual usar: casos de uso reais

Use TCP quando

Transferência de arquivos via FTP, SFTP ou SCP: cada byte precisa chegar exatamente uma vez, na ordem certa. Um arquivo corrompido por pacote perdido é inútil. HTTP e HTTPS (navegação web clássica com HTTP/1.1 e HTTP/2): páginas web são conjuntos de recursos que precisam chegar completos. E-mail (SMTP, IMAP, POP3): a mensagem precisa chegar inteira. SSH (acesso remoto): comandos executados em sequência dependem de entrega garantida e ordenada.

Use UDP quando

DNS em consultas normais: a pergunta e a resposta cabem em um único datagrama de 512 bytes ou menos. A latência importa mais que garantia. VoIP (chamadas de voz): codecs como Opus (RFC 6716) têm correção de erro embutida e preferem descartar pacotes antigos a esperar retransmissão. Streaming ao vivo (RTMP sobre UDP, SRT): manter o ritmo do vídeo é prioritário. Jogos online em tempo real: posição de jogadores, tiros, eventos de colisão chegam dezenas de vezes por segundo e precisam ser atuais, não antigos.

DNS usa TCP ou UDP?

Ambos, dependendo do tamanho da resposta. Consultas normais usam UDP na porta 53. Se a resposta excede 512 bytes (comum com DNSSEC, que assina registros criptograficamente), o resolvedor tenta novamente via TCP. Transferências de zona DNS (AXFR), que copiam todo o banco de dados de um servidor para outro, sempre usam TCP. Com EDNS0 (RFC 6891), o limite de UDP foi estendido para até 4096 bytes, reduzindo a necessidade de fallback para TCP.

QUIC e HTTP/3: o protocolo que mistura os dois

QUIC foi padronizado pela IETF na RFC 9000 em 2021. Desenvolvido originalmente pelo Google (onde era chamado de gQUIC), o QUIC roda sobre UDP e reimplementa do zero as funções que faltam no UDP: controle de fluxo, multiplexação de streams sem head-of-line blocking, retransmissão seletiva e criptografia TLS 1.3 embutida.

HTTP/3 usa QUIC como transporte. A mudança em relação ao HTTP/2 sobre TCP é fundamental: no HTTP/2, múltiplos streams compartilham uma conexão TCP, e a perda de um pacote bloqueia todos os streams. No HTTP/3 sobre QUIC, cada stream é independente. Um pacote perdido de um stream não impacta os outros.

Vantagens do QUIC em 2026

Conexão mais rápida: 0-RTT (zero round-trip time) em reconexões, onde o cliente armazena parâmetros da sessão anterior e os reutiliza sem novo handshake. Migração de conexão: se o IP muda durante a sessão (comum em celulares alternando entre Wi-Fi e 4G), a conexão QUIC não precisa ser reestabelecida porque usa um identificador de conexão que não depende do IP. TLS 1.3 embutido: sem negociação separada de TLS e TCP, o que reduz a latência de estabelecimento.

Onde HTTP/3 já está ativo

Google, YouTube, Meta (Facebook, Instagram, WhatsApp), Cloudflare e a maioria dos CDNs grandes já negociam HTTP/3 quando o cliente suporta. Para verificar se seu navegador está usando HTTP/3, abra as ferramentas do desenvolvedor (F12), aba Rede, e observe a coluna Protocolo. "h3" indica HTTP/3 sobre QUIC.

TCP vs UDP em jogos online no Brasil

Jogos competitivos operam com servidores dedicados na América do Sul, geralmente em São Paulo (principal hub da IX.br) ou Fortaleza (próximo aos cabos submarinos). Os protocolos de transporte para dados de jogo são quase universalmente UDP.

League of Legends no servidor BR1 usa UDP para pacotes de gameplay (posição, habilidades, dano) e TCP para lobby, chat e dados do perfil. A latência média esperada de São Paulo é 10-30ms. Do interior de Minas Gerais ou Nordeste, 30-80ms dependendo do roteamento do ISP local até o IX.br.

Valorant usa UDP com pacotes criptografados para o protocolo de gameplay e TCP para o cliente Riot. O servidor SA fica em São Paulo (riot.com/servers). Counter-Strike 2 usa o protocolo Source Engine sobre UDP, com tick rate de 64 Hz em servidores públicos e 128 Hz em competitivo.

Como identificar qual protocolo seu aplicativo usa

No Windows, o comando netstat -an no Prompt de Comando lista todas as conexões ativas com protocolo (TCP ou UDP), endereço local, endereço remoto e estado. Para filtrar apenas conexões de um processo específico, use netstat -b (requer executar como administrador).

No Linux e macOS, ss -tunap lista sockets TCP e UDP ativos com o processo associado. Para captura de pacotes e análise detalhada, o Wireshark filtra por protocolo: tcp ou udp no campo de filtro mostram apenas as conexões relevantes.

Para verificar HTTP/3 no navegador: Chrome e Edge mostram o protocolo na coluna "Protocol" na aba Network do DevTools (F12). "h3" é HTTP/3 sobre QUIC, "h2" é HTTP/2 sobre TCP, "http/1.1" é HTTP/1.1. Firefox mostra informações similares na aba Rede.

Perguntas frequentes sobre TCP e UDP