بشكل عام، يمكن أن يؤدي التخزين المؤقت إلى تحسين الأداء من خلال تخزين البيانات بحيث يتم عرض الطلبات المستقبلية للبيانات نفسها بشكل أسرع. على سبيل المثال، يمكن لمورد مخبأ من الشبكة تجنب الانتقال ذهابًا وإيابًا إلى الخادم. يمكن لنتيجة حسابية مخبأة أن تغفل الوقت لإجراء نفس العملية الحسابية.
في Chrome، يتم استخدام آلية ذاكرة التخزين المؤقت بطرق مختلفة وتعد ذاكرة التخزين المؤقت HTTP أحد الأمثلة على ذلك.
آلية عمل ذاكرة التخزين المؤقت HTTP في Chrome حاليًا
اعتبارًا من الإصدار 85، يخزِّن Chrome مؤقتًا الموارد التي تم جلبها من الشبكة، باستخدام عناوين URL ذات الصلة للموارد كمفتاح لذاكرة التخزين المؤقت. (يُستخدم مفتاح ذاكرة التخزين المؤقت لتحديد مورد مخزَّن مؤقتًا.)
يوضّح المثال التالي كيفية تخزين صورة واحدة مؤقتًا ومعالجتها في ثلاثة سياقات مختلفة:
يزور أحد المستخدمين صفحة (https://a.example
) تطلب صورة (https://x.example/doge.png
). يتم طلب الصورة من الشبكة وتخزينها مؤقتًا باستخدام https://x.example/doge.png
كمفتاح.
يزور المستخدم نفسه صفحة أخرى (https://b.example
)، تطلب الصورة نفسها (https://x.example/doge.png
). يتحقّق المتصفّح من ذاكرة التخزين المؤقت لـ HTTP لمعرفة ما إذا كان هذا المورد يحتوي على هذا المورد مؤقتًا، وذلك باستخدام عنوان URL للصورة كالمفتاح. يعثر المتصفح على تطابق في ذاكرة التخزين المؤقت الخاصة به، ولذلك يستخدم النسخة المخزنة مؤقتًا من المورد.
ولا يهم إذا تم تحميل الصورة من داخل iframe. إذا زار المستخدم موقعًا إلكترونيًا آخر (https://c.example
) باستخدام إطار iframe
(https://d.example
) وطلب إطار iframe الصورة نفسها
(https://x.example/doge.png
)، سيظل بإمكان المتصفّح تحميل الصورة من
ذاكرة التخزين المؤقت الخاصة به لأنّ مفتاح ذاكرة التخزين المؤقت هو نفسه في جميع الصفحات.
وتعمل هذه الآلية بشكل جيد من منظور الأداء لفترة طويلة. ومع ذلك، فإنّ الوقت الذي يستغرقه موقع إلكتروني للاستجابة لطلبات HTTP قد يكشف عن أنّ المتصفّح قد وصل إلى المورد نفسه في الماضي، ما يؤدي إلى تعريض المتصفّح لهجمات الأمان والخصوصية، كما يلي:
- الكشف عن زيارة المستخدم لموقع إلكتروني معيّن: يمكن للمنافس اكتشاف سجلّ تصفّح المستخدم من خلال التحقّق ممّا إذا كانت ذاكرة التخزين المؤقت تتضمّن موردًا قد يكون خاصًا بموقع إلكتروني معيّن أو مجموعة نموذجية من المواقع الإلكترونية.
- هجوم البحث على مواقع إلكترونية متعددة: يمكن للخصم اكتشاف ما إذا كانت سلسلة عشوائية تظهر في نتائج بحث المستخدم من خلال التحقق مما إذا كانت الصورة "بلا نتائج بحث" يستخدمها موقع إلكتروني معيّن في ذاكرة التخزين المؤقت في المتصفّح.
- التتبّع على مواقع إلكترونية متعددة: يمكن استخدام ذاكرة التخزين المؤقت لتخزين معرّفات تشبه ملفات تعريف الارتباط كآلية تتبُّع على مواقع إلكترونية متعددة.
للحدّ من هذه المخاطر، سيعمل Chrome على تقسيم ذاكرة التخزين المؤقت التي تستخدم HTTP بدءًا من Chrome 86.
كيف سيؤثر تقسيم ذاكرة التخزين المؤقت في ذاكرة التخزين المؤقت عبر HTTP في Chrome؟
من خلال تقسيم ذاكرة التخزين المؤقت، سيتم ربط الموارد المخزّنة مؤقتًا باستخدام "مفتاح عزل الشبكة" الجديد بالإضافة إلى عنوان URL للمورد. يتكون مفتاح عزل الشبكة من موقع المستوى الأعلى وموقع الإطار الحالي.
انظر مرة أخرى إلى المثال السابق لترى كيف يعمل تقسيم ذاكرة التخزين المؤقت في السياقات المختلفة:
يزور أحد المستخدمين صفحة (https://a.example
) تطلب صورة (https://x.example/doge.png
). في هذه الحالة، يتم طلب الصورة من الشبكة، ويتم تخزينها مؤقتًا باستخدام صف يتكون من https://a.example
(موقع المستوى الأعلى) وhttps://a.example
(موقع الإطار الحالي) وhttps://x.example/doge.png
(عنوان URL للمورد) باعتباره العنصر الأساسي. (لاحظ أنه عندما يكون طلب المورد من إطار -المستوى الأعلى، يكون الموقع ذو المستوى الأعلى وموقع الإطار الحالي في مفتاح عزل الشبكة متطابقين).
يزور المستخدم نفسه صفحة مختلفة (https://b.example
) تطلب الصورة نفسها (https://x.example/doge.png
). ورغم أنّه تم تحميل الصورة نفسها في المثال السابق، لن يؤدي عدم تطابق المفتاح مع ذلك إلى الوصول إلى نتيجة ذاكرة تخزين مؤقت.
ويتم طلب الصورة من الشبكة وتخزينها مؤقتًا باستخدام صف يتألف من https://b.example
وhttps://b.example
وhttps://x.example/doge.png
كمفتاح.
يعود المستخدم الآن إلى https://a.example
، ولكن هذه المرة تكون الصورة (https://x.example/doge.png
) مضمَّنة في إطار iframe. في هذه الحالة، يكون المفتاح
صفًا يحتوي على https://a.example
وhttps://a.example
وhttps://x.example/doge.png
، وتحدث نتيجة ذاكرة تخزين مؤقت. (لاحظ أنه عندما يكون موقع المستوى الأعلى وإطار iframe من نفس الموقع، يمكن استخدام المورد المخزنة مؤقتًا بإطار المستوى الأعلى.
عاد المستخدم إلى الموقع الإلكتروني https://a.example
، ولكن تمت استضافة الصورة في
إطار iframe من https://c.example
.
وفي هذه الحالة، يتم تنزيل الصورة من الشبكة لعدم توفّر
مورد في ذاكرة التخزين المؤقت يطابق المفتاح الذي يتألف من https://a.example
وhttps://c.example
وhttps://x.example/doge.png
.
ماذا لو كان النطاق يحتوي على نطاق فرعي أو رقم منفذ؟ ينتقل المستخدم إلى علامة https://subdomain.a.example
، التي تضمِّن إطار iframe
(https://c.example:8080
) يطلب عرض الصورة.
ولأنّ المفتاح يتم إنشاؤه استنادًا إلى "scheme://eTLD+1"، يتم تجاهل النطاقات الفرعية وأرقام المنافذ. ومن ثم تظهر نتيجة ذاكرة تخزين مؤقت.
ماذا لو تم دمج iframe عدة مرات؟ يزور المستخدم علامة https://a.example
، التي تضمِّن إطار iframe (https://b.example
) يتضمّن إطار iframe آخر (https://c.example
)، والذي يطلب الصورة في النهاية.
تحدث نتيجة ذاكرة تخزين مؤقت لأن المفتاح مأخوذ من الإطار العلوي (https://a.example
)
والإطار الفوري الذي يحمِّل المورد (https://c.example
).
الأسئلة الشائعة
هل هي مُفعَّلة على Chrome؟ كيف يمكنني التحقّق من ذلك؟
يتم طرح هذه الميزة حتى أواخر عام 2020. للتحقق مما إذا كان مثيل Chrome يتوافق بالفعل معها:
- افتح
chrome://net-export/
واضغط على بدء تسجيل الدخول إلى القرص. - حدِّد مكان حفظ ملف السجلّ على الكمبيوتر.
- تصفَّح الويب على Chrome لمدة دقيقة.
- ارجِع إلى
chrome://net-export/
واضغط على إيقاف التسجيل. - الانتقال إلى
https://netlog-viewer.appspot.com/#import
- اضغط على اختيار ملف ومرِّر ملف السجلّ الذي حفظته.
سيظهر لك ناتج ملف السجلّ.
في الصفحة نفسها، ابحث عن "SplitCacheByNetworkIsolationKey
". إذا كان تتبعه Experiment_[****]
، سيتم تفعيل ميزة تقسيم ذاكرة التخزين المؤقت على Chrome على Chrome. إذا كان يتبعه Control_[****]
أو Default_[****]
، لن يتم تفعيله.
كيف يمكنني اختبار تقسيم ذاكرة التخزين المؤقت HTTP على Chrome؟
لاختبار تقسيم ذاكرة التخزين المؤقت عبر HTTP على Chrome، يجب تشغيل Chrome باستخدام
علامة سطر الأوامر: --enable-features=SplitCacheByNetworkIsolationKey
. اتبع التعليمات الواردة في تشغيل Chromium باستخدام العلامات للتعرّف على كيفية تشغيل Chrome باستخدام علامة سطر أوامر على نظامك الأساسي.
بصفتي مطوِّر برامج على الويب، هل هناك أي إجراء يجب عليّ اتّخاذه استجابةً لهذا التغيير؟
هذا ليس تغييرًا قد يؤدي إلى عطل، ولكنه قد يفرض اعتبارات متعلقة بالأداء لبعض خدمات الويب.
على سبيل المثال، قد تشهد المواقع الإلكترونية التي تعرض أعدادًا كبيرة من الموارد القابلة للتخزين المؤقت بشكل كبير على العديد من المواقع الإلكترونية (مثل الخطوط والنصوص البرمجية الرائجة) زيادة في عدد الزيارات. كذلك، قد يكون لدى مستخدمي مثل هذه الخدمات اعتماد أكبر عليها.
هناك اقتراح لتفعيل المكتبات المشتركة بطريقة تحافظ على الخصوصية، وهو المكتبات المشتركة على الويب (فيديو العرض التقديمي)، ولكنه لا يزال قيد الدراسة.
ما تأثير هذا التغيير السلوكي؟
يزداد إجمالي نسبة الأخطاء في ذاكرة التخزين المؤقت بحوالي %3.6، وتكون التغييرات في سرعة عرض المحتوى على الصفحة (FCP) محدودة (%0.3 تقريبًا)، وتزيد النسبة الإجمالية لوحدات البايت التي يتم تحميلها من الشبكة بحوالي %4. يمكنك الاطّلاع على المزيد من المعلومات حول تأثير ذلك في الأداء من خلال شرح تقسيم ذاكرة التخزين المؤقت على HTTP.
هل هذا موحّد؟ هل تختلف طريقة عمل المتصفحات الأخرى؟
يتم توحيد "أقسام ذاكرة التخزين المؤقت لـ HTTP" في مواصفات الجلب على الرغم من أن المتصفحات تتصرف بشكل مختلف:
- Chrome: يستخدِم مخطط المستوى الأعلى://eTLD+1 ومخطّط الإطار://eTLD+1.
- Safari: يستخدِم نطاق eTLD+1 عالي المستوى.
- Firefox: التخطيط للتنفيذ باستخدام مخطط المستوى الأعلى://eTLD+1 مع التفكير في تضمين مفتاح ثانٍ مثل Chrome
كيف تتم معالجة عمليات الجلب من العاملين؟
يستخدم العاملون المتخصّصون المفتاح نفسه الذي يستخدمه الإطار الحالي. ويكون عاملو الخدمات والعاملون المشترَكون أكثر تعقيدًا لأنّه قد تتم مشاركتهم بين عدّة مواقع إلكترونية عالية المستوى. الحل بالنسبة لهم قيد المناقشة حاليًا.