تست سرعت پهنای باند اختصاصی: راهنمای کامل ابزارها، معیارها و تفسیر نتایج
اگر مدیریت یک زیرساخت شبکه سازمانی را بر عهده دارید یا صاحب یک کسبوکار آنلاین هستید که به اینترنت پرسرعت و پایدار وابسته است، احتمالاً بارها و بارها با این سوال روبرو شدهاید: آیا پهنای باندی که از ISP دریافت میکنم، واقعاً همان چیزی است که قراردادش را امضا کردهام؟ تست سرعت معمولی که روی کامپیوتر شخصی انجام میدهیم، جواب این سوال را نمیدهد. اینجاست که
تست سرعت پهنای باند اختصاصی بهعنوان یک ضرورت فنی مطرح میشود. در این مقاله از
دوربرد، قرار است بهطور عمیق به این موضوع بپردازیم و تمام ابزارها، معیارها و روشهای تفسیر نتایج را به شما آموزش دهیم.
چرا تست سرعت پهنای باند اختصاصی مهمتر از تست معمولی است؟
وقتی در خانه روی موبایلتان اپلیکیشن Speedtest را باز میکنید، در واقع دارید یک گوی ساده را در یک شنای بیپایان میاندازید تا ببینید چقدر سریع به دیواره میرسد. این تست برای بررسی کیفیت اینترنت خانگی کافی است، اما برای یک کسبوکار که SLA (توافقنامه سطح خدمات) امضا کرده، کاملاً ناکافی است. تست
پهنای باند اختصاصی به شما اجازه میدهد تا دقیقاً بسنجید که آیا تضمینهای ISP در مورد پهنای باند، تأخیر و میزان از دست دادن بستهها (packet loss) درست است یا نه. فرض کنید یک شرکت هاستینگ دارید که به 500 کلاینت سرویس میدهید. اگر پهنای باند شما در ساعات پیک 20% افت داشته باشد، این یعنی 100 کلاینت ناراضی، درخواستهای استرداد پول و در نهایت آسیب به برندتان. تست معمولی این افت را نشان نمیدهد، اما تست حرفهای پهنای باند اختصاصی، بلافاصله زنگ خطر را به صدا درمیآورد.
فراتر از Download و Upload: تضمین SLA چیست؟
وقتی قرارداد پهنای باند اختصاصی امضا میکنید، ISP متعهد میشود که 99.95% زمان، سرعت دانلود و آپلود شما از مقدار مشخصی کمتر نباشد. اما همین کافی است؟ اصلاً فکرش رو میکردی که تأخیر (latency) بالای 50ms میتواند یک تماس ویدیویی HD را بهطور کامل مختل کند؟ SLA حرفهای به معنای پایش تمام پارامترهای شبکه است: Throughput پایدار، Jitter کمتر از 5ms، Packet Loss زیر 0.1% و Latency تضمینشده. بدون تست سرعت پهنای باند اختصاصی، نمیتوانید این پارامترها را با دقت اندازهگیری کنید. سرورهای Speedtest عمومی معمولاً از نظر جغرافیایی دور هستند و مسیرهای مختلفی را طی میکنند که نتیجه تست را تحریف میکند.
تفاوت تست سرعت کاربر خانگی و مدیر شبکه سازمانی
یک کاربر خانگی وقتی نتایج تست را میبیند، فقط به عدد دانلود نگاه میکند و اگر بالای 50Mbps باشد، خوشحال است. اما یک مدیر شبکه باید به دنبال الگوها باشد. آیا سرعت در دقایق 5، 15 و 30 متفاوت است؟ آیا در تست UDP همین نتایج را میگیرید یا نه؟ آیا وقتی 1000 کانکشن همزمان باز میکنید، سرعت افت میکند؟ اینها سوالاتی هستند که فقط تست سرعت پهنای باند اختصاصی میتواند به آنها پاسخ دهد. مدیر شبکه به ابزارهایی مثل iPerf3 نیاز دارد که میتواند پارامترهای تست را دقیق کنترل کند، در حالی که کاربر خانگی فقط یک دکمه “Start Test” میخواهد.
تفاوت بنیادی: باند اختصاصی vs اشتراکی در تست سرعت
تفاوت اصلی بین این دو نوع سرویس، در تضمین منابع است. در باند اشتراکی، شما با 10، 20 یا حتی 50 کاربر دیگر یک خط را شریک هستید. ISP ممکن است 1Gbps را به 50 کاربر بفروشد، امیدوار باشد که همگی بهطور همزمان از حداکثر سرعت استفاده نکنند. اما در باند اختصاصی، آن 100Mbps یا 1Gbps فقط برای شماست. حالا این تفاوت چطور در تست سرعت نمایان میشود؟
چرا Speedtest.net روی باند اشتراکی فریبدهنده است
Speedtest.net یک ابزار عالی برای کاربران عادی است، اما برای تست سرعت پهنای باند اختصاصی، میتواند کاملاً گمراهکننده باشد. چرا؟ چون سرورهای آن در ساعتهای مختلف بارگذاری متفاوتی دارند. شما ممکن است ساعت 3 نصفشب 950Mbps بگیرید اما ساعت 8 شب فقط 400Mbps. این بهمعنای نقض قرارداد نیست، بلکه طبیعت اینترنت اشتراکی است. علاوه بر این، سرورهای Speedtest معمولاً ترافیک را بهصورت کوتاهمدت و با تعداد محدودی کانکشن تست میکنند که نمیتواند توان واقعی سرور شما را نشان دهد. برای تست حرفهای، باید از ابزارهایی استفاده کنید که بتواند تست را در بازههای زمانی طولانیتر و با کانکشنهای همزمان بیشتر انجام دهد.
مقایسه نتایج تست در ساعات پیک و آفپیک
وقتی شما باند اختصاصی دارید، نباید تفاوتی بین نتایج تست در ساعت 10 صبح و 9 شب ببینید. اما در عمل، اینطور نیست. ISPها معمولاً مسیرهای خروجی خود را در ساعات پیک اشتراکگذاری میکنند. بنابراین، تست سرعت پهنای باند اختصاصی باید حداقل 3 بار در روز انجام شود: یکبار در ساعات آفپیک (مثلاً 3 صبح)، یکبار در ساعتهای میانی (ظهر) و یکبار در پیک (شب). اگر اختلاف بیش از 5% باشد، باید با ISP تماس بگیرید. این مانیتورینگ مستمر است که نشان میدهد آیا واقعاً دارید از باند اختصاصی استفاده میکنید یا در عمل، همان باند اشتراکی است که با قیمت بیشتر فروخته شده.
نمودار تطابق سرعت تضمینشده و سرعت واقعی
بهترین روش برای ارائه شکایت به ISP، داشتن نمودارهایی است که سرعت تضمینشده قرارداد را با سرعت واقعی اندازهگیریشده مقایسه کند. شما میتوانید با ابزارهایی مثل LibreNMS یا اسکریپتهای Python ساده، هر ساعت یکبار تست سرعت را اجرا و نتایج را در پایگاه داده ذخیره کنید. بعد از یک ماه، نمودار را بکشید. اگر خط سرعت واقعی بهطور مداوم زیر خط سرعت تضمینشده باشد، شما سند محکمی برای شکایت دارید. این دقیقاً همان کاری است که شرکتهای حرفهای انجام میدهند و بدون آن، ISP بهراحتی میتواند ادعا کند که “موقتی بوده” یا “مشکل از طرف شماست”.
ابزارهای استاندارد تست سرعت: از iPerf3 تا Ookla Speedtest
حالا بریم سراغ ابزارهای واقعی. برای تست سرعت پهنای باند اختصاصی، به ابزارهایی نیاز دارید که دقیق، قابل تنظیم و قابل اتوماسیون باشند.
iPerf3: ابزار حرفهای مورد تأیید IEEE
iPerf3 استاندارد طلایی تست سرعت است. این ابزار متنباز است، توسط IEEE پشتیبانی میشود و روی تقریباً تمام پلتفرمها کار میکند. مهمتر از همه، اینکه iPerf3 میتواند تستهای TCP و UDP را بهصورت جداگانه انجام دهد، تعداد پورتها را مشخص کند، اندازه بستهها را تغییر دهد و حتی مدت زمان تست را دقیقاً کنترل کند. این ابزار به شما اجازه میدهد یک سرور iPerf3 روی سرور اختصاصیتان نصب کنید و از چندین کلاینت مختلف به آن متصل شوید. اینطوری، دارید واقعاً توان زیرساخت خودتان را تست میکنید، نه سرورهای خارجی را.
Ookla Speedtest Enterprise: وقتی به سرور خصوصی نیاز دارید
اگر محیط سازمانی دارید و دوست دارید از اینترفیس گرافیکی استفاده کنید، Ookla Speedtest Enterprise گزینه خوبی است. این نسخه به شما اجازه میدهد یک سرور Speedtest خصوصی روی سرور خودتان نصب کنید و فقط کاربران داخلیتان به آن دسترسی داشته باشند. این ابزار گزارشهای دقیقی ارائه میدهد و میتوانید آن را با سیستمهای مانیتورینگ ادغام کنید. اما نسخه Enterprise هزینه دارد و برای کسبوکارهای کوچکتر، iPerf3 رایگان و کارآمدتر است.
ابزارهای جایگزین: Fast.com, Nperf, LibreSpeed
Fast.com متعلق به Netflix است و فقط تست دانلود انجام میدهد. ساده است اما قابل تنظیم نیست. Nperf ابزار خوبی است و میتواند تستهای همزمان انجام دهد و آمارهای جغرافیایی ارائه دهد. LibreSpeed هم متنباز است و میتوانید آن را روی سرور خودتان نصب کنید. اما هیچکدام از اینها جانشین iPerf3 نمیشوند. آنها برای تستهای سریع و گاهی مناسباند، اما برای تست سرعت پهنای باند اختصاصی، به کنترل دقیقتری نیاز دارید.
تست سرعت از طریق خط فرمان (CLI) برای سرورهای لینوکس
وقتی سرور لینوکس دارید، تست از طریق CLI سریعتر و قابل اتوماسیونتر است. با iPerf3، میتوانید دستور iperf3 -c your-server-ip -t 60 -P 10 -R را بزنید تا یک تست 60 ثانیهای با 10 کانکشن همزمان و حالت ریورس (سرور به کلاینت) اجرا شود. این دستور دقیقاً همان چیزی است که یک مدیر شبکه حرفهای استفاده میکند. میتوانید خروجی را به یک فایل CSV هدایت کنید تا بعداً تحلیل کنید: iperf3 -c your-server-ip --json > result.json. این قابلیت اتوماسیون، کلید تمایز تستهای حرفهای از تستهای آماتور است.
پارامترهای کلیدی که باید تست کنید (Beyond Download/Upload)
سرعت دانلود و آپلود فقط نوک کوه یخ هستند. برای تست سرعت پهنای باند اختصاصی، باید پارامترهای دیگری را هم بسنجید.
Latency (Ping): چرا زیر ۲۰ms برای VoIP حیاتی است
Latency یا تأخیر، زمان لازم برای رفتوبرگشت یک بسته داده است. برای یک تماس VoIP، تأخیر بالای 150ms غیرقابل قبول است. برای گیمینگ، حتی 50ms هم زیاد است. در تست سرعت پهنای باند اختصاصی، باید latency را بهصورت مداوم مانیتور کنید. از دستور ping -c 100 your-gateway-ip استفاده کنید تا میانگین و انحراف معیار latency را بگیرید. اگر میانگین بالای 20ms باشد یا انحراف معیار بالای 5ms، یعنی شبکه شما ناپایدار است و برای اپلیکیشنهای حساس به تأخیر، مناسب نیست.
Jitter: نوسان تأخیر و تأثیر آن روی Game Server
Jitter تفاوت بین latencyهای مختلف است. فرض کنید ping شما یکبار 10ms، بار دیگر 50ms و بار بعد 30ms باشد. این نوسان برای استریمینگ ویدیو یا گیم سرور فاجعه است. در iPerf3، با پارامتر -J میتوانید Jitter را در تست UDP بسنجید. برای یک سرویس حرفهای، Jitter باید زیر 5ms باشد. اگر بالاتر باشد، بستهها دیر یا زود میرسند و کیفیت تجربه کاربر (QoE) بهشدت افت میکند.
Packet Loss: از دست دادن بسته و فاجعه در استریمینگ
Packet Loss یعنی چه تعداد از بستهها در مسیر گم میشوند. حتی 1% packet loss میتواند کیفیت یک استریم 4K را به HD تبدیل کند. در تست UDP iPerf3، packet loss بهصورت درصد نشان داده میشود. برای باند اختصاصی، packet loss باید عملاً صفر باشد. اگر بیش از 0.1% دارید، یعنی یا مشکل از کابلکشی است یا تجهیزات شبکه شما ضعیفاند یا ISP دارد overselling میکند. این پارامتر را نمیتوانید با Speedtest.net بسنجید. فقط iPerf3 یا ابزارهای مشابه این کار را به درستی انجام میدهند.
Throughput پایدار vs نقطهای: تفاوت بنیادی
Throughput نقطهای (Peak) همان عددی است که Speedtest به شما نشان میدهد: سرعت لحظهای. اما Throughput پایدار (Sustained) یعنی سرعت میانگین در یک بازه زمانی طولانی، مثلاً 10 دقیقه. برای یک سرویس استریمینگ یا بکاپگیری شبانه، throughput پایدار مهم است. iPerf3 با پارامتر -t 600 میتواند یک تست 10 دقیقهای اجرا کند و throughput پایدار را به شما بدهد. اگر این عدد خیلی کمتر از سرعت نقطهای باشد، یعنی تجهیزات شما یا ISP نمیتوانند بار سنگین را برای مدت طولانی تحمل کنند.
MOS Score: معیار کیفیت تجربه کاربر (QoE)
MOS (Mean Opinion Score) یک شاخص 1 تا 5 است که کیفیت تجربه کاربر را در اپلیکیشنهای صوتی و تصویری نشان میدهد. این شاخص ترکیبی از latency، jitter و packet loss است. خیلی از ابزارهای مانیتورینگ شبکه مثل LibreNMS میتوانند MOS را محاسبه کنند. برای یک سرویس حرفهای، MOS باید بالای 4 باشد. اگر زیر 3.5 باشد، کاربران از کیفیت شکایت خواهند کرد. تست سرعت پهنای باند اختصاصی بدون محاسبه MOS، ناقص است.
روششناسی صحیح: چگونه تستی معتبر انجام دهیم؟
داشتن ابزار خوب کافی نیست. باید روش درست تست را هم بلد باشید.
نصب iPerf3 روی سرور و کلاینت تست
روی سرور اوبونتو/دبیان، دستور sudo apt install iperf3 کافی است. سپس باید iPerf3 را بهعنوان سرویس اجرا کنید: iperf3 -s -D -p 5201. این سرور را در background اجرا میکند و به پورت 5201 گوش میدهد. روی کلاینت تست هم iPerf3 را نصب کنید. مطمئن شوید فایروال پورت 5201 را باز کرده باشید. این نصب ساده، پایه تمام تستهای حرفهای شماست.
دستورات دقیق تست TCP و UDP
برای تست TCP: iperf3 -c SERVER_IP -t 60 -P 10 -i 10. این دستور 10 کانکشن همزمان به مدت 60 ثانیه اجرا میکند و هر 10 ثانیه یکبار گزارش میدهد. برای تست UDP: iperf3 -c SERVER_IP -u -b 100M -t 60. این دستور UDP را با نرخ 100Mbps تست میکند. UDP مهم است چون بستههایش تایید نمیشوند و packet loss را بهتر نشان میدهد. همیشه هر دو را جداگانه تست کنید.
تست دوطرفه (Full Duplex) و نیمهدوطرفه (Half Duplex)
در Full Duplex، داده همزمان در دو جهت جریان دارد (مثل یک تماس ویدیویی). iPerf3 این را با دو نمونه همزمان پشتیبانی میکند: یکی برای آپلود و یکی برای دانلود. دستور iperf3 -c SERVER_IP --bidir این کار را انجام میدهد. اگر سرعت در یک جهت خوب باشد اما در جهت دیگر نه، مشکل از مسیر روتینگ یا QoS ISP است.
مدت زمان ایدهآل تست: ۳۰ ثانیه یا ۵ دقیقه؟
برای تست سریع، 30 ثانیه کافی است. اما برای تست پایدار، حداقل 5 دقیقه (300 ثانیه) باید تست کنید. بعضی از ISPها از الگوریتمهایی استفاده میکنند که سرعت را در ابتدای تست بالا میبرند و بعد محدود میکنند. تست طولانیتر این ترفندها را خنثی میکند. برای stress test، حتی 30 دقیقه هم توصیه میشود.
تست در بازههای زمانی مختلف: صبح، ظهر، شب
یک تست ساعت 3 صبح که همه خوابند، بیمعنی است. تست باید در ساعات کاری اصلی انجام شود. بهترین زمانها: 10 صبح (شروع کار)، 2 ظهر (پیک ناهار) و 9 شب (پیک شبانه). اگر تفاوت بین این ساعات بیش از 3-5% باشد، یعنی زیرساخت ISP مشکل دارد.
تحلیل نتایج: چه عددی خوب است و چه عددی نگرانکننده است؟
حالا که تستها را انجام دادید، وقت تفسیر نتایج است.
جدول استاندارد SLA برای کسبوکارهای مختلف
| نوع کسبوکار |
سرعت تضمینشده |
Latency Max |
Jitter Max |
Packet Loss Max |
MOS Min |
| هاستینگ وب سایت |
100Mbps/1Gbps |
20ms |
5ms |
0.1% |
4.0 |
| VoIP Provider |
10Mbps/10Mbps |
30ms |
10ms |
0.5% |
3.8 |
| Game Server |
100Mbps/100Mbps |
15ms |
3ms |
0.05% |
4.2 |
| استریمینگ ویدیو |
50Mbps/50Mbps |
25ms |
8ms |
0.2% |
3.9 |
| دفتر کار معمولی |
20Mbps/20Mbps |
40ms |
15ms |
0.5% |
3.5 |
اگر نتایج شما از حداکثرهای جدول بالاتر رفت، زنگ خطر به صدا در بیاید.
تفاوت سرعت تئوری و سرعت مؤثر (Goodput)
سرعت تئوری (Throughput) همان چیزی است که تست به شما میدهد. اما سرعت مؤثر (Goodput) یعنی سرعت انتقال دادههای واقعی بدون هدر TCP/IP و بدون retransmission. Goodput تقریباً 95% Throughput است. اگر خیلی کمتر از این است، یعنی packet loss یا مشکل از تنظیمات MTU دارید.
چه زمانی باید به ISP شکایت کنید؟
وقتی یکی از این شرایط برقرار باشد: 1) سرعت پایدار بیش از 10% پایینتر از تضمینشده است. 2) Packet Loss بیش از 0.1% در یک هفته. 3) Latency بالای 50ms برای بیش از 5% زمان. 4) SLA نقض شده در سه نوبت متوالی. در این موارد، لاگهای خود را از LibreNMS یا اسکریپتتان بگیرید و به پشتیبانی فنی ISP ارسال کنید. بدون لاگهای 24/7، شکایت شما قابل اثبات نیست.
محاسبه ضریب اطمینان (Safety Factor)
اگر سرور شما باید به 100 کاربر سرویس بدهد، هر کدام 10Mbps نیاز دارند، یعنی 1Gbps. اما نباید دقیقاً 1Gbps بگیرید. ضریب اطمینان 1.3 را در نظر بگیرید، یعنی 1.3Gbps. این فضای خالی برای اوجگیری (burst) و برای زمان تعمیرات ISP لازم است. تست سرعت پهنای باند اختصاصی باید نشان دهد که این ظرفیت اضافی را دارید یا نه.
تستهای پیشرفته: Bandwidth, Burst و Stress Test
برای اطمینان کامل، باید تستهای پیشرفتهتری انجام دهید.
تست بار سنگین (Stress Test) برای چک کردن توان سرور
دستور iperf3 -c SERVER_IP -t 1800 -P 100 -b 1G یک تست نیمساعته با 100 کانکشن همزمان و نرخ 1Gbps ایجاد میکند. این استرس تست نامیده میشود. اگر سرور یا تجهیزات شما تحمل نکنند، throughput افت میکند یا packet loss افزایش پیدا میکند. این تست را هر 3 ماه یکبار انجام دهید.
تست Burst: سرعت لحظهای vs سرعت پایدار
بعضی از ISPها اجازه میدهند برای چند ثانیه (مثلاً 10 ثانیه) سرعت بالاتر از حد تضمینشده بروید. این Burst مفید است اما باید تست کنید که واقعاً کار میکند یا نه. دستور iperf3 -c SERVER_IP -b 2G -t 10 این را تست میکند. اگر سرعت به 2Gbps نرسید، Burst فعال نیست یا محدودیتهای دیگری وجود دارد.
Simultaneous Connections: تست با ۱۰۰ کلاینت همزمان
یک سرور میتواند به راحتی یک کانکشن 1Gbps را پوشش دهد، اما آیا میتواند 100 کانکشن 10Mbps را همزمان مدیریت کند؟ این تست شبیهسازی دنیای واقعی است. از اسکریپت Bash استفاده کنید تا 100 نمونه iPerf3 همزمان اجرا شود. اگر سرعت میانگین از حد انتظار کمتر باشد، مشکل از تیونینگ kernel لینوکس یا محدودیتهای NIC است.
تست از نقاط جغرافیایی مختلف (Ping from Iran, Europe, Asia)
اگر کاربران شما از سراسر جهان هستند، باید latency را از چندین نقطه تست کنید. از سرویسهایی مثل
Ping.pe یا
Site24x7 استفاده کنید تا از 10 نقطه مختلف دنیا به سرورتان پینگ بزنید. این به شما دیدگاه جهانی میدهد و نشان میدهد کدام مسیرهای ISP مشکل دارند.
عیبیابی: وقتی سرعت تست با سرعت قرارداد تطابق ندارد
گاهی نتایج تست نامطلوب است. حالا باید بفهمید مشکل از کجاست.
Checklist بررسی تنظیمات NIC و MTU
اولین قدم: ethtool eth0 را بزنید. ببینید سرعت NIC روی 1Gbps یا 10Gbps ست شده یا نه. MTU را چک کنید: ifconfig eth0 | grep MTU. برای شبکه محلی، MTU باید 1500 باشد. برای اینترنت، بعضیوقتها 1492. اگر MTU نادرست باشد، packet fragmentation اتفاق میافتد و throughput افت میکند.
تأثیر فایروال و IDS/IPS روی throughput
فایروالهایی مثل iptables یا IDS/IPS مثل Snort میتوانند throughput را 30% کاهش دهند. برای تست، فایروال را بهطور موقت غیرفعال کنید: sudo iptables -F. اگر سرعت زیاد شد، یعنی قوانین فایروال شما خیلی سنگیناند. آنها را بهینهسازی کنید یا از hardware firewall استفاده کنید.
محدودیتهای kernel لینوکس: TCP Window Size
TCP Window Size تعیین میکند چقدر داده میتواند بدون تایید دریافت، ارسال شود. اگر کوچک باشد، throughput پایین میآید. مقدار را چک کنید: sysctl net.ipv4.tcp_rmem. برای شبکههای پرسرعت، این مقادیر را زیاد کنید: sysctl -w net.ipv4.tcp_rmem='4096 87380 16777216'. این تیونینگ میتواند throughput را 2 برابر کند.
زمانی که مشکل از ISP نیست: مسیر یابی (Traceroute)
گاهی مشکل از ISP نیست، بلکه از یک میانبر (hop) بین شما و ISP است. از traceroute -I 8.8.8.8 استفاده کنید تا ببینید کدام hop تأخیر بالا دارد. اگر hop اول (مودم شما) یا hop دوم (ISP) مشکل دارد، مسئولیت ISP است. اگر hopهای بعدی، باید با ISP تماس بگیرید تا مسیر را تغییر دهد.
مانیتورینگ مداوم: ابزارهای اتوماسیون تست سرعت
تست یکباره فایده ندارد. باید مانیتورینگ 24/7 داشته باشید.
نصب LibreNMS برای گرفتن نمودار سرعت ۲۴/۷
LibreNMS یک سیستم مانیتورینگ متنباز است که میتواند SNMP یا API iPerf3 را پول کند و نمودارهای لحظهای بکشد. نصب آن ساده است: wget https://raw.githubusercontent.com/librenms/librenms-agent/master/snmp/os-update.py. سپس یک cron job اضافه کنید تا هر ساعت یکبار تست اجرا شود.
اسکریپتهای Bash برای تست خودکار روزانه
یک اسکریپت ساده Bash میتواند هر روز ساعت 3 صبح تست را اجرا کند:
#!/bin/bash
DATE=$(date +%Y%m%d_%H%M%S)
iperf3 -c SERVER_IP --json > /var/log/iperf3_$DATE.json
این اسکریپت را در cron قرار دهید: 0 3 * * * /path/to/script.sh. حالا شما آرشیو کاملی از نتایج دارید.
ارسال Alert به تلگرام/ایمیل در صورت افت سرعت
با اسکریپتی ساده میتوانید نتایج را چک کنید و در صورت افت سرعت، هشدار بفرستید:
SPEED=$(iperf3 -c SERVER_IP -J | jq '.end.sum_received.bits_per_second')
if [ $SPEED -lt 100000000 ]; then
curl -s "https://api.telegram.org/botTOKEN/sendMessage?chat_id=ID&text=Speed dropped!"
fi
نگهداری لاگها برای اثبات نقض SLA
تمام لاگها را حداقل یک سال نگه دارید. ISPها معمولاً فقط 30 روز لاگ نگه میدارند. اگر شما یک سال داده داشته باشید، در صورت اختلاف حقوقی، سند محکمی دارید. لاگها را در فایلهای CSV با تاریخ مشخص ذخیره کنید و از آنها بکاپ بگیرید.
نتیجهگیری: چکلیست نهایی برای تست سرعت حرفهای
بیایید یک خلاصه عملیاتی بسازیم:
دوبار تست کنید: از داخل و خارج دیتاسنتر
همیشه تست را هم از داخل دیتاسنتر (LAN) و هم از خارج (WAN) انجام دهید. تست LAN مشکلات داخلی را نشان میدهد و تست WAN مشکلات ISP را.
همیشه UDP و TCP را جداگانه تست کنید
TCP برای وبسایتها و UDP برای VoIP/استریمینگ مهم است. هر کدام رفتار متفاوتی دارند. تست جداگانه، تصویر کاملی به شما میدهد.
نتایج را در فایل CSV آرشیو کنید
دستور iperf3 -c SERVER_IP --csv >> results.csv خیلی ساده است اما ارزشمند. با گذشت زمان، میتوانید trends را تحلیل کنید و پیشبینی کنید کی باید ارتقا بدهید.
هر ۳ ماه یکبار Stress Test انجام دهید
Stress Test منظم، مشکلات بالقوه را قبل از اینکه به فاجعه تبدیل شوند، نشان میدهد. یک یادآوری در تقویم بگذارید: هر 3 ماه یکبار، یک تست 30 دقیقهای با 100 کانکشن.
سوالات متداول
آیا تست سرعت معمولی Speedtest.net برای باند اختصاصی کافی نیست؟
نه، به هیچ وجه. Speedtest.net سرورهای عمومی دارد و نمیتواند پارامترهایی مثل jitter، packet loss و throughput پایدار را با دقت نشان دهد. برای باند اختصاصی، به iPerf3 یا ابزارهای مشابه نیاز دارید.
چه تفاوتی بین تست TCP و UDP وجود دارد و چرا باید هر دو را انجام داد؟
TCP بستهها را تایید میکند و جریان داده قابل اعتمادی دارد اما سربار (overhead) دارد. UDP بدون تایید است و برای اپلیکیشنهای زنده مثل VoIP و گیمینگ استفاده میشود. تست جداگانه، مشکلات مربوط به هر پروتکل را جداگانه نشان میدهد.
چند وقت یکبار باید تست سرعت پهنای باند اختصاصی را انجام دهم؟
حداقل هفتهای یکبار تست دستی و روزانه تست خودکار. اما برای کسبوکارهای حساس، مانیتورینگ 24/7 توصیه میشود. Stress Test هم هر 3 ماه یکبار کافی است.
اگر سرعت تست از سرعت قرارداد کمتر بود، اولین قدم چیست؟
اول فایروال و تجهیزات داخلی را چک کنید. سپس MTU و TCP Window Size را تنظیم کنید. اگر همه چیز درست بود، از traceroute استفاده کنید تا ببینید مشکل از کدام hop است. سپس لاگها را به ISP بفرستید.
آیا میتوان از تست سرعت برای اثبات نقض SLA در دادگاه استفاده کرد؟
بله، اگر لاگهای دقیق و مداوم داشته باشید. لاگها باید شامل تاریخ، زمان، تمام پارامترها و بهصورت دستنخورده باشند. استفاده از ابزارهایی مثل LibreNMS که لاگها را امضای دیجیتال میکنند، ارزش قانونی بالاتری دارد.
