Análise de Tráfego Peer-to-Peer baseada na Carga Útil dos Pacotes

Análise de Tráfego Peer-to-Peer baseada na Carga Útil dos Pacotes Guthemberg Silvestre 1, Carlos Kamienski 2, Stênio Fernandes 3, Dênio Mariz 2, Djamel Sadok 1 1 Centro de Informática Universidade Federal de Pernambuco (UFPE) Caixa Postal 7851 Cidade Universitária 50.732-970 Recife PE 2 Centro Federal de Educação Tecnológica da Paraíba (CEFET-PB) 3 Centro Federal de Educação Tecnológica de Alagoas (CEFET-AL) {guto,cak,stenio,denio,jamel}@gprt.ufpe.br Abstract. It is increasingly necessary to identify and successfully characterize peer-to-peer (P2P) traffic as it predominates in the Internet. Yet there is however no proven methodology to achieve this as it often hides itself behind well-known services and does not maintain fixed port numbers. This work analyses P2P traffic by examining packet load in the Brazilian academic network (RNP) and a commercial service provider (ISP). The obtained results show that P2P corresponds up to 60% of the total PoP-PE traffic and up to 40% in the ISP. Furthermore, this traffic has resulted in a significant change in profile in that it increased its outbound traffic to almost the level of inbound traffic. Resumo. A identificação e caracterização do tráfego gerado por aplicações peer-to-peer (P2P) vêm assumindo uma importância cada vez maior, devido ao aumento da sua participação no volume total de tráfego na Internet. No entanto, não existe ainda uma metodologia eficaz, porque as aplicações P2P atuais não utilizam números fixos de portas. Este artigo apresenta uma análise de tráfego P2P baseada na observação da carga útil dos pacotes para uma rede acadêmica (PoP-PE da RNP) e outra comercial (ISP). Os resultados mostram, por exemplo, que o tráfego P2P corresponde a cerca de 60% do total no PoP-PE e 40% no ISP. Além disso, o tráfego P2P gerou uma mudança de perfil no PoP-PE, que aumentou significativamente o seu tráfego de saída. 1. Introdução Nos últimos anos tem havido um grande crescimento da participação do tráfego gerado por aplicações peer-to-peer (P2P) no tráfego total observado em redes de tamanhos e características diferentes. Em alguns casos, suspeita-se que o tráfego P2P já represente mais de 2/3 do total, assumindo uma posição que anteriormente era ocupada pelo tráfego Web [9]. Identificar claramente o tráfego P2P é importante para finalidades diversas, como modelar o seu padrão de utilização, identificar aplicações novas e características do tráfego gerado por estas aplicações. Outra linha de utilização destas informações é tomar medidas administrativas, como bloquear ou limitar a vazão deste tipo de tráfego [7] e fazer cache de arquivos P2P para diminuir os custos com enlaces de conexão à Internet.

