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 ?
On Wed, Nov 18, 2015 at 09:14:50AM CET, Pascal Hambourg said:
honeyshell a écrit : > De mon côté je regarde comment réduire mon ping vers un serveur de jeu. > Il semble que la solution d'utiliser un VPN améliore ce ping.
Non, pas forcément. Cela peut être pire, ou ne rien changer.
> Je me pose quand même la question pourquoi un flux crypté irait plus > vite qu'un flux normal, alors que le traceroute reste le même, vpn ou > non?
Le chiffrement n'entre en ligne de compte que si les opérateurs en chemin s'amusent à faire de la classification de flux. Sinon, l'usage d'un tunnel ou d'un VPN ne peut améliorer la latence que dans le cas ou le routage aller ou retour [*] est sous-optimal et fait un gros détour plutôt que suivre une route plus directe, ou passe par des liens congestionnés. Si et seulement si le routage du VPN et le routage entre le point de sortie du VPN et la destination évite les détours et congestions, alors la latence pourra être améliorée.
[*] Ne pas oublier que traceroute ne montre que le chemin aller.
Par contre, le VPN diminuant la MTU, une mauvaise gestion de la taille des paquets peut amener à des performances catastrophiques.
On Wed, Nov 18, 2015 at 09:14:50AM CET, Pascal Hambourg <pascal@plouf.fr.eu.org> said:
honeyshell a écrit :
> De mon côté je regarde comment réduire mon ping vers un serveur de jeu.
> Il semble que la solution d'utiliser un VPN améliore ce ping.
Non, pas forcément. Cela peut être pire, ou ne rien changer.
> Je me pose quand même la question pourquoi un flux crypté irait plus
> vite qu'un flux normal, alors que le traceroute reste le même, vpn ou
> non?
Le chiffrement n'entre en ligne de compte que si les opérateurs en
chemin s'amusent à faire de la classification de flux. Sinon, l'usage
d'un tunnel ou d'un VPN ne peut améliorer la latence que dans le cas ou
le routage aller ou retour [*] est sous-optimal et fait un gros détour
plutôt que suivre une route plus directe, ou passe par des liens
congestionnés. Si et seulement si le routage du VPN et le routage entre
le point de sortie du VPN et la destination évite les détours et
congestions, alors la latence pourra être améliorée.
[*] Ne pas oublier que traceroute ne montre que le chemin aller.
Par contre, le VPN diminuant la MTU, une mauvaise gestion de la taille
des paquets peut amener à des performances catastrophiques.
On Wed, Nov 18, 2015 at 09:14:50AM CET, Pascal Hambourg said:
honeyshell a écrit : > De mon côté je regarde comment réduire mon ping vers un serveur de jeu. > Il semble que la solution d'utiliser un VPN améliore ce ping.
Non, pas forcément. Cela peut être pire, ou ne rien changer.
> Je me pose quand même la question pourquoi un flux crypté irait plus > vite qu'un flux normal, alors que le traceroute reste le même, vpn ou > non?
Le chiffrement n'entre en ligne de compte que si les opérateurs en chemin s'amusent à faire de la classification de flux. Sinon, l'usage d'un tunnel ou d'un VPN ne peut améliorer la latence que dans le cas ou le routage aller ou retour [*] est sous-optimal et fait un gros détour plutôt que suivre une route plus directe, ou passe par des liens congestionnés. Si et seulement si le routage du VPN et le routage entre le point de sortie du VPN et la destination évite les détours et congestions, alors la latence pourra être améliorée.
[*] Ne pas oublier que traceroute ne montre que le chemin aller.
Par contre, le VPN diminuant la MTU, une mauvaise gestion de la taille des paquets peut amener à des performances catastrophiques.
Pascal Hambourg
honeyshell a écrit :
De mon côté je regarde comment réduire mon ping vers un serveur de jeu. Il semble que la solution d'utiliser un VPN améliore ce ping.
Non, pas forcément. Cela peut être pire, ou ne rien changer.
Je me pose quand même la question pourquoi un flux crypté irait plus vite qu'un flux normal, alors que le traceroute reste le même, vpn ou non?
Le chiffrement n'entre en ligne de compte que si les opérateurs en chemin s'amusent à faire de la classification de flux. Sinon, l'usage d'un tunnel ou d'un VPN ne peut améliorer la latence que dans le cas ou le routage aller ou retour [*] est sous-optimal et fait un gros détour plutôt que suivre une route plus directe, ou passe par des liens congestionnés. Si et seulement si le routage du VPN et le routage entre le point de sortie du VPN et la destination évite les détours et congestions, alors la latence pourra être améliorée.
[*] Ne pas oublier que traceroute ne montre que le chemin aller.
honeyshell a écrit :
De mon côté je regarde comment réduire mon ping vers un serveur de jeu.
Il semble que la solution d'utiliser un VPN améliore ce ping.
Non, pas forcément. Cela peut être pire, ou ne rien changer.
Je me pose quand même la question pourquoi un flux crypté irait plus
vite qu'un flux normal, alors que le traceroute reste le même, vpn ou
non?
Le chiffrement n'entre en ligne de compte que si les opérateurs en
chemin s'amusent à faire de la classification de flux. Sinon, l'usage
d'un tunnel ou d'un VPN ne peut améliorer la latence que dans le cas ou
le routage aller ou retour [*] est sous-optimal et fait un gros détour
plutôt que suivre une route plus directe, ou passe par des liens
congestionnés. Si et seulement si le routage du VPN et le routage entre
le point de sortie du VPN et la destination évite les détours et
congestions, alors la latence pourra être améliorée.
[*] Ne pas oublier que traceroute ne montre que le chemin aller.
De mon côté je regarde comment réduire mon ping vers un serveur de jeu. Il semble que la solution d'utiliser un VPN améliore ce ping.
Non, pas forcément. Cela peut être pire, ou ne rien changer.
Je me pose quand même la question pourquoi un flux crypté irait plus vite qu'un flux normal, alors que le traceroute reste le même, vpn ou non?
Le chiffrement n'entre en ligne de compte que si les opérateurs en chemin s'amusent à faire de la classification de flux. Sinon, l'usage d'un tunnel ou d'un VPN ne peut améliorer la latence que dans le cas ou le routage aller ou retour [*] est sous-optimal et fait un gros détour plutôt que suivre une route plus directe, ou passe par des liens congestionnés. Si et seulement si le routage du VPN et le routage entre le point de sortie du VPN et la destination évite les détours et congestions, alors la latence pourra être améliorée.
[*] Ne pas oublier que traceroute ne montre que le chemin aller.
Merci Pascal pour ta réponse. Donc si Philippe trouve une solution pour améliorer le routage, je pense que toute la communauté sera plus qu'intéressée par la solution ;)
Depuis 2 ou 3 ans, j'utilise Cloudflare qui est une sorte de CDN avec une techno
assez bizarre, qui va prendre tes DNS en charge. Ce n'est pas un VPN, même si
ça y ressemble aussi.
Dans les exemples de tracerouting que j'ai cité au début, j'atteins ces sites sous
Cloudflare en 5 sauts, contre 9 pour ceux qui ne le sont pas.
Je suis à Nanterre (FR 92), OVH à Roubaix (FR 59) et Cloudflare un peu partout.
La soluce de Cloudflare a des avantages qui correspondent à ceux d'un CDN en
plus de la simplicité de mise en place :
Un petit changement dans ta zone DNS ; C'est modulable et gratuit ; Avec un bon réseau de serveurs répartis sur tout l'hémisphère nord
Par contre si Cloudflare plante, ton site aussi. Au niveau sécurité ce n'est pas très
au point non plus. Au niveau référencement naturel, je ne sais pas très bien.
Personnellement j'en suis satisfait, mais les avis sont partagés Il existe pas mal
d'opinions négatives à lire sur le Web. À tester si le cur t'en dit.
Mais ce n'est encore rien à côté de ce que j'ai déjà vu. Donc il doit exister une, ou
des solutions pour diviser les temps de réponse DNS (la résolution) par 10 ou 20.
Il n'est pas impossible que la combinaison de plusieurs solutions soit possible, en
somme que DNS + Cloudflare => truc de ouf! Je ne sais pas, je suis à l'écoute.
Après tu as encore plein d'autres choses à prendre en compte, parce que le temps
de réponse utile pour un site en production, est quand l'utilisateur a fini de charger
la première page. Pour un serveur de jeu ça doit être sensiblement la même chose.=
Le 18 nov. 2015 à 09:20, honeyshell <honeyshell@honeyshell.com> a écrit :
Merci Pascal pour ta réponse. Donc si Philippe trouve une solution
pour améliorer le routage, je pense que toute la communauté sera plus
qu'intéressée par la solution ;)
Depuis 2 ou 3 ans, j'utilise Cloudflare qui est une sorte de CDN avec une techno
assez bizarre, qui va prendre tes DNS en charge. Ce n'est pas un VPN, même si
ça y ressemble aussi.
Dans les exemples de tracerouting que j'ai cité au début, j'atteins ces sites sous
Cloudflare en 5 sauts, contre 9 pour ceux qui ne le sont pas.
Je suis à Nanterre (FR 92), OVH à Roubaix (FR 59) et Cloudflare un peu partout.
La soluce de Cloudflare a des avantages qui correspondent à ceux d'un CDN en
plus de la simplicité de mise en place :
Un petit changement dans ta zone DNS ;
C'est modulable et gratuit ;
Avec un bon réseau de serveurs répartis sur tout l'hémisphère nord
Par contre si Cloudflare plante, ton site aussi. Au niveau sécurité ce n'est pas très
au point non plus. Au niveau référencement naturel, je ne sais pas très bien.
Personnellement j'en suis satisfait, mais les avis sont partagés Il existe pas mal
d'opinions négatives à lire sur le Web. À tester si le cur t'en dit.
Mais ce n'est encore rien à côté de ce que j'ai déjà vu. Donc il doit exister une, ou
des solutions pour diviser les temps de réponse DNS (la résolution) par 10 ou 20.
Il n'est pas impossible que la combinaison de plusieurs solutions soit possible, en
somme que DNS + Cloudflare => truc de ouf! Je ne sais pas, je suis à l'écoute.
Après tu as encore plein d'autres choses à prendre en compte, parce que le temps
de réponse utile pour un site en production, est quand l'utilisateur a fini de charger
la première page. Pour un serveur de jeu ça doit être sensiblement la même chose.=
Merci Pascal pour ta réponse. Donc si Philippe trouve une solution pour améliorer le routage, je pense que toute la communauté sera plus qu'intéressée par la solution ;)
Depuis 2 ou 3 ans, j'utilise Cloudflare qui est une sorte de CDN avec une techno
assez bizarre, qui va prendre tes DNS en charge. Ce n'est pas un VPN, même si
ça y ressemble aussi.
Dans les exemples de tracerouting que j'ai cité au début, j'atteins ces sites sous
Cloudflare en 5 sauts, contre 9 pour ceux qui ne le sont pas.
Je suis à Nanterre (FR 92), OVH à Roubaix (FR 59) et Cloudflare un peu partout.
La soluce de Cloudflare a des avantages qui correspondent à ceux d'un CDN en
plus de la simplicité de mise en place :
Un petit changement dans ta zone DNS ; C'est modulable et gratuit ; Avec un bon réseau de serveurs répartis sur tout l'hémisphère nord
Par contre si Cloudflare plante, ton site aussi. Au niveau sécurité ce n'est pas très
au point non plus. Au niveau référencement naturel, je ne sais pas très bien.
Personnellement j'en suis satisfait, mais les avis sont partagés Il existe pas mal
d'opinions négatives à lire sur le Web. À tester si le cur t'en dit.
Mais ce n'est encore rien à côté de ce que j'ai déjà vu. Donc il doit exister une, ou
des solutions pour diviser les temps de réponse DNS (la résolution) par 10 ou 20.
Il n'est pas impossible que la combinaison de plusieurs solutions soit possible, en
somme que DNS + Cloudflare => truc de ouf! Je ne sais pas, je suis à l'écoute.
Après tu as encore plein d'autres choses à prendre en compte, parce que le temps
de réponse utile pour un site en production, est quand l'utilisateur a fini de charger
la première page. Pour un serveur de jeu ça doit être sensiblement la même chose.=
la première page. Pour un serveur de jeu ça doit être sens iblement la même chose.
Philippe Gras
Le 18 nov. 2015 à 11:02, Eric Degenetais a écrit :
optimiser le temps de réponse DNS DES AUTRES (client final)? si ça existe vraiment, je serais curieux de savoir comment ça marche
Non, là n'est pas la question. Évidemment, quand tu visites un site après
une première visite, tu l'atteindras plus vite en raison de caches divers et
variés : DNS, mémoire, javascript, etc.
La mission consiste à réduire le temps de résolution DNS de ton site : $ traceroute -a henix.com traceroute to henix.com (92.243.26.155), 64 hops max, 52 byte packets 1 [AS0] net1lo3.bsput151.puteaux.francetelecom.net (193.253.171.8) 20.092 ms 19.467 ms 16.956 ms 2 [AS0] 10.123.183.10 (10.123.183.10) 16.549 ms 17.461 ms 25.457 ms 3 [AS0] ae20-0.ncidf103.puteaux.francetelecom.net (193.253.80.90) 16.478 ms 18.245 ms 15.899 ms 4 [AS0] ae51-0.nridf101.paris.francetelecom.net (193.252.98.94) 17.647 ms 17.274 ms 16.387 ms 5 [AS0] ae41-0.noidf001.paris.francetelecom.net (193.252.98.102) 16.747 ms 17.326 ms 16.796 ms 6 [AS0] 193.253.13.206 (193.253.13.206) 17.072 ms 17.656 ms 16.432 ms 7 [AS44530] lag-pop-th2-1.std-1.rt.hopus.net (37.77.32.3) 17.471 ms 17.664 ms 16.948 ms 8 [AS44530] gandi.std-1.rt.hopus.net (37.77.38.5) 16.555 ms 20.203 ms 19.475 ms 9 [AS29169] xe2-5-5-dist1-d.paris.gandi.net (217.70.176.242) 17.477 ms 18.253 ms 18.977 ms 10 [AS29169] www.henix.com (92.243.26.155) 16.985 ms 17.926 ms 15.724 ms
Bien sûr, c'est par rapport à un client X. Par exemple, mon AS0 mouline comme un âne, et ça personne n'y peut rien à part mon FAI.
Mais ensuite tu devrais pouvoir faire quelque chose
Quand tu passes henix.com à la moulinette de GTmetrix (Vancouver), tu vois la réponse à la première requête arriver à 2 secondes. Bon tu as pas mal de trucs à améliorer sur les autres caches (mémoire, headers, etc.), déjà .
Mais tu as là une résolution DNS en 156 ms, tandis que j'ai 2 ms en comparant avec un site chez Cloudflare.
Après, tu as 1,86 seconde d'attente, et moi 330 ms d'attente. Ensuite, ça charge.
Quand je regarde lemonde.fr, la page commence à charger à 44 ms
______________ Éric Dégenètais Henix
http://www.henix.com http://www.squashtest.org
Le 18 novembre 2015 10:53, Philippe Gras a écrit :
Le 18 nov. 2015 à 09:20, honeyshell a écrit :
Merci Pascal pour ta réponse. Donc si Philippe trouve une solution pour améliorer le routage, je pense que toute la communauté sera plus qu'intéressée par la solution ;)
Depuis 2 ou 3 ans, j'utilise Cloudflare qui est une sorte de CDN avec une techno
assez bizarre, qui va prendre tes DNS en charge. Ce n'est pas un VPN, même si
ça y ressemble aussi.
Dans les exemples de tracerouting que j'ai cité au début, j'atteins ces sites sous
Cloudflare en 5 sauts, contre 9 pour ceux qui ne le sont pas.
Je suis à Nanterre (FR 92), OVH à Roubaix (FR 59) et Cloudflare un peu partout.
La soluce de Cloudflare a des avantages qui correspondent à ceux d'un CDN en
plus de la simplicité de mise en place :
Un petit changement dans ta zone DNS ; C'est modulable et gratuit ; Avec un bon réseau de serveurs répartis sur tout l'hémisphè re nord
Par contre si Cloudflare plante, ton site aussi. Au niveau sécurité ce n'est pas très
au point non plus. Au niveau référencement naturel, je ne sais pas très bien.
Personnellement j'en suis satisfait, mais les avis sont partagés Il existe pas mal
d'opinions négatives à lire sur le Web. À tester si le cur t'en dit.
Mais ce n'est encore rien à côté de ce que j'ai déjà vu. Donc il doit exister une, ou
des solutions pour diviser les temps de réponse DNS (la résolution) par 10 ou 20.
Il n'est pas impossible que la combinaison de plusieurs solutions soit possible, en
somme que DNS + Cloudflare => truc de ouf! Je ne sais pas, je suis à l'écoute.
Après tu as encore plein d'autres choses à prendre en compte, parce que le temps
de réponse utile pour un site en production, est quand l'utilisateur a fini de charger
la première page. Pour un serveur de jeu ça doit être sensiblement la même chose.
Le 18 nov. 2015 à 11:02, Eric Degenetais <edegenetais@henix.fr> a écrit :
optimiser le temps de réponse DNS DES AUTRES (client final)?
si ça existe vraiment, je serais curieux de savoir comment ça marche
Non, là n'est pas la question. Évidemment, quand tu visites un site après
une première visite, tu l'atteindras plus vite en raison de caches divers et
variés : DNS, mémoire, javascript, etc.
La mission consiste à réduire le temps de résolution DNS de ton site :
$ traceroute -a henix.com
traceroute to henix.com (92.243.26.155), 64 hops max, 52 byte packets
1 [AS0] net1lo3.bsput151.puteaux.francetelecom.net (193.253.171.8) 20.092 ms 19.467 ms 16.956 ms
2 [AS0] 10.123.183.10 (10.123.183.10) 16.549 ms 17.461 ms 25.457 ms
3 [AS0] ae20-0.ncidf103.puteaux.francetelecom.net (193.253.80.90) 16.478 ms 18.245 ms 15.899 ms
4 [AS0] ae51-0.nridf101.paris.francetelecom.net (193.252.98.94) 17.647 ms 17.274 ms 16.387 ms
5 [AS0] ae41-0.noidf001.paris.francetelecom.net (193.252.98.102) 16.747 ms 17.326 ms 16.796 ms
6 [AS0] 193.253.13.206 (193.253.13.206) 17.072 ms 17.656 ms 16.432 ms
7 [AS44530] lag-pop-th2-1.std-1.rt.hopus.net (37.77.32.3) 17.471 ms 17.664 ms 16.948 ms
8 [AS44530] gandi.std-1.rt.hopus.net (37.77.38.5) 16.555 ms 20.203 ms 19.475 ms
9 [AS29169] xe2-5-5-dist1-d.paris.gandi.net (217.70.176.242) 17.477 ms 18.253 ms 18.977 ms
10 [AS29169] www.henix.com (92.243.26.155) 16.985 ms 17.926 ms 15.724 ms
Bien sûr, c'est par rapport à un client X. Par exemple, mon AS0 mouline comme
un âne, et ça personne n'y peut rien à part mon FAI.
Mais ensuite tu devrais pouvoir faire quelque chose
Quand tu passes henix.com à la moulinette de GTmetrix (Vancouver), tu vois la
réponse à la première requête arriver à 2 secondes. Bon tu as pas mal de trucs
à améliorer sur les autres caches (mémoire, headers, etc.), déjà .
Mais tu as là une résolution DNS en 156 ms, tandis que j'ai 2 ms en comparant
avec un site chez Cloudflare.
Après, tu as 1,86 seconde d'attente, et moi 330 ms d'attente. Ensuite, ça charge.
Quand je regarde lemonde.fr, la page commence à charger à 44 ms
______________
Éric Dégenètais
Henix
http://www.henix.com
http://www.squashtest.org
Le 18 novembre 2015 10:53, Philippe Gras <ph.gras@worldonline.fr> a écrit :
Le 18 nov. 2015 à 09:20, honeyshell <honeyshell@honeyshell.com> a écrit :
Merci Pascal pour ta réponse. Donc si Philippe trouve une solution
pour améliorer le routage, je pense que toute la communauté sera plus
qu'intéressée par la solution ;)
Depuis 2 ou 3 ans, j'utilise Cloudflare qui est une sorte de CDN avec une techno
assez bizarre, qui va prendre tes DNS en charge. Ce n'est pas un VPN, même si
ça y ressemble aussi.
Dans les exemples de tracerouting que j'ai cité au début, j'atteins ces sites sous
Cloudflare en 5 sauts, contre 9 pour ceux qui ne le sont pas.
Je suis à Nanterre (FR 92), OVH à Roubaix (FR 59) et Cloudflare un peu partout.
La soluce de Cloudflare a des avantages qui correspondent à ceux d'un CDN en
plus de la simplicité de mise en place :
Un petit changement dans ta zone DNS ;
C'est modulable et gratuit ;
Avec un bon réseau de serveurs répartis sur tout l'hémisphè re nord
Par contre si Cloudflare plante, ton site aussi. Au niveau sécurité ce n'est pas très
au point non plus. Au niveau référencement naturel, je ne sais pas très bien.
Personnellement j'en suis satisfait, mais les avis sont partagés Il existe pas mal
d'opinions négatives à lire sur le Web. À tester si le cur t'en dit.
Mais ce n'est encore rien à côté de ce que j'ai déjà vu. Donc il doit exister une, ou
des solutions pour diviser les temps de réponse DNS (la résolution) par 10 ou 20.
Il n'est pas impossible que la combinaison de plusieurs solutions soit possible, en
somme que DNS + Cloudflare => truc de ouf! Je ne sais pas, je suis à l'écoute.
Après tu as encore plein d'autres choses à prendre en compte, parce que le temps
de réponse utile pour un site en production, est quand l'utilisateur a fini de charger
la première page. Pour un serveur de jeu ça doit être sensiblement la même chose.
Le 18 nov. 2015 à 11:02, Eric Degenetais a écrit :
optimiser le temps de réponse DNS DES AUTRES (client final)? si ça existe vraiment, je serais curieux de savoir comment ça marche
Non, là n'est pas la question. Évidemment, quand tu visites un site après
une première visite, tu l'atteindras plus vite en raison de caches divers et
variés : DNS, mémoire, javascript, etc.
La mission consiste à réduire le temps de résolution DNS de ton site : $ traceroute -a henix.com traceroute to henix.com (92.243.26.155), 64 hops max, 52 byte packets 1 [AS0] net1lo3.bsput151.puteaux.francetelecom.net (193.253.171.8) 20.092 ms 19.467 ms 16.956 ms 2 [AS0] 10.123.183.10 (10.123.183.10) 16.549 ms 17.461 ms 25.457 ms 3 [AS0] ae20-0.ncidf103.puteaux.francetelecom.net (193.253.80.90) 16.478 ms 18.245 ms 15.899 ms 4 [AS0] ae51-0.nridf101.paris.francetelecom.net (193.252.98.94) 17.647 ms 17.274 ms 16.387 ms 5 [AS0] ae41-0.noidf001.paris.francetelecom.net (193.252.98.102) 16.747 ms 17.326 ms 16.796 ms 6 [AS0] 193.253.13.206 (193.253.13.206) 17.072 ms 17.656 ms 16.432 ms 7 [AS44530] lag-pop-th2-1.std-1.rt.hopus.net (37.77.32.3) 17.471 ms 17.664 ms 16.948 ms 8 [AS44530] gandi.std-1.rt.hopus.net (37.77.38.5) 16.555 ms 20.203 ms 19.475 ms 9 [AS29169] xe2-5-5-dist1-d.paris.gandi.net (217.70.176.242) 17.477 ms 18.253 ms 18.977 ms 10 [AS29169] www.henix.com (92.243.26.155) 16.985 ms 17.926 ms 15.724 ms
Bien sûr, c'est par rapport à un client X. Par exemple, mon AS0 mouline comme un âne, et ça personne n'y peut rien à part mon FAI.
Mais ensuite tu devrais pouvoir faire quelque chose
Quand tu passes henix.com à la moulinette de GTmetrix (Vancouver), tu vois la réponse à la première requête arriver à 2 secondes. Bon tu as pas mal de trucs à améliorer sur les autres caches (mémoire, headers, etc.), déjà .
Mais tu as là une résolution DNS en 156 ms, tandis que j'ai 2 ms en comparant avec un site chez Cloudflare.
Après, tu as 1,86 seconde d'attente, et moi 330 ms d'attente. Ensuite, ça charge.
Quand je regarde lemonde.fr, la page commence à charger à 44 ms
______________ Éric Dégenètais Henix
http://www.henix.com http://www.squashtest.org
Le 18 novembre 2015 10:53, Philippe Gras a écrit :
Le 18 nov. 2015 à 09:20, honeyshell a écrit :
Merci Pascal pour ta réponse. Donc si Philippe trouve une solution pour améliorer le routage, je pense que toute la communauté sera plus qu'intéressée par la solution ;)
Depuis 2 ou 3 ans, j'utilise Cloudflare qui est une sorte de CDN avec une techno
assez bizarre, qui va prendre tes DNS en charge. Ce n'est pas un VPN, même si
ça y ressemble aussi.
Dans les exemples de tracerouting que j'ai cité au début, j'atteins ces sites sous
Cloudflare en 5 sauts, contre 9 pour ceux qui ne le sont pas.
Je suis à Nanterre (FR 92), OVH à Roubaix (FR 59) et Cloudflare un peu partout.
La soluce de Cloudflare a des avantages qui correspondent à ceux d'un CDN en
plus de la simplicité de mise en place :
Un petit changement dans ta zone DNS ; C'est modulable et gratuit ; Avec un bon réseau de serveurs répartis sur tout l'hémisphè re nord
Par contre si Cloudflare plante, ton site aussi. Au niveau sécurité ce n'est pas très
au point non plus. Au niveau référencement naturel, je ne sais pas très bien.
Personnellement j'en suis satisfait, mais les avis sont partagés Il existe pas mal
d'opinions négatives à lire sur le Web. À tester si le cur t'en dit.
Mais ce n'est encore rien à côté de ce que j'ai déjà vu. Donc il doit exister une, ou
des solutions pour diviser les temps de réponse DNS (la résolution) par 10 ou 20.
Il n'est pas impossible que la combinaison de plusieurs solutions soit possible, en
somme que DNS + Cloudflare => truc de ouf! Je ne sais pas, je suis à l'écoute.
Après tu as encore plein d'autres choses à prendre en compte, parce que le temps
de réponse utile pour un site en production, est quand l'utilisateur a fini de charger
la première page. Pour un serveur de jeu ça doit être sensiblement la même chose.
Francois Lafont
On 18/11/2015 11:57, Philippe Gras wrote:
La mission consiste à réduire le temps de résolution DNS de ton site :
Bon, j'ai pas tout suivi alors désolé si que je suis à côté de la plaque mais pourquoi n'installes-tu pas un resolver DNS local sur ton serveur (type unbound par exemple) afin qu'il fasse office de cache ?
-- François Lafont
On 18/11/2015 11:57, Philippe Gras wrote:
La mission consiste à réduire le temps de résolution DNS de ton site :
Bon, j'ai pas tout suivi alors désolé si que je suis à côté de la plaque
mais pourquoi n'installes-tu pas un resolver DNS local sur ton serveur
(type unbound par exemple) afin qu'il fasse office de cache ?
La mission consiste à réduire le temps de résolution DNS de ton site :
Bon, j'ai pas tout suivi alors désolé si que je suis à côté de la plaque mais pourquoi n'installes-tu pas un resolver DNS local sur ton serveur (type unbound par exemple) afin qu'il fasse office de cache ?
-- François Lafont
Philippe Gras
Le 18 nov. 2015 à 12:38, Francois Lafont a écrit :
On 18/11/2015 11:57, Philippe Gras wrote:
La mission consiste à réduire le temps de résolution DNS de ton site :
Bon, j'ai pas tout suivi alors désolé si que je suis à côté de la plaque mais pourquoi n'installes-tu pas un resolver DNS local sur ton serveur (type unbound par exemple) afin qu'il fasse office de cache ?
Ah ! Ben c'est peut-être ça l'idée :-) Je vais me renseigner !
-- François Lafont
Le 18 nov. 2015 à 12:38, Francois Lafont <mathsattacks@free.fr> a écrit :
On 18/11/2015 11:57, Philippe Gras wrote:
La mission consiste à réduire le temps de résolution DNS de ton site :
Bon, j'ai pas tout suivi alors désolé si que je suis à côté de la plaque
mais pourquoi n'installes-tu pas un resolver DNS local sur ton serveur
(type unbound par exemple) afin qu'il fasse office de cache ?
Ah ! Ben c'est peut-être ça l'idée :-) Je vais me renseigner !
Le 18 nov. 2015 à 12:38, Francois Lafont a écrit :
On 18/11/2015 11:57, Philippe Gras wrote:
La mission consiste à réduire le temps de résolution DNS de ton site :
Bon, j'ai pas tout suivi alors désolé si que je suis à côté de la plaque mais pourquoi n'installes-tu pas un resolver DNS local sur ton serveur (type unbound par exemple) afin qu'il fasse office de cache ?
Ah ! Ben c'est peut-être ça l'idée :-) Je vais me renseigner !
-- François Lafont
Francois Lafont
On 18/11/2015 12:49, Philippe Gras wrote:
Ah ! Ben c'est peut-être ça l'idée :-) Je vais me renseigner !
Ce n'est vraiment pas compliqué et je pense que sur un serveur c'est vraiment indispensable. Le resolver DNS d'un Linux est très basique et il ne fait aucun cache par exemple. Perso, sauf erreur, je fais ceci (sur du Debian Jessie, mais je pense que ça devrait être pareil sous Wheezy) :
# Pour que unbound ne s'en réfère plus directement au root DNS. mv /etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf /etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf.disabled
# Je configure unbound pour qu'il interroge les DNS du FAI (en fait on met les DNS qu'on veut ici). cat >/etc/unbound/unbound.conf.d/forward.conf <<EOF forward-zone: name: "." forward-addr: $IP_DNS1 forward-addr: $IP_DNS2 forward-addr: $IP_DNS3 # etc.
EOF
# Par défaut, unbound écoute sur localhost uniquement. service unbound restart
# Je préfère configurer le fichier /etc/resolv.conf moi même, # j'aime pas trop resolvconf. apt-get purge resolvconf
# On met 127.0.0.1 (ie unbound) en premier et ensuite les IP des DNS que # unbound va consulter. Comme ça, si un jour le service unbound tombe # (perso j'ai jamais vu mais bon...) et bien le résolver local demandera # à ces DNS là et ça continuera à marcher quand même (même si y'aura sans # un timeout à chaque requête DNS. cat >/etc/resolv.conf <<EOF nameserver 127.0.0.1 nameserver $IP_DNS1 nameserver $IP_DNS2 nameserver $IP_DNS3 # etc. EOF -------------------------------------------
Voilà comment je fais globalement.
Si cela vous semble foireux/incomplet/perfectible que sais-je encore, je suis intéressé par toute remarque bien sûr, car le sujet m'intéresse beaucoup.
-- François Lafont
On 18/11/2015 12:49, Philippe Gras wrote:
Ah ! Ben c'est peut-être ça l'idée :-) Je vais me renseigner !
Ce n'est vraiment pas compliqué et je pense que sur un serveur c'est
vraiment indispensable. Le resolver DNS d'un Linux est très basique et
il ne fait aucun cache par exemple. Perso, sauf erreur, je fais ceci
(sur du Debian Jessie, mais je pense que ça devrait être pareil sous
Wheezy) :
# Pour que unbound ne s'en réfère plus directement au root DNS.
mv /etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf /etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf.disabled
# Je configure unbound pour qu'il interroge les DNS du FAI (en fait on met les DNS qu'on veut ici).
cat >/etc/unbound/unbound.conf.d/forward.conf <<EOF
forward-zone:
name: "."
forward-addr: $IP_DNS1
forward-addr: $IP_DNS2
forward-addr: $IP_DNS3
# etc.
EOF
# Par défaut, unbound écoute sur localhost uniquement.
service unbound restart
# Je préfère configurer le fichier /etc/resolv.conf moi même,
# j'aime pas trop resolvconf.
apt-get purge resolvconf
# On met 127.0.0.1 (ie unbound) en premier et ensuite les IP des DNS que
# unbound va consulter. Comme ça, si un jour le service unbound tombe
# (perso j'ai jamais vu mais bon...) et bien le résolver local demandera
# à ces DNS là et ça continuera à marcher quand même (même si y'aura sans
# un timeout à chaque requête DNS.
cat >/etc/resolv.conf <<EOF
nameserver 127.0.0.1
nameserver $IP_DNS1
nameserver $IP_DNS2
nameserver $IP_DNS3
# etc.
EOF
-------------------------------------------
Voilà comment je fais globalement.
Si cela vous semble foireux/incomplet/perfectible que sais-je encore, je
suis intéressé par toute remarque bien sûr, car le sujet m'intéresse beaucoup.
Ah ! Ben c'est peut-être ça l'idée :-) Je vais me renseigner !
Ce n'est vraiment pas compliqué et je pense que sur un serveur c'est vraiment indispensable. Le resolver DNS d'un Linux est très basique et il ne fait aucun cache par exemple. Perso, sauf erreur, je fais ceci (sur du Debian Jessie, mais je pense que ça devrait être pareil sous Wheezy) :
# Pour que unbound ne s'en réfère plus directement au root DNS. mv /etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf /etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf.disabled
# Je configure unbound pour qu'il interroge les DNS du FAI (en fait on met les DNS qu'on veut ici). cat >/etc/unbound/unbound.conf.d/forward.conf <<EOF forward-zone: name: "." forward-addr: $IP_DNS1 forward-addr: $IP_DNS2 forward-addr: $IP_DNS3 # etc.
EOF
# Par défaut, unbound écoute sur localhost uniquement. service unbound restart
# Je préfère configurer le fichier /etc/resolv.conf moi même, # j'aime pas trop resolvconf. apt-get purge resolvconf
# On met 127.0.0.1 (ie unbound) en premier et ensuite les IP des DNS que # unbound va consulter. Comme ça, si un jour le service unbound tombe # (perso j'ai jamais vu mais bon...) et bien le résolver local demandera # à ces DNS là et ça continuera à marcher quand même (même si y'aura sans # un timeout à chaque requête DNS. cat >/etc/resolv.conf <<EOF nameserver 127.0.0.1 nameserver $IP_DNS1 nameserver $IP_DNS2 nameserver $IP_DNS3 # etc. EOF -------------------------------------------
Voilà comment je fais globalement.
Si cela vous semble foireux/incomplet/perfectible que sais-je encore, je suis intéressé par toute remarque bien sûr, car le sujet m'intéresse beaucoup.
# Je configure unbound pour qu'il interroge les DNS du FAI (en fait on m et les DNS qu'on veut ici). cat >/etc/unbound/unbound.conf.d/forward.conf <<EOF forward-zone: name: "." forward-addr: $IP_DNS1 forward-addr: $IP_DNS2 forward-addr: $IP_DNS3 # etc.
# Je configure unbound pour qu'il interroge les DNS du FAI (en fait on m et les DNS qu'on veut ici).
cat >/etc/unbound/unbound.conf.d/forward.conf <<EOF
forward-zone:
name: "."
forward-addr: $IP_DNS1
forward-addr: $IP_DNS2
forward-addr: $IP_DNS3
# etc.
# Je configure unbound pour qu'il interroge les DNS du FAI (en fait on m et les DNS qu'on veut ici). cat >/etc/unbound/unbound.conf.d/forward.conf <<EOF forward-zone: name: "." forward-addr: $IP_DNS1 forward-addr: $IP_DNS2 forward-addr: $IP_DNS3 # etc.
