🥇Hur vi bröt igenom Den Stora Kinesiska Brandväggen (del 1)

Hej alla!

Förbindelse här, Nikita – systemingenjör från företaget SEMrush. Idag ska jag berätta för er hur vi ställdes inför uppgiften att säkerställa stabiliteten hos vår tjänst semrush.com i Kina, och vilka problem vi stötte på under genomförandet (med tanke på platsen för vårt datacenter på USA:s östkust).

Det här kommer att bli en lång historia, uppdelad i flera artiklar. Jag ska berätta hur allt gick till hos oss: från en helt oanvändbar tjänst i Kina, till prestanda som matchade den amerikanska versionen för amerikaner. Jag lovar, det kommer bli intressant och nyttigt. Så, låt oss köra.

Kinas internetproblem

Även den mest avlägsna personen från nätverksadministration har åtminstone en gång hört talas om Den Stora Kinesiska Brandväggen. Uuu, låter coolt, eller hur? Men vad är det, hur fungerar det egentligen – frågan är ganska komplex. Det finns många artiklar på internet som handlar om detta, men ur teknisk synvinkel beskrivs enheten av denna brandvägg sällan. Vilket, förresten, inte är förvånande. Jag erkänner direkt, efter ett års arbete kan jag inte säga exakt hur den fungerar, men jag kan berätta om mina observationer och praktiska slutsatser. Och vi börjar med ryktena om denna brandvägg.

Det finns många rykten om denna brandvägg. Låt oss sammanställa de viktigaste och mest intressanta av dem i en lista:

Google, Facebook, Twitter och andra liknande tjänster är blockerade och fungerar inte i Kina.
All trafik som går UT ur Kina och IN i Kina analyseras och begränsas med hjälp av maskininlärning (vid misstänkt trafik), vilket kraftigt saktar ner den (trafiken) när den passerar gränsen.
Kinas säkerhetstjänster kan bryta krypterad trafik som går genom deras brandvägg.
VPN-tunnlar och IPSEC-tunnlar är instabila, faller och blockeras ständigt.
Ju enklare kryptering, desto enklare lösenfras som används för autentisering/kryptering av trafiken, desto snabbare passerar den genom den kinesiska brandväggen.

Här är vad vi har lyckats ta reda på om dessa rykten:

Google, Facebook, Twitter och andra liknande tjänster är faktiskt blockerade (din KO), men många tekniska domäner från Google, exempelvis, är inte blockerade och fungerar (som gstatic.com). Därför följer slutsatsen: det är inte klokt att avfärda alla Google och andra resurser som verkar vara blockerade.
All traffic crossing the border significantly increases its delay. Take a look at two results. One site, one page, simple GET curlfrom. The first measurement is from China (the beautiful city of Shenzhen). The second measurement is from outside in Hong Kong (which has sovereignty, and there is no firewall between it and the world). The distance between the cities is approximately 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/s

Observera time_connect. And overall, you see the result: the firewall adds 4 extra seconds, which is extremely long.

VPN and IPSEC tunnels do indeed often drop. I will discuss this in more detail later. VPN servers used by users are blocked over time (usually within a day after use starts).
There is an opinion, shared by people living in China, that the simpler the traffic encryption, the faster it crosses the border, because it is easier to understand that there is nothing illegal in it. Similarly, 'clean' traffic receives more bandwidth and speed, while 'dirty' traffic, which is harder to decipher, experiences a slower passage. For example, I will refer to curl to ifconfig.co over the HTTPS and HTTP protocols.

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

Skillnaden på 5 sekunder för den totala laddningstiden av 13 byte. Under flera tester kan man se att GET på HTTP vanligtvis tar ungefär samma tid varje gång, medan HTTPS-svaren varierar mellan 3, 5, 10 och till och med 17 sekunder. Ibland förekommer SSL-fel:

Okänt SSL-protokollfel i anslutning till ifconfig.co:443.

Så vad har vi?

Problem som orsakas av den kinesiska brandväggen som beskrivits ovan.
Pingar till externa resurser och inom tunnlar försvinner periodiskt.
Latensen mellan två punkter förändras ständigt och är ofta oförutsägbar. När man kopplar olika städer/regioner förväntar man sig att latensen ska vara lägre, baserat på deras geografiska läge, men får ofta motsatt resultat.
Internet och kommunikationskanaler fungerar ibland snabbt, ibland långsamt. Det finns en viss beroende av tid på dagen och veckodag, men det är inte alltid konsekvent.
DNS-förfrågningar till omvärlden från Kina överskrider ibland den tillåtna tidsgränsen.

Bilden som målas upp är helt enkelt "utmärkt".

Datacentret, som jag redan nämnt, ligger i östra USA, och hela SEMrush består av dussintals sammanlänkade produkter, backend-system, frontend-gränssnitt, databaser, allt detta är i datacentret och i molnet. Vårt team av systemadministratörer fick i uppdrag att snabbt och effektivt arbeta i Kina.

