WebSocket एक पूर्ण-द्वैध संचार प्रोटोकॉल है जो रीयल-टाइम डेटा आदान-प्रदान के लिए क्लाइंट और सर्वर के बीच एक स्थायी कनेक्शन स्थापित करता है। पारंपरिक HTTP अनुरोधों के विपरीत, यह प्रोटोकॉल एक एकल कनेक्शन स्थापित करता है और बार-बार हैंडशेक के बिना द्विदिश संचरण के लिए इसका उपयोग करता है। Mozilla Developer Network (2025) के अनुसार, WebSocket रीयल-टाइम एप्लिकेशन में HTTP polling की तुलना में विलंबता को 50% तक कम करता है।
मुख्य बिंदु
WebSocket एक संचार प्रोटोकॉल है जो TCP पर काम करता है और क्लाइंट और सर्वर के बीच एक पूर्ण-द्वैध चैनल प्रदान करता है। इसे 2011 में IETF द्वारा RFC 6455 के रूप में मानकीकृत किया गया था और यह सभी आधुनिक ब्राउज़रों, मोबाइल प्लेटफ़ॉर्म और सर्वर फ्रेमवर्क द्वारा समर्थित है।
HTTP के विपरीत, जहाँ क्लाइंट अनुरोध शुरू करता है और प्रतिक्रिया प्राप्त करता है, WebSocket कनेक्शन स्थापित होने के बाद दोनों पक्षों को किसी भी समय संदेश भेजने की अनुमति देता है। यह इसे तत्काल वितरण की आवश्यकता वाले परिदृश्यों के लिए आदर्श बनाता है: चैट, सूचनाएँ, सहयोगी दस्तावेज़ संपादन।
WebSocket प्रोटोकॉल प्रारंभिक हैंडशेक के लिए HTTP पोर्ट 80 या HTTPS पोर्ट 443 का उपयोग करता है, जिसके बाद यह न्यूनतम हेडर के साथ अपने स्वयं के प्रोटोकॉल पर स्विच करता है — HTTP में 800+ बाइट्स के बजाय केवल 2 बाइट्स। यह सुविधा बड़ी संख्या में संदेशों के साथ महत्वपूर्ण प्रदर्शन लाभ प्रदान करती है।
WebSocket कनेक्शन एक HTTP अपग्रेड अनुरोध (Upgrade) से शुरू होता है, जिसके बाद प्रोटोकॉल एक बाइनरी फ्रेम प्रारूप में बदल जाता है। फ्रेम का आकार 2 बाइट्स से 2^63 बाइट्स तक होता है, जो छोटे टेक्स्ट संदेशों और बड़े बाइनरी डेटा दोनों के संचरण की अनुमति देता है। प्रोटोकॉल संदेश विखंडन, क्लाइंट से सर्वर तक डेटा मास्किंग और कनेक्शन को सक्रिय रखने के लिए ping/pong का समर्थन करता है।
WebSocket कनेक्शन स्थापना प्रक्रिया में दो चरण होते हैं: हैंडशेक और डेटा स्थानांतरण। हैंडशेक चरण के दौरान, क्लाइंट Upgrade: websocket हेडर के साथ एक HTTP अनुरोध भेजता है, और सर्वर स्थिति 101 Switching Protocols के साथ प्रोटोकॉल स्विच की पुष्टि करता है। इसके बाद, कनेक्शन पूर्ण-द्वैध संचरण मोड में प्रवेश करता है।
WebSocket में प्रत्येक संदेश फ्रेम में विभाजित होता है। एक फ्रेम में एक opcode (टेक्स्ट, बाइनरी डेटा, बंद करना, ping/pong), पेलोड लंबाई और क्लाइंट से डेटा के लिए एक मास्किंग कुंजी होती है। फ्रेम को खंडित किया जा सकता है — नियंत्रण फ्रेम (ping/pong) संदेश खंडों के बीच प्रेषित किए जा सकते हैं, जो लंबे स्थानांतरण के दौरान कनेक्शन टाइमआउट को रोकते हैं।
const ws = new WebSocket('wss://example.com/chat')
ws.addEventListener('open', () => {
console.log('कनेक्शन स्थापित हुआ')
ws.send('नमस्ते, सर्वर!')
})
ws.addEventListener('message', (event) => {
console.log('प्राप्त हुआ:', event.data)
})
ws.addEventListener('close', () => {
console.log('कनेक्शन बंद हुआ')
})
उपरोक्त उदाहरण में, क्लाइंट सुरक्षित URL wss:// निर्दिष्ट करते हुए एक WebSocket ऑब्जेक्ट बनाता है। कनेक्शन खुलने के बाद, एक स्वागत संदेश भेजा जाता है, और संदेश हैंडलर सर्वर से प्रतिक्रियाएँ प्राप्त करता है। बंद होने पर, क्लोज़ हैंडलर सक्रिय होता है — नेटवर्क रुकावटों के मामले में पुनः कनेक्शन के लिए यह महत्वपूर्ण है।
WebSocket और HTTP के बीच मुख्य अंतर बातचीत मॉडल में है। HTTP एक अनुरोध-प्रतिक्रिया योजना पर काम करता है: क्लाइंट अनुरोध शुरू करता है, सर्वर प्रतिक्रिया देता है, और कनेक्शन बंद हो जाता है। दूसरी ओर, WebSocket एक स्थायी चैनल स्थापित करता है जिसके माध्यम से दोनों पक्ष किसी भी समय संचरण शुरू कर सकते हैं।
उन अनुप्रयोगों के लिए जिन्हें कम विलंबता और डेटा की निरंतर धारा की आवश्यकता होती है, WebSocket काफी अधिक कुशल है। HTTP Long Polling — एक विकल्प जहाँ सर्वर डेटा उपलब्ध होने तक अनुरोध को खुला रखता है — सर्वर पर अत्यधिक भार पैदा करता है और कई समवर्ती कनेक्शनों के कारण मेमोरी खपत बढ़ाता है।
| पैरामीटर | WebSocket | HTTP |
|---|---|---|
| मॉडल | पूर्ण-द्वैध | अनुरोध-प्रतिक्रिया |
| हेडर | 2-14 बाइट्स | 400-800 बाइट्स |
| स्थायी कनेक्शन | हाँ, एकल | नहीं, प्रति अनुरोध नया |
| विलंबता | कम (1-5 ms) | उच्च (50-200 ms) |
| प्रोटोकॉल | ws:// या wss:// | http:// या https:// |
High Performance Browser Networking (Grigorik, O'Reilly) के अनुसार, WebSocket रीयल-टाइम परिदृश्यों में HTTP Long Polling की तुलना में नेटवर्क विलंबता को 40-60% तक कम करता है, जबकि बार-बार हैंडशेक के उन्मूलन के कारण सर्वर लोड 3-5 गुना कम हो जाता है।
अपनी कम विलंबता और द्विदिश संचार के कारण, WebSocket का उपयोग अनुप्रयोगों की एक विस्तृत श्रृंखला में किया जाता है। मुख्य परिदृश्यों में त्वरित संदेशन, गेम में स्थिति सिंक्रनाइज़ेशन और वित्तीय प्रणालियों में बाज़ार डेटा ट्रांसमिशन शामिल हैं।
WebSocket चैट अनुप्रयोगों के लिए वास्तविक मानक बन गया है। Slack, Telegram Web और WhatsApp Web जैसे प्लेटफ़ॉर्म त्वरित संदेश वितरण के लिए WebSocket का उपयोग करते हैं। प्रोटोकॉल एक एकल चैनल के माध्यम से टेक्स्ट संदेशों और फ़ाइलों दोनों को भेजने की अनुमति देता है, जबकि ping/pong तंत्र निष्क्रियता की अवधि के दौरान भी कनेक्शन को सक्रिय रखता है।
मल्टीप्लेयर ब्राउज़र और मोबाइल गेम को खिलाड़ियों की स्थिति को सिंक्रनाइज़ करने के लिए न्यूनतम विलंबता की आवश्यकता होती है। WebSocket HTTP अनुरोधों की देरी के बिना रीयल टाइम में निर्देशांक, क्रियाएँ और ईवेंट प्रसारित करता है। Socket.IO और Colyseus जैसे फ्रेमवर्क निम्न-स्तरीय प्रोटोकॉल संचालन को अमूर्त करते हैं, स्वचालित पुनः कनेक्शन और कमरे जोड़ते हैं।
ट्रेडिंग टर्मिनल और व्यापार प्लेटफ़ॉर्म रीयल-टाइम कोट्स प्राप्त करने के लिए WebSocket का उपयोग करते हैं। कुछ मिलीसेकंड की देरी लाखों डॉलर खर्च कर सकती है, इसलिए वित्तीय API — जैसे Binance WebSocket Streams, Coinbase Pro — बाज़ार डेटा के लिए WebSocket इंटरफ़ेस प्रदान करते हैं।
मोबाइल डेवलपमेंट में, WebSocket का उपयोग मूल API के माध्यम से किया जाता है: iOS पर URLSessionWebSocketTask और Android पर OkHttp WebSocket। Flutter के लिए, web_socket_channel लाइब्रेरी मौजूद है, और React Native के लिए — react-native-websocket। IoT डिवाइस टेलीमेट्री प्रसारित करने और नियंत्रण आदेश प्राप्त करने के लिए WebSocket का उपयोग करते हैं, क्योंकि प्रोटोकॉल निरंतर HTTP polling की तुलना में कम ऊर्जा की खपत करता है।
आइए Node.js का उपयोग करके ws लाइब्रेरी के साथ एक सर्वर-साइड उदाहरण देखें — जावास्क्रिप्ट के लिए WebSocket का सबसे लोकप्रिय कार्यान्वयन। सर्वर कनेक्शन स्वीकार करता है, संदेशों को संसाधित करता है और उन्हें सभी जुड़े क्लाइंट को प्रसारित करता है।
const WebSocket = require('ws')
const wss = new WebSocket.Server({ port: 8080 })
wss.on('connection', (ws) => {
console.log('नया क्लाइंट जुड़ा')
ws.on('message', (data) => {
console.log('प्राप्त हुआ:', data.toString())
ws.send('सर्वर ने आपका संदेश प्राप्त कर लिया')
})
ws.on('close', () => {
console.log('क्लाइंट डिस्कनेक्ट हुआ')
})
})
console.log('WebSocket सर्वर पोर्ट 8080 पर शुरू हुआ')
सर्वर पोर्ट 8080 पर एक WebSocket.Server इंस्टेंस बनाता है और कनेक्शन की प्रतीक्षा करता है। प्रत्येक नए क्लाइंट को एक अलग ws ऑब्जेक्ट सौंपा जाता है जिसके माध्यम से सर्वर व्यक्तिगत संदेश भेज सकता है। सभी क्लाइंट को संदेश प्रसारित करना कनेक्शनों की सरणी के माध्यम से पुनरावृत्ति करके कार्यान्वित किया जाता है। बड़ी संख्या में क्लाइंट (1000 से अधिक) के साथ, क्लस्टरिंग समर्थन वाली लाइब्रेरी का उपयोग करने की अनुशंसा की जाती है, जैसे Socket.IO, जो Redis-आधारित स्केलिंग और स्वचालित पुनः कनेक्शन जोड़ता है।
wss.clients.forEach((client) => {
if (client.readyState === WebSocket.OPEN) {
client.send('सभी प्रतिभागियों के लिए संदेश')
}
})
भेजने से पहले readyState की जाँच करना अनिवार्य है: यदि क्लाइंट पहले ही डिस्कनेक्ट हो चुका है, तो send को कॉल करने से त्रुटि उत्पन्न होगी। WebSocket.OPEN फ़्लैग सुनिश्चित करता है कि कनेक्शन सक्रिय है और संदेश वितरित किया जाएगा।
iOS मोबाइल एप्लिकेशन के लिए, WebSocket को URLSessionWebSocketTask के माध्यम से कार्यान्वित किया जाता है, जो iOS 13 से उपलब्ध है। सत्र wss:// प्रोटोकॉल URL के साथ एक कार्य बनाता है, जिसके बाद send और receive विधियाँ कॉल की जाती हैं। संदेश प्राप्त करने को निरंतर receive रिकर्सन के माध्यम से व्यवस्थित किया जा सकता है, जो पिछले संदेश को संसाधित करने के बाद अगले संदेश की प्रतीक्षा करता है, बिना पुनः कनेक्शन के निरंतर डेटा रिसेप्शन सुनिश्चित करता है। Android के लिए, OkHttp WebSocket का उपयोग किया जाता है, जो onOpen, onMessage, onClosing और onClosed कॉलबैक के साथ एक समान इंटरफ़ेस प्रदान करता है, साथ ही कनेक्शन खोने पर स्वचालित पुनः कनेक्शन भी प्रदान करता है।
मोबाइल एप्लिकेशन में WebSocket के साथ काम करते समय, जीवनचक्र प्रबंधन पर विचार करना महत्वपूर्ण है: जब ऐप बैकग्राउंड में जाता है, तो सिस्टम कनेक्शन समाप्त कर सकता है। iOS पर, sceneDidBecomeActive डेलिगेट के माध्यम से फोरग्राउंड पर लौटने पर कनेक्शन को पुनः स्थापित किया जाना चाहिए। Android पर, कनेक्शन बनाए रखने के लिए Lifecycle-aware घटकों या Service का उपयोग किया जाना चाहिए। इसके अतिरिक्त, पुनः कनेक्शन के लिए एक्सपोनेंशियल बैकऑफ़ लागू करने की अनुशंसा की जाती है — प्रयासों के बीच अंतराल को 1 से 30 सेकंड तक बढ़ाना — अस्थायी नेटवर्क समस्याओं के दौरान सर्वर पर अत्यधिक भार पैदा करने से बचने के लिए।
अक्सर पूछे जाने वाले प्रश्न
WebSocket एक स्थायी पूर्ण-द्वैध कनेक्शन स्थापित करता है जहाँ दोनों पक्ष किसी भी समय डेटा भेज सकते हैं। HTTP अनुरोध-प्रतिक्रिया योजना पर काम करता है जहाँ प्रत्येक आदान-प्रदान के लिए एक नए कनेक्शन और पूर्ण हेडर की आवश्यकता होती है। WebSocket एक एकल TCP चैनल और केवल 2-14 बाइट्स के हेडर का उपयोग करता है, जो विलंबता को नाटकीय रूप से कम करता है।
WebSocket असुरक्षित कनेक्शन (ws://) के लिए पोर्ट 80 और सुरक्षित कनेक्शन (wss://) के लिए पोर्ट 443 का उपयोग करता है। यह अतिरिक्त कॉन्फ़िगरेशन के बिना अधिकांश प्रॉक्सी सर्वर और कॉर्पोरेट फ़ायरवॉल के माध्यम से पारित होने की अनुमति देता है। TLS एन्क्रिप्शन के कारण उत्पादन वातावरण के लिए पोर्ट 443 की अनुशंसा की जाती है।
हाँ, WebSocket सभी मोबाइल प्लेटफ़ॉर्म पर समर्थित है। iOS पर, मूल URLSessionWebSocketTask वर्ग iOS 13 से उपलब्ध है। Android पर — OkHttp WebSocket वर्ग और मानक java.net.WebSocket। React Native के लिए, react-native-websocket लाइब्रेरी मौजूद है।
WebSocket Secure प्रोटोकॉल का सुरक्षित संस्करण है जो TLS पर काम करता है। सभी डेटा HTTPS की तरह ही एन्क्रिप्ट किया जाता है। उत्पादन अनुप्रयोगों के लिए WSS अनिवार्य है, विशेष रूप से WebSocket के माध्यम से प्रमाणीकरण टोकन या व्यक्तिगत डेटा प्रेषित करते समय।
मुख्य विकल्प हैं: HTTP Long Polling (सर्वर अनुरोध को खुला रखता है), Server-Sent Events (सर्वर से एकदिशीय स्ट्रीम), और WebRTC Data Channel (पीयर-टू-पीयर संचार)। Server-Sent Events लागू करने में सरल हैं लेकिन क्लाइंट से सर्वर को भेजने का समर्थन नहीं करते हैं।
सारांश
हम एक मोबाइल एप्लिकेशन टर्नकी विकसित करेंगे
IT Sectr 2017 से स्टार्टअप और व्यवसायों के लिए iOS और Android एप्लिकेशन बनाता है। हम आपको सलाह देंगे और सर्वोत्तम समाधान प्रस्तावित करेंगे।
यह भी पढ़ें