بررسی مفهوم Browser Caching

منظور از Browser Caching (کش مرورگر)، ذخیره‌ی برخی (یا همه‌ی) منابع وب‌سایت روی مرورگر کاربر و عدم دریافت آن‌ها با هر بار مراجعه به وب‌سایت است. مرورگر این منابع را برای مدت ‌زمان مشخصی در Cache محلی خود ذخیره می‌کند. مرورگر وابسته به نوع سیاست Caching، پس از اتمام این مدت ‌زمان، برای استفاده‌ی دوباره از آن منبع، باید درخواستی را به‌سمت سرور ارسال کند.

سیاست‌های Caching هم‌چون مدت ‌زمان ذخیره‌ی یک منبع، چگونگی ذخیره‌ی آن، ذخیره‌ی آن از سوی چه کاربرانی (مرورگر یا سرورهای لبه‌ی CDN)، هم‌چنین نیاز یا بی‌نیازی دانلود دوباره‌ی یک منبع پس از منقضی شدن، همگی مواردی هستند که از راه هدرهای HTTP میان سرور و کاربر تبادل می‌شوند.

در این مطلب به مهم‌ترین هدرهای HTTP در حوزه‌ی Browser Caching و بررسی سیاست‌ کلی ابر آروان برای Cache منابع پرداخته می‌شود.

اعتبارسنجی پاسخ Cache شده با استفاده از هدر ETags

سرور از ETags HTTP header برای تبادل توکن اعتبارسنجی (Validation Token) استفاده می‌کند. Validation Token این امکان را فراهم می‌آورد که یک منبع Cache شده تنها زمانی دوباره دانلود شود که تغییر کرده باشد.

برای درک بهتر این موضوع، تصور کنید بیش‌ترین مدت ‌زمان ذخیره‌ی یک منبع در Cache مرورگر، 60 ثانیه باشد. پس از اتمام این مدت ‌زمان، مرورگر دیگر قادر به استفاده از آن منبع نیست و باید درخواستی را مبنی‌بر دریافت مجدد آن برای سرور ارسال کند. اما اگر این منبع در این مدت‌ زمان دچار هیچ تغییری نشده باشد، مرورگر دوباره همان داده‌هایی را دریافت می‌کند که در Cache خود دارد. پس دانلود دوباره‌ی این داده‌ها امری کار‌آمد نیست.

برای حل این مشکل، Validation Token که در هدر ETags گفته می‌شود، معرفی شد. سرور هنگام ارسال یک منبع برای نخستین‌بار به‌سمت مرورگر، به همراه مجموعه هدرهای HTTP، هدر Etags که حاوی Validation Token است را نیز برای آن می‌فرستد.

Validation Token یک رشته هش از محتوای فایل ارسالی است. پس از انقضای مدت‌ زمان ذخیره‌ی منبع در Cache، مرورگر این توکن را در قالب یک «If-None-Match HTTP request header» برای سرور ارسال می‌کند. سرور توکن را با منبع موجود مقایسه می‌کند و اگر منبع تغییری نکرده باشد، «HTTP status code 304 (Not Modified)» را در پاسخ، برای مرورگر می‌فرستد. این پاسخ برای مرورگر مشخص‌کننده‌ی آن است که به‌مدت 60 ثانیه‌ی دیگر نیز می‌تواند از منبع ذخیره‌شده در Cache خود استفاده کند و نیازی به دانلود دوباره‌ی آن نیست. عدم دانلود مجدد منبع به‌منزله‌ی حفظ زمان و پهنای باند و از سوی دیگر تاخیر کم‌تر در دسترسی کاربر به داده‌هاست.

تمامی این کارها را مرورگر به‌شکل خودکار انجام می‌دهد و توسعه‌دهندگان وب تنها کافی است تا از پشتیبانی ETags header از سوی سرور مطمین شوند. سرورهای لبه آروان از این هدر به‌طور کامل پشتیبانی می‌کنند.

هدر Expire

می‌توان با استفاده از این هدر، تاریخ و زمان دقیق انقضای یک منبع را مشخص کرد. در واقع استفاده از این هدر یک روش قدیمی برای انقضای یک پاسخ (Response) به‌شمار می‌آید.

