🥇Hur vi bröt igenom den Stora Kinesiska brandväggen (del 3)

Hej!
Alla bra berättelser har ett slut. Och vår berättelse om hur vi utvecklade en lösning för att snabbt passera den Kinesiska brandväggen är inget undantag. Därför vill jag dela med mig av den sista delen, slutordet om detta ämne.

I den föregående delen berättade vi om många testmiljöer som vi skapade, och vilka resultat de gav. Vi kom fram till att det skulle vara bra att lägga till CDN! för att förbättra vår lösning.

Jag kommer att berätta för er hur vi testade Alibaba Cloud CDN, Tencent Cloud CDN och Akamai, och vilken vi till slut valde. Självklart kommer vi också att sammanfatta.

Alibaba Cloud CDN

Vi är värd hos Alibaba Cloud, och använder IPSec och CEN från dem. Det är logiskt att först prova deras lösningar.

Alibaba Cloud har två typer av produkter som kan passa oss: CDN och DCDN. Det första alternativet är en klassisk CDN för en specifik domän (subdomän). Det andra alternativet står för Dynamic Route for CDN (jag kallar det dynamisk CDN), som kan aktiveras i Full-site-läge (för wildcard-domäner), det cachar också statiskt innehåll och accelererar dynamiskt innehåll, vilket innebär att dynamiken på sidan också laddas via leverantörens snabba nätverk. Detta är viktigt för oss, eftersom vår webbplats är mestadels dynamisk, med många subdomäner, och det är enklare att konfigurera CDN en gång för "stjärnan" — *.semrushchina.cn.

Vi har redan sett denna produkt i tidigare skeden av vårt kinesiska projekt, men då fungerade den inte ännu, och utvecklarna lovade att produkten snart skulle bli tillgänglig för alla kunder. Och den är här nu.

I DCDN kan man:

konfigurera SSL-terminering med sitt eget certifikat,
aktivera acceleration av dynamiskt innehåll,
flexibelt konfigurera caching av statiska filer,
utföra cache purge,
stötta webb-sockets,
aktivera komprimering och till och med HTML Beautifier.

Kort sagt, allt som hos stora och etablerade CDN-leverantörer.

När origin (den plats dit CDN edge-servrar kommer att gå) är angiven, återstår det att skapa en CNAME för stjärnan som refererar till all.semrushchina.cn.w.kunluncan.com (denna CNAME erhölls i Alibaba Cloud-konsolen), och CDN kommer att fungera.

Enligt testresultaten har denna CDN verkligen hjälpt oss. Statistiken anges nedan.

Lösning
Tillgänglighet
Median
75 Percentil
95 Percentil

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

CEN/IPsec + GLB
99.79
13s
16s
25s

Ali CDN + CEN/IPsec + GLB
99.75
10s
12.8s
17.3s

Det här är riktigt bra resultat, särskilt om man jämför med de siffror vi hade i början. Men vi visste att den amerikanska versionen av vårt webbtjänst www.semrush.com presterar i genomsnitt 8,3 sekunder i en webbläsartest (ett mycket approximativt värde). Det finns fortfarande rum för förbättring. Dessutom fanns det CDN-leverantörer som var intressanta att testa.

Så vi går smidigt över till en annan jätte på den kinesiska marknaden — Tencent.

Tencent Cloud

Tencent utvecklar fortfarande sitt moln — detta syns på det begränsade antalet produkter. Under vår användning ville vi inte bara testa deras CDN, utan också deras nätverksinfrastruktur i stort:

har de något liknande CEN?
hur fungerar deras IPSEC? Är det snabbt, vad är uptiden?
har de Anycast?

Vi går igenom dessa frågor en i taget.

CEN-liknande

Tencent har en produkt Cloud Connect Network (CCN), som möjliggör anslutningar mellan VPC:er från olika regioner, inklusive regioner både inom och utanför Kina. Produkterna är för närvarande i intern beta och man måste skapa en ticket för att be om anslutning. Från supporten fick vi veta att globala konton (varken kinesiska medborgare eller juridiska personer) inte kan delta i beta-programmet och överhuvudtaget koppla en region inom Kina med en region utanför. 1-0 till fördel för Ali Cloud.

IPSEC

