Hallo allemaal!
Aan de lijn is Nikita - systeemingenieur bij het bedrijf SEMrush. Vandaag zal ik u vertellen over de taak die we kregen om de stabiliteit van onze dienst semrush.com in China te waarborgen en met welke problemen we te maken kregen tijdens de uitvoering ervan (gezien de locatie van ons datacenter aan de oostkust van de VS).
Dit wordt een groot verhaal, verdeeld over meerdere artikelen. Ik zal vertellen hoe alles voor ons was: van een volledig niet-functionerende dienst vanuit China tot de prestatie-indicatoren van de dienst op het niveau van de Amerikaanse versie voor Amerikanen. Ik beloof dat het interessant en nuttig zal zijn. Laten we beginnen.
Problemen van het Chinese internet
Zelfs de meest onervaren persoon op het gebied van netwerkbeheer heeft minstens één keer gehoord van de Grote Chinese Firewall. Oeh, dat klinkt spannend, toch? Maar wat is het, hoe werkt het eigenlijk - dat is een vrij complexe vraag. Op het internet zijn er veel artikelen die aan dit onderwerp zijn gewijd, maar vanuit technisch oogpunt wordt de werking van deze firewall nergens uitgebreid beschreven. Wat overigens niet verwonderlijk is. Ik moet eerlijk zeggen dat ik na een jaar werken niet precies kan zeggen hoe het functioneert, maar ik kan wel mijn observaties en praktische conclusies met u delen. Laten we beginnen met de geruchten over deze firewall.
Er zijn veel geruchten over deze firewall. Laten we de belangrijkste en meest interessante ervan in één lijst verzamelen:
- Google, Facebook, Twitter en andere soortgelijke diensten zijn geblokkeerd en werken niet in China.
- Alle verkeer dat UIT China en NAAR China gaat, wordt geanalyseerd en beperkt met behulp van machine learning (in het geval van verdacht verkeer), wat het verkeer dat door de grens gaat aanzienlijk vertraagt.
- Chinese inlichtingendiensten kunnen elk versleuteld verkeer dat door hun firewall gaat, hacken.
- VPN-tunnels, IPSEC-tunnels zijn onbetrouwbaar, vallen vaak uit en worden voortdurend geblokkeerd.
- Hoe eenvoudiger de encryptie en hoe eenvoudiger de passphrase die voor authenticatie/encryptie van het verkeer wordt gebruikt, des te sneller het door de Chinese firewall gaat.
Dit is wat we hebben kunnen achterhalen over deze geruchten:
- Google, Facebook, Twitter en andere soortgelijke diensten zijn inderdaad geblokkeerd (uw K.O.), maar veel technische domeinen van Google, zoals gstatic.com, zijn niet geblokkeerd en werken. Hieruit volgt de conclusie: het is niet raadzaam om alles wat van Google of andere ogenschijnlijk geblokkeerde bronnen komt, blindelings te blokkeren.
- Alle verkeer dat de grens oversteekt, voegt echt een aanzienlijke vertraging toe aan zijn tijd. Kijk naar de twee resultaten. Eén website, één pagina, eenvoudige GET curl’om. De eerste meting vanuit China zelf (prachtige stad Shenzhen). De tweede meting van buitenaf uit Hongkong (heeft soevereiniteit en er is geen firewall tussen hem en de wereld). De afstand tussen de steden in een rechte lijn is ongeveer 30-40 km.
nikita@china-shenzhen:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
% Totaal % Ontvangen % Xferd Gemiddelde Snelheid Tijd Tijd Tijd Huidige
Dload Upload Totaal Besteed Over Snelheid
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_totaal: 5.443407
----------
grootte_download: 390968 Bytes
snelheid_download: 71824.000B/s
nikita@china-hongkong:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
% Totaal % Ontvangen % Xferd Gemiddelde Snelheid Tijd Tijd Tijd Huidige
Dload Upload Totaal Besteed Over Snelheid
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_totaal: 0.124871
----------
grootte_download: 326755 Bytes
snelheid_download: 2616740.000B/sLet op de time_connect. En in het algemeen, u ziet het resultaat: de firewall voegt 4 extra seconden toe, wat dramatisch lang is.
- VPN's en IPSEC-tunnels vallen inderdaad vaak uit. Hierover zal ik later meer en gedetailleerder vertellen. VPN-servers die door gebruikers worden gebruikt, worden na verloop van tijd geblokkeerd (meestal binnen 24 uur na de eerste gebruik).
- Er is een mening, verkregen van mensen die in China wonen, dat hoe eenvoudiger de versleuteling van verkeer is, hoe sneller het de grens overgaat, omdat het gemakkelijk te begrijpen is dat er niets illegaals in zit. Evenzo krijgt 'schoon' verkeer meer bandbreedte en doorvoersnelheid, terwijl 'vies' verkeer, waarin niets te onderscheiden is, juist een langzamere doorgang krijgt. Als voorbeeld neem ik curl tot ifconfig.co over het HTTPS- en HTTP-protocol.
curl -o /dev/null -w@curl_time "https://ifconfig.co/"
% Totaal % Ontvangen % Xferd Gemiddelde Snelheid Tijd Tijd Tijd Huidig
Dload Upload Totaal Bestede Over Snelheid
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/"
% Totaal % Ontvangen % Xferd Gemiddelde Snelheid Tijd Tijd Tijd Huidig
Dload Upload Totaal Bestede Over Snelheid
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/sHet verschil van 5 seconden in totale laadtijd van 13 bytes. Als je deze test meerdere keren uitvoert, zie je dat de GET op HTTP in het algemeen elke keer in een vergelijkbare tijd eindigt, terwijl de HTTPS-site soms antwoordt in 3, 5, 10 en zelfs 17 seconden. Soms zijn er SSL-fouten:
Onbekende SSL-protocolfout in verbinding met ifconfig.co:443.
Dus, wat hebben we:
- De problemen die door de Chinese firewall worden veroorzaakt, zoals hierboven beschreven.
- Pingen naar externe bronnen en binnen tunnels valt af en toe weg.
- De latentie tussen twee punten verandert voortdurend en is vaak onvoorspelbaar. Wanneer je verschillende steden/regio's verbindt, verwacht je dat de vertraging op basis van de geografische ligging van de regio's kleiner zal zijn, maar je krijgt juist het tegenovergestelde.
- Internet en verbindingen werken soms snel, soms traag. Hier is er een kleine afhankelijkheid van het tijdstip van de dag en de dag van de week, maar niet altijd.
- DNS-verzoeken naar de buitenwereld vanuit China overschrijden soms de toegestane timeout.
Het beeld dat zich aftekent is gewoon 'geweldig'.
Datacenter, zoals ik al zei, bevindt zich aan de oostkust van de VS, en SEMrush bestaat uit tientallen onderling verbonden producten, backends, frontends, databases, en dat alles in datacenters en cloud. Ons team van systeembeheerders kreeg de taak om met minimale inspanning snel in China te gaan werken.
We moesten een belangrijke vraag beantwoorden: kunnen we het met weinig moeite oplossen en alle problemen met het Chinese internet en de firewall op netwerk-/cloud-/serverniveau aanpakken?
We begonnen met het verkrijgen van .
ICP-licentie
Om in staat te zijn om je service binnen China (Mainland China) te hosten en tests uit te voeren, moet je eerst een ICP-licentie voor het domein verkrijgen.
Als het gebruikersverkeer van uw website in het vasteland van China wordt beëindigd en uw domein geen ICP-licentie heeft, zal uw verkeer worden geblokkeerd aan de kant van de provider / hosting. Interessant is dat in de ICP-licentie een specifieke provider wordt vermeld, of het nu Cloudflare of Alibaba Cloud is. Daarom, als u een ICP-licentie voor Cloudflare heeft verkregen en uw site bij hen heeft gehost, kunt u niet 'naadloos' naar Alibaba Cloud verhuizen. U zult deze licentie met een andere hosting moeten aanvullen.
Door een ICP-licentie voor het domein te verkrijgen, konden we specifieke technische ideeën en oplossingen bedenken en implementeren.
Oplossingen testen
Maar voordat we daadwerkelijk varianten van staging aanmaken, aan de knoppen draaien, de prestaties en snelheid van de website optimaliseren, moeten we een tool kiezen voor het testen ervan, zodat we kunnen zien welke acties de werking van de site verbeteren of juist verslechteren.
Onze testtool moest voldoen aan twee belangrijke eisen:
- het moet tests vanuit China kunnen uitvoeren,
- het moet browsertests kunnen uitvoeren.
Zo vonden we !, Ze hebben een uitstekende dekking met testlocaties over de hele wereld. Met deze tool kunnen tests ook vanuit 100500 provincies in China worden uitgevoerd. In elke provincie zijn er verschillende providers + de mogelijkheid om Backbone-tests (iets als een virtuele machine in een datacenter) en Lastmile-tests (maximaal benaderd aan de gebruikersomstandigheden, aka werkstation). De laatste soort tests is duurder.
Nadat we een jaarcontract hebben afgesloten (minder kan niet), begonnen we de tool te bestuderen. We moeten toegeven dat we aangenaam verrast waren door de functionaliteiten. Je kunt uitvoeren:
- DNS-tests,
- Webtests (browser, eenvoudige GET/POST, emulatie van mobiele clients, enz.),
- Transactietests (bijvoorbeeld login),
- API-tests,
- Ping, traceroute, NTP, enz.
Je kunt niet alles opsommen. En het belangrijkste is dat elke test behoorlijk goed kan worden aangepast, met een reeks headers en andere parameters. Het resultaat is een enorme hoeveelheid informatie die uw test volledig beschrijft. Wat het meest interessant voor ons is (browsertests), omvat het resultaat:
- Connect, Wait, Load, SSL, DNS-tijd,
- TTFB, TTLB, Document compleet, Render tijd, DOM-laden,
- Response (iets als de tijd tot de eerste byte), Webpagina-respons (iets als de tijd tot de laatste byte),
- Alle percentielen, Gemiddelde, Mediaan tijd
- enz.
Dientengevolge helpen al deze metrics uitstekend om veranderingen te zien en te begrijpen of het beter is geworden. We keken voornamelijk naar Response, Webpagina Respons, Mediaan, 75 en 95 Percentielen.
Een belangrijke vraag die vanaf het begin in de lucht hing: kun je Catchpoint vertrouwen?? Отражает ли этот инструмент реальную скорость загрузки сайта в Китае из разных городов или же это просто какой-то тест в вакууме, не имеющий ничего общего с real user experience?
Dit is een groot probleem, omdat het vanuit Rusland bijna onmogelijk is om betrouwbaar te weten hoe een website vanuit China werkt. Door een socks-proxy via een virtuele machine te gebruiken, duurt het enkele minuten voordat de website geladen is, wat onaanvaardbaar is voor tests, zodat de enige optie voor handmatige testing blijft om curl en simpele GET-oproepen vanuit de console met tijdmeting te gebruiken. Dit helpt omdat deze test goed de snelheid van de netwerkoplossing weergeeft, en als er ook browser tests zijn, is dat alleen maar beter.
Later zijn we zelf naar China gereisd en hebben we bevestigd dat je op Catchpoint kunt vertrouwen, het weerspiegelt de werkelijke snelheidsresultaten redelijk nauwkeurig.
Cloudflare China Network
Aangezien we voor de hoofdwebsite semrush.com met succes Cloudflare gebruiken, besloten we meteen hun functie genaamd . Deze optie wordt alleen ingeschakeld voor Enterprise-websites op verzoek en tegen een aparte vergoeding. Ook is het alleen beschikbaar voor websites met een passende ICP-licentie, waarin Cloudflare als provider is vermeld. Na inschakeling is de 'Chinese CDN' van Cloudflare beschikbaar voor de website — verkeer uit Chinese regio's wordt afgeleverd in de dichtstbijzijnde PoP (Points of Presence) van CF, en vanaf daar wordt het via zijn netwerken of de netwerken van providers / partners naar de origin geleverd.
Het schema van deze testopstelling is hieronder weergegeven.
Voor ons is dit een prachtige optie. Het blijkt dat de tweede domein ook onder CF zal vallen, wat niet bijdraagt aan het aantal oplossingen dat in het bedrijf wordt gebruikt en de infrastructuur praktisch niet compliceert.
We hebben browser tests uitgevoerd, en dit is wat eruit kwam:
De rode diamanten zijn testfaalgevallen. Faaltests onderaan zijn DNS-fouten (resolve timeout). Faaltests bovenaan zijn time-outs.
Uptime: 86.6
Mediaan: 18s
75 Percentiel: 29.3s
95 Percentiel: 60s
De mediaan, nadat we de laadboost verwijderd hebben reCaptcha (de Google-service, geblokkeerd in China), daalde van 28 naar 18 seconden. Maar dit zijn nog steeds verschrikkelijke cijfers, gezien het feit dat een gelijke test voor semrush.com (uit de VS) minder dan 10 seconden gaf voor 95% van de gebruikers (uit de VS) op dezelfde pagina (statisch + dynamisch).
In elke test kan je binnenkomen en kijken Waterfall en andere meer gedetailleerde parameters. We zijn begonnen met het onderzoeken van de oorzaken van fouten, en als de timeouts min of meer duidelijk zijn: internet in China is "soms stabiel, soms niet", waardoor de verbindingssnelheid en de laadtijden van middelen van buitenaf onbetrouwbaar en variabel zijn, dan waren we zeer verrast door de DNS-fouten. We ontdekten dat PoP Cloudflare inderdaad in China zijn, de website adresseert naar één anycast IP, maar Amerikaanse DNS-servers worden gebruikt, waardoor DNS-verzoeken gedwongen de grens moeten oversteken, en daarom soms mislukken.
Na dit vraagstuk bij CF te hebben verduidelijkt, bleek dat ze geen eigen DNS-servers in China hebben, en wanneer ze die zullen hebben, is voorlopig onbekend.
Daarom hebben we besloten om alleen de DNS van Cloudflare te testen en het werkmechanisme van Cloudflare voor onze website te veranderen naar de modus "Alleen DNS". Dit is een modus waarbij Cloudflare het verkeer niet via zichzelf proxiet, wat betekent dat er geen DDoS-bescherming, CDN en andere functies worden aangeboden, en die functioneert als een gewone DNS-server.
Deze opstelling is schematisch weergegeven in de volgende afbeelding. In de afbeelding is rekening gehouden met de opgedane kennis dat de DNS-servers van Cloudflare achter de firewall zijn.
Bij Catchpoint hebben we eenvoudige GET-tests (geen browser-tests) uitgevoerd, die veel fouten toonden. De oorzaak daarvan waren dezelfde DNS-fouten.
We zijn deze fouten gaan debuggen met behulp van niet in dit artikel te gebruiken. en ontdekten dat bij de eerste aanvraag het adres correct wordt bepaald, maar bij de herhaalde aanvraag krijgen we elke keer SERVFAIL en not found. Hoe kan dat plotseling?
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn heeft adres 220.170.186.192
Host semrushchina.cn niet gevonden: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn heeft adres 220.170.186.192
Host semrushchina.cn niet gevonden: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn heeft adres 220.170.186.192
Host semrushchina.cn niet gevonden: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn heeft adres 220.170.186.192
Host semrushchina.cn niet gevonden: 2(SERVFAIL)Bij het rechtstreeks opvragen van de NS-servers van Cloudflare zijn er geen dergelijke fouten:
root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Gebruik makend van domeinserver:
Naam: ray.ns.cloudflare.com.
Adres: 173.245.59.138#53
Aliassen:
semrushchina.cn heeft adres 220.170.186.192
semrushchina.cn heeft adres 220.170.186.192
Gebruik makend van domeinserver:
Naam: ray.ns.cloudflare.com.
Adres: 173.245.59.138#53
Aliassen:
semrushchina.cn heeft adres 220.170.186.192
semrushchina.cn heeft adres 220.170.186.192Dat betekent dat het probleem aan de kant van de "lokale" DNS-server of de server van de provider ligt.
Verdere onderzoeken hebben aangetoond dat SERVFAIL we bij de resolutie AAAA-records krijgen.
Het bleek dat bij het opvragen bij Cloudflare AAAA-record die niet bestaat in het domein, antwoordde Cloudflare A-record, wat een fout is en niet in overeenstemming met RFC. Daarom vond de lokale resolver (x.x.x.x) dit niet leuk en antwoordde hij SERVFAIL. Dit gedrag is duidelijk zichtbaar in de onderstaande log:
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 opties: +cmd
;; Ontvangen antwoord:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55467
;; vlaggen: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: versie: 0, vlaggen:; udp: 4096
;; Vraagsectie:
;semrushchina.cn. IN AAAA
;; Vraag tijd: 334 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; WANNEER: Di 14 aug 23:38:50 CST 2018
;; MSG GROOTE ontvangen: 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 opties: +cmd
;; Ontvangen antwoord:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63944
;; vlaggen: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WAARSCHUWING: recursie aangevraagd maar niet beschikbaar
;; OPT PSEUDOSECTION:
; EDNS: versie: 0, vlaggen:; udp: 512
;; Vraagsectie:
;semrushchina.cn. IN AAAA
;; ANTWOORDSECTIE:
semrushchina.cn. 300 IN A 220.170.186.192
;; Vraag tijd: 185 msec
;; SERVER: 173.245.58.105#53(173.245.58.105)
;; WANNEER: Di 14 aug 23:43:03 CST 2018
;; MSG GROOTE ontvangen: 60
We hebben een bugrapport naar Cloudflare gestuurd en zij hebben dit na enige tijd gecorrigeerd. Het bleek interessant: op dit moment is er nog steeds geen ondersteuning voor IPv6 in China, waardoor Cloudflare daar zijn IPv6-adres niet kon geven als antwoord op verzoeken AAAA-records. Uiteindelijk werd het zo opgelost, dat Cloudflare voor China begon te antwoorden NODATA op dergelijke verzoeken.
Zo zijn de DNS-fouten in de Catchpoint-tests drastisch verminderd, maar niet volledig. Time-outs zijn ook niet verdwenen:
En we begonnen naar een andere oplossing te zoeken.
In het volgende deel vertel ik hoe we de Chinese cloud hebben getest Alibaba Cloud, hoe we met een beetje 'magie' van Nginx snel PoC (Proof of Concept) oplossingen konden creëren, hoe we Multi-Cloud oplossingen hebben gecreëerd, waarvan er een uiteindelijk de werking van de service uit China aanzienlijk heeft versneld.
Blijf op de hoogte!
Volgende delen
Bron: habr.com
