محلّل التخزين المؤقت في HTTP

كيف تقرر المتصفحات وشبكات CDN مدة تخزين الصفحة مؤقتاً؟

تقرأ كل ذاكرة ترويسات الاستجابة: فـ max-age في Cache-Control تحدد العمر لكل الذاكرات، وتتقدّم عليها s-maxage أو ترويسة خاصة بـ CDN في الذاكرات المشتركة، ويمنع no-store التخزين، ويُبقي private النسخة في المتصفح وحده. وحين ينتهي العمر تتيح ETag أو Last-Modified للذاكرة إعادة التحقق بطلب شرطي رخيص بدلاً من تنزيل الصفحة من جديد. وتطبّق شبكة CDN هذه السياسة في كل موقع طرفي على حدة، ولذلك تختلف حالة ذاكرتها وقيمة Age من زائر إلى آخر.

ملاحظة أمنية: الاستجابة التي تضبط ملف تعريف ارتباط أو تعرض بيانات شخصية يجب أن تكون private أو no-store؛ فإن خزّنتها ذاكرة مشتركة فقد يتلقى الزائر التالي صفحة شخص آخر.

كيفية استخدام محلّل التخزين المؤقت في HTTP

1. أدخل عنوان صفحة أو ملف أو استجابة API — أو الصق ترويسات الاستجابة في الحقل الثاني.
2. فعّل «اطلب مرتين لمراقبة ذاكرة الحافة» إن أردت أن ترى هل تخزّن شبكة CDN الاستجابة.
3. اضغط «حلّل التخزين المؤقت» واقرأ سياسة التخزين: الحكم، وعمر النسخة في المتصفح وفي الذاكرة المشتركة، وطريقة إعادة التحقق.
4. عالج الملاحظات، وقارن ترويسات CDN في الطلبين، وكيّف السياسة المقترحة على الخادم أو في CDN.

مزايا محلّل التخزين المؤقت في HTTP

• يجلب العنوان عبر خادم متقن ولا يقرأ منه إلا ترويسات الاستجابة، أو يحلّل ترويسات تلصقها (استجابة خام أو مخرجات curl -I أو أسطر "Name: value") دون إرسال أي شيء
• يصوغ سياسة التخزين المؤقت بكلمات واضحة: هل يحق للمتصفحات والذاكرات المشتركة تخزين الاستجابة، ولكم من الوقت لكل منهما، وكيف يُعاد التحقق من النسخة القديمة
• يشرح كل توجيه في Cache-Control — max-age وs-maxage وpublic وprivate وno-cache وno-store وmust-revalidate وimmutable وstale-while-revalidate وغيرها
• يقرأ ETag وLast-Modified، وExpires وDate، وAge وVary، وترويسات CDN مثل CF-Cache-Status وX-Cache وX-Served-By وCDN-Cache-Control وSurrogate-Control
• ينبّه إلى أخطاء السياسة: استجابة تضبط ملف تعريف ارتباط ويحق للذاكرات المشتركة تخزينها، وتوجيهات متناقضة، وتواريخ غير صالحة، وVary على Cookie أو User-Agent، واستجابة مضغوطة بلا Vary: Accept-Encoding، وغياب أداة التحقق
• يطلب العنوان مرة ثانية عند الطلب ليُظهر هل خزّنت النقطة الطرفية التي أجابت الاستجابةَ بين الطلبين
• يقترح سياسة بداية تناسب نوع الاستجابة، لتكييفها لا لنسخها كما هي

المدخلات والمخرجات

المدخلات

• العنوان المراد تحليله — أي عنوان عام يبدأ بـ http:// أو https://؛ ويُضاف https:// إلى اسم المضيف المجرد.
• أو الصق ترويسات الاستجابة — تُحلَّل في المتصفح وتحلّ محل العنوان؛ وسطر الحالة اختياري (يُفترض 200 عند غيابه).
• اطلب مرتين لمراقبة ذاكرة الحافة — غير مفعّل افتراضياً؛ يرسل طلباً إضافياً إلى العنوان النهائي.

المخرجات

