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

stable, c'est stable, donc on mesure si on veut, mais on ne change rien au flux de données, ce qui est le rôle de l'algo de faire varier le flux de données en fonction des perturbations de l'environnement, mer calme, temps clair, cap automatique.

Citation de: Leon le Aujourd'hui à 19:53:14

Citation de: brupala le Aujourd'hui à 19:15:09

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.

ah ouais ? vas y explique Leon ce qu'ils auraient à faire ? (en partant du principe qu'il n'y a pas d'autres connexions actives sur les deux ports qui viendraient en concurrence).

C'est pourtant simple.
Soit un switch avec seulement 2 machines, un serveur et un PC client.
Soit une application qui utilise TCP, qui tourne sur le serveur connecté à 1Gb/s à ton switch, et qui est capable de générer beaucoup de débit (pas de limitation interne du à un disque dur par exemple).
Soit un PC "client" connecté à ton switch en 100Mb/s, et qui reçoit des données du serveur.
Le mécanisme flow control TCP va automatiquement limiter à 100Mb/s les données poussées par le serveur sur le réseau, et la couche TCP (le socket TCP) va informer en temps réel l'application serveur de la quantité de données que TCP a réussi à pousser sur la liaison, vu la limitation à 100Mb/s. Et si besoin l'application adaptera son comportement en conséquence.
Et ça avec une connexion parfaitement stable (stable = qui ne varie pas dans le temps), en étant tout seul sur ton réseau, sans aucune perturbation.
Voilà voilà.
Je vais finir par faire payer ces cours de TCP/IP pour débutant. LOL. 

Tiens, je mets la définition Wikipedia que je trouve plutôt bien écrite
https://fr.wikipedia.org/wiki/Contr%C3%B4le_de_flux
Le contrôle de flux, dans un réseau informatique ou un réseau de télécommunications, représente un asservissement du débit binaire de l'émetteur vers le récepteur.
Quand une machine a un débit montant supérieur au débit descendant de la destination, la source diminue son débit pour ne pas submerger le puits de requêtes (obligeant parfois, lorsque le puits ne peut pas les traiter, à la ré-émission de ces dernières). Le contrôle de flux doit être différencié du contrôle de congestion, qui est utilisé pour contrôler le flux de données lorsque la congestion a déjà eu lieu. Les mécanismes de contrôle de flux sont définis par le fait que le récepteur envoie une information de retour à l'émetteur.

Leon.

Oui, tu as dit ça, et c'est totalement faux.

ah ouais ? vas y explique Leon ce qu'ils auraient à faire ? (en partant du principe qu'il n'y a pas d'autres connexions actives sur les deux ports qui viendraient en concurrence).
C'est pourtant simple.
Soit un switch avec seulement 2 machines, un serveur et un PC client.
Soit une application qui utilise TCP, qui tourne sur le serveur connecté à 1Gb/s à ton switch, et qui est capable de générer beaucoup de débit (pas de limitation interne du à un disque dur par exemple).
Soit un PC "client" connecté à ton switch en 100Mb/s, et qui reçoit des données du serveur.
Le mécanisme flow control TCP va automatiquement limiter à 100Mb/s les données poussées par le serveur sur le réseau, et la couche TCP (le socket TCP) va informer en temps réel l'application serveur de la quantité de données que TCP a réussi à pousser sur la liaison, vu la limitation à 100Mb/s. Et si besoin l'application adaptera son comportement en conséquence.
Et ça avec une connexion parfaitement stable (stable = qui ne varie pas dans le temps), en étant tout seul sur ton réseau, sans aucune perturbation.
Voilà voilà.
Je vais finir par faire payer ces cours de TCP/IP pour débutant. LOL. 

Tiens, je mets la définition Wikipedia que je trouve plutôt bien écrite
https://fr.wikipedia.org/wiki/Contr%C3%B4le_de_flux
Le contrôle de flux, dans un réseau informatique ou un réseau de télécommunications, représente un asservissement du débit binaire de l'émetteur vers le récepteur.
Quand une machine a un débit montant supérieur au débit descendant de la destination, la source diminue son débit pour ne pas submerger le puits de requêtes (obligeant parfois, lorsque le puits ne peut pas les traiter, à la ré-émission de ces dernières). Le contrôle de flux doit être différencié du contrôle de congestion, qui est utilisé pour contrôler le flux de données lorsque la congestion a déjà eu lieu. Les mécanismes de contrôle de flux sont définis par le fait que le récepteur envoie une information de retour à l'émetteur.

