La Fibre
Télécom => Réseau => 
Comment tester son débit ? => Discussion démarrée par: vivien le 11 janvier 2023 à 13:42:35
-
L'Arcep a demandé aux opérateurs de mettre en place une API pour mieux caractériser l'environnement des tests de débit
(https://lafibre.info/images/logo/banniere_qos.svg)
L’API est accessible à des outils de mesure en crowdsourcing, pour le moment uniquement https://www.nperf.com/, utilisés par les usagers pour évaluer le débit ou, plus généralement, la qualité de service de leurs accès à internet. Sollicitée uniquement lorsque l’utilisateur initie un test de débit, et sous son contrôle, l’API renseigne l’outil de mesure sur une série d’indicateurs techniques, tels que le type de box, la technologie d’accès à internet, les débits montants ou descendants contractuels.
Les modalités de fonctionnement de l’API prennent pleinement en compte les questions de respect et de protection de la vie privée des utilisateurs. D’abord, les données recueillies par l’API ne sont évidemment pas transmises à l’Arcep. Ensuite, aucune donnée liée à l’identification de l’utilisateur (identifiant, nom, localisation, etc.) n’est transmise par l’API aux outils de mesure. Enfin, l’API n’est sollicitée que lors d’un test de débit initié par l’utilisateur lui-même et ne répond pas aux sollicitations depuis internet.
Questionnée dans le cadre de cette démarche, la CNIL a pu s’assurer que le dispositif répondait dans son principe aux exigences en matière de protection des données personnelles tout en insistant sur l’importance du rôle de conseil de l’Arcep, notamment au travers du « Code de conduite de la qualité de service internet », vis-à-vis des outils de mesure exploitant l’API.
Comment fonctionne l’API ?
Le schéma ci-dessus décrit le fonctionnement de l’API lorsqu’un client initie un test de QoS avec un outil de test ayant accès à l’API. Deux appels à l’API sont réalisés : le premier juste avant le test de débit et le second juste après. Ces appels permettent de récupérer les différents indicateurs pour caractériser le lien entre le terminal de l’utilisateur et internet tout en s’assurant qu’il n’y a pas eu de cross-trafic, c’est-à-dire un trafic autre que celui mesuré (trafic d’un autre PC ou smartphone, box TV ou trafic lié à un autre programme sur le PC de test). Pour ce faire, l’outil de mesure va comparer la quantité de données qu’il a envoyée et reçue sur internet à la quantité de données qui a été transmise sur internet par la box entre le premier et le second appel de l’API.
(https://lafibre.info/images/doc/202206_arcep_fonctionnement_de_api_carte_identite_de_acces.webp)
L’API est-elle accessible depuis internet ?
Non, l’API est accessible uniquement depuis le réseau local de l’utilisateur final. L’appel de l’API doit être réalisé sur les serveurs du fournisseur d’accès à internet depuis l’adresse IP du client. Les requêtes provenant d’autres adresses IP sont rejetées afin de sécuriser le dispositif. C’est donc uniquement l’outil de test exécuté sur le terminal du client qui peut appeler l’API. De plus, un système de restriction d’accès est mis en place, afin que seuls les outils autorisés puissent accéder à l’API.
-
Les résultats de nPerf ne sont pas encore enrichis grâce à l’API, mais vous pouvez déjà visualiser les données remontées par l'API dans votre navigateur, via la touche F12.
1/ Dans votre navigateur web, il faut ouvrir "les outils de développement" accessible via la touche F12 ou Ctrl + MAj + I.
- Firefox : Menu ➤ Outils supplémentaires ➤ Outils de développement web ;
- Chrome : Menu ➤ Plus d'outils ➤ Outils de développement ;
- Microsoft Edge : Menu ➤ Outils supplémentaires ➤ Outils de développement web ;
- Safari : Safari ➤ Préférences ➤ Avancé et cocher l'option Afficher le menu de développement puis Développement ➤ Afficher l'inspecteur web.
2/ Cliquer sur l'onglet "Réseau" pour démarrer l'enregistrement des requêtes.
3/ Aller sur https://www.nperf.com/ et lancer un test (c'est sur l'onglet nPerf que l'onglet "Réseau" doit être ouvert).
4/ Filtrer les URL pour obtenir uniquement les requêtes de l'API : rentrer api (Orange/Free/SFR) ou qos (Bouygues) de façon à n'avoir que des lignes :
- Bouygues Telecom : qos.bouygtel.fr:39443
- Orange : api-infoacces.orange.fr
- Free : api-arcep.proxad.net
- SFR : apibox.sfr.net
5/ Cliquer sur la réponse à une requête API puis sur l'onglet "Réponse"
Exemple avec une carte Wi-Fi 802.11g (le PC de mon fils) :
(https://lafibre.info/images/barometre/202301_api_arcep_box_sfr_1.webp)
-
Exemple avec un PC connecté en Ethernet 100 Mb/s :
(https://lafibre.info/images/barometre/202301_api_arcep_box_sfr_2.webp)
-
Voici plus d'information sur les données que peut remonter l'API (tout n'est pas obligatoire) :
"gateway" => "model": "NB6VAC"
description: Nom de l'IAD ("box") du client - élément facultatif, certains FAI le renseignement, d'autre non.
type: string
"gateway" => "softwareVersion": "R4.0.45d.0"
description: Version du logiciel de l'IAD - élément facultatif, certains FAI le renseignement, d'autre non.
type: string
Section SubscriptionSpeed pour le débit contractuel
"subscriptionSpeed" => "downloadMin": 0
description: Débit minimum descendant contractuel (Kb/s) - élément présent lorsque défini et existant.
type: integer
format: int64
minimum: 0
"subscriptionSpeed" => "uploadMin": 0
description: Débit minimum montant contractuel (Kb/s) - élément présent lorsque défini et existant.
type: integer
format: int64
minimum: 0
"subscriptionSpeed" => "downloadMax": 0
description: Débit maximum descendant contractuel (Kb/s)
type: integer
format: int64
minimum: 0
"subscriptionSpeed" => "uploadMax": 0
description: Débit maximum montant contractuel (Kb/s)
type: integer
format: int64
minimum: 0
"subscriptionSpeed" => "downloadNormally": 0
description: Débit "normalement disponible" descendant contractuel (Kb/s) - élément présent lorsque défini et existant.
type: integer
format: int64
minimum: 0
"subscriptionSpeed" => "uploadNormally": 0
description: Débit "normalement disponible" montant contractuel (Kb/s) - élément présent lorsque défini et existant.
type: integer
format: int64
minimum: 0
-
Section WAN
"wan" => "technology": "ftth"
description: Technologie WAN utilisée par l'IAD ("box")
type: string
enum: [ftth, adsl, vdsl, gfast, cable, satellite, 2g, 3g, 4g, 5g, other]
"wan" => "mode": "IntegratedNT"
description: Indique si la terminaison WAN opérateur est intégrée à l'IAD (IntegratedNT - exemple ADSL, VDSL, FTTH avec ONT intégré) ou non (ExternalNT - exemple FTTH avec boitier ONT sans accessoire de connectivité détecté). Si détection d'un accessoire de connectivité entre IAD et ExternalNT (notion de WAN complexe), la valeur de ce champ sera "Complex".
type: string
enum: [IntegratedNT, ExternalNT, Complex]
"wan" => "aggregation": "no"
description: Technologie WAN secondaire active ('no' = absence d'agrégation ou agrégation non activée)
type: string
enum: [no, ftth, adsl, vdsl, gfast, cable, satellite, 2g, 3g, 4g, 5g, other]
-
Section WAN - SpeedNT
"wan" => "speedNT" => "download": 1000000
description: Débit descendant Ethernet entre le boîtier de terminaison réseau et IAD (Kb/s) - élément présent lorsque présence d'un boîtier de terminaison réseau externe.
type: integer
"wan" => "speedNT" => "upload": 1000000
description: Débit montant Ethernet entre le boîtier de terminaison réseau et l'IAD (Kb/s) - élément présent lorsque présence d'un boîtier de terminaison réseau externe.
type: integer
format: int64
minimum: 0
"wan" => "speedNT" => "downloadEstimated": 1000000
description: Estimation du débit descendant utile du segment limitant, en cas de détection d’un accessoire de connectivité entre le boîtier de terminaison réseau et l'IAD (Kb/s) - élément présent lorsque "Wan Mode = Complex".
type: integer
format: int64
minimum: 0
"wan" => "speedNT" => "uploadEstimated": 1000000
description: Estimation du débit montant utile du segment limitant, en cas de détection d’un accessoire de connectivité entre le boîtier de terminaison réseau et l'IAD (Kb/s) - élément présent lorsque "Wan Mode = Complex".
type: integer
format: int64
minimum: 0
"wan" => "speedNT" => "duplex": "full"
description: Mode Ethernet entre le boitier de terminaison réseau (NT) et l'IAD - élément présent lorsque présence d'un boîtier de terminaison réseau externe.
type: string
enum: [half, full]
-
Section WAN - Syncronisation xDSL
"wan" => "speedSynchro" => "download": 10000
description: xDSL uniquement => débit de synchronisation descendant (Kb/s) - élément présent lorsque la technologie WAN est xDSL
type: integer
format: int64
minimum: 0
"wan" => "speedSynchro" => "upload": 1000
description: xDSL uniquement => débit de synchronisation montant (Kb/s) - élément présent lorsque la technologie WAN est xDSL
type: integer
format: int64
minimum: 0
-
Section WAN - ByteCounter pour le cross-traffic
"wan" => "byteCounter" => "download": 2021748595
description: Relevé du compteur de trafic descendant (internet => IAD) du port WAN (octets).
type: integer
format: int64
minimum: 0
"wan" => "byteCounter" => "upload": 4292080939
description: Relevé du compteur de trafic montant (IAD => internet) du port WAN (octets).
type: integer
format: int64
minimum: 0
-
Section LAN
"lan" => "connectionType": "ethernet"
description: Représente la technologie de l’interface de l’IAD par laquelle arrive la requête d'API émise par le terminal (note - La détection du CPL sur le LAN est facultative).
type: string
enum: [wifi, ethernet, cpl, other]
"lan" => "complexity": "Undefined"
description: Niveau de complexité de la topologie LAN. Le terminal requêtant l'API est détecté comme connecté directement à l'IAD (= Direct), derrière un ou plusieurs accessoires de connectivité avec connaissance par l'IAD des éléments constitutifs (= Complex) ou sans connaissance (= Undefined)
type: string
enum: [Direct, Complex, Undefined]
Section LAN - SpeedLAN
"lan" => "speedLan" => "downloadMax": 1000000
description: Débit maximal théorique de l’interface. Ethernet/CPL - capacité du port Ethernet coté box d’où provient la requête de l’API. Wi-Fi - débit maximum théorique proposé par le Wi-Fi de l’AP de l'IAD d’où provient la requête de l’API (Kb/s) - élément présent lorsque "Lan complexity = Direct" ou "Lan complexity = Complex".
type: integer
format: int64
minimum: 0
"lan" => "speedLan" => "uploadMax": 1000000
description: Débit maximal théorique de l’interface. Ethernet/CPL - capacité du port Ethernet coté box d’où provient la requête de l’API. Wi-Fi - débit maximum théorique proposé par le Wi-Fi de l’AP de l'IAD d’où provient la requête de l’API (Kb/s) - élément présent lorsque "Lan complexity = Direct" ou "Lan complexity = Complex".
type: integer
format: int64
minimum: 0
"lan" => "speedLan" => "download": 0
description: Estimation du débit utile descendant sur le LAN (Ethernet / Wi-Fi / CPL) du segment limitant du lien IAD-Terminal requêtant l'API. Wi-Fi - le débit wifi remonté est calculé selon une formule commune, partagée par tous (Kb/s) - élément présent lorsque "Lan complexity = Direct" ou "Lan complexity = Complex".
type: integer
format: int64
minimum: 0
"lan" => "speedLan" => "upload": 0
description: Estimation du débit utile montant sur le LAN (Ethernet / Wi-Fi / CPL) du segment limitant du lien IAD-Terminal requêtant l'API. Wi-Fi - le débit wifi remonté est calculé selon une formule commune, partagée par tous (Kb/s) - élément présent lorsque "Lan complexity = Direct" ou "Lan complexity = Complex".
type: integer
format: int64
minimum: 0
"lan" => "speedLan" => "duplex": "full"
description: Mode Ethernet entre l'IAD et le terminal - élément présent lorsque la connexion LAN est "Ethernet" et "Lan complexity = Direct" ou "Lan complexity = Complex".
type: string
enum: [half, full]
-
Section LAN - Wi-Fi
"lan" => "wifi" => "ieeeMax": "6E"
description: Norme Wifi IEEE 802.11 la plus élevée supportée par la box. Un chiffre représentant chaque technologie (802.11a => 1 ; 802.11b => 2 ; 802.11g => 3 ; 802.11n => 4 ; 802.11ac => 5 ; 802.11ax => 6 ; 802.11be => 7...) - élément présent lorsque la connexion LAN est "Wi-Fi" et "Lan complexity = Direct" ou "Lan complexity = Complex".
type: string
"lan" => "wifi" => "ieee": "6E"
description: Norme Wifi IEEE 802.11 négociée entre l'IAD et le terminal requêtant l'API. Un chiffre représentant chaque technologie (802.11a => 1 ; 802.11b => 2 ; 802.11g => 3 ; 802.11n => 4 ; 802.11ac => 5 ; 802.11ax => 6 ; 802.11be => 7...) - élément présent lorsque la connexion LAN est "Wi-Fi" et "Lan complexity = Direct" ou "Lan complexity = Complex".
type: string
"lan" => "wifi" => "radioBand": "6"
description: Bande radio Wi-Fi utilisée par le terminal requêtant l’API. Bloc de fréquence de 2,4 GHz, bloc de fréquence de 5 GHz ou bloc de fréquence de 6 Ghz. Une chaine de caractère représente chaque technologie (Bande 2,4 Ghz => 2 ; Bande 5 Ghz => 5 ; Bande 6 Ghz => 6) - élément présent lorsque la connexion LAN est "Wi-Fi" et "Lan complexity = Direct" ou "Lan complexity = Complex".
type: string
"lan" => "wifi" => "rssi": -50
description: Calcul à l’instant t par l’AP de l’IAD de la puissance du signal radio reçu du terminal (requêtant l’API). Facultatif - Le calcul est la moyenne des mesures RSSI effectuées sur chacune des antennes de l’AP (dBm) - élément présent lorsque la connexion LAN est "Wi-Fi" et "Lan complexity = Direct" ou "Lan complexity = Complex".
type: string
format: int64
maximum: 0
-
Section LAN - Calcul d'un cross-trafic sur le LAN (ex: accès à un film sur le NAS de la box)
"lan" => "byteCounter" => "download": 2021748595
description: Relevé du compteur de trafic descendant (IAD => terminal utilisateur) du port LAN (octets) - élément facultatif, certains FAI le renseignement, d'autre non.
type: integer
format: int64
minimum: 0
"lan" => "byteCounter" => "upload": 4292080939
description: Relevé du compteur de trafic montant (terminal utilisateur => IAD) du port LAN (octets) - élément facultatif, certains FAI le renseignement, d'autre non.
type: integer
format: int64
minimum: 0
Section Timestamp
"timestamp" => "apiCallTime": 1672830235
description: Horodatage correspondant à l'heure à laquelle l'API est requêtée.
type: integer
format: int64
minimum: 0
"timestamp" => "lastUpdate": 1672830234
description: Horodatage de la dernière mise à jour du compteur du port WAN (si le compteur est relevé en temps réel alors LastUpdate = ApiCallTime).
type: integer
format: int64
minimum: 0
-
"apiVersion": 4312662016
Version de l'API. 32 premiers bits - évolutions majeures (évolutions concertées avec l'ensemble des opérateurs et l'Arcep), 32 derniers bits - évolutions mineures (numérotation propre à chaque opérateur).
type: integer
format: int64
"id": "af6b2d8c-0c29-4734-80a6-b426249d7406"
Identifiant unique du test (récupéré lors du 1er appel). Permet de faire le lien entre le premier et le second appel.
type: string
format: uuid
-
Je suis intéressé pour avoir des retours de l'API sur tous les modèles de box supportés par l'API.
Une simple copie d'écran, sans oublier d'indiquer l'offre chez votre FAI, le modèle de box et comment le PC est connecté à la box et si vous avez des équipements intermédiaires tels qu'un switch ou CPL entre votre PC et la box.
-
Offre : Freebox Delta
Modèle : F-GW07B - Freebox v7 (r1)
Connexion : DAC direct du PC à la Box
(https://lafibre.info/images/barometre/202301_api_arcep_freebox_delta_r1_1.webp)
-
Par contre, c'est en vrac si on utilise ses propres DNS car dans mon cas (NB6VAC aussi), l'adresse apibox.sfr.net n'est pas résolu.
Pour contrer ça, il suffit d'ajouter dans /etc/hosts :
192.168.1.1 apibox.sfr.net
Avec la bonne ip bien sur.
PS: je n'utilise pas systemd-resolved, mais unbound.
Offre : Red-By-SFR
Modèle : NB6VAC-FXC-r0
Firmware : NB6VAC-MAIN-R4.0.45d
Connexion : ONT sur Box puis RJ45 via quelques switchs Ethernet en 1Gbits/s, donc le retour de la box est OK.
(https://lafibre.info/images/barometre/202301_api_arcep_box_sfr_3.webp)
-
Offre : SFR Fibre Power 8 (2gb/500mb réalité: 2gb / 800mb-1gb)
Box : Box 8 ( connectée au pc en test via divers switch 1GB )
(https://lafibre.info/images/barometre/202301_api_arcep_box_sfr_4.webp)
-
Section WAN - ByteCounter pour le cross-traffic
"wan" => "byteCounter" => "download": 2021748595
description: Relevé du compteur de trafic descendant (internet => IAD) du port WAN (octets).
type: integer
format: int64
minimum: 0
"wan" => "byteCounter" => "upload": 4292080939
description: Relevé du compteur de trafic montant (IAD => internet) du port WAN (octets).
type: integer
format: int64
minimum: 0
J'ai du mal a comprendre l'utilité de donner ces infos
-
fonctionne normalement chez moi
Freebox pop ZTD P2P, pc connecté en direct sur la box en 2.5gbps
(https://lafibre.info/images/barometre/202301_api_arcep_freebox_pop.webp)
-
J'ai du mal a comprendre l'utilité de donner ces infos
En faisant la différence entre les compteurs avant et après le test de débit, on peut détecter une activité en arrière plan (ou d'une autre machine) qui a pu fausser le résultat.
Ça permettrait donc d'avertir l'utilisateur, et aussi d'en tenir compte dans les statistiques.
-
Connecté en Wifi 5 sur une livebox 4 avec un SFP. Offre Sosh 300/300 symétrique.
(https://lafibre.info/images/barometre/202301_api_arcep_livebox4_sfp.webp)
-
J'ai du mal a comprendre l'utilité de donner ces infos
L'API est interrogée deux fois en début de test et en fin de test.
Deux appels API sont visibles car il y a deux appels : juste avant de réaliser le test et après.
La différence sur les compteurs « Wan/ByteCounter » entre l'appel final et l'appel initial permet de connaitre le nombre d'octets qui a été utilisé sur la box.
L'outil de test de débit va comparer par rapport au trafic qu'il a lui-même généré et, s'il y a un écart significatif, il peut conclure qu'il y a eu un trafic tiers pendant le test de débit.
Ce trafic tiers peut fausser le test, il faudra donc l'exclure du baromètre.
Exemple : Cela permet de détecter une box TV allumée sur une connexion ADSL ou une mise à jour Windows update qui se lance durant le test de débit. Bref, c'est un système de plus pour fiabiliser la mesure.
-
Quelle est la marge d'erreur dans le comptage/comparaison de trafic ?
-
De même en ce qui me concerne, Freebox Delta r1, windows 10 et Firefox. Connexion 10 Gb/s par câble DAC.
On voit que le modèle de box n'est pas indiqué, seul le débit down et up, que c'est du FTTH...
P.S ! J'ai un switch Mikrotik CRS-305 SFP+ en intermédiaire.
(https://lafibre.info/images/barometre/202301_api_arcep_freebox_delta_r1_2.webp)
-
Exemple : Cela permet de détecter une box TV allumée sur une connexion ADSL ou une mise à jour Windows update qui se lance durant le test de débit. Bref, c'est un système de plus pour fiabiliser la mesure.
ouais effectivement c'est logique.
-
Je complète mon tutoriel et je m'aperçois que je n'ai pas l'URL de Bouygues Telecom.
4/ Filtrer les URL pour obtenir uniquement les requêtes de l'API : rentrer api de façon à n'avoir que des lignes :
- Orange : api-infoacces.orange.fr
- Free : api-arcep.proxad.net
- SFR : apibox.sfr.net
Un abonné Bouygues Telecom (FyyH / xDSL peu importe du moment que la box est pas trop veille) pourrait suivre est m'indiquer l'URL utilisée et tant qu'à faire le retour de l'API ?
-
Et si la box a été remplacée par un routeur tiers ?
On a Erreur 501 Not Implemented chez SFR (et probablement chez les autres opérateurs)
(https://lafibre.info/images/barometre/202303_api_arcep_box_sfr_changee_par_routeur_tiers.webp)
-
Bouygues avec box remplacée par un routeur tiers.
Le contenu de retour
{"error":"Error from backend","errorDescription":"internal_server_error, unable_to_process"}
-
Merci, grâce à toi, j'ai enfin les 4 URL utilisée par les opérateurs :
- Bouygues Telecom : qos.bouygtel.fr:39443 ⇒ 89.95.242.77 / 2001:860:de00::89:77
- Orange : api-infoacces.orange.fr ⇒ pas d'IPv4 / 2a01:cb09:2040:8005::3
- Free : api-arcep.proxad.net ⇒ 213.36.23.1 / 2a01:e00:41:1201::1
- SFR : apibox.sfr.net ⇒ 109.0.64.176 / 2a02:8400:4:c0:4449:4147:a7ce:0
On se demande la mouche qui a piqué Bouygues pour le choix du port 39443 à la place du 443 habituel.
Ce port serait bloqué dans certains cas exotiques où Bouygues cherche à exclure de l'API ? (Car sans API le test pourrait ne pas être pris en compte dans le baromètre nPerf).
-
J'étais curieux si l'appel API était authentifié ou non. On voit bien le "Authorization: Basic" puis une chaine de caractères encodée en Base64. L'outil suivant permet de décoder le token https://jwt.io/
-
Mais le token n'est valable que 10 minutes de mémoire et uniquement pour l'adresse IP de la ligne.
Ils ont sécurisé la chose comme si cela transportait des données bancaires.
-
d'un côté, tant mieux, un mauvais acteur pourrait récupérer un token et l'utiliser sur son site pour collecter des infos permettant d'affiner encore plus le ciblage.
J'étais juste curieux s'il y avait des infos intéressantes dans le JWT.
-
Ces cas ou bien entendu été analysé lors du développement, les opérateurs ont souhaité le maximum de sécurité.
Certains ici trouvent que l'API est trop sécurisée / fermée cf l'intervention de kgersen et les messages en dessous :
y'a t'il un moyen légal de saisir l'ARCEP ou l'autorité de la concurrence ou le parlement pour contester la mise en œuvre cette API ?
J'aimerais aussi que cela soit plus ouvert, mais ce n'est pas simple de concilier les demande de sécurité des opérateurs et des demandes pour une ouverture.