تنظیم سیاست‌های Caching با استفاده از هدر Cache-Control

با استفاده از هدرهای HTTP cache-control می‌توان مشخص کرد که چه کاربری (Cacheability)، با چه شروطی (Revalidation) و چه مدت (Expiration) می‌تواند منبعی را Cache کند. این هدرها می‌توانند هم در Requestها و هم، Responseها حضور داشته باشند.

هدرهای Cache-Control این امکان را برای مدیران وب‌سایت‌ها فراهم می‌آورند که بتوانند چگونگی مدیریت محتوای دریافتی از وب‌سرور اصلی میزبان سایت را مشخص کنند. این سیاست‌ها را دستورات تعیین‌شده در Cache Control، مشخص می‌کنند. هدر Cache-Control می‌تواند شامل چند دستور باشد که این دستورات با ویرگول (,) از هم جدا می‌شوند. مهم‌ترین آن‌ها عبارت‌اند از:

• no-cache: کاربر (مرورگر یا سرور لبه‌ CDN) پیش از استفاده از منبعی که این دستور برای آن مشخص شده است، باید تایید معتبر بودن آن را از سرور اصلی دریافت کند. در نتیجه، اگر از ETags نیز استفاده شود، تنها Request و Response برای اطمینان از عدم تغییر منبع میان کاربر و سرور انجام می‌شود و نیاز به دانلود منبعی که تغییری نداشته، از بین می‌رود. این امر سبب حفظ پهنای باند و صرفه‌جویی در زمان می‌شود.
• no-store: این دستور به این معناست که مرورگر و تمام دستگاه‌های مابین آن و سرور اصلی (هم‌چون سرورهای لبه CDN) اجازه‌ی ذخیره‌ی این منبع در Cache خود را ندارند و در هربار نیاز به این منبع باید آن را از سرور اصلی درخواست کنند. برای نمونه، اطلاعات بانکی جزو دسته داده‌هایی هستند که نباید Cache شوند و کاربر در هربار دسترسی به آن‌ها باید این اطلاعات را از سرور اصلی درخواست کند و داده‌ها را به‌طور کامل دانلود کند.
• public: استفاده از این دستور برای یک منبع بیان‌گر آن است که هر کاربری (مرورگر یا سرورهای لبه‌ CDN) می‌تواند این منبع را ذخیره کند.
• private: اگر برای منبعی از این دستور استفاده شود، تنها مرورگر، و نه دستگاه‌های میان مرورگر و سرور اصلی، قادر به ذخیره‌ی آن منبع است. برای نمونه، مرورگر این اجازه را دارد تا صفحه HTML حاوی اطلاعات خصوصی کاربر را Cache کند اما سرورهای لبه‌ CDN، نمی‌توانند این صفحه را ذخیره کنند.
• max-age: این دستور مشخص‌کننده‌ی بیش‌ترین مدت ‌زمان ذخیره‌ی یک منبع در Cache، به ثانیه است. پس از اتمام این مدت، منبع منقضی شده و کاربر (مرورگر یا سرورهای لبه‌ CDN) باید دوباره آن را از سرور درخواست کند. برای نمونه، اگر max-age، برای یک منبع 60 ثانیه تعیین شود، مرورگر می‌تواند به‌مدت 60 ثانیه این منبع را در Cache خود ذخیره و از آن استفاده کند.

اگر در هدر Cache Control به‌روشنی از دستور private استفاده نشود و تنها max-age مشخص شود، به‌معنای ذخیره‌ی آن منبع به‌وسیله‌ی هر دستگاهی است و نیازی به تعیین روشن دستور public نیست.

مقادیر رایج برای max-age عبارت‌اند از:

• • یک دقیقه: max-age=60
  • یک ساعت: max-age=3600
  • یک روز: max-age=86400
  • یک هفته: max-age= 604800
  • یک ماه: max-age= 2628000
  • یک سال: max-age= 31536000
