ये तीनों अलग चीज़ें वर्णित करते हैं और लगातार भ्रमित किए जाते हैं। Latency देरी है — data की एक इकाई को A से B तक जाने में कितना समय लगता है (समय में मापी जाती है, जैसे ms)। Bandwidth क्षमता है — अधिकतम data दर जो एक link ले जा सकती है (जैसे Gbps)। वह दर है जो आप व्यवहार में हासिल करते हैं, जो आमतौर पर bandwidth से कम होती है। एक पाइप की उपमा इसे स्पष्ट कर देती है:
├────────────── length of pipe = LATENCY (how long to traverse) ─────────────┤
╔══════════════════════════════════════════════════════════════════════════╗
║ width of pipe = BANDWIDTH (max capacity) ║
║ water actually flowing = THROUGHPUT (real achieved rate ≤ bandwidth) ║
╚══════════════════════════════════════════════════════════════════════════╝
महत्वपूर्ण बात, एक चौड़ा पाइप उसे छोटा नहीं बनाता: bandwidth जोड़ने से latency कम नहीं होती। एक मोटी transatlantic link में अब भी दूरी और प्रकाश की गति द्वारा तय ~80 ms का round-trip latency होता है — आप इसके नीचे नहीं ख़रीद सकते। इसीलिए latency, न कि bandwidth, interactive apps के अनुभव पर हावी होती है: हर round trip (DNS, TCP handshake, TLS, फिर request) latency का दाम चुकाती है, और वे जुड़ते जाते हैं।
Latency और throughput Bandwidth-Delay Product (BDP = bandwidth × round-trip time) के ज़रिए एक-दूसरे से जुड़ते हैं, जो पाइप को भरा रखने के लिए "रास्ते में" data की मात्रा है। एक उच्च-bandwidth, उच्च-latency "long fat network" पर, TCP जैसा protocol जो ACKs का इंतज़ार करता है, पाइप को तब तक नहीं भर सकता जब तक उसकी window कम से कम BDP जितनी न हो — इसलिए throughput अंततः latency से सीमित हो जाता है, bandwidth से नहीं। इसीलिए लंबी दूरी पर एक अकेला TCP stream अक्सर एक तेज़ link पर भी कम प्रदर्शन करता है, और इसीलिए parallelism, बड़ी windows, और CDNs (जो दूरी, और इसलिए latency घटाते हैं) मदद करते हैं।
इन तीनों को घालमेल करना सबसे आम — और सबसे परिणामी — performance ग़लतियों में से एक है: teams उस चीज़ को ठीक करने के लिए अधिक bandwidth ख़रीदते हैं जो असल में एक latency समस्या है और कोई सुधार नहीं देखते। senior अंतर्दृष्टि यह है कि latency भौतिकी (दूरी) द्वारा तय एक निचली सीमा है जिस पर आप architectural रूप से हमला करते हैं — servers/CDNs को उपयोगकर्ताओं के पास रखें, round trips घटाएँ (connection reuse, HTTP/3, caching), और requests को batch करें — जबकि bandwidth अक्सर वह चीज़ है जिसे आप बस provision कर सकते हैं। BDP को समझना उन प्रति-सहज परिणामों को समझाता है जैसे एक "तेज़" link धीमे single-stream transfers दे रहा हो, जो ठीक वैसा तर्क है जैसा तब अपेक्षित है जब आप उच्च-प्रदर्शन, भौगोलिक रूप से वितरित सिस्टम design या debug करते हैं।
विस्तृत उत्तरों के साथ IT इंटरव्यू प्रश्नों की एक लाइब्रेरी — जूनियर से सीनियर तक।
दान करें