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