ماشین حساب پهنای باند و تاخیر شبکه

نرخ لینک، زمان رفت و برگشت و اندازه انتقال را وارد کنید تا سقف واقعی یک جریان تک TCP را همراه با نام گلوگاه، زمان انتقال و تمام جایگذاری‌ها مشاهده کنید.

مسیر

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

انتقال

داده مفیدی که باید منتقل شود — یک فایل، یک بکاپ یا یک مجموعه داده.

پارامترهای TCP

بایت‌هایی که گیرنده می‌تواند بافر کند. 65,535 حداکثر مقدار بدون مقیاس است؛ خالی = بدون محدودیت پنجره.
بایت‌های داده مفید در هر بسته — مقدار 1,460 یک فریم استاندارد اترنت را پر می‌کند. خالی = نادیده گرفتن سربار و اتلاف.
میانگین احتمال اتلاف بسته. خالی یا 0 = بدون محدودیت اتلاف.

Throughput و زمان انتقال

TCP throughput مورد انتظار

نرخ لینک، زمان رفت و برگشت و اندازه داده را وارد کنید.

فرمول‌ها و جایگذاری

throughput = min(نرخ × بازدهی, پنجره ÷ RTT, MSS ÷ RTT ÷ √p) · BDP = نرخ × RTT

    هر مقداری که وارد می‌کنید در همین مرورگر محاسبه می‌شود — هیچ چیز به هیچ کجا ارسال نمی‌شود.

    سوالات متداول

    چرا سرعت انتقال من از نرخ لینکی که برای آن هزینه پرداخت می‌کنم کمتر است؟

    یک جریان تک TCP با سه سقف مستقل مواجه است و کمترین آن‌ها اعمال می‌شود. سربار پروتکل خود لینک را حدود 5% کاهش می‌دهد — یک فریم استاندارد اترنت 1,460 بایت داده مفید از 1,538 بایت روی سیم را حمل می‌کند. پنجره دریافت، throughput را به نسبت window ÷ RTT محدود می‌کند، بنابراین پنجره کلاسیک 65,535 بایتی، یک مسیر 50 میلی‌ثانیه‌ای را بدون توجه به سرعت لینک، به حدود 10.5 Mbit/s محدود نگه می‌دارد. همچنین اتلاف بسته، آن را به فرمول (MSS ÷ RTT) ÷ √loss محدود می‌کند. نتیجه بالا نشان می‌دهد کدام سقف روی اعداد شما تاثیرگذار و محدودکننده است.

    حاصل‌ضرب پهنای باند در تاخیر چیست و چرا اندازه پنجره را تعیین می‌کند؟

    شاخص BDP — حاصل‌ضرب نرخ لینک در زمان رفت و برگشت — مقدار داده‌های در حال انتقال در هر لحظه است. TCP می‌تواند حداکثر یک پنجره تاییدنشده در جریان داشته باشد، بنابراین پنجره‌ای کوچکتر از BDP لوله را تا حدی خالی می‌گذارد: در سرعت 100 Mbit/s با RTT معادل 50 میلی‌ثانیه، ظرفیت لوله 625 kB است و یک پنجره 65,535 بایتی به سختی یک‌دهم آن را پر می‌کند. به همین دلیل است که مسیرهای سریع و طولانی به مقیاس‌گذاری پنجره TCP (RFC 7323) نیاز دارند که سقف قابل مذاکره را از 65,535 بایت به حدود 1 گیگابایت افزایش می‌دهد.

    اتلاف بسته چگونه throughput پروتکل TCP را محدود می‌کند؟

    پروتکل TCP با اتلاف بسته مانند احتقان رفتار می‌کند و با هر رویداد اتلاف، نرخ ارسال خود را نصف می‌کند؛ بنابراین حتی نرخ‌های اتلاف بسیار کوچک نیز در مسیرهای سریع اهمیت دارند. مدل Mathis سقف را به صورت (MSS ÷ RTT) ÷ √p تخمین می‌زند — در اتلاف 0.01% در یک مسیر 50 میلی‌ثانیه‌ای با MSS معادل 1,460 بایت، این مقدار بدون توجه به سرعت لینک، حدود 23 Mbit/s است. این مدل فرض می‌کند رویدادهای اتلاف به طور یکنواخت توزیع شده و مستقل هستند؛ زیر تقریباً 1% به خوبی با واقعیت همخوانی دارد و برای اتلاف‌های خوشه‌ای (bursty)، خوش‌بینانه است.

    آیا مگابایت‌های اینجا با مگابایت‌های مدیریت‌کننده فایل من یکی هستند؟

    نه کاملاً. این صفحه از واحدهای دهدهی که مرسوم شبکه‌سازی است استفاده می‌کند: 1 kbit = 1,000 bits و 1 MB = 1,000,000 bytes. اکثر مدیریت‌کننده‌های فایل بر اساس واحدهای مبنای 1024 محاسبه می‌کنند که اغلب به اشتباه MB نامیده می‌شوند — یک فایل «100 MB» در آنجا معمولاً 100 MiB ≈ 104.86 مگابایت دهدهی است، بنابراین انتقال آن حدود 5% بیشتر از آنچه رقم دهدهی نشان می‌دهد طول می‌کشد. برای مطابقت دقیق، عدد 104.86 MB را در اینجا وارد کنید.

    درک سقف عملکرد پروتکل TCP

    عملکرد واقعی یک جریان تک TCP (Single TCP Flow) در شبکه، به ندرت با حداکثر سرعت اسمی یا همان نرخ لینک برابر است. در واقعیت، سرعت انتقال داده‌ها تحت تأثیر تعامل پیچیده میان پهنای باند، تاخیر مسیر (RTT)، اندازه پنجره دریافت، اندازه سگمنت پیام (MSS) و نرخ اتلاف بسته قرار دارد. ماشین حساب پهنای باند و تاخیر شبکه با در نظر گرفتن تمامی این متغیرها، سقف تئوریک و عملی انتقال داده را محاسبه کرده و گلوگاه اصلی مسیر را مشخص می‌کند.

    محاسبات این ابزار بر اساس سه محدودکننده یا سقف مستقل انجام می‌شود: ظرفیت لینک پس از کسر سربار پروتکل، سقف ناشی از محدودیت پنجره دریافت، و سقف ناشی از اتلاف بسته بر اساس مدل ریاضی Mathis. در نهایت، کمترین مقدار در میان این سه سقف، به عنوان TCP throughput مورد انتظار تعیین می‌شود.

    ورودی‌های محاسباتی مسیر و پروتکل

    برای سنجش دقیق عملکرد شبکه، ابزار به چندین ورودی کلیدی نیاز دارد که شرایط فیزیکی مسیر و تنظیمات پروتکل را شبیه‌سازی می‌کنند:

    • نرخ لینک: این مقدار نشان‌دهنده کندترین هاپ در مسیر است که اغلب معادل سرعت اسمی طرح اینترنت شماست. این مقدار باید بزرگتر از صفر باشد.
    • زمان رفت و برگشت (RTT): زمان پینگ به مقصد نهایی که باید از بزرگترین مقداری که تحت بار شبکه انتظار دارید استفاده کنید. این مقدار نیز باید بزرگتر از صفر باشد.
    • اندازه داده: حجم داده مفیدی که باید منتقل شود، مانند یک فایل، یک بکاپ یا یک مجموعه داده. این مقدار باید بزرگتر از صفر باشد.
    • پنجره دریافت: بایت‌هایی که گیرنده می‌تواند بافر کند. مقدار ۶۵,۵۳۵ بایت حداکثر مقدار بدون مقیاس است. خالی گذاشتن این فیلد به معنای عدم اعمال محدودیت پنجره است و حداکثر مقدار مجاز آن ۱,۰۷۳,۷۲۵,۴۴۰ بایت می‌باشد.
    • MSS (بایت): بایت‌های داده مفید در هر بسته. مقدار ۱,۴۶۰ بایت یک فریم استاندارد اترنت را پر می‌کند. این مقدار باید یک عدد صحیح بین ۱ و ۶۵,۴۹۵ باشد. خالی گذاشتن آن باعث نادیده گرفتن سربار و اتلاف می‌شود.
    • اتلاف بسته (%): میانگین احتمال اتلاف بسته در مسیر که باید بین ۰ و ۱۰۰ درصد باشد. خالی یا ۰ گذاشتن آن به معنای بدون محدودیت اتلاف است.
    • تعداد ارقام اعشار نمایشی: میزان دقت اعشاری خروجی‌ها را کنترل می‌کند.

    کاربران می‌توانند با استفاده از دکمه بارگذاری نمونه مقادیر پیش‌فرض را بارگذاری کنند یا با دکمه پاک کردن تمامی فیلدها را بازنشانی نمایند.

    خروجی‌ها و تحلیل نتایج محاسبات

    پس از وارد کردن داده‌ها، ابزار نتایج را در سه بخش اصلی ارائه می‌دهد:

    Throughput و زمان انتقال

    • TCP throughput مورد انتظار: سرعت نهایی انتقال که با زیرعنوان محدود شده توسط ‹constraint› همراه است. این محدودیت می‌تواند یکی از موارد ظرفیت لینک، پنجره دریافت یا از دست رفتن بسته باشد.
    • زمان انتقال: کل زمان تخمینی برای ارسال داده.
    • زمان تا اولین بایت (1 RTT): تاخیر اولیه پیش از شروع انتقال داده.
    • زمان انتقال انبوه: زمان صرف‌شده برای انتقال خود داده‌ها بدون احتساب تاخیر اولیه.
    • حاصل‌ضرب پهنای باند در تاخیر: حجم داده‌های در حال انتقال در مسیر.
    • پنجره مورد نیاز برای پر کردن مسیر: حداقل اندازه بافر برای استفاده حداکثری از پهنای باند.
    • Throughput محدود به پنجره: سقف سرعت بر اساس محدودیت بافر گیرنده.
    • Throughput محدود به اتلاف (Mathis): سقف سرعت بر اساس نرخ اتلاف بسته.
    • سقف لینک پس از کسر سربار: حداکثر سرعت ممکن پس از کسر هدرهای پروتکل.
    • بازدهی پروتکل: نسبت داده مفید به کل داده ارسالی روی سیم.

    اعلان‌های پویای سیستم

    بر اساس مقادیر ورودی، سیستم هشدارهای زیر را نمایش می‌دهد:

    • "پر کردن این مسیر به یک پنجره ‹window› نیاز دارد — بالاتر از حداکثر مقدار بدون مقیاس 65,535 بایت، بنابراین هر دو طرف باید مقیاس‌گذاری پنجره TCP (RFC 7323) را مذاکره کنند."
    • "پر کردن این مسیر به ‹window› نیاز دارد — فراتر از بزرگترین پنجره‌ای که TCP می‌تواند مذاکره کند (1,073,725,440 بایت). یک جریان تک در این مسیر هرگز نمی‌تواند از ‹value› فراتر رود."
    • "افزایش پنجره دریافت به ‹window› به این انتقال اجازه می‌دهد تا به ‹value› برسد."
    • "اتلاف بالای 1% خارج از محدوده قابل اعتماد مدل Mathis است — سقف اتلاف را خوش‌بینانه در نظر بگیرید."

    فرمول‌ها و نحوه جایگذاری مقادیر

    محاسبات ریاضی ابزار به طور شفاف در بخش فرمول‌ها و جایگذاری نمایش داده می‌شود:

    • فرمول اصلی: throughput = min(نرخ × بازدهی, پنجره ÷ RTT, MSS ÷ RTT ÷ √p) · BDP = نرخ × RTT
    • بازدهی پروتکل: بازدهی پروتکل = MSS ÷ (MSS + 78 B) = ‹mss› ÷ ‹frame› = ‹eff› (۴۰ بایت هدر بسته + ۳۸ بایت روی سیم)
    • سقف لینک: سقف لینک = نرخ × بازدهی = ‹rate› × ‹eff› = ‹value›
    • حاصل‌ضرب پهنای باند در تاخیر (BDP): BDP = نرخ × RTT = ‹rate› × ‹rtt› = ‹bdp› = ‹bytes›
    • پنجره مورد نیاز برای پر کردن مسیر: پنجره مورد نیاز برای پر کردن مسیر = BDP ÷ 8 = ‹bdp› → ‹window›
    • سقف پنجره: سقف پنجره = پنجره ÷ RTT = ‹window› ÷ ‹rtt› = ‹value›
    • سقف اتلاف (Mathis): سقف اتلاف (Mathis) = MSS ÷ RTT ÷ √p = ‹mss› ÷ ‹rtt› ÷ √‹p› = ‹value›
    • Throughput مورد انتظار: throughput مورد انتظار = کمترین سقف موجود = ‹value› ← محدود شده توسط ‹constraint›
    • زمان انتقال: زمان انتقال = RTT + 8 × اندازه ÷ throughput = ‹rtt› + 8 × ‹size› ÷ ‹throughput› = ‹time›

    کاربران می‌توانند با استفاده از دکمه کپی کردن نتیجه تمامی این محاسبات و نتایج را ذخیره کنند.

    قوانین، محدودیت‌ها و خطاهای سیستم

    در محاسبات این ابزار قواعد فنی زیر اعمال می‌شود:

    • سربار پروتکل: محاسبات بر اساس استاندارد اترنت انجام می‌شود که ۷۸ بایت سربار به هر بسته اضافه می‌کند (۴۰ بایت هدر TCP/IP و ۳۸ بایت سربار فیزیکی سیم).
    • محدودیت‌های مدل Mathis: این مدل فرض می‌کند اتلاف بسته‌ها به صورت یکنواخت و مستقل رخ می‌دهد. این فرمول تنها برای نرخ‌های اتلاف زیر ۱٪ دقیق است و برای مقادیر بالاتر، هشدار صادر می‌شود.
    • محدودیت‌های مدل‌سازی: محاسبات برای حالت پایدار یک جریان تک TCP انجام می‌شود. مواردی چون شروع آهسته (slow start)، تنظیمات کنترل احتقان، گیرنده کند و دست‌دهی‌های TLS در این مدل لحاظ نشده‌اند، بنابراین انتقال‌های واقعی ممکن است کندتر باشند.

    پیام‌های خطا

    در صورت ورود داده‌های نامعتبر، سیستم خطاهای زیر را نمایش می‌دهد:

    • عدم امکان پردازش عدد: "‹field›: «‹token›» یک عدد نیست."
    • نرخ لینک نامعتبر: "نرخ لینک باید بزرگتر از صفر باشد."
    • زمان رفت و برگشت نامعتبر: "زمان رفت و برگشت باید بزرگتر از صفر باشد."
    • اندازه داده نامعتبر: "اندازه داده باید بزرگتر از صفر باشد."
    • پنجره دریافت نامعتبر: "پنجره دریافت باید بزرگتر از صفر باشد."
    • پنجره فراتر از حد استاندارد: "پروتکل TCP نمی‌تواند پنجره‌ای بزرگتر از 1,073,725,440 بایت را مذاکره کند (مقیاس‌گذاری پنجره RFC 7323)."
    • مقدار MSS خارج از محدوده: "مقدار MSS باید یک عدد صحیح بین 1 و 65,495 بایت باشد."
    • نرخ اتلاف خارج از محدوده: "نرخ اتلاف باید بین 0 و 100 درصد باشد."
    • سرریز محاسباتی: "یک مقدار یا نتیجه میانی از محدوده عددی پشتیبانی‌شده فراتر رفته است."

    حریم خصوصی و پردازش داده‌ها

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


    سوالات متداول (FAQ)

    چرا سرعت انتقال من از نرخ لینکی که برای آن هزینه پرداخت می‌کنم کمتر است؟

    یک جریان تک TCP با سه سقف مستقل مواجه است و کمترین آن‌ها اعمال می‌شود. سربار پروتکل خود لینک را حدود 5% کاهش می‌دهد — یک فریم استاندارد اترنت 1,460 بایت داده مفید از 1,538 بایت روی سیم را حمل می‌کند. پنجره دریافت، throughput را به نسبت window ÷ RTT محدود می‌کند، بنابراین پنجره کلاسیک 65,535 بایتی، یک مسیر 50 میلی‌ثانیه‌ای را بدون توجه به سرعت لینک، به حدود 10.5 Mbit/s محدود نگه می‌دارد. همچنین اتلاف بسته، آن را به فرمول (MSS ÷ RTT) ÷ √loss محدود می‌کند. نتیجه بالا نشان می‌دهد کدام سقف روی اعداد شما تاثیرگذار و محدودکننده است.

    حاصل‌ضرب پهنای باند در تاخیر چیست و چرا اندازه پنجره را تعیین می‌کند؟

    شاخص BDP — حاصل‌ضرب نرخ لینک در زمان رفت و برگشت — مقدار داده‌های در حال انتقال در هر لحظه است. TCP می‌تواند حداکثر یک پنجره تاییدنشده در جریان داشته باشد، بنابراین پنجره‌ای کوچکتر از BDP لوله را تا حدی خالی می‌گذارد: در سرعت 100 Mbit/s با RTT معادل 50 میلی‌ثانیه، ظرفیت لوله 625 kB است و یک پنجره 65,535 بایتی به سختی یک‌دهم آن را پر می‌کند. به همین دلیل است که مسیرهای سریع و طولانی به مقیاس‌گذاری پنجره TCP (RFC 7323) نیاز دارند که سقف قابل مذاکره را از 65,535 بایت به حدود 1 گیگابایت افزایش می‌دهد.

    اتلاف بسته چگونه throughput پروتکل TCP را محدود می‌کند؟

    پروتکل TCP با اتلاف بسته مانند احتقان رفتار می‌کند و با هر رویداد اتلاف، نرخ ارسال خود را نصف می‌کند؛ بنابراین حتی نرخ‌های اتلاف بسیار کوچک نیز در مسیرهای سریع اهمیت دارند. مدل Mathis سقف را به صورت (MSS ÷ RTT) ÷ √p تخمین می‌زند — در اتلاف 0.01% در یک مسیر 50 میلی‌ثانیه‌ای با MSS معادل 1,460 بایت، این مقدار بدون توجه به سرعت لینک، حدود 23 Mbit/s است. این مدل فرض می‌کند رویدادهای اتلاف به طور یکنواخت توزیع شده و مستقل هستند؛ زیر تقریباً 1% به خوبی با واقعیت همخوانی دارد و برای اتلاف‌های خوشه‌ای (bursty)، خوش‌بینانه است.

    آیا مگابایت‌های اینجا با مگابایت‌های مدیریت‌کننده فایل من یکی هستند؟

    نه کاملاً. این صفحه از واحدهای دهدهی که مرسوم شبکه‌سازی است استفاده می‌کند: 1 kbit = 1,000 bits و 1 MB = 1,000,000 bytes. اکثر مدیریت‌کننده‌های فایل بر اساس واحدهای مبنای 1024 محاسبه می‌کنند که اغلب به اشتباه MB نامیده می‌شوند — یک فایل «100 MB» در آنجا معمولاً 100 MiB ≈ 104.86 مگابایت دهدهی است، بنابراین انتقال آن حدود 5% بیشتر از آنچه رقم دهدهی نشان می‌دهد طول می‌کشد. برای مطابقت دقیق، عدد 104.86 MB را در اینجا وارد کنید.