वेबसॉकेट्स (WebSockets) कैसे काम करते हैं: वास्तविक समय कनेक्शन की पूरी जानकारी
वेब के शुरुआती दिनों में, ब्राउज़र एक सरल दस्तावेज़ दर्शक था। आपने एक पेज के लिए अनुरोध किया, सर्वर ने उसे रेंडर किया, और कनेक्शन बंद हो गया। यह अनुरोध-प्रतिक्रिया (request-response) चक्र HTTP (Hypertext Transfer Protocol) का मूल है।
हालांकि, जैसे-जैसे वेब एप्लिकेशन अधिक इंटरैक्टिव और वास्तविक समय के अनुभवों—जैसे चैट, लाइव वित्तीय टिकर, सहयोगी दस्तावेज़ संपादन और मल्टीप्लेयर गेम—में विकसित हुए, पारंपरिक HTTP मॉडल की सीमाएं सामने आने लगीं।
लाइव अपडेट प्राप्त करने के लिए, डेवलपर्स शुरू में कुछ वैकल्पिक तरीकों पर निर्भर थे:
- शॉर्ट पोलिंग (Short Polling): ब्राउज़र नए डेटा की जांच करने के लिए हर कुछ सेकंड में सर्वर को बार-बार HTTP अनुरोध भेजता है। यह बहुत अधिक हेडर ओवरहेड उत्पन्न करता है और सर्वर के संसाधनों को बर्बाद करता है।
- लॉन्ग पोलिंग (Long Polling / Comet): ब्राउज़र एक अनुरोध भेजता है, और सर्वर नया डेटा उपलब्ध होने तक कनेक्शन खुला रखता है। डेटा भेजे जाने के बाद, कनेक्शन बंद हो जाता है और ब्राउज़र तुरंत एक नया अनुरोध खोलता है। इसे प्रबंधित करना जटिल है और कनेक्शन सेटअप में अभी भी बहुत अधिक ओवरहेड शामिल है।
वेबसॉकेट्स (WebSockets) ने एकल TCP कनेक्शन पर स्थायी, द्वि-दिशात्मक (bi-directional), और फुल-डुप्लेक्स संचार के लिए एक मानकीकृत प्रोटोकॉल पेश करके इन सीमाओं को हल कर दिया।
वेबसॉकेट क्या है?
वेबसॉकेट्स (RFC 6455 में परिभाषित) HTTP के साथ काम करते हैं। जहाँ HTTP एक स्टेटलेस (stateless) प्रोटोकॉल है जिसमें केवल क्लाइंट अनुरोध शुरू कर सकता है, वहीं वेबसॉकेट कनेक्शन एक बार स्थापित होने के बाद अनिश्चित काल तक खुला रहता है, जिससे क्लाइंट और सर्वर दोनों न्यूनतम विलंबता (latency) के साथ किसी भी समय एक-दूसरे को डेटा भेज सकते हैं।
वेबसॉकेट का मूल नियम यह है:
एक बार स्थापित होने के बाद, कोई भी पक्ष नया कनेक्शन अनुरोध शुरू किए बिना किसी भी समय संदेश भेज सकता है।
चरण-दर-चरण कनेक्शन चक्र (Lifecycle)
एक वेबसॉकेट कनेक्शन तीन अलग-अलग चरणों से गुजरता है: हैंडशेक (Handshake), डेटा ट्रांसफर, और कनेक्शन बंद होना।
1. HTTP हैंडशेक (प्रोटोकॉल अपग्रेड)
चूंकि फ़ायरवॉल और राउटर आमतौर पर पोर्ट 80 (HTTP) और 443 (HTTPS) पर मानक वेब ट्रैफ़िक की अनुमति देने के लिए कॉन्फ़िगर किए जाते हैं, इसलिए वेबसॉकेट्स की शुरुआत एक मानक HTTP/1.1 अनुरोध के रूप में होती है। इसे अपग्रेड हैंडशेक कहा जाता है।
क्लाइंट का अनुरोध
क्लाइंट प्रोटोकॉल बदलने का अनुरोध करने वाले विशिष्ट हेडर के साथ एक HTTP GET अनुरोध भेजता है:
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Origin: https://example.com
Upgrade: websocketऔरConnection: Upgrade: सर्वर को सूचित करते हैं कि क्लाइंट प्रोटोकॉल बदलना चाहता है।Sec-WebSocket-Key: बेस64 में एन्कोडेड एक यादृच्छिक 16-बाइट मान। इसका उपयोग यह साबित करने के लिए किया जाता है कि सर्वर को हैंडशेक प्राप्त हुआ है और वह वेबसॉकेट प्रोटोकॉल को समझता है।Sec-WebSocket-Version: वेबसॉकेट प्रोटोकॉल संस्करण (आमतौर पर 13) निर्दिष्ट करता है।Origin: सर्वर द्वारा यह तय करने के लिए उपयोग किया जाता है कि कनेक्शन की अनुमति दी जाए या नहीं (अनाधिकृत साइटों के खिलाफ सुरक्षा जांच)।
सर्वर की प्रतिक्रिया
यदि सर्वर वेबसॉकेट का समर्थन करता है, तो यह अनुरोध को सत्यापित करता है और HTTP स्थिति कोड 101 Switching Protocols के साथ प्रतिक्रिया देता है:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
- सर्वर
Sec-WebSocket-Acceptकी गणना कैसे करता है:- सर्वर क्लाइंट का
Sec-WebSocket-Key(dGhlIHNhbXBsZSBub25jZQ==) लेता है। - इसे एक मानक मैजिक GUID स्ट्रिंग
"258EAFA5-E914-47DA-95CA-C5AB0DC85B11"के साथ जोड़ता है। - संयुक्त स्ट्रिंग का SHA-1 हैश निकालता है।
- परिणामी हैश को बेस64 में एन्कोड करता है।
- यदि क्लाइंट सत्यापित करता है कि यह मान उसकी उम्मीदों से मेल खाता है, तो हैंडशेक सफल होता है, HTTP कनेक्शन एक कच्चे TCP सॉकेट में बदल जाता है, और दोनों पक्ष वेबसॉकेट प्रोटोकॉल पर स्विच हो जाते हैं।
- सर्वर क्लाइंट का
2. डेटा फ़्रेमिंग और ट्रांसफर
HTTP के विपरीत, जो सादे टेक्स्ट हेडर और उसके बाद बॉडी भेजता है, वेबसॉकेट्स डेटा को संरचित बाइनरी पैकेट में प्रसारित करते हैं जिन्हें फ़्रेम (frames) कहा जाता है।
एक वेबसॉकेट फ़्रेम में एक बहुत ही हल्का हेडर (2 से 14 बाइट्स तक) होता है, जिसके बाद पेलोड (डेटा) होता है। इस हेडर में शामिल हैं:
- FIN बिट (1 बिट): यह दर्शाता है कि क्या यह संदेश का अंतिम फ़्रेम है।
- Opcode (4 बिट): फ़्रेम के प्रकार को परिभाषित करता है:
0x1: टेक्स्ट फ़्रेम (UTF-8 एन्कोडेड)0x2: बाइनरी फ़्रेम0x8: कनेक्शन बंद करने का अनुरोध0x9: पिंग (Ping)0xA: पोंग (Pong)
- मास्क बिट (1 बिट): यह निर्दिष्ट करता है कि पेलोड डेटा मास्क किया गया है या नहीं।
- पेलोड की लंबाई: डेटा का आकार।
- मास्किंग कुंजी (4 बाइट्स): महत्वपूर्ण सुरक्षा आवश्यकता: क्लाइंट से सर्वर पर भेजे जाने वाले सभी फ़्रेमों को एक यादृच्छिक 4-बाइट कुंजी का उपयोग करके मास्क (XOR विधि से अस्पष्ट) किया जाना चाहिए। यह मध्यवर्ती प्रॉक्सी कैशे को ट्रैफ़िक पढ़ने या कैशे पॉइज़निंग हमलों को अंजाम देने से रोकता है। सर्वर-से-क्लाइंट फ़्रेम मास्क नहीं किए जाने चाहिए।
हार्टबीट (पिंग/पोंग)
राउटर और लोड बैलेंसर को निष्क्रिय कनेक्शन बंद करने से रोकने के लिए, कोई भी पक्ष Ping फ़्रेम भेज सकता है। प्राप्त करने वाले पक्ष को तुरंत उसी पेलोड वाले Pong फ़्रेम के साथ उत्तर देना होगा।
3. कनेक्शन बंद करना
कनेक्शन को ठीक से बंद करने के लिए:
- एक पक्ष एक
Closeफ़्रेम भेजता है जिसमें स्थिति कोड (जैसे सामान्य बंद के लिए1000, असामान्य बंद के लिए1006) और एक वैकल्पिक विवरण होता है। - दूसरा पक्ष अपने स्वयं के
Closeफ़्रेम के साथ उत्तर देता है। - अंतर्निहित TCP सॉकेट बंद हो जाता है।
कोड उदाहरण: Node.js वेबसॉकेट कार्यान्वयन
वेबसॉकेट्स को काम करते हुए देखने के लिए, आइए एक सरल Node.js एप्लिकेशन लिखें। हम एक स्थानीय वेबसॉकेट सर्वर बनाएंगे जो प्राप्त होने वाले किसी भी संदेश को वापस भेजता है, साथ ही इससे जुड़ने के लिए एक क्लाइंट स्क्रिप्ट भी बनाएंगे।
वेबसॉकेट सर्वर (server.js)
const { WebSocketServer } = require('ws');
const http = require('http');
// 1. एक मानक HTTP सर्वर बनाएं
const server = http.createServer((req, res) => {
res.writeHead(200, { 'Content-Type': 'text/plain' });
res.end('HTTP Server running. Use WebSocket to connect.\n');
});
// 2. HTTP सर्वर से वेबसॉकेट सर्वर जोड़ें
const wss = new WebSocketServer({ server });
wss.on('connection', (ws, req) => {
const clientIp = req.socket.remoteAddress;
console.log(`[सर्वर] नया क्लाइंट जुड़ा: ${clientIp}`);
// क्लाइंट को स्वागत संदेश भेजें
ws.send(JSON.stringify({ type: 'welcome', message: 'ग़ज़्निक्स वेबसॉकेट सर्वर से जुड़े!' }));
// इस क्लाइंट से आने वाले संदेशों को सुनें
ws.on('message', (message) => {
console.log(`[सर्वर] प्राप्त संदेश: ${message}`);
try {
const data = JSON.parse(message);
ws.send(JSON.stringify({
type: 'echo',
message: `सर्वर प्रतिध्वनि: ${data.text.toUpperCase()}`,
timestamp: new Date().toISOString()
}));
} catch (e) {
ws.send(JSON.stringify({ type: 'error', message: 'अमान्य JSON प्रारूप' }));
}
});
// क्लाइंट डिस्कनेक्ट को संभालें
ws.on('close', (code, reason) => {
console.log(`[सर्वर] क्लाइंट डिस्कनेक्ट हुआ (कोड: ${code}, कारण: ${reason.toString() || 'कोई नहीं'})`);
});
ws.on('error', (error) => {
console.error(`[सर्वर] सॉकेट त्रुटि: ${error.message}`);
});
});
server.listen(8080, () => {
console.log('वेबसॉकेट सर्वर ws://localhost:8080 पर सुन रहा है');
});
ब्राउज़र क्लाइंट (क्लाइंट-साइड जावास्क्रिप्ट)
आप इस क्लाइंट को सीधे अपने ब्राउज़र के कंसोल में चला सकते हैं:
// 1. सर्वर से कनेक्शन स्थापित करें
const socket = new WebSocket('ws://localhost:8080');
// 2. कनेक्शन खुलने पर चलने वाला हैंडलर
socket.addEventListener('open', (event) => {
console.log('[क्लाइंट] सर्वर से जुड़ गया।');
const payload = JSON.stringify({ text: 'नमस्ते सर्वर!' });
socket.send(payload);
console.log(`[क्लाइंट] भेजा गया: ${payload}`);
});
// 3. सर्वर से आने वाले संदेशों को सुनें
socket.addEventListener('message', (event) => {
const response = JSON.parse(event.data);
console.log('[क्लाइंट] सर्वर से संदेश प्राप्त हुआ:', response);
});
// 4. कनेक्शन बंद होने को सुनें
socket.addEventListener('close', (event) => {
console.log(`[क्लाइंट] कनेक्शन बंद हो गया (कोड: ${event.code})`);
});
// 5. त्रुटियों को सुनें
socket.addEventListener('error', (error) => {
console.error('[क्लाइंट] वेबसॉकेट त्रुटि:', error);
});
HTTP बनाम वेबसॉकेट्स: एक विस्तृत तुलना
| विशेषता | HTTP/1.1 | वेबसॉकेट्स |
|---|---|---|
| संचार | एक-दिशात्मक (क्लाइंट द्वारा शुरू) | द्वि-दिशात्मक (क्लाइंट या सर्वर दोनों) |
| कनेक्शन मॉडल | अनुरोध-प्रतिक्रिया (अल्पकालिक) | स्थायी (दीर्घकालिक) |
| ओवरहेड | उच्च (हर अनुरोध के साथ हेडर भेजे जाते हैं) | बहुत कम (न्यूनतम फ़्रेम ओवरहेड) |
| स्थिति (State) | स्टेटलेस | स्टेटफुल (कनेक्शन संदर्भ बना रहता है) |
| प्रोटोकॉल | http:// या https:// |
ws:// या wss:// |
| उपयुक्तता | दस्तावेज़ प्राप्त करना, REST API | रियल-टाइम चैट, डैशबोर्ड, लाइव फ़ीड |
वेबसॉकेट्स के लिए सुरक्षा संबंधी विचार
चूंकि वेबसॉकेट्स हैंडशेक के बाद मानक HTTP रूटिंग को बायपास करते हैं, वे अद्वितीय सुरक्षा जोखिम लाते हैं:
- सुरक्षित वेबसॉकेट (
wss://) का उपयोग करें: हमेशा TLS/SSL (पोर्ट 443) पर वेबसॉकेट्स चलाएं। WSS डेटा को एन्क्रिप्ट करता है, जिससे बीच में डेटा चोरी या छेड़छाड़ को रोका जा सके। - ओरिजिन सत्यापन (Origin Validation): वेबसॉकेट्स उसी-उत्पत्ति नीति (Same-Origin Policy) द्वारा प्रतिबंधित नहीं हैं। अनधिकृत साइटों को कनेक्शन बनाने से रोकने के लिए हैंडशेक के दौरान सर्वर पर हमेशा
Originहेडर को सत्यापित करें। - हैंडशेक पर प्रमाणीकरण (Authentication): कनेक्शन स्थापित होने से पहले उपयोगकर्ताओं को प्रमाणित करें। यह आमतौर पर क्वेरी पैरामीटर में टोकन (जैसे JWT) पास करके या सत्र कुकीज़ को सत्यापित करके किया जाता है।
- इनपुट स्वच्छता (Sanitization): वेबसॉकेट्स के माध्यम से प्राप्त प्रत्येक संदेश को अविश्वसनीय इनपुट के रूप में मानें। क्रॉस-साइट स्क्रिप्टिंग (XSS) को रोकने के लिए डेटा को सत्यापित और साफ़ करें।
सारांश
वेबसॉकेट्स ने पारंपरिक HTTP पोलिंग के ओवरहेड को समाप्त करके वास्तविक समय के वेब अनुप्रयोगों में क्रांति ला दी है। एक ही स्थायी TCP कनेक्शन को बनाए रखकर, यह तत्काल द्वि-दिशात्मक संदेश भेजने में सक्षम बनाता है, जो आज के लाइव डैशबोर्ड, ऑनलाइन गेम और चैट ऐप को शक्ति प्रदान करता है। HTTP अपग्रेड, फ़्रेमिंग आर्किटेक्चर और महत्वपूर्ण सुरक्षा प्रथाओं को समझना यह सुनिश्चित करता है कि आप तेज़ और सुरक्षित वास्तविक समय सेवाएं बनाएं।
ग़ज़्निक्स ब्लॉग पर डेवलपर ट्यूटोरियल और गाइड के बारे में अधिक जानें →