Fabricio Julio Corrêa de Almeida. Ferramenta e análise da qualidade de conexão à Internet

Transcrição

1 Fabricio Julio Corrêa de Almeida Ferramenta e análise da qualidade de conexão à Internet Vitória - ES, Brasil 17 de fevereiro de 2012

2 Fabricio Julio Corrêa de Almeida Ferramenta e análise da qualidade de conexão à Internet Monografia apresentada para obtenção do Grau de Engenheiro de Computação pela Universidade Federal do Espírito Santo. Orientador: Prof. Dr. Magnos Martinello Co-orientador: Rafael Emerick Z. de Oliveira DEPARTAMENTO DE INFORMÁTICA CENTRO TECNOLÓGICO UNIVERSIDADE FEDERAL DO ESPÍRITO SANTO Vitória - ES, Brasil 17 de fevereiro de 2012

3 Monografia de Projeto Final de Graduação sob o título Ferramenta e análise da qualidade de conexão à Internet, defendida por Fabricio Julio Corrêa de Almeida e aprovada em 17 de fevereiro de 2012, em Vitória, Estado do Espírito Santo, pela banca examinadora constituída por: Prof. Dr. Magnos Martinello Universidade Federal do Espírito Santo Orientador Eng. Rafael Emerick Zape de Oliveira Universidade Federal do Espírito Santo Prof. Dr. Moisés Renato Nunes Ribeiro Universidade Federal do Espírito Santo

4 Dedicatória Ao Marcos, Clara e Eduarda

5 Agradecimentos Enfim chegou o momento tão esperado, momento de olhar para trás e ver todos os obstáculos superados nos últimos anos... E também de olhar adiante em busca de novos obstáculos a serem superados. Não vou negar que perdi as contas de quantos momentos difíceis foram superados, mas assim também foram inúmeros os momentos felizes que passei ao lado das pessoas que sempre estiveram do meu lado. E são essas pessoas que eu venho agradecer. Agradeço primeiramente a Deus por toda a força e coragem dos últimos anos, agradeço também imensamente à minha mãe Alice, por toda dedicação carinho e compreensão não só durante o curso, mas sim durante toda minha vida. Aos meus sobrinhos, ao Marcos Júnior pelas emocionantes partidas de PS2 e XBOX. A Maria Clara pelo seu jeitinho meigo e por todas as cartinhas feitas por ela sempre que fui à Linhares e a Maria Eduarda pelo carinho ao seu tio tão ausente. Aos três que mesmo um pouco longe sempre me motivaram e me presentearam com o amor tão verdadeiro que só uma criança é capaz de oferecer. Ao meu cunhado Marcos e minha irmã Ediézia e aos meus irmãos Edielson e Fernando, que por diversas vezes me ajudaram sem nunca pedir nada em troca. Não poderia deixar de fora dos agradecimentos os meus tão queridos amigos, a Jociele pelas brincadeiras sempre alegres, à Janiele e à Karol pelos momentos de descontração no MSN, ao Thiago e ao Rodolfo pela amizade de longa dada e de sábios conselhos, ao Maikon pela grande ajuda na elaboração do layout, aos amigos de turma Pedro, Moacyr, Glauber, Augusto (Guxtin), Flávio, José Nilton (Zé), Vitor (Spá), Renan pelas as várias "brejas"compartilhadas. Meus agradecimentos também à Vivian pelo empenho na divulgação do link da ferramente de testes, o que contribuiu bastante para este trabalho. Agradeço ao professor Magnos pela oportunidade e pela confiança em mim depositada para a realização deste trabalho, assim como agradeço ao PoP-ES, e ao Rafael. E em especial agradeço à minha namorada Cris, que mais do que ninguém esteve sempre perto de mim nesses últimos anos, e que soube me dar a atenção e o carinho necessário para

6 sempre seguir em frente, que soube me animar nos momentos tristes, me acalmar nos momentos de ira, que sempre esteve disposta a me ouvir contar sobre algum trabalho da faculdade mesmo que não entendendo muito. Obrigado Nega! Enfim, agradeço a todos os que me ajudaram ou torceram para que meus sonhos fossem realizados... Obrigado!

7 Resumo Este trabalho tem o propósito de apresentar uma aplicação que forneça aos usuários da Internet uma ferramenta para medição da qualidade de sua conexão, disponibilizando informações básicas como velocidade de download e upload como fazem boa parte dos serviços disponíveis atualmente, e ainda dados mais avançados como latência, perda de pacotes e congestionamento. Além de fornecer métricas sobre a qualidade da conexão, faz parte da solução que será apresentada neste trabalho, armazenar os dados coletados durante os testes para posterior análise. No momento do teste de conexão, o usuário pode informar sua localização geográfica inserindo a cidade e o estado de onde está sendo realizada a medição, desta forma os dados coletados serão indexados com base na localidade do usuário.

8 Sumário Lista de Figuras Lista de Tabelas Lista de Siglas e Abreviaturas 1 Introdução p Contexto p Problema p Objetivo p Metodologia p Estrutura da monografia p Fundamentação teórica e trabalhos relacionados p Medições em redes de computadores p Médotos de medição p Medição passiva p Medição ativa p Métricas de desempenho p Atraso p Variação do atraso p Perda de pacotes p Largura de banda p Trabalhos relacionados p. 23

9 3 Ferramenta NDT p Uma visão geral sobre o NDT p O Projeto Web p Protocolo NDT p Modelo lógico do protocolo p Protocolo de controle p Protocolo de testes p Teste Middlebox p Teste simples de firewall p Teste de vazão Cliente-Servidor p Teste de vazão Servidor-Cliente p Meta teste p Extensão da ferramenta de medição p Visão geral p Arquitetura p Camada de apresentação p Camada de aplicação p Camada de persistência e armazenamento p Dados da localização geográfica p Consulta à base de dados whois p Servidor whois RNP p Análise dos dados coletados p Comparação entre os serviços prestados pelas operadoras p A Importância dos pontos e troca de tráfego p Conclusões e trabalhos futuros p. 55

10 5.1 Trabalhos Futuros p. 55 Referências Bibliográficas p. 57 Anexo A -- Configuração da ferramenta de medição p. 60

11 Lista de Figuras 2.1 Atraso nodal total (KUROSE; ROSS, 2010) p Variação do atraso - Jitter p Estrutura de implementação Web100 (MUDAMBI, 2006a) p Protocolo do teste de vazão cliente-servidor (NDT Project, 2012) p Protocolo do teste de vazão servidor-cliente (NDT Project, 2012) p Estrutura da mensagem do protocolo de controle NDT (NDT Project, 2012). p Estrutura da mensagem de envio de resultados (NDT Project, 2012)..... p Diagrama do protocolo de controle NDT (NDT Project, 2012) p Diagrama do protocolo C2S (NDT Project, 2012) p Formato das mensagens de envio de resultados (NDT Project, 2012)..... p Diagrama do protocolo S2C (NDT Project, 2012) p Estrutura das mensagens do meta teste (NDT Project, 2012) p Arquitetura em camadas da solução proposta p Interface do applet NDT p Interação entra a interface e o cliente NDT p Interface desenvolvida para a ferramenta de medição p Representação da camada de aplicação p Modelo Entidade-Relacionamento do modelo proposto p Quatidade de testes realidados por operadora no Espírito Santo p Vazão das operadoras com maior número de testes p Latência e jitter das operadoras com maior número de testes p Comparativo entre as métricas da operadora NET a partir de diferentes estados p. 53

12 4.11 Latência e jitter obtidos a partir de medições da PRODEST p. 54

13 Lista de Tabelas 2.1 Requisitos de serviço de transporte de algumas aplicações p Tipos de mensagens utilizadas pelo protocolo NDT (NDT Project, 2012)... p Quatidade de testes realidados por operadora no Espírito Santo p Comparativo de vazão cliente-servidor entre as operadoras p Comparativo de vazão servidor-cliente entre as operadoras p Comparativo de detecção de perda e congestionamento entre as operadoras. p Participantes do PTT Vitória p. 52

