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 :
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"
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.

.....

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.

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.

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.

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é.