explicação do modelo OSI (camadas de aplicaçao)

Publicado: maio 2, 2009 em normal, rede, seguranca

Imagine que o objetivo de uma rede é simplesmente transportar os bits uns e zeros usados pelos programas de um ponto a outro. Da mesma forma que as trilhas da placa-mãe transportam informações do processador para a memória RAM, os cabos de par trançado da rede (ou os transmissores de rádio das redes wireless) permitem transportar as mesmas informações de um PC a outro.

Do ponto de vista do aplicativo, faz pouca diferença acessar um arquivo gravado diretamente no HD ou acessá-lo a partir de um compartilhamento dentro da rede, ou na Internet. Em ambos os casos, o próprio sistema operacional (com a ajuda do TCP/IP e das demais camadas que formam a rede) é quem acessa o arquivo e o entrega completo ao programa.

Entra em cena, então, o famoso modelo OSI, que tenta explicar o funcionamento da rede, dividindo-a em 7 camadas:

7- Aplicação (aqui está o programa, que envia e recebe dados através da rede)
6- Apresentação
5- Sessão
4- Transporte
(aqui entra o protocolo TCP e o sistema operacional, que controla a transmissão dos dados, detectando problemas na transmissão e corrigindo erros)
3- Camada de Rede
(aqui está o protocolo IP)
2- Link de dados
(aqui estão as placas de rede e os switches)
1- Camada Física
(aqui estão os cabos e os hubs)

Embora seja apenas um modelo teórico, que não precisa necessariamente ser seguido à risca pelos protocolos de rede, o modelo OSI é interessante, pois serve como deixa para explicar diversos aspectos teóricos do funcionamento da rede. Existem livros e cursos dedicados inteiramente ao assunto, que tentam explicar tudo detalhadamente, classificando cada coisa dentro de uma das camadas, mas na verdade entender o modelo OSI não é tão difícil assim.

Tudo começa com o aplicativo que precisa acessar alguma informação na rede. Digamos que você abriu o navegador e está acessando o http://guiadohardware.net.

Estamos na camada 7 (aplicação), onde o programa simplesmente solicita os arquivos para o sistema operacional, sem se preocupar com o que precisa ser feito para obtê-lo. É como quando você compra um produto em uma loja online: você não está preocupado com a logística envolvida, sabe apenas que daqui a dois dias o produto vai chegar na sua casa via sedex.

Ao receber a solicitação, o sistema operacional abre uma sessão (camada 5). Ela funciona de uma forma semelhante a um ticket de suporte: é aberta ao receber a solicitação e fechada apenas quando o problema é resolvido, ou seja, quando o programa recebe de volta os dados que solicitou.

Como um bom atendente, o sistema operacional ficará de prontidão durante todo o processo, aguardando a resposta do servidor e verificando se todos os arquivos chegaram corretamente ao aplicativo. Caso necessário, ele solicita retransmissões dos pacotes que se perderam e, caso eventualmente não seja possível atender a solicitação (a conexão está fora do ar, por exemplo), ele reporta o erro ao aplicativo, que exibe então alguma mensagem de erro, avisando do problema.

Depois de abrir a sessão, o sistema “vai à luta”: verifica qual é o endereço IP do site, qual protocolo será usado e outras informações necessárias, para então enviar a requisição ao servidor que hospeda o site, solicitando o envio dos arquivos que compõem a página. Aqui já estamos na camada 4 (transporte), onde o sistema operacional faz o trabalho do atendente, que faz o pedido para a central de distribuição, contendo o item que será entregue e o endereço de destino.

Você pode se perguntar o que aconteceu com a camada 6. Não a citei no exemplo porque ela nem sempre é usada. Ela funciona como uma camada extra, que é usada quando é necessário fazer algum trabalho adicional. Um exemplo de uso para a camada 6 são os túneis encriptados criados usando o SSH (que permite acessar máquinas rodando Linux ou outros sistemas Unix remotamente, de forma segura). Eles fazem com que os dados sejam transmitidos de forma encriptada pela rede, aumentando a segurança de forma transparente tanto para o aplicativo quanto para o sistema operacional.

Chegamos então à camada 3 (rede), onde entra em ação o endereçamento IP. A requisição é transformada em um pacote de dados e endereçada ao endereço IP do servidor do guiadohardware.net. É como se, em vez de usar e-mail ou telefone, o pedido precisasse ser enviado via carta à central de distribuição, que responderia enviando o produto. O sistema operacional atua como o atendente que faz o pedido (camada 4, transporte) e verifica o status do envio (camada 5, sessão). O TCP/IP (camadas 4 e 3) seria representado, no exemplo, pelo trabalho dos correios, incluindo o envelope que contém os endereços do remetente e do destinatário.

