System Design/02 - Componentes/Communication2 min
UDP
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Transporte sem conexão e sem garantias: envia o datagrama e não olha para trás. Sem handshake, sem ACK, sem retransmissão, sem ordenação, sem controle de congestionamento.
| TCP | UDP | |
|---|---|---|
| Conexão | Handshake de 3 vias | Nenhuma |
| Entrega | Garantida | Best-effort |
| Ordem | Garantida | Nenhuma |
| Overhead do cabeçalho | 20+ bytes | 8 bytes |
| Head-of-line blocking | Sim | Não |
| Broadcast / multicast | Não | Sim |
Onde é a escolha certa
| Uso | Por quê |
|---|---|
| VoIP, videochamada | Pacote antigo é inútil; retransmitir atrapalha |
| Jogo em tempo real | O próximo tick corrige o estado |
| DNS | Uma pergunta, uma resposta, cabe num datagrama |
| Streaming ao vivo | Melhor pular um frame que travar |
| Métricas (StatsD) | Perder uma amostra não importa |
| QUIC / HTTP/3 | Confiabilidade reimplementada por stream |
QUIC — o caso mais interessante
HTTP/3 roda sobre UDP não porque abre mão de confiabilidade, mas para reimplementá-la em espaço de usuário, por stream. Isso elimina o head-of-line blocking do TCP: a perda num stream não trava os outros. QUIC ainda funde handshake de transporte e TLS num único RTT (ou zero, em reconexão) e sobrevive à troca de rede sem reconectar.
Trade-offs
Ganha-se latência mínima e controle total; perde-se tudo que o TCP dá de graça. Se a aplicação precisa de confiabilidade, ela terá de implementar ACK, ordenação e retransmissão — e fazer isso bem é difícil.
Há um risco de rede frequentemente ignorado: UDP não tem controle de congestionamento. Um emissor agressivo pode saturar o enlace e prejudicar todo o tráfego que compartilha o caminho. Também é o transporte preferido para amplificação em ataques DDoS, por não exigir handshake.
Na prática, o padrão comum em jogos é híbrido: UDP para estado posicional (perda tolerável) e um canal confiável para eventos que não podem sumir.
Exemplo prático
Um jogo envia a posição dos jogadores 60 vezes por segundo. O pacote 42 se perde.
Com TCP, o pacote 43 — que já chegou — fica retido até o 42 ser retransmitido. O jogador vê um congelamento e depois um salto.
Com UDP, o pacote 43 é entregue na hora. A posição do pacote 42 nunca chega e não faz falta: ela já foi superada por uma mais recente. O resultado é um movimento visivelmente mais fluido — obtido justamente por abrir mão da garantia.
Relacionado
Parte de Communication · roadmap.sh/system-design