چگونه از فایروال بزرگ چینی شکستیم (قسمت 3)

سلام!
تمام داستان های خوب به پایان می رسد. و داستان ما در مورد چگونگی یافتن راه حلی برای عبور سریع فایروال چینی از این قاعده مستثنی نیست. بنابراین، من عجله دارم آخرین مورد را با شما به اشتراک بگذارم، قسمت پایانی در این مورد.

در قسمت قبل در مورد نیمکت های آزمایشی زیادی صحبت کردیم که به آنها رسیدیم و اینکه آنها چه نتایجی دادند. و ما در مورد چیزهایی که می‌توانیم اضافه کنیم، تصمیم گرفتیم CDN! برای ویسکوزیته در طرح ما.

من به شما خواهم گفت که چگونه Alibaba Cloud CDN، Tencent Cloud CDN و Akamai را آزمایش کردیم و در نهایت به چه چیزی رسیدیم. و البته بیایید خلاصه کنیم.

Alibaba Cloud CDN

ما در Alibaba Cloud میزبانی می کنیم و از IPSEC و CEN آنها استفاده می کنیم. منطقی است که ابتدا راه حل های آنها را امتحان کنید.

Alibaba Cloud دو نوع محصول دارد که ممکن است مناسب ما باشد: CDN и DCDN. اولین گزینه یک CDN کلاسیک برای یک دامنه خاص (زیر دامنه) است. گزینه دوم مخفف مسیر پویا برای CDN (من آن را CDN پویا می نامم)، می توان آن را در حالت Full-site فعال کرد (برای دامنه های wildcard)، همچنین محتوای استاتیک را ذخیره می کند و محتوای پویا را روی خود تسریع می کند، یعنی پویایی صفحه نیز از طریق ارائه دهنده بارگذاری می شود. شبکه های سریع این برای ما مهم است، زیرا اساساً سایت ما پویا است، از زیر دامنه های زیادی استفاده می کند، و راحت تر است که یک بار CDN برای "ستاره" - *.semrushchina.cn راه اندازی کنیم.

ما قبلاً این محصول را در مراحل اولیه پروژه چینی خود دیده بودیم، اما پس از آن هنوز کار نمی کرد و توسعه دهندگان قول دادند که این محصول به زودی در دسترس همه مشتریان قرار خواهد گرفت. و او انجام داد.

در DCDN می توانید:

• خاتمه SSL را با گواهی خود پیکربندی کنید،
• فعال کردن سرعت بخشیدن به محتوای پویا،
• پیکربندی انعطاف پذیر ذخیره سازی فایل های استاتیک،
• کش را پاک کنید،
• سوکت های وب فوروارد،
• فشرده سازی و حتی HTML Beautifier را فعال کنید.

به طور کلی، همه چیز مانند بزرگسالان و ارائه دهندگان CDN بزرگ است.

پس از مشخص شدن Origin (محلی که سرورهای لبه CDN در آنجا خواهند رفت)، تنها چیزی که باقی می ماند ایجاد یک CNAME برای ستاره است، با ارجاع به all.semrushchina.cn.w.kunluncan.com (این CNAME در کنسول ابری علی بابا دریافت شده است) و CDN کار خواهد کرد.

بر اساس نتایج آزمایش، این CDN کمک زیادی به ما کرد. آمار در زیر نشان داده شده است.

تصمیم
آپ تایم
متوسط
75 درصد
95 درصد

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

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

اینها نتایج بسیار خوبی هستند، به خصوص اگر آنها را با اعدادی که در ابتدا بودند مقایسه کنید. اما می دانستیم که تست مرورگر نسخه آمریکایی وب سایت ما www.semrush.com از ایالات متحده آمریکا به طور متوسط ​​8.3 ثانیه (مقدار بسیار تقریبی) اجرا می شود. امکان پیشرفت وجود دارد. علاوه بر این، ارائه دهندگان CDN نیز وجود داشتند که آزمایش آنها جالب بود.