Den sydligaste regionen hos Tencent är — Guangzhou. Vi byggde en tunnel och anslöt den till Hongkong-regionen i GCP (vid den tidpunkten var denna region redan tillgänglig). Vi reste även en andra tunnel i Ali Cloud från Shenzhen till Hongkong samtidigt. Det visade sig att latensen via Tencent-nätverket till Hongkong överlag var bättre (10 ms) än från Shenzhen till Hongkong i Ali (120 ms — vad?). Men detta påverkade inte hastigheten på webbplatsen, som var inställd för att fungera över Tencent och denna tunnel, vilket i sig var en förvånande insikt och bekräftade följande: latens — är inte en indikator som man verkligen bör uppmärksamma under utvecklingen av en lösning för att passera den kinesiska brandväggen.

Anycast Internet Acceleration

En annan produkt som möjliggör arbete via anycast IP — AIA. Men den är också otillgänglig för globala konton, så jag kan inte berätta om den, men att veta att en sådan produkt finns kan vara användbart.

Men testet av CDN visade ganska intressanta resultat. CDNet hos Tencent kan inte aktiveras för full webbplats, endast för specifika domäner. Vi registrerade domäner och dirigerade trafik till dem:

Det visade sig att denna CDN har följande funktion: Optimering av gränsöverskridande trafik. Denna funktion ska minska kostnaderna för trafik som passerar genom den kinesiska firewallen. Som Origin angavs IP-adressen av Googles GLB (GLB anycast). På så sätt ville vi förenkla projektarkitekturen.

Resultaten var mycket bra — i nivå med Ali Cloud CDN, och ibland till och med bättre. Detta är anmärkningsvärt eftersom vi vid framgångsrika tester kan avstå från en betydande del av infrastrukturen, tunnlar, CEN, virtuella maskiner etc.

Vi blev glada för kort, då ett problem uppstod: testerna i Catchpoint misslyckades för internetleverantören China Mobile. Från alla platser fick vi timeout genom Tencent CDN. Kommunikationsutbytet med teknisk support ledde ingenstans. Under cirka ett dygn försökte vi lösa problemet, men utan framgång.

Jag befann mig i Kina vid den tidpunkten, men kunde inte hitta offentlig Wi-Fi i denna leverantörs nätverk för att personligen verifiera problemet. I övrigt såg allt snabbt och bra ut.
Men på grund av att operatören China Mobile är en av de tre största operatörerna, var vi tvungna att återföra trafiken till Ali CDN.
Men överlag var detta en ganska intressant lösning som förtjänar mer långvarig testning och felsökning av detta problem.

Akamai

Den senaste CDN-leverantören vi testade var Akamai. Detta är en stor leverantör som har sitt eget nätverk i Kina. Självklart kunde vi inte förbise det.

Från början kom vi överens med Akamai om en testperiod så att vi kunde byta domän och se hur det skulle fungera i deras nätverk. Resultatet av hela testningen kommer jag att beskriva i form av "Vad jag gillade" och "Vad jag inte gillade", samt ge resultaten från testen.

Vad jag gillade:

Folk från Akamai var mycket hjälpsamma med alla frågor och stödde oss genom hela testningsprocessen. De försökte ständigt förbättra något på sin sida. De gav bra tekniska råd.
Akamai fungerar cirka 10-15% långsammare än vår lösning via Ali Cloud CDN. Det är imponerande att vi angav IP-adressen till GLB för Akamai, det vill säga trafiken gick inte genom vår lösning (potentiellt kan vi avstå från en del av infrastrukturen). Men resultaten från testerna visade trots allt att detta alternativ var sämre än vår nuvarande lösning (jämförande resultat nedan).
Både Origin GLB och Origin i Kina testades. Båda alternativen är ungefär lika.
Det finns Säker rutt (automatisk ruttoptimering). Du kan placera en testobjekt på Origin, och Akamai Edge-servrarna kommer att försöka hämta den (vanligt GET). För dessa förfrågningar mäts hastighet och andra metrik, utifrån vilket Akamai-nätverket optimerar rutterna så att trafiken går snabbare för vår webbplats och det är tydligt att aktiveringen av denna funktion verkligen har stor inverkan på webbplatsens prestanda.
Versionshantering av konfigurationen i webbgränssnittet – det är fantastiskt. Du kan göra en jämförelse mellan versionar, se diff. Titta på tidigare versioner.
Du kan först rulla ut en ny version endast på Staging-nätverket av Akamai – ett nätverk som är identiskt med produktionen, men den vägen påverkar inte verkliga användare. För detta test måste DNS-poster spoofas på den lokala maskinen.
Mycket snabb laddningstid via deras nätverk för stora statiska filer, och uppenbarligen även för andra filer. En fil från "kall" cache hämtas många gånger snabbare än samma fil från Ali CDNs "kalla" cache. Från "het" cache är hastigheten redan ungefär densamma.

