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

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

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

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.

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.