بنابراین ما به آرامی به سمت غول دیگری در بازار چین حرکت می کنیم - Tencent به.

ابر Tencent

Tencent به تازگی در حال توسعه ابر خود است - این را می توان از تعداد کمی از محصولات مشاهده کرد. در حین استفاده از آن، ما می‌خواستیم نه تنها CDN، بلکه زیرساخت شبکه آنها را نیز به طور کلی آزمایش کنیم:

• آیا آنها چیزی شبیه به CEN دارند؟
• چگونه IPSEC برای آنها کار می کند؟ آیا سریع است، زمان کار چقدر است؟
• آیا آنها Anycast دارند؟

بیایید این سوالات را جداگانه بررسی کنیم.

آنالوگ CEN

Tencent یک محصول دارد Cloud Connect Network (CCN)، به شما امکان می دهد VPC ها را از مناطق مختلف، از جمله مناطق داخل و خارج از چین متصل کنید. این محصول اکنون در نسخه بتای داخلی است و شما باید یک بلیط ایجاد کنید تا به آن متصل شوید. ما از پشتیبانی دریافتیم که حساب‌های جهانی (ما در مورد شهروندان چینی یا اشخاص حقوقی صحبت نمی‌کنیم) نمی‌توانند در برنامه آزمایش بتا شرکت کنند و به طور کلی، یک منطقه در داخل چین را با یک منطقه خارج از آن متصل کنند. 1-0 به سود علی کلود

IPsec

جنوبی ترین منطقه Tencent است گوانگژو. ما یک تونل را مونتاژ کردیم و آن را به منطقه هنگ کنگ در GCP متصل کردیم (در آن زمان این منطقه قبلاً در دسترس بود). تونل دوم در علی ابر از شنژن به هنگ کنگ نیز در همان زمان ساخته شد. مشخص شد که از طریق شبکه Tencent، تاخیر به هنگ کنگ به طور کلی بهتر است (10 میلی ثانیه) تا از شنژن به هنگ کنگ تا علی (120 میلی ثانیه - چه؟). اما این به هیچ وجه باعث سرعت بخشیدن به کار سایت با هدف کار از طریق Tencent و این تونل نشد که به خودی خود یک واقعیت شگفت انگیز بود و یک بار دیگر موارد زیر را ثابت کرد: تأخیر - برای چین این شاخصی نیست که واقعاً ارزش داشته باشد. توجه به هنگام توسعه راه حلی برای عبور از فایروال چینی.

شتاب اینترنت Anycast

محصول دیگری که به شما امکان می دهد از طریق آی پی anycast کار کنید AIA. اما برای حساب های جهانی نیز در دسترس نیست، بنابراین در مورد آن به شما نمی گویم، اما دانستن وجود چنین محصولی ممکن است مفید باشد.

اما تست CDN نتایج بسیار جالبی را نشان داد. CDN Tencent را نمی توان در یک سایت کامل، فقط در دامنه های خاص فعال کرد. ما دامنه ایجاد کردیم و ترافیک را برای آنها ارسال کردیم:

معلوم شد که این CDN عملکرد زیر را دارد: بهینه سازی ترافیک فرامرزی. این ویژگی باید هزینه ها را در هنگام عبور ترافیک از فایروال چینی کاهش دهد. مانند منشاء آدرس IP Google GLB (GLB anycast) مشخص شد. بنابراین، ما می خواستیم معماری پروژه را ساده کنیم.

نتایج بسیار خوب بود - در سطح Ali Cloud CDN، و در برخی جاها حتی بهتر. این تعجب آور است، زیرا در صورت موفقیت آمیز بودن آزمایش ها، می توانید بخش قابل توجهی از زیرساخت ها، تونل ها، CEN، ماشین های مجازی و غیره را رها کنید.

