Hvordan vi brød igennem den store kinesiske firewall (del 3)

Hi!
Alle gode historier får en ende. Og vores historie om, hvordan vi fandt på en løsning til hurtigt at passere den kinesiske firewall, er ingen undtagelse. Derfor skynder jeg mig at dele den sidste med dig, den sidste del om dette emne.

I den foregående del talte vi om mange testbænke, som vi kom frem til, og hvilke resultater de gav. Og vi besluttede, hvad der ville være rart at tilføje CDN! for viskositet i vores ordning.

Jeg vil fortælle dig, hvordan vi testede Alibaba Cloud CDN, Tencent Cloud CDN og Akamai, og hvad vi endte med. Og selvfølgelig, lad os opsummere.

Alibaba Cloud CDN

Vi er hostet på Alibaba Cloud og bruger IPSEC og CEN fra dem. Det ville være logisk at prøve deres løsninger først.

Alibaba Cloud har to slags produkter, der kan passe til os: CDN и DCDN. Den første mulighed er et klassisk CDN for et specifikt domæne (underdomæne). Den anden mulighed står for Dynamisk rute for CDN (Jeg kalder det dynamisk CDN), det kan aktiveres i Full-site-tilstand (for wildcard-domæner), det cacherer også statisk indhold og accelererer dynamisk indhold på sig selv, det vil sige, at sidens dynamik også vil blive indlæst gennem udbyderens hurtige netværk. Dette er vigtigt for os, fordi vores websted grundlæggende er dynamisk, det bruger mange underdomæner, og det er mere praktisk at oprette et CDN én gang for "stjernen" - *.semrushchina.cn.

Vi havde allerede set dette produkt i de tidligere stadier af vores kinesiske projekt, men så virkede det endnu ikke, og udviklerne lovede, at produktet snart ville blive tilgængeligt for alle kunder. Og det gjorde han.

I DCDN kan du:

• konfigurere SSL-afslutning med dit certifikat,
• muliggør acceleration af dynamisk indhold,
• fleksibelt konfigurere caching af statiske filer,
• tøm cachen,
• fremad web sockets,
• aktivere komprimering og endda HTML Beautifier.

Generelt er alt det samme som hos voksne og store CDN-udbydere.

Når oprindelsen (det sted, hvor CDN-edge-serverne vil gå hen) er angivet, er der kun tilbage at oprette et CNAME for stjernen, med henvisning til all.semrushchina.cn.w.kunluncan.com (dette CNAME blev modtaget i Alibaba Cloud-konsollen), og CDN'et vil fungere.

Baseret på testresultaterne hjalp denne CDN os meget. Statistikken er vist nedenfor.

beslutning
Uptime
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 er meget gode resultater, især hvis du sammenligner dem med, hvad tallene var i begyndelsen. Men vi vidste, at browsertesten af ​​den amerikanske version af vores hjemmeside www.semrush.com kører fra USA i gennemsnit på 8.3 s (en meget omtrentlig værdi). Der er plads til forbedringer. Desuden var der også CDN-udbydere, som var interessante at teste.

Så vi går uden problemer videre til en anden gigant på det kinesiske marked - Tencent.

Tencent Cloud

Tencent er netop ved at udvikle sin cloud – det kan ses på et lille antal produkter. Mens vi brugte det, ønskede vi at teste ikke kun deres CDN, men også deres netværksinfrastruktur som helhed:

• har de noget der ligner CEN?
• Hvordan fungerer IPSEC for dem? Er det hurtigt, hvad er oppetiden?
• har de Anycast?

Lad os se på disse spørgsmål separat.

Analog CEN

Tencent har et produkt Cloud Connect-netværk (CCN), så du kan forbinde VPC'er fra forskellige regioner, herunder regioner i og uden for Kina. Produktet er nu i intern beta, og du skal oprette en billet, der beder om at oprette forbindelse til det. Vi lærte af support, at globale konti (vi taler ikke om kinesiske statsborgere eller juridiske enheder) ikke kan deltage i beta-testprogrammet og generelt forbinde en region inde i Kina med en region udenfor. 1-0 til fordel for Ali Cloud