Ali CDN-test:

root@shenzhen1:~# curl -o /dev/null -w@curl_time https://en.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
  % Total    % Received % Xferd  Genomsnittlig hastighet   Tid    Tid     Tid  Aktuell
                                 Dload  Uppladdning   Totalt   Spent    Left  Hastighet
100 5757k    0 5757k    0     0   513k      0 --:--:--  0:00:11 --:--:--  526k
time_namelookup:  0.004286
time_connect:  0.030107
time_appconnect:  0.117525
time_pretransfer:  0.117606
time_redirect:  0.000000
time_starttransfer:  0.840348
----------
time_total:  11.208119
----------
size_download:  5895467 Bytes
speed_download:  525999.000B/s

Akamai-test:

root@shenzhen1:~# curl -o /dev/null -w@curl_time https://www.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
  % Total    % Received % Xferd  Genomsnittlig hastighet   Tid    Tid     Tid  Aktuell
                                 Dload  Uppladdning   Totalt   Spent    Left  Hastighet
100 5757k    0 5757k    0     0  1824k      0 --:--:--  0:00:03 --:--:-- 1825k
time_namelookup:  0.509005
time_connect:  0.528261
time_appconnect:  0.577235
time_pretransfer:  0.577324
time_redirect:  0.000000
time_starttransfer:  1.327013
----------
time_total:  3.154850
----------
size_download:  5895467 Bytes
speed_download:  1868699.000B/s

Vi har märkt att situationen i exemplet ovan beror på olika faktorer. Vid tidpunkten för skrivandet av detta avsnitt genomförde jag testet igen. Resultaten för båda plattformar visade sig vara ungefär desamma. Detta tyder på att internet i Kina, även för stora operatörer och molnleverantörer, ibland beter sig på olika sätt.

Ett stort plus med Akamai i förhållande till föregående punkt: om Ali visar sådana sken av hög prestanda och mycket låg (detta gäller både Ali CDN, Ali CEN och Ali IPSEC), så fungerar Akamai varje gång, oavsett hur jag testar deras nätverk, stabilt.
Akamai har verkligen en stor täckning i Kina och arbetar genom många leverantörer.

Vad jag inte gillade:

Jag gillar inte webbgränssnittet och hur det fungerar — det är ganska uselt. Men man vänjer sig (förmodligen).
Testresultaten är sämre än vår plattform.
Det finns fler fel vid testerna än på vår plattform (uptime är lägre).
Det finns inga egna DNS-servrar i Kina. Därför många fel i testerna på grund av DNS resolve timeout.
De tillhandahåller inte sina IP-ranges -> ingen möjlighet att ange korrekt set_real_ip_from på våra servrar.

Mätningar (~3626 körningar; alla mätningar utom Uptime i ms; statistik för en tidsperiod):

CDN-leverantör
Median
75%
95%
Response
Webbsidans svar
Tillgänglighet
DNS
Anslut
Vänta
Ladda
SSL

Ali CDN
9195
10749
17489
1,715
10,745
99.531
57
17
927
479
200

Akamai
9783
11887
19888
2,352
11,550
98.980
424
91
1408
381
50

Fördelning per percentil (i ms):

Percentil
Akamai
Ali CDN

10
7,092
6,942

20
7,775
7,583

30
8,446
8,092

40
9,146
8,596

50
9,783
9,195

60
10,497
9,770

70
11,371
10,383

80
12,670
11,255

90
15,882
13,165

100
91,592
91,596

Slutsatsen är denna: alternativet med Akamai är livskraftigt, men ger inte samma stabilitets- och hastighetsnivåer som vår egen lösning tillsammans med Ali CDN.

Små noteringar

Vissa aspekter kom inte med i berättelsen, men jag ville också skriva om dem.

Peking + Tokyo och Hongkong

