Pull و Push: دو راه برای تغذیه edge
در مدل Pull، cdn.com.tr هر شیء را بار اول که درخواست میشود از origin موجود شما دریافت میکند و سپس آن را برای مدت TTLای که تعیین کردهاید در edge نگه میدارد؛ روی origin بهجز DNS چیزی تغییر نمیدهید. در مدل Push، داراییها را در فضای ذخیرهسازی cdn.com.tr آپلود میکنید و edge مستقیماً از همانجا ارائه میدهد، که ایدهآل است وقتی اصلاً نمیخواهید یک سرور origin را روشن نگه دارید. بیشتر مشتریان با Pull شروع میکنند چون به هیچ انتقالی نیاز ندارد و بعداً رسانههای سنگین را به Push یا Object Storage منتقل میکنند. هر دو مدل از قواعد cache، ابزارهای purge و گزارشگیری یکسان بهره میبرند.
قواعد cache، TTL و کلیدهای cache که در کنترل شماست
کار اصلی یک CDN، تصمیمگیری درباره اینکه چه چیزی امن است که cache شود و برای چه مدت است، و دقیقاً همین را پنل در اختیار شما میگذارد. TTL را بر اساس مسیر یا پسوند فایل تنظیم میکنید، انتخاب میکنید که هدر Cache-Control اصلی را رعایت یا بازنویسی کنید، و کنترل میکنید که کدام query string ها و کوکیها بخشی از کلید cache باشند تا /list?page=2 و /list?page=3 جداگانه cache شوند در حالی که پارامترهای tracking باعث تکهتکه شدن cache نشوند. درست کردن کلید cache همان چیزی است که نرخ hit پایین را به بالا تبدیل میکند، و گزارشها آن را قابلمشاهده میکنند تا بهجای حدس زدن، آن را تنظیم کنید.
کاهش بار و سپر origin
هر درخواستی که از edge پاسخ داده شود، درخواستی است که origin شما هرگز آن را نمیبیند؛ بنابراین یک صفحه محتوای پرترافیک که پیشتر سرور شما را با صدها درخواست تصویر و دارایی میکوبید، به چند fetch از origin در هر بازه TTL کاهش مییابد. چون بازدیدکنندگان بهجای IP origin شما به edge resolve میشوند، origin نیز دیگر ترافیک مستقیم دریافت نمیکند، که هم هزینه پهنای باند و هم میزان قرارگیری در معرض خطر را کاهش میدهد. همین کاهش بار است که یک سایت را سرپا نگه میدارد وقتی یک کمپین، یک موج خبری یا یک اشتراکگذاری در شبکههای اجتماعی، سیلی ناگهانی از بازدیدکنندگان را یکباره روانه میکند.
بهینهسازی خودکار تصویر با WebP
تصاویر معمولاً سنگینترین بخش یک صفحه هستند و ارسال فایلهای JPEG یا PNG با اندازه کامل به هر بازدیدکننده، پهنای باند را هدر میدهد و رندر را کند میکند. cdn.com.tr میتواند تصاویر واجد شرایط را بهصورت شفاف در edge به WebP تبدیل کند و نسخه سبکتر را به مرورگرهایی که پشتیبانی خود را اعلام میکنند ارائه دهد، در حالی که مرورگرهایی که پشتیبانی نمیکنند نسخه اصلی را بدون تغییر دریافت میکنند. لازم نیست کتابخانه رسانه خود را دوباره export کنید یا HTML خود را تغییر دهید؛ بهینهسازی در مسیر تحویل انجام میشود و صرفهجویی مستقیماً در حجم صفحه و زمان بارگذاری نمایان میشود.
cache کردن ایمن محتوای پویا
cache تنها برای فایلهای ثابت نیست. بسیاری از صفحاتی که پویا بهنظر میرسند، مانند فهرست دستهبندیها، صفحات محصول یا متن مقالات، تنها هر چند دقیقه یکبار تغییر میکنند و میتوان آنها را با یک TTL کوتاه بهصورت micro-cache نگه داشت تا ترافیک را جذب کنند و در عین حال تازه بمانند. cdn.com.tr به شما امکان میدهد این پاسخها را با قواعدی cache کنید که نشستهای واردشده و مسیرهای شخصیسازیشده را مستثنا میکند، بنابراین بازدیدکنندگان ناشناس از edge پاسخ میگیرند در حالی که سبد خرید یا صفحه حساب کاربری همیشه به origin میرود. نتیجه، سرعت در سطح CDN روی صفحاتی است که بیشتر پلتفرمها آنها را بدون cache رها میکنند.
سنجش موفقیت: نرخ hit و زمان بارگذاری
چیزی را که نمیبینید نمیتوانید بهبود دهید، بنابراین پنل نرخ cache hit، بایتهای ارائهشده از edge در برابر origin، و وضعیت cache هر پاسخ را گزارش میکند. یک سایت سالمِ پُر از محتوای ثابت باید پس از گرم شدن cache به نرخ hit بالایی برسد؛ نرخ پایین معمولاً به کلید cache حاوی یک کوکی یا query string ناپایدار اشاره دارد که میتوانید آن را در قواعد اصلاح کنید. تماشای این اعداد پس از هر تغییر، حلقه میان پیکربندی و سرعت واقعیای که بازدیدکنندگان شما حس میکنند را میبندد.
راهاندازی گامبهگام
دامنه خود را به حساب CDN اضافه کنید
در پنل، بخش دامنه را باز کنید، نام میزبان خود را وارد کنید (برای مثال www.example.com) و انتخاب کنید که cdn.com.tr بهعنوان origin از نوع Pull در برابر سرور موجود شما عمل کند یا بهعنوان مقصد Push که فایلها را روی آن آپلود میکنید. برای بیشتر سایتها، Pull سریعترین راه شروع است: نیازی به انتقال فایل نیست.
DNS را به edge بدهید
رکورد CNAME (یا رکورد apex اگر DNS را نزد ما نگه میدارید) را بهروزرسانی کنید تا ترافیک بهجای IP origin شما، به edge شبکه cdn.com.tr resolve شود. پس از انتشار resolution، هر درخواست ابتدا وارد یک edge node میشود و در صورت امکان از cache پاسخ داده میشود.
قواعد cache خود را تنظیم کنید
برای هر مسیر یا پسوند، TTL تعریف کنید: TTL طولانی (روزها) برای داراییهای نسخهدار مانند /assets/*.css و /*.js و تصاویر و فونتها؛ قواعد کوتاه یا bypass برای /cart و /checkout یا هر چیزی که کوکی نشست دارد. میتوانید هدر Cache-Control ارسالی از origin را رعایت کنید یا آن را از پنل بازنویسی کنید.
بهینهسازی تصویر را فعال کنید
تبدیل خودکار WebP را روشن کنید تا تصاویر JPEG و PNG دوباره encode شده و در قالبی سبکتر به مرورگرهایی که آن را میپذیرند ارائه شوند، در حالی که نسخه اصلی بهعنوان fallback نگه داشته میشود. این کار معمولاً حجم تصاویر را بهطور چشمگیری کاهش میدهد بدون آنکه به فایلهای اصلی شما دست بزند.
بررسی کنید که cache کار میکند
یک صفحه را بارگذاری کنید و هدرهای پاسخ را برای وضعیت cache (HIT/MISS) و age بررسی کنید. درخواست دوم به همان URL باید یک HIT را که از edge ارائه شده بازگرداند. از گزارشهای پنل استفاده کنید تا با گرم شدن edge، افزایش نرخ cache hit را تماشا کنید.
هنگام تغییر محتوا، purge کنید
پس از هر deploy یا ویرایش محتوا، URLهای متأثر (یا همه چیز) را از پنل یا از طریق purge API پاک کنید تا بازدیدکنندگان بلافاصله نسخه جدید را دریافت کنند، نه اینکه منتظر انقضای TTL بمانند.
نمونه سناریوها
یک سایت خبری یا وبلاگ، تصاویر، CSS و JavaScript خود را با TTL طولانی از edge ارائه میدهد، ترافیک origin را بهشدت کاهش میدهد و زمان بارگذاری صفحه را برای خوانندگان سراسر جهان کم میکند.
در جریان یک فروش لحظهای، صفحات فهرست محصول بهصورت micro-cache و داراییهای ثابت بهطور کامل cache میشوند، بنابراین یک جهش ناگهانی ترافیک در edge جذب میشود بهجای آنکه origin فروشگاه را از پا درآورد.
یک فروشنده، نصبکنندهها و بستههای بهروزرسانی را از طریق فضای ذخیرهسازی Push در edge توزیع میکند و فایلهای بزرگ را بهسرعت به کاربران میرساند در حالی که origin را از جهشهای پهنای باند محافظت میکند.
پرسشهای پرتکرار
چگونه بفهمم یک درخواست از cache ارائه شده است؟
هر پاسخ یک هدر وضعیت cache دارد که HIT (ارائهشده از edge) یا MISS (دریافتشده از origin) را بههمراه یک مقدار age نشان میدهد. یک URL را دو بار بارگذاری کنید: درخواست دوم به یک منبع قابلcache باید یک HIT بازگرداند. گزارشهای پنل نیز این را در قالب یک نرخ کلی cache hit تجمیع میکنند.
آیا cache پس از بهروزرسانی سایت، محتوای قدیمی ارائه میدهد؟
اشیای cacheشده تنها تا زمان انقضای TTL خود زنده میمانند، اما لازم نیست منتظر بمانید. بلافاصله پس از یک deploy، URLهای تغییریافته یا کل zone را از پنل یا purge API پاک کنید، و edge در درخواست بعدی نسخههای تازه را دریافت میکند در حالی که بقیه را همچنان از cache ارائه میدهد.
آیا میتوانم صفحاتی را که از کوکی یا query string استفاده میکنند cache کنم؟
بله، با کنترل. شما تصمیم میگیرید کدام کوکیها و پارامترهای query بخشی از کلید cache باشند، بنابراین موارد ضروری نسخههای cacheشده جداگانه میسازند در حالی که پارامترهای tracking نادیده گرفته میشوند. درخواستهای نشست یا واردشده را میتوان طوری تنظیم کرد که بهکلی از cache عبور کنند تا محتوای شخصیسازیشده همیشه به origin برسد.
آیا تبدیل WebP فایلهای تصویر اصلی مرا تغییر میدهد؟
خیر. تبدیل در مسیر تحویل انجام میشود. نسخههای اصلی ذخیرهشده شما دستنخورده میمانند؛ edge یک نسخه WebP تولید و به مرورگرهایی که از آن پشتیبانی میکنند ارائه میدهد و برای بقیه به قالب اصلی بازمیگردد.
اگر سرور origin من از دسترس خارج شود چه میشود؟
هر چیزی که پیشتر در edge cache شده باشد، در طول بازه TTL همچنان به بازدیدکنندگان ارائه میشود، بنابراین یک قطعی کوتاه origin لزوماً محتوای ثابت شما را از دسترس خارج نمیکند. درخواست برای اشیای cacheنشده یا منقضی همچنان به origin نیاز دارند، که دلیل دیگری است برای اینکه TTL داراییهای پایدار را سخاوتمندانه نگه دارید.
آیا برای استفاده از CDN باید فایلهایم را جابهجا کنم؟
با مدل Pull خیر. سرور origin موجود خود را نگه میدارید و تنها DNS را تغییر میدهید تا edge جلوی آن قرار گیرد و محتوا را در صورت نیاز دریافت و cache کند. فضای ذخیرهسازی Push اختیاری است و زمانی مفید است که بخواهید edge رسانه را بدون هیچ origin ای ارائه دهد.