Sut wnaethon ni dorri trwy'r Wal Dân Fawr Tsieineaidd (Rhan 3)

Hi!
Pob stori dda yn dod i ben. Ac nid yw ein stori am sut y gwnaethom ddod o hyd i ateb i basio'r Firewall Tsieineaidd yn gyflym yn eithriad. Felly, brysiaf i rannu'r olaf gyda chi, y rhan olaf ar y pwnc hwn.

Yn y rhan flaenorol buom yn sôn am lawer o feinciau prawf a luniwyd gennym a pha ganlyniadau a roddwyd ganddynt. Ac fe wnaethom setlo ar yr hyn y byddai'n braf ei ychwanegu CDN! am gludedd yn ein cynllun.

Fe ddywedaf wrthych sut y gwnaethom brofi Alibaba Cloud CDN, Tencent Cloud CDN ac Akamai, a'r hyn a wnaethom yn y diwedd. Ac wrth gwrs, gadewch i ni grynhoi.

CDN Cwmwl Alibaba

Rydyn ni'n cael ein cynnal ar Alibaba Cloud ac yn defnyddio IPSEC a CEN ganddyn nhw. Byddai'n rhesymegol rhoi cynnig ar eu hatebion yn gyntaf.

Mae gan Alibaba Cloud ddau fath o gynnyrch a allai fod yn addas i ni: CDN и DCDN. Yr opsiwn cyntaf yw CDN clasurol ar gyfer parth penodol (is-barth). Mae'r ail opsiwn yn sefyll am Llwybr Dynamig ar gyfer CDN (Rwy'n ei alw'n CDN deinamig), gellir ei alluogi yn y modd Safle Llawn (ar gyfer parthau cerdyn gwyllt), mae hefyd yn storio cynnwys statig ac yn cyflymu cynnwys deinamig ynddo'i hun, hynny yw, bydd deinameg y dudalen hefyd yn cael ei lwytho trwy ddeinameg y darparwr rhwydweithiau cyflym. Mae hyn yn bwysig i ni, oherwydd yn y bôn mae ein gwefan yn ddeinamig, mae'n defnyddio llawer o is-barthau, ac mae'n fwy cyfleus sefydlu CDN unwaith ar gyfer y “seren” - *.semrushchina.cn.

Roeddem eisoes wedi gweld y cynnyrch hwn yng nghamau cynharach ein prosiect Tsieineaidd, ond yna nid oedd yn gweithio eto, ac addawodd y datblygwyr y byddai'r cynnyrch ar gael yn fuan i bob cwsmer. Ac efe a wnaeth.

Yn DCDN gallwch:

• ffurfweddu terfyniad SSL gyda'ch tystysgrif,
• galluogi cyflymu cynnwys deinamig,
• ffurfweddu caching o ffeiliau statig yn hyblyg,
• glanhau'r storfa,
• socedi gwe ymlaen,
• galluogi cywasgu a hyd yn oed HTML Beautifier.

Yn gyffredinol, mae popeth yr un fath ag oedolion a darparwyr CDN mawr.

Ar ôl i'r Tarddiad (y man lle bydd gweinyddwyr ymyl CDN yn mynd) gael ei nodi, y cyfan sydd ar ôl yw creu CNAME ar gyfer y seren, gan gyfeirio at all.semrushchina.cn.w.kunluncan.com (derbyniwyd y CNAME hwn yn y consol Alibaba Cloud) a bydd y CDN yn gweithio.

Yn seiliedig ar ganlyniadau'r profion, fe wnaeth y CDN hwn ein helpu ni'n fawr. Dangosir yr ystadegau isod.

penderfyniad
Uptime
Canolrif
75 Canradd
95 Canradd

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

Mae'r rhain yn ganlyniadau da iawn, yn enwedig os ydych chi'n eu cymharu â'r hyn oedd y niferoedd ar y dechrau. Ond roeddem yn gwybod bod prawf porwr fersiwn Americanaidd ein gwefan www.semrush.com yn rhedeg o UDA mewn cyfartaledd o 8.3s (gwerth bras iawn). Mae lle i wella. Ar ben hynny, roedd yna hefyd ddarparwyr CDN a oedd yn ddiddorol i'w profi.

Felly symudwn ymlaen yn ddidrafferth at gawr arall yn y farchnad Tsieineaidd - Tencent.

