A camada que entrega no processo certo — não basta chegar no computador, precisa chegar no navegador, no servidor de banco, no cliente de email. TCP, UDP e portas.
Entrega entre processos via portas — TCP confiável vs UDP rápido
A camada Internet entrega o pacote no computador certo. A camada Transporte entrega no processo certo dentro daquele computador — o navegador? o servidor SQL? o cliente de email? A ferramenta pra isso é a porta: número de 16 bits que identifica o serviço.
Dois protocolos principais: TCP (confiável, com handshake e ordem garantida) e UDP (rápido, sem garantia). A escolha depende do caso — TCP pra transferência de arquivo, UDP pra streaming. No OSI essa é exatamente a camada 4 (Transporte) — sem mudança de mapeamento.
Você manda e torce — sem conexão, sem garantia, mas rápido
O UDP (User Datagram Protocol) é o protocolo simples e rápido. Sem conexão (não tem handshake), sem garantia de entrega, sem ordem, sem retransmissão. Você manda o pacote e torce. Cabeçalho minúsculo: porta origem, porta destino, tamanho, checksum — só isso.
Quando vale a pena: streaming (perdeu um quadro? melhor pular do que travar), jogos online (latência baixa importa mais que perda de 1 pacote), DNS (consulta pequena, resposta rápida — perde? pergunta de novo), VoIP (voz não pode esperar retransmissão). Não vale pra transferência de arquivo, página web, banco de dados. No OSI seria camada 4 (Transporte).
Conexão confiável com handshake, retransmissão e ordem garantida
O TCP (Transmission Control Protocol) é o oposto do UDP: conexão estabelecida via handshake de 3 vias, confirmação de recebimento de cada pacote (ACK), retransmissão automática se não chegou, ordem garantida mesmo se os pacotes chegarem fora de ordem, e controle de fluxo pra não afogar quem está recebendo.
Praticamente tudo que precisa "chegar inteiro" usa TCP: HTTP/HTTPS (web), SSH, FTP, IMAP/SMTP (email), banco de dados. O custo é overhead — cabeçalho maior, mais idas-e-voltas, mais latência. Por isso o HTTP/3 está mudando pra QUIC (sobre UDP) tentando juntar o melhor dos dois. No OSI seria camada 4 (Transporte).
Número de 16 bits — qual processo recebe o pacote dentro do computador
A porta é um número de 16 bits (0 a 65535) que identifica o processo destinatário. O IP leva o pacote até o computador; a porta leva até o programa. Quando você acessa https://exemplo.com, na verdade vai pra exemplo.com:443 — porta 443 é o servidor HTTPS.
Três faixas: well-known (0–1023) reservadas pros serviços padrão (80=HTTP, 443=HTTPS, 22=SSH); registered (1024–49151) pra apps específicas (3306=MySQL, 5432=PostgreSQL); dynamic (49152–65535) pra conexões temporárias do cliente. Quando seu navegador conecta no servidor, ele usa uma porta dinâmica de origem que dura só o tempo da conexão. No OSI seria camada 4 (Transporte).
SYN → SYN-ACK → ACK — como TCP estabelece conexão antes de mandar dados
Antes de mandar qualquer dado, o TCP estabelece conexão com 3 mensagens: SYN (cliente: "quero conversar, número de sequência X") → SYN-ACK (servidor: "ok, recebi seu SYN, meu sequência é Y") → ACK (cliente: "recebi seu SYN-ACK, estamos conectados"). Só depois disso os dados começam a fluir.
Por que 3 e não 2? Pra ambos os lados confirmarem que conseguem mandar E receber — não basta saber só metade. O custo é uma volta inteira (round-trip) antes de qualquer dado útil. Pra fechar a conexão, existe o handshake reverso com FIN. Esse overhead é uma das razões pelas quais HTTP/3 mudou pra QUIC. No OSI seria camada 4 (Transporte).
22 SSH, 80 HTTP, 443 HTTPS, 5432 PostgreSQL — as que todo dev decora
Lista das portas que todo dev acaba decorando: 22 (SSH), 25 (SMTP — envio email), 53 (DNS), 80 (HTTP), 110 (POP3), 143 (IMAP), 443 (HTTPS), 3306 (MySQL), 5432 (PostgreSQL), 6379 (Redis), 8080 (HTTP alternativo), 27017 (MongoDB).
São convenções, não regras — você pode rodar HTTP em qualquer porta. Mas usar a padrão evita ter que digitar a porta na URL (https://site.com em vez de https://site.com:443). E facilita firewall: "libere 443" todo mundo entende. No OSI seria camada 4 (Transporte).
netstat, ss, lsof, telnet, nc, tcpdump — investigando portas e conexões
Ferramentas pra debug de camada 4. ss -tulpn (substituto moderno do netstat) mostra todas as portas em escuta e conexões ativas, com qual processo. lsof -i :8080 mostra qual processo está usando uma porta específica. telnet host porta ou nc -zv host porta testam se a porta está aberta e aceita conexão.
tcpdump -i any port 5432 captura pacotes de uma porta específica pra investigar protocolo. iptables/ufw controla firewall (libera ou bloqueia portas). Quando um serviço "não conecta", o checklist é: a porta está em escuta? o firewall libera? o cliente está mandando pra IP+porta certos? No OSI seria camada 4 (Transporte).