[لا] تستخدم CDN

تحتوي كل مقالة أو أداة تقريبًا لتحسين سرعة الموقع على بند متواضع "استخدم CDN". بشكل عام، CDN هي شبكة توصيل المحتوى أو شبكة توصيل المحتوى. نحن في Method Lab غالبًا ما نواجه أسئلة من العملاء حول هذا الموضوع؛ حيث يقوم بعضهم بتمكين CDN الخاص بهم. الغرض من هذه المقالة هو فهم ما يمكن أن توفره شبكة CDN من حيث سرعة تحميل الموقع، وما هي المشكلات التي قد تنشأ، وفي الحالات التي يكون فيها استخدام CDN مبررًا.

[لا] تستخدم CDN

التأخير المحاط بدائرة في الصورة ناتج عن استخدام CDN.

القليل من التاريخ

مثل العديد من التقنيات، ظهرت شبكات CDN بدافع الضرورة. ومع تطور قنوات الإنترنت بين مستخدمي الإنترنت، ظهرت خدمات الفيديو عبر الإنترنت. بطبيعة الحال، يتطلب محتوى الفيديو نطاقًا تردديًا أكبر بكثير مقارنة بمحتوى موقع الويب العادي (الصور والنصوص ورمز CSS أو JS).

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

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

مع تطور الويب، أصبحت تطبيقات الويب نفسها أكثر تعقيدًا وتعقيدًا. ظهرت مشكلة سرعة التحميل في المقدمة. حدد المتحمسون لسرعة موقع الويب بسرعة العديد من المشكلات الرئيسية التي تسببت في تحميل مواقع الويب ببطء. أحدها كان تأخيرات الشبكة (RTT - وقت الرحلة ذهابًا وإيابًا أو وقت اختبار الاتصال). تؤثر التأخيرات على العديد من العمليات في تحميل موقع الويب: إنشاء اتصال TCP، وبدء جلسة TLS، وتحميل كل مورد فردي (صورة، ملف JS، مستند HTML، وما إلى ذلك)

تفاقمت المشكلة بسبب حقيقة أنه عند استخدام بروتوكول HTTP/1.1 (قبل ظهور SPDY وQUIC وHTTP/2 كان هذا هو الخيار الوحيد)، لا تفتح المتصفحات أكثر من 6 اتصالات TCP لمضيف واحد. كل هذا أدى إلى توقف الاتصال والاستخدام غير الفعال لعرض النطاق الترددي للقناة. تم حل المشكلة جزئيًا عن طريق تقسيم النطاق - إنشاء مضيفين إضافيين للتغلب على الحد الأقصى لعدد الاتصالات.

هذا هو المكان الذي تظهر فيه القدرة الثانية لـ CDN - تقليل زمن الوصول (RTT) بسبب العدد الكبير من النقاط وقرب العقد من المستخدم. تلعب المسافة دورًا حاسمًا هنا: فسرعة الضوء محدودة (حوالي 200 كم/ثانية في الألياف الضوئية). وهذا يعني أن كل 000 كيلومتر من السفر تضيف 1000 مللي ثانية من التأخير أو 5 مللي ثانية إلى RTT. وهذا هو الحد الأدنى من الوقت اللازم للإرسال، نظرًا لوجود تأخيرات أيضًا في المعدات الوسيطة. نظرًا لأن شبكة CDN تعرف عادةً كيفية تخزين الكائنات مؤقتًا على خوادمها، فيمكننا الاستفادة من تحميل هذه الكائنات من خلال شبكة CDN. الشروط اللازمة لذلك: وجود الكائن في ذاكرة التخزين المؤقت، وقرب نقطة CDN من المستخدم مقارنة بخادم تطبيقات الويب (الخادم الأصلي). من المهم أن نفهم أن القرب الجغرافي لعقدة CDN لا يضمن زمن انتقال منخفض. يمكن إنشاء التوجيه بين العميل وشبكة CDN بطريقة تمكن العميل من الاتصال بمضيف في بلد آخر، وربما في قارة أخرى. هذا هو المكان الذي تلعب فيه العلاقة بين مشغلي الاتصالات وخدمة CDN (التناظر، والاتصالات، والمشاركة في IX، وما إلى ذلك) وسياسة توجيه حركة المرور الخاصة بشبكة CDN نفسها. على سبيل المثال، Cloudflare، عند استخدام خطتين أوليتين (مجانية ورخيصة)، لا يضمن تسليم المحتوى من أقرب مضيف - سيتم اختيار المضيف لتحقيق الحد الأدنى من التكلفة.

