Dia 1: Fundamentos de Redes — OSI vs TCP/IP e Conceitos Essenciais

Toda a comunicação na Internet — desde o browser que abre uma página até ao email que chega ao telemóvel — assenta em dois modelos teóricos: o modelo OSI, com sete camadas, e a pilha TCP/IP, com quatro. Compreender a diferença entre ambos não é um exercício académico: quando o ping falha mas o curl funciona, saber em que camada o problema está poupa horas de diagnóstico. Este artigo percorre cada camada com exemplos práticos em Linux e Windows, termina com uma tabela de erros comuns e um checklist de revisão.

As fontes principais são os RFCs originais (RFC 1122, RFC 791, RFC 793, RFC 768) e a documentação IANA para portos atribuídos, todos validados e acessíveis em Agosto de 2026. Para comandos práticos, as man pages do Linux (ip.8, ping.8) servem de referência canónica.

O Modelo OSI — As Sete Camadas

O modelo de referência OSI (Open Systems Interconnection) foi publicado pela ISO em 1984 como padrão teórico para descrever como sistemas de comunicação interoperam. Divide o processo de comunicação em sete camadas, cada uma responsável por uma função específica. Embora raramente implementado literalmente em produtos reais, o OSI é o vocabulário universal que engenheiros de rede usam para descrever problemas: “isso é um problema de Camada 3” ou “o switch é de Camada 2”.

A regra mnemónica clássica, de baixo para cima, é “Para a Internet Todo o Sistema Precisa de Tratamento Adequado” — Física, Ligação de Dados, Rede, Transporte, Sessão, Apresentação, Aplicação. Na prática, as camadas 5 e 6 (Sessão e Apresentação) fundem-se frequentemente com a Camada 7 na pilha TCP/IP.

A unidade de dados de cada camada chama-se PDU (Protocol Data Unit). Na Camada 4 é um segmento (TCP) ou datagrama (UDP), na Camada 3 é um pacote, na Camada 2 é uma trama e na Camada 1 é um bit. Saber o nome correcto da PDU em cada camada ajuda a ler documentação técnica e a descrever problemas com precisão.

Uma analogia útil: imaginemos uma carta enviada pelo correio. O conteúdo (a mensagem) é a Camada 7. O envelope com o remetente e destinatário é a Camada 3 (endereçamento lógico). O carteiro que transporta a carta entre cidades é a Camada 2 (ligação entre nós adjacentes). O camião e a estrada são a Camada 1 (meio físico). Cada camada usa a camada inferior sem precisar de saber como ela funciona internamente — é o princípio da encapsulação, que veremos em detalhe mais abaixo.

A Pilha TCP/IP — Quatro Camadas

A pilha TCP/IP é o modelo efectivamente implementado na Internet. Desenvolvida nos anos 70 pelo DoD (Department of Defense) dos EUA, precede o OSI em quase uma década. Em vez de sete camadas teóricas, define quatro camadas práticas que mapeiam directamente para os protocolos que correm em cada router, switch e sistema operativo do planeta. O RFC 1122 (“Requirements for Internet Hosts — Communication Layers”) é a especificação canónica destas camadas.

A diferença principal é que o TCP/IP funde as camadas 5, 6 e 7 do OSI numa única camada de Aplicação, e junta as camadas 1 e 2 numa camada de Acesso à Rede. Isto reflecte a realidade: HTTP trata formatação (Apresentação) e gestão de sessão (Sessão) dentro do próprio protocolo, sem precisar de camadas separadas. O TLS, que tecnicamente é Apresentação no OSI, é implementado como biblioteca dentro da aplicação.

A camada de Internet (equivalente à Camada 3 do OSI) é onde o IP opera. O IP é não-fiável por desenho: não garante entrega, não garante ordem, não detecta congestionamento. Essas garantias — quando necessárias — são responsabilidade da camada de Transporte (TCP). O UDP, por outro lado, partilha a filosofia do IP: envia e espera o melhor. Esta separação de responsabilidades é o princípio fundamental que torna a Internet escalável.

