Hallo an alle!
Nikita ist in Kontakt – ein Systemingenieur des Unternehmens SEMrush. Heute erzähle ich Ihnen, 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 der Lage unseres Rechenzentrums an der Ostküste der Vereinigten Staaten).
Dies wird eine große Geschichte sein, die in mehrere Artikel unterteilt ist. Ich erzähle Ihnen, wie alles bei uns passiert ist: von einem völlig nicht funktionierenden Dienst aus China bis hin zu Leistungsindikatoren des Dienstes auf dem Niveau seiner amerikanischen Version für Amerikaner. Ich verspreche, es wird interessant und nützlich sein. So lass uns gehen.
Probleme des chinesischen Internets
Sogar die Person, die am weitesten von den Besonderheiten der Netzwerkadministration entfernt ist, hat davon gehört Große Firewall von China. Wow, klingt cool, oder? Aber was es ist und wie es tatsächlich funktioniert, ist eine ziemlich komplizierte Frage. Im Internet findet man viele Artikel zu diesem Thema, aus technischer Sicht wird der Aufbau dieser Firewall jedoch nirgends beschrieben. Was jedoch nicht überraschend ist. Ich gebe sofort zu, dass ich aufgrund der Ergebnisse eines Jahres Arbeit nicht genau sagen kann, wie es funktioniert, aber ich kann Ihnen von meinen Kommentaren und praktischen Schlussfolgerungen berichten. Und wir beginnen mit Gerüchten über diese Firewall.
Es gibt viele Gerüchte über genau diese Firewall. Fassen wir die wichtigsten und interessantesten davon in einer Liste zusammen:
- Google, Facebook, Twitter und andere ähnliche Dienste sind blockiert und funktionieren in China nicht.
- Jeglicher Datenverkehr, der AUSSERHALB Chinas und NACH China verläuft, wird mithilfe von maschinellem Lernen analysiert und begrenzt (im Falle von verdächtigem Datenverkehr), wodurch er (der Datenverkehr), der die Grenze passiert, erheblich verlangsamt wird.
- Chinesische Geheimdienste hacken jeglichen verschlüsselten Datenverkehr, der ihre Firewall passiert.
- VPN-Tunnel, IPSEC-Tunnel sind instabil, stürzen ab und werden ständig blockiert.
- Je einfacher die Verschlüsselung, je einfacher die Passphrase zur Authentifizierung/Verschlüsselung des Datenverkehrs, desto schneller passiert er die chinesische Firewall.
Folgendes haben wir über diese Gerüchte herausgefunden:
- Google, Facebook, Twitter und andere ähnliche Dienste sind zwar blockiert (Ihr KO), aber viele technische Google-Domains sind beispielsweise nicht gesperrt und funktionieren (dasselbe gstatic.com). Daraus ergibt sich die Schlussfolgerung: Sie sollten nicht leichtsinnig alle scheinbar blockierten Google- und anderen Ressourcen ausschalten.
- Jeder Verkehr, der die Grenze passiert, verlängert die Fahrzeit erheblich. Schauen Sie sich die beiden Ergebnisse an. Eine Site, eine Seite, einfaches GET curl'om. Die erste Messung erfolgte aus China selbst (der wunderschönen Stadt Shenzhen). Der zweite wurde von außerhalb Hongkongs gemessen (es hat Souveränität und es gibt keine Firewall zwischen ihm und der Welt). Die Entfernung zwischen den Städten in einer Luftlinie beträgt ca. 30-40 km.
nikita@china-shenzhen:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
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 Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
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/sBeachten Sie die time_connect. Und im Allgemeinen sehen Sie das Ergebnis: Die Firewall fügt 4 zusätzliche Sekunden hinzu, was ungeheuer lang ist.
- VPN- und IPSEC-Tunnel scheitern häufig. Ich werde etwas später und ausführlicher darüber sprechen. VPN-Server, die von Benutzern genutzt werden, werden im Laufe der Zeit (in der Regel innerhalb eines Tages nach Beginn der Nutzung) gesperrt.
- In China lebende Menschen sind der Meinung, dass der Verkehr umso schneller über die Grenze gelangt, je einfacher die Verschlüsselung ist, denn es ist leicht zu verstehen, dass daran nichts Illegales ist. Und auf die gleiche Weise erhält „sauberer“ Verkehr mehr Bandbreite und Durchgangsgeschwindigkeit, während „schmutziger“ Verkehr, in dem nichts verstanden werden kann, im Gegenteil eine langsamere Durchgangsgeschwindigkeit erhält. Zum Beispiel verwende ich Curl, um ifconfig.co über HTTPS und HTTP-Protokoll.
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/sEine Differenz von 5 Sekunden bei einer Gesamtdownloadzeit von 13 Bytes. Wenn Sie einen solchen Test mehrmals durchführen, können Sie außerdem feststellen, dass GET auf HTTP im Allgemeinen jedes Mal zur gleichen Zeit abgeschlossen wird, während die Site auf HTTPS manchmal in 3, 5, 10 und sogar 17 Sekunden antwortet. Manchmal passieren SSL-Fehler:
Unknown SSL protocol error in connection to ifconfig.co:443.
Was wir also haben:
- Die durch die chinesische Firewall verursachten Probleme sind oben beschrieben.
- Pings an externe Ressourcen und innerhalb von Tunneln verschwinden regelmäßig.
- Die Latenz zwischen zwei Punkten ändert sich ständig und ist oft einfach unvorhersehbar. Wenn Sie verschiedene Städte/Regionen verbinden, gehen Sie davon aus, dass die Verzögerung aufgrund der geografischen Lage der Regionen geringer sein wird, aber Sie erhalten genau das Gegenteil.
- Das Internet und die Kommunikationskanäle sind entweder schnell oder langsam. Es besteht eine leichte Abhängigkeit von der Tageszeit und dem Wochentag, jedoch nicht immer.
- DNS-Anfragen aus China an die Außenwelt überschreiten manchmal das erlaubte Timeout.
Das Bild, das sich ergibt, ist einfach „exzellent“.
Das Rechenzentrum befindet sich, wie ich bereits sagte, im Osten der USA und das gesamte SEMrush besteht aus Dutzenden miteinander verbundenen Produkten, Backends, Frontends, Datenbanken und das alles im DC und in den Clouds. Wir als Team von Systemadministratoren erhielten die Aufgabe, mit geringem Aufwand schnell in China zu arbeiten.
Wir mussten eine wichtige Frage beantworten: Ist es möglich, mit geringem Aufwand auszukommen und alle Probleme im Zusammenhang mit dem chinesischen Internet und der Firewall auf Netzwerk-/Cloud-/Serverebene zu lösen?
Wir begannen mit dem Empfangen .
ICP-Lizenz
Um Ihren Dienst in China (Festlandchina) hosten und Tests durchführen zu können, müssen Sie zunächst eine ICP-Lizenz für die Domain erwerben.
Wenn der Benutzerverkehr Ihrer Website auf dem chinesischen Festland beendet wird und Ihre Domain nicht über eine ICP-Lizenz verfügt, wird Ihr Datenverkehr auf der ISP-/Hosting-Seite blockiert. Interessanterweise umfasst die ICP-Lizenz einen bestimmten Anbieter, sei es Cloudflare oder Alibaba Cloud. Wenn Sie also eine ICP-Lizenz für Cloudflare erhalten und Ihre Website dort gehostet haben, können Sie nicht „nahtlos“ zur Alibaba Cloud wechseln. Sie müssen dieser Lizenz ein weiteres Hosting hinzufügen.
Durch den Erhalt einer ICP-Lizenz für die Domain konnten wir konkrete technische Ideen und Lösungen entwickeln und umsetzen.
Lösungen testen
Aber bevor Sie direkt Staging-Optionen erstellen, an den Knöpfen drehen, die Leistung und Geschwindigkeit der Website optimieren, müssen Sie ein Tool zum Testen auswählen, um zu sehen, welche unserer Aktionen die Leistung der Website verbessern oder im Gegenteil verschlechtern.
Unser Testtool musste zwei Hauptanforderungen erfüllen:
- es sollte in der Lage sein, Tests von China aus durchzuführen,
- Es muss Browsertests haben.
So haben wir es gefunden ! Sie verfügen über eine hervorragende Abdeckung von Teststandorten auf der ganzen Welt. In China können über dieses Tool auch Tests aus 100500 Provinzen durchgeführt werden. Jeder hat mehrere verschiedene Anbieter + die Möglichkeit dazu Backbone (Rückgrat)-Tests (so etwas wie eine virtuelle Maschine in einem Rechenzentrum) und Letzte Meile-Tests (so nah wie möglich an den Benutzerbedingungen, auch bekannt als Workstation). Letztere Art von Tests ist teurer.
Nachdem wir einen Jahresvertrag abgeschlossen hatten (weniger als dieser ist nicht möglich), begannen wir, das Instrument zu studieren. Ehrlich gesagt waren wir von der Funktionalität angenehm überrascht. Du kannst rennen:
- DNS-Tests,
- Webtests (Browsertests, einfaches GET/POST, mobile Client-Emulation usw.),
- Transaktionsprüfungen (z. B. Login),
- API-Tests,
- Ping, Traceroute, NTP usw.
Man kann nicht alles auflisten. Und am wichtigsten ist, dass jeder Test durch das Hinzufügen einer Reihe von Headern und anderen Parametern recht gut angepasst werden kann. Die Ausgabe ist eine riesige Menge an Informationen, die Ihren Test vollständig beschreiben. Wenn wir über die für uns interessantesten Dinge sprechen (Browsertests), ergibt sich folgendes Ergebnis:
- Verbinden, Warten, Laden, SSL, DNS-Zeit,
- TTFB, TTLB, Dokument abgeschlossen, Renderzeit, DOM-Last,
- 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, mittlere Zeit
- Etc
Dementsprechend eignen sich alle diese Kennzahlen hervorragend, um Veränderungen zu erkennen und zu verstehen, ob sich die Dinge verbessert haben. Wir haben uns hauptsächlich angeschaut Antwort, Webseiten-Antwort, Median, 75. und 95. Perzentil.
Eine wichtige Frage, die von Anfang an im Raum stand: Können Sie Catchpoint vertrauen?? Spiegelt dieses Tool die tatsächliche Ladegeschwindigkeit von Websites in China aus verschiedenen Städten wider oder handelt es sich nur um eine Art Test im luftleeren Raum, der nichts mit der tatsächlichen Benutzererfahrung zu tun hat?
Dies ist ein großes Problem, da es in Russland fast unmöglich ist, zuverlässig herauszufinden, wie eine Website aus China funktioniert. Durch die Ausführung eines Socks-Proxys über eine virtuelle Maschine führt das Endergebnis dazu, dass die Site innerhalb weniger Minuten geladen wird, was für Tests einfach inakzeptabel ist. Daher ist die einzige Option für manuelle Tests Curl und einfaches GET von der Konsole mit einem Timer . Das hilft, weil dieser Test die Geschwindigkeit der Netzwerklösung gut widerspiegelt und wenn es auch Browsertests gibt, dann ist er sehr gut.
Später reisten wir selbst nach China und waren davon überzeugt Sie können Catchpoint vertrauen; es spiegelt die tatsächlichen Leistungsindikatoren ziemlich genau wider.
Cloudflare China-Netzwerk
Da wir Cloudflare erfolgreich für die Hauptdomain semrush.com nutzen, haben wir uns entschieden, die Funktion namens „Cloudflare“ sofort auszuprobieren . Diese Option ist nur für Enterprise-Sites auf gesonderte Anfrage und gegen eine zusätzliche Gebühr freigeschaltet. Es ist außerdem nur für Websites verfügbar, die über eine entsprechende ICP-Lizenz verfügen, in der Cloudflare als Anbieter aufgeführt ist. Nach der Aktivierung wird das „chinesische CDN“ von Cloudflare für die Site verfügbar – Datenverkehr aus chinesischen Regionen landet beim nächstgelegenen PoP (Points of Presence) CF und wird dann über dessen Netzwerke oder die Netzwerke von Anbietern/Partnern an den Ursprungsort weitergeleitet .
Das Diagramm dieses Prüfstands ist unten dargestellt.
Das ist eine tolle Option für uns. Es stellt sich heraus, dass die zweite Domäne auch für CF sein wird, was die Anzahl der im Unternehmen verwendeten Lösungen nicht erhöht und auch die Infrastruktur praktisch nicht verkompliziert.
Wir haben Browsertests durchgeführt und Folgendes ist passiert:
Rote Rauten sind Testfehler. Bei den folgenden Dateien handelt es sich um DNS-Fehler (Zeitüberschreitung bei der Lösung). Die Fehler oben sind Zeitüberschreitungen.
Betriebszeit: 86.6
Median: 18s
75. Perzentil: 29.3 s
95. Perzentil: 60 s
Median, nachdem die Belastung entfernt wurde reCaptcha (Google-Dienst in China blockiert) von 28 auf 18 Sekunden gesunken. Aber das sind immer noch schreckliche Ergebnisse, wenn man bedenkt, dass der gleiche Test für semrush.com (aus den USA) bei 10 % der Benutzer (aus den USA) weniger als 95 Sekunden auf derselben Seite (statisch + dynamisch) ergab.
Sie können in jeden Test gehen und nachschauen Wasserfall und andere detailliertere Parameter. Wir haben begonnen, die Gründe für die Fehler zu untersuchen, und wenn bei den Zeitüberschreitungen alles mehr oder weniger klar ist: Das Internet in China „bewegt sich rein und raus“, aus diesem Grund ist die Geschwindigkeit der Verbindung und das Laden von Ressourcen aus dem Ausland instabil und ungleichmäßig. Dann haben uns die DNS-Fehler sehr überrascht. Wir haben das gefunden Pop Cloudflare befindet sich tatsächlich in China, die Site-Adresse wird in eine Anycast-IP aufgelöst, die DNS-Server sind jedoch amerikanisch, weshalb DNS-Anfragen gezwungen sind, über die Grenze zu gehen, sodass sie manchmal fehlschlagen.
Nachdem ich diese Frage mit CF geklärt hatte, stellte sich heraus, dass dies der Fall war Sie haben in China keine eigenen DNS-Server, und wann es sein wird, ist noch unbekannt.
Aus diesem Grund haben wir uns entschieden, nur Cloudflare-DNS zu testen und haben den Cloudflare-Betriebsmechanismus für unsere Website auf „Nur DNS" Dies ist ein Modus, in dem Cloudflare den Datenverkehr nicht über sich selbst weiterleitet, was bedeutet, dass es keinen DDoS-Schutz, kein CDN und keine anderen Funktionen bietet und im Modus eines regulären DNS-Servers arbeitet.
Dieser Ständer ist in der folgenden Abbildung schematisch dargestellt. Die Zahl berücksichtigt die zunehmende Erkenntnis, dass sich die DNS-Server von Cloudflare hinter einer Firewall befinden.
Bei Catchpoint haben wir einfache GET-Tests (keine Browsertests) durchgeführt, die viele Fehler zeigten. Sie wurden durch dieselben DNS-Fehler verursacht.
Wir haben mit dem Debuggen dieser Fehler begonnen graben und stellte fest, dass die Adresse bei der ersten Anfrage korrekt ermittelt wurde, und bei wiederholter Anfrage erhalten wir sie jedes Mal SERVFAIL и nicht gefunden. Warum passiert das plötzlich?
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)Bei der direkten Abfrage von Cloudflare NS-Servern treten keine derartigen Fehler auf:
root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Using domain server:
Name: ray.ns.cloudflare.com.
Address: 173.245.59.138#53
Aliases:
semrushchina.cn has address 220.170.186.192
semrushchina.cn has address 220.170.186.192
Using domain server:
Name: ray.ns.cloudflare.com.
Address: 173.245.59.138#53
Aliases:
semrushchina.cn has address 220.170.186.192
semrushchina.cn has address 220.170.186.192Das bedeutet, dass das Problem auf der Seite des „lokalen“ DNS-Servers oder des Servers des Anbieters liegt.
Weitere Untersuchungen ergaben das SERVFAIL wir kommen zur Entschlossenheit AAAA-Aufzeichnungen.
Das stellte sich bei einer Anfrage bei Cloudflare heraus AAAA-Datensatz, der in der Domäne nicht existiert, antwortete Cloudflare А-ein Eintrag, der einen Fehler und eine Nichteinhaltung des RFC darstellt. Warum funktioniert der lokale Resolver (xxxx) Es gefiel mir nicht und er antwortete SERVFAIL. Dieses Verhalten ist im folgenden Protokoll 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
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55467
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;semrushchina.cn. IN AAAA
;; Query time: 334 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; WHEN: Tue Aug 14 23:38:50 CST 2018
;; MSG SIZE rcvd: 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.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63944
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;semrushchina.cn. IN AAAA
;; ANSWER SECTION:
semrushchina.cn. 300 IN A 220.170.186.192
;; Query time: 185 msec
;; SERVER: 173.245.58.105#53(173.245.58.105)
;; WHEN: Tue Aug 14 23:43:03 CST 2018
;; MSG SIZE rcvd: 60
Wir haben einen Fehlerbericht an Cloudflare gesendet und dieser wurde nach einiger Zeit behoben. Es stellte sich als interessant heraus: Derzeit gibt es in China noch keine IPv6-Unterstützung, sodass Cloudflare dort auf Anfrage seine IPv6-Adresse nicht herausgeben konnte AAAA-Aufzeichnungen. Am Ende wurde alles so gelöst, dass Cloudflare begann, für China einzustehen KEINE DATEN auf solche Anfragen.
Dadurch gingen DNS-Fehler bei Catchpoint-Tests stark zurück, jedoch nicht vollständig. Es gibt immer noch Timeouts:
Und wir begannen, nach einer anderen Lösung zu suchen.
Im nächsten Teil erzähle ich Ihnen, wie wir die chinesische Cloud getestet haben Alibaba-Wolke, wie wir mit Hilfe einer kleinen „Magie“ von Nginx schnell PoC-Lösungen (Proof of Concept) erstellen konnten, wie wir Multi-Cloud-Lösungen erstellt haben, von denen eine letztendlich erheblich dazu beigetragen hat, die Arbeit des Dienstes zu beschleunigen aus China.
Bleib dran!
Nächste Teile
Source: habr.com
