Auteur Sujet: Une connexion vers les site constitués sur Aliyun bloquée et GMO très lente ?!  (Lu 949 fois)

0 Membres et 1 Invité sur ce sujet

netabare

  • Client FAI autre
  • *
  • Messages: 12
  • Guangzhou, China (Actuellement en France)
Bonjour à tous,

Je viens de changer mon fournisseur chez Orange avec un abonnement de 200MBps/50MBps et au début tout s'est passé bien (sauf parfois il y a des déconnexions Wi-Fi mais plutôt des petits trucs..)

Pourtant depuis il y a 2 semaines des choses commencèrent à changer. Dans les sujets précédents j'ai mentionné que j'ai besoin d'une connexion plus fiable pour accéder sur les sites en Asie, mais il me semble que cela a été bloqué?

-------------------------------------

Voici un peu de teste et les résultats:

Request timeout for icmp_seq 38
Request timeout for icmp_seq 39
^C
--- simcity.cn ping statistics ---
41 packets transmitted, 7 packets received, 82.9% packet loss
round-trip min/avg/max/stddev = 315.492/414.672/1006.464/241.599 ms

traceroute to simcity.cn (121.40.25.108), 64 hops max, 52 byte packets
 1  192.168.1.1 (192.168.1.1)  6.153 ms  4.153 ms  4.021 ms
 2  80.10.237.217 (80.10.237.217)  7.747 ms  7.191 ms  6.312 ms
 3  ae101-0.nctou202.toulouse.francetelecom.net (193.249.214.46)  4.293 ms  3.735 ms  3.923 ms
 4  ae43-0.nipoi202.poitiers.francetelecom.net (193.252.160.54)  9.603 ms  10.694 ms  10.697 ms
 5  193.252.137.14 (193.252.137.14)  21.733 ms  21.050 ms  24.964 ms
 6  hundredgige1-11-0-0.auvtr4.aubervilliers.opentransit.net (193.251.129.87)  20.803 ms
    hundredgige2-15-0-0.auvtr4.aubervilliers.opentransit.net (193.251.128.185)  20.707 ms
    81.52.200.188 (81.52.200.188)  17.576 ms
 7  hundredgige0-14-0-2.ffttr5.frankfurt.opentransit.net (193.251.129.40)  32.899 ms  31.835 ms
    hundredgige0-7-0-2.ffttr4.frankfurtammain.opentransit.net (193.251.240.173)  31.486 ms
 8  hundredgige0-0-0-1.ffttr5.frankfurt.opentransit.net (193.251.128.73)  33.561 ms
    et-0-0-2-0.ffttr6.frankfurt.opentransit.net (193.251.133.165)  26.430 ms
    hundredgige0-0-0-1.ffttr5.frankfurt.opentransit.net (193.251.128.73)  33.725 ms
 9  chinatelecom.gw.opentransit.net (81.52.179.174)  27.810 ms  26.436 ms
    et-0-0-2-0.ffttr6.frankfurt.opentransit.net (193.251.133.165)  28.166 ms
10  chinatelecom.gw.opentransit.net (81.52.179.174)  31.663 ms  30.899 ms *
11  * * *
12  * * 202.97.50.229 (202.97.50.229)  323.543 ms
13  202.97.33.65 (202.97.33.65)  363.668 ms * *
14  220.191.200.38 (220.191.200.38)  330.693 ms *
    220.191.200.46 (220.191.200.46)  571.521 ms
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * 121.40.25.108 (121.40.25.108)  324.553 ms