ما برای مدت طولانی خوشحال نشدیم، زیرا یک مشکل آشکار شد: آزمایشات در Catchpoint برای ارائه دهنده اینترنت China Mobile شکست خورد. از هر مکانی که از طریق CDN Tencent یک مهلت دریافت کردیم. مکاتبه با پشتیبانی فنی به چیزی منجر نشد. ما حدود یک روز سعی کردیم این مشکل را حل کنیم، اما هیچ کاری نشد.

من در آن لحظه در چین بودم، اما نتوانستم Wi-Fi عمومی را در شبکه این ارائه دهنده پیدا کنم تا شخصاً مشکل را تأیید کنم. در غیر این صورت همه چیز سریع و خوب به نظر می رسید.
اما با توجه به اینکه چاینا موبایل یکی از سه اپراتور بزرگ است، مجبور شدیم ترافیک را به علی CDN برگردانیم.
اما به طور کلی، این یک راه حل نسبتا جالب بود که مستحق آزمایش و عیب یابی طولانی تر این مشکل است.

مستقیم Akamai

آخرین ارائه دهنده CDN که ما آزمایش کردیم، بود مستقیم Akamai. این یک ارائه دهنده بزرگ است که شبکه خود را در چین دارد. البته نتونستیم ازش بگذریم.

از همان ابتدا با Akamai برای یک دوره آزمایشی به توافق رسیدیم تا بتوانیم دامنه را تغییر دهیم و ببینیم که چگونه در شبکه آنها کار می کند. من نتیجه همه آزمایشات را به صورت "آنچه دوست داشتم" و "آنچه دوست نداشتم" را شرح خواهم داد و همچنین نتایج آزمایش را ارائه خواهم داد.

چیزی که دوست داشتیم:

• بچه های Akamai در تمام سوالات بسیار کمک کننده بودند و ما را در تمام مراحل تست همراهی کردند. ما دائماً در تلاش بودیم تا چیزی را در سمت خود بهبود دهیم. توصیه های فنی خوبی کردند.
• Akamai حدود 10-15٪ کندتر از راه حل ما از طریق Ali Cloud CDN است. آنچه قابل توجه است این است که در Origin برای Akamai ما آدرس IP GLB را مشخص کردیم، به این معنی که ترافیک از طریق راه حل ما عبور نمی کند (به طور بالقوه می توانیم بخشی از زیرساخت را رها کنیم). اما با این حال، نتایج آزمایش نشان داد که این راه حل بدتر از نسخه فعلی ما است (نتایج مقایسه ای در زیر).
• Origin GLB و Origin در چین تست شده است. هر دو گزینه تقریباً یکسان هستند.
• وجود دارد مسیر مطمئن (بهینه سازی مسیریابی خودکار). شما می توانید یک شی آزمایشی را در Origin میزبانی کنید، و سرورهای Akamai Edge سعی می کنند آن را انتخاب کنند (GET معمولی). برای این درخواست ها سرعت و سایر معیارها سنجیده می شود که بر اساس آن شبکه Akamai مسیرها را بهینه می کند تا ترافیک برای سایت ما سریعتر پیش برود و مشخص بود که فعال کردن این ویژگی واقعاً تأثیر زیادی روی سرعت سایت دارد.
• نسخه بندی پیکربندی در رابط وب جالب است. می توانید برای نسخه ها مقایسه کنید، به تفاوت نگاه کنید. مشاهده نسخه های قبلی
• شما می توانید یک نسخه جدید را ابتدا فقط در شبکه Akamai Staging منتشر کنید - همان شبکه تولید، فقط از این طریق بر کاربران واقعی تأثیر نمی گذارد. برای این آزمایش، باید سوابق DNS را در دستگاه محلی خود جعل کنید.
• سرعت دانلود بسیار سریع از طریق شبکه آنها برای فایل های استاتیک بزرگ و ظاهراً هر فایل دیگری. یک فایل از کش "سرد" چندین برابر سریعتر از همان فایل از کش "سرد" Ali 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

