Comment nous avons contourné le Grand Pare-feu de Chine (partie 3)

Bonjour !
Toutes les bonnes histoires ont une fin. Et notre histoire sur la façon dont nous avons trouvé une solution pour contourner le Grand Firewall de Chine ne fait pas exception. Je suis donc ravi de partager avec vous la dernière partie, la partie finale à ce sujet.

Dans la partie précédente, nous avons parlé de nombreux bancs d'essai que nous avons conçus et des résultats qu'ils ont donnés. Et nous nous étions arrêtés sur le fait qu'il serait bon d'ajouter un CDN ! pour la cohésion de notre schéma.

Je vais vous raconter comment nous avons testé Alibaba Cloud CDN, Tencent Cloud CDN et Akamai, et quelle solution nous avons finalement choisie. Et bien sûr, nous ferons un résumé.

Alibaba Cloud CDN

Nous sommes hébergés chez Alibaba Cloud, utilisant IPSEC et CEN de leur part. Il serait logique de commencer par essayer leurs solutions.

Alibaba Cloud propose deux types de produits qui pourraient nous convenir : CDN et DCDN. La première option est un CDN classique pour un domaine spécifique (sous-domaine). La seconde option se déchiffre en Dynamic Route for CDN (que j'appelle CDN dynamique), qui peut être activé en mode Full-site (pour les domaines wildcard), il met également en cache la statique et accélère le contenu dynamique, c'est-à-dire que la dynamique de la page sera également chargée via les réseaux rapides du fournisseur. C'est important pour nous, car notre site est principalement dynamique, utilisant de nombreux sous-domaines, et il est plus pratique de configurer le CDN une seule fois pour “l'astérisque” — *.semrushchina.cn.

Nous avions déjà vu ce produit lors des premières étapes de notre projet en Chine, mais à l'époque, il ne fonctionnait pas encore, et les développeurs promettaient que le produit serait bientôt disponible pour tous les clients. Et cela a été fait.

Dans DCDN, vous pouvez :

• configurer la terminaison SSL avec votre propre certificat,
• activer l'accélération du contenu dynamique,
• configurer de manière flexible le cache des fichiers statiques,
• effectuer un purge du cache,
• faire passer des web sockets,
• activer la compression et même HTML Beautifier.

En gros, tout comme chez les grands fournisseurs de CDN.

Après avoir spécifié l'Origin (l'endroit vers lequel iront les serveurs edge du CDN), il ne reste plus qu'à créer un CNAME pour l'astérisque, pointant vers all.semrushchina.cn.w.kunluncan.com (ce CNAME a été obtenu dans la console Alibaba Cloud), et le CDN fonctionnera.

D'après les résultats des tests, ce CDN nous a beaucoup aidés. Les statistiques sont ci-dessous.

Solution
Uptime
Médiane
75e percentile
95e percentile

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 à ceux d'auparavant. Mais nous savions que le test de la version américaine de notre site www.semrush.com s'effectue en moyenne depuis les États-Unis en 8,3 secondes (valeur très approximative). Il y a du chemin à parcourir. De plus, il y avait d'autres fournisseurs de CDN qui méritaient d'être testés.

Nous passons ainsi en douceur à un autre géant du marché chinois — Tencent.

Tencent Cloud

Tencent développe encore son cloud — cela se voit par le petit nombre de produits. Au cours de son utilisation, nous avons voulu tester non seulement leur CDN mais aussi l'infrastructure réseau dans son ensemble :

• ont-ils quelque chose qui ressemble à CEN ?
• Comment fonctionne leur IPSEC ? Est-ce rapide, quel est leur uptime ?
• ont-ils du Anycast ?

Nous allons examiner ces questions séparément.

Analog CEN

Tencent dispose d'un produit Cloud Connect Network (CCN), permettant de connecter entre eux des VPC de différentes régions, y compris des régions à l'intérieur et à l'extérieur de la Chine. Le produit est actuellement en version beta interne, et il faut créer un ticket pour demander à y accéder. D'après le support, nous avons appris que les comptes globaux (pas de citoyens chinois ou de personnes morales) ne peuvent pas participer au programme de test beta et ne peuvent généralement pas connecter une région en Chine avec une région à l'extérieur. 1-0 en faveur d'Ali Cloud.