Cwmwl Tencent

Dim ond datblygu ei gwmwl y mae Tencent - gellir gweld hyn o nifer fach o gynhyrchion. Wrth ei ddefnyddio, roeddem am brofi nid yn unig eu CDN, ond hefyd eu seilwaith rhwydwaith yn ei gyfanrwydd:

• oes ganddyn nhw rywbeth tebyg i CEN?
• Sut mae IPSEC yn gweithio iddyn nhw? A yw'n gyflym, beth yw'r uptime?
• oes ganddyn nhw Anycast?

Gadewch i ni edrych ar y cwestiynau hyn ar wahân.

CEN analog

Mae gan Tencent gynnyrch Rhwydwaith Cloud Connect (CCN), sy'n eich galluogi i gysylltu VPCs o wahanol ranbarthau, gan gynnwys rhanbarthau y tu mewn a thu allan i Tsieina. Mae'r cynnyrch bellach mewn beta mewnol, ac mae angen i chi greu tocyn yn gofyn am gysylltu ag ef. Fe wnaethom ddysgu o gefnogaeth na all cyfrifon byd-eang (nid ydym yn sôn am ddinasyddion Tsieineaidd nac endidau cyfreithiol) gymryd rhan yn y rhaglen brofi beta ac, yn gyffredinol, cysylltu rhanbarth y tu mewn i Tsieina â rhanbarth y tu allan. 1-0 o blaid Ali Cloud

IPSEC

Rhanbarth mwyaf deheuol Tencent yw Guangzhou. Fe wnaethon ni ymgynnull twnnel a'i gysylltu â rhanbarth Hong Kong yn GCP (yna roedd y rhanbarth hwn eisoes ar gael). Codwyd yr ail dwnnel yn Ali Cloud o Shenzhen i Hong Kong ar yr un pryd hefyd. Mae'n troi allan bod drwy rwydwaith Tencent y hwyrni i Hong Kong yn gyffredinol well (10ms) nag o Shenzhen i Hong Kong i Ali (120ms - beth?). Ond nid oedd hyn mewn unrhyw ffordd yn cyflymu gwaith y safle a anelwyd at weithio trwy Tencent a'r twnnel hwn, a oedd ynddo'i hun yn ffaith anhygoel ac unwaith eto wedi profi'r canlynol: hwyrni - i Tsieina nid yw hwn yn ddangosydd sy'n wirioneddol werth rhoi sylw i wrth ddatblygu ateb ar gyfer pasio'r wal dân Tsieineaidd.

Cyflymiad Rhyngrwyd Anycast

Cynnyrch arall sy'n eich galluogi i weithio trwy anycast IP yw AIA. Ond nid yw hefyd ar gael i gyfrifon byd-eang, felly ni fyddaf yn dweud wrthych amdano, ond gallai fod yn ddefnyddiol gwybod bod cynnyrch o'r fath yn bodoli.

Ond dangosodd y prawf CDN rai canlyniadau eithaf diddorol. Ni ellir galluogi CDN Tencent ar wefan lawn, dim ond ar barthau penodol. Fe wnaethon ni greu parthau ac anfon traffig atynt:

Daeth i'r amlwg bod gan y CDN hwn y swyddogaeth ganlynol: Optimeiddio Traffig Trawsffiniol. Dylai'r nodwedd hon leihau costau pan fydd traffig yn mynd trwy'r wal dân Tsieineaidd. Fel Tarddiad Pennwyd cyfeiriad IP Google GLB (GLB anycast). Felly, roeddem am symleiddio pensaernïaeth y prosiect.

Roedd y canlyniadau'n dda iawn - ar lefel Ali Cloud CDN, ac mewn rhai mannau hyd yn oed yn well. Mae hyn yn syndod, oherwydd os bydd y profion yn llwyddiannus, gallwch chi roi'r gorau i ran sylweddol o'r seilwaith, twneli, CEN, peiriannau rhithwir, ac ati.

Wnaethon ni ddim llawenhau yn hir, wrth i broblem gael ei datgelu: methodd profion yn Catchpoint ar gyfer y darparwr Rhyngrwyd China Mobile. O unrhyw leoliad cawsom egwyl trwy CDN Tencent. Nid oedd gohebiaeth â chymorth technegol yn arwain at unrhyw beth. Fe wnaethon ni geisio datrys y broblem hon am tua diwrnod, ond ni weithiodd dim.

