كيف اخترقنا جدار الحماية الصيني العظيم (الجزء 3)

مرحبا!
كل القصص الجيدة تنتهي. وقصتنا حول كيفية توصلنا إلى حل تمرير سريع لجدار الحماية الصيني ليس استثناءً. لذلك أسارع أن أشارككم آخر المستجدات ، الجزء الأخير حول هذا الموضوع.

في الجزء السابق ، تم إخبارنا بمقاعد الاختبار العديدة التي اخترعناها ، والنتائج التي أعطتها. واتفقنا على ما سيكون من الجيد إضافته CDN! من أجل اللزوجة في مخططنا.

سأخبرك كيف اختبرنا Alibaba Cloud CDN و Tencent Cloud CDN و Akamai ، وأين انتهى بنا المطاف. وبالطبع ، دعونا نلخص الأمر.

علي بابا كلاود CDN

نحن مستضافون على Alibaba Cloud ، ونستخدم IPSEC و CEN منهم. سيكون من المنطقي تجربة حلولهم أولاً.

لدى Alibaba Cloud نوعان من المنتجات التي يمكن أن تناسبنا: CDN и DCDN. الخيار الأول هو CDN كلاسيكي لنطاق معين (نطاق فرعي). يتم فك تشفير الخيار الثاني كـ المسار الديناميكي لـ CDN (أسميها CDN الديناميكي) ، يمكن تمكينها في وضع الموقع الكامل (لمجالات أحرف البدل) ، كما أنها تقوم بتخزين الإحصائيات مؤقتًا وتسريع المحتوى الديناميكي على نفسها ، أي أنه سيتم أيضًا تحميل ديناميكيات الصفحة من خلال شبكات المزود السريعة. هذا مهم بالنسبة لنا ، لأن موقعنا ديناميكي بشكل أساسي ، ويستخدم العديد من المجالات الفرعية ، ومن الملائم إعداد CDN مرة واحدة لـ "العلامة النجمية" - * .semrushchina.cn.

لقد رأينا هذا المنتج بالفعل في المراحل الأولى من مشروعنا الصيني ، ولكن بعد ذلك لم يعمل بعد ، ووعد المطورون بأن المنتج على وشك أن يصبح متاحًا لجميع العملاء. وصار.

في DCDN يمكنك:

• تكوين إنهاء SSL مع شهادتك ،
• تمكين تسريع المحتوى الديناميكي ،
• تكوين التخزين المؤقت للملفات الثابتة بمرونة ،
• تطهير ذاكرة التخزين المؤقت ،
• مآخذ الويب إلى الأمام ،
• تمكين الضغط وحتى HTML Beautifier.

بشكل عام ، كل شيء يشبه البالغين ومقدمي CDN الكبار.

بعد تحديد الأصل (المكان الذي ستذهب إليه خوادم حافة CDN) ، يبقى إنشاء CNAME للعلامة النجمية ، بالإشارة إلى all.semrushchina.cn.w.kunluncan.com (تم استلام CNAME هذا في وحدة تحكم Alibaba Cloud) ، وسيعمل CDN.

وفقًا لنتائج الاختبار ، ساعدتنا شبكة CDN كثيرًا. يتم عرض الإحصائيات أدناه.

حل
الجهوزية
متوسط
75 بالمائة
95 بالمائة

كلودفلاري
86.6
18s
30s
60s

أمن بروتوكول الإنترنت
99.79
18s
21s
30s

س.
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 على تطوير السحابة الخاصة بها فقط - ويمكن ملاحظة ذلك في عدد قليل من المنتجات. أثناء استخدامه ، أردنا اختبار ليس فقط CDN الخاص بهم ، ولكن البنية التحتية للشبكة بالكامل:

• هل لديهم شيء مشابه لـ CEN؟
• كيف يعمل IPSEC معهم؟ هل هو سريع ، ما هو الجهوزية؟
• هل لديهم Anycast؟

