TCP e UDP são os dois protocolos da camada de transporte que você vai encontrar em toda e qualquer rede. Eles resolvem o mesmo problema — transportar dados entre duas aplicações — mas fazem isso de formas completamente diferentes.
Entender a diferença não é decorar uma tabela comparativa. É entender por que cada protocolo existe e o que você abre mão quando escolhe um ou outro.
O que a camada de transporte faz
Antes de comparar TCP e UDP, vale entender o que os dois têm em comum: ambos operam na camada 4 do modelo OSI.
A camada de transporte é responsável por levar dados de uma aplicação em um host até uma aplicação em outro host. Para isso, ela usa portas: números que identificam qual processo está enviando e qual está recebendo.
O IP leva o pacote até o host certo. A camada de transporte, via porta, leva os dados até a aplicação certa dentro desse host.
TCP e UDP fazem essa entrega de formas distintas. A diferença começa na conexão.
TCP: confiável, ordenado, com custo
TCP significa Transmission Control Protocol. É orientado à conexão: antes de qualquer dado de aplicação trafegar, os dois lados estabelecem uma sessão via 3-Way Handshake (SYN, SYN-ACK, ACK).
Depois da conexão estabelecida, o TCP garante três coisas:
Entrega. Cada segmento precisa ser confirmado pelo destinatário. Se a confirmação não chega dentro do timeout, o remetente retransmite.
Ordem. Segmentos podem chegar fora de ordem na rede. O TCP usa números de sequência para remontar os dados na ordem correta antes de entregar à aplicação.
Controle de fluxo. O receptor informa ao remetente quanto buffer tem disponível (janela de recepção). O remetente não envia mais do que o receptor consegue processar.
Tudo isso tem custo: overhead de cabeçalho maior, latência do handshake, retransmissões quando há perda. O TCP é mais lento, mas entrega.
UDP: rápido, sem garantias, sem conexão
UDP significa User Datagram Protocol. Não faz handshake. Não confirma entrega. Não reordena pacotes. Não controla fluxo.
O UDP envia o datagrama e não sabe — nem se importa — se chegou.
O cabeçalho UDP tem apenas 8 bytes: porta de origem, porta de destino, comprimento e checksum. O cabeçalho TCP tem 20 bytes no mínimo, podendo chegar a 60 com opções.
Essa simplicidade tem valor real. O UDP adiciona latência mínima sobre o IP. Para aplicações onde velocidade importa mais do que entregar cada pacote, o UDP é a escolha certa.
A tabela que o CCNA cobra
| Característica | TCP | UDP |
|---|---|---|
| Orientado à conexão | Sim (3-Way Handshake) | Não |
| Garantia de entrega | Sim (ACK + retransmissão) | Não |
| Ordenação de pacotes | Sim (número de sequência) | Não |
| Controle de fluxo | Sim (janela de recepção) | Não |
| Velocidade relativa | Menor | Maior |
| Tamanho do cabeçalho | 20–60 bytes | 8 bytes |
| Confiabilidade | Alta | Baixa |
Quando usar TCP
Use TCP quando a perda de dados é inaceitável.
HTTP e HTTPS. Cada byte de uma página web precisa chegar. Um pacote perdido no meio do HTML ou do JavaScript quebra a aplicação.
SSH e Telnet. Sessões interativas de terminal. Um comando enviado incompleto é um problema real.
FTP e SFTP. Transferência de arquivos. Um arquivo corrompido por pacote perdido é inútil.
SMTP, IMAP, POP3. Email. Mensagens precisam chegar íntegras.
Banco de dados. Qualquer protocolo de banco de dados (MySQL, PostgreSQL, Oracle) usa TCP porque integridade transacional não é negociável.
A regra prática: se a aplicação não consegue funcionar com dados faltando ou fora de ordem, use TCP.
Quando usar UDP
Use UDP quando velocidade e baixa latência importam mais do que entregar cada pacote.
DNS. Consultas DNS são pequenas e rápidas. Se uma resposta não chega, o cliente simplesmente reenvia a consulta. O overhead do TCP para uma consulta de 30 bytes não faz sentido.
DHCP. Descoberta e oferta de endereços IP via broadcast. UDP é o único protocolo que funciona aqui porque o cliente ainda não tem IP para estabelecer uma conexão TCP.
Streaming de vídeo e áudio. Um frame de vídeo perdido é melhor do que pausar a reprodução esperando retransmissão. O usuário nem percebe um frame pulado. Percebe quando o vídeo trava.
VoIP. Chamadas de voz em tempo real. Latência alta é mais prejudicial do que um pacote perdido ocasional. Um pacote atrasado em VoIP é mais inútil do que um pacote perdido.
SNMP. Gerenciamento de rede. Polling periódico de dispositivos. Se uma resposta não chega, o sistema tenta de novo no próximo ciclo.
TFTP. Trivial File Transfer Protocol — a versão simplificada do FTP usada para carregar firmware e configurações em equipamentos de rede. Usa UDP e implementa sua própria lógica de confirmação de forma simples.
A regra prática: se a aplicação tolera perda e a latência do TCP é um problema real, use UDP.
O caso do DNS: começa UDP, termina TCP
O DNS usa UDP por padrão, na porta 53. Mas há um caso em que o DNS usa TCP: quando a resposta é maior que 512 bytes (ou 4096 bytes com EDNS), o servidor responde com o bit TC (Truncated) ativado e o cliente refaz a consulta usando TCP.
Transferências de zona entre servidores DNS (AXFR) também usam TCP, porque o volume de dados é grande e a integridade é crítica.
Isso é relevante para troubleshooting: se você bloqueou TCP na porta 53 no firewall, pode estar quebrando resolução DNS para domínios com respostas grandes.
O caso do QUIC: UDP com confiabilidade da aplicação
QUIC é o protocolo de transporte desenvolvido pelo Google e padronizado como base do HTTP/3. Ele roda sobre UDP mas implementa, na camada de aplicação, controle de fluxo, ordenação e confirmação de entrega.
Por que UDP e não TCP? Porque o TCP tem head-of-line blocking: se um segmento se perde, todos os segmentos seguintes ficam bloqueados esperando a retransmissão. O QUIC resolve isso por stream — um pacote perdido em um stream não bloqueia os outros.
O QUIC aparece no blueprint CCNA 200-301 v1.1 como parte dos fundamentos de rede. Entender que "UDP não garante entrega" não significa que aplicações sobre UDP não possam implementar confiabilidade própria é a distinção que questões mais avançadas testam.
Portas que o CCNA cobra por protocolo
TCP:
| Porta | Protocolo |
|---|---|
| 20, 21 | FTP (dados e controle) |
| 22 | SSH |
| 23 | Telnet |
| 25 | SMTP |
| 80 | HTTP |
| 110 | POP3 |
| 143 | IMAP |
| 443 | HTTPS |
UDP:
| Porta | Protocolo |
|---|---|
| 53 | DNS (também TCP para zonas) |
| 67, 68 | DHCP (servidor e cliente) |
| 69 | TFTP |
| 123 | NTP |
| 161, 162 | SNMP |
Ambos (TCP e UDP):
| Porta | Protocolo |
|---|---|
| 53 | DNS |
O que o CCNA pergunta sobre TCP vs UDP
Qual protocolo usar para transferência de arquivo confiável? TCP. FTP usa TCP nas portas 20 e 21.
Por que o DHCP usa UDP? Porque o cliente ainda não tem endereço IP para estabelecer uma conexão TCP. UDP permite broadcast sem conexão prévia.
Um administrador quer priorizar tráfego de voz na rede. Qual protocolo o VoIP usa? UDP. Latência é mais crítica do que garantia de entrega.
Qual protocolo garante que dados chegam na ordem correta? TCP, via números de sequência.
Qual o tamanho do cabeçalho UDP? 8 bytes. Questão direta que aparece com frequência.
Uma aplicação de streaming não consegue tolerar pausas de buffer. Qual protocolo faz mais sentido? UDP. A perda ocasional de pacote é preferível à latência de retransmissão.
Como identificar na análise de tráfego
No Wireshark, o campo Protocol na coluna de captura mostra TCP ou UDP diretamente. No campo Info, conexões TCP mostram as flags (SYN, ACK, FIN). Datagramas UDP mostram simplesmente a porta de origem e destino.
Em um roteador Cisco, show ip socket lista as conexões ativas com o protocolo de transporte. netstat -an em um host Linux ou Windows mostra o mesmo.
Para ACLs estendidas, você especifica o protocolo:
ip access-list extended BLOQUEAR_TELNET
deny tcp any any eq 23
permit ip any any
O tcp e o udp na ACL são o protocolo de camada 4. Se você usar ip, a ACL se aplica a ambos.
▌ TCP, UDP e portas de protocolo são cobrados em todas as simulações de prova CCNA. O diagnóstico gratuito do PacketPass identifica em 20 questões onde estão suas lacunas nesse domínio — resultado por área na hora, sem cadastro.
Este artigo cobre TCP e UDP conforme o blueprint CCNA 200-301 atual, domínio Network Fundamentals.