Auteur Sujet: Wehe: Une appli pour tester le débit port par port et la neutralité d'Internet (Lu 25642 fois)

Marco POLO · « **Réponse #36 le:** 24 décembre 2020 à 17:35:26 »

Citation de: hwti le 24 décembre 2020 à 15:52:36

Pourtant ils ont http://test-debit.free.fr/ (certes limité au http).

Personnellement, lorsque je clique sur ce lien, j'obtiens la réponse suivante:

Citer

Forbidden
You don't have permission to access this resource.

hwti · « **Réponse #37 le:** 24 décembre 2020 à 17:57:09 »

Citation de: Marco POLO le 24 décembre 2020 à 17:35:26

Personnellement, lorsque je clique sur ce lien, j'obtiens la réponse suivante:

Tu dois avoir une extension comme "HTTPS Everywhere" qui essaye de charger https://test-debit.free.fr/ (qui répond, mais "You don't have permission to access this resource.") au lieu de http://test-debit.free.fr/.

xp25 · « **Réponse #38 le:** 24 décembre 2020 à 18:03:52 »

Voilà ce qu'on doit voir

Marco POLO · « **Réponse #39 le:** 24 décembre 2020 à 18:15:37 »

Citation de: hwti le 24 décembre 2020 à 17:57:09

Tu dois avoir une extension comme "HTTPS Everywhere" qui essaye de charger https://test-debit.free.fr/ (qui répond, mais "You don't have permission to access this resource.") au lieu de http://test-debit.free.fr/.

Excellent diagnostic, sauf qu'habituellement, après près d'une minute, elle me demande la permission pour accéder au http.

Free_me · « **Réponse #40 le:** 24 décembre 2020 à 18:34:09 »

Citation de: hwti le 24 décembre 2020 à 17:57:09

Tu dois avoir une extension comme "HTTPS Everywhere" qui essaye de charger https://test-debit.free.fr/ (qui répond, mais "You don't have permission to access this resource.") au lieu de http://test-debit.free.fr/.

mamamia quelle horreur

Nico_S · « **Réponse #41 le:** 24 décembre 2020 à 18:55:36 »

Citation de: vivien le 24 décembre 2020 à 14:40:32

Nico_S, j'ai déjà eu ça avec un opérateur qui bridait le port 443 après un certain volume échangé.

Dans ce cas là, tous les autres ports sont en différentiation, vu que le port 443 est la référence.

Dans ton cas c'est étonnant d'avoir un tel traitement sur un réseau fixe.

C'est reproductible ?

C'est vérifiable avec d'autres serveurs ?

nPerf permet de faire des tests sur le port 8443 et 443 (le problème c'est que c'est mal indiqué)

Liste des ports par serveur :

Je viens de partir du bureau, je testerai quand j'y serai, sans doute pas demain mais peut-être samedi ou dimanche.

alarig · « **Réponse #42 le:** 25 décembre 2020 à 21:57:23 »

C’est dommage, y’a pas de version f-droid

eahlys · « **Réponse #43 le:** 25 décembre 2020 à 22:54:18 »

Citation de: vivien le 24 décembre 2020 à 15:36:15

