Par contre, quand je fais traceroute -I, tout se passe bien :-)
# traceroute -I google.com
traceroute to google.com (216.58.211.206), 30 hops max, 60 byte packets
1 vss-9b-6k.fr.eu (5.135.191.252) 0.684 ms 0.699 ms 0.872 ms
2 rbx-g1-a9.fr.eu (178.33.100.207) 3.461 ms 3.501 ms 5.102 ms
3 th2-1-a9.fr.eu (213.251.130.53) 4.288 ms 4.548 ms 4.578 ms
4 * * *
5 72.14.238.234 (72.14.238.234) 4.525 ms 4.536 ms 4.553 ms
6 209.85.245.83 (209.85.245.83) 11.334 ms 7.894 ms 7.696 ms
7 209.85.245.236 (209.85.245.236) 20.138 ms 19.948 ms 20.148 ms
8 216.239.50.135 (216.239.50.135) 19.560 ms 19.598 ms 19.603 ms
9 mad01s25-in-f14.1e100.net (216.58.211.206) 20.056 ms 20.065 ms =
20.068 ms
# traceroute -I cloudflare.net
traceroute to cloudflare.net (104.20.36.89), 30 hops max, 60 byte =
packets
1 vss-9b-6k.fr.eu (5.135.191.252) 0.674 ms 0.950 ms 1.001 ms
2 rbx-g2-a9.fr.eu (178.33.100.219) 0.869 ms 0.920 ms 0.928 ms
3 ams-5-a9.nl.eu (94.23.122.79) 8.649 ms 8.680 ms 8.695 ms
4 80.249.211.140 (80.249.211.140) 9.108 ms 9.134 ms 9.147 ms
5 104.20.36.89 (104.20.36.89) 9.206 ms 9.158 ms 9.227 ms
O=F9 ai-je merd=E9 dans ma configuration iptables ?
2). Ci-dessus, je vois que mon serveur est =E0 5 sauts de Cloudflare, =
mais =E0 9 sauts de
Google. C'est par ailleurs marrant quand je compare avec Google VF :
# traceroute -I google.fr
traceroute to google.fr (216.58.211.195), 30 hops max, 60 byte packets
1 vss-9b-6k.fr.eu (5.135.191.252) 0.650 ms 0.925 ms 0.974 ms
2 rbx-g1-a9.fr.eu (178.33.100.207) 0.936 ms 0.955 ms 0.966 ms
3 th2-1-a9.fr.eu (213.251.130.53) 4.044 ms 4.073 ms 4.088 ms
4 * * *
5 72.14.238.234 (72.14.238.234) 7.014 ms 7.028 ms 7.040 ms
6 209.85.245.83 (209.85.245.83) 4.815 ms 13.509 ms 13.451 ms
7 209.85.245.236 (209.85.245.236) 20.128 ms 20.187 ms 20.139 ms
8 216.239.50.135 (216.239.50.135) 19.718 ms 19.463 ms 19.586 ms
9 mad01s25-in-f195.1e100.net (216.58.211.195) 20.023 ms 20.036 ms =
19.944 ms
=C7a veut dire que google.{com | fr } est au m=EAme endroit (Mountain =
View ?) ;-)
Existe-t-il un outil qui permette de choisir ses routes en fonction d'un =
algorithme lambda,
afin que je rapproche mon serveur de Google par exemple ?
Le 18 nov. 2015 à 23:23, Pascal Hambourg a écrit :
Philippe Gras a écrit :
La mission consiste à réduire le temps de résolution DNS de ton site : $ traceroute -a henix.com
Le traceroute n'a rien à voir avec le temps de résolution DNS.
Oui, j'ai écrit une connerie. Mais à quel moment effectue-t-il cette opération ?
Quelle opération ? La résolution DNS ? A chaque fois qu'il a besoin de convertir un nom d'hôte en adresse IP et vice versa. Au début avant d'envoyer les paquets de traceroute pour déterminer l'adresse IP de la cible, à chaque réponse d'un routeur ou de la cible pour déterminer son nom d'hôte à partir de l'adresse source du paquet (résolution inverse).
C'est pas du TCP, en plus ?
Les requêtes DNS utilisent UDP par défaut. On peut aussi utiliser TCP dans certains cas particuliers comme quand la réponse est trop longue pour tenir dans un paquet UDP. C'est notamment le cas du transfert de zone (AXFR).
Traceroute va donner les routes qui mènent à destination. Comment sait-il où se trouve la destination ?
Ça dépend de ce que tu entends par "destination". Si c'est l'adresse IP de la cible, il la connaît après avoir effectué la résolution du nom d'hôte de la cible. Si c'est sa localisation, il ne la connaît pas. Traceroute ne fait qu'afficher les réponses des routeurs rencontrés en chemin, mais c'est biaisé : un routeur qui répond ne transmet pas le paquet, c'est le paquet suivant qui sera transmis mais passera peut-être par un routeur différent.
Philippe Gras a écrit :
Le 18 nov. 2015 à 23:23, Pascal Hambourg <pascal@plouf.fr.eu.org> a écrit :
Philippe Gras a écrit :
La mission consiste à réduire le temps de résolution DNS de ton site :
$ traceroute -a henix.com
Le traceroute n'a rien à voir avec le temps de résolution DNS.
Oui, j'ai écrit une connerie. Mais à quel moment effectue-t-il cette opération ?
Quelle opération ? La résolution DNS ? A chaque fois qu'il a besoin de
convertir un nom d'hôte en adresse IP et vice versa. Au début avant
d'envoyer les paquets de traceroute pour déterminer l'adresse IP de la
cible, à chaque réponse d'un routeur ou de la cible pour déterminer son
nom d'hôte à partir de l'adresse source du paquet (résolution inverse).
C'est pas du TCP, en plus ?
Les requêtes DNS utilisent UDP par défaut. On peut aussi utiliser TCP
dans certains cas particuliers comme quand la réponse est trop longue
pour tenir dans un paquet UDP. C'est notamment le cas du transfert de
zone (AXFR).
Traceroute va donner les routes qui mènent à destination. Comment sait-il où
se trouve la destination ?
Ça dépend de ce que tu entends par "destination". Si c'est l'adresse IP
de la cible, il la connaît après avoir effectué la résolution du nom
d'hôte de la cible. Si c'est sa localisation, il ne la connaît pas.
Traceroute ne fait qu'afficher les réponses des routeurs rencontrés en
chemin, mais c'est biaisé : un routeur qui répond ne transmet pas le
paquet, c'est le paquet suivant qui sera transmis mais passera peut-être
par un routeur différent.
Le 18 nov. 2015 à 23:23, Pascal Hambourg a écrit :
Philippe Gras a écrit :
La mission consiste à réduire le temps de résolution DNS de ton site : $ traceroute -a henix.com
Le traceroute n'a rien à voir avec le temps de résolution DNS.
Oui, j'ai écrit une connerie. Mais à quel moment effectue-t-il cette opération ?
Quelle opération ? La résolution DNS ? A chaque fois qu'il a besoin de convertir un nom d'hôte en adresse IP et vice versa. Au début avant d'envoyer les paquets de traceroute pour déterminer l'adresse IP de la cible, à chaque réponse d'un routeur ou de la cible pour déterminer son nom d'hôte à partir de l'adresse source du paquet (résolution inverse).
C'est pas du TCP, en plus ?
Les requêtes DNS utilisent UDP par défaut. On peut aussi utiliser TCP dans certains cas particuliers comme quand la réponse est trop longue pour tenir dans un paquet UDP. C'est notamment le cas du transfert de zone (AXFR).
Traceroute va donner les routes qui mènent à destination. Comment sait-il où se trouve la destination ?
Ça dépend de ce que tu entends par "destination". Si c'est l'adresse IP de la cible, il la connaît après avoir effectué la résolution du nom d'hôte de la cible. Si c'est sa localisation, il ne la connaît pas. Traceroute ne fait qu'afficher les réponses des routeurs rencontrés en chemin, mais c'est biaisé : un routeur qui répond ne transmet pas le paquet, c'est le paquet suivant qui sera transmis mais passera peut-être par un routeur différent.
Philippe Gras
Le 19 nov. 2015 à 01:16, honeyshell a écrit :
un petit cours sur le tcp : http://www.frameip.com/routage/#3.2_-_Lencapsulation
Merci :-) Je me demandais justement ce que c'était que cette affaire de couches
Comment sait-il où se trouve la destination ?
Tu demandes google.fr; ta trame va d'abord chez le DNS de ton FAI en priorité (à moins que tu changes ton DNS). Le DNS fera la résolution de nom vers l'adresse IP. Perso, j'ai pris les DNS de google (8.8.8.8, 8.8.4.4) pour des questions de performances => cela peut faire l'objet d'un test sur tes serveurs?
Tu les as ajoutées dans resolv.conf ? Je me suis posé cette question, en effet.
Une fois l'adresse récupérée, ta trame va passer par des routeurs de haut niveau, puis redescendre de "niveau" de routeur en fonction de ton IP. Mais ces routes peuvent être prédéfinies dans le cache des routeurs, et parfois ne pas être les plus rapides? C'est en gros le schéma que je connais. Mais je t'engage à vérifier par de la littérature, je ne m'y connais pas bcp en réseaux.
Le 19 nov. 2015 à 01:16, honeyshell <honeyshell@honeyshell.com> a écrit :
un petit cours sur le tcp : http://www.frameip.com/routage/#3.2_-_Lencapsulation
Merci :-) Je me demandais justement ce que c'était que cette affaire de couches
Comment sait-il où se trouve la destination ?
Tu demandes google.fr; ta trame va d'abord chez le DNS de ton FAI en
priorité (à moins que tu changes ton DNS). Le DNS fera la résolution
de nom vers l'adresse IP.
Perso, j'ai pris les DNS de google (8.8.8.8, 8.8.4.4) pour des
questions de performances => cela peut faire l'objet d'un test sur tes
serveurs?
Tu les as ajoutées dans resolv.conf ? Je me suis posé cette question, en effet.
Une fois l'adresse récupérée, ta trame va passer par des routeurs de
haut niveau, puis redescendre de "niveau" de routeur en fonction de
ton IP. Mais ces routes peuvent être prédéfinies dans le cache des
routeurs, et parfois ne pas être les plus rapides?
C'est en gros le schéma que je connais. Mais je t'engage à vérifier
par de la littérature, je ne m'y connais pas bcp en réseaux.
un petit cours sur le tcp : http://www.frameip.com/routage/#3.2_-_Lencapsulation
Merci :-) Je me demandais justement ce que c'était que cette affaire de couches
Comment sait-il où se trouve la destination ?
Tu demandes google.fr; ta trame va d'abord chez le DNS de ton FAI en priorité (à moins que tu changes ton DNS). Le DNS fera la résolution de nom vers l'adresse IP. Perso, j'ai pris les DNS de google (8.8.8.8, 8.8.4.4) pour des questions de performances => cela peut faire l'objet d'un test sur tes serveurs?
Tu les as ajoutées dans resolv.conf ? Je me suis posé cette question, en effet.
Une fois l'adresse récupérée, ta trame va passer par des routeurs de haut niveau, puis redescendre de "niveau" de routeur en fonction de ton IP. Mais ces routes peuvent être prédéfinies dans le cache des routeurs, et parfois ne pas être les plus rapides? C'est en gros le schéma que je connais. Mais je t'engage à vérifier par de la littérature, je ne m'y connais pas bcp en réseaux.
honeyshell
oui dans resolv.conf à lire : http://debian-facile.org/doc:systeme:resolv.conf
oui dans resolv.conf
à lire : http://debian-facile.org/doc:systeme:resolv.conf
Déjà, ce n'est pas un pavé comme on voit souvent dans ce genre de domaine. Le livre est truffé de nombreux schémas vraiment clairs et en plus il a une approche du haut vers le bas (par rapport aux niveaux des protocoles) ce qui est, je trouve, assez pédagogique. En effet, souvent dans ce domaine les livres commencent souvent par le bas niveau ce qui n'est pas forcément le plus intéressant pour celui qui administre des serveurs. Bref, je trouve que c'est une très bonne référence, tout à fait abordable.
-- François Lafont
Bonsoir,
On 19/11/2015 11:40, Philippe Gras wrote:
Merci :-) Je me demandais justement ce que c'était que cette affaire de couches…
Si tu veux avoir quelques bases sur la notion de réseau, sur la pile TCP/IP etc.
personnellement je te conseille vivement ce livre :
Déjà, ce n'est pas un pavé comme on voit souvent dans ce genre de domaine. Le livre
est truffé de nombreux schémas vraiment clairs et en plus il a une approche du haut
vers le bas (par rapport aux niveaux des protocoles) ce qui est, je trouve, assez
pédagogique. En effet, souvent dans ce domaine les livres commencent souvent par le
bas niveau ce qui n'est pas forcément le plus intéressant pour celui qui administre
des serveurs. Bref, je trouve que c'est une très bonne référence, tout à fait abordable.
Déjà, ce n'est pas un pavé comme on voit souvent dans ce genre de domaine. Le livre est truffé de nombreux schémas vraiment clairs et en plus il a une approche du haut vers le bas (par rapport aux niveaux des protocoles) ce qui est, je trouve, assez pédagogique. En effet, souvent dans ce domaine les livres commencent souvent par le bas niveau ce qui n'est pas forcément le plus intéressant pour celui qui administre des serveurs. Bref, je trouve que c'est une très bonne référence, tout à fait abordable.
