HTTP Negotiation
تتضمن معظم استجابات HTTP كيانًا يحتوي على معلومات للتفسير من قبل المستخدم. بطبيعة الحال
التاريخ
الدروس
المستوى
اللغة
المشاهدات
المواضيع
HTTP Negotiation
</> HTTP Negotiation
تتضمن معظم استجابات HTTP علي entity يحتوي على معلومات للتفسير من قبل المستخدم. وبطبيعة الحال ، يتم استخدامه لتزويد المستخدم بأفضل entity متاح يتوافق مع الطلب. لسوء الحظ بالنسبة لذاكرة التخزين المؤقت والخادم ، لا يمتلك جميع المستخدمين نفس التفضيلات لما هو أفضل. لهذا السبب يحتوي HTTP على أحكام للعديد من الآليات لـ "التفاوض على المحتوى". عندما يكون هناك العديد من التمثيلات المتاحة ، عملية اختيار أفضل تمثيل لاستجابة معينة. قد يخضع أي رد يحتوي على هيئة entity للتفاوض ، بما في ذلك الردود على الأخطاء. في HTTP ، يوجد نوعان من تفاوض المحتوى ، التفاوض الذي يعتمد على الخادم ، والتفاوض القائم على الوكيل. كلا المفاوضات متعامدة وبالتالي يمكن استخدامها معًا أو بشكل منفصل. يُشار إلى إحدى طرق الدمج بالمفاوضات الشفافة التي تحدث عندما يوفر الخادم الأصلي معلومات التفاوض الذي يحركه الوكيل ، والذي يتم استخدامه بواسطة ذاكرة التخزين المؤقت لتوفير تفاوض يحركه الخادم لـ
Server-driven Negotiation
</> Server-driven Negotiation
عند حدوث تفاوض يحركه الخادم ، يتم اختيار أفضل تمثيل للاستجابة بواسطة خوارزمية موجودة على الخادم. استنادًا إلى التمثيل المتاح للمورد ، يعتمد الاختيار والمحتويات. يعتمد التحديد أيضًا على محتويات entity-header معينة في رسالة الطلب request أو على معلومات أخرى ، والتي تتظاهر بالطلب (مثل عنوان شبكة العميل).
</> Advantages
- يكون مفيدًا عندما يصعب وصف خوارزمية الاختيار من بين التمثيلات المتاحة لوكيل المستخدم.
- يكون مفيدًا عندما يرغب الخادم في إرسال "أفضل تخمين" إلى العميل مع الاستجابة الأولى.
- لتحسين تخمين الخادم ، قد يقوم وكيل المستخدم بتضمين request header fields التي تصف تفضيلاته لمثل هذه الاستجابة.
</> Disadvantages
- بالنسبة للخادم ، من المستحيل تحديد ما هو الأفضل لأي مستخدم معين بدقة. لهذا السبب سيحتاج الخادم إلى معرفة كاملة بكل من قدرات وكيل المستخدم والاستخدام المقصود للاستجابة
- يعقد تنفيذ خادم الأصل والخوارزميات لتوليد استجابات للطلب.
Agent-driven Negotiation
</> Agent-driven Negotiation
للتفاوض القائم على الخادم بعض العيوب: فهو لا يتسع بشكل جيد. يتم استخدام header واحد لكل ميزة في التفاوض. إذا كنت تريد استخدام حجم الشاشة أو الدقة أو أبعاد أخرى ، فأنت بحاجة إلى إنشاء HTTP header جديد. يجب بعد ذلك إرسال headers مع كل طلب. هذه ليست مشكلة إذا كان هناك عدد قليل من العناوين فقط ، ولكن مع زيادة عدد headers ، قد يؤثر حجم الرسالة في النهاية على الأداء. كلما تم إرسال headers بشكل أكثر دقة ، مما يسمح بمزيد من بصمات HTTP ومخاوف الخصوصية المقابلة. يسمح HTTP بنوع تفاوض آخر: التفاوض القائم على الوكيل أو التفاوض التفاعلي. في هذه الحالة ، يرسل الخادم مرة أخرى صفحة تحتوي على ارتباطات إلى الموارد البديلة المتاحة عند مواجهة طلب غامض. يتم تقديم الموارد للمستخدم ويختار المصدر الذي سيستخدمه.
</> Advantages
- يتم استخدامه عندما تختلف الاستجابة حسب الأبعاد شائعة الاستخدام عندما يكون الخادم الأصلي غير قادر على تحديد قدرة وكيل المستخدم على فحص الطلب.
- يتم استخدامه عندما توزع ذاكرات التخزين المؤقت العامة تحميل الخادم وتقليل استخدام الشبكة.
</> Disadvantages
يعاني التفاوض الذي يحركه الوكيل عندما يحتاج إلى طلب ثان للحصول على أفضل تمثيل بديل.
تفاوض HTTP
تفاوض
كيان
تفاوض يحركها الخادم
عنوان الكيان
طلب
مزايا
عيوب
تفاوض قائم على وكيل
عناوين
CLOSETAG
منصة كلوز تاج التعليمية المتخصصة في تعلم البرمجة. نسعى لتقديم تجربة تعلم فريدة من خلال معسكراتنا العملية والمنظمة والمتسلسلة. نهدف إلى تقليص الفجوة بين النظرية والتطبيق العملي، لذا فإننا نركز على التعلم القائم على المشاريع والتطبيقات الحقيقية. ننقل لك سنوات من الخبرة في أقل وقت ممكن. هذه الخبرة ننقلها لك تحت إشراف مهندسين العباقرة عملوا في أكبر الشركات العربية والعالمية في مجال البرمجة. مهمتنا ليست فقط تعليم البرمجة، بل نسعى أيضًا لتزويدك بمجموعة من المهارات التي تتوافق مع احتياجات سوق العمل.
