🥇Wie wir die Große Chinesische Firewall durchbrachen (Teil 3)

Hallo!
Alle guten Geschichten haben ein Ende. Und unsere Geschichte, wie wir eine Lösung für den schnellen Durchgang durch die Chinesische Firewall entwickelt haben, bildet da keine Ausnahme. Daher möchte ich mit Ihnen den letzten Teil teilen, den abschließenden Teil zu diesem Thema informieren.

Im vorherigen Teil haben wir viele von uns entwickelte Testumgebungen vorgestellt und welche Ergebnisse sie geliefert haben. Wir sind bei dem Punkt angekommen, dass es sinnvoll wäre, ein CDN! in unser Schema einzufügen.

Ich werde Ihnen erzählen, wie wir Alibaba Cloud CDN, Tencent Cloud CDN und Akamai getestet haben und wofür wir uns letztendlich entschieden haben. Natürlich werden wir auch eine Zusammenfassung ziehen.

Alibaba Cloud CDN

Wir hosten bei Alibaba Cloud, verwenden IPSEC und CEN von ihnen. Es liegt nahe, zunächst ihre Lösungen auszuprobieren.

Alibaba Cloud bietet uns zwei Arten von Produkten, die für uns geeignet sein könnten: (CDN und DCDN. Die erste Option ist ein klassisches CDN für eine bestimmte Domain (Subdomain). Die zweite Option steht für Dynamic Route for CDN (ich nenne es dynamisches CDN), es kann im Full-Site-Modus (für Wildcard-Domains) aktiviert werden, es cachet auch statische Inhalte und beschleunigt dynamische Inhalte, das heißt, die Dynamik der Seite wird auch über die schnellen Netzwerke des Anbieters geladen. Das ist für uns wichtig, da unsere Website größtenteils dynamisch ist und zahlreiche Subdomains verwendet werden. Es ist einfacher, das CDN einmal für das „Sternchen“ – *.semrushchina.cn – einzustellen.

Wir haben dieses Produkt bereits in früheren Phasen unseres Projekts in China gesehen, aber damals funktionierte es noch nicht, und die Entwickler versicherten, dass das Produkt bald für alle Kunden verfügbar sein würde. Und es ist jetzt verfügbar.

Im DCDN kann man:

SSL-Terminierung mit seinem eigenen Zertifikat einrichten,
die Beschleunigung dynamischer Inhalte aktivieren,
das Caching statischer Dateien flexibel anpassen,
Cache-Purging durchführen,
WebSockets weiterleiten,
Kompression aktivieren und sogar HTML Beautifier nutzen.

Insgesamt alles wie bei großen und etablierten CDN-Anbietern.

Nachdem der Origin (der Ort, an den die CDN-Edge-Server senden) angegeben ist, bleibt nur noch, ein CNAME für das Sternchen zu erstellen, das verweist auf all.semrushchina.cn.w.kunluncan.com (dieser CNAME wurde in der Alibaba Cloud-Konsole erhalten), und das CDN wird funktionieren.

Die Testergebnisse zeigen, dass dieses CDN uns sehr geholfen hat. Die Statistiken finden Sie unten.

Lösung
Verfügbarkeit
Median
75. Perzentil
95. Perzentil

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

Das sind sehr gute Ergebnisse, vor allem im Vergleich zu den Werten zu Beginn. Wir wussten jedoch, dass der Browser-Test der amerikanischen Version unserer Website www.semrush.com im Durchschnitt 8,3s aus den USA benötigt (ein sehr angenäherter Wert). Da ist noch Luft nach oben. Außerdem gab es noch andere CDN-Anbieter, die wir gerne testen wollten.

So kommen wir sanft zu einem weiteren Giganten auf dem chinesischen Markt — Tencent.

Tencent Cloud

Tencent entwickelt sein Cloud-Angebot erst, was man an der geringen Anzahl an Produkten sieht. Bei der Nutzung wollten wir nicht nur ihr CDN testen, sondern auch die gesamte Netzwerk-Infrastruktur:

Haben sie etwas Vergleichbares wie CEN?
Wie funktioniert bei ihnen IPSEC? Ist es schnell, welche Verfügbarkeit haben sie?
Haben sie Anycast?

Lassen Sie uns diese Fragen einzeln betrachten.

CEN-Äquivalent

Tencent hat ein Produkt Cloud Connect Network (CCN), die es ermöglicht, VPCs zwischen verschiedenen Regionen zu verbinden, einschließlich Regionen innerhalb und außerhalb Chinas. Das Produkt befindet sich derzeit in der internen Beta-Phase, und es muss ein Ticket erstellt werden, um einen Zugang anzufordern. Unser Support hat uns mitgeteilt, dass globalen Konten (nicht für Bürger Chinas und keine juristischen Personen) die Teilnahme am Beta-Testprogramm und die Verbindung eines Bereichs innerhalb Chinas mit einem Bereich außerhalb nicht gestattet ist. 1-0 für Ali Cloud

IPSEC

Die südlichste Region von Tencent — Guangzhou. Wir haben einen Tunnel aufgebaut und ihn mit der Region Hongkong in GCP verbunden (dieser Bereich war dann bereits verfügbar). Gleichzeitig haben wir einen zweiten Tunnel in Ali Cloud von Shenzhen nach Hongkong errichtet. Es stellte sich heraus, dass die Latenz über das Netzwerk von Tencent nach Hongkong insgesamt besser war (10 ms) als von Shenzhen nach Hongkong in Ali (120 ms — was?). Aber das hat die Funktionalität der Website, die über Tencent und diesen Tunnel betrieben wird, nicht beschleunigt, was selbst ein erstaunlicher Fakt war und erneut bewies: Latenz ist für China kein Kriterium, auf das man während der Entwicklung einer Lösung zur Umgehung der chinesischen Firewall wirklich achten sollte.

Anycast Internet-Beschleunigung

Ein weiteres Produkt, das die Arbeit über Anycast-IP ermöglicht — AIA. Er ist jedoch für globale Konten nicht verfügbar, daher kann ich nicht mehr darüber sagen, aber es kann nützlich sein, zu wissen, dass es dieses Produkt gibt.

Der CDN-Test hat jedoch einige interessante Ergebnisse gezeigt. Das CDN von Tencent kann nicht für die gesamte Website aktiviert werden, sondern nur für spezifische Domains. Wir haben Domänen eingerichtet und Traffic darauf geleitet:

Es stellte sich heraus, dass dieser CDN folgende Funktion hat: Cross Border Traffic Optimization. Diese Funktion soll die Kosten beim Durchlauf des Traffics durch die chinesische Firewall senken. Als Ursprung wurde die IP-Adresse des Google GLB (GLB Anycast) angegeben. Damit wollten wir die Architektur des Projekts vereinfachen.

Die Ergebnisse waren sehr gut - auf dem Niveau von Ali Cloud CDN, teilweise sogar besser. Das ist erstaunlich, denn im Erfolgsfall der Tests könnte man auf einen erheblichen Teil der Infrastruktur, Tunnel, CEN, VMs usw. verzichten.

Die Freude währte nicht lange, da sich ein Problem zeigte: die Tests in Catchpoint hatten bei dem Internetanbieter China Mobile Fehler. Aus allen Standorten erhielten wir einen Timeout über das CDN von Tencent. Der Schriftverkehr mit dem technischen Support brachte nichts. Wir haben rund einen Tag versucht, dieses Problem zu lösen, aber es gelang uns nicht.

Ich war zu diesem Zeitpunkt in China, konnte aber kein öffentliches WLAN des Anbieters finden, um das Problem persönlich zu überprüfen. Ansonsten schien alles schnell und gut zu laufen.
Da China Mobile jedoch zu den drei größten Betreibern gehört, waren wir gezwungen, den Datenverkehr auf Ali CDN umzuleiten.
Insgesamt war es jedoch eine recht interessante Lösung, die eine längere Testphase und Fehlersuche verdient.

Akamai

Der letzte CDN-Anbieter, den wir getestet haben, ist Akamai. Es handelt sich um einen großen Anbieter, der ein Netzwerk in China hat. Natürlich konnten wir an ihm nicht vorbeigehen.

Von Anfang an haben wir mit Akamai einen Testzeitraum vereinbart, damit wir die Domain umschalten und sehen können, wie sie in ihrem Netzwerk funktioniert. Ich werde die Ergebnisse aller Tests in Form von "Was mir gefallen hat" und "Was mir nicht gefallen hat" sowie die Testergebnisse darstellen.

Was mir gefallen hat:

Die Leute von Akamai waren bei allen Fragen sehr hilfsbereit und begleiteten uns in allen Phasen der Tests. Sie haben ständig versucht, etwas auf ihrer Seite zu verbessern. Sie gaben auch gute technische Ratschläge.
Akamai benötigt etwa 10-15% mehr Zeit als unsere Lösung über Ali Cloud CDN. Bemerkenswert ist, dass wir für Akamai die IP-Adresse von GLB als Ursprung angegeben haben, sodass der Datenverkehr nicht über unsere Lösung lief (man könnte potenziell auf einen Teil der Infrastruktur verzichten). Dennoch haben die Testergebnisse gezeigt, dass diese Lösung schlechter abschneidet als unsere aktuelle Option (die vergleichenden Ergebnisse finden Sie unten).
Sowohl Origin GLB als auch der Ursprung in China wurden getestet. Beide Optionen sind ungefähr gleich.
Es gibt Sure Route (automatische Routenoptimierung). Sie können ein Testobjekt am Ursprung platzieren, und die Edge-Server von Akamai werden versuchen, es abzurufen (gewöhnliches GET). Für diese Anfragen werden Geschwindigkeit und andere Metriken gemessen, auf deren Grundlage das Akamai-Netzwerk die Routen optimiert, damit der Datenverkehr schneller zu unserer Website fließt und es offensichtlich wird, dass die Aktivierung dieser Funktion tatsächlich erheblichen Einfluss auf die Geschwindigkeit der Website hatte.
Die Versionskontrolle der Konfiguration im Webinterface ist großartig. Es kann ein Vergleich der Versionen erstellt werden, um die Unterschiede zu sehen. Frühere Versionen können ebenfalls angezeigt werden.
Die neue Version kann zunächst nur im Staging-Netzwerk von Akamai veröffentlicht werden – es handelt sich um dasselbe Netzwerk wie das Produktionsnetzwerk, jedoch beeinträchtigt dieser Weg keine realen Benutzer. Für diesen Test muss eine DNS-Aufzeichnung auf dem lokalen Rechner gefälscht werden.
Die Ladegeschwindigkeit über ihr großes statisches Netzwerk ist sehr hoch, anscheinend auch für alle anderen Dateitypen. Eine Datei aus dem „kalten“ Cache wird deutlich schneller abgerufen als dieselbe Datei aus dem „kalten“ Cache von Ali CDN. Bei „heißen“ Caches ist die Geschwindigkeit bereits ungefähr gleich.

Ali CDN Test:

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

Akamai Test:

root@shenzhen1:~# curl -o /dev/null -w@curl_time https://www.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
  % Gesamt    % Empfangen % Übertragen  Durchschnittsgeschwindigkeit   Zeit    Zeit     Zeit  Aktuell
                                 Herunterladen  Hochladen   Gesamt   Verbraucht    Rest  Geschwindigkeit
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
----------
größe_download:  5895467 Bytes
geschwindigkeit_download:  1868699.000B/s

Wir haben festgestellt, dass das Beispiel aus oben genannten Gründen von verschiedenen Faktoren beeinflusst wird. Zum Zeitpunkt der Erstellung dieses Punktes habe ich den Test noch einmal durchgeführt. Die Ergebnisse für beide Plattformen waren etwa gleich. Das zeigt uns, dass das Internet in China, selbst für große Betreiber und Cloud-Anbieter, gelegentlich unterschiedlich funktioniert.

Zu dem vorherigen Punkt möchte ich einen großen Vorteil von Akamai hinzufügen: Wenn bei Ali ähnliche Sprünge in der Leistungsfähigkeit und sehr niedrige Werte sichtbar sind (das betrifft sowohl Ali CDN, Ali CEN als auch Ali IPSEC), dann funktioniert bei Akamai jedes Mal, egal wie oft ich ihr Netzwerk teste, alles stabil.
Akamai hat tatsächlich eine große Abdeckung in China und arbeitet mit vielen Anbietern zusammen.

Was nicht gefallen hat:

Das Web-Interface und das Arbeitschema gefallen mir nicht – solche Nullnummern. Aber im Prinzip gewöhnt man sich daran (wahrscheinlich).
Die Testergebnisse sind schlechter als bei unserem Service.
Es gab mehr Fehler bei den Tests als bei unserem Service (Uptime niedriger).
Es gibt keine eigenen DNS-Server in China. Das führt zu vielen Testfehlern aufgrund von DNS-Auflösungszeitüberschreitungen.
Sie stellen keine eigenen IP-Bereiche zur Verfügung -> keine Möglichkeit, korrekte Angaben zu machen. set_real_ip_from auf unseren Servern.

Metriken (~3626 Durchläufe; alle Metriken außer Uptime in ms; Statistik für einen Zeitraum):

CDN-Anbieter
Median
75%
95%
Response
Webseitenantwort
Verfügbarkeit
DNS
Connect
Warten
Load
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

Verteilung nach Perzentil (in ms):

Perzentil
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

Die Schlussfolgerung ist folgende: Die Option mit Akamai ist tragfähig, bietet jedoch nicht die gleiche Stabilität und Geschwindigkeit wie unsere eigene Lösung in Kombination mit Ali CDN.

Kleine Anmerkungen

Einige Punkte wurden nicht in die Erzählung aufgenommen, aber ich wollte auch darüber schreiben.

Peking + Tokio und Hongkong

Wie bereits erwähnt, haben wir einen IPSEC-Tunnel nach Hongkong (HK) getestet. Aber wir haben auch das CEN nach HK getestet. Es ist etwas günstiger, und es war interessant zu sehen, wie es zwischen Städten mit einer Entfernung von etwa 100 km funktioniert. Interessanterweise war die Latenz zwischen diesen Städten um 100 ms höher als bei unserer ursprünglichen Variante (nach Taiwan). Die Geschwindigkeit und Stabilität waren ebenfalls besser für Taiwan. Letztendlich haben wir HK als Backup-IPSEC-Region belassen.

Darüber hinaus haben wir versucht, eine solche Installation aufzubauen:

Kunden-Terminierung in Peking,
IPSEC und CEN bis Tokio,
Ali CDN wurde in Peking als Origin-Server angegeben.

Dieses Setup war nicht so stabil, obwohl die Geschwindigkeit insgesamt nicht hinter unserer Lösung zurückblieb. Was den Tunnel betrifft, habe ich gelegentliche Ausfälle selbst für CEN gesehen, der stabil sein sollte. Daher sind wir zu der alten Lösung zurückgekehrt und haben dieses Staging abgebaut.

Unten sind die Latency-Statistiken zwischen verschiedenen Regionen über verschiedene Kanäle aufgeführt. Vielleicht interessiert es jemanden.

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

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

Allgemeine Informationen über das Internet in China

Als Ergänzung zu den zu Beginn beschriebenen Internetproblemen in Teil eins des Artikels.

Das Internet in China funktioniert innerhalb des Landes ziemlich schnell.
- Die Schlussfolgerung basiert auf Tests öffentlicher Wi-Fi-Netzwerke an verschiedenen Standorten, wo diese Netzwerke von vielen Personen genutzt werden.
- Die Download- und Uploadgeschwindigkeit auf Server in China betrug etwa 20 Mbit/s und 5-10 Mbit/s.
- Die Geschwindigkeit zu Servern außerhalb Chinas ist einfach miserabel, weniger als 1 Mbit/s.
Das Internet in China ist nicht sehr stabil.
- Manchmal können Webseiten schnell geladen werden, manchmal langsam (zu unterschiedlichen Zeiten am Tag an verschiedenen Tagen), vorausgesetzt, die Konfiguration ändert sich nicht. Wir haben dies am Beispiel von semrushchina.cn beobachtet. Dies könnte dem Ali CDN zugeschrieben werden, das ebenfalls je nach Tageszeit und anderen Faktoren unterschiedlich funktioniert.
Mobile Internetverbindungen sind nahezu überall 4G oder 4G+. Es funktioniert in U-Bahnen, Aufzügen — kurz gesagt, überall.
Dass chinesische Nutzer nur Domains mit der Endung .cn vertrauen, ist ein Mythos. Wir haben dies direkt von Nutzern erfahren.
- Man kann sehen, wie http://baidu.cn es auf www.baidu.com umleitet (auch im Festlandchina).
Viele Ressourcen sind tatsächlich blockiert. Primär: google.com, Facebook, Twitter. Aber viele Google-Ressourcen funktionieren (natürlich, nicht in allen Wi-Fi-Netzwerken und VPN wird dabei nicht verwendet (auch nicht auf der Router-Seite, das ist sicher).
Viele "technische" Domains blockierter Unternehmen funktionieren ebenfalls. Das bedeutet, dass man nicht immer alles überstürzt entfernen sollte, was wie ein blockierter Google- oder anderer Dienst erscheint. Man sollte nach einer Liste der verbotenen Domains suchen.
Es gibt nur drei Haupt-Internetanbieter: China Unicom, China Telecom und China Mobile. Es gibt noch kleinere Anbieter, aber deren Marktanteil ist unbedeutend.

Bonus: Die endgültige Lösungsschema

Zusammenfassung

Ein Jahr ist seit Projektstart vergangen. Wir begannen damit, dass unsere Website aus China überhaupt nicht richtig funktionierte, und ein einfacher GET-Befehl mit cURL benötigte 5,5 Sekunden.

Später waren wir bei diesen Werten beim ersten Lösungsansatz (Cloudflare):

Lösung
Verfügbarkeit
Median
75. Perzentil
95. Perzentil

Cloudflare
86.6
18s
30s
60s

Am Ende erzielten wir folgende Ergebnisse (Statistik für den letzten Monat):

Lösung
Verfügbarkeit
Median
75. Perzentil
95. Perzentil

Ali CDN + CEN/IPsec + GLB
99.86
8,8s
9,5s
13,7s

Wie man sieht, haben wir es bisher nicht geschafft, 100% Uptime zu erreichen, aber wir werden eine Lösung finden und dann in einem neuen Artikel über die Ergebnisse berichten :)

Respekt an alle, die bis zum Ende alle drei Teile gelesen haben. Ich hoffe, es war für euch ebenso interessant wie für mich, als ich daran gearbeitet habe.