A IDEIA CENTRAL
Ligação telefônica ou envio de cartas?
Os dois protocolos trabalham sobre o IP e usam portas para entregar dados à aplicação correta. A grande diferença está no acordo feito antes do envio e nas garantias oferecidas durante a conversa.
TCP · COMO UMA LIGAÇÃO
Primeiro conecta, depois conversa
Cliente e servidor estabelecem uma conexão. A partir daí, o TCP acompanha o fluxo, confirma o recebimento, retransmite perdas e entrega os bytes na ordem.
- Antes: há um handshake.
- Durante: os dois lados mantêm estado da conexão.
- Entrega: fluxo confiável e ordenado.
- Modelo: comunicação ponto a ponto.
UDP · COMO UMA CARTA
Prepara a mensagem e envia
Cada datagrama é independente. O UDP não negocia uma conexão antes do primeiro envio nem promete que a mensagem chegará, chegará uma única vez ou na ordem.
- Antes: não há handshake do UDP.
- Durante: cada datagrama segue por conta própria.
- Entrega: melhor esforço da rede.
- Modelo: unicast, multicast ou broadcast, quando a rede permite.
O “ACORDO” DA CONEXÃO
O TCP confirma que os dois lados estão prontos.
No TCP, cliente e servidor coordenam a conexão com três mensagens. No UDP, o primeiro datagrama já pode carregar os dados da aplicação. Alterne os modos e avance a animação.
Laboratório visual · Antes dos dados
Compare o handshake do TCP com o envio direto do UDP.
TCP preparado: ainda não há conexão. O cliente iniciará o acordo antes de enviar os dados da aplicação.
UM PARA UM · UM PARA MUITOS
Multicast evita que a origem envie uma cópia para cada participante.
No unicast, cada destinatário recebe um fluxo individual. No multicast IP, os receptores entram em um grupo e a rede replica o datagrama somente onde os caminhos se separam.
Laboratório visual · Unicast × multicast
Imagine a mesma aula ao vivo chegando a três salas de uma rede institucional.
Unicast: a origem mantém três comunicações independentes e envia três cópias do mesmo conteúdo.
Recebe quem participa
Os receptores interessados entram em um endereço de grupo multicast. Um dispositivo que não participa do grupo não deve receber a transmissão.
A rede copia nos pontos certos
A origem envia um datagrama. Roteadores e switches compatíveis replicam o tráfego onde os caminhos para os membros se dividem.
Depende da infraestrutura
Multicast precisa ser habilitado e administrado na rede. Ele não atravessa toda a Internet pública como uma conexão Web comum.
Não é um recurso do TCP
TCP cria conexões ponto a ponto. Multicast normalmente transporta datagramas UDP sobre o mecanismo de grupos oferecido pelo IP.
RESUMO PARA DECIDIR
A natureza dos dados indica o transporte.
| Pergunta | TCP | UDP |
|---|---|---|
| Há acordo antes dos dados? | Sim. A conexão começa com handshake. | Não há handshake do UDP. |
| Como os dados aparecem? | Como um fluxo contínuo de bytes. | Como mensagens independentes: datagramas. |
| O transporte recupera perdas? | Sim, confirma e retransmite para entregar em ordem. | Não. O protocolo superior decide se e como recuperar. |
| Como os participantes se relacionam? | Uma conexão entre dois pontos. | Pode ser unicast e, com suporte da rede IP, multicast ou broadcast. |
| Quando costuma fazer sentido? | Quando integridade e ordem são essenciais. | Quando mensagens são independentes, tempo é crítico ou um protocolo superior adiciona garantias. |
MAPA PARA AS PRÓXIMAS AULAS
TCP e UDP são a estrada; os protocolos de aplicação definem a conversa.
HTTP, WebSocket, MQTT e DNS não competem diretamente com TCP ou UDP. Eles ficam acima do transporte e escolhem a base adequada para suas mensagens.
HTTP/1.1 e HTTP/2
Normalmente usam TCP. Quando há HTTPS, o TLS protege a comunicação acima da conexão TCP.
HTTP → TLS → TCP → IPHTTP/3 e QUIC
HTTP/3 usa QUIC, construído sobre UDP. O QUIC acrescenta conexão, segurança, confiabilidade por stream e controle de congestionamento.
HTTP/3 → QUIC → UDP → IPWebSocket
Começa com um handshake HTTP e mantém comunicação bidirecional. O WebSocket clássico funciona sobre TCP.
WebSocket → TCP → IPMQTT
O MQTT convencional normalmente usa TCP e também pode passar por WebSocket. Seu modelo é publicar e assinar tópicos.
MQTT → TCP → IPDNS
Consultas comuns frequentemente usam UDP; o DNS também usa TCP quando necessário. A escolha faz parte das regras do próprio DNS.
DNS → UDP ou TCP → IPMídia e jogos em tempo real
Muitos protocolos usam UDP quando uma atualização recente vale mais que uma antiga. Eles podem acrescentar sequência, segurança e recuperação seletiva.
Protocolo de mídia/jogo → UDP → IPPARE E PENSE
Se o HTTP/3 usa UDP, então o navegador pode simplesmente aceitar partes perdidas de uma página?
Considere que UDP é apenas uma das camadas da pilha.
CONTINUE EXPLORANDO
Referências e itens adicionais de estudo
Referências técnicas
Documentos oficiais usados na construção da aula.
- RFC 9293 · Transmission Control Protocol — conexão, fluxo confiável e operação do TCP.
- RFC 768 · User Datagram Protocol — definição essencial dos datagramas UDP.
- RFC 1112 · IP Multicasting — participação em grupos multicast IPv4.
- RFC 9000 · QUIC — transporte seguro e confiável construído sobre UDP.
Itens adicionais de estudo
Atividades curtas para consolidar as relações.
- Abra o Wireshark e identifique as mensagens
SYN,SYN+ACKeACKde uma conexão TCP. - No DevTools do navegador, compare requisições negociadas como
h2eh3. - Desenhe as pilhas de HTTP/2 e HTTP/3 e destaque onde TCP, QUIC e UDP aparecem.
- Pesquise por que uma IPTV institucional pode usar multicast, enquanto um streaming público normalmente usa CDN e unicast.
- Classifique DNS, WebSocket e MQTT por protocolo de aplicação e transporte normalmente utilizado.