کندی اتصال سرور و TCP Retransmission؛ علت بازفرست بسته‌ها را پیدا کنید

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

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

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

IPهای 192.0.2.25 و نام رابط ens192 در نمونه‌ها صرفاً جای‌نگهدارند. آن‌ها را با مقادیر واقعی جایگزین کنید. آدرس کاربران، نام فایل و محتوای ترافیک ممکن است محرمانه باشند؛ گزارش را فقط از مسیر امن با افراد مجاز به اشتراک بگذارید.

اگر ابزار nstat نصب است، این فرمان مقادیر تجمعی TCP را بدون به‌روزرسانی تاریخچه ابزار نشان می‌دهد:

حدود یک دقیقه در شرایطی که مشکل دیده می‌شود صبر کنید و هر دو دستور را دوباره اجرا کنید. TcpRetransSegs شمار بازفرست ثبت‌شده و TcpOutSegs یکی از شمارنده‌های ارسال TCP است. تفاوت دو عدد را در همان بازه حساب کنید. مثلاً رشد بازفرست از ۱۲۰۰ به ۱۳۰۰ یعنی در آن بازه ۱۰۰ مورد به شمارنده اضافه شده است. مقدار تجمعی بزرگ از زمان شروع، بدون دانستن بازه و حجم ترافیک، به‌تنهایی نشانه مشکل فعلی نیست.

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

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

خروجی اتصال‌های TCP فعال به مقصد نمونه و اطلاعات داخلی آن‌ها را نشان می‌دهد. آدرس مقصد واقعی را بگذارید و در ستون‌های آدرس، پورت سرویس را نیز تطبیق دهید. ممکن است فیلدهایی مثل rtt، retrans و cwnd ظاهر شوند؛ نام و جزئیاتشان به نسخه هسته و ابزار بستگی دارد. چند بار هنگام همان انتقال نگاه کنید: اگر مقدار بازفرست همان اتصال رشد می‌کند و هم‌زمان سرعت افت دارد، شواهد قوی‌تری از یک شمارنده کلی دارید.

اگر خروجی خالی است، ممکن است ارتباط قبل از اجرای دستور تمام شده، IP اشتباه باشد یا اتصال در فضای شبکه دیگری قرار داشته باشد. ss مربوط به اتصال‌های زنده است و فهرست کامل تاریخچه گذشته را نشان نمی‌دهد. درستی فیلتر و نسخه ابزار را با راهنمای ss تطبیق دهید.

خروجی مسیر و رابط انتخاب‌شده برای مقصد را نشان می‌دهد. اگر رابط واقعاً ens192 است، آمار آن را بخوانید:

مقادیر errors و dropped در دریافت و ارسال را دو بار با فاصله و زمان ثبت کنید. رشد هم‌زمان آن‌ها سرنخی برای بررسی همان رابط و طرف مقابل است، اما معنای دقیق برخی شمارنده‌ها به درایور و نوع کارت بستگی دارد. روی VPS رابط ممکن است مجازی باشد و سلامت کابل یا کارت فیزیکی میزبان را نشان ندهد.

اگر ethtool نصب است و رابط فیزیکی پشتیبانی می‌کند:

سرعت، duplex، وضعیت لینک و شمارنده‌های پشتیبانی‌شده را با سوئیچ متصل و مشخصات همان سخت‌افزار مقایسه کنید. خروجی خالی یا Operation not supported روی کارت مجازی غیرعادی نیست. اگر خطاهای فیزیکی مرتبط در همان بازه بالا می‌روند، با دیتاسنتر پورت سوئیچ، کابل، ماژول و تنظیمات دو سر لینک را بررسی و قطعه معیوبِ تأییدشده را در زمان نگهداری تعویض کنید. سرعت یا duplex را کورکورانه مجبور به مقدار ثابت نکنید؛ تغییر اشتباه می‌تواند اتصال را قطع کند.

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

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

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

اگر پاسخ مسیر یا مقدار PMTU گزارش نشد، فیلترشدن بسته‌های تشخیصی هم ممکن است علت باشد. در یک آزمون مجاز IPv4، فرمان زیر payload با اندازه ۱۴۷۲ بایت و پرچم عدم تکه‌تکه‌شدن می‌فرستد؛ با سربرگ معمول IPv4 و ICMP، اندازه بسته معمولاً ۱۵۰۰ بایت است:

فیلتر ICMP، تونل یا headerهای اضافی می‌توانند نتیجه را تغییر دهند. شکست این آزمون به‌تنهایی ثابت نمی‌کند MTU نادرست است. اندازه‌های مناسب را از هر دو سمت و طبق طرح شبکه مقایسه کنید و پیام‌های مربوط به مسیر MTU را با مدیر شبکه بررسی کنید. تنظیم MTU یا MSS سراسری را بدون شناخت تونل، مسیر و روش بازگشت تغییر ندهید.

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