Embora uma caracterização ampla e completa seja de extrema importância para administradores e projetistas de rede e gestores de TI, ainda não existe uma metodologia ou ferramenta que seja ao mesmo tempo precisa, factível de implementar e apresente um custo aceitável. Um problema são as constantes mudanças de funcionamento das aplicações P2P existentes e o aparecimento de novas aplicações e protocolos. Por exemplo, há cerca de três anos, considerava-se o KaZaA a aplicação P2P mais utilizada. Atualmente, o edonkey tem uma grande participação e o BitTorrent vem apresentando um crescimento constante como será discutido na seção 3.2. Outra motivação para desenvolver pesquisa em medição e caracterização de tráfego P2P é a dificuldade de identificar o tráfego P2P, uma vez que as aplicações P2P de segunda geração não mais utilizam números estáticos de portas. Em geral, aplicações como o KaZaA usam números de portas variados para serem capazes de passar pelo bloqueio de firewall e freqüentemente usam as portas dos serviços bem conhecidos, como 80 (HTTP), 53 (DNS) e 161 (SNMP). Dessa forma, há uma dificuldade de se identificar com precisão o tráfego de aplicações P2P com informações da camada de transporte (número de porta) o que leva à necessidade de analisar a carga útil dos pacotes para identificar as assinaturas das aplicações. A assinatura é um padrão de bits encontrado nas várias mensagens de uma aplicação P2P, que pode ser textual ou binário (em [5] estão definidas algumas assinaturas de aplicações P2P comuns atualmente). Entretanto, a análise da carga útil dos pacotes apresenta problemas tanto para o processamento em tempo real, quanto para o tratamento estatístico posterior das informações de tráfego armazenadas. Observar a carga útil em um enlace de alta capacidade impõe uma grande sobrecarga ao firewall, o que pode prejudicar o desempenho da rede. Por outro lado, armazenar as informações de pacotes para posterior processamento faz com que o volume de tráfego armazenado seja excessivamente grande, mesmo para enlaces de média capacidade e considerando um curto intervalo de tempo. Uma outra conseqüência dessa abordagem é que não podem ser usados arquivos gerados pelo Netflow [8], que gera sumários do tráfego por fluxos de pacotes, baseando-se em informações do cabeçalho. Este artigo apresenta uma análise comparativa do tráfego P2P de duas redes de características diferentes e para diferentes aplicações. O tráfego foi coletado no ponto de presença de Pernambuco (PoP-PE) da Rede Nacional de Pesquisa (RNP) e em um provedor comercial brasileiro de tamanho médio (que neste artigo é chamado de ISP), que concentra principalmente usuários de banda larga. No total, foram analisados 88,25 TB de tráfego de pacotes em um período de 11 meses. Embora tenha sido realizada uma análise posterior com dados armazenados, não foi necessário guardar os traces (arquivos com tráfego) de pacotes, uma vez que o processo adotado identifica o tráfego P2P e depois descarta o pacote, que não precisa permanecer em disco. O estudo considerou onze aplicações P2P de transferência de arquivos, as mais utilizadas, que são: edonkey, KaZaA, BitTorrent, Gnutella, Soulseek, AppleJuice, Direct Connect, Earth, Ares, Mp2p e OpenNap. O restante deste artigo está distribuído da seguinte forma. A seção 2 apresenta alguns trabalhos relacionados. A seção 3 caracteriza os dados de tráfego analisados e descreve o processo utilizado para a coleta e análise do tráfego P2P. Na seção 4 os resultados da análise são apresentados e discutidos, considerando o volume do tráfego P2P, a direção, as portas usadas e o tamanho dos fluxos. Finalmente, a seção 5 apresenta algumas conclusões e apresenta sugestões para trabalhos futuros.