ما متوجه شدیم که وضعیت در مثال بالا به عوامل مختلفی بستگی دارد. در زمان نوشتن این نکته، دوباره آزمون را انجام دادم. نتایج برای هر دو سیستم عامل تقریباً یکسان بود. این به ما می گوید که اینترنت در چین، حتی برای اپراتورهای بزرگ و ارائه دهندگان ابری، هر از چند گاهی متفاوت رفتار می کند.

به نکته قبلی، یک نکته مثبت بزرگ برای Akamai اضافه می کنم: اگر علی فلاش های مشابه با عملکرد بالا و عملکرد بسیار پایین را نشان می دهد (این برای Ali CDN، Ali CEN و Ali IPSEC صدق می کند)، پس Akamai، هر بار، مهم نیست. چگونه شبکه آنها را آزمایش می کنم، همه چیز به طور پایدار کار می کند.
Akamai در چین پوشش زیادی دارد و از طریق بسیاری از ارائه دهندگان کار می کند.

چیزی که دوست نداشت:

• رابط وب و نحوه کار آن را دوست ندارم - خیلی ضعیف است. اما اساساً به آن عادت می کنید (احتمالا).
• نتایج تست از سایت ما بدتر است.
• خطاها در طول آزمایشات بیشتر از سایت ما وجود دارد (تایم آپدیت در زیر).
• ما سرورهای DNS خود را در چین نداریم. از این رو خطاهای زیادی در تست ها به دلیل وقفه زمانی رفع DNS وجود دارد.
• آنها محدوده IP خود را ارائه نمی دهند -> هیچ راهی برای ثبت موارد صحیح وجود ندارد set_real_ip_from در سرورهای ما

معیارها (~3626 اجرا؛ همه معیارها به جز زمان آپلود، در میلی ثانیه؛ آمار برای یک دوره زمانی):

ارائه دهنده CDN
متوسط
٪۱۰۰
٪۱۰۰
واکنش
پاسخ صفحه وب
آپ تایم
DNS
اتصال
صبر کنيد
بار
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

توزیع بر اساس درصد (بر حسب میلی‌ثانیه):

درصد
مستقیم 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

نتیجه این است: گزینه Akamai قابل دوام است، اما ثبات و سرعت مشابه راه حل خودمان همراه با Ali CDN را ارائه نمی دهد.

یادداشت های کوچک

برخی از لحظات در داستان گنجانده نشده بود، اما دوست دارم درباره آنها هم بنویسم.

پکن + توکیو و هنگ کنگ

همانطور که در بالا گفتم، ما یک تونل IPSEC را به هنگ کنگ (هنگ کنگ) آزمایش کردیم. اما ما CEN را به HK نیز آزمایش کردیم. هزینه آن کمی کمتر است و من فکر می کردم که چگونه بین شهرهایی با فاصله 100 کیلومتر کار می کند. جالب بود که تاخیر بین این شهرها 100 میلی ثانیه بیشتر از نسخه اصلی ما (به تایوان) است. سرعت، ثبات نیز برای تایوان بهتر بود. در نتیجه، HK را به عنوان یک منطقه پشتیبان IPSEC ترک کردیم.

علاوه بر این، ما سعی کردیم نصب زیر را نصب کنیم:

• خاتمه دادن به مشتریان در پکن،
• IPSEC و CEN به توکیو،
• در Ali CDN سرور در پکن به عنوان مبدا نشان داده شده است.

این طرح چندان پایدار نبود، اگرچه از نظر سرعت به طور کلی کمتر از راه حل ما نبود. در مورد تونل، من حتی برای CEN که باید پایدار می بود، افت متناوب دیده ام. بنابراین ما به طرح قبلی برگشتیم و این صحنه سازی را برچیدیم.

در زیر آمار تاخیر بین مناطق مختلف برای کانال های مختلف آورده شده است. شاید کسی به آن علاقه مند شود.