Vi behövde besvara en viktig fråga: kan vi med små insatser lösa alla problem relaterade till den kinesiska internetanvändningen och brandväggen på nätverks-/moln-/servernivå?

Vi började med att få ICP-licensen.

ICP-licens

För att kunna driva vår tjänst inom Kina (Mainland China) och utföra tester behöver vi först få ICP-licensen för domänen.

Om webbtrafiken från din användare termineras inom Fastlandskina och din domän saknar en ICP-licens, kommer din trafik att blockeras av leverantören/värden. Det är intressant att en specifik leverantör, oavsett om det är Cloudflare eller Alibaba Cloud, nämns i ICP-licensen. Om du har fått en ICP-licens för Cloudflare och har hostat din webbplats där, kommer det inte att vara möjligt att "smidigt" flytta den till Alibaba Cloud senare. Du måste lägga till en ytterligare hosting i denna licens.

När vi fick ICP-licensen för domänen kunde vi börja ta fram och implementera specifika tekniska idéer och lösningar.

Testning av lösningar

Men innan vi direkt skapar staging-alternativ, justerar inställningar, och optimerar webbplatsens prestanda och hastighet, är det nödvändigt att välja verktyget för att testa webbplatsen, så att vi kan se vilka åtgärder som förbättrar eller försämrar dess funktion.

Vårt testverktyg måste uppfylla två huvudkrav:

det ska kunna köra tester från Kina,
det ska erbjuda webbläsartester.

Så vi hittade Catchpoint! De har utmärkt täckning med testpunkter världen över. I Kina kan tester också köras genom detta verktyg från ett stort antal provinser. I varje provins finns flera olika leverantörer + möjligheten att göra Backbone-tester (något i stil med en virtuell maskin i datacentret) och Lastmile-tester (maximalt nära användarens förhållanden, d.v.s. arbetsstation). Den sista typen av tester kostar mer.

Genom att teckna ett årligt avtal (mindre är inte möjligt) började vi studera verktyget. Vi måste erkänna att vi blev glatt överraskade av dess funktionalitet. Man kan köra:

DNS-tester,
Web-tester (webbläsartester, enkel GET/POST, emulering av mobilklient etc.),
Transaktionskontroller (t.ex. inloggning),
API-tester,
Ping, traceroute, NTP, etc.

Man kan inte räkna upp allt. Och det mest intressanta för oss (webbläsartester) är att resultatet inkluderar:

Connect, Wait, Load, SSL, DNS-tid,
TTFB, TTLB, Dokument komplett, Render-tid, DOM-laddning,
Svar (något nära Time To First Byte), Webbsvars-tid (något nära Time To Last Byte),
Eventuella percentiler, Genomsnitt, Median tid
och så vidare.

Därför hjälper dessa mätningar oss att se förändringar och förstå om det har blivit bättre. Vi har främst tittat på Response, Webpage Response, Median, 75 och 95 percentiler.

En viktig fråga som hängde i luften från början: kan man lita på Catchpoint? Отражает ли этот инструмент реальную скорость загрузки сайта в Китае из разных городов или же это просто какой-то тест в вакууме, не имеющий ничего общего с real user experience?
Det är ett stort problem, eftersom det är nästan omöjligt att på ett tillförlitligt sätt ta reda på hur en webbplats från Kina fungerar när man befinner sig i Ryssland. Genom att använda en socks-proxy via en virtuell maskin får man en webbplatsladdning på ett par minuter, vilket är oacceptabelt för tester; därför återstår curl och enkla GET-anrop från konsolen med tidsmätning som det enda alternativet för manuell testning. Detta är till hjälp eftersom detta test väl återspeglar hastigheten på nätverkslösningen, och om det dessutom finns webbläsartester så är det helt okej.

Senare reste vi själva till Kina och kunde bekräfta att man kan lita på Catchpoint, den återspeglar hastighetsresultaten ganska exakt.

Cloudflare China Network

Eftersom vi framgångsrikt använder Cloudflare för vår huvuddomän semrush.com, beslöt vi oss för att omedelbart prova deras funktion som kallas China Network. Detta alternativ aktiveras endast för Enterprise-webbplatser på förfrågan och mot en extra kostnad. Dessutom är det endast tillgängligt för webbplatser som har en giltig ICP-licens, där Cloudflare anges som leverantör. När det har aktiverats blir ‘kinesisk CDN’ från Cloudflare tillgänglig för webbplatsen - trafiken från kinesiska regioner landar i närmaste CF PoP (Points of Presence), och därefter levereras den genom deras nätverk eller nätverken hos leverantörer/parters till origin.

Skissen av denna testmiljö presenteras nedan.