Uma observação importante sobre o TCP/IP é que ele é, na verdade, composto por dois protocolos. O “TCP” trabalha no nível 4, auxiliando o sistema operacional na criação, no envio e na checagem dos pacotes, enquanto o “IP” trabalha no nível 3 e é responsável pelo endereçamento. Os dois trabalham em conjunto, como se fossem uma coisa só, muito embora sejam dois protocolos separados.

Voltando à explicação, depois de criado e endereçado corretamente, o pacote é transportado através da rede local, passando pela placa de rede, pelos cabos e pelo hub (ou switch), até chegar ao gateway da rede e, a partir daí, à Internet. É nesta fase que chegamos às camadas 1 e 2, onde é feito o trabalho pesado.

Em primeiro lugar, a placa de rede não entende pacotes TCP/IP, é por isso que ela é chamada de “placa Ethernet” e não “placa TCP/IP”. Ela não sabe nem mesmo diferenciar um endereço IP do outro. Tudo o que ela conhece são endereços MAC (os endereços físicos das placas de rede, gravados ainda em fábrica).

Para despachar o pacote pela rede local (de forma que ele chegue até o gateway), ela o transforma em um “frame”, contendo o endereço MAC da placa destino. É como se ela colocasse o envelope original dentro de outro, que usa um endereçamento mais simples.

Os endereços MAC são endereços de 48 bits, representados através de 12 dígitos hexadecimais (conjunto que engloba os caracteres 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E e F), como em “00:15:00:4B:68:DB”. Os endereços MAC são gravados na ROM da própria placa, durante sua fabricação e, a menos que intencionalmente modificado, cada placa de rede possui um endereço MAC diferente. É como no dinheiro: duas cédulas só possuem o mesmo número de série se pelo menos uma delas for falsa.

Além do endereço de origem e de destino, o frame inclui 32 bits de CRC, que são usados pela placa de destino para verificar a integridade do frame recebido. Sempre que um frame chega corrompido, a placa solicita sua retransmissão, de forma a garantir que os dados recebidos são sempre os mesmos que foram enviados. O frame é então desmontado e os dados (o pacote TCP) são entregues ao sistema operacional.

Este sistema permite que as redes Ethernet sejam usadas em redes com qualquer protocolo, sem ficarem restritas ao TCP/IP. A rede age como uma camada genérica de transporte, com suas próprias regras, que se limita a transportar informações de um ponto a outro, sem tentar entender o conteúdo dos pacotes.

Embora os termos “frame” e “pacote” sejam freqüentemente usados como sinônimos, ao longo do livro procurarei manter o uso da designação correta, usando o termo “pacote” quando estiver me referindo aos pacotes TCP e o termo “frame” quando estiver me referindo às transmissões das placas de rede.

Hoje em dia, o TCP/IP é o protocolo dominante, mas antigamente ele concorria com um grande número de outros protocolos de rede, como o NetBEUI e IPX/SPX. Graças à neutralidade das redes Ethernet, não era necessário alterar o cabeamento da rede ao mudar de protocolo, tudo o que você precisava fazer era mudar a configuração do sistema operacional. Era possível até mesmo manter vários protocolos diferentes instalados.

Outra peculiaridade do sistema Ethernet é a forma como os dados são transmitidos. Hoje em dia, quase todas as redes locais utilizam cabos de par trançado, mas quando o padrão Ethernet foi criado, as redes ainda utilizavam cabos coaxiais, onde todas as estações eram ligadas no mesmo cabo. Porém, graças às origens, as redes Ethernet utilizam até hoje uma topologia lógica de barramento: independentemente da forma como os micros estão fisicamente interligados, eles se comportam como se estivessem todos ligados no mesmo cabo:

14Como apenas uma estação pode falar de cada vez, antes de transmitir dados a estação irá “ouvir” o cabo. Se perceber que nenhuma estação está transmitindo, enviará sua transmissão, caso contrário, esperará até que o cabo esteja livre. Este processo é chamado de “Carrier Sense” ou “Sensor Mensageiro”:

2

Contudo, quando duas estações ouvem o cabo ao mesmo tempo, ambas acabam percebendo que o cabo está livre e enviam seus frames simultaneamente. Temos, então, uma colisão de dados. Para lidar com as colisões e permitir que a rede funcione apesar delas, foi implantado o sistema CSMA-CD ou “Carrier Sense Multiple Access with Collision Detection”, que, apesar do nome pomposo, funciona de forma relativamente simples.

Para detectar as colisões, as estações monitoram as transmissões no cabo enquanto transmitem. Ao perceber que outra estação está transmitindo ao mesmo tempo, ela imediatamente pára de transmitir e gera um sinal de interferência, que elimina todos os dados que estiverem trafegando pelo cabo e ao mesmo tempo avisa as demais estações de que uma colisão ocorreu e que todas devem parar de transmitir.

Entra em cena então o algoritmo Binary Exponential Backoff, destinado a evitar que as estações voltem a tentar transmitir simultaneamente, entrando em um loop eterno de colisões e retransmissões.