IPSEC

La région la plus au sud de Tencent est Guangzhou. Nous avons créé un tunnel et l'avons connecté à la région de Hong Kong dans GCP (à l'époque, cette région était déjà accessible). Nous avons également ouvert en même temps un deuxième tunnel dans Ali Cloud de Shenzhen à Hong Kong. Il s'est avéré qu'à travers le réseau de Tencent, la latence vers Hong Kong est globalement meilleure (10 ms) que de Shenzhen à Hong Kong dans Ali (120 ms — quoi ?). Mais cela n'accélérait en aucun cas le fonctionnement du site orienté vers Tencent et ce tunnel, ce qui était un fait surprenant et prouvait encore une fois que : la latence — pour la Chine, ce n'est pas un indicateur sur lequel il faut vraiment se concentrer lors du développement d'une solution pour le contournement du pare-feu chinois.

Anycast Internet Acceleration

Un autre produit permettant de travailler via IP anycast — AIA. Mais il est également inaccessible aux comptes globaux, donc je n'en parlerai pas, mais savoir qu'un tel produit existe peut être utile.

Mais le test de CDN a montré des résultats plutôt intéressants. Le CDN de Tencent ne peut pas être activé sur un site complet, seulement sur des domaines spécifiques. Nous avons installé des domaines et dirigé du trafic vers eux :

Il s'est avéré que ce CDN a cette fonction : Optimisation du trafic transfrontalier. Cette fonctionnalité devrait réduire les coûts de passage du trafic à travers le pare-feu chinois. En tant que Origin adresse IP du GLB de Google (GLB anycast). Ainsi, nous voulions simplifier l'architecture du projet.

Les résultats ont été très bons — au niveau de l'Ali Cloud CDN, et parfois même meilleurs. C'est surprenant, car en cas de réussite des tests, il serait possible de se passer d'une part importante de l'infrastructure, des tunnels, CEN, des serveurs virtuels, etc.

Nous avons peu apprécié cette joie, car un problème est apparu : les tests dans Catchpoint échouaient pour le fournisseur d'accès internet China Mobile. Nous avons reçu un timeout via le CDN de Tencent depuis n'importe quelle localisation. La correspondance avec le support technique n'a rien donné. Pendant environ un jour, nous avons essayé de résoudre ce problème, mais sans succès.

À ce moment-là, j'étais en Chine, mais je n'ai pas pu trouver de Wi-Fi public dans le réseau de ce fournisseur pour vérifier le problème personnellement. En dehors de cela, tout semblait rapide et bon.
Cependant, étant donné que l'opérateur China Mobile fait partie des trois plus grands opérateurs, nous avons dû renvoyer le trafic vers l'Ali CDN.
Mais dans l'ensemble, c'était une solution assez intéressante qui mérite un test et un dépannage plus approfondis.

Akamai

Le dernier fournisseur CDN que nous avons testé est Akamai. C'est un grand fournisseur qui possède son propre réseau en Chine. Bien sûr, nous ne pouvions pas passer à côté.

Dès le départ, nous avons convenu avec Akamai d'une période d'essai, afin que nous puissions activer le domaine et voir comment il fonctionnerait sur leur réseau. Je décrirai les résultats de tous les tests sous forme de “Ce que j'ai aimé” et “Ce que je n'ai pas aimé”, ainsi que les résultats des tests.

Ce que j'ai aimé :

