چگونه کلاینت‌ها و patchهای بازی را با یک CDN توزیع کنیم

چه چیزهایی لازم دارید (و یک CDN اینجا چه می‌کند)

شما یک بازی دارید — رومیزی یا موبایل — که بازیکنان آن را نصب می‌کنند و به‌روز نگه می‌دارند: یک کلاینت که اغلب چند گیگابایت است، patchهای منظم، و محتوای دانلودی یا asset bundleها. و یک حساب cdn.com.tr دارید. کل فهرست همین است. شما یک ناوگان سرور دانلود برپا نمی‌کنید و خودتان یک شبکه‌ی جهانی نمی‌سازید.

اینجا از همان ابتدا محدوده را صادقانه می‌گوییم، چون اهمیت دارد. یک CDN هر چیزی را که بازیکنان دانلود می‌کنند و هر چیزی را که بازی شما روی HTTP سرو می‌کند توزیع می‌کند: کلاینت، patchها، DLC، asset bundleها و پاسخ‌های API بازی و حساب شما. این جایگزین سرورهای بازی چندنفره‌ی بلادرنگ نیست — شبیه‌سازی معتبر، matchmaking و netcode روی UDP یک لایه‌ی جداگانه‌اند. آنچه در ادامه می‌آید درباره‌ی سمت تحویل است، که برای بیشتر بازی‌ها بزرگ‌ترین، پرنوسان‌ترین و پرحمله‌ترین بخش عملیات است.

چطور کار می‌کند: از مبدأ تا edge تا بازیکن

یک CDN نسخه‌های کش‌شده‌ی فایل‌های شما را در مکان‌های edge در سراسر شبکه نگه می‌دارد. وقتی بازیکنی کلاینت یا یک patch را دانلود می‌کند، به‌جای یک سرور که ممکن است دور یا از پیش overload شده باشد، از نزدیک‌ترین edge سرو می‌شود. مبدأ شما — یا storage مربوط به CDN که بیلد را نگه می‌دارد — تنها زمانی درگیر می‌شود که یک edge هنوز فایل را نداشته باشد: نخستین درخواست کش را گرم می‌کند و هر کس پس از آن به‌صورت محلی سرو می‌شود.

این دقیقاً همان رفتاری است که در روز عرضه یا هنگام انتشار یک patch بزرگ می‌خواهید. سیل دانلودهایی که یک سرور دانلود واحد را ذوب می‌کرد، در سراسر شبکه پخش و نزدیک به هر بازیکن پاسخ داده می‌شود، در حالی که مبدأ شما پشت آن آرام می‌ماند. دانلودهای سریع‌تر برای بازیکنان دوردست به دست می‌آورید و صورتحسابی که ترافیک edge با کش کارآمد را بازتاب می‌دهد، نه مبدأیی که هر بایت را به هر کس سرو می‌کند.

بیلد خود را روی storage مربوط به CDN آپلود کنید

فایل‌های کلاینت و patch را روی خود CDN بگذارید تا هیچ سرور دانلودی برای اجرا نداشته باشید. از پنل، از بخش Files برای آپلود و سازمان‌دهی بیلدها مانند یک فایل‌منیجر استفاده کنید. از ترمینال، cdnctl مانند scp آپلود می‌کند — و مهم‌تر از همه، هر بیلد را زیر یک نسخه در مسیر می‌گذارید تا تغییرناپذیر باشد و بتوان آن را محکم کش کرد. برای خط لوله‌های تیمی یا ماشین‌های بیلد متعدد که ابزارهای S3 و access key می‌خواهند، به‌جای آن به object storage سازگار با 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/

# یک فایل patch افزایشی منفرد
cdnctl cp ./patches/1.4.1-to-1.4.2.pak patches/1.4.1-to-1.4.2.pak

کش و نسخه‌گذاری که هرگز patch کهنه سرو نمی‌کند

رمز توزیع امن بازی، URLهای نسخه‌دار و تغییرناپذیر است. چون builds/1.4.2/client.pak پس از انتشار هرگز نمی‌تواند تغییر کند، می‌توانید آن را روی edge عملاً برای همیشه کش کنید — بازیکنان هر فایل را دقیقاً یک‌بار می‌گیرند. وقتی 1.4.3 را عرضه می‌کنید، در مسیری کاملاً تازه قرار می‌گیرد، پس نه نسخه‌ی کهنه‌ای برای دست‌وپنجه نرم کردن هست و نه purge سراسری‌ای برای انتظار کشیدن.

تنها چیزی که تغییر می‌کند manifest کوچکی است که می‌گوید کدام نسخه فعلی است. آن را روی یک URL پایدار با کش کوتاه نگه دارید (یا هنگام انتشار آن را purge کنید) و هر فایل بیلد را تغییرناپذیر نگه دارید. همین ترکیب است که باعث می‌شود یک patch لحظه‌ای که manifest را جابه‌جا می‌کنید زنده شود، در حالی که گیگابایت‌ها داده‌ی بیلد شما برای همیشه کش‌شده می‌مانند.

Cache-Control برای بیلدهای نسخه‌دار در برابر manifest

# فایل‌های بیلد نسخه‌دار هرگز تغییر نمی‌کنند -> آن‌ها را محکم کش کنید
Cache-Control: public, max-age=31536000, immutable

# manifest که به نسخه‌ی فعلی اشاره می‌کند -> آن را تازه نگه دارید
Cache-Control: public, max-age=60

آن را به launcher یا patcher خود متصل کنید

به‌روزرسان خودکار شما هم به سرورهای سفارشی نیازی ندارد. یک manifest کوچک JSON روی CDN میزبانی کنید که نسخه‌ی فعلی و هر فایل را با مسیر، اندازه و hash آن فهرست می‌کند. هنگام شروع، launcher منیفست را از نزدیک‌ترین edge می‌گیرد، hashها را با آنچه بازیکن از پیش دارد مقایسه می‌کند و تنها فایل‌هایی را که تغییر کرده‌اند دانلود می‌کند — هرکدام از edge، هرکدام قابل‌ازسرگیری روی HTTP Range اگر ارتباط وسط دانلود قطع شود.

همین کل به‌روزرسان است: یک manifest به‌همراه فایل‌های نسخه‌دار، همه از CDN سرو می‌شوند. نه بک‌اند دانلودی برای اجرا، نه باگ دانلود ناقصی برای تعقیب، و همین طراحی برای یک launcher رومیزی یا یک بازی موبایل که در نخستین اجرا asset bundleها و remote config را می‌کشد کار می‌کند.

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 اضافه کنید تا هیچ کلاینت واحدی نتواند مسیر login یا patch-check را بکوبد. مبدأ واقعی شما پشت edge پنهان می‌ماند، پس هم سیل عرضه و هم یک حمله روی شبکه‌ای فرود می‌آیند که برای جذب آن‌ها ساخته شده، نه روی سرور شما. (برای شفافیت درباره‌ی محدوده: این از تحویل HTTP و API شما محافظت می‌کند — مهار حملات علیه سرورهای بازی بلادرنگ روی UDP یک لایه‌ی جداگانه و تخصصی است.)

استودیوها چه چیزهایی را این‌گونه عرضه می‌کنند