La Fibre
Télécom => Peering Transit (appairage) => Peering Google / Youtube => Discussion démarrée par: Leon le 11 décembre 2011 à 17:09:27
-
Bonjour à tous.
Ici, depuis un accès Free ADSL, Youtube est quasiment inutilisable. Même en 480, ça ne passe pas.
Aussi, je me permet de demander aux abonnés FTTH Free comment ça se passe pour eux? Est-ce qu'ils rencontrent le même problème? Ou alors est-ce que Free leur réserve un routage spécial qui leur permet de profiter pleinement de Youtube?
Merci d'avance pour vos retours.
Leon.
Edit Vivien : un problème similaire avait eu lieu en mai 2011
=> Saturation de YouTube chez Free (https://lafibre.info/free-les-news/saturation-de-youtube-chez-free/)
Petite vidéo montrant le problème a l'époque depuis la connexion Free FTTH de Barbatoutes (https://lafibre.info/profile/Barbatoutes/)
Freebox Révolution en fibre optique - Test connexion/Youtube (https://www.youtube.com/watch?v=vLBYEX3BsgM#)
-
lu,
ca m' intéresserais aussi , de savoir si c'est pareil pour ceux qui ont la V6 ( si je ne me trompe pas ) et qui peuvent regarder youtube par la tv .
-
Hello,
Est-ce que tu pourrais faire un traceroute pour comparer les chemins avec les clients xDSL ?
-
Détermination de l'itinéraire vers youtube.com [173.194.65.91]
avec un maximum de 30 sauts :
1 1 ms <1 ms <1 ms 192.168.x.xxx
2 5 ms 5 ms 5 ms 88.182.xxx.xxx
3 * 6 ms * marseille-6k-1-a5.routers.proxad.net [213.228.12.126]
4 6 ms 5 ms 5 ms marseille-9k-1-be1002.intf.routers.proxad.net [212.27.59.13]
5 10 ms 10 ms 11 ms lyon-crs16-1-be1003.intf.routers.proxad.net [212.27.50.102]
6 17 ms 17 ms * th2-crs16-1-be2001.intf.routers.proxad.net [212.27.59.29]
7 32 ms 31 ms 32 ms te0-0-0-3.340.ccr21.par04.atlas.cogentco.com [149.6.165.197]
8 32 ms 31 ms 35 ms te0-1-0-4.mpd21.par01.atlas.cogentco.com [130.117.2.77]
9 114 ms * 114 ms te0-5-0-4.mpd21.jfk02.atlas.cogentco.com [154.54.43.154]
10 115 ms 115 ms 115 ms te0-1-0-4.mpd21.dca01.atlas.cogentco.com [154.54.2.66]
11 111 ms 111 ms 111 ms te0-2-0-5.mpd21.iad02.atlas.cogentco.com [154.54.41.122]
12 127 ms 127 ms 128 ms 38.122.62.74
13 95 ms 95 ms 95 ms 209.85.252.80
14 126 ms 100 ms 99 ms 216.239.43.7
15 101 ms 100 ms 100 ms 209.85.253.90
16 105 ms 106 ms 105 ms 209.85.240.28
17 108 ms 107 ms 106 ms 216.239.49.30
18 * * * Délai d'attente de la demande dépassé.
19 107 ms 107 ms 106 ms ee-in-f91.1e100.net [173.194.65.91]
Itinéraire déterminé.
voila le mien sous win7
-
Oui mais la tu vas sur youtube.com, les vidéos ne sont pas sur le même serveur, normalement tu passes par google france, genre "o-o.preferred.par08s01.v11.lscache2.c.youtube.com".
Si tu fais un "dig" sur l'adresse tu vois qu'il y a des champs AAA (ipv6). Free.fr ne fait pas d'ipv6 natif donc c'est la merde, rien qu'en envoyant des requêtes ICMP on s'aperçoit d'une grosse différence:
ping6 o-o.preferred.par08s01.v11.lscache2.c.youtube.com
PING o-o.preferred.par08s01.v11.lscache2.c.youtube.com(2a00:1450:4007::8) 56 data bytes
64 bytes from 2a00:1450:4007::8: icmp_seq=1 ttl=57 time=33.2 ms
64 bytes from 2a00:1450:4007::8: icmp_seq=2 ttl=57 time=30.9 ms
64 bytes from 2a00:1450:4007::8: icmp_seq=3 ttl=57 time=30.9 ms
64 bytes from 2a00:1450:4007::8: icmp_seq=4 ttl=57 time=30.5 ms
ping o-o.preferred.par08s01.v11.lscache2.c.youtube.com
PING o-o.preferred.par08s01.v11.lscache2.c.youtube.com (173.194.20.8) 56(84) bytes of data.
64 bytes from 173.194.20.8: icmp_req=1 ttl=56 time=1.39 ms
64 bytes from 173.194.20.8: icmp_req=2 ttl=56 time=1.46 ms
64 bytes from 173.194.20.8: icmp_req=3 ttl=56 time=1.44 ms
64 bytes from 173.194.20.8: icmp_req=4 ttl=56 time=1.39 ms
En ipv6 il y a d'énormes congestions. Je viens de faire un test et j'obtiens pas plus de 90KB/s, avec l'ipv4 je fais du 2MB/s.
-
Mais déjà en réalisant un traceroute depuis la même IP depuis d'autres FAI, on voit la différence (Free n'utilise plus le peering privé qu'il a avec Google mais passe par le peering privé de Cogent - je suppose que Cogent est un des transitaire de Google et on sort de France. C'est quelle ville jfk, dca, iad ? par = Paris)
Vers Youtube.com :
(https://lafibre.info/images/free/201112_traceroute_free_youtube.png)
(https://lafibre.info/images/bbox/201112_traceroute_bouygues_youtube.png)
(https://lafibre.info/images/ovh/201112_traceroute_ovh_youtube.png)
Vers Google.fr :
(https://lafibre.info/images/free/201112_traceroute_free_google.png)
(https://lafibre.info/images/bbox/201112_traceroute_bouygues_google.png)
(https://lafibre.info/images/ovh/201112_traceroute_ovh_google.png)
-
Je sais par un ami qui est sur la "Freebre" que ça rame aussi.. mais étrangement tous les clients ne sont pas impactés de la même façon (QoS sélective). C'était la goutte d'eau qui m'a fait partir de chez Free, et je ne regrette pas avec 100M efficaces sur youtube sur la BBox fibre (contrairement à ce que dit l'assistance Free: "c'est pareil chez les autres!"). Pour ce qui est du traceroute, il ne veut rien dire vu que le trajet retour peut être complètement différent.
-
Je suis actuellement sur un DSLAM bridé depuis X mois donc je peux rien comparer...
-
Pour ce qui est du traceroute, il ne veut rien dire vu que le trajet retour peut être complètement différent.
Mais le ping du serveur (la dernière IP du traceroute) montre bien que chez Free le trajet n'est pas optimal :
- Ping moyen de 79,9ms chez Free depuis Paris
- Ping moyen de 0,7ms chez Bouygues Telecom depuis Paris
- Ping moyen de 4,3ms chez OVH depuis Roubaix (le lien Paris / Roubaix fait 4ms, on serait a moins de 0,5ms depuis Paris)
Dans tous les cas on est sans perte de paquet, le ping important n'est pas suffisant pour expliquer les problèmes de débit. Il faudrait faire des tests vers les serveurs délivrant le contenu et pas vers l'iP youtube.com ou google.fr
-
Je sais par un ami qui est sur la "Freebre" que ça rame aussi.. mais étrangement tous les clients ne sont pas impactés de la même façon (QoS sélective). C'était la goutte d'eau qui m'a fait partir de chez Free, et je ne regrette pas avec 100M efficaces sur youtube sur la BBox fibre (contrairement à ce que dit l'assistance Free: "c'est pareil chez les autres!").
Free raconte de la merde, je fais du 10MB/s depuis mon réseau (Kiev, Ukraine) et j'ai de très bonnes liaisons avec tous les fournisseurs commerciaux Français sauf free.fr. cogentco.com et tatacommunications.com ont déjà fourni des graphiques montrant très bien la congestion et la surcharge quasi-permanente des liens.
-
Free.fr ne fait pas d'ipv6 natif donc c'est la merde, rien qu'en envoyant des requêtes ICMP on s'aperçoit d'une grosse différence:
YT en IPv6 :
3 23 ms 22 ms 24 ms th2-crs16-1.intf.routers.proxad.net [2a01:e00:2:e::1]
4 23 ms 23 ms 24 ms cbv-9k-1-be1000.intf.routers.proxad.net [2a01:e00:2:c::2]
5 48 ms 47 ms 48 ms 2001:4860:1:1:0:3022::
6 23 ms 23 ms 27 ms 2001:4860:0:1::33c
7 48 ms 47 ms 48 ms 2a00:1450:4007:7::a
IPv4 :
10 * 21 ms * th2-6k-2-1-po1.intf.nra.proxad.net [78.254.255.1]
11 21 ms 22 ms 22 ms bzn-crs16-1-be1004.intf.routers.proxad.net [212.27.50.173]
12 23 ms 21 ms 21 ms cbv-9k-1-be1001.intf.routers.proxad.net [212.27.59.5]
13 48 ms * 54 ms 74.125.50.116
14 22 ms 25 ms 22 ms 216.239.48.200
15 22 ms 25 ms 22 ms 173.194.20.236
Quelle est la différence?
-
J'ai une bien grosse différence mais peut-être que ça va mieux que tout à l'heure.
-
Je viens de prendre une trace Wireshark pour les accès Google depuis Free et on reste sur de l'IPv6 (via le POP de Google a Courbevoie, dans le Netcenter SFR?) en peering plutôt que le transit via Cogent pour les client en IPv4.
Voici les détails:
ludovic@t420:~$ traceroute6 www.youtube.com (https://www.youtube.com)
traceroute to youtube-ui.l.google.com (2a00:1450:400c:c01::be) from 2a01:e35:2f67:7e30::, 30 hops max, 24 byte packets
1 2a01:e35:2f67:7e30:: (2a01:e35:2f67:7e30::) 2.338 ms 2.399 ms 2.335 ms
2 * * *
3 2a01:e00:1:11::1 (2a01:e00:1:11::1) 15.284 ms 31.485 ms 18.47 ms
4 2a01:e00:1:10::2 (2a01:e00:1:10::2) 57.873 ms 75.184 ms 52.672 ms
5 google-pni-3.intf.routers.proxad.net (2a01:e00:4:5::2) 65.735 ms 102.098 ms 67.807 ms
6 2001:4860::1:0:23 (2001:4860::1:0:23) 16.523 ms 45.135 ms 30.68 ms
7 2001:4860::8:0:2ac3 (2001:4860::8:0:2ac3) 22.335 ms 63.895 ms 55.673 ms
8 2001:4860::2:0:87b (2001:4860::2:0:87b) 60.849 ms 48.515 ms 33.833 ms
9 2001:4860:0:1::233 (2001:4860:0:1::233) 63.567 ms 44.734 ms 20.221 ms
10 bru01m01-in-xbe.1e100.net (2a00:1450:400c:c01::be) 62.943 ms 25.94 ms 62.27 ms
Traceroute vers un serveur d'authentification:
ludovic@t420:~$ traceroute6 2a00:1450:400c:c01::5b
traceroute to 2a00:1450:400c:c01::5b (2a00:1450:400c:c01::5b) from 2a01:e35:2f67:7e30::, 30 hops max, 24 byte packets
1 2a01:e35:2f67:7e30:: (2a01:e35:2f67:7e30::) 98.467 ms 2.346 ms 2.341 ms
2 * * *
3 bzn-crs16-1-te1-6-0-7.intf.routers.proxad.net (2a01:e00:1:f::1) 16.595 ms 30.082 ms 15.167 ms
4 2a01:e00:1:10::2 (2a01:e00:1:10::2) 15.207 ms 48.123 ms 45.643 ms
5 2001:4860:1:1:0:3022:: (2001:4860:1:1:0:3022::) 42.732 ms 98.295 ms 61.037 ms
6 2001:4860::1:0:23 (2001:4860::1:0:23) 30.123 ms 16.228 ms 15.299 ms
7 2001:4860::8:0:2ac3 (2001:4860::8:0:2ac3) 20.116 ms 43.962 ms 45.251 ms
8 2001:4860::2:0:87b (2001:4860::2:0:87b) 25.439 ms 52.469 ms 45.888 ms
9 2001:4860:0:1::233 (2001:4860:0:1::233) 20.385 ms 64.988 ms 39.487 ms
10 bru01m01-in-x5b.1e100.net (2a00:1450:400c:c01::5b) 20.717 ms 36.024 ms 20.627 ms
Cependant je dois dire que Youtube fonctionne beaucoup mieux pendant la journée que le soir, et on ressent bien la différence entre les vidéos a 360 ou 480p (qui peuvent bufferiser...).
-
En IPv6 on a donc un meilleur débit, si on passe par le peering privé, non ?
-
En fait Youtube en ipv6 ne marche que très, très, très peu...
J'ai fait un test "pure IPv6" ce matin, donc avec IPv6 uniquement, pas d'IPv4. Les services Google +, Gmail, Search, etc sont opérationnel, mais Google Talk gadget est IPv4 only, et Youtube fonctionne parfaitement au niveau UI (toutes les pages s'affichent très vite, très bien) mais 9 vidéo sur 10 balance une erreur.
Je pense que ceci est due au configuration des serveurs de contenu qui ne sont pas encore en IPv6, donc a par les quelques vidéos sur des serveurs en dual-stack, les vidéos sont téléchargées via IPv4 via Cogent...
-
Exact, il y en fait pas mal d'IPv4, je n'avais pas remarqué :
11 22 ms 21 ms 21 ms bzn-crs16-1-be1004.intf.routers.proxad.net [212.27.50.173]
12 22 ms 22 ms 21 ms te1-8.361.mag02.par01.atlas.cogentco.com [149.6.114.209]
13 22 ms 21 ms 22 ms te0-3-0-6.mpd22.par01.atlas.cogentco.com [130.117.50.70]
14 22 ms 22 ms 22 ms te0-5-0-2.ccr21.par04.atlas.cogentco.com [130.117.50.150]
15 22 ms 22 ms 22 ms ae0-1702-xcr1.par.cw.net [195.2.22.137]
16 50 ms 31 ms 32 ms xe-7-1-0-xcr1.fra.cw.net [195.2.9.50]
17 32 ms 31 ms 31 ms xe-0-1-1-xcr1.fix.cw.net [195.2.28.210]
18 40 ms 31 ms 32 ms 62.208.252.6
19 32 ms 33 ms 31 ms 208.117.247.177
20 32 ms 31 ms 31 ms 208.117.226.156
vs
3 22 ms 23 ms 22 ms th2-crs16-1.intf.routers.proxad.net [2a01:e00:2:e::1]
4 23 ms 22 ms 22 ms cbv-9k-1-be1000.intf.routers.proxad.net [2a01:e00:2:c::2]
5 45 ms 44 ms 43 ms google-pni-3.intf.routers.proxad.net [2a01:e00:4:5::2]
6 21 ms 21 ms 27 ms 2001:4860::1:0:23
7 31 ms 50 ms 32 ms 2001:4860::8:0:3016
8 31 ms 32 ms 32 ms 2001:4860::1:0:11
9 34 ms 34 ms 35 ms 2001:4860:0:1::223
10 33 ms 32 ms 31 ms fra07s07-in-x66.1e100.net [2a00:1450:4001:c01::66]
PNI = Private ?
-
Xavier Niel à interviewé hier soir par le nouvel observateur. A la question sur les ralentissement sur Youtube, Xavier Niel conseil d'aller sur Dailymotion : "j'invite les gens qui ont des problèmes avec YouTube de s'apercevoir que sur Dailymotion souvent il y a les mêmes vidéos."
(https://lafibre.info/images/free/201201_xavier_niel.jpg)
Le nouvel observateur : En dehors du mobile, les abonnés Free sont victimes de ralentissements récurrents lors de leur connexion à YouTube. Qu'en est-il ?
Xavier Niel : Effectivement, il y a un problème. Les tuyaux entre Google et nous sont pleins à certaines heures, et chacun se repoussent la responsabilité de rajouter des tuyaux. C'est un problème classique qui arrive partout, mais plus souvent avec Google. En comparaison, le trafic avec Dailymotion -avec qui tout se passe bien- ne pose pas de problème. Donc j'invite les gens qui ont des problèmes avec YouTube de s'apercevoir que sur Dailymotion souvent il y a les mêmes vidéos. J'espère que la solution arrivera sous peu.
-
Haha, il y a pas qu'avec Google, c'est la même chose avec tous les FAI de transit (TATA, Cogentco) etc... J'ai même confirmation de TATA que free refuse bien d'augmenter la capacité du transit. (Avec TATA c'était surchargé 24/7 et pas qu'a certaines heures).
-
Je ne comprends pas : qu'est-ce que ça couterait de changer la carte Ethernet?
Pourquoi "se renvoyer la responsabilité"? Il ne faut pas que chacun des deux change la carte Ethernet, et basta?
-
Si c'est du transit, Free doit payer.
Si c'est du peering uniquement, il est possible que l'un des acteur souhaite forcer l'autre a payer donc l'interco n'est pas upgradée.
Orange à également des problèmes vers de nombreuses destinations, Orange souhaitant les faire payer pour avoir le privilège de joindre la moitié du marché Français => Orange : Des débits escargots sur YouTube, MV et MU (https://lafibre.info/orange-les-news/orange-vers-la-fin-des-debits-escargots-sur-youtube-mv-et-mu/)
-
Si c'est du peering uniquement, il est possible que l'un des acteur souhaite forcer l'autre a payer donc l'interco n'est pas upgradée.
Faire payer Google? Bien sûr.
Heu... Free y croit encore à ça? Beaucoup d'autres y ont cru (à commencer par cet ahuri de Rupert Murdoch).
Orange à également des problèmes vers de nombreuses destinations, Orange souhaitant les faire payer pour avoir le privilège de joindre la moitié du marché Français => Orange : Des débits escargots sur YouTube, MV et MU (https://lafibre.info/orange-les-news/orange-vers-la-fin-des-debits-escargots-sur-youtube-mv-et-mu/)
Les orangés savent qu'ils sont un produit?
L'ARCEP ne devait pas sortir une analyse sur la vente des abonnés Internet?
-
Un FAI espagnol dit avoir réussi à faire payer Google...
Aujourd'hui personne n'a réussi à faire payer Google en France (même pas orange, qui a pourtant essayé en refusant de peerer)
-
Je suis ces problèmes depuis un moment et je n'ai toujours pas compris le coût que cela a d'augmenter les liens de peering.
Techniquement et physiquement à quoi cela correspond il?
Quel type d'investissement faudrait il?
-
À un moment on pouvait penser qu'en organisant la saturation à ce niveau on l'évitait dans le réseau capillaire.
Mais si le réseau peut supporter la VOD gratuite, donc massive, je ne pense pas que le réseau soit saturé.
Donc reste la tentative de chantage. "marché biface", ah ah ah.
-
Si Google a une croissance qui demande d'augmenter de 10 Gb/s tous les 6mois, il faut également faire évoluer tout le reste du réseau.
Donc investir. En limitant le trafic reçu dans le réseau au niveau du peering, on limite le trafic dans le reste du réseau.
Si tu empêche [par la saturation en heure de pointe] de voire une vidéo en HD, les clients vont rester en SD et donc consommer moins.
De plus le prix d'un routeur et des n x ports 10 Gb/s nécessaires n'est pas donné.
Free rajoute l'argument de la consommation électrique du routeur, cela me semble discutable.
-
1e100 représente quel % du trafic collecté par Free?
-
Le trafic des sites de Google (en fait Youtube principalement) est loin d'être négligeable.
Youtube est le site qui utilise le plus de bande passante pour un FAI et de loin. C'est également le peering le plus important pour un FAI.
La VoD qui est disponible sur la TV de Free elle ne charge pas la même façon le réseau et il me semble que son trafic est plus faible que celui du seul Youtube. Le Sud de la France est desservie par des serveurs situés au sud de la France. Quel intérêt ? Les liens sur le réseau ont symétrique (100 Gb/s dans le lien Marseille => Lyon et 100 Gb/s dans le sens Lyon => Marseille) or le trafic est asymétrique. Si on prend l'exemple d'un serveur sur Lyon, Google qui est présent sur Paris va donc charger le lien Paris => Lyon dans le sens où il est presque saturé alors que la VoD émise du sud de la Françe (exemple marseille) va charger le réseau à l'envers, dans le sens où il reste du trafic.
C'est un exemple pour montrer le principe, les serveurs VoD de Free ne sont pas situés à Marseille mais dans une ville entre Lyon et Bordeaux de mémoire.
Cela n’excuse en rien que le client paye son accès internet et donc que Free devrait mettre les moyens en face pour offrir un accès vers l'ensemble des site de manière équitable. Google est un exemple connu mais comme remonté par Cali, des pans entiers de l'internet sont impacté par des liaisons vers des transitaire saturés.
L'ARCEP souhaiterais monitorer ces problèmes de qualité de service mais les opérateurs expliquent que cela va permettre aux hébergeurs de reverser la négociation en leur faveur en imposant par exemple au FAI de payer pour recevoir les flux,... (ou au moins Google peut être sur de ne jamais avoir a payer pour joindre un FAI Français)
Ce sont des questions complexe. Il faudrait une régulation au niveau mondial vu que le réseau est mondial. Or ce n'est pas possible... donc je ne suis pas optimiste pour le futur... Les peering IPv6 pourraient être une nouvelle occasion de tension et de tentation d'une partie de faire payer l'autre.
-
Si Google a une croissance qui demande d'augmenter de 10 Gb/s tous les 6mois, il faut également faire évoluer tout le reste du réseau.
Donc investir. En limitant le trafic reçu dans le réseau au niveau du peering, on limite le trafic dans le reste du réseau.
Si tu empêche [par la saturation en heure de pointe] de voire une vidéo en HD, les clients vont rester en SD et donc consommer moins.
De plus le prix d'un routeur et des n x ports 10 Gb/s nécessaires n'est pas donné.
Free rajoute l'argument de la consommation électrique du routeur, cela me semble discutable.
CRS-3: 90K€
Carte 140G: 600K€ (42K€/10G)
Et moins de 3W/Gbps
Sympa leur marge de plusieurs millions d'euros :o
Bon apres j'y connais rien mais ca me parait abuser quand meme
-
Je pencherais plutot pour un ASR 9010, avec 10 slot et des line-cards de 24x10GE (soit 240 port 10GE), comme OVH l'a fait.
Je connais pas le prix mais ca doit etre bien moins cher qu'un CRS-3.
-
Un article intéressant qui date de novembre 2011 :
Les lenteurs d'accès à YouTube ne sont pas fantasmées par certains abonnés Free. L'opérateur concède des problèmes de connectivité et en fait peser la responsabilité sur l'absence d'investissement de Google. (http://www.numerama.com/magazine/20728-suspecte-de-brider-youtube-free-veut-que-google-investisse-davantage.html)
-
des redditers US ont fait joujou avec les serveurs de leur fournissseur d'accès et ont réussi à outrepasser le bridage:
http://www.reddit.com/r/technology/comments/13kmvd/have_time_warner_internet_but_can_barely_stream/c74vk39 (http://www.reddit.com/r/technology/comments/13kmvd/have_time_warner_internet_but_can_barely_stream/c74vk39)
m'en vais investiguer ça
-
impressionnant ??? redoutable ;) que du bon :)
-
Ce qui est troublant dans cette affaire, c'est la différence entre les deux traceroutes.
Test effectués sur OSX 10.8.2 ETH à 21h Dimanche
IPv4 :
Traceroute a démarré…
traceroute: Warning: youtube.fr has multiple addresses; using 74.125.230.206
traceroute to youtube.fr (74.125.230.206), 64 hops max, 72 byte packets
1 192.168.0.1 (192.168.0.1) 5.109 ms 0.219 ms 0.184 ms
2 XXX 6.962 ms 6.756 ms 6.936 ms
3 XXX 6.094 ms 6.875 ms 6.293 ms
4 th2-49m-1.intf.nra.proxad.net (78.254.251.78) 6.738 ms 6.822 ms 7.152 ms
5 * th2-6k-2-v914.intf.nra.proxad.net (78.254.251.61) 6.996 ms *
6 212.27.57.202 (212.27.57.202) 7.144 ms 10.815 ms 7.306 ms
7 te0-7-0-18.338.ccr21.par04.atlas.cogentco.com (149.6.165.145) 7.667 ms 7.544 ms 7.150 ms
8 te0-2-0-4.mpd22.par01.atlas.cogentco.com (130.117.1.141) 7.896 ms
te0-5-0-4.mpd21.par01.atlas.cogentco.com (130.117.48.253) 7.216 ms
te0-1-0-4.ccr21.par01.atlas.cogentco.com (130.117.2.21) 7.712 ms
9 te0-3-0-1.mpd22.lon13.atlas.cogentco.com (130.117.50.9) 15.901 ms
te0-3-0-1.mpd21.lon13.atlas.cogentco.com (130.117.0.181) 15.928 ms
te0-4-0-6.ccr21.lon13.atlas.cogentco.com (154.54.37.177) 15.060 ms
10 te0-0-0-0.ccr22.lon01.atlas.cogentco.com (130.117.0.94) 16.082 ms 16.464 ms
te0-3-0-1.ccr22.lon01.atlas.cogentco.com (130.117.0.237) 16.093 ms
11 te3-1.ccr01.lon18.atlas.cogentco.com (154.54.62.50) 121.186 ms 361.006 ms 202.244 ms
12 149.6.146.30 (149.6.146.30) 120.355 ms 115.183 ms 109.906 ms
13 209.85.255.78 (209.85.255.78) 15.546 ms 15.172 ms 15.036 ms
14 209.85.253.90 (209.85.253.90) 15.789 ms
209.85.253.94 (209.85.253.94) 16.213 ms
209.85.253.90 (209.85.253.90) 15.129 ms
15 72.14.232.210 (72.14.232.210) 15.174 ms 20.433 ms
209.85.242.79 (209.85.242.79) 16.009 ms
16 72.14.235.172 (72.14.235.172) 14.914 ms
72.14.235.168 (72.14.235.168) 15.585 ms
72.14.235.172 (72.14.235.172) 15.548 ms
17 209.85.242.49 (209.85.242.49) 16.152 ms 15.319 ms 15.946 ms
18 par08s09-in-f14.1e100.net (74.125.230.206) 15.513 ms 15.420 ms 15.445 ms
En IPv6
traceroute6 to youtube.fr (2a00:1450:400c:c06::be) from XXX, 64 hops max, 12 byte packets
1 XXX 0.632 ms 0.191 ms 1.424 ms
2 * * *
3 th2-crs16-1.intf.routers.proxad.net 7.777 ms 7.322 ms 7.095 ms
4 cbv-9k-1-be1000.intf.routers.proxad.net 7.598 ms 7.277 ms 7.303 ms
5 google-pni-3.intf.routers.proxad.net 109.168 ms
2001:4860:1:1:0:3022:: 100.941 ms
2001:4860:1:1::3022:0:5 102.801 ms
6 2001:4860::1:0:23 7.976 ms 8.705 ms 8.526 ms
7 2001:4860::8:0:3df4 7.782 ms 7.950 ms
2001:4860::8:0:3df5 7.822 ms
8 2001:4860::8:0:2ac3 27.320 ms
2001:4860::8:0:2ac4 13.165 ms
2001:4860::8:0:2ac3 13.517 ms
9 2001:4860::2:0:87d 12.257 ms
2001:4860::2:0:87b 12.839 ms 12.592 ms
10 * * *
11 wb-in-xbe.1e100.net 13.018 ms 12.743 ms 12.707 ms
On a bien deux saturations : L'une en IPv4 sur le Peering Cogent/Google à Londres (Paris --> Londres --> Paris, Pratique....) et l'autre sur le Peering privé PROXAD/Google....
WTF ?!
-
Ce qui est troublant dans cette affaire, c'est la différence entre les deux traceroutes.
Test effectués sur OSX 10.8.2 ETH à 21h Dimanche
Youtube/Google, c'est un très très gros CDN (Content Delivery Network) avec plein de serveurs partout dans le monde, sur plein de plages IP différentes, raccordés par des moyens divers et variés. Donc le tranceroute que tu fais ici n'est absolument pas valable pour l'ensemble de Youtube/Google, mais juste pour une petite partie.
Leon.
-
Léon : quel que soit l'emplacement des serveurs qui ont le contenu, c'est toujours un cache au même endroit qui te délivre le contenu. Si le cache ne possède pas le contenu, il le demande mais tu ne verra pas cette partie.
Merci de rappeler cette différence IPv4 / IPv6.
Les tests comparatif que j'ai réalisé sur le post Comparatif des débits vers Youtube (https://lafibre.info/peering/comparatif-peering-youtube/84/) est en IPv4 pour le serveur Free/Online et en IPv6 quand réalisé derrière un abonné Free ADSL. D'où la différence de débit, les deux peering n'étant pas saturés de la même façon.
-
Seconde remarque youtube.fr est un site web. Pour voir d'où viens le contenu, il faut utiliser youtube-dl -g suivit de l'url de la vidéo. On obtiens alors un lien temporaire sur le serveur de cache utilisé :
$ youtube-dl -g https://www.youtube.com/watch?v=-oCCnxBos10
http://o-o---preferred---sn-4g57kb7l---v20---lscache3.c.youtube.com/videoplayback?upn=T8_w0F5mYog&sparams=cp%2Cgcr%2Cid%2Cip%2Cipbits%2Citag%2Cratebypass%2Csource%2Cupn%2Cexpire&fexp=904825%2C916612%2C922401%2C920704%2C912806%2C927201%2C925706%2C922403%2C913546%2C913556%2C916805%2C920201%2C901451&ms=au&expire=1353897380&itag=37&ipbits=8&gcr=fr&sver=3&ratebypass=yes&mt=1353875952&ip=88.191.93.4&mv=m&source=youtube&key=yt1&cp=U0hUSFhUVV9NSkNONF9QTllEOmVmXzVhaU9EYmhn&id=fa80829f1068b35d&signature=1091EE1D26662D22D3B20654E9B8AAF3C5186BA1.313E638090FA58C668F90B3B7CDB28527F54CF66
En mettant cette url, dans un player type VLC il est possible de voir la vidéo. Cela consomme moins de ressource que le player Youtube, cela permet de regarder des vidéos en Full HD alors que la configuration ne suffit pas avec le player Youtube.
Exemple d'un vidéo Youtube avec VLC : (mais cela marche aussi avec MPlayer)
(https://lafibre.info/images/tv/201211_youtube_vlc.jpg)
youtube-dl est un utilitaire linux (intégré dans la logithèque Ubuntu) mais je pense qu'il doit y avoir un équivalent pour Windows.
-
Youtube/Google, c'est un très très gros CDN (Content Delivery Network) avec plein de serveurs partout dans le monde, sur plein de plages IP différentes, raccordés par des moyens divers et variés. Donc le tranceroute que tu fais ici n'est absolument pas valable pour l'ensemble de Youtube/Google, mais juste pour une petite partie.
Leon.
Certes, bien sûr que Google n'a pas mis tous ces oeufs dans le même panier. Cependant, corrige-moi si je me trompe, mais cela l'enlève en rien le fait que Free ne fait pas de peering avec Google en v4, mais qu'il en fait ou en a fait en v6. Ce que je ne comprends pas c'est que les deux parties n'arrivent pas à s'entendre. Google et Free sont deux entreprises à vocation commerciales, il y a toujours un moyen de s'arranger entre personnes de bonnes volontés.
Adrieth
-
Léon : quel que soit l'emplacement des serveurs qui ont le contenu, c'est toujours un cache au même endroit qui te délivre le contenu. Si le cache ne possède pas le contenu, il le demande mais tu ne verra pas cette partie.
Je n'ai pas bien compris ce que tu veux dire. Le contenu Youtube qui m'est délivré à moi abonné Free n'est pas toujours hébergé au même endroit. Il y a des vidéos youtube qui se chargent très rapidement depuis mon accès Free, et elles ne sont pas hébergées au même endroit que les vidéos qui rament. Regarde le test que j'avais fait, avec des vidéos hébergées à Paris ou à Amsterdam. Bref, c'est un gros CDN réparti.
https://lafibre.info/peering/qualite-peering-transit/msg50621/#msg50621 (https://lafibre.info/peering/qualite-peering-transit/msg50621/#msg50621)
Leon.
-
Pourquoi les opérateurs n'utilisent pas de CDN au niveau national pour mettre en cache les données (notamment youtube) au plus près des clients. Orange le fait déjà pour distribuer ses VOD. Y-a-t-il plus de contrainte lorsqu'il s'agit de cache HTTP ?
-
Pourquoi les opérateurs n'utilisent pas de CDN au niveau national pour mettre en cache les données (notamment youtube) au plus près des clients. Orange le fait déjà pour distribuer ses VOD. Y-a-t-il plus de contrainte lorsqu'il s'agit de cache HTTP ?
Free et Google justement n'arrivent pas à se mettre d'accord sur des serveurs de cache. Je ne sais plus vraiment les points divergeants mais chacun a le même discourt et veut gérer les serveurs de cache et toucher de l'argent parce que "cela rend service à l'autre"
-
Pourquoi les opérateurs n'utilisent pas de CDN au niveau national pour mettre en cache les données (notamment youtube) au plus près des clients. Orange le fait déjà pour distribuer ses VOD. Y-a-t-il plus de contrainte lorsqu'il s'agit de cache HTTP ?
Youtube a déjà des serveurs de cache hébergés à Paris. Pour Free, c'est sans doute moins contraignant que d'héberger des serveurs de Youtube sur son propre réseau.
Leon.
-
Pourquoi les opérateurs n'utilisent pas de CDN au niveau national pour mettre en cache les données (notamment youtube) au plus près des clients.
Free est en conflit avec plusieurs CDN pour la même raison que Google/Youtube.
Free souhaite être payé par ceux qui lui génère du trafic asymétrique. Ce sont tous les CDN et Youtube.
-
Free et Google justement n'arrivent pas à se mettre d'accord sur des serveurs de cache. Je ne sais plus vraiment les points divergeant mais chacun a le même discourt et veut gérer les serveurs de cache et toucher de l'argent parce que "cela rend service à l'autre"
Le problème vient justement de là. Google propose à Free de mettre ces serveurs de cache dans son réseau pour résoudre les problèmes de saturation. Mais free ne veut pas et préférerait faire son propre cache. Mais cette fois c'est google qui ne veut pas.
La position de chacun est compréhensible: free veut maîtriser son réseau et google le service offert. Bref encore une histoire de sous. L'un veut que l'autre participe à son réseau pour atteindre ces clients.
-
Bonsoir,
Cette histoire avec youtube ma tellement rendu dingue entre GOOGLE et FREE qui se rejettent mutuellement la faute et bien j'ai préféré quitter.
J'ai tout compris, j'ai quitté Free 8) et depuis c'est que du bonheur avec la fibre de BT 8)
-
A noter que si Google propose des cache a intégrer dans le réseau où Free souhaite (c'est donc possible de mettre un cache dans chaque POP en province par exemple si le trafic du POP a un trafic Google > 8 Gb/s), Google propose aussi de mettre en place des peering privé de forte capacité et là c'est Free qui refuse.
Pour moi cache ou peering privé ce qui pose problème, c'est que Free demande a être payé dans les deux cas ce que Google refuse.
-
Mes scripts m'ont indiqué ce matin de grosse modifications de routage chez Free vers les serveurs de youtube. Pour la majorité des vidéos les serveurs sont joint directement avec l'interconnexion Free <> Google ou en passant par "limelight".
Un test:
3. th2-crs16-1-be1503-p.intf.router 0.0% 157 0.7 0.9 0.5 18.8 1.4
4. limelight-pni.proxad.net 0.0% 157 2.0 4.8 0.5 18.7 5.0
5. ve6.fr4.par.llnw.net 0.0% 156 0.6 4.4 0.5 19.5 5.2
6. tge8-6.fr4.lon.llnw.net 0.0% 156 9.3 13.2 9.1 26.9 4.6
7. google.tge8-3.fr4.lon.llnw.net 0.0% 156 9.6 10.5 9.4 19.5 2.1
8. 208.117.247.185 0.0% 156 9.9 9.7 9.5 11.7 0.3
9. 208.117.245.231 0.0% 156 9.5 9.4 9.2 9.8 0.1
Parfois il y a encore du cogentco mais comme ça ne passe plus forcement par eux la charge est moindre donc la bande passante et beaucoup plus large, j'arrive à 30Mo/s avec certaines vidéos. On peut observer la même chose en IPv6.
-
Limelight est un transitaire de Free ?
Cela me semble étonnant !
Pour moi Limelight est plus un gros CDN du type Akamai en plus petit.
Je trouve étonnant que Free lui achète du transit IP.
-
Bah peut-être qu'ils achètent pas mais en tout cas ça passe par chez eux :p
-
Bon bah ça a l'air de très bien marcher depuis que j'suis passé en ipv6 tout à l'heure, vers 19h55 j'ai pu charger du 720p au max de ma connexion sans aucune baisse de débit, voilà un traceroute :D
traceroute to youtube.com (2a00:1450:400c:c00::5b), 30 hops max, 80 byte packets
1 2a01:e34:xxxx:xxxx::1 (2a01:e34:xxxx:xxxx::1) 2.962 ms 2.873 ms 2.898 ms
2 * * *
3 th2-crs16-1.intf.routers.proxad.net (2a01:e00:2:e::1) 26.281 ms 27.890 ms 29.271 ms
4 cbv-9k-1-be1000.intf.routers.proxad.net (2a01:e00:2:c::2) 30.176 ms 32.051 ms 32.937 ms
5 2001:4860:1:1:0:3022:0:5 (2001:4860:1:1:0:3022:0:5) 139.813 ms google-pni-3.intf.routers.proxad.net (2a01:e00:4:5::2) 141.899 ms 2001:4860:1:1:0:3022:0:5 (2001:4860:1:1:0:3022:0:5) 142.370 ms
6 2001:4860::1:0:9f2 (2001:4860::1:0:9f2) 36.748 ms 2001:4860::1:0:23 (2001:4860::1:0:23) 30.170 ms 29.947 ms
7 2001:4860::8:0:3df5 (2001:4860::8:0:3df5) 25.177 ms 2001:4860::8:0:3df4 (2001:4860::8:0:3df4) 26.383 ms 2001:4860::8:0:3df5 (2001:4860::8:0:3df5) 41.147 ms
8 2001:4860::8:0:2ac4 (2001:4860::8:0:2ac4) 33.751 ms 34.201 ms 40.248 ms
9 2001:4860::2:0:87b (2001:4860::2:0:87b) 40.348 ms 40.385 ms 29.228 ms
10 wg-in-x5b.1e100.net (2a00:1450:400c:c00::5b) 27.611 ms 29.531 ms 28.551 ms
-
Contrairement à depuis Marines dans le Val-d'Oise, chez moi depuis Paris, YouTube bloque tout le temps!
Un traceroute :
12 23 ms 22 ms 22 ms cbv-9k-1-be1002.intf.routers.proxad.net [212.27.59.9]
13 103 ms 105 ms 128 ms 72.14.216.98
14 23 ms 22 ms 21 ms 72.14.238.234
15 102 ms 102 ms 101 ms 216.239.46.218
16 103 ms 101 ms 102 ms 209.85.252.2
17 100 ms 103 ms 102 ms 72.14.239.93
18 103 ms 102 ms 179 ms 72.14.238.124
19 102 ms 101 ms 102 ms 74.125.214.115
Une autre vidéo :
3 23 ms 25 ms 22 ms th2-crs16-1.intf.routers.proxad.net [2a01:e00:2:d::1]
4 31 ms 22 ms 31 ms cbv-9k-1-be1000.intf.routers.proxad.net [2a01:e00:2:c::2]
5 95 ms 96 ms 107 ms 2001:4860:1:1:0:3022::
6 22 ms 22 ms 23 ms 2001:4860::1:0:9f2
7 22 ms 26 ms 22 ms 2001:4860::8:0:3df5
8 39 ms 45 ms 39 ms 2001:4860::1:0:106f
9 61 ms 69 ms 75 ms 2001:4860::4:0:118d
10 55 ms 53 ms 60 ms 2001:4860:0:1::205
11 59 ms 59 ms 63 ms 2a00:1450:4004:2::17
Une autre :
10 22 ms * * th2-6k-2-1-po1.intf.nra.proxad.net [78.254.255.1]
11 23 ms 22 ms 22 ms th2-crs16-1-be1000.intf.routers.proxad.net [212.27.57.202]
12 23 ms 22 ms 23 ms te0-7-0-0.346.ccr21.par04.atlas.cogentco.com [149.6.165.213]
13 30 ms 32 ms 23 ms upc.ams03.atlas.cogentco.com [130.117.15.118]
14 32 ms 31 ms 32 ms ae5-xcr1.prp.cw.net [195.2.10.89]
15 34 ms 32 ms 32 ms xe-1-0-0-xcr1.fra.cw.net [195.2.9.54]
16 32 ms 31 ms 33 ms xe-4-0-1-xcr1.fix.cw.net [195.2.28.146]
17 31 ms 39 ms 32 ms 62.208.252.62
18 * * * Délai d'attente de la demande dépassé.
19 33 ms 32 ms 32 ms 208.117.247.187
20 36 ms 32 ms 33 ms 208.117.226.224
Encore :
3 24 ms 23 ms 27 ms th2-crs16-1.intf.routers.proxad.net [2a01:e00:2:e::1]
4 24 ms 23 ms 22 ms cbv-9k-1-be1000.intf.routers.proxad.net [2a01:e00:2:c::2]
5 132 ms 132 ms 113 ms google-pni-3.intf.routers.proxad.net [2a01:e00:4:5::2]
6 23 ms 22 ms 22 ms 2001:4860::1:0:23
7 23 ms 23 ms 22 ms 2001:4860::8:0:3df5
8 45 ms 49 ms 44 ms 2001:4860::1:0:106f
9 54 ms 176 ms 62 ms 2001:4860::4:0:118d
10 59 ms 60 ms 59 ms 2001:4860:0:1::205
11 60 ms 58 ms 58 ms 2a00:1450:4004:2::d
Un de plus :
10 21 ms 21 ms 23 ms th2-6k-2-1-po1.intf.nra.proxad.net [78.254.255.1]
11 22 ms 24 ms 22 ms th2-crs16-1-be1000.intf.routers.proxad.net [212.27.57.202]
12 29 ms 24 ms 26 ms limelight-pni.proxad.net [212.27.40.154]
13 42 ms 32 ms 31 ms tge4-4.fr3.lon.llnw.net [69.28.171.50]
14 32 ms 31 ms 31 ms google.tge5-3.fr3.lon.llnw.net [178.79.195.2]
15 * * * Délai d'attente de la demande dépassé.
16 32 ms 30 ms 30 ms 208.117.247.185
17 30 ms 30 ms 30 ms 208.117.245.212
et
3 23 ms 22 ms 22 ms th2-crs16-1.intf.routers.proxad.net [2a01:e00:2:e::1]
4 26 ms 27 ms 22 ms cbv-9k-1-be1000.intf.routers.proxad.net [2a01:e00:2:c::2]
5 121 ms 112 ms 107 ms google-pni-3.intf.routers.proxad.net [2a01:e00:4:5::2]
6 22 ms 24 ms 98 ms 2001:4860::1:0:23
7 23 ms 22 ms 25 ms 2001:4860::8:0:3df5
8 39 ms 39 ms 39 ms 2001:4860::1:0:106f
9 76 ms 68 ms 56 ms 2001:4860::4:0:118d
10 63 ms 58 ms 57 ms 2001:4860:0:1::20b
11 55 ms 59 ms 59 ms 2a00:1450:4004:3::d
et
3 23 ms 23 ms 23 ms th2-crs16-1.intf.routers.proxad.net [2a01:e00:2:e::1]
4 26 ms 22 ms 26 ms cbv-9k-1-be1000.intf.routers.proxad.net [2a01:e00:2:c::2]
5 145 ms 120 ms 111 ms google-pni-3.intf.routers.proxad.net [2a01:e00:4:5::2]
6 29 ms 22 ms 23 ms 2001:4860::1:0:23
7 28 ms 23 ms 25 ms 2001:4860::8:0:3df4
8 46 ms 38 ms 39 ms 2001:4860::1:0:106f
9 53 ms 60 ms 107 ms 2001:4860::4:0:118d
10 54 ms 55 ms 54 ms 2001:4860:0:1::205
11 54 ms 54 ms 54 ms 2a00:1450:4004:2::7
-
On a gagné du débit mais bon on est loin des débit normaux :
Avec un serveur Free :
# youtube-dl https://www.youtube.com/watch?v=-oCCnxBos10
[youtube] Setting language
[youtube] -oCCnxBos10: Downloading video webpage
[youtube] -oCCnxBos10: Downloading video info webpage
[youtube] -oCCnxBos10: Extracting video information
[download] Destination: -oCCnxBos10.mp4
[download] 100.0% of 92.65M at 1.43M/s ETA 00:00
Avec un serveur Adeli :
$ youtube-dl https://www.youtube.com/watch?v=-oCCnxBos10
[youtube] Setting language
[youtube] -oCCnxBos10: Downloading video webpage
[youtube] -oCCnxBos10: Downloading video info webpage
[youtube] -oCCnxBos10: Extracting video information
[download] Destination: -oCCnxBos10.mp4
[download] 100.0% of 92.65M at 38.70M/s ETA 00:00
Le traceroute vers le serveur qui me délivre la vidéo avec Free :
mtr -rwc100 r20---sn-5hn7sb7k.c.youtube.com
HOST: s2 Loss% Snt Last Avg Best Wrst StDev
1.|-- 88.191.93.1 0.0% 100 0.4 0.7 0.3 10.7 1.4
2.|-- 88.191.2.53 0.0% 100 0.4 0.4 0.3 1.2 0.1
3.|-- 88.191.2.50 0.0% 100 0.4 0.3 0.2 1.5 0.2
4.|-- a9k1-6k1-460.bzn.online.net 0.0% 100 0.7 0.8 0.5 2.7 0.4
5.|-- bzn-crs16-1-be1500-t.intf.routers.proxad.net 0.0% 100 0.4 0.7 0.4 2.6 0.4
6.|-- te0-1-0-0.359.mag21.par01.atlas.cogentco.com 0.0% 100 1.6 1.6 1.4 2.1 0.2
7.|-- te0-0-0-7.mpd22.par01.atlas.cogentco.com 0.0% 100 1.5 1.6 1.3 3.2 0.5
8.|-- te0-3-0-5.mpd22.ams03.atlas.cogentco.com 0.0% 100 13.5 13.8 13.4 14.4 0.2
| `|-- 130.117.51.85
| |-- 130.117.51.81
| |-- 130.117.51.89
9.|-- te0-1-0-3.ccr21.ams04.atlas.cogentco.com 1.0% 100 14.2 14.1 13.8 14.7 0.1
10.|-- 149.11.38.62 0.0% 100 14.1 14.1 13.9 14.4 0.1
11.|-- ? ? 100.0 100
12.|-- 208.117.247.177 0.0% 100 13.4 13.4 13.4 13.5 0.0
13.|-- 208.65.155.153 0.0% 100 13.2 13.2 13.2 13.3 0.0
-
Ah oui normal c'est en ipv4, en ipv6 j'ai l'impression qu'on passe direct de Free à Google d'où mon absence de problèmes ;D
-
En ipv6 on est sur un pni (private network interface) depuis toujours (contrairement à ce que disait l'article de Freenews d'aujourd'hui avant édition), pas de changement hier à priori.
-
Ah moi j'ai switch aujourd'hui en ipv6 alors je pensais que c'était nouveau :p
-
Contrairement à depuis Marines dans le Val-d'Oise, chez moi depuis Paris, YouTube bloque tout le temps!
Un traceroute :
12 23 ms 22 ms 22 ms cbv-9k-1-be1002.intf.routers.proxad.net [212.27.59.9]
13 103 ms 105 ms 128 ms 72.14.216.98
14 23 ms 22 ms 21 ms 72.14.238.234
15 102 ms 102 ms 101 ms 216.239.46.218
16 103 ms 101 ms 102 ms 209.85.252.2
17 100 ms 103 ms 102 ms 72.14.239.93
18 103 ms 102 ms 179 ms 72.14.238.124
19 102 ms 101 ms 102 ms 74.125.214.115
Une autre vidéo :
3 23 ms 25 ms 22 ms th2-crs16-1.intf.routers.proxad.net [2a01:e00:2:d::1]
4 31 ms 22 ms 31 ms cbv-9k-1-be1000.intf.routers.proxad.net [2a01:e00:2:c::2]
5 95 ms 96 ms 107 ms 2001:4860:1:1:0:3022::
6 22 ms 22 ms 23 ms 2001:4860::1:0:9f2
7 22 ms 26 ms 22 ms 2001:4860::8:0:3df5
8 39 ms 45 ms 39 ms 2001:4860::1:0:106f
9 61 ms 69 ms 75 ms 2001:4860::4:0:118d
10 55 ms 53 ms 60 ms 2001:4860:0:1::205
11 59 ms 59 ms 63 ms 2a00:1450:4004:2::17
Une autre :
10 22 ms * * th2-6k-2-1-po1.intf.nra.proxad.net [78.254.255.1]
11 23 ms 22 ms 22 ms th2-crs16-1-be1000.intf.routers.proxad.net [212.27.57.202]
12 23 ms 22 ms 23 ms te0-7-0-0.346.ccr21.par04.atlas.cogentco.com [149.6.165.213]
13 30 ms 32 ms 23 ms upc.ams03.atlas.cogentco.com [130.117.15.118]
14 32 ms 31 ms 32 ms ae5-xcr1.prp.cw.net [195.2.10.89]
15 34 ms 32 ms 32 ms xe-1-0-0-xcr1.fra.cw.net [195.2.9.54]
16 32 ms 31 ms 33 ms xe-4-0-1-xcr1.fix.cw.net [195.2.28.146]
17 31 ms 39 ms 32 ms 62.208.252.62
18 * * * Délai d'attente de la demande dépassé.
19 33 ms 32 ms 32 ms 208.117.247.187
20 36 ms 32 ms 33 ms 208.117.226.224
Encore :
3 24 ms 23 ms 27 ms th2-crs16-1.intf.routers.proxad.net [2a01:e00:2:e::1]
4 24 ms 23 ms 22 ms cbv-9k-1-be1000.intf.routers.proxad.net [2a01:e00:2:c::2]
5 132 ms 132 ms 113 ms google-pni-3.intf.routers.proxad.net [2a01:e00:4:5::2]
6 23 ms 22 ms 22 ms 2001:4860::1:0:23
7 23 ms 23 ms 22 ms 2001:4860::8:0:3df5
8 45 ms 49 ms 44 ms 2001:4860::1:0:106f
9 54 ms 176 ms 62 ms 2001:4860::4:0:118d
10 59 ms 60 ms 59 ms 2001:4860:0:1::205
11 60 ms 58 ms 58 ms 2a00:1450:4004:2::d
Un de plus :
10 21 ms 21 ms 23 ms th2-6k-2-1-po1.intf.nra.proxad.net [78.254.255.1]
11 22 ms 24 ms 22 ms th2-crs16-1-be1000.intf.routers.proxad.net [212.27.57.202]
12 29 ms 24 ms 26 ms limelight-pni.proxad.net [212.27.40.154]
13 42 ms 32 ms 31 ms tge4-4.fr3.lon.llnw.net [69.28.171.50]
14 32 ms 31 ms 31 ms google.tge5-3.fr3.lon.llnw.net [178.79.195.2]
15 * * * Délai d'attente de la demande dépassé.
16 32 ms 30 ms 30 ms 208.117.247.185
17 30 ms 30 ms 30 ms 208.117.245.212
et
3 23 ms 22 ms 22 ms th2-crs16-1.intf.routers.proxad.net [2a01:e00:2:e::1]
4 26 ms 27 ms 22 ms cbv-9k-1-be1000.intf.routers.proxad.net [2a01:e00:2:c::2]
5 121 ms 112 ms 107 ms google-pni-3.intf.routers.proxad.net [2a01:e00:4:5::2]
6 22 ms 24 ms 98 ms 2001:4860::1:0:23
7 23 ms 22 ms 25 ms 2001:4860::8:0:3df5
8 39 ms 39 ms 39 ms 2001:4860::1:0:106f
9 76 ms 68 ms 56 ms 2001:4860::4:0:118d
10 63 ms 58 ms 57 ms 2001:4860:0:1::20b
11 55 ms 59 ms 59 ms 2a00:1450:4004:3::d
Dans mon message chronologique on voit que je suis en IPv4 une fois sur deux; est-ce que c'est le cas pour vous aussi?
-
Perso depuis tout à l'heure quand je suis passé en ipv6, j'ai toujours été en ipv6 sur YouTube, si je veux passer par ipv4 je dois le forcer avec l'option -4
-
Tu forces avec l'option -4 sur quel programme?
-
Sur le tracert de Windows
-
Attention de ne pas confondre les serveurs qui hébergent le site web (youtube.com) des serveurs qui délivrent la vidéo (par exemple r20---sn-5hn7sb7k.c.youtube.com)
Ce sont ces derniers qu'il faut regarder. Ils génèrent 90% de trafic de Google (alors que Google a d'autres services comme le moteur de recherche, Gmail ou Google Maps)
-
Effectivement c'est plus judicieux ;D je vais tester après
-
Perso depuis tout à l'heure quand je suis passé en ipv6, j'ai toujours été en ipv6 sur YouTube, si je veux passer par ipv4 je dois le forcer avec l'option -4
Quand tu parles d'aller sur YT, tu parles bien d'aller avec un navigateur Web sur le site https://www.youtube.com/ (https://www.youtube.com/) ?
-
Yep, les serveurs où sont les vidéos ça me co en ipv4 tout le temps
-
Est-ce que ton navigateur se connecte en priorité en IPv4?
-
Pour info voila comment ça marche vers Akamai ce soir... C'est en gros aussi performant que de l'ISDN :D
-
Comment je peux être sûr qu'il se connecte en priorité en ipv4 ou ipv6 ? ???
-
La nouvelle arrive ce matin à Univers freebox
http://www.universfreebox.com/article19094.html (http://www.universfreebox.com/article19094.html)
-
Ca concerne les pages YouTube, pas les serveurs de vidéos
-
"fake latency", c'est juste n'importe quoi! In English, pour faire chic, on ne pourrait pas juste dire "fausse latence". Mais c'est quoi une "fausse latence"?
En fait c'est un mec qui a entendu parler de l'outil traceroute, qui l'utilise quasiment pour la première fois, qui est étonné d'un résultat qu'il ne sait pas analyser, alors il crie au complot, comme cela se fait sur le net dès qu'un gugus est confronté à des données qu'il n'est pas capable d'analyser correctement. Tout ça mélangé avec des "sources" chez Free comme UF en a le secret (faut-il ressortir la photo de la Freebox v6 qu'ils avaient publié en exclusivité?).
C'est du pseudo-journalisme comme UF sait le faire.
Il faut lire les commentaires sous l'article :
Un peu de sérieux. Pourquoi une "fausse" latence ? Le routeur google-pni-3.intf.routers.proxad.net est plus ou moins chargé, quand il l'est plus il met plus de temps à traiter les pings comme les paquets, c'est tout. Les mecs qui inventent des histoires comme ça doivent se préparer, J-10... Vi j'avoue que faut pas vraiment connaitre bien les réseaux pour avoir une conclusion sur cet example.
J'aime bien le coup du traceroute pour "détecter" où se trouve la latence. Ca fait des siècles que les routeurs n'ont pas que ca à faire de répondre aux requêtes ICMP envoyées par un traceroute. Vu que ça monte dans la carte de supervision qui a franchement autre chose à faire que de s'occuper de ce genre de chose des fois, les cartes SUP mettent en queue et répondent si elles ont le temps. Donc mauvais test.
Franchement UF, vérifiez vos articles. C'est du grand n'importe quoi. Le pire c'est que vous êtes repris partout à droite à gauche comme caution en plus ..
Tout est dit!
-
En IPv6 cela n'a jamais passé par un transitaire!
Comment récupères-tu le nom du serveur de vidéo?
-
Tu peux nous poster ton traceroute ? (sur ma connec Free on va toujours directement de Free à Google en ipv6)
Sinon pour la "fake latency" @nkgl a posté ça suite à l'article d'UF : https://www.etherninja.org/?p=42 (https://www.etherninja.org/?p=42)
(je donne pour info, pas eu le temps de lire)
-
Bah en ipv6 non ça passait pas par un transitaire, mais les seuls serveurs YouTube que j'arrivais à contacter en ipv6 c'étaient les serveurs qui hébergent les pages d'accueil YouTube.fr et YouTube.com, les serveurs de vidéos j'y arrivais qu'en ipv4 :P
-
"fake latency", c'est juste n'importe quoi! In English, pour faire chic, on ne pourrait pas juste dire "fausse latence". Mais c'est quoi une "fausse latence"?
En fait c'est un mec qui a entendu parler de l'outil traceroute, qui l'utilise quasiment pour la première fois, qui est étonné d'un résultat qu'il ne sait pas analyser, alors il crie au complot, comme cela se fait sur le net dès qu'un gugus est confronté à des données qu'il n'est pas capable d'analyser correctement. Tout ça mélangé avec des "sources" chez Free comme UF en a le secret (faut-il ressortir la photo de la Freebox v6 qu'ils avaient publié en exclusivité?).
C'est du pseudo-journalisme comme UF sait le faire.
Il faut lire les commentaires sous l'article :Tout est dit!
Je pensais qu'avec la pseudo-news d'UF à base de pseudo-latence avec un contre-sens magnifique sur "fake latency" traduit par "fausse latence" comme dans "faux billets" ou lieu de "latence apparente" comme dans "je ne sais pas interpréter un traceroute", on avait touché le fond.
Mais UF a décidé de creuser encore beaucoup, beaucoup plus profond : avec l'aide de leur "expert" ils ont fait une mise à jour de cet article!
Mise à jour : Suite a vos remarques, violentes pour certaines, alors qu’il ne s’agit que d’ouvrir le débat avec un élèment nouveau, nous avons demandé à « Harry », qui est un spécialiste de ces questions, d’apporter des réponses.
Lien entre latence et débit
Les old school gamers le savent, le ping est important (donc la latence) car à force de faire des requêtes pour des "paquets perdus" on sature sa connexion et on se retrouve avec des erreurs type CRC. On peut avoir une connexion parfaite à 28 Mega, si le ping est mauvais, la communication sera mauvaise. Comme une antenne satellite qui réceptionne pendant une tempête.
Le routeur n’ajoute pas de latence car les serveurs après sont à 38 ms
Oui c’est vrai, mais il est fort probable qu’une QOS soit mise dans le routeur afin de faire une priorité basse au paquets transitant entre YouTube et l’usager et ainsi réduire la vitesse de réception (donc une latence supplèmentaire), de plus, au plus fort du "bridage" le temps de réponse du ping était d’1 seconde et 56 centième pour une simple requête ICMP non prioritaire. Imaginez donc maintenant des millions de paquets contenant des infos sur les vidéos que les utilisateurs essayent de regarder.
Les DNS Google sont meilleurs
Oui et non, nous travaillons sur un réseau de confiance. C’est à dire que lors du broadcast de notre destination, les différents annuaires vont annoncer leurs nombres de sauts et le temps moyen de réponse. Comme il a été remarqué dans les commentaires, le nœud en question est un nœud de sortie donc une route obligée. C’est pareil avec un VPN, qui ne se substitue pas a votre ligne physique, mais masque juste votre identité.
Depuis votre article, le nœud google-pni a de nouveau disparu (alors que ce matin il répondait a 80 ms), même s’il est vrai que le tracert n’est pas l’outil le plus fiable du monde, il a quand même déterminé qu’un équipement supplèmentaire était présent UNIQUEMENT sur les requêtes YouTube. Pour le reste (gmail, picasa, google+,...) il n’y a pas ce routeur.
Il existe toujours une probabilité que ce soit un routeur qui commence à tomber en panne, mais qu’elle est le pourcentage de chance pour que Free n’ai pas de routeurs en redondance ? D’ailleurs ce routeur change de nom régulièrement, il s’est appelé "Youtube-pni" puis "Google-pni" et je vous invite à regarder les tracert quand vous avez du lag sur YouTube, car je pense qu’il re-pointera le bout de son nez avant janvier 2013.
A ceux qui dénigre la "preuve par le tracert" :
2a01 est la plage réservée par Free pour ses équipements, les 2001 sont donc celles APRES le routage Free.
La ligne 5 du tracert change entre un équipement de Free et un équipement ailleurs (google,cogent ou autre acteur). Quand nous avons les temps de chargement au plus haut, c’est quand nous passons par le routeur de proxad. Quand nous passons par le 2001 : il n’y a AUCUN soucis de lag
Harry nous précise que ce qu’il essaie de montrer « c’est que les routes sont manipulées, et que le routeur de proxad est plus lent. Pourquoi je ne sais pas. Dans le contrat entre Cogent et Free peut être qu’il y a une clause en cas de paquets perdu qui ne serait pas à payer et du coup il laisserait passer uniquement un certain nombre des paquets tout en les conservant en mémoire dans le routeur pour un acheminement plus rapide aprés. »
http://www.universfreebox.com/article19094.html (http://www.universfreebox.com/article19094.html)
Putain, c'est VRAIMENT de la bonne.
Le nombre de conneries qu'UF peut mettre dans un seul article est juste hallucinant. Je me souvenais que c'était mauvais, que les rédacteurs étaient des mytho (ils se la racontent en disant "suite à notre signalement, Free a corrigé tel bug" alors que le bug est sur le bugtracker depuis des mois et qu'il a été confirmé par un corps depuis des semaines), mais à ce point là, je ne pensais même pas que c'était possible...
Il y a quelques réactions à l'article sur le net, dont http://forum.hardware.fr/hfr/reseauxpersosoho/FAI/bridage-youtube-amelioration-sujet_25706_65.htm#t618805 (http://forum.hardware.fr/hfr/reseauxpersosoho/FAI/bridage-youtube-amelioration-sujet_25706_65.htm#t618805)
(http://cdn.memegenerator.net/instances/400x/31691089.jpg)
C'est pas faux.
-
Tu peux nous poster ton traceroute ? (sur ma connec Free on va toujours directement de Free à Google en ipv6)
Encore?
J'en ai posté déjà 8! (https://lafibre.info/free-espace-technique/youtube-chez-free-ftth/msg67435/#msg67435)
Sinon pour la "fake latency" @nkgl a posté ça suite à l'article d'UF : https://www.etherninja.org/?p=42 (https://www.etherninja.org/?p=42)
Voilà, ça explique bien : fake = apparente, trompeuse
p.ex. :
- une apparence de ralentissement
- une mesure de vitesse trompeuse
et non : fake = faux, falsifié
p.ex.
- un faux passeport
- un faux panneau de limite de vitesse
- un complot du nouvel ordre mondial avec les Elohim et Darth Vader pour ralentir TonTuyau
-
Tenez pour la route :
(http://cdn.memegenerator.net/instances/400x/31700715.jpg)
(http://cdn.memegenerator.net/instances/400x/31690482.jpg)
Source : @pymaunier (https://x.com/pymaunier)
-
Le petit africain me fera toujours autant marrer je crois, peu importe le texte (ou presque)
-
C'est vrai que UF depuis un an est de pire en pire.
-
http://www.capital.fr/a-la-une/dossiers/free-sa-methode-commando-contre-orange-bouygues-sfr-et-les-autres-792420/free-peut-compter-sur-des-blogueurs-fanatiques-plus-efficaces-que-la-pub (http://www.capital.fr/a-la-une/dossiers/free-sa-methode-commando-contre-orange-bouygues-sfr-et-les-autres-792420/free-peut-compter-sur-des-blogueurs-fanatiques-plus-efficaces-que-la-pub)
En plus avec des liens aussi étroits, ils pourraient vérifier auprès des bonnes personnes
-
Mes tests:
Avec la fibre free:
youtube-dl "https://www.youtube.com/watch?v=-oCCnxBos10"
[youtube] Setting language
[youtube] -oCCnxBos10: Downloading video webpage
[youtube] -oCCnxBos10: Downloading video info webpage
[youtube] -oCCnxBos10: Extracting video information
[download] Destination: -oCCnxBos10.mp4
[download] 36.6% of 102.83M at 569.60k/s ETA 01:57^C
ERROR: Interrupted by user
Avec la fibre orange:
youtube-dl "https://www.youtube.com/watch?v=-oCCnxBos10"
[youtube] Setting language
[youtube] -oCCnxBos10: Downloading video webpage
[youtube] -oCCnxBos10: Downloading video info webpage
[youtube] -oCCnxBos10: Extracting video information
[download] Destination: -oCCnxBos10.mp4
[download] 100.0% of 102.83M at 12.58M/s ETA 00:00
-
Y aurait-il un effet de cache ? Mes tests (sous Orange)
1:
youtube-dl "https://www.youtube.com/watch?v=-oCCnxBos10"
[youtube] Setting language
[youtube] -oCCnxBos10: Downloading video webpage
[youtube] -oCCnxBos10: Downloading video info webpage
[youtube] -oCCnxBos10: Extracting video information
[download] Destination: -oCCnxBos10.mp4
[download] 100.0% of 102.83M at 2.40M/s ETA 00:00
2:
youtube-dl "https://www.youtube.com/watch?v=-oCCnxBos10"
[youtube] Setting language
[youtube] -oCCnxBos10: Downloading video webpage
[youtube] -oCCnxBos10: Downloading video info webpage
[youtube] -oCCnxBos10: Extracting video information
[download] Destination: -oCCnxBos10.mp4
[download] 100.0% of 102.83M at 12.72M/s ETA 00:00
-
Il y a bien des serveurs de cache pour Youtube.
-
Il y a bien des serveurs de cache pour Youtube.
Uniquement chez Orange ?
-
Google a des serveurs de cache plus ou moins près des réseaux FAI. Après "dans" le réseau du FAI (ce qui pourrait être le cas ici) je ne savais pas qu'il y en avait en France.
-
Nico, Google en France c'est uniquement des serveurs de cache (ce sont des GGC pour Google Global Cache).
Si c'est une vidéo fortement regardée, elle est déjà dans le cache GGC, sinon il faut faire la demande depuis le Datacenter de Google qui est en Belgique et qui a l'intégralité du contenu Youtube.
Tout contenu est placé sur le cache GGC et remplace le plus ancien contenu non demandé. Donc une vidéo peu demandée sera éjectée des serveurs de cache après une dizaine de minute si personne ne le demande de nouveau.
Le cache a une efficacité de 90% (90% des vidéos regardées sont déjà dans le cache, 10% demandent un accès au Datacenter Google en Belgique).
Les caches (GGC) sont soit dans des baies louées par Google (Paris, Marseille, Turin,...) soit chez les FAI.
-
Nico, Google en France c'est uniquement des serveurs de cache (ce sont des GGC pour Google Global Cache).
Si c'est une vidéo fortement regardée, elle est déjà dans le cache GGC, sinon il faut faire la demande depuis le Datacenter de Google qui est en Belgique et qui a l'intégralité du contenu Youtube.
Tout contenu est placé sur le cache GGC et remplace le plus ancien contenu non demandé. Donc une vidéo peu demandée sera éjectée des serveurs de cache après une dizaine de minute si personne ne le demande de nouveau.
Le cache a une efficacité de 90% (90% des vidéos regardées sont déjà dans le cache, 10% demandent un accès au Datacenter Google en Belgique).
Les caches (GGC) sont soit dans des baies louées par Google (Paris, Marseille, Turin,...) soit chez les FAI.
Ah ben vois-tu, je viens d'apprendre un truc sympas la :p
A quand un article détaillé sur le Sujet avec mesure et tracert ? :p
Bensay
-
Le cache a une efficacité de 90% (90% des vidéos regardées sont déjà dans le cache, 10% demandent un accès au Datacenter Google en Belgique).
Le cache est toujours dimensionné pareil (90% d'efficacité) ? Il ne peut pas y avoir des "GGC" plus ou moins efficaces ? (genre un plus "petit" cache qui ne serait efficace qu'à 80%)
-
Je viens de faire un test avec cette vidéo : Baby sings along with KoRn (https://www.youtube.com/watch?v=QLlmqySJTI8#ws)
J'ai indiqué à youtube-dl d'utiliser mon proxy et voici où il est allé la chercher : http://r12---sn-apn7en7r.c.youtube.com/videoplayback.... (http://r12---sn-apn7en7r.c.youtube.com/videoplayback....)
Host Loss% Snt Last Avg Best Wrst StDev
1. x.x.x.x 0.0% 6 20.9 20.4 19.6 20.9 0.0
2. 213.228.33.126 0.0% 6 20.5 20.5 19.7 21.4 0.4
3. caderousse-49m-1-v800.intf.routers.proxad.net 0.0% 5 20.7 23.8 20.1 34.4 6.0
4. vernegues-4k-1-v802.intf.routers.proxad.net 0.0% 5 22.6 22.4 21.8 23.0 0.0
5. marseille-6k-1-v808.intf.routers.proxad.net 0.0% 5 24.5 25.0 24.5 25.5 0.0
6. lyon-crs16-1-be1003.intf.routers.proxad.net 40.0% 5 28.2 27.6 27.2 28.2 0.0
7. p11-crs16-1-be1101.intf.routers.proxad.net 0.0% 5 33.9 33.4 32.1 33.9 0.5
8. bzn-crs16-2-be2000.intf.routers.proxad.net 0.0% 5 31.9 32.9 31.6 35.2 1.4
9. bzn-crs16-1-be1106.intf.routers.proxad.net 0.0% 5 32.0 31.7 30.5 32.3 0.5
10. cbv-9k-1-be1001.intf.routers.proxad.net 0.0% 5 31.1 31.8 31.0 32.4 0.5
11. google-pni-3.routers.proxad.net 0.0% 5 31.7 35.8 30.7 53.5 9.9
12. 72.14.238.228 0.0% 5 33.1 32.1 31.1 33.1 0.7
13. 72.14.235.173 0.0% 5 32.1 44.4 31.5 70.7 15.9
14. 209.85.240.190 0.0% 5 48.2 61.5 47.9 108.0 26.2
15. 216.239.49.249 0.0% 5 102.8 68.1 59.0 102.8 19.4
16. 64.233.174.149 0.0% 5 64.8 61.0 59.4 64.8 2.1
17. 173.194.13.49 0.0% 5 64.9 60.5 58.8 64.9 2.4
Vu les temps de réponse sur les 3-4 derniers, c'est pas la porte à coté...
Note: le download était très lent (normal, je suis chez Free) et par défaut il passe en IPv6.
Alors ? Cache ou pas cache ?
-
Les caches (GGC) sont soit dans des baies louées par Google (Paris, Marseille, Turin,...) soit chez les FAI.
Dans ce genre là (https://x.com/gaelv8/status/261507658505416704/photo/1) ? (selon l'auteur, cette baie se trouverai dans un Netcenter à Bordeaux).
(https://lafibre.info/images/datacenter/201304_google_appliance.jpg)
-
Ca peut etre une appliance Google, ça s'achète pour les recherches sur les Intranet. J'en eu un, il me semble qu'il était de cette couleur avec un gros G sur le dessus (on l'a enlevé car s'agissant d'une pre-prod, ça faisait luxueux....).
-
Je confirme, c'est une appliance Google, pas un GGC.
Le plus petit GGC, c'est 6u (cela génère 11 Gb/s de trafic).
Un exemple avec Bouygues Telecom. 1,2 ms, c'est forcèment un serveur en région parisienne :
$ mtr -rwc100 r11---sn-25g7sn7z.c.youtube.com
HOST: Loss% Snt Last Avg Best Wrst StDev
1.|-- 89.84.127.61 0.0% 100 0.3 0.4 0.3 1.0 0.1
2.|-- v113.tengec5-10g.core04-t2.club-internet.fr 15.0% 100 0.3 6.9 0.3 200.3 29.5
3.|-- ae5.tcore01-m.net.bbox.fr 0.0% 100 0.8 11.6 0.5 78.5 19.5
4.|-- po109.core02-c.net.bbox.fr 60.0% 100 0.8 3.7 0.8 80.3 12.9
5.|-- 72.14.217.60 0.0% 100 0.8 1.1 0.7 18.8 1.9
6.|-- 72.14.238.228 0.0% 100 1.2 2.1 1.2 18.4 2.5
7.|-- 72.14.239.204 0.0% 100 1.3 2.5 1.2 58.1 7.2
8.|-- 209.85.255.184 0.0% 100 1.7 1.8 1.6 2.0 0.1
9.|-- 173.194.9.16 0.0% 100 1.3 1.3 1.2 1.4 0.0
-
Depuis Free, il répond très bien aussi :
/outils/mtr/sbin/mtr -rwc100 173.194.9.16
Start: Sun Apr 28 16:40:11 2013
HOST: tao Loss% Snt Last Avg Best Wrst StDev
1.|-- x.x.x.x 0.0% 100 20.5 20.6 18.7 48.6 3.6
2.|-- 213.228.33.126 0.0% 100 24.9 22.8 19.2 84.1 8.0
3.|-- caderousse-49m-1-v800.intf.routers.proxad.net 0.0% 100 21.7 24.8 19.8 51.6 5.5
4.|-- vernegues-4k-1-v802.intf.routers.proxad.net 0.0% 100 21.3 23.2 20.8 104.6 8.3
5.|-- marseille-6k-1-v808.intf.routers.proxad.net 0.0% 100 25.1 26.2 23.8 56.5 4.8
6.|-- lyon-crs16-1-be1003.intf.routers.proxad.net 27.0% 100 28.4 27.7 24.1 76.1 5.9
7.|-- p11-crs16-1-be1101.intf.routers.proxad.net 0.0% 100 33.0 34.3 30.6 92.8 7.0
8.|-- bzn-crs16-2-be2000.intf.routers.proxad.net 0.0% 100 39.1 35.3 30.7 132.5 11.4
9.|-- bzn-crs16-1-be1106.intf.routers.proxad.net 0.0% 100 32.8 34.0 30.3 141.4 12.6
10.|-- cbv-9k-1-be1001.intf.routers.proxad.net 0.0% 100 34.0 34.2 30.8 149.9 13.3
11.|-- 74.125.50.116 0.0% 100 133.9 129.9 99.8 184.3 10.1
12.|-- 72.14.238.234 6.0% 100 30.9 32.4 30.7 41.9 1.9
13.|-- 72.14.239.144 0.0% 100 32.0 44.0 30.7 147.3 20.9
14.|-- 209.85.255.184 0.0% 100 33.0 34.4 31.3 95.4 8.9
15.|-- 173.194.9.16 0.0% 100 32.2 34.1 31.0 106.0 9.1
Du coup, komankonfé pour tomber dessus ?!
-
Tu regardes gangnam style :o
-
Tu regardes gangnam style :o
En effet mais cela pointe vers le serveur : cache.google.com
Est-ce le cas pour vous également ?
Cf
(http://img706.imageshack.us/img706/9418/tracertcachegoogle.png)
Bensay
-
Paris -> Londres -> Paris
Beurk!
9 * * 21 ms th2-6k-2-1-po1.intf.nra.proxad.net [78.254.255.1]
10 22 ms 22 ms 24 ms th2-crs16-1-be1000.intf.routers.proxad.net [212.27.57.202]
11 23 ms 21 ms 21 ms bzn-crs16-1-be2000.intf.routers.proxad.net [212.27.57.210]
12 23 ms 23 ms 24 ms bzn-crs16-2-be1000.intf.routers.proxad.net [212.27.59.102]
13 46 ms 45 ms 44 ms te0-1-0-5.365.mag21.par01.atlas.cogentco.com [149.6.160.101]
14 45 ms 44 ms 43 ms te0-7-0-1.mpd21.par01.atlas.cogentco.com [130.117.49.89]
15 53 ms * 54 ms 154.54.77.93
16 54 ms 52 ms 53 ms te0-1-0-4.ccr21.ams04.atlas.cogentco.com [130.117.2.62]
17 52 ms 88 ms 52 ms 149.11.38.102
18 53 ms 53 ms 53 ms 208.117.250.209
Vive Free! ;)
-
attention pour recuper l'ip reelle d'ou les données video proviennent il faut soit sniffer (Wireshark) soit utiliser un moniteur de traffic local (iftop ou autre) soit espionner le navigateur (F12 sous Chrome par exemple) car "youtube-dl -g" ne gère pas les redirections http dont ne voit pas ce qui va réellement se passer quand on va lire la video.
-
Tu regardes gangnam style :o
Faut la cacher dans la box cette vidéo, sérieusement !
Dans ce genre là (https://x.com/gaelv8/status/261507658505416704/photo/1) ? (selon l'auteur, cette baie se trouverai dans un Netcenter à Bordeaux).
"Le" Netcenter, nom donné à plusieurs gros datacenters de SFR (ex LD/9).
Un exemple avec Bouygues Telecom. 1,2 ms, c'est forcèment un serveur en région parisienne :
Vu les points de peering de Google en France, on peut imaginer que ça se trouve au Netcenter de Courbevoie (après c'est pas forcé non plus).
-
Google est présent sur le NetCenter de Courbevoie et sur Interxion 2 pour faire des PNI, mais les serveurs de cache ne sont pas forcèment dans le même datacenter.
Exemple avec Akamai qui est présent sur TH2 pour faire des PNI mais qui a ses serveurs de cache sur Interxion et de la trans entre les deux.
Je pense que l'hébergement à TH2 finissait par coûter trop cher (au début Akamai mettais ses serveurs de cache sur TH2)
-
Oui pour TH2 je ne m'en faisais pas, c'est un peu cher pour faire du hosting et ce genre de choses. J'avais pas noté que Google était à IX2, du coup leurs serveurs sont peut-être plutôt là-bas (le Netcenter servant peut-être plutôt à récupérer les opérateurs pas mal présents là-bas).
-
Google sur ITX2, c'est pour S1 2013, il me semble que ce n'est pas encore ouvert (mais je peux me tromper) alors que Courbevoie c'est historique.
-
"Le" Netcenter
Oui bon, pinailleur ! ;)
-
Je sais :). Disons que c'était pour être un peu plus précis pour ceux chez qui font pas l'association Netcenter / SFR. D'ailleurs ça et là où les trouve sous le nom (historique) de LDCom Netcenter.
-
Tu regardes gangnam style :o
j'ai regardé la video de PSY GENTLEMAN 1 journée apres sa sortie à 18h... un merveilleux 8kb/s... j'ai cru avoir repris un abonnement 128 kbps/s chez netissimo.
si c'etait pas dans un cache, faudra m'expliquer l'informatique.
les communautés FREE ont RDV bientot, j'y serais je vais encore en parler de ca mais ca sera "parlamonk matete est..."
-
Bonjour à tous,
Il y a du changement ?
En ipv6 :
pi@framboise ~ $ mtr -6 -rwc100 youtube.com
HOST: framboise.fairsys.lan Loss% Snt Last Avg Best Wrst StDev
1.|-- 2a01:e35:2eba:29e0:: 0.0% 100 0.8 0.9 0.8 1.2 0.1
2.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
3.|-- th2-crs16-1.intf.routers.proxad.net 0.0% 100 8.8 8.8 7.8 10.0 0.4
4.|-- cbv-9k-1-be1000.intf.routers.proxad.net 0.0% 100 7.9 8.2 7.6 9.3 0.3
5.|-- 2001:4860:1:1:0:3022:0:5 0.0% 100 7.8 8.9 7.3 39.8 3.7
6.|-- 2001:4860::1:0:9f2 0.0% 100 8.4 8.6 7.1 24.3 2.1
7.|-- 2001:4860::8:0:3df4 0.0% 100 8.1 10.5 7.7 48.1 6.4
8.|-- 2001:4860::8:0:507b 0.0% 100 13.1 13.4 12.7 17.6 0.5
9.|-- 2001:4860::2:0:2999 0.0% 100 13.1 15.2 12.7 36.3 4.5
10.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
11.|-- wi-in-x5b.1e100.net 0.0% 100 12.9 13.2 12.4 23.9 1.1
En IPv4:
pi@framboise ~ $ mtr -4 -rwc100 youtube.com
HOST: framboise.fairsys.lan Loss% Snt Last Avg Best Wrst StDev
1.|-- freebox.fairsys.lan 0.0% 100 0.8 0.8 0.7 4.1 0.3
2.|-- 82.235.162.254 0.0% 100 6.4 6.9 6.0 25.1 1.9
3.|-- 78.254.21.30 0.0% 100 6.7 7.6 6.2 45.9 4.2
4.|-- th2-49m-1.intf.nra.proxad.net 0.0% 100 6.8 7.4 6.4 23.3 2.0
5.|-- th2-6k-2-v914.intf.nra.proxad.net 31.0% 100 6.4 6.9 6.1 13.2 1.1
6.|-- th2-crs16-1-be1000.intf.routers.proxad.net 0.0% 100 7.2 7.8 6.7 40.3 3.3
7.|-- cbv-9k-1-be1002.intf.routers.proxad.net 0.0% 100 7.3 7.7 6.7 37.6 3.2
8.|-- google-pni-3.routers.proxad.net 0.0% 100 13.5 10.1 6.2 66.5 9.3
9.|-- 72.14.238.234 0.0% 100 7.4 9.5 6.5 55.1 7.2
10.|-- 209.85.242.47 0.0% 100 7.6 8.0 7.0 49.2 4.2
11.|-- par03s03-in-f7.1e100.net 0.0% 100 6.9 7.5 6.5 34.1 2.7
Et depuis bien longtemps, ça ne rame plus sur TonTuyau. A voir aux heures de pointes ;-)
-
UF (http://www.universfreebox.com/article/21315/Free-Une-nette-amelioration-sur-Youtube) semble dire que ça s'est amélioré mais :
1/ c'est UF quand même
2/ j'ai constaté hier soir à 23H que c'était toujours la misère de charger du 480p
-
Depuis hier soir, j'ai remarqué la même chose, aussi bien sur Youtube qu'Apple ou les Newsgroup, où normalement, mon débit tombe à 400kbit/s de 18h à minuit, là je sature ma (petite) connexion.
On ne passe plus par Cogent Londres, mais sur un routeur qui a pour nom google sur le réseau proxad.
HOP RTT ADDRESS
1 0.00 ms 192.168.0.254
2 26.00 ms 82.228.84.254
3 26.00 ms 213.228.9.254
4 26.00 ms toulouse-9k-1-be1000.intf.routers.proxad.net (212.27.50.177)
5 27.00 ms bordeaux-crs16-1-be1005.intf.routers.proxad.net (212.27.50.85)
6 27.00 ms bordeaux-crs8-1-be1000.intf.routers.proxad.net (78.254.249.21)
7 59.00 ms bzn-crs16-1-be1100.intf.routers.proxad.net (212.27.51.57)
8 59.00 ms bzn-crs16-1-be1106.intf.routers.proxad.net (212.27.59.101)
9 59.00 ms cbv-9k-1-be1001.intf.routers.proxad.net (212.27.59.5)
10 59.00 ms google-pni-3.routers.proxad.net (212.27.40.102)
11 48.00 ms 72.14.238.234
12 55.00 ms 209.85.242.47
13 55.00 ms par03s03-in-f24.1e100.net (173.194.34.56)