02 अप्रैल 2025·8 मिनट
बॉब कान और TCP/IP: ऐप्स को शक्ति देने वाली अदृश्य परत
जानें कि बॉब कान ने TCP/IP कैसे आकार दिया, भरोसेमंद पैकेट नेटवर्किंग क्यों ज़रूरी है, और किस तरह इसका डिज़ाइन आज भी ऐप्स, APIs और क्लाउड सेवाओं का आधार है।
जानें कि बॉब कान ने TCP/IP कैसे आकार दिया, भरोसेमंद पैकेट नेटवर्किंग क्यों ज़रूरी है, और किस तरह इसका डिज़ाइन आज भी ऐप्स, APIs और क्लाउड सेवाओं का आधार है।
ज्यादातर ऐप्स "तुरंत" लगते हैं: आप बटन टैप करते हैं, फ़ीड ताज़ा होता है, भुगतान पूरा होता है, वीडियो शुरू होता है। जो आप नहीं देखते वह नीचे हो रही मेहनत है — छोटे-छोटे डेटा टुकड़ों को Wi‑Fi, मोबाइल नेटवर्क, होम राउटर और डेटा सेंटर्स के बीच भेजना—कई बार कई देशों के पार—बिना आपको बीच की गंदगी के बारे में सोचे।
यह अदृश्यता TCP/IP का वादा है। यह कोई सिंगल प्रोडक्ट या क्लाउड फ़ीचर नहीं है। यह नियमों का एक सेट है जो उपकरणों और सर्वरों को ऐसा बोलने देता है कि यह आम तौर पर स्मूद और भरोसेमंद लगे, भले ही नेटवर्क शोर, भीड़, या आंशिक रूप से फेल हो।
बॉब कान उन प्रमुख लोगों में से एक थे जिन्होंने इसे संभव बनाया। विंट सर्फ़ जैसे सहयोगियों के साथ, कान ने उन मूल विचारों को आकार दिया जो TCP/IP बने: नेटवर्क्स के लिए एक सामान्य "भाषा" और ऐप्स के लिए भरोसा पैदा करने का तरीका। कोई हाइप नहीं—यह काम इसीलिए महत्वपूर्ण था क्योंकि इसने अस्थिर कनेक्शनों को सॉफ़्टवेयर के लिए भरोसेमंद मंच में बदल दिया।
पूरा संदेश एक निरंतर स्ट्रीम के रूप में भेजने के बजाय, पैकेट नेटवर्किंग इसे छोटे टुकड़ों—पैकेट्स—में तोड़ देती है। हर पैकेट अपनी अलग राह ले सकता है, जैसे अलग लिफाफे अलग पोस्ट ऑफिस से गुजरते हैं।
हम समझाएंगे कि TCP कैसे भरोसे की भावना बनाता है, क्यों IP जानबूझकर परिपूर्णता का वादा नहीं करता, और परतों (layers) से सिस्टम को कैसे समझने लायक रखा जाता है। अंत तक, आप यह तस्वीर बना पाएँगे कि जब एक ऐप API कॉल करता है तब क्या होता है—और क्यों ये दशक पुरानी विचारधाराएँ आज भी आधुनिक क्लाउड सेवाओं को चलाती हैं।
प्रारंभिक कंप्यूटर नेटवर्क्स "इंटरनेट" के रूप में जन्मे नहीं थे। वे अलग-अलग समूहों के लिए बनाए गए थे: एक विश्वविद्यालय का नेटवर्क यहाँ, एक मिलिट्री नेटवर्क वहाँ, एक रिसर्च लैब का नेटवर्क कहीं और। हर एक अपने अंदर अच्छा काम कर सकता था, लेकिन अक्सर उनका हार्डवेयर, मैसेज फॉर्मैट और डेटा यात्रा के नियम अलग होते थे।
इसका परिणाम निराशाजनक था: भले ही दो कंप्यूटर नेटवर्केड हों, वे फिर भी जानकारी का आदान-प्रदान नहीं कर पाते थे। यह कुछ वैसा ही है जैसे कई रेल प्रणालियाँ हों जिनके ट्रैक की चौड़ाई अलग हो और सिग्नल का मतलब अलग हो—एक सिस्टम के अंदर ट्रेनें चलेगी, पर किसी अन्य सिस्टम में जाना जटिल, महंगा या असम्भव होगा।
बॉब कान की मुख्य चुनौती सिर्फ़ “कंप्यूटर A को कंप्यूटर B से जोड़ना” नहीं थी। यह थी: आप नेटवर्क्स को एक-दूसरे से कैसे जोड़ते हैं ताकि ट्रैफ़िक कई स्वतंत्र सिस्टमों से होकर उसी तरह गुज़र सके जैसे वे एक बड़ा सिस्टम हों?
यही "इंटरनेटवर्किंग" का मतलब है—डेटा को एक नेटवर्क से दूसरे नेटवर्क तक हॉप करने की विधि बनाना, भले ही वे नेटवर्क अलग डिजाइन किए गए हों और अलग संगठनों द्वारा प्रबंधित हों।
इंटरनेटवर्किंग को बड़े पैमाने पर काम करने के लिए, हर किसी को एक सामान्य सेट ऑफ़ नियम—प्रोटोकॉल—की ज़रूरत थी जो किसी एक नेटवर्क के आंतरिक डिज़ाइन पर निर्भर न हो। उन नियमों को असली प्रतिबंधों को भी ध्यान में रखना था:
TCP/IP व्यावहारिक उत्तर बन गया: एक साझा "समझौता" जिसने स्वतंत्र नेटवर्कों को इंटरकनेक्ट होने और वास्तविक एप्लिकेशनों के लिए पर्याप्त रूप से डेटा मूव करने दिया।
बॉब कान इंटरनेट के "रूल्स ऑफ द रोड" के प्रमुख आर्किटेक्ट्स में से माने जाते हैं। 1970s में DARPA में काम करते हुए, उन्होंने नेटवर्किंग को एक चालाक रिसर्च प्रयोग से उस स्तर पर लाया जहाँ यह कई अलग तरह के नेटवर्कों को जोड़ सके—बिना यह ज़रूरी किए कि वे सभी एक ही हार्डवेयर, वायरिंग, या आंतरिक डिज़ाइन इस्तेमाल करें।
ARPANET ने दिखाया कि कंप्यूटर पैकेट-स्विच्ड लिंक पर संवाद कर सकते हैं। पर अन्य नेटवर्क भी उभर रहे थे—रेडियो-आधारित सिस्टम, उपग्रह लिंक, और अन्य प्रयोगात्मक नेटवर्क—हर एक की अपनी ख़ासियतें थीं। कान का ध्यान इंटरऑपरेबिलिटी पर था: एक संदेश को कई नेटवर्कों के पार इस तरह यात्रा करने योग्य बनाना जैसे वे एक ही नेटवर्क हों।
एक "संपूर्ण परफेक्ट" नेटवर्क बनाने के बजाय उन्होंने ऐसा दृष्टिकोण अपनाया:
विंट सर्फ़ के साथ मिलकर, कान ने TCP/IP का सह-डिजाइन किया। एक स्थायी परिणाम यह साफ़ जिम्मेदारी विभाजन था: IP पता और नेटवर्कों के बीच फ़ॉरवर्डिंग संभालता है, जबकि TCP उन एप्लिकेशनों के लिए भरोसेमंद डिलीवरी का प्रबंध करता है जिन्हें इसकी आवश्यकता होती है।
अगर आपने कभी API कॉल की है, कोई वेब पेज लोड किया है, या किसी कंटेनर से लॉग्स मॉनिटरिंग सर्विस में भेजे हैं, तो आप उसी इंटरनेटवर्किंग मॉडल पर निर्भर हैं जिसे कान ने बढ़ावा दिया। आपको परवाह करने की ज़रूरत नहीं कि पैकेट्स Wi‑Fi, फ़ाइबर, LTE, या क्लाउड बैकबोन को पार कर रहे हैं। TCP/IP इन सबको एक निरंतर सिस्टम जैसा दिखा देता है—ताकि सॉफ़्टवेयर फीचर्स पर ध्यान दे, वायरिंग पर नहीं।
TCP/IP के पीछे का सबसे स्मार्ट विचारों में से एक है लेयरिंग: एक बड़े "सब कुछ करें" नेटवर्क सिस्टम बनाने के बजाय, आप छोटे-छोटे हिस्सों को स्टैक करते हैं जहाँ हर लेयर एक काम अच्छा करती है।
यह महत्वपूर्ण है क्योंकि नेटवर्क्स एक जैसे नहीं होते। अलग-अलग केबल, रेडियो, राउटर, और प्रोवाइडर कुछ साफ जिम्मेदारियों पर सहमति होने पर इंटरऑपरेट कर सकते हैं।
IP (Internet Protocol) को ऐसे सोचिए जैसे यह सवाल जवाब करता है: यह डेटा कहाँ जा रहा है, और हम इसे उस जगह के करीब कैसे ले जाएँ?
IP पते प्रदान करता है (ताकि मशीनें पहचानी जा सकें) और बुनियादी रूटिंग करता है (ताकि पैकेट नेटवर्क से नेटवर्क तक हॉप कर सकें)। महत्त्वपूर्ण बात यह है कि IP परिपूर्ण बनने की कोशिश नहीं करता। यह पैकेट्स को आगे बढ़ाने पर ध्यान देता है, एक-एक कदम पर, भले ही रास्ता बदल जाए।
फिर TCP (Transmission Control Protocol) IP के ऊपर बैठता है और यह सवाल जवाब देता है: इसे भरोसेमंद कनेक्शन जैसा कैसे बनाया जाए?
TCP उन "रिलायबिलिटी" कामों को संभालता है जो एप्लिकेशन आम तौर पर चाहते हैं: डेटा को सही क्रम में देना, खोए हुए हिस्सों का पता लगाकर फिर से भेजना, और भेजने वाले को धीमा करके यह सुनिश्चित करना कि रिसीवर या नेटवर्क ओवरवेल्म न हो।
एक उपयोगी तरीके से समझें:
आप पता से पैकेज की डिलीवरी की गारंटी नहीं पूछते; आप वह भरोसा ऊपर पर बनाते हैं।
क्योंकि जिम्मेदारियाँ अलग हैं, आप एक लेयर में सुधार कर सकते हैं बिना बाकी सब कुछ पुनःडिज़ाइन किए। नया भौतिक नेटवर्क IP को वहन कर सकता है, और एप्लिकेशन TCP के व्यवहार पर भरोसा कर सकती है बिना यह जाने कि रूटिंग कैसे काम करती है। यह साफ विभाजन TCP/IP को लगभग हर ऐप और API के नीचे अदृश्य, साझा नींव बनने का एक बड़ा कारण है।
पैकेट स्विचिंग वही विचार है जिसने बड़े नेटवर्क को व्यवहार्य बनाया: आपकी पूरी संदेश के लिए समर्पित लाइन रिज़र्व करने के बजाय, आप संदेश को छोटे टुकड़ों में काट देते हैं और हर टुकड़ा स्वतंत्र रूप से भेजते हैं।
एक पैकेट डेटा का छोटा बंडल होता है जिसमें एक हेडर (किसने भेजा, किसे भेजा, और अन्य रूटिंग जानकारी) और कंटेंट का एक हिस्सा होता है।
डेटा को टुकड़ों में तोड़ने के फायदे:
यहां "अराजकता" शुरू होती है। एक ही डाउनलोड या API कॉल के पैकेट्स नेटवर्क के अलग-अलग रास्ते ले सकते हैं, उस समय किस रास्ते में भीड़ या उपलब्धता है उस पर निर्भर करते हुए। इसका मतलब है कि वे आर्डर से बाहर पहुँच सकते हैं—पैकेट #12 पैकेट #5 से पहले आ सकता है।
पैकेट स्विचिंग इसे रोकने की कोशिश नहीं करता। यह पैकेट्स को जल्दी से भेजने को प्राथमिकता देता है, भले ही आगमन क्रम गंदा हो।
पैकेट लॉस दुर्लभ नहीं है, और हमेशा किसी की गलती भी नहीं होती। सामान्य कारण:
मुख्य डिज़ाइन विकल्प यह है कि नेटवर्क को अपूर्ण होने की अनुमति है। IP पैकेट्स को आगे बढ़ाने पर ध्यान देता है बिना डिलीवरी या ऑर्डर का वादा किए। यही आज नेटवर्क्स को स्केल करने देता है—और इसलिए उच्च लेयर्स (जैसे TCP) अराजकता को साफ़ करने के लिए मौजूद हैं।
IP पैकेट्स को "बेस्ट-एफ़र्ट" आधार पर देता है: कुछ देर से पहुँचना, ऑर्डर से बाहर आना, डुप्लिकेट होना, या बिल्कुल न पहुँचना—यह सब हो सकता है। TCP इसके ऊपर बैठता है और एप्लिकेशन के लिए कुछ भरोसेमंद बनाता है: एक एकल, क्रमबद्ध, पूरा बाइट स्ट्रीम—वो कनेक्शन जिसका आप अपेक्षा करते हैं जब आप फ़ाइल अपलोड करते हैं, वेब पेज लोड करते हैं, या API कॉल करते हैं।
जब लोग कहते हैं कि TCP "भरोसेमंद" है, वे आम तौर पर इसका मतलब लेते हैं:
TCP आपके डेटा को टुकड़ों में बाँटता है और उन्हें सीक्वेंस नंबर देता है। रिसीवर ACKs भेजता है यह पुष्टि करने के लिए कि उसे क्या मिला।
अगर सेंडर को समय पर ACK नहीं मिलता, तो वह मान लेता है कुछ खो गया और रीट्रांसमिशन करता है। यह कोर "भ्रम" है: भले ही नेटवर्क पैकेट ड्रॉप करे, TCP तब तक कोशिश करता रहता है जब तक रिसीवर ने प्राप्ति की पुष्टि न कर दी।
ये मिलते-जुलते लगते हैं पर अलग समस्याएँ सुलझाते हैं:
मिलकर, वे TCP को तेज़ और गैर-लापरवाह बनाए रखने में मदद करते हैं।
एक निश्चित टाइमआउट धीमे और तेज दोनों नेटवर्क्स पर फेल कर देगा। TCP लगातार अपने टाइमआउट को मापी गई राउंड-ट्रिप टाइम के आधार पर समायोजित करता है। अगर कंडीशंस बिगड़ती हैं, तो यह रीट्रांसमिशन से पहले अधिक इंतज़ार करता है; अगर चीज़ें तेज़ होती हैं, तो यह अधिक उत्तरदायी बनता है। यही वजह है कि TCP Wi‑Fi, मोबाइल नेटवर्क, और लंबी दूरी के लिंक पर काम करते रह सकता है।
TCP/IP के पीछे का सबसे महत्वपूर्ण विचारों में से एक है एंड-टू-एंड सिद्धांत: नेटवर्क के किनारों (एंडपॉइंट्स) पर "स्मार्टनेस" रखें, और नेटवर्क के बीच वाले हिस्से को अपेक्षाकृत सरल रखें।
सरल शब्दों में, एंडपॉइंट्स वे डिवाइस और प्रोग्राम हैं जिन्हें वास्तव में डेटा की परवाह होती है: आपका फोन, आपका लैपटॉप, एक सर्वर, और उन पर चल रहे ऑपरेटिंग सिस्टम्स और ऐप्स। नेटवर्क कोर—राउटर और लिंक—मुख्यतः पैकेट्स को आगे बढ़ाने पर ध्यान देता है।
हर राउटर को "परफेक्ट" बनाने की कोशिश करने के बजाय, TCP/IP यह मानता है कि मध्य भाग अपूर्ण होगा और एंडपॉइंट्स वह भाग संभालें जो संदर्भ मांगता है।
कोर को सरल रखने से इंटरनेट का विस्तार आसान हुआ। नए नेटवर्क जुड़ सकते थे बिना हर मध्यवर्ती डिवाइस को हर एप्लिकेशन की ज़रूरत समझने के। राउटरों को यह जानने की ज़रूरत नहीं कि कोई पैकेट वीडियो कॉल का भाग है, फ़ाइल डाउनलोड का, या API अनुरोध का—वे बस उसे फ़ॉरवर्ड कर देते हैं।
एंडपॉइंट्स पर आप आम तौर पर संभालते हैं:
नेटवर्क में आप मुख्यतः संभालते हैं:
एंड-टू-एंड सोच अच्छे से स्केल करती है, पर यह जटिलता को आउटवर्ड धकेल देती है। ऑपरेटिंग सिस्टम्स, लाइब्रेरीज़, और एप्लिकेशन को नेटवर्क के मसलों के साथ "इसे काम करने योग्य बनाना" पड़ता है। यह लचीलापन देता है, पर इससे बग्स, गलत कॉन्फ़िगर किए गए टाइमआउट्स, या ज़्यादा आक्रामक रीट्राई वास्तविक उपयोगकर्ता-स्तर की समस्याएँ पैदा कर सकते हैं।
IP (Internet Protocol) एक साधारण वादा करता है: यह कोशिश करेगा कि आपके पैकेट्स को गंतव्य की ओर ले जाए। बस इतना ही। कोई गारंटी नहीं कि पैकेट पहुँचेगा, एक बार पहुँचेगा, क्रम में पहुँचेगा, या किसी निश्चित समय के भीतर पहुँचेगा।
यह सुनने में खामी लग सकती है—जब तक आप नहीं देखते कि इंटरनेट को वैश्विक स्तर पर क्या बनना था: कई छोटे नेटवर्कों से मिलकर बना एक ग्लोबल नेटवर्क, जो अलग-अलग संगठनों के अधीन है और लगातार बदलता रहता है।
राउटर IP के "ट्रैफिक डायरेक्टर्स" हैं। उनका मुख्य काम फ़ॉरवर्डिंग है: जब एक पैकेट आता है, राउटर गंतव्य पते को देखता है और उस समय सबसे अच्छा लगने वाले अगले हॉप का चुनाव करता है।
राउटर आम तौर पर किसी बातचीत का ट्रैक नहीं रखते जैसा एक फोन ऑपरेटर कर सकता है। वे आम तौर पर आपकी खातिर कैपेसिटी रिज़र्व नहीं करते और न ही किसी पैकेट के सफल पहुँचने की पुष्टि के लिए रुकते हैं। राउटरों को फ़ॉरवर्डिंग पर केंद्रित रखकर नेटवर्क का कोर सरल रहता है—और बहुत सारे डिवाइसेज़ और कनेक्शनों तक स्केल कर सकता है।
गारंटी महँगी होती है। अगर IP हर पैकेट के लिए डिलीवरी, ऑर्डर, और समय की गारंटी देने की कोशिश करता, तो पृथ्वी के हर नेटवर्क को कड़ी तालमेल, बहुत सारा state स्टोर करने, और एक ही तरह की फ़ेलओवर प्रक्रिया पर काम करना पड़ता। यह समन्वय बोझ वृद्धि और आउटेज को और गंभीर बना देता।
इसके बजाय IP गंदगी सहन करता है। अगर कोई लिंक फेल हो, तो राउटर पैकेट्स को दूसरे रूट के साथ भेज सकता है। अगर कोई पाथ भीड़ से भरा है, तो पैकेट्स देरी या ड्रॉप हो सकते हैं, पर ट्रैफ़िक अक्सर वैकल्पिक मार्गों से जारी रखा जा सकता है। नतीजा है resilience: इंटरनेट तब भी काम करना जारी रख सकता है जब इसके हिस्से टूटें या बदलें—क्योंकि नेटवर्क को परफेक्ट होने की ज़रूरत नहीं है कि वह उपयोगी रहे।
जब आप fetch() करके कोई API कॉल करते हैं, "Save" पर क्लिक करते हैं, या एक websocket खोलते हैं, तो आप एक स्मूद स्ट्रीम में सर्वर से बात नहीं कर रहे होते। आपकी ऐप OS को डेटा देती है, जो उसे पैकेट्स में काटकर कई अलग नेटवर्क्स पर भेजता है—हर हॉप अपनी पसंद के अनुसार निर्णय लेता है।
एक सामान्य आश्चर्य: आपके पास अच्छा थ्रूपुट हो सकता है और फिर भी UI सुस्त लग सकता है क्योंकि हर अनुरोध कई राउंड-ट्रिप्स पर निर्भर होता है।
TCP खोए पैकेट्स को रीट्राई करता है, पर यह नहीं जान सकता कि "बहुत लंबा" आपके उपयोगकर्ता के लिए क्या मतलब है। इसलिए एप्लिकेशन जोड़ते हैं:
पैकेट्स देरी हो सकते हैं, ऑर्डर बदल सकता है, डुप्लिकेट हो सकते हैं, या ड्रॉप हो सकते हैं। भीड़ अचानक लेटेंसी बढ़ा सकती है। एक सर्वर रिस्पॉन्ड कर सकता है पर रिस्पॉन्स आप तक नहीं पहुँचता। ये flaky tests, यादृच्छिक 504s, या "मेरे मशीन पर काम करता है" जैसी स्थितियों के रूप में दिखते हैं। अक्सर कोड ठीक होता है—रास्ता मशीनों के बीच ठीक नहीं होता।
क्लाउड प्लेटफ़ॉर्म पूरी तरह नया कंप्यूटिंग प्रकार लग सकता है—मैनेज्ड डेटाबेस, सर्वरलेस फ़ंक्शन्स, "अनंत" स्केलिंग। नीचे की परत में, आपकी रिक्वेस्ट्स अभी भी उन्हीं TCP/IP नींवों पर चलती हैं जिन्हें बॉब कान ने शुरू किया: IP पैकेट्स को नेटवर्कों के पार ले जाता है, और TCP (या कभी-कभी UDP) यह आकार देता है कि एप्लिकेशन नेटवर्क को कैसे अनुभव करता है।
वर्चुअलाइज़ेशन और कंटेनर बदलते हैं कहाँ सॉफ़्टवेयर चलता है और किस तरह पैक होता है:
पर ये तैनाती के विवरण हैं। पैकेट्स अभी भी IP पता और रूटिंग का उपयोग करते हैं, और कई कनेक्शन अभी भी क्रमबद्ध, भरोसेमंद डिलीवरी के लिए TCP पर निर्भर करते हैं।
सामान्य क्लाउड आर्किटेक्चर परिचित नेटवर्किंग बिल्डिंग ब्लॉक्स से बने हैं:
यहाँ तक कि जब आप कभी "IP पता" नहीं देखते, प्लेटफ़ॉर्म उन्हें आवंटित कर रहा होता है, पैकेट्स को रूट कर रहा होता है, और कनेक्शनों का ट्रैक रख रहा होता है—सभी पर्दे के पीछे।
TCP ड्रॉप हुए पैकेट्स से रिकवर कर सकता है, डिलीवरी का क्रम ठीक कर सकता है, और भीड़ के अनुसार एडजस्ट कर सकता है—पर यह असंभव चीज़ का वादा नहीं कर सकता। क्लाउड सिस्टम्स में विश्वसनीयता टीम वर्क है:
यही वजह है कि ऐसे प्लेटफ़ॉर्म जो पूरा स्टैक जनरेट और डिप्लॉय करते हैं (जैसे कि Koder.ai का उदाहरण) फिर भी उन्हीं मौलिक बातों पर निर्भर रहते हैं—कनेक्शंस, टाइमआउट्स, रीट्राई, और बाकी सब।
जब डेवलपर्स "नेटवर्क" कहते हैं, वे अक्सर दो ट्रांसपोर्ट्स में से चुन रहे होते हैं: TCP और UDP। दोनों IP के ऊपर बैठते हैं पर बहुत अलग ट्रेडऑफ़ बनाते हैं।
TCP तब अच्छा है जब आपको डेटा का क्रमबद्ध और बिना गैप आना चाहिए और आप प्रतीक्षा करना पसंद करेंगे बजाय अनुमान लगाने के। सोचिए: वेब पेज, API कॉल, फ़ाइल ट्रांसफर, डेटाबेस कनेक्शन।
इसी वजह से रोज़मर्रा के इंटरनेट का बड़ा हिस्सा TCP पर चलता है—HTTPS TCP के ऊपर चलता है (TLS के माध्यम से), और अधिकांश request/response सॉफ़्टवेयर TCP के व्यवहार पर आश्रित होते हैं।
पकड़: TCP की विश्वसनीयता लेटेंसी जोड़ सकती है। अगर एक पैकेट गायब है, तो बाद के पैकेट gap भरने तक रोके जा सकते हैं ("हेड-ऑफ-लाइन ब्लॉकिंग")। इंटरैक्टिव एक्सपीरियंस के लिए वह इंतज़ार कभी-कभी एक छोटे-से ग्लिच से बदतर महसूस होता है।
UDP अधिक "मेल भेजो और उम्मीद करो कि पहुंचे" के करीब है। UDP पर बिल्ट-इन ऑर्डरिंग, रीट्रांसमिशन, या भीड़-हैंडलिंग नहीं होती।
डेवलपर्स UDP चुनते हैं जब समय का महत्व पूर्णता से अधिक हो, जैसे लाइव ऑडियो/वीडियो, गेमिंग, या रीयल-टाइम टेलीमेट्री। कई ऐप्स अपनी हल्की-फुल्की विश्वसनीयता खुद बनाते हैं (या बिल्कुल नहीं), इस आधार पर कि उपयोगकर्ता क्या नोटिस करते हैं।
एक बड़ा आधुनिक उदाहरण: QUIC UDP पर चलता है, जिससे एप्लिकेशन तेज़ कनेक्शन सेटअप और कुछ TCP bottlenecks से बच सकते हैं—बिना नीचे के IP नेटवर्क को बदलने की ज़रूरत के।
निर्णय इस पर आधारित करें:
TCP अक्सर "भरोसेमंद" कहा जाता है, पर इसका मतलब यह नहीं कि आपकी ऐप हमेशा भरोसेमंद महसूस करेगी। TCP कई नेटवर्क समस्याओं से रिकवर कर सकता है, पर यह कम देरी, सुसंगत थ्रूपुट, या स्थिर पाथ होने की गारंटी नहीं दे सकता जब दो सिस्टम के बीच मार्ग अस्थिर हो।
पैकेट लॉस TCP को रीट्रांसमिशन करने के लिए मजबूर करता है। विश्वसनीयता बनी रहती है, पर परफ़ॉर्मेंस भारी गिर सकती है।
उच्च लेटेंसी (लंबा RTT) हर अनुरोध/उत्तर साइकल को धीमा कर देती है, भले ही कोई पैकेट न खोया हो।
बफ़रब्लोट तब होता है जब राउटर या OS कतारों में बहुत सारा डेटा हो। TCP कम लॉस देखता है, पर उपयोगकर्ता बड़े देरी और "लैगी" इंटरैक्शन देखता है।
गलत कॉन्फ़िगर किया गया MTU फ्रैगमेंटेशन या ब्लैकहोलिंग पैदा कर सकता है (पैकेट्स "बहुत बड़े" होने पर गायब हो जाते हैं), जो उलझन भरी त्रुटियाँ पैदा करते हैं जो यादृच्छिक टाइमआउट्स जैसी दिख सकती हैं।
स्पष्ट "नेटवर्क त्रुटि" के बजाय आप अक्सर देखेंगे:
ये लक्षण वास्तविक हैं, पर हमेशा आपके कोड की गलती नहीं होते। अक्सर यह TCP का काम होता है—रीट्रांसमिशन, बैक-ऑफ़, और प्रतीक्षा—जबकि आपकी ऐप क्लॉक चलते रहती है।
मूल रूप से वर्गीकृत करके शुरू करें: समस्या ज्यादातर लॉस, लेटेंसी, या पाथ चेंजेस में से किस प्रकार की है?
अगर आप तेज़ी से बना रहे हैं (उदाहरण के लिए Koder.ai में प्रोटोटाइप सर्विस बनाकर होस्ट कर रहे हैं), तो इन ऑब्ज़र्वेबिलिटी बेसिक्स को प्रारम्भिक "प्लानिंग मोड" चेकलिस्ट का हिस्सा बनाना क़ीमती होता है—क्योंकि नेटवर्क फेल्योर पहले टाइमआउट्स और रीट्राई के रूप में दिखते हैं, न कि साफ़-स्वच्छ एक्सेप्शन के रूप में।
नेटवर्क को गड़बड़ मानकर चलें। टाइमआउट्स, एक्सपोनेंशियल बैकऑफ़ के साथ रीट्राईज़, और ऑपरेशन्स को idempotent बनाएं ताकि रीट्राई से डबल-चार्ज, डबल-क्रिएट, या स्टेट करप्ट न हो।
TCP/IP नेटवर्किंग के साझा नियमों का एक समूह है जो अलग-अलग नेटवर्कों को आपस में जोड़ने और डेटा को अपेक्षित तरीके से पहुँचाने की अनुमति देता है।
यह इसलिए महत्वपूर्ण है क्योंकि यह अस्थिर और विविध लिंक (Wi‑Fi, LTE, फ़ाइबर, सैटेलाइट) को सॉफ़्टवेयर के लिए उपयोगी बनाता है—ताकि ऐप्स और सर्वर भौतिक नेटवर्क की जटिलताओं की चिंता किए बिना बाइट्स भेजकर उत्तर प्राप्त कर सकें।
बॉब कान ने “इंटरनेटवर्किंग” का विचार आगे बढ़ाया: अलग-अलग नेटवर्कों को इस तरह जोड़ना कि उन्हें एक ही आंतरिक हार्डवेयर या डिज़ाइन साझा करने की आवश्यकता न पड़े।
विंट सर्फ़ जैसे सहयोगियों के साथ, उनके काम ने वह विभाजन आकार दिया जहाँ IP नेटवर्कों के बीच पता और रूटिंग संभालता है और TCP एप्लिकेशन के ऊपर भरोसेमंद डिलीवरी देता है।
पैकेट स्विचिंग संदेश को छोटे पैकेट में बाँट देती है, जो स्वतंत्र रूप से यात्रा कर सकते हैं।
लाभ:
IP एक ही काम पर केंद्रित रहता है: पैकेट्स को गंतव्य पते की ओर अग्रसारित करना। यह डिलीवरी, क्रम, या समय का वादा नहीं करता।
यह “बेस्ट-एफ़र्ट” मॉडल वैश्विक स्तर पर इसलिए स्केल करता है क्योंकि राउटर सरल और तेज़ रह सकते हैं, और नेटवर्क लिंक विफल होने या बदलने पर भी काम करना जारी रख सकता है।
TCP IP के बेस्ट-एफ़र्ट पैकेट्स को एप्लिकेशन-फ्रेंडली ऑर्डर्ड बाइट स्ट्रीम में बदल देता है।
यह निम्न से करता है:
वे अलग समस्याओं का समाधान करते हैं:
अच्छी परफ़ॉर्मेंस के लिए दोनों जरूरी हैं: तेज़ सेंडर को रिसीवर और नेटवर्क दोनों का सम्मान करना चाहिए।
लेयरिंग जिम्मेदारियों को अलग कर देती है ताकि हर हिस्सा स्वतंत्र रूप से विकसित हो सके।
डेवलपर्स के लिए इसका मतलब: आप APIs बना सकते हैं बिना हर नेटवर्क प्रकार के लिए अपनी ऐप को फिर से डिज़ाइन किए हुए।
एंड-टू-एंड सिद्धांत नेटवर्क कोर (राउटर) को तुलनात्मक रूप से सरल रखता है और "स्मार्ट" सुविधाओं को एंडपॉइंट्स पर रखता है।
व्यवहार में: एप्स और ऑपरेटिंग सिस्टम्स विश्वसनीयता, टाइमआउट, रीट्राई, और एन्क्रिप्शन (अक्सर TLS के माध्यम से) संभालते हैं, क्योंकि नेटवर्क हर एप्लिकेशन के अनुरूप व्यवहार नहीं कर सकता।
लेटेंसी (राउंड-ट्रिप समय) चैटी पैटर्न्स को नुकसान पहुंचाती है: कई छोटे अनुरोध, रीडायरेक्ट, बार-बार API कॉल।
थ्रूपुट (बाइट्स प्रति सेकंड) बड़े ट्रांसफ़र्स को प्रभावित करता है: इमेज, बैकअप, वीडियो।
प्रैक्टिकल टिप्स:
अपनी ज़रूरत के हिसाब से चुनें:
रूल ऑफ थम्ब: यदि आपकी ऐप request/response और correctness-first है, तो TCP (या HTTP/3 के जरिए QUIC) आमतौर पर शुरुआत का बिंदु होता है।