كيفية عمل التخزين المؤقت

توفر هذه المقالة نظرة عامة على مفاهيم التخزين المؤقت العامة وكيفية استخدام Azure Content Delivery Network للتخزين المؤقت لتحسين الأداء. إذا كنت ترغب في التعرف على كيفية تخصيص سلوك التخزين المؤقت على نقطة نهاية شبكة تسليم المحتوى، فشاهد التحكم في سلوك التخزين المؤقت لشبكة تسليم المحتوى Azure باستخدام قواعد التخزين المؤقت والتحكم في سلوك التخزين المؤقت لشبكة تسليم المحتوى في Azure باستخدام سلاسل الاستعلام.

مقدمة للتخزين المؤقت

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

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

لا يمكن تخزين الموارد الديناميكية التي تتغير بشكل متكرر أو فريدة لمستخدم فردي مؤقتا. ومع ذلك، يمكن لهذه الأنواع من الموارد الاستفادة من تحسين تسريع الموقع الديناميكي (DSA) على شبكة تسليم محتوى Azure لتحسين الأداء.

يمكن أن يحدث التخزين المؤقت على مستويات متعددة بين خادم الأصل والمستخدم النهائي:

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

عادة ما تدير كل ذاكرة تخزين مؤقت حداثة الموارد الخاصة بها وتنفذ التحقق من الصحة عندما يكون الملف قديمًا. يتم تعريف هذا السلوك في مواصفات التخزين المؤقت لبروتوكول نقل نص تشعبي (HTTP) وهي، RFC 7234.

حداثة الموارد

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

التحقق من الصحة

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

التخزين المؤقت لشبكة تسليم المحتوى

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

  • نظرا لأن معظم حركة مرور الويب ثابتة (على سبيل المثال، الصور والخطوط ومقاطع الفيديو)، فإن التخزين المؤقت لشبكة تسليم المحتوى يقلل من زمن انتقال الشبكة عن طريق نقل المحتوى بالقرب من المستخدم، وبالتالي تقليل المسافة التي تقطعها البيانات.

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

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

يمكن استخدام رأسين لتحديد حداثة ذاكرة التخزين المؤقت: Cache-Control وExpires. Cache-Control هو أكثر حداثة ويأخذ الأسبقية على Expires، إذا كان كلاهما موجودًا. هناك أيضًا نوعان من الرؤوس المُستخدمة للتحقق من الصحة (تسمى المدققات): ETag وLast-Modified. ETag هو أكثر حداثة ويأخذ الأسبقية على Last-Modified، إذا تم تحديد كليهما.

رؤوس توجيه ذاكرة التخزين المؤقت

هام

بشكل افتراضي، تتجاهل نقطة نهاية Azure Content Delivery Network التي تم تحسينها ل DSA عناوين توجيه ذاكرة التخزين المؤقت وتتجاوز التخزين المؤقت. بالنسبة إلى Azure CDN Standard من ملفات تعريف Edgio ، يمكنك ضبط كيفية تعامل نقطة نهاية Azure Content Delivery Network مع هذه العناوين باستخدام قواعد التخزين المؤقت لشبكة تسليم المحتوى لتمكين التخزين المؤقت. بالنسبة إلى Azure CDN Premium من ملفات تعريف Edgio فقط، يمكنك استخدام محرك القواعد لتمكين التخزين المؤقت.

تدعم Azure Content Delivery Network عناوين توجيه ذاكرة التخزين المؤقت HTTP التالية، والتي تحدد مدة ذاكرة التخزين المؤقت ومشاركة ذاكرة التخزين المؤقت.

عنصر التحكم في المحتوى:

  • تم تقديمه في HTTP 1.1 لمنح ناشري الويب مزيدًا من التحكم في محتواهم ومعالجة قيود الرأس Expires.
  • يتجاوز الرأس Expires، إذا تم تحديده هو وCache-Control.
  • عند استخدامها في طلب HTTP من العميل إلى شبكة تسليم المحتوى POP، Cache-Control يتم تجاهلها من قبل جميع ملفات تعريف شبكة تسليم المحتوى Azure، بشكل افتراضي.
  • عند استخدامه في استجابة HTTP من خادم الأصل إلى شبكة تسليم المحتوى POP:

