P2P criptografado, um novo desafio!

Não sei, de vocês mas acho que controlar P2P é falta de respeito com o cliente, já que ele contrata a velocidade por exemplo 500Kbps, e faz download em p2p a 15kbps, 5kbps.
Primeiro acho isso ilegal, e segundo desrespeito para com o usuario.
Se estamos provendo o serviço nada melhor do que prover o serviço com qualidade. entrega a banda do cara ele que se exploda se não conseguir navegar e ligar enchendo o saco, ae fala para ele desligar, o P2P.
Mas veja bem isso em para quem controla P2P em provedor, não para uma empresa que tem sua banda limitada e tem usuarios detonando a rede com p2p, nesse caso só a favor até do bloqueio do P2P.

Bom essa é minha opnião. e acho que isso vai dar uma discussão boa.

O caso nao é bloqueio de p2p nem controlar a baixo do contratado, e sim limitar os sockets dos p2p para nao detonar com a rede.

Citação:

Postado originalmente por GrayFox

O caso nao é bloqueio de p2p nem controlar a baixo do contratado, e sim limitar os sockets dos p2p para nao detonar com a rede.

Justamente, e esse é o grande problema. O tráfego P2P é um veneno para qualquer rede, tanto que se o contrário fosse não existira ninguém trabalhando em ferramentas para contê-los.

O que o Patrick mencionou sobre o SFQ é uma opção uma vez que requer pouco uso da CPU e RAM, além dos algorítimos estocásticos usados na política SFQ priorizarem os pacotes de acordo com configurações, descartando, assim, os demais no caso de saturação no roteador.

Se não controlar o p2p, é humanamente impossível trabalhar em redes wireless. Não se trata de bloquear, mas de manter o p2p e a rede funcionando com qualidade.

Seguinte pessoal, eu andei monitorando aqui o tráfego da minha rede, e notei que o access log do meu squid começou a mostrar uma quantidade muito grande de: " error:unsupported-request-method"....

Fui atrás e percebi que isso tava acontecendo porque os softwares de p2p criptografados estava tentando a conexão pela porta 80, porém os headers dos pacotes não eram compatíveis com o protocolo HTTP, que é o que o squid espera e o cliente não consegue conectar na rede p2p, tendo que desconfigurar a opção de criptografia. Assim, então, voltam a sofrer o traffic shapping através do layer7 e do ipp2p.

Quanto ao SFQ, seu objetivo é trabalhar na alocação/distribuição da banda de forma justa...mas a maneira como ele é implementado a distribuição da banda ainda se torna "unfair", visto que clientes com um número maior de requisições / conexões conseguem ter mais banda alocada do que clientes com poucas conexões.

Para solucionar esse problema, foi criado um patch para o kernel e para o iproute, chamado ESFQ (Enhanced SFQ), onde se faz a alocação de banda por IP, e não por conexão.

ESFQ for Linux 2.6

Eu compilei e tô usando ele aqui...a diferença é muito grande...melhore e muito na equalização do compartilhamento da banda...