التخزين المؤقت لعامل الخدمات والتخزين المؤقت باستخدام بروتوكول HTTP

مزايا وعيوب استخدام منطق انتهاء صلاحية ثابت أو مختلف على مستوى ذاكرة التخزين المؤقت لعامل الخدمة وطبقات ذاكرة التخزين المؤقت لبروتوكول HTTP

Jonathan Chen

في حين أنّ مهام الخدمة وتطبيقات الويب التقدمية أصبحت معايير لتطبيقات الويب الحديثة، أصبح تخزين الموارد مؤقتًا أكثر تعقيدًا من أي وقت مضى. تتناول هذه المقالة الصورة الكبيرة لتخزين المحتوى المؤقت في المتصفّح، بما في ذلك:

• حالات استخدام ذاكرة التخزين المؤقت لعامل الخدمة وذاكرة التخزين المؤقت لبروتوكول HTTP والاختلافات بينهما
• الإيجابيات والسلبيات لاستراتيجيات انتهاء صلاحية ذاكرة التخزين المؤقت لعامل الخدمة المختلفة مقارنةً باستراتيجيات ذاكرة التخزين المؤقت العادية لبروتوكول HTTP

نظرة عامة على عملية التخزين المؤقت

بشكل عام، يتّبع المتصفّح ترتيب التخزين المؤقت أدناه عند طلب مرجع:

1. ذاكرة التخزين المؤقت لخدمة Worker: يتحقّق Worker مما إذا كان المورد متوفرًا في ذاكرة التخزين المؤقت ويحدد ما إذا كان سيتم عرض المورد نفسه استنادًا إلى استراتيجيات التخزين المؤقت المبرمَجة. يُرجى العلم أنّ هذا الإجراء لا يتم تلقائيًا. عليك إنشاء معالِج لحدث الجلب في عامل الخدمة واعتراض طلبات الشبكة حتى يتم عرض الطلبات من ذاكرة التخزين المؤقت لعامل الخدمة بدلاً من الشبكة.
2. ذاكرة التخزين المؤقت لواجهة HTTP (المعروفة أيضًا باسم ذاكرة التخزين المؤقت للمتصفّح): إذا تم العثور على المورد في ذاكرة التخزين المؤقت لواجهة HTTP ولم تنته صلاحيته بعد، يستخدم المتصفّح تلقائيًا المورد من ذاكرة التخزين المؤقت لواجهة HTTP.
3. من جهة الخادم: إذا لم يتم العثور على أي محتوى في ذاكرة التخزين المؤقت لخدمة Worker أو ذاكرة التخزين المؤقت لبروتوكول HTTP، ينتقل المتصفّح إلى الشبكة لطلب المورد. إذا لم يكن المورد محفوظًا مؤقتًا في شبكة توصيل المحتوى (CDN)، يجب أن يتم توجيه الطلب إلى خادم المصدر.

تخزين الطبقات مؤقتًا

التخزين المؤقت لمشغِّل الخدمات

يرصد عامل الخدمة طلبات HTTP من النوع "الشبكة" ويستخدم استراتيجية التخزين المؤقت لتحديد الموارد التي يجب عرضها في المتصفّح. تخدم ذاكرة التخزين المؤقت لمشغّل الخدمات وذاكرة التخزين المؤقت لبروتوكول HTTP الغرض العام نفسه، ولكنّ ذاكرة التخزين المؤقت لمشغّل الخدمات توفّر المزيد من إمكانات التخزين المؤقت، مثل التحكّم الدقيق في المحتوى الذي يتم تخزينه مؤقتًا وطريقة إجراء التخزين المؤقت.

التحكّم في ذاكرة التخزين المؤقت لمشغّل الخدمة

يعترض عامل الخدمة طلبات HTTP باستخدام مستمعي الأحداث (عادةً الحدث fetch). يوضّح مقتطف الرمز هذا منطق استراتيجية ملف التخزين المؤقت Cache-First.