• s-maxage: در این مورد s مخفف shared cache است. این دستور مشابه دستور max-age است ولی دستورالعملی تنها برای CDNهاست و مرورگر آن را نادیده می‌گیرد. اگر برای منبعی از این دستور استفاده شود، CDN مقدار مشخص‌شده در این دستور را در نظر می‌گیرد و به هنگام استفاده از max-age یا هدر Expire، مقادیر آن‌ها را نادیده‌ می‌گیرد.
• must-revalidate: این دستور مشخص‌کننده‌ی آن است که کاربر (مرورگر یا سرور لبه CDN)، پیش از استفاده از منبعی ذخیره‌شده در Cache (منبعی که قدیمی شده و ممکن است اکنون وجود نداشته باشد یا دچار تغییر شده باشد؛ به بیان بهتر، منبعی که max-age مشخص‌شده برای آن به پایان رسیده است)، باید ابتدا آن را از سرور اصلی اعتبارسنجی کند و تا زمانی‌که این اعتبارسنجی کامل نشود، اجازه‌ی استفاده از منبع قدیمی را ندارد.
• proxy-revalidate: مشابه must-revalidate است. تنها با این تفاوت که این دستور ویژه‌ی proxy serverهاست.
• no-transform: این دستور برای دستگاه‌های میان سرور اصلی و مرورگر، همانند سرورهای لبه CDN، مشخص‌کننده‌ی آن است که اجازه‌ی تغییر آن منبع را ندارند.
• stale-while-revalidate: این دستور مشخص‌کننده‌ی مدت ‌زمانی به ثانیه است که در آن کاربر (مرورگر یا سرور لبه CDN) می‌تواند از منبع قدیمی ذخیره‌شده در Cache خود استفاده کند و هم‌زمان اعتبارسنجی آن منبع را نیز با سرور اصلی انجام دهد.
• Stale-If-Error: مشابه stale-while-revalidate است با این تفاوت که تنها زمانی کاربر (مرورگر یا سرور لبه CDN) می‌تواند از منبع قدیمی ذخیره‌شده در Cache خود استفاده کند که سرور اصلی در زمان اعتبارسنجی یکی از کدهای خطای 500، 501، 502، 503 یا 504 را ارسال کرده باشد.
• immutable: این دستور برای کاربر (مرورگر یا سرور لبه‌ CDN) مشخص‌کننده‌ی آن است که بدنه‌ی اصلی پاسخ با گذشت زمان تغییر نمی‌کند، پس نیازی به بررسی به‌روز شدن آن منبع تا زمانی‌که منقضی نشده، نیست.

تعیین سیاست‌های درست Caching

فلوچارت زیر -که نسخه‌ی اصل آن را Ilya Grigorik، یکی از توسعه‌دهندگان گوگل، تهیه کرده است- دید خوبی نسبت به چگونگی Cache بهینه‌ی منابع فراهم می‌کند. با استفاده از آن می‌توان تعیین کرد که برای هر منبعی بهتر است چه دستوری تنظیم شود:

نمونه‌‌هایی از تنظیمات Cache-Control

• Cache یک منبع استاتیک

Cache-Control: public, max-age=86400

• اطمینان از عدم ذخیره‌ی یک منبع مهم

Cache-Control: no-store

• ذخیره‌ی یک منبع در Cache مرورگر و عدم ذخیره‌ی آن به‌وسیله‌ی سرورهای لبه CDN

Cache-Control: private, max-age=3600

• ذخیره‌ی یک منبع در Cache مرورگر و سرورهای لبه‌ CDN ولی با شرط اعتبارسنجی آن در هر بار استفاده

Cache-Control: public, no-cache

• ذخیره‌ی یک منبع در سرورهای لبه‌ CDN و اعتبارسنجی آن‌ها در هر بار استفاده از آن منبع

Cache-Control: public, s-maxage=0

• ذخیره‌ی یک منبع به‌وسیله‌ی هر کاربری (مرورگر یا سرور لبه‌ CDN) و الزام بر اعتبارسنجی آن در هر بار استفاده از آن منبع

Cache-Control: public, no-cache, must-revalidate

• Cache یک منبع با مدت ‌زمان‌های انقضایی متفاوت در مرورگر و سرورهای لبه‌ CDN

Cache-Control: public, max-age=7200, s-maxage=3600

پیکربندی Cache-Control

