Monitorização de Sistemas Distribuídos em Redes WiFi

Tamanho: px
Começar a partir da página:

Download "Monitorização de Sistemas Distribuídos em Redes WiFi"

Transcrição

1 Ana Sofia Bernardo Gonçalves Licenciada em Engenharia Informática Monitorização de Sistemas Distribuídos em Redes WiFi Dissertação para obtenção do Grau de Mestre em Engenharia Informática Orientador: Prof. Doutor Vitor Manuel Alves Duarte, Prof. Auxiliar, Universidade Nova de Lisboa Presidente: Arguente: Vogal: Júri: Prof. Doutor Fernando Pedro Reino da Silva Birra Prof. Doutor Rodolfo Alexandre Duarte Oliveira Prof. Doutor Vitor Manuel Alves Duarte Junho, 2015

2

3 Monitorização de Sistemas Distribuídos em Redes WiFi Copyright c Ana Sofia Bernardo Gonçalves, Faculdade de Ciências e Tecnologia, Universidade Nova de Lisboa A Faculdade de Ciências e Tecnologia e a Universidade Nova de Lisboa têm o direito, perpétuo e sem limites geográficos, de arquivar e publicar esta dissertação através de exemplares impressos reproduzidos em papel ou de forma digital, ou por qualquer outro meio conhecido ou que venha a ser inventado, e de a divulgar através de repositórios científicos e de admitir a sua cópia e distribuição com objectivos educacionais ou de investigação, não comerciais, desde que seja dado crédito ao autor e editor.

4

5 Aos meus pais

6

7 AGRADECIMENTOS Gostaria desde já apresentar os meus agradecimentos aos que me apoiaram durante a elaboração desta dissertação. Em primeiro lugar, gostaria de agradecer ao meu orientador, Prof. Doutor Vitor Manuel Alves Duarte, pela disponibilidade e paciência demonstradas ao longo deste tempo. O seu apoio foi crucial para a conclusão deste trabalho. À Faculdade de Ciências e Tecnologia da Universidade Nova de Lisboa, em particular ao Departamento de Informática, por me ter fornecido as bases essenciais para a minha formação, pelas pessoas que aqui conheci e onde passei a grande parte do meu tempo nestes últimos anos. À minha família, principalmente aos meus pais, pelo tempo, dedicação e esforço que despenderam para me proporcionar melhores oportunidades de vida. Aos meus amigos, pelas trocas de ideias, apoio e diversão nos bons e maus momentos. Em especial ao Alexandre, pelo apoio e pela paciência necessária nestes últimos meses. vii

8

9 RESUMO As aplicações distribuídas são particularmente difíceis de depurar pelo facto da sua execução necessitar de interações, de redes de computadores, assíncronas. Acresce ainda o facto de o seu desempenho depender, não só de fatores internos a cada um dos processos, mas também a problemas de comunicação da rede, como congestionamento, fraca ou elevada latência ou perda de pacotes. Esta dificuldade agrava-se quando uma aplicação distribuída executa através de uma rede WiFi, acrescentando desafios à gestão da qualidade da rede por serem mais instáveis e lentas que as redes cabladas. Esta problemática pode ser ultrapassada através de ferramentas que, através da monitorização das interações da rede, e sem as perturbar, possibilitem a depuração e avaliação do desempenho da aplicação distribuída que está em execução. Existem já diversas ferramentas de monitorização e análise de tráfego, porém estas ferramentas não possibilitam a fácil análise das interações geradas apenas pela aplicação e não têm em consideração os desafios inerentes à compreensão da comunicação através de redes sem fios, mais concretamente a norma IEEE O objetivo desta dissertação consiste em apresentar um conjunto de metodologias para avaliação de um algoritmo distribuído, através da monitorização de pacotes gerados pela aplicação distribuída. Palavras-chave: Monitorização, redes Wifi, depuração, avaliação, aplicações distribuídas ix

10

11 ABSTRACT Distributed applications are particularly difficult to debug because their implementation requires asynchronous computer network interactions, and their performance depends not only on internal factors to each of the processes, but also depends on the network problems, such as traffic congestion, low or high latency or packet loss. This difficulty is aggravated when a distributed application is running over a wireless network, given to the fact that WiFi networks are more unstable and slower than wired networks, adding challenges to the management of network quality. This problem can be overcome through tools that, by monitoring network interactions and without disturbing them, enable debugging and performance evaluation of the distributed application that is executing. There are already several tools for traffic monitoring and analysis, but these existing tools do not allow an easy analysis of network interactions generated by the application and do not help to undertand wireless communication patterns. The goal of this thesis is to present a set of methods to evaluate a distributed algorithm, by monitoring packets generated by the interactions of a distributed application. Keywords: Monitoring, wifi networks, debugging, evaluation, distributed applications xi

12

13 CONTEÚDO Conteúdo Lista de Figuras Lista de Tabelas xiii xv xvii 1 Introdução Contexto e motivação Objetivos Implementação de um sistema de análise Estudo de um algoritmo Estrutura do documento Monitorização de Redes Redes WiFi Serviços de Sistema de Distribuição Serviços de Estação Controlo de Acesso ao Meio Gestão de Energia Tipos de Pacotes Monitorização Biblioteca PCap Ferramentas de Captura TCPDump Wireshark Wireshark para Sistemas Distribuídos Monitorização de tráfego de rede de um processo com base no PCap Conclusões Algoritmos de Consenso Definição Paxos Turquois Consenso Multi-Valor xiii

14 CONTEÚDO 3.5 Análise do sistema Sistema de Análise Requisitos Captura Análise de Tráfego Classificação de Tráfego Informação sumária Visualização Versão Java Versão Web Análises Efetuadas Ambiente de testes Análise de capturas Análise de tempos de execução Análise de tráfego Análise de tráfego extra Conclusões Objetivos e metas Resultados Trabalho Futuro Bibliografia 63 xiv

15 LISTA DE FIGURAS 2.1 Exemplificação de um conjunto de serviços estendido Exemplificação de um conjunto de serviços independente Representação do protocolo CSMA/CA Exemplificação do protocolo RTS/CTS DCF com implementação dos protocolos CSMA/CA e RTS/CTS Estrutura de uma superframe Estrutura de um pacote ethernet Elementos envolvidos na captura de pacotes Execução correta do algoritmo Paxos Arquitetura da rede Exemplo de tráfego de rede Versão Java Versão Web Gráfico da versão web Informação agregada Diagrama do sistema Gráfico temporal da execução do algoritmo para cada tipo de pacote Gráfico temporal da execução do algoritmo para cada nó interveniente Gráficos de tráfego acumulado Falha na receção do pacote INIT no nó Falha na receção do pacote INIT no nó , com inclusão da porta Falha na receção do pacote VALUE nos nós e Caso de erro Caso de retransmissão de pacote Gráfico Gráfico com inclusão da porta Gráfico com zoom Gráfico com perda de pacotes Gráfico Evolução dos tempos médios de execução, sem broadcast adicional xv

16 LISTA DE FIGURAS 5.12 Evolução dos tempos médios de execução, com broadcast adicional Evolução dos tempos mínimos de execução, sem broadcast adicional Evolução dos tempos mínimos de execução, com broadcast adicional Execução do algoritmo com 6 nós e 10ms de intervalo, sem broadcast adicional Execução do algoritmo com 6 nós e 40ms de intervalo, sem broadcast adicional 54 xvi

17 LISTA DE TABELAS 2.1 Tipo de informação apresentada sobre cada pacote Melhores tempos entre envio de mensagens Tráfego total para cada tempo entre envio de mensagens e respetivo n o de nós Tráfego da aplicação para cada tempo entre envio de mensagens e respetivo n o de nós Tráfego de uma execução com 5ms, com broadcast adicional Tráfego da aplicação, com injeção de tráfego extra, sem broadcast adicional Tráfego da aplicação, sem broadcast adicional Tráfego da aplicação com injeção de tráfego extra, sem broadcast adicional.. 60 xvii

18

19 C A P Í T U L O 1 INTRODUÇÃO 1.1 Contexto e motivação Com o aparecimento e crescimento das redes de computadores e da Internet, existe uma crescente necessidade de modelos de cooperação e de mecanismos que permitam o acesso e a partilha de recursos, independentemente da sua localização. Os sistemas distribuídos surgem com a intenção de tirar partido dessa partilha. Permite-se assim que utilizadores e aplicações acedam e partilhem recursos remotos de forma eficiente e controlada, beneficiando também de maior capacidade computacional e armazenamento disponibilizado. Por definição, um sistema distribuído é uma coleção de computadores independentes que o utilizador, idealmente, perceciona como um sistema único e coerente [33]. Isto é, apesar da heterogeneidade e variedade de computadores, um sistema distribuído tem que ser capaz de executar de modo determinístico e fiável, e a ser percecionado como um só. Para tal, é necessário que os computadores intervenientes colaborem entre si. Esta colaboração poderá ser feita, por exemplo, através de modelos de programação ou middlewares que permitam a troca de informação. Um sistema distribuído visa cumprir diversos objetivos. Contudo, apesar de apresentarem vantagens, comparativamente aos sistemas centralizados, estes objetivos aumentam a complexidade dos sistemas distribuídos. Desta forma, existem novos desafios e problemas que necessitam ser resolvidos. Neste contexto, surgem então os algoritmos distribuídos, para resolver as problemáticas inerentes à computação e sistemas distribuídos. Um algoritmo distribuído consiste num algoritmo que executa em computadores independentes que colaboram entre si. Estes computadores poderão executar considerando a possibilidade de falhas de alguns dos intervenientes. Alguns dos problemas que são resolvidos com algoritmos distribuídos são, por exemplo, a eleição de líder, pesquisa distribuída, geração de spanning-tree, exclusão mútua e alocação de recursos [21]. 1

20 CAPÍTULO 1. INTRODUÇÃO Um dos maiores problemas de computação distribuída é o estabelecimento de consenso. O problema de consenso requer que um conjunto de processos concorde com um determinado valor. Para tal, é necessário que exista um quórum de processos a decidir um dado valor v. Um algoritmo de consenso terá assim que funcionar por várias fases, garantindo que à medida que o algoritmo avança, exista um quórum de processos em sintonia. Para tal é necessário que cada processo comunique o seu estado aos restantes, tendo que comunicar periodicamente e/ou à medida que avança para cada fase do algoritmo. Este facto leva a que haja um número significativo de interações na rede. O comportamento de um algoritmo distribuído é, por norma, difícil de prever e verificar. Isto porque, mesmo que a sua implementação seja simples, o facto da sua execução correr paralelamente em diversos processos, com fases intercaladas de forma indeterminada, implica que possam haver diferentes comportamentos do algoritmo para os mesmos valores de entrada. Além disso, estes algoritmos enfrentam algumas incertezas que envolvem as condições da rede, como por exemplo a) falhas de comunicação; b) ordem de mensagens desconhecida; c) incerteza no tempo de entrega de mensagens; e d) vários nós a executar em simultâneo, começando em tempos diferentes e a trabalhar em velocidades diferentes [21]. Devido a estas incertezas, ao não-determinismo, e às inúmeras interações que passam pela rede, torna-se difícil verificar o funcionamento, correto ou incorreto, de um algoritmo. Isto é, torna-se difícil avaliar o desempenho ou a causa de erros de um algoritmo. Entre estas situações encontram-se problemas provocados por fenómenos de saturação, ou interferências entre diversos sistemas que partilham a rede. Este facto dificulta o processo de desenvolvimento e monitorização das aplicações. Considere-se o exemplo do trabalho de Almeida[1]. Este trabalho consistiu no desenho de um protocolo de encaminhamento, tolerante a intrusões, com consenso de dados numa rede de sensores sem fios. Este trabalho recorreu a um protocolo de encaminhamento, MINSENS++ [34], que introduz tolerância a intrusões através da existência de múltiplos caminhos disjuntos, para que, em caso de um nó corrompido, esse nó não prejudique a restante rede. As redes de sensores são constituídas por diferentes tipos de nós, existindo um tipo de nós, denominado estações de base, que contém maior capacidade computacional que os restantes. No âmbito deste trabalho, são estes os nós responsáveis por calcular as árvores de encaminhamento. O protocolo MINSENS++ pressupõe que estes nós podem ficar comprometidos, pelo que é necessário recorrer a resoluções por consenso para casos de divergência de valores entre estações de base da mesma rede de sensores. Parte do desenvolvimento deste trabalho foi dedicado a um estudo do desempenho do algoritmo de consenso utilizado. Neste estudo foram apontadas diversas dificuldades em avaliar a solução e o impacto que esta tem na rede. Nas conclusões deste estudo são apresentados problemas de performance e de escalabilidade que se mantêm inexplicáveis. Isto porque não existem métodos que permitam analisar as interações, via rede, à medida que o algoritmo é desenvolvido. Nota-se então a necessidade de depurar as comunicações de rede, de forma a perceber o impacto que esta poderá ter no algoritmo, ou vice-versa. A mesma necessidade é notada nas mais variadas situações e já foi alvo de alguns trabalhos 2

21 1.1. CONTEXTO E MOTIVAÇÃO no Departamento de Informática [7], [23]. A par com a evolução dos sistemas e algoritmos distribuídos, o uso das redes sem fios também tem vindo a aumentar. Com o aparecimento de dispositivos móveis, como computadores portáteis, sensores, telemóveis e tablets, existe a necessidade destes dispositivos se ligarem a uma rede independentemente da sua localização. Com velocidades cada vez maiores, o uso de redes WiFi, é de importância cada vez maior. No entanto, ao satisfazer esta necessidade, existe um acréscimo na complexidade da rede e a importância de lidar com os problemas antes apontados aos sistemas distribuídos. Uma rede WiFi funciona através do uso de ondas rádio, pelo que este meio de comunicação tem a particularidade de ser partilhado. Como tal, é possível que vários dispositivos tentem aceder ao mesmo meio. Devido a este facto, uma rede WiFi é suscetível de sofrer interferências internas, assim como externas à rede e que prejudicam o desempenho da mesma. Estas interferências podem ser provocadas por outros dispositivos rádio (telefones sem fios ou micro-ondas 1, por exemplo) ou outras redes que comuniquem através do mesmo canal de rádio. Numa rede WiFi podem também ocorrer colisões de pacotes, provocadas pelos nós da mesma. Estas colisões ocorrem quando mais do que um nó tenta aceder ao meio em simultâneo. Apesar de não ser possível controlar as interferências externas, existem mecanismos de controlo de acesso ao meio, de modo a evitar que dois dispositivos, da mesma rede, acedam em simultâneo. Estes mecanismos têm como objetivo minimizar as colisões, sendo responsáveis por decidir que estação pode aceder ao meio. No entanto, este processo cria um certo overhead na rede. Este overhead e as interferências externas, tornam uma rede mais lenta do que seria expectável, degradando-se com a utilização. Uma rede WiFi pode também ser alvo de um ou mais clientes maliciosos. Estes clientes podem alterar as suas definições de modo a consumirem grande parte da largura de banda da rede, prejudicando os restantes clientes e o desempenho total da rede. Há que considerar também o facto de uma rede ser mais volátil, devido à movimentação das estações, existe uma alteração constante do grafo da rede. Estes fatores tornam as redes mais imprevisíveis e instáveis, podendo ter períodos de inúmeras perdas de pacotes, devido a colisões ou congestionamento da rede. Considere-se assim um algoritmo de consenso executado num sistema distribuído numa rede WiFi. As incertezas que este enfrenta são agravadas pela instabilidade e imprevisibilidade da rede. Este acréscimo na complexidade da rede dificulta ainda mais a verificação e avaliação da execução real de um algoritmo distribuído. Em muitos casos, estes fatores não podem ser resolvidos com técnicas já conhecidas de verificação do código. Isto deve-se ao facto do desempenho observado pode ser degradado por fenómenos externos aos próprios algoritmos que se pretendem avaliar. Uma abordagem passa por monitorizar as próprias interações e o tráfego nessas redes. Esta monitorização não deverá, idealmente, interferir 1 Os telefones sem fios e micro-ondas funcionam no mesmo intervalo de frequências que algumas redes WiFi 3

22 CAPÍTULO 1. INTRODUÇÃO na rede ou nos programas em execução. Desta forma, será possível compreender melhor e avaliar o que realmente ocorre durante o funcionamento desses algoritmos, e despistar situações que de outro modo se não seriam detetadas. Existem trabalhos feitos com o intuito de controlar e melhorar a utilização e qualidade das redes WiFi que mostram a necessidade que existe de gerir a instabilidade deste tipo de redes. WiFox [9], por exemplo, conclui que os pontos de acesso constituem um bottleneck na rede, por não terem vazão para tratar dos pedidos de todas as estações. Com esta conclusão os autores propuseram a priorização dos pacotes do ponto de acesso. Naturalmente, após completar a solução proposta, os autores necessitaram de voltar a estudar o rendimento da rede, utilizando novamente a monitorização de tráfego. Nota-se assim, uma vez mais, a necessidade de um ambiente e regime controlado que permita a análise do impacto que um algoritmo distribuído tem na rede, principalmente no contexto das redes pela sua instabilidade e imprevisibilidade. Um elemento importante deste regime, será uma ferramenta capaz de monitorizar e distinguir o tráfego gerado pelo algoritmo do restante, assim como o tráfego gerado pelo protocolo Para tal, terá que se considerar todo o tráfego gerado numa rede WiFi para controlo do meio, filtrando este tráfego que se torna desnecessário para a compreensão do comportamento da rede, mas que poderá ser útil, a nível da aplicação, para obter alguns dados sobre o estado da rede. Através desta ferramenta será então possível angariar um conjunto de dados que possam dar uma visão generalizada do impacto que o algoritmo poderá ter na rede, ou vice-versa, e o seu desempenho, assim como das influências externas ou de outros nós da rede. 1.2 Objetivos Através das necessidades e dificuldades passadas em alguns dos trabalhos anteriormente referidos, justifica-se a existência de um conjunto de metodologias que ajude na depuração, e avaliação de um algoritmo e do seu impacto na rede. Devido ao uso recorrente de redes WiFi e das complicações que lhes são inerentes, esta dissertação propõe focar-se, como caso de estudo, em algoritmos distribuídos que usufruem de uma rede sem fios, recorrendo a técnicas de monitorização de tráfego WiFi. No entanto, qualquer sistema que gere tráfego na rede poderá beneficiar deste trabalho. O objetivo desta dissertação passa por auxiliar a implementação de algoritmos distribuídos com um conjunto de métodos que permitam avaliar e melhorar os tempos de execução do mesmo, recorrendo a técnicas de monitorização sem perturbar o sistema avaliado. Para tal, pretende-se focar na captura de pacotes , proporcionando um meio de avaliação das condições do algoritmo e da rede. Como complemento a este conjunto de métodos, pretende-se desenvolver um sistema de análise do tráfego da rede. Desta forma, existem duas fases de elaboração desta dissertação. Estas fases são explicadas de seguida. 4

