Le pontage ajoute-t-il du retard?

Si j'utilise un pont pour effectuer le reniflement du trafic comme l'homme au milieu, le pont ajoutera-t-il un retard? Et quel mot dois-je utiliser retard ou latence?

— nufuniliza
source

Si vous voulez un délai nul, utilisez un robinet - le signal est répliqué électriquement (ou optiquement), donc vous voyez exactement ce qui a été envoyé (erreurs et tout) [note: ils sont chers, malgré la logique de 5 $ à l'intérieur]

— Ricky Beam

Réponses:

Salut et bienvenue à Network Engineering.

Quant à «retard» vs «latence»: Les termes ne sont pas toujours utilisés de manière cohérente. Quelques conseils peuvent être trouvés ici .

Je pense qu'en général, le terme latence est utilisé lorsque l'on regarde les temps de bout en bout pour une direction, qui sont essentiellement composés de la somme de tous les retards de propagation, de sérialisation, de mise en mémoire tampon (et éventuellement de traitement) introduits par les divers composants le long du chemin de la source à la destination (et retour, si l'on veut parler des temps d'aller-retour (RTT)). Vous pouvez donc dire qu'un pont ajoute un peu de retard à la latence globale.

(section suivante modifiée après un commentaire utile) Un pont, comparé à un câble direct, ajoutera au moins une fois le délai de sérialisation du support réseau donné (du côté de sortie du pont), après le traitement, pour envoyer les bits de la trame à nouveau du côté de la sortie. Bien sûr, une quantité de retard de sérialisation est ajoutée par direction , et comme la majorité des cas d'utilisation nécessite (au moins certaines) des données pour circuler dans l'une ou l'autre direction, le pont finira par ajouter deux fois le retard de sérialisation.

Voir également cette question et wiki.geant.org pour son tableau sur les retards de sérialisation).

Dans votre cas, un délai supplémentaire de mise en mémoire tampon et de traitement se produira en raison de "l'homme au milieu". Le montant dépendra entièrement de la capacité de traitement du logiciel de pontage donné sur la plate-forme donnée, et des différentes fonctionnalités et modules auxquels le cadre est soumis.

— Marc 'netztier' Luethi
source

Je n'ai pas pris mon café, alors je ne pense peut-être pas bien, mais l'ajout d'un pont ajoute-t-il nécessairement deux fois le délai de sérialisation? Évidemment, cela ajoutera toujours un délai de sérialisation (à moins qu'il n'y ait une sorte de coupure en cours), mais la sérialisation «d'envoi» se produit en parallèle avec la désérialisation du récepteur suivant (qui allait toujours se produire de toute façon), donc ce n'est pas le cas -il seulement un retard supplémentaire au total? Désolé si ce n'est pas très clair ...

— psmears

@psmears Le délai de sérialisation lorsque le pont envoie la trame à l'extrémité distante se produira dans tous les cas, convenu. Quant à la réception ... Imaginons un câble "direct" par ailleurs identique, contournant le pont, où la même séquence de bits est envoyée de manière synchrone, mais contournant le pont. Dans le câble, les bits se propagent le long de la ligne, tandis que le pont attend que le dernier bit commence à traiter ... Oh. vous avez raison, merci! Il est temps pour un montage, alors.

— Marc 'netztier' Luethi

Le délai de sérialisation est à la vitesse du fil, il ne s'agit donc pas d'un retard important. La plupart des commutateurs d'entreprise modernes commutent à la vitesse du fil, donc tout retard est très, très petit, probablement causé par la congestion et la mise en file d'attente sur une interface sursouscrite.

— Ron Maupin

Oui, un pont / commutateur ajoute un certain retard à une trame - de l'ordre de 1 à 20 µs.

Pour les commutateurs, vous parlez généralement de latence - le délai entre la réception d'une trame et sa transmission sur un autre port. Un commutateur nécessite un certain temps pour recevoir l'adresse de destination et prendre la décision de transfert. Les commutateurs de stockage et de retransmission (le type commun) doivent recevoir la trame entière avant de commencer à transmettre. Les commutateurs de coupure à grande vitesse peuvent descendre en dessous de 1 µs. Edit : comme @kasperd l'a correctement souligné, la coupure n'est possible qu'avec les ports source et de destination à la même vitesse ou en descendant.

— Zac67
source

Il convient de noter que la coupure n'atteint des performances optimales que lorsque les liaisons entrantes et sortantes s'exécutent au même débit binaire. Et il se pourrait qu'aucun fournisseur ne se soit même donné la peine d'implémenter le découpage pour des scénarios à débit binaire mixte.

— kasperd

@Kasperd Cisco, pour sa gamme Nexus 3000, revendique une "coupure" pour des vitesses identiques et des scénarios d'abaissement de vitesse (40G -> 1 / 10G), mais pas pour des accélérations (1 / 10G -> 40g). cisco.com/c/en/us/td/docs/switches/datacenter/nexus3000/sw/…

— Marc 'netztier' Luethi

@kasperd & Marc'netztier'Luethi - Absolument, merci. Il est impossible de couper avec l'intensification, car vous manquez rapidement de données (sauf si vous avez maintenant la longueur d'image que vous n'avez pas).

— Zac67

@ Zac67 La longueur est connue sur certains cadres mais pas sur tous les cadres. (Et après avoir lu comment cela fonctionne, je regrette en quelque sorte de l'avoir recherché en premier lieu.)

— kasperd