• Les équipes d'Akamai sont très aidantes dans toutes les questions et nous ont accompagnés à chaque étape des tests. Ils ont constamment cherché à améliorer quelque chose de leur côté. Ils ont donné de bons conseils techniques.
• Akamai fonctionne environ 10 à 15 % plus lentement que notre solution via Ali Cloud CDN. Ce qui est impressionnant, c'est que pour Akamai, nous avons indiqué l'adresse IP du GLB en tant qu'origine, ce qui signifie que le trafic ne passait pas par notre solution (il est donc potentiellement possible de se passer d'une part de l'infrastructure). Cependant, les résultats des tests ont montré que cette option était moins bonne que notre solution actuelle (les résultats comparatifs ci-dessous).
• Il a été testé à la fois comme origine GLB et comme origine en Chine. Les deux options sont à peu près identiques.
• Oui Sure Route (optimisation automatique du routage). Il est possible de placer un objet de test sur l'Origin, et les serveurs Edge d'Akamai essaieront de l'obtenir (appel GET classique). Pour ces requêtes, la vitesse et d'autres métriques sont mesurées, sur la base desquelles le réseau Akamai optimise les routes, afin que le trafic circule plus rapidement pour notre site et il devient évident que l'activation de cette fonctionnalité a réellement un impact significatif sur la vitesse de notre site.
• La versionnage de la configuration dans l'interface web est formidable. Il est possible de faire un Compare pour les versions, de voir un diff. Consulter les versions précédentes.
• Il est possible de déployer une nouvelle version d'abord uniquement sur le réseau Staging d'Akamai — un réseau identique à celui de production, mais ce chemin n'affecte pas les utilisateurs réels. Pour ce test, il faut effectuer un spoofing des enregistrements DNS sur la machine locale.
• Une vitesse de chargement très rapide à travers leur réseau pour de gros fichiers statiques, ainsi que pour tout autre type de fichiers. Un fichier du cache « froid » est récupéré bien plus rapidement qu'un même fichier du cache « froid » d'Ali CDN. Pour le cache « chaud », la vitesse est déjà plus ou moins équivalente.

Test Ali CDN :

root@shenzhen1:~# curl -o /dev/null -w@curl_time https://en.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
  % Total    % Received % Xferd  Vitesse Moyenne   Temps    Temps     Temps  Courant
                                 Dload  Upload   Total   Dépensé    Restant  Vitesse
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  Vitesse Moyenne   Temps    Temps     Temps  Courant
                                 Dload  Upload   Total   Dépensé    Restant  Vitesse
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 de l'exemple ci-dessus dépend de différents facteurs. Au moment de rédiger ce point, j'ai refait le test. Les résultats pour les deux plateformes se sont révélés être à peu près identiques. Cela nous indique que l'internet en Chine, même pour de grands opérateurs et fournisseurs de cloud, se comporte parfois de manière variable.

À l'élément précédent, j'ajouterai un grand avantage d'Akamai : si Ali présente des pics de performances élevées et des temps très bas (cela concerne à la fois Ali CDN, Ali CEN et Ali IPSEC), chez Akamai, peu importe combien de fois j'ai testé leur réseau, tout fonctionne de manière stable.
Akamai a effectivement une large couverture en Chine et collabore avec de nombreux fournisseurs.

Ce qui n'a pas plu :

• Je n'aime pas l'interface web et le schéma de fonctionnement — c'est vraiment basique. Mais dans l'ensemble, on s'y habitue (probablement).
• Les résultats des tests sont pires que ceux de notre plateforme.
• Il y a plus d'erreurs dans les tests que sur notre plateforme (temps de disponibilité inférieur).
• Il n'y a pas de serveurs DNS propres en Chine. Cela entraîne de nombreuses erreurs dans les tests en raison des délais d'expiration de la résolution DNS.
• Ils ne fournissent pas leurs plages d'IP -> impossible d'écrire correctement set_real_ip_from sur nos serveurs.

Métriques (~3626 exécutions; toutes les métriques, sauf le temps de disponibilité, en ms; statistiques pour une période donnée) :

Fournisseur CDN
Médiane
75%
95%
Response
Réponse de la page web
Uptime
DNS
Connecter
Attente
Charge
SSL

Ali CDN
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 percentiles (en ms) :

Percentile
Akamai
Ali CDN

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 avec Akamai est viable, mais elle ne fournit pas les mêmes niveaux de stabilité et de vitesse que notre propre solution en combinaison avec Ali CDN.

Petites notes

Certains points n'ont pas été inclus dans le récit, mais j'aimerais aussi en parler.

Pékin + Tokyo et Hong Kong

Comme je l'ai mentionné plus haut, nous avons testé un tunnel IPSEC vers Hong Kong (HK). Mais nous avons également testé CEN vers HK. Il est légèrement moins cher, et il était intéressant de voir comment il allait fonctionner entre des villes distantes de ~100 km. Il s'avère qu'il y a 100 ms de latence supplémentaire entre ces villes par rapport à notre option initiale (vers Taïwan). La vitesse et la stabilité étaient également meilleures pour Taïwan. Au final, nous avons conservé HK comme région de sauvegarde IPSEC.

