څنګه موږ د لوی چینایي فایروال له لارې مات شو (3 ​​برخه)

سلام!
ټولې ښې کیسې پای ته رسیږي. او زموږ کیسه پدې اړه چې څنګه موږ د چین فایروال ګړندي تیرولو لپاره د حل سره راغلی یو استثنا نه ده. له همدې امله، زه په چټکۍ سره ستاسو سره وروستی شریک کړم، وروستۍ برخه په دې موضوع.

په تیره برخه کې موږ د ډیری ازموینې بنچونو په اړه خبرې وکړې چې موږ ورسره مخ شو او کومې پایلې یې ورکړې. او موږ په هغه څه بسیا شو چې اضافه کول به ښه وي CDN! زموږ په سکیم کې د ویسکوسیت لپاره.

زه به تاسو ته ووایم چې څنګه موږ د علی بابا کلاوډ CDN، Tencent Cloud CDN او Akamai ازموینه وکړه، او موږ څه سره پای ته ورسیږو. او البته، راځئ چې لنډیز وکړو.

څنګه موږ د لوی چینایي فایروال له لارې مات شو (3 ​​برخه)

علی بابا کلاوډ CDN

موږ په علی بابا کلاوډ کې کوربه یو او له دوی څخه IPSEC او CEN کاروو. دا به منطقي وي چې لومړی د دوی حلونه هڅه وکړئ.

علی بابا کلاوډ دوه ډوله محصولات لري چې ممکن زموږ سره مناسب وي: CDN и DCDN. لومړی اختیار د ځانګړي ډومین (فرعي ډومین) لپاره کلاسیک CDN دی. دوهم اختیار د دې لپاره ولاړ دی د CDN لپاره متحرک لاره (زه دې ته متحرک CDN وایم) ، دا د بشپړ سایټ حالت کې فعال کیدی شي (د وائلډ کارډ ډومینونو لپاره) ، دا هم جامد مینځپانګه کیچ کوي او پخپله متحرک مینځپانګه ګړندي کوي ، دا دی چې د پاڼې متحرکات به هم د چمتو کونکي له لارې بار شي. چټکې شبکې. دا زموږ لپاره مهم دی، ځکه چې اساسا زموږ سایټ متحرک دی، دا ډیری فرعي ډومینونه کاروي، او دا د "ستوري" - *.semrushchina.cn لپاره یو ځل د CDN ترتیب کول خورا اسانه دي.

موږ دا محصول لا دمخه زموږ د چینایي پروژې په لومړیو مرحلو کې لیدلی و، مګر بیا یې کار نه و کړی، او پراختیا کونکو ژمنه وکړه چې دا محصول به ډیر ژر ټولو پیرودونکو ته وړاندې شي. او هغه وکړل.

په DCDN کې تاسو کولی شئ:

  • د خپل سند سره د SSL ختمول تنظیم کړئ،
  • د متحرک مینځپانګې ګړندی کول ،
  • په انعطاف سره د جامد فایلونو کیچ کول تنظیم کړئ ،
  • زیرمه پاکول،
  • مخکینۍ ویب ساکټونه
  • کمپریشن او حتی HTML بیوټیفیر فعال کړئ.

په عموم کې، هرڅه د لویانو او لوی CDN چمتو کونکو سره ورته دي.

وروسته له دې چې اصلي (هغه ځای چې د CDN څنډې سرورونه به ځي) مشخص شي، ټول هغه څه چې پاتې دي د ستوري لپاره د CNAME رامینځته کول دي، حواله کول all.semrushchina.cn.w.kunluncan.com (دا CNAME په علی بابا کلاوډ کنسول کې ترلاسه شوی) او CDN به کار وکړي.

د ازموینې پایلو پراساس، دې CDN موږ سره ډیره مرسته وکړه. احصایې لاندې ښودل شوي.

پریکړه
Uptime
میډیا
75 سلنه
95 سلنه

Cloudflare
86.6
18
30
60