14 Lista de Siglas e Abreviaturas ADSL Asymmetric Digital Subscriber Line ANATEL Agência Nacional de Telecomunicações CEPTRO Centro de Estudos e Pesquisas em Tecnologia de Redes e Operações CETIC Centro de Estudos sobre as Tecnologias da Informação e da Comunicação CGI.br Comitê Gestor da Internet no Brasil CGPID Comitê Gestor do Programa de Inclusão Digital GUI IP Graphical User Interface Internet Protocol IPPM IP Performance Metrics KIS MSS NDT Kernel Instrument Set Maximum Segment Size Network Diagnostic Tool NDTP Network Diagnostic Tool Protocol PoP-ES Ponto de Presença da RNP no Espírito Santo PTT RNP RTT Ponto de Troca de Tráfego Rede Nacional de Ensino e Pesquisa Round Trip Time SIMET Sistema de Medição de Tráfego de Última Milha TTL VoIP Time To Live Voice over IP W3C World Wide Web Consortium

15 14 1 Introdução 1.1 Contexto Os dados oriundos dos indicadores do CETIC (CETIC, 2010), mostram que no ano de % das residências brasileiras possuíam acesso à Internet, 53% da população brasileira já havia acessado a rede mundial de computadores ao menos uma vez dos quais 60% à acessam diariamente. Estes números deixam claro que o acesso à Internet ainda não abrange a maioria absoluta da população brasileira, mas que a parcela da população que a utiliza já é considerável. Parcela esta que tende a aumentar ainda mais rapidamente com iniciativas como a da implementação do Plano Nacional de Banda Larga (PNBL) que tem como objetivo promover a inclusão digital com maior facilidade de acesso da população à Internet banda larga. O governo federal tem adotado a visão de que a inclusão digital representa garantir que os cidadãos e instituições disponham de meios e capacitação para acessar, utilizar, produzir e distribuir informações e conhecimento, por meio das Tecnologias da Informação e Comunicação (TIC), de forma que possam participar de maneira efetiva e crítica da sociedade da informação (CGPID, 2012). Como afirmam Costa e Bianchini (COSTA; BIANCHINI, 2008), as empresas de telecomunicações tem sido uma das grandes responsáveis pelo crescimento explosivo da Internet, e um fato fundamental para isto é o constante investimento nas estruturas de transporte (backbone) que viabilizam o tráfego intenso e crescente. Embora as infraestruturas no núcleo da rede tenham um crescimento enorme, tanto em largura de banda quanto em acessibilidade, ainda é comum para aplicações ou usuários serem incapazes de tirar proveito desta nova infraestrutura melhorada, sendo a velocidade máxima atingida muitas vezes menor do que a velocidade contratada junto aos provedores. Durante os últimos anos, grande parte dos esforços dos profissionais de telecomunicação foi destinada para o amadurecimento do núcleo da rede, esforços estes que continuam sendo empregados fortemente e resultaram num enorme aumento da capacidade de transmissão com enlaces chegando facilmente a gigabits por segundo. Juntamente com o aumento de velocidade veio a preocupação com a disponibilidade e eficiência dos meios de transmissão, levando

16 1.2 Problema 15 profissionais da área a voltar suas atenções para a parte de desempenho. A motivação deste trabalho vem da necessidade de dedicar um pouco de atenção para o desempenho da rede do ponto de vista do usuário final, ou seja, monitorar a última milha dos enlaces e extrair medidas para avaliar quantitativamente a qualidade de conexão à Internet. 1.2 Problema Um dos maiores problemas encontrados pelos usuários da Internet brasileira, juntamente com a falta de disponibilidade e a confiabilidade, é a discrepância entre a velocidade contratada e a velocidade que efetivamente é entregue pela operadora. Problema que é agravado pelo fato de não ser de competência do Comitê Gestor da Internet no Brasil (CGI.br) o monitoramento ou intervenção em empresas provedoras de acesso ou serviços Internet. Cabendo ao usuário a escolha do melhor provedor e, em caso de algum conflito, procurar órgãos de defesa do consumidor, como o Procon ou o Idec, e até mesmo recorrer à justiça comum (CGI.BR, 2012) Por muito tempo, os provedores de acesso eram obrigados a fornecer em média 10% da velocidade contratada. Porém, o governo federal vem trabalhando com uma série de medidas para contribuir com a evolução das redes de telecomunicações do país, a exemplo o PNBL. No último dia 28 de Outubro de 2011, a Agência Nacional de Telecomunicações (ANATEL) publicou uma resolução (ANATEL, 2011) prevendo que a velocidade mínima de conexão entregue pelas empresas com mais de 50 mil assinantes deverá ser inicialmente de 60%, em uma média mensal. Esses percentuais deverão aumentar a cada ano, até chegar a uma média mensal de 80% da velocidade contratada em Objetivo O objetivo deste trabalho é estender uma ferramenta de medição ativa largamente implantada na Internet para incluir dados sobre localização geográfica dos usuários e armazenar o resultado das medições. Estes dados armazenados poderão ser analisados com a finalidade de aferir informações sobre a qualidade de serviço das conexões de um ponto de vista do usuário final.

17 1.4 Metodologia Metodologia A metodologia do trabalho é baseada em três etapas: extensão da ferramenta NDT, disponibilização da ferramenta para campanha de medição e análise dos dados obtidos. O Network Diagnostic Tool (NDT) assim como será visto mais adiante, é uma ferramenta cliente/servidor que provê teste de desempenho em redes de computadores. A extensão consiste em permitir ao usuário contribuir com a campanha de medição ao inserir sua localização geográfica no momento do teste. A localização do usuário tem como objetivo a obtenção de informações georreferenciadas do IP do qual o teste foi solicitado. Para a disponibilização da ferramenta desenvolvida, será feita uma instalação da mesma em um servidor fornecido pelo Ponto de Presença da RNP no Espírito Santo (PoP-ES), seguida da divulgação, para que os interessados possam voluntariamente testar suas conexões e contribuir para a base de dados a ser analisada na próxima etapa. Ao final deste trabalho os dados obtidos serão analisados com a finalidade de inferir informações pertinentes sobre a qualidade das conexões dos usuários que utilizaram a ferramenta. 1.5 Estrutura da monografia Além deste capítulo introdutório, o presente trabalho é composto por um capítulo referente à introdução teórica acerca de medições em redes de computadores, bem como a apresentação de trabalhos relacionados (Capítulo 2), um capítulo sobre a ferramenta NDT (Capítulo 3), um capítulo que tratará da aplicação desenvolvida e seus resultados (Capítulos 4) e um capítulo de conclusão (Capítulo 5).

18 17 2 Fundamentação teórica e trabalhos relacionados O objetivo deste capítulo é apresentar alguns aspectos teóricos importantes para a compreensão deste trabalho, aspectos estes que abrangem técnicas e métricas utilizadas para análise de desempenho em redes de computadores. 2.1 Medições em redes de computadores Medição é o processo de encontrar experimentalmente o valor de uma quantidade física com a ajuda de meios técnicos especiais denominados instrumentos de medida (RABINOVICH, 1994). Os processos de medição são tipicamente realizados de forma experimental e tem como objetivo representar uma propriedade através de um valor quantitativo expresso em uma unidade de medida. Na Internet existem diversas variáveis relacionadas com o desempenho e a confiabilidade da rede das quais os valores interessam aos usuários da rede. Quando essa variável é cuidadosamente especificada ela recebe o nome de métrica (PAXSON et al., 1998). Uma métrica é uma quantidade mensurável, bem definida qualitativamente e expressa quantitativamente. Mais especificamente na computação, o termo métrica se refere ao critério usado para avaliar o comportamento de um determinado sistema computacional. Usuários, administradores e designers de sistemas computacionais estão todos interessados em sua análise de desempenho com o objetivo de fornecer ou obter melhor desempenho e menor custo (JAIN, 1991). Medições de desempenho representam uma ferramenta essencial em atividades referentes ao gerenciamento e manutenção de redes de computadores, tais como, diagnóstico de problemas de desempenho, planejamento de capacidade, caracterização de tráfego, implantação e verificação de qualidade de serviço. Uma análise cuidadosa de resultados de medições pode ser útil ao se planejar novas redes ou novos sistemas que se utilizem destas, ou ainda prever a utilização e necessidades de atualização de sistemas existentes, além de auxiliar na administração do uso e