Free (enfin, il parait de source fiable que c'est Rani) ne souhaite pas héberger de serveur de test de débit, car cela charge le réseau.

J'ai jamais rien entendu d'aussi drôle sur Free, c'est sûr que quand le simple trafic de leurs abonnés sature les peerings/intercos faudrait pas ajouter du serveur de test de débit en plus hein...

Nico_S · « **Réponse #44 le:** 26 décembre 2020 à 12:10:08 »

Citation de: vivien le 24 décembre 2020 à 14:40:32

Nico_S, j'ai déjà eu ça avec un opérateur qui bridait le port 443 après un certain volume échangé.
Dans ce cas là, tous les autres ports sont en différentiation, vu que le port 443 est la référence.
Dans ton cas c'est étonnant d'avoir un tel traitement sur un réseau fixe.

C'est reproductible ?

C'est vérifiable avec d'autres serveurs ?

nPerf permet de faire des tests sur le port 8443 et 443 (le problème c'est que c'est mal indiqué)

Liste des ports par serveur :

C'est reproductible en effet sur tous les ports de test de Wehe
C'est vérifiable sur d'autres serveurs suivant ton tableau sur Nperf.

Qu'en penser ? Je gueule auprès de mon FAI ? J'imagine que ce n'est pas lié au Firewall de notre routeur qui laisserait soit passer, soit pas passer, mais pas passer à 30% ?

J'ai joint 6 copies d'écran de test sur Nperf. 3 depuis ma connexion fixe (Lasotel 100/100 fibre) et 3 depuis mon partage de connexion Free Mobile en 4G.
Mêmes serveurs pour les deux connexions bien entendu.

Nico_S · « **Réponse #45 le:** 26 décembre 2020 à 16:14:43 »

Je réponds à mon message précédent (sans le modifier pour la clarté).

Je viens de changer de routeur, chose que je voulais faire depuis longtemps, pour passer d'un CISCO RV110W (fourniture FAI) à un Ubiquiti USG 3P.
Je viens de refaire les mêmes tests depuis l'application Wehe et je n'ai bizarrement plus de différence avec le port 443 qui monte à 70Mbps sans souci.
Idem sur Nperf avec un des 3 serveurs précédent (Lyon) ou le "bridage" n'est plus d'actualité.

Une idée du pourquoi ?

vivien · « **Réponse #46 le:** 27 décembre 2020 à 14:30:48 »

Citation de: Nico_S le 26 décembre 2020 à 16:14:43

Je viens de changer de routeur, chose que je voulais faire depuis longtemps, pour passer d'un CISCO RV110W (fourniture FAI) à un Ubiquiti USG 3P.

Donc ton routeur CISCO RV110W semble brider le débit à 20 Mb/s symétrique sur le port 443, alors que les autres ports semblent ne pas avoir de limitation (100 Mb/s symétrique)

Et voici la cause probable de la limitation à 20 Mb/s :

Citation de: vivien le 06 juin 2011 à 09:39:07

Voici la réponse du chef de projet de CPE FTTH Sagem le 31 juillet 2006 :

Explication des performances non satisfaisantes vues sur un téléchargement HTTP.

Fonctionnement des Accélérateurs:
Lorsque l'utilisateur lance un téléchargement TCP/UDP, les premiers paquets qui sont responsables de l'établissement de la connexion passent par le CPU(chemin classique :NAT/FIREWALL/policies...), une fois le lien est établie tous les prochains paquets passeront par les accélérateurs (chemin rapide). Les accélérateurs n'analyse que l'entête TCP/IP du paquet et pas son contenue.

Cas d'un transfert de texte par MSN MESSENGER:
Lorsque un client utilise MSN MESSENGER pour chatter se dernier se connecte sur le port 1863/TCP à un serveur de chez Microsoft. dans ce cas le Nat est traversé proprement et le message retour est bien identifié par le Firewall du F@st3374.

Cas d'un transfert de vidéo par MSN MESSENGER :
Les problèmes arrivent lorsque le client demande une connexion vocale/video. Dans ce cas, MSN MESSENGER va demander au serveur de choisir un autre port pour faire passer le flux vidéo. Et le problème c'est que ce port est choisie au hasard entre le port TCP/9000 et TCP/65535. Pour que le flux
vidéo provenant du serveur soit identifier par le firewall du F@st3374 et qu'il soit forwardé correctement, tous les paquets msn( TCP et destPort/srcPort = 1863) passeront par une fonction de traitement supplèmentaire qui permet d'analyser les contenues des paquets en plus de leurs entêtes TCP/IP.
Dans ce cas le flux vidéo passera par les accélérateurs(chemin rapide) mais tous les paquets msn(TCP-port =1863) passeront par le CPU(chemin classique).

Cas du port 80:
Si pour une raison ou pour une autre le MSN MESSENGER n'arrive pas à se connecter au serveur Microsoft sur le port 1863 alors il retombe sur le port 80 en faisant du HTTP tunneling. Affin de supporter ce cas bien particulier le F@st3374 fait passer touts les paquets HTTP(port 80) par le même chemin par lequel passe les paquets msn (port 1863).

Solution immédiate :
Ne supporter que le chat en mode texte dans le cas où le client MSN MESSENGER fait du backup sur le port 80. Et si dans ce cas particulier l'utilisateur veut faire du Chat en mode vidéo il doit installer UPNP sur son poste qui va s'en charger de communiquer avec le Firewall du F@st3374 pour ouvrir les bons ports.

Je reste à votre disposition pour tout éclaircissement supplèmentaire.

Cordialement.

A noter que le même phénomène est utilisé sur le port 21 pour le FTP.

Note : Les box équipées de Watchdog reboot lors d'un transfert HTTP à 20 Mb/s ou plus, le CPU étant utilisé à 100%, le watchdog est là pour rétablir la situation via un reboot

Nico_S · « **Réponse #47 le:** 27 décembre 2020 à 14:47:37 »

Donc en gros le CISCO est un routeur archaïque d'un point de vue hardware ?
Il faudrait que je vois ce que donne l'utilisation processeur du Cisco lorsque je lance un Nperf sur le 443, mais comme je l'ai viré pour mettre l'USG à la place je ne vais pas tout remonter pour faire un test (enfin je verrai si je n'ai rien à faire le WE prochain ou un soir après les fêtes).

Par contre pour rester dans le sujet de départ, peut-on en déduire que les résultats sont faussés suivant le matériel en tête du réseau local (routeur) et que le résultat n'ets pas forcément représentatif ?
Dans mon cas c'est assez flagrant.