IPsec
99.79
18
21
30

CEN
99.75
16
21
27

CEN/IPsec + GLB
99.79
13
16
25

علي CDN + CEN/IPsec + GLB
99.75
10
12.8
17.3

دا خورا ښه پایلې دي، په ځانګړې توګه که تاسو دوی د هغه څه سره پرتله کړئ چې شمیرې یې په پیل کې وې. مګر موږ پوهیږو چې زموږ د ویب پا www.semrush.com د امریکایی نسخې براوزر ازموینه په اوسط ډول 8.3s (ډیر نږدې ارزښت) کې له متحده ایالاتو څخه تیریږي. د پرمختګ لپاره ځای شتون لري. سربیره پردې ، د CDN چمتو کونکي هم شتون درلود چې د ازموینې لپاره په زړه پوري وو.

نو موږ په اسانۍ سره د چین په بازار کې بل لوی ته حرکت کوو - Tencent.

Tencent ورېځ

Tencent یوازې خپل کلاوډ رامینځته کوي - دا د لږ شمیر محصولاتو څخه لیدل کیدی شي. د دې کارولو پرمهال، موږ غوښتل چې نه یوازې د دوی CDN، بلکې د دوی د شبکې زیربنا هم په ټوله کې ازموینه وکړو:

  • ایا دوی د CEN سره ورته یو څه لري؟
  • IPSEC د دوی لپاره څنګه کار کوي؟ ایا دا چټک دی، د وخت وخت څه دی؟
  • ایا دوی Anycast لري؟

څنګه موږ د لوی چینایي فایروال له لارې مات شو (3 ​​برخه)

راځئ چې دا پوښتنې په جلا توګه وګورو.

انلاګ CEN

Tencent یو محصول لري د Cloud Connect شبکه (CCN)، تاسو ته اجازه درکوي چې د مختلفو سیمو څخه VPCs وصل کړئ، په شمول د چین دننه او بهر سیمې. محصول اوس په داخلي بیټا کې دی، او تاسو اړتیا لرئ یو ټکټ جوړ کړئ چې له هغې سره وصل شئ. موږ د ملاتړ څخه زده کړل چې نړیوال حسابونه (موږ د چینایي اتباعو یا قانوني ادارو په اړه خبرې نه کوو) نشي کولی د بیټا ازموینې برنامې کې برخه واخلي او په عموم کې ، د چین دننه یوه سیمه بهر له یوې سیمې سره وصل کړي. 1-0 د علي بادل په ګټه

IPIss

د Tencent تر ټولو جنوبي سیمه ده ګوانګزو. موږ یو تونل راټول کړ او په GCP کې یې د هانګ کانګ سیمې سره وصل کړ (بیا دا سیمه لا دمخه شتون درلود). له شينجيانګ څخه هانګ کانګ ته د علي بادل دوهم تونل هم په همدې وخت کې پورته شو. دا معلومه شوه چې د Tencent شبکې له لارې هانګ کانګ ته ځنډ عموما ښه دی (10ms) د شینزین څخه هانګ کانګ ته علي (120ms - څه؟). مګر دا په هیڅ ډول د سایټ کار ګړندی نه کړ چې هدف یې د Tencent او دې تونل له لارې کار کول دي ، کوم چې پخپله یو حیرانونکی حقیقت و او یوځل بیا یې لاندې ثابت کړ: ځنډ - د چین لپاره دا یو شاخص ندی چې واقعیا ارزښت لري. د چینایی فایروال تیریدو لپاره د حل رامینځته کولو په وخت کې پاملرنه کول.

د Anycast انټرنیټ سرعت

بل محصول چې تاسو ته اجازه درکوي د هر کاسټ IP له لارې کار وکړئ AIA. مګر دا د نړیوالو حسابونو لپاره هم شتون نلري، نو زه به تاسو ته د دې په اړه ونه وایم، مګر پدې پوهیدل چې دا ډول محصول شتون لري ممکن ګټور وي.

