Hallo zusammen!
Hier ist Nikita – Systemingenieur bei SEMrush. Heute erzähle ich Ihnen, wie wir die Aufgabe bekamen, die Stabilität unseres Dienstes semrush.com in China zu gewährleisten und mit welchen Problemen wir während der Umsetzung konfrontiert waren (unter Berücksichtigung des Standorts unseres Rechenzentrums an der Ostküste der USA).
Das wird eine große Geschichte, aufgeteilt in mehrere Artikel. Ich werde Ihnen erzählen, wie alles bei uns war: vom völlig nicht funktionierenden Dienst aus China bis hin zu den Leistungskennzahlen des Dienstes auf dem Niveau seiner amerikanischen Version für Amerikaner. Ich verspreche, es wird interessant und nützlich sein. Also, los geht's.
Probleme des chinesischen Internets
Selbst der entfernteste Mensch von den Besonderheiten der Netzwerkadministration hat zumindest einmal von der Großen Firewall von Chinagehört. Uuu, das klingt cool, oder? Aber was ist das, und wie funktioniert es wirklich – die Frage ist ziemlich kompliziert. Im Internet gibt es viele Artikel darüber, aber aus technischer Sicht wurde die Funktionsweise dieser Firewall nirgendwo beschrieben. Was jedoch nicht verwunderlich ist. Ich gebe sofort zu, dass ich nach einem Jahr Arbeit nicht genau sagen kann, wie sie funktioniert, aber ich kann über meine Beobachtungen und praktischen Schlussfolgerungen berichten. Und wir beginnen mit den Gerüchten über diese Firewall.
Es gibt viele Gerüchte über diese Firewall. Lassen Sie uns die wichtigsten und interessantesten von ihnen in einer Liste zusammenfassen:
- Google, Facebook, Twitter und ähnliche Dienste sind in China blockiert und funktionieren nicht.
- Der gesamte Datenverkehr, der aus China hinaus und in China hinein fließt, wird analysiert und bei verdächtigem Datenverkehr mithilfe von maschinellem Lernen eingeschränkt, was ihn erheblich verlangsamt, wenn er die Grenze überquert.
- Die chinesischen Geheimdienste knacken jeden verschlüsselten Datenverkehr, der durch ihre Firewall fließt.
- VPN-Tunnel und IPSEC-Tunnel sind instabil, fallen aus und werden ständig blockiert.
- Je einfacher die Verschlüsselung, desto einfacher die Passphrase, die zur Authentifizierung/encryption des Datenverkehrs verwendet wird, desto schneller passiert sie die chinesische Firewall.
Das konnten wir über diese Gerüchte herausfinden:
- Google, Facebook, Twitter und ähnliche Dienste sind tatsächlich blockiert (Ihre K.O.), aber viele technische Domains von Google, wie gstatic.com, sind nicht gesperrt und funktionieren. Daraus folgt, dass man nicht einfach alle scheinbar blockierten Google-Ressourcen wahllos entfernen sollte.
- Jeder Verkehr, der die Grenze passiert, fügt seiner Zeit einen erheblichen Delay hinzu. Schauen Sie sich die beiden Ergebnisse an. Eine Website, eine Seite, einfacher GET curl’m. Die erste Messung stammt aus China selbst (die schöne Stadt Shenzhen). Die zweite Messung kam von außerhalb aus Hongkong (hat Souveränität, und zwischen ihm und der Außenwelt gibt es keine Firewall). Die Entfernung zwischen den Städten beträgt in gerader Linie etwa 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 Upload Total Verbraucht Verbleibend 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 Upload Total Verbraucht Verbleibend 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/sAchten Sie darauf, dass time_connect. Und insgesamt sehen Sie das Ergebnis: Die Firewall fügt 4 zusätzliche Sekunden hinzu, was monströs lange ist.
- VPNs und IPSEC-Tunnel fallen tatsächlich oft aus. Darüber werde ich später und ausführlicher sprechen. Die von Benutzern verwendeten VPN-Server werden im Laufe der Zeit blockiert (in der Regel innerhalb eines Tages nach Beginn der Nutzung).
- Es gibt die Meinung von Menschen, die in China leben, dass je einfacher die Verschlüsselung des Verkehrs ist, desto schneller passiert er die Grenze, weil es leicht zu erkennen ist, dass darin nichts Illegales enthalten ist. Ebenso erhält "sauberer" Verkehr mehr Bandbreite und Geschwindigkeit, während "schmutziger" Verkehr, der schwer verständlich ist, im Gegenteil langsamer durchgeführt wird. Zum Beispiel gebe ich curl bis ifconfig.co über das Protokoll HTTPS und HTTP.
curl -o /dev/null -w@curl_time "https://ifconfig.co/"
% Gesamt % Empfangen % Übertragen Durchschnittliche Geschwindigkeit Zeit Zeit Zeit Aktuell
Herunterladen Hochladen Gesamt Verbracht Verbleibend 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
----------
Größe_download: 13 Bytes
Geschwindigkeit_download: 2.000B/s
curl -o /dev/null -w@curl_time "http://ifconfig.co/"
% Gesamt % Empfangen % Übertragen Durchschnittliche Geschwindigkeit Zeit Zeit Zeit Aktuell
Herunterladen Hochladen Gesamt Verbracht Verbleibend 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
----------
Größe_download: 13 Bytes
Geschwindigkeit_download: 28.000B/sDer Unterschied von 5 Sekunden in der Gesamtdauer für den Download von 13 Bytes. Wenn man diesen Test mehrere Male durchführt, kann man feststellen, dass der GET-Befehl über HTTP jedes Mal insgesamt in ähnlicher Zeit abgeschlossen wird, während die Antwortzeit bei HTTPS manchmal 3, 5, 10 und sogar 17 Sekunden beträgt. Manchmal 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 von Tunneln fallen gelegentlich aus.
- Die Latenz zwischen zwei Punkten variiert ständig und ist oft einfach unvorhersehbar. Wenn man verschiedene Städte/Regionen verbindet, erwartet man aufgrund der geografischen Lage der Regionen, dass die Verzögerung geringer ist, erhält jedoch genau das Gegenteil.
- Das Internet und die Kommunikationskanäle funktionieren mal schnell, mal langsam. Hier gibt es einen gewissen Einfluss von Tageszeit und Wochentag, aber nicht immer.
- DNS-Anfragen aus China ins Ausland überschreiten manchmal das erlaubte Timeout.
Das Bild ist einfach „großartig”.
Wie ich bereits erwähnt habe, befindet sich unser Rechenzentrum im Osten der USA, und SEMrush besteht aus Dutzenden von miteinander verbundenen Produkten, Backends, Frontends, Datenbanken, und all dies im Rechenzentrum und in der Cloud. Die Aufgabe für uns als Systemadministratoren war es, mit minimalem Aufwand schnell in China arbeiten zu können.
Wir mussten die wichtige Frage beantworten: Kann man mit minimalem Aufwand alle Probleme, die mit dem chinesischen Internet und der Firewall verbunden sind, auf Netzwerk-/Cloud-/Serverebene lösen?
Wir haben mit dem Erhalt .
ICP-Lizenz
Um unseren Service innerhalb Chinas (Festlandchina) hosten und Tests durchführen zu können, muss man zuerst eine ICP-Lizenz für die Domain erhalten.
Wenn der Benutzertraffic Ihrer Website innerhalb von Festlandchina terminiert und Ihre Domain keine ICP-Lizenz hat, wird Ihr Traffic vom Anbieter/Hosting blockiert. Interessanterweise wird in die ICP-Lizenz ein spezifischer Anbieter eingetragen, egal ob Cloudflare oder Alibaba Cloud. Daher können Sie, wenn Sie eine ICP-Lizenz für Cloudflare erhalten haben und Ihre Website dort hosten, nicht nahtlos zu Alibaba Cloud wechseln. Es müssen zusätzliche Hosting-Anbieter in diese Lizenz aufgenommen werden.
Nachdem wir die ICP-Lizenz für die Domain erhalten hatten, konnten wir spezifische technische Ideen und Lösungen entwickeln und umsetzen.
Lösungen testen
Doch bevor wir direkt mit der Erstellung von Staging-Varianten beginnen, Drehregler drehen, die Leistung der Website und ihre Geschwindigkeit optimieren, müssen wir ein Werkzeug für deren Tests auswählen, um zu sehen, welche Maßnahmen unsere Arbeit an der Website verbessern oder im Gegenteil verschlechtern.
Unser Testwerkzeug sollte zwei Hauptanforderungen erfüllen:
- es sollte in der Lage sein, Tests aus China durchzuführen,
- es sollte Browsertests durchführen können.
So fanden wir ! Sie haben eine hervorragende Abdeckung von Testpunkten weltweit. In China können wir mit diesem Werkzeug auch Tests aus 100500 Provinzen durchführen. In jeder Provinz gibt es mehrere verschiedene Anbieter + die Möglichkeit, Backbone-Tests (etwas wie eine virtuelle Maschine im Rechenzentrum) und Lastmile-Tests (so nah wie möglich an den Nutzerbedingungen, auch bekannt als Arbeitsplatz). Die letzte Testart ist teurer.
Nachdem wir einen Jahresvertrag abgeschlossen hatten (weniger war nicht möglich), begannen wir mit dem Studium des Werkzeugs. Offen gesagt waren wir angenehm überrascht von seiner Funktionalität. Man kann starten:
- DNS-Tests,
- Web-Tests (Browser, einfacher GET/POST, Emulation eines mobilen Clients usw.),
- Transaktionsprüfungen (z.B. Login),
- API-Tests,
- Ping, Traceroute, NTP usw.
Man kann nicht alles aufzählen. Und das Wichtigste ist, dass jeder Test ziemlich gut angepasst werden kann, indem man eine Reihe von Headern und anderen Parametern hinzufügt. Am Ende erhält man eine riesige Menge an Informationen, die Ihren Test vollständig beschreiben. Wenn wir über das für uns Interessanteste sprechen (Browser-Tests), beinhaltet das Ergebnis:
- Connect, Wait, Load, SSL, DNS-Zeit,
- TTFB, TTLB, Dokument vollständig, Renderzeit, DOM-Ladung,
- Antwort (ähnlich der Zeit bis zum ersten Byte), Webseitenausgabe (ähnlich der Zeit bis zum letzten Byte),
- Alle Perzentile, Durchschnitt, Medianzeit
- usw.
Daher helfen alle diese Metriken hervorragend dabei, Veränderungen zu sehen und zu verstehen, ob es besser geworden ist. Wir haben hauptsächlich auf Response, Webpage Response, Median, 75 und 95 Perzentile.
Eine wichtige Frage, die von Anfang an in der Luft schwebte: Kann man Catchpoint vertrauen?? Отражает ли этот инструмент реальную скорость загрузки сайта в Китае из разных городов или же это просто какой-то тест в вакууме, не имеющий ничего общего с real user experience?
Das ist ein großes Problem, denn es ist in Russland fast unmöglich, zuverlässig zu erfahren, wie eine Website aus China funktioniert. Wenn man über einen virtuellen Proxy zugreift, dauert das Laden der Website mehrere Minuten, was für Tests einfach inakzeptabel ist, deshalb bleibt als einzige manuelle Testmöglichkeit curl und einfache GET-Anfragen aus der Konsole mit Zeitmessung. Das hilft, weil dieser Test die Geschwindigkeit der Netzwerklösung gut widerspiegelt, und wenn es auch noch Browser-Tests gibt, ist es umso besser.
Später sind wir selbst nach China gereist und haben uns überzeugt, dass man Catchpoint vertrauen kann, er spiegelt die tatsächlichen Geschwindigkeitswerte ziemlich genau wider.
Cloudflare China Network
Da wir für die Hauptdomain semrush.com erfolgreich Cloudflare verwenden, haben wir uns entschieden, sofort ihre Funktion namens auszuprobieren. Diese Option wird nur für Enterprise-Websites auf gesonderte Anfrage und gegen zusätzliche Gebühr aktiviert. Sie ist auch nur für Websites verfügbar, die über die entsprechende ICP-Lizenz verfügen, in der Cloudflare als Anbieter aufgeführt ist. Nach der Aktivierung steht dem Website-Betreiber das "chinesische CDN" von Cloudflare zur Verfügung – der Datenverkehr aus den chinesischen Regionen wird am nächstgelegenen PoP (Points of Presence) von CF abgewickelt und anschließend über dessen Netzwerke oder die Netzwerke von Providern/Partnern zum Ursprung weitergeleitet.
Das Schema dieser Testumgebung ist unten dargestellt.
Für uns ist das eine wunderbare 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 auch die Infrastruktur kaum kompliziert.
Wir haben Browser-Tests durchgeführt, und das ist dabei herausgekommen:
Die roten Rauten sind Testfehler. Die Fehler unten sind DNS-Fehler (resolve timeout). Die Fehler oben sind Timeouts.
Uptime: 86,6
Median: 18s
75 Perzentil: 29,3s
95 Perzentil: 60s
Die Medianzeit, nachdem die Last von reCaptcha (ein Google-Dienst, der in China blockiert ist), sank von 28 auf 18 Sekunden. Dennoch sind das schreckliche Werte, wenn man berücksichtigt, dass derselbe 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.
In jeden Test kann man hineingehen und schauen Waterfall und weitere detaillierte Parameter. Wir haben angefangen, die Ursachen der Fehler zu untersuchen, und während die Zeitüberschreitungen mehr oder weniger nachvollziehbar sind: Das Internet in China „springt hin und her“, weshalb die Geschwindigkeit der Verbindung und das Laden von Ressourcen aus dem Ausland instabil und unterschiedlich sind, hat uns die DNS-Fehler sehr überrascht. Wir haben festgestellt, dass PoP bei Cloudflare tatsächlich in China sind, die Website-Adresse wird auf eine Anycast-IP aufgelöst, aber es werden amerikanische DNS-Server verwendet, weshalb die DNS-Anfragen gezwungen sind, die Grenze zu überqueren, was manchmal zu Fehlern führt.
Nach Klärung dieser Frage mit CF stellte sich heraus, dass sie keine eigenen DNS-Server in China haben, und wann sie diese haben werden, ist noch unbekannt.
Daher haben wir beschlossen, nur die DNS von Cloudflare zu testen und die Betriebsweise von Cloudflare für unsere Website auf den Modus „Nur DNS“ zu ändern. Dies ist ein Modus, in dem Cloudflare den Traffic nicht durch sich selbst proxiert, was bedeutet, dass es keinen DDoS-Schutz, CDN und andere Funktionen bietet und im Modus eines normalen DNS-Servers arbeitet.
Dieser Stand ist schematisch im nächsten Bild dargestellt. Im Bild sind die neu gewonnenen Erkenntnisse bezüglich der DNS-Server von Cloudflare hinter der Firewall berücksichtigt.
Bei Catchpoint haben wir einfache GET-Tests (nicht browserbasiert) gestartet, die sehr viele Fehler zeigten. Der Grund dafür waren die gleichen DNS-Fehler.
Wir haben damit begonnen, diese Fehler mit Hilfe von dig zu debuggen und festgestellt, dass bei der ersten Anfrage die Adresse korrekt bestimmt wird, aber bei wiederholten Anfragen erhalten wir immer wieder SERVFAIL und nicht gefunden. Warum plötzlich?
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 gibt es diese Fehler nicht:
root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Verwende Domain-Server:
Name: ray.ns.cloudflare.com.
Adresse: 173.245.59.138#53
Aliase:
semrushchina.cn hat die Adresse 220.170.186.192
semrushchina.cn hat die Adresse 220.170.186.192
Verwende Domain-Server:
Name: ray.ns.cloudflare.com.
Adresse: 173.245.59.138#53
Aliase:
semrushchina.cn hat die Adresse 220.170.186.192
semrushchina.cn hat die Adresse 220.170.186.192Das bedeutet, das Problem liegt auf der Seite des „lokalen“ DNS-Servers oder des Anbieterservers.
Eine weitere Untersuchung ergab, dass SERVFAIL wir bei der Auflösung AAAA-Einträge erhalten.
Es stellte sich heraus, dass bei der Anfrage an Cloudflare AAAA-Eintrag, der nicht im Domain vorhanden ist, antwortete Cloudflare A-mit einer Fehlermeldung, die nicht den RFC entspricht. Deshalb gefiel das dem lokalen Resolver (x.x.x.x) nicht, und er antwortete SERVFAIL. In dem untenstehenden Protokoll ist dieses Verhalten deutlich zu sehen:
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, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; FRAGE ABSCHNITT:
;semrushchina.cn. IN AAAA
;; Abfragezeit: 334 ms
;; SERVER: x.x.x.x#53(x.x.x.x)
;; WANN: Di. Aug 14 23:38:50 CST 2018
;; 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, AUTHORITY: 0, ADDITIONAL: 1
;; WARNUNG: Rekursion angefordert, aber nicht verfügbar
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; FRAGE ABSCHNITT:
;semrushchina.cn. IN AAAA
;; ANTWORT ABSCHNITT:
semrushchina.cn. 300 IN A 220.170.186.192
;; Abfragezeit: 185 ms
;; SERVER: 173.245.58.105#53(173.245.58.105)
;; WANN: Di. Aug 14 23:43:03 CST 2018
;; 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: Momentan gibt es in China immer noch keine Unterstützung für IPv6, weshalb Cloudflare dort seine IPv6-Adresse nicht in der Antwort auf die Anfrage ausgeben konnte AAAA-Einträge. Letztendlich wurde alles so gelöst, dass Cloudflare für China NODATA auf solche Anfragen antwortete.
So haben die DNS-Fehler in den Catchpoint-Tests deutlich abgenommen, aber nicht vollständig. Auch die Timeouts sind nicht verschwunden:
Und wir begannen, nach einer anderen Lösung zu suchen.
Im nächsten Teil erzähle ich, wie wir die chinesische Cloud getestet haben Alibaba Cloud, wie wir mit ein wenig "Magie" von Nginx schnell PoC (Proof of Concept) Lösungen erstellen konnten, wie wir Multi-Cloud-Lösungen erstellt haben, wobei eine von ihnen letztendlich sehr geholfen hat, die Dienstleistung aus China zu beschleunigen.
Bleiben Sie dran!
Nächste Teile
Quelle: habr.com
