التخزين المؤقت HTTPHTTP Caching طريقة التحقق الشرطي ETag وكود 304، وفحص حالة الكاش في المتصفح، ومفهوم التخزين المؤقت في HTTP

بعد أن تعرّفنا في الدروس السابقة على آليات المصادقة وإدارة الجلسات، يبرز سؤال هندسي جوهري: هل يعقل أن يعيد المتصفح تنزيل شعار الموقع وملفات التنسيق والخطوط من الخادم الأصلي في كل مرة ينتقل فيها المستخدم من صفحة إلى أخرى؟ هنا يأتي دور التخزين المؤقت في HTTP (HTTP Caching الموثق في المعيار RFC 9111‏)، وهو الآلية التي تحتفظ بنسخ صالحة لإعادة الاستخدام من استجابات الخادم داخل ذاكرة المتصفح أو الخوادم الوسيطة لتقديمها فوراً دون استهلاك الشبكة من جديد.

قبل الغوص في التفاصيل الهندسية، استعرض جدول المصطلحات التقنية الأساسية لهذا الدرس:

تعتمد دورة عمل الكاش في بروتوكول HTTP على البحث عن استجابة محفوظة تطابق طريقة الطلب والرابط (وخاصة طلبات GET‏):

• عدم وجود نسخة في الكاش (Cache Miss — الزيارة الأولى): يطلب المتصفح الملف /assets/logo.svg، فلا يجده في ذاكرته، فيرسله إلى الخادم الأصلي ويستلم الرد 200 OK مرفقاً بحقول رأس التحكم بالكاش، فيعرضه ويحفظ نسخة منه.
• إصابة الكاش بنجاح (Cache Hit — الزيارات التالية): عند الانتقال لصفحة أخرى تطلب الشعار نفسه، يجد المتصفح النسخة الصالحة في ذاكرته المحلية فيعرضها خلال أجزاء من المللي ثانية دون إرسال أي حزمة عبر الشبكة.

لاحظ في المثال الآتي كيف يرفق الخادم الأصلي قواعد التخزين المؤقت داخل رؤوس الرسالة:

• HTTP/1.1 200 OK
• Date: Thu, 05 Nov 2026 10:00:00 GMT
• Content-Type: image/svg+xml
• Content-Length: 4120
• Cache-Control: public, max-age=86400
• ETag: "v2-8f9d1a"
• <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 30">...</svg>

يحقق تطبيق سياسة تخزين مؤقت دقيقة أربع فوائد هندسية ملموسة على مستوى الشبكة والخادم وتجربة المستخدم:

1. 1. إلغاء زمن تأخير الشبكة وتسريع العرض (Zero Network Latency‏): عندما تُقرأ الملفات مباشرة من ذاكرة المتصفح، يتجاوز الموقع زمن رحلة الحزم عبر الشبكة بالكامل، مما يرفع مؤشرات سرعة الصفحة مثل Largest Contentful Paint (LCP).
2. 2. توفير استهلاك البيانات وعرض النطاق (Bandwidth Savings‏): يمنع الكاش إعادة تنزيل الخطوط والصور والملفات الثابتة ذات الأحجام الكبيرة في كل صفحة، مما يوفر باقات الإنترنت لمستخدمي الهواتف ويقلل فاتورة نقل البيانات على الخادم.
3. 3. تخفيف العبء عن الخادم الأصلي وقاعدة البيانات (Origin Offloading‏): كل طلب يلبيه الكاش المحلي أو خادم CDN يزيل عبء معالجة طلب كامل عن وحدة المعالجة المركزية وقاعدة البيانات في الخادم الأصلي، مما يحمي الموقع من الانهيار أوقات الذروة.
4. 4. تعزيز استقرار الخدمة عند تذبذب الشبكة (Resilience‏): تتيح النسخ المخزنة استمرار عمل الواجهة الرسومية بسلاسة حتى لو واجه الاتصال بالخادم الأصلي بطئاً لحظياً.

يصنف المعيار القياسي RFC 9111 ذواكر التخزين المؤقت في الويب إلى فئتين معماريتين رئيسيتين بحسب نطاق الوصول إلى النسخ المحفوظة:

• 1. الكاش الخاص (Private Cache — ذاكرة المتصفح): مخصص لمستخدم واحد فقط ويعمل داخل متصفحه الشخصي (في الذاكرة العشوائية Memory Cache أو القرص Disk Cache‏). يُضبط عبر التوجيه Cache-Control: private، ويصلح لحفظ الموارد المرتبطة بحساب المستخدم نفسه دون مشاركتها مع غيره.
• 2. الكاش المشترك (Shared Cache — الخوادم الوسيطة وشبكات CDN‏): يقع في منتصف الطريق بين المستخدمين والخادم الأصلي (مثل الخوادم العكسية Reverse Proxies وعقد شبكات CDN‏). النسخة الواحدة المخزنة فيه بتوجيه Cache-Control: public تُقدَّم لآلاف الزوار المختلفين حول العالم؛ ولذلك يُمنع منعاً باتاً تخزين أي بيانات شخصية فيه.