مګر د CDN ازموینې ځینې خورا په زړه پوري پایلې وښودلې. د Tencent CDN نشي کولی په بشپړ سایټ کې فعال شي، یوازې په ځانګړو ډومینونو کې. موږ ډومینونه جوړ کړل او دوی ته مو ټرافيک لیږلی:

څنګه موږ د لوی چینایي فایروال له لارې مات شو (3 ​​برخه)

دا معلومه شوه چې دا CDN لاندې فعالیت لري: د پولې په اوږدو کې د ټرافیکو اصلاح کول. دا خصوصیت باید لګښتونه کم کړي کله چې ترافیک د چینایي اور وژنې له لارې تیریږي. لکه منشا د ګوګل GLB IP پته (GLB anycast) مشخص شوی. په دې توګه، موږ غوښتل چې د پروژې جوړښت ساده کړو.

پایلې خورا ښه وې - د علي کلاډ CDN په کچه، او په ځینو ځایونو کې حتی ښه. دا د حیرانتیا خبره ده، ځکه چې که ازموینې بریالۍ وي، تاسو کولی شئ د زیربنا، تونلونو، CEN، مجازی ماشینونو، او داسې نورو یوه مهمه برخه پریږدئ.

موږ د اوږدې مودې لپاره خوښ نه شو، لکه څنګه چې ستونزه څرګنده شوه: په کیچ پواینټ کې ازموینې د انټرنیټ چمتو کونکي چین ګرځنده لپاره ناکامه شوې. له هر ځای څخه موږ د Tencent's CDN له لارې وخت پای ترلاسه کړ. د تخنیکي مالتړ سره اړیکه د هیڅ شی لامل نه شوه. یوه ورځ مو هڅه وکړه چې دغه ستونزه حل کړو، خو هیڅ کار مو نه دی کړی.

زه په هغه وخت کې په چین کې وم ، مګر د دې چمتو کونکي شبکې کې عامه وائی فای نشم موندلی ترڅو ستونزه په شخصي توګه تصدیق کړي. که نه نو هر څه چټک او ښه ښکاري.
په هرصورت، د دې حقیقت له امله چې د چین موبایل یو له دریو لویو چلونکو څخه دی، موږ اړ شو چې د علي CDN ته ترافیک بیرته واستوو.
مګر په ټولیز ډول، دا یو په زړه پورې حل و چې د اوږدې ازموینې او د دې ستونزې د حل کولو مستحق دی.

اکامي

وروستی CDN چمتو کونکی چې موږ یې ازموینه کړې وه اکامي. دا یو لوی چمتو کونکی دی چې په چین کې یې شبکه لري. البته، موږ نشو کولی دا تیر کړو.

څنګه موږ د لوی چینایي فایروال له لارې مات شو (3 ​​برخه)

له پیل څخه، موږ د اکامي سره د محاکمې دورې لپاره موافقه وکړه ترڅو موږ ډومین بدل کړو او وګورو چې دا به د دوی په شبکه کې څنګه کار وکړي. زه به د ټولو ازموینو پایله د "هغه څه چې ما خوښ کړه" او "هغه څه چې ما نه خوښول" په بڼه تشریح کړم او زه به د ازموینې پایلې هم ورکړم.

