Share via

استكشاف أخطاء اتصال بوابة Azure NAT وإصلاحها

  • مقالة

توفر هذه المقالة إرشادات حول كيفية استكشاف مشكلات الاتصال الصادر الشائعة وحلها باستخدام بوابة NAT. توفر هذه المقالة أيضا أفضل الممارسات حول كيفية تصميم التطبيقات لاستخدام الاتصالات الصادرة بكفاءة.

انخفاض توفر مسار البيانات على بوابة NAT مع فشل الاتصال

السيناريو

لاحظت انخفاض في توفر مسار البيانات لبوابة NAT، والذي يتزامن مع فشل الاتصال.

الأسباب المحتملة

  • استنفاد منفذ ترجمة عناوين الشبكة المصدر (SNAT).

  • حدود اتصال SNAT المتزامنة.

  • مهلات الاتصال.

خطوات استكشاف الأخطاء وإصلاحها

  • تقييم صحة بوابة NAT عن طريق التحقق من مقياس توفر مسار البيانات.

  • تحقق من مقياس SNAT الاتصال ion Count وقسم حالة الاتصال حسب الاتصالات التي تمت محاولة إجراؤها وفشلها. تشير أكثر من صفر اتصالات فاشلة إلى استنفاد منفذ SNAT أو الوصول إلى حد عدد اتصالات SNAT لبوابة NAT.

  • تأكد من أن مقياس عدد الاتصالات ضمن الحدود عن طريق التحقق من مقياس إجمالي عدد الاتصال AT. تدعم بوابة NAT 50000 اتصال متزامن لكل عنوان IP إلى وجهة فريدة وما يصل إلى مليوني اتصال في المجموع. لمزيد من المعلومات، راجع أداء بوابة NAT.

  • تحقق من مقياس الحزم التي تم إسقاطها لأي قطرات حزمة تتوافق مع فشل الاتصال أو حجم الاتصال العالي.

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

الحلول الممكنة لاستنفاد منفذ SNAT أو الوصول إلى حدود الاتصال المتزامنة

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

  • وزّع بيئة التطبيق الخاصة بك عبر شبكات فرعية متعددة وتوفير مورد بوابة NAT لكل شبكة فرعية.

  • تحرير مخزون منفذ SNAT عن طريق تقليل مؤقت مهلة الخمول TCP إلى قيمة أقل. لا يمكن تعيين مؤقت مهلة خمول TCP على أقل من 4 دقائق.

  • ضع في اعتبارك أنماط الاستقصاء غير المتزامنة لتحرير موارد الاتصال لعمليات أخرى.

  • قم بإجراء اتصالات بخدمات Azure PaaS عبر العمود الفقري ل Azure باستخدام Private Link. يقوم الارتباط الخاص بتحرير منافذ SNAT للاتصالات الصادرة بالإنترنت.

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

إشعار

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

الحلول الممكنة لمهلات اتصال TCP

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

لا يلزم تمكين استمرار تشغيل TCP إلا من جانب واحد من الاتصال من أجل الحفاظ على استمرار الاتصال من كلا الجانبين. عند إرسال TCP keepalive من جانب واحد من الاتصال، يرسل الجانب الآخر تلقائيا حزمة إقرار (ACK). يتم بعد ذلك إعادة تعيين مؤقت مهلة الخمول على جانبي الاتصال.

إشعار

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

الحلول الممكنة لمهلات اتصال بروتوكول مخطط بيانات المستخدم (UDP)

يتم تعيين مهلة الخمول UDP إلى 4 دقائق وهي غير قابلة للتكوين. تمكين UDP keepalives لكلا الاتجاهين في تدفق الاتصال للحفاظ على اتصالات طويلة. عند تمكين UDP keepalive، يكون نشطا فقط لاتجاه واحد في الاتصال. لا يزال الاتصال الخاما وينتهى الوقت على الجانب الآخر من الاتصال. لمنع اتصال UDP من انتهاء مهلة الخمول، يجب تمكين استمرار تشغيل UDP لكلا الاتجاهين في تدفق الاتصال.

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

انخفاض توفر مسار البيانات على بوابة NAT ولكن لا يوجد فشل في الاتصال

السيناريو

ينخفض توفر مسار البيانات لبوابة NAT ولكن لا تتم ملاحظة أي اتصالات فاشلة.

السبب المحتمل

انخفاض عابر في توفر مسار البيانات بسبب الضوضاء في مسار البيانات.