HTTP cache-control header را می‌توان روی سرور، هم‌چنین با کد پیاده‌سازی کرد. در ادامه نمونه‌‎هایی از چگونگی پیاده‌سازی Cache-Control در سرورهای Apache، Nginx، هم‌چنین درون کدهای PHP آمده است.

• Apache

با اضافه کردن دستورات زیر به فایل .htacces می‌توان برای سرور مشخص کرد که برای فایل‌های تعیین‌شده در دستور، cache-control header را با پارامترهای: max-age با مقدار 84600 و public تنظیم کند:

<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
Header set Cache-Control "max-age=84600, public"
</filesMatch>

• Nginx

با افزودن دستورات زیر به فایل پیکربندی Nginx، برای فایل‌های مشخص‌شده در دستور، هدر  Cache-Controlبا پارامترهای: public و no-transform تنظیم می‌شود.

location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
add_header Cache-Control "public, no-transform";
}

می‌توان دستورات مربوط به اضافه شدن هدر Cache-Control را به‌شکل مستقیم درون کدهای وب‌سایت قرار داد. برای نمونه، دستور زیر، هدر Cache-Control با پارامتر max-age برابر یک روز را تنظیم می‌کند:

header('Cache-Control: max-age=84600');

سیاست‌های Caching ابر آروان

• فاز Request

در این فاز، نخست درخواست (Request) دریافت شده از سمت کاربر (مرورگر) با فهرستی از فایل‌های Cache شده در سرورهای لبه‌ آروان، مقایسه می‌شود و اگر درخواست، مربوط به یکی از این منابع Cache شده باشد، در زمان عدم انقضای آن منبع، سرورهای لبه‌ آن منبع را در پاسخ (Response) برای کاربر می‌فرستند. اما اگر منبع مورد درخواست منقضی شده باشد، سرورهای لبه آروان نخست منبع را از سرور اصلی میزبان سایت اعتبارسنجی می‌کند، سپس پاسخ کاربر را می‌دهند.

این‌که چه فایل‌هایی قابلیت Cache شدن در سرورهای لبه‌ آروان را دارند، بستگی به «تنظیمات Caching» شما در پنل آروان دارد. برای نمونه، هنگام تنظیم Cache تمامی فایل‌ها، به‌شکل خودکار تمام منابع وب‌سایت در سرورهای لبه آروان ذخیره می‌شود و دیگر مرحله‌ی بررسی فرمت، در هنگام دریافت درخواست کاربر انجام نمی‌شود.

• فاز Response

در این فاز سرورهای لبه آروان از دریافت Request در رابطه با منبعی با قابلیت Cache، نخست Cache خود را برای یافتن آن منبع جست‌وجو می‌کنند. اگر آن منبع را در Cache خود پیدا نکنند، درخواستی را برای سرور اصلی میزبان سایت، به‌منظور دریافت آن منبع می‌فرستند. پاسخی که از سمت سرور اصلی دریافت می‌شود را سرورهای لبه آروان برای کاربر می‌فرستند.

براساس هدرهای Request، پاسخی که از سمت سرور اصلی برای سرورهای لبه ارسال می‌شود، می‌تواند قابلیت Cache شدن داشته باشد که به ‌این ‌ترتیب با دریافت درخواست‌های بعدی برای دسترسی به این منبع، سرورهای لبه از منبع Cache شده برای پاسخ‌دهی به کاربران استفاده می‌کنند یا می‌تواند قابلیت Cache نداشته باشد که در این حالت، با هر بار درخواست دسترسی از جانب کاربران به این منبع، این مراحل باید دوباره تکرار شوند.

تنظیمات Cache مرورگر در پنل کاربری ابر آروان

شما می‌توانید در بخش «تنظیمات Caching» پنل آروان، با رفتن به بخش «تنظیمات پیشرفته» و فعال کردن گزینه‌ی «Cache اطلاعات در مرورگر»، مدت ‌زمان مجاز ذخیره‌ی داده‌ها در Cache مرورگر کاربران را مشخص کنید.

دقت داشته باشید که با استفاده از Browser Caching، منابع وب‌سایت شما در مرورگر کاربر ذخیره می‌شود و شما دسترسی به مرورگر کاربران خود برای پاک‌سازی Cache آن‌ها را نخواهید داشت.