23 1.2. OBJETIVOS Implementação de um sistema de análise Pretende-se criar um sistema de análise que permita avaliar as condições da rede. Isto é, através da monitorização das execuções do algoritmo, pretende-se que seja possível analisar o estado da rede e, consequentemente, tirar conclusões em relação aos tempos de execução vs condições da rede. Com este objetivo em mente, este sistema requer a existência de três componentes: Captura de Tráfego. Este componente deverá ser responsável pela captura de pacotes, por nós independentes do sistema em análise. Mais especificamente, este componente deverá ser capaz de capturar a informação do tráfego relevante, possivelmente baseado em ferramentas já existentes, como o TCPDump e/ou a biblioteca PCap [36], sem interferir e perturbar a rede e aplicação. Análise de Tráfego. O componente de análise de tráfego deverá ser responsável pela classificação e análise da informação recolhida. Esta análise terá como vista a identificação dos vários tipos de mensagens, seu número, volume e latência, ao longo do tempo. Visualização. Este componente deverá ser responsável pela apresentação da análise efetuada e correlação com a aplicação. Esta correlação, ao longo da execução do algoritmo distribuído e suas mensagens, tem como vista a explicação do desempenho e latência observada pela aplicação. Deverá ainda ser possível detetar as perturbações sofridas devido a outro tráfego, interferências ou fenómenos de saturação Estudo de um algoritmo O trabalho de Almeida refere como trabalho futuro a elaboração de testes mais exaustivos ao algoritmo de consenso. Deste modo, e aproveitando esta necessidade, pretende-se estudar a implementação de um algoritmo base deste trabalho [25]. Este algoritmo será utilizado para avaliação do sistema de análise implementado, mas também como base de estudo para o conjunto de metodologias futuramente apresentados. Tem-se como objetivo apresentar um conjunto de métodos que, podendo recorrer ao sistema de análise, consigam avaliar o funcionamento do algoritmo de consenso. Pretendese estudar o comportamento e desempenho do algoritmo em várias das configurações que antes foram deficientemente avaliadas. Através deste conjunto de metodologias tenciona-se completar os seguintes estudos: 1. Estudo do comportamento do algoritmo com recurso ao sistema de análise. Este estudo tenciona mostrar como é que o comportamento do algoritmo varia, dependendo do tempo de execução. 5

24 CAPÍTULO 1. INTRODUÇÃO 2. Estudo do desempenho do algoritmo com recurso à execução do algoritmo com diferentes parametrizações. Através destas execuções pretende-se comparar o impacto que as diferentes configurações do algoritmo podem ter. 3. Estudo do impacto do algoritmo na rede. Perante diferentes condições de rede, pretende-se determinar se o algoritmo prejudica outro tráfego que esteja a decorrer, ou se o tráfego extra prejudica a execução do algoritmo. 1.3 Estrutura do documento Este documento divide-se em seis capítulos. No capítulo 1 fez-se uma introdução ao problema que esta dissertação pretende resolver, mostrando o contexto e a motivação, descrevendo-se também os objetivos para este trabalhos. No capítulo 2 serão apresentados e introduzidos conceitos importantes para a compreensão dos desafios que esta dissertação encontra. Primeiro são introduzidos alguns detalhes do funcionamento das redes de computadores, com foco nas redes da norma IEEE e os desafios que existem neste tipo de redes. No fim deste capítulo são referidos conceitos de monitorização de tráfego, mais uma vez, com foco na captura de tráfego WiFi e, de seguida, são apresentadas algumas ferramentas existentes para monitorização de redes de computadores. No fim deste capítulo são apresentadas as conclusões tiradas após este estudo. No capítulo 3 são introduzidos conceitos e a noção de algoritmos de consenso, devido ao uso de um algoritmo de consenso para avaliação da solução proposta. Este capítulo exemplifica os algoritmos de consenso através da explicação dos algoritmos Turquois [25] e Multi-Valued Consensus [34], explicados nas secções 3.3 e 3.4. No capítulo 4 é apresentado o sistema de análise desenvolvido. Primeiro são explicados os requisitos necessários, passando ao detalhe dos componentes que constituem o sistema. No capítulo 5 é então exposto o conjunto de métodos de estudo. Começando por explicar a implementação do algoritmo Turquois usada e o ambiente de testes utilizado. De seguida são apresentadas as análises efetuadas ao algoritmo e os respetivos resultados. Por fim, no capítulo 6 são apresentadas as conclusões retiradas da elaboração desta dissertação e trabalho futuro. 6

25 C A P Í T U L O 2 MONITORIZAÇÃO DE REDES Este capítulo abordará alguns conceitos do escopo desta dissertação que serão importantes para a sua compreensão. Serão também abordados e referenciados alguns trabalhos já existentes de monitorização de tráfego. Na secção 2.1 serão introduzidos conceitos referentes ao funcionamento das redes sem fios, mais concretamente à norma IEEE e aos problemas que estão inerentes a este tipo de redes. Na secção 2.2 serão introduzidos conceitos relacionados com a monitorização e captura de tráfego de rede, assim como referências às especificações necessárias para a captura de tráfego numa rede sem fios. Por fim, na secção 2.3 serão apresentadas algumas ferramentas de captura de tráfego, e alguns casos de estudo onde se recorre à monitorização de tráfego específico de uma aplicação distribuída ou de somente um processo, para compreender ou melhorar o funcionamento de determinado sistema. Na secção serão apresentadas as conclusões do estudo feito às ferramentas de captura apresentadas. 2.1 Redes WiFi Uma rede local sem fios, Wireless Local Area Network (WLAN), consiste num conjunto de computadores, fixos ou portáteis, que comunicam entre si através de ondas rádio. No contexto das WLAN, cada computador ligado em rede é denominado de estação e várias estações ligadas entre si constituem um conjunto de serviços básico. Uma rede WiFi poderá conter vários conjuntos de serviços básicos de forma a aumentar a cobertura de rede. Para tal, este tipo de redes mantém dois ou mais conjuntos de serviços básicos ligados entre si, através de um sistema de distribuição. A comunicação entre o conjunto de serviços básico e o sistema de distribuição estabelece-se através de um ponto de acesso. O ponto de acesso é o dispositivo responsável por passar a informação do conjunto de serviços básicos para o respetivo sistema de distribuição, tal como é 7

26 CAPÍTULO 2. MONITORIZAÇÃO DE REDES responsável por estabelecer a comunicação entre estações. Quando uma rede funciona através desta arquitetura, a rede executa em modo infraestrutura. Desta forma, à medida que se movimenta, uma estação estará ligada ao ponto de acesso mais próximo, sem perder acesso à rede. A norma determina que o sistema de distribuição forneça um conjunto de serviços que podem ser divididos em serviços de estação e serviços de sistema de distribuição. Em suma, para dois conjuntos de serviços básicos existem dois pontos de acesso, um para cada, e ambos os pontos de acesso comunicam entre si através de um sistema de distribuição. Este sistema de distribuição poderá ser, por exemplo, uma rede ethernet. A este conjunto, no seu todo, denomina-se conjunto de serviços estendido. A figura 2.1 ilustra um exemplo de uma estrutura de um conjunto de serviços estendido. Sistema de Distribuição Ponto de Acesso Ponto de Acesso Estação Estação Estação Estação Estação Estação Conjunto de Serviços Básico Conjunto de Serviços Básico Figura 2.1: Exemplificação de um conjunto de serviços estendido No entanto, uma rede WiFi não requer sempre a existência de um ponto de acesso. Uma WLAN é considerada uma rede ad-hoc, ou um conjunto de serviços básicos independente, quando o conjunto de serviços básico não tem acesso a redes exteriores e as estações comunicam entre si ponto-a-ponto. A figura 2.2 ilusta uma rede ad-hoc Serviços de Sistema de Distribuição Os cinco serviços de sistema fornecidos pelo sistema de distribuição são: Associação. Quando uma estação pretende ligar-se a uma WLAN necessita juntar-se à infra-estrutura de um conjunto de serviços básico. Para tal, existe o serviço de associação que permite que uma estação se associe a um dado ponto de acesso. Reassociação. Um dos requisitos de uma rede WiFi é que permita a transição das estações entre conjuntos de serviços básicos da mesma rede. Este serviço permite que a estação se associe a outro ponto de acesso da mesma rede, sem perder conectividade. 8

27 2.1. REDES WIFI Estação Rede ad-hoc Estação Estação Figura 2.2: Exemplificação de um conjunto de serviços independente Dissociação. Este serviço consiste na terminação da associação entre uma estação e um ponto de acesso, deixando de ser possível a comunicação entre a estação e o ponto de acesso. Distribuição. Este serviço consiste na distribuição da informação. Quando uma estação A pretende enviar um pacote à estação B é enviado um pedido para o ponto de acesso do conjunto de serviços básico. De seguida, o pedido é transmitido através do sistema de distribuição até ao ponto de acesso a que a estação B se encontra associada. Integração. Este serviço é utilizado para permitir a comunicação com outro tipo de redes. Este serviço executa as alterações necessárias para que o pacote esteja de acordo com o protocolo da rede destino, e vice-versa. [3] Serviços de Estação Uma rede WiFi tem a particularidade de não se encontrar fisicamente limitada como no caso de uma rede ethernet. As redes IEEE utilizam ondas rádio para estabelecer a comunicação e como tal existe o problema de vários dispositivos utilizarem a mesma frequência de rádio quer tenham, ou não, o objetivo de enviar informação. Esta particularidade leva então à necessidade de identificar, autorizar e proteger a transmissão entre duas estações ou entre uma estação e um ponto de acesso. Para tal existem os seguintes serviços de estação: Autenticação. Este serviço consiste na verificação de que a estação é reconhecida e autorizada a comunicar com outra estação ou um ponto de acesso. Assim que a estação se encontra autenticada, esta pode prosseguir com o serviço de associação descrito anteriormente. Existem dois tipos de serviço de autenticação: Autenticação de Sistema Aberto, em que qualquer estação que se tenta autenticar pode comunicar na rede, e Autenticação de Chave Partilhada, em que as estações que se pretendem associar necessitam de ter uma chave secreta partilhada. 9

28 CAPÍTULO 2. MONITORIZAÇÃO DE REDES Revogação de Autenticação. Consiste na terminação do serviço de autenticação, deixando a estação de estar autenticada perante um ponto de acesso, a associação entre ambos deixa de existir. Privacidade. Este serviço consiste na garantia de privacidade da comunicação entre estação e ponto de acesso. Este serviço é garantido através da cifra do conteúdo dos pedidos, através de Wired Equivalent Privary (WEP) [12] ou Wireless Application Protocol (WAP) [26]. Este serviço poderá não ser utilizado, deixando a comunicação ser transmitida em claro e passível de sofrer ataques de eavesdropping 1. Serviço de entrega de unidade de dados MAC. Este serviço é responsável por garantir que os dados chegam ao seu destino. [8] Controlo de Acesso ao Meio Genericamente, a comunicação dos protocolos de rede pode ser feita através de dois tipos de ligação: 1) ligação ponto a ponto e 2) ligação por difusão. A ligação ponto a ponto permite conectar dois nós diretamente, havendo somente dois intervenientes na comunicação. A ligação por difusão permite que vários nós recebam e enviem pacotes através de um canal de comunicação partilhado. Neste caso, quando um pacote é transmitido, todos os nós recebem. As redes WiFi e Ethernet são exemplos de redes que utilizam ligação por difusão. No entanto, neste tipo de ligação ocorre o problema de múltiplo acesso. Este problema ocorre quando mais que um nó tenta aceder ao meio de comunicação. Nesta situação, existindo vários pacotes a ser transmitidos na rede, ocorre uma colisão e nenhum dos pacotes envolvidos chega corretamente ao destino. Considerando o exemplo da norma IEEE , esta recorre a ondas rádio para comunicar informação, utilizando o ar como meio de transmissão. Este facto possibilita que qualquer dispositivo rádio possa, potencialmente, emitir para este meio de difusão. O problema de múltiplo acesso encontra-se mais uma vez presente, estendendo-se até aos nós externos à rede. Isto porque, existindo duas redes a transmitir no mesmo canal rádio, as estações de ambas as redes competem pelo acesso ao mesmo meio de comunicação. De modo a combater o problema de múltiplo acesso foram criados protocolos de controlo de acesso ao meio. Estes protocolos visam controlar e coordenar os nós que acedem à rede, na tentativa de minimizar a ocorrência de colisões. De seguida são apresentados os mecanismos de controlo de acesso ao meio, tanto das redes Ethernet como das redes WiFi. 1 Eavesdropping consiste num ataque de redes de computadores em a informação que passa entre dois principais é "ouvida"por terceiros não autorizados 10

29 2.1. REDES WIFI CSMA/CD Como é sabido, as estações de uma rede comunicam através de uma ligação de difusão. Como tal, este protocolo recorre a um mecanismo de controlo de acesso ao meio. As redes ethernet executam um protocolo de deteção de colisões, denominado Carrier Sense Multiple Access with Collision Detection, vulgarmente conhecido como CSMA/CD [11]. Este protocolo pretende prevenir a ocorrência de colisões recorrendo a duas características das estações: a) percecionar quando outra estação se encontra a transmitir e b) detetar a colisão enquanto está a transmitir [16]. O protocolo CSMA/CD define que: 1. Uma estação nunca começa a transmissão de um pacote caso detete que existe outro nó da rede a transmitir. 2. Durante a transmissão de um pacote, se a estação detetar que existe mais atividade no meio, interrompe a sua transmissão. 3. Antes de retransmitir, é necessário esperar um tempo adicional para garantir que o meio não está a ser usado CSMA/CA Como referido anteriormente, o protocolo CSMA/CD requer que uma estação seja capaz de ouvir e transmitir para a rede em simultâneo, sendo capaz de interromper a transmissão em caso de colisão. Contudo, os dispositivos rádio de uma rede WiFi não possuem esta capacidade, pois se escutarem durante uma transmissão o seu próprio sinal será tão forte que só ouvem a sua própria emissão, impossibilitando a deteção de colisões. Para colmatar este problema, as redes utilizam uma versão modificada do protocolo CSMA/CD, o protocolo Carrier Sense Multiple Access with Collision Avoidance, vulgarmente conhecido como (CSMA/CA) [12]. A base da filosofia deste protocolo é semelhante à utilizada no protocolo CSMA/CD. Este novo protocolo utiliza a capacidade das estações analisarem o estado de utilização do canal. Contudo, como não é possível detetar a utilização do canal durante a transmissão, este protocolo foca-se em evitar a ocorrência de colisões, ao invés de as detetar. Desta forma, o protocolo CSMA/CA define que: 1. Quando a estação pressente que o canal está inativo, transmite o pacote após esperar um tempo adicional conhecido como DIFS (Distributed Inter-frame Space). 2. Caso o canal se encontre ativo, a estação espera um tempo aleatório para repetir a tentativa de envio. 3. Ao fim do tempo aleatório, quando o canal se encontra inativo, a estação transmite o pacote e espera pela chegada de um pacote ACK. 11

30 CAPÍTULO 2. MONITORIZAÇÃO DE REDES 4. Ao receber o pacote ACK, a estação reconhece que o seu pacote foi recebido no nó destino. Se a estação tiver mais pacotes para transmitir, recomeça o processo no passo 2. Caso o pacote ACK não seja recebido, é estabelecido mais um tempo aleatório para recomeçar a fase 2, desta vez com um intervalo de tempo maior. No caso do nó destino, quando este recebe um pacote de dados, e após verificar a integridade do pacote, espera um intervalo de tempo conhecido como SIFS (Short Interframe Space), para depois enviar o respetivo ACK. Este processo é descrito na figura 2.3. A B DIFS { Dados ACK } SIFS Figura 2.3: Representação do protocolo CSMA/CA RTS/CTS e O Problema do Nó Escondido Ao contrário das redes ethernet em que todas as estações se ouvem entre si, as redes WiFi, devido ao uso de ondas de rádio, não garante que todas as estações da rede sejam capazes de ouvir as restantes. Apesar de implementação do protocolo CSMA/CA, este facto leva a que este protocolo não seja capaz de evitar ou detetar todas as colisões possíveis. Reconhece-se assim um problema adicional, conhecido como o Problema do Nó Escondido. Este problema ocorre, por exemplo, quando numa rede existem três estações A, B e C e, sendo B o ponto de acesso, por exemplo. Devido à distância entre as estações A e C, a estação B consegue alcançar ambas A e C mas A não alcança C nem C alcança A. Esta situação está predisposta à ocorrência de colisões, visto que quando A quiser transmitir não conseguirá detetar se C está ou não a transmitir, e vice-versa. De modo a resolver este problema foi criado o protocolo Request To Send/Clear to Send (RTS/CTS) [12] na camada MAC. Este protocolo define que, quando uma estação quer transmitir, seja enviado um pacote de pedido de envio, conhecido como Request to Send (RTS), ao ponto de acesso. A estação emissora terá assim que esperar pela receção de um 2 Figura baseada em [16] 12

