नेटवर्क लेटेंसी बैंडविड्थ कैलकुलेटर

TCP थ्रूपुट सीमाओं को समझना

एक सिंगल TCP फ़्लो का वास्तविक प्रदर्शन कभी भी नेटवर्क लिंक की कच्ची क्षमता के बराबर नहीं होता है। वास्तविक थ्रूपुट हमेशा तीन स्वतंत्र सीमाओं में से सबसे कम मान द्वारा निर्धारित होता है: लिंक क्षमता, रिसीव विंडो, और पैकेट लॉस। इन तीनों कारकों में से जो भी सबसे कम थ्रूपुट की अनुमति देता है, वही कनेक्शन का सक्रिय बॉटलनेक बन जाता है।

नेटवर्क लेटेंसी बैंडविड्थ कैलकुलेटर इन तीनों सीमाओं का विश्लेषण करता है और "अपेक्षित TCP थ्रूपुट" की गणना करता है। इसके साथ ही यह एक सब-लेबल प्रदर्शित करता है जो सक्रिय बॉटलनेक को दर्शाता है: "‹constraint› द्वारा सीमित"। यहाँ पर परिस्थिति के अनुसार बॉटलनेक का नाम डायनामिक रूप से "लिंक क्षमता", "रिसीव विंडो", या "पैकेट लॉस" के रूप में दिखाया जाता है।

इनपुट पैरामीटर और उनकी सीमाएं

कैलकुलेटर में नेटवर्क पाथ, ट्रांसफ़र पेलोड और TCP मापदंडों को कॉन्फ़िगर करने के लिए निम्नलिखित इनपुट दिए जाते हैं:

• लिंक रेट: पाथ पर सबसे धीमा हॉप — अक्सर आपके प्लान की रेटेड स्पीड। इसका मान शून्य से अधिक होना चाहिए।
• राउंड-ट्रिप समय (RTT): दूर के छोर तक पिंग समय — लोड के तहत अपेक्षित सबसे बड़े मान का उपयोग करें। इसका मान शून्य से अधिक होना चाहिए।
• डेटा का आकार: स्थानांतरित किया जाने वाला पेलोड — एक फ़ाइल, एक बैकअप, एक डेटासेट। इसका मान शून्य से अधिक होना चाहिए।
• रिसीव विंडो: बाइट्स जिन्हें रिसीवर बफ़र कर सकता है। इसका मान शून्य से अधिक होना चाहिए और यह 1,073,725,440 बाइट्स से अधिक नहीं हो सकता। इस फ़ील्ड को खाली छोड़ने का अर्थ है कि कोई विंडो सीमा लागू नहीं है।
• MSS (बाइट्स): प्रति पैकेट पेलोड बाइट्स। यह 1 और 65,495 के बीच बाइट्स की एक पूर्ण संख्या होनी चाहिए। इसे खाली छोड़ने पर ओवरहेड और लॉस को अनदेखा कर दिया जाता है।
• पैकेट लॉस (%): औसत पैकेट लॉस की संभावना। यह 0 और 100 प्रतिशत के बीच होना चाहिए। इसे खाली छोड़ने या 0 दर्ज करने पर कोई लॉस सीमा लागू नहीं होती है।
• दिखाए जाने वाले दशमलव: यह आउटपुट मानों की दशमलव सटीकता को नियंत्रित करता है।

इंटरफ़ेस में फ़ील्ड्स को नमूना डेटा से भरने के लिए "उदाहरण लोड करें" बटन और इनपुट को रीसेट करने के लिए "साफ़ करें" बटन दिया गया है।

गणना के फ़ॉर्मूले और प्रतिस्थापन

कैलकुलेटर "फ़ॉर्मूले और प्रतिस्थापन" अनुभाग में सभी गणितीय चरणों को स्पष्ट रूप से प्रदर्शित करता है:

• मुख्य फ़ॉर्मूला: थ्रूपुट = 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 = दर × 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›

उपयोगकर्ता गणना किए गए डेटा को कॉपी करने के लिए "परिणाम कॉपी करें" बटन का उपयोग कर सकते हैं।

डायनामिक सिस्टम नोट्स और चेतावनियाँ

इनपुट मानों के आधार पर, टूल विशिष्ट सिस्टम सूचनाएं प्रदर्शित करता है:

• विंडो स्केलिंग की आवश्यकता: "इस पाथ को भरने के लिए ‹window› विंडो की आवश्यकता है — जो कि 65,535-बाइट की बिना स्केल की गई अधिकतम सीमा से अधिक है, इसलिए दोनों सिरों को TCP विंडो स्केलिंग (RFC 7323) पर बातचीत करनी होगी।"
• विंडो सीमा से अधिक होना: "इस पाथ को भरने के लिए ‹window› की आवश्यकता है — जो कि TCP द्वारा बातचीत की जा सकने वाली सबसे बड़ी विंडो (1,073,725,440 बाइट्स) से अधिक है। इस पाथ पर एक सिंगल फ़्लो कभी भी ‹value› से अधिक नहीं हो सकता।"
• विंडो अनलॉक करने का सुझाव: "रिसीव विंडो को बढ़ाकर ‹window› करने से यह ट्रांसफ़र ‹value› तक पहुँच सकेगा।"
• उच्च पैकेट लॉस: "1% से अधिक का लॉस Mathis मॉडल की विश्वसनीय सीमा से बाहर है — लॉस सीमा को आशावादी मानें।"

