ping les US

[ey74]

Bonjour,
je suis en Europe et je ping le site de l'université de Berkeley avec un temps de 20ms.

Comment est-ce possible ? Si la vitesse de la lumière de la fibre est d'environ 200 000 km/s, je devrais être plus proche des 90ms non ?
J'imaginais qu'ils avaient peut etre un serveur en europe, mais quand je regarde l'IP a priori elle est bien aux US.

Je vous remercie
-----

[pm42]

Il est possible que via les mécanismes de CDN tu sois dirigé vers un cache plus proche.

[Flyingbike]

et moi 4ms

[agitateur]

et moi 4ms

Ouaip mais avec 'flying" dans le pseudo, on ne peut pas exclure une vitesse hyper lumière.

[A voir en vidéo sur Futura]

[Flyingbike]

n'empêche que la question est intéressante. Effectivement l'IP pinguée est bien aux US, ça se confirme avec traceroute. Si ça renvoyait à un miroir, on aurait l'IP du miroir... ?

Peut être que Ikhar pourra faire une explication (celles du web ne sont pas convaincantes)

[JPL]

À la réflexion ton 4 ms me paraît peu crédible.

[pm42]

J'ai aussi 4ms. Pour être plus exact un temps variable entre 3.5 et 65 ms. Ce qui pourrait s'expliquer par un routage différent des paquets en fonction des gestions de cache.
traceroute est différent : il n'y a pas de protocole en soi donc le programme "découvre" les routes en envoyant des requêtes avec un nombre de plus en plus grand de sauts possibles ce qui peut lui faire "rater" le proxy.

[Flyingbike]

Pourtant traceroute aboutit à la même IP que ping qui lui te dit qu’il existe plusieurs IP pour Berkeley.edu. L’ip atteinte est bien réputée pour être aux us.

[pm42]

Oui c'est ce que je disais au début : pour une même IP tu es routé sur différents serveurs en fonction de ta position géographique :

https://gcore.com/learning/what-is-a...0administrator.

https://superuser.com/questions/1555...-europe-and-us

C'est aussi utilisé par les serveurs DNS : quand tu dis que tu utilises celui de Google par exemple avec l'IP 8.8.8.8, toutes les requêtes ne partent pas aux USA, ce ne serait pas tenable ni fiable.
On sait faire la même chose pour les contenus.

https://fr.wikipedia.org/wiki/R%C3%A...ion_de_contenu
https://www.cloudflare.com/fr-fr/lea...ycast-network/


Qui plus est, c'est une des techniques qui font que les attaques DDOS ne marchent plus vraiment de nos jours.

[Flyingbike]

oui je sais bien, mais ce que j'ai plus de mal à expliquer, c'est que l'IP effectivement testée est bien localisée aux US, visiblement. Donc le ping n'atteindrait pas un "miroir local".

Il y a un détail qui m'échappe.

[pm42]

Il n'y a pas d'IP effectivement testée puisque plusieurs serveurs ont la même,
Elle est localisée aux US parce que c'est là où est le serveur maître. Mais les copies avec la même sont eux un peu partout.
Cela veut simplement dire que tu ne peux pas faire confiance à la localisation par IP dans ce cas.

Par exemple en ce moment je suis à Berlin et si je fais un traceroute sur www.berkeley.edu, j'atteins en 7ms via le réseau Colt allemand puis un CDN allemand 141.193.213.20 qui est bien localisée officiellement aux USA mais en pratique est quelque part à Hambourg.

[Flyingbike]

Il n'y a pas d'IP effectivement testée puisque plusieurs serveurs ont la même,
Elle est localisée aux US parce que c'est là où est le serveur maître. Mais les copies avec la même sont eux un peu partout.
Cela veut simplement dire que tu ne peux pas faire confiance à la localisation par IP dans ce cas.

c'est la seule explication logique en effet, mais autant il parait logique que l'usager cherchant à atteindre Berkeley.edu atteigne en réalité le miroir le plus proche en toute transparence, autant il me parait pas clair que les routes obtenues ne soient pas représentatives de ce qui se passe en vrai...

Je vais tester un truc ou deux.

[Flyingbike]

Bon, ça ne m'aide pas.

