CDN مقابل السيرفر الأصل: مين يخزّن وش، ومتى تحتاجه فوق سيرفرك السعودي

السيرفر الأصل يملك الحقيقة الكاملة لموقعك، والـ CDN مجرد نسخة مؤقتة قريبة من الزائر. اعرف الفرق بدقة ومتى يوفّر لك CDN 60% من الحِمل ومتى يزيدك تعقيداً بلا فائدة.
الجواب المباشر: مين يخزّن وش
السيرفر الأصل (Origin) هو المصدر الوحيد للحقيقة في موقعك. عليه تعيش قاعدة البيانات، وكود التطبيق، وملفات المستخدمين، والجلسات، وكل عملية كتابة أو حساب أو تسجيل دخول. أما الـ CDN فهو شبكة سيرفرات موزّعة تخزّن نسخة مؤقتة فقط من الملفات الثابتة القريبة جغرافياً من الزائر: الصور، ملفات CSS و JavaScript، الخطوط، الفيديو، وأحياناً صفحات HTML كاملة إذا كانت لا تتغيّر لكل مستخدم.
الفرق الجوهري في سطر واحد: السيرفر الأصل يُنتج المحتوى، والـ CDN يعيد توزيع نسخة منه. لو حذفت ملفاً من السيرفر الأصل فهو زال فعلياً، أما لو حذفته من الـ CDN فهو مجرد إفراغ للنسخة المؤقتة (cache purge) وسيُجلب من جديد عند أول طلب. لهذا لا يمكن أبداً تشغيل موقع على CDN وحده، بينما يمكن تشغيله على سيرفر أصل وحده بلا CDN إطلاقاً.
القاعدة العملية: كل ما هو ثابت ويتكرر طلبه من آلاف الزوّار يستحق أن يعيش على حافة الشبكة (edge)، وكل ما هو خاص بمستخدم واحد أو يتغيّر كل ثانية يجب أن يبقى على الأصل. موقع نموذجي تشكّل الملفات الثابتة فيه 70% إلى 80% من إجمالي البايتات المنقولة، وهنا يظهر الربح: تحويل هذه النسبة إلى الـ CDN يخفّف الحِمل عن سيرفرك الأصل بشكل كبير ويقرّب المحتوى من الزائر.
ماذا يخزّن السيرفر الأصل تحديداً
السيرفر الأصل عندنا في كلاود هو خادمك السحابي (VPS على Virtualizor) أو حساب الاستضافة المُدارة (cPanel) في مركز بيانات الرياض. هو المكان الذي لا تنازل عنه، ويحتفظ بالتالي:
- قاعدة البيانات: كل صف بيانات وكل معاملة (transaction). لا يُخزَّن هذا على CDN لأنه يتغيّر باستمرار ويجب أن يكون متسقاً لحظياً.
- كود التطبيق ومنطق العمل: ملفات PHP أو Node أو Python التي تُنفَّذ لتوليد الصفحة. الـ CDN لا يُنفّذ كوداً خلفياً، هو يخدم مخرجات فقط.
- الجلسات والمصادقة: من سجّل الدخول، صلاحياته، سلّة الشراء، توكِن النفاذ الوطني. هذه بطبيعتها لا تُخزَّن مؤقتاً.
- ملفات المستخدمين المرفوعة: المستندات، الفواتير، المرفقات الخاصة، التي تحتاج تحكّم وصول دقيق.
لأن الأصل يحمل كل هذا، فإن زمن الاستجابة إليه يقرّر تجربة المستخدم في العمليات الديناميكية. سيرفر كلاود في الرياض يعطي زمن استجابة قرابة 8ms للزائر داخل المملكة، مقابل 100ms إلى 120ms لو كان الأصل في أوروبا أو أمريكا. هذا الفارق وحده، قبل أي CDN، يعني أن كل استعلام قاعدة بيانات وكل تسجيل دخول يكتمل أسرع بعشرة أضعاف تقريباً.
كيف يعمل الـ CDN فعلياً خلف الكواليس
حين يطلب زائر ملفاً، لا يذهب الطلب مباشرة للأصل بل لأقرب نقطة حضور (PoP) في شبكة الـ CDN. عندها يحدث أحد أمرين:
إصابة الكاش (Cache Hit)
إذا كان الملف موجوداً ومحدّثاً في تلك النقطة، يُسلَّم فوراً بلا لمس الأصل إطلاقاً. هذه هي الحالة المربحة، ومعدّل الإصابة الجيد لموقع مضبوط يتراوح بين 85% و95% من الطلبات الثابتة. كل إصابة كاش تعني طلباً أقل يصل لسيرفرك.
إخفاق الكاش (Cache Miss)
إذا لم يكن الملف موجوداً أو انتهت صلاحيته، يجلبه الـ CDN من الأصل مرة واحدة، يخزّنه، ثم يخدمه. الطلبات التالية لنفس الملف من نفس المنطقة تصير إصابات كاش. مدة بقاء الملف في الكاش يحكمها ترويسة TTL (مثل Cache-Control: max-age=31536000 أي سنة كاملة للأصول التي لا تتغيّر، أو دقائق معدودة لصفحة تتحدّث كثيراً).
المفتاح هنا هو ضبط الترويسات بدقة. ملف CSS أو صورة يحملان بصمة إصدار في الاسم (مثل app.9f3c.css) يمكن تخزينهما سنة كاملة بأمان، لأن أي تعديل ينتج اسماً جديداً. ضبط TTL خاطئ يسبب إما زوّاراً يشاهدون نسخاً قديمة، أو معدّل إصابة منخفض يُرهق الأصل. تجربة عملية: رفع نسبة الأصول المخزّنة سنوياً من 40% إلى 90% خفّض طلبات الأصل بمقدار النصف تقريباً في مواقع نراقبها.
متى تحتاج CDN فوق سيرفرك السعودي
الخطأ الشائع أن يظن صاحب موقع سعودي أن الـ CDN بديل عن السيرفر السعودي، والحقيقة أنهما طبقتان مختلفتان تعملان معاً. تحتاج CDN فوق سيرفرك في هذه الحالات:
- جمهور خارج المملكة: إذا كان جزء معتبر من زوّارك في الخليج أو مصر أو أوروبا، فالـ CDN يقرّب الأصول الثابتة منهم بدل أن تقطع المسافة كاملة للرياض. زائر في القاهرة قد يوفّر 60ms إلى 90ms على كل ملف ثابت.
- محتوى ثقيل بالوسائط: مواقع فيها صور عالية الدقة أو فيديو أو ملفات تحميل كبيرة. نقل هذه من الحافة يحرّر عرض النطاق (bandwidth) عن سيرفرك، وباقات VPS عندنا تبدأ بـ 500 GB نطاق شهري، والـ CDN يمدّها بشكل كبير.
- ذروات حِمل مفاجئة: حملة تسويقية أو خبر منتشر يجلب آلاف الطلبات المتزامنة. الـ CDN يمتص موجة الطلبات الثابتة ويحمي الأصل من الانهيار تحت الضغط.
- حماية إضافية: معظم شبكات الـ CDN تضيف طبقة تخفيف هجمات DDoS وجدار حماية تطبيقات (WAF) قبل أن يصل الطلب لأصلك.
باختصار: كلّما زاد نصيب المحتوى الثابت وتوزّع جمهورك جغرافياً، زاد عائد الـ CDN. موقع أخبار أو متجر بصور كثيرة قد يخدم 75% من بايتاته من الحافة.
متى لا تحتاج CDN، وقد يضرّك
ليست كل حالة تستفيد من CDN، وأحياناً تكون إضافته تعقيداً بلا مقابل:
- جمهورك كله داخل المملكة والأصل بالفعل في الرياض: إذا كان زوّارك جميعهم سعوديين وسيرفرك في مركز بيانات الرياض بزمن 8ms، فإن نقطة حضور الـ CDN قد لا تكون أقرب من سيرفرك أصلاً، والمكسب هامشي.
- موقع ديناميكي بالكامل: لوحة تحكّم أو نظام ERP داخلي حيث كل صفحة مخصّصة لمستخدم مسجّل الدخول. هنا لا شيء تقريباً قابل للتخزين المؤقت، والـ CDN يمرّر كل شيء للأصل ويضيف قفزة شبكية زائدة.
- سيادة البيانات والامتثال: إذا كان نظامك مرتبطاً بالنفاذ الوطني أو تكاملات حكومية تشترط بقاء البيانات داخل المملكة، فبعض شبكات الـ CDN العالمية تخزّن وتمرّر عبر نقاط خارجية، وهذا قد يخالف متطلبات الامتثال. تحقّق من مسار البيانات قبل التفعيل.
- حركة منخفضة: موقع بزوّار قليلين لا يجني من الـ CDN ما يبرّر تكلفته وتعقيد تصحيح أخطاء التخزين المؤقت.
القاعدة: الـ CDN يحسّن توصيل الثابت، لكنه لا يصلح بطء الأصل الديناميكي. لو كان سيرفرك بطيئاً في توليد الصفحات فالحل ترقية الأصل وضبط قاعدة البيانات، لا وضع CDN فوق مشكلة بنيوية.
كيف تقيس هل تحتاج CDN قبل أن تدفع مقابله
القرار لا يُبنى على انطباع بل على قياس. افتح أدوات المطوّر في المتصفح وراقب تبويب الشبكة (Network) لصفحتك الرئيسية، ثم صنّف الطلبات إلى ثابتة وديناميكية واحسب نسبة البايتات لكل نوع. إن كانت الأصول الثابتة تتجاوز 60% من الحجم المنقول، فأنت مرشّح قوي للاستفادة. راقب كذلك ثلاثة أرقام على سيرفرك الأصل عبر لوحة كلاود: استهلاك عرض النطاق الشهري مقابل حصّة باقتك (تبدأ بـ 500 GB على الباقات الأساسية)، ومتوسط زمن توليد الصفحة، وعدد الطلبات المتزامنة وقت الذروة.
إذا كان استهلاك النطاق يقترب من الحد أو يتجاوزه بسبب الصور والفيديو، فالـ CDN يوفّر عليك ترقية النطاق مباشرة. أما إن كان متوسط زمن توليد الصفحة مرتفعاً (مثلاً فوق 300ms) بينما نقل الملفات سريع، فالمشكلة في الأصل نفسه لا في التوزيع، والـ CDN لن يحلّها. هذا التمييز يوفّر عليك دفع اشتراك لا يعالج سبب البطء الحقيقي. عملياً، الموقع الذي تشكّل الصور فيه 70% من حجمه ويخدم زوّاراً من عدة دول هو الحالة المثالية للـ CDN، بينما لوحة تحكّم داخلية بزمن توليد بطيء تحتاج ترقية vCPU وذاكرة على الأصل أولاً.
المحتوى الديناميكي، النفاذ الوطني، والكاش
أخطر التباسات الـ CDN هو تخزين محتوى شخصي عن طريق الخطأ. لو خزّنت صفحة تعرض اسم المستخدم أو رصيده، فقد يراها زائر آخر بنسخة الأول، وهذه ثغرة تسريب بيانات حقيقية. لذلك القاعدة الصارمة: أي استجابة تحمل ترويسة Set-Cookie أو تعتمد على جلسة يجب ألا تُخزَّن مؤقتاً، وتُوسَم بـ Cache-Control: private, no-store.
الأنظمة المرتبطة بالنفاذ الوطني أو واجهات حكومية تتعامل غالباً مع بيانات هوية حسّاسة، وهذه يجب أن تصل الأصل السعودي مباشرة بلا وسيط يخزّنها. الحل المعماري السليم هو الفصل: الأصول الثابتة (صور، CSS، JS) عبر الـ CDN بأعلى معدّل إصابة، والمسارات الديناميكية والحسّاسة (تسجيل الدخول، لوحة التحكّم، واجهات الـ API) تُمرَّر للأصل بلا تخزين. هذا الفصل يعطيك أفضل ما في الطبقتين: سرعة الحافة للعام، وأمان وسيادة الأصل للخاص.
الخلاصة العملية
السيرفر الأصل ضرورة لا نقاش فيها، وهو ما تبنيه على كلاود بزمن استجابة 8ms داخل المملكة وتزويد تلقائي خلال ثوانٍ بعد الدفع. الـ CDN طبقة اختيارية فوقه، تُضاف حين يكون محتواك الثابت كبيراً أو جمهورك موزّعاً أو ذروات حِملك عالية. ابدأ بأصل سعودي سريع ومضبوط، ثم قِس نسبة الملفات الثابتة ومعدّل الإصابة المحتمل قبل أن تضيف CDN. إن كانت الأصول تفوق 60% من حركتك وجمهورك متفرّق، فالـ CDN يستحق، وإن كان كل شيء ديناميكياً وجمهورك سعودياً، فسيرفرك في الرياض وحده يكفي ويزيد.


