Mais traceroute/mtr ne montrent que le chemin aller, pas le chemin retour. Or le routage n'est pas forcément symétrique.
C'est tout Í fait juste. On utilise alors une looking glass au plus près de la destination pour confirmer le chemin suivi en direction de notre machine. Et le ping tient compte de l'aller et du retour. Il peut arriver que le délai TCP ou UDP soit différent du délai ICMP, mais sur équipements finaux ça me semble rare, ou bien?
Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
Mais traceroute/mtr ne montrent que le chemin aller, pas le chemin
retour. Or le routage n'est pas forcément symétrique.
C'est tout Í fait juste. On utilise alors une looking glass au plus près
de la destination pour confirmer le chemin suivi en direction de notre
machine.
Et le ping tient compte de l'aller et du retour. Il peut arriver que le
délai TCP ou UDP soit différent du délai ICMP, mais sur équipements
finaux ça me semble rare, ou bien?
Mais traceroute/mtr ne montrent que le chemin aller, pas le chemin retour. Or le routage n'est pas forcément symétrique.
C'est tout Í fait juste. On utilise alors une looking glass au plus près de la destination pour confirmer le chemin suivi en direction de notre machine. Et le ping tient compte de l'aller et du retour. Il peut arriver que le délai TCP ou UDP soit différent du délai ICMP, mais sur équipements finaux ça me semble rare, ou bien?
zeLittle de Médicis, un gueux
"Marc SCHAEFER" a écrit dans le message de groupe de discussion:
Pascal Hambourg wrote: Mais traceroute/mtr ne montrent que le chemin aller, pas le chemin retour. Or le routage n'est pas forcément symétrique.
C'est tout Í fait juste. On utilise alors une looking glass au plus près de la destination pour confirmer le chemin suivi en direction de notre machine. Et le ping tient compte de l'aller et du retour. Il peut arriver que le délai TCP ou UDP soit différent du délai ICMP, mais sur équipements finaux ça me semble rare, ou bien?
Merci pour vos clarifications. Je comprends mieux l'intérêt des "looking glass" pour valider un chemin du retour problématique de son FAI par rapport Í la moyenne des autres. Sinon, après, Í machine égale et QoS (quality of service = f(hops) très probablement) égale, l'optimisation peut venir du socket logiciel (défragmenter le datagramme IP en tenant compte de la MTU), voire déménager pour se rapprocher du central téléphonique dit de dégroupement des équipements des différents opérateurs FAI et téléphoniques. M'enfin, il faut aimer avoir une vue donnant sur un central téléphonique :) .
"Marc SCHAEFER" a écrit dans le message de groupe de discussion:
Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
Mais traceroute/mtr ne montrent que le chemin aller, pas le chemin
retour. Or le routage n'est pas forcément symétrique.
C'est tout Í fait juste. On utilise alors une looking glass au plus près
de la destination pour confirmer le chemin suivi en direction de notre
machine.
Et le ping tient compte de l'aller et du retour. Il peut arriver que le
délai TCP ou UDP soit différent du délai ICMP, mais sur équipements
finaux ça me semble rare, ou bien?
Merci pour vos clarifications. Je comprends mieux l'intérêt des "looking
glass" pour valider un chemin du retour problématique de son FAI par rapport
Í la moyenne des autres.
Sinon, après, Í machine égale et QoS (quality of service = f(hops) très
probablement) égale, l'optimisation peut venir du socket logiciel
(défragmenter le datagramme IP en tenant compte de la MTU), voire déménager
pour se rapprocher du central téléphonique dit de dégroupement des
équipements des différents opérateurs FAI et téléphoniques. M'enfin, il faut
aimer avoir une vue donnant sur un central téléphonique :) .
"Marc SCHAEFER" a écrit dans le message de groupe de discussion:
Pascal Hambourg wrote: Mais traceroute/mtr ne montrent que le chemin aller, pas le chemin retour. Or le routage n'est pas forcément symétrique.
C'est tout Í fait juste. On utilise alors une looking glass au plus près de la destination pour confirmer le chemin suivi en direction de notre machine. Et le ping tient compte de l'aller et du retour. Il peut arriver que le délai TCP ou UDP soit différent du délai ICMP, mais sur équipements finaux ça me semble rare, ou bien?
Merci pour vos clarifications. Je comprends mieux l'intérêt des "looking glass" pour valider un chemin du retour problématique de son FAI par rapport Í la moyenne des autres. Sinon, après, Í machine égale et QoS (quality of service = f(hops) très probablement) égale, l'optimisation peut venir du socket logiciel (défragmenter le datagramme IP en tenant compte de la MTU), voire déménager pour se rapprocher du central téléphonique dit de dégroupement des équipements des différents opérateurs FAI et téléphoniques. M'enfin, il faut aimer avoir une vue donnant sur un central téléphonique :) .
Jo Engo
Le Fri, 13 Aug 2021 18:03:56 +0200, zeLittle de Médicis, un gueux a écrit :
M'enfin, il faut aimer avoir une vue donnant sur un central téléphonique .
En passant, si on recommande d'utiliser un miroir proche géographiquement, ce n'est pas pour une question de performance, mais pour ajuster la balance entre les serveurs. -- Les cons, ça ose tout ; c'est même Í ça qu'on les reconnaÍ®t. -+- Michel Audiard -+-
Le Fri, 13 Aug 2021 18:03:56 +0200, zeLittle de Médicis, un gueux a
écrit :
M'enfin, il faut aimer avoir une vue donnant sur un central téléphonique
.
En passant, si on recommande d'utiliser un miroir proche
géographiquement, ce n'est pas pour une question de performance, mais
pour ajuster la balance entre les serveurs.
--
Les cons, ça ose tout ; c'est même Í ça qu'on les reconnaÍ®t.
-+- Michel Audiard -+-
Le Fri, 13 Aug 2021 18:03:56 +0200, zeLittle de Médicis, un gueux a écrit :
M'enfin, il faut aimer avoir une vue donnant sur un central téléphonique .
En passant, si on recommande d'utiliser un miroir proche géographiquement, ce n'est pas pour une question de performance, mais pour ajuster la balance entre les serveurs. -- Les cons, ça ose tout ; c'est même Í ça qu'on les reconnaÍ®t. -+- Michel Audiard -+-
Pascal Hambourg
Le 14/08/2021 Í 10:30, Jo Engo a écrit :
En passant, si on recommande d'utiliser un miroir proche géographiquement, ce n'est pas pour une question de performance, mais pour ajuster la balance entre les serveurs.
L'un n'empêche pas l'autre. D'autre part, quel est l'intérêt d'équilibrer la charge entre les serveurs si ce n'est pas pour une question de performance ?
Le 14/08/2021 Í 10:30, Jo Engo a écrit :
En passant, si on recommande d'utiliser un miroir proche
géographiquement, ce n'est pas pour une question de performance, mais
pour ajuster la balance entre les serveurs.
L'un n'empêche pas l'autre. D'autre part, quel est l'intérêt
d'équilibrer la charge entre les serveurs si ce n'est pas pour une
question de performance ?
En passant, si on recommande d'utiliser un miroir proche géographiquement, ce n'est pas pour une question de performance, mais pour ajuster la balance entre les serveurs.
L'un n'empêche pas l'autre. D'autre part, quel est l'intérêt d'équilibrer la charge entre les serveurs si ce n'est pas pour une question de performance ?
Jo Engo
Le Sat, 14 Aug 2021 11:48:10 +0200, Pascal Hambourg a écrit :
L'un n'empêche pas l'autre. D'autre part, quel est l'intérêt d'équilibrer la charge entre les serveurs si ce n'est pas pour une question de performance ?
Répartir la charge entre les différents «Â tuyaux » pour ne pes surcharger tel ou tel serveur, c'est en effet aussi une question de performance du point de vue du client, mais pas que. -- Nous pardonnons aisément Í nos amis les défauts qui ne nous regardent pas. -+- François de La Rochefoucauld (1613-1680), Maximes 428 -+-
Le Sat, 14 Aug 2021 11:48:10 +0200, Pascal Hambourg a écrit :
L'un n'empêche pas l'autre. D'autre part, quel est l'intérêt
d'équilibrer la charge entre les serveurs si ce n'est pas pour une
question de performance ?
Répartir la charge entre les différents «Â tuyaux » pour ne pes surcharger
tel ou tel serveur, c'est en effet aussi une question de performance du
point de vue du client, mais pas que.
--
Nous pardonnons aisément Í nos amis les défauts qui ne nous regardent
pas.
-+- François de La Rochefoucauld (1613-1680), Maximes 428 -+-
Le Sat, 14 Aug 2021 11:48:10 +0200, Pascal Hambourg a écrit :
L'un n'empêche pas l'autre. D'autre part, quel est l'intérêt d'équilibrer la charge entre les serveurs si ce n'est pas pour une question de performance ?
Répartir la charge entre les différents «Â tuyaux » pour ne pes surcharger tel ou tel serveur, c'est en effet aussi une question de performance du point de vue du client, mais pas que. -- Nous pardonnons aisément Í nos amis les défauts qui ne nous regardent pas. -+- François de La Rochefoucauld (1613-1680), Maximes 428 -+-