IPsec
علی cn-peijing <—> GCP asia-northeast1 — 193ms
Ali cn-shenzhen <—> GCP asia-east2 — 91ms
Ali cn-shenzhen <—> GCP us-east4 — 200ms

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

اطلاعات کلی در مورد اینترنت در چین

علاوه بر مشکلات اینترنت که در همان ابتدا در قسمت اول مقاله توضیح داده شد.

• اینترنت در چین در داخل بسیار سریع است.
  • نتیجه گیری بر اساس آزمایش شبکه های Wi-Fi عمومی در مکان های مختلف که این شبکه ها توسط تعداد زیادی از مردم استفاده می شود، انجام شد.
  • سرعت دانلود و آپلود به سرورهای داخل چین به ترتیب حدود 20 مگابیت بر ثانیه و 5 تا 10 مگابیت بر ثانیه بود.
  • سرعت سرورهای خارج از چین به سادگی ناچیز است، کمتر از 1 مگابیت بر ثانیه.
• اینترنت در چین چندان پایدار نیست.
  • گاهی اوقات سایت ها می توانند به سرعت باز شوند، گاهی اوقات به آرامی (در همان ساعت از روز در روزهای مختلف)، به شرطی که پیکربندی تغییر نکند. این را با مثال semrushchina.cn مشاهده کردیم. این را می توان به Ali CDN نسبت داد که بسته به زمان روز، موقعیت ستارگان و غیره نیز به این صورت و آن طرف کار می کند.
• اینترنت موبایل تقریباً در همه جا 4G یا 4G+ است. آن را در مترو، آسانسور بگیرید - خلاصه، همه جا.
• این یک افسانه است که کاربران چینی فقط به دامنه های موجود در منطقه cn. اعتماد دارند. ما این را مستقیماً از کاربران یاد گرفتیم.
  • می توانید ببینید که چگونه http://baidu.cn به www.baidu.com تغییر مسیر دهید (در سرزمین اصلی چین نیز).
• بسیاری از منابع در واقع مسدود شده اند. اولیه: google.com، فیس بوک، توییتر. اما بسیاری از منابع Google کار می کنند (البته در همه Wi-Fi و VPN استفاده نمی شود (در سمت روتر نیز مطمئناً).
• بسیاری از دامنه های "فنی" شرکت های مسدود شده نیز در حال کار هستند. این بدان معناست که شما نباید همیشه بی‌احتیاطی تمام گوگل و سایر منابع به ظاهر مسدود شده را قطع کنید. شما باید به دنبال لیستی از دامنه های ممنوعه باشید.
• آنها فقط سه اپراتور اصلی اینترنت دارند: China Unicom، China Telecom، China Mobile. حتی کوچکترها نیز وجود دارند، اما سهم آنها در بازار ناچیز است

امتیاز: نمودار راه حل نهایی

مجموع

یک سال از شروع پروژه می گذرد. ما با این واقعیت شروع کردیم که سایت ما به طور کلی از کار معمولی از چین خودداری کرد و به سادگی GET curl 5.5 ثانیه طول کشید.

سپس با این شاخص ها در راه حل اول (Cloudflare):

تصمیم
آپ تایم
متوسط
75 درصد
95 درصد

CloudFlare را
86.6
18s
30s
60s

در نهایت به نتایج زیر رسیدیم (آمار ماه گذشته):

تصمیم
آپ تایم
متوسط
75 درصد
95 درصد

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

همانطور که می بینید، ما هنوز نتوانسته ایم به 100٪ آپتایم برسیم، اما به چیزی خواهیم رسید و سپس در یک مقاله جدید در مورد نتایج به شما خواهیم گفت :)

با احترام به کسانی که هر سه قسمت را تا آخر مطالعه کردند. امیدوارم همه اینها به همان اندازه جالب بوده باشید که من در زمان انجام آن انجام دادم.

PS قسمت های قبلی

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

منبع: www.habr.com