إعادة تعيين TCP موازن التحميل ومهلة الخمول

  • مقالة

يمكنك استخدام Standard Load Balancer لإنشاء سلوك تطبيق أكثر قابلية للتنبؤ للسيناريوهات الخاصة بك عن طريق تمكين TCP Reset on Idle لقاعدة معينة. السلوك الافتراضي لـ Load Balancer هو إسقاط التدفقات بصمت عند الوصول إلى مهلة الخمول للتدفق. يؤدي تمكين إعادة تعيين TCP إلى قيام Load Balancer بإرسال عمليات إعادة تعيين TCP ثنائية الاتجاه (حزم TCP RST) على مهلة الخمول لإعلام نقاط نهاية التطبيق بأن مهلة الاتصال لم تعد قابلة للاستخدام. يمكن لنقاط النهاية إنشاء اتصال جديد سريع إذا لزم الأمر.

Diagram shows default TCP reset behavior of network nodes.

إعادة تعيين TCP

يمكنك تغيير هذا السلوك الافتراضي وتمكين إرسال عمليات إعادة تعيين TCP في مهلة الخمول على قواعد NAT الواردة، وقواعد موازنة التحميل، و القواعد الصادرة . عند التمكين لكل قاعدة، يرسل Load Balancer عمليات إعادة تعيين TCP ثنائية الاتجاه (حزم TCP RST) إلى كل من نقاط نهاية العميل والخادم في وقت انتهاء مهلة الخمول لجميع التدفقات المطابقة.

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

بالنسبة للعديد من السيناريوهات، يمكن أن تقلل إعادة تعيين TCP من الحاجة إلى إرسال TCP (أو طبقة التطبيق) إلى keepalives لتحديث مهلة الخمول للتدفق.

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

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

مهلة خمول TCP قابلة للتكوين

يحتوي Azure Load Balancer على نطاق مهلة من 4 دقائق إلى 100 دقيقة لقواعد Load Balancer والقواعد الصادرة وقواعد NAT الواردة. الإعداد الافتراضي هو 4 دقائق. إذا كانت فترة عدم النشاط أطول من قيمة المهلة، فليس هناك ما يضمن الحفاظ على جلسة TCP أو HTTP بين العميل والخدمة السحابية.

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

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

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

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

ترتيب الأسبقية

من المهم أن تأخذ في الاعتبار كيف يمكن أن تتفاعل قيم مهلة الخمول التي تم تعيينها ل IPs مختلفة.

وارد

  • إذا كانت هناك قاعدة موازن تحميل (واردة) مع تعيين قيمة مهلة الخمول بشكل مختلف عن مهلة الخمول لعنون IP الأمامي الذي تشير إليه، فإن مهلة الخمول ل IP للواجهة الأمامية لموازن التحميل لها الأسبقية.
  • إذا كانت هناك قاعدة NAT واردة مع تعيين قيمة مهلة الخمول بشكل مختلف عن مهلة الخمول لعنون IP الأمامي الذي تشير إليه، فإن مهلة الخمول للواجهة الأمامية لموازن التحميل لها الأسبقية.

صادر

  • إذا كانت هناك قاعدة صادرة مع قيمة مهلة الخمول مختلفة عن 4 دقائق (وهو ما يتم تأمين مهلة الخمول الصادرة IP العامة في)، فإن مهلة الخمول للقاعدة الصادرة لها الأسبقية.
  • نظرا لأن بوابة NAT ستكون لها دائما الأسبقية على القواعد الصادرة لموازن التحميل (وعلى عناوين IP العامة المعينة مباشرة إلى الأجهزة الظاهرية)، سيتم استخدام قيمة مهلة الخمول المعينة لبوابة NAT. (على طول نفس الخطوط، لا يتم النظر في مهلات الخمول الصادرة ل IP العامة المؤمنة التي تبلغ 4 دقائق من أي عناوين IP معينة إلى NAT GW.)

القيود

  • يتم إرسال إعادة تعيين TCP فقط أثناء اتصال TCP في حالة التأسيس.
  • لا تؤثر مهلة خمول TCP على قواعد موازنة التحميل على بروتوكول UDP.
  • لا يتم دعم إعادة تعيين TCP لمنافذ ILB HA عندما يكون الجهاز الظاهري للشبكة في المسار. قد يكون الحل البديل هو استخدام القاعدة الصادرة مع إعادة تعيين TCP من NVA.

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