Est-ce que l'augmentation de la bande passante sur une liaison de, disons, de 1 Mo à 30 Mo réduit le RTT?
J'ai trouvé une réponse disant non. Quelqu'un peut-il expliquer?
De plus, quels sont les meilleurs mécanismes pour réduire le RTT?
protocol-theory
latency
NetworkNinja
la source
la source
Réponses:
En bref, oui; vous modifiez le délai de sérialisation ; à 1 Mbps, le délai de sérialisation n'est pas anodin.
Comparez le délai de sérialisation pour un paquet de 1 500 octets à 1 Mbps et 30 Mbps:
N'oubliez pas que ce sont des nombres unidirectionnels; vous devez les doubler lorsque vous envisagez de RTT. Que vous vous souciez de la différence de 11,6 millisecondes dans chaque direction à 1500 octets est une autre question, mais à proprement parler, vous pouvez influencer RTT avec la vitesse de la liaison.
la source
Non, l'augmentation de la bande passante ne réduit pas le RTT à proprement parler. Je dis "à proprement parler" car cela dépend de ce que vous mesurez!
Scénario 1: la couche physique
Compte tenu de la topologie simple suivante qui est facile à suivre, une connexion Ethernet en cuivre fonctionnant à 1 Mbps avec une MTU de 1500 octets entre deux appareils avec un câble de 10 mètres, cela a le même RTT (le temps qu'il faudrait pour un paquet de demande d'écho ICMP pour voyager du périphérique 1 au périphérique 2 et le message de réponse d'écho ICMP pour voyager du périphérique 2 vers le périphérique 1) en tant que connexion Ethernet cuivre 10/30/50 / 100mbps entre eux avec une MTU de 1500 octets sur le même câble de 10 mètres.
En effet, le «retard» du signal sur le câble en cuivre est lié à sa constante dialectique ( permittivité relative ). Voir ces deux pages Wikipédia pour plus d'informations sur la physique qui sont hors de portée ici.
Essentiellement, le «temps de vol» des signaux électriques sur le câble en cuivre est la même vitesse pour une connexion de 10 Mbps et une connexion de 1000 Mbps lorsque vous utilisez le même câble Cat5e de longueur et de qualité. La différence est qu'avec une connexion à 10 Mbps, les données sont encodées sur le câble moins fréquemment qu'une connexion à 100 Mbps, il y a donc de plus petits écarts entre les bits de données lorsqu'ils sont placés sur le câble (c'est ce qu'on appelle le délai de sérialisation ). Ces deux articles wikipedia développent ces concepts: le temps de bit et le temps de slot .
Scénario 2: couche 4 et supérieure (exemple TCP)
Dans l'exemple de topologie suivant, une connexion Ethernet en cuivre fonctionnant à 1 Mbps avec une MTU de 1500 octets entre deux appareils avec un câble de 10 mètres. Si vous avez X quantité de données que nous prétendons être de 100 mégaoctets de données à transporter entre l'appareil 1 et l'appareil 2, cela prendra plus de temps qu'avec une connexion Ethernet cuivre de 30 ou 100 Mbps avec une MTU de 1500 octets sur 10 mètres câble en cuivre entre les deux mêmes appareils. En effet, le codage et la transmission des données sur le câble prennent plus de temps et la carte réseau de réception sera tout aussi lente à recevoir et à décoder les signaux.
Ici, le RTT des "données réelles", qui est peut-être un seul fichier de 100 Mo, prendra plus de temps car avec les protocoles de niveau supérieur introduits, vous devez non seulement transférer les données, mais aussi les SYN, ACK et les paquets PUSH échangés ici en utilisant des temps de bits supplémentaires, avant au niveau de la couche application, un message peut être envoyé du périphérique 2 vers le périphérique 1 disant "J'ai reçu toutes les données maintenant".
Réponse courte: pas grand chose
Longue réponse:
Pour mettre cela dans un exemple de la vie réelle en développant les exemples ci-dessus; Si vous "cinglez" entre deux appareils qui sont connectés ensemble via plusieurs routeurs et / ou commutateurs intermédiaires, le RTT est un produit de la distance physique et du temps qu'il faut aux signaux pour voyager aussi loin et en arrière à travers tous ces appareils (essentiellement ). Si la QoS est configurée sur ces appareils, cela peut également augmenter le délai de bout en bout et compliquer davantage le modèle.
Il n'y a pas grand-chose que vous puissiez faire ici (dans une situation purement hypothétique où l'argent n'est pas un objet et la politique n'a pas d'importance, etc.); Installez une connexion fibre qui s'exécute directement du périphérique 1 au périphérique 2 en coupant tous les commutateurs et routeurs entre les deux. Ce serait un scénario idéal. De manière réaliste, vous pouvez mettre à niveau n'importe quelle liaison cuivre ou sans fil vers la fibre (pas que la fibre soit extrêmement rapide [ i ], [ ii ]) et essayer de rendre le chemin de connexion aussi direct que possible afin que les données passent par le moins de périphériques intermédiaires et différents connexions physiques. Le réglage de la qualité de service et l'ingénierie du trafic (routage basé sur des contraintes) peuvent également aider sur de plus grandes distances avec de nombreux sauts entre les deux.
Si vous souhaitez transférer des données entre des points avec ce que vous considérez comme un "RTT trop élevé", vous pouvez regarder des technologies comme TCP SACK qui est déjà utilisé dans de nombreux endroits, mais si vous lisez ce qui vous donnera un point de départ car il existe d'autres technologies similaires que vous pouvez ensuite étudier. Cela inclut des technologies telles que les accélérateurs et les compresseurs WAN, bien que cela serait hors de portée de ce sujet. Vous devez considérer avec le transfert de données sur une liaison avec un RTT élevé le BDP (Bandwidth Delay Product, [ iii ]) - lorsque vous utilisez quelque chose comme TCP, cela vous retiendra toujours.
[i] Le temps de "vol" sur un milieu diélectrique en cuivre est très similaire à un guide d'onde à fibre
[ii] Cela pourrait changer cependant, de nouvelles recherches et technologies porteront, espérons-le, la vitesse de la lumière dans une fibre de la moyenne de 0,6 * c à près de 1,0 * c, http://www.orc.soton.ac.uk/ speedoflight.html
[iii] http://www.kehlet.cx/articles/99.html - exemple BDP
la source
La chose qui affecte le plus directement RTT est la vitesse de signalisation. Regardez la progression d'Ethernet au cours des éons: 10M, 100M, 1G, 10G, 40G et 100G. Chaque version suivante (sauf 40G) est 10 fois plus rapide que la précédente; le temps de transmission d'un seul bit est 1 / 10ème. Le temps de transmission d'une trame complète (1500B) diminue d'un facteur 10.
Ainsi, la réponse à votre question dépend de la couche de liaison. Si le changement de bande passante n'a pas de changement correspondant dans la vitesse de liaison, alors il aura un effet minimal sur RTT - car la régulation du trafic n'est pas effectuée par bit . Par exemple, ma connexion de métro-e de bureau est physiquement 1G, mais elle a une forme de 100M aux deux extrémités. Les bits coulent à des vitesses 1G; Les trames Ethernet seront retardées si nécessaire pour maintenir la moyenne (supérieure à 1 s, 10 s, etc.) à 100M ou moins. En termes simples, une seule trame transmet à la vitesse de la liaison.
Si vous parlez de DSL, le changement de bande passante est très probablement également un changement de vitesse de liaison. Mais pas toujours. La vitesse de synchronisation sera normalement supérieure au taux de profil. Ma ligne DSL se synchronise à 8M vers le bas, 1M vers le haut, mais le profil la limite à 6 / 512k. J'ai vu des lignes Uverse se synchroniser jusqu'à 60M mais j'ai toujours un profil de 25M.
la source
Personne n'a mentionné le chargement du lien.
Sur des liaisons autrement vides, il n'y a donc pas beaucoup de différence entre 1 Mo et 30 Mo - bien sûr, l'encodage peut être effectué au 1 / 30e du temps, mais cela est négligeable si la distance est le facteur dominant.
Cependant, si le lien 1 Mo est lourdement chargé (surchargé?), Vous verrez des temps de ping augmentés (et fluctuants).
La même charge de trafic sur une liaison de 30 Mo ne représente que quelques% de sa capacité et les temps de ping seront donc plus rapides et plus cohérents.
Le protocole de mesure active bidirectionnelle (TWAMP) définit une méthode flexible pour mesurer les performances IP aller-retour entre deux appareils d'un réseau prenant en charge la norme.
la source
La vraie réponse est que c'est compliqué.
La latence est composée de plusieurs composants.
Le temps passé à parcourir le support physique ne peut être modifié qu'en choisissant un support physique différent.
Le temps passé dans les files d'attente sera généralement réduit grâce à des liaisons plus rapides. Il en sera de même du temps consacré à la sérialisation et à la désérialisation des données.
Les effets sur le traitement peuvent devenir compliqués. Si l'étape de traitement reste la même, cela prendra généralement moins de temps à un débit de données plus rapide. Cependant, les techniques conçues pour extraire plus de bande passante des liaisons existantes peuvent également introduire des retards de traitement supplémentaires. Un exemple classique de ceci est l'entrelacement DSL.
la source