• الملخص — الحكم، وعمر النسخة في المتصفح وفي الذاكرة المشتركة، وAge، وأدوات التحقق الموجودة، ورمز حالة HTTP.
• سياسة التخزين — الحكم في جملة، وسلوك ذاكرة المتصفح والذاكرة المشتركة، ومصدر العمر، وإعادة التحقق، وVary، والعنوان الذي قيس.
• توجيهات Cache-Control والملاحظات وترويسات CDN والوكلاء — كلٌّ مع معناه؛ ويمكن تنزيل الملاحظات بصيغة CSV.
• مقارنة الطلبين وما يُظهره الطلب الثاني — حين يُطلب الطلب الثاني.
• سياسة بداية مقترحة — ترويسات مثال تناسب هذا النوع من الاستجابات.

مثال على محلّل التخزين المؤقت في HTTP

العنوان المراد تحليله: https://shop.example.com/ · اطلب مرتين لمراقبة ذاكرة الحافة: مفعّل

Verdict Cacheable · Browser lifetime 5 minutes · Shared-cache lifetime 1 hour · Validators ETag · HTTP status 200
Verdict: Cacheable: browsers may reuse it for 5 minutes and shared caches for 1 hour.
Revalidation: Conditional request with If-None-Match: W/"5f8d-1a2b3c"
Warning (Vary): Vary on Cookie splits the cache into a variant per value, so few requests are served from it.
cf-cache-status MISS → HIT; age — → 2
The edge that answered stored the response: the first request was MISS and the second a HIT.

كيف تقرأ نتائج محلّل التخزين المؤقت في HTTP

حكم «قابل للتخزين» مع عمرين يعني أن المتصفحات والذاكرات المشتركة تحتفظ بالنسخة لمدد مختلفة: فـ s-maxage أو ترويسة خاصة بـ CDN تتيح لشبكة CDN إبقاء الصفحة مدة أطول من المتصفحات التي تعود فتسأل CDN.

no-cache لا يعني «غير مخزّن»: النسخة تُخزَّن ويُتحقق منها قبل كل استخدام، وهذا رخيص مع ETag (فالرد 304 بلا محتوى). والتوجيه الذي يمنع التخزين هو no-store.

المشكلة المتعلقة بملفات تعريف الارتباط أو المصادقة هي أول ما يُصلح: فالذاكرة المشتركة التي تخزّن استجابة موجّهة لشخص واحد قد تقدّمها للزائر التالي.

حالة CDN وقيمة Age تصفان النقطة الطرفية التي أجابت خادم متقن في تلك اللحظة. وMISS يتبعه HIT يعني أن تلك النقطة خزّنت الاستجابة، والنقاط الأخرى تملأ ذاكرتها كلٌّ على حدة.

متى تستخدم محلّل التخزين المؤقت في HTTP

• قبل الإطلاق، تحقق من أن الملفات ذات الإصدارات تُخزَّن مدة طويلة، وأن صفحات HTML تُخزَّن لمدة قصيرة أو مع إعادة التحقق.
• اعرف لماذا تُخفق شبكة CDN في كل مرة: ابحث عن no-store أو private أو Set-Cookie أو Vary على Cookie أو حالة BYPASS أو DYNAMIC.
• تأكد أن الصفحات التي تحمل بيانات شخصية private أو no-store ولا تخزّنها الذاكرات المشتركة أبداً.
• راجع ترويسات منسوخة من اختبار حمل أو من أدوات المطوّر في المتصفح أو من curl -I بلصقها، دون جلب أي شيء.

استكشاف الأخطاء وإصلاحها

• الحكم «تقديري» (Heuristic): الاستجابة لا تضبط Cache-Control ولا Expires، فتختار كل ذاكرة عمرها بنفسها. اضبط سياسة صريحة ليصبح التخزين متوقعاً.
• الطلب الثاني ما زال MISS: قد لا تكون الاستجابة قابلة للتخزين على الحافة (ملفات تعريف ارتباط، أو private، أو قاعدة BYPASS)، أو وصل الطلبان إلى عقدتين مختلفتين. أعد التشغيل وراجع قواعد التخزين في CDN.
• الترويسات تختلف عما يعرضه متصفحك: خادم متقن لا يرسل ملفات تعريف ارتباط ويستخدم User-Agent ثابتاً، فالموقع الذي يغيّر ردّه بحسب تسجيل الدخول أو الجهاز أو البلد قد يجيبه بشكل مختلف. الصق الترويسات من لوحة الشبكة في متصفحك لتحليلها بدلاً من ذلك.
• رفض برسالة مثل «This address cannot be reached from the Mutqan server»: العناوين الخاصة والمحجوزة والمحظورة لا تُطلب أبداً. الصق الترويسات إن كان النظام داخلياً.

