Protocolos logicos de_comunicacao
Upcoming SlideShare
Loading in...5
×
 

Protocolos logicos de_comunicacao

on

  • 439 views

 

Statistics

Views

Total Views
439
Views on SlideShare
439
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Protocolos logicos de_comunicacao Protocolos logicos de_comunicacao Document Transcript

  • PROTOCOLOS LÓGICOS DE COMUNICAÇÃO1 INTRODUÇÃOProtocolo de Comunicação é a formalidade adotada para estabelecer a comunicaçãoentre nós de uma rede. Nestes termos, não podemos tratar um protocolo de comunicaçãode forma isolada. Devemos, sim, avaliar o conjunto de formalidades devidamenteidentificadas nas diversas camadas ou nos níveis que elas acontecem. Os protocoloslógicos são aquelas formalidades adotadas para tratar a rede lógica e os protocolos físicossão as formalidades adotadas para o meio físico correspondente.Somente os protocolos usados na camada física podem ser insuficientes ou carentes derecursos, por exemplo, para garantir o envio e o recebimento da informação. Para estagarantia faz-se necessário a inclusão de camadas de software auxiliares, estabelecendoassim os protocolos lógicos.Admita uma interface de rede enviando um frame para um certo destino. Como estainterface pode ter certeza que o frame foi enviado? Como ela pode ter certeza deque o frame foi recebido?É intuitivo que o envio só será confirmado caso o destinatário e os equipamentosintermediários, se existirem, retornarem algum outro frame para o remetente informando-o do fato. Receber também não implica que a informação foi entendida ou processadacorretamente. A informação, ou o pacote que a transporta, pode ter defeitos gerados porruídos na transmissão ou na própria montagem inadequada, deteriorando seu conteúdo oumodificando um padrão adotado. Assim, o receber pode implicar numa confirmação detodas as camadas superiores ou apenas de uma camada mais baixa. Neste último caso, aconfirmação pode acontecer por camadas ou seguir um mecanismo de confirmaçãodescendente (a camada mais baixa retornará ao remetente se todas as camadas acima delaconfirmarem o recebimento de forma correta ou vice-versa).Como o remetente deve proceder caso não receba uma confirmação dorecebimento?Reenvia o mesmo frame, continua enviando novos frames?Este tratamento é aplicável tanto às redes físicas (caso o hardware disponibilize recursos)quanto às lógicas (implementado por software). Temos, então, protocolos destinados aotratamento da informação quanto ao envio e recebimento desta nas várias camadas. Oreenvio do frame ou a confirmação de recebimento pode ocorrer após o reconhecimentoou análise feita por alguma camada superior. Além disto, tem-se protocoloscorrespondentes (ou associados) à prestação de serviços em camadas mais altas. Aprestação de serviços estabelece ou seguem modelos de comunicação, um delesdenominado Paradigma Cliente x Servidor. Neste modelo, o servidor executa algumaaplicação específica (com finalidade bem definida) e esta prepara o sistema para atender
  • solicitações ou "request" de uma aplicação cliente compatível. Assim, o cliente inicia acomunicação. Devemos observar que o "servidor" é um servidor de aplicação.Vimos que os Sistemas Operacionais são projetados para algum tipo de tarefa e atenderàs aplicações que seus fabricantes adotaram ou criaram. Junto com tais aplicações osfabricantes do SO também incluem os protocolos de comunicação. Discutiremos algunsprotocolos de comunicação dando uma ênfase superficial e o analisaremos o protocoloTCP/IP com maiores detalhes por ter sido adotado para uma grande número de aplicaçõese apresentar código aberto.Assim, veremos os seguintes protocolos: • NETBIOS/NetBEUI • SAP/IPX • TCP/IP2 Protocolos NETBIOS/NetBEUI2.1 INTRODUÇÃOEm 1985, a IBM (e não a Microsoft como muita gente pensa!!!) introduziu o NetBEUIcomo um protocolo que poderia ser usado em aplicações desenvolvidas para redes,considerando a interface do Sistema de Entrada/Saída Básico de Redes (ou, em inglês,Network Basic Input/Output System - NETBIOS).O NetBEUI foi projetado como um pequeno e eficiente protocolo (sob algum ponto devista) para uso em redes departamentais (locais) contendo entre 20 e 200 computadores, eque não precisavam ser roteadas para outras sub-redes, embora aceite o roteamentoquando explorado o roteamento Token-Ring da IBM. Inicialmente o protocolo NetBEUIé o protocolo padrão dos Sistema Operacional DOS (IBM/Microsoft). Hoje, esteprotocolo pode ser executado em diversos sistemas operacionais, onde citamos: DOS +LAN Manager, Windows (todos), Unix assim como IBM PCLAN, OS/2 (LAN Server),etc.O NetBEUI pode ser usado com programas que implementam uma variedade se serviçosbaseados nas seguintes interfaces de programação de aplicações (ou APIs - ApplicationProgramming Interface) e interfaces de programação NETBIOS • Named Pipes • Mailslot • Network DDE (dynamic data exchange) • Remote Procedure Call (RPC) sobre NetBIOS • RPC sobre Named Pipes.
  • 2.2 ARQUITETURAO NetBEUI é um veículo de transporte. É um protocolo de rede e de enlace e não oprotocolo de transporte. Sua estrutura é composta por drivers (interface, protocolo LLC)que denominamos de NBF (NetBEUI Frame), o protocolo de transporte (NETBIOS) e oprotocolo de aplicações. O exemplo a seguir considera uma máquina cliente executandoeste protocolo, conectada à outra que serve como gateway para uma rede local (LAN –Local Access Network) através de um acesso Dial-up.Fonte: Microsoft Windows NT Resource Kit. Arquivo network.hlp2.2.1 Protocolo LLC + Driver = NETBEUICorresponde a camada de Controle de Link Lógico (LLC) do modelo OSI. No protocoloLLC realizam-se códigos e protocolos voltados ao meio (hardware), endereços físicos,controle de fluxos dos frames, e transferência de dados com ou sem garantias de conexãoe abrange as camadas NetBEUI e de interface. Aqui encontramos os endereços físicos dasplacas de rede, e os protocolos usados para transmitir os frames.OBS: Reparem que não existe uma camada de rede definida. Apesar disto, o NetBEUI(também conhecido como NBF) permite um roteamento em gateway baseado natecnologia de redes Token-Ring.2.2.2 Protocolo NetBIOSCorresponde às camadas de transporte e de sessão do modelo OSI. Aqui, o NetBIOSestabelece a sessão, o multiplex/demultiplex, o término da sessão, a segmentação demensagens, delimitações, montagem e reconhecimentos de envio ou recebimento dospacotes. View slide
  • 2.2.3 SERVIÇOSO NETBIOS implementa um conjunto de serviços tais como: compartilhamento deperiféricos: discos, impressoras, fax/modems, áreas de trabalho (memória); envio erecebimento de mensagens, e um ilimitado número de outros serviços que podem serprogramados via RPC.Os serviços NETBIOS também podem ser encapsulados em outros protocolos de rederoteáveis para romper a restrição de rede local, como por exemplo: NETBIOS/TCP-IP.Este tipo de encapsulamento pode ser encontrado em diversos tipos de plataforma esistemas operacionais. Uma destas aplicações que implementam tal encapsulamentochama-se SAMBA (distribuição gratuita), cuja implementação abrange sistemasoperacionais UNIX, (Open)VMS. Os sistemas Windows já trazem este tipo de recursosem a necessidade de software adicional. Alguns Sistemas Windows (NT, 9x) podemservir como "gateway" para estes protocolos nas conexões de redes DIALUP eETHERNET.2.2.4 SEQUENCIA DE ENCAPSULAMENTOSO DADO é a informação (requisição ou resposta) que será envolvida pelo protocolo daaplicação. Este, por sua vez, é evolvido pelo protocolo NETBIOS. Este "envolvimento"representa que o NETBIOS inseriu alguma forma de cabeçalho, especificando afinalidade daquela aplicação, o nome da máquina, o grupo que pertence, o domínio...Agora a finalidade é enviar tudo isto para o meio físico, o que é preparado pelo protocoloNetBEUI e enviado para o meio físico (tamanho do frame, forma, tipo do meio, etc). View slide
  • 2.3 SEGMENTAÇÃO DA REDEUma vez que o NetBEUI é NÃO-ROTEÁVEL por roteadores "normais", a soluçãoadotada para estabelecer alguma divisão de forma lógica é através de GRUPO DETRABALHO (para compartilhamento) e DOMÍNIO, usado para AUTENTICAÇÃO.Nos GRUPOS DE TRABALHO (ou WORGROUP), uma máquina pertencente ao grupovê as outras máquinas do mesmo grupo num primeiro plano. As máquinas de outrosgrupos podem ser acessadas escolhendo o grupo correspondente.As máquinas controladoras de domínio, rodando Windows NT Server ou equivalente,usam diretórios compartilhados para armazenar informações para todo o domínio,concebendo uma administração única. Há dois tipos de controladores: • Os controladores de domínio primários (PDC - Primary Domain Controller), quemantém as modificações feitas nas contas do domínio e armazenam as informações numbanco de dados. Um domínio tem um PDC. • Os controladores de domínio de backup (BDC - Backup Domain Controller), quemantém uma cópia do banco de dados do PDC através de mecanismos de sincronização.Um domínio pode ter múltiplos BDCs.2.4 IDENTIFICAÇÂOAs máquinas são identificadas através de nomes únicos independente de grupo no qualelas pertencem. Estes nomes estão associados aos Endereços Ethernet de forma direta(MAC - Media Access Control), que podem ser simulados de forma lógica (Ex. conexõesPPP via modem).Os nomes são propagados através de frames tipo broadcast, enviados periodicamente porcada máquina (talvez a eficiência esteja aqui!). Todas as máquinas recebem aquele framee vão, assim, atualizando suas tabelas contendo as máquinas "vivas" na rede e os recursosque elas disponibilizam. Cada máquina mantém sua própria tabela de nomes,atualizando-as periodicamente. A resolução de nomes depende do tipo de configuração edo nó empregado em cada computador. São aceitos os seguintes tipos de nós: • b-node -- usam broadcast para o registro e resolução de nomes. • p-node -- usam solicitações de nomes em conexões ponto-a-ponto feitas aoservidor de nomes NetBIOS (servidores WINS - Windows Internet Name Server)onde os nomes estão registrados e resolvidos. Este tip de nó existirá se otransporte NetBIOS estiver encapsulado (envolvido) pelo protocolo TCP/IP. • m-node -- usam broadcast para o registro de nomes; para resolver os nomes estasmáquinas tentam os frames de broadcast (b-node), e no caso de não receberem
  • resposta, comutam para a forma p-node. • h-node -- usam um servidor de nomes NetBIOS para o registro e tradução;entretanto, se o servidor de nomes não está disponível (não pode ser localizado),um h-node tenta a forma de um b-node. A busca por um servidor de nomes écontínua, e um h-node comutará para a forma p-node tão logo encontre umservidor de nomes disponível. Equipamentos configurados como clientes WINSsão do tipo h-node. • Microsoft-enhanced -- Usam os arquivos locais LMHOSTS ou proxies WINS mais a chamada de funções de Socket gethostbyname() ( chamadas a DNS ou arquivos HOSTS) além dos tipos de node citados anteriormente. Este caso é aplicável quando consideramos o encapsulamento NETBIOS/TCP.Informações complementares podem ser encontradas no arquivo network.hlp doWindows NT Resouce Kit.3 Protocolo IPX3.1 INTRODUÇÃOO protocolo IPX (Internetwork Packet Exchange) foi desenvolvido pela NOVELL e é oprotocolo de rede padrão para redes NETWARE. Estas redes usam uma variedade deprotocolos, sendo muitos destes desenvolvidos especialmente para redes Netware ebaseados no protocolo da Xerox, o XNS (Xerox Network System). De fato, os dois sãoquase idênticos, exceto por uma pequena diferença em alguns sub-protocolos. Porexemplo, o IPX da Novell (ou Internetwork Packet Exchange) é baseado no IDP daXEROX (ou Internetwork Datagram Packet). O XNS inclui protocolos para aplicaçõescom propósitos especiais como a manipulação de mensagens enquanto o NetWare usa,apenas, algumas funções básicas ignorando o resto.Neste modelo de rede, todas as transações entre máquinas são autenticadas e verificadaspela máquina servidora Netware, mesmo que a informação esteja em outra máquinacliente. Ou seja, a servidora Netware tem controle total sobre as ações de seus clientes.
  • 3.2 ARQUITETURAA arquitetura do conjunto IPX em relação ao modelo de referencia OSI é apresentadoabaixo.3.2.1 PROTOCOLO IPXO IPX é o protocolo freqüentemente associado com redes NetWare e restabelece a partelógica da arquitetura, proporcionando as funções de "rede". O IPX caminha nos váriossegmentos de rede disponíveis e trata do envio dos dados.O endereço IPX é uma combinação de um endereço de rede e do endereço da placa derede. A parte de rede é um número hexadecimal de 32 bits representado numa cadeia decaracteres de 64 bits (ver identificação). Na maioria das vezes, a parte de rede estáassociada ao servidor Netware ou roteador. Uma máquina cliente Netware obterá estaparcela de endereçamento a partir do servidor ou do roteador, durante a fase deinicialização e a associará ao endereço de hardware existente (MAC). Se não existir umservidor Netware então o roteador alimentará a rede com esta informação, caso contrárioa identidade IPX ficará limitada à rede local através do endereço físico.Uma vez que o endereço de um nó IPX de tem seu endereço de hardware, os sistemaspodem se comunicar diretamente em uma mesma rede física, sem se preocupar com oendereço de rede. Se o sistema de destino é uma máquina de uma rede remota então odado é direcionado para o roteador e este tratará do envio para o segmento de redeadequado.
  • OBS: O IPX não garante o envio, ou proporciona serviços de correção ou detecção deerros. Estas funções são de responsabilidade da camada de transporte (o SPX ePEP).3.2.2 PROTOCOLO SPXO SPX (Sequenced Packet Exchange) é um protocolo de transporte confiável que usa oIPX para o envio. Uma vez que o IPX (o protocolo de rede) não oferece qualquerconfiabilidade, as aplicações que usam a rede devem ter algum protocolo confiável, nocaso, disponibilizada pelo SPX.Exemplos destas aplicações podemos incluir, um cliente-servidor de banco de dados, ouum produto de antivírus. Ao invés da aplicação cliente ler diretamente um arquivoarmazenado no servidor, como acontece com o NetBIOS/NETBEUI, a aplicação clientesolicita a informação desejada à aplicação no servidor e esta faz o acesso ao arquivo eenvia o registro (informação), através de comandos enviados e envolvidos pelo SPX.O SPX trata esta conectividade como circuitos virtuais, que proporcionam conexões entreaplicações através do IPX. O tratamento de erros e de reenvio é feito por janelas. Ou seja,ao enviar um conjunto de pacotes e se um deles apresentar algum erro, então todo oconjunto será retransmitido. Caso o recebimento tenha sucesso, então a máquina deorigem recebe uma confirmação de todo o conjunto. A confirmação individual dospacotes é feita pelo protocolo PEP. O mecanismo adotado no SPX permite o fluxo deuma grande quantidade de dados de forma rápida com um pequeno risco de dados seremcorrompidos.(Será que isto é tanto assim? E no caso da rede apresentar colisões? Eis o motivo peloqual os servidores IPX travam sob algum problema de rede! Por outro lado, quando arede está bem dimensionada o desempenho é alto!)3.2.3 PROTOCOLO PEPO PEP (Packet Exchange Protocol) é um outro protocolo de transporte similar ao SPX. OPEP é usado, exclusivamente, para o envio dos pacotes NCP usados para a leitura eescrita de arquivos nos servidores Netware, e proporciona grande confiabilidade. Quando
  • o pacote é enviado usando o PEP, cada pacote é verificado independentemente, e nestecaso é disparado um relógio. Nenhum outro pacote será enviado até que a origem recebauma resposta confirmando a sua chegada. Se o tempo expira, o PEP remonta eretransmite o pacote e reinicializa a contagem de tempo. Este tratamento (handshake) eespera consomem uma grande banda de passagem da rede, mas garante, de formaabsoluta, que o pacote foi enviado e recebido. Em pequenas redes locais (mesma redefísica e pequeno número de máquinas) este tratamento passa desapercebido, mas emredes grandes ou complexas a queda do desempenho é sensivelmente prejudicado quandoenvolve grandes períodos de espera.3.2.4 SEQUENCIA DE ENCAPSULAMENTOS:No envio, a solicitação, resposta, a informação, ou seja o DADO é envolvido pelaaplicação ou serviço (NCP, SAP, RIP, etc). Se o serviço não for o SAP, o pacote éenvolvido pelo protocolo de transporte correspondente (PEP e SPX). O serviço SAP,como veremos, não usa qualquer protocolo de transporte. Quase pronto para o meiofísico, o conjunto é envolvido pelo protocolo de rede (IPX) que identificará arede+máquina de destino e orígem do pacote IPX. Se o destino for uma máquina de outrarede uma função de roteameno é executada, e, finalmente, o pacote IPX é depositado nafila da interface de rede (ou canal de saída) correspondente e envolvido pelo framefísico.No recebimento, o frame identificado pela interface e endereço do nó e depositado nasfilas de entrada do IPX que analisará o destino do pacote. Caso o pacote apresente umarede de destino diferente interface recebida, estabelece-se o roteamento IPX. Nãohavendo identificação do serviço SAP, o pactote é direcinoado para a camada de SPXou PEP que estabelecem o mecanismo de confirmação de recebimento, eautomaticamente direcionado para o serviço final. Tratando-se de um acesso a arquivo, aaplicação tratará de fazê-lo e retornará o registro solicitado
  • 3.3 IDENTIFICAÇÃOA identificação dos nós lógicos no protocolo IPX é composto por duas partes: aprimeira identifica a rede Netware e é composto por 24 bits (representados na formahexadecimal, e valor entre 1 e FFFFFFFF. A segunda parte contém 6 bytes ecorresponde ao endereço MAC (Media Access Control). Todos as máquinas quepertencem ao mesmo segmento lógico possuem o mesmo endereço de rede4 Protocolo TCP/IP4.1 INTRODUÇÃOEm 1969, por questões militares, o governo americano iniciava os estudos sobre umprotocolo que atendesse certos requisitos de comunicação. Dentre eles, destacam-se:1) Grande número de conexões lógicas2) Capacidade de transferencia de mensagens de controle;3) Capacidade de execução remota em batch ou interativo;4) Transferência de arquivos, e5) Independência da PlataformaNeste curso, estudaremos o conjunto de protocolos que compõem o TCP/IP, as camadas eaplicações sob o ponto de vista funcional, porém com um nível de detalhe necessáriovisando a administração e o desenvolvimento de produtos de software.Um comentário para os "comodistas": Se existe alguma aplicação pronta é porquealguém fez. Usá-la, simplesmente, é tão perverso e perigoso quanto uma bomba relógioou uma arma desconhecida onde o tiro pode sair pela culatra. Não se busca um expert,mas profissionais sem inocência. Para justificar este ponto de vista busque informaçõessobre "cavalos de Tróia".
  • 4.2 ARQUITETURAComparado ao OSI, o modelo TCP/IP é muito mais simples e consta de apenas 4 níveis(camadas), podendo englobar um ou mais níveis do modelo OSI. Não considerando todoo rigor das atividades das camadas do TCP/IP em relação o modelo OSI, podemoscomparar os dois protocolos como segue:Numa mesma rede física, a troca de mensagens, datagramas, pacotes e frames entre osnós estabelecem conexões entre os vários níveis (ou camadas), deixando-a transparecerconexões entre as camadas lógicas num nível mais alto. A figura abaixo mostra estasconexões considerando uma mesma rede física. Ou seja, a mensagem enviada por um nóé idêntica aquela recebida pelo outro nó. Neste caso, a igualdade se estende até a camadade frames.
  • Na próxima figura, temos a presença de roteador. Neste caso, a igualdade só é satisfeitaaté os pacotes. Ao receber o frame na interface de entrada do roteador, este é transferidopara a camada de rede, o datagrama é extraído do frame, analisado, o cabeçalho paraidentificar a rede de destino (e não a máquina). Uma vez conhecida a interface de destino,é montado um novo datagrama e enviado à ela. Esta, por sua vez, monta o frameadequado para o novo meio físico usando o endereço físico do roteador.