Notas sobre TCP/IP: As Quatro Camadas, o Handshake e a Leitura de um Pacote

Nota: Este é um conteúdo de placeholder criado para demonstrar o blog. Substitua-o pela sua própria escrita.

Estas são notas de trabalho que volto sempre que preciso explicar TCP/IP para alguém — incluindo a mim mesmo. Elas não são exaustivas; são as partes que, na minha experiência, explicam na verdade 90% do comportamento que você vê na prática.

As Quatro Camadas#

O modelo TCP/IP condensa o modelo OSI de sete camadas em quatro. Na prática, este é o modelo que a internet realmente utiliza.

Camada	Exemplos	O que ele responde
Aplicação	HTTP, SSH, DNS, SMTP, TLS	"O que estamos dizendo um ao outro?"
Transporte	TCP, UDP, QUIC	"Como fazemos isso ser confiável/rápido?"
Internet	IP (v4/v6), ICMP	"Como chegamos do ponto A ao ponto B?"
Acesso à rede	Ethernet, Wi-Fi, ARP	"Como chegamos ao próximo salto?"

Um movimento mental útil: cada camada envolve a camada acima dela. Uma requisição HTTP se torna um segmento TCP, que se torna um pacote IP, que se torna um quadro Ethernet. No receptor, cada camada desempacota e passa a carga útil para cima.

O Handshake de Três Vias#

O TCP é orientado a conexão. Antes de qualquer fluxo de dados de aplicação, os dois pontos finais devem concordar com uma sequência de números e um conjunto de capacidades. Este é o handshake de três vias:

        Cliente                               Servidor
          |                                      |
          |  ----- SYN, seq=x ---------------> |
          |                                      |
          |  <---- SYN+ACK, seq=y, ack=x+1 ---- |
          |                                      |
          |  ----- ACK, ack=y+1 --------------> |
          |                                      |
          |  ===== dados de aplicação ==========> |
          |                                      |

Em palavras:

1. O cliente envia SYN com um número de sequência inicial x.
2. O servidor responde com SYN+ACK, seu próprio número de sequência inicial y, e um ack de x+1.
3. O cliente responde com ACK e ack=y+1. A conexão agora está ESTABLISHED.

Os números de sequência existem para que cada lado possa reconhecer o que recebeu e detectar lacunas. Eles não são "números de pacote" — são contadores de bytes, e eles rolam.

Flags TCP#

O cabeçalho TCP carrega um pequeno conjunto de flags. Conhecê-los de cor torna a leitura de capturas muito mais rápida:

Flag	Significado	Definido quando…
SYN	Sincronizar números de sequência	Abrindo uma conexão
ACK	Campo de reconhecimento é válido	Após o primeiro SYN, quase sempre
FIN	O remetente terminou de enviar	Fechamento elegante, em uma direção
RST	Redefinir a conexão	Aborto, recusa ou erro
PSH	Empurrar dados para o aplicativo imediatamente	Tráfego interativo (geralmente definido com ACK)
URG	Ponteiro urgente é válido	Raro; sinal fora de banda dentro do fluxo
CWR	Janela de congestionamento reduzida	Feedback ECN
ECE	Eco ECN	Notificação Explícita de Congestionamento

SYN, ACK, FIN e RST são os quatro que você verá constantemente. PSH+ACK é como a maioria dos segmentos de dados interativos se parecem. Um RST nu geralmente é o mais interessante em um contexto de segurança — pode significar "porta fechada", "esta conexão foi rejeitada" ou "algo no meio me matou".

Estados TCP (a versão curta)#

A máquina de estados completa é genuinamente útil, mas não cabe em um post de blog. Os estados que eu realmente penso:

• LISTEN — o servidor está esperando por SYNs.
• SYN_SENT — o cliente enviou SYN, esperando por SYN+ACK.
• SYN_RECEIVED — o servidor recebeu SYN, enviou SYN+ACK, esperando por ACK.
• ESTABLISHED — handshake feito, dados fluem.
• FIN_WAIT_1, FIN_WAIT_2, CLOSE_WAIT, LAST_ACK, CLOSING, TIME_WAIT — as várias fases de desmontagem de uma conexão.

TIME_WAIT é o que morde as pessoas. Após o lado que inicia o fechamento enviar seu ACK final, ele fica em TIME_WAIT por aproximadamente dois tempos de vida máximos de segmento (geralmente 60–120 segundos). Isso é para que um duplicado atrasado do ACK final não confunda uma nova conexão que reutiliza o mesmo par de portas. Em um servidor ocupado com conexões de curta duração, soquetes TIME_WAIT se acumulam; isso é normal, não um vazamento.

