Hallo allerseits!
In Kontakt Nikita ist ein Systemingenieur von SEMrush . Heute werde ich Ihnen erzählen, wie wir uns der Aufgabe gestellt haben, die Stabilität unseres semrush.com-Dienstes in China sicherzustellen, und auf welche Probleme wir bei seiner Implementierung gestoßen sind (angesichts des Standorts unseres Rechenzentrums an der Ostküste der USA).
Dies wird eine großartige Geschichte sein, die in mehrere Artikel unterteilt ist. Ich werde Ihnen erzählen, wie alles mit uns passiert ist: von einem völlig arbeitsfreien Dienst aus China bis zur Leistung des Dienstes auf dem Niveau seiner amerikanischen Version für Amerikaner. Ich verspreche, dass es interessant und nützlich sein wird. Also lass uns gehen.
Chinesische Internetprobleme
Selbst die von den Besonderheiten der Netzwerkadministration am weitesten entfernte Person hat mindestens einmal von der Great Chinese Firewall gehört . Ähh, das klingt cool, oder? Aber was es ist, wie es tatsächlich funktioniert, ist eine ziemlich komplizierte Frage. Im Internet finden Sie viele Artikel dazu, aber aus technischer Sicht wird das Gerät dieser Firewall nirgendwo beschrieben. Was jedoch nicht überraschend ist. Ich gestehe sofort, dass ich aufgrund der Ergebnisse des Arbeitsjahres nicht genau sagen kann, wie es funktioniert, aber ich kann über meine Kommentare und praktischen Schlussfolgerungen berichten. Und wir werden mit Gerüchten über diese Firewall beginnen.
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 andere ähnliche Dienste sind blockiert und funktionieren in China nicht.
- Jeder Verkehr, der über China hinaus und nach China führt, wird durch maschinelles Lernen (bei verdächtigem Verkehr) analysiert und begrenzt, wodurch der Verkehr über die Grenze erheblich verlangsamt wird.
- Chinesische Geheimdienste knacken jeden verschlüsselten Verkehr, der durch ihre Firewall geht.
- VPN-Tunnel, IPSEC-Tunnel sind instabil, fallen und werden ständig blockiert.
- Je einfacher die Verschlüsselung, desto einfacher die für die Authentifizierung / Verkehrsverschlüsselung verwendete Passphrase, desto schneller passiert sie die chinesische Firewall.
Folgendes haben wir über diese Gerüchte herausgefunden:
- Google, Facebook, Twitter und andere ähnliche Dienste sind wirklich blockiert (Ihr KO), aber viele technische Google-Domains sind beispielsweise nicht gesperrt und funktionieren nicht (dasselbe gstatic.com). Dies führt zu der Schlussfolgerung: Schneiden Sie nicht rücksichtslos alle Google- und anderen Ressourcen aus, die blockiert zu sein scheinen, scheinbar blockiert.
- Jeder Verkehr, der die Grenze passiert, verlängert die Zeit erheblich. Schauen Sie sich die beiden Ergebnisse an. Eine Seite, eine Seite, einfach Curl bekommen. Die erste Messung aus China selbst (der schönen Stadt Shenzhen). Die zweite fror außerhalb von Hongkong ein (sie hat Souveränität und es gibt keine Firewall zwischen ihr und der Welt). Die Entfernung zwischen Städten in einer geraden Linie beträgt etwa 30-40 km.
nikita@china-shenzhen:~
Achten Sie auf time_connect . Und im Allgemeinen sehen Sie das Ergebnis: Die Firewall fügt 4 zusätzliche Sekunden hinzu, was ungeheuer lang ist.
- VPNs und IPSEC-Tunnel fallen häufig aus. Ich werde etwas später und ausführlicher darüber sprechen. VPN-Server, die von Benutzern verwendet werden, werden im Laufe der Zeit blockiert (normalerweise innerhalb eines Tages nach Beginn der Verwendung).
- In China lebende Menschen sind der Meinung, dass der Verkehr umso schneller über die Grenze gelangt, je einfacher die Verschlüsselung ist, da leicht zu verstehen ist, dass darin nichts Illegales enthalten ist. Und genau wie "sauberer" Verkehr mehr Bandbreite und Geschwindigkeit erhält und "schmutziger" Verkehr, der nichts ausmacht, im Gegenteil langsamer wird. Als Beispiel werde ich curl mithilfe der Protokolle HTTPS und HTTP zu ifconfig.co bringen.
curl -o /dev/null -w@curl_time "https://ifconfig.co/" % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 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 Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 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/s
Die Differenz beträgt 5 Sekunden bei einer Gesamtladezeit von 13 Byte. Wenn Sie diesen Test mehrmals durchführen, können Sie feststellen, dass GET unter HTTP im Allgemeinen jedes Mal zur gleichen Zeit abgeschlossen wird. Bei Verwendung von HTTPS antwortet die Site manchmal in 3, 5, 10 und sogar 17 Sekunden. Manchmal treten SSL-Fehler auf:
Unknown SSL protocol error in connection to ifconfig.co:443.
Also was wir haben:
- Die Probleme, die durch die oben beschriebene chinesische Firewall verursacht wurden.
- Pings an externe Ressourcen und interne Tunnel verschwinden regelmäßig.
- Die Latenz zwischen zwei Punkten ändert sich ständig und ist oft einfach unvorhersehbar. Wenn Sie verschiedene Städte / Regionen verbinden, erwarten Sie, dass die Verzögerung basierend auf der geografischen Lage der Regionen geringer ist und Sie genau die entgegengesetzte Situation erhalten.
- Das Internet und die Kommunikationskanäle sind entweder schnell oder langsam. Es gibt eine leichte Abhängigkeit von der Tageszeit und dem Wochentag, aber nicht immer.
- DNS-Abfragen von China an die Außenwelt überschreiten manchmal das zulässige Zeitlimit.
Das Bild ist einfach „exzellent“.
Das Rechenzentrum befindet sich, wie gesagt, im Osten der USA, und der gesamte SEMrush besteht aus Dutzenden miteinander verbundener Produkte, Backends, Frontends, Datenbanken und all dies im Rechenzentrum und in den Clouds. Als Team von Systemadministratoren wurden wir mit geringem Aufwand beauftragt, schnell in China zu arbeiten.
Wir mussten eine wichtige Frage beantworten: Können wir mit ein wenig Blut auskommen und alle Probleme lösen, die mit dem chinesischen Internet und der Firewall auf Netzwerk- / Cloud- / Serverebene verbunden sind?
Wir haben zunächst eine ICP- Lizenz erhalten .
ICP-Lizenz
Um Ihren Service in China (Festlandchina) platzieren und Tests durchführen zu können, müssen Sie zunächst eine ICP-Domain-Lizenz erwerben.
Wenn der Benutzerverkehr Ihrer Website innerhalb von Festlandchina beendet wird und Ihre Domain keine ICP-Lizenz besitzt, wird Ihr Datenverkehr auf der Anbieter- / Hosting-Seite blockiert. Interessanterweise passt ein bestimmter Anbieter in die ICP-Lizenz, sei es Cloudflare oder Alibaba Cloud. Wenn Sie eine ICP-Lizenz für Cloudflare erhalten und Ihre Site mit diesen gehostet haben, können Sie daher nicht „nahtlos“ zu Alibaba Cloud wechseln. Es ist erforderlich, dieser Lizenz ein weiteres Hosting hinzuzufügen.
Nachdem wir eine ICP-Domain-Lizenz erhalten hatten, konnten wir spezifische technische Ideen und Lösungen entwickeln und umsetzen.
Testlösungen
Bevor Sie jedoch direkt die Optionen für die Bereitstellung erstellen, die Knöpfe drehen, die Site und ihre Geschwindigkeit optimieren, müssen Sie ein Tool zum Testen auswählen, um festzustellen, welche Aktionen die Site verbessern oder verschlechtern.
Unser Testwerkzeug musste zwei Hauptanforderungen erfüllen:
- er sollte in der Lage sein, Tests aus China durchzuführen,
- Es muss Browsertests haben.
Also haben wir den Fangpunkt gefunden ! Sie haben eine hervorragende Abdeckung mit Testpunkten auf der ganzen Welt. In China können Sie mit diesem Tool auch Tests aus 100.500 Provinzen durchführen. In jedem Fall mehrere verschiedene Anbieter + die Möglichkeit, Backbone- Tests (so etwas wie eine virtuelle Maschine in einem Rechenzentrum) und Lastmile- Tests (so nah wie möglich an den Benutzerbedingungen, auch bekannt als Workstation) durchzuführen. Die letztere Art von Test ist teurer.
Nachdem wir einen Einjahresvertrag abgeschlossen haben (Sie können nicht weniger tun), haben wir begonnen, das Tool zu studieren. Ehrlich gesagt waren wir angenehm überrascht von seiner Funktionalität. Sie können ausführen:
- DNS-Tests
- Webtests (Browser, einfaches GET / POST, Emulation eines mobilen Clients usw.),
- Transaktionsprüfungen (z. B. Login),
- API-Tests
- Ping, Traceroute, NTP usw.
Sie können nicht alles auflisten. Und am wichtigsten ist, dass jeder Test durch Hinzufügen einer Reihe von Headern und anderen Parametern ziemlich gut angepasst werden kann. Die Ausgabe ist eine riesige Menge an Informationen, die Ihren Test vollständig beschreiben. Wenn wir über das für uns interessanteste sprechen (Browsertests), dann beinhaltet das Ergebnis:
- Verbinden, Warten, Laden, SSL, DNS-Zeit,
- TTFB, TTLB, Dokument vollständig, Renderzeit, DOM-Laden,
- Antwort (etwas in der Nähe von Time To First Byte), Webseitenantwort (etwas in der Nähe von Time To Last Byte),
- Beliebiges Perzentil, Durchschnitt, Medianzeit
- Usw.
Dementsprechend helfen Ihnen all diese Metriken, die Änderungen zu erkennen und zu verstehen, ob sie besser geworden sind. Wir haben uns hauptsächlich Response, Webpage Response, Median, 75 und 95 Perzentile angesehen .
Eine wichtige Frage, die von Anfang an in der Luft lag: Kann man Catchpoint glauben ? Entspricht dieses Tool der tatsächlichen Ladegeschwindigkeit der Website in China aus verschiedenen Städten oder handelt es sich nur um eine Art Test in einem Vakuum, der nichts mit der tatsächlichen Benutzererfahrung zu tun hat?
Dies ist ein großes Problem, da es fast unmöglich ist, in Russland zuverlässig herauszufinden, wie die Website aus China funktioniert. Wenn Sie Socken-Proxy über eine virtuelle Maschine ausführen, wird am Ende in wenigen Minuten eine Website geladen, was für Tests einfach nicht akzeptabel ist. Die einzige Option für manuelle Tests sind Curl und einfache GETs von der Konsole mit Zeitmessung. Dies ist hilfreich, da dieser Test die Geschwindigkeit der Netzwerklösung widerspiegelt und bei Browsertests sehr gut ist.
Später gingen wir selbst nach China und stellten sicher, dass Catchpoint vertrauenswürdig ist. Es spiegelt die tatsächlichen Geschwindigkeitsindikatoren ziemlich genau wider.
Cloudflare China Netzwerk
Da wir Cloudflare erfolgreich für die Hauptdomäne semrush.com verwenden, haben wir uns entschlossen, die Funktion China Network sofort auszuprobieren. Diese Option ist nur für Enterprise-Sites auf Anfrage und gegen eine Gebühr aktiviert. Es ist auch nur für Websites verfügbar, die über die entsprechende ICP-Lizenz verfügen, in der Cloudflare als Anbieter angegeben ist. Nach seiner Aufnahme wird das „chinesische CDN“ von Cloudflare für die Site verfügbar - der Verkehr aus chinesischen Regionen landet im nächsten PoP (Points of Presence) CF und wird dann über seine Netzwerke oder Netzwerke von Anbietern / Partnern an den Ursprung geliefert.
Das Schema dieses Prüfstands ist unten dargestellt.
Dies ist eine großartige Option für uns. Es stellt sich heraus, dass die zweite Domäne auch für CF bestimmt ist, wodurch die Anzahl der im Unternehmen verwendeten Lösungen nicht erhöht wird und die Infrastruktur praktisch nicht kompliziert wird.
Wir haben die Browsertests ausgeführt, und Folgendes ist passiert:
Rote Diamanten sind Testdateien. Die folgenden Dateien sind DNS-Fehler (Timeout beheben). Die oben genannten Fehler sind Zeitüberschreitungen.
Betriebszeit: 86,6
Median: 18 Jahre
75 Perzentil: 29,3 s
95 Perzentil: 60er Jahre
Der Median verringerte sich nach dem Entfernen des reCaptcha- Downloads (ein in China blockierter Google- Dienst) von 28 auf 18 Sekunden. Trotzdem sind dies schreckliche Indikatoren, da der gleiche Test für semrush.com (aus den USA) für 95% der Benutzer (aus den USA) weniger als 10 Sekunden auf derselben Seite (Statik + Dynamik) ergab.
In jedem Test können Sie sich den Wasserfall und andere detailliertere Parameter ansehen. Wir haben begonnen, die Fehlerursachen zu untersuchen, und wenn für Zeitüberschreitungen alles weniger oder weniger klar ist: Das Internet in China „bewegt sich nach unten und bewegt sich dann weg“. Aus diesem Grund ist die Geschwindigkeit beim Verbinden und Laden von Ressourcen aus dem Ausland instabil und ungleichmäßig. Dann haben uns DNS-Fehler sehr überrascht . Wir haben festgestellt, dass sich die PoPs von Cloudflare tatsächlich in China befinden. Die Site-Adresse wird in eine einzelne Anycast-IP aufgelöst. Die DNS-Server werden jedoch von den USA verwendet, weshalb DNS-Abfragen gezwungen sind, die Grenze zu überschreiten, sodass sie manchmal fehlschlagen.
Nach der Klärung dieser Frage mit CF stellte sich heraus, dass sie in China keine eigenen DNS-Server haben und es noch nicht bekannt ist, wann dies der Fall sein wird.
Aus diesem Grund haben wir beschlossen, nur Cloudflare-DNS zu testen, und den Cloudflare-Mechanismus für unsere Site in den Modus " Nur DNS " geändert. Dies ist ein solcher Modus, wenn Cloudflare keinen Proxy-Verkehr über sich selbst überträgt. Dies bedeutet, dass es keinen DDoS-Schutz, CDN und andere Funktionen bietet und im Modus eines normalen DNS-Servers arbeitet.
Dieser Ständer ist in der folgenden Abbildung schematisch dargestellt. Die Abbildung berücksichtigt das aufkommende Wissen, dass sich der Cloudflare-DNS-Server hinter der Firewall befindet.
Bei Catchpoint haben wir einfache GET-Tests (ohne Browser) durchgeführt, bei denen viele Fehler aufgetreten sind. Der Grund für sie waren alle die gleichen DNS-Fehler.
Wir haben mit dem Debuggen dieser Fehler mit dig begonnen und festgestellt, dass die Adresse bei der ersten Anforderung korrekt ermittelt wurde. Bei wiederholter Anforderung erhalten wir SERVFAIL und werden nicht jedes Mal gefunden. Was ist das plötzlich?
root@iZwz97n2wgbp61qucbfrjsZ:~
Wenn Cloudflare NS-Server direkt angefordert werden, treten keine derartigen Fehler auf:
root@iZwz97n2wgbp61qucbfrjsZ:~
Dies bedeutet, dass das Problem auf der Seite des „lokalen“ DNS-Servers oder Anbieterservers liegt.
Weitere Untersuchungen ergaben, dass wir SERVFAIL zur Auflösung des AAAA- Datensatzes erhalten.
Es stellte sich heraus, dass Cloudflare, als Cloudflare einen AAAA- Datensatz anforderte, der sich nicht in der Domäne befand, mit einem A- Datensatz antwortete, was ein RFC-Fehler und eine Nichtübereinstimmung ist. Aus diesem Grund mochte der lokale Resolver ( xxxx ) dies nicht und antwortete auf SERVFAIL . Im folgenden Protokoll ist dieses Verhalten deutlich sichtbar:
root@iZwz97n2wgbp61qucbfrjsZ:~
Wir haben einen Cloudflare-Fehlerbericht gesendet, der nach einer Weile behoben wurde. Es stellte sich als interessant heraus: Derzeit gibt es in China noch keine IPv6-Unterstützung, sodass Cloudflare seine IPv6-Adresse nicht als Antwort auf die Anforderung eines AAAA- Datensatzes angeben konnte . Am Ende wurde alles so entschieden, dass Cloudflare für China begann, NODATA auf solche Anfragen zu reagieren.
Daher nahmen die DNS-Fehler in Catchpoint-Tests stark ab, jedoch nicht bis zum Ende. Timeouts sind auch nicht verschwunden:
Und wir suchten nach einer anderen Lösung.
Im nächsten Teil werde ich erzählen, wie wir die chinesische Alibaba Cloud getestet haben, wie wir mit Hilfe eines kleinen "magischen" Nginx schnell PoC-Lösungen (Proof of Concept) erstellen konnten, wie wir Multi-Cloud-Lösungen erstellt haben, von denen eine letztendlich sehr hilfreich war Beschleunigen Sie den Service aus China.
Bleib dran!
Alle Teile
Teil 2
Teil 3