Hvordan vi brøt gjennom den store kinesiske brannmuren (del 3)

Hei!
Alle gode historier tar slutt. Og historien vår om hvordan vi kom opp med en løsning for raskt å passere den kinesiske brannmuren er intet unntak. Derfor skynder jeg meg å dele med deg den siste, den siste delen om dette emnet.

I forrige del snakket vi om mange testbenker som vi kom frem til og hvilke resultater de ga. Og vi bestemte oss for hva som ville være fint å legge til CDN! for viskositet inn i opplegget vårt.

Jeg skal fortelle deg hvordan vi testet Alibaba Cloud CDN, Tencent Cloud CDN og Akamai, og hva vi endte opp med. Og selvfølgelig, la oss oppsummere.

Alibaba Cloud CDN

Vi er vert på Alibaba Cloud og bruker IPSEC og CEN fra dem. Det ville være logisk å prøve løsningene deres først.

Alibaba Cloud har to typer produkter som kan passe oss: CDN и DCDN. Det første alternativet er en klassisk CDN for et spesifikt domene (underdomene). Det andre alternativet står for Dynamisk rute for CDN (Jeg kaller det dynamisk CDN), det kan aktiveres i Full-site-modus (for jokertegndomener), det bufrer også statisk innhold og akselererer dynamisk innhold på seg selv, det vil si at dynamikken til siden også lastes gjennom leverandørens raske nettverk. Dette er viktig for oss, fordi nettstedet vårt i utgangspunktet er dynamisk, det bruker mange underdomener, og det er mer praktisk å sette opp et CDN én gang for "stjernen" - *.semrushchina.cn.

Vi hadde allerede sett dette produktet i de tidligere stadiene av vårt kinesiske prosjekt, men da fungerte det ennå ikke, og utviklerne lovet at produktet snart ville bli tilgjengelig for alle kunder. Og det gjorde han.

I DCDN kan du:

• konfigurere SSL-terminering med sertifikatet ditt,
• muliggjør akselerasjon av dynamisk innhold,
• fleksibelt konfigurere caching av statiske filer,
• tøm cachen,
• frem web-sockets,
• aktiver komprimering og til og med HTML Beautifier.

Generelt er alt det samme som hos voksne og store CDN-leverandører.

Etter at opprinnelsen (stedet hvor CDN-kantserverne skal gå) er spesifisert, gjenstår det bare å lage en CNAME for stjernen, med henvisning til all.semrushchina.cn.w.kunluncan.com (dette CNAME ble mottatt i Alibaba Cloud-konsollen) og CDN vil fungere.

Basert på testresultatene hjalp denne CDN oss mye. Statistikken vises nedenfor.

beslutning
Oppetid
median
75 prosentil
95 prosentil

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 veldig gode resultater, spesielt hvis du sammenligner dem med hva tallene var i begynnelsen. Men vi visste at nettlesertesten til den amerikanske versjonen av nettstedet vårt www.semrush.com kjører fra USA i gjennomsnitt på 8.3 s (en svært omtrentlig verdi). Det er rom for forbedring. Dessuten var det også CDN-leverandører som var interessante å teste.

Så vi går jevnt videre til en annen gigant på det kinesiske markedet - Tencent.

Tencent Cloud

Tencent utvikler nettopp sin sky – dette kan sees fra et lite antall produkter. Mens vi brukte det, ønsket vi å teste ikke bare deres CDN, men også deres nettverksinfrastruktur som helhet:

• har de noe som ligner på CEN?
• Hvordan fungerer IPSEC for dem? Er det raskt, hva er oppetiden?
• har de Anycast?

La oss se på disse spørsmålene separat.

Analog CEN

