Nola hautsi genuen Txinako Suebaki Handia (3. zatia)

Hi!
Istorio on guztiak amaitzen dira. Eta Txinako Firewall azkar gainditzeko irtenbidea nola asmatu genuenari buruzko gure istorioa ez da salbuespena. Horregatik, azkar nago zuekin azkena partekatzeko, azken zatia gai honen inguruan.

Aurreko zatian asmatu genituen proba-banku askotaz eta zer emaitzei buruz hitz egin genuen. Eta gehitzea ondo legokeenarekin finkatu ginen CDN! biskositatea gure eskeman sartu.

Esango dizut nola probatu genituen Alibaba Cloud CDN, Tencent Cloud CDN eta Akamai, eta zer lortu genuen. Eta, jakina, laburtu dezagun.

Alibaba Cloud CDN

Alibaba Cloud-en ostatatuta gaude eta haietatik IPSEC eta CEN erabiltzen ditugu. Logikoa litzateke lehenbailehen haien irtenbideak probatzea.

Alibaba Cloud-ek bi produktu mota ditu komeni zaizkigun: CDN и DCDN. Lehenengo aukera CDN klasikoa da domeinu jakin baterako (azpidomeinua). Bigarren aukerak esan nahi du CDNrako ibilbide dinamikoa (CDN dinamikoa deitzen diot), Gune osoa moduan gaitu daiteke (komodinen domeinuetarako), eduki estatikoa ere gordetzen du eta bere baitan eduki dinamikoa bizkortzen du, hau da, orriaren dinamika hornitzailearen bidez ere kargatuko da. sare azkarrak. Hau garrantzitsua da guretzat, funtsean gure gunea dinamikoa delako, azpidomeinu asko erabiltzen dituelako eta erosoagoa da behin CDN bat konfiguratzea "asterisko" - *.semrushchina.cn.

Lehendik ikusi genuen produktu hau gure txinatar proiektuaren lehen faseetan, baina oraindik ez zuen funtzionatzen, eta garatzaileek agindu zuten produktua laster bezero guztientzat eskuragarri egongo zela. Eta egin zuen.

DCDNn egin dezakezu:

• konfiguratu SSL amaiera zure ziurtagiriarekin,
• eduki dinamikoen bizkortzea ahalbidetu,
• malgutasunez konfiguratu fitxategi estatikoen cachea,
• garbitu cachea,
• aurreratu web socketak,
• gaitu konpresioa eta baita HTML Beautifier ere.

Oro har, dena berdina da helduekin eta CDN hornitzaile handiekin.

Jatorria (CDN ertzeko zerbitzariak joango diren lekua) zehaztu ondoren, izartxorako CNAME bat sortzea besterik ez da geratzen, erreferentzia eginez. all.semrushchina.cn.w.kunluncan.com (CNAME hau Alibaba Cloud kontsolan jaso zen) eta CDNk funtzionatuko du.

Proben emaitzetan oinarrituta, CDN honek asko lagundu digu. Estatistikak behean erakusten dira.

Erabaki
Funtzionamendu
median
75 ehunekoa
95 ehunekoa

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

Oso emaitza onak dira, batez ere hasieran zenbakiak zirenekin alderatzen badituzu. Baina bagenekien gure www.semrush.com webgunearen bertsio amerikarraren arakatzailearen proba AEBetatik batez beste 8.3 s-tan exekutatzen dela (oso gutxi gorabeherako balio bat). Hobetzeko aukera dago. Gainera, probatzeko interesgarriak ziren CDN hornitzaileak ere bazeuden.

Beraz, leunki mugitzen gara Txinako merkatuan beste erraldoi batera - Tencent.

Tencent Hodeia

Tencent bere hodeia garatzen ari da - produktu kopuru txiki batean ikus daiteke. Erabili bitartean, CDN ez ezik, sareko azpiegitura oro har ere probatu nahi izan dugu:

• ba al dute CENen antzeko zerbait?
• Nola funtzionatzen du IPSEC haientzat? Azkar al da, zein da funtzionamendu-denbora?
• Anycast dute?

Ikus ditzagun galdera hauek bereizita.

CEN analogikoa

Tencentek produktu bat du Cloud Connect sarea (CCN), eskualde ezberdinetako VPCak konektatzeko aukera ematen dizu, Txina barruko eta kanpoko eskualdeak barne. Produktua barne beta-n dago orain, eta txartel bat sortu behar duzu konektatzeko eskatuz. Laguntzatik jakin genuen mundu mailako kontuek (ez gara txinatar herritarrez edo pertsona juridikoez hitz egiten) ezin dutela beta testing programan parte hartu eta, oro har, Txina barruko eskualde bat kanpoko eskualde batekin konektatu. 1-0 Ali Cloud-en alde

