Auteur Sujet: Pourquoi un Speedtest n'est pas un DoS (Lu 172 fois)

brupala · « **le:** 11 novembre 2025 à 15:19:32 »

[Edit modération : hors sujet déplacé, en provenance de https://lafibre.info/gpon/50g-pon/msg1138348/#msg1138348]

Citation de: Leon le 11 novembre 2025 à 13:11:13

C'est quasi certain qu'il y a des mécanismes de QoS, de style Round-Robin ou équivalent, au niveau du GPON et des techno PON.
La preuve? Sur un même arbre GPON, si un utilisateur sature sa connexion (avec des flux UDP plus grand que le tuyau par exemple), alors il voit son ping augmenter fortement, avec des pertes de paquet, et pourtant les ping des autres utilisateur restent normaux.
C'est certain que ça existe en uplink, et il faudrait tester ça pour la partie downlink; il est probable que ça existe aussi en downlink, pour gérer le cas d'un utilisateur qui se prend un (D)DoS, pour ne pas que ça impacte ses voisins.
Je vous invite à faire le test.
Et même à l'intérieur d'un unique accès, d'un unique client, il y a priorisation entre le flux téléphonique et le reste. Souvent avec un VLAN séparé prioritaire pour la téléphonie.
Ces mécanismes sont en effet indispensables.

Les protocoles mobiles sont bourrés de mécanismes QoS comme ça, pour répartir équitablement les ressources, limiter, prioriser. J'imagine que ces mécanismes existent aussi pour les techno PON.

Si des clients constatent ici qu'il y a des pertes de paquet chez leur FAI (Free comme nous le dit kgersen) alors il serait temps de changer de FAI. Un FAI FTTH normal n'a pas de perte de paquets. Moins de 0.1% de perte sur un FTTH normal.

Leon.

A ce propos,
je me demande comment on peut faire des speedtest à 2 Gbit/s sur un GPON ou à 8 Gbit/s sur XG-PON, pareil pour la flux montant, mesuré proche du débit total du lien multiplexé.
Ou alors, ce sont des valeurs pic en fait mesurées sur 1 ou 2 millisecondes, ce qui est suffisant à ces débits (c'est déjà pas mal d'octets et de paquets IP), 1 seconde à 8 Gbit/s, c'est 1 GO soit 1 million de paquets de 1K octets, 1 ms suffirait donc pour mesurer 1000 paquets, 200 paquets sur 1 GPON , je me demande pourquoi les speedtest ont l'air de durer 10s alors qu'une ms de saturation du support suffit, mais bon il y a le temps de connexion de deux ou 3 sessions TCP.
Ce qui fait que quelques ms de saturation de la liaison sur un test de débit devient relativement indolore, tant qu'il n'y en a pas 500 en même temps.

Paul · « **Réponse #1 le:** 11 novembre 2025 à 18:07:02 »

C'est le temps que la fenêtre TCP s'adapte, pour avoir une moyenne significative. Le débit ne peut pas être au maximum dès le début.

Leon · « **Réponse #2 le:** 11 novembre 2025 à 18:38:23 »

Citation de: brupala le 11 novembre 2025 à 15:19:32

A ce propos,
je me demande comment on peut faire des speedtest à 2 Gbit/s sur un GPON ou à 8 Gbit/s sur XG-PON, pareil pour la flux montant, mesuré proche du débit total du lien multiplexé.
Ou alors, ce sont des valeurs pic en fait mesurées sur 1 ou 2 millisecondes, ce qui est suffisant à ces débits (c'est déjà pas mal d'octets et de paquets IP), 1 seconde à 8 Gbit/s, c'est 1 GO soit 1 million de paquets de 1K octets, 1 ms suffirait donc pour mesurer 1000 paquets, 200 paquets sur 1 GPON , je me demande pourquoi les speedtest ont l'air de durer 10s alors qu'une ms de saturation du support suffit, mais bon il y a le temps de connexion de deux ou 3 sessions TCP.
Ce qui fait que quelques ms de saturation de la liaison sur un test de débit devient relativement indolore, tant qu'il n'y en a pas 500 en même temps.

La question n'est pas super claire, donc je réponds peut-être à côté de la plaque, tu me diras.
En fait, il y a saturer et saturer... Le mot saturation a plusieurs signification du côté des "spécialistes". Je pense que c'est ça qui te pose des problèmes de compréhension.
Un speed test n'a pas pour vocation à pousser plus de donnée qu'il ne peut en rentrer dans le tuyau, l'objectif n'est pas de faire un DoS sur ta connexion et de la détruire.
Le speedtest va utiliser les protocoles standard de contrôle de flux : TCP-RWIN/SWIN, BBR, Cubic, etc... Tout ça pour ajuster en temps réel le débit à ce que permet réellement la liaison IP, de bout en bout, entre le serveur et toi, sans pour autant détruire la liaison.
Ces algorithme sont très efficaces, surtout sur une liaison stable de bout en bout, et ils poussent juste ce qu'est capable de tenir ta liaison IP.
Ils détectent la limite avec la détection de paquets perdus dès que ça sature réellement, et ils perdent très peu de paquets au final.
Donc en gros, tu atteins 99% du maxi de ta connexion, automatiquement.

A l'opposé, n'importe qui peut coder ou utiliser un test dégueulasse qui consiste à envoyer en UDP plus qu'il ne peut rentrer dans le tuyau, et constater que ça détruit la liaison (et en downstream, ça fait parfois tilter des protections dans les équipements du FAI). C'est le principe du DoS.

Leon.

brupala · « **Réponse #3 le:** 11 novembre 2025 à 19:37:30 »

Citation de: Leon le 11 novembre 2025 à 18:38:23

La question n'est pas super claire, donc je réponds peut-être à côté de la plaque, tu me diras.
En fait, il y a saturer et saturer...
Le speedtest va utiliser les protocoles standard de contrôle de flux : TCP-RWIN/SWIN, BBR, Cubic, etc... Tout ça pour ajuster en temps réel le débit à ce que permet réellement la liaison IP, de bout en bout, entre le serveur et toi, sans pour autant détruire la liaison.
Ces algorithme sont très efficaces, surtout sur une liaison stable de bout en bout, et ils poussent juste ce qu'est capable de tenir ta liaison IP.
Ils détectent la limite avec la détection de paquets perdus dès que ça sature réellement, et ils perdent très peu de paquets au final.
Donc en gros, tu atteins 99% du maxi de ta connexion, automatiquement.

A l'opposé, n'importe qui peut coder ou utiliser un test dégueulasse qui consiste à envoyer en UDP plus qu'il ne peut rentrer dans le tuyau, et constater que ça détruit la liaison (et en downstream, ça fait parfois tilter des protections dans les équipements du FAI). C'est le principe du DoS.

Leon.

Oui, en fait on ne se comprend pas bien:
Mon propos était de dire que les résultats d'un speedtest montrent que l'on peut utiliser à ce moment là toute la capacité du multiplex (l'arbre PON), si on met localement toutes les chances de son côté, mais que ça ne doit durer que quelques ms car ça n'impacte pas beaucoup les autres utilisateurs.
Le reste, qui plus ton propos:
Forcément, si ça durait plusieurs minutes ça ferait certainement un gros DOS de pas mal de gens, et pas que sur l'arbre sans doute, surtout sur un XG-PON où les uplink de l'OLT ne sont sans doute pas beaucoup plus puissants, mais sur quelques centaines de paquets IP, ça ne se voit pas.
Après, c'est sensé mesurer la partie la plus faible de la liaison seulement, pas la plus puissante, c'est influencé sur la charge globale bien sûr, à ce moment là les mécanismes de fenêtres et algo TCP vont entrer en ligne de compte, donc je pense que le résultat c'est juste un comptage de ce qui est reçu de chaque bout au total, l'idée étant d'avoir plusieurs connexions en parallèle pour continuer sur d'autres si une fenêtre TCP se retrouve bloquée.
Un test iperf qui potentiellement peut durer beaucoup plus longtemps serait bien plus destructeur, surtout si on le fait en UDP, mais heureusement, il y a une limite de débit dans ce cas (1 Mbit/s il me semble).

Leon · « **Réponse #4 le:** 11 novembre 2025 à 19:46:10 »

Citation de: brupala le 11 novembre 2025 à 19:37:30

Oui, en fait on ne se comprend pas bien:
Mon propos était de dire que les résultats d'un speedtest montrent que l'on peut utiliser à ce moment là toute la capacité du multiplex (l'arbre PON), si on met localement toutes les chances de son côté, mais que ça ne doit durer que quelques ms car ça n'impacte pas beaucoup les autres utilisateurs.

Je pense que tu n'as toujours pas compris le principe.
Un test de débit reste au débit maxi beaucoup plus que quelques millisecondes! C'est plutôt une dizaine de secondes.
Et si tu constates que tu peux faire quasiment 2.4Gb/s sur un arbre GPON et quasi 8Gb/s sur un arbre XGPON, c'est que ces arbres PON sont tout simplement très très peu remplis. C'est aussi simple que ça.
La plus grande partie du temps, un utilisateur lambda ne génère quasiment aucun trafic sur son FTTH monstrueusement grand, ou juste 1 ou 2 streaming de 10Mb/s, ou un flux 4k à 20-30Mb/s, ce qui est bien maigre par rapport aux 8Gb/s vendus.
(Oui, on peut faire 600 à 800 streaming HD sur un XGSPON sur lequel il y a une cinquantaine d'abonnés maxi).
Du jeu en ligne (hors téléchargement d'update), c'est quelques Mb/s tout au plus.
Un appel visio Whatsapp sur un smartphone, c'est quelques Mb/s.
Je continue, ou alors tu as compris ?
Et non, un speed test ne perturbera évidemment pas les autres utilisateurs.

Leon.

brupala · « **Réponse #5 le:** 11 novembre 2025 à 20:21:53 »

Citation de: Leon le 11 novembre 2025 à 19:46:10

Je pense que tu n'as toujours pas compris le principe.
Un test de débit reste au débit maxi beaucoup plus que quelques millisecondes! C'est plutôt une dizaine de secondes.
Et si tu constates que tu peux faire quasiment 2.4Gb/s sur un arbre GPON et quasi 8Gb/s sur un arbre XGPON, c'est que ces arbres PON sont tout simplement très très peu remplis. C'est aussi simple que ça.
La plus grande partie du temps, un utilisateur lambda ne génère quasiment aucun trafic sur son FTTH monstrueusement grand, ou juste 1 ou 2 streaming de 10Mb/s, ou un flux 4k à 20-30Mb/s, ce qui est bien maigre par rapport aux 8Gb/s vendus.
(Oui, on peut faire 600 à 800 streaming HD sur un XGSPON sur lequel il y a une cinquantaine d'abonnés maxi).
Du jeu en ligne (hors téléchargement d'update), c'est quelques Mb/s tout au plus.
Un appel visio Whatsapp sur un smartphone, c'est quelques Mb/s.
Je continue, ou alors tu as compris ?
Et non, un speed test ne perturbera évidemment pas les autres utilisateurs.

Leon.

Bon, je vais continuer aussi, bien que je comprenne parfaitement ton propos, qui encore une fois n'est pas le mien, tu parles de la charge des autres flux et je te parle de la charge du test lui même, c'est pourtant pas compliqué non plus.
Effectivement le test s'affiche pendant plusieurs secondes, mais je réfléchissais qu'il n'est sans doute pas continu, mais qu'il fonctionne peut-etre par bursts de flux pendant quelques ms, puis une pause pendant quelques centaines de ms entre chaque, afin de pousser au max le débit, mais sans bloquer tout le monde.
Maintenant j'arrête là mes réflexions et j'essaierai de faire des captures plus précises à l'occasion, histoire d'éclairer un peu ce petit mystère de saturer une liaison sans la bloquer.

Leon · « **Réponse #6 le:** 11 novembre 2025 à 20:44:23 »

J'avais bien compris, mais tu te trompes encore une fois.
Un speed test, c'est un flux continu de données. Tu as le ramp-up normal au début, le temps que l'algo de gestion de flux converge, puis c'est un flux continu au maxi pendant 5 à 10 secondes.
Donc ça ne fonctionne pas du tout comme tu l'imagines, ça ne fonctionne pas avec des burst espacés.
Ce que tu imagines ne permettrait pas de bénéficier de l'algo de gestion de flux, c'est impossible avec de petits burst.

Vivien avait fait plein de captures différentes ici même, avec des courbes de débit instantané pendant les speed-tests.

Leon.

brupala · « **Réponse #7 le:** 11 novembre 2025 à 21:37:23 »

Citation de: Leon le 11 novembre 2025 à 20:44:23

J'avais bien compris, mais tu te trompes encore une fois.
Un speed test, c'est un flux continu de données. Tu as le ramp-up normal au début, le temps que l'algo de gestion de flux converge, puis c'est un flux continu au maxi pendant 5 à 10 secondes.
Donc ça ne fonctionne pas du tout comme tu l'imagines, ça ne fonctionne pas avec des burst espacés.
Ce que tu imagines ne permettrait pas de bénéficier de l'algo de gestion de flux, c'est impossible avec de petits burst.

Vivien avait fait plein de captures différentes ici même, avec des courbes de débit instantané pendant les speed-tests.

Leon.

Donc, on bloquerait tout l'arbre le temps du test pour lire un résultat du niveau du débit global ?? ou alors on n'arriverait à des résultats minables si d'autres ont la même idée à ce moment là ?
De plus, je ne pense pas que le but soit d'utiliser l'algo de gestion TCP, si on peut l'éviter.

Leon · « **Réponse #8 le:** 11 novembre 2025 à 22:20:43 »

Citation de: brupala le 11 novembre 2025 à 21:37:23

Donc, on bloquerait tout l'arbre le temps du test pour lire un résultat du niveau du débit global ?? ou alors on n'arriverait à des résultats minables si d'autres ont la même idée à ce moment là ?
De plus, je ne pense pas que le but soit d'utiliser l'algo de gestion TCP, si on peut l'éviter.

J'abandonne. Tu pars avec beaucoup trop d'à-priori, de fausses idées que tu n'arrives pas à défaire de ta tête. J'ai tout expliqué dans mes précédents messages, je t'invite à les relire calmement, en essayant au maximum d'oublier tes idées préconçues.
Et si d'autres membres veulent prendre le relais pour expliquer avec des mots différents des miens, pourquoi pas.

Leon.

brupala · « **Réponse #9 le:** 11 novembre 2025 à 22:52:45 »

Citation de: Leon le 11 novembre 2025 à 22:20:43

J'abandonne. Tu pars avec beaucoup trop d'à-priori, de fausses idées que tu n'arrives pas à défaire de ta tête. J'ai tout expliqué dans mes précédents messages, je t'invite à les relire calmement, en essayant au maximum d'oublier tes idées préconçues.
Et si d'autres membres veulent prendre le relais pour expliquer avec des mots différents des miens, pourquoi pas.

Leon.

Effectivement,
je serais preneur d'autres explications plus techniques, oui, les tiennes, qui sont plutôt des affirmations, genre ça

Citer

En fait, il y a saturer et saturer... Le mot saturation a plusieurs signification du côté des "spécialistes". Je pense que c'est ça qui te pose des problèmes de compréhension.

n'arrivent pas à m'éclairer.

Pegasus38 · « **Réponse #10 le:** 11 novembre 2025 à 23:11:43 »

Tu cherches pas à comprendre tu cherches à affirmer quelque chose sur un sujet que tu ne maitrises pas.
Aucun speedtest peut "bloqué" comme tu dis, un arbre.
Les arbres sont quasi vide et quand bien même y aurait du monde ça changerait rien.

brupala · « **Réponse #11 le:** **Hier** à 00:05:51 »

Citation de: Pegasus38 le 11 novembre 2025 à 23:11:43

Tu cherches pas à comprendre tu cherches à affirmer quelque chose sur un sujet que tu ne maitrises pas.
Aucun speedtest peut "bloqué" comme tu dis, un arbre.
Les arbres sont quasi vide et quand bien même y aurait du monde ça changerait rien.

je parlais le temps du test, je l'ai dit plein de fois, pas du reste du temps, si on le remplit avec le speedtest, il est beaucoup moins vide non ?
Si les arbres sont si vides que ça, sans speedtest, pourquoi y a t-il plein de gens ici à réclamer du XG-pon voire du 50GPON comme on parle ici à la base ?