2. Trabalhos Relacionados Em um estudo anterior [1], foi desenvolvido o primeiro estudo sobre o perfil do tráfego P2P na RNP (Rede Nacional de Pesquisa) com o objetivo de avaliar o impacto gerado pelo uso de aplicações em seu backbone. Os dados analisados foram obtidos através de arquivos coletados no formato binário gerados pelo NetFlow [8] no POP de São Paulo. A classificação do tráfego baseou-se na filtragem de portas bem conhecidas utilizadas pelas aplicações. As métricas adotadas objetivavam descrever o comportamento básico do tráfego em termos de volume, vazão e duração dos fluxos. Com isto, através da análise do volume de tráfego por porta, os dados apresentados em [1] revelaram alguns comportamentos anômalos no perfil de tráfego, tais como um maior volume de tráfego associado às faixas de 100KB a 100MB na porta 80 (tradicionalmente utilizada pelo protocolo HTTP). Apesar de não ter precisão quanto à característica dos tipos de fluxos que contribuíam para o crescimento no volume de tráfego naquela porta, este resultado indicava fortemente que as aplicações P2P estivessem também utilizando portas bem conhecidas para transferência de dados. Para obtenção de resultados mais conclusivos, fez-se necessário implantar uma infra-estrutura de medição de tráfego de tal forma que, através da análise da carga útil dos pacotes atravessando alguns pontos de monitoramento, fosse possível confirmar as suspeitas apontadas anteriormente. Em outras palavras, este trabalho estende a análise de tráfego anteriormente realizada através de dados de fluxos, com a avaliação da carga útil de pacotes e classificação das diversas aplicações. Além disso, medições em dois backbones com perfis diferentes (a rede acadêmica RNP e um ISP comercial) e a adoção de um período de coleta muito maior foram utilizados nesta avaliação. Outros trabalhos similares de avaliação de tráfego P2P têm sido apresentados à comunidade científica recentemente. Alguns trabalhos focam sua avaliação na tentativa de extrair um modelo de comportamento de tráfego [4][5], enquanto outros puramente avaliam o perfil de tráfego e sua relação com o tráfego total no ponto de medição [2][3] [6]. Gummadi et al [4] realizaram uma análise criteriosa do tráfego P2P com dados coletados por um período de 200 dias na Universidade de Washington com o objetivo de compreender sua natureza comportamental. Em [2], Karagiannis et al desenvolveram um processo de monitoramento e de identificação de aplicações P2P com precisão de 95% sem a necessidade de análise da carga útil dos pacotes coletados, embora afirmem, baseados nos mesmos argumentos expostos em [1], que a identificação realmente confiável do tráfego P2P, ou seja, com precisão próxima de 100%, requer a análise da carga útil dos pacotes. Além disso, os autores afirmam ainda que as técnicas convencionais de medição (e.g., pelos registros NetFlow) podem subestimar a carga total do tráfego gerado ou dificultar sua identificação devido ao seu comportamento dinâmico (em relação a utilização de portas de serviços conhecidos). Uma conclusão deste trabalho é a confirmação da hipótese de que o tráfego P2P vem crescendo substancialmente em volume. Resultados similares foram relatados pelos mesmos autores em outro trabalho recente [3]. 3. O Processo de Coleta e Avaliação do Tráfego Esta seção identifica a origem e o período de coleta do tráfego e apresenta a metodologia utilizada para coleta, identificação e classificação das aplicações P2P quanto ao volume relativo e a direção do tráfego.

3.1. Descrição do Tráfego Analisado Para esta pesquisa foi analisada uma grande quantidade de informações de tráfego em duas redes com características diferentes: uma acadêmica e outra comercial. A maior quantidade de tráfego foi coletada no ponto de presença de Pernambuco (PoP-PE) da Rede Nacional de Pesquisa (RNP), que no momento da medição possuía um enlace de 34 Mbps com PoP do Rio de Janeiro [11]. Do PoP-PE foi coletado e processada uma quantidade total de 85.28 TB, entre 01 de novembro de 2004 e 30de setembro de 2005. O outro conjunto de informações de tráfego foi obtido pelo mesmo processo em um provedor de acesso comercial brasileiro de tamanho médio (ISP), que em sua base de assinantes concentra principalmente usuários comerciais e residenciais com acesso de banda larga. O ISP possuía no momento da coleta um enlace de 20 Mbps com um grande provedor de backbone brasileiro. No ISP foi coletada e processada uma quantidade total de 2.97 TB, entre 3 de novembro e 1 de dezembro de 2004. Esta pesquisa se iniciou pelo interesse em analisar o comportamento do tráfego P2P no backbone da RNP, como atividade do Grupo de Trabalho em Computação Colaborativa (GT-P2P) [12],[13]. A inclusão do ISP nesta avaliação tem o objetivo de estender a análise e comparar os perfis de utilização de aplicações P2P em duas redes de características distintas. Existem semelhanças e diferenças interessantes entre as duas redes, que corroboram para validar a utilidade de tal comparação. 3.2. Metodologia de Coleta e Análise A metodologia usada neste trabalho se divide em três fases: a) configuração; b) captura de pacotes; e c) produção de fluxos de dados. A primeira fase envolve a instalação e configuração de equipamentos necessários para coleta de pacotes no backbone da rede analisada. Tal como mostrado na Figura 1, utiliza-se um comutador com portas Fast Ethernet e capacidade de espelhamento de portas, que é conectado ao roteador da rede. A porta "espelho" do comutador permite a duplicação do tráfego do backbone (sem perda ou atraso para o tráfego original) para um computador "capturador". A fase de captura consiste na coleta do tráfego por parte do computador "capturador" usando a ferramenta tcpdump de forma passiva e em modo promíscuo. Além disso, somente os 500 bytes iniciais de dados de cada pacote foram armazenados, quantidade suficiente para permitir a caracterização do tráfego de aplicações P2P pela análise da carga útil. Essas informações são armazenadas em arquivos que chamaremos de "coleta bruta". É assumido neste trabalho que o impacto de possíveis perdas de captura por parte do tcpdump é desprezível. A terceira fase da metodologia refere-se ao processamento da "coleta bruta" com a finalidade de identificar os fluxos do tráfego, o qual é considerado como uma seqüência de pacotes com os mesmos valores dos campos endereço IP de origem e destino, porta (TCP ou UDP) de origem e destino. As fases de coleta e processamento são ilustradas na Figura 2.