OSI vs TCP/IP — Comparação Prática

A pergunta “qual o modelo usar?” tem uma resposta simples: use TCP/IP para implementar e diagnosticar, use OSI para descrever e ensinar. Na prática, ambos coexistem. Um engenheiro de rede diz “problema de Camada 2” (OSI) mas configura ip addr (TCP/IP, camada de Internet). A tabela seguinte resume as diferenças que importam no dia-a-dia.

Quando alguém diz “é um problema de Camada 3”, está a usar o vocabulário OSI para identificar que o problema está no roteamento/endereçamento IP. Quando configura ip route add pré-definida via 192.168.1.1, está a operar na camada de Internet do TCP/IP. Ambos descrevem a mesma realidade — o OSI é mais granular, o TCP/IP é mais pragmático.

Encapsulamento e Desencapsulamento

Encapsulamento é o processo pelo qual cada camada adiciona o seu próprio cabeçalho (header) aos dados recebidos da camada superior. Quando uma aplicação envia dados, a camada de Aplicação entrega os dados à camada de Transporte, que acrescenta o cabeçalho TCP (com portos de origem e destino, números de sequência, flags). A camada de Internet acrescenta o cabeçalho IP (com endereços IP de origem e destino). A camada de Acesso à Rede acrescenta o cabeçalho Ethernet (com endereços MAC). O resultado é uma trama que viaja pelo meio físico.

No destino, o processo inverso — desencapsulamento — remove cada cabeçalho camada a camada, até os dados chegarem à aplicação. Vejamos o fluxo completo com um exemplo concreto: o browser pede https://kbase.pt/.

O comando seguinte mostra os cabeçalhos de cada camada numa captura real. O tcpdump captura tramas Ethernet (Camada 2) e mostra os cabeçalhos IP (Camada 3) e TCP (Camada 4) dentro delas — o encapsulamento tornado visível.

# Capturar 3 pacotes na interface eth0 e mostrar cabeçalhos completos
# -n: não resolver nomes (mais rápido)
# -S: números de sequência absolutos
# -e: mostrar cabeçalho Ethernet (Camada 2)
sudo tcpdump -i eth0 -n -S -e -c 3

# Saída típica (formato simplificado):
# 14:30:22.123456 aa:bb:cc:11:22:33 > dd:ee:ff:44:55:66, ethertype IPv4 (0x0800),
#   length 74: 192.168.1.100.54321 > 93.104.209.176.443: Flags [S],
#   seq 1234567890, win 64240, [mss 1460,sackOK,TS val 123,nop,wscale 7], length 0

Nesta linha de saída, aa:bb:cc:11:22:33 > dd:ee:ff:44:55:66 é a Camada 2 (MAC origem → MAC destino). 192.168.1.100.54321 > 93.104.209.176.443 é Camada 3 (IP) e Camada 4 (porto) combinadas. Flags [S] indica um SYN TCP — o primeiro passo do three-way handshake. Este único comando mostra as três camadas inferiores a funcionar em conjunto.

Para quem usa Windows, o equivalente é o pktmon (disponível desde Windows 10 1809) ou o netsh trace. O pktmon é particularmente útil porque mostra o encapsulamento de forma estruturada, embora o saída seja menos compacto que o tcpdump.

O tamanho máximo de dados que uma trama pode transportar chama-se MTU (Maximum Transmission Unit). Em Ethernet padrão, o MTU é 1500 bytes. Se um pacote IP excede o MTU, é fragmentado (IPv4) ou descartado com ICMP “Packet Too Big” (IPv6, RFC 8200). A fragmentação degrada performance e deve ser evitada — o Dia 2 (IPv4 e Subnetting) aborda o impacto prático do MTU no dimensionamento de subredes.

Endereços MAC vs Endereços IP