الأسئلة الشائعة حول محلّل التخزين المؤقت في HTTP

ملاحظات تقنية

يعرّف RFC 9111 التخزين المؤقت في HTTP: توجيهات Cache-Control تحدد هل يمكن تخزين الاستجابة ولكم من الوقت (max-age لكل الذاكرات، وs-maxage للمشتركة منها، وExpires ناقص Date عند غياب max-age)، وتحمل Age تقدير الذاكرة للوقت الذي مضى منذ ولّد الخادم الأصلي النسخة أو أعاد التحقق منها (القسم 5.1 من RFC 9111)، وتتيح ETag أو Last-Modified إعادة التحقق من النسخة القديمة بطلب شرطي يُجاب بالرمز 304 Not Modified. ويأتي التوجيه immutable من RFC 8246، والتوجيهان stale-while-revalidate وstale-if-error من RFC 5861.

في وضع العنوان يُرسل طلب GET واحد عبر POST /api/v1/internet/http/fetch بمجموعة ترويسات ثابتة؛ وتُتبع عمليات إعادة التوجيه وتُحلَّل الاستجابة النهائية، مع حصر المحتوى في بايت واحد لأن المهم هو الترويسات فقط. ويذهب الطلب الثاني إلى العنوان النهائي دون اتباع إعادة التوجيه.

ترويسات حالة CDN أعراف خاصة بكل مزوّد لا معايير: CF-Cache-Status خاصة بـ Cloudflare (HIT وMISS وEXPIRED وBYPASS وDYNAMIC وغيرها)، وX-Cache تستخدمها عدة شبكات CDN ووكلاء، وCDN-Cache-Control أو Surrogate-Control تستهدفان طبقة CDN وحدها.

الحدود ومنهجية القياس

يُطلب العنوان من خادم متقن على شبكة Cloudflare؛ فحالة CDN وAge تصفان النقطة الطرفية التي أجابت ذلك الطلب، وقد تختلف عن أقرب نقطة إلى الزائر.

لا يقرأ التحليل إلا ترويسات الاستجابة؛ فلا يرى ذاكرة المتصفح ولا ذاكرة عامل الخدمة، ولا قواعد CDN التي تتجاوز الترويسات، ولا المدة الحقيقية التي تبقى فيها النسخة قبل حذفها.

لا تحمل الطلبات ملفات تعريف ارتباط ولا بيانات اعتماد، فلا يُرصد التخزين الذي يتوقف على جلسة مسجّلة.

الأمان والخصوصية

الترويسات الملصوقة لا تغادر متصفحك أبداً. وفي وضع العنوان يتسلّم خادم متقن العنوان، ويطلبه مرة واحدة (ومرتين عند الطلب) بترويسات ثابتة دون أي من ملفات تعريف الارتباط الخاصة بك، ولا يخزّن شيئاً؛ ولا تُعاد إلا ترويسات الاستجابة.

المراجع

• RFC 9111: HTTP CachingIETF · 2022كيف تحدد Cache-Control وExpires وETag والمتحقِّقات ما إذا كان يمكن تخزين الاستجابة وإعادة استخدامها.
• HTTP caching — MDNMDN Web Docs (Mozilla)التخزين المؤقت الخاص مقابل المشترك، والحداثة، والتحقق عبر ETag / Last-Modified، وأنماط Cache-Control الشائعة.
• Prevent unnecessary network requests with the HTTP Cacheweb.dev (Google)دليل عملي لـ Cache-Control: max-age طويلة مع عناوين ذات إصدارات، وno-cache مع ETag لصفحات HTML، وprivate للبيانات الشخصية، وكيف تعيد المتصفحات التحقق.