ننصح بشدة باستخدام Workbox لتجنُّب إعادة اختراع العجلة. على سبيل المثال، يمكنك تسجيل مسارات عناوين URL للموارد باستخدام سطر واحد من رمز التعبير العادي.

import {registerRoute} from 'workbox-routing';

registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);

استراتيجيات التخزين المؤقت في مهام الخدمة وحالات استخدامها

يوضّح الجدول التالي استراتيجيات التخزين المؤقت الشائعة لعامل الخدمة والحالات التي تكون فيها كل استراتيجية مفيدة.

مزايا إضافية لتخزين الخدمة

بالإضافة إلى التحكّم الدقيق في منطق التخزين المؤقت، يوفّر التخزين المؤقت لمشغّل الخدمة أيضًا ما يلي:

• مزيد من الذاكرة ومساحة التخزين لمصدرك: يخصّص المتصفّح موارد التخزين المؤقت لبروتوكول HTTP على أساس كل مصدر. بعبارة أخرى، إذا كانت لديك عدة نطاقات فرعية، ستتشارك جميعها ذاكرة التخزين المؤقت لواجهة HTTP نفسها. لا يمكن أبدًا ضمان بقاء محتوى مصدرك/نطاقك في ذاكرة التخزين المؤقت لبروتوكول HTTP لفترة طويلة. على سبيل المثال، يمكن للمستخدم تنظيف ذاكرة التخزين المؤقت يدويًا من واجهة مستخدم إعدادات المتصفّح، أو بدء إعادة تحميل صفحات الويب. باستخدام ذاكرة التخزين المؤقت لخدمة عامل الخدمة، يزداد احتمال بقاء المحتوى المخزّن مؤقتًا في الذاكرة. اطّلِع على مساحة التخزين الدائمة لمعرفة المزيد من المعلومات.
• مرونة أكبر في الشبكات غير المستقرة أو التجارب بلا إنترنت: باستخدام ذاكرة التخزين المؤقت لبروتوكول HTTP، يكون لديك خيار ثنائي فقط: إما تخزين المورد في ذاكرة التخزين المؤقت أو عدم تخزينه. باستخدام ميزة التخزين المؤقت لعامل الخدمة، يمكنك تخفيف بعض "المشاكل البسيطة" بسهولة أكبر (باستخدام استراتيجية "البيانات القديمة أثناء إعادة التحقّق")، وتقديم تجربة كاملة بلا إنترنت (باستخدام استراتيجية "التخزين المؤقت فقط") أو حتى إجراء ما بين هذين الخيارين، مثل واجهات مستخدم مخصّصة تتضمّن أجزاء من الصفحة تأتي من ذاكرة التخزين المؤقت لعامل الخدمة وبعض الأجزاء المستبعَدة (باستخدام استراتيجية "ضبط معالِج الأخطاء") عند الاقتضاء.

التخزين المؤقت عبر HTTP

في المرة الأولى التي يحمّل فيها المتصفّح صفحة ويب والموارد ذات الصلة، يخزّن هذه الموارد في ملف التخزين المؤقت لبروتوكول HTTP. تفعِّل المتصفّحات عادةً ذاكرة التخزين المؤقت لبروتوكول HTTP تلقائيًا، ما لم يتم إيقافها صراحةً من قِبل المستخدم النهائي.

يعني استخدام ميزة التخزين المؤقت في HTTP الاعتماد على الخادم لتحديد وقت تخزين مورد معيّن مؤقتًا ومدّة ذلك.

التحكّم في انتهاء صلاحية ذاكرة التخزين المؤقت في HTTP باستخدام عناوين استجابة HTTP

عندما يستجيب الخادم لطلب متصفّح للحصول على مورد، يستخدم الخادم رؤوس استجابة HTTP لتحديد المدة التي يجب أن يخزن فيها المتصفّح المورد في ذاكرة التخزين المؤقت. اطّلِع على رؤوس الاستجابة: ضبط ملف تكوين الخادم لمعرفة المزيد.

