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 a 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, melhorando o desempenho em enlaces com perda não relacionada ao congestionamento.

Diagrama: handshake 3-way vs fire-and-forget

O contraste visual entre os dois protocolos torna a diferença imediata: TCP estabelece um diálogo antes de transmitir qualquer dado; UDP simplesmente dispara o datagrama sem verificação.

Distribuição do tráfego: TCP vs UDP na internet

Com o crescimento do QUIC (que usa UDP como transporte) e HTTP/3, a fatia do UDP no tráfego global cresceu significativamente desde 2021. Estimativas de pesquisadores de rede indicam que, em 2026, aproximadamente 30% do tráfego de internet já passa por UDP, impulsionado principalmente pelo QUIC em navegadores Chrome e Firefox acessando Google, YouTube, Meta e Cloudflare.

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). 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.

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: 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), 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, 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, reduzindo 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 e 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. 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.

Controle de congestionamento TCP em profundidade

O comportamento do TCP diante de perda de pacotes é uma das áreas mais relevantes para entender por que downloads ficam lentos em redes com congestionamento, mesmo que a velocidade contratada seja alta. O algoritmo de controle de congestionamento do TCP funciona com uma janela deslizante (congestion window ou cwnd) que define quantos bytes o emissor pode ter "em trânsito" sem confirmação ACK.

No início de uma conexão, o TCP faz slow start: a cwnd começa em 1 MSS (Maximum Segment Size, tipicamente 1460 bytes em Ethernet) e dobra a cada RTT. Esse crescimento exponencial continua até atingir o ssthresh (slow start threshold) ou detectar congestionamento. Quando há perda, o CUBIC (algoritmo padrão do Linux) reduz a cwnd para 0,7 vezes a cwnd e tenta recuperar de forma mais suave do que o algoritmo Reno clássico.

Na prática isso significa: com 1% de perda de pacotes em uma conexão TCP com RTT de 50ms, o throughput máximo teórico pelo modelo de Mathis é de aproximadamente 2,9 Mbps, independente da velocidade física do enlace ser 100 Mbps ou 1 Gbps. Com 0,1% de perda, o mesmo modelo dá aproximadamente 9 Mbps: reduzir a perda dez vezes melhora o throughput cerca de 3,2 vezes, a raiz quadrada de dez. A fórmula é (MSS / RTT) x (C / raiz da perda), com a constante C próxima de 1,22 no modelo de Mathis.

O BBR (Bottleneck Bandwidth and RTT), desenvolvido pelo Google e disponível no Linux kernel desde 4.9 (2016), aborda o problema diferentemente. Em vez de inferir congestionamento por perda, o BBR modela a largura de banda disponível e a latência de propagação diretamente, mantendo a cwnd em um nível que maximiza o throughput sem criar filas. Em enlaces com alguma perda não relacionada ao congestionamento (como fibras ópticas com micro-interrupções), o BBR consegue taxas muito maiores que o CUBIC.

TCP Fast Open: reduzindo a latência do handshake

TCP Fast Open (TFO, RFC 7413) é uma extensão que permite enviar dados no primeiro pacote SYN, eliminando o overhead de 1 RTT do handshake para conexões repetidas com o mesmo servidor. O cliente armazena um cookie criptográfico fornecido pelo servidor na primeira conexão e o envia junto com o SYN nas conexões subsequentes. O servidor verifica o cookie e já começa a processar os dados sem esperar o ACK final do handshake.

TFO está disponível no Linux desde kernel 3.7 e no macOS desde Yosemite. No Windows, foi implementado no Windows 10. Para conexões com latência alta (como de cidades do interior do Brasil para servidores em São Paulo com 80ms de RTT), TFO pode reduzir o tempo de carregamento de páginas em 10-15%.

TLS 1.3 e o impacto na latência de HTTPS

Antes do TLS 1.3 (RFC 8446, 2018), uma conexão HTTPS sobre TCP exigia: 1 RTT para o handshake TCP + 2 RTTs para negociação TLS 1.2 = 3 RTTs antes do primeiro byte de dado. Com TLS 1.3, a negociação cai para 1 RTT (handshake TCP) + 1 RTT (TLS 1.3 1-RTT) = 2 RTTs. Com TLS 1.3 0-RTT (para reconexões), cai para 1 RTT total. O QUIC/HTTP3 vai além: 0-RTT de handshake para reconexões, sem separação entre TCP e TLS.

Para usuários com conexões de 60ms de RTT para servidores SA, a diferença entre TLS 1.2 e TLS 1.3 representa 60ms a menos de espera a cada nova conexão HTTPS. Multiplicado por dezenas de recursos em uma página moderna (scripts, fontes, imagens), o impacto acumulado é perceptível no tempo de carregamento.

UDP, multicast e protocolos especializados

Uma capacidade do UDP que o TCP não tem é o suporte nativo a multicast. Em uma transmissão multicast, um único pacote UDP é enviado para um grupo de receptores simultaneamente, em vez de enviar uma cópia separada para cada um. Isso é fundamental para IPTV (televisão por protocolo de internet), que alguns provedores brasileiros usam para entregar TV pela fibra sem triplicar o uso de banda para cada assinante assistindo ao mesmo canal.

Streaming multicast de vídeo opera tipicamente sobre RTP/UDP (Real-time Transport Protocol). O protocolo IGMP (Internet Group Management Protocol) gerencia a lista de receptores interessados em cada grupo multicast. Roteadores de borda do ISP usam IGMP snooping para encaminhar o tráfego multicast somente para as portas onde há receptores registrados, evitando inundar toda a rede com o tráfego de vídeo.

