Comment puis-je formuler la latence de communication en TCP / IP?

J'ai du mal à dériver un modèle / une équation mathématique pour estimer la latence aller-retour entre deux nœuds communiquant via TCP / IP. Les nœuds échangent des données sur la base du protocole HTTP. Dans ce modèle, les facteurs les plus importants à étudier sont la distance physique entre deux nœuds du réseau, le nombre de sauts intermédiaires, la bande passante, le retard de traitement à chaque saut. J'ai cherché sur le Web mais je n'ai rien trouvé dans ce sens, j'ai plutôt trouvé quelque chose sur les réseaux de commutation de circuits et le protocole UDP. Puis-je les personnaliser pour s'adapter à TCP?

Ceci est un processus très compliqué, donc formuler une équation qui pourrait être utile pour prédire avec précision les RTT est extrêmement difficile. Au mieux, je dirais que vous pouvez créer un modèle qui utilise un tas de moyennes pour chaque étape, que vous pouvez modifier s'il vous arrive de "mieux connaître" pour une situation particulière est à peu près aussi proche que possible. C'est quelque chose que j'étudie actuellement afin que je puisse vous dire ce que je sais jusqu'à présent (de A à Z, en commençant par la couche physique):

• Voir mes questions sur l'électronique SE; Le retard de codage d'Ethernet et la relation avec la fréquence nominale du câble et la vitesse de l'électricité (propagation du signal?) À travers le cuivre pour le retard de communication . Puisque vous utiliseriez des vitesses standardisées (100Mbps, 1Gbps, 10Gbps etc.), ne traitez pas la fibre ou le cuivre différemment. Le «retard» dans les deux est presque le même, mais le cuivre ne peut évidemment pas transporter un signal aussi loin. J'ai cette question sur le site Physics SE, dont je connais la réponse maintenant. J'ai juste besoin de trouver le temps de régler le problème, alors gardez un œil sur cela si vous êtes intéressé (je posterai d'autres questions liées à l'utilisation des fibres de télécommunications auxquelles je connais maintenant la réponse lorsque j'en aurai l'occasion) ).