PoP-RJ PoP-PE Comutador Enlace PDH RJ-PE (34Mbps) UFPE, UFRPE, CEFET-PE, POLI, Pop-Tefé, etc Espelhamento do tráfego Coleta do tráfego Figura 1 - Infra-estrutura de medição de tráfego P2P A identificação e classificação dos fluxos a partir da coleta bruta são feitos por uma ferramenta especialmente desenvolvida em C++, chamada de Analyser-PX. O papel do Analyser-PX é agregar informações para cada conjunto de pacotes capturados, tais como tempo de início e fim do fluxo, endereços IP de origem e destino (considerando-se a direção do fluxo dos pacotes), portas de origem e destino, quantidades de octetos transferidos, total de pacotes, tipo do fluxo (ex: aplicações P2P, web) e classificação do fluxo como de entrada ou de saída. Figura 2 - Fluxo dos dados no processo de medição O Analyser-PX atua periodicamente processando os arquivos de coleta bruta gerados pelo tcpdump e armazena as informações resumidas em fluxos na memória principal. Dessa forma, na medida em que processa periodicamente a coleta bruta o Analyser-PX identifica novos fluxos e os fluxos finalizados, gerando arquivos de resumo e descartando em seguida a coleta bruta analisada 1. Os arquivos de resumo são pós-processados em uma etapa seguinte, que consiste na identificação das aplicações. Existem duas condições para um fluxo ser considerado finalizado. Para fluxos TCP, o recebimento de um pacote com o flag FIN ou o alcance do tempo máximo para recebimento de um pacote que caracteriza a continuação do fluxo. Foi utilizado um tempo máximo de 240 segundos, de acordo com [8]. O processamento termina quando todos os arquivos de trace são processados, ou quando o tempo máximo para processamento de um período é alcançado. 1 A coleta bruta é descartada para garantir o sigilo dos dados e preservar o espaço de armazenamento.

A identificação do tráfego gerado pelas aplicações P2P e sua respectiva classificação foi, portanto, baseada na investigação de parte da carga útil do pacote para verificar a existência de determinadas cadeias de caracteres que são características das aplicações P2P, denominadas assinaturas. Essas assinaturas foram obtidas através do estudo dos trabalhos [7] e [2], ambos relacionados à identificação de tráfego P2P utilizando a carga útil dos pacotes. 4. Resultados da Análise de Tráfego Esta seção apresenta os resultados na análise do tráfego capturado para o PoP-PE e para o ISP. Em todos os resultados, a métrica utilizada é o volume de tráfego, em alguns casos representada como tamanho dos fluxos e em outros como o total de bytes global ou por aplicação. É importante ressaltar que o volume se refere à soma dos tráfegos de entrada e saída, com exceção da seção 0, que explicitamente faz a distinção da direção do tráfego. Apesar de terem sido consideradas dez aplicações de compartilhamento de arquivos, somente edonkey, KaZaA e BitTorrent apresentaram uma quantidade significativa de tráfego e seus resultados são apresentados individualmente. As demais aplicações (Gnutella, Soulseek, AppleJuice, Direct Connect, Earth, Ares, Mp2p e OpenNap) são mostradas com o rótulo Outros P2P. 4.1. Volume de Tráfego por Aplicação A Figura 3 mostra a contribuição de cada aplicação no volume total de tráfego para o período analisado. No PoP-PE a participação de tráfego P2P foi de 63,14% contrastando com o ISP, onde se observou 42,7%. edonkey 40% Web 22% BitTorrent 18% Não P2P 15% Outros P2P 2% KaZaA 3% edonkey 14% Web 31% BitTorrent 19% KaZaA 9% Não P2P 26% (a) PoP-PE (b) ISP Figura 3 Distribuição do tráfego P2P por aplicação no PoP-PE e no ISP Outros P2P 0,4% Esta diferença entre o PoP-PE e o ISP é provavelmente devido à cobrança por tráfego excedente realizada pelo ISP, que leva os usuários a controlarem o uso da banda. Além disso, se percebe claramente que no PoP-PE, a maior quantidade de tráfego P2P é gerado pelo edonkey, que também assume a posição de maior aplicação geradora global de tráfego com 40,47%, superando o tráfego Web, com 22%. No ISP, a maior participação P2P foi do BitTorrent, com 18,9%, enquanto que o tráfego Web foi de 31,3%. Isto representa uma grande mudança de perfil de tráfego em relação a alguns anos atrás, antes da era Napster, quando o tráfego Web ocupava cerca de 75% [9]. Pode-se observar também que, apesar de ter sido identificado o tráfego de onze aplicações P2P diferentes, apenas duas (edonkey e BitTorrent) tiveram uma contribuição significativa no volume de tráfego.