No contexto doméstico, UDP é também a base do mDNS (Multicast DNS, RFC 6762), usado por dispositivos da Apple (AirPlay, AirDrop, Bonjour) e sistemas de cast para descoberta local de serviços sem necessidade de servidor DNS centralizado. O protocolo envia mensagens UDP para o grupo multicast 224.0.0.251 (IPv4) ou ff02::fb (IPv6) na porta 5353.

DTLS: segurança sobre UDP

DTLS (Datagram Transport Layer Security) é o equivalente do TLS para UDP. Especificado na RFC 9147 (DTLS 1.3, 2022), o DTLS adiciona autenticação e criptografia a datagramas UDP sem exigir conexão orientada. WebRTC (a tecnologia por trás de videochamadas no navegador) usa DTLS para proteger os canais de dados e o fluxo de mídia. Não é possível usar TLS sobre UDP diretamente porque TLS pressupõe entrega ordenada e sem perda, o que é exatamente o que o UDP não garante.

QUIC e HTTP/3: o futuro e UDP

Uma das mudanças mais significativas na arquitetura da internet moderna foi a adoção do QUIC como protocolo de transporte para HTTP/3. O QUIC (RFC 9000, 2021) roda sobre UDP mas reimplementa dentro do protocolo as funcionalidades que tornavam o TCP confiável: controle de congestionamento, retransmissão seletiva, controle de fluxo e multiplexação de streams sem head-of-line blocking.

O head-of-line blocking é o problema central que o HTTP/2 sobre TCP não resolveu: quando um segmento TCP é perdido, todos os streams HTTP/2 multiplexados sobre aquela conexão ficam travados esperando a retransmissão, mesmo que a maioria dos streams não precise daquele segmento perdido. Com QUIC sobre UDP, cada stream é independente: a perda de um datagrama de um stream não bloqueia os outros.

O Cloudflare, o Google e a Akamai já servem a maioria do tráfego web via HTTP/3 para navegadores modernos. O Chrome e o Firefox ativam HTTP/3 por padrão. Para verificar se uma conexão está usando HTTP/3, no Chrome acesse o atalho chrome://net-internals/#quic e veja as conexões QUIC ativas, ou use a extensão HTTP/2 and SPDY indicator.

O impacto prático para o usuário em redes com alta perda de pacotes é significativo. Testes do IETF e do Google mostram que HTTP/3 sobre QUIC tem desempenho melhor que HTTP/2 sobre TCP quando a taxa de perda de pacotes é acima de 1-2%. Redes móveis, Wi-Fi congestionado e conexões de qualidade marginal se beneficiam mais. Em redes com perda próxima de zero, a diferença é negligenciável.

WebRTC: TCP e UDP para mídia em tempo real

O WebRTC (Web Real-Time Communication) é o protocolo usado por Google Meet, Zoom no navegador, Discord e videochamadas no WhatsApp Web. Ele usa uma pilha de protocolos híbrida: ICE (Interactive Connectivity Establishment) para descoberta de candidatos de conectividade, STUN/TURN para atravessar NAT, DTLS para criptografia e SRTP (Secure Real-time Transport Protocol) sobre UDP para o fluxo de mídia.

O WebRTC tenta estabelecer conexão UDP direta entre os clientes (peer-to-peer) quando possível. Quando UDP direto é bloqueado por firewall ou CGNAT, ele cai para TCP via servidores TURN. A conexão UDP direta tem latência tipicamente 30-80 ms menor que via TURN em TCP, o que explica por que chamadas de vídeo pelo mesmo provedor podem ter qualidade melhor que chamadas entre provedores diferentes com CGNAT.

Para verificar o tipo de conexão WebRTC em uma chamada no Chrome, acesse chrome://webrtc-internals/ durante a chamada. A linha "candidatepair" mostra se a conexão é direta (host ou srflx) ou via servidor de relay (relay). "relay" indica que o firewall ou CGNAT está forçando o tráfego pelo servidor TURN da aplicação.

TCP vs UDP em redes brasileiras: considerações práticas

No Brasil, o tráfego de dados residencial passa principalmente por duas estruturas: fibra óptica GPON nos grandes centros (com baixa perda de pacotes, tipicamente abaixo de 0,1%) e cabo coaxial DOCSIS em áreas onde a Claro/NET ainda opera infraestrutura HFC. Redes DOCSIS têm caracteristicamente mais jitter que GPON por causa do compartilhamento do meio coaxial entre usuários do mesmo nó.

Para usuários em redes com jitter alto (acima de 10 ms de variação), TCP tende a se comportar pior porque o algoritmo de controle de congestionamento interpreta jitter como sinal de perda e reduz a janela de transmissão. O BBRv2, quando disponível no sistema operacional e no servidor de destino, lida melhor com jitter porque baseia as decisões de taxa em medição de largura de banda e RTT, não em eventos de perda.

A Anatel não regula diretamente a proporção de TCP vs UDP no tráfego de provedores, mas a Resolução 614/2013 proíbe degradação discriminatória de protocolos sem transparência ao usuário. Provedores que limitam UDP (comum em algumas configurações de QoS para "controle de P2P") podem estar infringindo o princípio de neutralidade de rede do Marco Civil da Internet (Lei 12.965/2014, artigo 9o).

Perguntas frequentes sobre TCP e UDP