التعامل مع فقدان حزم البيانات في موقع المقبس

المشكلة

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

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

هناك العديد من الأسباب التي يمكن أن تؤدي إلى فقدان الحزم على الطريق. بعض الأسباب الشائعة هي:

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

فهم فقدان الحزم في كاتو

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

ملاحظة: أصغر حجم عينة للحاوية في الرسوم البيانية التحليلية هو 5 ثوانٍ. كنتيجة لذلك، أي بث قصير ضمن 5 مللي ثانية سيتم تطبيعه ضمن المتوسطات المعروضة ولن يظهر كذروة في الرسم البياني للتحليل.

1. فقدان من مزود الخدمة

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

كيف يقيس كاتو فقدان مزود الخدمة 

يتم قياس فقدان مزود الخدمة بمقارنة عدد الحزم المرسلة والعدد المستلم عبر رابط معين على كل من المقبس و PoP.

• فقدان الحزم في الاتجاه السفلي هو الفرق بين العدد المرسل من قبل PoP والعدد المستلم من قبل المقبس معبرًا عنه كنسبة مئوية.

الصيغة:

• فقدان الحزم في الاتجاه العلوي هو الفرق بين العدد المرسل من قبل المقبس والعدد المستلم من قبل PoP معبرًا عنه كنسبة مئوية.

الصيغة:

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

2. المهملات من كاتو

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

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

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

كيفية حل مشكلة فقدان الحزم

1. تحديد نطاق فقدان الحزم

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

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

2. التحقق من تحليل الموقع - الرسم البياني لفقدان الحزم

هل يظهر فقدان الحزم في الرسم البياني لتحليل فقدان الحزم للموقع؟ لدينا توصيات مختلفة بناءً على الرسوم البيانية التحليلية التي قد تظهر فقدان الحزم والحزم المهملة.

لا فقدان للحزم

من الممكن وجود فقدان للحزم دون أن يظهر أي فقدان للحزم على شاشة التحليل. قد تكون هناك مشكلة في الشبكة المحلية، أو قد تكون مشكلة متعلقة بـ PoP. استخدام أداة الشبكة في واجهة المستخدم للقيام باختبار بين عنوان IP في جانب LAN من المقبس يمكن أن يكون طريقة جيدة لتحديد السبب الجذري.

فقدان الحزم

إذا كان فقدان الحزم يظهر على الرسم البياني، فقد يكون بسبب سوء التكوين في BW. يرجى إلقاء نظرة على النطاق الترددي المُعد كما هو موضح أدناه في التحقق من تكوين النطاق الترددي.

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

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

3. التحقق من تحليل الموقع - الرسم البياني للحزم المهملة

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

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

يُظهر محلل الأولوية في شاشة التحليلات فقدان الحزم في الاتجاهين العلوي والسفلي لكل أولوية QoS.

4. (اختياري) مراقبة التجربة آخر ميل

يمكن للعملاء الذين لديهم ترخيص مراقبة التجربة التحقق من علامات التبويب لأداء آخر ميل والأداء التطبيقات لوجود احتمالية فقدان الحزم والحزم المهملة. يمكن أن تُرتبط البيانات مع النتائج في صفحة تحليل الشبكة الموقع لفهم أفضل لأين ينشأ المشكلة.

5. التحقق من تحليل الموقع - فقدان الحزم آخر ميل

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

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

1. هل تقوم بتطبيق QoS على حركة مرور UDP/443 أو UDP/1337 (DTLS)؟
2. هل تطبق أي حماية من هجمات الحرمان من الخدمة (DoS) على حركة مرور UDP التي قد تسبب فقدان الحزم إلى عنوان PoP IP؟
3. هل هناك ازدحام أو وحدة معالجة مركزية عالية على الراوتر(ات) الخاصة بك في المسار إلى عنوان PoP IP؟
4. هل تسمح بالزيادة على معدل الخط المشترك؟

6. التحقق من تكوين النطاق الترددي

يمكن أن يُسبب فقدان الحزم بسبب ازدحام الرابط، ومن المهم أن يتم تكوين النطاق الترددي لكل رابط WAN بشكل صحيح في تطبيق إدارة كاتو. تأكد من تطابق النطاق الترددي المُعد مع ما يوفره مزود الخدمة في تكوين الموقع. قم بتهيئة إعدادات النطاق الترددي لواجهة المقبس WAN وفقًا لشروط ترخيص الموقع كاتو.