J'ai fait un ping de Berkeley.edu depuis l'argentine, la Thaïlande, les US, et l'IP testée est toujours la même. autour des 100ms depuis les Amériques, 250 depuis la Thaïlande, et toujours 5 depuis la France. (en flushant le dns bien sur)


Il me parait contre intuitif qu'une seule et même IP permette d'atteindre plusieurs machines physiquement distinctes. C'est peut être ça qui m'échappe.

[Flyingbike]

https://blog.cloudflare.com/cloudflares-architecture-eliminating-single-p/

Dans ce lien trouvé dans un de tes liens, il y a une explication qui lève mes doutes :

Anycast at the WAN

At CloudFlare, we use Anycast at two levels: the WAN and the LAN. At the WAN level, every router in all of CloudFlare's 23 data centers announces all of our external-facing IP addresses. For example, one of the IPs that CloudFlare announces for DNS services is 173.245.58.205. A route to that IP address is announced from all 23 CloudFlare data centers. When you send a packet to that IP address, it passes through a series of routers. Those routers look at the available paths to CloudFlare's end points and send the packet down the one with the fewest stops along the way (i.e., "hops"). You can run a traceroute to see each of these steps.

If I run a traceroute from CloudFlare's office in San Francisco, the path my packets take is:

$ traceroute 173.245.58.205
traceroute to 173.245.58.205 (173.245.58.205), 64 hops max, 52 byte packets
1  192.168.2.1 (192.168.2.1)  3.473 ms  1.399 ms  1.247 ms
2  10.10.11.1 (10.10.11.1)  3.136 ms  2.857 ms  3.206 ms
3  ge-0-2-5.cr1.sfo1.us.nlayer.net (69.22.X.X)  2.936 ms  3.405 ms  3.193 ms
4  ae3-70g.cr1.pao1.us.nlayer.net (69.22.143.170)  3.638 ms  4.076 ms  3.911 ms
5  ae1-70g.cr1.sjc1.us.nlayer.net (69.22.143.165)  4.833 ms  4.874 ms  4.973 ms
6  ae1-40g.ar2.sjc1.us.nlayer.net (69.22.143.118)  8.926 ms  8.529 ms  6.742 ms
7  as13335.xe-8-0-5.ar2.sjc1.us.nlayer.net (69.22.130.146)  5.048 ms
8  173.245.58.205 (173.245.58.205)  4.601 ms  4.338 ms  4.611 ms
If you run the same traceroute from a Linode server in London, the path my packets take is:

$ traceroute 173.245.58.205
traceroute to 173.245.58.205 (173.245.58.205), 30 hops max, 60 byte packets
1  212.111.X.X (212.111.X.X)  6.574 ms  6.514 ms  6.522 ms
2  212.111.33.X (212.111.33.X)  0.934 ms  0.935 ms  0.969 ms
3  85.90.238.69 (85.90.238.69)  1.396 ms  1.381 ms  1.405 ms
4  ldn-b3-link.telia.net (80.239.167.93)  0.700 ms  0.696 ms  0.670 ms
5  ldn-bb1-link.telia.net (80.91.247.24)  2.349 ms  0.700 ms  0.671 ms
6  ldn-b5-link.telia.net (80.91.246.147)  0.759 ms  0.771 ms  0.774 ms
7  cloudflare-ic-154357-ldn-b5.c.telia.net (80.239.161.246)  0.917 ms  0.853 ms  0.833 ms
8  173.245.58.205 (173.245.58.205)  0.972 ms  1.292 ms  0.916 ms
In both cases, the 8th and final hop is the same. You can tell, however, that they are hitting different CloudFlare data centers from hints in the 7th hop (highlighted in red below): as13335.xe-8-0-5.ar2.sjc1.us.nlayer.net suggesting it is hitting San Jose and cloudflare-ic-154357-ldn-b5.c.telia.net suggesting it is hitting London.

C'est logique, mais il faut juste oublier le concept de 1 IP = 1 machine, worldwide..

[MissJenny]

$ nslookup berkeley.edu
Server:        212.27.40.240
Address:    212.27.40.240#53

