🥇Wie wir die große chinesische Firewall durchbrochen haben (Teil 3)

Hallo!
Alle guten Geschichten haben ein Ende. Und unsere Geschichte darüber, wie wir eine Lösung zum schnellen Durchbrechen der chinesischen Firewall erfunden haben, ist da keine Ausnahme. Daher beeile ich mich, Ihnen den letzten Teil zu präsentieren, den abschließenden Teil zu diesem Thema.

Im vorherigen Teil haben wir über zahlreiche Testumgebungen gesprochen, die wir entwickelt haben, und welche Ergebnisse sie geliefert haben. Und wir sind zu dem Schluss gekommen, dass es sinnvoll wäre, ein CDN! für die Kohäsion 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. Und natürlich ziehen wir ein Fazit.

Alibaba Cloud CDN

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

Alibaba Cloud bietet uns zwei Produkttypen, die 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 cached auch Statisches und beschleunigt Dynamischen Inhalt, das heißt, die dynamische Seite wird ebenfalls über die schnellen Netze des Anbieters geladen. Das ist für uns wichtig, da unsere Website hauptsächlich dynamisch ist, viele Subdomains verwendet werden und es einfacher ist, das CDN einmal für „Sternchen“ – *.semrushchina.cn – einzurichten.

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

Mit DCDN kann man:

SSL-Terminierung mit eigenem Zertifikat einrichten,
die Beschleunigung von dynamischen Inhalten aktivieren,
die Cache-Einstellungen für statische Dateien flexibel anpassen,
Cache-Purges durchführen,
WebSockets durchleiten,
Kompression aktivieren und sogar einen HTML Beautifier nutzen.

Im Allgemeinen alles wie bei großen, professionellen CDN-Anbietern.

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

Nach den Testergebnissen hat uns dieses CDN sehr geholfen. Die Statistiken sind unten aufgeführt.

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, insbesondere wenn man sie mit den Zahlen zu Beginn vergleicht. Aber wir wussten, dass der Browser-Test der amerikanischen Version unserer Webseite www.semrush.com im Durchschnitt aus den USA mit etwa 8,3 Sekunden läuft (ein sehr angenäherter Wert). Da gibt es noch Verbesserungspotenzial. Außerdem gab es noch CDN-Anbieter, die wir interessant fanden, um sie zu testen.

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

Tencent Cloud

Tencent entwickelt seine Cloud gerade erst — das sieht man an der geringen Anzahl an Produkten. Während unserer Nutzung wollten wir nicht nur ihr CDN testen, sondern auch die Netzwerkinfrastruktur insgesamt:

Haben sie etwas Ähnliches wie CEN?
Wie funktioniert bei ihnen IPSEC? Ist es schnell, wie sieht es mit der Betriebszeit aus?
Haben sie Anycast?

Wir werden diese Fragen einzeln behandeln.

Äquivalent zu CEN

Tencent hat ein Produkt Cloud Connect Network (CCN), das es ermöglicht, VPCs aus verschiedenen Regionen zu verbinden, einschließlich Regionen innerhalb und außerhalb Chinas. Das Produkt ist derzeit in einer internen Beta, und man muss ein Ticket zur Anmeldung anlegen. Vom Support erfuhren wir, dass globale Konten (keine Bürger Chinas und keine juristischen Personen) an dem Beta-Testprogramm nicht teilnehmen dürfen und generell keine Region innerhalb Chinas mit einer Region außerhalb verbinden können. 1-0 für Ali Cloud.

IPSEC

Die südlichste Region von Tencent — Guangzhou. Wir haben ein Tunnel aufgebaut und mit der Region Hongkong in GCP verbunden (zu diesem Zeitpunkt war diese Region bereits verfügbar). Gleichzeitig haben wir einen zweiten Tunnel in Ali Cloud von Shenzhen nach Hongkong eingerichtet. Es stellte sich heraus, dass die Latenz über das Tencent-Netzwerk insgesamt besser ist (10 ms) als von Shenzhen nach Hongkong in Ali (120 ms — was?). Aber das hat die Funktionalität der Webseite, die durch Tencent über diesen Tunnel läuft, in keiner Weise beschleunigt, was an sich schon eine erstaunliche Tatsache war und erneut bewies: Latenz ist für China kein Faktor, auf den man wirklich achten sollte, bei der Entwicklung einer Lösung zur Umgehung der chinesischen Firewall.