دعونا نفحص هذه الأسئلة بشكل منفصل.

التناظرية CEN

تينسنت لديها منتج شبكة الاتصال السحابي (CCN) ، مما يتيح لك ربط VPCs من مناطق مختلفة ، بما في ذلك المناطق داخل الصين وخارجها. المنتج حاليًا في مرحلة تجريبية داخلية ، وتحتاج إلى إنشاء تذكرة مع طلب الاتصال بها. من الدعم ، علمنا أن الحسابات العالمية (لا نتحدث عن المواطنين الصينيين أو الكيانات القانونية) لا يمكنها المشاركة في برنامج الاختبار التجريبي ، وبشكل عام ، ربط المنطقة داخل الصين بالمنطقة الخارجية. 1-0 لصالح علي كلاود

IPsec

المنطقة الجنوبية في تينسنت هي قوانغتشو. قمنا بتجميع نفق وربطه بمنطقة هونغ كونغ في GCP (كانت هذه المنطقة متاحة بالفعل). كما تم رفع النفق الثاني في علي كلاود من شنتشن إلى هونج كونج في نفس الوقت. اتضح أنه من خلال شبكة Tencent ، يكون زمن الانتقال إلى هونج كونج أفضل بشكل عام (10 مللي ثانية) من زمن الانتقال من Shenzhen إلى هونج كونج إلى علي (120 مللي ثانية - ماذا؟). لكن هذا لم يسرع بأي شكل من الأشكال من عمل الموقع الذي يهدف إلى العمل من خلال Tencent وهذا النفق ، والذي كان في حد ذاته حقيقة مذهلة وأثبت مرة أخرى ما يلي: الكمون بالنسبة للصين ليس مؤشرًا يجب عليك الانتباه إليه حقًا عند تطوير حل لاجتياز جدار الحماية الصيني.

تسريع الإنترنت Anycast

منتج آخر يسمح لك بالعمل من خلال anycast IP - AIA. ولكنه أيضًا غير متاح للحسابات العالمية ، لذلك لن أتحدث عنه ، ولكن قد يكون من المفيد معرفة وجود مثل هذا المنتج.

لكن اختبار CDN أظهر نتائج مثيرة للاهتمام. لا يمكن تمكين CDN الخاص بـ Tencent على موقع كامل ، فقط في مجالات محددة. قمنا بإعداد المجالات وأرسلنا حركة المرور إليها:

اتضح أن CDN هذا لديه الوظيفة التالية: تحسين حركة المرور عبر الحدود. يجب أن تقلل هذه الميزة التكاليف عندما تمر حركة المرور عبر جدار الحماية الصيني. مثل المنشأ تم تحديد عنوان IP الخاص بـ Google GLB (GLB anycast). وبالتالي ، أردنا تبسيط بنية المشروع.

كانت النتائج جيدة جدًا - على مستوى Ali Cloud CDN ، وفي بعض الأماكن أفضل. هذا مفاجئ ، لأنه إذا نجحت الاختبارات ، يمكنك التخلي عن جزء كبير من البنية التحتية والأنفاق و CEN والأجهزة الافتراضية ، إلخ.

لم نفرح لفترة طويلة ، حيث تم الكشف عن مشكلة: كانت الاختبارات في Catchpoint فشلت بالنسبة لمزود الإنترنت China Mobile. لقد تلقينا مهلة من أي مكان عبر شبكة توصيل المحتوى الخاصة بـ Tencent. لم تؤد المراسلات مع الدعم الفني إلى أي شيء. حاولنا لمدة يوم تقريبًا حل هذه المشكلة ، لكن لم يحدث شيء.

