نیٹ ورک لیٹنسی بینڈوتھ کیلکولیٹر

ایک سنگل TCP فلو کی حقیقی حد دیکھنے کے لیے لنک ریٹ، راؤنڈ ٹرپ ٹائم اور منتقلی کا سائز درج کریں — رکاوٹ کی نشاندہی، منتقلی کے وقت اور ہر متبادل کے ساتھ۔

راستہ

راستے کا سب سے سست ہاپ — اکثر آپ کے پلان کی طے شدہ رفتار۔
دوسرے سرے تک پنگ کا وقت — لوڈ کے تحت متوقع سب سے بڑی قدر استعمال کریں۔

منتقلی

منتقل کرنے کے لیے پے لوڈ — ایک فائل، ایک بیک اپ، یا ڈیٹا سیٹ۔

TCP پیرامیٹرز

بائٹس جنہیں رسیور بفر کر سکتا ہے۔ 65,535 غیر اسکیل شدہ زیادہ سے زیادہ حد ہے؛ خالی = ونڈو کی کوئی حد نہیں۔
پے لوڈ بائٹس فی پیکٹ — 1,460 ایک معیاری ایتھرنیٹ فریم کو بھرتا ہے۔ خالی = اوور ہیڈ اور نقصان کو نظر انداز کریں۔
اوسط پیکٹ نقصان کا امکان۔ خالی یا 0 = نقصان کی کوئی حد نہیں۔

تھرو پٹ اور منتقلی کا وقت

متوقع TCP تھرو پٹ

لنک ریٹ، راؤنڈ ٹرپ ٹائم اور ڈیٹا کا سائز درج کریں۔

فارمولے اور متبادل

