🥇Hvordan vi overvandt Den Store Kinesiske Firewall (del 3)

Hej!
Alle gode historier slutter. Og vores historie om, hvordan vi udtænkte en løsning til hurtig passage af den kinesiske firewall, er ingen undtagelse. Derfor haster jeg med at dele den sidste del med dig, den afsluttende del om dette emne.

I den forrige del blev der fortalt om de mange testmiljøer, vi havde udviklet, og hvilke resultater de gav. Vi stoppede ved, at det ville være godt at tilføje CDN! for at øge hastigheden i vores opsætning.

Jeg vil fortælle dig, hvordan vi testede Alibaba Cloud CDN, Tencent Cloud CDN og Akamai, og hvad vi i sidste ende valgte. Og selvfølgelig vil vi opsummere.

Alibaba Cloud CDN

Vi hoster på Alibaba Cloud, bruger IPSEC og CEN fra dem. Det virker logisk at prøve deres løsninger først.

Alibaba Cloud har to typer produkter, der kan passe til os: CDN og DCDN. Den første mulighed er en klassisk CDN til et specifikt domæne (eller subdomæne). Den anden mulighed står for Dynamic Route for CDN (jeg kalder det dynamisk CDN), det kan aktiveres i fuldsite-tilstand (til wildcard domæner), det cachelagrer også statisk indhold og accelererer dynamisk indhold, hvilket betyder, at dynamikken på siden også vil blive indlæst gennem hurtige netværk. Dette er vigtigt for os, fordi vores site primært er dynamisk, og det bruger mange underdomæner, og det er mere praktisk at konfigurere CDN én gang for “stjernen” — *.semrushchina.cn.

Vi har allerede set dette produkt på tidligere stadier af vores kinesiske projekt, men dengang fungerede det ikke endnu, og udviklerne lovede, at produktet snart ville blive tilgængeligt for alle kunder. Og det er det nu.

I DCDN kan man:

opsætte SSL-terminering med sit eget certifikat,
aktivere acceleration af dynamisk indhold,
fleksibelt konfigurere caching af statiske filer,
foretage cache-fjernelse,
gennemføre web-sockets,
aktivere kompression og endda HTML Beautifier.

Generelt, alt som hos etablerede og store CDN-udbydere.

Når Origin (det sted, hvor CDN edge-servere vil gå hen) er angivet, er det næste skridt at oprette et CNAME for stjernen, der peger på all.semrushchina.cn.w.kunluncan.com (denne CNAME blev erhvervet i Alibaba Cloud-konsollen), og CDN vil fungere.

Ifølge testresultaterne har denne CDN været meget hjælpsom for os. Statistikken er vist nedenfor.

Løsning
Driftstid
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

Dette er meget gode resultater, især når man sammenligner dem med de tal, vi havde i begyndelsen. Men vi vidste, at den browserbaserede test af den amerikanske version af vores hjemmeside www.semrush.com kører fra USA med et gennemsnit på 8,3 sekunder (et meget approximativt tal). Der er plads til forbedring. Desuden var der CDN-udbydere, som vi var interesseret i at teste.

Så vi glider glat over til en anden gigant på det kinesiske marked — Tencent.

Tencent Cloud

Tencent udvikler stadig deres cloud — det er tydeligt fra det lille antal produkter. Under brugen ville vi teste ikke kun deres CDN, men også netværksinfrastrukturen generelt:

Har de noget, der ligner CEN?
Hvordan fungerer IPSEC hos dem? Er det hurtigt, hvilken oppetid har de?
Har de Anycast?

Lad os gennemgå disse spørgsmål én ad gangen.

CEN-lignende

Tencent har et produkt Cloud Connect Network (CCN), som muliggør forbindelse mellem VPC'er fra forskellige regioner, både inden for Kina og udenfor. Produktet er i øjeblikket i intern beta, og man skal oprette en billet for at anmode om at blive tilsluttet det. Fra supporten fik vi at vide, at global-konti (som ikke omfatter kinesiske statsborgere og juridiske personer) ikke kan deltage i beta-testprogrammet og generelt ikke kan forbinde en region inden for Kina med en region udenfor. 1-0 til fordel for Ali Cloud.

IPSEC

Den sydligste region hos Tencent er — Guangzhou. Vi oprettede en tunnel og forbinder den med regionen Hongkong i GCP (på det tidspunkt var denne region allerede tilgængelig). Vi etablerede også samtidig en anden tunnel i Ali Cloud fra Shenzhen til Hongkong. Det viste sig, at latens gennem Tencent's netværk generelt var bedre (10ms) end fra Shenzhen til Hongkong i Ali (120ms — hvad?). Men dette accelererede ikke webstedets drift, der var rettet mod at fungere gennem Tencent og denne tunnel, hvilket i sig selv var en overraskende faktor og endnu en gang bekræftede følgende: latens — for Kina er det ikke et mål, man reelt bør fokusere på under udviklingen af løsninger til at passere den kinesiske firewall.

Anycast Internet Acceleration

Et andet produkt, der muliggør drift via anycast IP — AIA. Men det er heller ikke tilgængeligt for globale konti, så jeg vil ikke fortælle om det, men det kan være nyttigt at vide, at der findes et sådant produkt.