تنتهي الصلاحية:

  • عنوان قديم تم تقديمه في HTTP 1.0؛ معتمد للتوافق مع الإصدارات السابقة.
  • يستخدم وقت انتهاء الصلاحية المُستند إلى التاريخ بدقة ثانية.
  • مشابه لـ Cache-Control: max-age.
  • يُستخدم عندما لا يكون Cache-Control موجودًا.

Pragma:

  • لا يتم تكريمه من قبل شبكة تسليم المحتوى Azure، بشكل افتراضي.
  • عنوان قديم تم تقديمه في HTTP 1.0؛ معتمد للتوافق مع الإصدارات السابقة.
  • يُستخدم كرأس طلب عميل مع التوجيه التالي: no-cache. يوجه هذا التوجيه الخادم لتقديم إصدار حديث من المورد.
  • Pragma: no-cache يُعادل Cache-Control: no-cache.

المدققون

عندما تكون ذاكرة التخزين المؤقت قديمة، يتم استخدام مدققات ذاكرة التخزين المؤقت لـ HTTP لمقارنة الإصدار المخزن مؤقتًا لملف مع الإصدار على خادم الأصل. يدعم Azure CDN Standard/Premium من Edgio كلا من المدققين ETag والمدققين Last-Modified بشكل افتراضي، بينما يدعم Azure CDN Standard من Microsoft فقط Last-Modified.

ETag:

  • يدعم Azure CDN Standard/Premium من Edgio بشكل افتراضي، بينما لا يدعم ETag Azure CDN Standard من Microsoft.
  • ETag يعرف سلسلة فريدة لكل ملف وإصدار ملف. على سبيل المثال، ETag: "17f0ddd99ed5bbe4edffdd6496d7131f"
  • تم تقديمه في HTTP 1.1 وهو أحدث من Last-Modified. مفيد عندما يكون من الصعب تحديد تاريخ التعديل الأخير.
  • يدعم كلا من التحقق القوي والتحقق الضعيف؛ ومع ذلك، تدعم Azure Content Delivery Network التحقق من الصحة القوي فقط. بالنسبة إلى التحقق من الصحة القوي، يجب أن تكون تمثيلات الموردين متطابقة بايت مقابل بايت.
  • تتحقق ذاكرة التخزين المؤقت من صحة ملف يستخدم ETag عن طريق إرسال رأس If-None-Match مع مدقق واحد أو أكثر من ETag في الطلب. على سبيل المثال، If-None-Match: "17f0ddd99ed5bbe4edffdd6496d7131f" إذا تطابق إصدار الخادم مع مدقق ETag في القائمة، فإنه يرسل رمز الحالة 304 (غير معدل) في استجابته. إذا كان الإصدار مختلفًا، يستجيب الخادم مع رمز الحالة 200‏ (OK) والمورد المحدث.

