Hallo zusammen!
Hier ist Nikita – Systemingenieur bei SEMrush. Heute möchte ich Ihnen erzählen, wie wir die Herausforderung meistern mussten, die Stabilität unseres Dienstes semrush.com in China sicherzustellen und mit welchen Problemen wir während dieser Aufgabe konfrontiert wurden (unter Berücksichtigung des Standorts unseres Rechenzentrums an der Ostküste der USA).
Dies wird eine umfangreiche Geschichte, die in mehrere Artikel unterteilt ist. Ich werde Ihnen berichten, wie es bei uns war: vom völlig nicht funktionierenden Dienst in China bis hin zu den Leistungszahlen des Dienstes auf dem Niveau der amerikanischen Version für amerikanische Nutzer. Ich verspreche, es wird interessant und nützlich sein. Also, los geht's.
Probleme mit dem chinesischen Internet
Selbst die entferntesten Personen von der Welt der Netzadministration haben zumindest einmal von der Großen Firewall Chinas gehört.. Uuu, klingt cool, nicht wahr? Aber was ist das genau, und wie funktioniert es eigentlich – das ist eine ziemlich komplexe Frage. Im Internet findet man viele Artikel darüber, aber aus technischer Sicht ist die Funktionsweise dieser Firewall nirgends beschrieben. Was jedoch nicht verwunderlich ist. Ich gebe zu, dass ich nach einem Jahr der Nutzung nicht genau sagen kann, wie sie funktioniert, aber ich kann meine Beobachtungen und praktischen Schlussfolgerungen teilen. Lassen Sie uns mit den Gerüchten über diese Firewall beginnen.
Es gibt viele Gerüchte über diese spezielle Firewall. Lassen Sie uns die wichtigsten und interessantesten in einer Liste zusammenfassen:
- Google, Facebook, Twitter und ähnliche Dienste sind in China blockiert und funktionieren dort nicht.
- Jeder Verkehr, der AUS China und IN China verläuft, wird mit Hilfe von maschinellem Lernen verarbeitet und eingeschränkt (bei verdächtigem Verkehr), was diesen Verkehr, der die Grenze überschreitet, stark verlangsamt.
- Chinesische Geheimdienste knacken jeden verschlüsselten Verkehr, der durch ihre Firewall läuft.
- VPN-Tunnel und IPSEC-Tunnel sind instabil, brechen ab und werden ständig blockiert.
- Je einfacher die Verschlüsselung und das verwendete Passwort für die Authentifizierung/den verschlüsselten Datenverkehr sind, desto schneller passiert er die chinesische Firewall.
Hier ist, was wir über diese Gerüchte herausfinden konnten:
- Google, Facebook, Twitter und ähnliche Dienste sind tatsächlich blockiert (Ihr K.O.), aber viele technische Domains von Google sind beispielsweise nicht gesperrt und funktionieren (wie gstatic.com). Daraus folgt, dass man nicht vorschnell sämtliche Google- und andere vermeintlich blockierte Ressourcen abschalten sollte.
- Jeder Datenverkehr, der die Grenze überquert, verursacht tatsächlich beträchtliche Verzögerungen. Schauen Sie sich zwei Ergebnisse an. Eine Website, eine Seite, einfacher GET curl‘. Die erste Messung aus China (wunderschöne Stadt Shenzhen). Die zweite Messung von außen aus Hongkong (hat Souveränität und zwischen ihm und der Welt gibt es keine Firewall). Die Entfernung zwischen den Städten beträgt gerademal 30-40 km.
nikita@china-shenzhen:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
% Total % Received % Xferd Durchschnittsgeschwindigkeit Zeit Zeit Zeit Aktuell
Dload Hochladen Gesamt Verbraucht Übrig Geschwindigkeit
100 381k 0 381k 0 0 71824 0 --:--:-- 0:00:05 --:--:-- 82832
time_namelookup: 0.004500
time_connect: 0.169342
time_appconnect: 0.723189
time_pretransfer: 0.723499
time_redirect: 0.000000
time_starttransfer: 1.532912
----------
time_total: 5.443407
----------
size_download: 390968 Bytes
speed_download: 71824.000B/s
nikita@china-hongkong:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
% Total % Received % Xferd Durchschnittsgeschwindigkeit Zeit Zeit Zeit Aktuell
Dload Hochladen Gesamt Verbraucht Übrig Geschwindigkeit
100 319k 0 319k 0 0 2555k 0 --:--:-- --:--:-- --:--:-- 2573k
time_namelookup: 0.029366
time_connect: 0.030742
time_appconnect: 0.047310
time_pretransfer: 0.047388
time_redirect: 0.000000
time_starttransfer: 0.120793
----------
time_total: 0.124871
----------
size_download: 326755 Bytes
speed_download: 2616740.000B/sBitte beachten Sie time_connect. Insgesamt sehen Sie das Ergebnis: Die Firewall fügt 4 zusätzliche Sekunden hinzu, was extrem lange ist.
- VPN und IPSEC-Tunnel fallen tatsächlich häufig aus. Dazu werde ich später und genauer berichten. Die von den Nutzern verwendeten VPN-Server werden im Laufe der Zeit blockiert (in der Regel innerhalb eines Tages nach Beginn der Nutzung).
- Es gibt die Meinung, dass aus China lebende Menschen berichten, je einfacher die Verschlüsselung des Traffics ist, desto schneller passiert er die Grenze, da es leicht verständlich ist, dass darin nichts Illegales enthalten ist. Ebenso erhält „sauberer“ Traffic mehr Bandbreite und Geschwindigkeit, während „schmutziger“ Traffic, der undurchsichtig ist, langsamer verläuft. Zum Beispiel zeige ich curl zu ifconfig.co über die Protokolle HTTPS und HTTP.
curl -o /dev/null -w@curl_time "https://ifconfig.co/"
% Total % Received % Xferd Durchschnittsgeschwindigkeit Zeit Zeit Zeit Aktuell
Dload Upload Total Verbraucht Übrig Geschwindigkeit
100 13 100 13 0 0 2 0 0:00:06 0:00:05 0:00:01 3
time_namelookup: 0.004305
time_connect: 0.397465
time_appconnect: 5.149305
time_pretransfer: 5.149393
time_redirect: 0.000000
time_starttransfer: 5.568847
----------
time_total: 5.568893
----------
size_download: 13 Bytes
speed_download: 2.000B/s
curl -o /dev/null -w@curl_time "http://ifconfig.co/"
% Total % Received % Xferd Durchschnittsgeschwindigkeit Zeit Zeit Zeit Aktuell
Dload Upload Total Verbraucht Übrig Geschwindigkeit
100 13 100 13 0 0 28 0 --:--:-- --:--:-- --:--:-- 28
time_namelookup: 0.004282
time_connect: 0.212457
time_appconnect: 0.000000
time_pretransfer: 0.212484
time_redirect: 0.000000
time_starttransfer: 0.450565
----------
time_total: 0.450620
----------
size_download: 13 Bytes
speed_download: 28.000B/sDer Unterschied von 5 Sekunden bei der Gesamtladezeit von 13 Byte. Dabei kann man bei mehreren Tests feststellen, dass die GET-Anfrage über HTTP in der Regel zu einer konstanten Zeit abgeschlossen wird, während die Antwort über HTTPS manchmal 3, 5, 10 und sogar 17 Sekunden dauert. Gelegentlich treten SSL-Fehler auf:
Unbekannter SSL-Protokollfehler bei der Verbindung zu ifconfig.co:443.
Also, was haben wir:
- Die oben beschriebenen Probleme, die durch die chinesische Firewall verursacht werden.
- Pings zu externen Ressourcen und innerhalb der Tunnel fallen zeitweise aus.
- Die Latenz zwischen zwei Punkten ändert sich ständig und ist oft einfach unvorhersehbar. Wenn man verschiedene Städte/Regionen verbindet, erwartet man, dass die Latenz aufgrund der geografischen Lage geringer ist, und erhält genau das Gegenteil.
- Das Internet und die Kommunikationskanäle funktionieren mal schnell, mal langsam. Es gibt eine geringe Abhängigkeit von der Tageszeit und dem Wochentag, aber nicht immer.
- DNS-Anfragen aus China ins Ausland überschreiten manchmal den zulässigen Timeout.
Das Bild ergibt sich einfach als "hervorragend".
Wie bereits erwähnt, befindet sich unser Rechenzentrum im Osten der USA, und SEMrush besteht aus Dutzenden miteinander verbundener Produkte, Backends, Frontends und Datenbanken, alles in Rechenzentren und in der Cloud. Unser Team von Systemadministratoren hatte die Aufgabe, mit minimalem Aufwand schnell in China tätig zu werden.
Wir standen vor der wichtigen Frage: Können wir mit wenig Aufwand alle Probleme im Zusammenhang mit dem chinesischen Internet und der Firewall auf Netzwerk-/Cloud-/Serverebene lösen?
Wir begannen mit der Beantragung .
ICP-Lizenz
Um unseren Service innerhalb Chinas (Festlandchina) anbieten und Tests durchführen zu können, müssen wir zunächst eine ICP-Lizenz für die Domain erhalten.
Wenn der Benutzertraffik Ihrer Website innerhalb des Festlandchinas termininiert wird und Ihre Domain keine ICP-Lizenz besitzt, wird Ihr Traffik vonseiten des Providers/Hostings blockiert. Interessanterweise wird in die ICP-Lizenz der spezifische Provider aufgenommen, sei es Cloudflare oder Alibaba Cloud. Daher werden Sie, wenn Sie eine ICP-Lizenz für Cloudflare erhalten haben und Ihre Website bei ihnen gehostet ist, nicht ohne Weiteres nahtlos zu Alibaba Cloud wechseln können. Es wird erforderlich sein, einen weiteren Hosting-Anbieter in diese Lizenz aufzunehmen.
Nachdem wir die ICP-Lizenz für die Domain erhalten hatten, konnten wir spezifische technische Ideen und Lösungen entwickeln und umsetzen.
Testen von Lösungen
Aber bevor wir direkt mit der Erstellung von Staging-Optionen, Optimierung der Website und Verbesserung der Geschwindigkeit beginnen, müssen wir ein Werkzeug zur Testung auswählen, um zu sehen, welche unserer Maßnahmen die Leistung der Website verbessern oder verschlechtern.
Unser Testwerkzeug musste zwei Hauptanforderungen erfüllen:
- Es muss die Möglichkeit bieten, Tests aus China durchzuführen,
- es muss Browser-Tests ermöglichen.
So fanden wir ! Sie verfügen über eine hervorragende Abdeckung mit Testpunkten weltweit. In China können mit diesem Tool ebenfalls Tests aus 100500 Provinzen durchgeführt werden. In jeder davon gibt es mehrere verschiedene Anbieter sowie die Möglichkeit, Backbone-Tests (eine Art von virtueller Maschine im Rechenzentrum) und Lastmile-Tests (maximal nah an den Benutzerbedingungen, a.k.a. Workstation). Letzterer Testtyp ist teurer.
Nach Abschluss eines Jahresvertrags (weniger ist nicht möglich) begannen wir, das Tool zu erforschen. Ehrlich gesagt waren wir positiv überrascht von seinen Funktionen. Man kann starten:
- DNS-Tests,
- Web-Tests (Browser-Tests, einfache GET/POST, Emulation eines mobilen Clients usw.),
- Transaktionsüberprüfungen (zum Beispiel Anmeldungen),
- API-Tests,
- Ping, Traceroute, NTP usw.
Das lässt sich nicht alles auflisten. Und das Wichtigste ist, dass jeder Test recht gut angepasst werden kann, indem eine Vielzahl von Headern und anderen Parametern hinzugefügt wird. Das Ergebnis ist eine enorme Menge an Informationen, die deinen Test vollständig beschreiben. Wenn man über das für uns Interessanteste spricht (Browser-Tests), umfasst das Ergebnis:
- Connect, Wait, Load, SSL, DNS-Zeit,
- TTFB, TTLB, Dokument vollständig, Renderzeit, DOM-Ladung,
- Antwort (vergleichbar mit Time To First Byte), Webseitenantwort (vergleichbar mit Time To Last Byte),
- Alle Perzentile, Durchschnitt, Medianzeiten
- Und so weiter.
Diese Metriken sind äußerst hilfreich, um Veränderungen zu erkennen und zu verstehen, ob es besser geworden ist. Wir haben hauptsächlich auf Antwort, Webseitenantwort, Median, 75 und 95 Perzentilen geschaut..
Eine wichtige Frage, die von Anfang an im Raum stand: kann man Catchpoint vertrauen?? Отражает ли этот инструмент реальную скорость загрузки сайта в Китае из разных городов или же это просто какой-то тест в вакууме, не имеющий ничего общего с real user experience?
Das ist ein großes Problem, denn aus Russland heraus ist es praktisch unmöglich, verlässliche Informationen darüber zu erhalten, wie eine Website aus China funktioniert. Mit einem SOCKS-Proxy über eine virtuelle Maschine dauert das Laden der Website mehrere Minuten, was für Tests einfach nicht akzeptabel ist. Daher bleibt der einzige Weg des manuellen Testens mit curl und einfachen GET-Anfragen aus der Konsole mit einer Zeitmessung. Dies hilft, da dieser Test gut die Geschwindigkeit der Netzwerklösung widerspiegelt, und wenn Browser-Tests hinzukommen, ist das umso besser.
Später sind wir selbst nach China gereist und haben festgestellt, dass man auf Catchpoint vertrauen kann, da es die realen Geschwindigkeitswerte recht präzise wiedergibt.
Cloudflare China Netzwerk
Da wir für die Hauptdomain semrush.com erfolgreich Cloudflare nutzen, haben wir beschlossen, gleich deren Funktion mit dem Namen . Diese Option wird nur für Enterprise-Websites auf gesonderte Anfrage und gegen gesonderte Gebühr aktiviert. Sie ist auch nur für Websites verfügbar, die über eine entsprechende ICP-Lizenz verfügen, in der Cloudflare als Anbieter aufgeführt ist. Nach ihrer Aktivierung wird für die Website das „chinesische CDN“ von Cloudflare verfügbar – der Datenverkehr aus chinesischen Regionen wird an den nächsten PoP (Points of Presence) von CF geleitet und dann über deren Netzwerke oder die Netzwerke der Anbieter/Partner bis zum Origin transportiert.
Das Schema dieses Teststands ist unten dargestellt.
Für uns ist das eine hervorragende Option. Das bedeutet, dass die zweite Domain ebenfalls über CF läuft, was die Anzahl der in der Firma verwendeten Lösungen nicht erhöht und die Infrastruktur praktisch nicht komplizierter macht.
Wir haben Browser-Tests durchgeführt, und das sind die Ergebnisse:
Die roten Rauten sind Testfehler. Fehler unten sind DNS-Fehler (Resolve-Timeouts). Fehler oben sind Timeouts.
Uptime: 86.6
Median: 18s
75. Perzentil: 29.3s
95. Perzentil: 60s
Median, nachdem die Last entfernt wurde reCaptcha (Google-Dienst, der in China blockiert ist), ist von 28 auf 18 Sekunden gesunken. Trotzdem sind das schlechte Werte, wenn man bedenkt, dass ein ähnlicher Test für semrush.com (aus den USA) für 95 % der Nutzer (aus den USA) auf derselben Seite (statisch + dynamisch) weniger als 10 Sekunden ergab.
Jeder Test kann aufgerufen und betrachtet werden Wasserfall und andere detailliertere Parameter. Wir haben begonnen, die Ursachen der Fehler zu untersuchen, und während die Zeitüberschreitungen mehr oder weniger verständlich sind: Das Internet in China hat oft Einbrüche und Aussetzer, was die Geschwindigkeit des Verbindungsaufbaus und das Laden von Ressourcen aus dem Ausland instabil und unterschiedlich macht, hat uns die DNS-Fehler stark überrascht. Wir haben festgestellt, dass PoP von Cloudflare tatsächlich in China liegen, die Adresse der Website wird auf eine Anycast-IP aufgelöst, aber die DNS-Server sind amerikanischer Herkunft, weshalb die DNS-Anfragen die Grenze überqueren müssen, wodurch gelegentlich Fehler auftreten.
Nachdem wir diese Frage bei CF geklärt haben, stellte sich heraus, dass sie keine eigenen DNS-Server in China haben, und wann sie welche bekommen werden, ist derzeit unbekannt.
Deshalb haben wir beschlossen, nur die DNS von Cloudflare zu testen und den Arbeitsmodus von Cloudflare für unsere Website auf den Modus „Nur DNS“ zu ändern.Das ist ein Modus, in dem Cloudflare den Datenverkehr nicht selbst proxyisiert, was bedeutet, dass es keinen DDoS-Schutz, kein CDN und keine anderen Funktionen bereitstellt, sondern im Modus eines normalen DNS-Servers arbeitet.
Diese Umgebung ist schematisch im folgenden Bild dargestellt. In der Abbildung sind die neu gewonnenen Erkenntnisse darüber berücksichtigt, dass die DNS-Server von Cloudflare hinter der Firewall stehen.
Bei Catchpoint haben wir einfache GET-Tests (keine browserbasierten) gestartet, die viele Fehler zeigten. Die Ursache dafür waren die gleichen DNS-Fehler.
Wir begannen, diese Fehler mit Hilfe von dig zu debuggen und entdeckten, dass die Adresse beim ersten Aufruf korrekt aufgelöst wird, beim wiederholten Aufruf jedoch jedes Mal SERVFAIL und nicht gefunden. Woher kommt das plötzliche?
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn hat die Adresse 220.170.186.192
Host semrushchina.cn nicht gefunden: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn hat die Adresse 220.170.186.192
Host semrushchina.cn nicht gefunden: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn hat die Adresse 220.170.186.192
Host semrushchina.cn nicht gefunden: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn hat die Adresse 220.170.186.192
Host semrushchina.cn nicht gefunden: 2(SERVFAIL)Bei der direkten Anfrage an die NS-Server von Cloudflare treten solche Fehler nicht auf:
root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Verwendeter Domain-Server:
Name: ray.ns.cloudflare.com.
Adresse: 173.245.59.138#53
Aliases:
semrushchina.cn hat die Adresse 220.170.186.192
semrushchina.cn hat die Adresse 220.170.186.192
Verwendeter Domain-Server:
Name: ray.ns.cloudflare.com.
Adresse: 173.245.59.138#53
Aliases:
semrushchina.cn hat die Adresse 220.170.186.192
semrushchina.cn hat die Adresse 220.170.186.192Das bedeutet, dass das Problem beim "lokalen" DNS-Server oder beim Anbieter-Server liegt.
Eine weitere Untersuchung ergab, dass SERVFAIL wir beim Auflösen AAAA-Einträge.
Es stellte sich heraus, dass bei einer Anfrage an Cloudflare AAAA-Einträge, die im Domain nicht vorhanden sind, Cloudflare mit A-Einträgen antwortete, was als Fehler und Verstoß gegen RFC gilt. Dadurch gefiel es dem lokalen Resolver (x.x.x.x) nicht, und er antwortete SERVFAIL. In dem untenstehenden Protokoll ist dieses Verhalten deutlich sichtbar:
root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @x.x.x.x
; <> DiG 9.10.3-P4-Ubuntu <> -t AAAA semrushchina.cn @x.x.x.x
;; globale Optionen: +cmd
;; Antwort erhalten:
;; ->>HEADER<<- Opcode: QUERY, Status: SERVFAIL, ID: 55467
;; Flags: qr rd ra; QUERY: 1, ANTWORT: 0, AUTORITÄT: 0, ZUSÄTZLICH: 1
;; OPT PSEUDOSECTION:
; EDNS: Version: 0, Flags:; udp: 4096
;; FRAGESEKTION:
;semrushchina.cn. IN AAAA
;; Abfragezeit: 334 ms
;; SERVER: x.x.x.x#53(x.x.x.x)
;; WANN: Di. 14. Aug. 2018 23:38:50 CST
;; MSG GRÖSSE empfangen: 44
root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @dana.ns.cloudflare.com.
; <> DiG 9.10.3-P4-Ubuntu <> -t AAAA semrushchina.cn @dana.ns.cloudflare.com.
;; globale Optionen: +cmd
;; Antwort erhalten:
;; ->>HEADER<<- Opcode: QUERY, Status: NOERROR, ID: 63944
;; Flags: qr aa rd; QUERY: 1, ANTWORT: 1, AUTORITÄT: 0, ZUSÄTZLICH: 1
;; WARNUNG: Rekursion angefordert, aber nicht verfügbar
;; OPT PSEUDOSECTION:
; EDNS: Version: 0, Flags:; udp: 512
;; FRAGESEKTION:
;semrushchina.cn. IN AAAA
;; ANTWORTSEKTION:
semrushchina.cn. 300 IN A 220.170.186.192
;; Abfragezeit: 185 ms
;; SERVER: 173.245.58.105#53(173.245.58.105)
;; WANN: Di. 14. Aug. 2018 23:43:03 CST
;; MSG GRÖSSE empfangen: 60
Wir haben einen Bug-Report an Cloudflare gesendet, und sie haben das nach einer Weile behoben. Es stellte sich als interessant heraus: Zum aktuellen Zeitpunkt gibt es in China immer noch keine Unterstützung für IPv6, daher konnte Cloudflare dort seine IPv6-Adresse nicht in der Antwort auf die Anfrage ausgeben. AAAA-Records. Am Ende stellte sich heraus, dass Cloudflare für China auf solche Anfragen reagierte. NODATA auf solche Anfragen.
So hat sich die Anzahl der DNS-Fehler in den Catchpoint-Tests stark verringert, aber nicht vollständig. Auch die Timeouts sind weiterhin vorhanden.
Und wir haben begonnen, nach einer anderen Lösung zu suchen.
Im nächsten Teil werde ich erzählen, wie wir die chinesische Cloud getestet haben. Alibaba Cloud, wie wir mit ein wenig Nginx "Magie" schnell PoC (Proof of Concept)-Lösungen erstellen konnten, und wie wir Multi-Cloud-Lösungen entwickelt haben, von denen eine letztlich die Performance unseres Services aus China erheblich beschleunigt hat.
Bleiben Sie dran!
Die nächsten Teile
Quelle: habr.com