31 2.1. REDES WIFI pacote de autorização de envio, Clear to Send (CTS). Só após a receção de um pacote CTS é que a estação estará autorizada a enviar o seu pacote. Como todas as estações conseguem ouvir a atividade do ponto de acesso, quando um CTS é enviado todas as estações ficam cientes de que o meio está ocupado. Este processo garante que o meio fica reservado, deixando as restantes estações em espera durante a transmissão do pacote. Deste modo existem garantias de que, mesmo que a estação C não consiga ouvir a estação A, a estação C é notificada por B e não corre o risco de transmitir ao mesmo tempo que a estação A. Este processo é exemplificado na figura 2.4. RTS Área notificada após RTS A B C CTS Área notificada após CTS Figura 2.4: Exemplificação do protocolo RTS/CTS Funções de Coordenação As redes WiFi utilizam vários protocolos para partilha do meio de comunicação. Estes protocolos são denominados funções de coordenação. Existem duas funções de coordenação, sendo estas a função de coordenação distribuída, Distributed Coordination Function (DCF), e a função de coordenação central, Point Coordination Function (PCF). DCF A função DCF, sendo um algoritmo distribuído executado por todas as estações, pode ser utilizado tanto por redes ad-hoc como por redes em modo infra-estrutura. Esta função executa os protocolos CSMA/CA e RTS/CTS apresentados nas secções e , respetivamente. A figura 2.5 ilustra o funcionamento da função DCF. PCF A função PCF é somente utilizada em redes em modo infra-estrutura, devido à sua necessidade de uma estação central executar o algoritmo de coordenação. Nesta função de coordenação o tempo é dividido em superframes. Cada superframe é dividida entre um periodo de contenção, Contention Period (CP), em que é utilizada a função DCF, e um período livre de contenção, Contention Free Period (CFP), em que é utilizada a função PCF. 3 Figura baseada em [6] 4 Figura baseada em [16] 13

32 CAPÍTULO 2. MONITORIZAÇÃO DE REDES DIFS { A RTS B Restantes nós da rede SIFS CTS } SIFS { Dados ACK } SIFS Acesso diferido Figura 2.5: DCF com implementação dos protocolos CSMA/CA e RTS/CTS 4 Como o nome indica, o período livre de contenção elimina a necessidade das estações competirem pelo meio, sendo o ponto de acesso responsável por coordenar as estações. O ponto de acesso elege, à vez, a estação autorizada a transmitir. Através de uma lista ordenada por prioridade, o ponto de acesso envia um pacote do tipo CF-Poll à estação eleita. Após a receção deste pacote, se a estação eleita tiver dados para transmitir, prossegue com a transmissão do pacote e ACK respetivo ao pacote CF-Poll. Este processo repete-se para todas as estações da lista. Para garantir que as estações a transmitir através da função DCF não interfiram com a função PCF, antes de se dar início a este período, existe um tempo de espera denominado PCF Inter-frame Space (PIFS). Após este tempo de espera, a função PCF dá início ao período CFP quando o ponto de acesso envia um pacote beacon. O período livre de contenção terminado quando o ponto de acesso envia um pacote do tipo CF-End. A estrutura de uma superframe é ilustrada pela figura 2.6. Superframe PA Beacon Dados + CF-Poll Período livre de contenção - CFP Dados + CF-Ack + CF-Poll Dados + CF-Ack + CF-Poll Dados + CF-Poll CF-End Período de contenção - CP EST 1 Dados + CF-Ack EST 2 Dados + CF-Ack DCF EST 3 EST 4 Dados + CF-Ack PIFS SIFS SIFS SIFS SIFS SIFS PIFS SIFS SIFS PA não obteve resposta de EST 3 Figura 2.6: Estrutura de uma superframe 5 14

33 2.1. REDES WIFI Gestão de Energia Uma rede sem fios pode ser constituída por vários dispositivos móveis, podendo estes ser portáteis, telemóveis, tablets, etc. Para estes dispositivos a gestão de energia é importante para aumentar o tempo útil de bateria. Como tal, o protocolo possibilita que as estações alternem entre os estados ativo e inativo, de modo a pouparem energia durante os períodos inativos. O modo de poupança de energia começa quando a estação A notifica o ponto de acesso que irá alterar o seu estado para inativo. Com esta notificação, o ponto de acesso sabe quais são as estações que se encontram no período de poupança de energia. Durante este período, se o ponto de acesso receber um pacote que seja destinado à estação A, sabendo que esta se encontra em modo inativo, em vez de transmitir o pacote, este é mantido em espera num buffer. O ponto de acesso envia periodicamente pacotes beacon (tipicamente a cada 100ms [16]). Estes pacotes contêm a lista de estações com pacotes em espera para serem enviados. Quando a estação A retorna ao estado ativo, ao receber um beacon verifica se existem pacotes para receber. Caso verifique que não, retorna ao estado inativo. Caso verifique que sim, envia um pacote ao ponto de acesso a pedir que lhe sejam transmitidos os pacotes em espera. Deste modo, uma estação não necessita estar em modo ativo durante períodos em que não hajam pacotes que lhe sejam destinados. Este método de gestão de energia é utilizado em redes em modo infraestrutura. Considerando redes ad-hoc, o método anterior não poderá ser aplicado pela inexistência de um nó centralizado. Por este motivo, o método de gestão de energia em redes ad-hoc é diferente. No caso destas redes, todas as estações emitem pacotes beacon. O tempo é dividido em intervalos de beacon, e cada intervalo de beacon é dividido em dois intervalos, a janela ATIM (Announcement Traffic Indication Message Window) e a janela de dados. Se uma estação pretender transmitir dados, é necessário emitir um pacote ATIM durante o período de uma janela ATIM, para então estar autorizada a competir pela transmissão do pacote durante o período da janela de dados. Caso contrário, se a estação não emitir um pacote ATIM, durante o período de uma janela ATIM, entra em estado inativo durante o período da janela de dados [32]. No caso de estações que se encontrem em modo inativo, é necessário que a estação passa para modo ativo ao receber um pacote beacon, mantendo-se em estado ativo durante o período da janela ATIM. Caso esta estação receba um pacote ATIM, terá que se manter ativa, durante o período da janela de dados, para receber o pacote que lhe é destinado Tipos de Pacotes Face ao exposto anteriormente, o tráfego consiste em três tipos de pacotes: pacotes de dados, pacotes de gestão e pacotes de controlo. De seguida serão listados os sub-tipos de pacotes presentes no tráfego de uma rede WiFi. 5 Figura baseada em [41] 15

34 CAPÍTULO 2. MONITORIZAÇÃO DE REDES Pacotes de Dados Estes pacotes transportam os dados da rede. Tipicamente, estes pacotes são provenientes de outros protocolos (por exemplo IP, TCP, UDP, etc) e são encapsulados para que as estações e pontos de acesso possam interpretar os pedidos que provêm destes pacotes. Os pacotes de dados podem também ser aproveitados para fazer piggyback 6 de outro tipo de informação, como por exemplo, pacotes ACK. Dados: pacote utilizado para enviar dados CF-ACK: pacote de reconhecimento utilizado durante o período livre de contenção CF-Poll: pacote de eleição utilizado durante o período livre de contenção Dados+CF-ACK: pacote de dados com piggyback do pacote CF-ACK Dados+CF-Poll: pacote de dados com piggyback do pacote CF-ACK Dados+CF-ACK+CF-Poll: pacote de dados com piggyback dos pacotes CF-ACK e CF-Poll CF-ACK+CF-Poll: pacote CF-ACK com piggyback do pacote CF-Poll Função nula: pacote enviado pela estação para anunciar que entrará em modo de poupança de energia Pacotes de Gestão Os pacotes de gestão estão associados aos serviços de sistema de distribuição e de estação. Estes pacotes são enviados quando uma estação se pretende associar, autenticar, dissociar, reassociar ou terminar a autenticação. Dentro desta classificação encontram-se também os pacotes que as estações e os pontos de acesso enviam para determinar a acessibilidade dos nós e da rede (os pacotes beacon, por exemplo, são enviados esporadicamente pelos pontos de acesso para anunciar às estações que se encontram ativos e acessíveis). Os subtipos dos pacotes de gestão são: Beacon: pacote enviado pelo ponto de acesso para anunciar a sua presença Pedido de sondagem: pacote é enviado pelas estações que procuram os pontos de acesso disponíveis Resposta de sondagem: pacote é enviado pelos pontos de acesso após a receção de um pedido de sondagem Autenticação: pacote enviado quando uma estação pretende autenticar-se perante um ponto de acesso 6 Mecanismo que tenta minimizar os pacotes enviados, acrescentando informação dos pacotes de reconhecimento, por exemplo, a pacotes de dados 16

35 2.2. MONITORIZAÇÃO Revogação de Autenticação: pacote enviado para anunciar a terminação de autenticação Pedido e Resposta de Associação: pacotes enviados durante o serviço de associação de uma estação a um ponto de acesso Pedido e Resposta de Reassociação: pacotes enviados durante o serviço de reassociação de uma estação a um ponto de acesso Dissociação: pacote enviado para anunciar a terminação da associação entre estações Mensagem de anúncio da indicação de tráfego: pacote enviado durante o período da janela ATIM, para indicar que a estação pretende enviar um pacote de dados Pacotes de Controlo Estes pacotes são responsáveis pelo controlo de acesso ao meio, informando as estações e os pontos de acesso quando é que podem, ou não, enviar informação. Os pacotes Request to Send e Clear to Send, por exemplo, fazem parte do mecanismo de controlo de acesso ao meio, RTS/CTS, já referido anteriormente na secção Os subtipos dos pacotes de controlo são: RTS: pacote de pedido de envio CTS: pacote de autorização de envio ACK: pacote de reconhecimento CF-End: pacote de terminação do período livre de contenção CF-End+ACK: pacote CF-End com piggyback do pacote ACK Power Save Poll: pacote enviado pela estação para pedir que lhe sejam transmitidos os pacotes que ficaram em espera durante o período de poupança de energia 2.2 Monitorização A monitorização da rede é baseada na escuta ou captura do tráfego de rede que circula no meio de comunicação. Este método consiste em capturar os pacotes que são recebidos e enviados pelo dispositivo que se pretende monitorizar, ou por outro que tenha acesso ao meio e possa obter essa informação. Para explicar o processo de monitorização é preciso explicar antes o que acontece no dispositivo quando este recebe um pacote. Quando um dispositivo recebe um pacote ethernet, por exemplo, a placa de rede verifica se o endereço MAC corresponde ao dispositivo, em caso positivo o pacote é encaminhado para o controlador de rede. A este ponto é preciso identificar os protocolos do pacote para este ser encaminhado à camada de protocolos suportados pelo SO e suas aplicações. Para tal é preciso ter em 17

36 CAPÍTULO 2. MONITORIZAÇÃO DE REDES consideração que um pacote contém informação sobre os diversos protocolos a que se rege. A figura 2.7 mostra o exemplo de um pacote TCP, assim para concluir que este é um pacote TCP é necessário interpretar os diferentes cabeçalhos. Esta tarefa está encarregue ao controlador de rede e pilha de protocolos. A partir do momento em que um pacote é recebido pelo controlador de rede, os cabeçalhos são vistos um a um para identificar o protocolo e encaminhar o pacote ao devido handler da pilha de protocolos. Este processo acaba quando se consegue obter os dados do pacote e encaminhá-los à camada de aplicação para que sejam devidamente processados ao nível do processo utilizador. Cabeçalho Ethernet Cabeçalho IP Cabeçalho TCP Dados Ethernet Checksum Figura 2.7: Estrutura de um pacote ethernet Quando um programa de monitorização da rede se encontra a correr num dispositivo, o controlador de rede, para além do processo antes descrito, transfere uma cópia dos pacotes para um mecanismo de captura de pacotes. Em sistemas Unix, por exemplo, existe um módulo no núcleo do sistema, chamado Packet Filter que aplica filtros na captura, como exemplifica a figura 2.8. A biblioteca PCap [36], referida na secção 2.2.1, permite aceder a estes mecanismos, em particular os mecanismos baseados no Berkeley Packet Filtering (BPF) [24] ou suas variantes. Este mecanismo é o componente que permite controlar os tipos de pacotes que são recolhidos durante a monitorização. Este componente torna-se bastante importante em casos em que o administrador da rede não queira ver todos os pacotes que estão a passar na rede e quer limitar-se, por exemplo, a visualizar pacotes UDP, ou só os que envolvem determinado protocolo/porto. O Packet Filter permite assim especificar filtros de captura, minimizando a quantidade de dados que passam do núcleo para o nível de utilizador, que depois fará o processamento que acha necessário Biblioteca PCap Os sistemas operativos oferecem um mecanismo de monitorização de tráfego, não sendo necessário o uso de ferramentas externas para o mesmo. A biblioteca, de código aberto, PCap [36] oferece uma interface de alto nível que permite aceder a este mecanismo independentemente do sistema operativo usado. Esta biblioteca foi criada com o intuito de haver uma abstração de alto nível que permita ao programador aceder ao mecanismo de captura de pacotes, sem se preocupar com as particularidades do sistema operativo. Existindo em diferentes versões para Windows e Unix, WinPCap [38] e LibPCap [36], respetivamente. Esta ferramenta permite assim a elaboração de um programa, numa linguagem de alto nível (C/C++), com o intuito de capturar o tráfego da rede permitindo também a escolha de uma interface de rede, 7 Figura baseada em [22] 18

37 2.3. FERRAMENTAS DE CAPTURA Pacote Recebido / Transmitido Packet Filter Sniffer Monitor de Rede Pacotes Placa de Rede Driver de Rede Navegador Pilha de Protocolo Servidor FTP Hardware Núcleo de SO Utilizador Figura 2.8: Elementos envolvidos na captura de pacotes 7 filtros de pacotes e modos de captura (os modos promíscuo e monitor são suportados pela biblioteca). Como mencionado anteriormente, o mecanismo de captura suporta diferentes filtros para minimizar, logo à partida, a quantidade de dados que é passada do núcleo para o nível de utilizador. Os filtros são definidos a alto nível e convertidos para filtros reconhecidos pelo núcleo do sistema. No caso do sistema Unix, como referido anteriormente, o filtro reconhecido é o Berkeley Packet Filtering [24], existindo uma implementação para os sistema Linux denominado Linux Socket Filtering (LSF). Contudo, caso seja definido um filtro que não seja suportado diretamente pelo núcleo, a biblioteca PCap implementa o filtro internamente, em nível utilizador, oferecendo ao utilizador/programador a mesma interface, independentemente do sistema operativo. Esta biblioteca permite também guardar as capturas em ficheiros, no formato pcap, de modo a poderem ser consultadas a partir de programas de análise ou visualização gráfica, como por exemplo Wireshark. 2.3 Ferramentas de Captura As ferramentas baseadas na captura de tráfego podem operar de diferentes formas, consoante os seus objetivos, assim como as relações entre desempenho, uso de memória e perturbação do sistema monitorizado. Para além do processo da captura de pacotes anteriormente explicado, a monitorização de tráfego pode ser classificada como online, offline, ativa e passiva. Online. A visualização dos pacotes capturados é feita em tempo real, durante a monitorização. Offline. A visualização e análise dos pacotes só é possível após a terminação da captura. 19

38 CAPÍTULO 2. MONITORIZAÇÃO DE REDES Activa. Permite que o utilizador altere os parâmetros e os filtros da monitorização enquanto esta se encontra a decorrer. Passiva. A monitorização é levada a cabo sem qualquer intervenção no sistema, só sendo possível visualizar os dados. Independentemente do modo de funcionamento destas ferramentas, existem diferentes modos de captura. Os modos de captura disponíveis dependem das interfaces de rede, e respetivos controladores no núcleo do sistema. Estes modos definem o tipo e quais os pacotes que a ferramenta consegue capturar. Considerando o foco desta dissertação em redes , é necessário considerar a particularidade dos pacotes deste protocolo terem cabeçalhos específicos. Dependendo do modo de captura, poderá ser possível visualizar e analisar, ou não, os cabeçalhos do protocolo Para estes pacotes existem dois modos de processamento, ou são processados e traduzidos para falsos pacotes ethernet, ignorando a informação do protocolo , ou podem conter os cabeçalhos específicos do protocolo. Estes cabeçalhos contêm, por exemplo, informação referente ao tipo de pacote (gestão, controlo ou dados), tal como informação de nível rádio, como a força do sinal da rede ou o canal em que está a decorrer a transmissão. Modo Promíscuo. O modo promíscuo permite que o programa capture todos os pacotes que chegam ao controlador do dispositivo, mesmo que os pacotes não sejam destinados ao mesmo. Este modo permite assim apanhar todos os pacotes que estão a passar na rede. No contexto de redes sem fios, este modo de captura só permite capturar os pacotes a partir do momento em que o dispositivo se encontra autenticado perante um ponto de acesso. Os pacotes capturados neste modo serão traduzidos para falsos pacotes ethernet. Modo Monitor. Este modo de captura permite que o dispositivo apanhe o tráfego de todos os pontos de acesso que estiverem a transmitir no canal. A particularidade do modo monitor é que o dispositivo não necessita estar associado e autenticado a um ponto de acesso ou rede ad-hoc. Quando este modo se encontra ativo, o dispositivo é dissociado do ponto de acesso. Se o dispositivo só possuir um adaptador de rede, este modo impossibilita o dispositivo de comunicar em rede e só permite a receção de pacotes para que estes sejam passados ao programa de monitorização. Caso o dispositivo possua mais que um adaptador de rede, consegue comunicar com os restantes nós através do adaptador de rede adicional. O modo monitor só pode ser ativado em redes sem fios e permite a captura de cabeçalhos rádio. Este modo é assim o mais indicado no contexto desta dissertação, sendo a única maneira de capturar dados do protocolo Existem inúmeras ferramentas de monitorização de tráfego de rede, na sua maioria baseadas na biblioteca PCap, contudo, existem duas que merecem algum destaque sendo 20