Som jag nämnde ovan testade vi IPSEC-tunneln till Hongkong (HK). Men vi testade också CEN till HK. Det är något billigare, och det var intressant att se hur det skulle fungera mellan städer med ett avstånd på ~100 km. Det intressanta var att latensen mellan dessa städer var 100 ms högre än i vår ursprungliga lösning (till Taiwan). Hastighet och stabilitet var också bättre för Taiwan. I slutändan valde vi att hålla HK som en backup IPSEC-region.

Dessutom testade vi att sätta upp en sådan installation:

terminering av kunder i Peking,
IPSEC och CEN till Tokyo,
där Ali CDN angavs som origin server i Peking.

Denna konfiguration var inte lika stabil, även om den övergripande hastigheten inte var sämre än vår lösning. När det gällde tunneln såg jag periodiska avbrott även för CEN, som skulle varit stabil. Därför gick vi tillbaka till den gamla lösningen och avbröt denna uppställning.

Nedan visas statistiken över latens mellan olika regioner via olika kanaler. Kanske är den intressant för någon.

IPsec
Ali cn-beijing GCP asia-northeast1 — 193ms
Ali cn-shenzhen GCP asia-east2 — 91ms
Ali cn-shenzhen GCP us-east4 — 200ms

CEN
Ali cn-beijing Ali ap-northeast-1 — 54ms (!)
Ali cn-shenzhen Ali cn-hongkong — 6ms (!)
Ali cn-shenzhen Ali us-east1 — 216 ms

Allmän information om internet i Kina

Som ett tillägg till problemen med internet, som beskrivs i början, i den första delen av artikeln.

Internet i Kina fungerar ganska snabbt inrikes.
- Uttalandet baseras på testning av offentliga Wi-Fi-nätverk på olika platser där dessa nätverk används av ett stort antal personer.
- Nedladdnings- och uppladdningshastigheten till servrar inuti Kina var cirka 20 Mbit/s och 5-10 Mbit/s respektive.
- Hastigheten till servrar utanför Kina är minimal, mindre än 1 Mbit/s.
Internet i Kina är inte särskilt stabilt.
- Ibland kan webbplatser laddas snabbt, ibland långsamt (vid samma tid på dagen under olika dagar), förutsatt att konfigurationen inte ändras. Det har observerats med exemplet semrushchina.cn. Detta kan tillskrivas Ali CDN, som också fungerar olika beroende på tid på dagen, stjärnornas position, osv.
Mobilinternet är nästan överallt 4G eller 4G+. Det fungerar i tunnelbanan, hissar — kort sagt, överallt.
Att kinesiska användare bara tror på domäner i zonen .cn är en myt. Vi har fått detta bekräftat direkt av användare.
- Man kan se hur http://baidu.cn redirectar till www.baidu.com (även i mainland China).
Många resurser är verkligen blockerade. Enkla exempel: google.com, Facebook, Twitter. Men många Google-resurser fungerar (naturligtvis inte på alla Wi-Fi och VPN används inte (på router-sidan också, det är säkert).
Många "tekniska" domäner för blockerade företag fungerar också. Det betyder att man inte alltid ska utan att tänka radera alla Google- och andra resurs som verkar blockerade. Man bör leta efter en lista över blockerade domäner.
De har endast tre huvudsakliga internetleverantörer: China Unicom, China Telecom, China Mobile. Det finns även mindre, men deras marknadsandel är obetydlig.

Bonus: den slutgiltiga lösningsschemat

Resultat

Det har gått ett år sedan projektets start. Vi började med att vår webbplats överhuvudtaget vägrade fungera normalt från Kina, och en enkel GET curl tog 5,5 sekunder.

Sedan, utifrån dessa resultat vid första lösningen (Cloudflare):

Lösning
Tillgänglighet
Median
75 Percentil
95 Percentil

Cloudflare
86.6
18s
30s
60s

Vi kom i slutändan fram till sådana resultat (statistik för den senaste månaden):

Lösning
Tillgänglighet
Median
75 Percentil
95 Percentil

Ali CDN + CEN/IPsec + GLB
99.86
8,8 s
9,5 s
13,7 s

Som man kan se, har det inte lyckats att nå 100% drifttid än, men vi ska hitta på något, och sedan berättar vi för er om resultaten i en ny artikel :)

Respekt till den som har läst hela tre delar. Jag hoppas att ni fann detta lika intressant som jag gjorde när jag skapade det.