لغز بروتوكول مصدر مصدر موازن التحميل … أدخل … بروتوكول الوكيل

كان هناك وقت كانت الديناصورات تجوب فيه الديناصورات الأرض؛ حيث بدأ البشر لأول مرة العمل بأدوات مثل الصخور وموازنات التحميل القائمة على الطبقة 4 DSR.

في ذلك الوقت، كانت هذه الأدوات مفيدة لأنه كان بإمكانك الوصول إلى الخوادم بواسطتها، وكانت مفيدة أيضاً لأنه كان من السهل التأكد من أن خادم التطبيق كان يقدم عنوان IP الفعلي للعميل.

يقع موازن التحميل بين العميل والتطبيق، لذا بالنظر إلى التطبيق، من هو المرسل؟ العميل (نعم، من فضلك) أم موازن التحميل؟

كان هذا الأمر سهلاً إلى حد ما، وكانت أمامك عدة خيارات متاحة لك.

وضع DSR – إرجاع الخادم المباشر.

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

لذلك أحب الديناصورات هذا النهج لأنه يستخدم موارد أقل على البنية التحتية، ويحصل التطبيق على عنوان IP الحقيقي للعميل

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

العيب الآخر هو أن LB ليس لديه أي فكرة عن مدى جودة أداء خادم التطبيق، لذلك من الصعب موازنة التحميل على الخوادم التي من المرجح أن تكون أكثر أداءً. سيستخدم ADC أسرع الخوادم استجابةً أو أقلها اتصالاً. (يمكن لرجل العصر الحجري تثبيت وكيل على خادم التطبيق للإبلاغ عن ذلك.) أو يمكن لمركز ADC استخدام SNMP للحصول على ذلك.

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

التالي

وضع البوابة

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

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

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

يتعلم الإنسان الزراعة واستخدام موازنة التحميل القائمة على البروكسي

في هذا الوقت تقريبًا، كانت الشبكات وسرعات وحدة المعالجة المركزية تزداد سرعتها، وبدأنا نشهد نهج البروكسي.

قررنا أن نكون واضحين ونبدأ في استخدام موازن التحميل كعنوان IP المصدر بدلاً من خداع خادم التطبيق. قمنا بذلك لأسباب عديدة، منها أداء TCP، والأمان، والقدرة على توفير خدمات إضافية على موازن التحميل.

إلا أن هذا الابتعاد عن الصيد بالصنارة كان له ثمن كبير وتحدٍ كبير.

كيف ترسل عنوان IP الخاص بالعميل إلى خادم التطبيق؟

لحسن الحظ، كان لدى HTTP القديم الجيد إجابة رائعة طالما كنت تستخدم HTTP.

رأس X_Forwarded_For Header – يسمح لك بوضع عنوان IP الخاص بالعميل في الرأس ثم إرساله.

لن أشرح هذا الأمر بتفصيل أكثر من اللازم لأنه واضح ومباشر إلى حد ما، ولكن يكفي القول إنه عنوان يمكن لأي شخص تعيينه بسهولة. أيضًا، يمكن أن يصبح الأمر معقدًا. على سبيل المثال، ماذا يحدث إذا تم إرسال موازن التحميل بالفعل X_Forwareded_For IP؟ هل يجب عليه استخدام ذلك أم استخدام عنوان IP المصدر وتغييره؟ عادةً ما يكون من الممكن تكوين هذه الأمور على LB لائق، ولكن جميعها لها اعتبارات أمنية، وما إلى ذلك.

على أي حال، 99% من الوقت، في أي وقت يحتاج فيه تطبيق الويب إلى المصدر، هذه هي الطريقة التي يحصلون عليها (ملاحظة: 99% من الإحصائيات مختلقة)

ماذا عن البروتوكولات الأخرى؟

هناك القليل منها يحتوي على بعض الاختراقات الخاصة بالبروتوكول، ولكن لا يوجد شيء عام معتمد على نطاق واسع.

حسنًا، كان ذلك حتى تم اقتراح بروتوكول الوكيل واعتماده على نطاق واسع.

شرح بروتوكول الوكيل

يحل بروتوكول الوكيل هذه المشكلة عن طريق إضافة رأس إلى الطلب المعاد توجيهه يحتوي على تفاصيل اتصال العميل الأصلي.

يوجد بالفعل نسختان من هذا البروتوكول.

• بروتوكول الوكيل v1: يستخدم تنسيقاً نصياً بسيطاً يمكن للبشر قراءته.
• بروتوكول الوكيل الإصدار 2: يستخدم تنسيقًا ثنائيًا، وهو أكثر كفاءة ويمكنه دعم ميزات إضافية مثل IPv6 وعناوين مقابس Unix.

ما هو مختلف هو أن معظم خوادم التطبيقات ستتعطل إذا قمت بتمكين ذلك دون تهيئتها لقبوله. وذلك لأن بروتوكول الوكيل يضيف حرفياً التفاصيل المطلوبة إلى بداية البيانات.

ومع ذلك، فإن اعتماد هذا النظام آخذ في الازدياد ويدعمه الآن العديد من البائعين.

إنه رائع لبروكسي DNS، على سبيل المثال.

كما هو الحال مع X_Forwardard_For، لا تزال هناك بعض القرارات التي يجب اتخاذها:

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

يعد بروتوكول الوكيل طريقة بسيطة للحصول على عنوان IP الخاص بالعميل وهو الآن مدعوم على نطاق واسع، لذا انطلق واستمتع.

سأعود للتفكير في التوافر العالي في السحابة السحابية