A Figura 4 e a Figura 5 apresentam as informações referentes ao volume de tráfego através de uma série temporal, para 44 semanas do PoP-PE (Figura 4) e 29 dias do ISP (Figura 5). Observe que para a Figura 4, cada ponto nas curvas representa o total de tráfego para uma semana, enquanto a Figura 5, um dia. Nessas figuras, o tráfego normal (não P2P) é identificado pela região mais inferior (preenchida com linhas diagonais), enquanto que as regiões acima dessa área representam o tráfego das aplicações P2P edonkey, BitTorrent, KaZaA e outras aplicações P2P, de baixo para cima, nesta ordem. O volume de tráfego para cada aplicação é proporcional à área visível em cada gráfico, de maneira que o valor de cada ponto representa a soma do tráfego das aplicações representadas nas curvas abaixo dele. 3500 3000 Não P2P edonkey BitTorrent KaZaA Outros P2P Volume de Tráfego (GB) 2500 2000 1500 1000 500 0 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 Semana Figura 4 Evolução do tráfego P2P por aplicação no PoP-PE 200 Não P2P edonkey BitTorrent KaZaA Outros P2P Volume de Tráfego (GB) 150 100 50 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 Dia Figura 5 Evolução do tráfego P2P por aplicação no ISP No PoP-PE (Figura 4), pode-se observar um crescimento consistente do tráfego BitTorrent. Nas últimas semanas, o volume de tráfego BitTorrent superou o edonkey algumas vezes, como pode ser observado no gráfico. Para o ISP (Figura 5), observa-se claramente uma diferença do tráfego nas duas primeiras e duas últimas semanas. A partir do início da semana 3 houve um aumento considerável do tráfego total, que foi principalmente motivado pelo crescimento do tráfego BitTorrent. Segundo o pessoal técnico do ISP, neste período houve testes de carga na rede com o BitTorrent. Portanto, o tráfego não foi efetivamente produzido por

