UDP (User Datagram Protocol) एक बिना कनेक्शन वाला डेटा ट्रांसमिशन प्रोटोकॉल है जो IP पर काम करता है और डेटाग्राम भेजते समय न्यूनतम विलंबता प्रदान करता है। TCP के विपरीत, UDP डिलीवरी, पैकेट क्रम या डुप्लिकेशन से सुरक्षा की गारंटी नहीं देता है। IETF RFC 768 (2024) के अनुसार, UDP वीडियो कॉल, स्ट्रीमिंग और DNS क्वेरी के कारण वैश्विक इंटरनेट ट्रैफिक के 40% से अधिक को संभालता है।
मुख्य बातें
UDP (User Datagram Protocol) TCP/IP मॉडल की ट्रांसपोर्ट लेयर के प्रमुख प्रोटोकॉल में से एक है, जिसे David Reed ने 1980 में डिज़ाइन किया था। यह डेटा ट्रांसमिशन का न्यूनतम तंत्र प्रदान करता है: एप्लिकेशन एक डेटाग्राम भेजता है, और प्रोटोकॉल यह ट्रैक नहीं करता कि वह प्राप्तकर्ता तक पहुँचा या नहीं।
UDP हेडर में केवल चार फ़ील्ड होते हैं: स्रोत पोर्ट, गंतव्य पोर्ट, लंबाई और चेकसम। प्रत्येक फ़ील्ड 2 बाइट्स का होता है, इसलिए हेडर का कुल आकार 8 बाइट्स है। तुलना के लिए, TCP हेडर बिना विकल्पों के 20 बाइट्स और विकल्पों के साथ 60 बाइट्स तक होता है।
प्रोटोकॉल अपने स्तर पर फ़्रेग्मेंटेशन का समर्थन नहीं करता है — यदि कोई डेटाग्राम MTU (Maximum Transmission Unit) से अधिक होता है, तो यह IP स्तर पर फ़्रेग्मेंट हो जाता है। यदि एक फ़्रेग्मेंट खो जाता है, तो पूरा डेटाग्राम खारिज कर दिया जाता है, क्योंकि UDP अलग-अलग फ़्रेग्मेंट की पुनर्प्रेषण का अनुरोध नहीं कर सकता। डेवलपर्स को डेटाग्राम आकार को नियंत्रित करना चाहिए — मोबाइल नेटवर्क के लिए, MTU अक्सर 1400 बाइट्स होता है, इसलिए अधिकतम आकार इस मान से अधिक नहीं होना चाहिए।
UDP का उपयोग करने वाला एप्लिकेशन SOCK_DGRAM प्रकार का सॉकेट बनाता है, पोर्ट और गंतव्य IP पता निर्दिष्ट करता है, और एक डेटाग्राम भेजता है। प्रोटोकॉल न्यूनतम हेडर जोड़ता है और पैकेट को IP स्तर पर भेजता है। प्राप्तकर्ता अपने पोर्ट पर सुनता है और आने वाले डेटाग्राम से डेटा निकालता है।
UDP कंजेशन कंट्रोल नहीं करता — एप्लिकेशन नेटवर्क द्वारा समर्थित अधिकतम गति पर डेटाग्राम भेज सकता है। इससे चैनल कंजेशन हो सकता है, लेकिन रीयल-टाइम परिदृश्यों में ऐसी आक्रामकता उचित है: वीडियो कॉल के लिए, संभावित हानि वाला डेटा स्ट्रीम ट्रांसमिशन रोकने से अधिक महत्वपूर्ण है।
import socket
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.sendto(b'Hello, UDP!', ('192.168.1.100', 8888))
sock.close()
इस उदाहरण में, UDP के लिए एक SOCK_DGRAM सॉकेट बनाया गया है। sendto विधि कनेक्शन स्थापित किए बिना डेटाग्राम भेजती है — केवल प्राप्तकर्ता का IP और पोर्ट जानना आवश्यक है। सर्वर की ओर recvfrom विधि प्रतिक्रिया के लिए डेटा और भेजने वाले का पता दोनों लौटाती है। मोबाइल प्लेटफ़ॉर्म पर UDP सॉकेट समान रूप से कॉन्फ़िगर किए जाते हैं लेकिन अतिरिक्त अनुमतियों की आवश्यकता होती है: iOS पर, अनएन्क्रिप्टेड UDP कनेक्शन के लिए NSAppTransportSecurity जोड़ना होगा, और Android पर, मेनिफेस्ट में INTERNET अनुमति।
UDP चुनना उन परिदृश्यों में उचित है जहाँ गति विश्वसनीयता से अधिक महत्वपूर्ण है। प्रोटोकॉल कनेक्शन स्थापना, पुष्टिकरण और पुनर्प्रेषण पर समय बर्बाद नहीं करता — यह न्यूनतम विलंबता प्रदान करता है, लेकिन डेवलपर को स्वतंत्र रूप से हानि को संभालने की आवश्यकता होती है।
| लाभ | हानियाँ |
|---|---|
| कम विलंबता — कोई हैंडशेक नहीं | डिलीवरी की कोई गारंटी नहीं |
| छोटा हेडर — 8 बाइट्स | कोई कंजेशन कंट्रोल नहीं |
| ब्रॉडकास्ट और मल्टीकास्ट समर्थन | पैकेट डुप्लिकेट संभव |
| डेटाग्राम स्वतंत्रता — कोई कतार नहीं | डेटाग्राम आकार MTU द्वारा सीमित |
मोबाइल एप्लिकेशन में, UDP का उपयोग WebRTC जैसे फ्रेमवर्क के माध्यम से किया जाता है, जो UDP के ऊपर हानि नियंत्रण, अनुकूली बिटरेट और जिटर बफ़र जोड़ते हैं। यह नंगे प्रोटोकॉल की कमियों के बिना गति के लाभ प्रदान करता है।
UDP का एक और महत्वपूर्ण पहलू कंजेशन कंट्रोल की अनुपस्थिति है। TCP में, Slow Start और Congestion Avoidance एल्गोरिदम नेटवर्क ओवरलोड से बचने के लिए पैकेट हानि पर ट्रांसमिशन गति कम कर देते हैं। UDP में ऐसे तंत्र नहीं हैं, इसलिए डेवलपर्स को अपनी स्वयं की दर नियंत्रण रणनीतियों को लागू करना चाहिए — उदाहरण के लिए, वीडियो कॉल में अनुकूली बिटरेट या गेम सर्वर में अत्यधिक नेटवर्क कंजेशन को रोकने के लिए रेट लिमिटिंग।
UDP उन परिदृश्यों में अपरिहार्य है जहाँ विलंबता सहनशीलता पैकेट हानि सहनशीलता से अधिक महत्वपूर्ण है। आइए मोबाइल और वेब डेवलपमेंट में प्रोटोकॉल के मुख्य अनुप्रयोग क्षेत्रों का पता लगाएं।
RTP और RTSP प्रोटोकॉल, जो UDP पर चलते हैं, रीयल-टाइम ऑडियो और वीडियो स्ट्रीम ट्रांसमिट करने के लिए उपयोग किए जाते हैं। WebRTC — ब्राउज़र और मोबाइल एप्लिकेशन में वीडियो कॉल का मानक — मीडिया डेटा के लिए UDP को प्राथमिक ट्रांसपोर्ट और सिग्नलिंग के लिए TCP का उपयोग करता है। 30 fps वीडियो में एक पैकेट खोना उपयोगकर्ता के लिए अदृश्य होता है, पुनर्प्रेषण की देरी के विपरीत जो चित्र में ध्यान देने योग्य रुकावट पैदा करती है।
मल्टीप्लेयर शूटर और MOBA को उचित सिंक्रनाइज़ेशन के लिए 50 ms से कम विलंबता की आवश्यकता होती है। UDP खिलाड़ियों की स्थिति, शॉट्स और घटनाओं को TCP से तेज़ी से ट्रांसमिट करता है, और पैकेट हानि को आसानी से अनदेखा किया जाता है — अगला अपडेट 16–33 ms में आ जाएगा। लोकप्रिय गेम इंजन, जिनमें Unity और Unreal Engine शामिल हैं, एप्लिकेशन-स्तरीय पुष्टिकरण के माध्यम से महत्वपूर्ण घटनाओं के लिए अतिरिक्त विश्वसनीयता के साथ अपनी स्वयं की ट्रांसपोर्ट परतों के माध्यम से UDP का उपयोग करते हैं।
DNS क्वेरी पोर्ट 53 पर UDP का उपयोग करती हैं क्योंकि प्रत्येक क्वेरी एक एकल छोटा डेटाग्राम (आमतौर पर 512 बाइट्स तक) होता है। यदि कोई प्रतिक्रिया नहीं आती है, तो क्लाइंट टाइमआउट के बाद क्वेरी को फिर से प्रयास करता है, जो तीन-तरफ़ा हैंडशेक के साथ TCP कनेक्शन स्थापित करने से तेज़ है। DHCP भी UDP पर काम करता है, क्योंकि क्लाइंट के पास अभी तक IP पता नहीं है और वह TCP कनेक्शन स्थापित नहीं कर सकता, जबकि ब्रॉडकास्ट UDP पैकेट स्थानीय नेटवर्क पर DHCP सर्वर खोजने की अनुमति देते हैं।
UDP और TCP के बीच चुनाव गति और विश्वसनीयता के बीच एक समझौता है। प्रत्येक प्रोटोकॉल अपने कार्य वर्ग के लिए इष्टतम है, और उनके अंतर को समझने से मोबाइल एप्लिकेशन में नेटवर्क संचार डिज़ाइन करते समय सही आर्किटेक्चरल निर्णय लेने में मदद मिलती है।
| मानदंड | UDP | TCP |
|---|---|---|
| कनेक्शन स्थापना | आवश्यक नहीं | तीन-तरफ़ा हैंडशेक |
| हेडर | 8 बाइट्स | 20–60 बाइट्स |
| डिलीवरी गारंटी | नहीं | हाँ, पुष्टिकरण के साथ |
| क्रमबद्धता | नहीं | हाँ |
| कंजेशन कंट्रोल | नहीं | हाँ (AIMD, Slow Start) |
| उपयोग के मामले | स्ट्रीमिंग, गेम, DNS | वेब, ईमेल, फ़ाइलें, API |
मोबाइल प्रोजेक्ट अक्सर हाइब्रिड दृष्टिकोण का उपयोग करते हैं: विश्वसनीय अनुरोधों (प्रमाणीकरण, डेटा लोडिंग) के लिए TCP और मीडिया स्ट्रीम के लिए UDP। QUIC — UDP पर चलने वाला Google का एक आधुनिक प्रोटोकॉल — UDP की गति को TCP की विश्वसनीयता के साथ जोड़ता है और पहले से ही HTTP/3 में उपयोग किया जाता है।
आइए Python में एक सरल UDP सर्वर देखें जो क्लाइंट से संदेश प्राप्त करता है और प्रतिक्रिया भेजता है। सर्वर पोर्ट 8888 पर सुनता है और अनंत लूप में आने वाले डेटाग्राम को प्रोसेस करता है।
import socket
server = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
server.bind(('0.0.0.0', 8888))
print('UDP सर्वर पोर्ट 8888 पर शुरू हुआ')
while True:
data, addr = server.recvfrom(1024)
print(f'{addr} से प्राप्त: {data.decode()}')
server.sendto(b'OK', addr)
सर्वर एक UDP सॉकेट बनाता है, पोर्ट 8888 से बाइंड होता है, और आने वाले डेटाग्राम की प्रतीक्षा करता है। recvfrom डेटा और क्लाइंट का पता लौटाता है, जो sendto के माध्यम से प्रतिक्रिया देने की अनुमति देता है। TCP के विपरीत, सर्वर कनेक्शन की स्थिति बनाए नहीं रखता — प्रत्येक डेटाग्राम स्वतंत्र रूप से प्रोसेस किया जाता है। यह UDP सर्वर को स्केलेबल बनाता है: एक एकल सर्वर प्रत्येक व्यक्तिगत कनेक्शन के लिए मेमोरी आवंटित किए बिना लाखों क्लाइंट को संभाल सकता है, जो DNS सर्वर और गेम मैचमेकिंग सिस्टम के लिए महत्वपूर्ण है।
मोबाइल डेवलपमेंट में, UDP का उपयोग अक्सर उच्च-स्तरीय लाइब्रेरी के माध्यम से किया जाता है। उदाहरण के लिए, CocoaAsyncSocket iOS के लिए डेलीगेट और GCD के साथ UDP सॉकेट प्रदान करता है जो एसिंक्रोनस इवेंट हैंडलिंग के लिए होते हैं। Android पर, DatagramSocket क्लास मानक java.net लाइब्रेरी का हिस्सा है और किसी अतिरिक्त निर्भरता की आवश्यकता नहीं है। Flutter के लिए, udp पैकेज है जो नेटिव सॉकेट कॉन्फ़िगर किए बिना डेटाग्राम भेजने और प्राप्त करने के लिए एक सरल इंटरफ़ेस प्रदान करता है।
यह ध्यान रखना महत्वपूर्ण है कि कई मोबाइल नेटवर्क और कॉर्पोरेट फ़ायरवॉल UDP ट्रैफिक को ब्लॉक करते हैं, विशेष रूप से 1024 से ऊपर के पोर्ट पर। यदि आपका एप्लिकेशन UDP का उपयोग करता है, तो आपको TCP पर फ़ॉलबैक प्रदान करना होगा या STUN सर्वर के माध्यम से प्रोटोकॉल उपलब्धता की जांच करनी होगी, जैसा कि WebRTC करता है। iOS पर, सिस्टम Network.framework NWConnection के साथ TCP और UDP दोनों का समर्थन करता है, उपलब्धता के आधार पर स्वचालित रूप से इष्टतम प्रोटोकॉल चुनता है। रीयल-टाइम एप्लिकेशन के लिए, अनुकूली बिटरेट लागू करने की भी सिफारिश की जाती है, जो पैकेट हानि पर स्ट्रीम गुणवत्ता कम करता है, उच्च त्रुटि दर वाले अस्थिर चैनलों पर भी निरंतर प्लेबैक सुनिश्चित करता है।
अक्सर पूछे जाने वाले प्रश्न
UDP कनेक्शन स्थापित नहीं करता और पैकेट डिलीवरी की गारंटी नहीं देता, जो इसे TCP से तेज़ बनाता है। UDP हेडर 8 बाइट्स है जबकि TCP का 20–60 बाइट्स है। UDP स्ट्रीमिंग और गेम के लिए उपयुक्त है, जबकि TCP वेब अनुरोधों और फ़ाइल ट्रांसफर के लिए।
डेटाग्राम UDP हेडर (स्रोत पोर्ट, गंतव्य पोर्ट, लंबाई, चेकसम) के साथ एक स्वतंत्र डेटा पैकेट है। प्रत्येक डेटाग्राम पिछले वाले से संबंध के बिना स्वतंत्र रूप से प्रोसेस किया जाता है। डेटाग्राम का आकार नेटवर्क MTU द्वारा सीमित है और विशिष्टता के अनुसार — 65507 बाइट्स तक।
UDP ट्रांसपोर्ट स्तर पर विश्वसनीयता प्रदान नहीं करता — इसे एप्लिकेशन द्वारा लागू किया जाता है। डेवलपर्स अनुक्रम संख्या, चेकसम, पुनर्प्रेषण अनुरोध और त्रुटि सुधार जोड़ते हैं। FEC (Forward Error Correction) पुनर्प्रेषण के बिना खोए गए पैकेट को पुनर्प्राप्त करने की अनुमति देता है।
UDP उन परिदृश्यों के लिए उपयुक्त नहीं है जहाँ डेटा अखंडता महत्वपूर्ण है: फ़ाइल ट्रांसफर, बैंक लेनदेन, REST API। इन मामलों में, TCP गारंटी देता है कि प्रत्येक बाइट सही क्रम में पहुँचे। उच्च हानि दर वाले अस्थिर चैनलों पर भी UDP की अनुशंसा नहीं की जाती है।
QUIC UDP पर चलने वाला एक ट्रांसपोर्ट प्रोटोकॉल है, जिसे Google द्वारा विकसित किया गया और IETF द्वारा RFC 9000 के रूप में मानकीकृत किया गया। यह UDP की गति को TCP की विश्वसनीयता के साथ जोड़ता है, हेड-ऑफ-लाइन ब्लॉकिंग के बिना मल्टीप्लेक्सिंग का समर्थन करता है, और इसमें अंतर्निहित एन्क्रिप्शन है। HTTP/3 अपनी ट्रांसपोर्ट परत के रूप में QUIC का उपयोग करता है।
सारांश
हम एक मोबाइल एप्लिकेशन टर्नकी विकसित करेंगे
IT Sectr 2017 से स्टार्टअप और व्यवसायों के लिए iOS और Android एप्लिकेशन बनाता है। हम आपको सलाह देंगे और सर्वोत्तम समाधान प्रस्तावित करेंगे।
यह भी पढ़ें