تھرو پٹ = min(شرح × eff، window ÷ RTT، MSS ÷ RTT ÷ √p) · BDP = شرح × RTT

    آپ جو بھی قدر درج کرتے ہیں اس کا حساب اسی براؤزر میں لگایا جاتا ہے — کہیں بھی کچھ نہیں بھیجا جاتا۔

    عمومی سوالات

    میری منتقلی اس لنک ریٹ سے سست کیوں ہے جس کے لیے میں ادائیگی کرتا ہوں؟

    ایک واحد TCP فلو کو تین آزاد حدوں کا سامنا ہوتا ہے، اور سب سے کم حد جیت جاتی ہے۔ پروٹوکول اوور ہیڈ لنک کو خود تقریباً 5% تک کم کر دیتا ہے — ایک معیاری ایتھرنیٹ فریم تار پر موجود 1,538 بائٹس میں سے 1,460 پے لوڈ بائٹس لے جاتا ہے۔ رسیو ونڈو تھرو پٹ کو window ÷ RTT پر محدود کرتی ہے، اس لیے کلاسک 65,535 بائٹس کی ونڈو 50 ms کے راستے کو تقریباً 10.5 Mbit/s تک محدود رکھتی ہے چاہے لنک کتنا ہی تیز ہو۔ اور نقصان اسے (MSS ÷ RTT) ÷ √loss پر محدود کر دیتا ہے۔ اوپر دیا گیا نتیجہ یہ بتاتا ہے کہ آپ کے نمبروں پر کون سی حد لاگو ہو رہی ہے۔

    بینڈوتھ ڈیلے پروڈکٹ کیا ہے، اور یہ ونڈو کے سائز کا تعین کیوں کرتی ہے؟

    BDP — لنک ریٹ × راؤنڈ ٹرپ ٹائم — کسی بھی لمحے میں زیرِ منتقلی ڈیٹا کی مقدار ہے۔ TCP کے پاس زیادہ سے زیادہ ایک غیر تسلیم شدہ ونڈو بقایا ہو سکتی ہے، اس لیے BDP سے چھوٹی ونڈو پائپ کو جزوی طور پر خالی چھوڑ دیتی ہے: 50 ms RTT کے ساتھ 100 Mbit/s پر پائپ میں 625 kB ڈیٹا سما سکتا ہے، اور 65,535 بائٹس کی ونڈو اس کا بمشکل دسواں حصہ بھرتی ہے۔ یہی وجہ ہے کہ تیز رفتار، طویل راستوں کو TCP ونڈو اسکیلنگ (RFC 7323) کی ضرورت ہوتی ہے، جو گفت و شنید کے قابل زیادہ سے زیادہ حد کو 65,535 بائٹس سے بڑھا کر تقریباً 1 GB کر دیتی ہے۔

    پیکٹ کا نقصان TCP تھرو پٹ کو کس طرح محدود کرتا ہے؟

    TCP نقصان کو نیٹ ورک کا رش سمجھتا ہے اور ہر نقصان کے واقعے پر اپنی بھیجنے کی شرح کو آدھا کر دیتا ہے، اس لیے تیز رفتار راستوں پر نقصان کی معمولی شرحیں بھی اہمیت رکھتی ہیں۔ Mathis ماڈل حد کا تخمینہ (MSS ÷ RTT) ÷ √p کے طور پر لگاتا ہے — 1,460 بائٹس MSS کے ساتھ 50 ms کے راستے پر 0.01% نقصان پر یہ تقریباً 23 Mbit/s بنتا ہے، قطع نظر لنک کی رفتار کے۔ یہ ماڈل یکساں طور پر پھیلے ہوئے، آزاد نقصانات کے واقعات کو فرض کرتا ہے؛ تقریباً 1% سے نیچے یہ حقیقت کے بالکل قریب رہتا ہے، اور یکمشت ہونے والے نقصانات کے لیے یہ پرامید ہے۔

    کیا یہاں میگا بائٹس وہی ہیں جو میرے فائل مینیجر میں ہوتے ہیں؟

    بالکل نہیں۔ یہ صفحہ اعشاریہ یونٹس استعمال کرتا ہے، جو نیٹ ورکنگ کا رواج ہے: 1 kbit = 1,000 bits اور 1 MB = 1,000,000 bytes۔ زیادہ تر فائل مینیجرز 1024 پر مبنی یونٹس میں گنتی کرتے ہیں، جن پر اکثر غلط طور پر MB کا لیبل لگا ہوتا ہے — وہاں ایک "100 MB" کی فائل عام طور پر 100 MiB ≈ 104.86 اعشاریہ MB ہوتی ہے، اس لیے اسے منتقل ہونے میں اعشاریہ کی شکل میں بتائے گئے وقت سے تقریباً 5% زیادہ وقت لگتا ہے۔ اس سے بالکل مطابقت رکھنے کے لیے یہاں 104.86 MB درج کریں۔

    نیٹ ورک پاتھ کی کارکردگی کا تعین

    نیٹ ورک پاتھ پر ڈیٹا کی منتقلی کی حقیقی رفتار صرف لنک کی خام رفتار پر منحصر نہیں ہوتی۔ جب ایک سنگل TCP فلو کے ذریعے ڈیٹا منتقل کیا جاتا ہے، تو نیٹ ورک کی تاخیر (Latency)، پیکٹ کا نقصان (Packet Loss)، اور رسیور کے بفر کا سائز مل کر ایک ایسی حد مقرر کرتے ہیں جس سے زیادہ رفتار حاصل کرنا ناممکن ہوتا ہے۔ یہ کیلکولیٹر ان تمام عوامل کو مدنظر رکھ کر آپ کے نیٹ ورک پاتھ کی حقیقی کارکردگی کی بالائی حد کا حساب لگاتا ہے۔

    اس ٹول کے ذریعے آپ لنک ریٹ، راؤنڈ ٹرپ ٹائم (RTT)، اور ڈیٹا کا سائز درج کر کے فوری طور پر یہ جان سکتے ہیں کہ آپ کے کنکشن میں کون سا عنصر سب سے بڑی رکاوٹ (Bottleneck) بنا ہوا ہے۔ یہ حساب کتاب مکمل طور پر ریاضیاتی ماڈلز پر مبنی ہے جو نیٹ ورک انجینئرز کو پاتھ ڈیزائن کرنے اور خرابیوں کو دور کرنے میں مدد دیتے ہیں۔

    ان پٹ پیرامیٹرز کی تفصیلات

    درست نتائج حاصل کرنے کے لیے کیلکولیٹر میں درج ذیل ان پٹ فراہم کرنا ضروری ہے:

    • لنک ریٹ: یہ آپ کے نیٹ ورک پاتھ کا سب سے سست ہاپ ہوتا ہے، جو عام طور پر آپ کے انٹرنیٹ پلان کی طے شدہ رفتار ہوتی ہے۔ یہ قدر صفر سے زیادہ ہونی چاہیے۔
    • راؤنڈ ٹرپ ٹائم (RTT): دوسرے سرے تک پنگ کا وقت، جو لوڈ کے تحت متوقع سب سے بڑی قدر کو ظاہر کرتا ہے۔ یہ قدر بھی صفر سے زیادہ ہونی چاہیے۔
    • ڈیٹا کا سائز: وہ پے لوڈ (فائل، بیک اپ یا ڈیٹا سیٹ) جسے آپ منتقل کرنا چاہتے ہیں۔ اس کا صفر سے زیادہ ہونا لازمی ہے۔
    • رسیو ونڈو: وہ بائٹس جنہیں رسیور بفر کر سکتا ہے۔ یہ قدر صفر سے زیادہ ہونی چاہیے اور یہ 1,073,725,440 بائٹس سے تجاوز نہیں کر سکتی۔ اگر اسے خالی چھوڑ دیا جائے تو ونڈو کی کوئی حد لاگو نہیں ہوتی۔
    • ایم ایس ایس (MSS): پے لوڈ بائٹس فی پیکٹ۔ یہ 1 اور 65,495 کے درمیان بائٹس کی ایک مکمل تعداد ہونی چاہیے۔ اسے خالی چھوڑنے سے اوور ہیڈ اور نقصان کو نظر انداز کر دیا جاتا ہے۔
    • پیکٹ کا نقصان (%): اوسط پیکٹ نقصان کا امکان، جو 0 اور 100 فیصد کے درمیان ہونا چاہیے۔ اسے خالی چھوڑنے یا 0 درج کرنے کا مطلب ہے کہ نقصان کی کوئی حد نہیں ہے۔
    • ظاہر کردہ اعشاریہ: یہ آؤٹ پٹ اقدار کی اعشاریہ کی درستگی کو کنٹرول کرتا ہے۔

    ان پٹس کو فوری طور پر سمجھنے کے لیے آپ مثال لوڈ کریں کا بٹن استعمال کر سکتے ہیں، جبکہ تمام فیلڈز کو دوبارہ ترتیب دینے کے لیے صاف کریں کا بٹن موجود ہے۔

    آؤٹ پٹ اور کارکردگی کے نتائج

    حساب کتاب مکمل ہونے پر ٹول نتائج کو تین اہم حصوں میں تقسیم کرتا ہے:

    متوقع تھرو پٹ اور منتقلی کا وقت

    سب سے نمایاں نتیجہ متوقع TCP تھرو پٹ کی شکل میں ظاہر ہوتا ہے، جس کے ساتھ ایک ذیلی لیبل یہ واضح کرتا ہے کہ یہ رفتار کس وجہ سے محدود ہے: "محدود بذریعہ ‹constraint›"۔ یہاں رکاوٹ بننے والے عنصر کا نام متحرک طور پر لنک کی گنجائش، رسیو ونڈو، یا پیکٹ کا نقصان دکھایا جاتا ہے۔

    اس کے علاوہ درج ذیل تفصیلی اعداد و شمار بھی فراہم کیے جاتے ہیں:

    • منتقلی کا وقت
    • پہلے بائٹ تک کا وقت (1 RTT)
    • بلک منتقلی کا وقت
    • بینڈوتھ ڈیلے پروڈکٹ
    • راستے کو بھرنے کے لیے ونڈو
    • ونڈو سے محدود تھرو پٹ
    • نقصان سے محدود تھرو پٹ (Mathis)
    • اوور ہیڈ کے بعد لنک کی حد
    • پروٹوکول کی کارکردگی

    آپ ان تمام حساب شدہ نتائج کو ایک کلک کے ذریعے محفوظ کرنے کے لیے نتیجہ کاپی کریں کا بٹن استعمال کر سکتے ہیں۔

    متحرک سسٹم نوٹس اور انتباہات

    درج کردہ اقدار کی بنیاد پر کیلکولیٹر نیٹ ورک کی حالت کے بارے میں اہم نوٹس جاری کرتا ہے:

    • ونڈو اسکیلنگ کی ضرورت: اگر راستے کو بھرنے کے لیے درکار ونڈو 65,535 بائٹس کی غیر اسکیل شدہ حد سے زیادہ ہو، تو سسٹم یہ نوٹ دکھاتا ہے: "اس راستے کو بھرنے کے لیے ‹window› ونڈو کی ضرورت ہے — جو کہ 65,535 بائٹس کی غیر اسکیل شدہ حد سے زیادہ ہے، اس لیے دونوں سروں کو TCP ونڈو اسکیلنگ (RFC 7323) پر گفت و شنید کرنی ہوگی۔"
    • ونڈو اسکیلنگ کی حد سے تجاوز: اگر درکار ونڈو TCP کی انتہائی حد سے بھی بڑھ جائے: "اس راستے کو بھرنے کے لیے ‹window› کی ضرورت ہے — جو کہ سب سے بڑی ونڈو سے زیادہ ہے جس پر TCP گفت و شنید کر سکتا ہے (1,073,725,440 بائٹس)۔ اس راستے پر ایک واحد فلو کبھی بھی ‹value› سے تجاوز نہیں کر سکتا۔"
    • ونڈو بڑھانے کی ترغیب: اگر رسیو ونڈو کو بڑھا کر تھرو پٹ کو بہتر کیا جا سکتا ہو: "رسیو ونڈو کو ‹window› تک بڑھانے سے یہ منتقلی ‹value› تک پہنچ سکتی ہے۔"
    • زیادہ نقصان کا انتباہ: اگر پیکٹ کا نقصان 1% سے زیادہ ہو جائے: "1% سے زیادہ نقصان Mathis ماڈل کی قابل اعتماد حد سے باہر ہے — نقصان کی حد کو پرامید سمجھیں۔"

    ریاضیاتی فارمولے اور متبادل

    کیلکولیٹر نیٹ ورک کے رویے کا تعین کرنے کے لیے درج ذیل فارمولوں کا استعمال کرتا ہے:

    • بنیادی فارمولا: تھرو پٹ = min(شرح × eff، window ÷ RTT، MSS ÷ RTT ÷ √p) · BDP = شرح × RTT
    • پروٹوکول کی کارکردگی: پروٹوکول کی کارکردگی = MSS ÷ (MSS + 78 B) = ‹mss› ÷ ‹frame› = ‹eff› (40 B پیکٹ ہیڈرز + 38 B تار پر)
    • اوور ہیڈ کے بعد لنک کی حد: لنک کی حد = rate × efficiency = ‹rate› × ‹eff› = ‹value›
    • بینڈوتھ ڈیلے پروڈکٹ (BDP): BDP = rate × RTT = ‹rate› × ‹rtt› = ‹bdp› = ‹bytes›
    • راستے کو بھرنے کے لیے درکار ونڈو: راستے کو بھرنے کے لیے ونڈو = BDP ÷ 8 = ‹bdp› → ‹window›
    • ونڈو کی حد: ونڈو کی حد = window ÷ RTT = ‹window› ÷ ‹rtt› = ‹value›
    • نقصان کی حد (Mathis ماڈل): نقصان کی حد (Mathis) = MSS ÷ RTT ÷ √p = ‹mss› ÷ ‹rtt› ÷ √‹p› = ‹value›
    • متوقع تھرو پٹ کا تعین: متوقع تھرو پٹ = ان حدوں میں سب سے کم = ‹value› ← محدود بذریعہ ‹constraint›
    • منتقلی کا کل وقت: منتقلی کا وقت = RTT + 8 × size ÷ throughput = ‹rtt› + 8 × ‹size› ÷ ‹throughput› = ‹time›

    نیٹ ورک ماڈل کی حدود اور اصول

    اس کیلکولیٹر کے نتائج کو درست طریقے سے سمجھنے کے لیے درج ذیل تکنیکی اصولوں کو ذہن میں رکھنا ضروری ہے:

    1. اعشاریہ بمقابلہ بائنری یونٹس: نیٹ ورکنگ کے تمام معیارات کی طرح یہاں بھی تمام یونٹس اعشاریہ پر مبنی ہیں (مثلاً 1 kbit = 1,000 bits اور 1 MB = 1,000,000 bytes)۔ فائل مینیجرز عام طور پر 1024 پر مبنی بائنری یونٹس (MiB/GiB) استعمال کرتے ہیں، جس کی وجہ سے فائل مینیجر میں دکھائی دینے والی فائل کا سائز یہاں درج کرنے پر وقت میں معمولی فرق آ سکتا ہے۔
    2. پروٹوکول اوور ہیڈ: یہ ماڈل معیاری ایتھرنیٹ اوور ہیڈ کو فرض کرتا ہے، جس میں ہر پیکٹ پر 78 بائٹس کا اضافہ ہوتا ہے (40 بائٹس برائے TCP/IP ہیڈرز اور 38 بائٹس برائے فزیکل وائر اوور ہیڈ)۔
    3. Mathis ماڈل کی حدود: میتھس کا نقصان کا ماڈل یہ فرض کرتا ہے کہ پیکٹ کا نقصان نیٹ ورک پر یکساں طور پر پھیلا ہوا اور آزادانہ ہے۔ یہ ماڈل صرف 1% سے کم نقصان کی شرح پر قابل اعتماد نتائج دیتا ہے۔ یکمشت ہونے والا نقصان (Burst Loss) اس ماڈل کی پیش گوئی سے زیادہ نقصان پہنچا سکتا ہے۔
    4. مستحکم حالت کا مفروضہ: یہ حسابات ایک واحد، مستحکم حالت (Steady-state) والے TCP فلو کو فرض کرتے ہیں۔ حقیقی دنیا کے عوامل جیسے کہ TCP سلو اسٹارٹ، کنجیشن کنٹرول الگورتھم کی ٹیوننگ، سست رسیورز، اور TLS ہینڈ شیکس اس ماڈل کا حصہ نہیں ہیں، اس لیے حقیقی منتقلی ہمیشہ ان اعداد و شمار سے نیچے رہ سکتی ہے۔

    پرائیویسی اور ڈیٹا پروسیسنگ

    اس ٹول پر آپ کی پرائیویسی کا مکمل خیال رکھا گیا ہے۔ آپ جو بھی قدر درج کرتے ہیں اس کا حساب اسی براؤزر میں لگایا جاتا ہے — کہیں بھی کچھ نہیں بھیجا جاتا۔ کوئی بھی ڈیٹا کسی بیرونی سرور پر اپ لوڈ نہیں ہوتا، جس کی وجہ سے آپ کا نیٹ ورک ڈیزائن اور ڈیٹا کا سائز مکمل طور پر آپ کے اپنے کمپیوٹر تک محدود رہتا ہے۔


    اکثر پوچھے گئے سوالات (FAQ)

    بینڈوتھ ڈیلے پروڈکٹ کیا ہے، اور یہ ونڈو کے سائز کا تعین کیوں کرتی ہے؟

    BDP — لنک ریٹ × راؤنڈ ٹرپ ٹائم — کسی بھی لمحے میں زیرِ منتقلی ڈیٹا کی مقدار ہے۔ TCP کے پاس زیادہ سے زیادہ ایک غیر تسلیم شدہ ونڈو بقایا ہو سکتی ہے، اس لیے BDP سے چھوٹی ونڈو پائپ کو جزوی طور پر خالی چھوڑ دیتی ہے: 50 ms RTT کے ساتھ 100 Mbit/s پر پائپ میں 625 kB ڈیٹا سما سکتا ہے، اور 65,535 بائٹس کی ونڈو اس کا بمشکل دسواں حصہ بھرتی ہے۔ یہی وجہ ہے کہ تیز رفتار، طویل راستوں کو TCP ونڈو اسکیلنگ (RFC 7323) کی ضرورت ہوتی ہے، جو گفت و شنید کے قابل زیادہ سے زیادہ حد کو 65,535 بائٹس سے بڑھا کر تقریباً 1 GB کر دیتی ہے۔

    میری منتقلی اس لنک ریٹ سے سست کیوں ہے جس کے لیے میں ادائیگی کرتا ہوں؟

    ایک واحد TCP فلو کو تین آزاد حدوں کا سامنا ہوتا ہے، اور سب سے کم حد جیت جاتی ہے۔ پروٹوکول اوور ہیڈ لنک کو خود تقریباً 5% تک کم کر دیتا ہے — ایک معیاری ایتھرنیٹ فریم تار پر موجود 1,538 بائٹس میں سے 1,460 پے لوڈ بائٹس لے جاتا ہے۔ رسیو ونڈو تھرو پٹ کو window ÷ RTT پر محدود کرتی ہے، اس لیے کلاسک 65,535 بائٹس کی ونڈو 50 ms کے راستے کو تقریباً 10.5 Mbit/s تک محدود رکھتی ہے چاہے لنک کتنا ہی تیز ہو۔ اور نقصان اسے (MSS ÷ RTT) ÷ √loss پر محدود کر دیتا ہے۔ اوپر دیا گیا نتیجہ یہ بتاتا ہے کہ آپ کے نمبروں پر کون سی حد لاگو ہو رہی ہے۔

    پیکٹ کا نقصان TCP تھرو پٹ کو کس طرح محدود کرتا ہے؟

    TCP نقصان کو نیٹ ورک کا رش سمجھتا ہے اور ہر نقصان کے واقعے پر اپنی بھیجنے کی شرح کو آدھا کر دیتا ہے، اس لیے تیز رفتار راستوں پر نقصان کی معمولی شرحیں بھی اہمیت رکھتی ہیں۔ Mathis ماڈل حد کا تخمینہ (MSS ÷ RTT) ÷ √p کے طور پر لگاتا ہے — 1,460 بائٹس MSS کے ساتھ 50 ms کے راستے پر 0.01% نقصان پر یہ تقریباً 23 Mbit/s بنتا ہے، قطع نظر لنک کی رفتار کے۔ یہ ماڈل یکساں طور پر پھیلے ہوئے، آزاد نقصانات کے واقعات کو فرض کرتا ہے؛ تقریباً 1% سے نیچے یہ حقیقت کے بالکل قریب رہتا ہے، اور یکمشت ہونے والے نقصانات کے لیے یہ پرامید ہے۔

    کیا یہاں میگا بائٹس وہی ہیں جو میرے فائل مینیجر میں ہوتے ہیں؟

    بالکل نہیں۔ یہ صفحہ اعشاریہ یونٹس استعمال کرتا ہے، جو نیٹ ورکنگ کا رواج ہے: 1 kbit = 1,000 bits اور 1 MB = 1,000,000 bytes۔ زیادہ تر فائل مینیجرز 1024 پر مبنی یونٹس میں گنتی کرتے ہیں، جن پر اکثر غلط طور پر MB کا لیبل لگا ہوتا ہے — وہاں ایک "100 MB" کی فائل عام طور پر 100 MiB ≈ 104.86 اعشاریہ MB ہوتی ہے، اس لیے اسے منتقل ہونے میں اعشاریہ کی شکل میں بتائے گئے وقت سے تقریباً 5% زیادہ وقت لگتا ہے۔ اس سے بالکل مطابقت رکھنے کے لیے یہاں 104.86 MB درج کریں۔