خطوات استكشاف الأخطاء وإصلاحها

إذا لاحظت انخفاضا في توفر مسار البيانات دون أي تأثير على الاتصال الصادر، فقد يكون ذلك بسبب التقاط بوابة NAT ضوضاء عابرة في مسار البيانات.

إعداد تنبيه لإفلات توفر مسار البيانات أو استخدام Azure Resource Health للتنبيه على أحداث صحة بوابة NAT.

لا يوجد اتصال صادر بالإنترنت

السيناريو

لم تلاحظ أي اتصال صادر على بوابة NAT.

الأسباب المحتملة

  • التكوين الخاطئ لبوابة NAT.

  • تتم إعادة توجيه حركة مرور الإنترنت بعيدا عن بوابة NAT وإجبارها على الاتصال النفقي إلى جهاز ظاهري أو إلى وجهة محلية باستخدام VPN أو ExpressRoute.

  • يتم تكوين قواعد مجموعة أمان الشبكة (NSG) التي تمنع حركة مرور الإنترنت.

  • انخفاض توفر مسار بيانات بوابة NAT.

  • تكوين نظام أسماء المجالات (DNS) بشكل خاطئ.

خطوات استكشاف الأخطاء وإصلاحها

  • تحقق من تكوين بوابة NAT بعنوان IP عام واحد أو بادئة واحدة على الأقل ومرفقة بشبكة فرعية. لا تعمل بوابة NAT حتى يتم إرفاق IP عام وشبكة فرعية. لمزيد من المعلومات، راجع أساسيات تكوين بوابة NAT.

  • تحقق من جدول التوجيه للشبكة الفرعية المرفقة ببوابة NAT. أي حركة مرور 0.0.0.0/0 يتم فرض توجيهها نفقيا إلى جهاز ظاهري للشبكة (NVA) أو ExpressRoute أو بوابة VPN ستولي الأولوية على بوابة NAT. لمزيد من المعلومات، راجع كيفية تحديد Azure لمسار.

  • تحقق مما إذا كانت هناك أي قواعد NSG تم تكوينها لواجهة الشبكة على جهازك الظاهري التي تحظر الوصول إلى الإنترنت.

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

  • تحقق من إعدادات DNS إذا لم يتم حل DNS بشكل صحيح.

الحلول الممكنة لفقدان الاتصال الصادر

  • إرفاق عنوان IP عام أو بادئة ببوابة NAT. تأكد أيضا من إرفاق بوابة NAT بالشبكات الفرعية من نفس الشبكة الظاهرية. تحقق من أن بوابة NAT يمكنها الاتصال الصادر.

  • ضع في اعتبارك متطلبات توجيه نسبة استخدام الشبكة بعناية قبل إجراء أي تغييرات على مسارات نسبة استخدام الشبكة لشبكتك الظاهرية. تتجاوز المسارات المعرفة من قبل المستخدم (UDRs) التي ترسل نسبة استخدام الشبكة 0.0.0.0/0 إلى جهاز ظاهري أو بوابة شبكة ظاهرية بوابة NAT. راجع المسارات المخصصة لمعرفة المزيد حول كيفية تأثير المسارات المخصصة على توجيه حركة مرور الشبكة.

    لاستكشاف خيارات تحديث مسارات نسبة استخدام الشبكة على جدول توجيه الشبكة الفرعية، راجع:

  • تحديث قواعد أمان NSG التي تحظر الوصول إلى الإنترنت لأي من الأجهزة الظاهرية الخاصة بك. لمزيد من المعلومات، راجع إدارة مجموعات أمان الشبكة.

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

لا يتم استخدام IP العام لبوابة NAT للاتصال الصادر

السيناريو

يتم نشر بوابة NAT في شبكة Azure الظاهرية ولكن يتم استخدام عناوين IP غير المتوقعة للاتصالات الصادرة.

الأسباب المحتملة

  • التكوين الخاطئ لبوابة NAT.

  • اتصال نشط مع أسلوب اتصال خارجي آخر ل Azure مثل موازن تحميل Azure أو عناوين IP العامة على مستوى المثيل على الأجهزة الظاهرية. تستمر تدفقات الاتصال النشطة في استخدام عنوان IP العام السابق الذي تم تعيينه عند تأسيس الاتصال. عند نشر بوابة NAT، تبدأ الاتصالات الجديدة في استخدام بوابة NAT على الفور.

  • يتم استخدام عناوين IP الخاصة للاتصال بخدمات Azure بواسطة نقاط نهاية الخدمة أو الارتباط الخاص.

  • تأتي الاتصال لحسابات التخزين من نفس المنطقة مثل الجهاز الظاهري الذي تجري اتصالا منه.

  • تتم إعادة توجيه حركة مرور الإنترنت بعيدا عن بوابة NAT وإجبارها على الاتصال النفقي إلى NVA أو جدار الحماية.

