Explication transfert de données TCP

Explication transfert de données TCP - Windows & Software

Marsh Posté le 02-10-2006 à 23:07:00    

Alors, je suis à la recherche d'une explication avec argument
 
Pourquoi lorsqu'on envoit un flot de données de X octets entre 2 interfaces réseaux on n'obtient pas un temps comparable à la vitesse théorique de l'interface?
 
Outre le fait de la qualité du fil ethernet, la distance de la liaison, le passage par une ou plusieurs switch/routeur, un cpu qui n'est pas capable de fournir la carte réseau, etc. Quel serait la meilleure explication?

Reply

Marsh Posté le 02-10-2006 à 23:07:00   

Reply

Marsh Posté le 02-10-2006 à 23:13:12    

En tcp; il y a deux fenêtres qui limitent ton débit; le contrôle de flux et le contrôle de congestion. La premiere est négociée entre les deux hôtes; la seconde dépend de l'emetteur des données et de l'implémentation de TCP.

Reply

Marsh Posté le 02-10-2006 à 23:13:37    

Tu as un cas précis ou un exemple ? Parce que là, raisonner sur du vide, :/


---------------
Filmstory : gardez trace des films que vous avez vu ! :D
Reply

Marsh Posté le 02-10-2006 à 23:14:33    

et est-ce que l'un de ces 2 trucs sont observables concretement à l'aide d'outil comme ethereal?

Reply

Marsh Posté le 02-10-2006 à 23:18:17    

freds45 a écrit :

Tu as un cas précis ou un exemple ? Parce que là, raisonner sur du vide, :/


 
j'ai eu à coder un chat client/serveur en tcp qui devait contenir un mode automatique chez le client. Ce mode en 1000 lignes de textes les unes à la suite des autres.
 
Comme question complémentaire, on demande de vérifier le temps que ca prend pour envoyer le tout et le temps théorique que ca l'aurait du prendre et d'en donnée une courte explication.
 
Mon avis, c'est qu'il y a des tonnes de facteurs qui peuvent expliquer une partie du ralentissement, mais le principal selon moi reste le fait que 100mbps, c'est une valeur théorique et non pratique la plupart du temps.
 
Mais je me doute que celui-ci veut avoir une réponse un peu plus axé sur le protocole tcp que sur le hardware

Reply

Marsh Posté le 03-10-2006 à 08:01:50    

burgergold a écrit :

et est-ce que l'un de ces 2 trucs sont observables concretement à l'aide d'outil comme ethereal?

le controle de congestion non. Le controle de flux oui; il y a un champ window dans l'en tete tcp avec la valeur du tampon de reception.
 
http://www-rp.lip6.fr/~fourmaux/res/index.html
prend le cours 4 en pdf.
 
Par contre les 100 Mbps sur de l'Ethernet sont bien un débit réel de niveau 2 si les interfaces ont bien négociées leurs valeurs.


Message édité par dreamer18 le 03-10-2006 à 08:07:10
Reply

Marsh Posté le 03-10-2006 à 15:48:13    

donc en gros, le transfert est ralenti parce que le serveur arrete d'envoyer des packets lorsque le buffer du client est plein?
 
page 56 du cours 4

Reply

Marsh Posté le 03-10-2006 à 17:49:36    

oui, c'est tout à fait possible.

Reply

Marsh Posté le 04-10-2006 à 09:22:53    

burgergold a écrit :

Alors, je suis à la recherche d'une explication avec argument
 
Pourquoi lorsqu'on envoit un flot de données de X octets entre 2 interfaces réseaux on n'obtient pas un temps comparable à la vitesse théorique de l'interface?
 
Outre le fait de la qualité du fil ethernet, la distance de la liaison, le passage par une ou plusieurs switch/routeur, un cpu qui n'est pas capable de fournir la carte réseau, etc. Quel serait la meilleure explication?


 
Comme expliqué par dremaer18, ce sont principalement les couches  
hautes qui engendrent la latence de par le contrôle de flux, surtout
si tu parles de mode connecté comme une connexion TCP par exemple.
 
Si tu veux atteindre le "full wire speed", la meilleure façon de procéder
est d'injecter des trames avec un analyseur. Si la couche physique est  
"propre", tu devrais approcher la vitesse du media.
 
-sb

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed