La Fibre
Télécom => Peering Transit (appairage) => 
Peering Google / Youtube => Discussion démarrée par: kaktuss77 le 10 novembre 2016 à 11:29:57
-
Bonjour a tous et a toutes,
Je rencontre depuis plusieurs semaines des soucis entre ovh et les services google. le débit est "bloqué" a environ 1 - 2 mega, fonc adieu vidéos en HD, et bonjour lenteur des MaJ de mes appareils Android.
Je récapitule mon installation, j'ai donc 6 Acces ADSL (1 OVH et 5 Orange), un tunnel VPN est monté par Box vers un dédier OVH, c'est la ou j'agrège le débit (VPN Bonding / MLVPN)
Sur une seul connexion TCP, j'arrive a saturé mon débit global descendant sans soucis.
Je vous joint les captures d'écrans pour 2 vidéos Youtube et les traceroutes vers les serveur respectif
Traceroute video 1
traceroute to 173.194.5.28 (173.194.5.28), 30 hops max, 60 byte packets
1 172.16.3.10 (172.16.3.10) 2.391 ms 2.309 ms 1.679 ms
2 10.10.10.9 (10.10.10.9) 20.948 ms 21.572 ms 32.575 ms
3 149.202.196.252 (149.202.196.252) 67.383 ms 42.122 ms 33.852 ms
4 po115.sbg-g2-a75.fr.eu (188.165.9.73) 29.367 ms 42.345 ms 22.320 ms
5 10.95.48.8 (10.95.48.8) 68.306 ms 34.220 ms 10.95.48.10 (10.95.48.10) 37.264 ms
6 mad-3-4m.es.eu (91.121.215.219) 39.315 ms 27.574 ms 54.184 ms
7 * * *
8 108.170.244.161 (108.170.244.161) 46.946 ms 34.808 ms 108.170.244.225 (108.170.244.225) 35.256 ms
9 209.85.251.155 (209.85.251.155) 35.214 ms 209.85.251.157 (209.85.251.157) 35.647 ms 34.644 ms
10 173.194.5.28 (173.194.5.28) 34.795 ms 41.848 ms 39.198 ms
Traceroute video 2
traceroute to 173.194.9.246 (173.194.9.246), 30 hops max, 60 byte packets
1 172.16.3.10 (172.16.3.10) 2.145 ms 2.135 ms 2.116 ms
2 10.10.10.9 (10.10.10.9) 72.414 ms 23.525 ms 31.986 ms
3 149.202.196.252 (149.202.196.252) 62.464 ms 62.916 ms 60.437 ms
4 po115.sbg-g2-a75.fr.eu (188.165.9.73) 34.406 ms po115.sbg-g1-a75.fr.eu (188.165.9.71) 23.442 ms po115.sbg-g2-a75.fr.eu (188.165.9.73) 32.872 ms
5 * 10.95.48.8 (10.95.48.8) 40.424 ms *
6 94.23.122.139 (94.23.122.139) 71.029 ms 27.998 ms 26.048 ms
7 * * *
8 108.170.244.161 (108.170.244.161) 79.105 ms 27.127 ms 28.477 ms
9 72.14.239.103 (72.14.239.103) 40.478 ms 42.450 ms 72.14.239.99 (72.14.239.99) 29.421 ms
10 173.194.9.246 (173.194.9.246) 38.272 ms 39.844 ms 33.316 ms
Si vous avez des idées, a un moment, j'avais monté un VPS chez un autres hébergeur, et je renvoyais le trafic a destination de google vers ce VPS, mais c'est injouable sur le long terme....
Merci de votre aide :)
-
Un petit Scaleway ou dédié chez Online et à toi un réseau de qualité non bridé ;)
-
Je ne pense pas que kaktuss77 cherche ce genre de solutions vu l'infra qu'il a chez lui ;)
Puis sinon, sous entendre qu'OVH a un réseau de mauvaise qualité bridé, c'est se méprendre. Autant coté offres perso, c'est de l'infame merde, autant sur le pro, Online à coté c'est un tout tout petit joueur.
-
Je vois ça ;) Jamais eu de soucis avec Youtube chez le petit joueur en tout cas...
-
Ouais, et ?
-
Hum, étrange! Il faudrait qu'une autre personne test avec un dédié OVH pour confirmer un problème.
-
Merci pour vos réponse,
cependant, je ne souhaite pas changer d'hébergeur, j'ai une grosse machine chez eux (128Go de ram, 16cores etc) je me vois pas transfère 3To de Vm pour un soucis de débit youtube/google alors que j'ai pas d'autre soucis.
Au départ j'avais pensé que ça pouvait venir de mon pool IP (blacklist, filtre ou autre) comme j'ai plusieurs pool IP distinct j'ai testé avec une autre IP, même soucis.
J'ai du mal a cerné d'ou vient le problème.
je vais refaire un test avec une VM au DC et non chez moi, pour voir si c'est pas le VPN Bonding qui poserait soucis.
-
J'en ai des tas, par contre installer youtube-dl dessus c'est plus tendu, y'a moyen de tester avec un lien direct ?
-
J'en ai des tas, par contre installer youtube-dl dessus c'est plus tendu, y'a moyen de tester avec un lien direct ?
Je ne pense pas qu'il soit possible d'avoir le lien direct de la vidéo, et pourquoi c'est tendu d'installer youtube-dl? C'est plutôt easy non? ^^
-
De mon côté:
traceroute to 173.194.5.28 (173.194.5.28), 30 hops max, 60 byte packets
1 51.255.192.1 (51.255.192.1) 0.251 ms 0.233 ms 0.226 ms
2 158.69.61.222 (158.69.61.222) 0.220 ms 0.218 ms 0.213 ms
3 51.255.244.62 (51.255.244.62) 0.222 ms 0.334 ms 0.335 ms
4 10.97.154.135 (10.97.154.135) 0.208 ms 10.97.154.83 (10.97.154.83) 0.248 ms 10.97.154.135 (10.97.154.135) 0.228 ms
5 be10-120.gra-g2-a9.fr.eu (37.187.232.78) 1.553 ms be10-121.gra-g2-a9.fr.eu (37.187.232.80) 2.377 ms be10-120.gra-g1-a9.fr.eu (37.187.232.74) 3.697 ms
6 be99-1191.th2-1-a9.fr.eu (94.23.122.87) 4.932 ms 5.067 ms be99-1190.gsw-1-a9.fr.eu (94.23.122.85) 4.491 ms
7 * * *
8 108.170.244.225 (108.170.244.225) 4.866 ms 108.170.244.161 (108.170.244.161) 4.866 ms 4.864 ms
9 209.85.251.155 (209.85.251.155) 4.835 ms 5.029 ms 209.85.251.157 (209.85.251.157) 4.804 ms
10 173.194.5.28 (173.194.5.28) 4.715 ms 4.564 ms 4.708 ms
traceroute to 173.194.9.246 (173.194.9.246), 30 hops max, 60 byte packets
1 51.255.192.1 (51.255.192.1) 0.236 ms 0.227 ms 0.221 ms
2 158.69.61.222 (158.69.61.222) 0.219 ms 0.214 ms 0.209 ms
3 51.255.244.62 (51.255.244.62) 0.221 ms 0.256 ms 0.253 ms
4 10.97.154.135 (10.97.154.135) 0.213 ms 10.97.154.83 (10.97.154.83) 0.224 ms 10.97.154.135 (10.97.154.135) 0.215 ms
5 be10-121.gra-g2-a9.fr.eu (37.187.232.80) 1.800 ms be10-120.gra-g2-a9.fr.eu (37.187.232.78) 1.841 ms be10-121.gra-g1-a9.fr.eu (37.187.232.76) 1.944 ms
6 be99-1191.th2-1-a9.fr.eu (94.23.122.87) 4.886 ms be99-1190.gsw-1-a9.fr.eu (94.23.122.85) 4.762 ms 4.798 ms
7 * * *
8 108.170.244.161 (108.170.244.161) 4.688 ms 4.828 ms 4.711 ms
9 72.14.239.99 (72.14.239.99) 5.892 ms 72.14.239.103 (72.14.239.103) 6.241 ms 6.070 ms
10 173.194.9.246 (173.194.9.246) 5.131 ms 4.836 ms 4.913 ms
kldint@pluton:~$ youtube-dl //www.youtube.com/watch?v=YIwuCs1Yovwx
[youtube] YIwuCs1Yovw: Downloading webpage
[youtube] YIwuCs1Yovw: Downloading video info webpage
[youtube] YIwuCs1Yovw: Extracting video information
[youtube] YIwuCs1Yovw: Downloading MPD manifest
WARNING: Requested formats are incompatible for merge and will be merged into mkv.
[download] Destination: TRANSFORMERS 4 OFFICIAL Trailer [HD 1080p]-YIwuCs1Yovw.f137.mp4
[download] 37.7% of 42.47MiB at 11.78MiB/s ETA 00:02
RAS de mon côté (serveur vps ovh à strasbourg)
-
Je ne pense pas qu'il soit possible d'avoir le lien direct de la vidéo, et pourquoi c'est tendu d'installer youtube-dl? C'est plutôt easy non? ^^
Parce que t'installe pas de la merde sur de la prod (et que pour une raison que j'ignore, j'ai pas le root sur les VM à bordel)
-
Parce que t'installe pas de la merde sur de la prod (et que pour une raison que j'ignore, j'ai pas le root sur les VM à bordel)
Ah si c'est des VMs de prod, c'est sûr.
-
hugues@lab:~$ mtr -zrwc10 173.194.5.28
Start: Thu Nov 10 12:00:13 2016
HOST: lab Loss% Snt Last Avg Best Wrst StDev
1. AS16276 94.23.110.78 0.0% 10 1.1 1.1 0.8 2.0 0.3
2. AS16276 be51.rbx-g2-a9.fr.eu 0.0% 10 1.4 2.3 1.3 3.7 0.7
3. AS16276 be99-1181.gsw-1-a9.fr.eu 0.0% 10 4.2 4.2 4.0 4.5 0.0
4. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
5. AS15169 108.170.244.225 0.0% 10 4.1 4.1 4.1 4.3 0.0
6. AS15169 209.85.251.157 0.0% 10 4.4 4.4 4.3 4.6 0.0
7. AS15169 173.194.5.28 0.0% 10 4.0 4.1 4.0 4.1 0.0
hugues@lab:~$ mtr -zrwc10 173.194.9.246
Start: Thu Nov 10 12:00:40 2016
HOST: lab Loss% Snt Last Avg Best Wrst StDev
1. AS16276 94.23.110.78 0.0% 10 0.9 1.3 0.8 3.3 0.7
2. AS16276 be51.rbx-g1-a9.fr.eu 0.0% 10 5.7 8.3 0.8 58.8 18.0
3. AS16276 be99-1180.th2-1-a9.fr.eu 0.0% 10 4.2 4.3 4.1 4.5 0.0
4. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
5. AS15169 108.170.244.161 0.0% 10 4.3 4.3 4.2 4.4 0.0
6. AS15169 72.14.239.99 0.0% 10 5.3 5.3 5.3 5.5 0.0
7. AS15169 173.194.9.246 0.0% 10 4.7 4.7 4.6 4.7 0.0
-
Perso, je suis à plus de 55 Mo/s depuis un dédié OVH sur une vidéo youtube :
[youtube] nEtOCGw_ezw: Downloading webpage
[youtube] nEtOCGw_ezw: Downloading video info webpage
[youtube] nEtOCGw_ezw: Extracting video information
[youtube] nEtOCGw_ezw: Downloading MPD manifest
WARNING: Requested formats are incompatible for merge and will be merged into mkv.
[download] Destination: Neil ROBERTSON vs Stuart BINGHAM _ Rd1 2016 Champion of Champions-nEtOCGw_ezw.f136.mp4
[download] 100% of 1.10GiB in 00:20
[download] Destination: Neil ROBERTSON vs Stuart BINGHAM _ Rd1 2016 Champion of Champions-nEtOCGw_ezw.f171.webm
[download] 100% of 98.89MiB in 00:02
et iperf :
iperf3 -c bouygues.testdebit.info -p 5202 -R -t 20
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-20.00 sec 2.16 GBytes 929 Mbits/sec 2072 sender
[ 4] 0.00-20.00 sec 2.16 GBytes 929 Mbits/sec receiver
iperf Done.
-
Bon, comme je suis au taff (fibre symétrique 80M) je viens de tester en VPN depuis le poste, je sature la connexion fibre et Youtube en HD passe sans soucis :( ça laisse entendre que c'est le VPN Bonding qui pose problème, arf...
Merci Pach pour le test :)
-
Hm.. On passera donc la pub pour Online, et tu vas pouvoir sortir le Wireshark pour voir d'où ça vient :p
-
Je sais que j'ai beaucoup de out-of-order du au bonding, mais ca ne posait pas problème avant,
J'ai remarquer que j'ai un "burst" a 6 - 7 méga, et après chute du débit a 1-2méga,
Lors des captures Wirewhark, je vois que la windows commence a 48ko pour finir a 20ko
-
kaktuss77, si tu as des paquets qui arrivent dans le désordre, c'est catastrophique pour le débit.
Il suffit de quelques paquets dans le désordre au début d'une connexion TCP pour te casser compétemment le débit avec Windows.
Le problème est moins visible avec un client Linux, je pense que la raison est l’utilisation de l'option TCP timestamps qui permet de mieux gérer les dé séquencements.
Il y a plusieurs types de Bonding. Il est normalement conseillé de faire passer une même connexion TCP (même IP source, même IP destination, même port source, même port destinations) sur un même lien.
Dans tous les cas, les paquets devraient être restitués dans l'ordre, non ?
On m'a dit beaucoup de bien de la solution de bonding d'OVH Overthebox qui arriverait à faire passer mettre une connexion sur plusieurs liens différents sans être obligé de prendre la latence du lien la plus élevé. Je ne sais pas comment cela fonctionne.
-
On m'a dit beaucoup de bien de la solution de bonding d'OVH Overthebox qui arriverait à faire passer mettre une connexion sur plusieurs liens différents sans être obligé de prendre la latence du lien la plus élevé. Je ne sais pas comment cela fonctionne.
A ma connaissance c'est du MPTCP derrière, pas du bonding.
As-tu essayé cette solution d'ailleurs ? Un simple VPN TCP sur du MPTCP devrait faire l'affaire.
-
Si je fais ça, j'ai plus d’intérêt à faire du Bonding puisque j'aurais pour 1 connexion TCP le débit d'un accès (qui même le meilleurs ne me permet pas la HD sur Youtube)
pour le moment je suis en WRR (weighted Round Robin) je vais tester le MLVPN qui à un buffer pour re-ordering
OverTheBox ne gère que 4 lien ADSL max qui doit être dans des subnet LAN différents mais sur le même domaine ARP sans DHCP etc, donc problématique pour mes décodeurs TV (même par SAT, ils doivent passé par leur box respective et être dans le même réseau que la box)
Ce que j'ai du mal a comprendre c'est que je n'avais pas ce problème avant, et surtout que ca me le fait que pour les service google
@Flobaoti, peux-tu développer?
-
http://multipath-tcp.org/ ;)
Ça permet de créer des "sous-connexions" TCP dans une seule connexion TCP, et chaque sous-connexion peut emprunter un chemin différent (c'est l’intérêt du truc). Il faut un kernel patché avec ça de chaque côté, la bonne config de routage, puis un VPN en TCP par dessus et ça roule tout seul normalement.
-
Oui je vois j'en est entendu parlé, ça doit être un peut chaud à mettre en place lol, j'vais me renseigner
-
OVH a publié sur github si ca peut t'aider :
https://github.com/ovh/overthebox
-
A noter que des services comme Youtube ou Netflix utilisent au moins deux connexions TCP en // pour transférer les données. L'exception c'est CanalPlay qui est très peu agressif en n'utilisant qu'une seule connexion TCP qui est fermée après chaque bout récupéré.
Si tu restes dans une configuration ou les paquets arrivent dans le désordre, tu peut forcer l’activation de timestamps sous Windows via la base de registre.
-
@Pach, Yes j'ai été béta testeur :P
@Vivien, j'ai ce phénomème aussi bien sur mes machines linux, windows ou encore android.
je vais voir pour trouver une solution définitive
-
Tu me disait avoir un bon débit en téléchargement un fichier tel que wget -O /dev/null http://1.testdebit.info/fichiers/1000Mo.dat
Serait-il possible de voir si les paquets sont dé-séquencé ?
Si on comprend pourquoi le problème arrive dans certains cas et pas d'autres on pourra peut être corriger le problème.
Note: Youtube utilise des flux UDP + QUIC dans certains cas avec Chrome en client.
https://www.youtube.com/watch?v=hQZ-0mXFmk8
En TCP/IP, la couche 4 est géré par le système d’exploitation et donc pas souvent mis à jour (il reste encore de nombreux Windows XP).
En UDP/QUIC, la couche 4 est géré par le navigateur et donc mis à jour de façon très régulière, ce qui lui permet de profiter des dernières amélioration.
Google veut accélérer Internet avec QUIC
QUIC (Quick UDP Internet Connections, prononcé 'quick' NdT : 'couic' en français) est un protocole de transport multiplexé au dessus d'UDP avec comme but principal de ne pas ajouter de délai de connexion supplèmentaire.
Robbie Shade, un Développeur de Google, a introduit QUIC dans une vidéo récente, avec comme avantages principaux :
- Tous les avantages de SPDY (multiplexage, priorités, etc.)
- Connexions sans délai supplèmentaire
- Régulation de la vitesse d'émission de paquets pour diminuer les pertes
- Propagation de la correction d'erreurs pour réduire les latences de retransmission
- Gestion de congestion adaptative (proche de TCP), diminuant les reconnexions pour les clients mobiles
- Chiffrement équivalent à TLS
- Chrome peut communiquer avec Google par QUIC dès aujourd'hui
QUIC gère la retransmission, les paquets manquants ou dans le désordre, quelque chose qu'UDP ne fait pas par défaut. Le multiplexage dans QUIC siginifie que le protocole utilise plusieurs canaux pour envoyer les données, donc si un paquet est perdu dans un des flux de données, les autres ne sont pas bloqués en attente de celui-ci, comme c'est le cas pour SPDY, qui fait du multiplexage mais sur un seul canal. Cette approche dans QUIC résoud le problème de Head-of-line blocking (blocage d'un ensemble de paquets en attente du premier) qui peut arriver durant les retransmissions TCP, d'après Shade.
Un des bénéfices majeurs de l'utilisation de QUIC est le fait qu'il ne requiert pas de phase de handshake au premier contact entre le client et le serveur, d'une façon plus ou moins proche de TCP Fast Open, qui a été en discussion depuis 2011 mais n'a pas connu de large adoption. Selon Shade, le handshake TCP peut prendre jusqu'à 300 ms sur une connexion transatlantique si TLS est utilisé, alors que QUIC peut réduire cette latence à 100 ms.
Un autre avantage de QUIC est que les canaux de communication ne sont pas définis par le couple IP+port mais par un ID, ce qui permet de continuer une connexion même en changeant de réseau, par exemple quitter une zone Wi-Fi et entrer dans le réseau mobile.
Toutes les connexions QUIC sont chiffrées selon un mécanisme spécifique détaillé dans le QUIC Crypto document.
Quand on lui demande pourquoi ne pas utiliser une version améliorée de TCP + TLS, Shade répond que tandis que TCP et TLS subissent des améliorations, les itérations du protocole et leur déploiement sont très lents, alors que QUIC est déployé au niveau client et non au niveau du noyau, permettant des itérations beaucoup plus rapides - "des semaines plutôt que des années".
D'après Shade, SPDY peut fonctionner au dessus de QUIC dans le futur, le rendant encore meilleur qu'actuellement. Certaines des leçons apprises et testées par Google en pratique avec QUIC pourraient se retrouver dans TCP dans le futur.
Actuellement, il y a un client et un serveur disponible dans Chromium, et QUIC est utilisé par google.com, GMail, YouTube, et d'autres services Google.[/size]
Source : InfoQ (http://www.infoq.com/fr/news/2014/04/quic) le 15 avr. 2014 par Olivier Bourgain
-
le symptome est le même vers youtube quelque soit le navigateur, mais j'ai le meme soucis avec une update d'app sur le playstore par exemple.
Je fais une capture Wireshark avec un transfère complet d'un fichier de 10Mo
-
je joins la capture 201611_capture_bonding_6_lignes_adsl.pcap (https://lafibre.info/images/wireshark/201611_capture_bonding_6_lignes_adsl.pcap)
Voici le rendu au shell
wget -O /dev/null http://1.testdebit.info/fichiers/10Mo.dat
--2016-11-10 14:03:17-- http://1.testdebit.info/fichiers/10Mo.dat
Résolution de 1.testdebit.info (1.testdebit.info)… 194.158.102.114, 2001:860:f70b:200::2
Connexion à 1.testdebit.info (1.testdebit.info)|194.158.102.114|:80… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 10000000 (9,5M)
Enregistre : «/dev/null»
100%[======================================>] 10 000 000 1,80MB/s ds 5,5s
2016-11-10 14:03:23 (1,73 MB/s) - «/dev/null» enregistré [10000000/10000000]
-
Dans la capture on voit que les paquets arrivent dans un désordre complet, mais limité (les paquets en retard mettent moins de 200ys a arriver)
Il n'y a pas de retransmission TCP ici.
J'imagine que quand le débit est moindre, l'èmetteur a un comportement différent et il ré-èmet les paquets arrivés en retard, non ? (un même paquet est dans ce cas la visible deux fois)
(https://lafibre.info/images/wireshark/201611_capture_bonding_6_lignes_adsl.png)
-
je peux te faire une capture similaire avec un débit bloqué a 1méga pour une raison inconnue
-
Je vous joint les captures d'écrans pour 2 vidéos Youtube et les traceroutes vers les serveur respectif
traceroute to 173.194.5.28 (173.194.5.28), 30 hops max, 60 byte packets
4 po115.sbg-g2-a75.fr.eu (188.165.9.73) 29.367 ms 42.345 ms 22.320 ms
5 10.95.48.8 (10.95.48.8) 68.306 ms 34.220 ms 10.95.48.10 (10.95.48.10) 37.264 ms
6 mad-3-4m.es.eu (91.121.215.219) 39.315 ms 27.574 ms 54.184 ms
7 * * *
8 108.170.244.161 (108.170.244.161) 46.946 ms 34.808 ms 108.170.244.225 (108.170.244.225) 35.256 ms
9 209.85.251.155 (209.85.251.155) 35.214 ms 209.85.251.157 (209.85.251.157) 35.647 ms 34.644 ms
10 173.194.5.28 (173.194.5.28) 34.795 ms 41.848 ms 39.198 ms
Ce serait intéressant de savoir pourquoi tu es dirigé vers un serveur qui se trouve à Madrid...
Le DNS utilisé est-il le bon ou pas...
D'autre part il est toujours utile de désactiver le QUIC dans chrome://flags/
-
@Symbol: cela fait bien longtemps que je me sert plus de chrome mais merci pour l'info :)
Les serveurs DNS était ceux de OVH ISP, j'ai remit ceux de google, je testerais ce soir pour voir si c'est mieux
-
Ce serait intéressant de savoir pourquoi tu es dirigé vers un serveur qui se trouve à Madrid...
Le DNS utilisé est-il le bon ou pas...
D'autre part il est toujours utile de désactiver le QUIC dans chrome://flags/
oui .. c'est bien un serveur google ?
Car je ne crois pas qu'OVH peere avec Google à madrid.. et au vu du saut 6, çà ressemble à un routeur OVH à Madrid, (sauf si le reverse est faux ... )
-
Ils peerent ensemble sur l'Espanix :)
-
Ok, je pensais qu'ils utilisaient préférentiellement les 2 PNIs de Paris. (TH2 et GSW)
-
C'est vrai qu'on dirait un problème de DNS/GeoLoc : Google semble envoyer en Espagne.
Chez Free, je pars sur un GGC pour cette vidéo.
-
Le principe du GGC c'est d'envoyer un certain nombre de client (en fonction de la capacité du GGC) sur le GGC pour toutes les vidéos : populaires et moins populaires.
Si la vidéo n'est pas sur le GGC, celui-ci la télécharge avant de l'envoyer au client. Si la vidéo est peu populaire elle ne sera peut -être regardé que par ce client.
Le GGC, c'est physiquement un ensemble de serveurs Dell R720xd a 12 disques dur 3,5pouces hot-plug en façade + 2 disques dur 2,5pouces hot-plug en face arrière:
(https://lafibre.info/images/materiel/201210_dell_poweredge_r720xd_1.jpg)
-
Et dans la nature, ça donne ça :
(https://lafibre.info/images/k-net/201606_ggc_knet_gv1.jpg)
-
Hello tout le monde,
J'ai tester avec les serveurs DNS de Google au lieu de ce d'OVH, je suis toujours envoyé vers Madrid :/
Si quelqu'un a une idée, j'ai tester avec un autre pool IP que j'ai a dispo, toujours pareil, je précise que mes IPs sont localisées en France.
traceroute to r17---sn-25ge7ne6.googlevideo.com (173.194.135.182), 30 hops max, 60 byte packets
1 172.16.3.10 (172.16.3.10) 1.738 ms 1.698 ms 2.087 ms
2 10.10.10.9 (10.10.10.9) 40.565 ms 28.169 ms 28.116 ms
3 149.202.196.252 (149.202.196.252) 32.602 ms 32.544 ms 31.438 ms
4 po115.sbg-g1-a75.fr.eu (188.165.9.71) 30.508 ms po115.sbg-g2-a75.fr.eu (188.165.9.73) 30.447 ms 28.310 ms
5 * 10.95.48.10 (10.95.48.10) 27.335 ms *
6 mad-3-4m.es.eu (91.121.215.219) 30.502 ms 94.23.122.139 (94.23.122.139) 33.890 ms mad-3-4m.es.eu (91.121.215.219) 37.820 ms
7 * * *
8 108.170.244.161 (108.170.244.161) 35.640 ms 108.170.244.225 (108.170.244.225) 35.025 ms 108.170.244.161 (108.170.244.161) 33.508 ms
9 72.14.232.19 (72.14.232.19) 40.506 ms 72.14.232.57 (72.14.232.57) 35.921 ms 37.869 ms
10 173.194.135.182 (173.194.135.182) 39.313 ms 40.349 ms 38.739 ms
traceroute to r17---sn-25ge7ne6.googlevideo.com (173.194.135.182), 30 hops max, 60 byte packets
1 172.16.3.10 (172.16.3.10) 2.057 ms 1.982 ms 1.925 ms
2 10.10.10.9 (10.10.10.9) 30.547 ms 34.031 ms 20.515 ms
3 149.202.196.252 (149.202.196.252) 65.514 ms 66.352 ms 107.321 ms
4 po115.sbg-g1-a75.fr.eu (188.165.9.71) 39.760 ms po115.sbg-g2-a75.fr.eu (188.165.9.73) 29.266 ms po115.sbg-g1-a75.fr.eu (188.165.9.71) 33.656 ms
5 10.95.48.10 (10.95.48.10) 65.173 ms 37.849 ms *
6 94.23.122.139 (94.23.122.139) 37.762 ms mad-3-4m.es.eu (91.121.215.219) 46.827 ms 32.267 ms
7 * * *
8 108.170.244.225 (108.170.244.225) 36.233 ms 34.313 ms 108.170.244.161 (108.170.244.161) 39.700 ms
9 72.14.232.57 (72.14.232.57) 36.749 ms 27.120 ms 37.183 ms
10 173.194.135.182 (173.194.135.182) 37.543 ms 27.514 ms 73.453 ms
-
Il ne faut pas tester le serveur qui te sert la vidéo : celui-ci est en Espagne quelque soit l'endroit d'où l'on test.
Le problème c'est quand tu appelles la vidéo sur youtube.com : c'est lui qui cherche vers quel serveur vidéo te renvoyer.
Suivant le DNS que tu utilises, tu verras que l'IP de Youtube n'est pas la même, donc pas le même serveur donc la décision de t'envoyer vers le serveur de vidéo ne sera pas la même.
Chez OVH, c'est 213.186.33.99 que tu as utilisé ?
-
Tu peux utiliser l'astuce donné dans un autre sujet :
curl https://redirector.googlevideo.com/report_mapping
Sur mon serveur ovh, ca envoit vers par10s20
-
@BadMax : je suis allez sur youtube, j'ai pris une video au hasard, et je check dans les stats avancé sur quel serveur je suis co. et c'est a ce moment la que j'ai pris le lien du serveur.
@Phach : je suis aussi sur par10s20 (le 12-11-2016 a 15h53) pourtant le traceroute une fois connecté sur le serveur d'une vidéo m'envoie a priori vers l'espagne.
C:\Users\kaktuss>tracert r15---sn-25ge7n7z.googlevideo.com
Détermination de l’itinéraire vers r15.sn-25ge7n7z.googlevideo.com [173.194.0.116]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms 172.16.11.254
2 1 ms 1 ms 1 ms 172.16.3.10
3 29 ms 29 ms 28 ms 10.10.10.9
4 67 ms 71 ms 70 ms 149.202.196.252
5 21 ms 21 ms 22 ms po115.sbg-g2-a75.fr.eu [188.165.9.73]
6 30 ms 31 ms 30 ms 10.95.48.10
7 37 ms 37 ms 63 ms mad-3-4m.es.eu [91.121.215.219]
8 * * * Délai d’attente de la demande dépassé.
9 30 ms 27 ms 40 ms 108.170.244.161
10 39 ms 36 ms 36 ms 72.14.232.13
11 34 ms 36 ms 37 ms 173.194.0.116
Itinéraire déterminé.
Edit :
Quand je me sers de mon Pool IP en 164.132.20.xxx
j'ai ca : 164.132.20.xxx => par10s20 : router: "pr01.par10" next_hop_address: "37.187.231.240"(164.132.16.0/20)
et quand je me sers de mon Pool IP en 178.32.229.xxx
J'ai ca : 178.32.229.xxx => par03s07 : router: "pr01.par10" next_hop_address: "127.0.0.1"] (178.32.228.0/22) [u]
A quoi corresponds le Next_hop ?