O modelo Open Systems Interconnection (OSI) organiza a comunicação em rede em sete camadas, e a prova de fundamentos da F5, hoje aposentada, cobrava justamente a parte prática dele: dado um endereço, uma porta ou um protocolo, dizer a que camada ele pertence. Essa habilidade sobrevive a qualquer mudança de currículo porque é com ela que engenheiros dizem uns aos outros onde está um problema.

De onde vêm as sete camadas

O modelo é uma norma de verdade, não folclore. A ISO o publica como ISO/IEC 7498-1:1994, o Basic Reference Model, que "was last reviewed and confirmed in 2000. Therefore this version remains current" (ISO); o ITU-T o publica como a Recomendação X.200, aprovada em julho de 1994 e ainda em vigor (ITU-T). Ele nasceu como a arquitetura de uma suíte de protocolos completa, apoiada por governos e operadoras de telecom, que a internet acabou deixando para trás, história contada em a guerra dos protocolos. Os protocolos OSI, na maioria, perderam; o modelo ficou, porque dá a cada função um lugar certo.

As sete camadas e o que fica em cada uma

Camada 1, física: cabos, fibra, rádio, o próprio sinal elétrico ou óptico, e as falhas que acontecem ali, como um cabo danificado ou um duplex mismatch. Camada 2, de enlace (data link): frames Ethernet, os quadros, e endereços Media Access Control (MAC); é a camada dos switches. Camada 3, de rede: endereços Internet Protocol (IP) e roteamento; é a camada dos roteadores. Camada 4, de transporte: o Transmission Control Protocol (TCP) e o User Datagram Protocol (UDP), com os números de porta que identificam cada conversa. Camadas 5 e 6, sessão e apresentação: quase nunca citadas na prática; quando aparecem, é para falar de criptografia e de codificação dos dados. Camada 7, aplicação: o Hypertext Transfer Protocol (HTTP), o Domain Name System (DNS) e tudo aquilo que o usuário de fato pediu.

O mapeamento no estilo da prova é um reflexo que vale treinar: endereço MAC, camada 2. Endereço IP, camada 3. Porta TCP ou UDP, camada 4. O protocolo da aplicação, camada 7. Um virtual server, que atende num endereço IP e numa porta, ocupa as camadas 3 e 4; um proxy que decide com base nos headers HTTP está trabalhando na camada 7.

As camadas da própria internet: quatro, não sete

Os protocolos que venceram nunca foram projetados em cima das sete camadas. A 1122, os requisitos para hosts de outubro de 1989, define quatro: aplicação, transporte, internet e enlace (link) (RFC 1122, seção 1.1.3). A camada de enlace é o protocolo que um host precisa implementar "to communicate on its directly-connected network", e sobre o topo da pilha a RFC diz: "The application layer of the Internet suite essentially combines the functions of the top two layers", apresentação e aplicação, "of the OSI reference model". Por isso, quando um engenheiro fala em "camada 7", ele está falando da camada de aplicação da internet; quando fala em "camada 2", está falando do link em que o host está; e as camadas 5 e 6 não têm um protocolo próprio na suíte da internet para onde apontar.

Camada OSICamada da internet (RFC 1122)O que aparece na captura
7, 6, 5AplicaçãoHTTP, DNS, registros TLS
4Transportesegmentos TCP, datagramas UDP
3Internetdatagramas IP,
2Enlace (link)frames ,
1(não é uma camada da suíte)sinais elétricos, luz, rádio

Encapsulamento: por que as camadas se empilham

Cada camada encapsula a de cima: os dados da aplicação vão dentro de um segmento TCP, o segmento vai dentro de um datagrama IP, e o datagrama vai dentro de um frame Ethernet. A RFC 1122 dá nome a cada um desses envelopes: um segmento é "a TCP header followed by application data"; um datagrama IP "consists of an IP header followed by transport layer data"; um pacote é "the unit of data passed across the interface between the internet layer and the link layer"; e um frame "consists of a link-layer header followed by a packet" (RFC 1122, seção 1.3.3). Ler uma captura de pacotes é abrir esses envelopes, do mais externo para o mais interno, e é por isso que as ferramentas de captura mostram o frame, depois o IP, depois o TCP e, por fim, o payload, nessa ordem. Quando um equipamento reescreve uma camada e não mexe nas outras (um roteador que troca os headers de camada 2 a cada hop, enquanto os endereços de camada 3 seguem intactos), é o modelo que torna esse comportamento previsível em vez de misterioso.

Uma requisição, camada por camada

Acompanhe uma única requisição passando pelas camadas, em ordem. Um navegador que precisa abrir https://example.com primeiro precisa de um endereço, então envia uma consulta ao DNS, uma mensagem de camada 7 que viaja em UDP até a porta do servidor: "Messages sent using UDP user server port 53 (decimal)" (RFC 1035). Se o resolver estiver em outra rede, a consulta tem de passar pelo default gateway; então, antes de ela sair, o host descobre o endereço MAC do gateway com o ARP, uma troca de camada 2. A resposta dá ao navegador um endereço IP, camada 3, e o esquema da URL dá a porta: no https, "TCP port 443 (the reserved port for HTTP over TLS) is the default" (RFC 9110), camada 4. Depois vêm o handshake TCP, o handshake TLS e a requisição HTTP propriamente dita: três conversas empilhadas numa mesma conexão.

Quando a página não carrega, cada um desses passos vira uma pergunta, e cada pergunta aponta para uma camada. Se não há entrada na tabela ARP para o gateway, o problema está na camada 2; um timeout de DNS é um sintoma de camada 7 que pode ter causa na camada 3; um reset da conexão logo depois do ClientHello do TLS está em algum ponto entre as camadas 4 e 7. Descobrir qual passo falhou é descobrir em que camada procurar.

Onde o modelo não dá conta

O modelo é um vocabulário, não uma lei, e muita tecnologia não cabe numa camada só. Um load balancer que termina o Transport Layer Security (TLS) e criptografa de novo o tráfego até o servidor atua da camada 4 à 7 de uma vez. Túneis colocam pilhas inteiras dentro de outras pilhas: o , no próprio título da RFC 7348, é "A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks" e carrega frames Ethernet dentro de UDP, na porta 4789 (RFC 7348); numa captura, aparece camada 2 por cima da camada 4. Os arquitetos da internet foram ainda mais diretos: a RFC 3439 tem uma seção chamada "Layering Considered Harmful", porque a separação rígida em camadas faz com que "the optimization of each layer has to be done separately" (RFC 3439, dezembro de 2002). Nada disso torna o modelo inútil; significa que as camadas descrevem funções, e um mesmo equipamento pode exercer várias delas.

Um hábito que vale a pena

Use o modelo como os engenheiros usam no dia a dia: dizer "o problema está abaixo da camada 3" já descarta a aplicação e o DNS numa frase só, e "só falha na camada 7" avisa ao time de rede que, provavelmente, o problema não é com eles. No troubleshooting, diga qual é a camada mais alta que você já provou que funciona e a mais baixa que você provou que falha; o defeito está entre as duas. LED de link aceso e contadores de interface sem erros tiram a camada 1 da lista de suspeitos; a resolução ARP tira a 2; uma resposta ao ping tira a 3; um handshake TCP completo tira a 4; daí para cima, a conversa é com a aplicação. Com esse hábito, as sete camadas deixam de ser resposta de prova e viram uma ferramenta de diagnóstico.

Fontes