नियम, सीमाएं और त्रुटि संदेश

कैलकुलेटर कुछ विशिष्ट नेटवर्किंग नियमों और सीमाओं के आधार पर काम करता है:

• इकाई परंपराएं: सभी इकाइयाँ दशमलव-आधारित हैं (जैसे, 1 kbit = 1,000 bits, 1 MB = 1,000,000 bytes)। फ़ाइल मैनेजर आमतौर पर 1024-आधारित बाइनरी इकाइयों का उपयोग करते हैं (जहाँ "100 MB" की फ़ाइल वास्तव में 100 MiB या लगभग 104.86 दशमलव MB होती है)।
• ओवरहेड गणना: प्रोटोकॉल ओवरहेड मानक ईथरनेट पर आधारित है, जो प्रति पैकेट 78 बाइट्स जोड़ता है (40 बाइट्स TCP/IP हेडर के लिए और 38 बाइट्स भौतिक तार ओवरहेड के लिए)।
• Mathis मॉडल की सीमाएं: Mathis लॉस मॉडल समान रूप से फैले हुए, स्वतंत्र पैकेट लॉस को मानता है। यह केवल लगभग 1% से कम के लॉस रेट के लिए विश्वसनीय है।
• मॉडल से बाहर के कारक: गणना एक स्थिर अवस्था वाले, सिंगल TCP फ़्लो को मानती है। वास्तविक दुनिया के कारक जैसे TCP स्लो स्टार्ट, कंजेशन-कंट्रोल ट्यूनिंग, धीमा रिसीवर और TLS हैंडशेक इस मॉडल से बाहर हैं, जिससे वास्तविक ट्रांसफ़र इन आंकड़ों से नीचे रह सकते हैं।

यदि इनपुट में कोई त्रुटि होती है, तो निम्नलिखित संदेश प्रदर्शित होते हैं:

• यदि इनपुट पार्स नहीं किया जा सकता: "‹field›: “‹token›” कोई संख्या नहीं है।"
• यदि लिंक रेट शून्य या नकारात्मक है: "लिंक रेट शून्य से अधिक होना चाहिए।"
• यदि राउंड-ट्रिप समय शून्य या नकारात्मक है: "राउंड-ट्रिप समय शून्य से अधिक होना चाहिए।"
• यदि डेटा का आकार शून्य या नकारात्मक है: "डेटा का आकार शून्य से अधिक होना चाहिए।"
• यदि रिसीव विंडो शून्य या नकारात्मक है: "रिसीव विंडो शून्य से अधिक होनी चाहिए।"
• यदि रिसीव विंडो RFC 7323 सीमा से अधिक है: "TCP 1,073,725,440 बाइट्स (RFC 7323 विंडो स्केलिंग) से ऊपर की विंडो पर बातचीत नहीं कर सकता।"
• यदि MSS सीमा से बाहर है: "MSS 1 और 65,495 के बीच बाइट्स की एक पूर्ण संख्या होनी चाहिए।"
• यदि पैकेट लॉस सीमा से बाहर है: "लॉस रेट 0 और 100 प्रतिशत के बीच होना चाहिए।"
• यदि गणना सिस्टम सीमा से बाहर चली जाती है: "कोई मान या मध्यवर्ती परिणाम समर्थित संख्या सीमा से अधिक है।"

गोपनीयता और प्रोसेसिंग

आपके द्वारा दर्ज किया गया प्रत्येक मान इसी ब्राउज़र में परिकलित किया जाता है — कहीं भी कुछ भी नहीं भेजा जाता है।

अक्सर पूछे जाने वाले प्रश्न (FAQ)

प्रश्न: मेरा ट्रांसफ़र उस लिंक रेट से धीमा क्यों है जिसके लिए मैं भुगतान करता हूँ? उत्तर: एक सिंगल TCP फ़्लो को तीन स्वतंत्र सीमाओं का सामना करना पड़ता है, और सबसे कम सीमा जीतती है। प्रोटोकॉल ओवरहेड लिंक को ही लगभग 5% कम कर देता है — एक मानक ईथरनेट फ़्रेम तार पर 1,538 बाइट्स में से 1,460 पेलोड बाइट्स ले जाता है। रिसीव विंडो थ्रूपुट को window ÷ RTT पर सीमित कर देती है, इसलिए क्लासिक 65,535-बाइट की विंडो 50 ms के पाथ को लगभग 10.5 Mbit/s पर रोक देती है, चाहे लिंक कितना भी तेज़ क्यों न हो। और लॉस इसे (MSS ÷ RTT) ÷ √loss पर सीमित कर देता है। ऊपर दिया गया परिणाम यह बताता है कि आपके आंकड़ों पर कौन सी सीमा लागू हो रही है।

प्रश्न: बैंडविड्थ-देरी उत्पाद (BDP) क्या है, और यह विंडो का आकार क्यों निर्धारित करता है? उत्तर: 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 दर्ज करें।