كيفية توزيع عملاء الألعاب والتحديثات عبر شبكة CDN

ما الذي تحتاجه (وما الذي تفعله CDN هنا)

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

وإليك النطاق بصدق منذ البداية، لأنه مهم. تُوزّع شبكة CDN كل ما يُنزّله لاعبوك وكل ما تقدّمه لعبتك عبر HTTP: العميل، والتحديثات، والمحتوى الإضافي (DLC)، وحزم الأصول، واستجابات واجهات API الخاصة باللعبة والحساب. وهي ليست بديلًا عن خوادم الألعاب متعددة اللاعبين الفورية — فالمحاكاة المرجعية والمطابقة (matchmaking) وشيفرة شبكة UDP طبقة منفصلة. ما يلي يتعلّق بجانب التوصيل، وهو لدى معظم الألعاب الجزء الأكبر والأكثر تقطّعًا والأكثر تعرّضًا للهجوم في العملية.

كيف تعمل: من الخادم الأصلي إلى الـ edge إلى اللاعب

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

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

ارفع نسختك (build) إلى تخزين CDN

ضع ملفات عميلك وتحديثاتك على CDN نفسها فلا يكون هناك خادم تنزيل تشغّله. من اللوحة، استخدم منطقة الملفات (Files) لرفع النسخ وتنظيمها كمدير ملفات. من الطرفية، ترفع cdnctl مثل scp — والأهم أنك تضع كل نسخة تحت رقم إصدار في المسار بحيث تكون غير قابلة للتغيير ويمكن تخزينها مؤقتًا بقوة. ولأنابيب الفِرق أو آلات البناء المتعددة التي تريد أدوات S3 ومفاتيح وصول، انتقل إلى تخزين الكائنات المتوافق مع S3 بدلًا من ذلك (cdnctl object-storage buckets create ...).

cdnctl login --email you@studio.com --password ...
cdnctl accounts use <account_uuid>

# النسخة كاملةً، تحت مسار يحمل رقم إصدار (غير قابل للتغيير)
cdnctl cp -r ./build/1.4.2 builds/1.4.2/

# ملف تحديث تزايدي واحد
cdnctl cp ./patches/1.4.1-to-1.4.2.pak patches/1.4.1-to-1.4.2.pak

تخزين مؤقت وترقيم إصدارات لا يقدّم أبدًا تحديثًا قديمًا

الحيلة في توزيع الألعاب الآمن هي روابط غير قابلة للتغيير تحمل رقم إصدار. ولأن builds/1.4.2/client.pak لا يمكن أن يتغيّر بعد نشره، يمكنك تخزينه مؤقتًا على الـ edge فعليًا إلى الأبد — يجلب اللاعبون كل ملف مرة واحدة بالضبط. وحين تُصدر 1.4.3 فإنها تعيش في مسار جديد تمامًا، فلا نسخة قديمة تصارعها ولا تفريغ عالمي تنتظره.

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

Cache-Control للنسخ المُرقّمة مقابل الmanifest

# ملفات النسخ المُرقّمة لا تتغيّر أبدًا -> خزّنها مؤقتًا بقوة
Cache-Control: public, max-age=31536000, immutable

# الmanifest الذي يشير إلى الإصدار الحالي -> أبقِه محدّثًا
Cache-Control: public, max-age=60

اربطها بمُشغّلك (launcher) أو أداة التحديث

أداة التحديث التلقائي لديك لا تحتاج خوادم مخصّصة أيضًا. استضِف ملف manifest صغيرًا بصيغة JSON على CDN يسرد الإصدار الحالي وكل ملف مع مساره وحجمه وبصمته (hash). عند البدء، يجلب المُشغّل الmanifest من أقرب edge، ويقارن البصمات بما يملكه اللاعب أصلًا، ويُنزّل فقط الملفات التي تغيّرت — كلٌّ من الـ edge، وكلٌّ قابل للاستئناف عبر HTTP Range إن انقطع الاتصال في منتصف التنزيل.

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

manifest إصدار يُقدَّم من CDN

{
  "version": "1.4.2",
  "base_url": "https://cdn.yourgame.com/builds/1.4.2/",
  "files": [
    { "path": "client.pak", "size": 4213374208, "sha256": "..." },
    { "path": "audio.pak",  "size": 812934144,  "sha256": "..." }
  ]
}

تعامل مع موجات الإطلاق وهجمات DDoS

الألعاب من أكثر الأشياء تقطّعًا وتعرّضًا للهجوم على الإنترنت: فالإطلاق أو التخفيض يدفع كل لاعب إلى التنزيل دفعةً واحدة، والألعاب عبر الإنترنت هدف مفضّل لهجمات DDoS. تقديم التنزيلات من الـ edge يستوعب أصلًا الموجة المشروعة، لأن الشبكة تجيب عليها قرب اللاعبين بدلًا من خادمك الأصلي.

فوق ذلك، ضع WAF وحماية DDoS من CDN أمام نقاط التنزيل وأمام واجهة API الخاصة باللعبة والحساب، وأضِف تحديد المعدّل (rate limiting) بحيث لا يستطيع أي عميل واحد قصف مسار تسجيل الدخول أو فحص التحديث. يبقى خادمك الأصلي الحقيقي مخفيًّا خلف الـ edge، فتحطّ كل من موجة الإطلاق والهجوم على الشبكة المبنيّة لاستيعابهما، لا على خادمك. (وتوضيحًا للنطاق: هذا يحمي توصيلك عبر HTTP وواجهة API — أما التخفيف من الهجمات ضد خوادم ألعاب UDP الفورية فطبقة منفصلة ومتخصّصة.)

ما الذي تُطلقه الاستوديوهات بهذه الطريقة