تأمل المخطط المعماري الآتي الذي يقارن بين مسار الكاش الخاص والكاش المشترك وحالات الصلاحية:

• Cache-Control: private, max-age=600
• Cache-Control: public, max-age=86400, s-maxage=604800

تمر كل نسخة محفوظة داخل الكاش بحالتين زمنيتين تحددهما معادلة عمر النسخة الحالي (Age‏) مقابل مدة الصلاحية الكلية (Freshness Lifetime‏):

• حالة النسخة الطازجة (Fresh‏): عندما يكون الوقت المنقضي منذ إصدار الاستجابة أقل من مدة الصلاحية المحددة (مثلاً max-age=3600 ثانية ولم يمر سوى 500 ثانية). هنا يستخدمها المتصفح فوراً دون أي اتصال بالخادم.
• حالة النسخة المنتهية (Stale‏): عندما يتجاوز عمر النسخة مدة الصلاحية. من المهم معرفة أن المتصفح لا يحذف النسخة المنتهية فوراً، بل يحتفظ بها في الذاكرة ويرسل طلباً شرطياً صغيراً لسؤال الخادم إن كانت لا تزال صالحة.

يحسب المتصفح والخادم الوسيط زمن الصلاحية عبر حقول الرأس القياسية الآتية (حيث تتفوق تعليمة max-age دائماً على حقل Expires القديم عند وجودهما معاً):

• HTTP/1.1 200 OK
• Date: Thu, 05 Nov 2026 12:00:00 GMT
• Cache-Control: public, max-age=3600
• Expires: Thu, 05 Nov 2026 13:00:00 GMT
• Age: 1200

يُعدّ حقل الرأس Cache-Control مركز القيادة الرئيسي للتخزين المؤقت في HTTP؛ إذ يقبل مجموعة من التوجيهات (Directives‏) المفصولة بفواصل لضبط السياسة بدقة:

• التوجيه max-age=N: يحدد عدد الثواني التي تظل فيها النسخة صالحة (Fresh‏) بدءاً من وقت إصدار الاستجابة.
• التوجيه s-maxage=N: يحدد مدة صلاحية خاصة بالكاش المشترك (Shared Caches / CDN‏) تتجاوز قيمة max-age العادية.
• التوجيهان public وprivate: يسمح public بتخزين النسخة في كلٍّ من المتصفح وشبكات CDN، بينما يحصر private التخزين داخل متصفح المستخدم وحده.
• التوجيه must-revalidate: يلزم الكاش بعدم استخدام النسخة بعد انتهاء صلاحيتها (Stale‏) إلا بعد نجاح التحقق الشرطي من الخادم الأصلي.
• التوجيه immutable: يخبر المتصفح أن هذا الملف ثابت ولن يتغير أبداً طوال مدة صلاحيته، مما يمنع المتصفح من إرسال طلبات تحقق شرطية حتى لو ضغط المستخدم زر تحديث الصفحة.

من أكثر الأخطاء شيوعاً في هندسة الويب الخلط بين التوجيهين no-cache وno-store؛ فبرغم تقارب الاسمين، يختلف سلوكهما الفعلي اختلافاً جذرياً:

• التوجيه Cache-Control: no-cache (خزّن النسخة ولكن تحقق من الخادم قبل كل استخدام): على عكس ما يوحي به اسمه الحرفي، فإن no-cache يسمح للمتصفح بحفظ النسخة في الكاش! لكنه يشترط عدم عرضها للمستخدم في أي زيارة تالية إلا بعد إرسال طلب تحقق شرطي سريع للخادم الأصلي للتأكد من عدم تغيرها. وهو مثالي لصفحات HTML المتجددة.
• التوجيه Cache-Control: no-store (منع التخزين تماماً في أي ذاكرة): يمنع المتصفح وجميع الخوادم الوسيطة منعاً قاطعاً من كتابة أي بايت من الاستجابة في القرص أو الكاش. وهو الخيار الإلزامي للبيانات شديدة الحساسية مثل كشوف الحسابات البنكية ورموز الاسترداد السرية.

جرّب المختبر التفاعلي الآتي لمقارنة سلوك المتصفح مع التوجيهات الأربعة على السلك:

ماذا يحدث عندما تنتهي مدة صلاحية ملف مخزن في الكاش ويصبح في حالة Stale؟ بدلاً من إعادة تنزيل الملف بالكامل وإهدار البيانات، ينفذ المتصفح عملية التحقق الشرطي (Conditional Revalidation‏) باستخدام ثنائيات التحقق:

1. 1. التحقق ببصمة الكيان (ETag → If-None-Match — الأدق والأحدث): يرسل الخادم مع الملف في المرة الأولى حقل الرأس ETag: "v2-8f9d1a" الذي يمثل بصمة فريدة لمحتوى الملف. وعند انتهاء الصلاحية، يرسل المتصفح طلب GET مرفقاً بحقل الرأس الشرطي If-None-Match: "v2-8f9d1a".
2. 2. التحقق بتاريخ آخر تعديل (Last-Modified → If-Modified-Since‏): يرسل الخادم تاريخ آخر تعديل للملف، فيعيد المتصفح إرساله في حقل الرأس If-Modified-Since.