usuários. Isto vem a diminuir inclusive a participação total do tráfego P2P no ISP, que nas duas primeiras semanas situa-se na faixa de 30%. No entanto, também pode ser observado um crescimento do tráfego edonkey, que não foi gerado pela administração do ISP. O ISP possuía um mecanismo de limitação de banda (rate limit) para aplicações P2P, que foi retirado em algum ponto entre a primeira e segunda semana. Isso pode explicar o aumento do tráfego edonkey nas duas semanas finais. 4.2. Tráfego de Entrada e Saída A Figura 6 e Figura 7 mostram, respectivamente, a distribuição de tráfego dividida por entrada e saída para 44 semanas no PoP-PE. Esses gráficos trazem várias observações notáveis. A principal questão é que tipicamente PoPs periféricos são consumidores de tráfego, ou seja, o tráfego de entrada é maior que o de saída. Volume de Tráfego (GB) 1200 1100 1000 900 800 700 600 500 400 300 200 100 0 Total P2P 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 Sem ana Figura 6 Distribuição do tráfego P2P de entrada no PoP-PE da RNP Volume de Tráfego (GB) 2200 2000 1800 1600 1400 1200 1000 800 600 400 200 0 Total P2P 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 Semana Figura 7 Distribuição do tráfego P2P de saída no PoP-PE da RNP No PoP-PE essa era a realidade até algum tempo atrás. No entanto, atualmente o tráfego de saída está maior que o de entrada em muitas horas do dia, principalmente à noite e nos finais de semana. Como mostra a Figura 7, o tráfego P2P é o grande responsável por esta mudança de perfil, isto é, o aumento do tráfego de saída é resultado dos usuários do PoP-PE serem grandes fornecedores de arquivos de aplicações P2P.

4.3. Portas Utilizadas pelas Aplicações P2P Esta seção apresenta uma análise sobre as portas mais usadas pelas aplicações P2P. A primeira geração de aplicações de compartilhamento de arquivos P2P usava portas estáticas, como a bem conhecida 1214 do KaZaA. Devido à facilidade com que eram bloqueadas por firewalls, as aplicações foram adaptadas para usarem qualquer porta aberta (no firewall). Este é o caso das portas dos serviços bem conhecidos, que geralmente estão abertas, porque caso contrário serviços como Web, correio eletrônico e DNS não funcionariam. Por este motivo, uma parcela do tráfego em portas conhecidas, como a 80, é gerada por aplicações P2P (não legítimas naquela porta). O tráfego foi agrupado em dez classes diferentes de portas. Oito classes contendo portas bem conhecidas e duas contendo outras portas inferiores e superiores a 1024. A Tabela 1 apresenta as classes de serviços e as portas correspondentes que foram filtradas e o tráfego agrupado para apresentar os resultados dessa seção. Tabela 1 Classes de serviços bem conhecidos e portas selecionadas Classe Correio SNMP FTP Remoto SMTP HTTPS DNS HTTP Porta 109, 110, 143, 993 161, 162 20, 21 22, 23 25 443 53 80, 8080 A Tabela 2 mostra para o PoP-PE e para o ISP o volume total e relativo (%) de tráfego e o para as dez classes de serviços, separando por tráfego total e P2P. Tabela 2 - Tráfego P2P por porta para o PoP-PE e o ISP Classe PoP-PE ISP P2P (GB) % P2P P2P (GB) % P2P Correio 3.63 2.38 0.00 0.00 SNMP 0.75 6.70 0.01 0.00 FTP 52.26 16.04 0.35 4.14 Remoto 39.51 17.28 0.48 12.89 SMTP 16.18 1.13 0.10 0.20 HTTPS 16.00 2.61 8.44 37.68 DNS 167.13 41.43 0.10 1.46 HTTP 6179.57 28.68 10.22 1.86 <1024 259.17 11.78 1.31 11.64 > 1024 48406.92 80.11 1168.26 55.31 Pode-se observar que, conforme o esperado, as portas maiores que 1024 concentram o maior volume de tráfego P2P. O volume de tráfego P2P observado no em portas acima de 1024 corresponde a 80,11% de todo o tráfego do PoP-PE e a 55,31% de todo o tráfego do ISP. Outra característica importante revelada pela Tabela 2 é que outras classes apresentam uma maior percentual de tráfego P2P do que a classe HTTP. Por exemplo, 41,43 % do tráfego da classe DNS para o PoP-PE e 37.68% do tráfego da classe HTTPS no ISP são, na verdade, tráfego P2P. 4.4. Volume de Tráfego por Tamanho de Fluxo Esta seção apresenta uma visão do tráfego P2P distribuído por faixa de tamanho de fluxo. Foram consideradas 6 faixas de tamanho dos fluxos: menor que 10KB, entre 10KB e 100KB, entre 100KB e 1MB, entre 1MB e 10MB, entre 10MB e 100MB e maior que 100MB. Para cada faixa, as figuras apresentam o volume total de tráfego P2P, com uma distinção por classe de serviço, conforme definido na seção 4.3.

