مشاركة عبر


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

هام

سيتم إيقاف Azure CDN Standard من Microsoft (الكلاسيكي) في 30 سبتمبر 2027. لتجنب أي تعطيل للخدمة، من المهم ترحيل Azure CDN Standard من ملفات تعريف Microsoft (الكلاسيكية) إلى Azure Front Door Standard أو المستوى المتميز بحلول 30 سبتمبر 2027. لمزيد من المعلومات، راجع Azure CDN Standard من إيقاف Microsoft (الكلاسيكي).

تم إيقاف Azure CDN من Edgio في 15 يناير 2025. لمزيد من المعلومات، راجع الأسئلة المتداولة حول إيقاف Azure CDN من Edgio.

توفر هذه المقالة نظرة عامة على مفاهيم التخزين المؤقت العامة وكيفية استخدام 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 عناوين توجيه ذاكرة التخزين المؤقت HTTP التالية، والتي تحدد مدة ذاكرة التخزين المؤقت ومشاركة ذاكرة التخزين المؤقت.

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

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

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

  • عنوان قديم تم تقديمه في 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 من Microsoft فقط Last-Modified.

إشعار

لا يدعم ETagAzure CDN من Microsoft (الكلاسيكي) .

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

  • يحدد تاريخ ووقت تحديد خادم الأصل لآخر تعديل للمورد. على سبيل المثال، 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 التي لا تفي بجميع هذه الشروط مؤقتا.

‏‏شروط القيمة‬
رموز حالة HTTP 200, 203, 206, 300, 301, 410, 416
أساليب HTTP GET، وHEAD
حدود حجم الملف 300 جيجابايت

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

إشعار

لن يتم تخزين الطلبات التي تتضمن عنوان التخويل مؤقتا.

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

سلوك التخزين المؤقت الافتراضي ل Azure CDN هو تكريم الأصل ومحتوى ذاكرة التخزين المؤقت لمدة يومين.

أصل الشرف: يحدد هذا الإعداد ما إذا كان يجب احترام عناوين توجيه ذاكرة التخزين المؤقت (Cache-Control أو Expires) إذا كانت موجودة في استجابة HTTP من خادم الأصل.

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

إشعار

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

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