شبكة توصيل المحتوى (CDN) هي شبكة من الخوادم موزَّعة على مواقع جغرافية متعددة، تحتفظ بنسخ مخزَّنة مؤقتًا من محتوى الموقع الثابت، بحيث يُخدَم طلب الزائر من موقع أقرب إليه فعليًا بدلاً من أن يقطع كل المسافة إلى الخادم الأصلي. هذه هي الآلية بأكملها — كل ما تنفع فيه CDN ينبع من هذه الفكرة الواحدة، وكل ما لا تنفع فيه ينبع من حدود تلك الفكرة نفسها.

ماذا تفعل شبكة CDN فعليًا

حين توجد CDN أمام موقع، لا يتصل متصفح الزائر بالضرورة بالخادم الأصلي في كل طلب. تُنسَخ الأصول الثابتة — الصور، ملفات CSS وJavaScript، وأحيانًا صفحات HTML كاملة مخزَّنة مؤقتًا — إلى خوادم طرفية (تُعرَف أيضًا بنقاط التواجد) في مناطق متعددة، ويُوجَّه طلب الزائر إلى أقرب خادم طرفي له، باستخدام توجيه معتمد على DNS أو ما يُعرف بالـ anycast عادةً. إن كان الملف المطلوب مخزَّنًا مؤقتًا هناك بالفعل، يُخدَم مباشرة من ذلك الخادم القريب. إن لم يكن كذلك، يجلبه الخادم الطرفي من الأصل مرة واحدة، ويخزّنه مؤقتًا، ويقدّمه لذلك الزائر ولكل زائر لاحق يُوجَّه لنفس الخادم حتى تنتهي صلاحية النسخة المخزَّنة.

المشكلة التي تحلها: المسافة الجغرافية

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

تخفيف الحمل عن الخادم الأصلي: النصف الآخر من عمل CDN

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

كيف تقرر CDN ماذا تُخزِّن مؤقتًا ولأي مدة

لا تخمّن CDN ما يُعدّ آمنًا للتخزين المؤقت — بل تتبع قواعد تخزين، أكثرها شيوعًا مُعبَّر عنها عبر ترويسات cache-control في HTTP يرسلها الخادم الأصلي مع كل استجابة، تحدد هل يمكن تخزين المورد مؤقتًا أصلاً ولأي مدة (نفس فكرة زمن البقاء (TTL) في DNS الموضَّح في شرح TTL في DNS، مطبَّقة على المحتوى بدلاً من سجلات DNS). قد يُضبَط ملف CSS نادر التغيير ليُخزَّن مؤقتًا ليوم أو أكثر؛ وقد تُضبَط صفحة HTML متكررة التحديث لنافذة تخزين أقصر بكثير، أو تُعلَّم كغير قابلة للتخزين مؤقتًا إطلاقًا. يسبب الخطأ في أي الاتجاهين مشاكل حقيقية: التخزين المؤقت لمدة طويلة جدًا يعني أن الزوار قد يرون محتوى قديمًا بعد تحديث حتى تنتهي صلاحية النسخة، بينما التخزين المؤقت الحذر جدًا (أو عدم تخزين محتوى قابل للتخزين إطلاقًا) يتخلى عن معظم الفائدة التي توجد CDN من أجلها. تقدّم معظم شبكات CDN أيضًا خيار إفراغ يدوي للذاكرة المؤقتة، يتيح لمالك الموقع فرض تحديث فوري عبر المواقع الطرفية مباشرة بعد تغيير محتوى متعمَّد، بدلاً من انتظار انتهاء نافذة التخزين المؤقت العادية.

ما لا تصلحه شبكة CDN

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

هل يحتاج موقعك فعلاً إليها؟

  • الزوار موزَّعون عبر قارات أو مناطق متعددة بعيدة عن الأصل. إن كان الجمهور محليًا بالغالب لمكان وجود الخادم أصلاً، فلم يكن التأخير الذي تزيله CDN كبيرًا من الأساس.
  • حركة المرور متذبذبة أو غير متوقعة. تهم فائدة تخفيف الحمل عن الأصل أكثر كلما قلّ انتظام نمط الحركة.
  • معظم المحتوى ثابت أو قابل للتخزين المؤقت. موقع بمحتوى ديناميكي شخصي بالغالب يحصل على حصة أصغر من الفائدة، لأن تلك الطلبات عادة لا يمكن خدمتها من الذاكرة المؤقتة.
  • وزن الصفحة يهيمن عليه الصور والسكربتات وأوراق الأنماط لا زمن معالجة الخادم. تُسرِّع CDN توصيل تلك الأصول؛ لا تُسرِّع ما يُولِّد HTML المحيط بها.

موقع تجاري بموقع واحد وقاعدة عملاء إقليمية وحركة متواضعة ومستقرة غالبًا لا يحتاجها — فالتأخير الذي كانت ستزيله لم يكن كبيرًا أصلاً نسبة لكل شيء آخر يؤثر في زمن التحميل. أما موقع يخدم زوارًا عبر عدة دول، أو يحتاج استيعاب ارتفاعات حركة غير متوقعة دون انهيار الأصل، فحالة أوضح بكثير لإضافتها. يستحق الأمر أيضًا قياس القرار حسب توزيع الجمهور الفعلي بدلاً من معاملته كخيار كله أو لا شيء: موقع بـ90% من حركته في منطقة واحدة ونزر بسيط من مناطق أخرى يحصل على معظم الفائدة المتاحة فقط من خادم أصلي جيد الموقع، مع دور CDN الأساسي في تنعيم الذيل الطويل بدلاً من تحويل التجربة لمعظم الزوار — حالة مختلفة عن موقع بحركة عالمية فعلاً وموزَّعة بالتساوي، حيث لا يقترب أي موقع أصل واحد من معظم الزوار أينما وُضِع.

كيف تتناسب CDN مع بقية البنية التحتية

تقف CDN أمام الاستضافة، لا بديلاً عنها — لا يزال الخادم الأصلي مضطرًا لتوليد كل استجابة غير مخزَّنة مؤقتًا بالفعل، ولا يزال يشغّل قاعدة البيانات، ولا يزال يحتاج سعة كافية للتعامل مع الطلبات غير المخزَّنة والطلبات الديناميكية. اقتران CDN ببنية تحتية مُصغَّرة أصلاً عن حجم التطبيق لا يفعل أكثر من نقل مكان ظهور البطء، لا إزالته؛ راجع فهم قابلية التوسع في البنية التحتية السحابية لمعرفة كيف تعمل سعة الأصل والتوزيع معًا لا كبديلين لبعضهما. التسلسل العملي المعتاد هو: التأكد أولاً أن الأصل نفسه يستجيب بسرعة، ثم إضافة CDN لمدّ تلك السرعة للزوار البعيدين جغرافيًا عنه أو لاستيعاب حركة لم يكن الأصل وحده ليتعامل معها بسلاسة. إضافة CDN تُدخِل أيضًا طبقة إضافية يجب احتسابها حين يبدو شيء خاطئًا — زائر يُبلِغ عن محتوى قديم بعد نشر إصلاح قد يكون بسبب ذاكرة تخزين مؤقت طرفية قديمة بقدر ما قد يكون خطأً فعليًا، ومعرفة أن CDN تقف في المسار تُغيِّر أين تبحث أولاً.