ليس لدى بيئات Azure/AWS قيود تقليدية على النطاق الترددي. بدلاً من ذلك، ينبغي ألا يتجاوز النطاق الترددي المُعد في الموقع النطاق الترددي المدعوم لـ vSocket. بالنسبة لـ Azure، اعتبارًا من الإصدار 21، يدعم حجم VM من طراز Standard_D8ls_v5 حتى 2Gbps. في AWS، يوفر حجم النمط c5n.xlarge النطاق الترددي الذي يتجاوز 2Gbps. من المهم ضمان بقاء النطاق الترددي الموجه للموقع داخل الحدود المدعومة للحصول على الأداء المثالي.

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

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

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

تتوفر معلومات الإنتاجية والقدرة لكل نموذج من نماذج المقبس في ورقة بيانات المقبس، انظر هذا المقال: دليل Socket X1700، X1600 & X1500.

7. تحقق من أداء وحدة المعالجة المركزية للمقبس

من تحليلات الشبكة في CMA، اختر علامة التبويب الأجهزة. يعرض هذا الجزء استخدم CPU التاريخي بنسبة مئوية لكل نواة.

يمكن أن يؤثر الاستخدام المستمر لمعالج CPU بنسبة أعلى من 90% بشكل سلبي على أداء Socket وقد يسبب خسارة الحزم وزمن انتقال عالي. إذا تم ملاحظة الاستخدام المستمر لمعالج CPU بنسبة عالية، اتصل بممثل حسابك لتقييم استبدال أجهزة محتملة (مثال: من X1500 إلى X1600).

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

يمكن رؤية استخدام CPU الخاص بـ Socket اللحظي من واجهة المستخدم الخاصة بـ Socket، تحت علامة تبويب حالة الأجهزة HW. قارن الاستخدام النشط مع البيانات التاريخية لتحديد اتجاهات الأداء.

8. استبعاد إعادة اتصال الموقع

إعادة اتصال الموقع بـ كاتو كلاود هي مصدر فقدان الحزم. تحقق من الصفحة الرئيسية > الأحداث لمعرفة ما إذا كان فقدان الحزم مرتبطًا بأحداث إعادة الاتصال. قم بتصفية الأحداث كنمط فرعي = 'إعادة الاتصال'.

ستظهر أحداث إعادة الاتصال رسالة توضح سبب انقطاع الاتصال. راجع فهم أحداث إعادة الاتصال

9. التجاوز على كاتو

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

10. إجراء اختبارات Ping

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

تسمح واجهة المستخدم للمقبس أيضًا بإجراء اختبار اتصال حسب اسم المضيف أو IP باستخدام أداة الاتصال. يمكنك تحديد الواجهة التي تريد إرسال الاتصال عبرها، إما عبر كاتو أو مباشرة عبر رابط الشبكة الواسعة. ابحث عن أي عدم اتساق في نتائج الاتصال، مثل فقدان الحزم أو ارتفاع التأخير. إذا كانت هناك خسارة في الحزم سواء باستخدام Cato أو بدونها، فقد يشير ذلك إلى مشكلة في مزود الخدمة. أيضًا، إذا كان أحد الروابط 4G/LTE، يجب أن تتذكر أن هذه الروابط تكون أكثر حساسية لخسارة الحزم.

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

ملاحظة: اختبارات ping جيدة لفحص الصحة الأساسية للشبكة، لكن لا تعني عدم سقوط ping بالضرورة أن الخط نظيف.

11. تشغيل اختبارات المسار التوجيهي

يتم استخدام المسار التوجيهي لتحديد أجهزة التوجيه (الحركات) بين المصدر والوجهة. سيعرض خسارة الحزم وزمن الانتقال لكل حركة.

يمكن تشغيل المسار التوجيهي من واجهة المستخدم Socket باستخدام أداة أداة المسار التوجيهي. قم بتشغيل المسار التوجيهي للعثور على أي خسارة في الحزم أو زمن انتقال عالي غير متوقع على أي من الحركات عبر رابط WAN بين Socket والوجهة. واجهة المستخدم ترسل فقط حزمة واحدة لكل حركة وتظهر خسارة الحزم لكل حركة. نظرًا لوجود حزمة واحدة فقط مُرسلة، ستشاهد فقط 0% أو 100% خسارة.