39 2.3. FERRAMENTAS DE CAPTURA elas Wireshark e TCPDump [36], a seguir descritas. Serão também referidos alguns trabalhos antes realizados no Departamento de Informática com base nestas ferramentas e biblioteca TCPDump TCPDump [36] é uma ferramenta de monitorização de rede executada através da linha de comandos do sistema Unix, ou Windows. No caso do sistema Windows, a versão da ferramenta chama-se WinDump [37]. Esta ferramenta utiliza a biblioteca LibPCap para captura de tráfego e permite a aplicação de diversos tipos de filtros. É possível visualizar os resultados no terminal ou guardá-los em ficheiro. O TCPDump serve como base e referência para muitos outros sistemas de monitorização e análise de tráfego [35], como por exemplo: capinfo, tcpstat, tcptrace, etc. A ferramenta Wireshark, explicada na secção 2.3.2, permite a obtenção de estatísticas do tráfego e tem como base o TCPDump Wireshark Wireshark [39] é uma ferramenta de monitorização passiva de tráfego que permite capturar, visualizar e analisar os pacotes de que passam por uma dada interface de rede. Sendo uma ferramenta de código aberto, permite expandir as suas funcionalidades através do desenvolvimento de plug-ins e extensões. Para a monitorização da rede, o programa apresenta as diversas interfaces de rede existentes no dispositivo, para que o utilizador possa indicar qual usar. Após a escolha da interface de rede, o utilizador tem diversas opções ao seu dispor, como, por exemplo, filtros de captura, modos de captura e tipos de cabeçalhos que pretende visualizar. Durante a monitorização é apresentada uma lista, que mostra a captura de pacotes em tempo real (modo online), e que para pacote mostra a informação da Tabela 2.1. N o Sequência Tempo Origem Destino Protocolo Tamanho Informação Tabela 2.1: Tipo de informação apresentada sobre cada pacote Ao aceder à informação de cada pacote é possível aceder aos campos que estão nos vários cabeçalhos do pacote (por exemplo, IP - IPv4 - TCP - HTTP). A ferramenta faz a interpretação dos pacotes de modo a, à medida que são apresentados, indicar o protocolo a que estes correspondem e fornece vários tipos de visualização de estatísticas e informações sumárias da captura num todo. Através desta ferramenta é possível fazer capturas tanto em modo promíscuo como em modo monitor, com o pormenor de que esta capacidade estará dependente do adaptador de rede do dispositivo. 21

40 CAPÍTULO 2. MONITORIZAÇÃO DE REDES Wireshark para Sistemas Distribuídos O trabalho de Farruca [7] focou-se na monitorização de sistemas distribuídos, isto é, na monitorização dos processos que se encontram a executar nos computadores que constituem o sistema distribuído. Considerando o Wireshark, esta ferramenta atualmente não permite filtrar o tráfego de rede por aplicação, nem de capturar o tráfego a partir de diversos computadores. Assim, a principal motivação deste trabalho foi contribuir com uma ferramenta que permita monitorizar uma aplicação distribuída em concreto. Para tal, este trabalho recorreu à biblioteca PCap, igualmente utilizada pelo Wireshark, para captura do tráfego. De modo a monitorizar o tráfego do processo, o mesmo é identificado para que o seu descritivo seja usado para obter os sockets em uso. É assim possível criar um filtro para a ferramenta PCap, com base nas portas usadas pelo processo. De modo a que a captura não necessite de ser iniciada manualmente em cada computador, um a um, o processo de monitorização é iniciado num computador que, ao detetar o processo a ser monitorizado, consegue detetar os computadores que se encontram a comunicar com este, e propagar o processo de monitorização por todos os intervenientes do sistema distribuído. Após a monitorização de todos os processos estar concluída, existe um elemento central que recolhe os resultados de cada monitorização para elaborar o relatório final. Este relatório apresenta os pacotes que passaram na rede durante a monitorização, devidamente ordenados, dando a possibilidade de filtrá-los e ainda de mostrar o grafo do sistema distribuído Monitorização de tráfego de rede de um processo com base no PCap O trabalho de Farruca [7] recorre à monitorização de processos de modo a garantir a captura do tráfego gerado por uma aplicação distribuída. Contudo, o resultado produzido faz uso de filtros a nível do utilizador para identificar e filtrar o tráfego da aplicação, aumentando a carga do programa de captura. O trabalho de Martins [23] focou-se na otimização da monitorização do tráfego de rede de somente um processo. Tendo em conta os objetivos deste trabalho, pretende-se assim em utilizar mecanismos internos ao núcleo do sistema para monitorizar e filtrar o tráfego gerado por um processo sem causar perturbações no sistema. Ao focar a monitorização para o tráfego gerado por um programa e ao centrar a análise desse tráfego no núcleo do sistema, este trabalho pretende simplificar o processo de filtragem do tráfego e minimizar o conhecimento necessário sobre a aplicação para levar a cabo a mesma. A implementação deste trabalho focou-se no desenvolvimento de um módulo do núcleo que fosse uma extensão do Linux Socket Filtering, uma implementação do Berkeley Socket Filter referido anteriormente. O módulo desenvolvido acrescenta a opção de monitorizar o tráfego gerado por um processo e, o facto deste módulo ter sido implementado a nível do núcleo, permite que qualquer aplicação possa ser monitorizada sem alterações ao seu código. O facto deste módulo ser uma extensão do LSF permite também que as 22

41 2.3. FERRAMENTAS DE CAPTURA ferramentas de monitorização baseadas no LipPcap possam beneficiar deste módulo. Deste modo, foi possível desenvolver uma solução que permitisse a captura do tráfego gerado por um processo e, pelo facto desta monitorização ser levada a cabo a nível do núcleo, não se observam perturbações no sistema nem na aplicação a ser analisada Conclusões Face aos objetivos expostos na secção 1.2, as ferramentas anteriormente apresentadas foram alvo de estudo. Na secção é apresentado o Wireshark, uma ferramenta de monitorização de rede que possibilita a captura de pacotes e a visualização de pacotes de dados, gestão e de controlo. Esta ferramenta permite assim distinguir os diferentes tipos de pacotes, desencapsular os pacotes de dados e apresentar os diferentes protocolos que destes fazem parte. No entanto, não possibilita a distinção do tráfego gerado pelo algoritmo, impossibilitando a análise do tráfego útil para a avaliação do funcionamento e desempenho do algoritmo distribuído. Esta ferramenta também não permite uma clara análise da utilização da rede pelo algoritmo ou pelos vários tipos de pacotes WiFi. Tal como não permite identificar fenómenos de congestionamento ou interferências que estejam a reduzir o desempenho da rede. O trabalho de Farruca, Wireshark para Sistemas Distribuídos, [7] é apresentado na secção Esta ferramenta, baseada no Wireshark para colmatar as suas limitações, permite monitorizar um sistema distribuído. Isto é, esta ferramenta é capaz de distinguir e filtrar o tráfego gerado por uma aplicação distribuída e, correndo instâncias das ferramentas em todos os nós, capturar as interações que ocorrem durante a execução da mesma. No entanto, a solução implementada causa perturbações no sistema onde decorre a monitorização e, no contexto desta dissertação, não captura pacotes específicos do protocolo , sendo incapaz de distinguir, perante o tráfego de uma rede WiFi, os tipos de pacotes que estão a ser transmitidos na rede. Na secção é apresentado o trabalho de Martins, Monitorização de tráfego de rede de um processo com base no PCap [23] que por sua vez foca-se em colmatar as limitações do trabalho de Farruca, mitigando as perturbações que a monitorização de um processo pode causar no sistema. Este trabalho foca-se somente nesta problemática, como tal não oferece meios automatizados de monitorizar todos os nós que executam a aplicação distribuída, e assim obter as interações que ocorrem durante a execução desta. Esta ferramenta limita-se a identificar o tráfego de um processo, não ajudando na captura de outro tráfego (WiFi ou outro) nem na identificação dos problemas já apresentados que ocorram durante o funcionamento de uma aplicação distribuída. Nota-se, mais uma vez, uma lacuna nas ferramentas desta índole e no modo como lidam com o tráfego , que, como referido por Schulman et al. [31], tem problemáticas inexistentes na monitorização de tráfego (por exemplo). A acrescentar a estes desafios, não existem ferramentas que possibilitem a monitorização e distinção de tráfego de uma 23

42 CAPÍTULO 2. MONITORIZAÇÃO DE REDES aplicação distribuída da do restante tráfego da rede. Este facto dificulta a avaliação e depuração do funcionamento e desempenho de um algoritmo distribuído, aliado à falta de um regime de estudo controlado, não existem métodos a que o programador possa recorrer durante o desenho, ou avaliação do funcionamento, de um algoritmo ou aplicação distribuídos. 24

43 C A P Í T U L O 3 ALGORITMOS DE CONSENSO Este capítulo abordará conceitos para a compreensão de algoritmos de consenso, seguidos de alguns algoritmos de exemplo. A secção 3.1 apresenta os conceitos necessários para a compreensão de algoritmos de consenso. De seguida a secção 3.2 apresenta o algoritmo de referência Paxos. As secções 3.4 e 3.3 apresentam os algoritmos utilizados no trabalho de motivação a esta dissertação. 3.1 Definição Algoritmos distribuídos são algoritmos desenhados para correr em vários processadores ligados entre si. Partes de um algoritmo distribuído correm concorrente e independentemente, cada uma com uma quantidade de dados limitada. Os algoritmos são supostos correr corretamente, mesmo que um dos processadores ou canais de comunicação operem em velocidade diferentes e até em caso de falha. [21] Um algoritmo de consenso é um algoritmo distribuído que visa resolver o problema de consenso. Esta classe de algoritmos serve de base à resolução de muitos dos problemas específicos dos ambientes distribuídos, como, por exemplo, a eleição de processos líder, coordenação entre os processos, sincronização, etc. O problema de consenso requer que processos distribuídos cheguem a acordo quanto a um determinado valor. Para tal, este problema requer que sejam cumpridas as seguintes propriedades: Validade. Se todos os processos propõem um valor v, então v será o valor acordado. Acordo. Dois processos corretos não podem decidir valores diferentes. Terminação. Todos os processos corretos decidem eventualmente 1 um valor. 1 Do inglês eventually, que implica que irá acontecer algures no tempo 25

44 CAPÍTULO 3. ALGORITMOS DE CONSENSO Integridade. Se um processo correto decide v, então v foi a proposta inicial de algum processo. O algoritmo de consenso começa com a proposta de valores dos processos, sendo, no final, acordado um desses valores propostos. Considera-se que se chegou a um consenso quando um quórum de processos decide o mesmo valor, sendo o quórum (n/2) + 1, em n processos. Durante este processo é necessário tolerar a falha de processos, podendo estes falhar por paragem ou por serem corrompidos. Existindo assim dois tipos de falhas: Falhas por Paragem. Denominam-se falhas por paragem, os casos em que um processo deixa de executar, cessando todas as suas operações. Falhas Bizantinas. Consideram-se falhas bizantinas quando um processo toma um comportamento inesperado. Este comportamento pode passar por enviar mensagens erradas, incompletas, a enviar informação diferente a processos diferentes ou processos a deixar de responder temporariamente (simulando uma falha por paragem). Este tipo de falhas são mais difíceis de detetar. Neste contexto, só é possível chegar a um consenso quando se limitam a f falhas bizantinas, com f < n 3. O funcionamento do algoritmo altera também consoante o modelo temporal que assume. Os tipos de sincronismo que se podem considerar em algoritmos de consenso são: Síncrono. Assume-se um modelo síncrono quando a interação ocorre num intervalo de tempo limitado, sendo o envio e a receção bloqueantes. Assíncrono. Assume-se um modelo assíncrono quando não se conseguem assumir limites de tempo na interação, não podendo o envio e a receção bloquear o processo, sob pena de nunca se conseguir desbloquear. O tipo de falhas que o algoritmo tolera terá impacto no funcionamento do mesmo [27] [19], alterando as especificações necessárias para calcular o quórum do consenso. Existem diversos algoritmos de consenso consoante os modelos de falhas e sincronismo. Existem protocolos deterministas (Paxos [17], por exemplo) que são os protocolos considerados previsíveis, em que valores de entrada iguais geram sempre os mesmos valores de saída, e que permitem assumir um tempo limite para a sua terminação. Existem também protocolos probabilísticos, que recorrem a processos estocásticos, tornando-se em algoritmos imprevisíveis. Neste caso os valores de saída nem sempre são os mesmos para valores de entrada iguais e, em oposição aos algoritmos deterministas, não permitem assumir tempo limite para a sua terminação. O algoritmo Turquois [25], explicado na secção 3.3 é considerado um algoritmo probabilístico. 26

45 3.2. PAXOS 3.2 Paxos Paxos [17] é um algoritmo de consenso assíncrono com modelo de falhas por paragem. Neste algoritmo os processos são classificados em três agentes a) proposers b) acceptors e c) learners, podendo um processo assumir o papel dos três agentes. O algoritmo executa em vários rondas em que cada ronda é dividida por duas fases. A figura 3.1 ilustra a execução correta do algoritmo Paxos. Fase 1a: Preparação O proposer, cria uma proposta identificada por um número n. Este valor n terá que ser maior do que qualquer outro número de proposta por este proposer. De seguida, o proposer envia uma mensagem do tipo prepare, contendo o valor proposto, para um quórum de acceptors. O proposer é quem decide que acceptors constituem o quórum. Fase 1b: Promessa O acceptor, ao receber uma mensagem do tipo prepare, verifica se o valor n é o maior valor que já recebeu de qualquer proposer. Se o valor for o mais elevado até à data recebido, o acceptor envia uma promessa de que irá ignorar propostas futuras que sejam menores que o valor n recebido. Se o acceptor já tiver aceite um valor anteriormente, terá que enviar o valor da proposta e o número correspondente à proposta na mensagem de promessa. Caso o valor n não seja o mais elevado recebido até à data, a mensagem de prepare é ignorada. Fase 2a: Aceitação Pedido Após o proposer receber um quórum de mensagens de promessa, necessita definir um valor de proposta. Se, até à data, qualquer acceptor tiver aceite uma proposta, o proposer terá recebido os valor aceites anteriormente pelos acceptors, tendo que definir o valor da sua proposta como o maior valor aceite pelos acceptors. Se nenhum dos acceptors tiver aceite um valor anteriormente, o proposer pode definir qualquer valor de proposta. Após definir o valor de proposta, o proposer envia uma mensagem to tipo accept request para um quórum de acceptor, que contém o valor da sua proposta. Fase 2b: Aceitação Se um acceptor receber uma mensagem to tipo accept request para uma proposta n, o acceptor aceita a proposta somente se não tiver prometido considerar apenas propostas de número maior que n. Neste caso, o acceptor regista o valor v da proposta e envia uma mensagem to tipo accept ao proposer e a todos os learners. Caso contrário ignora a mensagem accept request. Este algoritmo original de Paxos serve como base para diversas variantes, como por exemplo a versão Byzantine Paxos [18] que assume um modelo de falhas bizantinas. 3.3 Turquois Turquois [25] é um protocolo de consenso binário e probabilístico desenhado para redes ad-hoc sem fios com modelo de falhas bizantinas. Este protocolo permite que k, de n 27

46 CAPÍTULO 3. ALGORITMOS DE CONSENSO Proposer Acceptor Acceptor Acceptor prepare(n) promise(n, v1) accept request(n, v2) accept(n) Figura 3.1: Execução correta do algoritmo Paxos processos, sendo k n, decidam um valor v, sendo v {0, 1} ou, caso não cheguem a um consenso. O estado inicial de um processo é composto por três variáveis internas: 1. Fase φ i Valor proposto v i {0, 1}. 3. Estado da decisão status i {decided, undecided}. No início do protocolo, as variáveis internas encontram-se com os seguintes valores: φ i = 1, status i = undecided e v i = proposal i. O algoritmo encontra-se dividido em duas tarefas que são executadas em paralelo por cada processo, sendo elas: Receção. Esta tarefa recebe as mensagens, do formato i, φ i, v i, status i de todos os restantes processos. É esta tarefa que está encarregue de validar e processar a mensagem consoante a fase em que o ciclo se encontra. Emissão. Esta tarefa envia as mensagens broadcast com o formato i, φ i, v i, status i aos restantes processos. Estas mensagens são enviadas periodicamente, sendo a tarefa ativa por um relógio interno. Como referido, a tarefa de receção dos pacotes é responsável por processar a mensagem consoante a fase em que o ciclo se encontra. Isto deve-se ao facto deste protocolo de consenso funcionar em ciclos, em que cada ciclo está dividido em três fases: CONVERGE. Fase em que os processos tentam convergir para o valor mais observado entre todos os processos, (φ i mod 3 = 1). 28