كنت في الصين في ذلك الوقت ، لكنني لم أتمكن من العثور على شبكة Wi-Fi عامة على شبكة هذا المزود لأرى بنفسي. خلاف ذلك ، بدا كل شيء سريعًا وجيدًا.
ومع ذلك ، نظرًا لحقيقة أن China Mobile هي واحدة من أكبر ثلاث مشغلين ، فقد اضطررنا إلى إعادة حركة المرور إلى Ali CDN.
ولكن بشكل عام كان حلاً مثيرًا للاهتمام يستحق المزيد من الاختبارات واستكشاف هذه المشكلة وإصلاحها.

أكامي

آخر مزود CDN اختبرناه هو أكامي. هذا مزود ضخم له شبكته الخاصة في الصين. بالطبع ، لم نتمكن من تجاوزها.

منذ البداية ، اتفقنا مع Akamai على فترة تجريبية حتى نتمكن من تبديل النطاق ومعرفة كيفية عمله على شبكتهم. سأصف نتيجة جميع الاختبارات في شكل "ما أعجبني" و "ما لم يعجبني" ، وسأقدم أيضًا نتائج الاختبار.

ما اعجبنا:

• كان الرجال من Akamai متعاونين للغاية في جميع الأمور ورافقونا في جميع مراحل الاختبار. يحاولون باستمرار تحسين شيء ما من جانبهم. لقد قدموا نصيحة فنية جيدة.
• Akamai أبطأ بحوالي 10-15٪ من الحل الذي نقدمه عبر Ali Cloud CDN. من المثير للإعجاب أننا في Origin for Akamai حددنا عنوان GLB IP ، أي أن حركة المرور لم تمر عبر حلنا (من الممكن التخلي عن جزء من البنية التحتية). ولكن مع ذلك ، أظهرت نتائج الاختبار أن هذا الحل أسوأ من نسختنا الحالية (النتائج المقارنة أدناه).
• تم اختباره من قبل Origin GLB و Origin في الصين. كلا الخيارين متماثلان تقريبًا.
• هنالك طريق أكيد (تحسين التوجيه التلقائي). يمكنك استضافة كائن اختبار على Origin ، وستحاول خوادم Edge في Akamai التقاطه (GET العادي). بالنسبة لهذه الطلبات ، يتم قياس السرعة والمقاييس الأخرى ، والتي على أساسها تعمل شبكة Akamai على تحسين المسارات بحيث تكون حركة المرور أسرع لموقعنا ، وكان من الواضح أن تضمين هذه الميزة كان له تأثير كبير على سرعة الموقع .
• يعد تعيين الإصدار للتكوين في واجهة الويب أمرًا رائعًا. من الممكن عمل مقارنة للإصدارات ، لإلقاء نظرة على فرق. عرض الإصدارات السابقة.
• يمكنك طرح إصدار جديد أولاً فقط على شبكة Akamai Staging - نفس شبكة الإنتاج ، بهذه الطريقة فقط لن تؤثر على المستخدمين الحقيقيين. لإجراء هذا الاختبار ، تحتاج إلى انتحال سجلات 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

اختبار 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

لاحظنا أن الموقف من المثال أعلاه يعتمد على عوامل مختلفة. في وقت كتابة هذا التقرير ، أجريت الاختبار مرة أخرى. كانت نتائج كلا النظامين متشابهة. يخبرنا هذا أن الإنترنت في الصين ، حتى بالنسبة لكبار المشغلين ومقدمي الخدمات السحابية ، يتصرف بشكل مختلف من وقت لآخر.

سأضيف إضافة Akamai الكبيرة إلى النقطة السابقة: إذا أظهر علي ومضات مماثلة من الأداء العالي ومنخفضة جدًا (ينطبق هذا على Ali CDN و Ali CEN و Ali IPSEC) ، فعندئذٍ Akamai في كل مرة ، بغض النظر عن كيفية اختبار شبكتهم ، كل شيء يعمل بثبات.
تتمتع Akamai بتغطية رائعة في الصين وتعمل من خلال العديد من مقدمي الخدمات.

ما لم يعجبه:

• لا تعجبني واجهة الويب ونظام العمل - فهما صفران للغاية. لكن من حيث المبدأ تعتاد على ذلك (على الأرجح).
• نتائج الاختبار أسوأ من موقعنا.
• توجد أخطاء أثناء الاختبارات أكثر من تلك الموجودة على موقعنا (وقت التشغيل أدناه).
• لا توجد خوادم DNS في الصين. ومن ثم هناك الكثير من الأخطاء في الاختبارات بسبب انتهاء مهلة حل DNS.
• إنهم لا يوفرون نطاقات IP الخاصة بهم -> لا توجد طريقة لتسجيل النطاقات الصحيحة set_real_ip_from على خوادمنا.

المقاييس (حوالي 3626 عملية تشغيل ؛ جميع المقاييس ، باستثناء وقت التشغيل ، بالمللي ثانية ؛ إحصاءات لفترة واحدة من الوقت):

مزود CDN
متوسط
75%
95%
استجابة
استجابة صفحة الويب
الجهوزية
DNS
التواصل

حمل
SSL

علي CDN
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

التوزيع حسب النسبة المئوية (بالمللي ثانية):

المئوي
أكامي
علي CDN

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 مللي ثانية أعلى من نسختنا الأصلية (لتايوان). كانت السرعة والاستقرار أيضًا أفضل لتايوان. نتيجة لذلك ، تركنا هونج كونج كمنطقة IPSEC احتياطية.

بالإضافة إلى ذلك ، حاولنا رفع مثل هذا التثبيت:

• إنهاء العملاء في بكين ،
• IPSEC و CEN إلى طوكيو ،
• في Ali CDN ، تمت الإشارة إلى الخادم في بكين على أنه الأصل.

لم يكن هذا المخطط مستقرًا ، على الرغم من أنه بشكل عام لم يكن أدنى من حلنا من حيث السرعة. أما بالنسبة للنفق ، فقد رأيت قطرات متقطعة حتى بالنسبة لـ CEN ، والتي كان ينبغي أن تكون مستقرة. لذلك عدنا إلى المخطط القديم وفككنا هذا التدريج.

فيما يلي إحصائيات عن زمن الانتقال بين المناطق المختلفة عبر قنوات مختلفة. ربما شخص ما سوف يهتم بها

أمن بروتوكول الإنترنت
Ali cn-beijing <—> GCP asia-north1 - 193ms
علي cn-sh Shenzhen <—> GCP asia-east2 - 91 مللي ثانية
علي CN- شنتشن <—> GCP us-east4 - 200 مللي ثانية

س.
Ali cn-beijing <—> Ali ap-north-1 - 54ms (!)
علي CN- شنتشن <—> علي cn-hongkong - 6 مللي ثانية (!)
علي cn-Shenzhen <—> علي 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 في نفس الوقت (على جانب جهاز التوجيه ، هذا أمر مؤكد أيضًا).
• تعمل أيضًا العديد من المجالات "التقنية" للشركات المحظورة. هذا يعني أنه لا يجب عليك دائمًا قطع جميع موارد Google وغيرها من الموارد التي تبدو محظورة بشكل متهور. تحتاج إلى البحث عن بعض قائمة المجالات المحظورة.
• لديهم ثلاثة مشغلي إنترنت رئيسيين فقط: تشاينا يونيكوم ، تشاينا تيليكوم ، تشاينا موبايل. حتى أن هناك شركات أصغر ، لكن حصتها في السوق ضئيلة

المكافأة: مخطط الحل النهائي

مجموع

لقد مر عام على بدء المشروع. لقد بدأنا بحقيقة أن موقعنا رفض بشكل عام العمل بشكل طبيعي من الصين ، ولكن ببساطة استغرق GET curl 5.5 ثانية.

ثم من هذه المؤشرات في القرار الأول (Cloudflare):

حل
الجهوزية
متوسط
75 بالمائة
95 بالمائة

كلودفلاري
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