• Beaucoup plus de retard va être ajouté par les appareils à la fin d'une liaison. Il n'y a pas de façon standard de dire "oh 2 commutateurs le long d'un chemin est un retard Xms, 4 commutateurs est 2 * Xms, 2 routeurs est Yms ... etc". En supposant que vous utilisez, par exemple, 1 Gpbs et les périphériques dans la voie à suivre au débit de ligne, nous savons que c'est 1000000000 bps, donc l'interface physique fonctionne à un taux de codage fixe (allant de 1 nanoseconde par bit jusqu'à quel que soit le maximum de la Le schéma de codage des symboles utilisé est, tel que 10b )

• Il existe trois principaux types de retard (au niveau de la couche physique) dont vous devez être conscient et prendre en compte; Délai de sérialisation, délai d'encodage, délai de propagation (et délai de traitement, délai de mise en file d'attente, délai d'encodage et de décodage, mais ceux-ci sont au-dessus de la couche physique mais doivent être mentionnés!). Ceux-ci sont raisonnablement bien documentés sur Internet, VoIP: une analyse approfondie , diapositive 13 ici , charges sur Google Scholar , et bien d'autres.

• Au fur et à mesure que nous montons dans la pile de protocoles, je travaillerais sur l'hypothèse que le MAC de destination se trouve dans chaque table de came des commutateurs et, au niveau de la couche IP, le MAC de destination dans les tables ARP. Le délai supplémentaire induit par ces processus de découverte ne se produit que pour le premier paquet d'un flux afin qu'ils puissent être contournés en augmentant les délais d'attente et en envoyant des ARP gratuits, etc.

• Lorsque vous arriverez à la couche application, cela deviendra très difficile car cela dépend du serveur (par exemple) qui traite la demande, qui sera soumis à un retard d'interruption. Le nombre d'interruptions nécessaires pour traiter la demande et les changements de contexte en raison de la charge est imprévisible.

J'aimerais beaucoup vous aider avec votre question, malheureusement c'est tout ce que j'ai pour le moment. Je mettrai à jour cette réponse peut-être plus tard ce soir ou demain, je voulais publier ce que j'ai jusqu'à présent.

Dans le même temps, la plupart des gens ont tendance à travailler avec le chiffre du retard sur une couche physique de cuivre / fibre d'environ 0,6 * c (C = vitesse de la lumière). En outre, vous devez penser à l'échange TCP des ACK tous les paquets X, qui diffère si vous utilisez SACK par exemple, et si vous utilisez des trames jumbo et / ou une taille MSS plus grande (maintenant MTU doit également être pris en compte!) , si vous envoyez plus d'ACK intermédiaires (si le volume de données transférées vous intéresse). Vous devez également prendre en compte le fameux produit de retard de bande passante et ne pas faire la mauvaise interprétation stupide que j'ai faite de cette page. J'ai commencé à faire différents calculateurs de données simples (et très laid) ici. Encore une fois un travail en cours je vais essayer de les mettre à jour bientôt. Je prévois d'ajouter une calculatrice similaire à ce que vous essayez de faire. J'ai également fait des calculatrices lumière et fibre si vous êtes intéressé, mais encore une fois, pas le temps !, je n'ai pas encore fini de les télécharger. Je vais essayer ASAP de mettre à jour cette réponse un peu plus, dans les prochains jours.

PS J'ai oublié de mentionner la QoS! Si la QoS est en jeu n'importe où sur le chemin, cela va devenir très difficile de caluber la RTT!

(Je tiens à souligner que d' autres l' ont d' excellentes réponses sur la façon dont les retards et autres travaux et ce qui les causes , mais l'OP a demandé aux modélisation,.. Un modèle de base est simple et vous suffit de brancher en nombre par exemple Si vous voulez savoir pourquoi les retards sont ce qu'ils sont, alors voyez les réponses de tout le monde: ^)

La latence du réseau est simplement le temps de transit d'un point de terminaison à l'autre point de terminaison, couvrant N sauts entre .

Vous avez donc N segments (sauts) avec N-1 nœuds intermédiaires. Chaque nœud a un retard (l'effet cumulatif de plusieurs choses sur ce nœud, comme le retard de file d'attente, les retards de traitement, etc.), et chaque segment a un retard de transit. Globalement, cela représente 2N - 1 variables indépendantes. Donc c'est seg1 + node1 + seg2 ... + node (N-1) + segN Un saut, c'est juste = seg1, deux espoirs c'est seg1 + node1 + seg2, etc.

Ensuite, vous devez définir quelles sont toutes ces pièces. Vous pouvez donc construire un réseau modèle avec un réseau CATV, une liaison satellite, une liaison fibre optique, un Ethernet, etc. Pour chacune de ces technologies, vous devez rechercher des exemples d'informations.

Les retards de transit correspondraient approximativement à la taille des données divisée par la vitesse de transmission du segment. Si vous avez besoin d'un modèle plus précis, vous avez ajouté le décalage de temps de vol - approximativement la longueur du segment, divisée par la vitesse du flux de données (approximativement la vitesse de la lumière.) Cela importe si vous avez une liaison satellite impliquée; La montée et la descente vers le satellite géosynchrone sont importantes.

Vous devrez estimer les retards sur chaque nœud en fonction de l'équipement que vous placez dans votre modèle.

Si vous voulez la latence de l'application (par exemple, le délai jusqu'au début du flux de données d'un transfert FTP), alors vous construisez en comptant combien de fois votre latence réseau entre en jeu. Par exemple, une négociation TCP à 3 voies ajoute une latence de réseau triple, et ainsi de suite à ce que voit l'application.

Vous pouvez estimer la latence aller-retour en effectuant une capture de paquets de chaque côté, puis mesurer le délai entre les requêtes sortant de la machine surveillée et les réponses qui reviennent. Par exemple, si vous marquez l'heure à laquelle un SYN sort sur la machine distante, puis marquez l'heure à laquelle la réponse SYN + ACK est entrée, la différence vous donnera une assez bonne idée de la latence TCP aller-retour.

Gardez à l'esprit que cela sera supérieur à la véritable latence du réseau, et combien plus dépend de la charge de chaque machine.

Le délai entre deux hôtes dépendra de plusieurs facteurs:

• Délai de propagation
• Délai de sérialisation
• Délai de mise en file d'attente / tampon

Le délai de propagation est le temps qu'il faut physiquement pour que les paquets voyagent entre deux emplacements. La vitesse de la lumière dans la fibre est d'environ 200000 km / s. La Suède où j'habite est d'environ 1570 km, ce serait donc 7,85 ms mais en réalité c'est plus parce que c'est la distance via la vue des oiseaux.

Le délai de sérialisation est le temps qu'il faut pour sérialiser le paquet via le support physique, c'est-à-dire les interfaces sur le périphérique réseau. Si vous disposez d'une connexion à 2 Mbit et que vous envoyez un paquet de 1 500 octets, ce serait 6 ms pour sérialiser le paquet (12000/2000000).

Le délai de mise en file d'attente / de mise en mémoire tampon est le temps que le paquet doit rester dans une file d'attente / tampon avant d'être envoyé sur l'interface. En fonction de la vitesse sur l'interface et de la taille des tampons utilisés, cela pourrait être à côté de rien ou d'un retard important.

Il y aurait alors un certain délai sur les hôtes pour générer les paquets et pour que l'application les gère. Il existe des applications pour mesurer le retard HTTP. Les gens n'acceptent pas beaucoup de retard sur les sites Web avant de les abandonner, c'est donc un facteur important.