47 3.4. CONSENSO MULTI-VALOR LOCK. Fase em que os processos tentam bloquear um valor v i {0, 1} ou, se não conseguirem decidir, (φ i mod 3 = 2). DECIDE. Fase em que os processos tentam decidem o valor que foi bloqueado na fase anterior, (φ i mod 3 = 0). Caso os processos não consigam decidir um valor, começa um novo ciclo em que cada processo propõe valores aleatórios. Devido ao modelo de falhas bizantinas, este protocolo necessita validar as mensagens que são recebidas. Esta validação de mensagens é feita através da validação de autenticidade e de semântica das mensagens. Para a validação de autenticidade, é necessária a troca de chaves entre os intervenientes do algoritmo, para que, na receção de uma mensagem, esta possa ser devidamente autenticada de modo a validar a origem da mensagem. A validação da semântica das mensagens é levada a cabo para garantir que os dados recebidos estão congruentes com o estado do algoritmo. 3.4 Consenso Multi-Valor O trabalho de motivação desta dissertação [1], baseou-se num protocolo de consenso multi valor, com modelo de falhas bizantino e assíncrono, denominado Multi-Valued Consensus [34]. Este algoritmo, por sua vez, necessita de recorrer a um algoritmo de consenso binário, tendo sido, neste âmbito, escolhido o algoritmo Turquois [25]. O protocolo executa em três fases distintas: proposta de um valor, deteção do valor mais votado e decisão do valor. O protocolo começa com todos os processos a proporem um valor v através de mensagens com o formato INIT, i, v i, sendo i o identificador do processo e v i o seu valor proposto. Cada processo guarda as mensagens INIT recebidas num vetor V, na posição i e espera até receber (n f ) mensagens, sendo n o total de processos e f o número de falhas admissíveis. Quando um processo recebe (n 2 f ) mensagens com o mesmo valor v, envia uma mensagem do formato VECT, i, v a todos os restantes processos. Caso o processo não consiga decidir um valor v, envia um valor. A dada altura todos os processos terão difundido mensagens do tipo VECT, i, v, assim, um processo espera até receber (n f ) mensagens VECT. Quando são recebidas (n 2 f ) mensagens VECT com o mesmo valor v proposto, o processo inicia o consenso binário propondo o valor 1, para que todos os processos se possam decidir pelo valor v. O valor v só é aceite quando o protocolo de consenso binário decidir 1, caso contrário o valor decidido, pelo consenso multi-valor, é. 29

48 CAPÍTULO 3. ALGORITMOS DE CONSENSO 3.5 Análise do sistema O trabalho de Almeida [1] atravessou algumas dificuldades no estudo da solução implementada. No processo de avaliação da solução, foram feitos diversos testes, nomeadamente à latência da rede. Estes testes tiveram em consideração diferentes números de nós da rede (4, 7, 10 e 13), protocolos de comunicação (TCP, TCP persistente, UDP e UDP multicast), presença de falhas e algumas parametrizações adicionais. Os testes de latência foram feitos com temporizadores em cada nó que no fim da execução do protocolo retornam o tempo total calculado. No contexto das parametrizações adicionais, foram considerados vários intervalos e tempos de espera. Um dos parâmetros considerados, por exemplo, foi o intervalo de tempo entre o envio de mensagens. Este intervalo pode ser malicioso se assumir um valor demasiado baixo, podendo congestionar a rede e levar à perda de pacotes e ao aumento da latência da rede. O aumento da latência da rede poderá levar ao aumento de falhas, dificultando o consenso entre os processos. Por outro lado, caso o valor assumido seja muito alto, este pode atrasar a execução do protocolo. Os ajustes a estes parâmetros foram feitos por experimentação, não havendo um controlo e conhecimento total do comportamento do protocolo de modo a se conseguir calcular parâmetros favoráveis. Este pormenor leva a uma das questões levantadas na avaliação deste trabalho, será que os intervalos e tempos de espera utilizados podem ser relaxados e mesmo assim obter bons tempos de latência? Esta será uma questão que só poderá ser respondida através da monitorização detalhada e controlada da rede durante a execução do protocolo, ao contrário do método por tentativa e erro. A avaliação feita com diferentes números de nós começou com uma rede mais pequena, de 4 nós, até chegar a uma rede de 13 nós. No caso de uma rede de 13 nós o protocolo de consenso mostrou ser bastante instável. A execução do mesmo tornava-se demorada, causando até a falha de todo o sistema. Foi colocada em questão a combinação de hardware e rede usados. No entanto, não é percetível se o problema se prende com o facto do protocolo não ser escalável ou se está presente no tipo de dispositivos utilizados. Uma possível causa deste problema é o intervalo de tempo já referido anteriormente. O mesmo intervalo de tempo terá um impacto diferente à medida que se aumenta o tamanho da rede. Isto porque, proporcionalmente ao tamanho da rede, o número de mensagens trocadas aumenta. Assim, um tempo favorável para uma rede de 4 nós poderá ser demasiado baixo para uma rede de 13 nós, estando a congestionar o tráfego da rede. No entanto, a dúvida mantém-se sem resposta. Não havendo metodologias e ferramentas destinadas a perceber o que está a acontecer na rede para causar esta instabilidade. As metodologias de avaliação usadas mostram que existe uma lacuna, não só, nas ferramentas de depuração e gestão de aplicações distribuídas, mas como na falta de métodos controlados de análise da rede. Pelos problemas indicados, nota-se a necessidade de haver um sistema que favoreça a monitorização do tráfego gerado por um sistema distribuído, sem perturbar o mesmo, de modo a compreender melhor o seu comportamento, e perceber 30

49 3.5. ANÁLISE DO SISTEMA se o protocolo a ser desenvolvido tem impacto positivo ou negativo no desempenho da rede. 31

50

51 C A P Í T U L O 4 SISTEMA DE ANÁLISE Este capítulo abordará o sistema implementado no contexto desta dissertação. Na secção 4.1 serão apresentados os requisitos necessários para a implementação do sistema. Nas secções 4.2, 4.3 e 4.4 serão explicados os diferentes componentes que cumprem os requisitos do sistema. 4.1 Requisitos Para prosseguir com a implementação de um sistema de monitorização, de um algoritmo distribuído a executar numa rede WiFi, é necessário fazer o levantamento dos requisitos deste mesmo sistema. Após a análise dos objetivos pretendidos e as particularidades da norma , foram definidos os seguintes requisitos: Captura sem interferências. Com o objetivo de obter resultados reais e fidedignos é necessário que a captura de tráfego não interfira na rede e/ou nos dispositivos intervenientes. Classificação de tráfego. De modo a ser possível analisar o tráfego de um algoritmo específico é essencial fazer a classificação do tráfego, distinguindo a origem do tráfego e o seu impacto na rede. Este sistema precisa assim de ser capaz de identificar os diferentes tipos de tráfego: Pacotes de Gestão, secção Pacotes de Controlo, secção Pacotes de Dados, secção Pacotes desconhecidos 33

52 CAPÍTULO 4. SISTEMA DE ANÁLISE Considerando os pacotes de dados, é ainda possível separar em duas sub-categorias: tráfego da aplicação e tráfego extra. Os pacotes desconhecidos constituem pacotes mal formados que não permitem identificar a sua origem. Modo monitor. Para que o requisito anterior seja possível, é necessário que a captura de tráfego seja efetuada em modo monitor. Só neste modo é que será possível obter todo o tráfego da rede, incluindo pacotes do protocolo Análise da evolução. Para uma melhor compreensão do algoritmo, é necessário ter uma visualização da sua evolução ao longo do tempo. Deste modo, poderá ser possível identificar períodos de maior congestionamento ou falhas do sistema. Agregação de informação. Considerando que o meio WiFi não é estável, é de esperar que a execução de um algoritmo distribuído neste meio não seja estável e previsível. Como tal, é necessário processar a informação de várias capturas de modo a agregar a informação e obter dados estatísticos. De modo a cumprir estes requisitos, o sistema terá que contar com três componentes distintos. O sistema será assim dividido por captura, análise e visualização. Estes componentes serão explicados de seguida. 4.2 Captura Este componente é responsável por cumprir dois dos requisitos enumerados: captura sem interferências e captura com modo monitor. Como existem programas de captura de tráfego simples e eficientes, não existe a necessidade de implementar de raiz este componente. Tendo como objetivo agregar diversas capturas, pretende-se utilizar um programa de captura já existente. A título de experimentação, a primeira opção foi o uso da ferramenta Wireshark [39]. Primeiramente, o processo de captura passou por executar a ferramenta Wireshark em simultâneo com o tráfego em estudo. No entanto, após alguma análise dos resultados obtidos, concluiu-se que desta forma se perturba e altera os resultados obtidos. Considerando que esta ferramenta necessita processar cada pacote que captura, este processamento introduz um atraso no atendimento dos pacotes que chegam ao Packet Filter. Caso a ferramenta não consiga processar pacotes ao mesmo ritmo com que estes passam na rede, os resultados apresentados na captura não serão representativos do que realmente se passa na rede. Esta situação observou-se em execuções mais rápidas do algoritmo, em que, no ficheiro resultante da captura, não eram apresentados pacotes gerados pelo algoritmo. Assim sendo, como substituto da ferramenta Wireshark, passou-se a utilizar TCPDump [36], com a particularidade de colocar o processo a executar em segundo plano e sem geração de output em tempo real. Deste modo minimiza-se o processamento de pacotes, limitando a ferramenta a capturar e guardar a informação dos mesmos. 34

53 4.3. ANÁLISE DE TRÁFEGO Uma das particularidades do modo monitor é que o dispositivo dissocia-se do ponto de acesso no momento da captura. Assim, este modo não permite comunicações com a rede, caso o dispositivo não tenha adaptadores de rede adicionais. Mesmo que o dispositivo de captura seja capaz de monitorizar e produzir tráfego em simultâneo, é importante considerar que tal poderá prejudicar as condições tanto da captura, como da execução do algoritmo. Isto porque o overhead introduzido pelo processamento de pacotes para o algoritmo pode prejudicar o processamento de pacotes da captura, e vice-versa. Estes factos levam à escolha de manter um nó monitor externo à execução do algoritmo. Considerando o exemplo da figura 4.1, com um algoritmo a correr entre os nós A, B e C, a captura do tráfego é efetuada num quarto nó D. Ponto de Acesso Estação A Estação B Estação C Estação Monitora D Figura 4.1: Arquitetura da rede Em suma, este componente limita-se à utilização da ferramenta TCPDump e da produção de um ficheiro pcap. A captura de tráfego executa-se, em modo monitor, através de um computador externo, que não intervém no algoritmo a estudar. 4.3 Análise de Tráfego Este componente é responsável por processar os resultados da captura de tráfego e produzir os dados que são consumidos pelo componente de visualização. Este componente é assim responsável por cumprir o requisito de classificação de tráfego e parte dos requisitos análise da evolução e agregação de informação. A implementação deste componente recorre à utilização da biblioteca Pcap [36], mais concretamente a versão LibPcap [36], com uso da linguagem de programação C. Na prática este componente divide-se em dois programas que, consumindo a mesma captura, originam tipos de dados diferentes Classificação de Tráfego Este programa é o que permite fazer a distinção dos tipos de pacotes que ocorrem na rede sem fios. A nível da classificação dos tipos de pacotes (gestão, controlo e dados), esta informação encontra-se disponível no cabeçalho De modo a poder caracterizar 35

54 CAPÍTULO 4. SISTEMA DE ANÁLISE o tráfego da aplicação é necessário introduzir quais os endereços IP intervenientes no algoritmo. E, caso sejam conhecidas, é possível limitar mais os resultados, indicando as portas utilizadas pelo algoritmo. Assim, se o utilizador definir que pretende analisar o tráfego entre as máquinas , e , é considerado pacote da aplicação qualquer pacote que tenha como origem e destino dois destes endereços IP. Considerando que estas três máquinas poderão comunicar entre si, fora da execução do algoritmo, o tráfego útil da aplicação pode ser filtrado através das portas utilizadas. Utilizando o exemplo da figura 4.2, limitar a classificação de tráfego aos endereços IP levaria a que os pacotes do protocolo ICMP fossem classificados como tráfego útil. Existe assim a possibilidade de introduzir um conjunto de portas para restringir o filtro de pacotes. Os restantes pacotes de dados são classificados como tráfego extra pacote udp, porta pacote icmp pacote udp, porta pacote icmp pacote udp, porta Figura 4.2: Exemplo de tráfego de rede De modo a cumprir o requisito de análise da evolução, é guardado o estado da rede de tempos a tempos. Numa captura de dez segundos, por exemplo, se o utilizador pedir uma análise de 200 em 200 milissegundos, é guardado o número de pacotes e o total de bytes das mensagens para cada intervalo de tempo. Após o processamento, é produzido um ficheiro no formato csv que contém a evolução dos tipos de tráfego ao longo do tempo Informação sumária Este programa é em parte responsável pelo requisito de agregação de informação. O processamento dos pacotes é semelhante ao do programa anterior. Neste caso a classificação de tráfego é simplificada, limitando a distinguir tráfego da aplicação e tráfego extra. No entanto, ao contrário da implementação anterior, este programa acumula os dados, apresentando no final um sumário das condições da rede. Os resultados são, mais uma vez, disponibilizados em formato csv. Neste caso, são produzidos dois ficheiros, separando a informação do tráfego da aplicação e do tráfego extra. A informação apresentada em ambos é a seguinte: Tempo de execução 36

55 4.4. VISUALIZAÇÃO Número de pacotes Número de bytes Número de pacotes/segundo Número de bytes/segundo 4.4 Visualização Este componente é responsável por parte dos requisitos de análise da evolução do algoritmo e agregação de informação. Como já referido, este componente consome os resultados produzidos pelo componente anterior. Para o utilizador gerir as capturas que pretende analisar e visualizar, é necessário que o sistema disponibilize uma interface gráfica. De seguida são apresentadas as duas versões da interface gráfica que foram implementadas Versão Java Inicialmente, foi escolhida a linguagem de programação Java [13] para a implementação desta interface gráfica. Esta implementação foi feita com recurso ao pacote Java Swing [14] e à biblioteca XChart [40]. A base desta implementação passa por receber um ficheiro pcap ou csv e os devidos parâmetros: endereços IP, portas (opcional) e intervalo de tempo (em milissegundos). Caso o ficheiro introduzido tenha sido em formato pcap, os parâmetros são usados para executar o programa de classificação de tráfego. Este programa de classificação produz um ficheiro csv que é processado posteriormente para gerar um gráfico. Caso seja introduzido um ficheiro csv, não é necessário executar o programa de classificação de tráfego, sendo possível passar diretamente à produção do gráfico. O utilizador pode então escolher que informação que pretende visualizar, assim como o tipo de gráfico que prefere usar. A figura 4.3 mostra a primeira versão da interface gráfica, implementada em Java Versão Web Durante a implementação da versão Java, houve algumas dificuldades em acrescentar interatividade aos gráficos. Chegando à conclusão que, para acrescentar funcionalidades aos gráficos, teria que ser despendido muito tempo, optou-se por procurar uma alternativa. Considerando a familiaridade com as tecnologias, e a vasta oferta de bibliotecas de geração de gráficos, optou-se por procurar uma alternativa web em Javascript [15]. Tomou-se assim conhecimento da biblioteca CanvasJS [4] que oferece uma API com as funcionalidades pretendidas. Alterando a interface gráfica para uma implementação web, é necessária a implementação de um servidor, sendo escolhida a linguagem Ruby [29], com uso da framework Ruby on Rails [30]. De modo a agilizar a criação da interface gráfica, foi usada a framework Bootstrap [2]. Em suma, a versão web é constituída por uma parte de servidor, 37

56 CAPÍTULO 4. SISTEMA DE ANÁLISE (a) Ecrã inicial (b) Opções do gráfico (c) Gráfico Figura 4.3: Versão Java implementada em Ruby on Rails, e por uma parte de cliente, implementada em HTML5 [10], CSS [5] e Javascript com recurso à framework Bootstrap e à biblioteca CanvasJS. Esta alteração permitiu assim criar uma alternativa à versão Java, em menos tempo de implementação, acrescentando algumas características interessantes aos gráficos: Zoom Interatividade com o gráfico, obtendo os valores dos pontos Exportação para imagem JPG/PNG Ativação/desativação de conjuntos de dados Considerando a versão anterior, o mesmo ficheiro (pcap ou csv) era processado de todas as vezes que era submetido. Com recurso a uma base de dados, a versão web guarda os resultados da captura, aquando da primeira submissão do ficheiro. Deste modo é mantido um histórico de ficheiros, facilitando o acesso a gráficos anteriormente observados. As figuras 4.4 e 4.5 mostram a interface gráfica que possibilita a visualização de gráficos. Para além da visualização de gráficos, esta versão permite, com o uso do programa de informação sumária, agregar a informação de várias capturas. Neste caso, com a submissão 38

57 4.4. VISUALIZAÇÃO (a) Página inicial (b) Opções do gráfico Figura 4.4: Versão Web Figura 4.5: Gráfico da versão web de várias capturas, e respetivos parâmetros, a aplicação processa a informação sumária resultante de todas as capturas e produz o seguinte resultado: Média do tempo de execução Média do número de pacotes Média do número de pacotes/segundo Média de bytes Média de bytes/segundo 39

58 CAPÍTULO 4. SISTEMA DE ANÁLISE Figura 4.6: Informação agregada Menor tempo de execução N o de pacotes, correspondente à captura de menor tempo de execução N o de pacotes/segundo, correspondente à captura de menor tempo de execução N o de bytes, correspondente à captura de menor tempo de execução N o de bytes/segundo, correspondente à captura de menor execução Esta informação é apresentada tanto para o tráfego de aplicação como para o tráfego extra, podendo destes dados calcular os valores do tráfego total. A figura 4.6 mostra o resultado da agregação de informação das capturas. Através deste conjunto de ferramentas, é possível obter um sistema que fornece vários tipos de informação que podem ser posteriormente utilizados para análise. A figura 4.7 mostra o diagrama de funcionamento deste sistema. O componente de captura é responsável por fazer a monitorização do algoritmo e produzir um ficheiro pcap, que contém os dados da captura. O ficheiro pcap, e respetivos parâmetros, é passado ao componente de análise, através do uso da interface gráfica, de modo a processar os dados. O componente de análise por sua vez produz dois ficheiros csv, com a classificação do tráfego e informação sumária, respetivamente, do ficheiro pcap inserido. Estes ficheiros csv são então utilizados pelo componente de visualização para produção de gráficos e obtenção da informação agregada. Os gráficos e a informação agregada são por fim apresentados ao utilizador através da interface gráfica. Interface Gráfica Captura pcap Análise csv Visualização csv Figura 4.7: Diagrama do sistema Os gráficos produzidos pelo sistema podem ser obtidos por um utilizador que, ao estudar um algoritmo, se depara com uma execução mais demorada. Visualizando os gráficos, o utilizador pode assim perceber se há problemas com a comunicação dos nós, 40

