Comment nous avons franchi le grand pare-feu chinois (partie 3)

Salut!
Toutes les bonnes histoires ont une fin. Et notre histoire sur la façon dont nous avons trouvé une solution pour contourner rapidement le pare-feu chinois ne fait pas exception. Je m'empresse donc de partager avec vous le dernier, la dernière partie sur ce sujet.

Dans la partie précédente, nous avons parlé des nombreux bancs de tests que nous avons imaginés et des résultats qu'ils ont donnés. Et nous avons décidé de ce qu'il serait bien d'ajouter CDN ! pour la viscosité dans notre schéma.

Je vais vous expliquer comment nous avons testé Alibaba Cloud CDN, Tencent Cloud CDN et Akamai, et ce que nous avons obtenu. Et bien sûr, résumons.

Alibaba Nuage CDN

Nous sommes hébergés sur Alibaba Cloud et utilisons IPSEC et CEN. Il serait logique d'essayer d'abord leurs solutions.

Alibaba Cloud propose deux types de produits qui peuvent nous convenir : CAN и DCDN. La première option est un CDN classique pour un domaine (sous-domaine) spécifique. La deuxième option signifie Route dynamique pour CDN (Je l'appelle CDN dynamique), il peut être activé en mode Site complet (pour les domaines génériques), il met également en cache le contenu statique et accélère le contenu dynamique sur lui-même, c'est-à-dire que la dynamique de la page sera également chargée via le fournisseur réseaux rapides. Ceci est important pour nous, car fondamentalement, notre site est dynamique, il utilise de nombreux sous-domaines et il est plus pratique de configurer un CDN une fois pour « l'astérisque » - *.semrushchina.cn.

Nous avions déjà vu ce produit dans les premières étapes de notre projet chinois, mais il ne fonctionnait pas encore et les développeurs ont promis que le produit serait bientôt disponible pour tous les clients. Et il l'a fait.

Dans DCDN, vous pouvez :

• configurer la terminaison SSL avec votre certificat,
• permettre l'accélération du contenu dynamique,
• configurer de manière flexible la mise en cache des fichiers statiques,
• purger le cache,
• transférer les sockets Web,
• activer la compression et même HTML Beautifier.

En général, tout est comme chez les adultes et les grands fournisseurs de CDN.

Une fois l'Origine (l'endroit où iront les serveurs Edge CDN) précisée, il ne reste plus qu'à créer un CNAME pour l'astérisque, en référençant all.semrushchina.cn.w.kunluncan.com (ce CNAME a été reçu dans la console Alibaba Cloud) et le CDN fonctionnera.

Sur la base des résultats des tests, ce CDN nous a beaucoup aidé. Les statistiques sont présentées ci-dessous.

décision
Uptime
Moyenne
75 centile
95 centile

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

CEN/IPsec + GLB
99.79
13s
16s
25s

Ali CDN + CEN/IPsec + GLB
99.75
10s
12.8s
17.3s

Ce sont de très bons résultats, surtout si on les compare avec les chiffres du début. Mais nous savions que le test du navigateur de la version américaine de notre site www.semrush.com s'exécute depuis les USA en 8.3s en moyenne (une valeur très approximative). Il y a place à amélioration. De plus, il existait également des fournisseurs de CDN intéressants à tester.

Nous passons donc en douceur à un autre géant du marché chinois - Tencent.

Nuage tencent

Tencent développe tout juste son cloud – cela se voit à partir d'un petit nombre de produits. En l'utilisant, nous voulions tester non seulement leur CDN, mais aussi leur infrastructure réseau dans son ensemble :

• ont-ils quelque chose de similaire au CEN ?
• Comment fonctionne IPSEC pour eux ? Est-ce rapide, quelle est la disponibilité ?
• est-ce qu'ils ont Anycast ?

Examinons ces questions séparément.

Analogique CEN