19 2.2 Médotos de medição 18 distribuição de largura de banda entre os vários serviços. 2.2 Médotos de medição Existem algumas maneiras de se realizar a medição de desempenho de uma rede de computadores. Os dois métodos mais comuns são a medição passiva (ou não intrusiva) e a medição ativa (ou intrusiva): Medição passiva O método de medição não intrusivo, ou método passivo, como é mais conhecido, analisa o desempenho da rede através de mecanismos passivos, que recebem este nome por não introduzirem ou modificarem tráfego na rede durante o processo de medição. Neste caso a coleta de dados é feita através da observação do tráfego corrente que passa pelo ponto de observação. Medir o desempenho utilizando medição passiva não aumenta o tráfego da rede no momento da medição, já que esta técnica utiliza o tráfego real. Por outro lado, é preciso acessar o meio para coletar os dados e os alarmes geram tráfego, que em alguns casos podem ser substancial. Além disso, a quantidade de dados coletados pode ser vigorosa, especialmente se a análise de fluxo ou a coleta de informações desejar a observação de todos os pacotes de dados passantes na rede (SOUZA, R. S., 2005) Medição ativa O método de medição intrusivo, ou medição ativa, diferentemente da passiva consiste em de forma controlada, injetar pacotes de teste na rede ou enviar pacotes de teste a servidores ou aplicações, e a partir da coleta e análise desses pacotes medir o desempenho da rede avaliando o comportamento dos pacotes de teste. A troca de pacotes Ping pode ser citado como um exemplo desde método. Através deste comando pacotes sequenciais são enviados em intervalos regulares de tempo e a estação de medição pode medir parâmetros como o tempo de resposta Round Trip Time (RTT) e a expectativa de perdas de pacotes no caminho de ida e volta. Um problema de medições ativas é que os pacotes de teste podem provocar o saturamento de enlaces que possuam pouca largura de banda, além de prejudicar outras aplicações que utilizem da mesma rede. Em contra partida, este método apresenta uma maior facilidade e rapidez a obtenção dos resultados. Considerando uma técnica que na qual sejam necessários um número n de pacotes transmitidos para se obter a largura de banda, utilizando-se este método, basta gerar

20 2.3 Métricas de desempenho 19 os pacotes necessários, enquanto que no caso da medição passiva, seria necessário aguardar que estes pacotes fossem gerados por algum dispositivo na rede. A proposta abordada neste trabalho tem como base uma ferramenta (Capítulo 3) que utiliza a técnica de medições ativas. 2.3 Métricas de desempenho Para a obtenção de um entendimento comum e preciso do desempenho e da confiabilidade da Internet, métricas devem ser propostas, e medidas destas métricas devem ser tomadas. A proposição de métricas deve seguir alguns critérios, por exemplo, as métricas devem ser bem definidas, e as metodologias devem apresentar as propriedades de precisão, repetibilidade e reprodutibilidade (AUGUSTO, 2002). A literatura (PAXSON et al., 1998; MAHDAVI; PAXSON, 1999; ALMES; KALIDINDI; ZEKAUSKAS, 1999a, 1999b; MATHIS; ALLMAN, 2001; KOODLI; RAVIKANTH, 2002) traz a definição de várias métricas padronizadas que podem ser aplicadas para avaliação da qualidade, desempenho e confiabilidade dos serviços de troca de dados na Internet. Na sequencia serão apresentadas algumas dessas métricas Atraso Atraso ou retardo em redes de transmissão de dados corresponde ao tempo de necessário para uma informação ir de um lado ao outro de uma rede. Segundo o IP Performance Metrics (IPPM) podemos subdividir o atraso em dois tipos: Atraso de ida e volta: O atraso de ida e volta, ou RTT é o tempo decorrido desde a inserção do primeiro bit de um pacote enviado a um sistema remoto até o momento de chegada do último bit de um pacote de resposta. Neste caso dois pacotes terão que transitar pela rede, um no sentido transmissor-receptor e outro no sentido receptor-transmissor. Atraso unidirecional: O atraso unidirecional ou One-Way Delay é o tempo decorrido a partir da inserção do primeiro bit de um pacote, até a chegada o último bit deste mesmo pacote ao destino. Na Internet a rota da origem até um destino pode ser diferente da rota do destino para a origem (rotas assimétricas). Neste caso sequencias de roteadores diferentes estão sendo usadas para as rotas.

21 2.3 Métricas de desempenho 20 As medidas de retardo de ida e volta medem realmente o desempenho de dois trajetos distintos. Medir cada trajeto destaca independentemente a diferença de performance entre os dois trajetos. Por exemplo, numa transferência de arquivos o desempenho depende na maior parte da performance no sentido do fluxo de dados do que no sentido inverso (BATTISTI, 2002). Quando um pacote viaja sob uma rede, ele sofre ao longo desse caminho diversos tipos de atraso em cada nó existente no caminho. Os principais são: o atraso de processamento nodal, o atraso de fila, o atraso de transmissão e o atraso de propagação (KUROSE; ROSS, 2010). Segundo Kurose e Ross (KUROSE; ROSS, 2010), podemos definir esses atrasos como: Atraso de processamento Tempo necessário de tomada de decisão para encaminhar um pacote a partir da análise do seu cabeçalho. Este atraso ainda pode conter o tempo gasto com códigos de verificação de erros nos bits transmitidos. Atraso de fila Tempo gasto enquanto um pacote aguarda para ser transmitido no enlace. Quando existem mais de um pacote para ser transmitido, os pacotes são colocados em uma fila. Quando não há mais que um pacote aguardando (fila vazia) podemos considerar este atraso como sendo zero, por outro lado quando o enlace está sobrecarregado o tempo de espera pode ser elevado. Atraso de transmissão Tempo gasto para se transmitir todos os bits de um pacote através do enlace. Como não é possível para o transmissor injetar no enlace todos os bits de um pacote de forma instantânea, é necessário um tempo para que isto seja feito. O atraso de transmissão depende do tamanho do pacote e da taxa de transmissão do canal por onde será transmitido. Atraso de propagação Atraso de propagação, ou latência, é o tempo necessário para a propagação de um bit do início ao fim do enlace. Após o início da transmissão o bit se propaga com a velocidade de propagação do enlace, velocidade esta, que depende do meio de propagação (fibra ótica, par trançado de fios de cobre, etc...), que em alguns meios pode estar perto da velocidade da luz. O atraso de propagação é a razão entre o comprimento do enlace e a velocidade de propagação.

22 2.3 Métricas de desempenho 21 Sendo d proc, d fila, d trans e d prop respectivamente os atrasos de processamento, fila, transmissão e propagação, então podemos definir o atraso nodal total d nodal como sendo: d nodal = d proc + d fila + d trans + d prop (2.1) A Figura 2.1 ilustra cada um dos componentes do atraso total de propagação de um pacote transmitido pelo enlace do roteador A ao roteador B. Figura 2.1: Atraso nodal total (KUROSE; ROSS, 2010) Variação do atraso A variação do atraso, ou jitter, corresponde à diferença entre os atrasos durante a transmissão de pacotes subsequentes. Isso implica em que o atraso na entrega dos pacotes não é constante, o que produz uma recepção não regular dos pacotes. Por exemplo, caso ocorresse uma transmissão entre dois dispositivos de uma rede, onde o transmissor transmitisse à uma taxa constante com intervalo de 10 ms entre dois pacotes consecutivos, tais pacotes deveriam chegar ao destino também com 10 ms se atraso. Porém, cada pacote pode trafegar por diferentes rotas da rede, fazendo com que alguns pacotes acabem trafegando por enlaces com maior utilização (maior atraso de fila), provocando não somente uma variação no atraso, mas podendo em alguns casos provocar a entrega dos dados fora da ordem em que foram transmitidos. Figura 2.2: Variação do atraso - Jitter