Uma das confusões mais frequentes em iniciantes é a diferença entre endereço MAC e endereço IP. A distinção é fundamental: o endereço MAC identifica fisicamente uma interface de rede (NIC) e é atribuído pelo fabricante — não muda quando o dispositivo se move de rede. O endereço IP identifica logicamente um host numa rede específica e muda quando o dispositivo se liga a uma rede diferente.

Analogia: o MAC é como a matrícula do carro — única, atribuída na fábrica, não muda. O IP é como o endereço de casa — depende de onde o carro está estacionado. Para enviar uma carta, precisa do endereço (IP); para identificar o carro no parque, usa a matrícula (MAC). O protocolo ARP (Address Resolution Protocol, RFC 826) faz a ponte: dado um IP local, descobre o MAC correspondente.

Para ver os endereços MAC e IP das interfaces no Linux, usa-se o comando ip. No Windows, o equivalente é ipconfig /all ou Get-NetAdapter em PowerShell. O comando ip link show mostra o MAC (campo link/ether) e o ip addr show mostra ambos MAC e IP.

# Ver todas as interfaces, MACs e IPs (Linux)
ip addr show

# Output resumido:
# 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP
#     link/ether aa:bb:cc:11:22:33 brd ff:ff:ff:ff:ff:ff     ← MAC (Camada 2)
#     inet 192.168.1.100/24 brd 192.168.1.255 scope global eth0  ← IPv4 (Camada 3)
#     inet6 fe80::a8bb:ccff:fe11:2233/64 scope link           ← IPv6 link-local

# Descobrir o MAC associado a um IP local (tabela ARP)
ip neigh show

# Saída típica:
# 192.168.1.1 dev eth0 lladdr dd:ee:ff:44:55:66 REACHABLE
#                ↑ IP (Camada 3)         ↑ MAC (Camada 2)

# Equivalente Windows (PowerShell):
# Get-NetAdapter | Select-Object Name, MacAddress, Status
# Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress
# arp -a

No saída de ip addr show, link/ether é o MAC da interface, inet é o IPv4 e inet6 é o IPv6. O /24 após o IPv4 é a máscara de subrede em notação CIDR — tema do Dia 2. O fe80:: é um endereço IPv6 link-local, automaticamente configurado e usado para comunicação dentro do mesmo segmento.

A tabela ARP (ip neigh show em Linux, arp -a em Windows) é a bridge entre Camada 2 e Camada 3: para cada IP local conhecido, guarda o MAC correspondente. Se a tabela ARP não tem a entrada para um IP, o hospedeiro envia um difusão ARP “Who has 192.168.1.1?” e o dono desse IP responde com o seu MAC.

Portos TCP e UDP — Como Aplicações se Identificam

Um endereço IP identifica um host, mas um host corre múltiplas aplicações simultaneamente. Como sabe o sistema operativo qual aplicação deve receber um pacote que chega? A resposta são os portos — números de 16 bits (0 a 65535) que identificam um processo ou serviço dentro de um host. Os portos operam na Camada 4 (Transporte) e são geridos pelo TCP e UDP.

A IANA divide os portos em três ranges. Os portos bem conhecidos (0-1023) requerem privilégios administrativos em Unix e estão atribuídos a serviços padrão: HTTP (80), HTTPS (443), SSH (22), DNS (53), SMTP (25). Os portos registados (1024-49151) são usados por aplicações específicas. Os portos dinâmicos/efémeros (49152-65535) são atribuídos temporariamente pelo SO às ligações de saída.

A diferença entre TCP e UDP é central para entender o comportamento das aplicações. O TCP (Transmission Control Protocol, RFC 793) é orientado a ligação: estabelece uma sessão com o three-way handshake (SYN → SYN-ACK → ACK), garante entrega, ordem e controlo de fluxo. É usado por HTTP, SSH, SMTP — aplicações onde perder dados não é aceitável. O UDP (User Datagram Protocol, RFC 768) é não-orientado a ligação: envia datagramas sem garantia de entrega ou ordem. É usado por DNS, NTP, VoIP, streaming — aplicações onde velocidade importa mais que fiabilidade absoluta, ou onde a aplicação implementa as suas próprias garantias.