C'est un forum chinois auquel je m'accède souvent (pour discuter un peu sur les jeux et l'urbanisme et des blagues, par exemple), et il est déposé sur Hichina, un hosting proposé par Aliyun.
Et ensuite j'ai testé le site d'Aliyun, bien sur sans fonctionnement.
Ces sites ont aussi été testés sur mon portable (iOS 9 et puis iOS 10, iPhone 5S) pour retrouver le même résultat. Alors que dans le réseau cellulaire de Bouygues la connexion réussite.

J'ai utilisé Google DNS (8.8.8.8 et 8.8.4.4 pour IPv4 et 2001:4860:4860::8888 pour IPv6) dans un premier temps lors de l'apparition du problème mais rien n'a changé. Et sur la page Configuration de Livebox je n'arrive pas à trouver des paramètres avancés pour changer de DNS, etc.
Donc je suis obligé d'utiliser, actuellement un VPN (au fait un proxy Shadowsocks) pour me connecter sur ces sites "théoriquement bloqués". Mais j'aimerais vraiment être rassuré qu'ils sont vraiment bloqué par quelle raison, donc je pourrai essayer des solutions comme VPN ou chaine de proxy pour dépasser cette limitation, ou bien que c'est justement un incident par hasard.

D'ailleurs je suis aussi étonnant de savoir qu'une connexion vers un VPS déposé au Tokyo manque tant de fiable comme ça:


--- MA_MACHINE ping statistics ---
9 packets transmitted, 8 packets received, 11.1% packet loss
round-trip min/avg/max/stddev = 362.773/843.646/1007.162/228.140 ms

1  192.168.1.1 (192.168.1.1)  4.031 ms  2.631 ms  2.580 ms
 2  80.10.237.217 (80.10.237.217)  3.788 ms  4.350 ms  3.718 ms
 3  ae101-0.nctou202.toulouse.francetelecom.net (193.249.214.46)  6.040 ms  3.073 ms  3.848 ms
 4  ae43-0.nipoi202.poitiers.francetelecom.net (193.252.160.54)  10.201 ms  10.123 ms  16.823 ms
 5  193.252.137.14 (193.252.137.14)  25.174 ms  23.418 ms  24.075 ms
 6  ae-11.r04.parsfr01.fr.bb.gin.ntt.net (129.250.66.17)  46.155 ms  45.509 ms  44.237 ms
 7  ae-2.r25.londen12.uk.bb.gin.ntt.net (129.250.6.13)  51.303 ms  52.852 ms  51.433 ms
 8  ae-1.r24.londen12.uk.bb.gin.ntt.net (129.250.2.26)  47.587 ms  52.083 ms  51.912 ms
 9  ae-5.r24.nycmny01.us.bb.gin.ntt.net (129.250.2.18)  115.651 ms  1067.770 ms  115.024 ms
10  ae-2.r20.sttlwa01.us.bb.gin.ntt.net (129.250.4.13)  188.770 ms  900.868 ms  181.301 ms
11  ae-23.r30.tokyjp05.jp.bb.gin.ntt.net (129.250.2.38)  266.380 ms  756.172 ms  1228.671 ms
12  ae-20.r00.tokyjp05.jp.bb.gin.ntt.net (129.250.7.83)  1130.749 ms  1293.991 ms  1228.917 ms
13  ae-0.gmo.tokyjp05.jp.bb.gin.ntt.net (61.120.146.182)  1130.329 ms  1303.367 ms  1228.796 ms
14  * * *
15  * * *
16  c-5en-a11-1-v-711.interq.or.jp (157.7.41.126)  707.285 ms  1303.123 ms  1032.194 ms
17  * * *

Et ceci va continuer jusqu'à exhaustion du temps.

Avec une fibre de FTTH c'est déjà incroyable d'avoir une latence de mille ms vers un hosting service commun (comme DigitalOcean en France) et j'aimerais en savoir pourquoi.
Et si c'est possible comment peut-on le configurer (ou autrement dit résoudre).

Appareil: MacbookAir 13', Système: macOS Sierra

Merci beaucoup!
Bonne journée.

Aize147

  • Client Orange Fibre
  • *
  • Messages: 441
  • Lyon (69006)
Une connexion vers les site constitués sur Aliyun bloquée et GMO très lente ?!
« Réponse #1 le: 16 décembre 2016 à 20:08:49 »
De mon côté :

root@OpenWrt:~# mtr simcity.cn -rwc10
Start: Fri Dec 16 20:02:47 2016
HOST: OpenWrt                                              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1                                           0.0%    10    0.3   0.4   0.2   0.7   0.0
  2.|-- 80.10.234.49                                         20.0%    10   14.5   8.0   4.8  14.5   4.2
  3.|-- ae103-0.nclyo202.Lyon.francetelecom.net               0.0%    10    5.2   5.7   4.8   8.4   0.9
  4.|-- 81.253.182.230                                        0.0%    10    5.6   6.3   4.8  14.0   2.7
  5.|-- ae40-0.nilyo101.Lyon.francetelecom.net                0.0%    10    4.9   5.4   4.9   7.3   0.6
  6.|-- 81.253.184.114                                        0.0%    10   18.6  19.9  16.6  23.5   2.4
  7.|-- hundredgige0-13-0-2.ffttr5.Frankfurt.opentransit.net  0.0%    10   21.0  20.5  16.6  23.0   2.4
  8.|-- et-0-0-6-0.ffttr6.Frankfurt.opentransit.net           0.0%    10   15.4  15.7  15.3  16.9   0.3
  9.|-- chinatelecom.GW.opentransit.net                       0.0%    10   18.1  17.5  15.9  19.7   1.2
 10.|-- 202.97.58.61                                         70.0%    10  308.6 309.1 308.6 309.4   0.0
 11.|-- ???                                                  100.0    10    0.0   0.0   0.0   0.0   0.0
 12.|-- 202.97.33.109                                        50.0%    10  313.9 312.7 311.8 313.9   0.5
 13.|-- ???                                                  100.0    10    0.0   0.0   0.0   0.0   0.0
 14.|-- 220.191.200.122                                      90.0%    10  305.2 305.2 305.2 305.2   0.0
 15.|-- 115.236.101.221                                      60.0%    10  301.2 301.1 300.7 301.3   0.0
 16.|-- 42.120.247.61                                        90.0%    10  316.6 316.6 316.6 316.6   0.0
 17.|-- 140.205.27.197                                       55.6%     9  314.6 317.7 314.6 326.4   5.8
 18.|-- ???                                                  100.0     9    0.0   0.0   0.0   0.0   0.0
 19.|-- ???                                                  100.0     7    0.0   0.0   0.0   0.0   0.0
 20.|-- 121.40.25.108                                        71.4%     7  314.4 314.5 314.4 314.5   0.0


Il n'y a rien d'anormal, le site répond lentement et c'est normal avec plus de 300ms. Même si tu es en FTTH ça ne changera rien au faite que le site se trouve toujours en Asie.

robin4002

  • Client SFR sur réseau Numericable
  • *
  • Messages: 254
  • Illkirch (67) / Hattstatt (68)
Une connexion vers les site constitués sur Aliyun bloquée et GMO très lente ?!
« Réponse #2 le: 16 décembre 2016 à 20:24:23 »
Salut,

Ce n'est pas parce que tu as la fibre que tout internet est sensé fonctionner super rapidement.
Pour comparer avec quelque chose d'un peu plus visuel, on peut se représenter les câbles / la fibre par des tuyaux.
Quand tu es en adsl, tu as un petit tuyau entre toi et ton opérateur.
Quand tu as la fibre, tu as un énorme tuyau entre toi et ton opérateur.

Le problème, c'est qu'internet ce n'est pas juste ton opérateur. Quand tu veux joindre un site, il faut ensuite passer par le tuyaux qui relit ton opérateur à l'hébergeur du site.
Et dans ce tuyau il n'y a pas que toi mais également les autres clients de ton opérateur qui veulent joindre la même destination. Et les tuyaux entre un opérateur et un hébergeur (ou autre destination) ne sont malheureusement pas toujours bien dimensionné. (exemple : youtube et free où il y a eu de gros problèmes qui ont fait du bruit sur la presse).

Là ton soucis c'est que la connexion entre Orange et Aliyun est sous dimensionné et donc sature.
En passant par un vpn, tu passes par un autre chemin, qui est surement moins saturé comme cela fonctionne.
Et dans le cas de ta connexion mobile avec Bouygues, idem, le tuyau entre Bouygues et Aliyun est suffisamment dimensionné pour que cela fonctionne sans problème.


Tu peux aller faire un tour dans la section peering / transit qui parle de tout ça si tu veux te renseigner plus sur le sujet : https://lafibre.info/peering-transit/

netabare

  • Client FAI autre
  • *
  • Messages: 12
  • Guangzhou, China (Actuellement en France)
Salut robin4002 et Aize147

Merci pour vos réponses. En effet c'est une première fois que j'ai abonné à un FAI. J'étais chez un logement étudiant auparavant (évidemment le RENATER ayant des censures) et en avance...
Donc j'ai eu peur que les FAI pourront censurer ou manœuvrer le réseau, limiter les connexions ou la performances...

En tout cas merci beaucoup! Je vais voir si pour peering il y aura des choses intéressantes..

petrus

  • Expert AS206155
  • Expert
  • *
  • Messages: 741
Là ton soucis c'est que la connexion entre Orange et Aliyun est sous dimensionné et donc sature.

Non pas forcèment.

Avec 300ms de rtd il y a le scaling tcp qui va jouer énormèment sur le débit, et avec l'asie, et surtout la chine, c'est très compliqué de ne pas avoir de perte de paquets. Je parle en connaissance de cause pour avoir fourni du vpn à des expats français en chine depuis la france, c'était la grosse galère des débits. Pour toucher la chine continentale il vaut mieux avoir un serveur à HK par exemple. Et avec la perte de paquets le tcp ne va jamais monter en débit... ce qui impactera les perfs en téléchargement.

Et même si c'est juste de la consultation de pages web, une page moderne c'est plein de ressources (html, images, js, etc) qui nécessiterons souvent une connexion tcp chacune, vers des serveurs différents. Même en faisant les requetes plus ou moins en parallèle, avec 3-400ms de latence c'est juste _lent_.



netabare

  • Client FAI autre
  • *
  • Messages: 12
  • Guangzhou, China (Actuellement en France)
Non pas forcèment.

Avec 300ms de rtd il y a le scaling tcp qui va jouer énormèment sur le débit, et avec l'asie, et surtout la chine, c'est très compliqué de ne pas avoir de perte de paquets. Je parle en connaissance de cause pour avoir fourni du vpn à des expats français en chine depuis la france, c'était la grosse galère des débits. Pour toucher la chine continentale il vaut mieux avoir un serveur à HK par exemple. Et avec la perte de paquets le tcp ne va jamais monter en débit... ce qui impactera les perfs en téléchargement.

Et même si c'est juste de la consultation de pages web, une page moderne c'est plein de ressources (html, images, js, etc) qui nécessiterons souvent une connexion tcp chacune, vers des serveurs différents. Même en faisant les requetes plus ou moins en parallèle, avec 3-400ms de latence c'est juste _lent_.




Souvent les fournisseurs en HK sont des fournisseurs suspicieux avec des services pas du tout cher mais de qualité questionnable et saturé par les bitcoiners et des diffuseurs de pubs. Pourtant si on peut passer par le réseau CN2 la performance sera beaucoup mieux.
Je pense ce qui compte c'est plutôt la latence que le débit.

Je viens de rétablir mon proxy et rencontrer un protocole qui s'appelle kcp, disant que ce protocole permet de réduire 30% à 40% de latence en moyen et 3 fois le retard en augmentant 10~20% de bande que tcp (c'est implanté en udp). Donc j'ai implanté ceci en dehors de mon shadowsocks vpn et j'ai impression que les pages web s'affichent plus tranquillement...
https://github.com/skywind3000/kcp
Je ne connais pas les autres vpn mais normalement c'est possible de combiner kcp avec d'autres protocole.

kcp va envoyer beaucoup plus de paquets udp que le cas sans cette implantation et le résultat sera un gros gaspillage de bandwidth. Je suis passé à TCP-BBR qui nécessite une mise à jour de système du serveur mais la performance est satisfaisante sans nécessité de gaspillage des ressources...
https://doub.io/wlzy-15/ (J'arrive pas à trouver un tuto en français ou anglais à ce sujet  :-\)
Apres il y a aussi un service vxtrans de vnet.link qui propose des amélioration mais c'est un peu cher et c'est plutôt spécialisé en la connexion entre la chine et les autres pays (alors que ce n'est qu'une part de mon souci).

Ce sujet peut être considéré comme résolu (au moins à ce jour).
« Modifié: 16 février 2017 à 12:30:31 par netabare »

 

Mobile View