23 2.3 Métricas de desempenho 22 O jitter é uma métrica de extrema importância para aplicações em tempo real, sendo potencialmente danoso à qualidade dos serviços de mídia contínua (áudio e vídeo) como o Voice over IP (VoIP). Pro exemplo, em uma transmissão de voz, enquanto o atraso apenas introduz um intervalo entre o início da fala e sua recepção recepção, o jitter pode provocar um certo desconforto por parte do receptor. Este tipo de aplicação necessita por exemplo de atrasos inferiores a 150 ms e variação do atraso entre 20 ms e 50 ms segundo as recomendações da ITU-T (ITU-T, 1998). O jitter pode ser causado por diversos fatores tais como alterações nas rotas entre dois nós de uma rede e tamanho das filas de transmissão nos nós intermediários Perda de pacotes Esta métrica corresponde ao percentual de pacotes perdidos durante a transmissão. Um pacote é considerado perdido caso ele não chegue ao destino após um limite de tempo pré determinado chamado timeout, que pode variar dependendo da distância do caminho e das condições da rede tais como tamanho das filas nos roteadores ou congestionamento de um enlace. Uma rede ou enlace com altas taxas de perda será extremamente prejudicial à aplicações como transferência de dados. Por exemplo, para que a transferência de um arquivo seja concluída com sucesso, após a transmissão o host receptor deve possuir todos os bits referentes aquele arquivo transmitidos, caso durante o envio dos pacotes algum deles se perca, o protocolo de transmissão (TCP) se encarregará com que o mesmo seja retransmitido. Ou seja, caso as taxas de perda sejam muito elevadas, o número de pacotes retransmitidos também será, gerando assim um tráfego extra na rede, além de aumentar o tempo de transmissão. No caso de aplicações multimídia, pequenas taxas de perda são bem toleradas, pois neste tipo de aplicação uma pequena quantidade de pacotes pode ser descartada sem que a qualidade do serviço chegue a níveis intoleráveis pelos usuários, ou seja, uma solicitação de retransmissão seguida da espera para que o pacote retransmitido seja entregue pode ser mais danoso do que simplesmente descartar o pacote perdido. Obviamente à medida que a taxa de perda aumenta a qualidade do serviço multimídia cai podendo chegar a níveis inaceitáveis. Alguns dos motivos que podem provocar perda de pacotes em uma rede são: Sobrecarga das filas dos roteadores: As filas dos roteadores possuem um tamanho finito, ou seja, são capazes de acomodar um número finito de pacotes, sendo assim, um pacote pode chegar a um roteador e encontrar sua fia cheia. Sem espaço para armaze-

24 2.4 Trabalhos relacionados 23 nar este pacote, ele será descartado pelo roteador. A fração de pacotes perdidos aumenta juntamente com o aumento da utilização de um enlace (KUROSE; ROSS, 2010). Erro de bits no meio físico: Normalmente ocasionado pela distorção do sinal de transmissão, como por exemplo, ruídos ou atenuação. Descarte provocados pelos protocolos: Um pacote também pode ser descartado pelo protocolo, como por exemplo o caso em que o campo TTL (Time To Live) chegue a zero Largura de banda A largura de banda é a avaliação da capacidade de transmissão em determinado enlace. Geralmente, aplicações que possuem requisitos de qualidade de serviço, requerem que haja garantia de largura de banda mínina. Exemplifica-se, uma aplicação de voz digitalizada produz um fluxo de 64 kbps 1. Tal aplicação precisa de bons algoritmos de codificação se ao longo do caminho houver um enlace com menos de 64 kbps (SILVA, 2004). A tabela 2.1 (KUROSE; ROSS, 2010) mostra o requerimento de algumas aplicações. Aplicação Perda de dados Vazão Sensível ao tempo Transferência de arquivos Sem perda Elástica Não Sem perda Elástica Não Documentos web Sem perda Elástica Não Áudio/Vídeo tempo real Tolerante a perda Áudio: 5 kbps-1 Mbps Sim, centenas de ms Vídeo: 10 kbps-5 Mbps Áudio/Vídeo armazenado Tolerante a perda Áudio: 5 kbps-1 Mbps Sim, alguns segundos Vídeo: 10 kbps-5 Mbps Jogos interativos Tolerante a perda Poucos bkps ou mais Sim, centenas de ms Mensagem instantânea Sem perda Elástica Sim e não Tabela 2.1: Requisitos de serviço de transporte de algumas aplicações 2.4 Trabalhos relacionados Podemos citar como um trabalho relacionado, o projeto SIMET (SIMET, 2012) que tem como características permitir a medição, armazenamento e visualização sobre testes realizados na última milha, extraindo métricas dos protocolos TCP e UDP. O SIMET dispõe de um applet Java que realiza testes de desempenho de redes com acesso a Internet, através de servidores espalhados dentro dos Pontos de Troca de Tráfego (PTT) e 1 Em modularização PCM sem compressão

25 2.4 Trabalhos relacionados 24 no NIC.br. A escolha de qual servidor será utilizado no teste é feita de forma automática, utilizando-se o critério da menor latência. A localização geográfica do IP de origem do teste também é feita através do CEP informado pelo usuário no momento do teste. O NDT apoia-se no web100 extraindo estados de congestionamento da rede, e uma série de informações detalhadas que não estão presentes no Simet, porém não oferece a possibilidade da indexação de informações sobre a localização do usuário, nem mesmo uma forma consistente de armazenamento das informações coletadas. Com a extensão que será proposta neste trabalho, pretende-se abordar as deficiências de armazenamento e de referência geográfica apresentadas pelo NDT para melhor proveito das informações detalhadas extraídas do web100.

26 25 3 Ferramenta NDT Este capítulo tem como objetivo apresentar a ferramenta NDT que foi a aplicação base utilizada neste trabalho para a realização das medições. 3.1 Uma visão geral sobre o NDT NDT é uma ferramenta de diagnóstico de rede que consiste em uma aplicação cliente/servidor que provê testes de configuração e performance (NDT, 2012). O sistema é composto por um programa cliente (linha de comando ou applet) e por outros programas que são hospedados no servidor. A aplicação cliente, seja linha de comando ou applet, se comunica com um servidor Web100 (WEB100.ORG, 2012) para realizar as funções de diagnóstico. Resultados com vários níveis de informação permitem que desde usuários novatos até administradores de redes sejam capazes de visualizar e compreender as informações obtidas. O aplicativo mede a vazão sobre o protocolo TCP nas duas direções (do cliente para servidor e do servidor para o cliente). Um kernel Linux modificado com por um patch Web100 é o responsável por desempenhar as funções de diagnóstico através da análise dos dados capturados, tentando localizar possíveis problemas na conexão. O sistema é constituído por vários componentes, um programa cliente e um grupo de programas que são executados no servidor, sendo um servidor web básico (fakewww) para lidar com as solicitações recebidas do cliente, o serviço fakewww é um servidor web simples e pode ser subistituido por um outro servidor mais robusto como o Apache (APACHE.ORG, 2012), e um segundo processo (web100srv) que realiza os testes específicos necessários para determinar problemas na conexão. O cliente pode acessar o serviço através de duas formas: tanto com linha de comando (web100clt) como através de uma página web. Para a execução via linha de comando, o cliente deve ser instalado manualmente, já para o acesso via página web o applet Java é carregado automaticamente. Neste trabalho a versão de acesso pela web mostrou-se mais atrativa dada a

27 3.2 O Projeto Web facilidade com que os usuários poderiam realizar seus testes. 3.2 O Projeto Web100 O projeto Web100 foi criado com o objetivo de tentar resolver de forma abrangente os problemas encontrados no mal desempenho das redes de computadores. A abordagem proposta é produzir um ambiente de hospedagem de software completo que irá executar aplicações Web comum a 100% da banda disponível, independentemente da magnitude da capacidade de uma rede. Em particular, as aplicações seriam capazes de consumir automaticamente 100% da largura de banda disponível. Para tal proposito, o projeto Web100 vem desenvolvendo uma interface de gerenciamento avançada para o TCP, coletando dados estatísticos das conexões e todos os eventos significantes do protocolo. Foram desenvolvidos instrumentos para capturar desde eventos comuns como segmentos de dados enviados e recebidos até eventos mais sutis como os que poderiam causar a redução das taxas de transmissão do TCP. Estes eventos são referenciados como Kernel Instrument Set (KIS), que é o núcleo do projeto. A biblioteca desenvolvida neste projeto provê funções para consultar e configurar valores de variáveis TCP para uma sessão particular. Estas funções permitem que as aplicações sincronizem e monitorem suas conexões. Além disso, a equipe Web100 lançou uma instrumentação da pilha TCP, que fornece uma interface para os programas em modo usuário possam acessar variáveis internas do TCP. Esta interface é fornecida através do sistema de arquivos Linux /proc. A estrutura da pilha Web100 é mostrado na Figura 3.1 (MUDAMBI, 2006b). O conjunto de instrumentação kernel (KIS) interage com a pilha de rede e interfaces para o espaço do usuário. A mesma interface também permite que alguns campos na estrutura de dados interna que o Linux mantém para cada soquete TCP possam ser definidas a partir do escopo do usuário.

