CA BRIDE AUSSI POUR LES DEGROUPES...
Je ne comprends pas que personne ne parle du bridage du Peer2peer concernant les abonnés dégroupés.
Dès que je lance eMule, et avant même tout transfert, ma bande passante chute de 1500 Ko/s à 500-700 Ko/s (tests grenouille et test console Free).
Ainsi, bien que j'ai limité eMule à 10 Ko/s UL et 100 Ko/s DL, je perds d'un coup entre la moitié et les 2/3 de mon débit descendant.
Le bridage NE CONCERNE DONC PAS QUE LES NON DEGROUPES.
(vérification de ces chutes de débits chez deux autres abonnés dégroupés sur Marseille)
alors ça c'est parfaitement faux et si on était méchant on pourrait qualifier ça de grosse diffamation. Apprend à configurer un logiciel de A à Z ou reviens avec des preuves irréfutables de ce que tu avances ; en l'état, la situation de bridage ne concerne que les ND (et c'est déjà bien trop comme ça).
Je viens de m'inscrire (enfin ;-) ) pour répondre à ce post, désolé je n'ai pas encore lu la suite...
Je voulais simplement confirmer Aotus, je suis dégroupé et j'ai déjà remarqué un bridage...
C'est arrivé une seule fois, il y à quelques jours :
- lancement de la mule (highID, plage de ports aléatoires, & co)
- attente de 30/40 mins (ça grimpe à ~120ko/s sur une capacité de 220ko/s)
- chute du download à ~30ko/s (28, mais avec l'overhead & les ack ça dois être 30ko/s tout pile)
- je reboote FBX & routeur, au cas où, je baisse le nombre de connexions pour être sur que la table NAT ne sature pas (ce qui n'est jamais arrivé)...
- je relance la mule... limitation directe à 30ko/s (genre une première source à 25ko/s, puis une deuxième, les deux passent à ~14ko/s chacunes.... équilibrage sur la BP allouée par le bridage)
- ~10h aprés, le bridage était débloqué, c'est remonté direct à 200ko/s
Mais j'ai remarqué ceci une seule fois, je ne suis évidemment pas souvent devant la fenètre de la mule, elle même n'est pas souvent en fonction (tout du moins pour les downloads) mais le bridage était flagrant, même amusant avec des dents de scie par moment.. on à le droit a un peu plus pendant un trés court instant, et juste aprés on retombe presque à zéro, la moyenne semblant être au alentour de 30ko/s... toujours ^^
Mais avec le bridage actif, les test de débits sur différentes applications (HTTP, HTTPS, FTP et POP3) m'on permis d'atteindre à chqque fois sensiblement 190ko/s (220-30 ^^). bref, le filtrage semble bien être au niveau application, peut être avec ce système :
http://l7-filter.sourceforge.net/layer7-protocols/protocols/edonkey.pat qui repose sur l'analyse des données des paquets, indépendament du port.
Je me posent donc deux questions :
- Le filtrage applicatif, qui repose donc sur l'analyse de la correspondance des données qui transitent est-elle légale, ne s'agit t'il pas de données privée (les données d'un packet pouvant tout à fait être le contenu d'un mail par exemple)
- Si le filtrage est bien effectué avec l'application dont j'ai donné un lien ci-dessus (ou même un autre système, le risque existe), il semble que 2% des données interceptées comme étant du p2p (sur le edonkey) ne le sont pas... mais se verront tout de même appliquer le QOS... si il s'agit juste d'une limitation de bande passante, ce n'est pas un problème, mais si le réseau est fortement engorgé et que la régle de traitement de ces données est plus sévère (un refus pur est simple), cela peut supposé que certaines applications, dans certaines conditions, puissent ne pas fonctionner correctement malgrés qu'elles ne soit pas concernées (tout type d'applications tranmettant des flux binaires, tel que de la video ou du son, par exemple, peuvent générer une trame correspondant à un packet edonkey, de manière aléatoire).
Bon, ça c'est surtout du blabla, tout ce que j'ai dis ici n'est basé essentiellement que sur quelques heures de bridage auquel j'ai été soumis, mais d'ici la rentrée scolaire je vais avoir a prendre un abonnement dans une zone non dégroupée par free... et ce petit aperçu me laisse songeur...
codidex.