TCP versus UDP para Desenvolvedores — Quando o Protocolo Realmente Importa

Você está construindo um jogo multiplayer. Os jogadores estão reclamando de atraso. Você otimizou o código do servidor, reduziu consultas ao banco de dados e a latência p99 parece boa. O problema é mais simples: você está usando TCP. Isso é tudo. Isso é o atraso.

TCP e UDP não são apenas duas caixas em uma lista de protocolos — eles representam apostas fundamentais sobre o que a rede fará. A escolha errada não apenas custa desempenho. Muda o caráter do falha quando as coisas vão errado.

A aposta que o TCP faz

O TCP promete uma sequência confiável e ordenada de bytes. Se um pacote for perdido, o TCP o retransmitirá. Se os pacotes chegarem fora de ordem, o TCP os reorganizará. Seu aplicativo vê dados limpos e sequenciais, sempre.

Essa garantia custa três coisas:

• Latência de handshake — O TCP exige um handshake de três vias antes que um único byte de dados do aplicativo se mova. Em uma rede com 50ms de viagem de ida e volta, você gasta 150ms antes que sua primeira requisição até mesmo comece.
• Bloqueio de cabeça da fila — Este é o que mata jogos. Se o pacote #5 for perdido, o TCP mantém os pacotes #6, #7 e #8 em um buffer esperando que o #5 seja retransmitido e chegue. A sequência é bloqueada. A atualização de posição do jogador de 100ms atrás está parada em um buffer enquanto a rede se organiza.
• Overhead de controle de congestionamento — O algoritmo de janela de congestionamento do TCP (CUBIC, BBR, etc.) reduz a taxa de envio quando detecta perda. Em uma rede com perda, isso significa que o TCP reduz a taxa de transmissão exatamente no momento em que a rede está tendo dificuldades — o que é exatamente quando os usuários sentem mais.

O que o UDP realmente oferece

O UDP envia um datagrama e não olha para trás. Sem handshake, sem confirmação, sem retransmissão. Se um pacote for perdido, ele desaparece. O receptor recebe o que chega, na ordem em que chega.

Isso não é uma limitação — é o ponto. Quando você precisa de baixa latência mais do que de garantias de entrega, o UDP permite que você faça essa escolha explicitamente. A lógica de confiabilidade passa para a camada de aplicação, onde você pode tomar decisões mais inteligentes sobre o que realmente precisa ser retransmitido.

Em um jogo, uma atualização de posição do jogador de 50ms atrás é inútil — você quer a atual. Com TCP, você bufferia e esperaria. Com UDP, você envia o estado mais recente e pula o que for obsoleto. A experiência é mais suave mesmo com mais perda de pacotes.

TCP versus UDP: a comparação que realmente importa

Propriedade	TCP	UDP
Configuração da conexão	Handshake de três vias (adiciona 1,5× RTT antes do primeiro byte)	Nenhum — envia imediatamente
Garantia de entrega	Sim — retransmite em caso de perda	Não — envia e esquece
Ordem dos pacotes	Garantida pela pilha	Seu problema
Bloqueio de cabeça da fila	Sim — um pacote perdido bloqueia a sequência	Não — cada datagrama é independente
Controle de congestionamento	Integrado (CUBIC, BBR, etc.)	Nenhum — implemente o próprio ou pule
Overhead típico de latência	150–300ms em conexões frias	Sub-milissegundo
Casos de uso	HTTP/1.1, HTTP/2, bancos de dados, transferência de arquivos, e-mail	DNS, jogos, transmissão ao vivo, HTTP/3 (QUIC)

Onde cada protocolo realmente pertence

DNS funciona sobre UDP — e há uma lição nisso

Cada consulta DNS que seu aplicativo faz é feita por UDP por padrão. A requisição cabe em um único pacote, a resposta cabe em um único pacote, e você recebe a resposta em uma única rota. Sem overhead de handshake, sem estado para manter no servidor.

Se a resposta for muito grande (registros DNSSEC, muitos registros A), o DNS cai para TCP. Mas o caso comum — uma consulta para um nome de host — é puramente UDP porque a troca é evidente: o handshake de três vias levaria mais tempo do que a própria consulta.

Você pode ver esse comportamento em ação com o IO Tools DNS Lookup tool — digite um domínio e observe como rapidamente os tipos de registro são resolvidos. Essa velocidade é UDP eliminando um ciclo completo de overhead de handshake.

Jogos: UDP é a única resposta real

Cada biblioteca principal de rede de jogos — o GameNetworkingSockets da Valve, o transporte da EOS da Epic, o UTP do Unity — é construída sobre UDP. A razão é o bloqueio de cabeça da fila.

