Trilha 10 · Internet e redes

TCP: conexão confiável

A internet descarta pacotes sem avisar. O TCP é a camada que garante que eles chegam, em ordem e sem erros.

① Intuição

O carteiro que pede confirmação

Imagina mandar uma carta e só saber que chegou quando o destinatário te ligar confirmando. O TCP faz exatamente isso: cada segmento enviado espera um ACK (acknowledgement) do receptor. Se o ACK não chega em tempo, o segmento é retransmitido.

Para isso funcionar, cliente e servidor precisam primeiro se apresentar — o famoso 3-way handshake (aperto de mãos triplo). Só depois de estabelecida a conexão é que os dados começam a fluir.

TCP é orientado a fluxo, não a mensagens. Ao contrário do UDP, o TCP não sabe onde termina uma mensagem e começa a próxima — ele só garante que os bytes chegam em ordem. Quem define o "fim" da mensagem é o protocolo de aplicação (HTTP, por exemplo, usa Content-Length).
② Visualização interativa

Veja o handshake e a transferência de dados

Clique em Iniciar para ver a conexão TCP acontecer: conexão (3 mensagens), dados (HTTP) e encerramento (4 mensagens).

Conexão (3-way handshake)
Transferência de dados
Encerramento (4-way)
💻 Cliente
🖥️ Servidor
SYNseq=1000
────►
◄────
SYN-ACKseq=2000, ack=1001
ACKack=2001
────►
HTTP GET /seq=1001, len=78
────►
◄────
HTTP 200 OKseq=2001, ack=1079
ACKack=2501
────►
FINseq=2002
────►
◄────
ACKack=2003
◄────
FINseq=2501
ACKack=2502
────►
③ Explicação técnica

A estrutura de um segmento TCP

# Estrutura de um segmento TCP (simplificado)
┌──────────────┬──────────────┐
│ Porta origem │ Porta destino│  16 bits cada
├──────────────┴──────────────┤
│       Número de sequência   │  32 bits — identifica os bytes
├─────────────────────────────┤
│         Número de ACK       │  32 bits — confirma recebimento
├──────┬──────────────────────┤
│ Flags│ SYN ACK FIN RST PSH │  SYN=iniciar, ACK=confirmar, FIN=encerrar
├──────┴──────────────────────┤
│        Janela (Window)      │  controle de fluxo
├─────────────────────────────┤
│            Dados…           │
└─────────────────────────────┘

TCP vs. UDP

# TCP vs UDP: escolha certa para cada caso

TCP (confiável, ordenado, com handshake):
  ✓ HTTP/HTTPS, SSH, e-mail (SMTP), banco de dados
  ✗ Overhead de handshake + ACKs — não ideal para tempo real

UDP (rápido, sem conexão, sem garantias):
  ✓ Streaming de vídeo/áudio — um frame perdido é ok, atraso não
  ✓ Jogos online — latência importa mais que confiabilidade
  ✓ DNS — uma pergunta e uma resposta, rápido
  ✓ WebRTC — video calls no browser
Controle de congestionamento: o TCP detecta congestionamento na rede (pacotes sendo descartados por roteadores cheios) e reduz automaticamente a taxa de envio. Algoritmos como CUBIC e BBR são usados por kernels Linux modernos para maximizar throughput sem sobrecarregar a rede.
④ Projeto para programar

Implemente sobre sockets TCP

Mini projeto: crie um servidor TCP simples em Python que aceita conexões, lê uma linha de texto e responde com ela em maiúsculas (echo server). Teste com telnet localhost 8080 ou nc localhost 8080.

Projeto principal: implemente um chat simples: servidor aceita múltiplos clientes com threading, e toda mensagem de um cliente é retransmitida para todos os outros conectados.

Desafio extra: adicione um protocolo simples com framing: cada mensagem é prefixada pelo seu tamanho em 4 bytes (struct.pack("!I", len(msg))), para que o receptor saiba exatamente onde termina cada mensagem.

⑤ Exercícios rápidos

Teste sua intuição

Qual é a sequência correta do 3-way handshake do TCP?
Para streaming de vídeo ao vivo, qual protocolo é mais adequado e por quê?
O que faz o ACK (acknowledgement) no TCP?
⑥ Aplicações no mundo real

Onde você encontra isso

🔒

TLS sobre TCP

HTTPS é HTTP sobre TLS sobre TCP. O TLS faz seu próprio handshake depois do handshake TCP — por isso conexões seguras custam mais RTTs.

HTTP/3 e QUIC

O HTTP/3 abandona o TCP e usa QUIC (baseado em UDP), eliminando o head-of-line blocking e o overhead do handshake TCP separado.

🎮

Jogos online

FPS e jogos de ritmo usam UDP para movimentação (perda tolerável) e TCP para eventos críticos (itens coletados, dano recebido).

📡

WebRTC

Video chamadas no browser usam DTLS (TLS sobre UDP) para criptografar streams de áudio e vídeo com baixa latência.

← Anterior: DNS Próxima: HTTP e HTTPS →