تجذب العديد من شركات الإنترنت الرائدة الاهتمام العام (مطوري الويب وأصحاب الخدمات) بموضوع سرعة التحميل وأداء موقع الويب. ومن بين هذه الشركات Yahoo (أداة Yslow)، وAOL (WebPageTest)، وGoogle (خدمة Page Speed ​​Insights)، التي تعمل على تطوير توصياتها الخاصة لتسريع المواقع (تتعلق في المقام الأول بتحسين العميل). لاحقًا، تظهر أدوات جديدة لاختبار سرعة موقع الويب، والتي تقدم أيضًا نصائح حول زيادة سرعة موقع الويب. تحتوي كل من هذه الخدمات أو المكونات الإضافية على توصية متسقة: "استخدم CDN". عادةً ما يتم الاستشهاد بالانخفاض في زمن وصول الشبكة كتفسير لتأثير CDN. لسوء الحظ، ليس الجميع على استعداد لفهم كيفية تحقيق تأثير تسارع CDN بالضبط وكيف يمكن قياسه، لذلك يتم أخذ التوصية على محمل الجد واستخدامها كمسلمة. في الواقع، لم يتم إنشاء جميع شبكات CDN على قدم المساواة.

باستخدام CDN اليوم

لتقييم فائدة استخدام شبكات CDN، يجب تصنيفها. ما الذي يمكن العثور عليه الآن عمليًا (الأمثلة الموجودة بين قوسين ليست شاملة بالطبع):

  1. CDN مجاني لتوزيع مكتبات JS (MaxCDN، Google. Yandex).
  2. CDN للخدمات لتحسين العميل (على سبيل المثال، Google Fonts للخطوط، Cloudinary، Cloudimage للصور).
  3. CDN لتحسين الموارد والثبات في CMS (متوفر في Bitrix وWordPress وغيرها).
  4. CDN للأغراض العامة (StackPath، CDNVideo، NGENIX، Megafon).
  5. CDN لتسريع موقع الويب (Cloudflare، Imperva، Airi).

والفرق الرئيسي بين هذه الأنواع هو مقدار حركة المرور التي تمر عبر شبكة CDN. الأنواع 1-3 هي تسليم جزء فقط من المحتوى: من طلب واحد إلى عدة عشرات (عادةً صور). النوعان 4 و5 عبارة عن وكيل كامل لحركة المرور عبر CDN.

عمليًا، هذا يعني عدد الاتصالات المستخدمة لتحميل الموقع. باستخدام HTTP/2، نستخدم اتصال TCP واحدًا بالمضيف لمعالجة أي عدد من الطلبات. إذا قمنا بتقسيم الموارد إلى المضيف الرئيسي (الأصل) وCDN، فمن الضروري توزيع الطلبات عبر عدة مجالات وإنشاء العديد من اتصالات TCP. أسوأ الحالات هي: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. لا تأخذ هذه الصيغة في الاعتبار التأخير في شبكات الهاتف المحمول لتنشيط قناة الراديو الخاصة بالجهاز (إذا لم تكن نشطة) والتأخير في برج الخلية.

إليك ما يبدو عليه شلال التحميل بالموقع (يتم تمييز زمن الاستجابة للاتصال بشبكة CDN عند RTT 150 مللي ثانية):

[لا] تستخدم CDN