O sistema é baseado em slots de tempo, cada um com 51.2 microssegundos, valor que corresponde ao tempo máximo que o sinal demora para percorrer o cabo e se propagar para todas as demais estações em uma rede montada dentro dos padrões.

Inicialmente, as estações escolhem entre voltar a transmitir imediatamente ou esperar 1 slot de tempo antes de voltar a retransmitir. Se houver duas estações envolvidas, a possibilidade de haver uma nova colisão é de 50%, de forma que as estações já ficam de sobreaviso. Se uma nova colisão ocorre, o número de possibilidades é dobrado e elas passam a escolher entre esperar 0 e 3 slots de tempo, reduzindo a possibilidade para 25%. Se as colisões continuarem ocorrendo, o volume de combinações vai crescendo exponencialmente, até chegar a 1024 possibilidades (de 0 a 1023 slots de tempo), na décima tentativa, que é o valor máximo permitido pelo algoritmo.

São feitas então mais 6 tentativas usando o valor máximo. Caso as colisões persistam (o que é quase impossível, a menos que exista algum problema de hardware em uma das placas ou no hub), a retransmissão é abortada e o erro é reportado ao sistema operacional. Você recebe então um erro de “conexão encerrada” ou similar.

Em situações normais, as estações conseguem transmitir na segunda ou terceira tentativa, o que causa uma perda de tempo relativamente pequena. As colisões são uma ocorrência absolutamente normal e esperada. O problema é que em redes com muitas estações, as colisões podem reduzir bastante o desempenho da rede. A solução nesses casos é dividir a rede em segmentos menores, interligados por bridges, switches ou roteadores, como veremos em detalhes no capítulo 1.

Pode parecer estranho estar falando sobre os cabos coaxiais que, felizmente, deixamos de usar há mais de uma década, mas esses mesmos princípios continuam válidos nas redes wireless, onde todos os micros estão ligados no mesmo “cabo” (o ar) e as transmissões de todos os micros da rede são recebidas por todos os demais, de forma que as colisões de pacotes são frequentes, assim como nas antigas redes com cabo coaxial.

Nas redes wireless, as colisões não se limitam aos micros da sua própria rede, mas a todos os participantes de redes próximas, que estejam operando na mesma faixa de frequência. Como você pode imaginar, isso pode rapidamente se tornar um problema em regiões densamente povoadas, como em centros financeiros e em grandes conjuntos habitacionais, como veremos em mais detalhes no capítulo 3.

Em uma rede com cabos de par trançado, temos a figura do hub (ou switch), que atua como a figura central que interliga todos os micros, criando uma topologia de estrela:

3

Se temos cabos separados para cada micro, você pode imaginar que não existe o problema das colisões, pois, afinal, o hub pode encaminhar as transmissões diretamente de um micro a outro. É aqui que entra diferença entre os antigos hubs e os switches, usados atualmente. Explicar a diferença entre os dois é uma boa forma de explicar a diferença entre as camadas 1 e 2 do modelo OSI.

Os hubs são dispositivos burros, que operam na camada 1. Eles não entendem pacotes nem endereços de rede, simplesmente pegam os uns e zeros que recebem em uma porta e os retransmitem para todas as outras. O hub atua simplesmente como um centralizador e repetidor, não é mais inteligente que um pedaço de cabo. Ao usar um hub, as colisões continuam ocorrendo, exatamente como aconteceria se você estivesse usando uma rede antiga, com cabo coaxial.

Os switches, por sua vez, trabalham na camada 2, assim como as próprias placas de rede. Eles entendem frames e endereços MAC e por isso são capazes de “fechar circuitos”, transmitindo os frames apenas para o micro ligado na placa correta. Cada porta é ligada a um circuito separado, que são coordenados por um controlador central, que mantém uma tabela com os endereços MAC das estações ligadas a cada porta e pode assim checar o conteúdo de cada frame e encaminhá-lo à porta correta.

Apesar disso, os switches não entendem TCP/IP. Isso é trabalho para os roteadores, que trabalham na camada 3 e tomam suas decisões baseadas nos endereços IP dos emissores e destinatários dos pacotes, tentando sempre usar a rota mais curta.

Ao receber um frame Ethernet, o roteador descarta os endereços MAC e as demais estruturas adicionadas pela placa de rede, ficando apenas com o pacote TCP dentro dele. É por isso que não é possível usar regras de firewall baseadas em endereços MAC para hosts da Internet, ao contrário do que temos ao criar regras para os endereços da rede local.

Veremos mais detalhes sobre estas diferenças entre hubs, switches e roteadores logo a seguir, no capítulo 1. Para detalhes sobre os pacotes TCP, frames Ethernet e o uso dos endereços MAC, consulte o capítulo 4.

Fonte: gdhpress

comentários
  1. jean disse:

    otimo tutorial

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s