59 4.4. VISUALIZAÇÃO como se poderá ver na secção 5.2. Pode ainda tentar perceber se, no momento daquela execução, houve tráfego extra acima do normal. A título de exemplo, os gráficos 4.8 e 4.9 representam a mesma execução do algoritmo Turquois. O gráfico 4.10 ilustra a evolução, ao longo do tempo, do número de pacotes para pacotes de gestão, controlo e dados, sendo feita a distinção entre os pacotes da aplicação e os pacotes de tráfego adicional. O gráfico 4.9 ilustra a evolução, ao longo do tempo, do número de pacotes para cada nó que executa o algoritmo. Figura 4.8: Gráfico temporal da execução do algoritmo para cada tipo de pacote Figura 4.9: Gráfico temporal da execução do algoritmo para cada nó interveniente É também possível estudar várias capturas, comparando a informação sumária obtida em cada uma. Por exemplo, o cenário da figura 4.10, em que foram feitas várias execuções com 4 e 7 nós. Através das capturas destas execuções, pôde-se obter uma média do tráfego da aplicação e tráfego extra, indicando o tráfego da rede. Esta informação permite a formação de gráficos, com uso de Excel, por exemplo. É possível observar que, com o aumento do número de nós da rede, não só aumenta o tráfego da aplicação como aumenta o tráfego extra. Assim, num caso de estudo, em que seja necessário testar o 41

60 CAPÍTULO 4. SISTEMA DE ANÁLISE (a) Tráfego médio acumulado, com 4 nós (b) Tráfego médio acumulado, com 7 nós Figura 4.10: Gráficos de tráfego acumulado comportamento do algoritmo em diferentes cenários, é interessante poder obter o tráfego da rede, observando o rácio de tráfego de aplicação e tráfego extra. A ferramenta implementada servirá assim como auxílio às análises que serão apresentadas no capítulo 5. 42

61 C A P Í T U L O 5 ANÁLISES EFETUADAS Este capítulo abordará a análise efetuada ao algoritmo em estudo no âmbito desta dissertação. Na secção 5.1 é apresentado o ambiente de testes. De seguida, a secção 5.2 apresenta a análise feita a capturas, através da visualização de gráficos gerados pelo sistema de análise. Na secção 5.3 é apresentada a análise aos tempos entre envio de mensagens, feita com o propósito de encontrar os tempos favoráveis à execução do algoritmo. A secção 5.4 representa a análise ao tráfego da rede, sendo feita a comparação entre os valores obtidos na secção anterior, de modo a perceber quais os níveis de tráfego desejáveis. Por fim, a secção 5.5 apresenta a análise do tráfego extra. Nesta análise, o comportamento do algoritmo é testado com a injeção de tráfego adicional na rede, de modo a perceber as influência que o tráfego extra poderá ter na execução do algoritmo, ou vice-versa. 5.1 Ambiente de testes No contexto da avaliação, utilizou-se uma implementação do algoritmo Turquois [25]. Esta implementação foi utilizada no contexto da avaliação de um algoritmo de consenso, tolerante a falhas bizantinas, em redes ad-hoc. [20] Esta versão recorre à existência de um nó que controla a experiência e como tal coordena os intervenientes do consenso. Este nó começa por enviar uma mensagem (INIT), com a parametrização do algoritmo, dando início à troca de chaves entre os restantes nós. Após a troca de chaves estar concluída, o nó coordenador envia outra mensagem (VALUE) a indicar o valor a decidir, dando sinal aos restantes nós para iniciar o consenso. O nó coordenador mantém-se a par do desenvolvimento do processo de consenso, sendo responsável por detetar quando é que um quórum de processos chega a consenso. No âmbito dos testes, este algoritmo foi executado sem falhas, por paragem ou bizantinas, sendo necessário um quórum de k, em n, processos, sendo k = n n

62 CAPÍTULO 5. ANÁLISES EFETUADAS Os dispositivos usados para correr o algoritmo foram Raspberry Pi [28], modelo B, com sistema Unix, tendo sido usados para redes com 5 a 9 nós. Sendo o principal objetivo perceber o impacto do algoritmo com diferentes tempos entre envio de mensagens, foram feitas várias execuções com cada tempo de espera e com diferentes números de nós. Os tempos entre envio de mensagens usados foram 5, 10, 20, 40 60, 80, 100, 120, 160 e 200 milissegundos. Esta implementação define que de cada vez que um nó muda de fase é enviada uma mensagem broadcast. Assim, para avaliar se este broadcast terá algum impacto, optou-se por testar execuções com e sem este broadcast adicional. Em primeira instância, a rede sem fios consistiu numa rede aberta com um ponto de acesso. De modo a minimizar a possibilidade de colisões, a rede em uso foi mantida num canal inutilizado por redes vizinhas. Além disso há que considerar a inexistência de pacotes do protocolo RTS/CTS [12], pelo facto de todos os nós serem capazes de ouvir os restantes nós da rede. 5.2 Análise de capturas Para a análise dos resultados obtidos é necessário considerar algumas particularidades do algoritmo. No caso da implementação do algoritmo Turquois em questão, é sabido que a troca de chaves e o consenso executam através do envio de mensagens em portas diferentes. Mais concretamente, a troca de chaves é feita através de pacotes recebidos pela porta e a fase de consenso recebe pacotes pela porta Para além destas duas portas, os pacotes de pedido de retransmissão, enviados ao nó coordenador, são recebidos pela porta Tendo este conhecimento, é possível identificar as diferentes fases do algoritmo através da visualização dos gráficos gerados pela ferramenta. As capturas iniciais, feitas a este algoritmo, serviram como meio de avaliação à ferramenta de análise. Através das capturas, e da sua análise através da ferramenta Wireshark [39], foi possível verificar a autenticidade dos resultados produzidos pela ferramenta implementada. Estas capturas permitiram também detetar que a implementação do algoritmo Turquois continha alguns problemas que não garantiam que os nós atingissem o consenso. Considere-se o gráfico 5.1, que ilustra a evolução do número de pacotes de cada nó, ao longo do tempo. Neste caso, existem quatro nós com endereços , , e , a executar o algoritmo, sendo o nó coordenador, e o tráfego das portas e Pode-se observar na figura 5.2 que os nós não entram na fase de consenso pelo facto que não existir tráfego na porta É também possível observar que, a determinada altura, somente os nós , e continuam a enviar pacotes. Sendo estes pacotes enviados para a porta 12347, concluiu-se que estes nós ainda se encontram na fase de troca de chaves. Este cenário repete-se em várias execuções do algoritmo, dando indicação de que existem problemas na implementação do algoritmo. 44

63 5.2. ANÁLISE DE CAPTURAS Figura 5.1: Falha na receção do pacote INIT no nó Figura 5.2: Falha na receção do pacote INIT no nó , com inclusão da porta Figura 5.3: Falha na receção do pacote VALUE nos nós e

64 CAPÍTULO 5. ANÁLISES EFETUADAS Após identificar as fases problemáticas, foi possível identificar as partes da implementação que deviam ser corrigidas. Devido à não fiabilidade do protocolo UDP e do envio de mensagens por difusão, caso a mensagem INIT se perdesse e o nó B não o recebesse, este nó não seria capaz de iniciar o algoritmo, figura 5.4. O mesmo caso acontecia no início do consenso, caso a mensagem VALUE não chegasse a todos os nós, estes não seriam capazes de participar no consenso. As capturas permitiram observar que, por vezes, numa rede de quatro nós, por exemplo, enquanto três comunicavam entre si, um dos nós não participava na troca de chaves. Não sendo possível efetuar a troca de chaves entre os quatro nós, o processo de decisão nem sequer era iniciado. O mesmo acontecia no envio da mensagem VALUE, em caso de falha do envio da mensagem para dois nós, era possível observar que somente dois nós tentavam chegar a consenso, sem sucesso. Este tipo de falha pode ser observado na figura 5.3, em que a fase de consenso é identificada pelo acréscimo de tráfego dos nós e A B C Figura 5.4: Caso de erro Para a resolução deste problema, foi necessário implementar um mecanismo de retransmissão destes dois pacotes. No caso da mensagem INIT, o nó B ao detetar que os restantes nós iniciaram a troca de chaves, pede ao nó coordenador para retransmitir a mensagem, figura 5.5. Na situação da mensagem VALUE, é necessário um valor de timeout. Completando a troca de chaves, os nós têm um tempo limitado para esperar pela mensagem VALUE. Ultrapassando esse valor, o nó pede ao nó coordenador para reenviar a mensagem. Utilizando como exemplo uma execução com quatro nós , , e e o nó coordenador Ao observar o gráfico da figura 5.6, pode-se ter a perceção do tráfego gerado por cada nó, em número de pacotes. Nota-se, por exemplo, que o nó coordenador ( ) gera muito menos tráfego que os restantes, sendo um elemento passivo que não está envolvido na troca de mensagens por difusão. Se, ao gráfico anterior, se juntar a informação referente ao tráfego recebido na porta 12345, correspondente ao processo de decisão, pode-se identificar o momento em que o consenso começa, como se pode observar na figura 5.7. De modo a facilitar a análise do tráfego do consenso, é ainda possível ampliar o gráfico na zona pretendida e desativar os 46

65 5.2. ANÁLISE DE CAPTURAS A B C pedido retransmissão Figura 5.5: Caso de retransmissão de pacote Figura 5.6: Gráfico Figura 5.7: Gráfico com inclusão da porta dados da porta 12345, como é possível ver na figura

66 CAPÍTULO 5. ANÁLISES EFETUADAS Figura 5.8: Gráfico com zoom Figura 5.9: Gráfico com perda de pacotes O exemplo do gráfico da figura 5.8 mostra também o caso de uma execução que correu sem percalços. Pode-se observar que assim que a fase de consenso começa, os quatro nós enviam mensagens a um ritmo semelhante. O gráfico da figura 5.9, por outro lado, mostra que os nós não iniciaram o consenso na mesma altura. Neste gráfico pode observar-se com clareza que os nós e começam imediatamente o consenso, enquanto que os nós e estão inicialmente sem atividade. Este gráfico permite ainda identificar o momento em que a mensagem VALUE foi retransmitida. É possível ver, após o período de inatividade dos dois nós, que o nó coordenador estabelece comunicação e que, de seguida, ambos os nós começam a sua participação no consenso. Através da visualização de gráficos é ainda possível relacionar a evolução dos diferentes tipos de pacotes. Na figura 5.10 pode-se observar a evolução do número de pacotes de gestão, controlo, da aplicação e extra. Neste exemplo e possível ver que o tráfego dos 48

67 5.3. ANÁLISE DE TEMPOS DE EXECUÇÃO Figura 5.10: Gráfico pacotes de dados é acompanhado pelo tráfego dos pacotes de controlo, sendo este constituído, maioritariamente, por pacotes de reconhecimento. O tráfego de gestão mantém-se mínimo por ser constituído, na sua maioria, por pacotes beacon enviados pelo ponto de acesso. O tráfego de dados extra constitui pacotes mal formados e pacotes de função nula. 5.3 Análise de tempos de execução Considerando a instabilidade e imprevisibilidade do meio das redes sem fios, de modo a avaliar os diversos tempos entre envio de mensagens, foi necessário obter uma amostragem de capturas das execuções do algoritmo. Mais concretamente, foi extraída uma amostragem de 15 execuções do algoritmo. Devido à grande variação dos tempos de execução dos 15 valores observados, foi retirado o valor de maior duração de forma a descartar valores demasiado dispares. Para fins de análise, foram observados os tempos de execução da fase de consenso, extraindo o tempo de troca de chaves. Os gráficos, das figuras 5.11 e 5.12, mostram uma evolução imprevisível dos tempos de execução médios da fase de consenso. Mais uma vez, considerando o meio de comunicação instável, os tempos de execução do algoritmo variam bastante, mesmo em execuções do mesmo caso de estudo. No entanto, se se observar os melhores tempos de execução de cada caso de estudo, os valores encontrados são mais expectáveis. Pode-se observar nos gráficos das figuras 5.13 e 5.14 a evolução do algoritmo à medida que o intervalo de tempo entre mensagens aumenta. Os valores apresentados nos gráficos correspondem à execução de menor duração, para cada caso de estudo. Pela observação destes gráficos pode-se concluir três aspetos interessantes: 1. Como seria de esperar, tempos de espera baixos levam a tempos de execução elevados. Este facto leva a que se pretenda aumentar este valor. No entanto, após 49

68 CAPÍTULO 5. ANÁLISES EFETUADAS Figura 5.11: Evolução dos tempos médios de execução, sem broadcast adicional Figura 5.12: Evolução dos tempos médios de execução, com broadcast adicional atingir uma fase favorável, o aumento do tempo entre mensagens enviadas, torna a execução do algoritmo mais lenta. 2. O aspeto anterior torna-se mais visível na figura 5.13, mostrando que a existência de um broadcast adicional acaba por beneficiar o algoritmo, nos casos com maiores tempos entre envio de mensagens. Este broadcast acelera a execução do algoritmo quando o intervalo de tempo é mais elevado. Há que notar, porém, que baixos tempos entre envio de mensagens, tornam as execuções mais demoradas, aquando do uso deste broadcast. 3. Para cada número de nós existe um conjunto de intervalos de tempo favoráveis. No gráfico figura 5.13, por exemplo, pode-se reparar que o melhor tempo de execução para 4 nós encontra-se com um tempo entre envio de mensagens a 20 ms. Ao observar os valores dos tempos de execução para 8 nós, pode-se reparar que o melhor caso encontra-se com um tempo entre envio de mensagens a 80 ms. Estes dados são expectáveis, considerando que com o aumento do tamanho da rede, é de esperar que o número de mensagens aumente e seja necessário aumentar o tempo entre envio de 50

Redes de Computadores sem Fio

Redes de Computadores sem Fio Redes de Computadores sem Fio Prof. Marcelo Gonçalves Rubinstein Programa de Pós-Graduação em Engenharia Eletrônica Faculdade de Engenharia Universidade do Estado do Rio de Janeiro Programa Introdução

Leia mais

Redes de Computadores

Redes de Computadores Redes de Computadores Prof. Macêdo Firmino Comunicação Wireless Macêdo Firmino (IFRN) Redes de Computadores Maio de 2012 1 / 30 Redes sem Fio Nas redes sem fio (wireless), não exite uma conexão cabeada

Leia mais

Redes Wireless. Padrão IEEE 802.11. Redes Sem Fio (Wireless) 1

Redes Wireless. Padrão IEEE 802.11. Redes Sem Fio (Wireless) 1 Padrão IEEE 802.11 Redes Wireless Redes Sem Fio (Wireless) 1 Topologias e pilha de protocolos 802.11 Parte da pilha de protocolos 802.11. Padrão IEEE 802.11 Redes Wireless Redes Sem Fio (Wireless) 3 Quadros

Leia mais

REDE DE COMPUTADORES

REDE DE COMPUTADORES SERVIÇO NACIONAL DE APRENDIZAGEM COMERCIAL REDE DE COMPUTADORES Tecnologias de Rede Arquitetura Padrão 802.11 Prof. Airton Ribeiro de Sousa E-mail: airton.ribeiros@gmail.com 1 Arquitetura Wireless Wi-Fi

Leia mais

Mobilidade em Redes 802.11

Mobilidade em Redes 802.11 Mobilidade em Redes 802.11 Prof. Rafael Guimarães Redes sem Fio Aula 14 Aula 14 Rafael Guimarães 1 / 37 Sumário Sumário 1 Motivação e Objetivos 2 O protocolo MAC 802.11 3 Quadro 802.11 4 802.11: Mobilidade

Leia mais

Redes de Computadores

Redes de Computadores Padrão IEEE 802.11 Inst tituto de Info ormátic ca - UF FRGS Redes de Computadores IEEE 802.11 Aula 12 Modelo para arquiteturas wireless (1997) Especifica a camada de nível físico (PHY) e seu controle de

Leia mais

RCO2. Redes Locais (LANs): Características e requisitos

RCO2. Redes Locais (LANs): Características e requisitos RCO2 Redes Locais (LANs): Características e requisitos 1 Aplicações de LANs LANs para computadores pessoais Baixo custo Taxas de transmissão limitadas Redes de conexão Interconexão de sistemas maiores

Leia mais

Redes de Computadores I

Redes de Computadores I Redes de Computadores I REDES SEM FIO CARACTERÍSTICAS DE ENLACE LAN S SEM FIO 802.11 Slide 1 Elementos de uma Rede Sem Fio Hospedeiros sem fio Equipamentos de sistemas finais que executam aplicações Enlaces

Leia mais

UNIVERSIDADE ESTÁCIO DE SÁ

UNIVERSIDADE ESTÁCIO DE SÁ UNIVERSIDADE ESTÁCIO DE SÁ CURSO DE REDES DE COMPUTADORES PROFESSOR MARCELO BERRÊDO NOTAS DE AULA PADRÃO IEEE 802.11 REVISÃO ABRIL/2004 IEEE 802.11 WIRELESS LAN 1. INTRODUÇÃO O Grupo de trabalho IEEE 802.11

Leia mais

prof.edney@superig.com.br Redes de Computadores

prof.edney@superig.com.br Redes de Computadores prof.edney@superig.com.br Redes de Computadores Apresentação do professor, da disciplina, dos métodos de avaliação, das datas de trabalhos e provas; introdução a redes de computadores; protocolo TCP /

Leia mais

INF-111 Redes Sem Fio Aula 04 Tecnologias para WLAN Prof. João Henrique Kleinschmidt