IPSEC

Tencent-en hegoaldeko eskualdea da Guangzhou. Tunel bat muntatu eta Hong Kong eskualdearekin konektatu genuen GCPn (orduan eskualde hau jada eskuragarri zegoen). Shenzhenetik Hong Kongera Ali Cloud-eko bigarren tunela ere altxatu zuten aldi berean. Tencent sarearen bidez Hong Kongerako latentzia, oro har, hobea da (10 ms) Shenzhenetik Hong Kong-era Ali-ra baino (120 ms - zer?). Baina horrek ez zuen inola ere bizkortu Tencent eta tunel honen bidez lan egiteko gunearen lana, berez gertaera harrigarria izan zen eta beste behin ere honako hau frogatu zuen: latentzia - Txinarentzat hau ez da benetan merezi duen adierazlea. arreta jarriz Txinako suebakia pasatzeko irtenbide bat garatzerakoan.

Anycast Interneteko azelerazioa

Anycast IP bidez lan egiteko aukera ematen duen beste produktu bat da AIA. Baina kontu globaletarako ere ez dago eskuragarri, beraz, ez dizut horren berri emango, baina horrelako produktu bat existitzen dela jakitea erabilgarria izan daiteke.

Baina CDN probak emaitza nahiko interesgarriak erakutsi zituen. Tencent-en CDN ezin da gaitu gune oso batean, domeinu zehatzetan soilik. Domeinuak sortu eta haiei trafikoa bidali genien:

Agertu zen CDN honek funtzio hau duela: Mugaz gaindiko trafikoaren optimizazioa. Eginbide honek kostuak murriztu beharko lituzke trafikoa Txinako suebakitik igarotzen denean. As Jatorria Google GLB (GLB anycast) IP helbidea zehaztu da. Horrela, proiektuaren arkitektura sinplifikatu nahi izan dugu.

Emaitzak oso onak izan ziren - Ali Cloud CDNren mailan, eta leku batzuetan are hobeak. Hori harrigarria da, izan ere, probak arrakastatsuak badira, azpiegituraren zati garrantzitsu bat, tunelak, CEN, makina birtualak, etab.

Ez ginen luzaroan poztu, arazo bat agertu baitzen: Catchpoint-eko probek huts egin zuten China Mobile Internet hornitzaileak. Edozein tokitatik denbora-muga bat jaso genuen Tencent-en CDN-ren bidez. Laguntza teknikoarekin egindako korrespondentziak ez zuen ezer ekarri. Arazo hau konpontzen saiatu ginen egun batez, baina ezerk ez zuen funtzionatu.

Txinan nengoen momentu horretan, baina ezin izan dut hornitzaile honen sarean wifi publikoa aurkitu arazoa pertsonalki egiaztatzeko. Bestela dena azkar eta ona ikusten zen.
Hala ere, China Mobile hiru operadore handienetako bat denez, trafikoa Ali CDNra itzultzera behartuta egon ginen.
Baina, oro har, arazo honen probak eta arazoak konpontzea merezi duen irtenbide nahiko interesgarria izan zen.

Akamai

Probatu genuen azken CDN hornitzailea izan zen Akamai. Txinan bere sarea duen hornitzaile handi bat da. Noski, ezin izan dugu gainditu.

Hasiera-hasieratik, Akamai-rekin adostu genuen proba-aldi baterako, domeinua aldatzeko eta haien sarean nola funtzionatuko zuen ikusteko. Proba guztien emaitza "Gustu dudana" eta "Gustu ez dudana" moduan deskribatuko dut eta probaren emaitzak ere emango ditut.

Gustatu zaidana:

• Akamai-ko mutilak oso lagungarriak izan ziren galdera guztietan eta probaren fase guztietan lagundu ziguten. Gure alde zerbait hobetzen saiatzen ginen etengabe. Aholku tekniko onak eman zituzten.
• Akamai gure soluzioa baino % 10-15 motelagoa da Ali Cloud CDN bidez. Ikusgarria dena da Origin for Akamai-n GLBren IP helbidea zehaztu genuela, hau da, trafikoa ez zen gure soluziotik igaro (potentzialki azpiegituraren zati bat alde batera utzi genezake). Hala ere, probaren emaitzek erakutsi zuten irtenbide hau gure egungo bertsioa baino okerragoa dela (emaitzak konparatuak behean).
• Origin GLB eta Origin Txinan probatu dira. Bi aukerak gutxi gorabehera berdinak dira.
• Ez dago Ziur Ibilbidea (bideratze-optimizazio automatikoa). Proba-objektu bat Origin-en osta dezakezu, eta Akamai Edge zerbitzariak hura jasotzen saiatuko dira (ohiko GET). Eskaera horietarako, abiadura eta bestelako neurketak neurtzen dira, eta horietan oinarrituta, Akamai sareak ibilbideak optimizatzen ditu, trafikoa gure gunerako azkarrago joan dadin eta argi zegoen funtzio hau gaitzeak benetan eragin handia zuela gunearen abiaduran.
• Oso polita da web-interfazeko konfigurazioa bertsioratzea. Bertsioetarako Konparatu egin dezakezu, begiratu desberdina. Ikusi aurreko bertsioak.
• Lehenik eta behin, bertsio berri bat kaleratu dezakezu Akamai Staging sarean soilik; ekoizpenaren sare bera, soilik modu honek ez die benetako erabiltzaileei eragingo. Proba honetarako, zure tokiko makinan DNS erregistroak faltsutu behar dituzu.
• Deskarga-abiadura oso azkarra haien sarean fitxategi estatiko handietarako eta, itxuraz, beste edozein fitxategietarako. "Hotzetako" cacheko fitxategi bat Ali CDNren "hotzetako" cacheko fitxategi bera baino askoz azkarrago lortzen da. Cache "beroa"tik, abiadura berdina da dagoeneko, gehi edo ken.

Ali CDN proba:

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 proba:

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

Goiko adibideko egoera hainbat faktoreren araberakoa dela ohartu gara. Puntu hau idazteko momentuan, proba berriro egin nuen. Bi plataformetarako emaitzak gutxi gorabehera berdinak izan ziren. Horrek esaten digu Txinan Internetek, nahiz eta operadore handiek eta hodeiko hornitzaileek, modu ezberdinean jokatzen duela noizean behin.

Aurreko puntuari, Akamai-ri abantaila handi bat gehituko diot: Alik errendimendu handiko eta oso errendimendu baxuko flash antzekoak erakusten baditu (hau Ali CDN, Ali CEN eta Ali IPSEC-i aplikatzen zaie), orduan Akamai, aldi bakoitzean, berdin dio. nola probatzen dudan haien sarea, dena egonkor funtzionatzen du.
Akamai-k estaldura handia du Txinan eta hornitzaile askoren bitartez egiten du lan.

Gustatu ez zaidana:

• Ez zait gustatzen web-interfazea eta funtzionatzeko modua - oso eskasa da. Baina funtsean ohitzen zara (ziurrenik).
• Proben emaitzak gure webgunea baino okerragoak dira.
• Probetan gure webgunean baino errore gehiago daude (behean funtzionatzeko denbora).
• Ez dugu gure DNS zerbitzari propiorik Txinan. Horregatik, akats asko daude probetan DNS ebazteko denbora-muga dela eta.
• Ez dute beren IP barrutiak ematen -> ez dago zuzenak erregistratzeko modurik set_real_ip_from gure zerbitzarietan.

Neurketak (~ 3626 exekuzio; neurketa guztiak Uptime izan ezik, ms-tan; denbora-tarte baterako estatistikak):

CDN hornitzailea
median
75%
95%
Response
Web-orriaren erantzuna
Funtzionamendu
DNS
Konektatu
Itxaron
Karga
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

Banaketa pertzentilaren arabera (ms-tan):

pertzentila
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

Ondorioa hau da: Akamai aukera bideragarria da, baina ez du Ali CDNrekin batera gure soluzio propioaren egonkortasun eta abiadura bera ematen.

Ohar txikiak

Momentu batzuk ez ziren ipuinean sartu, baina horiei buruz ere idatzi nahiko nuke.

Beijing + Tokio eta Hong Kong

Goian esan bezala, IPSEC tunel bat probatu genuen Hong Kongera (HK). Baina CEN-ra HK-ra ere probatu genuen. Gutxiago kostatzen da, eta ~100 km-ko distantzia duten hirien artean nola funtzionatuko zuen galdetzen nion. Interesgarria izan da hiri horien arteko latentzia gure jatorrizko bertsioan (Taiwanera) baino 100 ms handiagoa izatea. Abiadura, egonkortasuna ere hobea zen Taiwanentzat. Ondorioz, HK IPSEC eskualde babeskoi gisa utzi genuen.

Horrez gain, honako instalazio hau instalatzen saiatu gara:

• Bezeroen baja Pekinen,
• IPSEC eta CEN Tokiora,
• Ali CDNn Pekineko zerbitzaria adierazi zen jatorri gisa.