Roeddwn yn Tsieina ar y foment honno, ond ni allwn ddod o hyd i Wi-Fi cyhoeddus ar rwydwaith y darparwr hwn i wirio'r broblem yn bersonol. Fel arall roedd popeth yn edrych yn gyflym ac yn dda.
Fodd bynnag, oherwydd y ffaith bod China Mobile yn un o'r tri gweithredwr mwyaf, fe'n gorfodwyd i ddychwelyd traffig i Ali CDN.
Ond yn gyffredinol, roedd hwn yn ateb eithaf diddorol sy'n haeddu profi hirach a datrys problemau'r broblem hon.

Akamai

Y darparwr CDN diwethaf i ni ei brofi oedd Akamai. Mae hwn yn ddarparwr enfawr sydd â'i rwydwaith yn Tsieina. Wrth gwrs, ni allem fynd heibio iddo.

O'r cychwyn cyntaf, fe wnaethom gytuno ag Akamai am gyfnod prawf fel y gallem newid y parth a gweld sut y byddai'n gweithio ar eu rhwydwaith. Byddaf yn disgrifio canlyniad yr holl brofion ar ffurf “Beth roeddwn i'n ei hoffi” a “Yr hyn nad oeddwn yn ei hoffi,” a byddaf hefyd yn rhoi canlyniadau'r prawf.

Yr hyn yr oeddem yn ei hoffi:

• Roedd y bechgyn o Akamai yn gymwynasgar iawn ym mhob cwestiwn ac yn mynd gyda ni ar bob cam o'r profion. Roeddem yn gyson yn ceisio gwella rhywbeth ar ein hochr ni. Rhoesant gyngor technegol da.
• Mae Akamai tua 10-15% yn arafach na'n datrysiad trwy Ali Cloud CDN. Yr hyn sy'n drawiadol yw ein bod yn Origin for Akamai wedi nodi cyfeiriad IP y GLB, sy'n golygu na aeth y traffig trwy ein datrysiad (o bosibl y gallem gefnu ar ran o'r seilwaith). Ond o hyd, dangosodd canlyniadau'r profion fod yr ateb hwn yn waeth na'n fersiwn gyfredol (canlyniadau cymharol isod).
• Wedi profi Origin GLB a Origin yn Tsieina. Mae'r ddau opsiwn tua'r un peth.
• Mae Llwybr Cadarn (optimeiddio llwybro awtomatig). Gallwch chi gynnal gwrthrych prawf ar Origin, a bydd gweinyddwyr Akamai Edge yn ceisio ei godi (GET rheolaidd). Ar gyfer y ceisiadau hyn, mesurir cyflymder a metrigau eraill, ar sail y mae rhwydwaith Akamai yn gwneud y gorau o'r llwybrau fel bod traffig yn mynd yn gyflymach i'n gwefan ac roedd yn amlwg bod galluogi'r nodwedd hon wedi cael effaith fawr ar gyflymder y wefan.
• Mae fersiwnio'r ffurfweddiad yn y rhyngwyneb gwe yn cŵl. Gallwch chi wneud Cymharwch am fersiynau, edrychwch ar diff. Gweld fersiynau blaenorol.
• Dim ond ar rwydwaith Akamai Staging y gallwch chi gyflwyno fersiwn newydd yn gyntaf - yr un rhwydwaith â chynhyrchu, dim ond fel hyn ni fydd yn effeithio ar ddefnyddwyr go iawn. Ar gyfer y prawf hwn, mae angen i chi ffugio cofnodion DNS ar eich peiriant lleol.
• Cyflymder lawrlwytho cyflym iawn trwy eu rhwydwaith ar gyfer ffeiliau sefydlog mawr, ac, yn ôl pob tebyg, unrhyw ffeiliau eraill. Mae ffeil o'r storfa “oer” yn cael ei hadalw lawer gwaith yn gyflymach na'r un ffeil o storfa “oer” Ali CDN. O'r storfa “poeth”, mae'r cyflymder eisoes yr un peth, plws neu finws.

Prawf CDN Ali:

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

Prawf Akamai:

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