Tencent a un produit Réseau de connexion au cloud (NCF), vous permettant de connecter des VPC de différentes régions, y compris des régions situées à l'intérieur et à l'extérieur de la Chine. Le produit est désormais en version bêta interne et vous devez créer un ticket demandant de vous y connecter. Nous avons appris grâce au support que les comptes mondiaux (nous ne parlons pas de citoyens chinois ou d'entités juridiques) ne peuvent pas participer au programme de tests bêta et, en général, connecter une région à l'intérieur de la Chine avec une région à l'extérieur. 1-0 en faveur d'Ali Cloud

IPSEC

La région la plus méridionale de Tencent est Canton. Nous avons assemblé un tunnel et l'avons connecté à la région de Hong Kong dans GCP (cette région était alors déjà devenue disponible). Le deuxième tunnel d'Ali Cloud, de Shenzhen à Hong Kong, a également été surélevé au même moment. Il s'est avéré que grâce au réseau Tencent, la latence vers Hong Kong est généralement meilleure (10 ms) que de Shenzhen à Hong Kong vers Ali (120 ms - quoi ?). Mais cela n'a en aucun cas accéléré les travaux du site visant à passer par Tencent et ce tunnel, ce qui en soi était un fait étonnant et a prouvé une fois de plus ce qui suit : la latence - pour la Chine, ce n'est pas un indicateur qui vaut vraiment la peine en prêtant attention lors du développement d'une solution pour contourner le pare-feu chinois.

Accélération Internet Anycast

Un autre produit qui vous permet de travailler via anycast IP est AIA. Mais il n’est pas non plus disponible pour les comptes mondiaux, donc je ne vous en parlerai pas, mais savoir qu’un tel produit existe peut être utile.

Mais le test CDN a montré des résultats assez intéressants. Le CDN de Tencent ne peut pas être activé sur un site complet, uniquement sur des domaines spécifiques. Nous avons créé des domaines et leur avons envoyé du trafic :

Il s'est avéré que ce CDN a la fonction suivante : Optimisation du trafic transfrontalier. Cette fonctionnalité devrait réduire les coûts lorsque le trafic passe par le pare-feu chinois. Comme Origine L'adresse IP de Google GLB (GLB anycast) a été spécifiée. Ainsi, nous avons voulu simplifier l'architecture du projet.

Les résultats ont été très bons - au niveau d'Ali Cloud CDN, et même meilleurs à certains endroits. C'est surprenant, car si les tests réussissent, on peut abandonner une partie importante de l'infrastructure, tunnels, CEN, machines virtuelles, etc.

Nous ne nous sommes pas réjouis longtemps, car un problème a été révélé : les tests de Catchpoint ont échoué pour le fournisseur Internet China Mobile. Depuis n'importe quel endroit, nous avons reçu un délai d'attente via le CDN de Tencent. La correspondance avec le support technique n'a abouti à rien. Nous avons essayé de résoudre ce problème pendant environ une journée, mais rien n'a fonctionné.

J'étais en Chine à ce moment-là, mais je n'ai pas trouvé de Wi-Fi public sur le réseau de ce fournisseur pour vérifier personnellement le problème. Sinon, tout avait l'air rapide et bon.
Cependant, étant donné que China Mobile est l'un des trois plus grands opérateurs, nous avons été contraints de restituer le trafic vers Ali CDN.
Mais dans l’ensemble, il s’agissait d’une solution plutôt intéressante qui mérite des tests et un dépannage plus longs pour résoudre ce problème.

Akamai

Le dernier fournisseur CDN que nous avons testé était Akamai. Il s'agit d'un énorme fournisseur qui possède son réseau en Chine. Bien sûr, nous ne pouvions pas nous en sortir.

Dès le début, nous avons convenu avec Akamai d'une période d'essai afin de pouvoir changer de domaine et voir comment cela fonctionnerait sur leur réseau. Je décrirai le résultat de tous les tests sous la forme de « Ce que j’ai aimé » et « Ce que je n’ai pas aimé » et je donnerai également les résultats des tests.

Qu'est-ce que vous avez aimé:

• Les gars d'Akamai ont été très utiles pour toutes les questions et nous ont accompagnés à toutes les étapes des tests. Nous essayions constamment d’améliorer quelque chose de notre côté. Ils ont donné de bons conseils techniques.
• Akamai est environ 10 à 15 % plus lent que notre solution via Ali Cloud CDN. Ce qui est impressionnant, c'est que dans Origin pour Akamai, nous avons spécifié l'adresse IP du GLB, ce qui signifie que le trafic ne passait pas par notre solution (nous pourrions potentiellement abandonner une partie de l'infrastructure). Mais les résultats des tests ont montré que cette solution est moins bonne que notre version actuelle (résultats comparatifs ci-dessous).
• Testé à la fois Origin GLB et Origin en Chine. Les deux options sont à peu près les mêmes.
• Il est Itinéraire sûr (optimisation automatique du routage). Vous pouvez héberger un objet de test sur Origin et les serveurs Akamai Edge tenteront de le récupérer (GET normal). Pour ces requêtes, la vitesse et d'autres mesures sont mesurées, sur la base desquelles le réseau Akamai optimise les itinéraires afin que le trafic soit plus rapide pour notre site et il était clair que l'activation de cette fonctionnalité avait vraiment un fort impact sur la vitesse du site.
• La gestion des versions de la configuration dans l'interface Web est cool. Vous pouvez comparer les versions, regarder les différences. Consultez les versions précédentes.
• Vous pouvez d'abord déployer une nouvelle version uniquement sur le réseau Akamai Staging - le même réseau que celui de production, mais cette méthode n'affectera pas les utilisateurs réels. Pour ce test, vous devez usurper les enregistrements DNS sur votre ordinateur local.
• Vitesse de téléchargement très rapide via leur réseau pour les gros fichiers statiques et, apparemment, pour tout autre fichier. Un fichier du cache « froid » est récupéré plusieurs fois plus rapidement que le même fichier du cache « froid » d’Ali CDN. Depuis le cache « chaud », la vitesse est déjà la même, plus ou moins.

Test AliCDN :

root@shenzhen1:~# curl -o /dev/null -w@curl_time https://en.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 5757k    0 5757k    0     0   513k      0 --:--:--  0:00:11 --:--:--  526k
time_namelookup:  0.004286
time_connect:  0.030107
time_appconnect:  0.117525
time_pretransfer:  0.117606
time_redirect:  0.000000
time_starttransfer:  0.840348
----------
time_total:  11.208119
----------
size_download:  5895467 Bytes
speed_download:  525999.000B/s

Test Akamai :

root@shenzhen1:~# curl -o /dev/null -w@curl_time https://www.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 5757k    0 5757k    0     0  1824k      0 --:--:--  0:00:03 --:--:-- 1825k
time_namelookup:  0.509005
time_connect:  0.528261
time_appconnect:  0.577235
time_pretransfer:  0.577324
time_redirect:  0.000000
time_starttransfer:  1.327013
----------
time_total:  3.154850
----------
size_download:  5895467 Bytes
speed_download:  1868699.000B/s

Nous avons remarqué que la situation dans l’exemple ci-dessus dépend de divers facteurs. Au moment d’écrire ce point, j’ai refait le test. Les résultats pour les deux plateformes étaient à peu près les mêmes. Cela nous indique qu'Internet en Chine, même pour les grands opérateurs et les fournisseurs de cloud, se comporte de temps en temps différemment.

Au point précédent, j'ajouterai un gros plus pour Akamai : si Ali affiche des flashs similaires de hautes performances et de très faibles performances (cela s'applique à Ali CDN, Ali CEN et Ali IPSEC), alors Akamai, à chaque fois, peu importe comment je teste leur réseau, tout fonctionne de manière stable.
Akamai dispose d'une large couverture en Chine et travaille par l'intermédiaire de nombreux fournisseurs.

Ce qui n'a pas aimé:

• Je n’aime pas l’interface Web et la façon dont elle fonctionne – elle est vraiment médiocre. Mais en gros, on s'y habitue (sans doute).
• Les résultats des tests sont pires que ceux de notre site.
• Il y a plus d'erreurs lors des tests que sur notre site (uptime ci-dessous).
• Nous n'avons pas nos propres serveurs DNS en Chine. Par conséquent, il existe de nombreuses erreurs dans les tests en raison du délai d’expiration de la résolution DNS.
• Ils ne fournissent pas leurs plages IP -> il n'y a aucun moyen d'enregistrer les bonnes set_real_ip_from sur nos serveurs.

Métriques (~ 3626 XNUMX exécutions ; toutes les métriques sauf la disponibilité, en ms ; statistiques pour une période) :

Fournisseur CDN
Moyenne
75%
95%
Réponse
Réponse de la page Web
Uptime
DNS
NOUS CONTACTER
Attendez
Charge
SSL

AliCDN
9195
10749
17489
1,715
10,745
99.531
57
17
927
479
200

Akamai
9783
11887
19888
2,352
11,550
98.980
424
91
1408
381
50

Distribution par centile (en ms) :

Centile
Akamai
AliCDN

10
7,092
6,942

20
7,775
7,583

30
8,446
8,092

40
9,146
8,596

50
9,783
9,195

60
10,497
9,770

70
11,371
10,383

80
12,670
11,255

90
15,882
13,165

100
91,592
91,596

La conclusion est la suivante : l’option Akamai est viable, mais n’offre pas la même stabilité et rapidité que notre propre solution couplée à Ali CDN.

Petites remarques

Certains moments n'étaient pas inclus dans l'histoire, mais j'aimerais aussi écrire sur eux.

Pékin + Tokyo et Hong Kong

Comme je l'ai dit plus haut, nous avons testé un tunnel IPSEC vers Hong Kong (HK). Mais nous avons également testé le CEN à HK. Cela coûte un peu moins cher et je me demandais comment cela fonctionnerait entre des villes distantes d'environ 100 km. Il s'est avéré intéressant que la latence entre ces villes soit 100 ms plus élevée que dans notre version originale (vers Taiwan). La vitesse et la stabilité étaient également meilleures pour Taiwan. En conséquence, nous avons laissé Hong Kong comme région IPSEC de secours.

De plus, nous avons essayé d'installer l'installation suivante :

• licenciement de clients à Pékin,
• IPSEC et CEN à Tokyo,
• dans Ali CDN, le serveur de Pékin était indiqué comme origine.

Ce schéma n'était pas aussi stable, même si en termes de vitesse il n'était généralement pas inférieur à notre solution. Concernant le tunnel, j'ai constaté des baisses intermittentes même pour le CEN, qui aurait dû être stable. Nous sommes donc revenus à l’ancien schéma et avons démonté cette mise en scène.

Vous trouverez ci-dessous des statistiques sur la latence entre différentes régions pour différents canaux. Peut-être que quelqu'un sera intéressé.

IPsec
Ali cn-beijing <—> GCP asie-nord-est1 — 193 ms
Ali cn-shenzhen <—> GCP asie-est2 — 91 ms
Ali cn-shenzhen <—> GCP us-east4 — 200 ms

CEN
Ali cn-beijing <—> Ali ap-nord-est-1 — 54 ms (!)
Ali cn-shenzhen <—> Ali cn-hongkong — 6 ms (!)
Ali cn-shenzhen <—> Ali us-east1 — 216 ​​ms

Informations générales sur Internet en Chine

En complément des problèmes liés à Internet décrits au tout début, dans la première partie de l'article.

• Internet en Chine est assez rapide à l'intérieur.
  • La conclusion a été tirée sur la base de tests de réseaux Wi-Fi publics dans divers endroits où ces réseaux sont utilisés par un grand nombre de personnes.
  • Les vitesses de téléchargement et de téléchargement vers les serveurs en Chine étaient respectivement d'environ 20 Mbit/s et 5 à 10 Mbit/s.
  • La vitesse vers les serveurs en dehors de la Chine est tout simplement maigre, inférieure à 1 Mbit/s.
• Internet en Chine n'est pas très stable.
  • Parfois les sites peuvent s'ouvrir rapidement, parfois lentement (à la même heure selon des jours différents), à condition que la configuration ne change pas. Nous l’avons observé avec l’exemple de semrushchina.cn. Cela peut être attribué à Ali CDN, qui fonctionne également de cette façon et cela en fonction de l'heure de la journée, de la position des étoiles, etc.
• L'Internet mobile est presque partout en 4G ou 4G+. Attrapez-le dans le métro, les ascenseurs, bref, partout.
• C'est un mythe selon lequel les utilisateurs chinois ne font confiance qu'aux domaines de la zone .cn. Nous l’avons appris directement des utilisateurs.
  • Vous pouvez voir comment http://baidu.cn redirigez vers www.baidu.com (en Chine continentale également).
• De nombreuses ressources sont en effet bloquées. Primitif : google.com, Facebook, Twitter. Mais de nombreuses ressources de Google fonctionnent (bien sûr, pas sur toutes). Le Wi-Fi et le VPN ne sont pas utilisés (côté routeur aussi, c'est sûr).
• De nombreux domaines « techniques » des entreprises bloquées fonctionnent également. Cela signifie que vous ne devez pas toujours supprimer imprudemment toutes les ressources Google et autres ressources apparemment bloquées. Vous devez rechercher une liste de domaines interdits.
• Ils ne disposent que de trois principaux opérateurs Internet : China Unicom, China Telecom, China Mobile. Il en existe encore plus petits, mais leur part de marché est insignifiante

Bonus : diagramme de solution finale

Total

Un an s'est écoulé depuis le début du projet. Nous avons commencé par le fait que notre site refusait généralement de fonctionner normalement depuis la Chine, et simplement GET curl prenait 5.5 secondes.

Ensuite, avec ces indicateurs dans la première solution (Cloudflare) :

décision
Uptime
Moyenne
75 centile
95 centile

Cloudflare
86.6
18s
30s
60s

Nous avons finalement atteint les résultats suivants (statistiques du mois dernier) :

décision
Uptime
Moyenne
75 centile
95 centile

Ali CDN + CEN/IPsec + GLB
99.86
8.8s
9.5s
13.7s

Comme vous pouvez le constater, nous n'avons pas encore réussi à atteindre une disponibilité de 100 %, mais nous trouverons quelque chose, puis nous vous parlerons des résultats dans un nouvel article :)

Respect à ceux qui ont lu les trois parties jusqu'à la fin. J'espère que vous avez trouvé tout cela aussi intéressant que moi lorsque je l'ai fait.

PS Parties précédentes

Partie 1
Partie 2

Source: habr.com