كيفية استكشاف الأخطاء وإصلاحها

  • تحقق من أن بوابة NAT تحتوي على عنوان IP عام واحد على الأقل أو بادئة مقترنة وشبكة فرعية واحدة على الأقل.

  • تحقق مما إذا كان أي أسلوب اتصال صادر سابق، مثل موازن التحميل العام، لا يزال نشطا بعد نشر بوابة NAT.

  • تحقق مما إذا كانت الاتصالات التي يتم إجراؤها بخدمات Azure الأخرى تأتي من عنوان IP خاص في شبكة Azure الظاهرية.

  • تحقق مما إذا كان لديك ارتباط خاص أو نقاط نهاية خدمة ممكنة للاتصال بخدمات Azure الأخرى.

  • تأكد من وجود جهازك الظاهري في نفس منطقة تخزين Azure عند إجراء اتصال تخزين.

  • تحقق مما إذا كان عنوان IP العام المستخدم للاتصالات ينشأ من خدمة Azure أخرى داخل شبكة Azure الظاهرية، مثل الجهاز الظاهري للشبكة (NVA).

الحلول الممكنة ل IP العام لبوابة NAT غير مستخدمة للاتصال الصادر

  • إرفاق عنوان IP عام أو بادئة ببوابة NAT. تأكد من إرفاق بوابة NAT بالشبكات الفرعية من نفس الشبكة الظاهرية. تحقق من أن بوابة NAT يمكنها الاتصال الصادر.

  • اختبار وحل المشكلات المتعلقة بالأجهزة الظاهرية التي تحتفظ بعناوين IP القديمة ل SNAT من أسلوب اتصال صادر آخر من خلال:

    • تأكد من إنشاء اتصال جديد ومن عدم إعادة استخدام الاتصالات الموجودة في نظام التشغيل أو أن المستعرض يقوم بالتخزين المؤقت للاتصالات. على سبيل المثال، عند استخدام curl في PowerShell، تأكد من تحديد المعلمة -DisableKeepalive لفرض اتصال جديد. إذا كنت تستخدم مستعرضا، يمكن أيضا تجميع الاتصالات.

    • ليس من الضروري إعادة تشغيل جهاز ظاهري في شبكة فرعية تم تكوينها على بوابة NAT. ومع ذلك، إذا تم إعادة تمهيد جهاز ظاهري، فسيتم مسح حالة الاتصال. عند مسح حالة الاتصال، تبدأ جميع الاتصالات في استخدام عنوان IP لمورد بوابة NAT أو عناوينه. يعد هذا السلوك أحد الآثار الجانبية لإعادة تشغيل الجهاز الظاهري وليس مؤشرًا على ضرورة إعادة التشغيل.

    • إذا كنت لا تزال تواجه مشكلة، فافتح حالة دعم لمزيد من استكشاف الأخطاء وإصلاحها.

  • ستكون للمسارات المخصصة التي توجه نسبة استخدام الشبكة 0.0.0.0/0 إلى NVA الأسبقية على بوابة NAT لتوجيه نسبة استخدام الشبكة إلى الإنترنت. لجعل حركة مرور بوابة NAT توجه إلى الإنترنت بدلا من NVA، قم بإزالة المسار المخصص لنسبة استخدام الشبكة 0.0.0.0/0 التي تنتقل إلى الجهاز الظاهري. تستأنف نسبة استخدام الشبكة 0.0.0.0/0 باستخدام المسار الافتراضي إلى الإنترنت ويتم استخدام بوابة NAT بدلا من ذلك.

هام

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

  • تستخدم الخدمات التي يتم نشرها في نفس المنطقة مثل حساب تخزين Azure عناوين AZURE IP الخاصة للاتصال. لا يمكنك تقييد الوصول إلى خدمات Azure معينة استنادا إلى نطاق عناوين IP الصادرة العامة الخاصة بها. لمزيد من المعلومات، راجع قيود قواعد شبكة IP.
  • تستخدم نقاط نهاية الارتباط الخاص والخدمة عناوين IP الخاصة لمثيلات الجهاز الظاهري في شبكتك الظاهرية للاتصال بخدمات النظام الأساسي Azure بدلا من IP العام لبوابة NAT. استخدم Private Link للاتصال بخدمات Azure الأخرى عبر العمود الفقري ل Azure بدلا من الإنترنت باستخدام بوابة NAT.

