La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
OS mobile (Android, iOS,...) => Discussion démarrée par: vivien le 23 décembre 2020 à 21:04:22
-
Wehe : Une application pour tester le débit port par port et la neutralité d'Internet
(https://lafibre.info/testdebit/android/202012_logo_wehe.png)
Cette nouvelle application permet de tester le débit avec un flux https sur plusieurs ports populaires :
- Port 80 (trafic http, mais le test de débit sera réalisé en https sur ce port)
- Port 81 (http alternatif, test de débit réalisé en https)
- Port 443 (port de référence, c'est le port le plus utilisé sur Internet)
- Port 465 (SMTPS pour l’envoi de courriels)
- Port 853 (DoT - DNS over TLS, un concurrent à DoH - DNS over HTTPS (https://lafibre.info/navigateurs/doh-usa/). DoH ayant l'avantage d'utiliser le port 443, alors que le port 853 de DoT peut se faire bloquer)
- Port 993 (IMAPS pour la consultation de courriels)
- Port 995 (POP3S pour la récupération de courriels)
- Port 1194 (OpenVPN)
- port 1701 (pour la mise en place d'un L2TP - Layer 2 Tunneling Protocol)
- Port 5061 (trafic SIPS pour la téléphonie)
- Port 6881 (BitTorrent)
- Port 8080 (SpeedTest d'Ookla)
- Port 8443 (nPerf / 5GMARK / DébitTest 60 / NetgMark ZD-Net)
Le débit sur chaque port est comparé au débit du port de référence, le port 443 https.
Une différentiation est remontée si le débit est sensiblement plus faible ou plus important que le port de référence.
Ces différences peut être lié à une baisse de débit, les deux ports étant testé à quelques secondes d’intervalle, il faut donc relancer le tests au moins trois fois quand il y a différentiation pour pouvoir avoir une forte présomption de priorisation ou dé-priorisation d'un port.
Petit extrait du communiqué de presse :
L’Arcep lance une nouvelle version de l’application Wehe, pour détecter les bridages de flux et de ports internet
Le règlement européen sur l’internet ouvert impose un traitement égal et non discriminatoire du trafic par les fournisseurs d’accès à internet. En charge de contrôler le respect des obligations issues de ce règlement, l’Arcep analyse les pratiques liées à la gestion des flux de trafic sur internet par les fournisseurs d’accès à internet.
Développé par la Northeastern University de Boston et fondé sur un code en open source, Wehe analyse le trafic généré via l’application, notamment pour déterminer si l’opérateur est susceptible de brider ou de prioriser certains flux de trafic. Le test s’effectue en deux étapes. Premièrement, l’outil simule l’utilisation d’un service dans le réseau d’un FAI afin de mesurer comment celui-ci traite le trafic réel issu de ce service. Deuxièmement, l’outil simule à nouveau le même trafic mais en remplaçant le contenu par un contenu chiffré invisible pour le FAI. En cas de dissemblance entre les deux simulations, il est possible de soupçonner l’existence d’une mesure de gestion de trafic mise en œuvre par le FAI.
La nouvelle version de Wehe permet de tester de nouveaux services et de détecter des blocages de ports logiciels.
(https://lafibre.info/testdebit/android/202012_wehe_fonctionnement_2.png)
L’application met aussi à disposition des utilisateurs un test de ports, dont les éventuels blocages, bridages ou priorisations pourraient affecter les modalités d’accès à certains services en ligne par les utilisateurs. Les utilisateurs ont ainsi la possibilité de contrôler 12 ports logiciels, parmi les plus fréquemment utilisés. Techniquement, le test de ports compare le trafic https pour chacun des ports sélectionnés par l’utilisateur en le rapportant au trafic sur le port 443, défini comme port de référence.
En cas de dissemblance avérée, les utilisateurs sont invités à relayer leurs difficultés directement via la plateforme « J’alerte l’Arcep (https://jalerte.arcep.fr/) », afin que l’Autorité puisse examiner au cas par cas les éventuelles incompatibilités avec le règlement internet ouvert. Wehe s’inscrit dans la démarche de régulation par la donnée de l’Arcep, qui a fait l’objet d’un premier bilan après 5 ans de mise en œuvre le 8 décembre dernier (voir le communiqué du 8 décembre 2020)
L’Arcep invite également les acteurs de l’écosystème à faire part de leurs éventuels retours d’expérience sur cette nouvelle fonctionnalité.
-
On a besoin de vos retours :
- Pour identifier des acteurs qui proposent un internet non neutre. Ne pas hésiter à tester restaurent, hôtels ou moyens de transports : eux aussi doivent proposer un internet neutre.
- Pour identifier les bugs de l'application.
Pour tout vous dire, cela fait de nombreux mois que l'application est testée en interne Arcep, via un petit serveur OVH. Pour la prod, on est passé sur un réseau de serveurs avec M-Lab (https://www.measurementlab.net) et d'autres acteurs et on a noté des erreurs "Serveur inaccessible" au dernier moment. On a décidé de lancer quand même l'application, mais il faut être indulgent et ne pas hésiter à nous remonter quand cette erreur apparaît.
Wehe est disponible sur Android (Lien vers le Google Play (https://play.google.com/store/apps/details?id=mobi.meddle.wehe&hl=fr) - copie d'écran à gauche) et iOS (Lien vers l'App Store (https://apps.apple.com/fr/app/wehe/id1309242023) - copie d'écran à droite) :
(https://lafibre.info/testdebit/android/202012_wehe_android.png) (https://lafibre.info/testdebit/android/202012_wehe_ios.png)
-
Quelques copies d'écran de Wehe
À gauche Android, à droite iOS.
Voici le menu au lancement de Wehe. Le test de port se lance en appuyant sur "Tests de ports"
(https://lafibre.info/testdebit/android/202012_wehe_android_1.png) (https://lafibre.info/testdebit/android/202012_wehe_ios_1.png)
Trois ports sont aléatoirement sélectionnés, choisissez ceux que vous souhaitez tester et la taille du fichier de test : 10 Mo ou 50 Mo.
(https://lafibre.info/testdebit/android/202012_wehe_android_6.png) (https://lafibre.info/testdebit/android/202012_wehe_ios_4.png)
-
Le test dure approximativement une minute par port.
Les résultats apparaissent au fur et à mesure :
(https://lafibre.info/testdebit/android/202012_wehe_android_7.png) (https://lafibre.info/testdebit/android/202012_wehe_ios_5.png)
En cas de différentiation, vous pouvez cliquer sur le lien « J’alerte l’Arcep (https://jalerte.arcep.fr/) » afin de déposer une alerte, toutefois nous vous invitons à ne le faire qu'aprés avoir fait au moins deux fois le test du port en question, afin de s'assurer de la fiabilité du résultat.
Vous êtes également invité à partager vos résultats sur ce forum.
(https://lafibre.info/testdebit/android/202012_wehe_android_8.png) (https://lafibre.info/testdebit/android/202012_wehe_ios_6.png)
-
Wehe : tests applicatifs ou DPI
WeHe sait toujours réaliser des tests pour voir si un DPI (Deep packet inspection (https://fr.wikipedia.org/wiki/Deep_packet_inspection)) bride le débit en fonction du SNI renvoyé par votre navigateur.
=> Encrypted SNI où la fin de la surveillance d'internet / bridage DPI (https://lafibre.info/cryptographie/encrypted-sni/)
Le rapport explique que le DPI (Deep packet inspection) est interdit, même pour catégoriser le trafic :
Extrait de la page 66 (https://lafibre.info/images/doc/202006_arcep_rapport_etat_internet_2020.pdf#page=66) : Le règlement Internet ouvert permet aux FAI d’accéder qu’aux informations contenues dans l’en-tête du parquet IP et dans l’en-tête du protocole de la couche transport (par exemple l’en-tête TCP ou l’en-tête UDP) dont les noms de domaine et URL sont exclus. Par ailleurs, dans une lettre rendue publique (https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_letter_out2019-0055_berecnetneutrality2.pdf), le Comité européen de la protection des données (EDPB) qui a été saisi pour avis, précise que le nom de domaine et l’URL peuvent être qualifiés de données à caractères personnels et à ce titre sont protégées par les dispositions de la directive vie privée et communications électroniques et du règlement général sur la protection des données. Ainsi, les FAI qui utiliseraient le nom de domaine ou les URL à des fins de catégorisation de trafic ou de facturation s’exposeraient non seulement à une violation potentielle du règlement internet ouvert, mais aussi à une possible violation de la protection des données à caractère personnel de leurs clients.
(https://lafibre.info/images/doc/202006_arcep_rapport_etat_internet_2020_4_neutralite_2.png)
La liste des services testés par la fonction de test de différenciation de flux a été étendue et intègre désormais plusieurs services de visioconférences et différentes plateformes françaises de streaming vidéo, reflétant ainsi au mieux les usages des utilisateurs français.
(https://lafibre.info/images/doc/202006_arcep_rapport_etat_internet_2020_4_neutralite_3.png)
Attention, Wehe ne teste pas les serveurs d'origine de l'application : Le test est réalisé en rejouant un contenu enregistré à l'avance, en prenant un abonnement comme n'importe quel client.
Wehe va tester en jouant le flux pré-enregistré depuis un serveur Wehe avec le SNI original et le même flux en modifiant le contenu des paquets, de sorte que un DPI ne sera pas en mesure de reconnaître le flux.
(https://lafibre.info/testdebit/android/202012_wehe_fonctionnement_1.png)
Captures Wireshark des flux de références joués par Wehe : (Wireshark est nécessaire pour lire les fichiers)
Pour Amazon prime vidéo, c'est un de ces deux flux qui est joué :
Amazon Prime Vidéo "Les héritiers de la nuit" CDN Akamai (https://lafibre.info/images/wireshark/202011_amazon_prime_akamai_396p.pcapng.gz)
- Capture du 12/11/2020 : 19 Mo, 66 secondes, 1 connexion https, TLS 1.2
- Firefox 82, sous Ubuntu 20.10, noyau Linux 5.8
Amazon Prime Vidéo "This Is Us" CDN Amazon (https://lafibre.info/images/wireshark/202011_amazon_prime_amazon_cdn_396p.pcapng.gz)
- Capture du 12/11/2020 : 15 Mo, 69 secondes, 1 connexion https, TLS 1.3
- Firefox 82, sous Ubuntu 20.10, noyau Linux 5.8
Dailymotion 1080p (https://lafibre.info/images/wireshark/201909_dailymotion_1080p.pcapng.gz)
- Capture du 19/09/2019 : 80 Mo, 67 secondes, 1 connexion https, TLS 1.2
- Firefox 69, sous Ubuntu 19.04, noyau Linux 5.0
Molotov TV flux live 1080p (https://lafibre.info/images/wireshark/201908_molotovtv_live_1080p.pcapng.gz)
- Capture du 05/08/2019 : 55 Mo, 63 secondes, 1 connexion https, TLS 1.2
- Client Molotov TV pour Linux au format Appimage sous Ubuntu 19.04, noyau Linux 5.0
My Canal profil à 3400 Kb/s (720p ?) (https://lafibre.info/images/wireshark/201910_mycanal_3400kbps.pcapng.gz)
- Capture du 04/10/2019 : 55 Mo, 70 secondes, 2 connexions https, TLS 1.2
- Firefox 69, sous Ubuntu 19.04, noyau Linux 5.0
SFR Play VoD 1080p (https://lafibre.info/images/wireshark/201908_sfr_play_vod_1080p.pcapng.gz)
- Capture du 05/08/2019 : 37 Mo, 70 secondes, 4 connexions https (successives pas en //), TLS 1.2
- Firefox 68, sous Ubuntu 19.04, noyau Linux 5.0
Salto - série Fargo "S2 E8 Sioux Falls" - Résolution 960x540 (https://lafibre.info/images/wireshark/202011_salto_replay_540p.pcapng.gz)
38ème seconde : clic sur ignorer l'introduction
- Capture du 24/11/2020 : 31 Mo, 68 secondes, 1 connexion https, TLS 1.3
- Firefox 83, sous Ubuntu 20.10, noyau Linux 5.8
OCS Replay 1080p (https://lafibre.info/images/wireshark/201908_ocs_replay_1080p.pcapng.gz)
- Capture du 05/08/2019 : 27 Mo, 65 secondes, 6 connexions https (successives pas en //), TLS 1.2
- Firefox 68, sous Ubuntu 19.04, noyau Linux 5.0
Deezer (audio) 320 Kb/s (https://lafibre.info/images/wireshark/201909_deezer_320kbps.pcapng.gz)
- Capture du 19/09/2019 : 12 Mo, 59 secondes, 1 connexion https, TLS 1.3
- Firefox 69, sous Ubuntu 19.04, noyau Linux 5.0
-
Quelques copies d'écran de Wehe pour les tests applicatifs
À gauche Android, à droite iOS.
Le test de port se lance en appuyant sur "Tests de différenciation" depuis le menu.
(https://lafibre.info/testdebit/android/202012_wehe_android_2.png) (https://lafibre.info/testdebit/android/202012_wehe_ios_2.png)
Le débit n'est pas le débit maximum de votre connexion, mais le débit maximum du flux enregistré.
Il varie donc en fonction des applications et est particulièrement faible pour des application de téléphonie.
Cela permet d'être au plus proche, le débit pouvant jouer dans les choix du DPI.
(https://lafibre.info/testdebit/android/202012_wehe_android_3.png) (https://lafibre.info/testdebit/android/202012_wehe_ios_3.png)
-
Les copie d’écran ci-dessous sont uniquement réalisées avec Android, mais on retrouve l'équivalent sous iOS :
(https://lafibre.info/testdebit/android/202012_wehe_android_4.png) (https://lafibre.info/testdebit/android/202012_wehe_android_5.png)
-
Quand une différentiation est détectée ou quand il y a un résultat non concluant, il y a un (i) en haut à droite du test.
Il faut cliquer dessus pour avoir plus d'information
(https://lafibre.info/testdebit/android/202012_wehe_android_9.png)
En fin de test, il propose de relancer uniquement les tests où il y a eu une différentiation.
N’hésitez pas à faire deux ou trois tests pour être sur qu'il y a bien une différentiation.
(https://lafibre.info/testdebit/android/202012_wehe_android_10.png)
-
Si vous tombez sur un résultat non concluant, je suis intéressé pour savoir quand c'est survenu et pourquoi, tout comme la différentiation.
Le message dans le (i) est important.
A gauche, le trafic a été bloqué quel que part à droite, le bug de "Serveur inaccessible" qui est arrivé suite à la mise en prod de nombreux serveurs.
(https://lafibre.info/testdebit/android/202012_wehe_android_11.png) (https://lafibre.info/testdebit/android/202012_wehe_android_12.png)
-
Menu "Mes résultats"
Il affiche les tests réalisés.
Il permet aussi de savoir si un test a été réalisé en IPv4 ou en IPv6 (pour le moment ce n'est pas affiché à un autre endroit sur l'application).
Les tests de ports sont, il me semble, réalisés en IPv6 quand l'opérateur propose ce protocole.
N'hésitez pas sur le mobile à configurer l'APN en IPv4 only, pour tester l'IPv4 : Certains problèmes peuvent être présent en IPv4 mais pas en IPv6 :
(https://lafibre.info/testdebit/android/202012_wehe_android_13.png) (https://lafibre.info/testdebit/android/202012_wehe_android_14.png)
-
Ce qu'il me faut comme information quand vous avez une différentiation ou un "résultat non concluant" :
- Votre opérateur
- Votre offre (FTTH, xDSL, mobile) et le débit de cette offre
- Le type de connexion (Wifi, 4G, 5G)
- Si le test est réalisé en IPv4 ou IPv6 (c'est indiqué dans "Mes résultats")
- Le modèle de votre mobile
- La version d'Android ou iOS
- Si vous avez relancé le test et si c'était de nouveau présent après l'avoir relancé
Merci !
-
Je viens de tester. Je n'ai pratiquement que des tests "non concluants", sans aucun texte d'explication.
J'étais en WiFi (Free, Delta S), je suis passé en 4G, d'abord avec Free, puis avec SFR (2eme SIM), même résultat. Je n'ai qu'un seul test qui a abouti, Pour YouTube, pas de différenciation... J'ai relancé plusieurs fois.
Je suis sous Android 10, en IPv4.
P.S : en fait, j'avais oublié d'appuyer sur le 'i' pour avoir le texte d'explication. C'est donc, sur les derniers que j'ai fait (Microsoft Teams et Skype) : "Le serveur est occupé à exécuter des tests pour d'autres utilisateurs, veuillez réessayer plus tard".
-
Pas de version PC?
Il y a aussi potentiellement le problème de matériel pour la gestion de certains ports.
https://forum.caps.services/index.php/topic,7996.msg101857.html#msg101857
-
Je viens de tester. Je n'ai pratiquement que des tests "non concluants", sans aucun texte d'explication.
J'ai peur que ce soit le bug du "Serveur inaccessible".
Pour avoir le détail du résultat, il faut cliquer sur le (i) en haut à droite du test.
C'est ce que j'ai entouré en vert dans la copie d'écran ci-dessous :
(https://lafibre.info/testdebit/android/202012_wehe_android_9.png)
Ce bug est lié comme je l'expliquait aux nouveaux serveurs, mais il ne semble impacter que Android.
-
Oui, c'est bien cela, j'avais fait un P.S à mon premier message, j'ai donc "Le serveur est occupé...".
-
Pas de version PC?
Non pas de encore de version PC.
Je pense proposer des scripts pour les tests de ports, si il n'y a pas d'autre solution.
Il y a aussi potentiellement le problème de matériel pour la gestion de certains ports.
Le problème de matériel pour la gestion de certains ports ne se pose pas sur les ports choisit.
Le port 1723 qui était à une époque prévu d'être testé ne l'est plus pour les raisons expliquées sur Limitation de débit de certains opérateurs sur le port TCP 1723 (PPTP) ? (https://lafibre.info/vpn/limitation-debit-port-1723/).
-
- Votre opérateur: Sosh 22:40
- Le type de connexion 4G+
- Si le test est réalisé en IPv4
- Le modèle de votre mobile :Galaxy S7
- La version d'Android 8.0
- Si vous avez relancé le test et si c'était de nouveau présent après l'avoir relancé:
Disney+:............ Pas de différenciation
Dailymotion:........Pas de différenciation
Facebook Vidéo:.Pas de différenciation
Netflix:................Pas de différenciation
myCANAL:...........Pas de différenciation
OCS:...................Pas de différenciation
SAlto:.................Résultats non concluants... /2e essai Pas de différenciation
Prime vidéo: ......Résultats non concluants... /2e essai Pas de différenciation
Twitch:................Pas de différenciation
Viméo:................Résultats non concluants... /2e essai Résultats non concluants...
Youtube:.............Résultats non concluants.../2e essai Pas de différenciation
SFR Play:.............Pas de différenciation
Molotov TV.........Pas de différenciation
Edit:
Port:1194 Pas de différenciation/ 6881 Pas de diff./ 853 Résult. non c./ 80 Pas de diff./ 81 Résult. non c./ 465 Résult. non c./ 465 Résult. non c./ 993 Différenciation détecté*/ 995 Pas de diff./ 8443 Pas de diff.
2e essai: 81 Résult. non c. (serveur occupé)/ 465 Pas de diff./ 853 Pas de diff.
*Le trafic https sur ce port pourrait être bridé.
-
Bonsoir Vivien,
C'est très intéressant ce topic mais j'avoue être perplexe quand à la finalité dans notre pays de cette application.
Il y a ça comme explications dans l'application :
Edit: après lecture du fonctionnement sur l'application j'ai saisi le but recherché.
-
Sosh Fibre OK pour 993 IMAP
J'ai testé avec juste YouTube à 23h58
Relancé 3x pour que Monsieur daigne effectuer le test :o
Ça va être chaud d'en faire quelque chose si Wehe est lui même bridé un 24 décembre à minuit ???
Et si quasi tout Google est dans les choux comme l'autre jour de 11h à 13h30, ça va être coton :o
-
Bonsoir,
Est-ce que c'est normal que j'obtienne des débits aussi faibles pour les test de viso ?
Car avec ces aussi petits débits, ça va être compliqué de voir une différence.
Les débits sont les mêmes même après plusieurs tests à différentes heures :
-
Merci pour vos tests.
Est-ce que c'est normal que j'obtienne des débits aussi faibles pour les test de viso ?
Oui, comme expliqué, le débit est celui d'un flux enregistré au préalable :
Le débit n'est pas le débit maximum de votre connexion, mais le débit maximum du flux enregistré.
Il varie donc en fonction des applications et est particulièrement faible pour des application de téléphonie.
Cela permet d'être au plus proche, le débit pouvant jouer dans les choix du DPI.
Ce n'est pas moi qui ait réalisé l'enregistrement du flux Google Meet, mais c'est visiblement un flux audio uniquement, à un débit de 0,2 Mb/s.
Certains opérateurs mobiles bloquaient ce type de flux, pour forcer les clients a passer les appels par l'opérateur.
Il y a 10 ans c'était le cas en France sur la 3G : un appel Skype coupait après quelques minutes, quand la plateforme avait identifié que c'était un flux Skype audio.
-
Développé par la Northeastern University de Boston et fondé sur un code en open source
codes sources: https://dd.meddle.mobi/codeanddata.html
Une nouvelle version de l’application Wehe a été développée en 2020 grâce à la poursuite d’une coopération rapprochée entre les équipes de l’Arcep et l’équipe de recherche de Dave Choffnes, professeur associé à la Northeastern University. Un travail d’une année a permis d’intégrer deux évolutions majeures à cet outil.
les codes sources indiqués datent de 16 mois , du coup ou est le nouveau code ?
-
les codes sources indiqués datent de 16 mois , du coup ou est le nouveau code ?
Je vais remonter le point.
C'est très intéressant ce topic mais j'avoue être perplexe quand à la finalité dans notre pays de cette application.
Wehe fait partie de la boite à outil de l'Arcep pour garantir la neutralité de l'internet.
Sur les tests applicatifs (Youtube, Netflix,...), c'est plus de la dissuasion, les opérateurs ont testé des solutions pour brider la résolution de Youtube à 2 Mb/s (le week-end !) mais cela n'a pas été généralisé. Mais si il n'y avait pas de dissuasion, je pense que cela serait déjà en place chez les opérateurs.
Pour le test de port, tout n'est pas propre, il y a encore des choses à régler et les opérateurs, informés en amont, ont pour certains déjà travaillé sur la chose, preuve que ce n'est pas inutile.
(https://lafibre.info/images/doc/202006_arcep_rapport_etat_internet_2020_4_neutralite_5.png)
-
Le port 853 c'est DoT, comme indiqué dans l'application, pas DoH.
J'ai beaucoup de résultats non concluants pour cause de serveurs occupés.
Pour le torrent, il y a certains clients (je ne saurais pas dire la part) qui peuvent échanger en UDP.
De même, QUIC/HTTP3 utilisent l'UDP sur le port 443, qui a des chances d'être bloqué sur des connexions d'entreprises ou les wifi des hôtels et autres.
Est-ce considéré comme un internet non neutre, dans le sens ou un repli sur le TCP est normalement possible ?
Sinon il semble y avoir un bridage vers 80-90Mbps, c'est volontaire ?
-
C'est corrigé pour DoT / DoH.
Je ne suis pas juriste en neutralité d'internet, mais le blocage des flux UDP, si il n'a pas une justification forte, est probablement une atteinte à la neutralité de l'Internet.
WeHe teste tous les ports avec du TCP + https.
Oui, cela serait bien de faire des tests avec HTTP3, mais il est encore jeune.
Pour la neutralité, il y a une infinité de tests à faire sur plus de 60000 ports. On tente de proposer une application pour faciliter les tests les plus utiles, mais cela n'exclue pas des tests manuels.
-
Google et Facebook, entres autres, utilisent déjà énormément UDP (via QUIC & HTTP/3) ca fait pas mal de trafic quand même.
Pour Facebook c'est 75% de leur trafic (https://engineering.fb.com/2020/10/21/networking-traffic/how-facebook-is-bringing-quic-to-billions/#:~:text=Today%2C%20more%20than%2075%20percent,%2F3%20together%20as%20QUIC).).
Pour Google j'ai pas de chiffre récent mais c'est plus de 50%.
Cloudflare qui sert de frontal a beaucoup de sites vient d'activer UDP/HTTP3 depuis peu.
Il ne faudrait donc pas que ce "nouveau" test soit en retard par rapport a la réalité de ce qu'il est sensé mesuré.
-
Pour Facebook c'est 75% de leur trafic (https://engineering.fb.com/2020/10/21/networking-traffic/how-facebook-is-bringing-quic-to-billions/#:~:text=Today%2C%20more%20than%2075%20percent,%2F3%20together%20as%20QUIC).).
Pour Google j'ai pas de chiffre récent mais c'est plus de 50%.
Leurs études indiquent une amélioration de la qualité des connexions, notamment sur mobile.
Donc si par exemple l'UDP 443 passait vers certains serveurs et pas d'autres, ce serait clairement une atteinte à la neutralité.
Cloudflare qui sert de frontal a beaucoup de sites vient d'activer UDP/HTTP3 depuis peu.
Ils n'envoient plus de header Alt-Svc (du moins sur https://cloudflare-quic.com).
Donc pour que ça fonctionne, il faut supporter la requête DNS "HTTPS" (https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/).
Dans Firefox, il faut :
- network.http.http3.enabled.
- le DoH activé
- network.dns.upgrade_with_https_rr et network.dns.use_https_rr_as_altsvc
Selon le blog Cloudflare, Safari sur iOS14, à condition d'activer le support HTTP/3 expérimental.
Côté Chrome, ça ne semble pas encore supporté.
Bref, on est loin d'une utilisation massive.
-
Salut Vivien.
Pourquoi cette différence de débit entre 443 et les autres ?
Connexion fibre 100/100 sur ResoLiain, teste en wifi tôt ce matin au bureau sans personne depuis mon iPad a quelques mètres de ma borne Wifi.
Comme je pensais qu'il y avait vraiment un problème, j'ai directement appelé le FBI plutôt que d'alerter l'ARCEP ;D ;D ;D ;D
-
...Dans Firefox, il faut :
- network.http.http3.enabled.
- le DoH activé
- network.dns.upgrade_with_https_rr et network.dns.use_https_rr_as_altsvc...
Merci pour le tuyau. ;)
-
Pourquoi cette différence de débit entre 443 et les autres ?
Connexion fibre 100/100 sur ResoLiain, teste en wifi tôt ce matin au bureau sans personne depuis mon iPad a quelques mètres de ma borne Wifi.
Dans ce sens là c'est effectivement étrange.
"au bureau" : est-ce qu'il pourrait y avoir un dispositif de DPI sur le port 443 ? Ca peut servir à filtrer les sites autorisés en fontion du SNI, vérifier le contenu des échanges en faisant du MITM (avec un certificat racine ajouté sur les appareils), ...
-
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 :
Pour nPerf :
(https://lafibre.info/images/doc/202006_arcep_mire_nperf.png)
-
...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 :...
Bonjour Vivien,
Dans ton tableau, on peut trouver Orange, Bouygues et SFR: Qu'en est-il de Free ? :-[
-
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.
-
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.
Merci pour ta réponse. ;)
-
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.
Pourtant ils ont http://test-debit.free.fr/ (certes limité au http).
-
Il est aussi limité en performance, c'est un serveur 1 Gb/s, non ?
En tout cas il n'est pas fiable pour tester son débit et il n’héberge plus d'iPerf.
-
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:
Forbidden
You don't have permission to access this resource.
:'(
-
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/.
-
Voilà ce qu'on doit voir ;)
-
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. ;)
-
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, 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.
-
C’est dommage, y’a pas de version f-droid :(
-
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, 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.
-
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 ?
-
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 :
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
-
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.
-
Une limitation à 20 Mb/s par le CPU, oui, c'est vraiment vieux.
Aujourd'hui une box grand public sait router de manière logicielle à 200 Mb/s. Là on parle d'un routeur CISCO RV110W qui n'a même pas de ports 1 Gb/s (ports WAN limité à 100 Mb/s et ports LAN limités à 100 Mb/s).
Je ne sais pas de quand il date, mais il a au moins 10 ans.
Après si tu as mis des règles trop complexes sur le port 443, cela pourrait expliquer une lenteur.
Pour faire un nouveau test, il faudrait faire un test en remettant la configuration par défaut du CISCO RV110W : Tu arua probablement un débit de 100 Mb/s sur le port 443.
-
En même temps, le RV110 c'est vraiment très bas de gamme...
-
Sur LDLC :
Produit référencé le : 24/06/2011
-
Une limitation à 20 Mb/s par le CPU, oui, c'est vraiment vieux.
Aujourd'hui une box grand public sait router de manière logicielle à 200 Mb/s. Là on parle d'un routeur CISCO RV110W qui n'a même pas de ports 1 Gb/s (ports WAN limité à 100 Mb/s et ports LAN limités à 100 Mb/s).
Je ne sais pas de quand il date, mais il a au moins 10 ans.
Après si tu as mis des règles trop complexes sur le port 443, cela pourrait expliquer une lenteur.
Pour faire un nouveau test, il faudrait faire un test en remettant la configuration par défaut du CISCO RV110W : Tu aura probablement un débit de 100 Mb/s sur le port 443.
Routeur fourni par mon FAI il y a environ 2 ans, il remplaçait un RV120W de mémoire. Aucune règle appliquée, il était "stock" comme fourni par mon FAI.
Quand je pense qu'ils nous le louent 8 euro HT par mois il me semble c'est de l'abus 8)
-
J'ai l'impression qu'SFR mobile bloque le port 53 : https://lafibre.info/4g-sfr/neutralite-du-net-et-blocage-port-53-chez-sfr (https://lafibre.info/4g-sfr/neutralite-du-net-et-blocage-port-53-chez-sfr)
il n'est malheureusement pas possible de tester le port 53 avec cette application ?
-
Non, le port 53 n'est pas testé par Wehe a cause d'une problématique de certains serveurs Wehe présent dans le pool : Certains hébergeurs interdisent l’utilisation de ce port.
Si c'est confirmé, cela me semble une nouveauté car le port 53 a déjà posé problème avec un autre opérateur et à l'époque seul cet opérateur ce port (c'est débloqué depuis).
-
Non, le port 53 n'est pas testé par Wehe a cause d'une problématique de certains serveurs Wehe présent dans le pool : Certains hébergeurs interdisent l’utilisation de ce port.
Si c'est confirmé, cela me semble une nouveauté car le port 53 a déjà posé problème avec un autre opérateur et à l'époque seul cet opérateur ce port (c'est débloqué depuis).
Cf ma réponse ici https://lafibre.info/4g-sfr/neutralite-du-net-et-blocage-port-53-chez-sfr/msg826361/#msg826361 (https://lafibre.info/4g-sfr/neutralite-du-net-et-blocage-port-53-chez-sfr/msg826361/#msg826361) mais aucun packet n'est reçu (sur les capture Wireshark) sur le WAN de mon routeur en UDP 53 depuis mon téléphone chez SFR (RED)
-
Si c'est confirmé, cela me semble une nouveauté car le port 53 a déjà posé problème avec un autre opérateur et à l'époque seul cet opérateur ce port (c'est débloqué depuis).
Cela me rappelle Bouygues Telecom, je ne me rappelle plus avoir vu passer que c'était résolu. Ce n'était pas en fait un blocage, mais les requêtes vers le port UDP 53 était systématiquement redirigées vers les serveurs Bouygues Telecom, si je me souviens bien.
-
D'après mes tests (cf le fil dédié), chez SFR mobile le port 53 en UDP en émission n'est disponible que pour le protocole DNS (quel que soit le serveur). Les autres protocoles sont bloqués.
A mon sens c'est une atteinte à la neutralité du net.
-
La version Wehe qui corrige les bugs que vous avez remontés, soumise à Google le 24 décembre a enfin été validée cette nuit.
La version 3.6 a aussi été poussée sur iOS.
J'ai fait de nombreux de tests et je ne vois plus de problèmes liés à l'application.
N’hésitez pas à remonter ici tous les résultats que vous avez qui sont différent de "Pas de différentiation", pour que je regarde dans quelle case il rentre :
- Bug de l'application
- Différentiation temporaire liée à la charge du réseau au moment du test
- Différentiation permanente connue de nos services (en cours de traitement)
- Différentiation permanente non référencée
Les tests réalisés ce matin avec de gauche à droite, un Android 9.0, un Android 8.0 et un Android 7.0 :
(https://lafibre.info/testdebit/android/202101_tests_wehe.jpg)
-
J'ai testé sur la fibre Orange en Wifi.
Il y a toujours un peu de variation :
- entre 58Mbps et 85Mbps pour les fichiers de 10Mo
- entre 83Mbps et 102Mbps pour les fichiers de 50Mo
Peut-être qu'il serait plus pertinent (surtout en wifi) de faire une durée fixe (par exemple 3s pour TCP slow start, puis 3s de mesure) plutpôt qu'une une taille fixe (et une mesure sur le temps total ?).
Un test non concluant sur le port 81, à cause d'un serveur non accessible (finalemement OK après avoir relancé 2 fois).
Sur une autre série, pareil pour 6881, 993, 995, 8080, et 8443 (3 résolus en relançant une fois, les 2 autres ensuite).
-
L'erreur "serveur non accessible" ne semble arriver que sur Android 10/11.
Je veut bien ton modèle de smartphone et la version d'Android.
-
Je veut bien ton modèle de smartphone et la version d'Android.
C'est effectivement Android 11, une ROM AOSP (GSI, donc une ROM générique installable sur beaucoup de téléphones).
-
Vous savez comment faire tourner Android 10 ou 11 sur une machine virtuelle Virtualbox ?
J'explique sur https://lafibre.info/os-mobile/android-rapport-bug/msg827264/#msg827264 comment faire une machine virtuelle Android-x86, mais Android-x86 ne propose ni Android 10, ni Android 11 et mon téléphone (Samsung S8) est limité à Android 9.
-
Vous savez comment faire tourner Android 10 ou 11 sur une machine virtuelle Virtualbox ?
J'explique sur https://lafibre.info/os-mobile/android-rapport-bug/msg827264/#msg827264 comment faire une machine virtuelle Android-x86, mais Android-x86 ne propose ni Android 10, ni Android 11 et mon téléphone (Samsung S8) est limité à Android 9.
Android-x86 est un port d'Android qui n'est pas forcement a jour ou complet.
Il est mieux d'utiliser l'Android Emulator d'Android Studio (KVM) ou GenyMotion (Virtualbox)
-
La version Wehe qui corrige les bugs que vous avez remontés, soumise à Google le 24 décembre a enfin été validée cette nuit.
Il est prévu d’ouvrir le code et de la publier sur f-droid ?
-
Le point prioritaire est de fiabiliser les tests sous Android 10 et 11 pour éviter d'avoir de temps en temps des erreurs.
Ensuite nous avons deux points ouverts :
- Mise à jour du code source de l'application et du serveur
- Mode sombre sous iOS : il y a des éléments qui ne sont pas visible
Pour F-Droid ce n'a pas été évoqué, mais je peut tenter. Si cela prend peu de temps cela pourrait être fait.
Tu aurais une présentation pour essayer de motiver mes collègues et la Northeastern University qui fait la publication ?
-
Bonjour,
Nous avons des difficultés pour reproduire le problème suivant et prendre des traces pour les développeurs de Wehe.
Cette erreur de "Serveur inaccessible" se produirait maintenant uniquement avec Android 10 et 11.
(https://lafibre.info/testdebit/android/202012_wehe_android_12.png)
Nous avons besoin d'une capture d'écran en ayant appuyé sur le petit cercle (i) en haut à droite du test non concluant (pou avoir les détail de l'erreur) et surtout du rapport de bug associé via la prise de trace détaillée dans le tutoriel ci-dessous.
=> Tutoriel pour activer le mode développeur et créer un rapport de bug (https://lafibre.info/os-mobile/android-rapport-bug/)
Perso, avec des mobiles sous Android 7.0, 8.0 et 9.0 je n'ai plus de problème.
Si un volontaire peut aider sur ce point et me transmettre la trace en privé.
Merci.
-
Pour F-Droid ce n'a pas été évoqué, mais je peut tenter. Si cela prend peu de temps cela pourrait être fait.
Tu aurais une présentation pour essayer de motiver mes collègues et la Northeastern University qui fait la publication ?
De l’intérêt de f-droid ou de comment publier une application dessus ?
-
On en a discuté ce matin, l'Arcep devrait faire la demande à la Northeastern University.
Un document qui présente l’intérêt de F-Droid de mettre une application sur ce magasin d'applications libres serait bienvenue (en Anglais si possible, c'est la Northeastern University qu'il faut convaincre, pas l'Arcep)
-
Là j'ai un autre problème : tous les tests restent "En attente", et il finit par afficher une popup "Serveur inaccessible, relancer le test ultérieurement".
C'est probablement le serveur qui ne répond pas du tout.
-
La sélection des serveurs est complexe.
La librairie Web Socket n'est pas disponible avec Android 7 et plus ancien, donc il y a un fall back pour les vieux Android.
Pour les Android récents (je considère Andorid 9 comme récent), il y un système complexe. (je n'ai pas regardé dans quel cas de figure est Android 8 )
J'ai réussi à reproduire ton problème avec mon Samsung S8 sous Android 9 et j'ai fait le rapport de bug associé. Ce n'est pas systématique, mais c'est fréquent.
Je reviens vers vous quand ce problème supplémentaire est résolut.
-
J'ai réussi à reproduire ton problème avec mon Samsung S8 sous Android 9 et j'ai fait le rapport de bug associé. Ce n'est pas systématique, mais c'est fréquent.
Lequel ?
Tout à l'heure tous les tests restaient bloqués "En attente", et j'avais une popup d'erreur.
Là presque tous les ports passent, mais l'un est resté longtemps bloqué sur "Création du canal auxiliaire", et c'est le seul qui a échoué, avec le message "Serveur inaccessible, relancer le test ultérieurement".
-
Voici les deux bugs pour lequel j'ai fait une capture et envoyé le tout à la Northeastern University.
(https://lafibre.info/testdebit/android/202101_wehe_android_erreur_1.png) (https://lafibre.info/testdebit/android/202101_wehe_android_erreur_2.png)
Personnellement avec mon Andorid 9 je n'avais pas eu du tout ce type d'erreur en 2021.
-
Il semble que l'un de serveurs WeHe était surchargé. Il a été redémarré.
Je suis intéressé, si vous avez des erreurs et si possible une trace de l'erreur.
-
Voici des erreurs rencontrées ce matin vers 10h.
Oneplus Nord, Android 10
Pour info, le test pour Deezer est très très compliqué depuis la publication de l'application, et chez moi ça plante la plupart du temps
-
La Northeastern University a trouvé un problème sur le soft serveur.
Parfois, lorsque le serveur est soumis à une charge importante, le test précédent ne nettoie pas assez rapidement, ce qui empêche le test suivant de s'exécuter correctement.
Un correctif a été déployé sur les serveurs EC2. La mise à jour des autres serveurs sera fait d'ici la fin de la semaine.
-
Si il y a des abonnés Zeop ici, je suis intéressé pour des tests WeHe...
Ils ont un peu de mal avec la neutralité du net chez #ZeopMobile @Arcep
Offrir une itinérance sur le réseau @OrangeReunion c'est bien mais une expérience utilisateur potable c'est mieux
Je plains les abonnés qui n'ont pas d'antenne Zeop à proximité de chez eux... #LaRéunion
(https://lafibre.info/images/zeop/202102_wehe_tests_zeop.jpg)
Source : Twitter @Dylan_Legros (https://twitter.com/Dylan_Legros/status/1358441915075743745)
-
Salut je suis chez free en VDSL avec une synchro 45mb de synchro est ce que c'est normal que les debits de mes ports ne dépasse pas les 0,3 mbs?. (Freebox revolution)
-
Non, pas du tout.
Cela serait une saturation vers les serveurs ? (C'est compliqué d'identifier les serveurs utilisés, il y a plusieurs paramètres à prendre en compte)
Pour le vérifier, je serais intéressé par un test le matin, quand tu te lèves. C'est là que le réseau est le moins chargé.
-
D'accord @Vivien je post les screen demain matin.
-
@vivien. J'ai les même débits mauvais sur les tests de différenciations sur prime, netflix. Est-ce que le débit sur ces tests doit être proche du débit nécessaire pour visualiser les vidéos de ces services ?
-
Sur les tests de ports, les débits sont élevés (on peut dépasser 50 Mb/s)
Sur les tests d'application, c'est un rejeu d'un vrai enregistrement, avec le débit original.
Wehe n'utilise pas les serveurs des applications, mais d'autres serveurs, avec le contenu des applications enregistrés, et donc le SNI et le certificat des applications, ces éléments étant ceux utilisés par le DPI (quand il existe, je rappelle que c'est interdit) pour brider le débit.
Concrètement pour Prime, il rejoue un des deux enregistrements que j'ai fait en novembre 2020 :
=> https://lafibre.info/tv-numerique-hd-3d/amazon-prime-video-45152/
Captures Wireshark : (Wireshark est nécessaire pour lire les fichiers)
Amazon Prime Vidéo "Les héritiers de la nuit" CDN Akamai (https://lafibre.info/images/wireshark/202011_amazon_prime_akamai_396p.pcapng.gz)
- Capture du 12/11/2020 : 19 Mo, 66 secondes, 1 connexion https, TLS 1.2
- Firefox 82, sous Ubuntu 20.10, noyau Linux 5.8
Amazon Prime Vidéo "This Is Us" CDN Amazon (https://lafibre.info/images/wireshark/202011_amazon_prime_amazon_cdn_396p.pcapng.gz)
- Capture du 12/11/2020 : 15 Mo, 69 secondes, 1 connexion https, TLS 1.3
- Firefox 82, sous Ubuntu 20.10, noyau Linux 5.8
Il est donc normal d'avoir des petits débits, surtout sur des application audio.
-
Non, pas du tout.
Cela serait une saturation vers les serveurs ? (C'est compliqué d'identifier les serveurs utilisés, il y a plusieurs paramètres à prendre en compte)
Pour le vérifier, je serais intéressé par un test le matin, quand tu te lèves. C'est là que le réseau est le moins chargé.
Salut bon ce matin c'est beaucoup mieux je plafonne donc a 15mbs mais on est quand meme très loins des 45mbs de synchro ? Cela peut venir de quoi ? Que puis-je faire pour améliorer cela?
Merci
-
Wehe n'est pas directement un test de débit.
C'est assez complexe et fait à l'origine pour le DPI.
Ce qui est important, c'est de ne pas avoir de différence entre le port de référence, le 443 et les autres.
Tu met par contre en évidence des saturations chez Free, mais tu n'es pas le premier.
Note: Peu le savent, mais une saturation des interconnexions (coucou Free <=> Cogent) n'est pas a priori directement une entrave à la neutralité. Pour que cela devienne une entrave à la neutralité, il faut que la saturation soit fait dans le but de nuire à la neutralité et donc il faut le prouver.
-
Wehe n'est pas directement un test de débit.
C'est assez complexe et fait à l'origine pour le DPI.
Ce qui est important, c'est de ne pas avoir de différence entre le port de référence, le 443 et les autres.
Tu met par contre en évidence des saturations chez Free, mais tu n'es pas le premier.
Note: Peu le savent, mais une saturation des interconnexions (coucou Free <=> Cogent) n'est pas a priori directement une entrave à la neutralité. Pour que cela devienne une entrave à la neutralité, il faut que la saturation soit fait dans le but de nuire à la neutralité et donc il faut le prouver.
Oui je vois, exactement la c'est une très grosse saturation on parle quand meme de 0,3mbs c'est donc presque 0. Il n'y a donc rien que je puisse faire pour essayer d'améliorer ça ?
-
Note: Peu le savent, mais une saturation des interconnexions (coucou Free <=> Cogent) n'est pas a priori directement une entrave à la neutralité. Pour que cela devienne une entrave à la neutralité, il faut que la saturation soit fait dans le but de nuire à la neutralité et donc il faut le prouver.
Mais si certains services sont inutilisables chez un FAI donné parce que son interco est très mauvaise pendant que d'autres services, utilisant des intercos meilleures sont totalement utilisables : pourquoi ne peut-on pas qualifier ça d'atteinte à la neutralité du net ? Le fait est que Free a volontairement laisser se dégrader Netflix pendant des mois pour ses clients (volontairement car par négligence, ils auraient pu agir mais ne l'ont pas fait)
-
Mais si certains services sont inutilisables chez un FAI donné parce que son interco est très mauvaise pendant que d'autres services, utilisant des intercos meilleures sont totalement utilisables : pourquoi ne peut-on pas qualifier ça d'atteinte à la neutralité du net ?
parce que c'est debile ? j'ai qu'a monter un serveur pourrave au fin fond d'une grotte en chine et ensuite me plaindre que ca rame depuis la france pour dire que y a atteinte a la neutralité du net ?
ce qui est pas neutre c'est d'agir pour brider.
-
Oui je vois, exactement la c'est une très grosse saturation on parle quand meme de 0,3mbs c'est donc presque 0. Il n'y a donc rien que je puisse faire pour essayer d'améliorer ça ?
deja fait bien un test vrai test de debit (donc pas cette appli). Et si ca se confirme des debit aussi bas le soir et pas le matin, ben y a que free qui peut agir.
donc gueuler au support et resiliation s'il le faut.
-
deja fait bien un test vrai test de debit (donc pas cette appli). Et si ca se confirme des debit aussi bas le soir et pas le matin, ben y a que free qui peut agir.
donc gueuler au support et resiliation s'il le faut.
D'accord ce soir je relance donc un test avec cette appli et juste apres avec un speedtest histoire de voir si c'est vraiment un gros problème de saturation. Je vous poste ça ici des que c'est possible.
-
Mais si certains services sont inutilisables chez un FAI donné parce que son interco est très mauvaise pendant que d'autres services, utilisant des intercos meilleures sont totalement utilisables : pourquoi ne peut-on pas qualifier ça d'atteinte à la neutralité du net ? Le fait est que Free a volontairement laisser se dégrader Netflix pendant des mois pour ses clients (volontairement car par négligence, ils auraient pu agir mais ne l'ont pas fait)
C'est pas automatique comme expliqué et dans tous les cas pas simple à prouver.
bien sur c'est un résumé pour essayer de rendre l'information accessible.
Je ne suis pas juriste et c'est soumis à interprétation et a plein de choses.
C'est surtout pour ceux qui pensent que l'Arcep ne fait pas son travail car tel opérateur sature vers xxx.
-
C'est pas automatique comme expliqué et dans tous les cas pas simple à prouver.
bien sur c'est un résumé pour essayer de rendre l'information accessible.
Je ne suis pas juriste et c'est soumis à interprétation et a plein de choses.
C'est surtout pour ceux qui pensent que l'Arcep ne fait pas son travail car tel opérateur sature vers xxx.
Peut etre je devrais envoyer un mail a cogent france ou contacter directement free mais j'ai une question ? Comment savez-vous que les saturation viennent de chez cogent ya t'il une raison spéciale.
-
Cogent est l'unique transitaire de Free.
Un FAI paye ses transitaire (donc Free pay Cogent) mais par contre les peering sont soit gratuit soit rémunèrent l'opérateur.
En saturant le transitaire, tu incite les opérateurs qui souhaitent de la qualité a payer un peering privé.
-
Cogent est l'unique transitaire de Free.
Un FAI paye ses transitaire (donc Free pay Cogent) mais par contre les peering sont soit gratuit soit rémunèrent l'opérateur.
En saturant le transitaire, tu incite les opérateurs qui souhaitent de la qualité a payer un peering privé.
Donc si j'ai bien compris le mieux que je puisse faire est de trouver le datacenter cogent le plus proches de chez moi et de signaler des problèmes de saturation chez eux (par exemple par mail) ou peut-être contacter free et signaler que le soir ma connexion est très saturé dû a des problèmes en rapport avec cogent? J'aimerais être un peu éclairer la dessus. Car je ne paye pas 50€ tout les mois pour avoir un debit de 0.3 mbs c'est inadmissible !
-
Tenter de rentrer en contact avec Cogent ne fera rien. Tu n'es pas client pour eux, Free l'est. Cogent est comme un "gros FAI" pour Free (je schématise à fond).
Cogent en soi n'est pas un mauvais transitaire. Bouygues Telecom utilise les services de Cogent (et d'autres) et ça se passe très bien.
La question c'est est-ce que Free dimensionne suffisamment son tuyau avec Cogent pour que leurs deux réseaux puissent correctement s'échanger des données : la réponse est "oui à peu près mais des fois ça passe pas". Et ce sont les abonnés qui trinquent.
Free laisse son interconnexion avec Cogent saturer car cela permet à Free de faire pression sur d'autres acteurs d'internet pour se connecter à lui. En gros, Free dit "Bonjour [gros service sur internet au pif], vous essayez d'échanger des données avec nous mais ça marche bof parce qu'on passe par plusieurs réseaux intermédiaires [cogent, quoi]. Ça vous dit on s'interconnecte en direct entre nous ? Par contre, vous devez nous payer pour ça".
Si Free avait une interco nickel avec Cogent, alors les autres acteurs d'internet n'auraient plus besoin de le rémunérer pour s'interconnecter directement avec lui (tout passerait par cogent, mais ça serait 100% fonctionnel si c'était bien dimensionné).
Non, ce que tu peux faire pour éviter ces saturations c'est prendre un tunnel VPN (je pense par exemple à MilkyWan) qui te fera emprunter d'autres routes non saturées sur Internet. Ou simplement changer de FAI. Tous en France sont très bons niveau interconnexions avec le reste d'internet, à l'exception de Free (qui est pas horrible non plus, juste clairement en dessous du lot).
De ce que je peux voir de mon côté, je connais au moins un gros opérateur en France avec lequel aucune interconnexion ne sature jamais :)
-
Tenter de rentrer en contact avec Cogent ne fera rien. Tu n'es pas client pour eux, Free l'est. Cogent est comme un "gros FAI" pour Free (je schématise à fond).
Cogent en soi n'est pas un mauvais transitaire. Bouygues Telecom utilise les services de Cogent (et d'autres) et ça se passe très bien.
La question c'est est-ce que Free dimensionne suffisamment son tuyau avec Cogent pour que leurs deux réseaux puissent correctement s'échanger des données : la réponse est "oui à peu près mais des fois ça passe pas". Et ce sont les abonnés qui trinquent.
Free laisse son interconnexion avec Cogent saturer car cela permet à Free de faire pression sur d'autres acteurs d'internet pour se connecter à lui. En gros, Free dit "Bonjour [gros service sur internet au pif], vous essayez d'échanger des données avec nous mais ça marche bof parce qu'on passe par plusieurs réseaux intermédiaires [cogent, quoi]. Ça vous dit on s'interconnecte en direct entre nous ? Par contre, vous devez nous payer pour ça".
Si Free avait une interco nickel avec Cogent, alors les autres acteurs d'internet n'auraient plus besoin de le rémunérer pour s'interconnecter directement avec lui (tout passerait par cogent, mais ça serait 100% fonctionnel si c'était bien dimensionné).
Non, ce que tu peux faire pour éviter ces saturations c'est prendre un tunnel VPN (je pense par exemple à MilkyWan) qui te fera emprunter d'autres routes non saturées sur Internet. Ou simplement changer de FAI. Tous en France sont très bons niveau interconnexions avec le reste d'internet, à l'exception de Free (qui est pas horrible non plus, juste clairement en dessous du lot).
De ce que je peux voir de mon côté, je connais au moins un gros opérateur en France avec lequel aucune interconnexion ne sature jamais :)
D'accord sinon est ce possible de contourner le peering avec un Proxy? (Sinon je vais essayer Milkywan)
Merci pour ton aide !
-
En effet, avec un proxy web ça marche. C'était une technique renommée pour accéder à YouTube quand ça ramait chez Free (toujours le même problème avec Cogent, puis une interco directe entre Free et YouTube a été montée. Qui a payé qui, mystère.).
Cependant je sais que ça marchait avec YouTube, mais avec d'autres sites genre twitch je ne sais pas.
-
Donc si j'ai bien compris le mieux que je puisse faire est de trouver le datacenter cogent le plus proches de chez moi et de signaler des problèmes de saturation chez eux (par exemple par mail) ou peut-être contacter free et signaler que le soir ma connexion est très saturé dû a des problèmes en rapport avec cogent? J'aimerais être un peu éclairer la dessus.
comme dit plus haut : non. Tu es client de free c'est a eu d'agir.
Car je ne paye pas 50€ tout les mois pour avoir un debit de
sur l'adsl tu ne payes pas pour un debit, mais pour la mise a dispo du matos.
0.3 mbs c'est inadmissible !
tu as fait un vrai test de debit ou tu continue a utiliser cette app qui ne fait pas de test de debit ?
-
Que donne un test de débit sur https://speed.measurementlab.net/ ?
Wehe utilise dans certains cas les serveurs de Measurement Lab
-
Si tu veux pour te donner un exemple avec le lien de Vivien ci-dessus, sur une connexion Sosh Fibre voila la résultat (PC portable sous W10 en ethernet) et il est 20h20
Test Server Marseille, FR
Download 293.57 Mb/s
Upload 292.13 Mb/s
Latency 19 ms
Retransmission 0.00%
-
20h26 :
Test Server Marseille, FR
Download 567.75 Mb/s
Upload 230.31 Mb/s
Latency 26 ms
Retransmission 0.00%
-
Que donne un test de débit sur https://speed.measurementlab.net/ ?
Wehe utilise dans certains cas les serveurs de Measurement Lab
Je viens de faire le test 20h36 (le résultat niveau ping est très mauvais sachant que j'habite pas tres loin de Marseille)
-
pour moi rien d'anormal pour une connec vdsl en fait.
-
pour moi rien d'anormal pour une connec vdsl en fait.
80 de ping c'est très très mauvais pour mon debit et je suis qu'a 137km de Marseille
-
Faut traceroute le serveur pour ça. C’est pas parce que tu es pas loin de Marseille que les données y vont directement
-
Faut traceroute le serveur pour ça. C’est pas parce que tu es pas loin de Marseille que les données y vont directement
Ya t'il un moyen de connaître l'adresse ip ? du serveur utilisé par ce site
-
Donc encore le meme problème hein... test fait a 21h debit médiocre encore une fois.
-
Il est prévu d’ouvrir le code et de la publier sur f-droid ?
Je n'ai pas oublié ta demande.
C'est enfin fait :
(https://lafibre.info/testdebit/android/202106_Android_F-Droid_Wehe.png)