Tencent har et produkt Cloud Connect-nettverk (CCN), slik at du kan koble til VPC-er fra forskjellige regioner, inkludert regioner i og utenfor Kina. Produktet er nå i intern beta, og du må opprette en billett som ber om å koble til det. Vi lærte av støtten at globale kontoer (vi snakker ikke om kinesiske statsborgere eller juridiske enheter) ikke kan delta i beta-testprogrammet og generelt sett koble en region i Kina med en region utenfor. 1-0 til fordel for Ali Cloud

IPsec

Tencents sørligste region er Guangzhou. Vi satte sammen en tunnel og koblet den til Hong Kong-regionen i GCP (da var denne regionen allerede blitt tilgjengelig). Den andre tunnelen i Ali Cloud fra Shenzhen til Hong Kong ble også hevet på samme tid. Det viste seg at gjennom Tencent-nettverket er ventetiden til Hong Kong generelt bedre (10ms) enn fra Shenzhen til Hong Kong til Ali (120ms - hva?). Men dette fremskyndet ikke på noen måte arbeidet med nettstedet med sikte på å jobbe gjennom Tencent og denne tunnelen, som i seg selv var et fantastisk faktum og nok en gang beviste følgende: latens - for Kina er ikke dette en indikator som virkelig er verdt ta hensyn til når du utvikler en løsning for å passere den kinesiske brannmuren.

Anycast Internett-akselerasjon

Et annet produkt som lar deg jobbe via anycast IP er AIA. Men det er heller ikke tilgjengelig for globale kontoer, så jeg vil ikke fortelle deg om det, men det kan være nyttig å vite at et slikt produkt eksisterer.

Men CDN-testen viste noen ganske interessante resultater. Tencents CDN kan ikke aktiveres på et fullstendig nettsted, bare på spesifikke domener. Vi opprettet domener og sendte trafikk til dem:

Det viste seg at denne CDN har følgende funksjon: Trafikkoptimalisering på tvers av landegrensene. Denne funksjonen skal redusere kostnadene når trafikken går gjennom den kinesiske brannmuren. Som Origin IP-adressen til Google GLB (GLB anycast) ble spesifisert. Derfor ønsket vi å forenkle prosjektarkitekturen.

Resultatene var veldig gode – på nivå med Ali Cloud CDN, og noen steder enda bedre. Dette er overraskende, for hvis testene er vellykkede, kan du forlate en betydelig del av infrastrukturen, tunneler, CEN, virtuelle maskiner, etc.

Vi gledet oss ikke lenge, da et problem ble avslørt: Tester i Catchpoint mislyktes for internettleverandøren China Mobile. Fra et hvilket som helst sted mottok vi en timeout via Tencents CDN. Korrespondanse med teknisk støtte førte ikke til noe. Vi prøvde å løse dette problemet i omtrent en dag, men ingenting fungerte.

Jeg var i Kina i det øyeblikket, men kunne ikke finne offentlig Wi-Fi på nettverket til denne leverandøren for å bekrefte problemet personlig. Ellers så alt raskt og bra ut.
Men på grunn av det faktum at China Mobile er en av de tre største operatørene, ble vi tvunget til å returnere trafikk til Ali CDN.
Men totalt sett var dette en ganske interessant løsning som fortjener lengre testing og feilsøking av dette problemet.

Akamai

Den siste CDN-leverandøren vi testet var Akamai. Dette er en enorm leverandør som har sitt nettverk i Kina. Selvfølgelig kunne vi ikke komme forbi det.

Helt fra begynnelsen ble vi enige med Akamai om en prøveperiode slik at vi kunne bytte domenet og se hvordan det ville fungere på nettverket deres. Jeg vil beskrive resultatet av all testing i form av "Hva jeg likte" og "Hva jeg ikke likte", og jeg vil også gi testresultatene.

Hva vi likte:

• Gutta fra Akamai var veldig hjelpsomme i alle spørsmål og fulgte oss på alle stadier av testingen. Vi prøvde hele tiden å forbedre noe på vår side. De ga gode tekniske råd.
• Akamai er omtrent 10-15 % tregere enn løsningen vår via Ali Cloud CDN. Det som er imponerende er at vi i Origin for Akamai spesifiserte GLBs IP-adresse, noe som betyr at trafikken ikke gikk gjennom løsningen vår (potensielt kan vi forlate en del av infrastrukturen). Men likevel viste testresultatene at denne løsningen er dårligere enn vår nåværende versjon (sammenlignende resultater nedenfor).
• Testet både Origin GLB og Origin i Kina. Begge alternativene er omtrent like.
• Det er Klart rute (automatisk ruteoptimalisering). Du kan være vert for et testobjekt på Origin, og Akamai Edge-serverne vil prøve å plukke det opp (vanlig GET). For disse forespørslene måles hastighet og andre beregninger, basert på hvilke Akamai-nettverket optimaliserer rutene slik at trafikken går raskere for nettstedet vårt, og det var tydelig at aktivering av denne funksjonen virkelig hadde en sterk innvirkning på hastigheten til nettstedet.
• Versjon av konfigurasjonen i webgrensesnittet er kult. Du kan gjøre Sammenlign for versjoner, se på diff. Se tidligere versjoner.
• Du kan rulle ut en ny versjon først bare på Akamai Staging-nettverket - det samme nettverket som produksjon, bare denne måten vil ikke påvirke ekte brukere. For denne testen må du forfalske DNS-poster på din lokale maskin.
• Veldig rask nedlastingshastighet gjennom nettverket for store statiske filer, og tilsynelatende andre filer. En fil fra den "kalde" cachen hentes mange ganger raskere enn den samme filen fra den "kalde" cachen til Ali CDN. Fra den "varme" cachen er hastigheten allerede den samme, pluss 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 la merke til at situasjonen i eksemplet ovenfor avhenger av ulike faktorer. Da jeg skrev dette punktet, kjørte jeg testen på nytt. Resultatene for begge plattformene var omtrent de samme. Dette forteller oss at Internett i Kina, selv for store operatører og skyleverandører, oppfører seg forskjellig fra tid til annen.

Til forrige punkt vil jeg legge til et stort pluss for Akamai: hvis Ali viser lignende glimt av høy ytelse og svært lav ytelse (dette gjelder Ali CDN, Ali CEN og Ali IPSEC), så Akamai, hver gang, uansett hvordan jeg tester nettverket deres, fungerer alt stabilt.
Akamai har mye dekning i Kina og jobber gjennom mange leverandører.

Det jeg ikke likte:

• Jeg liker ikke nettgrensesnittet og måten det fungerer på - det er så dårlig. Men i bunn og grunn blir man vant til det (sannsynligvis).
• Testresultatene er dårligere enn nettstedet vårt.
• Det er flere feil under tester enn på siden vår (oppetid nedenfor).
• Vi har ikke egne DNS-servere i Kina. Derfor er det mange feil i tester på grunn av tidsavbrudd for DNS-løsning.
• De oppgir ikke sine IP-områder -> det er ingen måte å registrere de riktige sett_ekte_ip_fra på våre servere.

Beregninger (~3626 kjøringer; alle beregninger unntatt Oppetid, i ms; statistikk for én tidsperiode):

CDN-leverandør
median
75%
95%
Respons
Nettsiderespons
Oppetid
DNS
Koble
Vent
Laste
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 etter prosentil (i ms):

persentil
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

Konklusjonen er denne: Akamai-alternativet er levedyktig, men gir ikke samme stabilitet og hastighet som vår egen løsning kombinert med Ali CDN.

Små notater

Noen øyeblikk var ikke inkludert i historien, men jeg vil gjerne skrive om dem også.

Beijing + Tokyo og Hong Kong

Som jeg sa ovenfor, testet vi en IPSEC-tunnel til Hong Kong (HK). Men vi testet også CEN til HK. Det koster litt mindre, og jeg lurte på hvordan det ville fungere mellom byer med en avstand på ~100 km. Det viste seg å være interessant at latensen mellom disse byene er 100 ms høyere enn i vår originalversjon (til Taiwan). Hastighet, stabilitet var også bedre for Taiwan. Som et resultat forlot vi HK som en backup-IPSEC-region.