28 3.3 Protocolo NDT 27 Figura 3.1: Estrutura de implementação Web100 (MUDAMBI, 2006a) 3.3 Protocolo NDT O protocolo NDT, ou Network Diagnostic Tool Protocol (NDTP), na verdade consiste em outros dois protocolos relacionados: NDTP de Controle e NDTP de Testes. NDTP de Controle é usado para iniciar e interromper as sessões de teste além de buscar seus resultados, enquanto NDTP de Testes é um conjunto de pequenas sub protocolos que concentram-se em testar o desempenho da rede. O NDTP Testes consiste de cinco menores sub-protocolos: teste Middlebox, Teste Simples de Firewal, Teste de vazão Cliente-Servidor (ou teste C2S), teste de vazão Servidor-Cliente (ou teste S2C) e teste META. Estes testes são completamente independentes uns das outros e podem ser executados em qualquer ordem ou mesmo ignorados. O protocolo de controle é projetado para suportar a negociação de sessões e resultados. No início da sessão há uma negociação do conjunto de testes a serem realizados, onde o cliente indica quais os testes que ele pretende realizar. Além disso, o protocolo de controle define um formato de mensagem, que aumenta consideravelmente a confiabilidade do protocolo e permite que outros protocolos de teste possam se comunicar de forma mais estruturada.

29 3.3 Protocolo NDT Modelo lógico do protocolo Vários papéis diferentes tanto no protocolo de controle quanto no de testes podem ser distinguidos. Dentre eles: Sessão de envio (Session-Sender): Sessão de envio de dados para o protocolo de testes; Sessão do receptor (Session-Receiver): Sessão do receptor do protocolo de testes; Servidor: Sistema que gerencia o protocolo de controle e as sessões de testes; Cliente: Sistema que inicia pedidos de sessões de testes e recebe os dados dos resultados. As figuras 3.2 e 3.3 (NDT Project, 2012) descrevem respectivamente o protocolo de teste de vazão cliente-servidor e servidor-cliente. Figura 3.2: Protocolo do teste de vazão cliente-servidor (NDT Project, 2012) Figura 3.3: Protocolo do teste de vazão servidor-cliente (NDT Project, 2012) Como descrito acima, o NDTP consiste de dois conjuntos relacionados de protocolos: controle e testes. Ambos estão sobre a camadas TCP. O primeiro é usado para iniciar e controlar as sessões de teste e para buscar os seus resultados, enquanto o último é um subconjunto de protocolos usado para realizar os testes. Ao início de uma sessão de teste é estabelecido uma conexão TCP a uma previamente conhecida, a porta 3001, e essa conexão permanece aberta durante todas as sessões de testes. O servidor NDT deve ouvir esta mesma porta. As mensagens de controle são transmitidas antes do início das sessões de teste. Além disso, o protocolo de teste pode usar o protocolo de controle para sincronizar suas sessões, além da troca de dados de configuração.

30 3.4 Protocolo de controle Protocolo de controle Este protocolo é implementado de forma a eliminar conexões não utilizadas para prevenir ataques de denial-of-service (DoS), ou o uso de memória ilimitada pelo servidor. Por exemplo, se a mensagem de controle não for recebida dentro de um determinado número de segundos pré-definido as conexões associadas à sessão devem ser descartadas. Como já foi visto, o NDT utiliza-se de mensagens padronizadas para aumentar a confiabilidade das informações. O tipo de cada mensagem do protocolo de controle pode ser encontrado após a leitura do primeiro octeto. O tamanho de cada mensagem pode ser obtida com a leitura do segundo octeto. Nenhuma mensagem é menor do que 3 octetos. A figura 3.4 mostra a estrutura das mensagens utilizadas durante o teste. Vários tipos de mensagens são utilizados pelo NDT tanto para transferência de dados quanto para gerenciar e sincronizar procedimentos dos teste. A tabela 3.1 mostra os tipos de mensagens utilizadas e uma breve descrição para cada um dos tipos. Figura 3.4: Estrutura da mensagem do protocolo de controle NDT (NDT Project, 2012) Nome simbólico COMM_FAILURE SRV_QUEUE MSG_LOGIN TEST_PREPARE TEST_START TEST_MSG TEST_FINALIZE MSG_ERROR MSG_RESULTS MSG_LOGOUT MSG_WAITING Descrição Notificação para falha no link de comunicação Mensagem utiliza para controle de filas de clientes Usada durante a inicialização, para negociação da versão do cliente Usada para enviar todas as informações necessárias para um teste Usada para iniciar um teste Usada para comunicação entre cliente e servidor durante um teste Usada para encerrar um teste Usada para enviar mensagens de erros ou notificações Usada para envio dos resultados finais dos testes Última mensagem enviada após o envio dos resultados Enviada ao cliente indicando que sua solicitação ainda está ativa Tabela 3.1: Tipos de mensagens utilizadas pelo protocolo NDT (NDT Project, 2012) A ferramenta NDT possui um conjunto de testes que podem ser realizados ou não por um cliente. Quando o cliente faz uma solicitação para início de se uma sessão de testes, ele deve enviar a lista dos testes que ele deseja realizar. Cabe ao protocolo de controle fornecer ao cliente uma lista de identificadores de testes a serem executados, onde não deve haver nenhum teste diferente dos solicitados, caso isso ocorra, o cliente deve abandonar o teste.

31 3.4 Protocolo de controle 30 Após a conexão ser estabelecida, o servidor verifica se já existe algum teste em andamento, caso exista, o servidor irá proceder de forma que esta solicitação aguarde em uma fila para ser executada assim que possível, enquanto isso o cliente receberá uma mensagem indicando que deverá aguardar pelo teste. O servidor NDT também deve fazer uma verificação de compatibilidade, a sua própria versão e a versão utilizada pelo cliente. O próximo passo é a execução da lista de testes fornecida pelo servidor, na ordem em que ela foi entregue. Após o último teste, o servidor deve enviar todos os resultados obtidos para o cliente. Esses resultados devem ser enviados em um conjunto de mensagens MSG_RESULTS (Figura 3.5). Todos os resultados devem ser codificados como strings legíveis para permitir que o cliente possa exibi-los diretamente na tela sem qualquer modificação. Figura 3.5: Estrutura da mensagem de envio de resultados (NDT Project, 2012) No final o servidor deve fechar a sessão de todo o teste, enviando uma mensagem indicando ao cliente que o teste foi finalizado e logo em seguida fechar conexão. A visão geral da sessão inteira de teste pode ser vista no diagrama a seguir. Tanto o servidor quanto o cliente deve seguir a sequência descrita: Figura 3.6: Diagrama do protocolo de controle NDT (NDT Project, 2012)

