راهنمای مطالعه
هدر Cache-Control (کنترل کش) یک هدر کلی است که خط‌مشی‌های کش پاسخ‌های سرور و همچنین درخواست‌های مشتری را مشخص میکند. اساساً، اطلاعاتی در مورد نحوه ذخیره یک منبع خاص، مکان منبع ذخیره‌شده و حداکثر سن آن که قبل از منقضی شدن به‌دست‌آمده است را مشخص میکند. در این پست از مجله هاست ایران می‌خواهیم در رابطه با مفهوم کنترل کش و ابعاد مختلف آن به گفتگو بپردازیم.
مفهوم کنترل کش چیست؟
کنترل کش یک هدر HTTP است که رفتار حافظه پنهان مرورگر را نشان می‌دهد و آن را دیکته میکند. به‌طور خلاصه، وقتی شخصی از یک وب‌سایت بازدید میکند، مرورگر او منابع خاصی مانند تصاویر و داده‌های وب‌سایت را در مکانی به نام کش ذخیره میکند. هنگامی‌که آن کاربر دوباره از همان وب‌سایت بازدید میکند، کنترل کش قوانینی را تعیین میکند که تعیین میکند آیا کاربر آن منابع را از حافظه پنهان محلی خود بارگذاری میکند یا اینکه مرورگر باید درخواستی برای منابع جدید به سرور ارسال کند. برای درک عمیق‌تر کنترل حافظه پنهان، به درک اولیه از کش مرورگر و هدرهای HTTP نیاز است.
کش مرورگر چیست؟
همان‌طور که در بالا توضیح داده شد، کش کردن مرورگر زمانی است که یک مرورگر وب منابع وب‌سایت را ذخیره میکند تا مجبور نباشد آن‌ها را دوباره از یک سرور واکشی کند. به‌عنوان‌مثال، یک تصویر پس‌زمینه در یک وب‌سایت ممکن است به‌صورت محلی در حافظه پنهان ذخیره شود تا زمانی که کاربر برای بار دوم از آن صفحه بازدید میکند، تصویر از فایل‌های محلی کاربر بارگیری میشود و صفحه بسیار سریع‌تر بارگیری میشود.
مرورگرها این منابع را فقط برای یک دوره زمانی مشخص ذخیره می‌کنند که به‌عنوان Time To Live (TTL) شناخته میشود. اگر کاربر پس از منقضی شدن TTL یک منبع ذخیره‌شده را درخواست کند، مرورگر باید دوباره به سرور دسترسی پیدا کند و یک نسخه جدید از منبع را دانلود کند. چگونه مرورگرها و سرورهای وب TTL را برای هر منبع می‌دانند؟ اینجاست که هدرهای HTTP وارد عمل می‌شوند. برای اطلاعات بیشتر در مورد کش، خواندن مقاله کش چیست پیشنهاد میشود.
هدرهای HTTP چیست؟
پروتکل انتقال ابرمتن (HTTP) نحوی را برای ارتباطات در شبکه جهانی وب تشریح میکند و این ارتباط شامل درخواست‌هایی از کلاینت‌ها به سرورها و پاسخ‌هایی از سرورها به مشتریان است. این درخواست‌ها و پاسخ‌های HTTP هرکدام با یک سری جفت‌های کلید-مقدار به نام سر صفحه یا هدر مهر می‌شوند.
این هدرها حاوی اطلاعات مهم زیادی در مورد هر ارتباط هستند. به‌عنوان‌مثال، یک هدر درخواست معمولاً شامل موارد زیر است:
- اطلاعات در مورد چه منبعی درخواست شده است
- مشتری از کدام مرورگر استفاده میکند
- چه فرمت‌های داده‌ای را مشتری می‌پذیرد
هدرهای پاسخ اغلب حاوی اطلاعاتی در مورد:
- اینکه آیا درخواست با موفقیت انجام شد یا خیر
- زبان و قالب هر منبع در بدنه پاسخ.
یک هدر کنترل کش می‌تواند هم در درخواست‌های HTTP و هم در پاسخ‌ها ظاهر شود.
هدر کنترل کش چیست؟
هدرهای کنترل کش از جفت‌های کلید-مقدار تشکیل‌شده‌اند که با دونقطه از هم جداشده‌اند. برای کنترل کش، ” key” یا قسمت سمت چپ کولون، همیشه «کنترل کش» است.” value” همان چیزی است که در سمت راست ویرگول یافت میشود و می‌تواند یک یا چند مقدار جداشده با کاما برای کنترل کش وجود داشته باشد.
این مقادیر دستورالعمل نامیده می‌شوند و تعیین می‌کنند که چه کسی می‌تواند یک منبع را در حافظه پنهان نگه دارد و همچنین مدت‌زمانی که آن منابع می‌توانند قبل از اینکه باید به‌روزرسانی شوند، ذخیره شوند. در زیر برخی از رایج‌ترین دستورالعمل‌های کنترل حافظه پنهان را مرور می‌کنیم:
کنترل کش خصوصی یا private
پاسخی با دستورالعمل “private” فقط توسط مشتری و هرگز توسط یک عامل واسطه مانند CDN یا یک پروکسی قابل ذخیره‌سازی نیست. این‌ها اغلب منابع حاوی داده‌های خصوصی هستند، مانند وب‌سایتی که اطلاعات شخصی کاربر را نمایش می‌دهد.
کنترل کش عمومی
برعکس، دستور عمومی به این معنی است که منبع را می‌توان توسط هر کش ذخیره کرد.
کش-کنترل no-store
پاسخی با دستورالعمل «no-store» را نمی‌توان در هیچ کجا ذخیره کرد. این بدان معنی است که هر بار که کاربر این داده را درخواست میکند، یک درخواست باید برای یک نسخه جدید به سرور اصلی ارسال شود. این دستورالعمل معمولاً برای منابعی محفوظ است که حاوی داده‌های بسیار حساس هستند، مانند اطلاعات حساب بانکی.
کنترل کش no-cache یا بدون کش
این دستورالعمل کنترل کش به این معنی است که نسخه‌های ذخیره‌شده منبع درخواستی را نمی‌توان بدون بررسی اولیه برای مشاهده نسخه به‌روزرسانی شده استفاده کرد. این معمولاً با استفاده از ETag انجام میشود. ETag یکی دیگر از هدرهای HTTP است که حاوی یک نشانه منحصربه‌فرد برای نسخه منبع در زمان درخواست آن است. هر زمان که منبع به‌روز شود، این نشانه در سرور مبدأ تغییر میکند.
وقتی کاربر به صفحه‌ای با منبع «no-cache» بازمی‌گردد، مشتری همیشه باید به سرور مبدأ متصل شود و ETag موجود در منبع ذخیره‌شده را با یک منبع در سرور مقایسه کند. اگر تگ‌های ET یکسان باشند، منبع ذخیره‌شده در حافظه پنهان در اختیار کاربر قرار می‌گیرد. در غیر این صورت، به این معنی است که منبع به‌روز شده است و مشتری باید یک نسخه جدید را دانلود کند تا در اختیار کاربر قرار دهد. این فرآیند تضمین میکند که کاربر همیشه به‌روزترین نسخه آن منبع را بدون نیاز به دانلودهای غیرضروری دریافت میکند.
کش کنترل حداکثر سن یا max-age
این دستورالعمل زمان زندگی را تعیین میکند، به‌عبارت‌دیگر چند ثانیه می‌توان یک منبع را پس از بارگیری از حافظه پنهان ارائه کرد. به‌عنوان‌مثال، اگر حداکثر سن روی ۱۸۰۰ تنظیم شود، به این معنی است که به مدت ۱۸۰۰ ثانیه (۳۰ دقیقه) پس از اولین درخواست منبع از سرور، نسخه کش شده آن منبع در درخواست‌های بعدی به کاربر ارائه میشود. اگر کاربر پس از انقضای ۳۰ دقیقه دوباره منبع را درخواست کند، مشتری باید یک نسخه جدید از سرور اصلی درخواست کند.
دستورالعمل ‘s-maxage’ به‌طور خاص برای حافظه‌های پنهان مشترک مانند CDN ها است و تعیین میکند که این کش های مشترک تا چه مدت می‌توانند منبع را از حافظه پنهان نگه‌دارند. این دستورالعمل «حداکثر سن» را برای مشتریان فردی لغو میکند.
چرا کنترل کش اهمیت دارد؟
کش مرورگر یک راه عالی برای حفظ منابع و بهبود تجربه کاربر در اینترنت است، اما بدون کنترل کش، بسیار شکننده خواهد بود. هر منبعی در هر سایتی به قوانین کش کردن یکسان محدود میشود، به این معنی که اطلاعات حساس مانند اطلاعات عمومی در حافظه پنهان ذخیره می‌شوند و منابعی که مکرراً به‌روز می‌شوند برای مدت‌زمان مشابهی ذخیره می‌شوند که به‌ندرت تغییر می‌کنند.
Cache-Control انعطاف‌پذیری را اضافه میکند که این امر کش مرورگر را واقعاً مفید میکند و به توسعه‌دهندگان اجازه می‌دهد نحوه ذخیره‌سازی هر منبع را دیکته کنند. همچنین به توسعه‌دهندگان این امکان را می‌دهد که قوانین خاصی را برای واسطه‌ها تعیین کنند که عاملی در این است که چرا سایت‌هایی که از CDN استفاده می‌کنند، نسبت به سایت‌هایی که این کار را نمی‌کنند، بهتر عمل می‌کنند.
سینتکس کنترل کش
سینتکس کنترل كش به‌صورت زیر است:
Cache-Control: <directive> [, <directive>]*
دستورالعمل ها: این هدر ۱۵ دستورالعمل را می‌پذیرد که همه موارد زیر را توضیح می‌دهد:
- Public: این دستورالعمل نشان می‌دهد که پاسخ را می‌توان بدون هیچ محدودیتی توسط هر کش ذخیره کرد. در صورتی که پاسخ غیرقابل کش باشد، همچنان می‌توان آن را کش کرد.
- private: نشان می‌دهد که فقط کش مرورگر برای ذخیره پاسخ واجد شرایط است.
- no-cache: نشان می‌دهد که پاسخ را می‌توان توسط هر کش بدون هیچ محدودیتی ذخیره کرد، حتی اگر غیرقابل کش باشد. شرطی که در اینجا باید رعایت شود این است که پاسخ ذخیره‌شده باید قبل از استفاده توسط سرور مبدأ تأیید شود.
- no-store: نشان می‌دهد که پاسخ توسط هیچ کشی ذخیره نمی‌شود.
- max-age=<seconds>: نشان‌دهنده حداکثر مدت‌زمانی است که یک منبع تازه باقی می‌ماند و می‌توان برای دسترسی به آن درخواست کرد.
- s-maxage=<seconds>: این دستورالعمل عمدتاً برای حافظه پنهان مشترک توسط شبکه‌های تحویل محتوا (CDN) استفاده میشود. این دستورالعمل حداکثر سن را لغو میکند و در صورت وجود سر صفحه منقضی میشود.
- max-stale[=<seconds>]: نشان می‌دهد که فقط یک پاسخ قدیمی توسط مشتری پذیرفته میشود.
- min-fresh=<seconds>: نشان می‌دهد که فقط پاسخی که تازه است توسط مشتری برای مدت‌زمان مشخص‌شده برحسب ثانیه پذیرفته میشود.
- stale-while-revalidate=<seconds>: نشان می‌دهد که پاسخ توسط مشتری پذیرفته میشود و به‌طور ناهم‌زمان به دنبال پاسخ‌های تازه می‌گردد. زمان برحسب ثانیه نشان‌دهنده مدت‌زمانی است که مشتری پاسخ قدیمی را می‌پذیرد
- stale-if-error=<seconds>: نشان‌دهنده این است که در صورت عدم موفقیت در بررسی جدید، پاسخ توسط مشتری پذیرفته میشود. زمان برحسب ثانیه نشان‌دهنده مدت‌زمانی است که مشتری پس از انقضای اولیه، پاسخ قدیمی را می‌پذیرد.
- must-validate: این نشان می‌دهد که حافظه‌های پنهان نمی‌توانند پس از قدیمی شدن از منابع قدیمی خود بدون تأیید اعتبار از سرور مبدأ استفاده کنند.
- proxy-revalidate: این دستورالعمل مشابه must-revalidate است. بااین‌حال، فقط برای کش های مشترک کار میکند و توسط کش های خصوصی نادیده گرفته میشود.
- Immutable: نشان می‌دهد که بدنه پاسخ در طول مدت‌زمان بدون تغییر باقی می‌ماند.
- no-transform: نشان می‌دهد که منابع را نمی‌توان به شکل دیگری تبدیل یا تغییر داد.
- only-if-cached: نشان می‌دهد که شبکه نمی‌تواند برای پاسخ توسط مشتری استفاده شود. این بدان معناست که کش می‌تواند از پاسخ ذخیره‌شده یا کد وضعیت ۵۰۴ استفاده کند.
مثال‌ها:
برای جلوگیری از کش، هدر پاسخ زیر می‌تواند استفاده شود:
Cache-Control: no-store
به‌منظور ذخیره کردن دارایی‌های استاتیک، می‌توان از هدر پاسخ زیر استفاده کرد:
· Cache-Control: public, max-age=604800, immutable
برای نیاز به اعتبارسنجی مجدد، می‌توان از موارد زیر استفاده کرد:
Cache-Control: no-cache
Cache-Control: no-cache, max-age=0
Cache-Control: no-cache, max-age=0, stale-while-revalidate=300
مرورگرهایی که از کنترل كش پشتیبانی می‌کنند
مرورگرهای سازگار با هدر HTTP Cache-Control در زیر فهرست شده‌اند:
- گوگل کروم
- Edge
- فایرفاکس
- اینترنت اکسپلورر
- اپرا
- سافاری