إشعار

الارتباط الخاص هو الخيار الموصى به عبر نقاط تقديم الخدمة للوصول الخاص إلى خدمات Azure المستضافة.

فشل الاتصال في وجهة الإنترنت العامة

السيناريو

فشل اتصالات بوابة NAT إلى وجهات الإنترنت أو انتهاء مهلتها.

الأسباب المحتملة

  • جدار الحماية أو مكونات إدارة نسبة استخدام الشبكة الأخرى في الوجهة.

  • حد معدل واجهة برمجة التطبيقات الذي يفرضه جانب الوجهة.

  • تخفيف DDoS الحجمي أو تشكيل حركة مرور طبقة النقل.

  • تستجيب نقطة النهاية الوجهة بحزم مجزأة.

كيفية استكشاف الأخطاء وإصلاحها

  • تحقق من الاتصال بنقطة نهاية في نفس المنطقة أو في مكان آخر للمقارنة.

  • إجراء التقاط الحزمة من جانبي المصدر والوجهة.

  • انظر إلى عدد الحزم في المصدر والوجهة (إذا كانت متوفرة) لتحديد عدد محاولات الاتصال التي تم إجراؤها.

  • انظر إلى الحزم التي تم إسقاطها لمعرفة عدد الحزم التي تم إسقاطها بواسطة بوابة NAT.

  • تحليل الحزم. تشير حزم TCP مع حزم بروتوكول IP المجزأة إلى تجزئة IP. لا تدعم بوابة NAT تجزئة IP وبالتالي تفشل الاتصالات مع الحزم المجزأة.

  • تأكد من إدراج عنوان IP العام لبوابة NAT كما هو مسموح به في وجهات الشركاء مع جدران الحماية أو مكونات إدارة حركة المرور الأخرى.

الحلول المحتملة لفشل الاتصال في وجهة الإنترنت

  • تحقق من إدراج IP العام لبوابة NAT كما هو مسموح به في الوجهة.

  • إذا كنت تقوم بإنشاء حجم كبير أو اختبار معدل المعاملات، فاستكشف ما إذا كان تقليل المعدل يقلل من حدوث حالات الفشل.

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

فشل الاتصال في خادم FTP في الوضع النشط أو السلبي

السيناريو

ترى فشل الاتصال على خادم FTP عند استخدام بوابة NAT مع وضع FTP نشط أو سلبي.

الأسباب المحتملة

  • تم تمكين وضع FTP النشط.

  • يتم تمكين وضع FTP السلبي وتستخدم بوابة NAT أكثر من عنوان IP عام واحد.

الحل الممكن لوضع FTP النشط

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

في وضع FTP النشط، ينشئ العميل قناة الأمر وينشئ الخادم قناة البيانات.

بوابة NAT غير متوافقة مع وضع FTP النشط. يستخدم FTP النشط أمر PORT من عميل FTP الذي يخبر خادم FTP بعنوان IP والمنفذ للخادم لاستخدامه على قناة البيانات للاتصال مرة أخرى بالعميل. يستخدم الأمر PORT العنوان الخاص للعميل، والذي لا يمكن تغييره. نسبة استخدام الشبكة من جانب العميل هي SNATed بواسطة بوابة NAT للاتصالات المستندة إلى الإنترنت بحيث ينظر إلى الأمر PORT على أنه غير صالح من قبل خادم FTP.

الحل البديل لوضع FTP النشط هو استخدام وضع FTP الخامل بدلا من ذلك. ومع ذلك، من أجل استخدام بوابة NAT في وضع FTP الخامل، يجب إجراء بعض الاعتبارات .

الحل الممكن لوضع FTP السلبي

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

لا يعمل بروتوكول نقل الملفات الخاملة الصادرة لبوابة NAT مع عناوين IP عامة متعددة، اعتمادا على تكوين خادم FTP الخاص بك. عندما ترسل بوابة NAT ذات عناوين IP عامة متعددة نسبة استخدام الشبكة الصادرة، فإنها تحدد بشكل عشوائي أحد عناوين IP العامة الخاصة بها لعنوان IP المصدر. يفشل FTP عندما تستخدم قنوات البيانات والتحكم عناوين IP مختلفة المصدر، اعتمادا على تكوين خادم FTP.