32 3.5 Protocolo de testes Protocolo de testes NDT é uma típica aplicação cliente/servidor de teste, o seu diferencial está no recursos avançados de diagnóstico que são ativados pelos dados coletados através do kernel e a infraestrutura de monitoramento web100. Esses dados são coletados durante o teste e analisados após sua conclusão para determinar caso exista, qual fator possa ter impactado nos resultados. O protocolo de testes é um conjunto de outros protocolos que são responsáveis por controlar os procedimentos de testes Teste Middlebox O teste middlebox é um pequeno teste de vazão do servidor para o cliente com uma janela de congestionamento limitada (janela de congestionamento é um dos fatores que determina o número de bytes que podem ser transmitidos simultaneamente) para verificar se há alguma incompatibilidade duplex (bidirecional). Este teste usa um tamanho máximo de segmento ou MSS, do inglês Maximum Segment Size, pré-definido para verificar se algum nó intermediário está modificando as configurações da conexão. Todas as mensagens trocadas entre o cliente e o servidor durante o protocolo de Middlebox são enviadas usando a mesma conexão e formato das mensagens do protocolo de controle. Apenas os pacotes de dados usados efetivamente para calcular a vazão são enviados em uma nova conexão e não seguem este padrão. Neste teste, o servidor deve preparar uma conexão e enviar para o cliente uma mensagem contendo o número da porta da conexão criada. Em seguida, o cliente deve se conectar a esta porta e começar a ler dados enviados pelo servidor. Quando o cliente se conecta com êxito, o servidor NDT inicia um teste de vazão durante cinco segundos usando a conexão recém criada. Após a conclusão do teste, o cliente deve enviar para o servidor o valor calculado para sua vazão usando a conexão do protocolo de controle. O valor da vazão deve ser calculado através da seguinte fórmula: Vazão = 8x(n o de bytes transmitidos) 1000 (tempo decorrido durante o teste) (3.1)

33 3.5 Protocolo de testes Teste simples de firewall Este teste tenta descobrir qualquer firewall entre o cliente e o servidor NDT que possa impedir conexões com uma porta cujo o número não seja previamente conhecido. O teste é realizado em ambas as direções, ou seja, no sentido do cliente para o servidor e no sentido do servidor para o cliente. Assim como no teste middlebox, todas as mensagens de controle trocadas entre o cliente e o servidor durante o teste simples de firewall são enviadas usando a mesma conexão e formato de mensagem do protocolo de controle. Apenas uma mensagem contendo uma string previamente conhecida, "Simple firewall test", é enviada usando uma nova conexão. Na primeira etapa do teste o servidor inicia uma conexão em uma porta aleatória, e logo em seguida envia ao cliente uma mensagem contendo o número desta porta. Esta mensagem é enviada usando a conexão do protocolo de controle. Em seguida, o cliente também deve criar uma conexão em uma porta aleatória e enviar uma mensagem contendo apenas o número desta porta. O servidor NDT deve iniciar o teste enviando uma mensagem TEST_START, imediatamente após receber o número do porta do cliente. O teste deve ser realizado em ambas as direções em paralelo, ou seja, o cliente deve tentar se conectar a porta informada pelo servidor e enviar uma mensagem contendo uma mensagem pré definida usando a conexão recém criada enquanto o servidor tenta se conectar a porta informada pelo cliente e enviar uma outra mensagem com mesmo conteúdo. Depois de realizar o teste em ambas as direções, o servidor envia ao cliente seus resultados utilizando a conexão do protocolo de controle Teste de vazão Cliente-Servidor O teste de vazão cliente-servidor, ou C2S, mede a largura de banda disponível do cliente para o servidor ou upload, através da realização de um teste de transferência de dados com duração de aproximadamente 10 segundos. Todas as mensagens trocadas entre o cliente e o servidor durante o teste C2S são enviados usando a mesma conexão e formato de mensagem do protocolo de controle. Apenas os pacotes de transferência são enviados por uma nova conexão e não seguem o padrão de formato de mensagem. Primeiramente o servidor deve criar uma conexão em uma nova porta, e enviar uma mensagem TEST_PREPARE contendo este número de porta para o cliente usando a conexão do

34 3.5 Protocolo de testes 33 protocolo de controle. Em seguida, o cliente deve se conectar a esta porta recém criada a fim de iniciar o teste. Então, cliente deve iniciar o teste de 10 segundos usando a conexão recém criada, enquanto o servidor deve ler os dados transmitidos. Quando o cliente deixa de streaming de dados de teste o servidor deve enviar ao cliente o valor de transferência calculada codificado como string na mensagem TEST_MSG usando a conexão do protocolo de controle. O valor de transferência deve ser calculado utilizando a mesma função da equação 3.1 No final o servidor deve fechar a sessão de testes C2S enviando uma mensagem ao cliente para comunicar que o teste foi concluído. A figura 3.7 mostra um diagrama do protocolo descrito. Figura 3.7: Diagrama do protocolo C2S (NDT Project, 2012) Teste de vazão Servidor-Cliente O teste de vazão Servidor-Cliente, ou S2C, mede a largura de banda disponível do cliente para o servidor ou download, através da realização de um teste de transferência de dados com duração de aproximadamente 10 segundos. Durante este teste, o servidor NDT utiliza-se do kernel web100 para realizar medições mais detalhadas, ou seja, o servidor também irá recolher as variáveis web100 e as enviar ao cliente ao término do teste.

35 3.5 Protocolo de testes 34 Inicialmente, o servidor deve criar uma nova conexão em uma porta aleatória, em seguida, ele deve enviar uma mensagem contendo este número de porta para o cliente usando a conexão do protocolo de controle. Após receber a mensagem enviada pelo servidor, o cliente deve se conectar a esta porta recém criada. A fim de iniciar o teste, o servidor então deve enviar uma mensagem TEST_START usando a conexão do protocolo de controle mais uma vez. Após isso, o servidor deve utilizar a conexão recém criada para iniciar o teste de vazão durante 10 segundos. Durante o teste o cliente deve ler os dados transmitidos. Após o término do envio dos dados de teste, o servidor deve enviar ao cliente o valor de da vazão calculada, utilizando uma mensagem através da conexão do protocolo de controle. O valor de transferência deve ser calculado com a mesma fórmula da equação 3.1. Ao término do teste, o servidor deve enviar ao cliente as variáveis web100 recolhidas durante teste de vazão S2C. Cada par nome/valor deve ser codificado como uma string em mensagens TEST_MSG individuais e separadas, cada uma usando o seguinte formato: Figura 3.8: Formato das mensagens de envio de resultados (NDT Project, 2012) Após o envio de todas as mensagens necessárias para a transmissão dos resultados, o servidor encerra a conexão.

36 3.5 Protocolo de testes 35 A figura 3.9 mostra um diagrama do protocolo descrito: Figura 3.9: Diagrama do protocolo S2C (NDT Project, 2012) Meta teste Este teste permite que o cliente envie uma informação adicional para o servidor para ser incluído junto com o conjunto global de resultados do teste. O cliente deve enviar os meta dados em pares no formato nome/valor codificados em uma string utilizando-se de mensagens TEST_MSG individuais e separadas, assim como ilustra a figura 3.10:

37 3.5 Protocolo de testes 36 Figura 3.10: Estrutura das mensagens do meta teste (NDT Project, 2012)

38 37 4 Extensão da ferramenta de medição Neste capítulo, será apresentada a o processo de extensão da ferramenta, e como a ferramenta estendida foi empregada na campanha de medição. 4.1 Visão geral O armazenamento dos dados assim como a informação geográfica do usuário, não são suportados pelo NDT tradicional, neste caso, a extensão foi feita de tal forma a permitir que essas funcionalidades fossem incluídas no arcabouço do NDT. A interface foi alterada para possibilitar que o usuário possa inserir informações sobre sua localização no momento do teste. Além da reformulação da interface, foi preciso incluir um daemon no lado do servidor que fica aguardando por requisições de envio de dados. Já no lado do cliente NDT (applet) foi necessário adicionar a funcionalidade de comunicação com este daemon, para que, após a finalização do teste, os dados possam ser enviados, e posteriormente armazenados em um banco de dados relacional. Para aumentar as informações sobre o IP de origem, uma consulta ao whois auxilia na certificação da origem do endereço daquela rede. Essas informações são indexadas juntamente com os dados da medições. 4.2 Arquitetura O ambiente proposto foi desenvolvido utilizando-se o princípio de arquitetura de aplicações em três camadas de forma modular, de tal forma que qualquer uma das três camadas (Apresentação, Aplicação e Persistência) possa ser substituídas em trabalhos futuros sem que essas substituições interfiram obrigatoriamente nas outras. Por exemplo, caso uma análise futura implicasse que o banco de dados utilizado (MySQL) não atende mais as necessidades da aplicação, esse banco poderia ser substituído por um outro sendo necessárias alterações somente