Gwelsom fod y sefyllfa yn yr enghraifft uchod yn dibynnu ar wahanol ffactorau. Ar adeg ysgrifennu'r pwynt hwn, rhedais y prawf eto. Roedd y canlyniadau ar gyfer y ddau blatfform fwy neu lai yr un fath. Mae hyn yn dweud wrthym fod y Rhyngrwyd yn Tsieina, hyd yn oed ar gyfer gweithredwyr mawr a darparwyr cwmwl, yn ymddwyn yn wahanol o bryd i'w gilydd.

I'r pwynt blaenorol, byddaf yn ychwanegu mantais fawr i Akamai: os yw Ali yn dangos fflachiadau tebyg o berfformiad uchel a pherfformiad isel iawn (mae hyn yn berthnasol i Ali CDN, Ali CEN, ac Ali IPSEC), yna Akamai, bob tro, ni waeth sut rydw i'n profi eu rhwydwaith, mae popeth yn gweithio'n sefydlog.
Mae gan Akamai lawer o sylw yn Tsieina ac mae'n gweithio trwy lawer o ddarparwyr.

Beth nad oedd yn ei hoffi:

• Dydw i ddim yn hoffi'r rhyngwyneb gwe a'r ffordd mae'n gweithio - mae mor wael. Ond yn y bôn rydych chi'n dod i arfer ag ef (yn ôl pob tebyg).
• Mae canlyniadau profion yn waeth na'n gwefan.
• Mae mwy o wallau yn ystod profion nag ar ein gwefan (uptime isod).
• Nid oes gennym ein gweinyddwyr DNS ein hunain yn Tsieina. Felly mae yna lawer o wallau mewn profion oherwydd terfyn amser datrys DNS.
• Nid ydynt yn darparu eu hystodau IP -> nid oes unrhyw ffordd i gofrestru'r rhai cywir set_real_ip_from ar ein gweinyddion.

Metrigau (~ rhediadau 3626; pob metrig ac eithrio Uptime, mewn ms; ystadegau am un cyfnod amser):

Darparwr CDN
Canolrif
75%
95%
Ymateb
Ymateb Tudalen We
Uptime
DNS
Cyswllt
Arhoswch
Llwyth
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

Dosbarthiad yn ôl Canradd (mewn ms):

Canran
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

Y casgliad yw hyn: mae opsiwn Akamai yn hyfyw, ond nid yw'n darparu'r un sefydlogrwydd a chyflymder â'n datrysiad ein hunain ynghyd ag Ali CDN.

Nodiadau bach

Ni chynhwyswyd rhai eiliadau yn y stori, ond hoffwn ysgrifennu amdanynt hefyd.

Beijing + Tokyo a Hong Kong

Fel y dywedais uchod, fe wnaethon ni brofi twnnel IPSEC i Hong Kong (HK). Ond fe wnaethon ni hefyd brofi CEN i HK. Mae'n costio ychydig yn llai, ac roeddwn i'n meddwl tybed sut y byddai'n gweithio rhwng dinasoedd sydd â phellter o ~100 km. Roedd yn ddiddorol bod yr hwyrni rhwng y dinasoedd hyn 100m yn uwch nag yn ein fersiwn wreiddiol (i Taiwan). Roedd cyflymder, sefydlogrwydd hefyd yn well i Taiwan. O ganlyniad, gadawsom HK fel rhanbarth IPSEC wrth gefn.

Yn ogystal, rydym yn ceisio gosod y gosodiad canlynol:

• terfynu cleientiaid yn Beijing,
• IPSEC a CEN i Tokyo,
• yn Ali CDN nodwyd y gweinydd yn Beijing fel y tarddiad.

Nid oedd y cynllun hwn mor sefydlog, er o ran cyflymder yn gyffredinol nid oedd yn israddol i'n datrysiad. O ran y twnnel, rwyf wedi gweld diferion ysbeidiol hyd yn oed ar gyfer CEN, a ddylai fod yn sefydlog. Felly, dychwelasom at yr hen gynllun a datgymalu’r llwyfannu hwn.

Isod mae ystadegau ar hwyrni rhwng gwahanol ranbarthau ar gyfer gwahanol sianeli. Efallai y bydd gan rywun ddiddordeb ynddo.

IPsec
Ali cn-beijing <—> GCP asia-gogledd-ddwyrain1 — 193ms
Ali cn-Shenzhen <—> GCP asia-ddwyrain2 — 91ms
Ali cn-Shenzhen <—> GCP us-east4 — 200ms

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

