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