استراتيجيات التخزين المؤقت في HTTP وحالات الاستخدام

إنّ ميزة التخزين المؤقت عبر HTTP أبسط بكثير من ميزة التخزين المؤقت لمشغّل الخدمة، لأنّ ميزة التخزين المؤقت عبر HTTP لا تتعامل إلا مع منطق انتهاء صلاحية المورد المستنِد إلى الوقت (TTL). اطّلِع على ما هي قيم رؤوس الاستجابة التي يجب استخدامها؟ والملخّص لمعرفة المزيد من المعلومات عن استراتيجيات التخزين المؤقت لبروتوكول HTTP.

تصميم منطق انتهاء صلاحية ذاكرة التخزين المؤقت

يوضّح هذا القسم مزايا وعيوب استخدام منطق انتهاء صلاحية متّسق في كل من ذاكرة التخزين المؤقت لعامل الخدمة وطبقة ذاكرة التخزين المؤقت لبروتوكول HTTP، بالإضافة إلى مزايا وعيوب منطق انتهاء الصلاحية المنفصل في كل من هذين الطبقتَين.

يوضّح الرابط أدناه كيفية عمل التخزين المؤقت لعامل الخدمة والتخزين المؤقت عبر HTTP في سيناريوهات مختلفة:

منطق انتهاء صلاحية متّسق لجميع طبقات ذاكرة التخزين المؤقت

لتوضيح الإيجابيات والسلبيات، سننظر في 3 سيناريوهات: على المدى الطويل والمتوسط والقصير.

السيناريو: التخزين المؤقت على المدى الطويل (التخزين المؤقت، الرجوع إلى الشبكة)

• عندما يكون المورد المخزَّن مؤقتًا صالحًا (<= 30 يومًا): يعرض عامل الخدمة المورد المُخزَّن على الفور بدون الاتصال بالشبكة.
• عند انتهاء صلاحية مورد محفوظ في ذاكرة التخزين المؤقت (> 30 يومًا): يتصل عامل الخدمة بالشبكة ل retrieving the resource. لا يتضمّن المتصفّح نسخة من المورد في ذاكرة التخزين المؤقت لبروتوكول HTTP، لذا ينتقل إلى جهة الخادم للحصول على المورد.

العيب: في هذا السيناريو، لا يقدّم التخزين المؤقت لبروتوكول HTTP قيمة كبيرة لأنّ المتصفح سيمرّر الطلب دائمًا إلى جهة الخادم عند انتهاء صلاحية ذاكرة التخزين المؤقت في مشغّل الخدمة.

السيناريو: التخزين المؤقت على المدى المتوسط (Stale-while-revalidate)

• عندما يكون المورد المخزّن مؤهّلاً (<= يوم واحد): يعرض عامل الخدمة المورد المُخزّن على الفور، وينتقل إلى الشبكة لتحميل المورد. يحتوي المتصفّح على نسخة من المورد في ذاكرة التخزين المؤقت لبروتوكول HTTP، لذا يعرض هذه النسخة لمشغّل الخدمة.
• عند انتهاء صلاحية مورد محفوظ في ذاكرة التخزين المؤقت (> يوم واحد): يعرض عامل الخدمة المورد المحفوظ في ذاكرة التخزين المؤقت على الفور، وينتقل إلى الشبكة لتحميل المورد. لا يتوفّر لدى المتصفّح نسخة من المورد في ذاكرة التخزين المؤقت لبروتوكول HTTP، لذا ينتقل إلى جهة الخادم لجلب المورد.

العيب: يتطلّب مشغّل الخدمة ميزة إضافية لإزالة ذاكرة التخزين المؤقت من أجل إلغاء ذاكرة التخزين المؤقت لبروتوكول HTTP للاستفادة إلى أقصى حد من خطوة "إعادة التحقّق من الصحة".

السيناريو: التخزين المؤقت على المدى القصير (الشبكة تعود إلى ذاكرة التخزين المؤقت)