INF-111 Redes Sem Fio Aula 04 Tecnologias para WLAN Prof. João Henrique Kleinschmidt INF-111 Redes Sem Fio Aula 04 Tecnologias para WLAN Prof. João Henrique Kleinschmidt Santo André, outubro de 2014 Roteiro Introdução Camada física Subcamada MAC Estrutura do quadro Segurança Introdução

Leia mais

Redes de Computadores. Trabalho de Laboratório Nº7

Redes de Computadores. Trabalho de Laboratório Nº7 Redes de Computadores Curso de Eng. Informática Curso de Eng. de Electrónica e Computadores Trabalho de Laboratório Nº7 Análise do tráfego na rede Protocolos TCP e UDP Objectivo Usar o Ethereal para visualizar

Leia mais

A topologia em estrela é caracterizada por um determinado número de nós, conectados em uma controladora especializada em comunicações.

A topologia em estrela é caracterizada por um determinado número de nós, conectados em uma controladora especializada em comunicações. Topologia em estrela A topologia em estrela é caracterizada por um determinado número de nós, conectados em uma controladora especializada em comunicações. Como esta estação tem a responsabilidade de controlar

Leia mais

Wireless LANs. IEEE 802.11 e 802.11e. FEUP/DEEC Redes de Banda Larga MIEEC 2009/10 José Ruela

Wireless LANs. IEEE 802.11 e 802.11e. FEUP/DEEC Redes de Banda Larga MIEEC 2009/10 José Ruela Wireless LANs IEEE 802.11 e 802.11e FEUP/DEEC Redes de Banda Larga MIEEC 2009/10 José Ruela IEEE 802.11 IEEE 802.11 Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications é uma

Leia mais

REDES DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com

REDES DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com - Aula Complementar - MODELO DE REFERÊNCIA OSI Este modelo se baseia em uma proposta desenvolvida pela ISO (International Standards Organization) como um primeiro passo em direção a padronização dos protocolos

Leia mais

Agenda. Propostas e Avaliações de Protocolos de Acesso Alternativos ao Padrão IEEE 802.11e. Exemplos de Padrões de Redes Sem Fio

Agenda. Propostas e Avaliações de Protocolos de Acesso Alternativos ao Padrão IEEE 802.11e. Exemplos de Padrões de Redes Sem Fio Propostas e Avaliações de Protocolos de Acesso Alternativos ao Padrão IEEE 8.e Aluno... : Fernando Carlos Azeredo Verissimo Orientador... : Luís Felipe Magalhães de Moraes Agenda. Redes Sem Fio. Métodos

Leia mais

Tecnologia e Infraestrutura. Conceitos de Redes

Tecnologia e Infraestrutura. Conceitos de Redes Tecnologia e Infraestrutura Conceitos de Redes Agenda Introdução às Tecnologias de Redes: a) Conceitos de redes (LAN, MAN e WAN); b) Dispositivos (Hub, Switch e Roteador). Conceitos e tipos de Mídias de

Leia mais

Placa de Rede. Rede de Computadores. Tipos de Redes LAN (Local Area Network) Rede local. Placa de Rede

Placa de Rede. Rede de Computadores. Tipos de Redes LAN (Local Area Network) Rede local. Placa de Rede Rede de Computadores Prof. André Cardia Email: andre@andrecardia.pro.br MSN: andre.cardia@gmail.com Placa de Rede Uma placa de rede (NIC), ou adaptador de rede, oferece capacidades de comunicações nos

Leia mais

Subcamada MAC. O Controle de Acesso ao Meio

Subcamada MAC. O Controle de Acesso ao Meio Subcamada MAC O Controle de Acesso ao Meio Métodos de Acesso ao Meio As implementações mais correntes de redes locais utilizam um meio de transmissão que é compartilhado por todos os nós. Quando um nó

Leia mais

Treze razões pelas quais uma rede wireless é lenta

Treze razões pelas quais uma rede wireless é lenta Treze razões pelas quais uma rede wireless é lenta April 29, 2008 No meu último ano de graduação tenho estudado redes sem fio. Confesso que não gostava muito desse assunto mas, passando a conhecê-lo um

Leia mais

Redes de Computadores I Licenciatura em Eng. Informática e de Computadores 1 o Semestre, 27 de Janeiro de 2006 Exame de 2ª Época A

Redes de Computadores I Licenciatura em Eng. Informática e de Computadores 1 o Semestre, 27 de Janeiro de 2006 Exame de 2ª Época A Número: Nome: Redes de Computadores I Licenciatura em Eng. Informática e de Computadores o Semestre, 27 de Janeiro de 2006 Exame de 2ª Época A Duração: 2,5 horas A prova é sem consulta A prova deve ser

Leia mais

TRANSMISSÃO DE DADOS

TRANSMISSÃO DE DADOS TRANSMISSÃO DE DADOS Aula 6: Controle de acesso ao meio Notas de aula do livro: FOROUZAN, B. A., Comunicação de Dados e Redes de Computadores, MCGraw Hill, 4ª edição Prof. Ulisses Cotta Cavalca

Leia mais

Uso de Virtual Lan (VLAN) para a disponibilidade em uma Rede de Campus

Uso de Virtual Lan (VLAN) para a disponibilidade em uma Rede de Campus Uso de Virtual Lan (VLAN) para a disponibilidade em uma Rede de Campus Edson Rodrigues da Silva Júnior. Curso de Redes e Segurança de Sistemas Pontifícia Universidade Católica do Paraná Curitiba, Fevereiro

Leia mais

Características Básicas de Sistemas Distribuídos

Características Básicas de Sistemas Distribuídos Motivação Crescente dependência dos usuários aos sistemas: necessidade de partilhar dados e recursos entre utilizadores; porque os recursos estão naturalmente em máquinas diferentes. Demanda computacional

Leia mais

Rede de Computadores

Rede de Computadores Escola de Ciências e Tecnologia UFRN Rede de Computadores Prof. Aquiles Burlamaqui Nélio Cacho Luiz Eduardo Eduardo Aranha ECT1103 INFORMÁTICA FUNDAMENTAL Manter o telefone celular sempre desligado/silencioso

Leia mais

Subcamada de Controle de Acesso ao Meio. Bruno Silvério Costa

Subcamada de Controle de Acesso ao Meio. Bruno Silvério Costa Subcamada de Controle de Acesso ao Meio Bruno Silvério Costa 1. O Problema de Alocação do Canal Alocação estática de canais em LANs e MANs Alocação dinâmica de canais em LANs e MANs 1.1 Alocação dinâmica

Leia mais

Redes IEEE 802.11. Makoto Miyagawa 1. Manaus Amazonas Brasil

Redes IEEE 802.11. Makoto Miyagawa 1. Manaus Amazonas Brasil Redes IEEE 802.11 Makoto Miyagawa 1 1 Faculdade de Tecnologia Universidade Federal do Amazonas Manaus Amazonas Brasil Resumo. A mobilidade oferecida pelas redes sem fio aos usuários, aliada ao baixo custo

Leia mais

CAPÍTULO 4 PROTOCOLOS INDUSTRIAIS PARTE 2

CAPÍTULO 4 PROTOCOLOS INDUSTRIAIS PARTE 2 25 CAPÍTULO 4 PROTOCOLOS INDUSTRIAIS PARTE 2 O Protocolo PROFIBUS O PROFIBUS (acrônimo de Process Field Bus) é o segundo tipo mais popular de sistema de comunicação em rede Fieldbus, ficando atrás somente

Leia mais

Wireless. Leandro Ramos www.professorramos.com

Wireless. Leandro Ramos www.professorramos.com Wireless Leandro Ramos www.professorramos.com Redes Wireless Interferências Access-Point / ROUTER Wireless Ponto de Acesso Numa rede wireless, o hub é substituído pelo ponto de acesso (access-point em

Leia mais

3.1. Principais características e implementações na Camada Física

3.1. Principais características e implementações na Camada Física 3 Padrão 802.11n Com o intuito de desenvolver um padrão que atendesse a crescente demanda por maior vazão, em julho de 2003 foi formado o grupo de trabalho para desenvolver o padrão 802.11n. O objetivo

Leia mais

REDES DE COMUNICAÇÕES MÓVEIS 2º Trabalho de Laboratório. DESEMPENHO E LIMITAÇÕES DE REDES SEM FIOS IEEE802.11 1- Introdução

REDES DE COMUNICAÇÕES MÓVEIS 2º Trabalho de Laboratório. DESEMPENHO E LIMITAÇÕES DE REDES SEM FIOS IEEE802.11 1- Introdução Mestrado em Engª de Redes de Comunicações REDES DE COMUNICAÇÕES MÓVEIS 2º Trabalho de Laboratório 3º ano, 1º semestre, 2010/11 Segunda-Feira, 16:30h Alunos Nome Número João Salada 57849 Marco Alves 57846

Leia mais

Aula 06 Redes Locais: Acessos Múltiplos e Ethernet. Prof. Dr. S. Motoyama

Aula 06 Redes Locais: Acessos Múltiplos e Ethernet. Prof. Dr. S. Motoyama Aula 06 Redes Locais: Acessos Múltiplos e Ethernet Prof. Dr. S. Motoyama Redes Locais (Local area networks, LANs) Início da década de 80 IBM s token ring vs. DIX (Digital, Intel, e Xerox) Ethernet IEEE

Leia mais

FACULDADE DE TECNOLOGIA SENAC GOIÁS PROJETO INTEGRADOR. Projeto de Redes de Computadores. 5º PERÍODO Gestão da Tecnologia da Informação GOIÂNIA 2014-1

FACULDADE DE TECNOLOGIA SENAC GOIÁS PROJETO INTEGRADOR. Projeto de Redes de Computadores. 5º PERÍODO Gestão da Tecnologia da Informação GOIÂNIA 2014-1 FACULDADE DE TECNOLOGIA SENAC GOIÁS PROJETO INTEGRADOR Projeto de Redes de Computadores 5º PERÍODO Gestão da Tecnologia da Informação Henrique Machado Heitor Gouveia Gabriel Braz GOIÂNIA 2014-1 RADIUS

Leia mais

Introdução à redes de computadores

Introdução à redes de computadores 1/8 Introdução à redes de computadores Faz todo o sentido ligar os computadores em rede. Você não precisa ter uma impressora, um HD de grande capacidade, um gravador de DVDs e conexão via ADSL para cada

Leia mais

Comunicando através da rede

Comunicando através da rede Comunicando através da rede Fundamentos de Rede Capítulo 2 1 Estrutura de Rede Elementos de comunicação Três elementos comuns de comunicação origem da mensagem o canal destino da mensagem Podemos definir

Leia mais

1 Redes de comunicação de dados

1 Redes de comunicação de dados 1 Redes de comunicação de dados Nos anos 70 e 80 ocorreu uma fusão dos campos de ciência da computação e comunicação de dados. Isto produziu vários fatos relevantes: Não há diferenças fundamentais entre

Leia mais

CÓDIGO DA VAGA: TP08 QUESTÕES DE MÚLTIPLAS ESCOLHAS

CÓDIGO DA VAGA: TP08 QUESTÕES DE MÚLTIPLAS ESCOLHAS QUESTÕES DE MÚLTIPLAS ESCOLHAS 1) Em relação à manutenção corretiva pode- se afirmar que : a) Constitui a forma mais barata de manutenção do ponto de vista total do sistema. b) Aumenta a vida útil dos

Leia mais

Placa de Rede. Tipos de Redes LAN (Local Area Network) Rede local. MAN (Metropolitan Area Network) Rede Metropolitana

Placa de Rede. Tipos de Redes LAN (Local Area Network) Rede local. MAN (Metropolitan Area Network) Rede Metropolitana Rede de Computadores Parte 01 Prof. André Cardia Email: andre@andrecardia.pro.br MSN: andre.cardia@gmail.com Placa de Rede Uma placa de rede (NIC), ou adaptador de rede, oferece capacidades de comunicações

Leia mais

Equipamentos de Rede. Prof. Sérgio Furgeri 1

Equipamentos de Rede. Prof. Sérgio Furgeri 1 Equipamentos de Rede Repetidor (Regenerador do sinal transmitido)* Mais usados nas topologias estrela e barramento Permite aumentar a extensão do cabo Atua na camada física da rede (modelo OSI) Não desempenha

Leia mais

Capítulo 8 - Comutação Ethernet. Associação dos Instrutores NetAcademy - agosto de 2007 - Página

Capítulo 8 - Comutação Ethernet. Associação dos Instrutores NetAcademy - agosto de 2007 - Página Capítulo 8 - Comutação Ethernet 1 Bridging da Camada 2 CCNA1_8_1_1_pt[1].swf Ao acrescentarmos mais hosts em um segmento, aumentamos o domínio de colisão e o número de retransmissões. Uma solução é dividir

Leia mais

Voz em ambiente Wireless

Voz em ambiente Wireless Voz em ambiente Wireless Mobilidade, acesso sem fio e convergência são temas do momento no atual mercado das redes de comunicação. É uma tendência irreversível, que vem se tornando realidade e incorporando-se

Leia mais

Redes de Computadores Grupo de Redes de Computadores

Redes de Computadores Grupo de Redes de Computadores Redes de Computadores Grupo de Redes de Computadores Interligações de LANs: Equipamentos Elementos de interligação de redes Aplicação Apresentação Sessão Transporte Rede Ligação Física LLC MAC Gateways

Leia mais

REDES DE COMPUTADORES

REDES DE COMPUTADORES REDES DE COMPUTADORES Rede é um conjunto de módulos processadores capazes de trocar informações e compartilhar recursos. O tipo de rede é definido pela sua área de abrangência, podemos classificar as redes

Leia mais

Redes de Computadores I Licenciatura em Eng. Informática e de Computadores 1 o Semestre, 26 de Outubro de 2005 1 o Teste A

Redes de Computadores I Licenciatura em Eng. Informática e de Computadores 1 o Semestre, 26 de Outubro de 2005 1 o Teste A Redes de Computadores I Licenciatura em Eng. Informática e de Computadores 1 o Semestre, 26 de Outubro de 2005 1 o Teste A Número: Nome: Duração: 1 hora O teste é sem consulta O teste deve ser resolvido

Leia mais

Redes de Computadores

Redes de Computadores Introdução Inst tituto de Info ormátic ca - UF FRGS Redes de Computadores Controle de acesso ao meio (Medium Access Control - MAC) Aula 10 Enlaces podem ser divididos em duas grandes categorias: Enlace

Leia mais

A Camada de Transporte

