در مقاله قبلی در مورد فن آوری های وب، به مقاله مفیدی برای ذخیره سازی در HTTP (از این پس: "مقاله از nomagic.ru") اشاره کردیم. با این حال، در مورد مقاله، سؤالاتی داشتیم، و بحث در آنجا به پایان رسید، بنابراین ما مجبور شدیم خودمان به دنبال همه پاسخ ها باشیم. در واقع سؤالات به طور خاص به مقاله مربوط نمی شوند - آنها چندین سال است که انباشته شده اند. از حل نشدن آنها خسته شده‌ام، و مقاله فقط دلیلی برای جستجوی فعال‌تر راه‌حل‌ها ارائه می‌دهد.
ابزار
اولین سوال این است که چگونه می توان هدرهای HTTP درخواست های مرورگر و پاسخ های سرور را مشاهده کرد؟ نویسنده مقاله از nomagic.ru توصیه می‌کند از "ابزار توسعه‌دهنده وب" در فایرفاکس "برای این منظور و نوعی نوار توسعه‌دهنده گل آلود" برای اینترنت اکسپلورر استفاده کنید.
1) توسعه دهنده وبابزارهایی برای FF که قبلاً داریم، و هیچ ابزاری برای مشاهده هدرهای HTTP وجود ندارد، حتی بازرس DOM در نسخه 3 به دلایلی حذف شد!
3) و یک فکر بسیار غم انگیز: خوب، بیایید بگوییم که LiveHTTPHeaders برای FF داریم. با اینترنت اکسپلورر - ناگهان بله شما خوش شانس هستید. خوب، در مورد اپرا چطور؟ و گوگل کروم چطور؟
چرا تمام هدرهای HTTP را با استفاده از ابزارهای PHP مستقیماً در سایت نمایش نمی دهید؟ پس از همه، وجود دارد متغیرهای محیطی، متغیرهای کار با سرور و همه چیز. یعنی دقیقاً می دانیم چه چیزی وجود دارد، به عنوان مثال، $ _SERVER ["HTTP_HOST"] و HTTP_REFERER (ما در هر سایتی از آن استفاده می کنیم). همه بقیه باید اضافه شود HTTP_- در اینجا سرصفحه های درخواست وجود دارد. علاوه بر این، PHP یک تابع خاص getallheaders () برای این کار دارد. یا apache_request_headers (). و apache_response_headers (). آره. با این کار تمام هدرهای HTTP نمایش داده می شود. ظاهرا. اما ما در زیر کمربند و 15 دقیقه عذاب سختی روبه رو بودیم که نتیجه آن این بود: PHP روی هاست ما به صورت cgi (و نه به عنوان ماژول آپاچی) نصب شده است و در این پیکربندی همه این توابع ... هدرها () کار نکن!
با اجرای اسکریپت با اکو phpinfo ()و با نگاهی به نتیجه، متوجه می شویم که هدرهای درخواست HTTP مورد نیاز در آرایه هستند $ _ENV(و هیچ جای دیگر). بسیار خوب، _env خیلی _env است. اما تعداد زیادی زباله وجود دارد (در حال حاضر برای ما اضافی است) ، بنابراین ما یک آرایه جدید ایجاد می کنیم $ varrvisو قطعات کم و بیش ضروری را با دقت از _env جدا کنید:
Foreach ($ _ ENV به عنوان $ ke => $ va) (اگر (preg_match ("/ ^ HTTP \ _ / i"، $ ke) &&! Preg_match ("/ COOKIE / i، $ ke)) $ varrvis [" $ ke "] = $ va;)
اما برای دریافت هدرهای پاسخ سرور ما - خوب، در نهایت، هیچ چیز، به جز تابع headers_list ()... و فقط آن هدرهایی که خودمان با استفاده از تابع در اسکریپت PHP ارسال می کنیم سرتیتر ()... در تئوری، تابع headers_list ()باید بعد از نوشته شدن تمام سرصفحه ها اجرا شود. ما این کار را تقریباً انجام دادیم، اگرچه، به احتمال زیاد، برای این سایت (سایتی که آزمایش ها در آن انجام شده است) مهم نیست، زیرا همه جا استفاده می شود ob_start ("ob_gzhandler")... ساختار زیر را به انتهای اسکریپت های در حال آزمایش اضافه کنید:
Foreach (headers_list () به عنوان $ ke => $ va) ($ varrvis [$ ke] = $ va;)
و ما آرایه هدرهای خود را با پاسخ های سرور تکمیل می کنیم. و بین Request و Response، برای خوانایی، خط را وارد کنید:
$ varrvis ["پاسخ"] = "=============================";
در انتهای فیلمنامه‌ها باید برای نوشتن آزمایش شوند print_r ($ varrvis)- و سپس با خوشحالی صفحات سایت را در تمام مرورگرهای موجود ورق بزنید و هدرهای HTTP را تحسین کنید.
کش HTTP با دستورالعمل های آپاچی
مقاله nomagic.ru دو منبع دستورالعمل‌های کش را نشان می‌دهد: فایل‌های پیکربندی آپاچی (http.conf &&.htacces) و یک اسکریپت PHP مستقیماً با دستوراتی مانند هدر ("Pragma: no-cache"). اما هنوز منبع سومی وجود دارد - می توان آن را با تجربه ساده کشف کرد:
1) نوشتن (از نظر) در httpd.conf(Apache 1.3.39) خطوط:
LoadModule expires_module modules / mod_expires.so LoadModule headers_module modules / mod_headers.so AddModule mod_expires.c AddModule mod_headers.c
2) در پوشه سایت ما در htaccessدستورالعمل ها را اضافه کنید:
هدر اضافه کردن Cache-Control "public" ExpiresActive On ExpiresDefault "دسترسی به اضافه 1 ساعت"
3) یک اسکریپت ساده بنویسید pi.phpاز دو خط:
4) صفحه pi.php را در فایرفاکس باز کنید و آن را در LiveHTTPHeaders ببینید (ابزار PHP ما فقط می تواند هدرهای ارسال شده توسط تابع هدر () را نشان دهد، فعلا از آن استفاده نمی کنیم).خطوط زیر مربوط به کش است:
Cache-Control: بدون ذخیره، بدون حافظه پنهان، باید مجدداً تأیید شود، پس از بررسی = 0، پیش‌بررسی = 0 منقضی می‌شود: پنجشنبه، 19 نوامبر 1981، 08:52:00 به وقت گرینویچ پراگما: بدون کش
وویلا و شما به هیچ ویکی‌پدیایی نیاز ندارید - در اینجا آنها سرصفحه‌هایی هستند که حافظه پنهان را از بین می‌برند. آنها از منبع سوم - فایل php.ini می آیند. در آن، به طور پیش فرض، هنگام نصب PHP، دستورالعمل زیر نوشته شده است، به ویژه:
Session.cache_limiter = nocache
این اوست که باعث می شود PHP تحت شرایط خاصی هدرهای ضد کش ارسال کند (مثلاً هنگام استفاده از تابع session_register ()). ما البته با تطبیق شرایط با این شرایط کمی تقلب کردیم. اما چه کسی می تواند تضمین کند که او هرگز از این تابع در اسکریپت های خود استفاده نخواهد کرد session_register ()? بله، به طور کلی، و بدون آن، وضعیت بسیار بد است: خط اول را از اسکریپت pi.php حذف کنید (فقط echo phpinfo ();) - همچنین هیچ چیز خوبی نیست:
و این تمام چیزی است که دستورالعمل های کش آپاچی در ترکیب با "session.cache_limiter = nocache" در php.ini ارائه می دهد. مهمترین عنوان گم شده است - آخرین اصلاح شده(تاریخ آخرین تغییر صفحه)، بدون آن نصب صحیح یا از بین بردن حافظه پنهان در مرورگر غیرممکن است.
خنده دارترین نتیجه به دست می آید اگر "طوطی را همزمان از هر دو پا بکشید" - در php.ini بنویسید "session.cache_limiter = private" (شما باید آپاچی را مجددا راه اندازی کنید) و خط session_register ("var1") را در اسکریپت رها کنید. :
Cache-Control: خصوصی، حداکثر سن = 300، پیش بررسی = 300 منقضی می شود: پنجشنبه، 19 نوامبر 1981، 08:52:00 GMT آخرین تغییر: دوشنبه، 06 ژوئیه 2009، 15:13:40 GMT
ظاهر می شود آخرین تغییرکه زمان آخرین تغییر اسکریپت php را نشان می دهد و Cache-Controlتناقض دارد منقضی می شود... رفتار مرورگر غیر قابل پیش بینی خواهد بود.
HTTP Caching را تصحیح کنید
در آخرین عناوینی که در طول تجربه خود دریافت کردیم، ناهماهنگی به طور کلی به هیچ وجه کشنده نیست: مرورگرها هنوز این را ندیده اند، آنها کاملاً در برابر چنین چیزهایی "ایمن از نویز" هستند. بزرگترین مشکل فقط این است آخرین تغییر، که هم مورد نیاز کاربران (مرورگرها) و هم موتورهای جستجو است. واضح است که نمی توان از تاریخ اصلاح فایل PHP برای آن استفاده کرد - زیرا محتوای واقعی صفحه ممکن است اصلاً ربطی به این تاریخ نداشته باشد: معمولاً محتوای صفحه از پایگاه داده بازیابی می شود و تاریخ اصلاح آن نیز باید از آنجا بازیابی شود (از DB).
اگر این مقاله خاصی از سایت ما است، ما به سادگی تاریخ پست فعلی را از قسمت "datrec" جدول "مقالات" می گیریم. اگر این لیستی از مقالات (در صفحه اصلی سایت) است، ما به دنبال بالاترین تاریخ از همه ورودی ها با استفاده از فرمول "انتخاب حداکثر (`datrec`) از "مقالات" هستیم - این تاریخ خواهد بود آخرین تغییر صفحه که در عنوان می گذریم آخرین تغییر.
دو "نقطه کنترل" دیگر برای محتوا وجود دارد که با استفاده از هدرهای HTTP پیاده سازی می شوند:
1) Etag- هش محتوای صفحه، به عنوان مثال، با استفاده از تابع md5(صفحه_متن)؛
2) طول محتوا- طول کل متن ارسال شده به مرورگر در پاسخ به درخواست آن.
ما نمی توانیم استفاده کنیم طول محتوا، زیرا این پارامتر دائماً در حال تغییر است: در ستون سمت راست هر صفحه یادآوری می کنیم که این در نهایت سایت روزنامه تبلیغاتی "Delovaya Nedelya" است - لیستی از محصولات از آخرین شماره روزنامه. این لیست بسیار بزرگ است، بنابراین صفحه تنها بخش کوچکی از لیست انتخاب شده را نمایش می دهد به صورت تصادفی.
شما بپرسید چگونه استفاده می کنیم Etag- او نیز، پس دائماً به طور تصادفی تغییر می کند؟ خیلی ساده است: ما بخش متغیر صفحه را در هش نمی‌گذاریم، بلکه یک هش را فقط «از مواد پایگاه داده مقاله» می‌نویسیم. چرا نمی توانید همین کار را با طول محتوا? زیرا طول محتوامرورگر به راحتی می تواند بررسی کند (IE دقیقاً این کار را انجام می دهد - طول واقعی محتوای دریافتی را به سرور ارسال می کند). و هش را می توان به صورت تصادفی نوشت (مهم این است که با تغییر قسمت ردیابی شده صفحه تغییر می کند)، مرورگر نمی داند از کدام الگوریتم استفاده می کنیم و مجبور است به سادگی ما را بپذیرد. Etagبر ایمان
ما از دو روش هش استفاده می کنیم:
1) در مورد لیستی از متون به دست آمده از بسیاری از ردیف های جدول، ما ایجاد می کنیم Etag* طبق فرمول $ etag = md5 (لیست $);
2) در یک حالت ساده تر (فقط یک رکورد از جدول بازیابی می شود)، ما mysql را با افزودن یک مقدار اضافی به پرس و جو کار می کنیم: "select` id`, "title",` text, `author`,` datrec `، گذرواژه_قدیمی (concat ("عنوان"،" متن"، "نویسنده")) به عنوان` etag`از «مقالات» ...».
هنگام ارسال هدرها با استفاده از تابع هدر () باید مطمئن شوید که این اقدامات انجام شده است قبل ازهر نوع محتوایی که به مرورگر ارسال می شود (از طریق اکو، چاپ PHP یا فقط HTML ساده). یعنی ابتدا کل قسمتی که باید بررسی شود در یک متغیر قرار می گیرد و محاسبه می شود Etag*، تمام هدرها ارسال می شوند و تنها پس از آن می توان محتوا را نمایش داد. البته مگر اینکه در ابتدای صفحه ob_start ("ob_gzhandler") نوشته باشید. ما فقط آن را نوشتیم، بنابراین سرصفحه ها را در هر زمان و هر زمان ارسال می کنیم. این ob_gzhandlerهمچنین به شما امکان می دهد تمام محتوای ارسال شده به مرورگر را به یکباره دریافت کنید - توسط عملکرد ob_get_contents ()و همچنین طول واقعی محتوا (برای سربرگ طول محتوا) - عملکرد ob_get_length ()... ما، همانطور که قبلاً گفته شد، نمی توانیم در این سایت استفاده کنیم همهمحتوای صفحه برای تشکیل این هدرها. اما در سایت های دیگر - کاملا.
304 اصلاح نشده است
بنابراین ما تاریخ صحیح تغییر صفحه را برای مشتریان ارسال می کنیم Etag... مشتریان درک می کنند - آنها هدرها را در تماس های بعدی به این صفحه ارسال می کنند If-Modified-Sinceو اگر-هیچ-تطابق، که می توانید در انتهای هر یک از مقالات ما (البته پس از فشار دادن کلید F5) آن را مشاهده کنید. اما نتیجه مطلوب حاصل نشد: سرور در پاسخ به تمام درخواست های مرورگر به طور منظم هدر را ارسال می کند HTTP / 1.x 200 OKو نه 304 ... "ابزار" ما هدرهای "200 OK" را نمایش نمی دهد، زیرا ما آنها را با عملکرد هدر () تولید نمی کنیم.
سرفصل 304 می توان به تعداد زیاد از طریق LiveHTTPHeaders - برای فایل های تصویری، جاوا اسکریپت، css و صفحات ساده HTML مشاهده کرد. این هدر توسط خود آپاچی ارسال می شود و بدون هیچ گونه تغییری که ما با ماژول headers.so انجام می دهیم و بدون دستورالعمل های اضافی مانند "ExpiresActive On" این کار را انجام می دهد. اما برای صفحات تولید شده با PHP نه.
ما خودمان ارسال هدرها به مرورگر را در اسکریپت PHP نوشته‌ایم و خودمان باید وجود یا عدم اعتبار درخواست‌های بعدی مرورگر را بررسی کنیم و سپس خودمان پارامترهای کنترل را مقایسه کرده و بسته به نتیجه آن را ارسال کنیم. هدر مرورگر 200 یا 304. به طور دقیق تر، هدر 200 پی اچ پی همیشه خودش را می فرستد، ما فقط باید وضعیت نیاز را 304 محاسبه کنیم. این کار را در فایل پیکربندی اصلی همه سایت ها configbase.php انجام می دهیم.
مشکل در به دست آوردن اطلاعات در مورد هدرها این است که در یک میزبان PHP به صورت cgi و در دیگری به عنوان یک ماژول آپاچی اجرا می شود، بنابراین ابتدا باید وجود متغیرها را در آرایه های "superglobal" بررسی کنید. Envو سرورو بسته به نتیجه، یک مرجع به آرایه مناسب ایجاد کنید:
$ h304 = "HTTP / 1.x 304 اصلاح نشده است"; $ match = ""; $ since = ""; $ varr = آرایه (); $ varrvis = آرایه (); if (array_key_exists ("HTTP_HOST"، $ _ ENV)) $ varr = & $ _ENV; if (array_key_exists ("HTTP_HOST"، $ _ SERVER)) $ varr = & $ _SERVER; if (isset ($ varr ["HTTP_IF_NONE_MATCH"])) $ مطابقت = $ varr ["HTTP_IF_NONE_MATCH"]; $ match = trim (strval ($ match)); if (isset ($ varr ["HTTP_IF_MODIFIED_SINCE"])) $ since = $ varr ["HTTP_IF_MODIFIED_SINCE"]; $ since = explode (";"، $ since); $ since = strtotime (تریم ($ since));
خط ماقبل آخر به دلیل اینترنت اکسپلورر مورد نیاز است، که همچنین طول صفحه را در هدر IF_MODIFIED_SINCE ارسال می کند: "جمعه، 03 ژوئیه 2009، 15:42:30 GMT؛ طول = 20994" - ما همه چیز را از این سرصفحه که شایدبعد از نقطه ویرگول سپس یک آرایه مستقل از میزبان از هدرهای HTTP ایجاد می کنیم:
Foreach ($ varr به عنوان $ ke => $ va) (اگر (preg_match ("/ ^ HTTP \ _ / i"، $ ke) &&! Preg_match ("/ COOKIE / i، $ ke)) $ varrvis ["$ ke "] = $ va;) $ varrvis [" پاسخ "] =" ============================= ";
خوب، و بخش اصلی کش، هسته کل سیستم ما، که در داخل صفحات PHP قرار دارد (که در آن $ dat زمان جدول mysql است که توسط تابع به ثانیه تبدیل شده است. strtotime):
سربرگ ("Etag: $ etag")؛ هدر ("Cache-Control: private, max-age = 0")؛ هدر ("انقضا:" .gmdate ("r"). "GMT"); هدر ("اتصال: Keep-Alive")؛ هدر ("Keep-Alive: timeout = 5، حداکثر = 100")؛ if ($ since == $ dat) (اگر (! $ مطابقت || $ match == $ etag) ($ varrvis = h304 $؛ شامل "bottom.php"؛ هدر ($ h304)؛ سرصفحه ("اتصال: بستن ")؛ exit;)) else (سرصفحه ("آخرین تغییر: ".gmdate ("r"، $dat)." GMT")؛)
این سیستم در تمام مرورگرهای ذکر شده در این مقاله به درستی کار می کند: در صورت نیاز حافظه پنهان می کند و در صورت وجود اطلاعات جدید را به مرورگر ارسال می کند. به عنوان مثال، اگر پس از باز کردن صفحه اصلی سایت (با لیست مقالات) F5 را فشار دهید (در Opera نیست! :-)، در پایین صفحه می توانید عنوان مورد انتظار را مشاهده کنید. 304 (در اپرا نیز اگر به این صفحه بروید با کلیک بر روی پیوند در صفحه دیگری از سایت می توانید آن را ببینید). اگر در عنوان یک مقاله تغییراتی ایجاد شده باشد یا مثلاً مقاله جدیدی اضافه شده باشد، اسکریپت پس از دریافت درخواست اعتبارسنجی از مرورگر، تغییر در داده ها را تشخیص داده و محتوای صفحه جدید را برای مرورگر ارسال می کند. ، نه عنوان 304 .
از نظر انسانی، کاری که با این عناوین انجام می دهیم را می توان به صورت زیر خلاصه کرد:
1) ما به مرورگر (به طور کلی برای هر مشتری) دو علامت شناسایی ارسال می کنیم: زمان آخرین تغییر محتوای صفحه و هش صفحه (جمع چک). ما همچنین یک دستورالعمل ارسال می کنیم که اجازه ذخیره سازی را فقط به مشتری نهایی می دهد (Cache-Control: private). در همان عنوان (max-age = 0) می گوییم که مشتری نباید محتوای جدید را برای 0 ثانیه درخواست کند (یعنی همیشه باید آن را درخواست کند). در هدر بعدی (Expires) به مشتری همین را می گوییم: صفحه فوراً در حال حاضر منقضی می شود.
2) مرورگر با اطاعت صفحه را به همراه تصاویر و فایل های css در حافظه پنهان خود قرار می دهد. در تماس‌های بعدی به صفحه، مرورگر از سرور می‌پرسد که آیا تاریخ تغییر کرده است (IF_MODIFIED_SINCE) و گاهی اوقات، جمع چک (IF_NONE_MATCH) - برای مثال، IE در مورد چک‌سوم سؤال نمی‌کند.
3) اگر تاریخ تغییر کرده است، بررسی می کنیم که آیا درخواستی برای چک سام از مرورگر وجود داشته است یا خیر، و اگر چنین است، تغییر آن را نیز بررسی می کنیم. اگر چیزی تغییر نکرده است، هدر را به مرورگر ارسال کنید 304 ; در صورت تغییر - ما ارسال نمی کنیم 304 (و خود پی اچ پی 200 اوکی می فرستد).
بله، و یک جزئیات دیگر برای "ابزار" ما: هدر اول (وضعیت HTTP) به دلایلی توسط تابع بازیابی نمی شود. headers_list ()... وقتی که او 200 ، این خیلی مهم نیست، اما 304 من می خواهم ببینم (تا مطمئن شوم که سیستم کش ما کار می کند). بنابراین، شما باید این عنوان را با دست در خط به آرایه عناوین "رنگ" کنید
$ varrvis = $ h304;,و سپس برای سایر موارد دریافت شده توسط تابع headers_list ()هدرها شاخص را یک برابر افزایش می دهند ($ ke + 1):
Foreach (headers_list () به عنوان $ ke => $ va) ($ varrvis [$ ke + 1] = $ va;)
آخرین نکته ظریف. نحوه دیدن عنوان 304 در مرورگر اگر مرورگر این هدر را از سرور دریافت کرده باشد و محتوای صفحه را دریافت نکرده باشد (صفحه نباید روی صفحه تغییر کند)؟ بگذار این راز کوچک ما باقی بماند.
© 2009، "هفته تجاری"، میخائیل گوتنتوگ
501. SlipkeR
متشکرم) همه چیز واضح و قابل فهم است) به نویسنده ATP)
مرورگرهای مدرن اغلب از کش محلی در کار خود استفاده می کنند. این یعنی چی؟ این بدان معنی است که مرورگر با دریافت یک سند html، تصویر یا منبع دیگری از سرور، آن را در حافظه پنهان محلی خود قرار می دهد (به عبارت دیگر، منبع دریافتی را روی هارد دیسک دستگاه کاربر می نویسد) و در صورت درخواست های بعدی. به چنین منبعی، به سرور مراجعه نمی کند، بلکه منبع را از حافظه پنهان محلی دریافت می کند.
این الگوریتم مرورگر به طور چشمگیری سرعت بارگذاری اسناد html را افزایش می دهد. از آنجایی که اگر منبع قبلاً بارگیری شده باشد و در نتیجه در حافظه پنهان محلی قرار داشته باشد، زمان دسترسی نه با پهنای باند کانال ارتباطی (به عنوان مثال، یک اتصال مودم)، بلکه با سرعت هارد تعیین می شود. دیسک
با این حال، این روش در کنار مزایایی که دارد، تعدادی از مشکلات را نیز به همراه دارد. به طور خاص، اکثر برنامه نویسان وب مبتدی، هنگام توسعه سایت های پویا، با همین مشکل مواجه می شوند. ماهیت این مشکل این است که مرورگر به جای دسترسی مجدد به سرور برای صفحه ای که اسکریپتی را روی سرور اجرا می کند که برخی از اطلاعات را تغییر می دهد، به حافظه پنهان محلی دسترسی پیدا می کند. و در نتیجه، به عنوان مثال، از سه تماس، سه تغییر در اطلاعات موجود در سرور وجود ندارد، بلکه تنها یک تغییر وجود دارد.
برای اینکه مرورگر را مجبور کنیم هر بار صفحه ای را در سرور درخواست کند، لازم است از ورود مرورگر به این منبع به حافظه پنهان جلوگیری شود. در زیر متداول‌ترین روش‌ها برای غیرفعال کردن یا دور زدن حافظه پنهان هستند.
ایجاد یک URL جدید
فرض کنید منبع درخواستی دارای آدرس زیر است: test.html؟Id = 7. همانطور که از url می بینید، یک پارامتر به آن ارسال می شود. مثلاً با استفاده از جاوا اسکریپت، یک پارامتر دیگر به url اضافه می کنیم و مقدار آن را یک عدد تصادفی می کنیم. url حاصل به این شکل خواهد بود: test.html؟ ID = 7 و rnd = 0.6700820127538827. پارامتر تصادفی هر بار دوباره تولید می شود. در زیر فهرستی وجود دارد که این رویکرد را نشان می دهد:
هر بار نتیجه چنین درخواستی کش می شود، اما از آنجایی که کش در کل آدرس اینترنتی انجام می شود، هر بار یک آدرس اینترنتی جدید دریافت می شود و مرورگر مجبور می شود منبعی را از سرور درخواست کند، زیرا آدرس این دو مورد درخواست ها دقیقا مطابقت ندارند.
فیلدهای سرصفحه
همچنین می توانید کش را از سمت سرور مدیریت کنید. برای انجام این کار، منبع ارسال شده به مرورگر با فیلدهای هدر همراه است. شرح مفصلی از فیلدهای هدر را می توان در استاندارد RFC 2068 یافت که پروتکل HTTP 1.1 را توصیف می کند.
فیلد سرصفحه منقضی می شود
مقدار این هدر تاریخی است که پس از آن محتوای منبع منقضی می شود. اگر کاربری پس از این تاریخ به منبع دسترسی پیدا کند، مرورگر باید منبع را از سرور درخواست کند، نه از کش محلی.
اگر فیلد > منقضی می شود< содержит дату, прошедшую, по отношению к текущей, то при следующем обращении к ресурсу браузер будет вынужден снова обратиться к серверу. Это произойдет вследствие того, что либо документ не будет занесен в кэш — как уже устаревший, либо при обращении к кэшу браузер определит, что документ уже устарел. Следующий листинг на PHP демонстрирует использование заголовка Expires:
فیلد سرصفحه آخرین اصلاح شده
مقدار این هدر تاریخ آخرین به روز رسانی منبع است. اکثر مرورگرهای مدرن زمانی که منبع از قبل در حافظه پنهان محلی است از الگوریتم زیر استفاده می کنند:
* تاریخ آخرین به روز رسانی منبع را از سرور درخواست می کند
* تاریخ دریافت و تاریخ منبع را در حافظه پنهان محلی مقایسه می کند
* اگر منبع روی سرور جدیدتر از منبع موجود در حافظه پنهان باشد، منبع از سرور درخواست می شود.
اگر منبعی که در سرور قرار دارد حاوی تاریخ فعلی در این قسمت باشد، مرورگر هر بار منبع را از سرور درخواست می‌کند و نه از حافظه پنهان محلی. فهرست زیر استفاده از قسمت هدر آخرین اصلاح را نشان می دهد:
هدر ("آخرین تغییر:". gmdate ("D, d M Y H: i: s"). "GMT");
Cache-Control و Pragma Header Fields
در نهایت، فیلدهای هدر وجود دارند که مستقیماً مسئول ذخیره کردن منبع هستند. رشته
فیلد دوم در استاندارد RFC 2068 تعریف شده است که پروتکل HTTP 1.1 را توصیف می کند. این فیلد هدر به شما این امکان را می دهد که کش را غیرفعال کنید و هر بار یک منبع از سرور درخواست کنید. فهرست زیر استفاده از فیلدهای هدر Cache-Control و Pragma را برای غیرفعال کردن کش نشان می دهد:
هدر ("Cache-Control: no-cache, must-revalidate"); هدر ("Pragma: no-cache")؛
خوب بد
در روزهای خوب قدیم، ایجاد وب‌سایت‌ها به سادگی تایپ کردن چند وب‌سایت بود Html-pages، ارسال صفحات وب به مرورگر یک فایل ساده ارسال شده توسط وب سرور بود. بازدیدکنندگان سایت می توانند این صفحات کوچک و متنی را تقریباً فوراً ببینند (به جز کاربران مودم های کند). به محض اینکه صفحه بارگذاری شد، مرورگر آن را در جایی از رایانه محلی ذخیره می کند تا در صورت درخواست مجدد صفحه، نسخه محلی خود را تنها با ارسال یک درخواست کوتاه از حافظه پنهان بگیرد تا مطمئن شود که صفحه در سرور تغییر نکرده است درخواست ها به سرعت و تا حد امکان کارآمد پردازش شدند و همه راضی بودند (به جز کسانی که از مودم های 9600 باود استفاده می کردند).
ظهور صفحات وب پویا همه چیز را بدتر کرده است و به طور موثر این مدل ارائه صفحه وب را از طریق دو مشکل شکسته است:
- هنگامی که سرور درخواستی برای یک صفحه وب پویا دریافت می کند، برخی از پردازش های میانی انجام می شود، به عنوان مثال، تجزیه (تجزیه) اسکریپت توسط موتور PHPتکمیل شود. به لطف این، قبل از اینکه وب سرور شروع به ارسال خروجی به مرورگر کند، یک تاخیر دریافت می کنیم. برای ساده PHP-اسکریپت ضروری نیست، اما برای کاربردهای پیچیده تر، موتور PHPمی تواند اقدامات زیادی را قبل از آماده شدن صفحه برای ارسال انجام دهد. این مراحل اضافی تاخیر قابل توجهی را بین درخواست های کاربر و رندر واقعی صفحات در مرورگرهای آنها ایجاد می کند.
- یک وب سرور معمولی، مانند آپاچی، از زمان اصلاح فایل برای اطلاع صحیح به مرورگر وب از وضعیت کش صفحه درخواستی استفاده می کند. در واقع برای صفحات وب پویا PHP-اسکریپت را فقط می توان گاهی اوقات تغییر داد، در حالی که محتوای نمایش داده شده که احتمالاً در پایگاه داده قرار دارد، اغلب تغییر می کند. وب سرور هیچ راهی برای اطلاع از تغییر پایگاه داده ندارد، با این حال، آخرین تاریخ اصلاح را ارسال نمی کند. اگر مشتری (مرورگر) هیچ نشانه ای مبنی بر اینکه چه مدت داده درست است دریافت نکند، فرض می کند که دفعه بعد نیاز به درخواست صفحه جدید است. سرور وب همیشه با نسخه به روز شده صفحه پاسخ می دهد، صرف نظر از اینکه داده ها تغییر کرده باشند یا خیر. برای جلوگیری از این عیب، اکثر توسعه دهندگان وب از متا تگ یا HTTPهدرهایی که به مرورگر می گویند هرگز از نسخه کش صفحه استفاده نکند. با این حال، این توانایی طبیعی مرورگر وب برای ذخیره صفحات وب را نفی می کند و دارای معایب قابل توجهی است. به عنوان مثال، محتوای یک صفحه داینامیک می تواند یک بار در روز تغییر کند، بنابراین مزایای داشتن حتی 24 ساعته کش مرورگر صفحه آشکار است.
به طور کلی ممکن است برنامه های کوچک PHP این مشکلات را نادیده بگیرند، اما با افزایش پیچیدگی و ترافیک سایت شما ممکن است با مشکل مواجه شوید. با این حال، هر دوی این مشکلات را می توان حل کرد، اولی با کش سمت سرور، و دومی با کنترل حافظه پنهان سمت سرویس گیرنده از برنامه شما. روشی که برای حل مسائل استفاده می کنید به برنامه کاربردی شما بستگی دارد، اما در این فصل خواهیم دید که چگونه می توانید هر دو مشکل را با استفاده از PHP و برخی کلاس های کتابخانه ای حل کنید. گلابی.
چگونه از کش کردن صفحه توسط مرورگرها جلوگیری کنم؟
قبل از اینکه به روش‌های کش کردن مشتری و سرور نگاه کنیم، ابتدا باید بدانیم که چگونه می‌توان از ذخیره صفحات توسط مرورگر وب (و پروکسی‌ها) جلوگیری کرد. راه اصلی برای رسیدن به این هدف استفاده از متا تگ های HTML است:
با درج تاریخ گذشته در متا تگ Expires، به مرورگر می گویید که نسخه کش شده صفحه همیشه قدیمی است. این بدان معناست که مرورگر هرگز نباید صفحه را کش کند. متا تگ پراگما: بدون کشیک قرارداد نسبتاً خوب حفظ شده که اکثر مرورگرهای وب از آن پیروی می کنند. هنگامی که آنها این برچسب را پیدا کردند، معمولاً صفحه را کش نمی کنند (اگرچه هیچ تضمینی وجود ندارد، این فقط یک قرارداد است).
این خوب به نظر می رسد، اما دو مشکل در استفاده از متا تگ وجود دارد:
- اگر زمانی که صفحه برای اولین بار توسط مرورگر درخواست شد، تگ وجود نداشت، اما بعداً ظاهر شد (به عنوان مثال، فایل شامل را تغییر دادید. pageheader.phpکه سربرگ هر صفحه وب است)، مرورگر به طرز سعادتی نادان خواهد بود و از کپی های ذخیره شده اصلی خود استفاده می کند.
- پراکسی هایی که صفحات وب را ذخیره می کنند، مانند اشتراک گذاری شده ISPبه هیچ وجه مستقیماً محتوا را بررسی نمی کند Html-سند در عوض، آنها فقط به وب سروری که اسناد از آن آمده و پروتکل متکی هستند HTTP... به عبارت دیگر، مرورگر وب ممکن است فکر کند که نباید صفحه را کش کند، اما احتمالاً پروکسی بین مرورگر و وب سرور شما این را نمی داند - و همچنان همان صفحه قدیمی را برای مشتری ارسال می کند.
بهترین روش استفاده مستقیم از پروتکل است HTTPبا استفاده از تابع PHP سرتیتر ()، معادل دو متا تگ فوق:
با استفاده از عنوان می توانیم یک قدم جلوتر برویم Cache-Controlسازگار با مرورگرهایی که پشتیبانی می کنند HTTP 1.1:
سربرگ ("انقضا: دوشنبه، 26 ژوئیه 1997، 05:00:00 GMT")؛ هدر ("Cache-Control: no-store, no-cache, must-revalidate"); هدر ("Cache-Control: post-check = 0، pre-check = 0"، FALSE)؛ هدر ("Pragma: no-cache")؛
این تضمین می کند که هیچ مرورگر وب یا سرور پروکسی میانی صفحه را ذخیره نمی کند، بنابراین بازدیدکنندگان همیشه جدیدترین نسخه محتوا را دریافت می کنند. در واقع، هدر اول باید مستقل باشد، این بهترین راه برای اطمینان از ذخیره نشدن صفحه است. سرفصل ها Cache-Controlو پراگمابه منظور "ایمن بازی" اضافه شده است. در حالی که آنها در همه مرورگرها یا پروکسی ها کار نمی کنند، برخی موارد را پیدا می کنند منقضی می شودهمانطور که انتظار می رود کار نمی کند (به عنوان مثال، اگر تاریخ در رایانه مشتری به درستی تنظیم نشده باشد).
البته، حذف کامل کش کردن، مشکلاتی را که در ابتدای این فصل به آن پرداختیم، برای ما فراهم می‌کند. اکنون به دنبال راه حلی برای این مشکلات خواهیم بود.
اینترنت اکسپلورر و کش دانلود فایل
اگر در طول سرویس آپلود فایل PHP-اسکریپت از هدرهایی مانند Content-Disposition: پیوست، نام فایل = myFile.pdfیا Content-Disposition: درون خطی، نام فایل = myFile.pdfبا مشکل مواجه خواهید شد اینترنت اکسپلورراهم اگر به مرورگر بگویید صفحه را کش نکند.
اینترنت اکسپلورربارگذاری را به روشی نسبتاً غیرمعمول مدیریت می کند و دو درخواست به وب سایت می دهد. درخواست اول فایل را دانلود می کند و آن را در حافظه پنهان ذخیره می کند تا درخواست دوم ایجاد شود (بدون ذخیره کردن پاسخ). این درخواست فرآیند انتقال فایل به کاربر نهایی را با توجه به نوع فایل فراخوانی می کند (به عنوان مثال، راه اندازی می شود آکروبات ریدراگر فایل است PDF-سند). این بدان معناست که اگر هدرهایی را ارسال کرده اید که از ذخیره کردن صفحه توسط مرورگر جلوگیری می کند، اینترنت اکسپلوررفایل بین درخواست اول و دوم را حذف می کند و در نتیجه کاربر نهایی چیزی دریافت نمی کند. اگر فایلی که در حال آپلود هستید PHP-اسکریپت، تغییر نمی‌کند، یکی از ساده‌ترین راه‌حل‌ها حذف هدرهای "منع ذخیره کش" از اسکریپت خواهد بود.
اگر فایلی که دانلود می کنید به طور مرتب تغییر می کند (یعنی می خواهید مرورگر جدیدترین نسخه را دانلود کند) باید از هدر استفاده کنید. آخرین تغییر، که بعداً در این فصل پوشش داده خواهد شد و اطمینان حاصل کنید که زمان اصلاح بین دو درخواست متوالی تغییر نمی کند. شما باید این کار را به گونه ای انجام دهید که بر روی کاربران مرورگر که به درستی بارگذاری می شوند تأثیر نگذارد. یکی از راه حل ها در این مورد این است که فایل را در وب سرور خود ذخیره کنید و یک پیوند ساده به آن ارائه دهید و به وب سرور اجازه دهید هدرهای کش را برای شما گزارش کند. البته اگر دسترسی مجاز به فایل فرض شده باشد، ممکن است این راه حل قابل قبول نباشد، این راه حل اجازه بارگذاری مستقیم فایل ذخیره شده را می دهد.
چگونه می توانم داده های سمت سرور را برای ذخیره سازی ذخیره کنم؟
زمان آن رسیده است که نگاهی بیندازیم که چگونه می توانیم با استفاده از کش خروجی سمت سرور، تاخیر را کاهش دهیم. رویکرد کلی این است که شروع به رندر کردن صفحه به طور معمول با انجام پرس و جوهای پایگاه داده و غیره کنید PHP... با این حال، قبل از ارسال نتیجه به مرورگر، آن را می گیریم و صفحه تمام شده را برای مثال در یک فایل ذخیره می کنیم. در درخواست بعدی، PHP-اسکریپت ابتدا نسخه کش شده صفحه را بررسی می کند. اگر وجود داشته باشد، اسکریپت نسخه کش را به مرورگر ارسال می کند، بنابراین تاخیر در ایجاد مجدد صفحه حذف می شود.
چند کلمه در مورد کش کردن با قالب ها
چگونه می توانم کش سمت کلاینت را با PHP مدیریت کنم؟
زمان آن فرا رسیده است که مکانیزمی را بررسی کنیم که به ما امکان می دهد حافظه پنهان سمت کلاینت را با ابزار کنترل کنیم PHP... این روش تنها در صورتی کار خواهد کرد که از آن استفاده کنید PHPدر ارتباط با سرور آپاچیهمانطور که از تابع getallheaders () برای دریافت سرصفحه ها توسط مرورگر استفاده خواهیم کرد. این تابع فقط در داخل کار می کند آپاچی.
نام توابع جدید
اگر استفاده می کنید PHP 4.3.0 ثانیه آپاچیهدرهای HTTP با apache_request_headers () و apache_response_headers () در دسترس هستند. تابع getallheaders () به نام مستعار تابع apache_request_headers () جدید تبدیل شده است.
مکانیسم کار با کش مرورگر وب دوباره است HTTP... بسیاری از هدرها در آموزش به مرورگرهای وب و پروکسی ها برای ذخیره کردن صفحه به طور مستقل دخیل هستند، که به دلیل این واقعیت پیچیده است که برخی از آنها فقط در دسترس هستند HTTP 1.1.
بررسی هدرهای HTTP در مرورگر شما
یک ابزار ساده اما بسیار کاربردی برای بررسی هدر درخواست و پاسخ است LiveHttpHeaders- افزونه به مرورگر موزیلا... دقیقاً بدانید که اسکریپت شما چه هدرهایی را ارسال می کند، به خصوص زمانی که با هدرهای کش سروکار دارید. HTTP.
برای سادگی، ما فقط هدرهای کش HTTP 1.0 را در نظر می گیریم. منقضی می شود, آخرین تغییرو If-Modified-Sinceو همچنین کد وضعیت HTTP 304 (تغییر نشده).
سایر عناوین موجود با HTTPبرای مثال 1.1 Cache-Controlو ETagدر نظر گرفته شده است تا مکانیزم پیشرفته ای را ارائه دهد که می تواند در ارتباط با وضعیت جلسه وب مورد استفاده قرار گیرد، به عبارت دیگر، نسخه یک صفحه معین که به یک بازدیدکننده غیرمجاز نمایش داده می شود ممکن است به طور قابل توجهی با نسخه نمایش داده شده برای یک کاربر مجاز متفاوت باشد. سرفصل ها HTTP 1.1 در ابتدا اضافه شد تا امکان ذخیره چنین صفحاتی را فراهم کند.
انقضای صفحه
ساده ترین عنوان برای استفاده، عنوان است منقضی شودکه تاریخ انقضای صفحه را تعیین می کند (احتمالاً در آینده). تا آن زمان، مرورگر وب مجاز است از نسخه کش صفحه استفاده کند.
مثال 7. 6.php
"; echo" Now ". gmdate ("H: i: s")." GMT"؛ اکو" دوباره نگاه کنید
"; ?>
عملکرد setExpiresهدر می فرستد HTTP منقضی می شودبا زمان آینده مشخص شده در ثانیه. مثال بالا زمان فعلی GMT را نشان می دهد و یک لینک را به شما امکان می دهد دوباره به صفحه بروید. با استفاده از دکمه Refresh مرورگر خود، می‌توانید به مرورگر بگویید که می‌خواهید کش را تازه‌سازی کند. با استفاده از لینک مشاهده خواهید کرد که زمان تنها هر 10 ثانیه یکبار تغییر می کند.
تاریخ و زمان در HTTP
تاریخ ها در HTTP همیشه نسبت به زمان گرینویچ (GMT) محاسبه می شود. تابع gmdate () PHP دقیقاً همان تابع date () است، با این تفاوت که به طور خودکار GMT را بر اساس ساعت سیستم و تنظیمات منطقه سرور شما جبران می کند.
هنگامی که مرورگر با هدر روبرو می شود منقضی می شود، صفحه را کش می کند. تمام درخواست‌های صفحه بعدی که قبل از زمان انقضای مشخص شده انجام می‌شوند از نسخه کش صفحه استفاده می‌کنند، هیچ درخواستی به وب سرور انجام نمی‌شود.
سرفصل منقضی می شودپیاده سازی اکثراً آسان است، اما در بیشتر موارد، مگر اینکه فردی بسیار سازماندهی شده باشید، نمی توانید دقیقاً بدانید که یک صفحه معین از سایت شما چه زمانی به روز شده است. از آنجایی که مرورگر فقط پس از انقضای صفحه با سرور تماس می گیرد، هیچ راهی وجود ندارد که به مرورگر بگوید که صفحه موجود در حافظه پنهان آن قدیمی است. شما همچنین بخشی از ترافیک وب سایت خود را از دست می دهید زیرا مرورگر هنگام درخواست صفحه از کش با سرور تماس نمی گیرد.
زمان تغییر صفحه
استفاده از هدرها عملی تر است آخرین تغییرو If-Modified-Sinceقابل دسترسی در HTTP 1.0. از نظر فنی، به عنوان درخواست GET مشروط شناخته می شود، شما هر محتوایی را بر اساس شرایط هدر درخواست دریافتی برمی گردانید. If-Modified-Since.
هنگام استفاده از این روش، باید هدر را ارسال کنید آخرین تغییرهر بار که به اسکریپت PHP شما دسترسی پیدا می کند. دفعه بعد که مرورگر صفحه را درخواست کرد، هدر را ارسال می کند If-Modified-Sinceحاوی زمانی است که اسکریپت شما می تواند تعیین کند که آیا صفحه از آخرین درخواست به روز شده است یا خیر. اگر نه، اسکریپت شما یک کد وضعیت ارسال می کند HTTP 304برای نشان دادن اینکه صفحه بدون نمایش محتوای صفحه تغییر نکرده است.
زمان اصلاح فایل کش را با این خط تنظیم می کنیم: $ lastModified = filemtime ($ cache_file);
سپس با استفاده از زمان اصلاح فایل کش، هدر را ارسال می کنیم آخرین تغییر... ما باید آن را برای هر صفحه ای که ارائه می کنیم ارسال کنیم تا مرورگر مجبور شود برای ما هدر ارسال کند. If-Modified-Sinceبا هر درخواستی
// سرصفحه HTTP را دریافت کنید Last-Modified ("Last-Modified:". Gmdate ("D, d M Y H: i: s", $ lastModified). "GMT");\ n \ n "؛ پژواک"
\ n "؛ پژواک" \ n "؛ پژواک" \ n ";?>اگر آخرین رویکرد زمان اصلاح شده را با زمانی که از قبل در برنامه خود در دسترس است ترکیب کنید (به عنوان مثال، زمان آخرین مقاله خبری، یا مهلت زمانی حافظه پنهان سمت سرور که در آخرین راه حل دیدیم)، می توانید استفاده کنید. استفاده از کش مرورگر وب و تخلیه کانال انتقال داده، صرفه جویی در ترافیک اطلاعات از سایت شما و بهبود عملکرد آن در صورت امکان.
هنگام تست کردن هر کشی که به این سبک انجام می شود مراقب باشید، اگر این کار را اشتباه انجام دهید، می توانید بازدیدکنندگان خود را مجبور کنید همیشه کپی های قدیمی از سایت شما داشته باشند.
کش کردن صفحات خود در 5 مرحله
اصلی: ارسال شده در PHP / جاوا اسکریپت توسط ibzi در 17 فوریه 2007ترجمه: کوزما فسکوف ( [ایمیل محافظت شده]، http://kuzma.russofile.ru)
کش کردن صفحات شما می تواند مکانیزم خوب و مفیدی باشد، به خصوص اگر آنها با استفاده از PHP تولید شوند و پرس و جوهای SQL زیادی انجام دهند. به محض اعمال کش، سرور شما بلافاصله بار را کاهش می دهد و از مصرف حافظه زیادی برای تولید صفحات جلوگیری می کند - به سادگی آنها را از حافظه پنهان بارگذاری می کند. من به شما نشان خواهم داد که چگونه PHP می تواند صفحات را کش کند و در آینده می توانید حدود 5 دقیقه را روی آن صرف کنید.
بیایید نگاهی به فناوری کش در مراحل بیندازیم:
- فایل ها را در فهرست اصلی ایجاد کنید htaccess, start_cache.php, end_cache.phpو همچنین یک پوشه با نام cache_files.
- پوشه cache_filesلازم است که صفات را پایین بیاوریم 777 .
- داخل htaccessفایل خطوط زیر را بنویسید: php_value auto_prepend_file /home/username/public_html/start_cache.php php_value auto_append_file /home/username/public_html/end_cache.php خط / خانه / نام کاربری / public_html /باید با مسیر دایرکتوری خانه شما جایگزین شود.
- به فیلمنامه start_cache.phpکد زیر را قرار دهید:فراموش نکنید که مسیر را درست کنید / خانه / نام کاربری / public_html /به مسیر دایرکتوری خانه شما.
- کد زیر را در اسکریپت قرار دهید end_cache.php:
تمام صفحات شما به مدت 3600 ثانیه = 1 ساعت کش می شوند. شما به راحتی می توانید این پارامتر را در اسکریپت تغییر دهید. start_cache.php... کش صفحه در پوشه ذخیره می شود cache_files.
کاملاً بدیهی است که در این مورد صفات 777 یک نقض امنیتی قطعی هستند. در این رابطه توصیه می کنم پوشه را خارج کنید cahce_filesفراتر از مرزها public_htmlبه عنوان مثال، آن را یک سطح بالاتر قرار دهید. با این کار دسترسی کاربران سایت شما به فایل های موجود در آن بسته می شود اما به هیچ وجه بر عملکرد سیستم تاثیری نخواهد داشت.
همچنین این روش یک اشکال جدی دیگر نیز دارد: نویسنده مقاله کل کش را در یک پوشه قرار می دهد که با تعداد صفحات کافی در سایت شما مشکل ایجاد می کند، به عنوان مثال در سیستم های یونیکس به اندازه کافی وجود دارد. کاهش سرعت عملکرد زمانی که بیش از 1000 فایل در پوشه وجود دارد ... در این ارتباط باید یکسری تغییرات در الگوریتم اعمال شود و فایل ها در زیر پوشه های جداگانه داخل پوشه قرار بگیرند. cache_files... به عنوان مثال، از 3-4 کاراکتر اول کش md5 برای این کار استفاده کنید.
برای منابع پویا، انتخاب زمان کش چند (5-10) ثانیه یا 1-2 دقیقه کاملاً امکان پذیر است که بار روی سرور را به میزان قابل توجهی کاهش می دهد اما به تعامل سایت آسیب نمی رساند.
برای صفحاتی که تعامل برای آنها اهمیت ویژه ای دارد، می توانید استثناهایی را در آنها معرفی کنید htaccess، که به آنها اجازه می دهد دائماً تغییر کنند و برای بقیه صفحات می توانید کش را اعمال کنید.
بازسازی محتوا در لحظه
صفحاتی که به صورت پویا تولید می شوند اما به صورت ایستا ارائه می شوند. صفحاتی که باید صرفاً ثابت ارائه شوند (از سیستم فایل خوانده شده و سپس در صورت درخواست ارسال می شوند)، اما اگر در سیستم فایل وجود نداشته باشند باید به صورت پویا توسط وب سرور تولید شوند. به این ترتیب می‌توانید صفحات تولید شده با PHP داشته باشید که به صورت ایستا ارائه شوند، مگر اینکه کسی (یا زمان‌بندی‌کننده) محتوای ثابت را حذف کند. در این صورت محتوا به روز می شود.
این کار با مجموعه دستورالعمل های زیر انجام می شود:
RewriteCond% (REQUEST_FILENAME)! -S RewriteRule ^ page \ .html $ page.php
در اینجا، یک درخواست به page.html باعث می‌شود که page.php مربوطه به صورت داخلی اجرا شود، اگر page.html هنوز وجود نداشته باشد یا اندازه آن صفر باشد. ترفند اینجاست که page.php یک اسکریپت معمولی PHP است که علاوه بر خروجی خود، خروجی خود را در فایل page.html می نویسد. با اجرای این یک بار، سرور داده های page.html را ارسال می کند. هنگامی که یک مدیر وب می خواهد محتوا را به روز کند، به سادگی page.html را حذف می کند (معمولاً با یک cronjob).
مشکل کش کردن صفحه اینترنت اکسپلورر
اینترنت اکسپلورر هنگام کار با هدر "Vary" یک خطای مخرب در حافظه پنهان صفحه دارد. مشکل با اضافه کردن خطوط زیر به .htaccess حل می شود:
مشکل اصلی ذخیره سازی سرعت پاسخ به درخواست ها به سیستم های ذخیره سازی اصلی و پردازش اطلاعات ساختاری ورودی و خروجی است.
تصور کنید که شما نیاز به انتقال سریع اطلاعات دارید، اما سرعت دسترسی به داده ها بسیار کم است. یا وضعیت دیگری: سرعت خوب است، اما حافظه در دسترس کمی وجود دارد یا عرض کانال کافی نیست، یا عوامل پردازنده و دیسک در کار اختلال ایجاد می کنند. در این حالت، حافظه پنهان تنها راه خروج از وضعیت است.
انواع کش
ذخیره سازی (یا حافظه پنهان)نوعی بافر میانی است که داده ها در آن ذخیره می شود. به لطف ذخیره سازی، صفحه سایت برای هر کاربر دوباره ایجاد نمی شود. ذخیره سازی به شما این امکان را می دهد که در کمترین زمان ممکن و با منابع محدود (سرور و کاربر) با حجم زیادی از داده ها کار کنید.درک این نکته ضروری است که کار با داده ها هم در سمت مشتری و هم در سرور قابل انجام است. علاوه بر این، پردازش داده های سمت سرور متمرکز است و دارای تعدادی مزایای بدون شک (به ویژه برای خدمات پشتیبانی) است.
انواع مختلفی از کش وجود دارد، ما پیشنهاد می کنیم هر نوع، ویژگی ها و توصیه های آن را برای استفاده در نظر بگیریم:
1. کش مرورگر یا کش مشتری
در حال کامپایل کردن دستوری برای مرورگر است تا از یک نسخه کش موجود استفاده کند. کار چنین ذخیره‌سازی مبتنی بر این واقعیت است که در یک بازدید دوم، هدر 304 Not Modified به مرورگر بازگردانده می‌شود و خود صفحه یا تصویر از حافظه پنهان کاربر محلی بارگیری می‌شود. به نظر می رسد که در ترافیک بین مرورگر بازدیدکننده و میزبانی سایت صرفه جویی می کنید. بر این اساس، صفحه وب سایت شما سریعتر شروع به بارگذاری می کند.1.1 ذخیره فایل ها و تصاویر
حافظه پنهان مرورگر بهترین گزینه برای سایت هایی است که دارای تعداد زیادی تصویر هستند: هر بار که سایت را باز می کنید تصویر دانلود نمی شود، بلکه به سادگی از طریق کش مرورگر بارگیری می شود.
این اولین سطح ذخیره سازی است که شامل ارائه هدر است "منقضی شده"و عنوان "304 اصلاح نشده است"... ذخیره سازی به مدت 2 هفته موثرترین در نظر گرفته می شود.
با این حال، در این مورد یک تفاوت ظریف وجود دارد: اگر تصویر در سایت تغییر کند، مرورگر فوراً از آن مطلع نخواهد شد، اما فقط در صورتی که منتظر انقضا باشید یا حافظه پنهان را در خود مرورگر تنظیم مجدد کنید. اگر فایل دائماً در حال تغییر است و شما نیاز دارید که نسخه فعلی آن را دائماً سرویس دهید، خیلی مؤثر نیست.
1.2 ذخیره سازی https
سرصفحه های ویژه مانند امنیت شدید. به مرورگر اجازه می دهد همیشه از طریق https به دامنه انتخابی مراجعه کند. این حالت را نسبتاً سفت نگه می‌دارد و اگر این نوع حافظه پنهان لغو شود، مرورگر همچنان سعی می‌کند برای مدتی طولانی صفحه را از طریق https بارگیری کند، در حالی که هدرهای فعلی را نادیده می‌گیرد.1.3 ذخیره سازی مرجع گواهی
به اصطلاح مهر مرجع صدور گواهینامه.اگر نمی خواهید کاربران سایت شما منتظر یک مرجع صدور گواهینامه (و این سرور خاصی است که مسئول اعتبار گواهی شما است) برای پردازش درخواستی از مرورگر کاربر و تأیید اینکه سایت در واقع توسط آن تایید شده است.
1.4 ذخیره صفحه
هنگامی که صفحه قبلاً تولید شده است، باید پیوسته ارتباط آن را کنترل کنید. برای انجام این کار، باید از یک کش سمت سرور با ردیابی زمان تغییر بخش‌های جداگانه صفحه استفاده کنید (اگر صفحه از بسیاری از بلوک‌های تولید شده به صورت پویا ساخته شده باشد). با این رویکرد، در هر پاسخ از سرور، هدرهای ویژه ای تنظیم می شود که زمان تغییر صفحه را نشان می دهد که پس از دسترسی مجدد به صفحه سایت، توسط مرورگر کاربر ارسال می شود. هنگام دریافت چنین هدرهایی، سرور می تواند وضعیت فعلی صفحه را تجزیه و تحلیل کند (شاید حتی آن را رندر کند)، اما به جای محتوای صفحه، هدر را ارائه دهد. "304 اصلاح نشده است"، که برای مرورگر کاربر به این معنی است که امکان نمایش صفحه از کش (مرورگر کاربر) وجود دارد.البته امکان ارسال هدرهای مناسب بدون استفاده از کش ردیابی سمت سرور وجود دارد، اما در این صورت اکثر کاربران با تاخیر به روز رسانی محتوای صفحه را دریافت خواهند کرد. با این رویکرد، مرورگر گاهی اوقات از سرور برای به‌روزرسانی نظرسنجی می‌کند، اما فرکانس و قوانین هر مرورگر توسط توسعه‌دهنده آن پیکربندی می‌شود، بنابراین نیازی نیست امیدوار باشید که کاربران شما به‌روزرسانی‌ها را به موقع دریافت کنند.
به طور معمول، کش بر اساس نوع کاربر دسته بندی می شود:
این تقسیم بندی به دلیل منحصر به فرد بودن محتوا برای هر کاربر مجاز و کلی بودن محتوا برای کاربران مهمان است. در اکثر سایت ها، کاربر غیرمجاز نمی تواند محتوای سایت را تغییر دهد و در نتیجه بر محتوای آن تأثیر بگذارد.
کش مرورگر به شما امکان می دهد در ترافیک و زمان صرف شده برای بارگذاری صفحات صرفه جویی کنید. اما برای رسیدن به اثر صرفه جویی، کاربر باید حداقل یک بار از صفحه ما بازدید کند، به این معنی که بار روی منابع سرور کاهش می یابد، اما نه به میزان قابل توجهی.
2. کش سرور
حافظه نهان سرور به همه انواع کش که در آن داده ها در سمت سرور ذخیره می شود اشاره دارد. این داده ها برای مرورگرهای مشتری در دسترس نیست. کش بر اساس یک به چند ایجاد و ذخیره می شود (در این مورد بسیاری از دستگاه های مشتری هستند).
2.1 ذخیره کل صفحه
کارآمدترین کش چرا جالب است؟ بزرگترین مزیت آن این است که صفحه تقریباً در لحظه دسترسی بازگردانده می شود، در نتیجه امکان پردازش میلیون ها درخواست حتی در ضعیف ترین سرور با سرعت حافظه و با مصرف کم CPU وجود دارد.شاید کسی تا به حال رویای سایتی را دیده باشد که با سرعت "پینگ" یا سریعتر اجرا شود.
اما این نوع کش معایبی نیز دارد: به عنوان مثال، ناتوانی در کش کردن صفحات برای یک کاربر مجاز، یا برای کاربری که محتوای صفحه آن به متغیرهای کاربر فعلی بستگی دارد.
اگر سرور از تمام حالت های استاتیک داده های خارجی مانند: uri، get (بدون پارامترهای اضافی)، کاربر وارد نشده است، از این کش استفاده کنید - یعنی در واقع، این وضعیت صفحه ایده آل برای کاربران مهمان است. . به خاطر داشته باشید که با چنین ذخیره سازی، معماری یک سایت یا برنامه باید همیشه درخواست های دریافتی را به یک روش پردازش کند و نوع پاسخ های مشابهی را بدهد. چنین حالتی در هر برنامه یا سایتی وجود دارد، فقط باید ردیابی شود و در حافظه پنهان اعمال شود.
کش کردن کل صفحات اغلب در موارد اضطراری مورد استفاده قرار می گیرد، در حالی که حافظه پنهان صفحات برای مدت زمان از پیش تعیین شده (از 2 دقیقه) ذخیره می شود، که در طی آن پاسخ های سرور از یک نوع هستند (به مرورگر اجازه ندهید حافظه پنهان شود. این).
2.2 کش کردن نتایج کامپایل فایل های php
بین کامپایل خالص کد و بهینه سازی آن در حین کامپایل (جایگزینی اسکریپت ها) تفاوت قائل می شود. بارزترین نمونه ها:هر دو نوع کش را می توان در یک پروژه استفاده کرد، اما هر کدام تفاوت های ظریف خاص خود را دارند که باید هنگام نوشتن کد در نظر گرفته شوند.
2.3 ذخیره کردن تک تک بلوک های یک صفحه
این شاید جالب ترین و در عین حال سخت ترین نوع ذخیره سازی باشد. با این حال، همچنین می تواند موثر باشد، و ساده ترین راه برای توضیح اصول ذخیره سازی به طور کلی است.لازم است نظارت شود: وضعیت جداول، وضعیت جلسه کاربر، خاموش کردن کش در طول درخواست های POST یا GET (پرس و جو http)، وابستگی به آدرس فعلی، تداوم ذخیره سازی (در صورت تغییر شرایط قبلی) یا تنظیم دینامیکی آن
در صورت نیاز، به عنوان مثال، کاهش تعداد درخواست‌های کاربران واقعی (مجاز) به پایگاه داده، ذخیره کردن بلوک‌های صفحه جداگانه بهتر از سایر انواع ذخیره‌سازی است. به هر حال، با وابستگی‌های صحیح، حتی کارآمدتر از همه انواع ذخیره‌سازی بعدی کار خواهد کرد.
چرا این نوع ذخیره سازی اینقدر مهم است؟ مسئله این است که گسترش استخر سرورهای پایگاه داده بسیار دشوارتر از گسترش استخر سرور قسمت php سایت است. علاوه بر این، حل تعارض‌های حالت کش php بسیار آسان‌تر از تداخل با چندین پایگاه داده است.
2.4 کش کردن php بر اساس منابع اشتراک گذاری نشده
بهترین گزینه برای استانداردسازی درخواست ها، بازیابی داده ها از منابع مشترک، داشتن متغیرهای داخلی است که منابع php چندین بار در طول تولید صفحه به آنها دسترسی دارند.2.5 کش کردن php بر اساس منابع مشترک
از این کش برای ذخیره داده های سریالی استفاده کنید. به عنوان مثال: فایل پیکربندی، وضعیت جداول، لیست های سیستم فایل.2.6 ذخیره سازی mysql بر اساس کش کوئری
این یک موضوع نسبتاً شناخته شده و پر پوشش است. با این وجود، من می‌خواهم ویژگی‌های کار با برچسب زمانی را در نظر بگیرم و اینکه چگونه می‌توانید از شستشوی مداوم حافظه پنهان کوئری جلوگیری کنید.مطمئناً شما مرتباً با موقعیتی روبرو می شوید که نیاز به ارائه مطالب جدید دارید که تاریخ انتشار آن قبلاً توسط مهر زمانی فعلی مجاز است؟ به زبان ساده،
WHERE show_ts<=UNIX_TIMESTAMP()
اگر از یک مهر زمانی دائماً در حال تغییر در چنین پرس و جوهایی استفاده می کنید، کش sql نه تنها بی فایده، بلکه حتی مضر خواهد بود، زیرا تعداد کوئری های ذخیره شده در حافظه پنهان جمع می شود که داده های آنها در زمان ایجاد کش قدیمی است.
ما راه حل زیر را برای خروج از وضعیت ارائه می دهیم:
به عنوان یک قاعده، هر مطلبی در مقاطع خاصی از زمان منتشر می شود. به عنوان مثال، 00:00. تنها کاری که باید انجام دهید این است که یک پرس و جو ایجاد کنید که جدول را با حداکثر تاریخ ارزیابی کند، در حالی که کمتر از تاریخ فعلی است.
چیزی مثل:
SQL_NO_CACHE MAX (show_ts) را انتخاب کنید... WHERE show_ts<=UNIX_TIMESTAMP();
بله، این پرس و جو ذخیره نمی شود، اما تمام پرس و جوهای این جدول در صورتی که تعداد آنها بیش از یک باشد، در حافظه پنهان ذخیره می شوند. این عملیات ساده عمر کش sql را تا حد زیادی بهبود می بخشد.
اگر تعداد خوانده‌های جدول کمی بیشتر از رکوردها باشد، ذخیره کردن این پرسش‌ها منطقی است.
2.7 ذخیره خروجی mysql، جمع آوری جداول
یک قانون وجود دارد: برای بازگرداندن آنها باید به‌روزرسانی‌های داده به میزان قابل توجهی کمتر از خواندن‌ها باشد.یعنی جمع آوری آنچه در همان لحظه تغییر خواهد کرد معنی ندارد، در حالی که ارتباط داده های جمع آوری شده مهم است.
برای تجمیع چه چیزی را انتخاب کنیم؟ معمولاً این نوعی اطلاعات آماری در مورد تعداد رکوردها، تاریخ آخرین به روز رسانی، نویسنده آخرین به روز رسانی و موارد مشابه است.
نتیجه
با توجه به بار ثابت شبکه، نمی توانید هیچ پروژه ای را بدون کش ایجاد کنید. Caching این امکان را فراهم می کند که داده ها را با حداقل منابع به دایره بزرگی از مشتریان تحویل دهید. در این مقاله انواع زیادی از کش را بررسی کردیم که مطمئن هستیم راه حل مناسبی برای پروژه شما وجود خواهد داشت.برای بهینه سازی کار با شبکه، مکانیزمی برای ذخیره اسناد پس از دریافت از طریق HTTP در حافظه پنهان با هدف استفاده مجدد از آنها بدون تماس با سرور منبع استفاده می شود. سند ذخیره شده در حافظه نهان، دفعه بعد که به آن دسترسی پیدا می کند، بدون بارگیری از سرور منبع، که برای افزایش سرعت دسترسی مشتری به آن و کاهش مصرف ترافیک شبکه طراحی شده است، در دسترس خواهد بود.
خود کش ها دو نوع هستند - محلی و اشتراکی. Local یک کش است که مستقیماً روی دیسک در مشتری ذخیره می شود و توسط مرورگر او ایجاد و مدیریت می شود. Shared یک حافظه پنهان از سرور پروکسی یک سازمان یا ارائه دهنده است و می تواند از یک یا چند سرور پراکسی تشکیل شده باشد. حافظه پنهان محلی احتمالاً در هر مرورگر وجود دارد؛ بخش قابل توجهی از افرادی که از اینترنت استفاده می کنند از یک کش معمولی استفاده می کنند. و اگر اکنون بخش کوچکی از سایت ها بر اساس میزان مصرف ترافیک ارزیابی می شوند، سرعت دانلود معیار مهمی است که باید هنگام توسعه پروژه وب خود در نظر گرفته شود.
به نظر می رسد که کش برای صفحات پویا ایجاد شده در نتیجه یک برنامه PHP مضر است. محتوای صفحه به درخواست کاربر بر اساس منبع داده تولید می شود. با این حال، کش می تواند مفید باشد. با مدیریت آن، می توانید کار با سرور خود را برای کاربر راحت تر کنید و اجازه بارگذاری صفحات خاصی از حافظه پنهان را بدهید و در نتیجه از بارگذاری مجدد آنها از سرور خود جلوگیری کنید و در زمان و ترافیک کاربر صرفه جویی کنید.
کش کنم یا نه؟
توانایی کش کردن یک صفحه با پویایی اطلاعات موجود در منبع داده تعیین می شود. بنابراین، نیاز به استفاده از کش توسط شما بر اساس طول عمر صفحه برنامه ریزی شده تعیین می شود.
اگر ما در مورد تشکیل یک انتخاب با توجه به پایگاه داده صحبت می کنیم (به عنوان مثال، جستجوی کلمه ای که کاربر وارد کرده است)، پس با هر تماس بدون استفاده از حافظه نهان، چنین صفحه ای باید از سرور درخواست شود، زیرا تعداد گزینه ها برای کلمات درخواستی بسیار زیاد است و اگر با تغییر آرایه داده ها نیز سر و کار داریم، کش کردن بی معنی است. یا در مورد تشکیل، مثلاً، برنامه ای از بازدیدکنندگان ورودی صحبت می کنیم (که با هر بازدید، یعنی تقریباً با هر تماس تغییر می کند)، پس ذخیره سازی در حال حاضر به سادگی مضر است.
با این حال، اگر در مورد همان زمان‌بندی صحبت می‌کنیم، اما برای دیروز، ذخیره کردن در حافظه پنهان توصیه می‌شود، زیرا داده‌ها دیگر تغییر نمی‌کنند و می‌توانیم با قرار دادن آنها در حافظه پنهان محلی یا اشتراکی، منابع و زمان خود و کاربر را برای بارگیری چنین صفحاتی ذخیره کنیم. . در ادامه این وضعیت، شکل گیری نمودار به صورت لحظه ای نیست، بلکه ساعتی است. در اینجا می توانید تاریخ انقضای "تاریخ انقضا" داده های تولید شده را از قبل پیش بینی کنید.
اصول کلی ذخیره صفحات در کش
یک برنامه PHP می تواند با ایجاد فیلدهای اضافی در سربرگ پاسخ HTTP با فراخوانی تابع Header () ذخیره نتایج کار خود را کنترل کند.
چند عبارت کلی که مختص برنامه های PHP نیستند:
- صفحات POST هرگز کش نمی شوند.
- صفحات درخواست شده توسط GET و حاوی پارامترهای ("؟" در URL موجود است) در حافظه پنهان ذخیره نمی شوند مگر اینکه طور دیگری مشخص شده باشد.
بنابراین در بیشتر مواقع نیازی به افزودن دستورالعمل های اضافی به برنامه نیست. نکات اصلی که باید به آنها توجه کنید را می توان در دو مورد خلاصه کرد:
- ذخیره اسناد ذخیره شده در حافظه پنهان به طور پیش فرض ممنوع است
- کش کردن اسنادی که به طور پیش فرض کش نیستند.
از کش کردن اسناد ذخیره شده به طور پیش فرض جلوگیری کنید
این وظیفه برای اسکریپت‌های PHP که بدون پارامتر نامیده می‌شوند یا فهرست‌های دایرکتوری‌ها هستند، ایجاد می‌شود، با این حال، داده‌ها را شخصاً برای کاربر تولید می‌کنند (مثلاً بر اساس کوکی‌ها یا یک عامل کاربر) یا بر اساس داده‌های به سرعت در حال تغییر کار می‌کنند. با توجه به مشخصات HTTP / 1.1، می توانیم فیلدهای زیر را کنترل کنیم:
منقضی می شود
تاریخ انقضای سند را مشخص می کند. تنظیم آن در گذشته ممنوعیت کش برای این صفحه را تعیین می کند.
Cache-Control: بدون کش
مدیریت کش مقدار no-cache عدم مجاز بودن حافظه پنهان را برای این صفحه مشخص می کند. برای نسخه پروتکل HTTP / 1.0، "Pragma: no-cache" در حال اجرا است.
آخرین تغییر
تاریخ آخرین تغییر محتوا این فیلد فقط برای صفحات استاتیک مرتبط است. آپاچی این فیلد را با مقدار فیلد Date برای صفحاتی که به صورت پویا تولید می شوند، از جمله صفحات حاوی SSI جایگزین می کند.
سایت www.php.net کد زیر را برای غیرفعال کردن کش ارائه می دهد.
سربرگ ("انقضا: دوشنبه، 26 ژوئیه 1997، 05:00:00 GMT")؛ // تاریخ در گذشته
هدر ("آخرین تغییر:". gmdate ("D, d M Y H: i: s"). "GMT"); // همیشه اصلاح می شود
هدر ("Cache-Control: no-cache, must-revalidate"); // HTTP / 1.1
هدر ("Pragma: no-cache")؛ // HTTP / 1.0
با این حال، این هدر اضافی است. در بیشتر موارد کافی است:
برای علامت گذاری سند به عنوان "از قبل منسوخ" Expires را برابر با قسمت تاریخ تنظیم کنید.
هدر ("انقضا:". gmdate ("D, d M Y H: i: s"). "GMT");
همچنین، به خاطر داشته باشید که فرم های درخواستی POST نیز مشمول ذخیره سازی نیستند.
ذخیره سازی اسنادی که به طور پیش فرض کش نیستند
مشکل معکوس ممکن است در نگاه اول پوچ به نظر برسد. با این حال، نیاز به این نیز وجود دارد. علاوه بر به حداقل رساندن ترافیک، هنگام توسعه یک برنامه وب، باید راحتی کاربر را در کار با آن در نظر بگیرید. به عنوان مثال، برخی از صفحات روی سرور شما بر اساس داده های ثابت بزرگ تولید می شوند. امکان گنجاندن آنها در حافظه نهان به طور قابل توجهی سرعت سرور را برای کاربر بهبود می بخشد و تا حدی شما را از نسل های تکراری متعدد چنین صفحه ای آزاد می کند. هدر که امکان ذخیره در سرورهای پروکسی را فراهم می کند:
مقاله مرتبط: ارتقاء موتور جستجوی فروشگاه آنلاین در Yandex و Google: چک لیست ممیزی عوامل رتبه بندی
اگر صفحه اطلاعات ذخیره شده در مرورگر کاربر (نوع و نسخه مرورگر، کلیدها، مجوز و غیره) را در نظر بگیرد، چنین صفحه ای را نمی توان در پروکسی ذخیره کرد، اما می توان آن را در حافظه پنهان مرورگر محلی ذخیره کرد:
هدر ("Cache-Control: private")؛
ذخیره تا پایان اعتبار
راه حل های توضیح داده شده در بالا نسبتاً ساده هستند، اگرچه برای اکثر وظایف مناسب هستند. اما پروتکل HTTP / 1.1 دارای امکاناتی برای کنترل دقیق تر کش صفحه است و کارهایی وجود دارد که نیاز به استفاده از این مکانیسم ها دارد. به عنوان مثال - برنامه های کاربردی وب که با داده های بزرگ و پویایی قابل پیش بینی کار می کنند. صحت داده ها را می توان هم با تاریخ به روز رسانی پیش بینی شده و هم با تغییر در محتوا مشخص کرد. هدرهای کنترل کش مختلف برای این موارد استفاده می شود.
ذخیره سازی به روز رسانی پیش بینی شده
یک مثال را در نظر بگیرید - لیست قیمتی که دوشنبه ها به روز می شود. از قبل می دانید که محتوای صفحه را می توان تا هفته بعد در کش ذخیره کرد که باید در سربرگ پاسخ مشخص شود تا از رفتار مطلوب صفحه در کش اطمینان حاصل شود.
وظیفه اصلی دریافت تاریخ دوشنبه آینده در قالب RFC-1123 است
$ dt_tmp = getdate (تاریخ ("U"));
سربرگ ("انقضا:". gmdate ("D, d M Y H: i: s"، تاریخ ("U") - (86400 * ($ dt_tmp ["wday"] - 8))). "GMT");
هدر ("Cache-Control: public")؛
این روش می تواند به طور موثر رفتار صفحه را در حافظه پنهان کنترل کند و برای تعداد زیادی از صفحات مفید است - به هر حال، می توانید فواصل زمانی را اختصاص دهید که در طی آن محتوای صفحه ثابت می ماند. واقعیت این است که صفحات اکثر سایت های پویا دارای طول عمر مشخصی هستند که بر اساس آن توسعه دهنده می تواند سرور را برای کار با آن دلپذیرتر کند.
روش دیگری که برای به‌روزرسانی سریعتر اطلاعات و ترافیک بالای سرور به طور همزمان مورد استفاده قرار می‌گیرد (در غیر این صورت کش کردن مؤثر نخواهد بود) استفاده از Cache-control: max-age = seconds header است که مدت زمانی را که سند منسوخ در نظر گرفته می‌شود و تعیین می‌کند. هنگام محاسبه "تازه بودن" سند از اولویت بیشتری برخوردار است.
