دليل استكشاف الأخطاء وإصلاحها للمشكلات الشائعة في خدمة Azure SignalR

هل هذه الصفحة مفيدة؟

هل لديك ملاحظات إضافية؟

سيتم إرسال الملاحظات إلى Microsoft: بالضغط على الزر «إرسال»، سيتم استخدام ملاحظاتك لتحسين منتجات Microsoft وخدماتها. نهج الخصوصية.

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

رمز الوصول طويل جدا

الأخطاء المحتملة

• من جانب العميل ERR_CONNECTION_
• 414 URI طويل جدا
• 413 حمولة كبيرة للغاية
• يجب ألا يزيد رمز الوصول عن 4K. 413 كيان الطلب كبير جدًا

السبب الجذري

بالنسبة إلى HTTP/2، يكون الحد الأقصى لطول رأس واحد هو 4 K، لذلك إذا كنت تستخدم المستعرض للوصول إلى خدمة Azure، فسيكون هناك خطأ ERR_CONNECTION_ في هذا القيد.

بالنسبة لعملاء HTTP/1.1 أو C # ، يبلغ الحد الأقصى لطول URI 12 K ، والحد الأقصى لطول الرأس هو 16 K.

باستخدام إصدار SDK 1.0.6 أو أعلى ، /negotiate سيتم رميه 413 Payload Too Large عندما يكون رمز الوصول الذي تم إنشاؤه أكبر من 4 K.

حل

بشكل افتراضي ، يتم تضمين المطالبات من عند إنشاء رمز وصول JWT إلى ASRS (Azure SignalRService) ، بحيث يتم الحفاظ على المطالبات ويمكن تمريرها منcontext.User.ClaimsASRS إلى Hub عندما يتصل العميل ب .Hub

في بعض الحالات ، يتم استخدامها لتخزين الكثير من المعلومات لخادم التطبيق ، context.User.Claims ومعظمها لا يتم استخدامه بواسطة Hubs ولكن بواسطة مكونات أخرى.

يتم تمرير رمز الوصول الذي تم إنشاؤه عبر الشبكة ، وبالنسبة لاتصالات WebSocket / SSE ، يتم تمرير رموز الوصول عبر سلاسل الاستعلام. لذلك كأفضل ممارسة ، نقترح فقط تمرير المطالبات الضرورية من العميل من خلال ASRS إلى خادم التطبيق الخاص بك عندما يحتاج Hub.

هناك خيار ClaimsProvider لك لتخصيص المطالبات التي تنتقل إلى ASRS داخل رمز الوصول.

للنواة ASP.NET:

services.AddSignalR()
        .AddAzureSignalR(options =>
            {
                // pick up necessary claims
                options.ClaimsProvider = context => context.User.Claims.Where(...);
            });

ASP.NET:

services.MapAzureSignalR(GetType().FullName, options =>
            {
                // pick up necessary claims
                options.ClaimsProvider = context.Authentication?.User.Claims.Where(...);
            });

هل لديك مشكلات أو ملاحظات حول استكشاف الأخطاء وإصلاحها؟ أبلغنا بها.

TLS 1.2 مطلوب

الأخطاء المحتملة

• ASP.NET الخطأ #279 "لا يتوفر خادم"
• ASP.NET "الاتصال غير نشط ، لا يمكن إرسال البيانات إلى الخدمة." الخطأ #324
• "حدث خطأ أثناء تقديم طلب HTTP إلى https://<API endpoint>. قد يكون هذا الخطأ بسبب عدم تكوين شهادة الخادم بشكل صحيح مع HTTP.SYS في حالة HTTPS. يمكن أن يحدث هذا الخطأ أيضا بسبب عدم تطابق ارتباط الأمان بين العميل والخادم."

السبب الجذري

تدعم خدمة Azure TLS1.2 فقط للمخاوف الأمنية. باستخدام .NET Framework ، من الممكن ألا يكون TLS1.2 هو البروتوكول الافتراضي. ونتيجة لذلك، لا يمكن تأسيس اتصالات الخادم إلى ASRS بنجاح.

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

1. إذا كان من الممكن إعادة إنتاج هذا الخطأ محليا ، فقم بإلغاء تحديد Just My Code ورمي جميع استثناءات CLR وتصحيح أخطاء خادم التطبيق محليا لمعرفة الاستثناء الذي يطرحه.

   • قم بإلغاء تحديد الرمز الخاص بي فقط

     

   • رمي استثناءات CLR

     

   • راجع الاستثناءات التي يتم طرحها عند تصحيح أخطاء التعليمات البرمجية من جانب خادم التطبيق:

     

2. بالنسبة ASP.NET ، يمكنك أيضا إضافة التعليمة البرمجية التالية إلى التعليمات البرمجية الخاصة بك Startup.cs لتمكين التتبع التفصيلي ورؤية الأخطاء من السجل.

   app.MapAzureSignalR(this.GetType().FullName);
   // Make sure this switch is called after MapAzureSignalR
   GlobalHost.TraceManager.Switch.Level = SourceLevels.Information;
   

حل

قم بإضافة التعليمة البرمجية التالية إلى بدء التشغيل:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

هل لديك مشكلات أو ملاحظات حول استكشاف الأخطاء وإصلاحها؟ أبلغنا بها.

400 طلب غير صحيح تم إرجاعه لطلبات العملاء

السبب الجذري

تحقق مما إذا كان طلب العميل يحتوي على سلاسل استعلام متعددة hub . hub هي معلمة استعلام محفوظة وسيتم طرح 400 إذا اكتشفت الخدمة أكثر من واحد hub في الاستعلام.

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

401 إرجاع غير مصرح به لطلبات العملاء

السبب الجذري

حاليا القيمة الافتراضية لعمر الرمز المميز JWT هي 1 ساعة.

بالنسبة ASP.NET Core SignalR ، عندما يستخدم نوع نقل WebSocket ، فلا بأس به.

بالنسبة ASP.NET نوع النقل الآخر ل Core SignalR ، SSE والاقتراع الطويل ، فهذا يعني افتراضيا أن الاتصال يمكن أن يستمر على الأكثر لمدة 1 ساعة.

بالنسبة ASP.NET SignalR ، يرسل /ping العميل طلب KeepAlive إلى الخدمة من وقت لآخر ، عندما /ping يفشل ، يقوم العميل بإجهاض الاتصال وعدم إعادة الاتصال أبدا. هذا يعني ، بالنسبة ASP.NET SignalR ، أن عمر الرمز المميز الافتراضي يجعل الاتصال يستمر لمدة 1 ساعة على الأكثر لجميع أنواع النقل.

حل

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

تحقق هنا من كيفية إعادة تشغيل اتصالات العميل.

هل لديك مشكلات أو ملاحظات حول استكشاف الأخطاء وإصلاحها؟ أبلغنا بها.

تم إرجاع 404 لطلبات العملاء

بالنسبة للاتصال المستمر ب SignalR ، فإنه أولا /negotiate بخدمة Azure SignalR ثم ينشئ الاتصال الحقيقي بخدمة Azure SignalR.

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

• متابعة كيفية عرض الطلبات الصادرة للحصول على الطلب من العميل إلى الخدمة.
• تحقق من عنوان URL للطلب عند حدوث 404. إذا كان عنوان URL يستهدف تطبيق الويب الخاص بك ، ومشابها {your_web_app}/hubs/{hubName}، فتحقق مما إذا كان العميل SkipNegotiation .true عند استخدام Azure SignalR، يتلقى العميل عنوان URL لإعادة التوجيه عند التفاوض لأول مرة مع خادم التطبيق. يجب على العميل عدم تخطي التفاوض عند استخدام Azure SignalR.
• يمكن أن يحدث 404 آخر عند معالجة طلب الاتصال بعد /negotiate أكثر من 5 ثوان من استدعائه. تحقق من الطابع الزمني لطلب العميل ، وافتح مشكلة لنا إذا كان الطلب إلى الخدمة بطيئا في الاستجابة.

هل لديك مشكلات أو ملاحظات حول استكشاف الأخطاء وإصلاحها؟ أبلغنا بها.

تم إرجاع 404 لطلب إعادة الاتصال ASP.NET SignalR

على سبيل ASP.NET SignalR ، عندما ينقطع اتصال العميل ، فإنه يعيد الاتصال باستخدام نفس الشيء connectionId لمدة ثلاث مرات قبل إيقاف الاتصال. /reconnect يمكن أن يساعد إذا تم إسقاط الاتصال بسبب مشكلات /reconnect متقطعة في الشبكة يمكنها إعادة إنشاء الاتصال المستمر بنجاح. في ظل ظروف أخرى ، على سبيل المثال ، يتم إسقاط اتصال العميل بسبب إسقاط اتصال الخادم الموجه ، أو تحتوي خدمة SignalR على بعض الأخطاء الداخلية مثل إعادة تشغيل المثيل / تجاوز الفشل / النشر ، ولم يعد الاتصال موجودا ، وبالتالي /reconnect يعود 404. هذا هو السلوك المتوقع وبعد /reconnect ثلاث مرات إعادة محاولة توقف الاتصال. نقترح وجود منطق إعادة تشغيل الاتصال عند توقف الاتصال.

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

429 (عدد كبير جدا من الطلبات) تم إرجاعه لطلبات العملاء

هناك حالتان.

يتجاوز عدد الاتصالات المتزامنة الحد الأقصى

بالنسبة للمثيلات المجانية، يكون حد عدد الاتصالات المتزامنة 20 بالنسبة للمثيلاتالقياسية، يكون حد عدد التوصيلات المتزامنةلكل وحدة هو 1 K، مما يعني أن Unit100 تسمح باتصالات متزامنة 100-K.

تتضمن الاتصالات اتصالات العميل والخادم. تحقق هنا لمعرفة كيفية حساب الاتصالات.

الكثير من طلبات التفاوض في نفس الوقت

نقترح وجود تأخير عشوائي قبل إعادة الاتصال ، تحقق هنا من عينات إعادة المحاولة.

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

خطأ 500 عند التفاوض: خدمة Azure SignalR غير متصلة بعد، يرجى المحاولة مرة أخرى لاحقا

السبب الجذري

يتم الإبلاغ عن هذا الخطأ عند عدم وجود اتصال خادم بخدمة Azure SignalR متصلة.

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

قم بتمكين التتبع من جانب الخادم لمعرفة تفاصيل الخطأ عندما يحاول الخادم الاتصال بخدمة Azure SignalR.

تمكين التسجيل من جانب الخادم ل ASP.NET Core SignalR

يتكامل التسجيل من جانب الخادم ل ASP.NET Core SignalR مع ILoggerالتسجيل المستند المقدم في إطار عمل ASP.NET Core. يمكنك تمكين التسجيل من جانب الخادم باستخدام ConfigureLogging، استخدام عينة كما يلي:

.ConfigureLogging((hostingContext, logging) =>
        {
            logging.AddConsole();
            logging.AddDebug();
        })

تبدأ فئات المسجل ل Azure SignalR دائما ب Microsoft.Azure.SignalR. لتمكين السجلات التفصيلية من Azure SignalR، قم بتكوين البادئات السابقة لتصل إلى Debug المستوى في ملف appsettings.json كما هو موضح أدناه:

{
    "Logging": {
        "LogLevel": {
            ...
            "Microsoft.Azure.SignalR": "Debug",
            ...
        }
    }
}

تمكين عمليات التتبع من جانب الخادم ASP.NET SignalR

عند استخدام إصدار >SDK = 1.0.0، يمكنك تمكين عمليات التتبع عن طريق إضافة ما يلي إلى web.config: (التفاصيل)

<system.diagnostics>
    <sources>
      <source name="Microsoft.Azure.SignalR" switchName="SignalRSwitch">
        <listeners>
          <add name="ASRS" />
        </listeners>
      </source>
    </sources>
    <!-- Sets the trace verbosity level -->
    <switches>
      <add name="SignalRSwitch" value="Information" />
    </switches>
    <!-- Specifies the trace writer for output -->
    <sharedListeners>
      <add name="ASRS" type="System.Diagnostics.TextWriterTraceListener" initializeData="asrs.log.txt" />
    </sharedListeners>
    <trace autoflush="true" />
  </system.diagnostics>

هل لديك مشكلات أو ملاحظات حول استكشاف الأخطاء وإصلاحها؟ أبلغنا بها.

انقطاع اتصال العميل

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

الأخطاء المحتملة التي تظهر من جانب العميل

• The remote party closed the WebSocket connection without completing the close handshake
• Service timeout. 30.00ms elapsed without receiving a message from service.
• {"type":7,"error":"Connection closed with an error."}
• {"type":7,"error":"Internal server error."}

السبب الجذري

يمكن أن تنخفض اتصالات العميل في ظل ظروف مختلفة:

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

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

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

هل لديك مشكلات أو ملاحظات حول استكشاف الأخطاء وإصلاحها؟ أبلغنا بها.

يزداد اتصال العميل باستمرار

قد يكون سببه الاستخدام غير السليم لاتصال العميل. إذا نسي شخص ما إيقاف / التخلص من عميل SignalR ، فسيظل الاتصال مفتوحا.

الأخطاء المحتملة التي تظهر من مقاييس SignalR الموجودة في قسم المراقبة في قائمة موارد مدخل Azure

ترتفع اتصالات العملاء باستمرار لفترة طويلة في مقاييس Azure SignalR.

السبب الجذري

لا يتم استدعاء اتصال DisposeAsync عميل SignalR أبدا ، ويظل الاتصال مفتوحا.

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

تحقق مما إذا كان عميل SignalR لا يغلق أبدا .

حل

تحقق مما إذا كنت تغلق الاتصال. اتصل HubConnection.DisposeAsync() يدويا لإيقاف الاتصال بعد استخدامه.

على سبيل المثال:

var connection = new HubConnectionBuilder()
	.WithUrl(...)
	.Build();
try
{
	await connection.StartAsync();
	// Do your stuff
	await connection.StopAsync();
}
finally
{
	await connection.DisposeAsync();
}

الاستخدام غير السليم الشائع لاتصال العميل

مثال على دالة Azure

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

حل

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

هل لديك مشكلات أو ملاحظات حول استكشاف الأخطاء وإصلاحها؟ أبلغنا بها.

انقطاع اتصال الخادم

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

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

على أساس منتظم، هناك إصدارات جديدة لخدمة Azure SignalR، وأحيانا تصحيح أو ترقيات نظام التشغيل على مستوى Azure أو الانقطاع أحيانا عن خدماتنا التابعة. قد يؤدي ذلك إلى فترة قصيرة من انقطاع الخدمة ، ولكن طالما أن جانب العميل لديه آلية قطع الاتصال / إعادة الاتصال ، فإن التأثير يكون ضئيلا مثل أي سبب من جانب العميل يؤدي إلى قطع الاتصال وإعادة الاتصال.

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

الأخطاء المحتملة التي تظهر من جانب الخادم

• [Error]Connection "..." to the service was dropped
• The remote party closed the WebSocket connection without completing the close handshake
• Service timeout. 30.00ms elapsed without receiving a message from service.

السبب الجذري

يتم إغلاق اتصال خدمة الخادم بواسطة ASRS(Azure SignalRService).

بالنسبة لمهلة ping ، قد يكون سببها الاستخدام العالي لوحدة المعالجة المركزية أو تجويع تجمع مؤشرات الترابط على جانب الخادم.

بالنسبة ASP.NET SignalR ، تم إصلاح مشكلة معروفة في SDK 1.6.0. قم بترقية SDK إلى أحدث إصدار.

تجويع تجمع الخيوط

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

عادة، يحدث هذا السيناريو بسبب عدم المزامنة عبر المزامنة أو في Task.Result/Task.Wait() الأساليب غير المتزامنة.

راجع ASP.NET أفضل ممارسات الأداء الأساسية.

انظر المزيد عن تجويع تجمع الخيوط.

كيفية الكشف عن تجويع تجمع المواضيع

تحقق من عدد المواضيع. إذا لم تكن هناك طفرات في ذلك الوقت، فاتبع الخطوات التالية:

• إذا كنت تستخدم خدمة تطبيقات Azure، فتحقق من عدد سلاسل الرسائل في المقاييس. تحقق من التجميع Max :

  

• إذا كنت تستخدم .NET Framework، يمكنك العثور على مقاييس في شاشة الأداء في الجهاز الظاهري للخادم.

• إذا كنت تستخدم .NET Core في حاوية، فراجع تجميع التشخيصات في حاويات.

يمكنك أيضا استخدام التعليمات البرمجية للكشف عن تجويع تجمع مؤشرات الترابط:

public class ThreadPoolStarvationDetector : EventListener
{
    private const int EventIdForThreadPoolWorkerThreadAdjustmentAdjustment = 55;
    private const uint ReasonForStarvation = 6;

    private readonly ILogger<ThreadPoolStarvationDetector> _logger;

    public ThreadPoolStarvationDetector(ILogger<ThreadPoolStarvationDetector> logger)
    {
        _logger = logger;
    }

    protected override void OnEventSourceCreated(EventSource eventSource)
    {
        if (eventSource.Name == "Microsoft-Windows-DotNETRuntime")
        {
            EnableEvents(eventSource, EventLevel.Informational, EventKeywords.All);
        }
    }

    protected override void OnEventWritten(EventWrittenEventArgs eventData)
    {
        // See: https://docs.microsoft.com/en-us/dotnet/framework/performance/thread-pool-etw-events#threadpoolworkerthreadadjustmentadjustment
        if (eventData.EventId == EventIdForThreadPoolWorkerThreadAdjustmentAdjustment &&
            eventData.Payload[3] as uint? == ReasonForStarvation)
        {
            _logger.LogWarning("Thread pool starvation detected!");
        }
    }
}

أضفه إلى خدمتك:

service.AddSingleton<ThreadPoolStarvationDetector>();

ثم تحقق من السجل الخاص بك عند قطع اتصال الخادم عن طريق مهلة ping.

كيفية العثور على السبب الجذري لمجاعة تجمع الخيوط

للعثور على السبب الجذري لتجويع تجمع الخيوط:

• تفريغ الذاكرة، ومن ثم تحليل مكدس المكالمات. لمزيد من المعلومات، راجع تجميع عمليات تفريغ الذاكرة وتحليلها.
• استخدم clrmd لتفريغ الذاكرة عند اكتشاف تجويع تجمع المواضيع. ثم قم بتسجيل مكدس المكالمات.

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

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

هل لديك مشكلات أو ملاحظات حول استكشاف الأخطاء وإصلاحها؟ أبلغنا بها.

النصائح

كيفية عرض الطلب الصادر من العميل؟

خذ ASP.NET Core One على سبيل المثال (ASP.NET واحد مشابه):

• من المتصفح: خذ Chrome كمثال، يمكنك استخدام F12 لفتح نافذة وحدة التحكم، والتبديل إلى علامة التبويب الشبكة . قد تحتاج إلى تحديث الصفحة باستخدام F5 لالتقاط الشبكة من البداية.

  

• من عميل C #:

  يمكنك عرض زيارات الويب المحلية باستخدام Fiddler. يتم دعم زيارات WebSocket منذ Fiddler 4.5.

  

كيفية إعادة تشغيل اتصال العميل؟

فيما يلي نماذج الرموز التي تحتوي على منطق إعادة تشغيل الاتصال باستخدام استراتيجية ALWAYS RETRY :

• ASP.NET Core C # العميل

• ASP.NET عميل جافا سكريبت الأساسي

• ASP.NET C # العميل

• ASP.NET عميل جافا سكريبت

هل لديك مشكلات أو ملاحظات حول استكشاف الأخطاء وإصلاحها؟ أبلغنا بها.

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

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

كيفية استكشاف مشكلات الاتصال وتسليم الرسائل وإصلاحها