Leon.

ça, je n'ai jamais dit le contraire et quand je donnais en exemple 2 ports de switch, il fallait lire deux ports au même débit, sinon c'est déjà un réseau perturbé qui oblige le switch à stocker des trames le temps que tcp limite son envoi, ce qui peut être rapide si la fenêtre est courte.
Mais bon, un switch avec des ports à débit différents, c'est à peu près la même chose que le réseau wan donné en exemple par vivien à un moment, au temps RTT près, qui a bien sûr son influence.

Ah bon? Je suis pourtant certain que tu as dit le contraire. Voir ci-dessous. Les algo de flow control sont actifs et indispensables même quand ton réseau est stable et non perturbé. Dire qu'ils n'ont "rien à faire", ça montre que tu n'as pas compris.

Donc maintenant on mélange les notions de stable, perturbé, et on change l'énoncé des sujet avec des switches de ports de débit identique... On n'est pas sorti de l'auberge, je vous le dit. Un switch avec des ports de débit différents serait donc un switch perturbé!!! LOL on rigole bien ici. Un switch perturbé mais stable j'espère (stable = qui ne varie pas dans le temps). Tu nous confirmeras.

Leon.

oui, présent, mais actif (change le débit) ou pas actif (ne change pas).
On rigole bien en effet et on s' oppose en s'échinant à répéter à peu près la même chose que l'autre ne veut pas entendre, parce que venu avec un éclairage un peu différent, un vrai forum, quoi 
J'espère que les cours TCP de cette discussion apporteront à d'autres, c'est l'essentiel, on n'a pas souvent occasion de parler de ça.

Après, il existe aussi une fonction plus méconnue à TCP, et pourtant essentielle : réordonner les paquets dans le bon ordre.

Car même quand il n'y a pas de perte de paquet, quand il n'y a pas de saturation, le fait d'en modifier l'ordre peut vraiment semer la pagaille.

Et c'est ce qui s'est passé chez Orne THD à ses débuts. Livré via plusieurs liens, aggrégés au paquet près (normalement on équilibre au flux près pour qu'un flux garde le même lien, du premier au dernier paquet). Donc à un instant T, une connexion pouvait utiliser 4 liens à la fois, et donc le message final était totalement désordonné car différence de longueur d'onde, différence de longueur de jarretière, etc. Ceux qui naviguaient sur Internet ou ceux qui faisaient des speedtests justement ne voyaient rien (grâce à TCP qui faisait le job en dessous)... mais ceux qui jouaient, visioconférence et autre voip, c'était une boucherie.

Donc oui, même si vous avez téléchargez cette pauvre petite page à qq Kbits en TCP sur un réseau non saturé (et dieu sait que vous en avez traversé des routeurs !), vous avez toujours une magie qui opère pour que tous mes mots que vous avez lu jusque là soient le ordre bon dans.

Après, il existe aussi une fonction plus méconnue à TCP, et pourtant essentielle : réordonner les paquets dans le bon ordre.

Car même quand il n'y a pas de perte de paquet, quand il n'y a pas de saturation, le fait d'en modifier l'ordre peut vraiment semer la pagaille.

Et c'est ce qui s'est passé chez Orne THD à ses débuts. Livré via plusieurs liens, aggrégés au paquet près (normalement on équilibre au flux près pour qu'un flux garde le même lien, du premier au dernier paquet). Donc à un instant T, une connexion pouvait utiliser 4 liens à la fois, et donc le message final était totalement désordonné car différence de longueur d'onde, différence de longueur de jarretière, etc. Ceux qui naviguaient sur Internet ou ceux qui faisaient des speedtests justement ne voyaient rien (grâce à TCP qui faisait le job en dessus)... mais ceux qui jouaient, visioconférence et autre voip, c'était une boucherie.

Donc oui, même si vous avez téléchargez cette pauvre petite page à qq Kbits en TCP sur un réseau non saturé (et dieu sait que vous en avez traversé des routeurs !), vous avez toujours une magie qui opère pour que tous mes mots que vous avez lu jusque là soient le ordre bon dans.

Tout à fait, mais ça c'est TCP lui même de base, c'est pas l'algo machin.