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 e orientado a conexão: antes de trocar um único byte de dado, os dois lados precisam completar o handshake de tres vias.

O handshake de tres 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. So então a conexão esta 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 e 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 retransmissao (RTO), o emissor reenvia o segmento. Isso garante que os dados cheguem, mas introduz latência variável quando ha 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 e 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 dialogo antes de transmitir qualquer dado; UDP simplesmente dispara o datagrama sem verificação.

Distribuicao 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) esta definido na RFC 768 em apenas tres paginas. E deliberadamente simples: envia datagramas sem estabelecimento de conexão, sem confirmacao de recebimento, sem reordenacao e sem controle de fluxo.

O cabecalho UDP tem exatos 8 bytes: porta de origem (2 bytes), porta de destino (2 bytes), comprimento (2 bytes) e checksum (2 bytes). O cabecalho TCP minimo tem 20 bytes e pode chegar a 60 bytes com opcoes. Menos overhead por pacote significa mais espaço para dados e menos processamento por datagrama.

Tabela comparativa: 12 dimensoes

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 e inutil. HTTP e HTTPS (navegacao web clássica com HTTP/1.1 e HTTP/2): paginas 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) tem correcao de erro embutida e preferem descartar pacotes antigos a esperar retransmissao. Streaming ao vivo: manter o ritmo do video e prioritario. Jogos online em tempo real: posição de jogadores, tiros, eventos de colisao 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. Transferencias 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, retransmissao seletiva e criptografia TLS 1.3 embutida.

HTTP/3 usa QUIC como transporte. A mudanca em relação ao HTTP/2 sobre TCP e 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 e 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 reconexoes, onde o cliente armazena parâmetros da sessão anterior e os reutiliza sem novo handshake. Migracao 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 negociacao separada de TLS e TCP, reduzindo a latência de estabelecimento.

Onde HTTP/3 já esta 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 esta 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 (proximo 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 especifico, 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 analise 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" e HTTP/3 sobre QUIC, "h2" e HTTP/2 sobre TCP, "http/1.1" e 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 e uma das areas 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 confirmacao ACK.

No início de uma conexão, o TCP faz slow start: a cwnd comeca 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 ha perda, o CUBIC (algoritmo padrão do Linux) reduz a cwnd para sqrt(0.7 * 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 maximo teórico pelo modelo de Mathis e de aproximadamente 4 Mbps, independente da velocidade física do enlace ser 100 Mbps ou 1 Gbps. Com 0,1% de perda, o mesmo modelo da aproximadamente 40 Mbps. A formula e MSS / (RTT * sqrt(perda)).

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-interrupcoes), o BBR consegue taxas muito maiores que o CUBIC.

TCP Fast Open: reduzindo a latência do handshake

TCP Fast Open (TFO, RFC 7413) e uma extensao 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 criptografico 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 esta 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 paginas 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 negociacao TLS 1.2 = 3 RTTs antes do primeiro byte de dado. Com TLS 1.3, a negociacao cai para 1 RTT (handshake TCP) + 1 RTT (TLS 1.3 1-RTT) = 2 RTTs. Com TLS 1.3 0-RTT (para reconexoes), cai para 1 RTT total. O QUIC/HTTP3 vai além: 0-RTT de handshake para reconexoes, sem separacao 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 pagina moderna (scripts, fontes, imagens), o impacto acumulado e perceptivel no tempo de carregamento.

UDP, multicast e protocolos especializados

Uma capacidade do UDP que o TCP não tem e o suporte nativo a multicast. Em uma transmissão multicast, um único pacote UDP e enviado para um grupo de receptores simultaneamente, em vez de enviar uma copia separada para cada um. Isso e fundamental para IPTV (televisao 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 video 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 ha receptores registrados, evitando inundar toda a rede com o tráfego de video.

No contexto domestico, UDP e 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: seguranca sobre UDP

DTLS (Datagram Transport Layer Security) e 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 tras de videochamadas no navegador) usa DTLS para proteger os canais de dados e o fluxo de midia. Não e possível usar TLS sobre UDP diretamente porque TLS pressupoe entrega ordenada e sem perda, o que e exatamente o que o UDP não garante.

QUIC e HTTP/3: o futuro e UDP

Uma das mudancas mais significativas na arquitetura da internet moderna foi a adocao 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 confiavel: controle de congestionamento, retransmissao seletiva, controle de fluxo e multiplexação de streams sem head-of-line blocking.

O head-of-line blocking e o problema central que o HTTP/2 sobre TCP não resolveu: quando um segmento TCP e perdido, todos os streams HTTP/2 multiplexados sobre aquela conexão ficam travados esperando a retransmissao, mesmo que a maioria dos streams não precise daquele segmento perdido. Com QUIC sobre UDP, cada stream e 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 esta usando HTTP/3, no Chrome acesse o atalho chrome://net-internals/#quic e veja as conexões QUIC ativas, ou use a extensao HTTP/2 and SPDY indicator.

O impacto prático para o usuário em redes com alta perda de pacotes e 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 e acima de 1-2%. Redes móveis, Wi-Fi congestionado e conexões de qualidade marginal se beneficiam mais. Em redes com perda proxima de zero, a diferença e negligenciavel.

WebRTC: TCP e UDP para midia em tempo real

O WebRTC (Web Real-Time Communication) e o protocolo usado por Google Meet, Zoom no navegador, Discord e videochamadas no WhatsApp Web. Ele usa uma pilha de protocolos hibrida: 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 midia.

O WebRTC tenta estabelecer conexão UDP direta entre os clientes (peer-to-peer) quando possível. Quando UDP direto e 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 video 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 e direta (host ou srflx) ou via servidor de relay (relay). "relay" indica que o firewall ou CGNAT esta forcando o tráfego pelo servidor TURN da aplicação.

TCP vs UDP em redes brasileiras: consideracoes práticas

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

Para usuários em redes com jitter alto (acima de 10 ms de variacao), 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 decisoes de taxa em medicao de largura de banda e RTT, não em eventos de perda.

A Anatel não regula diretamente a proporcao de TCP vs UDP no tráfego de provedores, mas a Resolucao 614/2013 probe degradacao discriminatoria de protocolos sem transparencia ao usuário. Provedores que limitam UDP (comum em algumas configurações de QoS para "controle de P2P") podem estar infringindo o principio de neutralidade de rede do Marco Civil da Internet (Lei 12.965/2014, artigo 9o).

Perguntas frequentes sobre TCP e UDP