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.
TCP/IP / Fonctionnement des réseaux