Discussion :

[Détail]

Bonsoir à tous,

En continuant de chercher un peu partout pour en apprendre plus sur TCP je suis tombé sur un article indiquant que TCP avait la capacité d'envoyer des indicateurs "Not ready" et "Stop" pour mettre en pause une connexion et qu'il pouvait ensuite la relancer avec les indicateurs "Ready" et "Go".

Source : http://www.firewall.cx/networking-to...-overview.html : paragraphe "Flow Control".

Seulement, je ne comprends pas comment ces indicateurs sont envoyés, il n'y a à ma connaissance aucun flag de ce type et je n'ai rien trouvé de ressemblant dans les options de tcp
Comment cela peut il fonctionner ?

D'autre part (je n'ai pas encore approfondi ce point) n'y a t'il pas un certain laps de temps au bout duquel la connexion est interrompue si les interlocuteurs n'échangent aucun segment ?

Merci d'avance.

[ram-0000]

En continuant de chercher un peu partout pour en apprendre plus sur TCP je suis tombé sur un article indiquant que TCP avait la capacité d'envoyer des indicateurs "Not ready" et "Stop" pour mettre en pause une connexion et qu'il pouvait ensuite la relancer avec les indicateurs "Ready" et "Go".

Source : http://www.firewall.cx/networking-to...-overview.html : paragraphe "Flow Control".

Seulement, je ne comprends pas comment ces indicateurs sont envoyés, il n'y a à ma connaissance aucun flag de ce type et je n'ai rien trouvé de ressemblant dans les options de tcp
Comment cela peut il fonctionner ?

Heu ... ils ont fumé, il n'y a rien de tel dans TCP. A la limite, en cas de congestion, la machine peut ne pas acquitter ce qui va forcer l'autre à ré-émettre et probablement aussi modifier la taille de la fenêtre d'anticipation. Mais le "Not Ready" et le "Ready" ne sont pas des "trucs" TCP.

D'autre part (je n'ai pas encore approfondi ce point) n'y a t'il pas un certain laps de temps au bout duquel la connexion est interrompue si les interlocuteurs n'échangent aucun segment ?