För oss är detta ett utmärkt alternativ. Det visar sig att den andra domänen också kommer att vara bakom CF, vilket inte ökar antalet lösningar som används i företaget samt praktiskt taget inte komplicerar infrastrukturen.

Vi har startat webbläsartester och här är vad vi fick:

De röda romberna är testfel. Felen längst ner är DNS-fel (resolve timeout). Felen högst upp är tidsöverskridanden.

Uptime: 86.6
Median: 18s
75 Percentile: 29.3s
95 Percentile: 60s

Medianen, efter att ha tagit bort laddningen reCaptcha (en Google-tjänst som är blockerad i Kina), minskade från 28 till 18 sekunder. Men det är ändå fruktansvärda siffror, med tanke på att samma test för semrush.com (från USA) gav mindre än 10 sekunder för 95% av användarna (från USA) på samma sida (statik + dynamik).

Du kan gå in i varje test och titta på Waterfall och andra mer detaljerade parametrar. Vi började undersöka orsakerna till felen, och om tidsutdragen är ganska tydliga: internet i Kina "går fram och tillbaka", vilket gör att hastigheten på anslutningen och inläsningen av resurser från utlandet är instabil och varierande, så blev vi djupt överraskade av DNS-felen. Vi upptäckte att PoP Cloudflares servrar verkligen är i Kina, webbplatsadressen resolveras till en anycast IP, men DNS-servrarna är amerikanska, vilket gör att DNS-förfrågningarna måste passera gränsen, så ibland misslyckas de.

Vid förtydligande av denna fråga med CF, visade det sig att de inte har egna DNS-servrar i Kina, och när de kommer att ha det är fortfarande okänt.

Därför beslutade vi att bara testa Cloudflares DNS och ändrade Cloudflares arbetsläge för vår webbplats till läget "Endast DNS". Det är ett läge där Cloudflare inte proxyar trafiken genom sig själv, vilket innebär att de inte erbjuder DDoS-skydd, CDN och andra funktioner och fungerar som en vanlig DNS-server.

Denna arkitektur är schematiskt presenterad i följande bild. I bilden beaktas de nya insikterna om att Cloudflares DNS-servrar är bakom brandväggen.

I Catchpoint körde vi enkla GET-tester (inte webbläsartester), vilket visade mycket många misslyckanden. Orsaken till dessa var fortfarande DNS-felen.

Vi började debugga dessa fel med hjälp av dig och upptäckte att vid den första förfrågan bestäms adressen korrekt, men vid en upprepning av förfrågan får vi varje gång SERVFAIL och not found. Vad är det plötsligt?

root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn har adress 220.170.186.192
Värd semrushchina.cn kunde inte hittas: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn har adress 220.170.186.192
Värd semrushchina.cn kunde inte hittas: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn har adress 220.170.186.192
Värd semrushchina.cn kunde inte hittas: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn har adress 220.170.186.192
Värd semrushchina.cn kunde inte hittas: 2(SERVFAIL)

Vid direktförfrågan av Cloudflares NS-servrar finns det inga sådana fel:

root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Använder domänserver:
Namn: ray.ns.cloudflare.com.
Adress: 173.245.59.138#53
Alias:

semrushchina.cn har adress 220.170.186.192
semrushchina.cn har adress 220.170.186.192
Använder domänserver:
Namn: ray.ns.cloudflare.com.
Adress: 173.245.59.138#53
Alias:

semrushchina.cn har adress 220.170.186.192
semrushchina.cn har adress 220.170.186.192

Det betyder att problemet ligger på sidan av den "lokala" DNS-servern eller leverantörens server.
Vidare undersökning visade att SERVFAIL vi får på resolven AAAA-poster.

Det visade sig att vid en förfrågan hos Cloudflare AAAAA-post som inte finns i domänen, svarade Cloudflare A-post som är ett fel och en avvikelse från RFC. Vilket ledde till att den lokala resolvern (x.x.x.x) inte gillade det, och den svarade SERVFAIL. I loggen nedan syns detta beteende tydligt:

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

Vi skickade en buggrapport till Cloudflare, och de åtgärdade det efter ett tag. Det visade sig vara intressant: för närvarande finns det fortfarande inget stöd för IPv6 i Kina, så Cloudflare kunde inte ge sitt IPv6-adress i svaret på förfrågan AAAAA-poster. Slutresultatet blev att Cloudflare började svara NODATA på sådana förfrågningar.

Så, DNS-fel i Catchpoint-testerna minskade kraftigt, men inte helt. Tidsgränser försvann inte heller:

Och vi började söka efter en annan lösning.

I nästa del kommer jag att berätta hur vi testade det kinesiska molnet Alibaba Cloud, hur vi med lite "magi" från Nginx snabbt kunde skapa PoC (Proof of Concept) lösningar, hur vi skapade Multi-Cloud lösningar, varav en verkligen hjälpte till att påskynda tjänsten från Kina.

Stay tuned!