Gwybodaeth gyffredinol am y Rhyngrwyd yn Tsieina

Fel ychwanegiad at y problemau gyda'r Rhyngrwyd a ddisgrifiwyd ar y cychwyn cyntaf, yn rhan gyntaf yr erthygl.

• Rhyngrwyd yn Tsieina yn eithaf cyflym y tu mewn.
  • Daethpwyd i'r casgliad yn seiliedig ar brofi rhwydweithiau Wi-Fi cyhoeddus mewn gwahanol leoliadau lle mae'r rhwydweithiau hyn yn cael eu defnyddio gan nifer fawr o bobl.
  • Roedd y cyflymder llwytho i lawr a llwytho i fyny i weinyddion yn Tsieina tua 20 Mbit yr eiliad a 5-10 Mbit yr eiliad, yn y drefn honno.
  • Yn syml, mae'r cyflymder i weinyddion y tu allan i Tsieina yn brin, yn llai nag 1 Mbit yr eiliad.
• Nid yw'r Rhyngrwyd yn Tsieina yn sefydlog iawn.
  • Weithiau gall safleoedd agor yn gyflym, weithiau'n araf (ar yr un amser o'r dydd ar ddiwrnodau gwahanol), ar yr amod nad yw'r ffurfweddiad yn newid. Gwelsom hyn gyda'r enghraifft o semrushchina.cn. Gellir priodoli hyn i Ali CDN, sydd hefyd yn gweithio fel hyn ac yn dibynnu ar yr amser o'r dydd, lleoliad y sêr, ac ati.
• Mae Rhyngrwyd Symudol bron ym mhobman 4G neu 4G+. Daliwch ef yn yr isffordd, codwyr - yn fyr, ym mhobman.
• Mae'n chwedl bod defnyddwyr Tsieineaidd yn ymddiried mewn parthau yn y parth .cn yn unig. Fe wnaethom ddysgu hyn yn uniongyrchol gan ddefnyddwyr.
  • Gallwch weld sut http://baidu.cn ailgyfeirio i www.baidu.com (ar dir mawr Tsieina hefyd).
• Mae llawer o adnoddau yn wir wedi'u rhwystro. Cyntefig: google.com, Facebook, Twitter. Ond mae llawer o adnoddau Google yn gweithio (wrth gwrs, nid ar bob Wi-Fi ac ni ddefnyddir VPN (ar ochr y llwybrydd hefyd, mae hynny'n sicr).
• Mae llawer o barthau “technegol” o gorfforaethau sydd wedi'u blocio hefyd yn gweithio. Mae hyn yn golygu na ddylech bob amser dorri allan yn ddi-hid yr holl adnoddau Google ac adnoddau eraill sydd i bob golwg wedi'u rhwystro. Mae angen ichi edrych am restr o barthau gwaharddedig.
• Dim ond tri phrif weithredwr Rhyngrwyd sydd ganddyn nhw: China Unicom, China Telecom, China Mobile. Mae rhai hyd yn oed yn llai, ond mae eu cyfran o'r farchnad yn ddibwys

Bonws: diagram datrysiad terfynol

Cyfanswm

Mae blwyddyn wedi mynd heibio ers dechrau'r prosiect. Dechreuon ni gyda'r ffaith bod ein gwefan yn gyffredinol yn gwrthod gweithio fel arfer o Tsieina, ac yn syml iawn cymerodd GET curl 5.5 eiliad.

Yna, gyda'r dangosyddion hyn yn yr ateb cyntaf (Cloudflare):

penderfyniad
Uptime
Canolrif
75 Canradd
95 Canradd

Cloudflare
86.6
18s
30s
60s

Yn y diwedd fe wnaethom gyrraedd y canlyniadau canlynol (ystadegau ar gyfer y mis diwethaf):

penderfyniad
Uptime
Canolrif
75 Canradd
95 Canradd

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

Fel y gallwch weld, nid ydym eto wedi gallu cyflawni 100% uptime, ond byddwn yn meddwl am rywbeth, ac yna byddwn yn dweud wrthych am y canlyniadau mewn erthygl newydd :)

Parch i'r rhai sy'n darllen y tair rhan hyd y diwedd. Gobeithio bod hyn i gyd mor ddiddorol ag y gwnes i pan wnes i.

PS Rhannau blaenorol

Rhan 1
Rhan 2

Ffynhonnell: hab.com