O QUIC (Quick UDP Internet Connections, RFC 9000) é a evolução moderna: corre sobre UDP mas implementa fiabilidade, encriptação (TLS 1.3 integrado) e multiplexação de streams dentro do próprio protocolo. É a base do HTTP/3, usado hoje por Google, Cloudflare e Facebook. O QUIC demonstra que a camada de transporte continua a evoluir — os fundamentos não mudam, mas as implementações sim.

Para ver que portos estão abertos e à escuta no Linux, usa-se ss (substituto moderno do netstat). No Windows, netstat -an ou Get-NetTCPConnection em PowerShell.

# Ver portos TCP à escuta (Linux)
ss -tlnp

# -t: TCP apenas
# -l: à escuta (listening) apenas
# -n: não resolver nomes (portos como números)
# -p: mostrar processo associado (requer root)

# Saída típica:
# State   Recv-Q  Send-Q  Local Address:Port  Peer Address:Port  Process
# LISTEN  0       128     0.0.0.0:22          0.0.0.0:*          sshd
# LISTEN  0       128     0.0.0.0:80          0.0.0.0:*          nginx
# LISTEN  0       128     0.0.0.0:443         0.0.0.0:*          nginx
# LISTEN  0       128     127.0.0.1:53        0.0.0.0:*          named

# Ver portos UDP (não há "listening" em UDP — é "open")
ss -ulnp

# Ver todas as ligações estabelecidas (TCP + UDP)
ss -tunap

# Equivalente Windows (PowerShell):
# Get-NetTCPConnection -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess
# Get-NetUDPEndpoint | Select-Object LocalAddress,LocalPort,OwningProcess

A saída mostra que o sshd está à esculta no porto 22, o nginx nos portos 80 e 443, e o named (DNS) no porto 53 mas apenas em 127.0.0.1 (localhost). A coluna Local Address indica em que interface o serviço escuta: 0.0.0.0 significa todas as interfaces (acessível externamente); 127.0.0.1 significa apenas local.

Para uma lista completa e actualizada de portos atribuídos, a referência canónica é o registo IANA (Service Names and Port Numbers). O kbase.pt tem também uma listagem de portos mais comuns e protocolos com os portos que mais aparecem em ambientes PME.

Ferramentas Essenciais de Diagnóstico

Cada camada do modelo tem ferramentas de diagnóstico associadas. Saber qual ferramenta usar para cada camada é a base do troubleshooting estruturado — em vez de tentar ferramentas ao acaso, começa-se na camada física e sobe-se até à camada de aplicação. O Dia 19 (Diagnóstico de Rede) aprofunda esta metodologia; aqui ficam as ferramentas essenciais para cada camada.

O fluxo de diagnóstico recomendado é de baixo para cima: verificar primeiro a Camada 1 (a interface tem link?), depois Camada 2 (o MAC e ARP estão correctos?), Camada 3 (o ping ao gateway funciona?), Camada 4 (o porto de destino está acessível?) e finalmente Camada 7 (o curl ao serviço funciona?). Embora o top-down também funcione em alguns casos, o de baixo para cima é mais sistemático para problemas de conectividade.

Os comandos seguintes demonstram o fluxo completo, da Camada 1 à Camada 7, num host Linux. Cada comando testa uma camada específica — se um falha, não adianta testar camadas superiores até o resolver.

# Camada 1 — A interface tem link físico?
ip link show eth0
# Procurar: state UP (link activo)

# Camada 2 — O MAC está correcto? ARP resolve o gateway?
ip neigh show | grep 192.168.1.1
# Procurar: 192.168.1.1 lladdr dd:ee:ff:44:55:66 REACHABLE