• عندما يكون المورد المخزّن مؤهّلاً (<= 10 دقائق): ينتقل عامل الخدمة إلى الشبكة لاسترداد المورد. يحتوي المتصفّح على نسخة من المورد في ذاكرة التخزين المؤقت لبروتوكول HTTP، لذا يعرضه على مشغّل الخدمة بدون الانتقال إلى الخادم.
• عند انتهاء صلاحية مورد محفوظ في ذاكرة التخزين المؤقت (> 10 دقائق): يعرض عامل الخدمة المورد المحفوظ في ذاكرة التخزين المؤقت على الفور، وينتقل إلى الشبكة لتحميل المورد. لا يتضمّن المتصفّح نسخة من المورد في ذاكرة التخزين المؤقت لبروتوكول HTTP، لذا ينتقل إلى جهة الخادم لجلب المورد.

العيوب: على غرار سيناريو التخزين المؤقت على المدى المتوسط، يتطلّب مشغّل الخدمة مزيدًا من LOGIC لإلغاء ذاكرة التخزين المؤقت لبروتوكول HTTP من أجل جلب أحدث مورد من العميل الخادم.

الخدمة العاملة في جميع السيناريوهات

في جميع السيناريوهات، يمكن أن تستمر ذاكرة التخزين المؤقت لمشغّل الخدمة في عرض الموارد المخزّنة مؤقتًا عندما تكون الشبكة غير مستقرة. من ناحية أخرى، لا يمكن الاعتماد على ذاكرة التخزين المؤقت لبروتوكول HTTP عندما تكون الشبكة غير مستقرة أو متوقّفة.

منطق مختلف لانتهاء صلاحية ذاكرة التخزين المؤقت في ذاكرة التخزين المؤقت لعامل الخدمة وطبقات HTTP

لتوضيح الإيجابيات والسلبيات، سننظر مرة أخرى في سيناريوهات المدّة الطويلة والمدّة المتوسطة والمدّة القصيرة.

السيناريو: التخزين المؤقت على المدى الطويل (التخزين المؤقت، الرجوع إلى الشبكة)

• عندما يكون المرجع المخزّن مؤقتًا صالحًا في ذاكرة التخزين المؤقت لمشغّل الخدمة (<= 90 يومًا): يعرض مشغّل الخدمة المرجع المخزّن مؤقتًا على الفور.
• عند انتهاء صلاحية مورد محفوظ في ذاكرة التخزين المؤقت لخدمة worker (> 90 يومًا): ينتقل service worker إلى الشبكة لجلب المورد. لا يتوفّر لدى المتصفّح نسخة من المورد في ذاكرة التخزين المؤقت لبروتوكول HTTP، لذا يتم إرسال الطلب إلى الخادم.

الإيجابيات والسلبيات

• المزايا: يحصل المستخدمون على استجابة فورية لأنّ الخدمة العاملة تعرض الموارد المخزّنة مؤقتًا على الفور.
• المزايا: يمكن لعامل الخدمة التحكّم بشكل أدق في وقت استخدام ذاكرة التخزين المؤقت ووقت طلب إصدارات جديدة من الموارد.
• العيب: يجب تحديد استراتيجية تخزين مؤقت لمشغّل الخدمة بشكل جيد.

السيناريو: التخزين المؤقت على المدى المتوسط (Stale-while-revalidate)

• عندما يكون المورد المخزّن مؤقتًا صالحًا في ذاكرة التخزين المؤقت لمشغّل الخدمة (<= 30 يومًا): يعرض مشغّل الخدمة المورد المخزّن مؤقتًا على الفور.
• عند انتهاء صلاحية مورد محفوظ في ذاكرة التخزين المؤقت لعامل الخدمة (> 30 يومًا): يتصل عامل الخدمة بالشبكة للحصول على المورد. لا يتضمّن المتصفّح نسخة من المورد في ملف التخزين المؤقت لبروتوكول HTTP، لذا يتم إرسال الطلب من جهة الخادم.