A Camada de Transporte A Camada de Transporte Romildo Martins Bezerra CEFET/BA s de Computadores II Funções da Camada de Transporte... 2 Controle de conexão... 2 Fragmentação... 2 Endereçamento... 2 Confiabilidade... 2 TCP (Transmission

Leia mais

O Nível de Enlace nas Redes Locais. Ethernet. Ethernet

O Nível de Enlace nas Redes Locais. Ethernet. Ethernet O Nível de Enlace nas Redes Locais Como já foi visto, o nível de enlace deve fornecer uma interface de serviço bem definida para o nível de rede. deve determinar como os bits do nível físico serão agrupados

Leia mais

Acesso Ethernet com Hubs

Acesso Ethernet com Hubs Acesso Ethernet com Hubs O dado é enviado de um por vez Cada nó trafega a 10 Mbps Acesso Ethernet com Bridges Bridges são mais inteligentes que os hubs Bridges reuni os quadros entre dois segmentos de

Leia mais

TRABALHO #1 Sistemas de Informação Distribuídos: Reflexão sobre a segurança

TRABALHO #1 Sistemas de Informação Distribuídos: Reflexão sobre a segurança DEPARTAMENTO DE ENGENHARIA INFORMÁTICA FACULDADE DE CIÊNCIAS E TECNOLOGIA DA UNIVERSIDADE DE COIMBRA Negócio Electrónico, 2006/2007 TRABALHO #1 Sistemas de Informação Distribuídos: Reflexão sobre a segurança

Leia mais

Capítulo 8 - Aplicações em Redes

Capítulo 8 - Aplicações em Redes Capítulo 8 - Aplicações em Redes Prof. Othon Marcelo Nunes Batista Mestre em Informática 1 de 31 Roteiro Sistemas Operacionais em Rede Modelo Cliente-Servidor Modelo P2P (Peer-To-Peer) Aplicações e Protocolos

Leia mais

6127. Redes comunicação de dados. RSProf@iol.pt. 2014/2015. Introdução.

6127. Redes comunicação de dados. RSProf@iol.pt. 2014/2015. Introdução. Sumário 6127. Redes comunicação de dados. 6127. Redes comunicação de dados A Internet: Permite a interação entre pessoas. 6127. Redes comunicação de dados A Internet: Ensino; Trabalho colaborativo; Manutenção

Leia mais

Aula 03 Regras de Segmentação e Switches

Aula 03 Regras de Segmentação e Switches Disciplina: Dispositivos de Rede II Professor: Jéferson Mendonça de Limas 4º Semestre Aula 03 Regras de Segmentação e Switches 2014/1 19/08/14 1 2de 38 Domínio de Colisão Os domínios de colisão são os

Leia mais

Redes de Computadores I

Redes de Computadores I Redes de Computadores I Nível de Enlace (Redes Ethernet & WiFi) por Helcio Wagner da Silva. p.1/35 Introdução A Arquitetura TCP/IP não define muito bem o que deve haver no Nível de Host/rede. Neste contexto,

Leia mais

Protocolos de gerenciamento

Protocolos de gerenciamento Protocolos de gerenciamento Os protocolos de gerenciamento têm a função de garantir a comunicação entre os recursos de redes homogêneas ou não. Com esse requisito satisfeito, operações de gerenciamento

Leia mais

SSC0748 - Redes Móveis

SSC0748 - Redes Móveis - Redes Móveis Introdução Redes sem fio e redes móveis Prof. Jó Ueyama Agosto/2012 1 Capítulo 6 - Resumo 6.1 Introdução Redes Sem fo 6.2 Enlaces sem fo, características 6.3 IEEE 802.11 LANs sem fo ( wi-f

Leia mais

Alan Menk Santos alanmenk@hotmail.com www.sistemasul.com.br/menk. Camada Física: Redes Sem Fio. Equipamentos de Rede. O que já conhecemos.

Alan Menk Santos alanmenk@hotmail.com www.sistemasul.com.br/menk. Camada Física: Redes Sem Fio. Equipamentos de Rede. O que já conhecemos. Alan Menk Santos alanmenk@hotmail.com www.sistemasul.com.br/menk Camada Física: Redes Sem Fio Equipamentos de Rede O que já conhecemos. Cabos; Atenas; Tipos de transmissão; 1 O que vamos conhecer. Equipamentos

Leia mais

Comunicação sem Fio WLAN (802.11) Edgard Jamhour

Comunicação sem Fio WLAN (802.11) Edgard Jamhour Comunicação sem Fio WLAN (802.11) Edgard Jamhour WLAN: Parte II Controle de Acesso ao Meio e Segurança Padrões WLAN: WiFi Define duas formas de organizar redes WLAN: Ad-hoc: Apenas computadores computadores

Leia mais

Rede de Computadores II

Rede de Computadores II Rede de Computadores II Slide 1 SNMPv1 Limitações do SNMPv1 Aspectos que envolvem segurança Ineficiência na recuperação de tabelas Restrito as redes IP Problemas com SMI (Structure Management Information)

Leia mais

Mestrado em Engª de Redes de Comunicações. Redes de Comunicações Móveis Trabalho de Laboratório (2007/2008)

Mestrado em Engª de Redes de Comunicações. Redes de Comunicações Móveis Trabalho de Laboratório (2007/2008) Mestrado em Engª de Redes de Comunicações Redes de Comunicações Móveis Trabalho de Laboratório (2007/2008) 2007-10-18 Configuração, caracterização, desempenho e limitações de redes sem fios IEEE802 Objectivo

Leia mais

Cartão PC para LAN sem fios

Cartão PC para LAN sem fios Cartão PC para LAN sem fios AWL-100 Manual do utilizador Versão 1.1 Junho de 2002 i Aviso I Declaração de copyright Este manual não pode ser reproduzido sob nenhuma forma, por quaisquer meios ou ser utilizado

Leia mais

Teste de Qualidade Web based para Banda Larga FAQs

Teste de Qualidade Web based para Banda Larga FAQs Teste de Qualidade Web based para Banda Larga FAQs Pergunta O que é o teste de velocidade? Quem é o público alvo? O que oferece? Como funciona? Por onde é o acesso? Resposta Um teste de qualidade de banda

Leia mais

Protocolos de Redes Revisão para AV I

Protocolos de Redes Revisão para AV I Protocolos de Redes Revisão para AV I 01 Aula Fundamentos de Protocolos Conceituar protocolo de rede; Objetivos Compreender a necessidade de um protocolo de rede em uma arquitetura de transmissão entre

Leia mais

Processos (Threads,Virtualização e Migração de Código)

Processos (Threads,Virtualização e Migração de Código) Processos (Threads,Virtualização e Migração de Código) Roteiro Processos Threads Virtualização Migração de Código O que é um processo?! Processos são programas em execução. Processo Processo Processo tem

Leia mais

UNIVERSIDADE FEDERAL DO PARANÁ UM SNIFFER PARA REDES SEM FIO CURITIBA

UNIVERSIDADE FEDERAL DO PARANÁ UM SNIFFER PARA REDES SEM FIO CURITIBA UNIVERSIDADE FEDERAL DO PARANÁ UM SNIFFER PARA REDES SEM FIO CURITIBA 2008 CAIO RUAN NICHELE UM SNIFFER PARA REDES SEM FIO Trabalho de Graduação II apresentado como requisito parcial à obtenção do grau

Leia mais

REDES DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

REDES DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - Aula 1- MODELO DE CAMADAS 1. INTRODUÇÃO A compreensão da arquitetura de redes de computadores envolve a compreensão do modelo de camadas. O desenvolvimento de uma arquitetura de redes é uma tarefa complexa,

Leia mais

Notas da Aula 15 - Fundamentos de Sistemas Operacionais

Notas da Aula 15 - Fundamentos de Sistemas Operacionais Notas da Aula 15 - Fundamentos de Sistemas Operacionais 1. Software de Entrada e Saída: Visão Geral Uma das tarefas do Sistema Operacional é simplificar o acesso aos dispositivos de hardware pelos processos

Leia mais

Protocolo Ethernet e Dispositivos de Interconexão de LANs

Protocolo Ethernet e Dispositivos de Interconexão de LANs Protocolo Ethernet e Dispositivos de Interconexão de LANs Prof. Rafael Guimarães Redes de Alta Velocidade Tópico 4 - Aula 1 Tópico 4 - Aula 1 Rafael Guimarães 1 / 31 Sumário Sumário 1 Motivação 2 Objetivos

Leia mais

Arquitetura de Sistemas Operativos

Arquitetura de Sistemas Operativos Arquitetura de Sistemas Operativos Sistemas Operativos 2011/2012 1 Modelos de Interacção entre Processos Produtor e Consumidor Os dados transmitidos entre as aplicações são geralmente opacos para o sistema

Leia mais

Exercícios do livro: Tecnologias Informáticas Porto Editora

Exercícios do livro: Tecnologias Informáticas Porto Editora Exercícios do livro: Tecnologias Informáticas Porto Editora 1. Em que consiste uma rede de computadores? Refira se à vantagem da sua implementação. Uma rede de computadores é constituída por dois ou mais

Leia mais

SIMULADO ENADE 2011 5º Semestre 2ª parte Curso Tecnológico em Redes de Computadores

SIMULADO ENADE 2011 5º Semestre 2ª parte Curso Tecnológico em Redes de Computadores SIMULADO ENADE 2011 5º Semestre 2ª parte Curso Tecnológico em Redes de Computadores ALUNO(A): DATA DE APLICAÇÃO: PONTUAÇÃO OBTIDA: Prezados (as) alunos (as), Vocês estão recebendo o caderno do Simulado

Leia mais

Redes de computadores e Internet

Redes de computadores e Internet Polo de Viseu Redes de computadores e Internet Aspectos genéricos sobre redes de computadores Redes de computadores O que são redes de computadores? Uma rede de computadores é um sistema de comunicação

Leia mais

Sistemas Multimédia. Instituto Superior Miguel Torga. Francisco Maia famaia@gmail.com. Redes e Comunicações

Sistemas Multimédia. Instituto Superior Miguel Torga. Francisco Maia famaia@gmail.com. Redes e Comunicações Sistemas Multimédia Instituto Superior Miguel Torga Redes e Comunicações Francisco Maia famaia@gmail.com Estrutura das Aulas 5 Aulas Aula 10 (20 de Abril) Classificação Componentes Aula 11 (27 de Abril)

Leia mais

PROJETO DE REDES www.projetoderedes.com.br

PROJETO DE REDES www.projetoderedes.com.br PROJETO DE REDES www.projetoderedes.com.br Curso de Tecnologia em Redes de Computadores Disciplina: Redes I Fundamentos - 1º Período Professor: José Maurício S. Pinheiro Material de Apoio VI PROTOCOLOS

Leia mais

REDES DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

REDES DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - Aula Complementar - EQUIPAMENTOS DE REDE 1. Repetidor (Regenerador do sinal transmitido) É mais usado nas topologias estrela e barramento. Permite aumentar a extensão do cabo e atua na camada física

Leia mais

Comunicação sem fios (somente em alguns modelos) Manual do utilizador

Comunicação sem fios (somente em alguns modelos) Manual do utilizador Comunicação sem fios (somente em alguns modelos) Manual do utilizador Copyright 2007 Hewlett-Packard Development Company, L.P. Windows é uma marca registada da Microsoft Corporation nos E.U.A. Bluetooth

Leia mais

Redes. Pablo Rodriguez de Almeida Gross

Redes. Pablo Rodriguez de Almeida Gross Redes Pablo Rodriguez de Almeida Gross Conceitos A seguir serão vistos conceitos básicos relacionados a redes de computadores. O que é uma rede? Uma rede é um conjunto de computadores interligados permitindo

Leia mais

Claudivan C. Lopes claudivan@ifpb.edu.br

Claudivan C. Lopes claudivan@ifpb.edu.br Claudivan C. Lopes claudivan@ifpb.edu.br Motivação Camadas do modelo OSI Exemplos de protocolos IFPB/Patos - Prof. Claudivan 2 Para que dois ou mais computadores possam se comunicar, é necessário que eles

Leia mais

Um sistema é constituído de um conjunto de processos que executam seus respectivos códigos do sistema operacional e processos e códigos de usuários.

Um sistema é constituído de um conjunto de processos que executam seus respectivos códigos do sistema operacional e processos e códigos de usuários. Os sistemas computacionais atuais permitem que diversos programas sejam carregados na memória e executados simultaneamente. Essa evolução tornou necessário um controle maior na divisão de tarefas entre

Leia mais

Visão geral das redes sem fio

Visão geral das redes sem fio Visão geral das redes sem fio 1 - Introdução O termo redes de dados sem fio pode ser utilizado para referenciar desde dispositivos de curto alcance como o Bluetooth à sistemas de altas taxas de transmissão

Leia mais

Arquitetura de Computadores. Introdução aos Sistemas Operacionais

Arquitetura de Computadores. Introdução aos Sistemas Operacionais Arquitetura de Computadores Introdução aos Sistemas Operacionais O que é um Sistema Operacional? Programa que atua como um intermediário entre um usuário do computador ou um programa e o hardware. Os 4

Leia mais

Módulo 8 Ethernet Switching

Módulo 8 Ethernet Switching CCNA 1 Conceitos Básicos de Redes Módulo 8 Ethernet Switching Comutação Ethernet 2 Segmentação de Redes Numa Ethernet o meio de transmissão é compartilhado Só um nó pode transmitir de cada vez. O aumento

Leia mais

Unidade 1. Bibliografia da disciplina 15/11/2008. Curso Superior de Tecnologia: Banco de Dados Redes de Computadores

Unidade 1. Bibliografia da disciplina 15/11/2008. Curso Superior de Tecnologia: Banco de Dados Redes de Computadores Faculdade INED Curso Superior de Tecnologia: Banco de Dados Redes de Computadores Disciplina: Redes de Computadores Prof.: Fernando Hadad Zaidan 1 Unidade 1 Conceitos básicos de Redes de Computadores 2

Leia mais

6 PLANEJAMENTO DE SI 6.1 Planejamento de Segurança da Informação O planejamento em S.I é algo crucial para que haja o bom funcionamento de uma

6 PLANEJAMENTO DE SI 6.1 Planejamento de Segurança da Informação O planejamento em S.I é algo crucial para que haja o bom funcionamento de uma 6 PLANEJAMENTO DE SI 6.1 Planejamento de Segurança da Informação O planejamento em S.I é algo crucial para que haja o bom funcionamento de uma empresa. Diferente do senso comum o planejamento não se limita

Leia mais

Sem fios (somente em alguns modelos)

Sem fios (somente em alguns modelos) Sem fios (somente em alguns modelos) Manual do utilizador Copyright 2006 Hewlett-Packard Development Company, L.P. Microsoft e Windows são marcas registadas da Microsoft Corporation nos EUA. Bluetooth

Leia mais

Comunicação Comunicação é o ato de transmissão de informações de uma pessoa à outra. Emissor: Receptor: Meio de transmissão Sinal:

Comunicação Comunicação é o ato de transmissão de informações de uma pessoa à outra. Emissor: Receptor: Meio de transmissão Sinal: Redes - Comunicação Comunicação é o ato de transmissão de informações de uma pessoa à outra. Comunicação sempre foi, desde o início dos tempos, uma necessidade humana buscando aproximar comunidades distantes.

Leia mais

Uma análise dos mecanismos de segurança de redes locais sem fio e uma proposta de melhoria

Uma análise dos mecanismos de segurança de redes locais sem fio e uma proposta de melhoria Uma análise dos mecanismos de segurança de redes locais sem fio e uma proposta de melhoria Gilson Marques Silva, João Nunes Souza Faculdade de Computação Universidade Federal de Uberlândia (UFU) 38.400-902

Leia mais

Redes de Computadores

Redes de Computadores Redes de Computadores Introdução Redes de Computadores é um conjunto de equipamentos que são capazes de trocar informações e compartilhar recursos entre si, utilizando protocolos para se comunicarem e

Leia mais

UNIVERSIDADE. Sistemas Distribuídos

UNIVERSIDADE. Sistemas Distribuídos UNIVERSIDADE Sistemas Distribuídos Ciência da Computação Prof. Jesus José de Oliveira Neto Comunicação Inter-Processos Sockets e Portas Introdução Sistemas distribuídos consistem da comunicação entre processos

Leia mais

EN3611 Segurança de Redes Prof. João Henrique Kleinschmidt Prática Wireshark Sniffer de rede

EN3611 Segurança de Redes Prof. João Henrique Kleinschmidt Prática Wireshark Sniffer de rede EN3611 Segurança de Redes Prof. João Henrique Kleinschmidt Prática Wireshark Sniffer de rede Entregar um relatório contendo introdução, desenvolvimento e conclusão. A seção desenvolvimento pode conter

Leia mais

Site Survey (Indoor)

Site Survey (Indoor) Comunicações Móveis Faculdade de Engenharia da Universidade do Porto Licenciatura em Engenharia Electrotécnica e de Computadores Site Survey (Indoor) 6 de Junho de 2003 Ricardo Oliveira rmpoliveira@portugalmail.pt

Leia mais

REDE EM BARRENTO UTILIZANDO O MÉTODO DE ACESSO CSMA-CD ETHERNET

REDE EM BARRENTO UTILIZANDO O MÉTODO DE ACESSO CSMA-CD ETHERNET REDE EM BARRENTO UTILIZANDO O MÉTODO DE ACESSO CSMA-CD ETHERNET HISTÓRICO 1973, XEROX INICIALIZOU O DESENVOLVIMENTO DE UM REDE LOCAL DE TOPOLOGIA DE BARRAMENTO NO XEROX PALO ALTO RESEARCH CENTER (PARC);

Leia mais

REDES DE COMPUTADORES

REDES DE COMPUTADORES REDES DE COMPUTADORES Rede é um conjunto de módulos processadores capazes de trocar informações e compartilhar recursos. O tipo de rede é definido pela sua área de abrangência, podemos classificar as redes

Leia mais

Redes Locais de Computadores

Redes Locais de Computadores Redes Locais de Computadores Pós Graduação em Redes de Computadores e Telecomunicações Controle de Acesso Múltiplo Prof. Josafá de Jesus Silva A tecnologia Ethernet AlohaNet inicio da década de 1960 -

Leia mais

UTP ( PAR TRANÇADO SEM PROTEÇÃO)

UTP ( PAR TRANÇADO SEM PROTEÇÃO) Par Trançado UTP ( PAR TRANÇADO SEM PROTEÇÃO) O cabo UTP é composto por pares de fios, sendo que cada par é isolado um do outro e todos são trançados juntos dentro de uma cobertura externa, que não possui

Leia mais

REDES ETHERNET. Curso Profissional Técnico de Gestão e Programação de Sistemas Informáticos. Redes de Comunicação 10º Ano

REDES ETHERNET. Curso Profissional Técnico de Gestão e Programação de Sistemas Informáticos. Redes de Comunicação 10º Ano REDES ETHERNET Curso Profissional Técnico de Gestão e Programação de Sistemas Informáticos Redes de Comunicação 10º Ano Nome: Marcelo Filipe Rocha Assunção 2013/2014 ÍNDICE Introdução... 2 Arquitetura

Leia mais

Unidade 1. Bibliografia da disciplina. Introdução. O que compartilhar? Exemplo 12/10/2009. Conceitos básicos de Redes de Computadores

Unidade 1. Bibliografia da disciplina. Introdução. O que compartilhar? Exemplo 12/10/2009. Conceitos básicos de Redes de Computadores Faculdade INED Unidade 1 Conceitos básicos de Redes de Computadores Curso Superior de Tecnologia: Banco de Dados, Sistemas para Internet e Redes de Computadores Disciplina: Fundamentos de Redes Prof.:

Leia mais

Wireshark Lab: Iniciando

Wireshark Lab: Iniciando Wireshark Lab: Iniciando Versão 1.1 2005 KUROSE, J.F & ROSS, K. W. Todos os direitos reservados 2008 BATISTA, O. M. N. Tradução e adaptação para Wireshark. Conte-me e esqueço. Mostre-me e eu lembro. Envolva-me

Leia mais

Product Architecture. Product Architecture. Aranda 360 ENDPOINT SECURITY. Conteúdos STANDARD & ENTERPRISE EDITION

Product Architecture. Product Architecture. Aranda 360 ENDPOINT SECURITY. Conteúdos STANDARD & ENTERPRISE EDITION Conteúdos Product Architecture Product Architecture Introdução Ambiente RedesdeTrabalho Configurações Políticas Servidores Componentes Agente Servidor Base de Dados Console Comunicação Console Servidor

Leia mais

604 wifi. Visite www.archos.com/manuals para transferir a versão mais recente deste manual.

604 wifi. Visite www.archos.com/manuals para transferir a versão mais recente deste manual. 604 wifi FUNÇÕES WIFI e Internet Suplemento ao Manual do Utilizador ARCHOS 504/604 Versão 1.2 Visite www.archos.com/manuals para transferir a versão mais recente deste manual. Este manual contém informações

Leia mais

Detecção de Portadora em Redes de Acesso múltiplo (CSMA)

Detecção de Portadora em Redes de Acesso múltiplo (CSMA) Detecção de Portadora em Redes de Acesso múltiplo (CSMA) Carrier Sense on Mullti-Access Network CSMA CSMA/CA CSMA/CD CSMA/CD Carrier SenseMulti-Access / CollisionData Computadores ligados Ethernet usam

Leia mais