إذا كان CDN يغطي كل حركة مرور الموقع (باستثناء خدمات الطرف الثالث)، فيمكننا استخدام اتصال TCP واحد، مما يوفر التأخير في الاتصال بمضيفين إضافيين. بالطبع، ينطبق هذا على اتصالات HTTP/2.

يتم تحديد الاختلافات الإضافية من خلال وظيفة CDN معينة - بالنسبة للنوع الأول فهو يستضيف فقط ملفًا ثابتًا، أما بالنسبة للخامس فهو يقوم بتغيير عدة أنواع من محتوى الموقع بغرض التحسين.

قدرات CDN لتسريع موقع الويب

دعونا نصف النطاق الكامل لقدرات CDN لتسريع المواقع، بغض النظر عن وظائف الأنواع الفردية لـ CDN، ثم نرى ما يتم تنفيذه في كل منها.

1. ضغط موارد النص

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

  • يمكن استخدام درجات منخفضة للضغط الديناميكي - 5-6 (على سبيل المثال، بالنسبة لـ gzip، الحد الأقصى هو 9)؛
  • لا يستخدم الضغط الثابت (الملفات الموجودة في ذاكرة التخزين المؤقت) ميزات إضافية (على سبيل المثال، zopfi أو brotli بدرجة 11)
  • لا يوجد دعم لضغط Brotli الفعال (يوفر حوالي 20% مقارنة بـ gzip).

إذا كنت تستخدم CDN، فمن المفيد التحقق من هذه النقاط القليلة: خذ الملف الذي جاء من CDN، وقم بتسجيل حجمه المضغوط وضغطه يدويًا للمقارنة (يمكنك استخدام بعض الخدمات عبر الإنترنت مع دعم brotli، على سبيل المثال vsszhat.rf).

2. تحديد رؤوس التخزين المؤقت للعميل

هناك أيضًا ميزة تسريع بسيطة: إضافة رؤوس للتخزين المؤقت للمحتوى بواسطة العميل (المتصفح). أحدث رأس هو التحكم في ذاكرة التخزين المؤقت، والرأس القديم قد انتهت صلاحيته. بالإضافة إلى ذلك، يمكن استخدام Etag. الشيء الرئيسي هو أن الحد الأقصى لعمر التحكم في ذاكرة التخزين المؤقت كبير بما يكفي (من شهر أو أكثر). إذا كنت مستعدًا لتخزين المورد مؤقتًا بأقصى قدر ممكن، فيمكنك إضافة الخيار غير القابل للتغيير.

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

3. تحسين الصورة

نظرًا لأن CDN تتولى وظائف التخزين المؤقت وتقديم الصور، فسيكون من المنطقي تحسينها من جانب CDN وتقديمها للمستخدمين بهذا النموذج. دعونا نحجز على الفور أن هذه الميزة متاحة فقط لأنواع CDN 2 و3 و5.

يمكنك تحسين الصور بعدة طرق: استخدام تنسيقات الضغط المتقدمة (مثل WebP)، أو برامج التشفير الأكثر كفاءة (MozJPEG)، أو ببساطة تنظيف البيانات التعريفية غير الضرورية.

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

4. تحسين اتصال TLS

تنتقل معظم حركة المرور اليوم عبر اتصالات TLS، مما يعني أننا نقضي وقتًا إضافيًا في مفاوضات TLS. وفي الآونة الأخيرة، تم تطوير تقنيات جديدة لتسريع هذه العملية. على سبيل المثال، هذا هو تشفير EC، وTLS 1.3، وذاكرة التخزين المؤقت للجلسة والتذاكر، وتسريع تشفير الأجهزة (AES-NI)، وما إلى ذلك. يمكن أن يؤدي إعداد TLS بشكل صحيح إلى تقليل وقت الاتصال إلى 0-1 RTT (لا يشمل DNS وTCP ).

مع البرامج الحديثة، ليس من الصعب تنفيذ مثل هذه الممارسات بنفسك.