Anycast Internet Acceleration

Ein weiteres Produkt, das es ermöglicht, über Anycast IP zu arbeiten — AIA. Aber es steht auch globalen Konten nicht zur Verfügung, daher werde ich nicht darüber berichten, aber die Kenntnis, dass ein solches Produkt existiert, kann nützlich sein.

Der CDN-Test zeigte jedoch ziemlich interessante Ergebnisse. Das CDN von Tencent kann nicht für die gesamte Webseite aktiviert werden, nur für bestimmte Domains. Wir haben Domains eingerichtet und Traffic darauf geleitet:

Es stellte sich heraus, dass dieses CDN eine solche Funktion hat: Optimierung des grenzüberschreitenden Verkehrs. Diese Funktion soll die Kosten für die Durchleitung des Verkehrs durch die chinesische Firewall senken. Als Origin wurde die IP-Adresse des Google GLB (GLB Anycast) angegeben. Dadurch wollten wir die Architektur des Projekts vereinfachen.

Die Ergebnisse waren sehr gut - auf dem Niveau von Ali Cloud CDN, und 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.

Wir freuten uns nicht lange, da ein Problem aufgetreten ist: Die Tests in Catchpoint schlugen für den Internetanbieter China Mobile fehl. Aus allen Standorten erhielten wir einen Timeout über das CDN von Tencent. Die Korrespondenz mit dem technischen Support brachte nichts. Etwa einen Tag versuchten wir, dieses Problem zu lösen, aber ohne Erfolg.

Ich befand mich zu diesem Zeitpunkt in China, konnte aber kein öffentliches Wi-Fi im Netzwerk dieses Anbieters finden, um das Problem persönlich zu überprüfen. Ansonsten sah alles schnell und gut aus.
Da der Anbieter China Mobile jedoch zu den drei größten Anbietern gehört, waren wir gezwungen, den Verkehr wieder auf Ali CDN zu lenken.
Insgesamt war dies 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. Dies ist ein großer Anbieter, der ein eigenes Netzwerk in China hat. Natürlich konnten wir ihn nicht ignorieren.

Von Anfang an vereinbarten wir mit Akamai einen Testzeitraum, um die Domain umzuschalten und zu sehen, wie sie in ihrem Netzwerk funktioniert. Die Ergebnisse aller Tests werde ich in den Abschnitten „Was gefiel“ und „Was gefiel nicht“ zusammenfassen und die Testergebnisse präsentieren.

Was gefiel:

