La Fibre
Télécom => Réseau => 
TCP/IP / Fonctionnement des réseaux => Discussion démarrée par: 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]
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.
-
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.
-
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.
-
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).
-
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.
-
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.
-
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.
-
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.
-
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.
-
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 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.
-
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.
-
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 ?
-
Y a un multiplexage temporel dans les PON. Chacun des membres de l'arbre a un slot temporel ça t'empêche de d'empiéter sur le voisin Tu peux pas garder le micro ou l'écouteur indéfiniment pour bloquer un voisin pendant un speedtest
-
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à ?
Si tu es tout seul à faire ton speedtest sur ton arbre PON, si les autres utilisateurs ne font quasiment rien (quelques dizaines de Mb/s demandés), alors oui l'ONT réserve 99% de la resource de cet arbre juste pour toi.
Il est très très peu probable que 2 speed-tests soient réalisés en même temps par 2 des ~50 utilisateurs d'un même arbre.
Un speed test c'est 5 à 10 secondes, et les utilisateurs en font peut être 1 à 10 par jour grand maximum. 1 seul speedtest quotidien par utilisateur utilise quasi toute la bande passante pendant seulement 0.01% du temps (10s / 3600s / 24h).
Et pour finir, si 2 utilisateurs d'un même arbre PON font un speedtest exactement en même temps, à la seconde près, alors ils verront les débits divisés par 2, pour chacun d'entre eux, l'ONT faisant une allocation équitable de la bande passante.
De plus, je ne pense pas que le but soit d'utiliser l'algo de gestion TCP, si on peut l'éviter.
Encore un à priori qu'il faut défaire de ton cerveau. L'algo de congestion / flow-control TCP est tout le temps utilisé pour chercher automatiquement le débit maxi atteignable. Ca n'est pas juste utilisé dans les situations exceptionnelles/dégradées.
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 ?
2 réponses à cette question "pourquoi les gens achètent du 8Gb/s"
- pour une raison qui m'a toujours échappée, beaucoup de gens aiment avoir toujours plus, même s'ils ne savent pas à quoi ça leur servira (à jouer à qui a la plus grosse? A s'auto-satisfaire avec un speed-test); et ils pensent que 8Gb/s c'est mieux que 1Gb/s. Moi je sais que pour mon usage et pour 99% des usages ça n'est pas le cas.
- Du 8Gb/s, ça va accélérer les gros téléchargements de plusieurs dizaines de Go. Gros update de jeu par exemple. Sauf qu'un gros téléchargement de 100Go à disons 4Gb/s (peu de serveurs atteignent 8Gb/s), ça va durer 5 minutes; au lieu de 20-30 minutes avec du 1Gb/s. Donc c'est du confort. Mais 5 minutes c'est très très court dans le temps, ça ne va saturer l'arbre que pendant 5 minutes, et il est une nouvelle fois peu probable qu'un autre utilisateur de l'arbre veuille faire un speedtest exactement en même temps.
Leon.
-
- Du 8Gb/s, ça va accélérer les gros téléchargements de plusieurs dizaines de Go. Gros update de jeu par exemple. Sauf qu'un gros téléchargement de 100Go à disons 4Gb/s (peu de serveurs atteignent 8Gb/s), ça va durer 5 minutes; au lieu de 20-30 minutes avec du 1Gb/s. Donc c'est du confort. Mais 5 minutes c'est très très court dans le temps, ça ne va saturer l'arbre que pendant 5 minutes, et il est une nouvelle fois peu probable qu'un autre utilisateur de l'arbre veuille faire un speedtest exactement en même temps.
Leon.
Outre énormément d'autres usages plus pro à la maison (qui certe sont 0.1% possiblement des usager), ce confort et gain de temps est pour certain non négligeable!
Un exemple, plutôt que d'avoir plein de disque dur etc, je télécharge les jeux à la volés quand je joue, supprime, et le récup la prochaine fois, pourquoi m'embéter à stocker quand cela va me prendre 1/2min à télécharger.
-
Y a un multiplexage temporel dans les PON. Chacun des membres de l'arbre a un slot temporel ça t'empêche de d'empiéter sur le voisin Tu peux pas garder le micro ou l'écouteur indéfiniment pour bloquer un voisin pendant un speedtest
Tout à fait d'accord, mais les slots sont dynamiques et affectés à l'usager qui en a besoin, j'aimerais bien connaitre le principe de l'algo d'affectation d'ailleurs :) Est ce que c'est en fonction des files d'attente dans l'olt et l'ont ?
-
Outre énormément d'autres usages plus pro à la maison (qui certe sont 0.1% possiblement des usager), ce confort et gain de temps est pour certain non négligeable!
Un exemple, plutôt que d'avoir plein de disque dur etc, je télécharge les jeux à la volés quand je joue, supprime, et le récup la prochaine fois, pourquoi m'embéter à stocker quand cela va me prendre 1/2min à télécharger.
C'est à mon avis plus 0,01%, et pour les jeux je doute que tu supprimes le jeu le soir avant de te coucher pour le télécharger à nouveau le lendemain ? Et un jeu à télécharger et à installer il faut plus que 2mn !
-
C'est à mon avis plus 0,01%, et pour les jeux je doute que tu supprimes le jeu le soir avant de te coucher pour le télécharger à nouveau le lendemain ? Et un jeu à télécharger et à installer il faut plus que 2mn !
Cela m'arrive assez souvant en fait ;D surtout quand je veux tester un jeux sur game pass sur une soirée histoire de...
En fonction du jeux et de la plateform, par exemple steam, le téléchargement et l'installation ce fait en même temps, ayant une machine qui suit sans soucis, cela peut tout à fait prendre 2min de bout en bout ;)
-
Cela m'arrive assez souvant en fait ;D surtout quand je veux tester un jeux sur game pass sur une soirée histoire de...
En fonction du jeux et de la plateform, par exemple steam, le téléchargement et l'installation ce fait en même temps, ayant une machine qui suit sans soucis, cela peut tout à fait prendre 2min de bout en bout ;)
C'est vrai que ce truc là a dû augmenter le traffic, le catalogue est tellement grand. Et les jeux aujourd'hui ne font plus 40Go...
Préparez vous à la sortie de GTA VI où tout le monde (estimé à plus de 20M de joueurs) va télécharger 200Go le jour J. Même si ceux qui ont préco auront déjà une pré instal sur leur console, beaucoup vont acheter le jour J.
Là pour le coup je pense qu'Internet va casser.
Pour en revenir au 50G PON, car c'est le sujet de base.
Pas besoin de 50Gb/s, même 4Gb/s suffisent largement pour télécharger/installer un jeux au max des capacité de l'ordinateur et des serveurs en face.
-
C'est vrai que ce truc là a dû augmenter le traffic, le catalogue est tellement grand. Et les jeux aujourd'hui ne font plus 40Go...
Préparez vous à la sortie de GTA VI où tout le monde (estimé à plus de 20M de joueurs) va télécharger 200Go le jour J. Même si ceux qui ont préco auront déjà une pré instal sur leur console, beaucoup vont acheter le jour J.
Là pour le coup je pense qu'Internet va casser.
Pour en revenir au 50G PON, car c'est le sujet de base.
Pas besoin de 50Gb/s, même 4Gb/s suffisent largement pour télécharger/installer un jeux au max des capacité de l'ordinateur et des serveurs en face.
Sur le 50Gb/s et plus, je commence à comprendre le test d'Orange dans un sens.
Pour utiliser beaucoup xcloud/geforce now (malgré ma machine perso) et en pensant au futur, je pense que dans 10/20ans cela pourrait devenir la norme et on achetera plus de console ou pc gaming, just l'interface (headset vr/manette) et tout sera joué via le cloud. Cela fonctionne tellement bien aujourd'hui qu'avec des techo encore mieux et plus rapide, cela va vite devenir indicernable
-
Tout à fait d'accord, mais les slots sont dynamiques et affectés à l'usager qui en a besoin, j'aimerais bien connaitre le principe de l'algo d'affectation d'ailleurs :) Est ce que c'est en fonction des files d'attente dans l'olt et l'ont ?
L'algo en uplink dans un ONT c'est du Round-Robin ou du Weighted-Round-Robin. Et évidemement ça dépend de si chaque utilisateur a (encore) des données à envoyer. Calculé en temps réel, mis à jour en permanence. C'est optimisé, ça ne réserve pas de slots quand ça n'est pas nécessaire et que ça pourrait dégrader la qualité pour les autres.
En downlink, je ne sais pas.
Leon.
-
Je continue mes explications pour brupala
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.
Tu as compris ce que faisaient les algorithme de flow-control TCP? Ils ajustent en temps réel le débit à ce que sait supporter ta liaison IP entre ton serveur de speed-test et ton PC. En faisant en sorte de ne pas saturer, de ne pas DOS, de ne pas détruire ta liaison. En gros ils réussissent réellement à utiliser ~98-99% de ce qui est disponible. Et ce en perdant assez peu de paquets.
Et un Speedtest, ça n'est pas foncièrement différent d'un téléchargement. Donc un téléchargement qui dure plusieurs minutes à "vitesse maximale", c'est possible, et ça ne détruira pas ta liaison, grâce à l'algo de flow-control! Si tu télécharges plusieurs dizaines de Go, tu seras dans ce cas là, c'est équivalent à un speedtest de plusieurs minutes.
Et évidemment, la taille du "tuyau" pour 1 seul utilisateur d'un arbre GPON, elle varie en temps réel en fonction de ce que font les autres sur ton arbre GPON, grâce au Round-Robin.
Donc il y a bien 2 algorithmes imbriqués qui marchent de concert
- le round-robin du GPON qui réparti la bande passante entre les utilisateurs, de manière équitable et en temps réel, en fonction des besoins de utilisateurs
- l'algo de flow-control TCP de ton téléchargement / speedtest, qui ajuste en temps réel la quantité de données qui sont "poussées", en fonction de la bande passante disponible (qui est fonction de ce que le round-robin GPON a décidé à la strate du dessous).
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.
Si tu as compris ce que j'explique au dessus, alors tu comprendras que ton idée têtue de "bloquer tout le monde" n'a pas de sens. Il n'y a aucune raison qu'un speedtest ou un téléchargement bloque tout le monde.
Leon.
-
La limite de 8 Gbps côté client doit aussi bien aider étant donné que c'est au moins du 10 Gbps derrière, non ? Impossible pour un seul accès de saturer la collecte de l'arbre à lui tout seul. Je ne sais pas si c'est pour cette raison que tous les FAI nationaux donnent 8 et pas 10... mais ça me semble probable :)
Si les 128 clients d'un arbre se mettaient tous à faire un speedtest en même temps, ça devrait laisser environ 120 Mbps par personne. Ça reste mieux que le VDSL ! (bien sûr, dans un environnement parfait ou il n'y a qu'un seul arbre sur cette collecte, et sans tenir compte de la charge utile dans le débit etc.)
-
L'explication usuelle pour la limite a 8 Gbps est l'activation obligatoire du FEC en XGS-PON.
Si on suit la norme: https://www.itu.int/epublications/en/publication/itu-t-g-9807-1-2023-02-10-gigabit-capable-symmetric-passive-optical-network-xgs-pon/en
page 152 (ou section C.10.1.3 en web): le FEC est un code de correction d'erreur de type RS(248,216) donc en gros pour 248 octets transmis, 216 sont utiles , 32 sont des octets de parité. Ca fait donc sur un débit nominal de 9,95328 Gps , un débit utile de 8,66 Gbps ( 9,95328 x 216/248 ). C'est du "line rate" (débit couche 2) pas du débit réseau (IP) ou speedtest (couche 7 ou 4).
Dans la couche PON on fait passer de l'Ethernet dans des paquets GEM et dans Ethernet y'a des entetes, un numero de VLAN, etc donc ca rajoute des bits.
Au niveau couche 2 en comptant VLAN et 1500 MTU on arrive a 8,389 Gbps. Qui serait le max théorique du XGS-PON au niveau 2 (juste avant IP).
┌───────────────────────────────────────────────┐
│ Layer 3: IP (IPv4/IPv6) │
├───────────────────────────────────────────────┤
│ Layer 2: Data Link │
│ ├─ Ethernet MAC (user traffic) │
│ └─ PON TC + GEM encapsulation (PON L2) │
├───────────────────────────────────────────────┤
│ Layer 1: Physical │
│ ├─ Optical signaling (light pulses) │
│ ├─ Line coding, timing, burst mode │
│ ├─ FEC encoding/decoding │
│ └─ Optical fiber + transceivers (medium) │
└───────────────────────────────────────────────┘
Ensuite y'a IPv4 ou IPv6 + TCP c'est au dela qu'on mesure avec speedtest ou iperf3.
(calcul plus précis à faire mais on n'a pas toutes les données réelles).
-
La limite de 8 Gbps côté client doit aussi bien aider étant donné que c'est au moins du 10 Gbps derrière, non ? Impossible pour un seul accès de saturer la collecte de l'arbre à lui tout seul. Je ne sais pas si c'est pour cette raison que tous les FAI nationaux donnent 8 et pas 10... mais ça me semble probable :)
Si les 128 clients d'un arbre se mettaient tous à faire un speedtest en même temps, ça devrait laisser environ 120 Mbps par personne. Ça reste mieux que le VDSL ! (bien sûr, dans un environnement parfait ou il n'y a qu'un seul arbre sur cette collecte, et sans tenir compte de la charge utile dans le débit etc.)
Bon, je vais en remettre une couche:
Si tu pompes le max on va dire 8 Gbit/s d'un arbre XG-Gpon, il me parait clair que le temps que tu fais ça, si vous êtes 128, les 127 autres ont zéro à l'instant I. Si ça dure 1ms, ça fait 1MO de données et c'est transparent, si ça dure 10s, ça fait 10 GO mais ça va faire tousser, les multiplexages vont normalement intervenir pour diminuer ta gourmandise et répartir plus équitablement la bande en fonction des besoins des autres.
Après, la régulation TCP, si on est seul ou que les autres morceaux de la liaison ont beaucoup plus ne se mettra pas en route et essaiera de pousser au maximum de la liaison, ça ne ralentira que si le flux est contrarié par d'autres éléments, concurrence, ralentissements pour bufferisation en files d'attente et au pire perte de paquets et retransmissions, là le débit tcp va très vite s'écrouler si ça dure plusieurs secondes/minutes, c'est à ce moment là que les algos TCP vont intervenir pour optimiser, mais sur le (les flux) du speedtest seulement, pas sur les autres utilisateurs, pour les autres c'est aux matériels actifs du réseau d'agir, au pire en mettant à la corbeille une partie des flux les plus gênants, si ils ne sont pas marqués prioritaires, QOS ordinaire quoi.
Si je calcule bien, à 8 Gbit/s, un paquet de 1000 octets dure à peu près 1 micro seconde, donc retarder une dizaine de paquets, pour en passer d'autres, ça ne change pas grand chose.
un test nperf que j'ai mesuré approximativement sur un lien 1 Gbit/s envoie environ 700 000 paquets, un toutes les 35µs en gros, ça laisse donc peu de temps le support libre, contrairement à ce que je pensais.
-
Je me suis permis de déplacer ce hors sujet dans une section plus appropriée. Vous pouvez continuer la discussion sans problème.
Leon.
-
Et moi je vais en remettre une couche :
Orange te vend 8Gb/s mais la vraie limitation du XGS-PON c'est 10Gb/s (un peu moins)
-
Après, la régulation TCP, si on est seul ou que les autres morceaux de la liaison ont beaucoup plus ne se mettra pas en route et essaiera de pousser au maximum de la liaison, ça ne ralentira que si le flux est contrarié par d'autres éléments, concurrence, ralentissements pour bufferisation en files d'attente et au pire perte de paquets et retransmissions, là le débit tcp va très vite s'écrouler si ça dure plusieurs secondes/minutes,
source pour le passage en gras?
c'est à ce moment là que les algos TCP vont intervenir
ils interviennent tout le long du téléchargement
https://fr.wikipedia.org/wiki/Algorithme_TCP
pour optimiser, mais sur le (les flux) du speedtest seulement, pas sur les autres utilisateurs, pour les autres c'est aux matériels actifs du réseau d'agir, au pire en mettant à la corbeille une partie des flux les plus gênants, si ils ne sont pas marqués prioritaires, QOS ordinaire quoi.
source pour le passage en gras?
Si je calcule bien, à 8 Gbit/s, un paquet de 1000 octets dure à peu près 1 micro seconde, donc retarder une dizaine de paquets, pour en passer d'autres, ça ne change pas grand chose.
latence
un test nperf que j'ai mesuré approximativement sur un lien 1 Gbit/s envoie environ 700 000 paquets, un toutes les 35µs en gros, ça laisse donc peu de temps le support libre, contrairement à ce que je pensais.
le temps pour faire quoi?
-
Un Déni de service, c'est généralement beaucoup plus que le débit que peut atteindre TCP.
Par exemple envoyer 20 Gb/s vers un client c'est du DOS.
-
Même si le forum n'est pas réprésentatif (je l'espère en tout cas sinon ouch ::)), et c'est une chose que l'on aura certainement jamais, mais je serais très curieux d'avoir le pourcentage de bande passante mensuel de speedtest/nperfs etc chez les fournisseurs.
-
Un Déni de service, c'est généralement beaucoup plus que le débit que peut atteindre TCP.
Par exemple envoyer 20 Gb/s vers un client c'est du DOS.
probablement, oui, je ne pratique pas ça et la victime ne voit qu'une partie du volume qui l'attaque.
-
source pour le passage en gras?
La source c'est des tests que je faisais autrefois sur des réseaux avec beaucoup d'erreurs, et sur des débits beaucoup plus faibles.
c'est à ce moment là que les algos TCP vont intervenir
ils interviennent tout le long du téléchargement
Certes ils sont là mais sans effet si la liaison est stable, l'effet ne se fait sentir qu'en cas de problèmes afin de les compenser le plus tôt possible, une liaison sans erreurs et pas trop chargée par exemple entre 2 ports de switch à même débit, on n'a besoin d'aucun algo, on bourre, c'est tout, les cas extrêmes sont gérés au niveau applis ou pas du tout.
le temps pour faire quoi?
pour passer un autre flux important quoi, sans ralentir le nôtre.
au pire en mettant à la corbeille une partie des flux les plus gênants, si ils ne sont pas marqués prioritaires, QOS ordinaire quoi.
source pour le passage en gras?
Pareil des tests sur des lignes bas débit saturées.
<mode vieux C..>
C'est sûr que c'est d'une autre époque les liaisons avec beaucoup d'erreurs et les lignes "bas débit" à, on va dire, moins de 1 Mbit/s avec les produits d'aujourd'hui la QOS est en voie de disparition car de plus en plus inutile. une latence de quelques microsecondes ne gêne pas grand monde en principe.
</mode vieux C..>
-
Après, la régulation TCP, si on est seul ou que les autres morceaux de la liaison ont beaucoup plus ne se mettra pas en route et essaiera de pousser au maximum de la liaison, ça ne ralentira que si le flux est contrarié par d'autres éléments, concurrence, ralentissements pour bufferisation en files d'attente et au pire perte de paquets et retransmissions, là le débit tcp va très vite s'écrouler
[les protocoles de flow control]Certes ils sont là mais sans effet si la liaison est stable, l'effet ne se fait sentir qu'en cas de problèmes afin de les compenser le plus tôt possible, une liaison sans erreurs et pas trop chargée par exemple entre 2 ports de switch à même débit, on n'a besoin d'aucun algo, on bourre, c'est tout, les cas extrêmes sont gérés au niveau applis ou pas du tout.
Je confirme que tu n'as pas compris ce qu'étaient les algos de flow control TCP, où ils étaient utiles, comment ils se déclenchaient. Mais alors pas du tout.
- Non, un flux TCP ne bourre pas bêtement le maximum de ce que sait faire le serveur, sans algo de flow control, contrairement à ce que tu dis, c'est tout le contraire. Si c'était ça, alors internet s'écroulerait totalement en permanence!!!
- "essayer de pousser au maximum de la liaison" comme tu le dis, ça n'est possible qu'avec un algo de flow control, c'est lui qui détecte automatiquement ce qu'est le débit "maximum de la liaison".
- Les algo de flow control TCP ne sont pas du tout réservés aux situations "en cas de problème, d'erreur, de liaisons instables". PAS DU TOUT!
- Non, la limitation de débit n'est pas gérée au niveau des "applications" (=Layer 7), pas du tout, dans le cas d'un téléchargement ou d'un speedtest. (une limitation au niveau applicatif c'est surtout pour du streaming à débit variable en UDP, mais c'est un autre sujet).
- Les algo de flow control TCP sont utiles tout le temps, et les effets se font sentir dès que l'application pourrait pousser/tirer plus de débit qu'il ne peut en passer sur la liaison, ce qui est très très fréquent:
1) très fréquent, sur un téléchargement classique, et même sur un streaming par burst via TCP, etc...
2) systématique en cas de test de débit, c'est bien ce que tu cherches à tester justement! C'est bien le débit "lissé" obtenu par l'algo de flow control TCP (après ramp up et convergence de quelques secondes) qui sera le résultat de ton test de débit. (Et très souvent le débit volontairement cumulé / réparti sur plusieurs TCP-sessions, mais c'est un détail ici.)
3) extrêmement fréquent sur une liaison à débit limité comme une connexion 4G/5G à quelques Mb/s ou dizaines de Mb/s, même si cette liaison est stable
Bref, je t'invite une nouvelle fois à oublier tes à priori faux, à relire nos messages, à te renseigner sur ces algo de flow control TCP et surtout de leur utilité, et à faire des tests de téléchargement "bridés par la liaison". N'importe qui peut régler une interface Ethernet à 10 ou 100Mb/s par exemple et faire une capture WireShark sur un téléchargement bridé par cette liaison à 100Mb/s, c'est un très bon exercice; en mettant un ping en parallèle, c'est encore mieux pour comprendre; la latence (ping) augmente mais ne s'envole pas grâce au flow control de la connexion TCP d'à côté, et la perte de paquet est faible. Le débit réel du téléchargement monte progressivement et rapidement, et s'adapte automatiquement aux 100Mb/s disponibles, tout ça grâce à ton algo de flow control TCP, avec très peu de pertes de paquet, juste ce qu'il faut comme paquets "sacrifiés" pour que l'algo de flow control puisse détecter la capacité maxi de la liaison.
Leon.
-
Cubic et BBR sont les deux algorithmes les plus utilisés côté serveur pour décider de la vitesse d’envoi des paquets par TCP :
• Cubic, créé en 2006, s’appuie sur la perte de paquets comme signal pour réduire le débit. Cubic est l’algorithme d’évitement de congestion utilisé par défaut sous Linux (qui équipe la majorité des serveurs sur internet), mais aussi Android et macOS. C’est la valeur par défaut d’Ubuntu 22.04 LTS.
• BBR : Google a développé en 2016 BBR (pour « Bottleneck Bandwidth and Round-trip propagation time »), qui utilise un modèle différent, s’appuyant sur la bande passante maximale et le temps d’aller-retour (RTT ou « round trip time »). Cette approche permet à BBR, quand une connexion perd des paquets, de proposer un débit nettement plus élevé que ceux offerts par les algorithmes s’appuyant sur la perte de paquets, comme Cubic. Aujourd’hui, BBR est de plus en plus utilisé par certains grands acteurs de l’Internet, notamment sur les serveurs proposant HTTP/3, la nouvelle norme HTTP de troisième génération. Cependant, BBR n’est pas encore généralisé sur internet notamment en raison de problématiques d’équité des flux. En effet, sur un même lien où le débit est partagé entre utilisateurs (exemple : les fréquences du réseau mobile ou un lien fibre), les connexions BBR vont « prendre la place » des connexions Cubic. Une version « BBRv3 » sera finalisé fin 2024. Déjà utilisé sur YouTube et google.com, BBRv3 améliore les performances de BBR et devrait permettre une meilleure cohabitation avec Cubic, en ce qu’il permet un partage de liens avec ce dernier. Note : « BBRv2 » n'a jamais été finalisé.
Source : Arcep - Configuration des serveurs pour l'enquête QoS mobile 2025 (https://www.arcep.fr/fileadmin/user_upload/grands_dossiers/qualite-services-mobiles/202412_arcep_configuration_enquete_qos_mobile_2025.pdf#page=5)
-
Je confirme que tu n'as pas compris ce qu'étaient les algos de flow control TCP, où ils étaient utiles, comment ils se déclenchaient. Mais alors pas du tout.
Non, un flux TCP ne bourre pas bêtement, sans algo de flow control, contrairement à ce que tu dis, c'est tout le contraire.
Les algo de flow control TCP ne sont pas du tout réservés aux situations "en cas de problème, d'erreur, de liaisons instables". PAS DU TOUT!
Les algo de flow control TCP sont utiles tout le temps,dès que l'application pourrait pousser/tirer plus de débit qu'il ne peut en passer sur la liaison[/b], ce qui est très très fréquent:
! C'est bien le débit "lissé" obtenu par l'algo de flow control TCP qui sera le résultat de ton test de débit. (Et très souvent le débit volontairement cumulé / réparti sur plusieurs TCP-sessions, mais c'est un détail ici.)
Leon.
Discours assez contradictoire:
Comment on peut pousser plus que la capacité de la liaison ?? Pourquoi on met des liaisons de fou alors ?
Pourquoi on met justement plusieurs flux tcp en parallèle, si ça n'est pas pour contourner les contrôles de flux et blocages de TCP ?
Ou alors les algos gèrent les flux multiples, ce qui serait une découverte pour moi.
A ce que j'ai compris, c'est le but recherché par QUIC aussi.
Dans ce que j'ai appris, les fameux algo ne font que recalculer la fenêtre, en l'agrandissant ou la réduisant, je ne pense pas qu'ils réduisent le gap interpaquets à l'émission entre buffer et port ou changent la MSS et s'ils augmentent le gap , ça réduit le débit, donc, tant que la fenêtre est ouverte, on continue, en plus je pense aussi qu'ils n'agissent que côté émetteur, je ne vois pas comment on peut faire venir plus vite sur un récepteur, juste moins vite en fermant la fenêtre.
Après, je n'ai pas dit que le débit était réglé au niveau application, mais que c'est là que l'on peut finir par relancer une situation catastrophique comme c'est le cas en UDP: si pas de réponse, on recommence la requête.
-
Cubic et BBR sont les deux algorithmes les plus utilisés côté serveur pour décider de la vitesse d’envoi des paquets par TCP :
• Cubic, créé en 2006, s’appuie sur la perte de paquets comme signal pour réduire le débit. Cubic est l’algorithme d’évitement de congestion utilisé par défaut sous Linux (qui équipe la majorité des serveurs sur internet), mais aussi Android et macOS. C’est la valeur par défaut d’Ubuntu 22.04 LTS.
• BBR : Google a développé en 2016 BBR (pour « Bottleneck Bandwidth and Round-trip propagation time »), qui utilise un modèle différent, s’appuyant sur la bande passante maximale et le temps d’aller-retour (RTT ou « round trip time »). Cette approche permet à BBR, quand une connexion perd des paquets, de proposer un débit nettement plus élevé que ceux offerts par les algorithmes s’appuyant sur la perte de paquets, comme Cubic. Aujourd’hui, BBR est de plus en plus utilisé par certains grands acteurs de l’Internet, notamment sur les serveurs proposant HTTP/3, la nouvelle norme HTTP de troisième génération. Cependant, BBR n’est pas encore généralisé sur internet notamment en raison de problématiques d’équité des flux. En effet, sur un même lien où le débit est partagé entre utilisateurs (exemple : les fréquences du réseau mobile ou un lien fibre), les connexions BBR vont « prendre la place » des connexions Cubic. Une version « BBRv3 » sera finalisé fin 2024. Déjà utilisé sur YouTube et google.com, BBRv3 améliore les performances de BBR et devrait permettre une meilleure cohabitation avec Cubic, en ce qu’il permet un partage de liens avec ce dernier. Note : « BBRv2 » n'a jamais été finalisé.
Source : Arcep - Configuration des serveurs pour l'enquête QoS mobile 2025 (https://www.arcep.fr/fileadmin/user_upload/grands_dossiers/qualite-services-mobiles/202412_arcep_configuration_enquete_qos_mobile_2025.pdf#page=5)
Donc c'est bien reconnaitre en fait que les algos sont là pour améliorer les choses au mieux quand il y a un problème et sont inactifs quand tout va bien et que les fenêtres tcp ne passent pas en mode compte goutte, ce qui fait bien qu'ils réduisent le moins possible le débit, mais le réduisent au strict besoin, ne l'accélèrent jamais.
-
- Les algo de flow control TCP sont utiles tout le temps, et les effets se font sentir dès que l'application pourrait pousser/tirer plus de débit qu'il ne peut en passer sur la liaison, ce qui est très très fréquent:
Comment on peut pousser plus que la capacité de la liaison ??
Comment on pourrait pousser plus que ne permet la liaison s'il n'y avait pas de flow control? C'est très simple. Internet c'est constitué de liaisons mises bout à bout qui ont chacune des débits très différents.
Il existe des liaisons à 400Gb/s ou 1Tb/s (entre gros routeurs) et des liaisons à 1Mb/s (un smartphone 4G/5G en limite de réception). Facteur 1 million entre les deux...
Exemple concret: un serveur connecté à 10Gb/s à Internet pourra pousser les 10Gb/s. Un accès FTTH 1Gb/s ne sait recevoir que 1Gb/s.
Le serveur sait pousser physiquement disons 8 ou 9Gb/s constants sans difficulté. En UDP (si aucun bridage routeur), tu sais pousser 8Gb/s vers le client 1Gb/s.
Donc la liaison entre les deux est limitée à 1Gb/s et ton flux UDP à 8Gb/s va saturer/DoS la connexion du client FTTH, la rendre inutilisable. Saturation du buffer de l'ONT qui va rejeter la majorité des paquets, grosse perte de paquets.
C'est bien pour ça qu'on a des bridages UDP sur certains accès FTTH (tous?) ou des serveurs (VPS, serveur dédié), pour éviter de pourrir, de faire du DoS avec de l'UDP, c'est très facile de faire du DoS avec de l'UDP.
En TCP, grâce au flow control naturel de TCP, toujours avec le même serveur et le même client, le débit s'adapte automatiquement au facteur limitant, donc à un peu moins de 1Gb/s dans notre exemple, même si le serveur sait pousser beaucoup plus. Et l'accès FTTH reste utilisable pour d'autres usages en parallèle, car le flow-control TCP va "respecter" les autres flux en parallèle qui passent par le lien à 1Gb/s.
Leon.
-
Comment on peut pousser plus que la capacité de la liaison ?? Comment on pourrait pousser plus que ne permet la liaison s'il n'y avait pas de flow control? C'est très simple. Internet c'est constitué de liaisons mises bout à bout qui ont chacune des débits très différents.
Il existe des liaisons à 400Gb/s ou 1Tb/s (entre gros routeurs) et des liaisons à 1Mb/s (un smartphone 4G/5G en limite de réception). Facteur 1 million entre les deux...
Exemple concret: un serveur connecté à 10Gb/s à Internet pourra pousser les 10Gb/s. Un accès FTTH 1Gb/s ne sait recevoir que 1Gb/s.
Le serveur sait pousser physiquement disons 8 ou 9Gb/s constants sans difficulté. En UDP (si aucun bridage routeur), tu sais pousser 8Gb/s vers le client 1Gb/s.
Donc la liaison entre les deux est limitée à 1Gb/s et ton flux UDP à 8Gb/s va saturer/DoS la connexion du client FTTH, la rendre inutilisable. Saturation du buffer de l'ONT qui va rejeter la majorité des paquets, grosse perte de paquets.
C'est bien pour ça qu'on a des bridages UDP sur certains accès FTTH (tous?) ou des serveurs (VPS, serveur dédié), pour éviter de pourrir, de faire du DoS avec de l'UDP, c'est très facile de faire du DoS avec de l'UDP.
En TCP, grâce au flow control naturel de TCP, toujours avec le même serveur et le même client, le débit s'adapte automatiquement au facteur limitant, donc à un peu moins de 1Gb/s dans notre exemple, même si le serveur sait pousser beaucoup plus. Et l'accès FTTH reste utilisable pour d'autres usages en parallèle, car le flow-control TCP va "respecter" les autres flux en parallèle qui passent par le lien à 1Gb/s.
Leon.
On tourne vraiment en rond avec ces explications qui n'en sont pas:
Une liaison c'est une chaine et son débit total est celui du maillon le plus faible, donc le dernier lien dans ton exemple (très répandu effectivement).
Bien sûr le serveur peut pousser 10 fois plus, mais sur d'autres connexions tcp et sur d'autres clients.
Après, le flow control TCP ne gère que sa propre connexion, il ne s'occupe pas des connexions voisines, juste de ce qui est disponible pour lui sur la ligne et si effectivement d'autres l'occupent aussi, il devra réduire son flux, non pas pour protéger les autres, mais parce que les autres ne lui laissent pas la place, et si ta connexion baisse trop, les autres prendront la place si ils en ont besoin, il peinera à la reprendre, c'est le multiplexage statistique, ou dans le cas d'un arbre gpon, temporel dynamique (à un moindre degré car l'OLT va garder plus d'opportunités à chacun).
Quand à UDP, si il envoie 10 fois plus que le dernier lien peut supporter, 90% des paquets passeront à la poubelle au niveau des files d'attente du dernier routeur, qui ne peut pas empiler indéfiniment, soit ils ne comportent pas d'information importante et ça fera des trous dans de la voix ou de la pixelisation sur une vidéo, soit l'appli devra refaire une requête pour ce qui est perdu en espérant que ça passe, bien sûr les autres connexions tcp ou autres ne passeront pas non plus, donc DOS, plouf :-\
Il vaut donc mieux qu'un émetteur UDP soit réglé par l'appli qui l'utilise et suspende ses envois en attendant des acquittements applicatifs (je pense à un transfert TFTP par exemple) car la plupart des connexions UDP sauf streaming RTP c'est une requête et on attend une réponse avant d'en envoyer une autre, en évitant les réponses trop longues .
-
Il est assez dur de t'expliquer car tu pars avec trop d'apriori.
Pour une affirmation fausse :
Comment on peut pousser plus que la capacité de la liaison ??
Tu vois tout le texte de Leon nécessaire à t'expliquer pourquoi oui on peut.
Sauf que tes posts sont remplis d’apriori, souvent faux.
Si tu veux vraiment comprendre, laisse tout tes aprioris de côté et pose toi la question du comment.
Pour chaque élément que où tu émets l'hypothèse, vérifie si c'est vraiment le mécanisme que tu imagines derrière.
Car ça risque de prendre du temps de t'expliquer si à chaque fois tu poses des bases fausses.
Quelques éléments à revoir sur tes derniers posts où tu as l'air sur de toi sans vraiment savoir l'élément sous jacent:
Bien sûr le serveur peut pousser 10 fois plus, mais sur d'autres connexions tcp et sur d'autres clients.
=> tu sembles pas avoir bien compris le poste de Leon. Tu peux envoyer 10 fois plus qu'une liaison d'un client. Exemple plus tôt de vivien sur le DOS de 20G vers un client. La deuxième partie de ton affirmation est donc fausse. Sauf que tu as l'air sur de toi sur ce point.
juste de ce qui est disponible pour lui sur la ligne et si effectivement d'autres l'occupent aussi, il devra réduire son flux
Affirmation, pose toi la question du comment derrière. Quel mécanisme est utilisé ?
non pas pour protéger les autres, mais parce que les autres ne lui laissent pas la place
Comment ?
et si ta connexion baisse trop, les autres prendront la place si ils en ont besoin, il peinera à la reprendre
Comment et pourquoi ?
c'est le multiplexage statistique, ou dans le cas d'un arbre gpon, temporel dynamique (à un moindre degré car l'OLT va garder plus d'opportunités à chacun).
Je connais moins le gpon mais ça parait confus aussi.
Tu dois te poser la question du comment pour chaque affirmation que tu donnes.
J'ai l'impression que tu affirmes des choses sans vraiment savoir le mécanisme technique sous jacent.
Si tu ne sais pas décrire précisément le mécanisme qui appui tes affirmations, c'est qu'il y a des chances que tes affirmations sont fausses.
-
Il est assez dur de t'expliquer car tu pars avec trop d'apriori.
Pour une affirmation fausse :
Tu vois tout le texte de Leon nécessaire à t'expliquer pourquoi oui on peut.
Sauf que tes posts sont remplis d’apriori, souvent faux.
.......
C'est encore plus difficile d'expliquer quand on se contente de porter un jugement sans aucun argument autre que "puisqu'on te le dit" :o
Personne ne pourra me faire croire qu'envoyer 10 Gbit/s sur une ligne qui est physiquement à 1 Gbit/s est possible, même si tous les liens avant sont à 40 Gbit/s. ça pourrait l'être en 10 fois plus de temps, bien sûr, si on avait une bufferisation gigantesque et des attentes d'acquitement tout autant énormes, mais ça n'existe pas à grande échelle, le débordement passe à la poubelle, plouf....
-
C'est encore plus difficile d'expliquer quand on se contente de porter un jugement sans aucun argument autre que "puisqu'on te le dit" :o
Personne ne pourra me faire croire qu'envoyer 10 Gbit/s sur une ligne qui est physiquement à 1 Gbit/s est possible, même si tous les liens avant sont à 40 Gbit/s. ça pourrait l'être en 10 fois plus de temps, bien sûr, si on avait une bufferisation gigantesque et des attentes d'acquitement tout autant énormes, mais ça n'existe pas à grande échelle, le débordement passe à la poubelle, plouf....
Relis bien, personne n'a dit qu'on pouvait envoyer 10Gb/s sur une ligne 1Gb/s.
Un serveur peut pousser 10Gb/s en UDP de son côté, oui, sans problème (si les routeurs lui autorisent). Même s'il s'adresse à un client qui a un accès 1Mb/s ou 1Gb/s. Ca va saturer et DoS la liaison, oui, c'est la 3ieme fois que je le dis.
Et sinon, quel est le mécanisme magique qui fait qu'un serveur 10Gb/s ne pousse en TCP que 1Gb/s sur un accès FTTH 1Gb/s, sans que le serveur sache à l'avance qu'il s'agit d'un accès limité à 1Gb/s ?
...roulement de tambour....
Le mécanisme magique c'est l'algorithme de flow control TCP bien sur! (avec les acquittements, les window de taille dynamiquement variable, etc...).
Voilà, la boucle est bouclée, je m'arrêterai probablement là.
La "littérature" est pléthorique sur le sujet.
Leon.
-
Relis bien, personne n'a dit qu'on pouvait envoyer 10Gb/s sur une ligne 1Gb/s.
Un serveur peut pousser 10Gb/s en UDP de son côté, oui, sans problème (si les routeurs lui autorisent). Même s'il s'adresse à un client qui a un accès 1Mb/s ou 1Gb/s. Ca va saturer et DoS la liaison, oui, c'est la 3ieme fois que je le dis.
.....
OK, tu modifies maintenant en parlant d'un serveur via UDP, sans parler des mécanismes propres à UDP dont j'ai déjà parlé, les acquittements applicatifs destinés à limiter la chose.
Après, sur TCP, je ne conteste pas, c'est le principe de base de TCP sur un serveur, j'ai même expliqué que les fameux algos ne faisaient que calculer une fenêtre optimale. Au passage, l'élément faible débit n'est pas forcément à l'autre bout, il peut être au milieu de la liaison globale aussi (cas d'un lien wan en backup par exemple), donc on explique la même chose: TCP ne fait que ralentir le flux pour s'adapter aux conditions de la liaison, c'est juste pour ça qu'il a été inventé, mais ça n'est pas la question initiale.
Sur un speedtest, il y a normalement plusieurs flux tcp, avec donc des autres pour prendre le relais si un est au bout de sa fenetre TCP, afin d'aller au max possible de la liaison, en contournant justement les algos de contrôle de flux, si bien que si il n'y avait pas de TCP, ou un TCP avec sa fenêtre bloquée au max (1 GO avec l'option extension au max), on n'aurait plus guère de contrôle de flux, équivalent à UDP à la possibilité de retransmission près. Sachant que les retransmissions des paquets augmentent encore la saturation des liens, mais c'est toujours mieux que de reprendre au début.
-
C'est encore plus difficile d'expliquer quand on se contente de porter un jugement sans aucun argument autre que "puisqu'on te le dit" :o
J'avais préparé une réponse plus longue mais https://www.rfc-editor.org/rfc/rfc5681.html suffira. C'est "comme ça" parce que c'est un standard.
[...] en contournant justement les algos de contrôle de flux [...]
"The Internet, to a considerable degree, relies on the correct
implementation of these algorithms in order to preserve network
stability and avoid congestion collapse."
Tu te rends bien compte qu'enlever le frein à main fait parti des abus du réseau qui peut valoir une rupture de contrat de ton FAI ?
-
J'avais préparé une réponse plus longue mais https://www.rfc-editor.org/rfc/rfc5681.html suffira. C'est "comme ça" parce que c'est un standard.
"The Internet, to a considerable degree, relies on the correct
implementation of these algorithms in order to preserve network
stability and avoid congestion collapse."
Tu te rends bien compte qu'enlever le frein à main fait parti des abus du réseau qui peut valoir une rupture de contrat de ton FAI ?
houla, on se calme,
il faut arrêter de tout déformer,
je n'ai jamais dit autre chose, surtout pas qu'il n'en fallait pas dans TCP, il n'existerait pas sans eux, par contre, c'est clair pour moi que quand on ouvre plusieurs connexions tcp en parallèle avec le même serveur, c'est une manière de les contourner, et j'ai dit aussi qu'ils n'ont rien à faire quand le réseau est stable, par exemple entre deux ports d'un même switch.
Il n'y a pas que les FAI dans la vie des réseaux et j'argumente sur un plan plus général que ta vision.
Après, sur les forums, on voit plus de gens qui se plaignent des limitations des FAI que de gens dont les abus sur leur connexion leur vaut résiliation de connexion quoique,
ça m'est arrivé une fois, ça n'est pas le sujet, c'est pour l'anecdote:
C'était à une époque heureusement révolue où il n'y avait même pas d'adsl chez moi, je me connectais en RTC (Numéris) avec donc un accès T0 et ça devait être avec 9telecom à ce moment là, j'ai eu plusieurs accès gratuits avec communications pas gratuites, mais prix d'une com locale. Toujours est-il que ce FAI ne facturait pas bien cher, mais on n'avait droit qu'à une seule connexion à la fois avec le compte. Il se trouve qu'un accès RNIS T0 permettait (on peut mettre au passé) deux connexions simultanées sur 2 canaux B donc 2 fois 64Kbit/s, héoui.
Au départ, j'avais un adaptateur RNIS simple, on ne peut pas parler de modem, qui ne savait utiliser qu'un seul canal B, il ne savait pas agréger, mais ensuite, j'ai mis un routeur qui savait faire ça, donc passer à 128K.
Hélas 9T a vu ça comme 2 connexions différentes (alors que je l'ai fait chez d'autres FAI) et a donc décidé de me résilier, je suis ensuite passé chez AOL ou Free, je ne sais plus, en attendant l'adsl.
Bref je peux donc me vanter d'avoir été exclu par un FAI.
-
Sur un speedtest, il y a normalement plusieurs flux tcp, avec donc des autres pour prendre le relais si un est au bout de sa fenetre TCP, afin d'aller au max possible de la liaison, en contournant justement les algos de contrôle de flux
ah? ça sort d'où ça encore?
si bien que si il n'y avait pas de TCP, ou un TCP avec sa fenêtre bloquée au max (1 GO avec l'option extension au max), on n'aurait plus guère de contrôle de flux, équivalent à UDP à la possibilité de retransmission près.
et donc le rapport avec la choucroute?
relis tes premiers messages, toutes tes interrogations ont trouvé réponses.
Sachant que les retransmissions des paquets augmentent encore la saturation des liens, mais c'est toujours mieux que de reprendre au début.
De quels paquets parles-tu? trame PON/ethernet, datagramme ip, paquet http, autre? As-tu seulement compris que tes paquets couche 3 seront sousmis dans tous les cas à la QoS couche 2?
-
il faut arrêter de tout déformer,
je n'ai jamais dit autre chose, surtout pas qu'il n'en fallait pas dans TCP, il n'existerait pas sans eux, par contre, c'est clair pour moi que quand on ouvre plusieurs connexions tcp en parallèle avec le même serveur, c'est une manière de les contourner, et j'ai dit aussi qu'ils [les algo de flow control / congestion TCP] n'ont rien à faire quand le réseau est stable, par exemple entre deux ports d'un même switch.
Oui, tu as dit ça, et c'est totalement faux.
Leon.
-
De quels paquets parles-tu? trame PON/ethernet, datagramme ip, paquet http, autre? As-tu seulement compris que tes paquets couche 3 seront sousmis dans tous les cas à la QoS couche 2?
ouais, bon:
un paquet c'est L3, donc IP V4/V6 dans ce qui nous intéresse c'est tout, en L2, c'est une trame.Le L2 peut éventuellement corriger des erreurs simples, mais il ne retransmet pas (pas assez de buffers pour garder en mémoire généralement).
Un datagramme c'est un bloc de données, ça peut être un paquet si ça ne dépasse pas la MSS ou plusieurs si ça la dépasse.
ah? ça sort d'où ça encore?
oui, c'est évident, comme on a un algo qui va limiter une connexion TCP en cas de problème, en mettant plusieurs connexions en parallèle, on peut contourner la limitation d'un seul algo.
et donc le rapport avec la choucroute?
L'odeur, probablement, mais j'aime bien :)
-
Oui, tu as dit ça, et c'est totalement faux.
Leon.
Oui. Pour compléter Leon pour aller au bout et mettre en évidence le souci : comment tu sais que le réseau est stable ?
C'est là toute la question.
Donc tu dois tester et utiliser des algos de congestion à un moment donné, sinon tu n'en as aucune idée de cette stabilité que tu as décidé.
-
Oui, tu as dit ça, et c'est totalement faux.
Leon.
ah ouais ? vas y explique Leon ce qu'ils auraient à faire ? (en partant du principe qu'il n'y a pas d'autres connexions actives sur les deux ports qui viendraient en concurrence).
-
Oui. Pour compléter Leon pour aller au bout et mettre en évidence le souci : comment tu sais que le réseau est stable ?
C'est là toute la question.
Donc tu dois tester et utiliser des algos de congestion à un moment donné, sinon tu n'en as aucune idée de cette stabilité que tu as décidé.
stable, c'est stable, donc on mesure si on veut, mais on ne change rien au flux de données, ce qui est le rôle de l'algo de faire varier le flux de données en fonction des perturbations de l'environnement, mer calme, temps clair, cap automatique.
-
ah ouais ? vas y explique Leon ce qu'ils auraient à faire ? (en partant du principe qu'il n'y a pas d'autres connexions actives sur les deux ports qui viendraient en concurrence).
pourquoi parler d'une chose et changer les conditions et hypothèse dans le post d'après ?
Tu aurais vraiment du lire la RFC que j'ai mise y a les conditions de seuil d'activation des algos de congestion dedans.
-
il faut arrêter de tout déformer,
je n'ai jamais dit autre chose, surtout pas qu'il n'en fallait pas dans TCP, il n'existerait pas sans eux, par contre, c'est clair pour moi que quand on ouvre plusieurs connexions tcp en parallèle avec le même serveur, c'est une manière de les contourner, et j'ai dit aussi qu'ils [les algo de flow control / congestion TCP] n'ont rien à faire quand le réseau est stable, par exemple entre deux ports d'un même switch.
Oui, tu as dit ça, et c'est totalement faux.
ah ouais ? vas y explique Leon ce qu'ils auraient à faire ? (en partant du principe qu'il n'y a pas d'autres connexions actives sur les deux ports qui viendraient en concurrence).
C'est pourtant simple.
Soit un switch avec seulement 2 machines, un serveur et un PC client.
Soit une application qui utilise TCP, qui tourne sur le serveur connecté à 1Gb/s à ton switch, et qui est capable de générer beaucoup de débit (pas de limitation interne du à un disque dur par exemple).
Soit un PC "client" connecté à ton switch en 100Mb/s, et qui reçoit des données du serveur.
Le mécanisme flow control TCP va automatiquement limiter à 100Mb/s les données poussées par le serveur sur le réseau, et la couche TCP (le socket TCP) va informer en temps réel l'application serveur de la quantité de données que TCP a réussi à pousser sur la liaison, vu la limitation à 100Mb/s. Et si besoin l'application adaptera son comportement en conséquence.
Et ça avec une connexion parfaitement stable (stable = qui ne varie pas dans le temps), en étant tout seul sur ton réseau, sans aucune perturbation.
Voilà voilà.
Je vais finir par faire payer ces cours de TCP/IP pour débutant. LOL. ;)
Tiens, je mets la définition Wikipedia que je trouve plutôt bien écrite
https://fr.wikipedia.org/wiki/Contr%C3%B4le_de_flux
Le contrôle de flux, dans un réseau informatique ou un réseau de télécommunications, représente un asservissement du débit binaire de l'émetteur vers le récepteur.
Quand une machine a un débit montant supérieur au débit descendant de la destination, la source diminue son débit pour ne pas submerger le puits de requêtes (obligeant parfois, lorsque le puits ne peut pas les traiter, à la ré-émission de ces dernières). Le contrôle de flux doit être différencié du contrôle de congestion, qui est utilisé pour contrôler le flux de données lorsque la congestion a déjà eu lieu. Les mécanismes de contrôle de flux sont définis par le fait que le récepteur envoie une information de retour à l'émetteur.
Leon.
-
pourquoi parler d'une chose et changer les conditions et hypothèse dans le post d'après ?
Tu aurais vraiment du lire la RFC que j'ai mise y a les conditions de seuil d'activation des algos de congestion dedans.
Effectivement, je ne la connaissais pas, elle ne concerne pas vraiment ce que je faisais, et elle bien plus récente que TCP lui même, quand je l'ai appris, on disait juste qu'il y avait une fenêtre variable calculée en fonction des évènements sur la liaison, quand l'émetteur était au bout de cette fenêtre, il mettait sur pause.
-
Oui, tu as dit ça, et c'est totalement faux.
ah ouais ? vas y explique Leon ce qu'ils auraient à faire ? (en partant du principe qu'il n'y a pas d'autres connexions actives sur les deux ports qui viendraient en concurrence).
C'est pourtant simple.
Soit un switch avec seulement 2 machines, un serveur et un PC client.
Soit une application qui utilise TCP, qui tourne sur le serveur connecté à 1Gb/s à ton switch, et qui est capable de générer beaucoup de débit (pas de limitation interne du à un disque dur par exemple).
Soit un PC "client" connecté à ton switch en 100Mb/s, et qui reçoit des données du serveur.
Le mécanisme flow control TCP va automatiquement limiter à 100Mb/s les données poussées par le serveur sur le réseau, et la couche TCP (le socket TCP) va informer en temps réel l'application serveur de la quantité de données que TCP a réussi à pousser sur la liaison, vu la limitation à 100Mb/s. Et si besoin l'application adaptera son comportement en conséquence.
Et ça avec une connexion parfaitement stable (stable = qui ne varie pas dans le temps), en étant tout seul sur ton réseau, sans aucune perturbation.
Voilà voilà.
Je vais finir par faire payer ces cours de TCP/IP pour débutant. LOL. ;)
Tiens, je mets la définition Wikipedia que je trouve plutôt bien écrite
https://fr.wikipedia.org/wiki/Contr%C3%B4le_de_flux
Le contrôle de flux, dans un réseau informatique ou un réseau de télécommunications, représente un asservissement du débit binaire de l'émetteur vers le récepteur.
Quand une machine a un débit montant supérieur au débit descendant de la destination, la source diminue son débit pour ne pas submerger le puits de requêtes (obligeant parfois, lorsque le puits ne peut pas les traiter, à la ré-émission de ces dernières). Le contrôle de flux doit être différencié du contrôle de congestion, qui est utilisé pour contrôler le flux de données lorsque la congestion a déjà eu lieu. Les mécanismes de contrôle de flux sont définis par le fait que le récepteur envoie une information de retour à l'émetteur.
Leon.
ça, je n'ai jamais dit le contraire et quand je donnais en exemple 2 ports de switch, il fallait lire deux ports au même débit, sinon c'est déjà un réseau perturbé qui oblige le switch à stocker des trames le temps que tcp limite son envoi, ce qui peut être rapide si la fenêtre est courte.
Mais bon, un switch avec des ports à débit différents, c'est à peu près la même chose que le réseau wan donné en exemple par vivien à un moment, au temps RTT près, qui a bien sûr son influence.
-
ça, je n'ai jamais dit le contraire et quand je donnais en exemple 2 ports de switch, il fallait lire deux ports au même débit, sinon c'est déjà un réseau perturbé qui oblige le switch à stocker des trames le temps que tcp limite son envoi, ce qui peut être rapide si la fenêtre est courte.
Ah bon? Je suis pourtant certain que tu as dit le contraire. Voir ci-dessous.
il faut arrêter de tout déformer,
je n'ai jamais dit autre chose, surtout pas qu'il n'en fallait pas dans TCP, il n'existerait pas sans eux, par contre, c'est clair pour moi que quand on ouvre plusieurs connexions tcp en parallèle avec le même serveur, c'est une manière de les contourner, et j'ai dit aussi qu'ils [les algo de flow control / congestion TCP] n'ont rien à faire quand le réseau est stable, par exemple entre deux ports d'un même switch.
Les algo de flow control sont actifs et indispensables même quand ton réseau est stable et non perturbé. Dire qu'ils n'ont "rien à faire", ça montre que tu n'as pas compris.
Donc maintenant on mélange les notions de stable, perturbé, et on change l'énoncé des sujet avec des switches de ports de débit identique... On n'est pas sorti de l'auberge, je vous le dit. Un switch avec des ports de débit différents serait donc un switch perturbé!!! LOL on rigole bien ici. Un switch perturbé mais stable j'espère (stable = qui ne varie pas dans le temps). Tu nous confirmeras.
Leon.
-
Ah bon? Je suis pourtant certain que tu as dit le contraire. Voir ci-dessous. Les algo de flow control sont actifs et indispensables même quand ton réseau est stable et non perturbé. Dire qu'ils n'ont "rien à faire", ça montre que tu n'as pas compris.
Donc maintenant on mélange les notions de stable, perturbé, et on change l'énoncé des sujet avec des switches de ports de débit identique... On n'est pas sorti de l'auberge, je vous le dit. Un switch avec des ports de débit différents serait donc un switch perturbé!!! LOL on rigole bien ici. Un switch perturbé mais stable j'espère (stable = qui ne varie pas dans le temps). Tu nous confirmeras.
Leon.
oui, présent, mais actif (change le débit) ou pas actif (ne change pas).
On rigole bien en effet et on s' oppose en s'échinant à répéter à peu près la même chose que l'autre ne veut pas entendre, parce que venu avec un éclairage un peu différent, un vrai forum, quoi ;D
J'espère que les cours TCP de cette discussion apporteront à d'autres, c'est l'essentiel, on n'a pas souvent occasion de parler de ça.
-
oui, présent, mais actif (change le débit) ou pas actif (ne change pas).
Il manque des mots dans ta phrase, mais j'ai compris ce que tu veux dire. Et laisse moi te dire encore une fois que tu te trompes lourdement.
La notion d'algo de flow control actif n'a rien à voir avec le fait que le débit change ou non, que l'algo change sa décision ou non; ça c'est une pure invention de ta part. Actif, ça veut juste dire que l'algo tourne, est actif, voire à la rigueur qu'il a un effet. Effet de limiter le débit poussé. même si cet effet est constant et invariant.
Si tu t'inventes tes propres définitions, on n'est pas sorti de la berge...
Je te remets la définition Wikipedia.
Le contrôle de flux, dans un réseau informatique ou un réseau de télécommunications, représente un asservissement du débit binaire de l'émetteur vers le récepteur.
Quand une machine a un débit montant supérieur au débit descendant de la destination, la source diminue son débit pour ne pas submerger le puits de requêtes (obligeant parfois, lorsque le puits ne peut pas les traiter, à la ré-émission de ces dernières). Le contrôle de flux doit être différencié du contrôle de congestion, qui est utilisé pour contrôler le flux de données lorsque la congestion a déjà eu lieu. Les mécanismes de contrôle de flux sont définis par le fait que le récepteur envoie une information de retour à l'émetteur.
Leon.
-
Après, il existe aussi une fonction plus méconnue à TCP, et pourtant essentielle : réordonner les paquets dans le bon ordre.
Car même quand il n'y a pas de perte de paquet, quand il n'y a pas de saturation, le fait d'en modifier l'ordre peut vraiment semer la pagaille.
Et c'est ce qui s'est passé chez Orne THD à ses débuts. Livré via plusieurs liens, aggrégés au paquet près (normalement on équilibre au flux près pour qu'un flux garde le même lien, du premier au dernier paquet). Donc à un instant T, une connexion pouvait utiliser 4 liens à la fois, et donc le message final était totalement désordonné car différence de longueur d'onde, différence de longueur de jarretière, etc. Ceux qui naviguaient sur Internet ou ceux qui faisaient des speedtests justement ne voyaient rien (grâce à TCP qui faisait le job en dessous)... mais ceux qui jouaient, visioconférence et autre voip, c'était une boucherie.
Donc oui, même si vous avez téléchargez cette pauvre petite page à qq Kbits en TCP sur un réseau non saturé (et dieu sait que vous en avez traversé des routeurs !), vous avez toujours une magie qui opère pour que tous mes mots que vous avez lu jusque là soient le ordre bon dans. ;)
-
Et c'est ce qui s'est passé chez Orne THD à ses débuts. Livré via plusieurs liens, aggrégés au paquet près (normalement on équilibre au flux près pour qu'un flux garde le même lien, du premier au dernier paquet). Donc à un instant T, une connexion pouvait utiliser 4 liens à la fois, et donc le message final était totalement désordonné car différence de longueur d'onde, différence de longueur de jarretière, etc. Ceux qui naviguaient sur Internet ou ceux qui faisaient des speedtests justement ne voyaient rien (grâce à TCP qui faisait le job en dessus)... mais ceux qui jouaient, visioconférence et autre voip, c'était une boucherie.
Oui, j'avais vu ça (des out of order massifs/systématiques) sur un accès FTTH SFR aussi qu'on m'avait demandé de tester / dépanner. Ca rendait le VPN d'entreprise du télétravailleur quasi inutilisable (VPN Cisco), alors que le surf web et le streaming était corrects en dehors du VPN. Le support SFR était d'une inutilité classique, impossible d'avoir le support N2 / N3. Et c'est revenu à la normal 2 ou 3 mois après "par magie" (sans doute modification du coeur de réseau SFR).
Leon.
-
Après, il existe aussi une fonction plus méconnue à TCP, et pourtant essentielle : réordonner les paquets dans le bon ordre.
Car même quand il n'y a pas de perte de paquet, quand il n'y a pas de saturation, le fait d'en modifier l'ordre peut vraiment semer la pagaille.
Et c'est ce qui s'est passé chez Orne THD à ses débuts. Livré via plusieurs liens, aggrégés au paquet près (normalement on équilibre au flux près pour qu'un flux garde le même lien, du premier au dernier paquet). Donc à un instant T, une connexion pouvait utiliser 4 liens à la fois, et donc le message final était totalement désordonné car différence de longueur d'onde, différence de longueur de jarretière, etc. Ceux qui naviguaient sur Internet ou ceux qui faisaient des speedtests justement ne voyaient rien (grâce à TCP qui faisait le job en dessus)... mais ceux qui jouaient, visioconférence et autre voip, c'était une boucherie.
Donc oui, même si vous avez téléchargez cette pauvre petite page à qq Kbits en TCP sur un réseau non saturé (et dieu sait que vous en avez traversé des routeurs !), vous avez toujours une magie qui opère pour que tous mes mots que vous avez lu jusque là soient le ordre bon dans. ;)
Tout à fait, mais ça c'est TCP lui même de base, c'est pas l'algo machin.
-
pour rajouter de l'eau au moulin (ou de l'huile sur le feu...): https://datatracker.ietf.org/doc/rfc8257/
et notion d'ECN notamment qui s'utilise en LAN (DC) et WAN (inter DC) privés, moins sur Internet entre opérateurs.
après l'avenir c'est QUIC donc UDP , pour ceux qui veulent creuser la différence avec TCP: https://datatracker.ietf.org/doc/html/rfc9002
-
Tout à fait, mais ça c'est TCP lui même de base, c'est pas l'algo machin.
Euh...
Le flow control (=l'algo machin) fait partie intégrante de TCP de base, depuis le début. Donc je ne comprends pas l'objet de cette phrase plus qu'étrange.
Leon.
-
Euh...
Le flow control (=l'algo machin) fait partie intégrante de TCP de base, depuis le début. Donc je ne comprends pas l'objet de cette phrase plus qu'étrange.
Leon.
La base pour moi, c'est la 793:
http://abcdrfc.online.fr/rfc-vf/rfc0793.html (http://abcdrfc.online.fr/rfc-vf/rfc0793.html)
Mais c'est sûr que les évolutions depuis le temps sont nombreuses, options, les algos, ECN ...
Lecture: https://dedu.fr/teaching/tcp/cours.pdf
-
La base pour moi, c'est la 793:
http://abcdrfc.online.fr/rfc-vf/rfc0793.html (http://abcdrfc.online.fr/rfc-vf/rfc0793.html)
Oui, et alors? TCP a toujours eu du flow control, c'est la base de la base. La RFC que tu cites en parle en long et en large. Donc je ne comprends pas trop ton message par rapport au reste de notre discussion.
Leon.
-
Flow Control et Congestion Control sont 2 choses distincts que certains mélangent parfois...
Flow Control: garantir de ne pas surcharger le récepteur, en gros envoyer les paquets au bon rythme pour que le receveur puisse les traiter. C'est une coopération entre l'émetteur et le récepteur via un échange d'informations ajoutées aux paquets du protocole TCP.
Congestion Control: empêcher de congestionner les liens et garantir a tout le monde du débit. C'est un algorithme uniquement coté émetteur donc par nature "en dehors" du protocole TCP lui meme (meme si les normes imposent que les clients TCP utilisent un algo).
Ces notions et mécanismes ne sont pas spécifiques a TCP.
Quelque soit le protocol qu'on utilise au dessus d'un lien qui peut saturer ou perdre des paquets, il faut un algo de ce genre. Donc QUIC par exemple a aussi besoin d'un algo de contrôle et les memes algos qu'on utilise avec TCP peuvent s'utiliser avec QUIC.
Dans un environnement maitrisé ou cas particulier on peut donc utiliser TCP sans algo de congestion. Par exemple sur un réseau dont on sait que ne le saturera jamais (ou TCP over TCP meme si ce n'est pas une bonne idée).
-
Oui, et alors? TCP a toujours eu du flow control, c'est la base de la base. La RFC que tu cites en parle en long et en large. Donc je ne comprends pas trop ton message par rapport au reste de notre discussion.
Leon.
du contrôle de flux par la fenêtre, oui, c'est de base aussi, mais pas des algos.
-
du contrôle de flux par la fenêtre, oui, c'est de base aussi, mais pas des algos.
Ah, donc un contrôle de flux n'est pas un algo... N'importe quoi... C'est de pire en pire ce que tu racontes!
Un algo c'est juste une logique codable, rien de plus.
Si tu te fais tes propres définitions, il est normal que l'on ne se comprenne pas, et ce depuis le début.
Leon.
-
Ah, donc un contrôle de flux n'est pas un algo... N'importe quoi... C'est de pire en pire ce que tu racontes!
Un algo c'est juste une logique codable, rien de plus.
Si tu te fais tes propres définitions, il est normal que l'on ne se comprenne pas, et ce depuis le début.
Leon.
alors là non,
il y a plein de contrôles de flux antiques qui ne sont pas des algos, juste le remplissage d'une file d'attente.
rts/cts ou xon/xoff ça te dit quelque chose ?
des fenêtres L2 sur hdlc, trames RR, les ECN/BCN sur FR .... sont gérés par de simples mécaniques, comme une butée de fin de course sur un rail, c'est paramétrable/réglable, mais pas tellement codable.
tu joues vraiment trop sur les mots Leon.
-
des fenêtres L2 sur hdlc, trames RR, les ECN/BCN sur FR .... sont gérés par de simples mécaniques, comme une butée de fin de course sur un rail, c'est paramétrable/réglable, mais pas tellement codable.
tu joues vraiment trop sur les mots Leon.
Non, je ne joue pas sur les mots, tu utilises les mots n'importe comment, et du coup personne ne te comprends.
C'est d'ailleurs peut-être ça qui rend cette conversation aussi difficile depuis le début.
Désolé, mais l'algo de base de flow control de TCP, c'est bel et bien un algo. La quinzaine de fois où je parlais d'algo de flow control TCP, sur les précédents posts, c'était bien de ça dont je parlais, il n'y avait aucune ambiguïté de ma part. Si tu as compris autre chose, à cause de tes fausses définitions, je n'y peux rien. Je t'invite donc à relire la conversation depuis le début avec ce nouvel éclairage.
Leon.
-
Si tu as compris autre chose, à cause de tes fausses définitions, je n'y peux rien. Je t'invite donc à relire la conversation depuis le début avec ce nouvel éclairage.
Leon.
Effectivement, nous avons des références un peu différentes, ancienneté de la formation probablement, bien que j'aie fait pas mal de mises à jour, y compris au travers de cette discussion, en rafraichissant des notions enterrées parce que inutiles au quotidien, et en ajoutant d'autres où j'étais passé à côté (pas forcément objet de nos discussions) parce que pas de besoin non plus, la connaissance à l'épreuve du quotidien :)
-
Effectivement, nous avons des références un peu différentes, ancienneté de la formation probablement[...]
Tu me diras quand tu as été formé. Moi c'était dans les années 90. Et je n'ai jamais travaillé dans le secteur des réseaux ou des télécom.
Et je ne pense pas que le problème d'incompréhension entre nous soit un problème de "références un peu différentes".
Leon.
-
Tu me diras quand tu as été formé. Moi c'était dans les années 90. Et je n'ai jamais travaillé dans le secteur des réseaux ou des télécom.
Et je ne pense pas que le problème d'incompréhension entre nous soit un problème de "références un peu différentes".
Leon.
ah ouais, après ça dépend ce que tu appelles formé,
Mon CV simplifié:
au niveau scolaire un BTS électrotechnique en 73, un job dans l'électronique et les télécom en 75, j'apprends l'informatique par les microprocesseurs (6800) à partir de 1980, ensuite plein de formations sur l'informatique plus bureautique dans les années 80, au niveau réseau surtout SDLC et BSC ainsi que modems divers et puis retour plus spécifique dans les télécom et réseaux en 90, surtout sur X25, de là plein de formations encore sur divers protocoles dont ethernet (cuivre et fibre) et tcpip à partir de 95 environ, les switchs, les Cisco et Nortel (à cette époque 1990-2000, les formations étaient très complètes généralités et matériel jusqu'au composant).
En 2005 , changement toujours dans les télécom, mais nouveau monde: services aux opérateurs, déploiement voix et données sur ADSL, surtout SDSL et plus tard après 2010 fibre FTTO, jusqu'à 2016, retraite presque méritée, de toute façon travail devenu sans intérêt, trop industrialisé à mon goût, mais je reste informé au top, notamment grâce à ce forum.
donc formations purement réseau étalées entre 80 et 2003 en gros, le reste autoformation.
Voilà, maintenant je me rhabille, le strip est terminé :D
-
Je réponds de manière brute en fonction du titre initial.
Un speedtest est considéré comme un genre de "service public" si il est utilisé comme tel avec une capacité calibrée... par exemple on sait que les 40 ou100Gbps seront priviliégiés des users que des serveurs 10 Gbps
Si il n'y a pas de campagne avec des trolls pour saturer le serveur de test c'est pas un DoS
Si on laisse un serveur sur du 1 Gbps et qu'on voit plein de freebox ultra/pop se connecter c'est un peu délicat
d'evoquer une saturation avec de telles capacités serveurs
En résumé plus un serveur est calibrée pour ne pas être à 100% CPU, plus il ne pourra invoquer d'être en DoS...
Un DoS peut etre invoqué quand un créateur de software bidouille avait utilisé les serveurs FTP de distro linux
pour fabriqsuer un test de vitesse multithread dans les années 2005/2010 mais zut alors a qui je pense hormis m*i ? ! ;) ;) ;) ;) ;) ;)
Je comprends pas trop le besoin de causer de cela ?
-
Je comprends pas trop le besoin de causer de cela ?
Tu as lu la discussion? Je ne pense pas.
Je comprendrais parfaitement que tu n'en n’aie pas eu le courage, vu l'absurdité d'une grande partie de la discussion. (Moi ça m'a amusé).
Je résume, pour ne pas que tu perdes du temps:
- l'ami brupala affirme des choses bizarres (et fausses) à propos des speed-test, soit disant qu'ils sont fait par burst de quelques millisecondes espacés dans le temps, pour ne pas faire du DoS sur le réseau (saturer des liaisons).
- on lui répond que non, que le flux de donnée du speedtest est automatiquement régulé par les algos de flow-control-TCP, et donc que ça ne saturera pas le réseau. Donc un speedtest est basé sur des flux de données TCP continus qui durent une dizaine de secondes. Dans ces conditions, aucun risque pour le réseau contrairement à ce que prétend brupala.
- mais le bougre insiste, et la discussion part sur d'autres sujets au grès des incompréhensions, notamment sur les termes technique, "flow control TCP" notamment.
Leon.
-
> Tu as lu la discussion? Je ne pense pas.
J'ai lu sans lire vu comment cela partait en vrille.
> Je comprendrais parfaitement que tu n'en n’aie pas eu le courage, vu l'absurdité d'une grande partie de la discussion. (Moi ça m'a amusé).
C'est un peu cela mais vu qu'en ce moment il y a de plus en plus de trolls partout donc... J'ai voulu résumer la situation en fonction du titre "brut" et court de ce sujet.
> - l'ami brupala affirme des choses bizarres (et fausses) à propos des speed-test, soit disant qu'ils sont fait par burst de quelques millisecondes espacés dans le temps, pour ne pas faire du DoS sur le réseau (saturer des liaisons).
Seuls les vieux speedtests pourri des années 2005 du style SPEEDZILLA qui te donne un resultat en 3 secondes se rapproche de cela... indiquer 14 mbit/s avec une liaison ADSL 8 mbit/s avec qui 3 downloads multithreads d'ISO durant 1 heure te fait jamais dépasser les 8 mbit/s quand on est pres du central telephonique (coucou les pas sdi anciens du forum anciens qui revaient d'habiter collé au central téléphonique ;) ca vous rappelle des souvenirs hein ?)
Bon bref. A l'epoque c'etait le download en 3/5 secondes maxi et qui donnait la vitesse de DL d'un fichier test à la cinquieme seconde qui gonflait car c'etait fake 9 fois sur 10 et la personne n'a l'idée dans tous les speedtests de 2015/2020 comme nperf et les autres librespeed de faire ainsi !!!
Maintenant pour parler d'un interet de burster X fous XX miliisecondes c'estconnu que c'est du résultat fake pourri et j'ai plus jamais vu de recentes applications style NPERF qui donnaient des résultats de telles sortes !!!
Au point de vu légal on a pas besoin de gérer un aspect DDoS car on vise dans 99,999% un serveur dédié aux speedtest dans un réseau d'ordi de style FAI et que si même on le saturait de trolls ca ferait un DoS sur un serveur sans (trop) d'interet.
donc DDoS que test-debit.free.fr sur iliad ou proof.ovh.net feraient tomber tous les serveurs de chez FREE ou dechez OVH ??? hihihihihihihihihihihi.
Bon bref laissez ce troll feeder ce sujet et passez lui des fois le bonjour danscesujet et passez a autre chose ;)
-
Merci willemijns pour cet historique sur les vieux speed-test pourris.
C'est un peu cela mais vu qu'en ce moment il y a de plus en plus de trolls partout donc... J'ai voulu résumer la situation en fonction du titre "brut" et court de ce sujet.
C'est moi qui ai choisi le titre après avoir déplacé le hors sujet.
Au point de vu légal on a pas besoin de gérer un aspect DDoS car on vise dans 99,999% un serveur dédié aux speedtest dans un réseau d'ordi de style FAI et que si même on le saturait de trolls ca ferait un DoS sur un serveur sans (trop) d'interet.
En fait, brupala (et moi) parlait du DoS non pas du serveur, mais de l'arbre PON sur lequel le client est connecté (dans le cas où le serveur pousserait trop de données). Et toi tu évoques l'inverse, DoS d'un serveur, mais ça n'est pas de ça dont on parlait.
Leon.
-
Je résume, pour ne pas que tu perdes du temps:
- l'ami brupala affirme des choses bizarres (et fausses) à propos des speed-test, soit disant qu'ils sont fait par burst de quelques millisecondes espacés dans le temps, pour ne pas faire du DoS sur le réseau (saturer des liaisons).
- on lui répond que non, que le flux de donnée du speedtest est automatiquement régulé par les algos de flow-control-TCP, et donc que ça ne saturera pas le réseau. Donc un speedtest est basé sur des flux de données TCP continus qui durent une dizaine de secondes. Dans ces conditions, aucun risque pour le réseau contrairement à ce que prétend brupala.
Précision:
je n'ai personnellement jamais parlé de DoS dans cette discussion, qui est issue d'une autre, même si le but du speedtest est de saturer une connexion pour en tirer le maximum le temps du test.
Effectivement je me demandais si le test n'était pas fait de petits time slots avec des marqueurs temporels sans balancer un énorme volume de données (plusieurs GO), quelques ms étant suffisantes pour évaluer un débit max, quitte à les répartir sur une période plus longue, ça pourrait même être permanent, mais ce serait du gaspillage de réseau.
entre temps, j'ai fait quelques relevés Wireshark chez moi, connexion Free à 1G/1G pour essayer de voir par moi même ce qui se passait:
Un speedtest est bien un bourrin flux de paquets sur plusieurs connexions, j'ai vu que speedtest était sur plusieurs serveurs mais nperf sur un seul, mais plusieurs tcp et c'est bien continu, pas de pointes successives, courbes de débits sur ma freebox et sur mon switch central le confirment et j'avais beaucoup de données dans la capture.
Mais Wireshark n'est pas un bon outil pour voir la répartition des différents flux dans le temps, ou je n'ai pas encore trouvé comment le voir, comme le nombre de paquets est énorme, j'ai très vite eu la flemme d'essayer d'évaluer les temps à la main.
-
Précision:
je n'ai personnellement jamais parlé de DoS dans cette discussion, qui est issue d'une autre, même si le but du speedtest est de saturer une connexion pour en tirer le maximum le temps du test.
Ah bon, tu es sur et certain?
Personnellement je n'ai pas trop de doute, tu as bel et bien affirmé ce genre de choses; voir ci-dessous.
C'est bien pour ça que j'ai choisi ce titre pour ce fil de discussion.
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.
Leon.
-
Ah bon, tu es sur et certain?
Personnellement je n'ai pas trop de doute, tu as bel et bien affirmé ce genre de choses; voir ci-dessous.
C'est bien pour ça que j'ai choisi ce titre pour ce fil de discussion.
Leon.
oups,
j'avais zappé ce bout là :(,
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."
A ce que j'ai mesuré grossièrement, à 1 Gbit/s, c'est quelques centaines .... de milliers de paquets, pendant quelques secondes, forcément ça doit gêner.
-
Dans le cas où on considère qu'un user se connecte pour faire du speed test, il faut lire le contrat que il a signé et on est souvent pour un usage dit du "bon père de famille" pour un particulier et une formule du même acabit pour les pros qui sont en shared.
Si tous les users d'un shared link ont eu une envie folle de faire en même temps un speed test hier à 16h18 c'est un DoS "pas de chance" épivala. Il est d'usage d'autoriser quelques bursts de temps a autre après qu on a donné des explications au service technico commercial qui vous demande pourquoi une pointe de traffic durant 6 heures le 23 novembre.
Tiens ça me rappelle un pro il y a 5/15 ans qui fesait du speed test via curl toutes les 2 minutes sur un sharedlink pour simplement être sûr d'être connecté 24/7. Son opérateur l'a enguirlandé pour traffic peu compatible avec un usage pro partagé.
-
A ce que j'ai mesuré grossièrement, à 1 Gbit/s, c'est quelques centaines .... de milliers de paquets, pendant quelques secondes, forcément ça doit gêner.
Gêner ou DoS? Il faudrait savoir. Il y a une énorme différence entre les 2.
Un téléchargement de ~14Go (un petit jeu Steam), ça fait à la louche ~10 Milliards de paquets. Est-ce gênant pour autant? Est-ce un DoS pour autant?
Où est la différence, du point de vue réseau, entre un téléchargement et un speedtest? Spoiler : il n'y en n'a pas.
Leon.
-
Gêner ou DoS? Il faudrait savoir. Il y a une énorme différence entre les 2.
Un téléchargement de ~14Go (un petit jeu Steam), ça fait à la louche ~10 Milliards de paquets. Est-ce gênant pour autant? Est-ce un DoS pour autant?
Où est la différence, du point de vue réseau, entre un téléchargement et un speedtest? Spoiler : il n'y en n'a pas.
Leon.
Décidément ... jeu sur les mots,
gêner, c'est juste perturber, pas bloquer.
Encore une fois, un téléchargement, c'est 1 flux tcp, un speedtest, plusieurs, je n'ai pas contrôlé exactement , mais un netstat le dirait.
Après, un téléchargement QUIC, qui ouvre aussi plusieurs flux en parallèle, ça pourrait faire la même chose, si le serveur ne limite pas.
Par contre, un serveur de téléchargement ne peut pas se permettre de délivrer tout le débit que chaque utilisateur espère, surtout avec les connexions actuelles dont on parle, qui sont parfois plus puissantes que la sienne, donc il vaut mieux qu'il mette une limite de débit à chaque client, vu qu'ils peuvent être plusieurs milliers sur le papier, ça s'est toujours fait en P2P.
-
On ne peut parler de perturbation quand on sature un lien. les routeurs ou autres babioles hardwares sont souvent ne sont jamais a 100% CPU
0,00004% ou 99,9999% CPU les routeurs vont pas faire de chichis, les données arrivent tous au temps initial imparti.Ce qui compte c'est que les liens peuvent être saturés saturés suite a des ruptures de fibres ok mais un DoS et une saturation suite a un problème HW c'est pas la même chose.
-
Encore une fois, un téléchargement, c'est 1 flux tcp, un speedtest, plusieurs, je n'ai pas contrôlé exactement , mais un netstat le dirait.
Après, un téléchargement QUIC, qui ouvre aussi plusieurs flux en parallèle, ça pourrait faire la même chose, si le serveur ne limite pas.
Par contre, un serveur de téléchargement ne peut pas se permettre de délivrer tout le débit que chaque utilisateur espère, surtout avec les connexions actuelles dont on parle, qui sont parfois plus puissantes que la sienne, donc il vaut mieux qu'il mette une limite de débit à chaque client, vu qu'ils peuvent être plusieurs milliers sur le papier, ça s'est toujours fait en P2P.
1 flux tcp ou plusieurs c'est pareil pour le milieu du réseau... les speedtests utilisent plusieurs flux pour contrer les problemes de latence ou les limitations cpu des PC , limitation des navigateurs web, et chez certains abonnés la trop grande perte de paquets (collecte Free notamment)
sur mon PC Linux connecté derriere une livebox Orange a 8G/8G, je télécharge a 8Gbps depuis le serveur ping.online.net avec une seule connexion TCP. Si j'en utilise 2, elle feront 4 Gbps chacune. Derriere la meme livebox mon PC Windows limite a environ 6Gbps par connexion TCP (ce n'est pas le cpu, sans doute un souci buffer ou autre). Donc avec 2 flux TCP j'arrive bien a 8Gbps avec Windows aussi. Les speedtests prévoient les pires cas donc utilisent plusieurs flux pour être sur que le facteur limitant n'est pas une des extrémités.
Linux, 1 flux TCP
[ 5] 0.00-10.04 sec 9.49 GBytes 8.12 Gbits/sec 1 sender
[ 5] 0.00-10.00 sec 9.47 GBytes 8.13 Gbits/sec receiver
Windows, 1 flux TCP
[ 5] 0.00-10.06 sec 6.84 GBytes 5.84 Gbits/sec 0 sender
[ 5] 0.00-10.01 sec 6.82 GBytes 5.85 Gbits/sec receiver
Windows, 2 flux TCP
[ 5] 0.00-10.05 sec 4.68 GBytes 4.00 Gbits/sec 0 sender
[ 5] 0.00-10.00 sec 4.67 GBytes 4.01 Gbits/sec receiver
[ 7] 0.00-10.05 sec 4.90 GBytes 4.19 Gbits/sec 0 sender
[ 7] 0.00-10.00 sec 4.89 GBytes 4.20 Gbits/sec receiver
[SUM] 0.00-10.05 sec 9.59 GBytes 8.20 Gbits/sec 0 sender
[SUM] 0.00-10.00 sec 9.56 GBytes 8.21 Gbits/sec receiver
Pour le milieu du réseau, le nombre de flux TCP ne change rien donc (encore heureux d'ailleurs).
Les serveurs de téléchargement (miroirs distro, steam, etc) ne limitent pas forcement le débit d'envoi vu que TCP s'en occupe déja. Certains ont des quotas ou une limite de débit mais c'est rare. ils peuvent parfois limiter le nombre de connexions simultanées d'un meme client.
Donc oui 99% des serveurs délivrent tout le débit que chaque utilisateur espère, du moins "tentent de délivrer". C'est TCP (ou QUIC) qui se charge de réguler les flux et l'équité. Pas besoin de complexifier son serveur (sauf cas particuliers).
-
Décidément ... jeu sur les mots,
gêner, c'est juste perturber, pas bloquer.
C'est toi qui parlait de DoS. Un DoS, c'est une grosse perturbation qui rend un service, une liaison inutilisable. Tu peux stp nous expliquer pourquoi tu as dis qu'un speed-test qui durerait plusieurs minutes serait un gros DoS? Tu as même mis l'adjectif gros dans ta phrase. C'est donc très très différent d'une "gêne".
A moins que tu n'admettes que tu te sois trompé précédemment en disant ça?
Je rappelle ce que tu avais écrit:
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.
Leon.
-
C'est toi qui parlait de DoS. Un DoS, c'est une grosse perturbation qui rend un service, une liaison inutilisable. Tu peux stp nous expliquer pourquoi tu as dis qu'un speed-test qui durerait plusieurs minutes serait un gros DoS? Tu as même mis l'adjectif gros dans ta phrase. C'est donc très très différent d'une "gêne".
A moins que tu n'admettes que tu te sois trompé précédemment en disant ça?
Je rappelle ce que tu avais écrit:
Leon.
j'ai dit gros parce qu'il peut toucher plusieurs utilisateurs, pas un seul, vu qu'ils sont sur un multiplex et qu'un seul dans le tas utilise toute la bande (ce qui se voit dans le résultat speedtest). C'est aussi le cas du iperf de Kgersen.
Mais si le résultat donne la moitié de la capacité, c'est que le reste est utilisé ailleurs.
-
1 flux tcp ou plusieurs c'est pareil pour le milieu du réseau... les speedtests utilisent plusieurs flux pour contrer les problemes de latence ou les limitations cpu des PC , limitation des navigateurs web, et chez certains abonnés la trop grande perte de paquets (collecte Free notamment)
au niveau du réseau, oui, bien sûr, à peu de choses près, surtout quand c'est routé dans le hardware.
Ton iperf avec 2 flux est peu significatif, car sur la même machine et le même port physique aux deux bouts, c'est peut-etre le contrôleur ethernet qui équilibre la charge. par contre, tu ne me feras pas croire que d'autres utilisateurs peuvent exploiter la liaison pendant les 10S, du moins le iperf ne sera pas au débit nominal comme là.
Donc oui 99% des serveurs délivrent tout le débit que chaque utilisateur espère, du moins "tentent de délivrer". C'est TCP (ou QUIC) qui se charge de réguler les flux et l'équité. Pas besoin de complexifier son serveur (sauf cas particuliers).
l'équité, je ne suis pas sûr si les RTT sont très différents et quand tu as 200 utilisateurs simultanés sur le serveur, on sera loin du débit espéré par chacun.
-
j'ai dit gros parce qu'il peut toucher plusieurs utilisateurs, pas un seul, vu qu'ils sont sur un multiplex et qu'un seul dans le tas utilise toute la bande (ce qui se voit dans le résultat speedtest).
Mais si le résultat donne la moitié de la capacité, c'est que le reste est utilisé ailleurs.
Tu n'as toujours pas changé d'avis là dessus? Tu es toujours convaincu, à tort, qu'un SpeedTest de plusieurs minutes boufferait toute la bande passante des autres utilisateurs d'un arbre PON qui en auraient besoin, et rendrait donc leur liaison inutilisable ? Malgré toutes les explications qu'on t'a données ?
Ou alors tu admets enfin que ton hypothèse de gros DoS était farfelue et même totalement fausse?
Leon.
-
Tu n'as toujours pas changé d'avis là dessus? Tu es toujours convaincu, à tort, qu'un SpeedTest de plusieurs minutes boufferait toute la bande passante des autres utilisateurs d'un arbre PON qui en auraient besoin, et rendrait donc leur liaison inutilisable ? Malgré toutes les explications qu'on t'a données ?
Ou alors tu admets enfin que ton hypothèse de gros DoS était farfelue et même totalement fausse?
Leon.
ah .. ça y est je vois un peu mieux où tu bloques:
quand je dis un speedtest, je voulais dire, quand il affiche un résultat qui est proche du débit de l'arbre, comme on en voit parfois, si le résultat est la moitié du débit max c'est que la bande est partagée à cet instant, ce qui est normal.
Après, je peux admettre que l'hypothèse est une hypothèse et quand on est sur un multiplex, il faut partager, pas tout vouloir tout le temps, sinon plus rien ne fonctionne, heureusement, l'usage normal en domestique fait que l'on ne consomme guère plus de 1% d'un lien gigabit en moyenne.
Mais le souci avec les évolutions genre 50G-PON, les débits aval sont du même niveau voire plus que les débits amont, sur du transit ça va, mais sur de la distribution, on peut réfléchir à ce genre de problème, bien que je ne sois pas concerné personellement.
-
OK, donc tu es toujours sur les mêmes raisonnements faux qu'au tout début de la discussion. J'abandonne, bonne continuation.
Leon.
-
au niveau du réseau, oui, bien sûr, à peu de choses près, surtout quand c'est routé dans le hardware.
Ton iperf avec 2 flux est peu significatif, car sur la même machine et le même port physique aux deux bouts, c'est peut-etre le contrôleur ethernet qui équilibre la charge. par contre, tu ne me feras pas croire que d'autres utilisateurs peuvent exploiter la liaison pendant les 10S, du moins le iperf ne sera pas au débit nominal comme là.
Si 2 personnes du meme arbre font un test iperf3 en meme temps, il se partagerons la BP totale (donc 4Gbps chacun) a ce moment la, du moins si les 2 serveurs utilisent le meme algo de congestion (d'ou le probleme avec BBR).
l'équité, je ne suis pas sûr si les RTT sont très différents et quand tu as 200 utilisateurs simultanés sur le serveur, on sera loin du débit espéré par chacun.
Si ton serveur a la capacité suffisante oui. Pour les RTT on les compense, en pratique, par plus de flux TCP en meme temps (si le contenu téléchargé peut être fractionner en morceaux).
Apres je ne vois pas ou tu veux en venir la (a moins d'évidence banale comme: pas meme RTT pas equitable....)
-
Si ton serveur a la capacité suffisante oui. Pour les RTT on les compense, en pratique, par plus de flux TCP en meme temps (si le contenu téléchargé peut être fractionner en morceaux).
Apres je ne vois pas ou tu veux en venir la (a moins d'évidence banale comme: pas meme RTT pas equitable....)
oui, c'est ça: RTT différents, équité KO, le plus faible avance plus vite, tu veux dire qu'on peut mettre plus de débit sur un RTT plus long pour compenser la réduction naturelle de celui ci ?
je me demande comment c'est géré, vu que ce sont deux connexions différentes, ce sont deux algos différents, non?
j'ai du mal à imaginer qu'ils travaillent de concert.
-
oui, c'est ça: RTT différents, équité KO, le plus faible avance plus vite, tu veux dire qu'on peut mettre plus de débit sur un RTT plus long pour compenser la réduction naturelle de celui ci ?
je me demande comment c'est géré, vu que ce sont deux connexions différentes, ce sont deux algos différents, non?
j'ai du mal à imaginer qu'ils travaillent de concert.
non ? "on ne met pas de débit" , on ne "règle pas le débit" , c'est TCP qui fait cela tout seul.
Le RTT impacte le débit si les buffers ne sont pas assez grands. c'est juste une histoire de BDP ( https://en.wikipedia.org/wiki/Bandwidth-delay_product ).
Et il y aussi le fait qu'en général plus le RTT est grand plus il y a de chance que le débit total théorique max de bout en bout soit moindre parce que ca traverse plein de routeurs et plein de liens différents (souvent des agrégations aussi du style Nx1Gbps par exemple). Et plus le chemin est grand plus y'a de chance de perte de paquets ce qui impacte fortement TCP (du moins sans BBR).
Pour qu'un serveur 100Gbps a Los Angeles délivre 8Gbps a mon PC avec un seul flux TCP il me faudrait un buffer de 400 MB minimum (net.core.rmem_max et net.ipv4.tcp_rmem). En plus rien ne garantie que tout les liens intermédiaires empruntés laisseront un seul flux passé a 8Gbps. Souvent y'a plusieurs chemins différents donc les paquets n'arrivent pas forcement dans le meme ordre.
Plus y'a de la latence (du moins celle du a la distance), plus on met de flux en parallèle pour la compenser les buffers et les pertes, mais ce n'est pas toujours possible.