39 4.2 Arquitetura 38 na camada de persistência sem afetar de nenhuma outra forma as outras camadas. Obviamente nem todas as alterações podem ser realizadas de forma tão pontual. A figura 4.1 mostra de forma resumida como funciona a arquitetura do sistema. Figura 4.1: Arquitetura em camadas da solução proposta Camada de apresentação A camada de apresentação, ou Graphical User Interface (GUI), ou simplesmente interface é a camada responsável por interagir diretamente com o usuário. Vale lembrar que o NDT já possui uma própria interface gráfica, assim como mostra a figura 4.2. A proposta da criação de uma nova interface para a nossa aplicação surge da a necessidade de apresentar aos usuários os resultados obtidos de uma forma mais amigável e mais atrativa, ampliando a probabilidade de que os utilizadores do sistema sejam atraídos a realizarem novos testes em outras oportunidades, aumentando assim a quantidade de informação na base de dados, o que por sua vez possibilita uma análise mais ampla e precisa.

40 4.2 Arquitetura 39 Figura 4.2: Interface do applet NDT Além da tentativa de tornar o ambiente de testes mais atrativo para os usuários, outro ponto merece atenção. Por se tratar de um sistema que será disponibilizado via web, é necessário que ele seja capaz de operar nos diferentes navegadores. Apesar de existirem iniciativas para a padronização, a criação e interpretação de conteúdos na Web, como o W3C (W3C, 2012), ainda é comum encontrar aplicações ou sites que não funcionam, ou que restringem algumas funcionalidades para determinados navegadores. Um dos principais motivos dessa falta de portabilidade é causada por incompatibilidade de funções JavaScript, que atualmente é a principal linguagem de programação client-side em navegadores. A opção encontrada para contornar este problema foi a utilização da biblioteca jquery (JQUERY, 2012), que é um biblioteca JavaScript de código aberto. Lançada em janeiro de 2006, foi desenvolvida com o objetivo de fornecer funções JavaScript que sejam compatíveis com os principais navegadores. Mesmo com a nova interface, o applet não foi descartado, pois é ele ainda quem faz a comunicação com o servidor NDT e recebe os dados do servidor. O que foi feito na verdade foi sua ocultação, ou seja, ele ainda faz a comunicação com o servidor NDT, e a interação do usuário com o usuário é feita através de chamadas JavaScript de forma que quando o usuário clica no botão "Iniciar Teste"o ocorre é executado um script que aciona o applet Java iniciado o teste realmente. Após a conclusão do teste, o dados são recebidos, e a interface se encarrega de solicitá-los e apresentá-los ao usuário.

41 4.2 Arquitetura 40 Figura 4.3: Interação entra a interface e o cliente NDT A figura 4.3, ilustra de forma simplificada a interação que ocorre entre a interface web e o cliente NDT. A interface web é composta basicamente por dois componentes, o componente javascript representado pela biblioteca jquery e o componente HTML A troca de dados entre a interface e o applet ocorre nos dois sentidos, uma vez que a interface consultar e fornecer informações. As informações de localização geográfica são fornecidas pelo usuário no momento de realização do teste através da escolha do estado e cidade. Apesar desta informação ser extremamente importante para o este trabalho, ela não é obrigatória, ou seja, é possível realizar um teste sem que estas informações sejam informadas.a figura 4.4 mostra a nova interface. Figura 4.4: Interface desenvolvida para a ferramenta de medição

42 4.2 Arquitetura Camada de aplicação A camada de aplicação, ou camada lógica, como o próprio nome já diz, é responsável por abranger toda e qualquer lógica relacionada à aplicação. O NDT juntamente com o kernel web100 são responsáveis pela implementação desta camada, que por tamanha importância para o bom funcionamento deste trabalho mereceu um capítulo próprio (Capítulo 3). Assim, a ferramenta NDT foi apenas incorporada a ferramenta de testes, de forma a interagir com as outras duas camadas. A figura 4.5 mostra a representação da camada de aplicação que é composta basicamente pelo cliente NDT, o kernel web100 e o servidor NDT, sendo estes dois últimos localizados no ponto de medição, ou seja, no servidor de testes. Figura 4.5: Representação da camada de aplicação Camada de persistência e armazenamento A camada, de persistência, ou de acesso aos dados, é a parte da aplicação responsável por se comunicar com o banco de dados. Esta camada tem o papel de armazenar os dados, ou seja, os persistir. A camada de persistência é responsável por acessar e conhecer os métodos de armazenamento do banco de dados, no caso da aplicação desenvolvida neste trabalho, essa camada é representada por um daemon, ou seja, um aplicação que é executada em background no sistema operacional. Como o ambiente do NDT é desenvolvido para o sistema operacional Linux, o daemon da camada de persistência também foi projetado para tal sistema operacional.

43 4.2 Arquitetura 42 O daemon coletor de dados O daemon coletor de dados (DataCollector), é uma aplicação desenvolvida em Java, que fica em constante execução no ponto de medição (servidor NDT), ele é responsável por receber os dados provenientes da medição e os inserir devidamente no banco de dados. Após o teste, enquanto os resultados são exibidos para o usuário, o cliente NDT (applet Java) inicia uma nova conexão em uma porta previamente conhecida, e conecta-se ao servidor NDT, após a conexão ter sido estabelecida é iniciado o processo de envio dos dados da medição, assim como os dados referentes à localização geográfica. Esses dados são enviados em formato de string igual ao formato usado pelos protocolos do NDT. Do outro lado da conexão a aplicação coletora de dados, coleta as mensagens enviadas pelo cliente, verifica quais as variáveis foram enviadas e armazena seus respectivos valores no banco de dados. A segurança da aplicação coletora de dados é feita a partir do controle do tamanho máximo das mensagens enviadas, além da sua padronização, logo, em uma tentativa de enviar dados aleatórios eles seriam descartados por não seguirem o padrão pré definido. Modelagem do banco de dados O armazenamento dos dados é feito em um banco de dados relacional. Portanto, a técnica de modelagem que foi utilizada é a de entidade-relacionamento. Figura 4.6: Modelo Entidade-Relacionamento do modelo proposto A figura 4.6 mostra o modelo entidade-relacionamento proposto para este trabalho. O modelo tem baixa complexidade e possui apenas 3 entidades: Medição: Entidade principal do modelo, ela contem além de atributos relacionados às métricas de rede como vazão de upload e download e também dados relevantes como

44 4.3 Dados da localização geográfica 43 IP do cliente, sua localização geográfica, navegador utilizado, data e hora da medição, dentre outros. Variáveis NDT: Pode ser considerada uma entidade fraca, sendo que a existência de seus dados está diretamente ligada a entidade principal. Seus atributos são as variáveis fornecidas pelo próprio cliente NDT. Variáveis Web100: Pode ser considerada uma entidade fraca, sendo que a existência de seus dados está diretamente ligada a entidade principal. Seus atributos são as variáveis fornecidas pelo kernel Web Dados da localização geográfica A obtenção da localização geográfica de um usuário a partir do seu endereço IP é uma informação valiosa, porém, ainda é uma questão em aberto no mundo das telecomunicações. Durante o desenvolvimento deste trabalho, surgiram formas diferentes para a implementação desta função, a primeira delas foi a utilização do CEP, que atribuiria ao usuário a função de informar o código postal de seu endereço, o que dificultaria a realização dos testes um vez que um usuário desatendo poderia inserir a informação de forma incorreta, poluindo a base de dados com informações incorretas. Dessa forma, optou-se por inicialmente utilizar informações de estado e cidade cedidas pelos próprios usuários, por serem mais fáceis de serem adquiridas, e também por apresentar uma maior facilidade para o usuário inserir os dados corretamente, evitando assim a poluição da base de dados. A forma mais segura e precisa de se obter essas informações, sem que seja necessária intervenção do usuário e com uma margem de erro muito baixa, seria a utilização de dispositivos de Global Positioning System (GPS), por outro lado ainda são raros os usuários que dispõem desse dispositivo. Com a intenção dessa ferramenta de obtenção de localização geográfica, é que a modelagem do bando de dados foi feita de tal forma que esses atributos possam ser facilmente implementados em trabalhos futuros. 4.4 Consulta à base de dados whois Durante o desenvolvimento deste trabalho, além dos dados de métricas fornecidos pelo NDT e a localização geográfica do usuário, observamos que outros tipos de informações pode-