Die Leute von Akamai halfen uns in allen Belangen und begleiteten uns in allen Phasen des Tests. Sie versuchten ständig, etwas auf ihrer Seite zu verbessern. Sie gaben gute technische Ratschläge.
Akamai arbeitet etwa 10-15 % langsamer als unsere Lösung über Ali Cloud CDN. Beeindruckend ist, dass wir für Akamai die IP-Adresse des GLB angaben, was bedeutet, dass der Verkehr nicht über unsere Lösung lief (potenziell könnte man auf einen Teil der Infrastruktur verzichten). Dennoch zeigten die Testergebnisse, dass diese Lösung schlechter ist als unsere aktuelle Variante (vergleichende Ergebnisse siehe unten).
Es wurde sowohl als Origin GLB als auch als Origin in China getestet. Beide Optionen sind ungefähr gleich.
Ja Sure Route (automatische Routenoptimierung). Sie können ein Testobjekt bei sich auf Origin platzieren, und die Edge-Server von Akamai werden versuchen, es abzurufen (normales GET). Für diese Anfragen werden Geschwindigkeit und andere Metriken gemessen, auf deren Grundlage das Akamai-Netzwerk die Routen optimiert, damit der Datenverkehr schneller für unsere Website fließt, und es zeigt sich, dass die Aktivierung dieser Funktion wirklich einen starken Einfluss auf die Geschwindigkeit der Website hatte.
Die Versionsverwaltung der Konfiguration im Web-Interface ist großartig. Man kann einen Vergleich der Versionen durchführen, um den Unterschied zu sehen. Frühere Versionen anzeigen.
Neue Versionen können zunächst nur im Staging-Netzwerk von Akamai bereitgestellt werden – dasselbe Netzwerk wie im Produktionsbetrieb, jedoch ohne Auswirkungen auf echte Benutzer. Für diesen Test muss eine Spoofing von DNS-Einträgen auf dem lokalen Computer erfolgen.
Sehr schnelle Ladegeschwindigkeit über ihr Netzwerk großer Statik und offenbar auch für andere Dateien. Eine Datei aus dem „kalten“ Cache wird um ein Vielfaches schneller abgerufen als dieselbe Datei aus dem „kalten“ Cache von Ali CDN. Bei aus dem „heißen“ Cache ist die Geschwindigkeit schon mehr oder weniger 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  Durchschnittsgeschwindigkeit   Zeit    Zeit     Zeit  Aktuell
                                 Dload  Upload   Total   Verbraucht    Übrig  Geschwindigkeit
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
  % Total    % Received % Xferd  Durchschnittsgeschwindigkeit   Zeit    Zeit     Zeit  Aktuell
                                 Dload  Upload   Total   Verbraucht    Übrig  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
----------
size_download:  5895467 Bytes
speed_download:  1868699.000B/s

Wir haben festgestellt, dass die Situation aus dem obigen Beispiel von verschiedenen Faktoren abhängt. Zum Zeitpunkt der Erstellung dieses Punkts habe ich den Test erneut durchgeführt. Die Ergebnisse für beide Plattformen waren ungefähr gleich. Das weist darauf hin, dass das Internet in China selbst für große Betreiber und Cloud-Anbieter von Zeit zu Zeit unterschiedlich reagiert.

Ein großer Vorteil von Akamai, den ich zum vorherigen Punkt hinzufügen möchte: Wenn Ali solche Spitzen in der hohen Leistung und sehr niedrigen Latenz zeigt (das betrifft sowohl Ali CDN, als auch Ali CEN und Ali IPSEC), funktioniert bei Akamai, egal wie oft ich ihr Netzwerk teste, alles stabil.
Akamai hat tatsächlich eine große Abdeckung in China und arbeitet über viele Anbieter.

Was uns nicht gefallen hat:

Der Web-Interface und das Funktionsschema gefallen mir nicht – sie sind ziemlich nutzlos. Aber grundsätzlich gewöhnt man sich wohl daran.
Die Testergebnisse sind schlechter als bei unserem Standort.
Bei den Tests gab es mehr Fehler als an unserem Standort (Uptime ist niedriger).
Es gibt keine eigenen DNS-Server in China. Daher gibt es viele Fehler bei den Tests aufgrund von DNS-Resolve-Timeouts.
Sie stellen keine eigenen IP-Ranges zur Verfügung -> keine Möglichkeit, die korrekten set_real_ip_from auf unseren Servern zu definieren.

Metriken (~3626 Durchläufe; alle Metriken, ausser Uptime, in ms; Statistik für einen bestimmten Zeitraum):

CDN-Anbieter
Median
75%
95%
Response
Webseitenreaktion
Verfügbarkeit
DNS
Connect
Warten
mit dem ausgewählten Testplan
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 Prozentil (in ms):

Prozentil
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

Das Ergebnis ist folgendes: Die Variante mit Akamai ist tragfähig, bietet jedoch nicht die gleiche Stabilitäts- und Geschwindigkeitswerte wie unsere eigene Lösung zusammen mit Ali CDN.

Kleine Anmerkungen

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

Peking + Tokio und Hongkong

Wie ich oben bereits erwähnte, haben wir den IPSEC-Tunnel nach Hongkong (HK) getestet. Aber wir haben auch das CEN nach HK getestet. Es kostet etwas weniger und es war interessant zu sehen, wie es zwischen Städten mit einem Abstand von ~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 war ebenfalls besser für Taiwan. Letztendlich haben wir HK als Backup-IPSEC-Region beibehalten.