# Camada 3 — O ping ao gateway funciona?
ping -c 3 192.168.1.1
# Procurar: 3 packets transmitted, 3 received, 0% packet loss

# Camada 3 — E para a Internet? (testa roteamento + DNS)
ping -c 3 1.1.1.1
# Se falhar: problema de roteamento ou firewall

# Camada 7 — DNS resolve?
dig kbase.pt +short
# Procurar: 93.104.209.176 (ou IP actual)

# Camada 7 — HTTP funciona?
curl -sI https://kbase.pt/ | head -5
# Procurar: HTTP/2 200 (ou HTTP/1.1 301/302 redirect)

# Se o ping funciona mas o curl falha:
# → Problema de Camada 4 (porto bloqueado) ou Camada 7 (TLS, aplicação)

Este fluxo de baixo para cima é a metodologia base que será aprofundada no Dia 19 (Diagnóstico de Rede com tcpdump, Wireshark, traceroute e mtr). Para já, o importante é interiorizar a associação camada → ferramenta. Se o ping ao gateway funciona mas o ping a 1.1.1.1 falha, o problema está na Camada 3 (roteamento ou firewall). Se o ping a 1.1.1.1 funciona mas o curl falha, o problema está na Camada 4 ou 7 (porto bloqueado, TLS, aplicação).

Algumas destas ferramentas podem não estar instaladas por defeito. O mtr e o dig em particular costumam exigir instalação explícita. Em Debian/Ubuntu: sudo apt install mtr-tiny dnsutils. Em RHEL/Fedora: sudo dnf install mtr bind-utils. Em Arch: sudo pacman -S mtr bind. O ping, ip, ss e curl vêm pré-instalados na maioria das distribuições.

Erros Comuns em Iniciantes

Quando se aprende o modelo OSI e a pilha TCP/IP, certos erros de compreensão repetem-se. A tabela seguinte lista os mais frequentes, a causa e como corrigir a percepção.

Checklist de Revisão

Antes de avançar para o Dia 2 (IPv4 — Classes, Subnetting, CIDR e VLSM), confirme que domina os seguintes pontos:

1. Sabe nomear as 7 camadas do OSI e as 4 do TCP/IP, de baixo para cima e de cima para baixo.
2. Sabe em que camada operam os protocolos mais comuns: Ethernet (2), IP (3), TCP/UDP (4), HTTP/DNS/SSH (7).
3. Explica a diferença entre MAC e IP sem hesitar — físico/local vs lógico/global.
4. Sabe o que é encapsulamento e por que ordem os cabeçalhos são adicionados (App → Transporte → Internet → Acesso).
5. Corre ip addr show e identifica MAC, IPv4, IPv6 e máscara CIDR no saída.
6. Corre ss -tlnp e identifica que portos estão abertos e que processos os usam.
7. Sabe a diferença entre TCP e UDP e quando usar cada um (fiabilidade vs latência).
8. Aplica o fluxo de diagnóstico de baixo para cima: Camada 1 → 2 → 3 → 4 → 7.

Artigos Relacionados

• Listagem de Portos mais Comuns e Protocolos — referência rápida de portos TCP/UDP que aparece em ambientes PME
• Dia 8 do Curso Linux: Redes Linux — ip, ss, nmcli e DNS — comandos práticos de rede em Linux, complementa este artigo
• Diagnóstico de Rede Windows — equivalentes Windows das ferramentas aqui apresentadas (ping, tracert, netsh)
• VLANs e Switching: Segmentação de Rede Empresarial — aprofunda a Camada 2 (switching, VLANs, 802.1Q)
• Configuração e Diagnóstico de NIC em Linux — detalha ethtool, configuração de interfaces e resolução de problemas físicos
• Nmap Cheat Sheet: Comandos Essenciais para Auditoria de Rede — descoberta de hosts e portos, complementa o diagnóstico de Camada 3 e 4