هغه څه چې موږ خوښ کړل:

  • د اکامي هلکان په ټولو پوښتنو کې خورا ګټور وو او د ازموینې په ټولو مرحلو کې زموږ سره ملګري وو. موږ په دوامداره توګه هڅه کوله چې زموږ په لور یو څه ښه کړو. دوی ښه تخنیکي مشوره ورکړه.
  • اکامي د علي کلاوډ CDN له لارې زموږ د حل په پرتله شاوخوا 10-15٪ ورو دی. هغه څه چې اغیزمن دي دا دي چې د اکامي لپاره په اصل کې موږ د GLB IP پته مشخص کړه، پدې معنی چې ټرافيک زموږ د حل له لارې نه و تللی (احتمالي موږ کولی شو د زیربنا یوه برخه پریږدو). مګر بیا هم، د ازموینې پایلې ښودلې چې دا حل زموږ د اوسني نسخې څخه ډیر خراب دی (لاندې پرتله کولو پایلې).
  • په چین کې د اصلي GLB او اوریجن دواړه ازمول شوي. دواړه اختیارونه تقریبا ورته دي.
  • موجود دي ډاډه لاره (د اتوماتیک روټینګ اصلاح کول). تاسو کولی شئ په اصل کې د ازموینې څیز کوربه کړئ، او د اکامي ایج سرورونه به هڅه وکړي چې دا غوره کړي (منظم GET). د دې غوښتنو لپاره، سرعت او نور میټریکونه اندازه کیږي، چې پر بنسټ یې د اکامي شبکه لارې غوره کوي ترڅو ټرافيک زموږ سایټ ته ګړندی شي او دا روښانه وه چې د دې خصوصیت فعالول واقعیا د سایټ په سرعت خورا قوي اغیزه درلوده.
  • په ویب انٹرفیس کې د ترتیب نسخه کول ښه دي. تاسو کولی شئ د نسخو لپاره پرتله کړئ، توپیر وګورئ. پخوانۍ نسخې وګورئ.
  • تاسو کولی شئ یو نوی نسخه لومړی یوازې د اکامای سټیګینګ شبکه کې راوباسئ - د تولید په څیر ورته شبکه ، یوازې دا به په ریښتیني کاروونکو اغیزه ونکړي. د دې ازموینې لپاره، تاسو اړتیا لرئ چې په خپل محلي ماشین کې د DNS ریکارډونه غلا کړئ.
  • د دوی د شبکې له لارې د لوی جامد فایلونو لپاره خورا ګړندی ډاونلوډ سرعت ، او په څرګند ډول ، کوم بل فایلونه. د "سړې" کیچ څخه فایل د ورته فایل په پرتله څو ځله ګړندی د علي CDN د "سړې" زیرمې څخه ترلاسه کیږي. د "ګرم" کیچ څخه، سرعت لا دمخه یو شان دی، جمع یا منفي.

د علي CDN ازموینه:

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

د اکامي ازموینه:

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

موږ ولیدل چې په پورته مثال کې وضعیت په مختلفو عواملو پورې اړه لري. د دې ټکي لیکلو په وخت کې ، ما بیا ازموینه واخیسته. د دواړو پلیټ فارمونو پایلې نږدې ورته وې. دا موږ ته وایی چې په چین کې انټرنیټ ، حتی د لوی آپریټرانو او کلاوډ چمتو کونکو لپاره ، وخت په وخت مختلف چلند کوي.

مخکیني ټکي ته ، زه به د اکامي لپاره یو لوی پلس اضافه کړم: که علي د لوړ فعالیت او خورا ټیټ فعالیت ورته چمکونه وښیې (دا په علي CDN ، علي CEN ، او علي IPSEC باندې پلي کیږي) ، نو اکامي ، هر وخت ، هیڅ اهمیت نلري زه څنګه د دوی شبکه ازموینه کوم، هرڅه په ثابت ډول کار کوي.
اکامي په چین کې ډیر پوښښ لري او د ډیری چمتو کونکو له لارې کار کوي.

هغه څه چې ما خوښ نه کړل:

  • زه د ویب انٹرفیس او هغه طریقه نه خوښوم چې دا کار کوي - دا خورا خراب دی. مګر اساسا تاسو دې سره عادت یاست (شاید).
  • د ازموینې پایلې زموږ د سایټ څخه بدتر دي.
  • زموږ د سایټ په پرتله د ازموینو په جریان کې ډیرې غلطۍ شتون لري (لاندې وخت وخت).
  • موږ په چین کې خپل DNS سرورونه نلرو. له همدې امله د DNS حل کولو وخت پای ته رسیدو له امله په ازموینو کې ډیری غلطۍ شتون لري.
  • دوی د دوی د IP سلسلې نه وړاندې کوي -> د سمو راجستر کولو لپاره کومه لاره نشته set_real_ip_from زموږ په سرورونو کې.