الإيجابيات والسلبيات

• المزايا: يحصل المستخدمون على استجابة فورية لأنّ الخدمة العاملة تعرض الموارد المخزّنة مؤقتًا على الفور.
• الإيجابيات: يمكن لعامل الخدمة ضمان أنّ الطلب القادم لعنوان URL معيّن يستخدم استجابة جديدة من الشبكة، وذلك بفضل إعادة التحقّق التي تتم "في الخلفية".
• العيب: يجب تحديد استراتيجية تخزين مؤقت لمشغّل الخدمة بشكل جيد.

السيناريو: التخزين المؤقت على المدى القصير (الشبكة تعود إلى ذاكرة التخزين المؤقت)

• عندما يكون المورد المخزّن مؤهّلاً في ذاكرة التخزين المؤقت لخدمة worker (‎<= يوم واحد): ينتقل لخدمة worker إلى الشبكة للحصول على المورد. يعرض المتصفّح المورد من ملف التخزين المؤقت لبروتوكول HTTP إذا كان متوفّرًا. في حال انقطاع الاتصال بالشبكة، يعرض مشغّل الخدمة المورد من ذاكرة التخزين المؤقت لمشغّل الخدمة.
• عند انتهاء صلاحية مورد محفوظ في ذاكرة التخزين المؤقت لعامل الخدمة (> يوم واحد): يتصل عامل الخدمة بالشبكة لتحميل المورد. يُجلب المتصفّح الموارد عبر الشبكة لأنّ النسخة المخزّنة مؤقتًا في ذاكرة التخزين المؤقت لبروتوكول HTTP قد انتهت صلاحيتها.

الإيجابيات والسلبيات

• المزايا: عندما تكون الشبكة غير مستقرة أو متوقّفة، يعرض عامل الخدمة موارد التخزين المؤقت على الفور.
• العيب: يتطلّب مشغّل الخدمة ميزة إضافية لإزالة ذاكرة التخزين المؤقت من أجل إلغاء ذاكرة التخزين المؤقت لبروتوكول HTTP و تقديم طلبات "الشبكة أولاً".

الخاتمة

نظرًا لتعقيد مجموعة سيناريوهات التخزين المؤقت، لا يمكن تصميم قاعدة واحدة تغطي جميع الحالات. ومع ذلك، استنادًا إلى النتائج الواردة في الأقسام السابقة، هناك بعض الاقتراحات التي يجب مراعاتها عند تصميم استراتيجيات ذاكرة التخزين المؤقت:

• لا يلزم أن يكون منطق التخزين المؤقت لعامل الخدمة متناسقًا مع منطق انتهاء صلاحية التخزين المؤقت في HTTP. استخدِم منطق انتهاء صلاحية أطول في مشغّل الخدمة إن أمكن، وذلك لمنحه مزيدًا من التحكّم.
• لا يزال التخزين المؤقت لبروتوكول HTTP يلعب دورًا مهمًا، ولكنّه غير موثوق به عندما تكون الشبكة غير مستقرة أو متوقّفة.
• راجِع استراتيجيات التخزين المؤقت لكل مورد للتأكّد من أنّ استراتيجية التخزين المؤقت لعامل الخدمة توفّر قيمتها بدون تعارض مع ذاكرة التخزين المؤقت لبروتوكول HTTP.

مزيد من المعلومات

• موثوقية الشبكة
• منع الطلبات غير الضرورية من الشبكة باستخدام ذاكرة التخزين المؤقت عبر HTTP
• دورة تدريبية حول رمز ذاكرة التخزين المؤقت لبروتوكول HTTP
• قياس تأثير أداء "العمال في الخدمة" في الاستخدام الفعلي
• Cache-Control مقارنةً بـ Expires
• معلومات حول ذاكرة التخزين المؤقت: فحص ذاكرات التخزين المؤقت ومحو بياناتها وإيقافها