سؤال

لقد قرأت كتابًا ولدي سؤال معين حول فصل ETAG. يقول المؤلف أن ETAGs قد تضر بالأداء وأنه يجب عليك ضبطها بدقة أو تعطيلها تمامًا.

أنا أعرف بالفعل ما هي etags وفهم المخاطر ، ولكن هل من الصعب الحصول على etags بشكل صحيح؟

لقد قدمت للتو تطبيقًا يرسل ETAG قيمته هي تجزئة MD5 لجسم الاستجابة. هذا حل بسيط ، يسهل تحقيقه في العديد من اللغات.

  • هل استخدام md5 hash لجسم الاستجابة كخطأ etag؟ إذا كان الأمر كذلك لماذا؟

  • لماذا لا يقترح المؤلف (الذي يتفوق عليّ بوضوح العديد من أوامر الحجم) مثل هذا الحل البسيط؟

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

هل كانت مفيدة؟

المحلول

ETAG يشبه الرأس المعدل الأخير. إنها آلية لتحديد التغيير من قبل العميل.

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

الآن ، من الناحية الفنية ، فإن ETAG لديه دقة "لا حصر لها" مقارنة برأس آخر معدل. التغييرات المعدلة الأخيرة فقط عند الحبيبية من ثانية واحدة ، في حين أن ETAG يمكن أن تكون ثانية.

يمكنك تنفيذ كل من ETAG والمعدل الأخير ، أو ببساطة واحد أو آخر (أو لا شيء ، بالطبع). إذا لم تكن تعديلها الأخير غير كافٍ ، ففكر في ETAG.

ضع في اعتبارك ، لن أقوم بتعيين ETAG لمورد "كل". في الأساس ، لن أقوم بتعيينه على أي شيء لا يتوقع أن يتم تخزينه مؤقتًا (محتوى ديناميكي بشكل ملحوظ). ليس هناك فائدة من هذه الحالة ، فقط العمل الضائع.

تحرير: أرى تحريرك ، وأوضح.

MD5 بخير. الجانب السلبي الوحيد هو حساب MD5 طوال الوقت. تشغيل MD5 على ، على سبيل المثال ، ملف PDF 200k ، مكلف. إن تشغيل MD5 على مورد لا يتوقع أن يتم تخزينه مؤقتًا هو ببساطة مضيعة (أي المحتوى الديناميكي).

الحيلة هي ببساطة أنه مهما كانت الآلية التي تستخدمها ، يجب أن تكون رخيصة كما هو معدل آخر عادة. المعدل الأخير ، مرة أخرى ، عادةً ما يكون خاصية للموارد ، وعادة ما يكون رخيصًا جدًا للوصول.

يجب أن تكون etags رخيصة بالمثل. إذا كنت تستخدم MD5 ، ويمكنك تخزين/تخزين الارتباط بين المورد وتجزئة MD5 ، فهذا حل جيد. ومع ذلك ، فإن إعادة حساب MD5 في كل مرة تكون ETAG ضرورية ، تتعارض بشكل أساسي مع فكرة استخدام ETAGs لتحسين أداء الخادم العام.

نصائح أخرى

نحن نستخدم ETAGs لمحتوىنا الديناميكي في Instela.

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

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

لدينا صفحة رئيسية في Facebook Newsfeed Style تحتوي على محتوى مختلف لكل مستخدم. مع تغير محتوى Fromfeed 3-4 فقط في الساعة ، فإن تحديث الصفحة الرئيسية فعالة للغاية لجانب العميل. في عصر الهاتف المحمول ، أعتقد أنه من الأفضل قضاء وقت أكثر قليلاً من وحدة المعالجة المركزية من إنفاق النطاق الترددي. لا يزال النطاق الترددي أغلى من وحدة المعالجة المركزية ، وهي تجربة أفضل للعميل.

بعد عدم قراءة الكتاب ، لا يمكنني التحدث عن المخاوف الدقيقة للمؤلف.

ومع ذلك ، يجب أن يكون توليد ETAGs بحيث لا يتم إنشاء ETAG إلا مرة واحدة عندما تتغير الصفحة. توليد تجزئة MD5 لصفحة الويب تكاليف معالجة الطاقة والوقت على الخادم ؛ إذا كان لديك العديد من العملاء الذين يتصلون ، فقد يبدأ في التسبب في مشاكل في الأداء.

وبالتالي ، تحتاج إلى تقنية جيدة لتوليد etags فقط عند الضرورة والتخزين المؤقت لهم على الخادم حتى تتغير الصفحة ذات الصلة.

اعتقد ان perceived problem مع ETAGs ربما يكون متصفحك يجب أن يصدر ويحلل طلب / استجابة (بسيطة وصغيرة) لكل مورد على صفحتك للتحقق مما إذا كانت قيمة ETAG قد تغيرت جانب الخادم.

أنا شخصياً أجد هذه المستديرة الصغيرة الإضافية إلى الخادم مقبولة في كثير من الأحيان عن الصور ، CSS ، JavaScript (لا يحتاج الخادم إلى إعادة تقديم المحتوى إذا كان ETAG للمتصفح حاليًا) لأن الآلية تجعل من السهل تحديد محتوى "محدث".

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top