Außerdem haben wir versucht, eine solche Installation aufzubauen:

Kundenabschluss in Peking,
IPSEC und CEN nach Tokio,
in Ali CDN wurde als Ursprungsserver in Peking angegeben.

Dieses Schema war nicht so stabil, obwohl es in der Geschwindigkeit insgesamt unserem Lösung nicht nachstand. Was den Tunnel betrifft, habe ich sporadische Ausfälle sogar für das CEN gesehen, das stabil sein sollte. Daher sind wir zu unserem alten Schema zurückgekehrt und haben diese Staging-Umgebung abgebaut.

Nachfolgend sind die Statistiken zur Latenz zwischen verschiedenen Regionen über unterschiedliche Kanäle aufgeführt. Vielleicht ist das für einige interessant.

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

Allgemeine Informationen über das Internet in China

Als Ergänzung zu den anfänglich beschriebenen Internetproblemen in der ersten Artikelhälfte.

Das Internet funktioniert innerhalb Chinas ziemlich schnell.
- Die Schlussfolgerung basiert auf Tests öffentlicher Wi-Fi-Netze an verschiedenen Standorten, an denen diese Netze von einer großen Anzahl von Personen verwendet werden.
- Die Download- und Upload-Geschwindigkeit zu Servern innerhalb Chinas betrug etwa 20 Mbit/s bzw. 5-10 Mbit/s.
- Die Geschwindigkeit zu Servern außerhalb Chinas ist einfach miserabel, unter 1 Mbit/s.
Das Internet in China ist nicht sehr stabil.
- Manchmal können Websites schnell geladen werden, manchmal langsam (zu derselben Tageszeit an verschiedenen Tagen), vorausgesetzt, die Konfiguration ändert sich nicht. Dies haben wir am Beispiel von semrushchina.cn beobachtet. Man kann dies auf Ali CDN zurückführen, das auch je nach Tageszeit, Stellung der Sterne usw. unterschiedlich funktioniert.
Mobilinternet ist fast überall 4G oder 4G+. Es funktioniert in U-Bahnen, Aufzügen – kurz gesagt, überall.
Die Vorstellung, dass chinesische Nutzer nur Domains in der Zone .cn vertrauen, ist ein Mythos. Wir haben das direkt bei den Nutzern erfragt.
- Man kann sehen, wie http://baidu.cn auf www.baidu.com umleitet (auch im chinesischen Festland).
Viele Ressourcen sind tatsächlich blockiert. Grob gesagt: google.com, Facebook, Twitter. Aber viele Google-Ressourcen funktionieren (natürlich nicht auf allen Wi-Fi-Netzen und VPN wird dabei nicht verwendet (auch nicht auf Router-Seite, das ist sicher).
Viele "technische" Domains blockierter Unternehmen funktionieren ebenfalls. Das bedeutet, dass man nicht immer leichtfertig alle scheinbar blockierten Google- und andere Ressourcen löschen sollte. Man sollte nach einer Liste verbotener Domains suchen.
Es gibt nur drei große Internetanbieter: China Unicom, China Telecom, China Mobile. Es gibt noch kleinere Anbieter, aber deren Marktanteil ist unbedeutend.

Bonus: Die endgültige Lösungsskizze

Fazit

Ein Jahr seit dem Start des Projekts ist vergangen. Wir begannen damit, dass unsere Website überhaupt nicht normal aus China funktionierte, und ein einfacher GET curl benötigte 5,5 Sekunden.

Dann, mit solchen Werten bei der ersten Lösung (Cloudflare):

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

Cloudflare
86.6
18s
30s
60s

Wir haben letztendlich solche Ergebnisse erzielt (Statistik für den letzten Monat):

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

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

Wie zu sehen ist, haben wir bisher keinen 100%-Uptime erreicht, aber wir werden etwas ausdenken und später in einem neuen Artikel über die Ergebnisse berichten :)

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