التخزين المؤقت مع Azure Front Door
هام
سيتم إيقاف Azure Front Door (الكلاسيكي) في 31 مارس 2027. لتجنب أي تعطيل للخدمة، من المهم ترحيل ملفات تعريف Azure Front Door (الكلاسيكية) إلى مستوى Azure Front Door Standard أو Premium بحلول مارس 2027. لمزيد من المعلومات، راجع إيقاف Azure Front Door (الكلاسيكي).
Azure Front Door هي شبكة تسليم محتوى حديثة (CDN)، مع تسريع ديناميكي للموقع وقدرات موازنة التحميل. عند تكوين التخزين المؤقت على المسار الخاص بك، يتحقق موقع الحافة الذي يتلقى كل طلب من ذاكرة التخزين المؤقت الخاصة به للحصول على استجابة صالحة. يساعد التخزين المؤقت على تقليل مقدار نسبة استخدام الشبكة المرسلة إلى خادم الأصل. إذا لم تتوفر استجابة مخزنة مؤقتا، تتم إعادة توجيه الطلب إلى الأصل.
يدير كل موقع حافة Front Door ذاكرة التخزين المؤقت الخاصة به، وقد يتم تقديم الطلبات بواسطة مواقع حافة مختلفة. ونتيجة لذلك، قد لا تزال ترى بعض نسبة استخدام الشبكة تصل إلى أصلك، حتى إذا قمت بخدمة الاستجابات المخزنة مؤقتا.
يمكن أن يقلل التخزين المؤقت بشكل كبير من زمن الانتقال ويقلل الحمل على خوادم الأصل. ومع ذلك، لا يمكن لجميع أنواع نسبة استخدام الشبكة الاستفادة من التخزين المؤقت. تعد الأصول الثابتة مثل الصور وملفات CSS وJavaScript مثالية للتخزين المؤقت. بينما لا ينبغي تخزين الأصول الديناميكية، مثل نقاط نهاية واجهة برمجة التطبيقات المصادق عليها، مؤقتا لمنع تسرب المعلومات الشخصية. من المستحسن أن يكون لديك مسارات منفصلة للأصول الثابتة والديناميكية، مع تعطيل التخزين المؤقت للأخير.
تحذير
قبل تمكين التخزين المؤقت، راجع الوثائق العامة بدقة، واختبر جميع السيناريوهات الممكنة قبل تمكين التخزين المؤقت. كما هو ملاحظ سابقا، مع التكوين الخاطئ، يمكنك تخزين بيانات محددة للمستخدم عن غير قصد يمكن مشاركتها من قبل العديد من المستخدمين مما يؤدي إلى حوادث الخصوصية.
أساليب الطلب
الطلبات التي تستخدم أسلوب الطلب هي فقط قابلة GET
للتخزين المؤقت. يتم إجراء جميع أساليب الطلب الأخرى من خلال شبكة الاتصال.
تسليم الملفات الكبيرة
تقدم Azure Front Door ملفات كبيرة دون حد أقصى لحجم الملف. إذا تم تمكين التخزين المؤقت، يستخدم Front Door تقنية تسمى تقسيم الكائنات. عند طلب ملف كبير، يقوم Front Door باسترداد أجزاء أصغر من الملف من الأصل. بعد أن يتلقى Front Door طلب ملف كامل أو طلب ملف من نطاق بايت، تطلب بيئة Front Door الملف من الأصل في مجموعات من 8 ميغابايت.
بعد وصول المجموعة إلى بيئة Azure Front Door، يتم تخزينها مؤقتا وتقديمها على الفور للمستخدم. ثم يقوم Front Door بإحضار الجزء التالي بشكل متواز. يضمن هذا الجلب المسبق بقاء المحتوى سابق على المستخدم بمجموعة واحدة، ما يقلل من زمن الوصول. تستمر هذه العملية حتى تنزيل الملف بالكامل (إذا طلب ذلك) أو يغلق العميل الاتصال. لمزيد من المعلومات حول طلب نطاق البايت، اقرأ RFC 7233.
تخزن Front Door أي مجموعات أثناء استلامها حتى لا يحتاج الملف بأكمله إلى التخزين المؤقت على ذاكرة التخزين المؤقت لـ Front Door. يتم تقديم الطلبات اللاحقة لنطاقات الملفات أو البايت من ذاكرة التخزين المؤقت. إذا لم يتم تخزين جميع المجموعات مؤقتا، يتم استخدام الإحضار المسبق لطلب أجزاء من الأصل.
يعتمد هذا التحسين على قدرة الأصل على دعم طلبات نطاق البايت. إذا كان الأصل لا يدعم طلبات نطاق البايت، أو إذا لم يعالج طلبات النطاق بشكل صحيح، فإن هذا التحسين غير فعال.
عندما يستجيب الأصل لطلب برأس Range
، يجب أن يستجيب بإحدى الطرق التالية:
إرجاع استجابة نطاقية. يجب أن تستخدم الاستجابة رمز حالة HTTP 206. أيضا،
Content-Range
يجب أن يكون رأس الاستجابة موجودا، ويجب أن يتطابق مع الطول الفعلي للمحتوى الذي يرجعه الأصل. إذا لم يرسل أصلك رؤوس الاستجابة الصحيحة بقيم صالحة، فلا يقوم Azure Front Door بتخزين الاستجابة مؤقتا، وقد ترى سلوكا غير متناسق.تلميح
إذا كان الأصل يضغط الاستجابة، فتأكد من
Content-Range
تطابق قيمة العنوان مع الطول الفعلي للاستجابة المضغوطة.إرجاع استجابة غير نطاقية. إذا تعذر على الأصل معالجة طلبات النطاق، فيمكنه تجاهل
Range
العنوان وإرجاع استجابة غير مرتبة. تأكد من أن الأصل يرجع رمز حالة استجابة غير 206. على سبيل المثال، قد يرجع الأصل استجابة 200 OK.
إذا كان الأصل يستخدم ترميز النقل المقسم (CTE) لإرسال البيانات إلى Azure Front Door POP، فإن أحجام الاستجابة الأكبر من 8 ميغابايت غير مدعومة.
ضغط الملف
راجع تحسين الأداء عن طريق ضغط الملفات في Azure Front Door.
يمكن لخدمة Azure Front Door (الكلاسيكية) ضغط المحتوى على الحافة ديناميكيًا، مما ينتج عنه وقت استجابة أقل وأسرع لعملائك. لكي يكون الملف مؤهلاً للضغط، يجب تمكين التخزين المؤقت ويجب أن يكون الملف من نوع MIME ليكون مؤهلاً للضغط. حالياً، لا تسمح Front Door بتغيير هذه القائمة. القائمة الحالية هي:
- "application/eot"
- "application/font"
- "application/font-sfnt"
- "application/javascript"
- "application/json"
- "application/opentype"
- "application/otf"
- "application/pkcs7-mime"
- "application/truetype"
- "application/ttf",
- "application/vnd.ms-fontobject"
- "application/xhtml+xml"
- "application/xml"
- "application/xml+rss"
- "application/x-font-opentype"
- "application/x-font-truetype"
- "application/x-font-ttf"
- "application/x-httpd-cgi"
- "application/x-mpegurl"
- "application/x-opentype"
- "application/x-otf"
- "application/x-perl"
- "application/x-ttf"
- "application/x-javascript"
- "font/eot"
- "font/ttf"
- "font/otf"
- "font/opentype"
- "image/svg+xml"
- "text/css"
- "text/csv"
- "text/html"
- "text/javascript"
- "text/js"، "text/plain"
- "text/richtext"
- "text/tab-separated-values"
- "text/xml"
- "text/x-script"
- "text/x-component"
- "text/x-java-source"
بالإضافة إلى ذلك، يجب أن يتراوح حجم الملف أيضاً بين 1 كيلوبايت و8 ميغابايت.
ملفات التعريف هذه تدعم ترميزات الضغط التالية:
إذا كان الطلب يدعم ضغط gzip وBrotli، يكون لضغط Brotli الأسبقية.
عندما يحدد طلب أحد الأصول الضغط وينتج عن الطلب فقدان ذاكرة التخزين المؤقت، يقوم Azure Front Door (كلاسيكي) بضغط الأصل مباشرة على خادم POP. بعد ذلك، يُقدَّم الملف المضغوط من ذاكرة التخزين المؤقت. يتم إرجاع العنصر الناتج برأس استجابة Transfer-Encoding: chunked
.
إذا كان الأصل يستخدم ترميز النقل المقسم (CTE) لإرسال البيانات إلى Azure Front Door POP، فإن الضغط غير مدعوم.
إشعار
قد تُضغط طلبات النطاق إلى أحجام مختلفة. تتطلب Azure Front Door أن تكون قيم طول المحتوى هي نفسها لأي طلب GET HTTP. إذا أرسل العملاء طلبات نطاق البايت مع Accept-Encoding
العنوان الذي يؤدي إلى استجابة Origin بأطوال محتوى مختلفة، فسترجع Azure Front Door خطأ 503. يمكنك إما تعطيل الضغط على الأصل، أو إنشاء قاعدة محرك القواعد لإزالة Accept-Encoding
العنوان من طلب طلبات نطاق البايت.
سلوك سلسلة الاستعلام
باستخدام خدمة Azure Front Door، يمكنك التحكم في كيفية تخزين الملفات مؤقتا لطلب ويب يحتوي على سلسلة استعلام.
في طلب ويب مع سلسلة استعلام، سلسلة الاستعلام هي ذلك الجزء من الطلب الذي يحدث بعد علامة استفهام (?
). يمكن أن تحتوي سلسلة الاستعلام على زوج واحد أو أكثر من أزواج قيمة المفتاح، حيث يتم فصل اسم الحقل وقيمته بعلامة يساوي (=
). يُفصل كل زوج من أزواج قيم المفاتيح بعلامة العطف (&).
على سبيل المثال، يحتوي عنوان URL http://www.contoso.com/content.mov?field1=value1&field2=value2
على سلسلتي استعلام:
field1
، بقيمةvalue1
.field2
، بقيمةvalue2
.
إذا كان هناك أكثر من زوج واحد من قيم المفاتيح في سلسلة استعلام لطلب، فلن يكون ترتيبهم مهماً.
عند تكوين التخزين المؤقت، يمكنك تحديد كيفية معالجة ذاكرة التخزين المؤقت لسلاسل الاستعلام. يتم دعم السلوكيات التالية:
تجاهل سلسلة الاستعلام: في هذا الوضع، يمرر Azure Front Door سلاسل الاستعلام من العميل إلى الأصل في الطلب الأول ويخزن الأصل مؤقتا. تتجاهل الطلبات المستقبلية للأصل الذي يتم تقديمه من بيئة Front Door سلاسل الاستعلام حتى تنتهي صلاحية الأصل المخزن مؤقتا.
استخدام سلسلة الاستعلام: في هذا الوضع، يتم التعامل مع كل طلب بعنوان URL فريد، بما في ذلك سلسلة الاستعلام، كأصل فريد مع ذاكرة التخزين المؤقت الخاصة به. على سبيل المثال، يتم تخزين الاستجابة من الأصل لطلب لـ
www.example.ashx?q=test1
مؤقتاً في بيئة Front Door ويتم إرجاعها لذاكرة التخزين المؤقت التالية مع نفس سلسلة الاستعلام. يُخزن طلبwww.example.ashx?q=test2
مؤقتاً باعتباره أصل منفصل مع إعداد مدة البقاء خاصته.لا يهم ترتيب معلمات سلسلة الاستعلام. على سبيل المثال، إذا كانت بيئة Azure Front Door تتضمن استجابة مخزنة مؤقتا لعنصر URL
www.example.ashx?q=test1&r=test2
، أيضا تقديم طلب منwww.example.ashx?r=test2&q=test1
ذاكرة التخزين المؤقت.
تجاهل سلاسل الاستعلام المحددة وتضمين سلاسل الاستعلام المحددة: في هذا الوضع، يمكنك تكوين Azure Front Door لتضمين معلمات محددة أو استبعادها عند إنشاء مفتاح ذاكرة التخزين المؤقت.
على سبيل المثال، افترض أن مفتاح ذاكرة التخزين المؤقت الافتراضي هو
/foo/image/asset.html
، ويتم إجراء طلب إلى عنوان URLhttps://contoso.com/foo/image/asset.html?language=EN&userid=100&sessionid=200
. إذا كانت هناك قاعدة محرك قواعد لاستبعاد معلمةuserid
سلسلة الاستعلام، فسيكون/foo/image/asset.html?language=EN&sessionid=200
مفتاح ذاكرة التخزين المؤقت لسلسلة الاستعلام هو .
تكوين سلوك سلسلة الاستعلام على مسار Front Door.
تطهير ذاكرة التخزين المؤقت
راجع مسح ذاكرة التخزين المؤقت في Azure Front Door لمعرفة كيفية مسح ذاكرة التخزين المؤقت.
يقوم Azure Front Door بتخزين الأصول مؤقتاً حتى انتهاء مدة بقاء الأصل (TTL). عندما يطلب العميل أصلاً وتكون مدة البقاء (TTL) منتهية الصلاحية، تسترد بيئة Front Door نسخة محدثة جديدة من الأصل لخدمة الطلب ثم تخزن ذاكرة التخزين المؤقت التي جرى تحديثها.
أفضل ممارسة للتأكد من حصول المستخدمين دائماً على أحدث نسخة من أصولك هي إصدار أصولك لكل تحديث ونشرها كعناوين URL جديدة. ستبادر Front Door باسترداد الأصول الجديدة على الفور لطلبات العميل التالية. في بعض الأحيان قد ترغب في إزالة المحتوى المُخزَّن مؤقتاً من جميع عُقد الحافة وإجبارهم جميعاً لاسترداد الأصول المحدثة الجديدة. قد يكون السبب هو التحديثات التي أُجريت على تطبيق الويب خاصتك، أو التحديث السريع للأصول التي تحتوي على معلومات غير صحيحة.
حدد الأصول التي تريد إزالتها من عُقد الحافة. لمسح جميع الأصول، حدد إزالة الكل. وإلا، في المسار، أدخِل مسار كل أصل تريد إزالته.
تُعتمد هذه التنسيقات في قوائم المسارات المقرر إزالتها:
- إزالة مسار واحد: إزالة الأصول الفردية عن طريق تحديد المسار الكامل للأصل (دون البروتوكول والمجال)، مع ملحق الملف، على سبيل المثال، /pictures/strasbourg.png؛
- مسح حرف البدل: يمكنك استخدام علامة النجمة باعتبارها حرف بدل. بادر بمسح جميع المجلدات والمجلدات الفرعية والملفات الموجودة ضمن نقطة نهاية مع /* في المسار أو امسح جميع المجلدات الفرعية والملفات الموجودة ضمن مجلد معين عن طريق تحديد المجلد متبوعاً بـ /*، على سبيل المثال، /pictures/*.
- إزالة المجال الجذر: إزالة جذر نقطة النهاية مع "/" في المسار.
إشعار
إزالة المجالات البدل: لا ينطبق تحديد المسارات المخزنة مؤقتاً للإزالة كما نُوقِش في هذا القسم على أي مجالات لأحرف البدل مرتبطةً بـ Front Door. حالياً، لا ندعم إزالة مجالات أحرف البدل مباشرةً. يمكنك إزالة المسارات من مجالات فرعية معينة عن طريق تحديد ذلك المجال الفرعي المحدد ومسار الإزالة. على سبيل المثال، إذا كانت، Front Door تحتوي على *.contoso.com
، يمكنني تطهير أصول مجالي الفرعي foo.contoso.com
عن طريق كتابة foo.contoso.com/path/*
. في الوقت الحالي، يقتصر تحديد أسماء المضيف في مسار محتوى المسح على المجالات الفرعية لمجالات أحرف البدل، إن أمكن ذلك.
عمليات إزالة ذاكرة التخزين المؤقت على Front Door غير حساسة لحالة الأحرف. بالإضافة إلى ذلك، فهي سلسلة استعلام غير محددة، ما يعني أن إزالة عنوان URL يزيل كافة تباينات سلسلة الاستعلام منه.
انتهاء صلاحية ذاكرة التخزين المؤقت
يتم استخدام الترتيب التالي للرؤوس لتحديد المدة التي يتم فيها تخزين عنصر في ذاكرة التخزين المؤقت لدينا:
Cache-Control: s-maxage=<seconds>
Cache-Control: max-age=<seconds>
Expires: <http-date>
تشير بعض Cache-Control
قيم رأس الاستجابة إلى أن الاستجابة غير قابلة للتخزين المؤقت. تتضمن private
هذه القيم و no-cache
و.no-store
تحترم Front Door قيم العنوان هذه ولا تقوم بتخزين الاستجابات مؤقتا، حتى إذا تجاوزت سلوك التخزين المؤقت باستخدام محرك القواعد.
Cache-Control
إذا لم يكن العنوان موجودا على الاستجابة من الأصل، يحدد Front Door بشكل افتراضي مدة ذاكرة التخزين المؤقت بين يوم واحد وثلاثة أيام بشكل عشوائي.
إشعار
لا يمكن أن تتجاوز مدة انتهاء صلاحية ذاكرة التخزين المؤقت 366 يوما.
قد ترى REVALIDATED_HIT
في عنوان الاستجابة Cache-Control
. يشير هذا إلى أنه تمت إعادة التحقق من المحتوى المخزن مؤقتا في Azure Front Door مع خادم الأصل قبل تقديمه إلى العميل. يمكن أن يحدث هذا عند انتهاء صلاحية المحتوى المخزن مؤقتا، ولكن الخادم الأصلي يشير إلى أن المحتوى لم يتغير. في هذه الحالة، يتم تقديم المحتوى المخزن مؤقتا إلى العميل، ويتم إعادة تعيين انتهاء صلاحية ذاكرة التخزين المؤقت.
عناوين الطلبات
لا تتم إعادة توجيه رؤوس الطلبات التالية إلى الأصل عند تمكين التخزين المؤقت:
Content-Length
Transfer-Encoding
Accept
Accept-Charset
Accept-Language
إشعار
لن يتم تخزين الطلبات التي تتضمن عنوان التخويل مؤقتا.
رؤوس الردود
إذا كانت استجابة الأصل قابلة للتخزين المؤقت، تتم Set-Cookie
إزالة العنوان قبل إرسال الاستجابة إلى العميل. إذا كانت استجابة الأصل غير قابلة للتخزين المؤقت، فلن يقوم Front Door بتجريد العنوان. على سبيل المثال، إذا كانت استجابة الأصل تتضمن عنوانا Cache-Control
بقيمة max-age
يشير إلى Front Door أن الاستجابة قابلة للتخزين المؤقت، ويتم Set-Cookie
تجريد الرأس.
بالإضافة إلى ذلك، يرفق X-Cache
Front Door العنوان بجميع الاستجابات. X-Cache
يتضمن رأس الاستجابة إحدى القيم التالية:
TCP_HIT
أوTCP_REMOTE_HIT
: أول جزء 8 ميغابايت من الاستجابة هو الوصول إلى ذاكرة التخزين المؤقت، ويتم تقديم المحتوى من ذاكرة التخزين المؤقت Front Door.TCP_MISS
: أول جزء 8 ميغابايت من الاستجابة هو فقدان ذاكرة التخزين المؤقت، ويتم جلب المحتوى من الأصل.PRIVATE_NOSTORE
: لا يمكن تخزين الطلب مؤقتا لأنه تم تعيين عنوان استجابة التحكم في ذاكرة التخزين المؤقت إلى خاص أو بدون مخزن.CONFIG_NOCACHE
: تم تكوين الطلب لعدم التخزين المؤقت في ملف تعريف Front Door.
السجلات والتقارير
يتضمن سجل الوصول حالة ذاكرة التخزين المؤقت لكل طلب. تتضمن التقارير أيضا معلومات حول كيفية استخدام ذاكرة التخزين المؤقت ل Azure Front Door في التطبيق الخاص بك.
يتضمن سجل الوصول حالة ذاكرة التخزين المؤقت لكل طلب.
سلوك ذاكرة التخزين المؤقت ومدته
يمكنك تكوين سلوك ذاكرة التخزين المؤقت ومدتها في محرك القواعد. يتجاوز تكوين التخزين المؤقت لمحرك القواعد دائما تكوين المسار.
عند تعطيل التخزين المؤقت، لا يقوم Azure Front Door بتخزين محتويات الاستجابة مؤقتا، بغض النظر عن توجيهات استجابة الأصل.
عند تمكين التخزين المؤقت، يختلف سلوك ذاكرة التخزين المؤقت اعتمادا على قيمة سلوك ذاكرة التخزين المؤقت المطبقة بواسطة محرك القواعد:
- أصل الشرف: يحترم Azure Front Door دائما توجيه عنوان استجابة الأصل. إذا كان توجيه الأصل مفقودا، يقوم Azure Front Door بالتخزين المؤقت للمحتويات في أي مكان من يوم إلى ثلاثة أيام.
- التجاوز دائما: يتجاوز Azure Front Door دائما مدة ذاكرة التخزين المؤقت، ما يعني أنه يخزن محتويات مدة ذاكرة التخزين المؤقت مؤقتا متجاهلا القيم من توجيهات استجابة الأصل. ينطبق هذا السلوك فقط إذا كانت الاستجابة قابلة للتخزين المؤقت.
- تجاوز إذا كان الأصل مفقودا: إذا لم يرجع الأصل قيم TTL التخزين المؤقت، يستخدم Azure Front Door مدة ذاكرة التخزين المؤقت المحددة. ينطبق هذا السلوك فقط إذا كانت الاستجابة قابلة للتخزين المؤقت.
إشعار
- لا يقدم Azure Front Door أي ضمانات بشأن مقدار الوقت الذي يتم فيه تخزين المحتوى في ذاكرة التخزين المؤقت. يمكن إزالة المحتوى المخزن مؤقتا من تخزين الحافة المؤقت قبل انتهاء صلاحية المحتوى في حال عدم استخدام المحتوى بشكل متكرر. من الممكن لخدمة Front Door تقديم البيانات من ذاكرة التخزين المؤقت حتى في حال انتهاء مدة البيانات المخزنة مؤقتا. يمكن أن يساعد هذا السلوك موقعك على أن يظل متاحاً جزئياً عندما تكون أصولك غير متصلة بالإنترنت.
- قد تحدد الأصول عدم تخزين ردود معينة مؤقتاً باستخدام العنوان Cache-Control بقيمة no-cache، أو private، أو no-store. عند استخدامه في استجابة HTTP من الخادم الأصلي إلى Azure Front Door POPs، يدعم Azure Front Door توجيهات التحكم في ذاكرة التخزين المؤقت ويحترم سلوكيات التخزين المؤقت لتوجيهات التحكم في ذاكرة التخزين المؤقت في RFC 7234 - بروتوكول نقل النص التشعبي (HTTP/1.1): التخزين المؤقت (ietf.org).
يمكن تكوين سلوك ومدة ذاكرة التخزين المؤقت في كل من قاعدة تحويل مصمم Front Door ومحرك القواعد. يتجاوز تكوين التخزين المؤقت لمحرك القواعد دائما تكوين قاعدة توجيه مصمم Front Door.
عند تعطيل التخزين المؤقت، لا يقوم Azure Front Door (الكلاسيكي) بتخزين محتويات الاستجابة مؤقتا، بغض النظر عن توجيهات استجابة الأصل.
عند تمكين التخزين المؤقت، يختلف سلوك ذاكرة التخزين المؤقت لقيم مختلفة من استخدام المدة الافتراضية لذاكرة التخزين المؤقت.
- عند تعيين استخدام المدة الافتراضية لذاكرة التخزين المؤقت إلى نعم، يحترم Azure Front Door (الكلاسيكي) دائما توجيه عنوان استجابة الأصل. إذا كان توجيه الأصل مفقودا، يقوم Front Door بالتخزين المؤقت للمحتويات في أي مكان من يوم إلى ثلاثة أيام.
- عند تعيين استخدام المدة الافتراضية لذاكرة التخزين المؤقت إلى لا، يتجاوز Azure Front Door (الكلاسيكي) دائما مدة ذاكرة التخزين المؤقت (الحقول المطلوبة)، ما يعني أنه يخزن محتويات مدة ذاكرة التخزين المؤقت مؤقتا متجاهلا القيم من توجيهات استجابة الأصل.
إشعار
- لا تقدم خدمة Azure Front Door (الكلاسيكية) أية ضمانات بشأن مقدار الوقت الذي يخزن فيه المحتوى في ذاكرة التخزين المؤقت. يمكن إزالة المحتوى المخزن مؤقتا من تخزين الحافة المؤقت قبل انتهاء صلاحية المحتوى في حال عدم استخدام المحتوى بشكل متكرر. من الممكن لـ Azure Front Door تقديم البيانات من ذاكرة التخزين المؤقت حتى في حال انتهاء صلاحية البيانات المخزنة مؤقتا. يمكن أن يساعد هذا السلوك موقعك على أن يظل متاحاً جزئياً عندما تكون أصولك غير متصلة بالإنترنت.
- مدة ذاكرة التخزين المؤقت المحددة في قاعدة تحويل مصمم Front Door هو الحد الأدنى لمدة ذاكرة التخزين المؤقت. لن يعمل هذا التجاوز إذا كان رأس عنصر تحكم ذاكرة التخزين المؤقت من الأصل يحتوي على TTL أكبر من قيمة التجاوز.
الخطوات التالية
- تعرف على كيفية إنشاء خدمة Azure Front Door (الكلاسيكية).
- تعرف على كيفية عمل خدمة Azure Front Door (الكلاسيكية).
- تعرف أكثر عن شروط مطابقة مجموعة القواعد
- تعرف أكثر عن إجراءات مجموعة القواعد