لا تطبق جميع شبكات CDN أفضل ممارسات TLS؛ يمكنك التحقق من ذلك عن طريق قياس وقت اتصال TLS (على سبيل المثال، في Webpagetest). مثالي للاتصال الجديد - 1RTT، و2RTT - المستوى المتوسط، و3RTT والمزيد - السيئ.

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

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

5. تقليل تأخير الاتصال

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

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

معظم شبكات CDN الغربية ليس لديها نقاط في روسيا على الإطلاق. من خلال الاتصال بهم، يمكنك فقط زيادة التأخير لجمهورك الروسي.

6. تحسين المحتوى (التصغير، التغييرات الهيكلية)

النقطة الأكثر تعقيدًا وتقدمًا من الناحية التكنولوجية. قد يكون تغيير المحتوى أثناء التسليم محفوفًا بالمخاطر للغاية. حتى لو أخذنا التصغير: فإن تقليل الكود المصدري (بسبب المسافات الزائدة، والهياكل غير المهمة، وما إلى ذلك) يمكن أن يؤثر على أدائه. إذا تحدثنا عن تغييرات أكثر خطورة - نقل كود JS إلى نهاية HTML، ودمج الملفات، وما إلى ذلك - فإن خطر تعطيل وظائف الموقع أعلى.

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

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

دعم قدرات التسريع حسب نوع CDN

لذلك دعونا نلقي نظرة على فرص التسريع المحتملة التي توفرها الأنواع المختلفة من شبكات CDN.

للراحة، نكرر التصنيف.

  1. CDN مجاني لتوزيع مكتبات JS (MaxCDN، Google. Yandex).
  2. CDN للخدمات لتحسين العميل (على سبيل المثال، Google Fonts للخطوط، Cloudinary، Cloudimage للصور).
  3. CDN لتحسين الموارد والثبات في CMS (متوفر في Bitrix وWordPress وغيرها).
  4. CDN للأغراض العامة (StackPath، CDNVideo، NGENIX، Megafon).
  5. CDN لتسريع موقع الويب (Cloudflare، Imperva، Airi).

الآن دعونا نقارن ميزات وأنواع CDN.

فرصة
اكتب 1
اكتب 2
اكتب 3
اكتب 4
اكتب 5

ضغط النص
+ -
-
+ -
+ -
+

رؤوس ذاكرة التخزين المؤقت
+
+
+
+
+

Картинки
-
+ -
+ -
-
+

TLS
-
-
-
+ -
+

تأخير
-
-
-
+
+

محتوى
-
-
-
-
+

في هذا الجدول، يتم استخدام "+" للإشارة إلى الدعم الكامل، و"-" لعدم وجود دعم، و"+–" للإشارة إلى الدعم الجزئي. بالطبع، قد تكون هناك انحرافات عن هذا الجدول في الواقع (على سبيل المثال، ستنفذ بعض CDN ذات الأغراض العامة ميزات لتحسين الصور)، ولكنها مفيدة لفكرة عامة.

نتائج

نأمل، بعد قراءة هذه المقالة، أن يكون لديك صورة أوضح فيما يتعلق بتوصية "استخدام CDN" لتسريع مواقعك.

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

من الممكن أن يؤدي استخدام CDN الآن إلى إبطاء وقت تحميل موقعك.

كتوصية عامة، يمكننا التركيز على ما يلي: دراسة جمهورك، وتحديد نطاقه الجغرافي. إذا كان جمهورك الرئيسي يتركز داخل دائرة نصف قطرها 1-2 ألف كيلومتر، فلن تحتاج إلى CDN لغرضها الرئيسي - وهو تقليل زمن الوصول. بدلاً من ذلك، يمكنك وضع خادمك بالقرب من المستخدمين لديك وتكوينه بشكل صحيح، والحصول على معظم التحسينات الموضحة في المقالة (مجانية ودائمة).

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

المصدر: www.habr.com

إضافة تعليق