گزارش MTR و Packet Loss را چطور بخوانیم؟ آیا روتر وسط مسیر خراب است؟

سایت برای بخشی از کاربران کند یا قطع‌و‌وصل می‌شود و پشتیبانی از شما گزارش MTR می‌خواهد. در گزارش، یک روتر وسط مسیر ۵۰ درصد Loss نشان می‌دهد، اما مقصد نهایی بدون افت پاسخ می‌دهد. آیا همان روتر خراب است؟ الزاماً نه: بعضی روترها پاسخ به بسته‌های تشخیصی را محدود می‌کنند، در حالی که ترافیک عبوری را همچنان منتقل می‌کنند.

در این راهنما معنی ستون‌ها، روش گرفتن نمونه و راه تفسیر محتاطانه را توضیح می‌دهیم. هدف پیدا کردن شواهد قابل استفاده است؛ یک جدول کوتاه به‌تنهایی همیشه محل دقیق مشکل را ثابت نمی‌کند.

MTR ترکیبی از ایده‌های ping و traceroute است. ابزار بسته‌های تشخیصی می‌فرستد و پاسخ نقاط مسیر یا hopها را در چند نوبت ثبت می‌کند. ستون Loss% درصد پاسخ‌هایی را که برای آن hop دریافت نشده نشان می‌دهد. Snt تعداد نمونه‌ها، Avg میانگین زمان پاسخ و Wrst بیشترین زمان مشاهده‌شده است. واحد زمان معمولاً میلی‌ثانیه است.

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

در این نمونه روتر دوم به نیمی از درخواست‌های تشخیصی پاسخ نداده، اما نقاط بعدی و مقصد به نمونه‌های خود پاسخ داده‌اند. بنابراین عدد ۵۰ درصد در ردیف دوم به‌تنهایی ثابت نمی‌کند نیمی از داده کاربران در آن روتر از بین رفته است. محدودکردن پاسخ ICMP یکی از توضیح‌های ممکن است. توضیح Cloudflare درباره MTR نمونه‌ای از این رفتار را نشان می‌دهد.

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

در لینوکسی که MTR نصب و اجرای آن مجاز است، در ترمینال دستور زیر را با مقصدی که اجازه آزمایش آن را دارید اجرا کنید:

example.com را با نام یا IP مقصد موردنظر عوض کنید. -r پس از پایان نمونه‌گیری گزارش می‌دهد، -c 30 تعداد دورها را تعیین می‌کند و -n نمایش نام معکوس را کنار می‌گذارد تا خواندن IPها ساده‌تر شود. بسته به سیستم ممکن است اجرای ابزار به مجوز شبکه مناسب نیاز داشته باشد. از افزایش بی‌دلیل نرخ یا آزمایش طولانی روی مقصدی که اجازه ندارید خودداری کنید.

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

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

هم‌زمان سرویس واقعی را نیز تست کنید: مثلاً بازشدن همان صفحه یا درخواست مجاز HTTPS را با ثبت زمان و نتیجه بررسی کنید. ممکن است ICMP در مقصد محدود باشد ولی سرویس وب سالم کار کند، یا ping خوب باشد و برنامه وب خطا دهد. نتیجه هر دو را کنار هم بگذارید.

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

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

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