Non-authoritative answer:
Name:    berkeley.edu
Address: 141.193.213.20
Name:    berkeley.edu
Address: 141.193.213.21

$ traceroute 212.27.40.240
traceroute to 212.27.40.240 (212.27.40.240), 30 hops max, 60 byte packets
 1  _gateway (192.168.0.254)  1.480 ms  1.873 ms  1.863 ms
 2  station11.multimania.isdnet.net (194.149.174.108)  31.088 ms  32.088 ms  32.500 ms
 3  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  34.562 ms  36.134 ms  36.460 ms

à mon avis le temps affiché par ping est une estimation et pas une mesure.

[Flyingbike]

Et en traceroute, depuis la France puis depuis les US :

traceroute to berkeley.edu (141.193.213.20), 64 hops max, 40 byte packets 1  livebox (192.168.1.1)  2.087 ms  0.974 ms  0.837 ms
 2  8xx5 (80.xx.25)  2.376 ms  3.745 ms  2.543 ms
 3  ae117-0.ncidf103.rbci.orange.net (193.253.80.38)  3.301 ms  3.552 ms  3.078 ms
 4  ae41-0.niidf101.rbci.orange.net (193.252.159.41)  3.602 ms  4.207 ms  3.525 ms
 5  * * *
 6  bundle-ether305.partr2.saint-denis.opentransit.net (193.251.133.23)  4.019 ms  3.791 ms  3.680 ms
 7  cloudflare-22.gw.opentransit.net (193.251.150.160)  4.147 ms
    cloudflare-23.gw.opentransit.net (193.251.150.166)  6.235 ms  6.802 ms
 8  172.71.132.4 (172.71.132.4)  3.491 ms  7.373 ms
    172.71.124.2 (172.71.124.2)  4.452 ms
 9  141.193.213.20 (141.193.213.20)  3.790 ms  4.031 ms  4.447 ms

1  10.2.0.1 (10.2.0.1)  116.393 ms  114.651 ms  113.808 ms 2  irxxxxx,ro (31.13.189.225)  127.879 ms  113.517 ms  155.422 ms
 3  146.70.0.211 (146.70.0.211)  116.451 ms
    146.70.0.221 (146.70.0.221)  114.635 ms
    146.70.0.211 (146.70.0.211)  115.835 ms
 4  de-cix-new-york.as13335.net (206.82.104.31)  117.034 ms  115.541 ms  132.527 ms
 5  172.70.108.2 (172.70.108.2)  116.578 ms
    172.70.112.2 (172.70.112.2)  116.087 ms
    162.158.152.3 (162.158.152.3)  121.818 ms
 6  141.193.213.21 (141.193.213.21)  114.751 ms  116.337 ms  114.897 ms

La destination semble la même mais la route dans le second cas passe par NY

[Ikhar84]

@Flyingbike cherches vers un load balancing particulier, le geo load balancing, et le global load balancing, sûrement plus clair à comprendre.

Exemple :
https://cloud.google.com/architectur...policies?hl=fr

[pm42]

c'est la seule explication logique en effet, mais autant il parait logique que l'usager cherchant à atteindre Berkeley.edu atteigne en réalité le miroir le plus proche en toute transparence, autant il me parait pas clair que les routes obtenues ne soient pas représentatives de ce qui se passe en vrai...

C'est surprenant mais c'est parce que traceroute est un hack quelque part, que rien ne te garanti d'ailleurs que 2 paquets vont prendre la même et que surtout cet utilitaire a été conçu bien avant l'existence des techniques de cache moderne.

Effectivement autrefois un ip était égale à une machine et on routait vers les caches avec les DNS.
Comme dit plus haut on ne peut plus se le permettre pour différentes raisons dont la protection contre les attaques en déni de service.

[ey74]

Merci pour vos retours !

J'ai du mal à comprendre comment plusieurs serveurs peuvent avoir la même ip (je vais regarder vos liens en détail, je ne comprends pas comment le routage est possible), et pourtant c'est l'explication qui me parait la plus cohérente.

je me souviens que dans un cours on devait indiquer à partir de quel routeur on traversait l'atlantique, à moins de trouver un "petit" hébergeur ca n'est plus faisable.
Tout ce que je ping aux US à cet ordre de grandeur !