IPsec

Tencents sydligste region er Guangzhou. Vi samlede en tunnel og koblede den til Hong Kong-regionen i GCP (så var denne region allerede blevet tilgængelig). Den anden tunnel i Ali Cloud fra Shenzhen til Hong Kong blev også rejst på samme tid. Det viste sig, at gennem Tencent-netværket er latensen til Hong Kong generelt bedre (10ms) end fra Shenzhen til Hong Kong til Ali (120ms - hvad?). Men dette fremskyndede på ingen måde arbejdet på webstedet, der havde til formål at arbejde gennem Tencent og denne tunnel, hvilket i sig selv var et fantastisk faktum og endnu en gang beviste følgende: latency - for Kina er dette ikke en indikator, der virkelig er værd være opmærksom på, når der udvikles en løsning til at passere den kinesiske firewall.

Anycast internetacceleration

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

Men CDN-testen viste nogle ret interessante resultater. Tencents CDN kan ikke aktiveres på et komplet websted, kun på specifikke domæner. Vi oprettede domæner og sendte trafik til dem:

Det viste sig, at denne CDN har følgende funktion: Grænseoverskridende trafikoptimering. Denne funktion skulle reducere omkostningerne, når trafikken passerer gennem den kinesiske firewall. Som Oprindelse IP-adressen på Google GLB (GLB anycast) blev angivet. Derfor ønskede vi at forenkle projektarkitekturen.

Resultaterne var meget gode - på niveau med Ali Cloud CDN, og nogle steder endda bedre. Dette er overraskende, for hvis testene lykkes, kan du opgive en væsentlig del af infrastrukturen, tunneler, CEN, virtuelle maskiner osv.

Vi glædede os ikke længe, ​​da et problem blev afsløret: Tests i Catchpoint mislykkedes for internetudbyderen China Mobile. Fra ethvert sted modtog vi en timeout via Tencents CDN. Korrespondance med teknisk support førte ikke til noget. Vi forsøgte at løse dette problem i omkring en dag, men intet virkede.

Jeg var i Kina på det tidspunkt, men kunne ikke finde offentlig Wi-Fi på netværket af denne udbyder for at bekræfte problemet personligt. Ellers så alt hurtigt og godt ud.
Men på grund af det faktum, at China Mobile er en af ​​de tre største operatører, var vi tvunget til at returnere trafikken til Ali CDN.
Men alt i alt var dette en ret interessant løsning, der fortjener længere test og fejlfinding af dette problem.

Akamai

Den sidste CDN-udbyder vi testede var Akamai. Dette er en enorm udbyder, der har sit netværk i Kina. Det kunne vi selvfølgelig ikke komme forbi.

Helt fra begyndelsen aftalte vi med Akamai en prøveperiode, så vi kunne skifte domæne og se, hvordan det ville fungere på deres netværk. Jeg vil beskrive resultatet af alle test i form af "Hvad jeg kunne lide" og "Hvad jeg ikke kunne lide", og jeg vil også give testresultaterne.

Hvad jeg kunne lide:

• Fyrene fra Akamai var meget hjælpsomme i alle spørgsmål og fulgte os på alle teststadier. Vi forsøgte hele tiden at forbedre noget fra vores side. De gav gode tekniske råd.
• Akamai er omkring 10-15 % langsommere end vores løsning via Ali Cloud CDN. Hvad der er imponerende er, at vi i Origin for Akamai specificerede GLB's IP-adresse, hvilket betyder, at trafikken ikke gik gennem vores løsning (potentielt kunne vi opgive en del af infrastrukturen). Men alligevel viste testresultaterne, at denne løsning er værre end vores nuværende version (sammenlignende resultater nedenfor).
• Testet både Origin GLB og Origin i Kina. Begge muligheder er omtrent det samme.
• Der er Sikker rute (automatisk routingoptimering). Du kan være vært for et testobjekt på Origin, og Akamai Edge-serverne vil forsøge at hente det (almindelig GET). For disse anmodninger måles hastighed og andre målinger, baseret på hvilke Akamai-netværket optimerer ruterne, så trafikken går hurtigere for vores websted, og det var tydeligt, at aktivering af denne funktion virkelig havde en stærk indflydelse på webstedets hastighed.
• Versionering af konfigurationen i webgrænsefladen er cool. Du kan lave Sammenlign for versioner, se på diff. Se tidligere versioner.
• Du kan først udrulle en ny version kun på Akamai Staging-netværket - det samme netværk som produktion, kun på denne måde vil det ikke påvirke rigtige brugere. Til denne test skal du forfalske DNS-poster på din lokale maskine.
• Meget hurtig downloadhastighed gennem deres netværk for store statiske filer og tilsyneladende andre filer. En fil fra den "kolde" cache hentes mange gange hurtigere end den samme fil fra den "kolde" cache på Ali CDN. Fra den "varme" cache er hastigheden allerede den samme, plus eller minus.

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 i eksemplet ovenfor afhænger af forskellige faktorer. Da jeg skrev dette punkt, kørte jeg testen igen. Resultaterne for begge platforme var omtrent de samme. Dette fortæller os, at internettet i Kina, selv for store operatører og cloud-udbydere, opfører sig forskelligt fra tid til anden.

Til det foregående punkt vil jeg tilføje et stort plus for Akamai: hvis Ali viser lignende glimt af høj ydeevne og meget lav ydeevne (dette gælder for Ali CDN, Ali CEN og Ali IPSEC), så Akamai, hver gang, uanset hvordan jeg tester deres netværk, fungerer alt stabilt.
Akamai har meget dækning i Kina og arbejder gennem mange udbydere.

Hvad jeg ikke kunne lide:

• Jeg kan ikke lide webgrænsefladen og den måde, den fungerer på - den er så dårlig. Men i bund og grund vænner man sig til det (sandsynligvis).
• Testresultater er værre end vores side.
• Der er flere fejl under test end på vores side (oppetid nedenfor).
• Vi har ikke vores egne DNS-servere i Kina. Derfor er der mange fejl i test på grund af DNS-løsningstimeout.
• De giver ikke deres IP-intervaller -> der er ingen måde at registrere de korrekte sæt_rigtig_ip_fra på vores servere.

Metrics (~3626 kørsler; alle målinger undtagen Oppetid, i ms; statistik for én tidsperiode):

CDN-udbyder
median
75 %
95 %
Respons
Hjemmesidesvar
Uptime
DNS
Tilslut
Vent
Load
SSL

AliCDN
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 procent (i ms):

percentil
Akamai
AliCDN

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 denne: Akamai-muligheden er levedygtig, men giver ikke den samme stabilitet og hastighed som vores egen løsning kombineret med Ali CDN.

Små noter

Nogle øjeblikke var ikke med i historien, men dem vil jeg også gerne skrive om.

Beijing + Tokyo og Hong Kong

Som jeg sagde ovenfor, testede vi en IPSEC-tunnel til Hong Kong (HK). Men vi testede også CEN til HK. Det koster lidt mindre, og jeg spekulerede på, hvordan det ville fungere mellem byer med en afstand på ~100 km. Det viste sig at være interessant, at latensen mellem disse byer er 100 ms højere end i vores originale version (til Taiwan). Hastighed, stabilitet var også bedre for Taiwan. Som et resultat forlod vi HK som en backup IPSEC-region.

Derudover forsøgte vi at installere følgende installation:

• opsigelse af kunder i Beijing,
• IPSEC og CEN til Tokyo,
• i Ali CDN blev serveren i Beijing angivet som oprindelsen.

Denne ordning var ikke så stabil, selvom den med hensyn til hastighed generelt ikke var ringere end vores løsning. Med hensyn til tunnelen har jeg set periodiske fald selv for CEN, som burde have været stabilt. Derfor vendte vi tilbage til den gamle ordning og afmonterede denne iscenesættelse.

Nedenfor er statistikker over latenstid mellem forskellige regioner for forskellige kanaler. Måske vil nogen være interesseret i det.

IPsec
Ali cn-beijing <—> GCP asien-nordøst1 — 193ms
Ali cn-shenzhen <—> GCP asia-east2 — 91ms
Ali cn-shenzhen <—> GCP us-east4 — 200ms

CEN
Ali cn-beijing <—> Ali ap-nordøst-1 — 54ms (!)
Ali cn-shenzhen <—> Ali cn-hongkong — 6ms (!)
Ali cn-shenzhen <—> Ali us-east1 — 216ms

Generel information om internettet i Kina

Som en tilføjelse til problemerne med internettet beskrevet i begyndelsen, i første del af artiklen.

• Internettet i Kina er ret hurtigt indeni.
  • Konklusionen er baseret på test af offentlige Wi-Fi-netværk forskellige steder, hvor disse netværk bruges af et stort antal mennesker.
  • Download- og uploadhastighederne til servere i Kina var henholdsvis omkring 20 Mbit/s og 5-10 Mbit/s.
  • Hastigheden til servere uden for Kina er simpelthen mager, mindre end 1 Mbit/s.
• Internettet i Kina er ikke særlig stabilt.
  • Nogle gange kan websteder åbne hurtigt, nogle gange langsomt (på samme tidspunkt på dagen på forskellige dage), forudsat at konfigurationen ikke ændres. Vi observerede dette med eksemplet semrushchina.cn. Dette kan tilskrives Ali CDN, som også fungerer på denne måde, og at afhængigt af tidspunktet på dagen, stjernernes position osv.
• Mobilt internet er næsten overalt 4G eller 4G+. Fang det i metroen, elevatorer - kort sagt overalt.
• Det er en myte, at kinesiske brugere kun stoler på domæner i .cn-zonen. Det lærte vi direkte fra brugerne.
  • Du kan se hvordan http://baidu.cn omdirigere til www.baidu.com (også på det kinesiske fastland).
• Mange ressourcer er faktisk blokeret. Primitiv: google.com, Facebook, Twitter. Men mange Google-ressourcer virker (selvfølgelig ikke på alle Wi-Fi, og VPN bruges ikke (også på routersiden, det er helt sikkert).
• Mange "tekniske" domæner af blokerede virksomheder fungerer også. Det betyder, at du ikke altid skal skære alle Google og andre tilsyneladende blokerede ressourcer ud. Du skal kigge efter en liste over forbudte domæner.
• De har kun tre hovedinternetoperatører: China Unicom, China Telecom, China Mobile. Der er endnu mindre, men deres markedsandel er ubetydelig

Bonus: endelig løsningsdiagram

Total

Et år er gået siden projektets start. Vi startede med, at vores side generelt nægtede at arbejde normalt fra Kina, og det tog ganske enkelt 5.5 sekunder med GET curl.

Derefter med disse indikatorer i den første løsning (Cloudflare):

beslutning
Uptime
median
75 Percentil
95 Percentil

CloudFlare
86.6
18s
30s
60s

Vi nåede til sidst frem til følgende resultater (statistikker for den sidste måned):

beslutning
Uptime
median
75 Percentil
95 Percentil

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

Som du kan se, har vi endnu ikke kunne opnå 100% oppetid, men vi finder på noget, og så fortæller vi om resultaterne i en ny artikel :)

Respekt til dem, der læser alle tre dele til ende. Jeg håber, du fandt alt dette lige så interessant, som jeg gjorde, da jeg gjorde det.

PS Tidligere dele

Часть 1
Часть 2

Kilde: www.habr.com