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

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

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

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

بابا سحابة CDN

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

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

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

في DCDN ، يمكنك:

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

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

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

وفقا لنتائج الاختبار ، ساعدنا هذا CDN كثيرا. وترد الإحصاءات أدناه.

هذه نتائج جيدة جدًا ، خاصةً إذا ما قارناها بالأرقام التي كانت في البداية. لكننا علمنا أن اختبار المتصفح للنسخة الأمريكية لموقعنا www.semrush.com كان يعمل من الولايات المتحدة الأمريكية بمعدل 8.3 ثانية (قيمة تقريبية جدًا). هناك الكثير لنسعى جاهدين من أجله. علاوة على ذلك ، كان هناك مزودي CDN الذين كانوا مهتمين في الاختبار.

لذلك نحن ننتقل بسلاسة إلى عملاق آخر في السوق الصينية - تينسنت .

سحابة تينسنت

تقوم شركة Tencent بتطوير السحابة الخاصة بها فقط - وهذا واضح في عدد صغير من المنتجات. أثناء استخدامه ، أردنا اختبار ليس فقط CDN ، ولكن أيضًا البنية التحتية للشبكة ككل:

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

سنقوم بتحليل هذه الأسئلة بشكل منفصل.

النظير CEN

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

IPSEC

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

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

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

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

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

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

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

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

أكامي

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

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

ما الذي أعجبك:

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

ما لم يعجبه:

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

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

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

الاستنتاج هو هذا: الخيار مع Akamai قابل للتطبيق ، لكنه لا يعطي نفس مؤشرات الاستقرار والسرعة التي يوفرها الحل الخاص بنا ، إلى جانب Ali CDN.

ملاحظات صغيرة

لم يتم تضمين بعض النقاط في القصة ، لكنني أود أن أكتب عنها أيضًا.

بكين + طوكيو وهونج كونج

كما قلت أعلاه ، اختبرنا نفق IPSEC إلى هونج كونج (هونج كونج). لكننا اختبرنا CEN قبل هونج كونج. تكلفتك أرخص قليلاً ، وكان من المثير للاهتمام كيف ستعمل بين المدن على بعد حوالي 100 كم. اتضح أنه من المثير للاهتمام أن زمن الانتقال بين هذه المدن أعلى بمقدار 100 مللي ثانية من نسختنا الأصلية (إلى تايوان). كانت السرعة والاستقرار أفضل لتايوان. نتيجة لذلك ، غادرنا هونج كونج كمنطقة IPSEC احتياطية.

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

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

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

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

أمن بروتوكول الإنترنت
علي cn-beijing <--> برنامج "شركاء Google المعتمدون" - شمال شرق 1 - 193 مللي ثانية
علي cn-shenzhen <--> GCP asia-east2 - 91ms
علي cn-shenzhen <--> GCP us-east4 - 200ms

CEN
علي cn- بكين <---> علي ا ف ب شمال شرق - 1 - 54ms (!)
Ali cn-shenzhen <---> Ali cn-hongkong - 6ms (!)
علي cn-shenzhen <---> علي us-east1 - 216ms

معلومات عامة عن الإنترنت في الصين

كإضافة إلى مشاكل الإنترنت الموصوفة في البداية ، في الجزء الأول من المقال.

• الانترنت في الصين سريع جدا في الداخل.
  
  • يستند الاستنتاج إلى اختبار شبكات Wi-Fi العامة في مواقع مختلفة حيث يتم استخدام هذه الشبكات من قبل عدد كبير من الأشخاص.
  • كانت سرعات التنزيل والتحميل للخوادم داخل الصين حوالي 20 ميغابت في الثانية و 5 إلى 10 ميغابت في الثانية على التوالي.
  • تعد السرعة للخوادم خارج الصين بائسة ، فهي أقل من 1 ميغابت في الثانية.
• الانترنت في الصين ليست مستقرة جدا.
  
  • في بعض الأحيان ، يمكن فتح المواقع بسرعة ، وأحيانًا ببطء (في نفس الوقت من اليوم في أيام مختلفة) ، بشرط ألا يتغير التكوين. لاحظنا هذا بمثال semrushchina.cn. يمكن أن يعزى ذلك إلى علي CDN ، الذي يعمل أيضًا بهذه الطريقة وهذا ، حسب الوقت من اليوم ، وموقع النجوم ، إلخ.
• الإنترنت عبر الهاتف النقال هو في كل مكان تقريبا 4G أو 4G +. المصيد في المترو والمصاعد - باختصار ، في كل مكان.
• حقيقة أن المستخدمين الصينيين يثقون فقط المجالات في منطقة .cn هي خرافة. لقد تعلمنا هذا مباشرة من المستخدمين.
  
  • يمكنك معرفة كيفية إعادة توجيه http://baidu.cn إلى www.baidu.com (في الصين القارية أيضًا).
• يتم حظر العديد من الموارد حقا. البدائية: google.com ، Facebook ، Twitter. لكن العديد من موارد Google تعمل (بالطبع ، لا يتم استخدام كل شبكات Wi-Fi و VPN في نفس الوقت (على جانب جهاز التوجيه أيضًا ، وهذا أمر مؤكد).
• العديد من المجالات "التقنية" للشركات المحظورة تعمل أيضًا. هذا يعني أنه لا ينبغي عليك دائمًا الاستغناء عن جميع موارد Google وغيرها من الموارد التي يبدو أنها محظورة. تحتاج إلى البحث عن قائمة بالمجالات المحظورة.
• لديهم ثلاثة مزودين رئيسيين للإنترنت فقط: تشاينا يونيكوم ، تشاينا تليكوم ، تشاينا موبايل. هناك حتى أصغر منها ، ولكن حصتها في السوق ضئيلة

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

يؤدي

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

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

نتيجة لذلك ، توصلنا إلى النتائج التالية (إحصائيات الشهر الماضي):

كما ترون ، لم تتحقق بعد نسبة الجهوزية بنسبة 100٪ ، لكننا سنتوصل إلى شيء ، ثم سنخبرك بالنتائج في مقال جديد :)

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

PS الأجزاء السابقة

الجزء 1
الجزء 2