डेटाग्राम प्रोटेकॉलका उपयोग करें
| Internet protocol suite |
|---|
| Application layer |
| Transport layer |
| Internet layer |
| Link layer |
कंप्यूटर नेटवर्किंग में, उपयोगकर्ता आंकड़ारेख प्रोटोकॉल (यूडीपी) इंटरनेट प्रोटोकॉल सूट के मुख्य संचार प्रोटोकॉल में से है जो इंटरनेट प्रोटोकॉल (आईपी) नेटवर्क पर अन्य मेजबानों को संदेश (नेटवर्क पैकेट में डेटाग्राम के रूप में ले जाया जाता है) भेजने के लिए उपयोग किया जाता है। आईपी नेटवर्क के भीतर, यूडीपी को संचार चैनल या डेटा पथ स्थापित करने के लिए पूर्व संचार की आवश्यकता नहीं होती है।
यूडीपी न्यूनतम प्रोटोकॉल तंत्र के साथ साधारण कनेक्शन रहित संचार मॉडल का उपयोग करता है। यूडीपी डेटा अखंडता के लिए अंततः, प्रदान करता है, और डेटाग्राम के स्रोत और गंतव्य पर विभिन्न कार्यों को संबोधित करने के लिए पोर्ट नंबर प्रदान करता है। इसमें कोई हाथ मिलाना (कंप्यूटिंग) संवाद नहीं है, और इस प्रकार अंतर्निहित नेटवर्क की किसी भी विश्वसनीयता (कंप्यूटर नेटवर्किंग) के लिए उपयोगकर्ता के कार्यक्रम को उजागर करता है, डिलीवरी करने या ऑर्डर देने या डुप्लीकेट सुरक्षा की कोई गारंटी नहीं है। यदि नेटवर्क इंटरफ़ेस स्तर पर त्रुटि-सुधार सुविधाओं की आवश्यकता है, तो इसके अतिरिक्त एप्लिकेशन प्रसारण नियंत्रण प्रोटोकॉल (टीसीपी) या स्ट्रीम कंट्रोल ट्रांसमिशन प्रोटोकॉल (एससीटीपी) का उपयोग कर सकता है जो इस उद्देश्य के लिए डिज़ाइन किए गए हैं।
यूडीपी उन उद्देश्यों के लिए उपयुक्त है जहां त्रुटि जांच और सुधार या तो आवश्यक नहीं हैं या आवेदन में किए जाते हैं; यूडीपी प्रोटोकॉल स्टैक में इस तरह के प्रसंस्करण के ऊपरी हिस्से से बचा जाता है। समय-संवेदी अनुप्रयोग अधिकांशतः यूडीपी का उपयोग करते हैं क्योंकि पुनः स्थानांतरण (डेटा नेटवर्क) के कारण विलंबित पैकेटों की प्रतीक्षा करने के लिए पैकेट छोड़ना बेहतर होता है, जो वास्तविक समय प्रणाली में विकल्प नहीं हो सकता है।[1] प्रोटोकॉल 1980 में डेविड पी. रीड द्वारा डिजाइन किया गया था और औपचारिक रूप से 1980 में परिभाषित किया गया था। RFC 768.
गुण
यूडीपी (UDP) साधारण संदेश-उन्मुख ट्रांसपोर्ट परत प्रोटोकॉल है, जिसे इसमें प्रलेखित किया गया है RFC 768. चूंकि यूडीपी हेडर और पेलोड की अखंडता सत्यापन (चेकसम के माध्यम से) प्रदान करता है,[2] यह संदेश वितरण के लिए ऊपरी परत प्रोटोकॉल की कोई गारंटी नहीं देता है और यूडीपी परत बार भेजे जाने पर यूडीपी संदेशों की कोई स्थिति नहीं रखती है। इस कारण से, यूडीपी को कभी-कभी विश्वसनीयता (कंप्यूटर नेटवर्किंग) डेटाग्राम प्रोटोकॉल कहा जाता है।[3] यदि ट्रांसमिशन विश्वसनीयता वांछित है, तो इसे उपयोगकर्ता के आवेदन में लागू किया जाना चाहिए।
यूडीपी की कई विशेषताएँ इसे कुछ अनुप्रयोगों के लिए विशेष रूप से अनुकूल बनाती हैं।
- यह लेन-देन-उन्मुख है, सरल क्वेरी-प्रतिक्रिया प्रोटोकॉल जैसे डॉमेन नाम सिस्टम या नेटवर्क टाइम प्रोटोकॉल के लिए उपयुक्त है।
- यह डेटाग्राम प्रदान करता है, जो अन्य प्रोटोकॉल जैसे कि आईपी टनलिंग या दुरस्तह प्रकिया कॉल और नेटवर्क फ़ाइल सिस्टम के मॉडलिंग के लिए उपयुक्त है।
- यह सरल है, बूटस्ट्रैपिंग या अन्य उद्देश्यों के लिए पूर्ण प्रोटोकॉल स्टैक के बिना उपयुक्त है, जैसे डाइनामिक होस्ट कॉन्फिगरेशन प्रोटोकॉल और तुच्छ फ़ाइल स्थानांतरण प्रोटोकॉल हैं।
- यह स्टेटलेस है, बहुत बड़ी संख्या में ग्राहकों के लिए उपयुक्त है, जैसे कि आईपीटीवी स्ट्रीमिंग मीडिया अनुप्रयोगों में इसका उपयोग किया जाता हैं।
- रिट्रांसमिशन विलंब की कमी इसे वास्तविक समय के अनुप्रयोगों जैसे आईपी पर आवाज, ऑनलाइन खेल और रीयल टाइम स्ट्रीमिंग प्रोटोकॉल का उपयोग करने वाले कई प्रोटोकॉल के लिए उपयुक्त बनाती है।
- क्योंकि यह बहुस्त्र्पीय का समर्थन करता है, यह प्रसारण सूचना के लिए उपयुक्त है जैसे कि कई प्रकार की सेवा खोज और साझा जानकारी जैसे सटीक समय प्रोटोकॉल और रूटिंग सूचना प्रोटोकॉल हैं।
पोर्ट्स
एप्लिकेशन होस्ट-टू-होस्ट संचार स्थापित करने के लिए डेटाग्राम सॉकेट का उपयोग कर सकते हैं। एप्लिकेशन सॉकेट को डेटा ट्रांसमिशन के अपने एंडपॉइंट से बांधता है, जो आईपी पता और पोर्ट (कंप्यूटर नेटवर्किंग) का संयोजन है। इस तरह, यूडीपी एप्लिकेशन बहुसंकेतन प्रदान करता है। पोर्ट सॉफ्टवेयर संरचना है जिसे पोर्ट संख्या द्वारा पहचाना जाता है, 16-बिट पूर्णांक मान, जो 0 और 65535 के बीच पोर्ट नंबरों की अनुमति देता है। पोर्ट 0 आरक्षित है, लेकिन अनुमेय स्रोत पोर्ट मान है यदि भेजने की प्रक्रिया संदेशों की अपेक्षा नहीं करती है प्रतिक्रिया।
इंटरनेट निरुपित नंबर प्राधिकरण (आईएएनए) ने पोर्ट नंबरों को तीन श्रेणियों में विभाजित किया है।[4] पोर्ट नंबर 0 से 1023 का उपयोग सामान्य, प्रसिद्ध सेवाओं के लिए किया जाता है। यूनिक्स जैसे ऑपरेटिंग सिस्टम पर, इनमें से किसी पोर्ट का उपयोग करने के लिए सुपर उपयोगकर्ता ऑपरेटिंग अनुमति की आवश्यकता होती है। पोर्ट नंबर 1024 से 49151 आईएएनए-पंजीकृत सेवाओं के लिए उपयोग किए जाने वाले पंजीकृत पोर्ट हैं। पोर्ट 49152 से 65535 डायनेमिक पोर्ट हैं जो किसी विशिष्ट सेवा के लिए आधिकारिक आधार पर नामित नहीं हैं, और किसी भी उद्देश्य के लिए उपयोग किए जा सकते हैं। इन्हें क्षणिक बंदरगाहों के रूप में भी उपयोग किया जा सकता है, जो होस्ट पर चल रहे सॉफ़्टवेयर गतिशील रूप से आवश्यकतानुसार संचार समापन बिंदु बनाने के लिए उपयोग कर सकते हैं।[4]
यूडीपी डेटाग्राम संरचना
एक यूडीपी डेटाग्राम में डेटाग्राम हेडर होता है जिसके बाद डेटा सेक्शन (एप्लिकेशन के लिए पेलोड डेटा) होता है। यूडीपी डेटाग्राम हेडर में 4 फ़ील्ड होते हैं, जिनमें से प्रत्येक 2 बाइट्स (16 बिट) का होता है:[1]
| आफव्यवस्थित | औकटेट | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| औकटेट | [बिट] | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | सोर्स पोर्ट | डेस्टिनेशन पोर्ट | ||||||||||||||||||||||||||||||
| 4 | 32 | लंबाई | चेकसम | ||||||||||||||||||||||||||||||
आईपीवी4 (तालिका में गुलाबी पृष्ठभूमि) में चेकसम और स्रोत पोर्ट फ़ील्ड का उपयोग वैकल्पिक है। आईपीवी6 में केवल स्रोत पोर्ट फ़ील्ड वैकल्पिक है।
- स्रोत पोर्ट संख्या
- यह फ़ील्ड उपयोग किए जाने पर प्रेषक के पोर्ट की पहचान करता है, और यदि आवश्यक हो तो उत्तर देने के लिए पोर्ट माना जाना चाहिए। यदि उपयोग नहीं किया जाता है, तो यह शून्य होना चाहिए। यदि स्रोत होस्ट क्लाइंट है, तो पोर्ट नंबर अल्पकालिक पोर्ट होने की संभावना है। यदि स्रोत होस्ट सर्वर है, तो पोर्ट नंबर 0 से 1023 तक प्रसिद्ध पोर्ट नंबर होने की संभावना है।[4]
गंतव्य पोर्ट संख्या
- यह फ़ील्ड रिसीवर के पोर्ट की पहचान करता है और आवश्यक है। स्रोत पोर्ट नंबर के समान, यदि क्लाइंट गंतव्य होस्ट है तो पोर्ट नंबर अस्थायी पोर्ट नंबर होगा और यदि गंतव्य होस्ट सर्वर है तो पोर्ट नंबर संभवतः लंबाई के लिए प्रसिद्ध पोर्ट नंबर पर होगी।[4]
- यह फ़ील्ड यूडीपी हेडर और यूडीपी डेटा की बाइट में लंबाई निर्दिष्ट करती है। न्यूनतम लंबाई 8 बाइट्स है, हेडर की लंबाई। यूडीपी डेटाग्राम के लिए फ़ील्ड आकार 65,535 बाइट्स (8-बाइट हेडर + 65,527 बाइट्स डेटा) की सैद्धांतिक सीमा निर्धारित करता है। चूंकि डेटा लंबाई की वास्तविक सीमा, जो अंतर्निहित आईपीवी4 प्रोटोकॉल द्वारा लगाई गई है, 65,507 बाइट्स (65,535 बाइट्स - 8-बाइट यूडीपी हेडर - 20-बाइट आईपीवी4 हेडर) है।[5]
- आईपीवी6 जंबोग्राम का उपयोग करके 65,535 बाइट्स से अधिक आकार के यूडीपी डेटाग्राम का होना संभव है।[6] RFC 2675 निर्दिष्ट करता है कि यूडीपी हेडर प्लस यूडीपी डेटा की लंबाई 65,535 से अधिक होने पर लंबाई फ़ील्ड शून्य पर व्यवस्थित है।
- अंततः,
- हेडर और डेटा की त्रुटि-जाँच के लिए चेकसम फ़ील्ड का उपयोग किया जा सकता है। यह फ़ील्ड आईपीवी4 में वैकल्पिक है, और आईपीवी6 में अनिवार्य है।[7] अप्रयुक्त होने पर क्षेत्र में सभी शून्य होते हैं।[8]
चेकसम गणना
चेकसम की गणना करने के लिए उपयोग की जाने वाली विधि को परिभाषित किया गया है RFC 768, और कुशल गणना में चर्चा की गई है RFC 1071:
चेकसम 16-बिट किसी का पूरक है, जो आईपी हेडर, यूडीपी हेडर, और डेटा से जानकारी के एक छद्म हेडर के पूरक योग का है, जो एक बनाने के लिए अंत में शून्य ऑक्टेट के साथ (यदि आवश्यक हो) दो अष्टक का गुणक पैडेड है।[8]
दूसरे शब्दों में, सभी 16-बिट शब्दों को पूरक अंकगणित का उपयोग करके अभिव्यक्त किया जाता है। 16-बिट मान ऊपर जोड़ें। प्रत्येक जोड़ पर, यदि कैरी-आउट (17 वां बिट) का उत्पादन किया जाता है, तो उस 17 वें कैरी बिट को चारों ओर घुमाएँ और इसे चल रहे कुल के कम से कम महत्वपूर्ण बिट में जोड़ दें।[9] अंत में, यूडीपी चेकसम फ़ील्ड के मूल्य को प्राप्त करने के लिए योग को पूरक बनाया जाता है।
यदि चेकसम गणना का परिणाम शून्य होता है (सभी 16 बिट्स 0) तो इसे के पूरक (सभी 1s) के रूप में भेजा जाना चाहिए क्योंकि शून्य-मान चेकसम इंगित करता है कि कोई चेकसम की गणना नहीं की गई है।[8]इस स्थिति में, रिसीवर पर किसी विशिष्ट प्रसंस्करण की आवश्यकता नहीं है, क्योंकि सभी 0s और सभी 1s 1 के पूरक अंकगणित में शून्य के बराबर हैं।
आईपीवी4 और आईपीवी6 के बीच अंतर चेकसम की गणना करने के लिए उपयोग किए जाने वाले स्यूडो हेडर में हैं, और यह कि आईपीवी6 में चेकसम वैकल्पिक नहीं है।[10]
आईपीवी4 छद्म शीर्षलेख
जब यूडीपी आईपीवी4 पर चलता है, तो चेकसम की गणना छद्म हेडर का उपयोग करके की जाती है जिसमें वास्तविक आईपीवी4 हेडर से कुछ समान जानकारी होती है।[8]: 2 छद्म हेडर वास्तविक आईपीवी4 हेडर नहीं है जिसका उपयोग आईपी पैकेट भेजने के लिए किया जाता है, इसका उपयोग केवल चेकसम गणना के लिए किया जाता है।
| औफव्यवस्थित | औकटेट | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| औकटेट | बिट | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | सोर्स आईपीवी4 एड्रेस | |||||||||||||||||||||||||||||||
| 4 | 32 | डेस्टिनेशन आईपीवी4 एड्रेस | |||||||||||||||||||||||||||||||
| 8 | 64 | ज़िरोज़ | प्रोटोकाल | यूडीपी की लंबाई | |||||||||||||||||||||||||||||
| 12 | 96 | सोर्स पोर्ट | डेस्टिनेशन पोर्ट | ||||||||||||||||||||||||||||||
| 16 | 128 | यूडीपी की लंबाई | चेकसम | ||||||||||||||||||||||||||||||
| 20 | 160+ | डेटा | |||||||||||||||||||||||||||||||
स्रोत और गंतव्य पते वे हैं जो आईपीवी4 हेडर में हैं। प्रोटोकॉल यूडीपी के लिए है (आईपी प्रोटोकॉल नंबरों की सूची देखें): 17 (0x11)। यूडीपी लंबाई क्षेत्र यूडीपी हेडर और डेटा की लंबाई है। फ़ील्ड डेटा संचरित डेटा के लिए खड़ा है।
आईपीवी4 के लिए यूडीपी चेकसम संगणना वैकल्पिक है। यदि चेकसम का उपयोग नहीं किया जाता है तो इसे शून्य मान पर व्यवस्थित किया जाना चाहिए।
आईपीवी6 छद्म शीर्षलेख
जब यूडीपी आईपीवी6 पर चलता है, तो चेकसम अनिवार्य है। चूंकि आईपीवी6 में बड़े पते और अलग हेडर लेआउट है, इसलिए इसकी गणना करने के लिए उपयोग की जाने वाली विधि को उसी के अनुसार बदल दिया जाता हैREFERENCE FOR RFC8200 IS NOT DEFINED YET. You are invited to add it here.:
कोई भी परिवहन या अन्य ऊपरी-परत प्रोटोकॉल जिसमें IP शीर्षलेख से इसके चेकसम संगणना में पते सम्मलित हैं, को IPv6 पर उपयोग के लिए संशोधित किया जाना चाहिए, 32-बिट IPv4 पतों के अतिरिक्त 128-बिट IPv6 पतों को सम्मलित करने के लिए।
चेकसम की गणना करते समय, पुनः सूडो हेडर का उपयोग किया जाता है जो वास्तविक आईपीवी6 हेडर की नकल करता है:
| औफव्यवस्थित | औकटेट | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| औकटेट | बिट | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | सोर्स आईपीवी6 एड्रेस | |||||||||||||||||||||||||||||||
| 4 | 32 | ||||||||||||||||||||||||||||||||
| 8 | 64 | ||||||||||||||||||||||||||||||||
| 12 | 96 | ||||||||||||||||||||||||||||||||
| 16 | 128 | डेस्टिनेशन आईपीवी6 एड्रेस | |||||||||||||||||||||||||||||||
| 20 | 160 | ||||||||||||||||||||||||||||||||
| 24 | 192 | ||||||||||||||||||||||||||||||||
| 28 | 224 | ||||||||||||||||||||||||||||||||
| 32 | 256 | यूडीपी की लंबाई | |||||||||||||||||||||||||||||||
| 36 | 288 | ज़िरोज़ | Next Header = प्रोटोकाल[11] | ||||||||||||||||||||||||||||||
| 40 | 320 | सोर्स पोर्ट | डेस्टिनेशन पोर्ट | ||||||||||||||||||||||||||||||
| 44 | 352 | की लंबाई | चेकसम | ||||||||||||||||||||||||||||||
| 48 | 384+ | डेटा | |||||||||||||||||||||||||||||||
स्रोत पता आईपीवी6 शीर्षलेख में से है। गंतव्य पता अंतिम गंतव्य है; यदि आईपीवी6 पैकेट में रूटिंग हेडर नहीं है, तो वह आईपीवी6 हेडर में गंतव्य पता होगा; अन्यथा, प्रारंभिक नोड पर, यह रूटिंग शीर्षलेख के अंतिम तत्व में पता होगा, और प्राप्त करने वाले नोड पर, यह आईपीवी6 शीर्षलेख में गंतव्य पता होगा। अगले हेडर फ़ील्ड का मान यूडीपी के लिए प्रोटोकॉल मान है: 17, जो यूडीपी लंबाई फ़ील्ड यूडीपी हेडर और डेटा की लंबाई है।
विश्वसनीयता और भीड़ नियंत्रण
विश्वसनीयता की कमी, यूडीपी अनुप्रयोगों में कुछ पैकेट हानि, पुनः क्रमांकन, त्रुटियां या दोहराव का सामना करना पड़ सकता है। यदि यूडीपी का उपयोग कर रहे हैं, तो एंड-यूज़र एप्लिकेशन को आवश्यक हैंडशेकिंग प्रदान करनी चाहिए जैसे कि वास्तविक समय की पुष्टि कि संदेश प्राप्त हो गया है। ट्रिवियल फाइल ट्रांसफर प्रोटोकॉल जैसे एप्लिकेशन, आवश्यकतानुसार एप्लिकेशन लेयर में अल्पविकसित विश्वसनीयता तंत्र जोड़ सकते हैं।[4]यदि किसी एप्लिकेशन को उच्च स्तर की विश्वसनीयता की आवश्यकता होती है, तो इसके अतिरिक्त ट्रांसमिशन कंट्रोल प्रोटोकॉल जैसे प्रोटोकॉल का उपयोग किया जा सकता है।
बहुधा, यूडीपी अनुप्रयोग विश्वसनीयता तंत्रों को नियोजित नहीं करते हैं और उनके द्वारा बाधित भी हो सकते हैं। स्ट्रीमिंग मीडिया, रीयल-टाइम मल्टीप्लेयर गेम और वॉयस ओवर आईपी (वीओआईपी) ऐसे अनुप्रयोगों के उदाहरण हैं जो अधिकांशतः यूडीपी का उपयोग करते हैं। इन विशेष अनुप्रयोगों में, पैकेट का नुकसान सामान्यतः घातक समस्या नहीं होती है। वीओआईपी में, उदाहरण के लिए, विलंबता और घबराना प्राथमिक चिंताएं हैं। यदि कोई पैकेट गुम हो जाता है तो टीसीपी का उपयोग घबराहट पैदा करेगा क्योंकि टीसीपी आवेदन के बाद के डेटा को प्रदान नहीं करता है, जबकि यह लापता डेटा को पुनः भेजने का अनुरोध कर रहा है।
अनुप्रयोग
कई प्रमुख इंटरनेट एप्लिकेशन यूडीपी का उपयोग करते हैं, जिनमें सम्मलित हैं: डोमेन नाम सिस्टम (डीएनएस), सरल नेटवर्क प्रबंधन प्रोटोकॉल (एसएनएमपी), रूटिंग सूचना प्रोटोकॉल (आरआईपी)[1]और डायनेमिक होस्ट कॉन्फ़िगरेशन प्रोटोकॉल (डीएचसीपी) इत्यादि।
आवाज और वीडियो यातायात सामान्यतः यूडीपी का उपयोग कर प्रसारित किया जाता है। आईपी पर वास्तविक समय के वीडियो और ऑडियो को कभी-कभी खोए हुए पैकेटों को संभालने के लिए डिज़ाइन किया गया है, इसलिए गुणवत्ता में केवल मामूली गिरावट होती है, बजाय बड़े विलंब के यदि खोए हुए पैकेटों को पुनः प्रेषित किया जाता है। क्योंकि टीसीपी और यूडीपी दोनों ही नेटवर्क पर चलते हैं, 2000 के दशक के मध्य में कुछ व्यवसायों ने पाया कि इन वास्तविक समय के अनुप्रयोगों से यूडीपी ट्रैफ़िक में वृद्धि ने टीसीपी का उपयोग करने वाले अनुप्रयोगों के प्रदर्शन को थोड़ा बाधित किया जैसे बिक्री बिंदु, लेखा सॉफ्टवेयर और डेटाबेस प्रबंधन प्रणाली सिस्टम (जब टीसीपी पैकेट हानि का पता लगाता है, तो यह डेटा दर उपयोग को वापस कर देगा)।[12] कुछ वीपीएन सिस्टम जैसे ओपनवीपीएन यूडीपी का उपयोग कर सकते हैं और विश्वसनीय कनेक्शन लागू करते समय एप्लिकेशन स्तर पर त्रुटि जांच कर सकते हैं।
क्विक ट्रांसपोर्ट प्रोटोकॉल है जो यूडीपी के ऊपर बनाया गया है। क्विक विश्वसनीय और सुरक्षित कनेक्शन प्रदान करता है। एचटीटीपी/3 एचटीटीपीएस के पिछले संस्करणों के विपरीत क्विक का उपयोग करता है जो क्रमशः विश्वसनीयता और सुरक्षा सुनिश्चित करने के लिए ट्रांसमिशन कंट्रोल प्रोटोकॉल और परिवहन परत सुरक्षा के संयोजन का उपयोग करते हैं। इसका मतलब यह है कि टीसीपी और टीएलएस के लिए दो अलग-अलग हैंडशेक होने के अतिरिक्त एचटीटीपी/3 कनेक्शन स्थापित करने के लिए सिंगल हैंडशेक का उपयोग करता है, जिसका अर्थ है कि कनेक्शन स्थापित करने का कुल समय कम हो जाता है।[13]
यूडीपी और टीसीपी की तुलना
ट्रांसमिशन कंट्रोल प्रोटोकॉल कनेक्शन-उन्मुख प्रोटोकॉल है और एंड-टू-एंड संचार स्थापित करने के लिए हैंडशेकिंग की आवश्यकता होती है। बार कनेक्शन स्थापित हो जाने के बाद, कनेक्शन पर उपयोगकर्ता डेटा द्वि-दिशात्मक रूप से भेजा जा सकता है।
- विश्वसनीय - टीसीपी संदेश पावती, पुन: प्रसारण और टाइमआउट का प्रबंधन करता है। संदेश देने के कई प्रयास किए जाते हैं। यदि रास्ते में डेटा खो जाता है, तो डेटा पुनः भेजा जाएगा। टीसीपी में, या तो कोई लापता डेटा नहीं है, या, कई टाइमआउट के स्थिति में, कनेक्शन गिरा दिया गया है।
- आदेश दिया गया - यदि दो संदेश क्रम में कनेक्शन पर भेजे जाते हैं, तो पहला संदेश प्राप्त करने वाले एप्लिकेशन तक पहुंच जाएगा। जब डेटा सेगमेंट गलत क्रम में आते हैं, तो टीसीपी आउट-ऑफ-ऑर्डर डेटा को तब तक बफ़र करता है जब तक कि सभी डेटा को ठीक से री-ऑर्डर नहीं किया जा सकता और एप्लिकेशन को डिलीवर नहीं किया जा सकता।
- हैवीवेट - किसी भी उपयोगकर्ता डेटा को भेजे जाने से पहले टीसीपी को सॉकेट कनेक्शन स्थापित करने के लिए तीन पैकेट की आवश्यकता होती है। टीसीपी विश्वसनीयता और भीड़ नियंत्रण को संभालती है।
- स्ट्रीमिंग - डेटा को बाइट स्ट्रीम के रूप में पढ़ा जाता है, सिग्नल संदेश (सेगमेंट) सीमाओं में कोई विशिष्ट संकेत प्रेषित नहीं होते हैं।
उपयोगकर्ता डेटाग्राम प्रोटोकॉल सरल संदेश-आधारित कनेक्शन रहित प्रोटोकॉल है। कनेक्शन रहित प्रोटोकॉल समर्पित एंड-टू-एंड कनेक्शन व्यवस्थित नहीं करते हैं। प्राप्तकर्ता की तत्परता या स्थिति को सत्यापित किए बिना स्रोत से गंतव्य तक दिशा में सूचना प्रसारित करके संचार प्राप्त किया जाता है।
- अविश्वसनीय - जब यूडीपी संदेश भेजा जाता है, तो यह ज्ञात नहीं हो सकता है कि यह अपने गंतव्य तक पहुंचेगा या नहीं; यह रास्ते में खो सकता है। पावती, पुन: प्रसारण, या टाइमआउट की कोई अवधारणा नहीं है।
- आदेशित नहीं - यदि दो संदेश ही प्राप्तकर्ता को भेजे जाते हैं, तो जिस क्रम में वे आते हैं उसकी गारंटी नहीं दी जा सकती।
- लाइटवेट - संदेशों का कोई क्रम नहीं है, कोई ट्रैकिंग कनेक्शन आदि नहीं है। यह आईपी के शीर्ष पर डिज़ाइन की गई बहुत ही सरल परिवहन परत है।
- डेटाग्राम - पैकेट व्यक्तिगत रूप से भेजे जाते हैं और आगमन पर अखंडता के लिए जाँच की जाती है। पैकेटों की निश्चित सीमाएँ होती हैं जिन्हें प्राप्त होने पर सम्मानित किया जाता है; रिसीवर सॉकेट पर रीड ऑपरेशन संपूर्ण संदेश देगा क्योंकि यह मूल रूप से भेजा गया था।
- कोई भीड़ नियंत्रण नहीं - यूडीपी स्वयं भीड़भाड़ से नहीं बचता है। कंजेशन नियंत्रण उपायों को एप्लिकेशन स्तर पर या नेटवर्क में लागू किया जाना चाहिए।
- प्रसारण - कनेक्शन रहित होने के कारण, यूडीपी प्रसारित कर सकता है - भेजे गए पैकेट को सबनेट पर सभी उपकरणों द्वारा प्राप्य होने के लिए संबोधित किया जा सकता है।
- मल्टीकास्ट - ऑपरेशन का मल्टीकास्ट मोड समर्थित है जिससे ग्राहकों के समूह को दोहराव के बिना डेटाग्राम पैकेट को स्वचालित रूप से रूट किया जा सकता है।
मानक
- RFC 768 - डेटाग्राम प्रोटेकॉलका उपयोग करें
- RFC 2460 - इंटरनेट प्रोटोकॉल, संस्करण 6 (आईपीवी6) विशिष्टता
- RFC 2675 - आईपीवी6 जंबोग्राम
- RFC 4113 - यूडीपी के लिए प्रबंधन सूचना आधार
- RFC 8085 - यूडीपी उपयोग दिशानिर्देश
यह भी देखें
- परिवहन परत प्रोटोकॉल की तुलना
- डेटाग्राम ट्रांसपोर्ट लेयर सुरक्षा (डीटीएलएस)
- टीसीपी और यूडीपी पोर्ट नंबरों की सूची
- माइक्रो ट्रांसपोर्ट प्रोटोकॉल (μटीपी)
- विश्वसनीय डेटा प्रोटोकॉल (आरडीपी)
- विश्वसनीय उपयोगकर्ता डेटाग्राम प्रोटोकॉल (आरयूडीपी)
- यूडीपी आधारित डाटा ट्रांसफर प्रोटोकॉल
- यूडीपी बाढ़ हमला
- यूडीपी सहायक पता
- यूडीपी-लाईट - एक संस्करण जो विकृत होने पर भी पैकेट डिलीवर करता है
संदर्भ
- ↑ 1.0 1.1 1.2 Kurose, J. F.; Ross, K. W. (2010). Computer Networking: A Top-Down Approach (5th ed.). Boston, MA: Pearson Education. ISBN 978-0-13-136548-3.
- ↑ Clark, M.P. (2003). Data Networks IP and the Internet, 1st ed. West Sussex, England: John Wiley & Sons Ltd.
- ↑ content@ipv6.com (15 August 2006). "यूडीपी प्रोटोकॉल अवलोकन". Ipv6.com. Retrieved 17 August 2011.
- ↑ 4.0 4.1 4.2 4.3 4.4 Forouzan, B.A. (2000). TCP/IP: Protocol Suite, 1st ed. New Delhi, India: Tata McGraw-Hill Publishing Company Limited.
- ↑ Stevens, W. Richard (1994). टीसीपी/आईपी इलस्ट्रेटेड: प्रोटोकॉल. Vol. 1 (2 ed.). Addison-Wesley. ISBN 978-0-20-163346-7.
- ↑ RFC 2675
- ↑ Deering S. & Hinden R. (December 1998). "इंटरनेट प्रोटोकॉल, संस्करण 6 (आईपीवी6) विशिष्टता". Internet Engineering Task Force. RFC 2460.
- ↑ 8.0 8.1 8.2 8.3 Postel, J. (August 1980). User Datagram Protocol. Internet Engineering Task Force. doi:10.17487/RFC0768. RFC 768.
- ↑ "16-बिट वाले के पूरक योग की गणना करें". mathforum.org. John. 2002-03-20. Archived from the original (email) on 2020-11-17. Retrieved 2014-11-05.
- ↑ इंटरनेट प्रोटोकॉल, संस्करण 6 (आईपीवी6) विशिष्टता. p. 27-28. doi:10.17487/RFC8200. RFC 8200.
- ↑ The value of the Next Header field is the protocol value for UDP
- ↑ "डेटा अनुप्रयोगों पर UDP का प्रभाव". Networkperformancedaily.com. Archived from the original on 31 July 2007. Retrieved 17 August 2011.
- ↑ "QUIC, UDP पर एक मल्टीप्लेक्स स्ट्रीम ट्रांसपोर्ट". chromium.org. Retrieved 17 February 2021.
