Apresentou-se nesse cap´ıtulo um panorama do que compreende a realizac¸˜ao de monitorac¸˜ao passiva de tr´afego com recuperac¸˜ao de estado.
As duas formas de se realizar monitorac¸˜ao de tr´afego, a monitorac¸˜ao ativa e a passiva, foram apresentadas, bem como o funcionamento, vantagens, desvantagens e limitac¸˜oes de cada uma delas.
Algumas atividades que possuem semelhanc¸as com a monitorac¸˜ao passiva de tr´afego foram analisadas. Al´em disso, comentou-se sobre suas similaridades, seus problemas e suas particularidades. Em especial, comentou-se sobre os problemas que tais atividades tˆem com o aumento da velocidade da rede e como elas os contornam.
Mecanismos de captura de pacotes s˜ao comuns a todas essas atividades, incluindo `a monitorac¸˜ao passiva de tr´afego. Por esse motivo, abordamos as soluc¸˜oes encontradas na literatura para implementar tais mecanismos e para torn´a-los eficientes, mesmo quanto tais mecanismos s˜ao utilizados em enlaces de alta velocidade.
Finalmente, abordamos o problema de realizar a recuperac¸˜ao de estado de tr´afego mo- nitorado, focando nas particularidades encontradas quando tal remontagem deve ocorrer em tempo real.
Cap´ıtulo 3
A Arquitetura do Sistema de
Monitorac¸˜ao
Tendo em vista a motivac¸˜ao apresentada na introduc¸˜ao e os trabalhos apresentados no cap´ıtulo anterior, como poderia se conceber um sistema capaz de realizar monitorac¸˜ao pas- siva de tr´afego com recuperac¸˜ao de estado em tempo real? Como ele se adequaria `as veloci- dades das redes atuais? Qual o custo e o desempenho de que tal sistema teria?
Nesse cap´ıtulo pretendemos responder essas quest˜oes, revisitando os objetivos e os re- quisitos desse trabalho. Comentaremos tamb´em sobre os compromissos e limitac¸˜oes encon- tradas durante a implementac¸˜ao do Palant´ır, o nosso sistema de monitoramento passivo com recuperac¸˜ao de estado em tempo real. Detalharemos como esses aspectos influenciaram o seu desenvolvimento e, finalmente, faremos uma an´alise do seu desempenho.
3.1
Considerac¸˜oes iniciais
Para que se possa compreender alguns dos aspectos envolvidos na forma com a qual propo- mos e implementamos o sistema de monitorac¸˜ao desenvolvido ´e importante que se saliente o que desejamos obter com tal sistema e alguns dos compromissos aos quais est´avamos su- jeitos durante a sua concepc¸˜ao.
Conforme explicitado no cap´ıtulo 1, objetivamos implementar uma soluc¸˜ao que viabilize a an´alise e a caracterizac¸˜ao de tr´afego de aplicac¸˜oes em tempo real, tendo como foco prin- cipal as aplicac¸˜oes P2P de troca de arquivos mais populares. Tal soluc¸˜ao deve ser o menos intrusiva poss´ıvel e, por esse motivo, optamos pelo uso de mecanismos de monitorac¸˜ao pas- siva. Al´em disso, para que se possa obter an´alises e caracterizac¸˜oes mais ricas atrav´es da soluc¸˜ao, desejamos recuperar o tr´afego tal como ele ´e entregue `as aplicac¸˜oes, o que implica
na necessidade de realizarmos recuperac¸˜ao de estado no tr´afego monitorado. Em suma, de- sejamos criar um sistema de monitorac¸˜ao passiva de tr´afego com recuperac¸˜ao de estado em tempo real.
Para ser capaz de analisar o tr´afego de rede a n´ıvel das aplicac¸˜oes envolvidas e recupe- rar as informac¸˜oes trocadas ´e necess´ario que o sistema (e em particular os mecanismos de captura adotados) tenha(m) um desempenho elevado. Taxas comuns em canais de sa´ıda de provedores de servic¸o banda larga, por exemplo, est˜ao hoje na faixa de centenas de megabits por segundo ou mais. Por isso, o sistema deve ser capaz de capturar e tratar os pacotes a essa taxa, com todo o processamento necess´ario para recompor o comportamento dos usu´arios das aplicac¸˜oes de interesse.
Como mencionado no cap´ıtulo anterior, com as taxas atuais, a arquitetura dos com- putadores de uso geral tradicionais (usualmente identificados pela sigla COTS, commo-
dity, off-the-shelf hardware) est´a perto do seu limite de capacidade [Cleary et al., 2000,
Iannaccone et al., 2001]. Algumas soluc¸˜oes utilizando hardware especializado existem para
o problema de captura de pacotes em enlaces de alta velocidade [Iannaccone et al., 2001,
Endance Measurement Systems, 2005, Sen et al., 2004], mas com um custo elevado e limi- tadas `a captura. Alternativas baseadas em hardware s˜ao claramente mais caras e, como comentado no cap´ıtulo 2, existem soluc¸˜oes propostas que visam tornar o trabalho de captura vi´avel e eficiente em sistemas comuns, mesmo em altas velocidades. Essas soluc¸˜oes v˜ao de encontro com os anseios inicias do projeto, pois desejava-se que a abordagem adotada fosse implement´avel em sistemas operacionais de c´odigo aberto e que tivesse um baixo custo.
´
E importante salientar que o fato de existirem soluc¸˜oes que possibilitam a captura de pacotes em enlaces de alta-velocidade com hardware comum n˜ao basta para que se possa construir sistemas que realizem recuperac¸˜ao de estado em tempo real nesse mesmo hard-
ware. H´a de se considerar que existe um custo n˜ao desprez´ıvel para processar o tr´afego
capturado para a fim de realizar a recuperac¸˜ao de estado. Al´em disso, tendo em mente que a tarefa de monitorac¸˜ao de tr´afego ´e uma atividade onde n˜ao existe controle direto sobre a velocidade dos dados processados, se esse custo for muito alto, o sistema pode n˜ao ser capaz de realizar a sua func¸˜ao de maneira satisfat´oria.
Por esse motivo, nesse cap´ıtulo, apresentaremos e analisaremos o desempenho de diver- sas otimizac¸˜oes que podem ser aplicadas a um sistema operacional de uso geral bem como o desempenho de outras ferramentas que, quando reunidas, possibilitem a criac¸˜ao de um sistema como o discutido e com um desempenho satisfat´orio.