میټریکونه (~ 3626 منډې؛ ټول میټریکونه پرته له اپټایم، په ms کې؛ د یو وخت مودې لپاره احصایې):

د CDN چمتو کوونکی
میډیا
۸۵٪
۸۵٪
ځواب
د ویب پاڼې ځواب
Uptime
ډی
سره نښلوي
انتظار
بار
ایس ایس

AliCDN
9195
10749
17489
1,715
10,745
99.531
57
17
927
479
200

اکامي
9783
11887
19888
2,352
11,550
98.980
424
91
1408
381
50

د سلنې له مخې توزیع (په ms کې):

سلنه
اکامي
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

پایله دا ده: د اکامي اختیار د اعتبار وړ دی، مګر ورته ثبات او سرعت نه وړاندې کوي لکه څنګه چې زموږ خپل حل د علي CDN سره یوځای شوی.

کوچني یادښتونه

ځینې ​​شېبې په کیسه کې نه وې شاملې، خو غواړم چې په اړه یې هم ولیکم.

بیجینګ + توکیو او هانګ کانګ

لکه څنګه چې ما پورته وویل، موږ هانګ کانګ (HK) ته د IPSEC تونل ازموینه وکړه. مګر موږ د CEN څخه HK ته هم ازموینه وکړه. دا یو څه لږ لګښت لري، او زه حیران وم چې دا به څنګه د ~ 100 کیلومتره واټن سره د ښارونو ترمنځ کار وکړي. دا په زړه پورې شوه چې د دې ښارونو ترمینځ ځنډ زموږ د اصلي نسخې (تایوان ته) په پرتله 100ms لوړ دی. سرعت، ثبات د تایوان لپاره هم ښه و. د پایلې په توګه، موږ HK د بیک اپ IPSEC سیمې په توګه پریښود.

سربیره پردې، موږ هڅه وکړه چې لاندې نصب نصب کړو:

  • په بیجینګ کې د پیرودونکو ختمول،
  • IPSEC او CEN ټوکیو ته،
  • په علي CDN کې په بیجینګ کې سرور د اصلي په توګه ښودل شوی.

دا سکیم دومره باثباته نه و، که څه هم د سرعت له مخې دا عموما زموږ د حل څخه ټیټ نه و. د تونل په اړه، ما حتی د CEN لپاره وقفې څاڅکي لیدلي، کوم چې باید باثباته وي. له همدې امله، موږ زاړه سکیم ته راستانه شو او دا مرحله یې ړنګه کړه.

لاندې د مختلف چینلونو لپاره د مختلف سیمو ترمینځ د ځنډ په اړه احصایې دي. شاید یو څوک په دې کې دلچسپي ولري.

IPsec
علي cn-beijing <—> GCP آسیا-شمال ختیځ1 - 193ms
علي cn-شینزین <—> GCP آسیا-ختیځ 2 - 91ms
علي cn-شینزین <—> GCP us-east4 — 200ms

CEN
علي cn-beijing <—> Ali ap-northeast-1 — 54ms (!)
علي cn-شینزین <—> علي cn-هانګ کانګ - 6ms (!)
علي cn-شینزین <—> Ali us-east1 — 216ms

په چین کې د انټرنیټ په اړه عمومي معلومات