تحليل نتائج المسار التوجيهي

كن واعيًا بأن خسارة الحزم الظاهرة في أي حركة واحدة ليست بالضرورة علامة على مشكلة. قد تظهر حركة واحدة خسارة الحزم بنسبة 100% ببساطة لأن بروتوكول ICMP غير مفعل على جهاز التوجيه. يمكن أن يظهر حركة انخفاض في خسارة الحزم عن 100% دون وجود مشكلة بسبب تحديد معدل بروتوكول ICMP. إذا شاهدت بعض خسارة الحزم في حركة واحدة و0% خسارة في الحزم في الحركة التالية، فأنت غالبًا تشهد تحديد معدل بروتوكول ICMP.

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

12. توليد حمل حركة مرور عالٍ لاكتشاف خسارة الحزم

يمكن أن تساعد شاشة Real-Time في اكتشاف أي تغييرات في طرق النقل للتعرف على خسارة الحزم الفورية والحزم المُلغاة. استخدم أداة speedtest tool الخاصة بـSocket لمحاكاة الحمل العالي واستنساخه نتيجة الطلب العالي أثناء استكشاف الأخطاء وإصلاحها.

من المتوقع أن تكون نتائج اختبار السرعة عبر Cato قريبة من العرض الترددي المُحَدد للرابط في تطبيق إدارة Cato. كن واعيًا بأن النفقات المسؤول عنها نفق DTLS (117 بايت) يمكن أن تقلل من عرض النطاق الترددي بشكل طفيف. 

سيقوم الاختبار بتشبع الرابط ويظهر أي خسارة من الحزم المتعلقة بالـISP على شاشة Network Analytics. من المتوقع حدوث حزم مُلغاة أثناء تشغيل الاختبار إذا كان عرض النطاق الترددي المُحَدد للرابط أقل من العرض الترددي المقدم من الـ ISP.

اختبار السرعة المباشر 

عند تشغيل اختبار السرعة مباشرةً عبر منفذ WAN، يجب أن تكون نتيجة الأعلى قريبة من ترخيص العرض الترددي المُحَدد في تطبيق إدارة Cato. سيظل Socket يستخدم QoS للأعلى في اختبار السرعة المباشر وفقًا لترخيص العرض الترددي الخاص بالموقع. من ناحية أخرى، ستظهر نتيجة الأسفل السعة الكاملة للـISP المحلي.

13. اختبار الرابط باستخدام iPerf

تتيح واجهة المستخدم Socket استخدام أداة iPerf tool لاستكشاف مشاكل الأداء في الميل الأخير بين Socket ونقطة PoP المتصلة في السحابة Cato. يؤدي Socket الذي يقوم بتشغيل عميل iPerf الاختبار ضد الخادم iPerf الذي يعمل على PoP المتصلة.

قم بتشغيل اختبار iPerf عبر Cato مباشرةً عبر WAN من صفحة أدوات واجهة المستخدم الخاصة بـ Socket. حدد UDP كبروتوكول (لاستبعاد التحكم في تدفق TCP) ، اضبط الاتجاه (أعلى أو أسفل) ، ومعدل الهدف كالعرض الترددي المُحَدد. يمكن لهذه الأداة التأكيد بشكل أفضل على أن عرض النطاق الترددي عبر Cato وعبر WAN يكون كما هو متوقع. كن واعيًا بأن النفقات المسؤول عنها نفق DTLS (117 بايت) يمكن أن تقلل من العرض الترددي بشكل طفيف. 

في المثال أدناه نحن نقوم بإعداد 45Mbps كمعدل هدف (والذي هو نفس عرض النطاق الترددي المُحَدد في تطبيق إدارة Cato) والمعدل المستلم أقل من المتوقع مع خسارة في الحزم بنسبة 3.7%

14. التحقق من روابط تجميع الروابط (LAG)

قد تكون خسارة الحزم وزمن الانتقال العالي ناتجة عن عدم تكوين صحيح لتجميع الروابط (LAG) بين Socket ومحول داخلي. لا يمكن اكتشاف هذه المشكلة الخاصة في تحليلات الشبكة، بل تحتاج إلى استكشاف الأخطاء وإصلاحها داخل الشبكة المحلية LAN. يدعم Cato فقط LAG الثابت ويجب أن يدعم نظير LAG نفس الوضع. سيؤدي عدم تطابق تكوين LAG إلى خسارة الحزم.

لمزيد من معلومات استكشاف الأخطاء وإصلاحها، انظر إلى رابط Link Aggregation (LAG) Link Experiencing High Latency and Packet Loss

15. التحقق من سرعة رابط Socket

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

تأكد أيضًا من أن سرعة روابط WAN وLAN تساوي أو تزيد على العرض الترددي المُحَدد لموقع. يمكن أن تكون سرعة الرابط هي العامل المحدد لـ throughput. على سبيل المثال، إذا كانت عرض النطاق الترددي للموقع هو 200 Mbps لكن رابط LAN قد تفاوض فقط على 100 Mbps بدوام كامل، لا يمكن لجهاز كمبيوتر متصل بـ Socket تحقيق أعلى من throughput 100 Mbps.

للتحقق من حالة الرابط، قم بتسجيل الدخول إلى واجهة المستخدم الخاصة بـ Socket وشاهد حالة الرابط في صفحة المراقبة. المثال أدناه يظهر رابط WAN1 بسرعة 100 Mbps بنصف الازدواج.

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

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

16. التحقق من عناوين IP المكررة

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

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

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

17. التحقق من انفجارات صغيرة micro-bursts

سبب آخر محتمل لخسارة الحزم هو انفجارات صغيرة (micro-bursts). تتميز انفجارات صغيرة بزيادة مفاجئة للحزم أو إطارات البيانات التي تحدث خلال فترة زمنية قصيرة جدًا، وعادةً ما تستمر لبعض الميكروثواني إلى المللي ثواني. في حالات حدوث الانفجارات الصغيرة وتجاوز حد سرعة الرابط، قد يقوم مقدم Last-Mile (ISP) بإسقاط حركة المرور الزائدة، مما يؤدي إلى خسارة الحزم.

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

في المثال أعلاه، تم تعديل قيمة مستوى الانفجارات من القيمة الافتراضية 0.2 إلى 0.01 مما يعني أن Socket وPoP تطبق شكلًا أكثر عدوانية في تحسين حركة المرور، مما يحل مشكلة خسارة الحزم. 

ضبط إعدادات مستوى الانفجارات للتخفيف من خسارة الحزم

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

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

أفضل ممارسات لتعديل مستوى الانفجارات هي تقليل القيمة تدريجيًا (على سبيل المثال، من 0.2 إلى 0.18).  بعد تقليل القيمة، راقب التأثير من خلال تحليل خسارة الحزم في شاشات الوقت الحقيقي أو تحليلات الشبكة للموقع. ضع في اعتبارك أن مقاييس الموقع عادة ما تستغرق بضع دقائق لتحديثها. تابع تقليل مستوى الانفجارات حتى يتم التحكم في خسارة الحزم. 

إذا لم يتم حل خسارة الحزم بواسطة هذا الإجراء، فهذا يعني أنها ناتجة بسبب آخر غير الانفجارات الصغيرة.  في هذه الحالة، استعد القيمة الافتراضية للانفجارات 0.2 و اتصل بالدعم لمزيد من المساعدة. 

تعديل مستوى الانفجارات

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

يتم تطبيق التكوين على مستوى الموقع أو مستوى الحساب. يأخذ التكوين على مستوى الموقع الأسبقية على مستوى الحساب.

لتكوين مستوى الانفجارات:

1. من قائمة التنقل، اختر المصادر > التكوين المتقدم على مستوى الحساب أو تكوين الموقع > التكوين المتقدم على مستوى الموقع.
   
2. حدد قيمة الانفجارات السفلى أو قيمة الانفجارات العليا.
3. قم بتمكين الإعداد وضبط القيمة بين النطاق 0.001 - 0.2.
   
4. انقر على تطبيق
5. انقر على حفظ

ملاحظات: 

• إذا تم تعديل الانفجارات مسبقًا بواسطة دعم Cato، ستظهر القيمة المعدلة بدلاً من القيمة الافتراضية 0.2
• يمكن ضبط قيم الانفجارات فقط لمواقع Socket
• أصغر جزء بيانات في تطبيق إدارة Cato هو 5 ثوان، ويتم توفير انفجارات صغيرة داخل أصغر أجزاء بيانات وعادةً ما تكون صعبة التعرف.