100 Tráfego P2P (%) 80 60 40 <10KB 10KB - 100KB 100KB - 1MB 1MB - 10MB 10MB - 100MB >100MB 20 0 Correio Snmp Ftp Remoto Smtp Https Dns Http <1024 >1024 Portas e serviços Figura 8 Percentual de tráfego P2P por faixa de tamanho de fluxo para o PoP-PE Estes resultados apresentam uma das contribuições mais relevantes deste artigo. Em [1], uma análise de traces Netflow que usa a mesma divisão de faixas, foi observado que havia muito tráfego para portas como 80 e 53 de fluxos com tamanhos acima de 1 MB, levantando a suspeita de que grande parte deste tráfego seria de aplicações P2P. 100 Tráfego P2P (%) 80 60 40 <10KB 10KB - 100KB 100KB - 1MB 1MB - 10MB 10MB - 100MB >100MB 20 0 Correio Snmp Ftp Remoto Smtp Https Dns Http <1024 >1024 Portas e serviços Figura 9 Percentual de tráfego P2P por faixa de tamanho de fluxo para o ISP Pelos resultados da Figura 8 (PoP-PE), pode-se ver claramente que a maior parte do tráfego P2P em portas reservadas a serviços bem conhecidos, como SNMP, SMTP, DNS e HTTP, ocorre em faixas acima de 1MB, onde também corresponde maioria do tráfego. Por exemplo, observando a classe SNMP, pode-se constatar que 100% dos fluxos na faixa superior a 100MB são de tráfego P2P. A Figura 9 mostra os mesmos resultados para o ISP. Neste caso, como já comentado, a única porta bem conhecida mais utilizada foi a 443 e a maioria do tráfego ocorre nas portas acima de 1024. Pode-se observar também que as faixas maiores (e particularmente a faixa acima de 100MB), em geral concentram o maior volume de tráfego. Isso significa que os usuários estão cada vez mais usando as aplicações P2P para obter grandes volumes de dados (filmes ou softwares), cujo tamanho é limitado pelo máximo de um CD ou DVD.

5. Conclusões Nos últimos anos, a popularização das aplicações P2P tem alterado o comportamento do tráfego nas redes. Este estudo, além de avaliar tráfego P2P na RNP (POP-PE), estende o estudo também para uma rede de ISP comercial, para fins comparativos, permitindo constatar diferenças e semelhanças interessantes. Constatou-se que, em geral, o tráfego P2P participa com aproximadamente 60% do tráfego da RNP/POP-PE em média, com predomínio no período da noite e dos fins de semana, quando atinge 80%. Considerando a direção do tráfego, o tráfego P2P corresponde a 36 % do total do tráfego de entrada e 78% do tráfego de saída, com picos próximos de 100%. Na rede do ISP, o tráfego P2P verificado foi em média de 44% do total. Esta diferença no perfil do tráfego do PoP-PE e do ISP provavelmente se dá pelo fato de haver cobrança pelo tráfego excedente pelo ISP, que leva os usuários a controlarem o uso da banda. Em todos os momentos durante a medição, o tráfego P2P de saída superou em muito o tráfego de entrada. A conseqüência mais importante disso é o aumento do tráfego total de saída do PoP-PE. Este trabalho mostra que o principal responsável pelo aumento do tráfego de saída do POP-PE é o tráfego P2P. Esta tendência pode quebrar o paradigma de que o PoP-PE é tipicamente consumidor de tráfego, que possui enlaces de capacidade assimétrica justamente pela tradicional característica assimétrica do tráfego, podendo forçá-la a rever o seu planejamento e atualizações da rede. Este problema não foi identificado no tráfego do ISP, uma vez que eles possuíam um mecanismo de limitação de banda (rate limit) para aplicações P2P. Com relação às aplicações P2P, constatou-se que o edonkey é o maior gerador de tráfego no POP-PE com 40% do tráfego total, superando o tráfego Web, com 22%. No ISP, o BitTorrent foi responsável 19%, enquanto que o tráfego Web foi de 31%. Ambas as observações ratificam a grande mudança de perfil de tráfego em relação há alguns anos atrás, antes da era Napster, quando o tráfego Web ocupava cerca de 75% e confirmam a redução do domínio do KaZaA e crescimento do edonkey e do BitTorrent. Em trabalhos anteriores, foi identificada a existência de fluxos com tamanho desproporcional para serviços bem conhecidos (e.g. fluxos de 100MB para DNS ou HTTP). A análise da carga útil dos pacotes, feita nesta pesquisa, revelou que o tráfego P2P realmente se disfarça de tráfego legítimo de serviços bem conhecidos, sendo as portas 80 (HTTP) e 443 (HTTPS) as que registraram o maior volume de tráfego P2P. Entretanto, as portas maiores do que 1024 realmente concentram o maior volume de tráfego, com 88% do tráfego P2P no POP-PE e 98% no ISP. Como continuação deste trabalho, pretende-se analisar o tráfego P2P de outros PoPs e ampliar o tempo de coleta e refinar a análise para o tráfego ISP. Alguns trabalhos muito recentes (como [14]) já prospectaram a presença de tráfego malicioso, em função da grande explosão do uso (indevido) desse tipo de aplicação nos últimos anos. Uma análise desse tipo de tráfego pode ser considerada em trabalhos futuros para as redes acadêmica e comercial. 6. Agradecimentos Os autores agradecem à RNP e ao ISP pelo suporte a esta pesquisa.