د انټرنیټ سره د ستونزو سربیره په پیل کې تشریح شوي، د مقالې په لومړۍ برخه کې.

  • په چین کې انټرنیټ خورا ګړندی دی.
    • پایله په مختلفو ځایونو کې د عامه وای فای شبکې د ازموینې پراساس رامینځته شوې چیرې چې دا شبکې د لوی شمیر خلکو لخوا کارول کیږي.
    • په چین کې دننه سرورونو ته د ډاونلوډ او اپلوډ سرعت په ترتیب سره شاوخوا 20 Mbit/s او 5-10 Mbit/s وو.
    • د چین څخه بهر د سرورونو سرعت په ساده ډول لږ دی، د 1 Mbit/s څخه کم.
  • په چین کې انټرنیټ ډیر باثباته نه دی.
    • ځینې ​​​​وختونه سایټونه په چټکۍ سره پرانیستل کیدی شي، ځینې وختونه ورو ورو (د ورځې په ورته وخت کې په مختلفو ورځو کې)، په دې شرط چې ترتیب بدل نشي. موږ دا د semrushchina.cn مثال سره ولیدل. دا د علي CDN ته منسوب کیدی شي، کوم چې دا ډول کار کوي او دا د ورځې وخت، د ستورو موقعیت، او نور پورې اړه لري.
  • ګرځنده انټرنیټ تقریبا هر ځای 4G یا 4G+ دی. دا په فرعي سړک کې ونیسئ، لفټونه - په لنډه توګه، هرچیرې.
  • دا یوه افسانه ده چې چینایي کاروونکي یوازې په .cn زون کې په ډومینونو باور لري. موږ دا په مستقیم ډول د کاروونکو څخه زده کړل.
    • تاسو کولی شئ وګورئ چې څنګه http://baidu.cn www.baidu.com ته واستوئ (په چین کې هم.
  • ډیری سرچینې واقعیا بندې دي. لومړی: google.com، فیسبوک، ټویټر. مګر د ګوګل ډیری سرچینې کار کوي (البته ، په ټولو Wi-Fi کې نه او VPN نه کارول کیږي (د روټر اړخ کې هم ، دا د ډاډ لپاره دی).
  • د بند شوي شرکتونو ډیری "تخنیکي" ډومینونه هم کار کوي. دا پدې مانا ده چې تاسو باید تل په بې پروایۍ سره ټولې ګوګل او نورې ښکاري بلاک شوي سرچینې پرې نه کړئ. تاسو اړتیا لرئ چې د منع شوي ډومینونو ځینې لیست وګورئ.
  • دوی یوازې درې اصلي انټرنیټ چلونکي لري: China Unicom، China Telecom، China Mobile. حتی کوچني هم شتون لري، مګر د دوی د بازار ونډه لږه ده

بونس: وروستی حل ډیاګرام

څنګه موږ د لوی چینایي فایروال له لارې مات شو (3 ​​برخه)

نتیجه

د پروژې له پیل څخه یو کال تیر شو. موږ د دې حقیقت سره پیل وکړ چې زموږ سایټ عموما د چین څخه په نورمال ډول کار کولو څخه انکار وکړ ، او په ساده ډول GET curl 5.5 ثانیې وخت نیولی.

بیا، په لومړي حل کې د دې شاخصونو سره (Cloudflare):

پریکړه
Uptime
میډیا
75 سلنه
95 سلنه

Cloudflare
86.6
18
30
60

موږ په نهایت کې لاندې پایلو ته ورسیدو (د تیرې میاشتې احصایې):

پریکړه
Uptime
میډیا
75 سلنه
95 سلنه

علي CDN + CEN/IPsec + GLB
99.86
8.8
9.5
13.7

لکه څنګه چې تاسو لیدلی شئ، موږ لا تر اوسه د 100 up وخت ترلاسه کولو توان نه لرو، مګر موږ به د یو څه سره راشي، او بیا به موږ تاسو ته په نوې مقاله کې د پایلو په اړه ووایو :)

هغو کسانو ته درناوی چې درې برخې یې تر پایه ولوستلې. زه امید لرم چې تاسو دا ټول په زړه پوري موندلي لکه څنګه چې ما وکړل کله چې ما وکړل.

PS پخوانۍ برخې

د 1 برخه
د 2 برخه

سرچینه: www.habr.com

Add a comment