Em um FPS competitivo, você envia atualizações de posição a cada 64 ticks — a cada 15ms. Se um pacote for perdido e o TCP bloqueia os próximos cinco enquanto espera a retransmissão, você introduz 75ms de estalo exatamente no momento errado. Com UDP, você envia a próxima atualização imediatamente. O cliente interpola sobre a lacuna. A experiência é suave.

A maioria do código de rede de jogos construído sobre UDP implementa sua própria confiabilidade seletiva — números de sequência, filas de prioridade, ACKs seletivos — mas apenas para dados que realmente precisam: mensagens de chat, aquisição de itens, estado do jogo. Os dados de posição são irrelevante por design. Uma leitura obsoleta é pior do que nenhuma leitura.

Transmissão de vídeo: depende do caso de uso

Transmissão ao vivo (Twitch, transmissões esportivas) usa protocolos baseados em UDP — RTP, WebRTC, SRT — porque algumas perdas de quadros são aceitáveis, mas a latência não é. Você não pode buffer 30 segundos de uma partida ao vivo para garantir entrega suave.

VOD (Netflix, YouTube) realmente usa TCP, porque o buffer oculta o custo. Alguns segundos de pré-buffer significam que o overhead de retransmissão do TCP é invisível — você só vê uma reprodução suave. O custo de latência não importa quando você está assistindo algo que aconteceu ontem.

HTTP/3 funciona sobre UDP — e muda o desempenho da web

HTTP/3 funciona sobre QUIC, que funciona sobre UDP. O Google construiu QUIC especificamente para corrigir o problema de bloqueio de cabeça da fila do TCP para o tráfego da web. Com HTTP/2 sobre TCP, um único pacote perdido bloqueia todos os streams multiplexados que compartilham essa conexão. O QUIC implementa multiplexação de streams na camada de transporte com confirmação independente — um pacote perdido bloqueia apenas um stream, não todos.

O QUIC também integra o TLS no handshake, reduzindo a configuração de conexões frias a um único ciclo (0-RTT em ressincronização). Em redes com perda — conexões móveis, WiFi congestionado — isso é uma melhoria significativa. Em 2024, cerca de 30% de sites suportam HTTP/3, e todos os principais navegadores o ativam por padrão. Se você estiver deployando atrás do Cloudflare ou de um CDN moderno, provavelmente já está servindo HTTP/3 sem ter configurado explicitamente.

A árvore de decisão prática

Quando você está escolhendo um transporte para um novo protocolo ou serviço, a pergunta não é “TCP ou UDP?” — é “quais falhas posso tolerar?”

• Cada byte deve chegar, na ordem correta, ou a operação falha → TCP. Uploads de arquivos, conexões com bancos de dados, chamadas de API, e-mail. Dados ausentes significam dados corrompidos ou erro de parsing.
• A latência importa mais do que a entrega garantida → UDP. Jogos, transmissão ao vivo, chamadas de voz, telemetria de sensores. Uma leitura obsoleta é pior do que nenhuma leitura.
• Você precisa dos dois, por mensagem → Construa sobre UDP com confiabilidade seletiva. O QUIC faz isso. O canal de dados do SCTP do WebRTC faz isso. Bibliotecas como ENet e GameNetworkingSockets fazem isso também — embora implementar isso por si só seja um trabalho não trivial que é fácil de errar de forma sutil.

Um erro importante a destacar: assumir que “tráfego interno” significa que você pode usar UDP com desprezo. A perda de pacotes dentro de um datacenter é rara, mas não nula — falhas de hardware, congestionamento de rede sob carga máxima, switches mal configurados. Se seu aplicativo corrompe silenciosamente os dados em caso de perda, um rede interna não o salvará.

Resumo

O TCP é a escolha correta para a maioria dos códigos de aplicação. Se você está fazendo chamadas de API, conversando com um banco de dados ou transferindo arquivos, as garantias do TCP são exatamente o que você precisa e o overhead é invisível em escalas humanas.

O UDP é a escolha correta quando a latência é uma restrição rígida e seu aplicativo pode assumir sua relação com a confiabilidade. Isso é um conjunto específico de problemas — jogos em tempo real, mídias ao vivo, protocolos personalizados — não uma otimização de desempenho geral para alcançar quando o TCP parece lento.

O erro real não é usar TCP quando o UDP seria mais rápido. É não saber qual é a escolha que você está fazendo, ou por que, e ficar surpreso quando o modo de falha chega.

Você também pode gostar