डेटाग्राम प्रोटेकॉलका उपयोग करें

From Vigyanwiki
Revision as of 20:16, 30 December 2022 by alpha>Indicwiki (Created page with "{{short description|Principal protocol used for transmission of datagrams across an IP network}} {{Use dmy dates|date=August 2021}} {{IPstack}} कंप्यूटर न...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Internet protocol suite
Application layer
Transport layer
Internet layer
Link layer

कंप्यूटर नेटवर्किंग में, उपयोगकर्ता आंकड़ारेख प्रोटोकॉल (यूडीपी) [[इंटरनेट प्रोटोकॉल सूट]] के मुख्य संचार प्रोटोकॉल में से एक है जो इंटरनेट प्रोटोकॉल (आईपी) नेटवर्क पर अन्य मेजबानों को संदेश (नेटवर्क पैकेट में डेटाग्राम के रूप में ले जाया जाता है) भेजने के लिए उपयोग किया जाता है। आईपी ​​​​नेटवर्क के भीतर, यूडीपी को संचार चैनल या डेटा पथ स्थापित करने के लिए पूर्व संचार की आवश्यकता नहीं होती है।

यूडीपी न्यूनतम प्रोटोकॉल तंत्र के साथ एक साधारण कनेक्शन रहित संचार मॉडल का उपयोग करता है। यूडीपी डेटा अखंडता के लिए अंततः, प्रदान करता है, और डेटाग्राम के स्रोत और गंतव्य पर विभिन्न कार्यों को संबोधित करने के लिए पोर्ट नंबर प्रदान करता है। इसमें कोई हाथ मिलाना (कंप्यूटिंग) संवाद नहीं है, और इस प्रकार अंतर्निहित नेटवर्क की किसी भी विश्वसनीयता (कंप्यूटर नेटवर्किंग) के लिए उपयोगकर्ता के कार्यक्रम को उजागर करता है; डिलीवरी, ऑर्डर देने या डुप्लीकेट सुरक्षा की कोई गारंटी नहीं है। यदि नेटवर्क इंटरफ़ेस स्तर पर त्रुटि-सुधार सुविधाओं की आवश्यकता है, तो इसके बजाय एक एप्लिकेशन प्रसारण नियंत्रण प्रोटोकॉल (टीसीपी) या स्ट्रीम कंट्रोल ट्रांसमिशन प्रोटोकॉल (एससीटीपी) का उपयोग कर सकता है जो इस उद्देश्य के लिए डिज़ाइन किए गए हैं।

यूडीपी उन उद्देश्यों के लिए उपयुक्त है जहां त्रुटि जांच और सुधार या तो आवश्यक नहीं हैं या आवेदन में किए जाते हैं; यूडीपी प्रोटोकॉल स्टैक में इस तरह के प्रसंस्करण के ऊपरी हिस्से से बचा जाता है। समय-संवेदी अनुप्रयोग अक्सर यूडीपी का उपयोग करते हैं क्योंकि रिट्रान्समिशन (डेटा नेटवर्क) के कारण विलंबित पैकेटों की प्रतीक्षा करने के लिए पैकेट छोड़ना बेहतर होता है, जो वास्तविक समय प्रणाली में एक विकल्प नहीं हो सकता है।[1] प्रोटोकॉल 1980 में डेविड पी. रीड द्वारा डिजाइन किया गया था और औपचारिक रूप से 1980 में परिभाषित किया गया था RFC 768.

गुण

UDP एक साधारण संदेश-उन्मुख ट्रांसपोर्ट परत प्रोटोकॉल है, जिसे इसमें प्रलेखित किया गया है RFC 768. हालांकि यूडीपी हेडर और पेलोड की अखंडता सत्यापन (चेकसम के माध्यम से) प्रदान करता है,[2] यह संदेश वितरण के लिए ऊपरी परत प्रोटोकॉल की कोई गारंटी नहीं देता है और UDP परत एक बार भेजे जाने पर UDP संदेशों की कोई स्थिति नहीं रखती है। इस कारण से, UDP को कभी-कभी विश्वसनीयता (कंप्यूटर नेटवर्किंग) डेटाग्राम प्रोटोकॉल कहा जाता है।[3] अगर ट्रांसमिशन विश्वसनीयता वांछित है, तो इसे उपयोगकर्ता के आवेदन में लागू किया जाना चाहिए।

यूडीपी की कई विशेषताएँ इसे कुछ अनुप्रयोगों के लिए विशेष रूप से अनुकूल बनाती हैं।

पोर्ट्स

एप्लिकेशन होस्ट-टू-होस्ट संचार स्थापित करने के लिए डेटाग्राम सॉकेट का उपयोग कर सकते हैं। एक एप्लिकेशन सॉकेट को डेटा ट्रांसमिशन के अपने एंडपॉइंट से बांधता है, जो एक आईपी ​​पता और पोर्ट (कंप्यूटर नेटवर्किंग) का संयोजन है। इस तरह, यूडीपी एप्लिकेशन बहुसंकेतन प्रदान करता है। एक पोर्ट एक सॉफ्टवेयर संरचना है जिसे पोर्ट संख्या द्वारा पहचाना जाता है, एक 16-बिट पूर्णांक मान, जो 0 और 65535 के बीच पोर्ट नंबरों की अनुमति देता है। पोर्ट 0 आरक्षित है, लेकिन एक अनुमेय स्रोत पोर्ट मान है यदि भेजने की प्रक्रिया संदेशों की अपेक्षा नहीं करती है प्रतिक्रिया।

इंटरनेट निरुपित नंबर प्राधिकरण (IANA) ने पोर्ट नंबरों को तीन श्रेणियों में विभाजित किया है।[4] पोर्ट नंबर 0 से 1023 का उपयोग सामान्य, प्रसिद्ध सेवाओं के लिए किया जाता है। यूनिक्स जैसे ऑपरेटिंग सिस्टम पर, इनमें से किसी एक पोर्ट का उपयोग करने के लिए सुपर उपयोगकर्ता ऑपरेटिंग अनुमति की आवश्यकता होती है। पोर्ट नंबर 1024 से 49151 आईएएनए-पंजीकृत सेवाओं के लिए उपयोग किए जाने वाले पंजीकृत पोर्ट हैं। पोर्ट 49152 से 65535 डायनेमिक पोर्ट हैं जो किसी विशिष्ट सेवा के लिए आधिकारिक तौर पर नामित नहीं हैं, और किसी भी उद्देश्य के लिए उपयोग किए जा सकते हैं। इन्हें क्षणिक बंदरगाहों के रूप में भी इस्तेमाल किया जा सकता है, जो होस्ट पर चल रहे सॉफ़्टवेयर गतिशील रूप से आवश्यकतानुसार संचार समापन बिंदु बनाने के लिए उपयोग कर सकते हैं।[4]


यूडीपी डेटाग्राम संरचना

एक UDP डेटाग्राम में एक डेटाग्राम हेडर होता है जिसके बाद एक डेटा सेक्शन (एप्लिकेशन के लिए पेलोड डेटा) होता है। UDP डेटाग्राम हेडर में 4 फ़ील्ड होते हैं, जिनमें से प्रत्येक 2 बाइट्स (16 बिट) का होता है:[1]

UDP datagram header
Offsets Octet 0 1 2 3
Octet Bit  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 Source port Destination port
4 32 Length Checksum

IPv4 (तालिका में गुलाबी पृष्ठभूमि) में चेकसम और स्रोत पोर्ट फ़ील्ड का उपयोग वैकल्पिक है। IPv6 में केवल स्रोत पोर्ट फ़ील्ड वैकल्पिक है।

स्रोत पोर्ट संख्या
यह फ़ील्ड उपयोग किए जाने पर प्रेषक के पोर्ट की पहचान करता है, और यदि आवश्यक हो तो उत्तर देने के लिए पोर्ट माना जाना चाहिए। यदि उपयोग नहीं किया जाता है, तो यह शून्य होना चाहिए। यदि स्रोत होस्ट क्लाइंट है, तो पोर्ट नंबर एक अल्पकालिक पोर्ट होने की संभावना है। यदि स्रोत होस्ट सर्वर है, तो पोर्ट नंबर 0 से 1023 तक एक प्रसिद्ध पोर्ट नंबर होने की संभावना है।[4]; गंतव्य पोर्ट संख्या
यह फ़ील्ड रिसीवर के पोर्ट की पहचान करता है और आवश्यक है। स्रोत पोर्ट नंबर के समान, यदि क्लाइंट गंतव्य होस्ट है तो पोर्ट नंबर एक अस्थायी पोर्ट नंबर होगा और यदि गंतव्य होस्ट सर्वर है तो पोर्ट नंबर संभवतः एक प्रसिद्ध पोर्ट नंबर होगा।[4]; लंबाई
यह फ़ील्ड UDP हेडर और UDP डेटा की बाइट में लंबाई निर्दिष्ट करती है। न्यूनतम लंबाई 8 बाइट्स है, हेडर की लंबाई। यूडीपी डेटाग्राम के लिए फ़ील्ड आकार 65,535 बाइट्स (8-बाइट हेडर + 65,527 बाइट्स डेटा) की सैद्धांतिक सीमा निर्धारित करता है। हालाँकि डेटा लंबाई की वास्तविक सीमा, जो अंतर्निहित IPv4 प्रोटोकॉल द्वारा लगाई गई है, 65,507 बाइट्स (65,535 बाइट्स - 8-बाइट UDP हेडर - 20-बाइट IPv4 हेडर) है।[5]
IPv6 जंबोग्राम का उपयोग करके 65,535 बाइट्स से अधिक आकार के UDP डेटाग्राम का होना संभव है।[6] RFC 2675 निर्दिष्ट करता है कि यूडीपी हेडर प्लस यूडीपी डेटा की लंबाई 65,535 से अधिक होने पर लंबाई फ़ील्ड शून्य पर सेट है।
अंततः,
हेडर और डेटा की त्रुटि-जाँच के लिए चेकसम फ़ील्ड का उपयोग किया जा सकता है। यह फ़ील्ड IPv4 में वैकल्पिक है, और IPv6 में अनिवार्य है।[7] अप्रयुक्त होने पर क्षेत्र में सभी शून्य होते हैं।[8]


चेकसम गणना

चेकसम की गणना करने के लिए उपयोग की जाने वाली विधि को परिभाषित किया गया है RFC 768, और कुशल गणना में चर्चा की गई है RFC 1071:

Checksum is the 16-bit one's complement of the one's complement sum of a pseudo header of information from the IP header, the UDP header, and the data, padded with zero octets at the end (if necessary) to make a multiple of two octets.[8]

दूसरे शब्दों में, सभी 16-बिट शब्दों को एक पूरक अंकगणित का उपयोग करके अभिव्यक्त किया जाता है। 16-बिट मान ऊपर जोड़ें। प्रत्येक जोड़ पर, यदि एक कैरी-आउट (17 वां बिट) का उत्पादन किया जाता है, तो उस 17 वें कैरी बिट को चारों ओर घुमाएँ और इसे चल रहे कुल के कम से कम महत्वपूर्ण बिट में जोड़ दें।[9] अंत में, यूडीपी चेकसम फ़ील्ड के मूल्य को प्राप्त करने के लिए योग को पूरक बनाया जाता है।

यदि चेकसम गणना का परिणाम शून्य होता है (सभी 16 बिट्स 0) तो इसे एक के पूरक (सभी 1s) के रूप में भेजा जाना चाहिए क्योंकि शून्य-मान चेकसम इंगित करता है कि कोई चेकसम की गणना नहीं की गई है।[8]इस मामले में, रिसीवर पर किसी विशिष्ट प्रसंस्करण की आवश्यकता नहीं है, क्योंकि सभी 0s और सभी 1s 1 के पूरक अंकगणित में शून्य के बराबर हैं।

IPv4 और IPv6 के बीच अंतर चेकसम की गणना करने के लिए उपयोग किए जाने वाले स्यूडो हेडर में हैं, और यह कि IPv6 में चेकसम वैकल्पिक नहीं है।[10]


IPv4 छद्म शीर्षलेख

जब UDP IPv4 पर चलता है, तो चेकसम की गणना छद्म हेडर का उपयोग करके की जाती है जिसमें वास्तविक IPv4 हेडर से कुछ समान जानकारी होती है।[8]: 2  छद्म हेडर वास्तविक IPv4 हेडर नहीं है जिसका उपयोग IP पैकेट भेजने के लिए किया जाता है, इसका उपयोग केवल चेकसम गणना के लिए किया जाता है।

IPv4 pseudo header format
Offsets Octet 0 1 2 3
Octet Bit 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 Source IPv4 Address
4 32 Destination IPv4 Address
8 64 Zeroes Protocol UDP Length
12 96 Source Port Destination Port
16 128 UDP Length Checksum
20 160+ Data

स्रोत और गंतव्य पते वे हैं जो IPv4 हेडर में हैं। प्रोटोकॉल यूडीपी के लिए है (आईपी प्रोटोकॉल नंबरों की सूची देखें): 17 (0x11)। यूडीपी लंबाई क्षेत्र यूडीपी हेडर और डेटा की लंबाई है। फ़ील्ड डेटा संचरित डेटा के लिए खड़ा है।

IPv4 के लिए UDP चेकसम संगणना वैकल्पिक है। यदि चेकसम का उपयोग नहीं किया जाता है तो इसे शून्य मान पर सेट किया जाना चाहिए।


IPv6 छद्म शीर्षलेख

जब UDP IPv6 पर चलता है, तो चेकसम अनिवार्य है। चूंकि IPv6 में बड़े पते और एक अलग हेडर लेआउट है, इसलिए इसकी गणना करने के लिए उपयोग की जाने वाली विधि को उसी के अनुसार बदल दिया जाता हैREFERENCE FOR RFC8200 IS NOT DEFINED YET. You are invited to add it here.:

Any transport or other upper-layer protocol that includes the addresses from the IP header in its checksum computation must be modified for use over IPv6, to include the 128-bit IPv6 addresses instead of 32-bit IPv4 addresses.

चेकसम की गणना करते समय, फिर से एक सूडो हेडर का उपयोग किया जाता है जो वास्तविक IPv6 हेडर की नकल करता है:

IPv6 pseudo header format
Offsets Octet 0 1 2 3
Octet Bit 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 Source IPv6 Address
4 32
8 64
12 96
16 128 Destination IPv6 Address
20 160
24 192
28 224
32 256 UDP Length
36 288 Zeroes Next Header = Protocol[11]
40 320 Source Port Destination Port
44 352 Length Checksum
48 384+ Data

स्रोत पता IPv6 शीर्षलेख में से एक है। गंतव्य पता अंतिम गंतव्य है; यदि IPv6 पैकेट में रूटिंग हेडर नहीं है, तो वह IPv6 हेडर में गंतव्य पता होगा; अन्यथा, प्रारंभिक नोड पर, यह रूटिंग शीर्षलेख के अंतिम तत्व में पता होगा, और प्राप्त करने वाले नोड पर, यह IPv6 शीर्षलेख में गंतव्य पता होगा। अगले हेडर फ़ील्ड का मान UDP के लिए प्रोटोकॉल मान है: 17. UDP लंबाई फ़ील्ड UDP हेडर और डेटा की लंबाई है।

विश्वसनीयता और भीड़ नियंत्रण

विश्वसनीयता की कमी, यूडीपी अनुप्रयोगों में कुछ पैकेट हानि, पुनः क्रमांकन, त्रुटियां या दोहराव का सामना करना पड़ सकता है। यदि यूडीपी का उपयोग कर रहे हैं, तो एंड-यूज़र एप्लिकेशन को आवश्यक हैंडशेकिंग प्रदान करनी चाहिए जैसे कि वास्तविक समय की पुष्टि कि संदेश प्राप्त हो गया है। ट्रिवियल फाइल ट्रांसफर प्रोटोकॉल जैसे एप्लिकेशन, आवश्यकतानुसार एप्लिकेशन लेयर में अल्पविकसित विश्वसनीयता तंत्र जोड़ सकते हैं।[4]यदि किसी एप्लिकेशन को उच्च स्तर की विश्वसनीयता की आवश्यकता होती है, तो इसके बजाय ट्रांसमिशन कंट्रोल प्रोटोकॉल जैसे प्रोटोकॉल का उपयोग किया जा सकता है।

बहुधा, यूडीपी अनुप्रयोग विश्वसनीयता तंत्रों को नियोजित नहीं करते हैं और उनके द्वारा बाधित भी हो सकते हैं। स्ट्रीमिंग मीडिया, रीयल-टाइम मल्टीप्लेयर गेम और वॉयस ओवर आईपी (वीओआईपी) ऐसे अनुप्रयोगों के उदाहरण हैं जो अक्सर यूडीपी का उपयोग करते हैं। इन विशेष अनुप्रयोगों में, पैकेट का नुकसान आमतौर पर घातक समस्या नहीं होती है। वीओआईपी में, उदाहरण के लिए, विलंबता और घबराना प्राथमिक चिंताएं हैं। यदि कोई पैकेट गुम हो जाता है तो टीसीपी का उपयोग घबराहट पैदा करेगा क्योंकि टीसीपी आवेदन के बाद के डेटा को प्रदान नहीं करता है, जबकि यह लापता डेटा को फिर से भेजने का अनुरोध कर रहा है।

अनुप्रयोग

कई प्रमुख इंटरनेट एप्लिकेशन UDP का उपयोग करते हैं, जिनमें शामिल हैं: डोमेन नाम सिस्टम (DNS), सरल नेटवर्क प्रबंधन प्रोटोकॉल (SNMP), रूटिंग सूचना प्रोटोकॉल (RIP)[1]और डायनेमिक होस्ट कॉन्फ़िगरेशन प्रोटोकॉल (डीएचसीपी)।

आवाज और वीडियो यातायात आम तौर पर यूडीपी का उपयोग कर प्रसारित किया जाता है। IP पर वास्तविक समय के वीडियो और ऑडियो को कभी-कभी खोए हुए पैकेटों को संभालने के लिए डिज़ाइन किया गया है, इसलिए गुणवत्ता में केवल मामूली गिरावट होती है, बजाय बड़े विलंब के यदि खोए हुए पैकेटों को पुनः प्रेषित किया जाता है। क्योंकि टीसीपी और यूडीपी दोनों एक ही नेटवर्क पर चलते हैं, 2000 के दशक के मध्य में कुछ व्यवसायों ने पाया कि इन वास्तविक समय के अनुप्रयोगों से यूडीपी ट्रैफ़िक में वृद्धि ने टीसीपी का उपयोग करने वाले अनुप्रयोगों के प्रदर्शन को थोड़ा बाधित किया जैसे बिक्री बिंदु, लेखा सॉफ्टवेयर और डेटाबेस प्रबंधन प्रणाली सिस्टम (जब टीसीपी पैकेट हानि का पता लगाता है, तो यह डेटा दर उपयोग को वापस कर देगा)।[12] कुछ वीपीएन सिस्टम जैसे ओपनवीपीएन यूडीपी का उपयोग कर सकते हैं और विश्वसनीय कनेक्शन लागू करते समय एप्लिकेशन स्तर पर त्रुटि जांच कर सकते हैं।

QUIC एक ट्रांसपोर्ट प्रोटोकॉल है जो UDP के ऊपर बनाया गया है। QUIC एक विश्वसनीय और सुरक्षित कनेक्शन प्रदान करता है। HTTP/3 HTTPS के पिछले संस्करणों के विपरीत QUIC का उपयोग करता है जो क्रमशः विश्वसनीयता और सुरक्षा सुनिश्चित करने के लिए ट्रांसमिशन कंट्रोल प्रोटोकॉल और परिवहन परत सुरक्षा के संयोजन का उपयोग करते हैं। इसका मतलब यह है कि टीसीपी और टीएलएस के लिए दो अलग-अलग हैंडशेक होने के बजाय एचटीटीपी/3 कनेक्शन स्थापित करने के लिए एक सिंगल हैंडशेक का उपयोग करता है, जिसका अर्थ है कि कनेक्शन स्थापित करने का कुल समय कम हो जाता है।[13]


== यूडीपी और टीसीपी == की तुलना

See also: Transport layer

ट्रांसमिशन कंट्रोल प्रोटोकॉल एक कनेक्शन-उन्मुख प्रोटोकॉल है और एंड-टू-एंड संचार स्थापित करने के लिए हैंडशेकिंग की आवश्यकता होती है। एक बार कनेक्शन स्थापित हो जाने के बाद, कनेक्शन पर उपयोगकर्ता डेटा द्वि-दिशात्मक रूप से भेजा जा सकता है।

  • विश्वसनीय - टीसीपी संदेश पावती, पुन: प्रसारण और टाइमआउट का प्रबंधन करता है। संदेश देने के कई प्रयास किए जाते हैं। अगर रास्ते में डेटा खो जाता है, तो डेटा फिर से भेजा जाएगा। टीसीपी में, या तो कोई लापता डेटा नहीं है, या, कई टाइमआउट के मामले में, कनेक्शन गिरा दिया गया है।
  • आदेश दिया गया - यदि दो संदेश क्रम में एक कनेक्शन पर भेजे जाते हैं, तो पहला संदेश प्राप्त करने वाले एप्लिकेशन तक पहुंच जाएगा। जब डेटा सेगमेंट गलत क्रम में आते हैं, तो टीसीपी आउट-ऑफ-ऑर्डर डेटा को तब तक बफ़र करता है जब तक कि सभी डेटा को ठीक से री-ऑर्डर नहीं किया जा सकता और एप्लिकेशन को डिलीवर नहीं किया जा सकता।
  • हैवीवेट - किसी भी उपयोगकर्ता डेटा को भेजे जाने से पहले टीसीपी को सॉकेट कनेक्शन स्थापित करने के लिए तीन पैकेट की आवश्यकता होती है। टीसीपी विश्वसनीयता और भीड़ नियंत्रण को संभालती है।
  • स्ट्रीमिंग - डेटा को बाइट स्ट्रीम के रूप में पढ़ा जाता है, सिग्नल संदेश (सेगमेंट) सीमाओं में कोई विशिष्ट संकेत प्रेषित नहीं होते हैं।

उपयोगकर्ता डेटाग्राम प्रोटोकॉल एक सरल संदेश-आधारित कनेक्शन रहित प्रोटोकॉल है। कनेक्शन रहित प्रोटोकॉल एक समर्पित एंड-टू-एंड कनेक्शन सेट नहीं करते हैं। प्राप्तकर्ता की तत्परता या स्थिति को सत्यापित किए बिना स्रोत से गंतव्य तक एक दिशा में सूचना प्रसारित करके संचार प्राप्त किया जाता है।

  • अविश्वसनीय - जब एक यूडीपी संदेश भेजा जाता है, तो यह ज्ञात नहीं हो सकता है कि यह अपने गंतव्य तक पहुंचेगा या नहीं; यह रास्ते में खो सकता है। पावती, पुन: प्रसारण, या टाइमआउट की कोई अवधारणा नहीं है।
  • आदेशित नहीं - यदि दो संदेश एक ही प्राप्तकर्ता को भेजे जाते हैं, तो जिस क्रम में वे आते हैं उसकी गारंटी नहीं दी जा सकती।
  • लाइटवेट - संदेशों का कोई क्रम नहीं है, कोई ट्रैकिंग कनेक्शन आदि नहीं है। यह आईपी के शीर्ष पर डिज़ाइन की गई एक बहुत ही सरल परिवहन परत है।
  • डेटाग्राम - पैकेट व्यक्तिगत रूप से भेजे जाते हैं और आगमन पर अखंडता के लिए जाँच की जाती है। पैकेटों की निश्चित सीमाएँ होती हैं जिन्हें प्राप्त होने पर सम्मानित किया जाता है; रिसीवर सॉकेट पर एक रीड ऑपरेशन एक संपूर्ण संदेश देगा क्योंकि यह मूल रूप से भेजा गया था।
  • कोई भीड़ नियंत्रण नहीं - यूडीपी स्वयं भीड़भाड़ से नहीं बचता है। कंजेशन नियंत्रण उपायों को एप्लिकेशन स्तर पर या नेटवर्क में लागू किया जाना चाहिए।
  • प्रसारण - कनेक्शन रहित होने के कारण, यूडीपी प्रसारित कर सकता है - भेजे गए पैकेट को सबनेट पर सभी उपकरणों द्वारा प्राप्य होने के लिए संबोधित किया जा सकता है।
  • मल्टीकास्ट - ऑपरेशन का एक मल्टीकास्ट मोड समर्थित है जिससे ग्राहकों के एक समूह को दोहराव के बिना एक डेटाग्राम पैकेट को स्वचालित रूप से रूट किया जा सकता है।

मानक

  • RFC 768 - डेटाग्राम प्रोटेकॉलका उपयोग करें
  • RFC 2460 - इंटरनेट प्रोटोकॉल, संस्करण 6 (आईपीवी6) विशिष्टता
  • RFC 2675 - IPv6 जंबोग्राम
  • RFC 4113 - यूडीपी के लिए प्रबंधन सूचना आधार
  • RFC 8085 - यूडीपी उपयोग दिशानिर्देश

यह भी देखें


संदर्भ

  1. ↑ 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.
  2. ↑ Clark, M.P. (2003). Data Networks IP and the Internet, 1st ed. West Sussex, England: John Wiley & Sons Ltd.
  3. ↑ content@ipv6.com (15 August 2006). "यूडीपी प्रोटोकॉल अवलोकन". Ipv6.com. Retrieved 17 August 2011.
  4. ↑ 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.
  5. ↑ Stevens, W. Richard (1994). टीसीपी/आईपी इलस्ट्रेटेड: प्रोटोकॉल. Vol. 1 (2 ed.). Addison-Wesley. ISBN 978-0-20-163346-7.
  6. ↑ RFC 2675
  7. ↑ Deering S. & Hinden R. (December 1998). "इंटरनेट प्रोटोकॉल, संस्करण 6 (आईपीवी6) विशिष्टता". Internet Engineering Task Force. RFC 2460.
  8. ↑ 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.
  9. ↑ "16-बिट वाले के पूरक योग की गणना करें". mathforum.org. John. 20 March 2002. Archived from the original (email) on 17 November 2020. Retrieved 5 November 2014.
  10. ↑ इंटरनेट प्रोटोकॉल, संस्करण 6 (आईपीवी6) विशिष्टता. p. 27-28. doi:10.17487/RFC8200. RFC 8200.
  11. ↑ The value of the Next Header field is the protocol value for UDP
  12. ↑ "डेटा अनुप्रयोगों पर UDP का प्रभाव". Networkperformancedaily.com. Archived from the original on 31 July 2007. Retrieved 17 August 2011.
  13. ↑ "QUIC, UDP पर एक मल्टीप्लेक्स स्ट्रीम ट्रांसपोर्ट". chromium.org. Retrieved 17 February 2021.


इस पेज में लापता आंतरिक लिंक की सूची

  • बातचीत का माध्यम
  • पुनर्संचरण (डेटा नेटवर्क)
  • रूटिंग इन्फोर्मेशन प्रोटोकॉल
  • अस्थायी बंदरगाह
  • पंजीकृत बंदरगाह
  • प्रसिद्ध बंदरगाह
  • आईपी ​​​​प्रोटोकॉल नंबरों की सूची
  • IPv6 हैडर
  • साधारण नेटवर्क प्रबंधन प्रोटोकॉल
  • आईपी ​​​​पर ऑडियो
  • बिक्री केन्द्र
  • लेखांकन सॉफ्टवेयर
  • यूडीपी आधारित डेटा ट्रांसफर प्रोटोकॉल

बाहरी कड़ियाँ

Wikiversity has learning resources about User Datagram Protocol

श्रेणी: इंटरनेट प्रोटोकॉल श्रेणी: इंटरनेट मानक श्रेणी: परिवहन परत प्रोटोकॉल श्रेणी:1980 परिचय

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=डेटाग्राम_प्रोटेकॉलका_उपयोग_करें&oldid=68213’