7. Referências [1] Fernandes, S., Kamienski, C. A., Silvestre, G., Rocha, J., Dias, K., Sadok, D. Análise de Tráfego P2P no Backbone da RNP, Anais do 22o. Simpósio Brasileiro de Redes de Computadores 2004, Gramado/RS, Maio 2004. [2] Karagiannis, T., Broido, A., Brownlee, N., Kc claffy, Transport Layer Identification of P2P Traffic, ACM Internet Measurement Conference 2004, Outubro 2004. [3] Karagiannis, T., Broido, A., Brownlee, N., Kc claffy & Faloutsos, M., Is P2P dying or just hiding?, IEEE Globecom 2004, Novembro/Dezembro 2004. [4] Krishna P. Gummadi, Richard J. Dunn, Stefan Saroiu, Steven D. Gribble, Henry M. Levy, and John Zahorjan, Measurement, Modeling, and Analysis of a Peer-to-Peer FileSharing Workload, 19th ACM Symposium on Operating Systems Principles, October 2003. [5] S. Sen, O. Spatscheck, and D. Wang. Accurate, Scalable In-Network Identification of P2P Traffic Using Application Signatures. In WWW, 2004. [6] S. Sen and J. Wang. Analyzing Peer-to-Peer Traffic Across Large Networks. In ACM IMW 2002. [7] IPP2P Project - A NetFilter extension to identify P2P filesharing traffic, http://www.ipp2p.org/index_en.html, acessado em 17/12/2004.. [8] CISCO NetFlow, http://www.cisco.com/warp/public/732/tech/nmp/netflow. [9] Thompson, K., Miller. G. J., & Wilder, R., Wide-Area Internet Traffic Patterns and Characteristics, IEEE Network, Novembro/Dezembro 1997. [10] RNP, Estatísticas de tráfego no backbone da RNP2, http://www.rnp.br/ceo/trafego acessado em 17/12/2004. [11] RNP, Mapa do backbone RNP2, http://www.rnp.br/backbone/, acessado em 17/12/2004. [12] GT P2P RNP, Grupo de Trabalho de Computação Colaborativa da RNP GT P2P, http://www.cin.ufpe.br/~gprt/gtp2p, acessado em 18/12/2004. [13] Computação Colaborativa (P2P) - Fase II, http://www.rnp.br/pd/gts2004-2005/p2p.html, acessado em 18/12/2004. [14] Stefan Saroiu, Steven D. Gribble, and Henry M. Levy. Measurement and Analysis of Spyware in a University Environment. Proceedings of the 1st Symposium on Networked Systems Design and Implementation (NSDI), San Francisco, CA, 2004.