إذا تطابقت البصمة ولم يتغير الملف، يرد الخادم بكود الحالة 304 Not Modified وبدون جسم رسالة إطلاقاً (فتوفر نقل الملف بالكامل) ويجدد المتصفح صلاحية النسخة المحفوظة لديه. أما إذا تغير الملف فيرد الخادم بكود 200 OK مع النسخة الجديدة.

• GET /assets/bundle.css HTTP/1.1
• Host: www.closetag.com
• If-None-Match: "v2-8f9d1a"
• If-Modified-Since: Wed, 04 Nov 2026 08:00:00 GMT
• HTTP/1.1 304 Not Modified
• Date: Thu, 05 Nov 2026 11:05:00 GMT
• Cache-Control: public, max-age=86400
• ETag: "v2-8f9d1a"

عند فحص حركة الشبكة داخل أدوات المطورين (DevTools → Network‏) أو عبر أداة سطر الأوامر curl -I، راقب عمودي الحالة (Status‏) والحجم (Size‏) لتمييز مصدر كل ملف:

• العبارة 200 OK (from memory cache): جُلبت النسخة فوراً من الذاكرة العشوائية RAM في التبويب الحالي بزمن 0 ms.
• العبارة 200 OK (from disk cache): جُلبت النسخة من الكاش المحفوظ على القرص الصلب دون إرسال أي طلب عبر الشبكة.
• الكود 304 Not Modified: أرسل المتصفح طلباً شرطياً عبر الشبكة وأكد الخادم صلاحية النسخة المحلية دون إعادة إرسال جسم الملف.
• خيار تعطيل الكاش أثناء البرمجة (Disable cache‏): تفعيل مربع Disable cache أعلى تبويب Network يوقف استخدام الكاش المحلي طالما بقيت نافذة DevTools مفتوحة، ليضمن لك رؤية تعديلاتك البرمجية فوراً.

• curl -I https://www.closetag.com/assets/app.css
• curl -i -H 'If-None-Match: "v2-8f9d1a"' https://www.closetag.com/assets/app.css

تواجه هندسة الويب معضلة كلاسيكية عند ضبط الكاش: نحن نريد تخزين ملفات CSS وJavaScript لمدة سنة كاملة (max-age=31536000, immutable‏) لأقصى سرعة ممكنة، لكننا نريد في الوقت ذاته أن يصل أي تحديث برمجي جديد إلى جميع المستخدمين في اللحظة نفسها التي ننشره فيها! فكيف نجمع بين الأمرين؟

الحل الهندسي القياسي هو كسر الكاش بالبصمة الرقمية (Cache Busting / Content Fingerprinting‏)؛ حيث تضيف أدوات البناء الحديثة (مثل Vite وWebpack‏) بصمة محتوى الملف إلى اسمه مباشرة (مثل app.8f9d1a.css‏):

• الملفات الثابتة المختومة بالبصمة (.css و.js‏): تُعطى صلاحية سنة كاملة مع immutable.
• صفحة المستند الرئيسية (HTML‏): تُضبط بالتوجيه Cache-Control: no-cache ليتحقق المتصفح منها دائماً. وفور تعديل كود التنسيق، يتغير اسم الملف في البناء الجديد إلى app.c4e29b.css داخل صفحة HTML، فيتعامل معه المتصفح كرابط جديد تماماً ويجلبه على الفور!

لبناء سياسة تخزين مؤقت احترافية تجمع بين السرعة القصوى وحماية خصوصية المستخدمين من تسرب البيانات في الخوادم الوسيطة، طبّق القواعد الهندسية الثلاث الآتية:

• الفئة الأولى — الملفات الثابتة المختومة بالبصمة (app.8f9d1a.js والخطوط والصور): استخدم التوجيه Cache-Control: public, max-age=31536000, immutable؛ فهي عامة وآمنة للتخزين لمدة عام كامل لأن أي تعديل سيغير رابطها تلقائياً.
• الفئة الثانية — صفحات HTML العامة والملفات غير المختومة: استخدم التوجيه Cache-Control: no-cache مع حقل البصمة ETag ليضمن المتصفح عرض أحدث نسخة دائماً مع توفير البيانات عبر الكود 304 Not Modified.
• الفئة الثالثة — صفحات الحسابات الشخصية والعمليات المالية (/account و/checkout‏): استخدم دائماً التوجيه الصارم Cache-Control: no-store, private لمنع حفظ أي بيانات خاصة في شبكات CDN أو على الأقراص المشتركة.

• Cache-Control: public, max-age=31536000, immutable
• Cache-Control: no-cache
• ETag: "page-v14-9c2a"
• Cache-Control: no-store, private