Você pode ver o estado atual de cada conexão em uma caixa Linux com:

ss -tan | awk 'NR==1 || $1=="ESTAB" || $1=="TIME-WAIT"' | head

O comando ss substituiu netstat para a maioria dos casos de uso. Ele é mais rápido e lê do netlink em vez de fazer scraping de /proc.

Uma Inspeção Prática de Pacotes#

O material didático acima só realmente clica quando você o vê em uma captura. tcpdump e tshark são as duas ferramentas que eu uso, nessa ordem. tcpdump é mais rápido e está em toda caixa Linux; tshark é o que eu quero quando preciso ver campos decodificados.

Uma captura simples de uma única conexão SSH:

# Captura os primeiros 20 pacotes de tráfego TCP para a porta 22, sem resolução de DNS.
sudo tcpdump -n -c 20 'tcp port 22' -i any

Uma linha típica do tcpdump para um SYN se parece com:

10.0.0.5.54321 > 10.0.0.10.22: Flags [S], seq 1234567890, win 64240, options [mss 1460,sackOK,TS val 123 ecr 0,nop,wscale 7], length 0

Lendo-a:

• 10.0.0.5.54321 > 10.0.0.10.22 — IP.porta de origem para IP.porta de destino.
• Flags [S] — SYN. [S.] significaria SYN+ACK (o ponto é ACK).
• seq 1234567890 — número de sequência inicial.
• win 64240 — janela de recebimento que o remetente está oferecendo.
• length 0 — sem carga útil, o que faz sentido para um SYN.

Para uma análise mais aprofundada — campos decodificados, bem estruturados — tshark com saída JSON é excelente para script e para compartilhar capturas com pessoas que não querem instalar o Wireshark:

# Decodifica o mesmo tráfego e emite JSON, um objeto por pacote.
sudo tshark -i any -f 'tcp port 22' -c 3 -T json > handshake.json

Uma versão resumida do que você recebe de volta se parece com isto:

{
  "_index": "packets-2026-07-18",
  "_source": {
    "layers": {
      "ip": {
        "ip.src": "10.0.0.5",
        "ip.dst": "10.0.0.10",
        "ip.proto": "6"
      },
      "tcp": {
        "tcp.srcport": "54321",
        "tcp.dstport": "22",
        "tcp.flags": "0x00000002",
        "tcp.flags.syn": "1",
        "tcp.seq": "1234567890",
        "tcp.window_size": "64240"
      }
    }
  }
}

Esta é a mesma informação que o tcpdump mostrou para você, apenas estruturada. Útil para diff de capturas, para construir dashboards, ou para encaminhar para jq quando você está procurando por um padrão específico.

Uma Nota sobre MTU e Fragmentação#

A camada Internet (IP) é responsável por fazer um pacote atravessar múltiplos saltos. Cada salto tem uma unidade de transmissão máxima — o maior quadro que ele irá transportar. O MTU do Ethernet é tipicamente 1500 bytes. Quando um pacote é maior que o MTU do próximo salto, o IP o fragmenta (IPv4) ou o descarta e sinaliza o remetente (IPv6, com Packet Too Big ICMP).

Duas consequências práticas:

1. A descoberta de MTU de caminho importa. A maioria das pilhas modernas a fazem; firewalls mal configurados que bloqueiam ICMP podem quebrá-la silenciosamente, produzindo o clássico modo de falha "pacotes pequenos funcionam, pacotes grandes travam".
2. Os segmentos TCP devem caber. O TCP usa MSS (tamanho máximo de segmento) para negociar um tamanho de carga útil que caiba no MTU do caminho, tipicamente 1460 bytes sobre Ethernet padrão (1500 − 20 IP − 20 TCP). Este é o número que você verá nas opções do SYN.

Notas Finais#

O modelo TCP/IP é pequeno o suficiente para caber em um post de blog e profundo o suficiente para se gastar uma carreira nele. As quatro camadas explicam a estrutura; o handshake explica como as conexões começam; as flags e a máquina de estados explicam como elas se comportam (e se comportam mal); e tcpdump / tshark são como você realmente vê qualquer disso. Uma vez que você pode ler uma única linha do tcpdump com confiança, você tem a maior parte do que precisa para depurar os problemas de rede que não têm uma mensagem de erro agradável.

Para as referências canônicas, RFC 793 define o TCP (com muitas atualizações desde então), RFC 1122 é o documento de requisitos de host que codifica o que as pilhas realmente fazem, e a página man do tcpdump é uma das melhores peças de documentação escritas do mundo Unix.