افت دو درصدی در یک اجرای طولانی ping مانند عددی به نظر می‌رسد که می‌توانید بر اساس آن عمل کنید، و به‌ندرت چنین است. نمی‌گوید پاسخ‌ها کجا گم شدند، آیا با هم گم شدند، یا یک برنامه مشخص آن بازه را چگونه تجربه کرد. افتِ یکنواخت پخش‌شده در یک دقیقه و افتِ جمع‌شده در یک تبادل واحد برای همان درصد نتایج بسیار متفاوتی می‌دهند.

به‌جای اعتماد به یک اندازه‌گیری، سه مورد را مقایسه کنید: آنچه کاوشگر دید، آنچه شمارنده‌های واسط انجام دادند، و آنچه برنامه در واقع منتظرش بود.

درصد ping در واقع چه چیزی را می‌سنجد

کاوشگر پژواک یک جهت از یک پروتکل را با یک اندازه بسته، با همان نرخی که انتخاب کرده‌اید می‌آزماید. تونلی که یک بارگذاری بزرگ را حمل می‌کند کار کاملاً دیگری می‌کند، و پیوندی که کاوشگرهای کوچک را می‌اندازد لزوماً همان پیوندی نیست که به انتقال آسیب می‌زند. درصد همچنین اطلاعات زمانی را که بیشترین اهمیت را دارد از بین می‌برد، زیرا ده پاسخ گم‌شده در یک انفجار با ده پاسخ گم‌شده با فاصله یک ساعت یکی نیست. همچنین نمی‌تواند بگوید کدام سمت تونل چیزی را انداخته است.

نتیجه کاوشگر را به‌عنوان سرنخی درباره مسیر نگه دارید. سپس به دنبال زمان‌بندی و مرزی بگردید که آن را تولید کرد.

اختلاف شمارنده‌ها را مقایسه کنید، نه مجموع‌های طول عمر

خوانش‌های زمان‌دار را پیش و پس از پنجره‌ای که نشانه در آن ظاهر شد، در هر دو نقطه پایانی و در هر درگاه سوئیچی که کنترل می‌کنید بگیرید. حجم ترافیک را همراه با خطاها، دورریزها و تغییرات وضعیت پیوند ثبت کنید، زیرا مجموع غیرصفری که در طول ماه‌ها انباشته شده تاریخ را توصیف می‌کند نه این رخداد را. شمارنده‌ای که هنگام توقف سه واحد حرکت کرده، مشاهده‌ای متفاوت از شمارنده‌ای است که سه هزار نشان می‌دهد و هرگز تغییر نکرده است.

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

بسته‌هایی که به دلیل خطاهای دریافت دور ریخته می‌شوند و بسته‌هایی که به دلایل دیگر دور ریخته می‌شوند در شمارنده‌های جداگانه زندگی می‌کنند، و این تمایز ادامه کار را تغییر می‌دهد. شمارنده‌های خطا به لایه فیزیکی یا لایه درایور اشاره می‌کنند، در حالی که فشار صف و دورریزهای سیاستی به جایی بالاتر از آن اشاره می‌کنند. جهت و نام واسط را هم نگه دارید، زیرا افزایش خطای دریافت روی یک پیوند بالارو و شمارنده بسته تونل قابل تعویض نیستند.

اگر درایور شمارنده‌های فیزیکی دقیق ارائه می‌دهد، آن‌ها را از طریق مستندات همان آداپتر بخوانید. دادن یک معنا به هر فیلدی به نام “drop” در دو سازنده، راهی است که یک عجیب‌وغریب عادی حسابداری به تشخیص سخت‌افزاری تبدیل می‌شود.

چگونه یک قطعه گم‌شده به انتظاری طولانی تبدیل می‌شود

یک برنامه پس از گم کردن یک قطعه می‌تواند بسیار بیشتر از یک رفت‌وبرگشت منتظر بماند. TCP زمان رفت‌وبرگشت را تخمین می‌زند، از آن تخمین یک تایمر ارسال مجدد محاسبه می‌کند و وقتی ارسال مجدد هم شکست می‌خورد عقب می‌نشیند، بنابراین یک قطعه گم‌شده در لحظه اشتباه می‌تواند درخواستی را برای بازه‌ای محسوس متوقف کند. این سازوکار در RFC 6298 مشخص شده است، و توضیح می‌دهد چرا نرخی افت که بی‌اهمیت به نظر می‌رسد هنوز هم احساس می‌شود.

با این حال هر توقفی مهلت ارسال مجدد نیست. همان انتظار می‌تواند از تحلیل نام، یک سرور کند، یا برنامه‌ای بیاید که پس از شکست درخواست خودش را دوباره امتحان می‌کند. این موارد را با هم‌تراز کردن عملیات ناموفق با مشاهدات انتقال و با رویدادهای نشست خود تونل جدا کنید. یک وقفه در مسیر داده بدون اتصال مجدد رویدادی متفاوت از دست‌دادن تازه و تبادل اعتبارنامه است.

جایی که ضبط مجاز است، آن را باریک نگه دارید. آنچه لازم دارید این است که آیا بسته‌ها یا تأییدهای موردانتظار در یک مرز مشخص متوقف می‌شوند، نه این واقعیت که جایی در یک رد پرترافیک ارسال مجددی وجود دارد.

یک مرز را بدون جابه‌جا کردن بقیه تغییر دهید

اگر شواهد به یک پیوند محلی اشاره می‌کند، یک کابل یا درگاه تأییدشده را به‌عنوان مقایسه کنترل‌شده جایگزین کنید و بقیه را به حال خود بگذارید. نقطه پایانی، برنامه و بار کاری را قابل مقایسه نگه دارید و در هر تلاش دقیقاً یک مرز را تغییر دهید. مقایسه یک لپ‌تاپ سیمی با یک لپ‌تاپ بی‌سیم در حالی که خروجی‌ها و پروتکل‌ها را هم عوض می‌کنید، چیزی به شما نمی‌گوید که بتوانید به آن نسبت دهید.

شمارنده‌های محلی پاک، بقیه مسیر را تأیید نمی‌کنند. آن‌ها بخشی را که می‌بینید محدود می‌کنند، و گزارش صادقانه می‌گوید کدام مرزها مشاهده شدند و کدام نشدند. آنچه در پایان می‌خواهید این است که یک مشاهده وقتی یک مداخله رخ داد تغییر کرد، نه حکایتی درباره یک کابل بد که به قاعده‌ای جهان‌شمول ارتقا یافته است.

مقالات مرتبط