Non, rien de tel (et c'est vrai que cela peut être un problème parfois). C'est aussi pour cela qu'il existe une option TCP_KEEPALIVE qui permet à la pile TCP d'envoyer de temps en temps un paquet afin de vérifier que l'autre extrémité répond toujours.

[JML19]

Bonsoir

Le Flow Control existe bien pour le Protocol TCP, mais c'est l'émetteur et le récepteur qui gèrent la fenêtre glisante.

Lorsque le débit de transmission est différent entre l'émetteur et le récepteur, c'est pour cela qu'on dit TCP Windows Flow Controls (ICI).

Regarde (ICI) une explication du site IBM

Contrôle du débit TCP et fenêtre dynamique
TCP (Transmission Control Protocol) utilise une fenêtre dynamique pour le contrôle du débit. Avant d'optimiser les paramètres TCP/IP, il est nécessaire de comprendre le fonctionnement de la fenêtre dynamique TCP.

TCP utilise une fenêtre dynamique pour déterminer le nombre d'octets sans accusé de réception (x) qu'un système peut envoyer à un autre. Deux critères déterminent la valeur de x :
La taille de la mémoire tampon d'envoi sur le système expéditeur
La taille et l'espace disponible de la mémoire tampon de réception sur le système destinataire
Le système expéditeur ne peut pas envoyer plus d'octets qu'il n'y a d'espace disponible dans la mémoire tampon de réception sur le système destinataire. Sur le système expéditeur, TCP doit marquer une pause avant d'envoyer d'autres données jusqu'à ce que tous les octets de la mémoire tampon d'envoi en cours aient fait l'objet d'un accusé de réception de TCP sur le système destinataire.

Sur le système destinataire, TCP stocke les données reçues dans une mémoire tampon de réception. TCP accuse réception des données et annonce (communique) une nouvelle fenêtre de réception au système expéditeur. La fenêtre de réception présente le nombre d'octets disponibles dans la mémoire tampon de réception. Si la mémoire tampon de réception est pleine, le système destinataire annonce une taille de fenêtre de réception nulle et le système expéditeur ne peut plus envoyer de données supplémentaires. Une fois que l'application de réception de commande extrait des données de la mémoire tampon de réception, le système destinataire peut annoncer une taille de fenêtre de réception correspondant à la quantité de données lues. Le TCP du système expéditeur peut alors poursuivre l'envoi de données.

L'espace disponible dans la mémoire tampon de réception dépend de la vitesse de lecture des données de la mémoire tampon par l'application de réception de commande. TCP conserve ces données dans la mémoire tampon de réception jusqu'à ce que l'application de réception de commande les lise depuis cette mémoire tampon. Lorsque l'application de réception de commande a fini de lire les données, l'espace correspondant dans la mémoire tampon est de nouveau disponible pour accueillir de nouvelles données. La quantité d'espace disponible dans la mémoire tampon est annoncée au système expéditeur, comme il est décrit au paragraphe précédent.

Vous devez bien comprendre ce à quoi correspond la taille de fenêtre TCP lorsque vous utilisez la fenêtre dynamique pour le contrôle du débit. La taille de la fenêtre correspond à la quantité de données qui peuvent être gérées. Vous pouvez être amené à ajuster la taille de la fenêtre si la mémoire tampon reçoit plus de données qu'elle ne peut en transmettre. Pour plus d'informations sur l'optimisation de la taille de fenêtre TCP, voir Optimisation de la taille de fenêtre pour différentes opérations sur le même système.

Le mode d'interaction des mémoires tampon d'envoi et de réception présente les conséquences suivantes :
Le nombre maximal d'octets sans accusé de réception qu'un système peut envoyer correspond à la plus petite des deux valeurs suivantes :
La taille de la mémoire tampon d'envoi sur le système expéditeur
La taille de fenêtre de réception que le système destinataire annonce au système expéditeur
Si l'application de réception de commande lit les données aussi rapidement que le système expéditeur les envoie, la fenêtre de réception garde la même taille ou une taille équivalente à celle de la mémoire tampon de réception. Cela permet au flux de données de circuler de manière fluide sur le réseau. Si l'application de réception de commande parvient à lire les données assez rapidement, une fenêtre de réception plus grande peut améliorer les performances.
Si la mémoire tampon de réception est pleine, le système destinataire annonce une taille de fenêtre de réception nulle. Le système expéditeur doit marquer une pause et ne peut temporairement plus envoyer de données supplémentaires.
Généralement, des occurrences plus fréquentes de taille nulle de la fenêtre de réception entraînent une transmission de données plus lente globalement sur le réseau. A chaque fois que la fenêtre de réception est nulle, le système expéditeur doit attendre avant d'envoyer des données supplémentaires.
Généralement, vous définissez les tailles des fenêtres d'envoi et de réception séparément pour un système d'exploitation. Sous AIX, par exemple, les paramètres tcp_sendspace et tcp_recvspace de la commande no permettent de définir les tailles des fenêtres d'envoi et de réception.

La fenêtre dynamique utilisée par les opérations Tivoli Storage Manager peut être contrôlée à l'aide de l'option TCPWINDOWSIZE.

[Détail]

Donc si j'ai bien compris, si par exemple ma machine effectue un téléchargement et décide d'envoyer un acquittement avec une taille de fenêtre valant 0, la machine qui m'envoie des données mettra en pause le téléchargement jusqu'à ce que la mienne renvoie un deuxième acquittement avec une taille de fenêtre > 0 ?

[JML19]

Bonjour

Un en un sens car s'il y a une fenêtre nulle c'est que le tampon ne peut pas suivre et dans ce cas il faut stopper c'est indiqué sur le site IBM.

Tout ceci n'a vraiment d'intérêt que lorsque deux machines discutent avec des vitesses différentes, comme un PC et un Smartphone par exemple

Voici le texte repris du site IBM :

Le mode d'interaction des mémoires tampon d'envoi et de réception présente les conséquences suivantes :

Le nombre maximal d'octets sans accusé de réception qu'un système peut envoyer correspond à la plus petite des deux valeurs suivantes :

- La taille de la mémoire tampon d'envoi sur le système expéditeur

- La taille de fenêtre de réception que le système destinataire annonce au système expéditeur

Si l'application de réception de commande lit les données aussi rapidement que le système expéditeur les envoie, la fenêtre de réception garde la même taille ou une taille équivalente à celle de la mémoire tampon de réception.

Cela permet au flux de données de circuler de manière fluide sur le réseau.

Si l'application de réception de commande parvient à lire les données assez rapidement, une fenêtre de réception plus grande peut améliorer les performances.

Si la mémoire tampon de réception est pleine, le système destinataire annonce une taille de fenêtre de réception nulle. Le système expéditeur doit marquer une pause et ne peut temporairement plus envoyer de données supplémentaires.

[Détail]

Merci pour vos réponses,

Sinon, vous pensez que les logiciels qui permettent de limiter le trafic par processus (NetBalancer / NetLimiter par exemple) utilisent le champ "Fenêtre" de l'entête TCP ou agissent à un autre niveau ?

[JML19]

Je ne connais pas ces logiciels, mais ils peuvent jouer sur le MTU (Maximum Transmission Unit) et sur la taille du cache regarde (ICI) les réglages de la base de registre .

[sevyc64]

certains agissent aussi en interceptant les acquittements et les retardant étalant de fait les envois du serveur dans le temps