التعديل الأخير:

  • بالنسبة إلى Azure CDN Standard/Premium من Edgio فقط، Last-Modified يتم استخدامه إذا ETag لم يكن جزءا من استجابة HTTP.
  • يحدد تاريخ ووقت تحديد خادم الأصل لآخر تعديل للمورد. على سبيل المثال، Last-Modified: Thu, 19 Oct 2017 09:28:00 GMT
  • بالنسبة للمحتوى الأكبر من 8 ميغابايت، يجب أن تحتفظ خوادم الخلفية الأصلية بالطوابع الزمنية المتسقة Last-Modified لكل أصل. سيؤدي إرجاع أوقات غير متناسقة Last-Modified من خوادم الواجهة الخلفية إلى حدوث أخطاء عدم تطابق المدقق ويؤدي إلى فشل HTTP 5XX. قد لا يدعم Azure Storage الطوابع الزمنية المتسقة Last-Modified عبر النسخ المتماثلة، مما قد يتسبب في أخطاء عدم تطابق المدقق المماثلة.
  • تتحقق ذاكرة التخزين المؤقت من صحة ملف يستخدم Last-Modified عن طريق إرسال رأس If-Modified-Since مع تاريخ ووقت في الطلب. يقارن خادم الأصل هذا التاريخ مع الرأس Last-Modified لأحدث مورد. إذا لم يتم تعديل المورد منذ الوقت المحدد، يقوم الخادم بإرجاع رمز الحالة 304 (غير معدل) في استجابته. إذا تم تعديل المورد، يقوم الخادم بإرجاع رمز الحالة 200‏ (OK) والمورد المُحدث.

تحديد الملفات التي يمكن تخزينها مؤقتًا

لا يمكن تخزين جميع الموارد مؤقتًا. يوضح الجدول التالي الموارد التي يمكن تخزينها مؤقتًا، استنادًا إلى نوع استجابة HTTP. لا يمكن تخزين الموارد التي تم تسليمها مع استجابات HTTP التي لا تفي بجميع هذه الشروط مؤقتا. بالنسبة إلى Azure CDN Premium من Edgio فقط، يمكنك استخدام محرك القواعد لتخصيص بعض هذه الشروط.

Azure Content Delivery Network من Microsoft Azure Content Delivery Network من Edgio
رموز حالة HTTP 200, 203, 206, 300, 301, 410, 416 200
أساليب HTTP GET، وHEAD GET
حدود حجم الملف 300 جيجابايت 300 جيجابايت

لكي يعمل التخزين المؤقت في Azure CDN Standard من Microsoft على مورد، يجب أن يدعم خادم الأصل أي طلبات HTTP لـ HEAD وGET ويجب أن تكون قيم طول المحتوى هي نفسها لأي استجابات HTTP لـ HEAD وGET للأصل. بالنسبة لطلب HEAD، يجب أن يدعم خادم الأصل طلب HEAD، ويجب أن يستجيب بنفس العناوين كما لو أنه تلقى طلب GET.

سلوك التخزين المؤقت الافتراضي

يصف الجدول التالي سلوك التخزين المؤقت الافتراضي لمنتجات Azure Content Delivery Network وتحسيناتها.

Microsoft: تسليم الويب العام Edgio: تسليم ويب عام Edgio: DSA
أصل Honor ‏‏نعم‬ نعم لا
مدة ذاكرة التخزين المؤقت لشبكة تسليم المحتوى يومان سبعة أيام بلا

أصل Honor: يحدد ما إذا كان يجب قبول رؤوس توجيه ذاكرة التخزين المؤقت المدعومة إذا كانت موجودة في استجابة HTTP من خادم الأصل.

مدة ذاكرة التخزين المؤقت ل CDN: تحدد مقدار الوقت الذي يتم تخزين المورد مؤقتا على شبكة تسليم محتوى Azure. ومع ذلك، إذا كان أصل Honor هو نعم وكانت استجابة HTTP من خادم الأصل تتضمن رأس Expires توجيه ذاكرة التخزين المؤقت أو Cache-Control: max-age، تستخدم شبكة تسليم محتوى Azure قيمة المدة المحددة بواسطة العنوان بدلا من ذلك.

إشعار

لا تقدم Azure Content Delivery Network أي ضمانات حول الحد الأدنى من الوقت الذي سيتم فيه تخزين الكائن في ذاكرة التخزين المؤقت. قد يتم إخلاء المحتويات المخزنة مؤقتا من ذاكرة التخزين المؤقت لشبكة تسليم المحتوى قبل انتهاء صلاحيتها إذا لم يتم طلب المحتويات بشكل متكرر لتوفير مساحة للمحتويات المطلوبة بشكل متكرر.

الخطوات التالية