Eskema hau ez zen hain egonkorra, nahiz eta abiadurari dagokionez, oro har, ez zen gure soluzioa baino txikiagoa izan. Tunelari dagokionez, tarteka jaitsierak ikusi ditut CENentzat ere, egonkorra izan behar zuena. Horregatik, eskema zaharrera itzuli eta eszenaratze hori desmuntatu genuen.

Jarraian, kanal ezberdinetarako eskualde ezberdinen arteko latentziari buruzko estatistikak daude. Agian norbait interesatuko zaio.

IPsec
Ali cn-beijing <—> GCP asia-ipar-ekialdea1 — 193 ms
Ali cn-shenzhen <—> GCP asia-east2 — 91 ms
Ali cn-shenzhen <—> GCP us-east4 — 200 ms

CEN
Ali cn-beijing <—> Ali ap-ipar-ekialdea-1 — 54 ms (!)
Ali cn-shenzhen <—> Ali cn-hongkong — 6 ms (!)
Ali cn-shenzhen <—> Ali us-east1 — 216 ​​ms

Txinan Interneti buruzko informazio orokorra

Artikuluaren lehen zatian hasieran azaldutako Interneten arazoei gehigarri gisa.

• Txinan Internet nahiko azkarra da barruan.
  • Ondorioa sare horiek jende ugarik erabiltzen dituen hainbat tokitan Wi-Fi sare publikoak probatzean oinarrituta egin zen.
  • Txina barruko zerbitzarietara deskargatzeko eta kargatzeko abiadurak 20 Mbit/s eta 5-10 Mbit/s ingurukoak ziren, hurrenez hurren.
  • Txinatik kanpoko zerbitzarietarako abiadura eskasa da, 1 Mbit/s baino txikiagoa.
• Txinan Internet ez da oso egonkorra.
  • Batzuetan guneak azkar ireki daitezke, beste batzuetan poliki (eguneko ordu berean egun ezberdinetan), baldin eta konfigurazioa aldatzen ez bada. Hau semrushchina.cn adibidearekin ikusi dugu. Hori Ali CDN-ri egotzi diezaioke, honek ere horrela eta horrela funtzionatzen duen eguneko orduaren, izarren posizioaren, etab.
• Internet mugikorra ia nonahi dago 4G edo 4G+. Harrapatu metroan, igogailuetan - laburbilduz, nonahi.
• Txinako erabiltzaileek .cn eremuko domeinuetan soilik fidatzen dutela mito bat da. Hori zuzenean erabiltzaileengandik ikasi dugu.
  • Ikus dezakezu nola http://baidu.cn birbideratu www.baidu.com-era (Txina kontinentalean ere).
• Baliabide asko blokeatuta daude. Primitiboa: google.com, Facebook, Twitter. Baina Google-ren baliabide askok funtzionatzen dute (noski, ez da Wi-Fi guztietan eta VPN ez da erabiltzen (bideratzailearen aldetik ere, hori ziur).
• Blokeatutako korporazioen domeinu "tekniko" asko ere lanean ari dira. Horrek esan nahi du ez dituzula beti arduragabekeriaz moztu behar Google eta itxuraz blokeatutako beste baliabide guztiak. Debekatutako domeinuen zerrenda batzuk bilatu behar dituzu.
• Hiru Internet operadore nagusi baino ez dituzte: China Unicom, China Telecom, China Mobile. Are txikiagoak daude, baina merkatu kuota hutsala da

Bonua: azken irtenbidearen diagrama

Guztira

Urtebete igaro da proiektua hasi zenetik. Gure guneak, oro har, Txinatik normalean funtzionatzeari uko egin ziola hasi ginen, eta GET kizkurra 5.5 segundo behar izan zituen.

Ondoren, adierazle hauek lehen irtenbidean (Cloudflare):

Erabaki
Funtzionamendu
median
75 ehunekoa
95 ehunekoa

CloudFlare
86.6
18s
30s
60s

Azkenean, ondorengo emaitzetara iritsi ginen (azken hilabeteko estatistikak):

Erabaki
Funtzionamendu
median
75 ehunekoa
95 ehunekoa

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

Ikusten duzunez, oraindik ezin izan dugu %100eko funtzionamendu-denbora lortu, baina zerbait asmatuko dugu, eta gero artikulu berri batean emaitzak kontatuko dizkizugu :)

Errespetua hiru zatiak amaiera arte irakurri dituztenei. Espero dut hau guztia egin dudanean ni bezain interesgarria iruditu izana.

PS Aurreko zatiak

Xnumx-ren zati bat
Xnumx-ren zati bat

Iturria: www.habr.com