التخزين المؤقت من أقدم وظائف البروكسي: بدلًا من تنزيل المحتوى نفسه مرارًا وتكرارًا، يُحفظ نسخة منه ويُردّ على الطلبات اللاحقة محليًا. ومع انتشار HTTPS تقلّص نطاق هذه الوظيفة لكنه لم يختفِ تمامًا — وهو ما يزال مصدر توفير جدي في خط جمع البيانات الخاص بك.
التدفق الأساسي
عند تحقق إصابة في التخزين المؤقت لا يُذهب إلى الخادم المصدر إطلاقًا. وهذا مكسب من حيث السرعة وعرض النطاق والحمل على الخادم الهدف معًا.
من يحدد ما الذي يُحفظ؟
القرار يتخذه الخادم ويعلنه عبر ترويسة Cache-Control على النحو التالي:
| التوجيه | المعنى | سلوك البروكسي |
|---|---|---|
public | يمكن للتخزين المؤقت المشترك حفظه | يحفظ |
private | ليحفظه المتصفح وحده | لا يحفظ |
no-store | لا يُحفظ إطلاقًا | لا يحفظ |
no-cache | يمكن حفظه لكن يجب التحقق منه عند كل استخدام | يرسل طلبًا شرطيًا |
max-age=3600 | يُعدّ طازجًا لمدة 3600 ثانية | لا يذهب إلى المصدر طوال المدة |
s-maxage=600 | مدة منفصلة للتخزين المؤقت المشترك | تُقدَّم هذه القيمة على غيرها |
no-cacheلا يعني "لا تحفظ إطلاقًا" — بل يعني "احفظ لكن تحقّق قبل الاستخدام". ومقابل "لا تحفظ إطلاقًا" هو no-store.
الطلبات الشرطية: 304 Not Modified
عندما تتقادم النسخة الموجودة في التخزين المؤقت لا يكون البروكسي مضطرًا لتنزيل المحتوى من جديد. بل يسأل الخادم: "هل النسخة التي لديّ ما زالت صالحة؟":
رد 304 لا يتضمن جسمًا؛ إذ تعود الترويسات فقط. وهذا يعني تقليص صفحة بحجم 500 KB إلى 300 بايت.
واستخدام هذه الآلية في خط جمع البيانات الخاص بك تكلفة عرض النطاق يخفّضها بشكل ملحوظ.
كيف أثّر HTTPS على التخزين المؤقت؟
عند إنشاء نفق CONNECT لا يستطيع البروكسي رؤية المحتوى — وبالتالي لا يستطيع تخزينه مؤقتًا أيضًا. ولأن الويب بأكمله تقريبًا انتقل إلى HTTPS فقد صار التخزين المؤقت الكلاسيكي في البروكسي عديم الوظيفة إلى حد بعيد.
ولهذا خرج التخزين المؤقت الحديث من طبقة البروكسي وانتقل إلى طبقة CDN والعميل.
بناء تخزينك المؤقت الخاص
إذا تعذّر استخدام التخزين المؤقت في البروكسي، يمكنك تحقيق المكسب نفسه داخل تطبيقك. وهذا فعّال جدًا في خطوط جمع البيانات:
هذه الطبقة البسيطة تمنعك من تنزيل الصفحات نادرة التغيّر مرارًا وتكرارًا. وفي الموارد المحاسَبة على أساس الـ GB مثل residential proxy ينعكس التوفير مباشرة على الفاتورة.
متى يكون التخزين المؤقت خطأً؟
التخزين المؤقت مناسب
- صفحات المنتجات والفئات نادرة التغيّر.
- البيانات المرجعية الثابتة.
- الأعمال التي تسحب الصفحة نفسها أكثر من مرة في اليوم.
- مرحلة التطوير والاختبار (يحافظ على الحصة).
التخزين المؤقت خطأ
- تتبع الأسعار والمخزون في الزمن الحقيقي.
- المحتوى المخصص.
- الصفحات التي تتطلب جلسة.
- أعمال SEO التي تتابع تغيّر الترتيب.
العمل ببيانات قديمة مخزّنة مؤقتًا قد يؤدي إلى نتائج أسوأ من عدم جمع البيانات إطلاقًا. وفي المجالات الحساسة للزمن مثل الأسعار والمخزون أبقِ مدة التخزين المؤقت قصيرة جدًا أو لا تستخدمه أصلًا.
الخلاصة
فقد التخزين المؤقت في البروكسي وظيفته بمعناه الكلاسيكي إلى حد كبير مع انتشار HTTPS؛ لأن البروكسي لا يرى المحتوى داخل نفق CONNECT. في المقابل ما يزال بناء المنطق نفسه في طبقة تطبيقك ممكنًا وبالغ القيمة. فالطلبات الشرطية القائمة على ETag تلغي حركة البيانات كلها تقريبًا في المحتوى نادر التغيّر. أما في البيانات الحساسة للزمن فينبغي تجنّب التخزين المؤقت. ولحساب الاستهلاك راجع مقالنا عن عرض النطاق يمكنك الاطّلاع.