لمنع حالات فشل اتصال FTP السلبية المحتملة، قم بالخطوات التالية:

  1. تحقق من إرفاق بوابة NAT بعنوان IP عام واحد بدلا من عناوين IP متعددة أو بادئة.

  2. تأكد من السماح لنطاق المنفذ السلبي من بوابة NAT بتمرير أي جدران حماية في نقطة النهاية الوجهة.

إشعار

يقلل تقليل كمية عناوين IP العامة على بوابة NAT الخاصة بك من مخزون منفذ SNAT المتاح لإجراء اتصالات صادرة وقد يزيد من خطر استنفاد منفذ SNAT. ضع في اعتبارك احتياجات اتصال SNAT قبل إزالة عناوين IP العامة من بوابة NAT. لا يوصى بتغيير إعدادات خادم FTP لقبول التحكم وحركة مرور مستوى البيانات من عناوين IP المصدر المختلفة.

تم حظر الاتصالات الصادرة على المنفذ 25

السيناريو

تعذر الاتصال الصادر ببوابة NAT على المنفذ 25 لحركة مرور بروتوكول نقل البريد البسيط (SMTP).

السبب

يحظر النظام الأساسي Azure اتصالات SMTP الصادرة على منفذ TCP 25 للأجهزة الظاهرية المنشورة. هذه الكتلة هي لضمان أمان أفضل لشركاء وعملاء Microsoft، وحماية النظام الأساسي ل Microsoft Azure، والتوافق مع معايير الصناعة.

استخدم خدمة ترحيل SMTP مصادق عليها لإرسال بريد إلكتروني من أجهزة Azure الظاهرية أو من Azure App Service. لمزيد من المعلومات، راجع استكشاف مشكلات اتصال SMTP الصادرة وإصلاحها.

المزيد من إرشادات استكشاف الأخطاء وإصلاحها

تسجيلات إضافية للشبكة

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

  • اختبر استجابة منفذ الفحص باستخدام ps ping من أحد الأجهزة الظاهرية الخلفية داخل الشبكة الظاهرية وسجل النتائج (مثال: ps ping 10.0.0.4:3389).

  • إذا لم يتم تلقي أي استجابة في اختبارات اختبار الاتصال هذه، فقم بتشغيل تتبع متزامن netsh على الجهاز الظاهري الخلفي، والجهاز الظاهري لاختبار الشبكة الظاهرية أثناء تشغيل PsPing ثم أوقف التتبع netsh .

أفضل ممارسات الاتصال الصادر

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

استخدم تجميع الاتصال

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

لتجميع اتصالات HTTP، راجع تجميع اتصالات HTTP باستخدام HttpClientFactory.

إعادة استخدام الاتصالات

بدلاً من إنشاء اتصالات TCP فردية وذرية لكل طلب، كون التطبيق الخاص بك لإعادة استخدام الاتصالات. ينتج عن إعادة استخدام الاتصال معاملات TCP أفضل من حيث الأداء وترتبط بشكل خاص ببروتوكولات مثل HTTP/1.1,، حيث تكون إعادة الاتصال هي الوضع الافتراضي. تنطبق إعادة الاستخدام هذه على البروتوكولات الأخرى التي تستخدم HTTP كوسيلة نقل مثل REST.

استخدام منطق إعادة المحاولة الأقل عدوانية

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

اعتمادا على مهلة الخمول المكونة، إذا كانت عمليات إعادة المحاولة عدوانية جدا، فلن يكون للاتصالات الوقت الكافي لإغلاق منافذ SNAT وتحريرها لإعادة استخدامها.

للحصول على إرشادات وأمثلة إضافية، راجع نمط إعادة المحاولة.

استخدام keepalives لإعادة تعيين مهلة الخمول الصادرة

لمزيد من المعلومات حول keepalives، راجع مهلة الخمول TCP.

عندما يكون ذلك ممكنًا، يجب استخدام Private Link للاتصال مباشرة من شبكاتك الظاهرية بخدمات النظام الأساسي لـ Azure من أجل تقليل الطلب على منافذ SNAT. قد يساعد تقليل الطلب على منافذ SNAT في تقليل مخاطر استنفاد منفذ SNAT.

لإنشاء ارتباط خاص، راجع أدلة التشغيل السريع التالية للبدء:

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

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

لمعرفة المزيد عن بوابة NAT، راجع: