كيف تقرأ فقدان الحزم قبل لوم الكابل

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

قارن ثلاثة مقاييس بدلًا من الثقة بواحد: ما رآه المجس، وما فعلته عدادات الواجهة، وما انتظرته التطبيقات فعليًا.

ما تقيسه نسبة ping فعليًا

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

احتفظ بنتيجة المجس كتلميح عن المسار. ثم اذهب للبحث عن التوقيت والحدّ الذي أنتجها.

قارن فروق العدادات، لا الإجماليات العمرية

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

ip -s link show dev eth0
nstat -az TcpRetransSegs TcpExtTCPTimeouts
date -u +%Y-%m-%dT%H:%M:%SZ

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

إذا كشف المشغّل عدادات فيزيائية مفصّلة، فاقرأها عبر توثيق ذلك المحول. إعطاء معنى واحد لكل حقل باسم “drop” عند مورّدين اثنين هو كيف يتحول سلوك محاسبي عادي إلى تشخيص عتاد.

كيف يصبح مقطع ضائع انتظارًا طويلًا

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

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

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

غيّر حدًّا واحدًا دون تحريك الآخرين

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

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