I tillegg prøvde vi å installere følgende installasjon:

• oppsigelse av kunder i Beijing,
• IPSEC og CEN til Tokyo,
• i Ali CDN ble serveren i Beijing angitt som opprinnelse.

Denne ordningen var ikke så stabil, selv om den når det gjelder hastighet generelt sett ikke var dårligere enn vår løsning. Angående tunnelen har jeg sett periodiske fall selv for CEN, som burde vært stabilt. Derfor gikk vi tilbake til den gamle ordningen og demonterte denne oppsetningen.

Nedenfor er statistikk over ventetid mellom ulike regioner for ulike kanaler. Kanskje noen vil være interessert i det.

IPsec
Ali cn-beijing <—> GCP asia-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

Generell informasjon om Internett i Kina

Som et tillegg til problemene med Internett beskrevet helt i begynnelsen, i første del av artikkelen.

• Internett i Kina er ganske raskt inne.
  • Konklusjonen ble gjort basert på testing av offentlige Wi-Fi-nettverk på ulike steder hvor disse nettverkene brukes av et stort antall mennesker.
  • Nedlastings- og opplastingshastighetene til servere inne i Kina var henholdsvis ca. 20 Mbit/s og 5-10 Mbit/s.
  • Hastigheten til servere utenfor Kina er rett og slett mager, mindre enn 1 Mbit/s.
• Internett i Kina er lite stabilt.
  • Noen ganger kan nettsteder åpne raskt, noen ganger sakte (på samme tid på dagen på forskjellige dager), forutsatt at konfigurasjonen ikke endres. Vi observerte dette med eksempelet semrushchina.cn. Dette kan tilskrives Ali CDN, som også fungerer slik og at avhengig av tid på døgnet, stjernenes plassering osv.
• Mobilt Internett er nesten overalt 4G eller 4G+. Ta den i t-banen, heiser - kort sagt, overalt.
• Det er en myte at kinesiske brukere kun stoler på domener i .cn-sonen. Dette lærte vi direkte fra brukerne.
  • Du kan se hvordan http://baidu.cn omdirigere til www.baidu.com (også på fastlands-Kina).
• Mange ressurser er faktisk blokkert. Primitiv: google.com, Facebook, Twitter. Men mange Google-ressurser fungerer (selvfølgelig ikke på alle Wi-Fi og VPN brukes ikke (på rutersiden også, det er sikkert).
• Mange "tekniske" domener til blokkerte selskaper fungerer også. Dette betyr at du ikke alltid bør kutte ut alle Google og andre tilsynelatende blokkerte ressurser. Du må se etter en liste over forbudte domener.
• De har bare tre hovedinternettoperatører: China Unicom, China Telecom, China Mobile. Det er enda mindre, men deres markedsandel er ubetydelig

Bonus: endelig løsningsdiagram

Total

Et år har gått siden prosjektet startet. Vi startet med det faktum at nettstedet vårt generelt nektet å fungere normalt fra Kina, og ganske enkelt GET curl tok 5.5 sekunder.

Deretter, med disse indikatorene i den første løsningen (Cloudflare):

beslutning
Oppetid
median
75 prosentil
95 prosentil

CloudFlare
86.6
18s
30s
60s

Vi nådde til slutt følgende resultater (statistikk for siste måned):

beslutning
Oppetid
median
75 prosentil
95 prosentil

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

Som du kan se har vi ennå ikke klart å oppnå 100% oppetid, men vi kommer på noe, og så vil vi fortelle deg om resultatene i en ny artikkel :)

Respekt til de som leser alle tre delene til slutten. Jeg håper du fant alt dette like interessant som jeg gjorde da jeg gjorde det.

PS Tidligere deler

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

Kilde: www.habr.com