45 4.4 Consulta à base de dados whois 44 riam ser relevantes para uma análise mais abrangente. Parte dessas informações estão relacionadas aos provedores de acesso que fornecem o serviço de Internet. Ter o conhecimento sobre qual a prestadora é responsável por fornecer a conexão de cada usuário que realiza um teste é importante para o objetivo aqui proposto, pois com este dado é possível a realização mais aprimorada da qualidade da Internet, como por exemplo através de inferências estatísticas obter qual provedor é mais bem conectado ao ponto de medição, qual oferece em média maior banda de upload e download para seus usuário, qual possui a maior ou menor latência até o ponto de medição. As informações dos provedores que tiveram sua importância justifica acima foram obtidas através do endereço IP solicitante dos testes, a partir do IP do é possível consultar a base de dados de algum servidor whois que fornecem as informações necessárias. Whois é a função da Internet apropriadamente chamado que permite a consulta bancos de dados whois remotos para obter informações de registro de domínio. Ao realizar uma pesquisa simples que pode descobrir quando e por quem um domínio foi registrado, informações de contato, dentre outras. A pesquisa também pode revelar o nome de rede mapeada para um endereço IP. Por motivos de segurança, alguns servidores whois possuem um limite diários de consultas provenientes de um mesmo endereço IP, por esta limitação não seria interessante concentrar todas as consultas no servidor do ponto de medição, sendo assim, as consultas à base de dados são feitas pelo applet cliente NDT. A consulta é realizada logo após o teste ser concluído, e seu resultado é enviado à aplicação coletora de dados juntamente com o restante das informações referentes ao teste. Caso os dados da consulta whois não sejam entregues por algum motivo para a camada de persistência a aplicação coletora de dados tenta novamente fazer uma nova consulta. Abaixo temos um exemplo do resultado obtido a partir de uma consulta whois do endereço : inetnum: /16 aut-num: AS1916 abuse-c: SIC128 owner: Associação Rede Nacional de Ensino e Pesquisa ownerid: / responsible: Nelson Simões Silva country: BR owner-c: RCO217

46 4.4 Consulta à base de dados whois 45 tech-c: RCO217 inetrev: /24 nserver: ns1.pop-es.rnp.br nsstat: AA nslastaa: nserver: ns2.pop-es.rnp.br nsstat: AA nslastaa: created: changed: nic-hdl-br: RCO217 person: RNP - Centro de Engenharia e Operações registro@rnp.br created: changed: nic-hdl-br: SIC128 person: Security Incidents Response Center cais@cais.rnp.br created: changed: Servidor whois RNP A RNP possui seu próprio servidor whois (no endereço whois.rnp.br). Com base nas informações obtidas a partir da consultas feitas a este servidor podemos afirmar se um determinado IP pertence ou não à rede da RNP, como este trabalho foi desenvolvido em parceria com o PoP-ES, optamos em dar um tratamento diferencial aos testes originados desta rede. Esta diferenciação está justamente na lógica de consultas à base de dados whois. A RNP opera um serviço de backbone para atender à comunidade acadêmica e de pesquisa, oferecendo acesso à Internet através dos seus pontos de presença (PoPs) regionais. Os PoPs da RNP, que compõem o seu backbone nacional, estão presentes em todos os 27 Estados da Federação. Justamente pelo fato de haver essa distribuição, podemos supor que se cada PoP possuir seu próprio servidor whois esse servidor poderia ser consultado de forma a obter informações mais precisas sobre a localização geográfica do endereço IP consultado. Com descentralização do servidor whois, seria mais fácil administrar as informações das bases de dados. Partindo deste principio a lógica para a identificação dos servidores a serem

47 4.5 Análise dos dados coletados 46 consultados segue o seguinte padrão: i) Ao receber os dados de um teste, a aplicação coletora de dados sempre faz uma consulta ao servidor da RNP; ii) Caso o endereço IP consultado não pertença à RNP, é feita uma consulta ao servidor de nível nacional, caso a consulta não seja concluída com sucesso será feita uma consulta à um servidor com nível de hierarquia maior. Os endereços dos servidores são configuráveis pelo administrador do sistema; iii) Caso o endereço IP consultado pertença à RNP, a partir da consulta já realizada é possível obter à qual estado este IP pertence, logo à qual PoP ele está vinculado. Com essas informações em mãos, basta apenas consultar a base de dados whois daquele PoP específico para obter as informações que sejam relevantes, como dados de localização geográfica. Essas informações além de cidade e estado podem conter informações mais precisas como coordenadas de longitude e latitude. Atualmente os pontos de presença da RNP não possuem este tipo de base de dados detalhada, mas todavia a aplicação desenvolvida tem a capacidade de lidar com tal cenário. 4.5 Análise dos dados coletados Após a fase de desenvolvimento da ferramenta de medição, iniciou-se o trabalho de coleta de dados. Através o endereço mais de 600 medições durante o período compreendido entre 01 de Dezembro de 2011 e 30 de Janeiro de Todos os dados foram coletados a partir de testes realizados voluntariamente por usuários da Internet Comparação entre os serviços prestados pelas operadoras A partir da base de dados coletada durante a fase de utilização da ferramenta, é possível inferir alguns dados estatísticos a respeito da qualidade dos serviços prestados pelas diferentes operadoras que atuam no estado do Espírito Santo, esta sessão tem como objetivo usar estes dados para fornecer níveis de qualidade das métricas descritas no capítulo 2. Número de medições realizadas A partir dos dados obtidos nas consultas whois foi possível obter a qual operadora pertence cada IP do qual foram solicitados testes. A tabela 4.1 mostra os dados referentes aos testes

48 4.5 Análise dos dados coletados 47 realizados no Espírito Santo. Operadora Número de medições Percentual de medições Amigo Telecomunicações Ltda 6 1,06 Associação Rede Nacional de Ensino e Pesquisa 74 13,14 Claro S/A 9 1,60 Dinâmica Telecomunicações Ltda 2 0,35 EBR Informática Ltda 11 1,95 Emp Proc de Dados do Estado do ES 15 2,67 Global Village Telecom (GVT) ,41 Intercol - Internet Colatina Ltda-ME 1 0,18 Intervip Networks Ltda. 1 0,18 Linhares Serviços Online LTDA EPP 3 0,53 NET Serviços de Comunicação S.A ,79 Novatec Informatica 1 0,18 RCA Company de Telecomunicações Ltda 85 15,09 Telemar Norte Leste S.A ,61 Tim Celular S.A. 1 0,18 Vivo S.A. 5 0,89 WKVE Asses. em Serviços de Inform. e Telecom. Ltda 2 0,35 Total Tabela 4.1: Quatidade de testes realidados por operadora no Espírito Santo Como mostra a tabela 4.1 algumas das operadoras não possuem um número significante de medições para que os dados sejam analisados, ou seja, não há um número suficiente de amostras no conjunto de dados, portando usaremos como critério para seleção das operadoras a serem analisadas aquelas que possuírem ao menos cinco medições, dando um enfoque às que tem um número maior de testes.

49 4.5 Análise dos dados coletados 48 Figura 4.7: Quatidade de testes realidados por operadora no Espírito Santo Vazão Um dos o fatores que mais influência o usuário no momento da contratação de um plano de Internet banda larga, e ainda o maior motivo de queixa dos usuários no pós-compra, obter medidas de vazão é uma forma bem considerável para inferir a percepção do usuário. Afinal a rapidez de atividades como transferência de arquivos, navegação web aplicações e assistir a um stream de vídeo dependem diretamente desta métrica. As tabelas 4.2 e 4.3, mostram respectivamente uma comparação entre a vazão clienteservidor e servidor-cliente das operadoras utilizadas nas medições de usuários localizados no Espírito Santo. A partir dos dados destas tabelas, podemos observar que a Global Village Telecom (GVT) não somente foi a operadora mais utilizada durante os testes, assim como mostra a tabela 4.1, como também disponibiliza em média maior largura de banda para seus clientes dentre as operadoras comerciais do estado. Os gráficos da figura 4.8 dão uma visualização mais precisa dos dados obtidos pelas operadoras com maior número de testes (GVT, NET, RCA e OI Telemar).