Men testen af CDN viste ret interessante resultater. CDN hos Tencent kan ikke aktiveres for hele hjemmesiden, kun for specifikke domæner. Vi oprettede domæner og sendte trafik til dem:

Det viste sig, at denne CDN har en sådan funktion: Optimering af grænseoverskridende trafik. Denne funktion skal reducere omkostningerne ved at passere trafik gennem den kinesiske firewall. Som Origin blev IP-adressen til Googles GLB (GLB anycast) angivet. På den måde ønskede vi at forenkle projektets arkitektur.

Resultaterne var meget gode — på niveau med Ali Cloud CDN, og nogle steder endda bedre. Det er overraskende, fordi i tilfælde af succes med testene kan vi undvære en betydelig del af infrastrukturen, tunnellerne, CEN, virtuelle maskiner osv.

Vi glædede os ikke længe, da der opstod et problem: testene i Catchpoint fejlede for internetudbyderen China Mobile. Fra enhver lokation fik vi timeout gennem Tencent CDN. Korrespondancer med teknisk support førte ikke til noget. I cirka et døgn forsøgte vi at løse dette problem, men det lykkedes os ikke.

Jeg befandt mig på det tidspunkt i Kina, men kunne ikke finde offentlig Wi-Fi i dette udbyders netværk for at bekræfte problemet personligt. Ellers så alt hurtigt og godt ud.
Dog, da operatøren China Mobile er en af de tre største operatører, var vi nødt til at returnere trafikken til Ali CDN.
Men samlet set var det en ret interessant løsning, som fortjener mere langvarig testning og fejlfinding af dette problem.

Akamai

Den sidste CDN-udbyder, vi testede, er Akamai. Dette er en stor udbyder, der har sit netværk i Kina. Selvfølgelig kunne vi ikke ignorere dem.

Fra starten aftalte vi med Akamai en testperiode, så vi kunne skifte domæne og se, hvordan det ville fungere på deres netværk. Resultatet af hele testen vil jeg beskrive som "Hvad vi kunne lide" og "Hvad vi ikke kunne lide", samt inkludere testresultaterne.

Hvad vi kunne lide:

Folkene fra Akamai hjalp os meget med alle spørgsmål og støttede os i alle testfaser. De forsøgte konstant at forbedre noget på deres side. Gave os gode tekniske råd.
Akamai arbejder cirka 10-15% langsommere end vores løsning gennem Ali Cloud CDN. Det imponerende er, at vi angav IP-adressen til GLB for Akamai, hvilket betyder, at trafikken ikke gik gennem vores løsning (potentielt kan vi undvære en del af infrastrukturen). Men alligevel viste testresultaterne, at denne løsning var dårligere end vores nuværende løsning (sammenlignende resultater nedenfor).
Både Origin GLB og Origin i Kina blev testet. Begge varianter var omtrent ens.
Der er Sikker rute (automatisk ruteoptimering). Du kan placere et testobjekt på Origin, og Akamai Edge-serverne vil forsøge at hente det (normal GET). For disse anmodninger måles hastigheden og andre metrikker, hvormed Akamai-netværket optimerer ruterne for at sikre, at trafikken går hurtigere til vores hjemmeside, og at det er tydeligt, at aktiveringen af denne funktion virkelig har haft stor indflydelse på websitets hastighed.
Versionsstyring af konfigurationen i webgrænsefladen er fantastisk. Du kan sammenligne versioner og se forskelle. Tjek tidligere versioner.
Du kan rulle en ny version ud kun på Akamai Staging-netværket — et netværk, der er nøjagtigt som production, kun med denne rute påvirkes de reelle brugere ikke. Til denne test skal der udføres DNS-spoofing på den lokale maskine.
Meget hurtig indlæsningstid gennem deres netværk for store statiske filer, samt sandsynligvis alle andre filer. En fil fra det 'kolde' cache hentes meget hurtigere end den samme fil fra Ali CDN’s 'kolde' cache. Fra det 'varme' cache er hastigheden stort set ens.

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  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
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  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
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 bemærket, at situationen fra ovenstående eksempel afhænger af forskellige faktorer. På tidspunktet for skrivningen af dette punkt har jeg lavet en ny test. Resultaterne for begge platforme var omtrent de samme. Dette viser os, at internettet i Kina, selv for store operatører og cloud-udbydere, til tider opfører sig forskelligt.

En stor fordel ved Akamai, som jeg vil tilføje til det forrige punkt: hvis Ali oplever sådanne lysglimt af høj ydeevne og meget lav (dette gælder både for Ali CDN, Ali CEN, og Ali IPSEC), så fungerer Akamai hver gang, uanset hvor meget jeg tester deres netværk, stabilt.
Akamai har virkelig stor dækning i Kina og arbejder gennem mange udbydere.

Hvad jeg ikke kunne lide:

Jeg bryder mig ikke om webgrænsefladen og arbejdsmetoden - de er temmelig mediocre. Men man vænner sig til det (måske).
Testresultaterne er dårligere end vores platform.
Der er flere fejl i testene end på vores platform (uptime er lavere).
Der er ingen egne DNS-servere i Kina. Dette fører til mange fejl i testene på grund af DNS resolve timeout.
De giver ikke deres IP-rækken -> der er ingen mulighed for at angive korrekt set_real_ip_from på vores servere.

Metrikker (~3626 runs; alle metrikker undtagen Uptime i ms; statistik for ét tidsrum):

CDN-udbyder
Median
75%
95%
Svar
Webside-svar
Driftstid
DNS
Forbind
Vent
Belastning
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

Fordeling efter Percentile (i ms):

Percentile
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

Konklusionen er: muligheden med Akamai er levedygtig, men den giver ikke de samme stabilitets- og hastighedsresultater som vores egen løsning sammen med Ali CDN.

Små bemærkninger

Nogle punkter blev ikke nævnt i fortællingen, men jeg ville også gerne skrive om dem.

Beijing + Tokyo og Hongkong

Som jeg nævnte tidligere, testede vi en IPSEC-tunnel til Hongkong (HK). Men vi testede også CEN til HK. Det koster lidt mindre, og det var interessant at se, hvordan det ville fungere mellem byer med en afstand på ~100 km. Det interessante var, at latenstiden mellem disse byer var 100 ms højere end i vores oprindelige mulighed (til Taiwan). Hastigheden og stabiliteten var også bedre for Taiwan. I sidste ende valgte vi HK som en backup IPSEC-region.

Desuden prøvede vi at etablere en sådan installation:

klientterminering i Beijing,
IPSEC og CEN til Tokyo,
i Ali CDN blev angivet som origin-server i Beijing.

Denne ordning var ikke så stabil, selvom hastigheden generelt ikke var ringere end vores løsning. Med hensyn til tunnelen så jeg periodiske nedbrud selv for CEN, som burde være stabil. Derfor gik vi tilbage til den gamle ordning og skruede dette staging ned.

Nedenfor er statistikken for latenstid mellem forskellige regioner over forskellige kanaler. Måske vil nogen finde den interessant.

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 — 216ms

Generel information om internettet i Kina

Som supplement til problemerne med internettet, der blev beskrevet i begyndelsen, i den første del af artiklen.

Internettet i Kina fungerer ganske hurtigt indeni.
- Konklusionen er baseret på test af offentlige Wi-Fi-netværk på forskellige lokationer, hvor disse netværk bruges af mange personer.
- Hastigheden for download og upload til servere inden i Kina var omkring 20 Mbit/s og 5-10 Mbit/s henholdsvis.
- Hastigheden til servere uden for Kina er simpelthen ubetydelig, under 1 Mbit/s.
Internettet i Kina er ikke særlig stabilt.
- Nogle gange kan sider åbnes hurtigt, nogle gange langsomt (på samme tid af døgnet på forskellige dage), forudsat at konfigurationen ikke ændres. Vi har observeret dette ved at se på eksemplet semrushchina.cn. Dette kan tilskrives Ali CDN, som også fungerer skidt fra tid til anden afhængigt af tidspunktet på dagen, positionen af stjernerne osv.
Mobilinternet er praktisk taget overalt 4G eller 4G+. Det fungerer i metroen, i elevatorer — kort sagt, overalt.
At kinesiske brugere kun stoler på domæner i zone .cn — er en myte. Vi har fået det bekræftet direkte fra brugere.
- Man kan se, hvordan http://baidu.cn videresender til www.baidu.com (også i mainland Kina).
Mange ressourcer er virkelig blokeret. Primitivt: google.com, Facebook, Twitter. Men mange Google-ressourcer fungerer (selvfølgelig ikke på alle Wi-Fi, og VPN bruges ikke (på router-siden også, det er sikkert).
Mange "tekniske" domæner fra blokerede virksomheder fungerer også. Dette betyder, at man ikke altid skal overilat skære alle tilsyneladende blokerede Google- og andre ressourcer væk. Man skal finde en liste over forbudte domæner.
De har kun tre hoved internetudbydere: China Unicom, China Telecom, China Mobile. Der findes også mindre selskaber, men deres markedsandel er uvæsentlig.

Bonus: den endelige løsningsskema

Resultat

Der er gået et år siden projektets start. Vi begyndte med, at vores hjemmeside overhovedet nægtede at fungere normalt fra Kina, og en simpel GET curl tog 5.5 sekunder.

Derefter, med sådanne tal ved den første løsning (Cloudflare):

Løsning
Driftstid
Median
75 Percentil
95 Percentil

Cloudflare
86.6
18s
30s
60s

Vi nåede til slut resultater som disse (statistik for den sidste måned):

Løsning
Driftstid
Median
75 Percentil
95 Percentil

Ali CDN + CEN/IPsec + GLB
99.86
8.8s
9.5s
13.7s

Som man kan se, har vi ikke været i stand til at opnå 100% oppetid endnu, men vi vil finde en løsning, og så fortælle jer om resultaterne i en ny artikel :)

Respekt til dem, der har læst alle tre dele til ende. Jeg håber, det har været lige så interessant for jer, som det var for mig, da jeg skrev det.