De plus, nous avons tenté de mettre en place une telle installation :

• terminaison des clients à Pékin,
• IPSEC et CEN vers Tokyo,
• indiqué comme serveur d'origine dans le CDN Ali à Pékin.

Ce schéma n'était pas aussi stable, bien que la vitesse globale ne soit pas inférieure à notre solution. En ce qui concerne le tunnel, j'ai remarqué des baisses périodiques même pour CEN, qui était censé être stable. Nous sommes donc revenus à l'ancien schéma et avons abandonné cette mise en scène.

Vous trouverez ci-dessous des statistiques sur la latence entre différentes régions par différents canaux. Cela peut intéresser certains.

IPsec
Ali cn-beijing GCP asia-northeast1 — 193ms
Ali cn-shenzhen GCP asia-east2 — 91ms
Ali cn-shenzhen GCP us-east4 — 200ms

CEN
Ali cn-beijing Ali ap-northeast-1 — 54ms (!)
Ali cn-shenzhen Ali cn-hongkong — 6ms (!)
Ali cn-shenzhen Ali us-east1 — 216ms

Informations générales sur Internet en Chine

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

• Internet en Chine fonctionne assez rapidement à l'intérieur.
  • Cette conclusion est basée sur des tests réalisés sur des réseaux Wi-Fi publics dans divers endroits où ces réseaux sont utilisés par un grand nombre de personnes.
  • La vitesse de téléchargement et de téléversement vers les serveurs à l'intérieur de la Chine était d'environ 20 Mbit/s et 5-10 Mbit/s respectivement.
  • La vitesse vers des serveurs en dehors de la Chine est simplement dérisoire, inférieure à 1 Mbit/s.
• Internet en Chine n'est pas très stable.
  • Parfois, les sites peuvent se charger rapidement, parfois lentement (à la même heure de la journée, mais différents jours), à condition que la configuration ne change pas. Nous l'avons observé avec semrushchina.cn. Cela peut être attribué à Ali CDN, qui fonctionne également de manière variable selon l'heure de la journée, la position des étoiles, etc.
• Internet mobile est pratiquement partout en 4G ou 4G+. On capte dans le métro, les ascenseurs — en gros, partout.
• L'idée que les utilisateurs chinois ne font confiance qu'aux domaines en .cn est un mythe. Nous l'avons vérifié directement auprès des utilisateurs.
  • On peut voir comment http://baidu.cn redirige vers www.baidu.com (également en Chine continentale).
• De nombreuses ressources sont effectivement bloquées. Par exemple : google.com, Facebook, Twitter. Mais beaucoup de ressources de Google fonctionnent (bien sûr, ce n'est pas sur tous les Wi-Fi et le VPN n'est pas utilisé (côté routeur aussi, c'est certain).
• De nombreux domaines "techniques" des entreprises bloquées fonctionnent également. Cela signifie qu'il ne faut pas toujours éliminer toutes les ressources Google et autres qui semblent bloquées sans discernement. Il faut rechercher une liste de domaines interdits.
• Ils n'ont que trois principaux opérateurs Internet : China Unicom, China Telecom, China Mobile. Il y en a d'autres plus petits, mais leur part de marché est insignifiante.

Bonus : le schéma final de la solution

Conclusion

Il y a un an, nous avons lancé le projet. Nous avons commencé par le fait que notre site refusait complètement de fonctionner correctement depuis la Chine, et une simple requête GET avec curl prenait 5,5 secondes.

Ensuite, avec ces chiffres lors de la première solution (Cloudflare) :

Solution
Uptime
Médiane
75e percentile
95e percentile

Cloudflare
86.6
18s
30s
60s

Nous avons finalement obtenu ces résultats (statistiques du dernier mois) :

Solution
Uptime
Médiane
75e percentile
95e percentile

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

Comme on peut le voir, atteindre un uptime de 100 % n'a pas encore été possible, mais nous allons trouver une solution, et nous vous informerons des résultats dans un nouvel article :)

Respect à ceux qui ont lu les trois parties jusqu'à la fin. J'espère que tout cela vous a intéressé autant que moi lorsque je l'ai écrit.

P.S. Parties précédentes

Partie 1
Partie 2

Source : habr.com