वेबसॉकेट क्या है और यह HTTP से कैसे अलग है?

मैं लगातार सुनता रहा “रियल-टाइम चीज़ों के लिए वेबसॉकेट इस्तेमाल करो” बिना यह समझे कि वायर पर असल में होता क्या है। तो मैंने जाकर RFC पढ़ा, कुछ सर्वर्स को टटोला, और सोचा कि जो कुछ मुझे पता चला वह लिख दूं — जिसमें वह हिस्सा भी शामिल है जिसने मुझे सबसे ज़्यादा उलझाया: क्या वेबसॉकेट अपने आप में एक प्रोटोकॉल है या सिर्फ HTTP के ऊपर कोई चालाक तरकीब?

तो वेबसॉकेट है क्या?

वेबसॉकेट एक स्थायी (persistent), फुल-डुप्लेक्स कम्युनिकेशन चैनल है जो ब्राउज़र (या किसी भी क्लाइंट) और सर्वर के बीच एक ही TCP कनेक्शन पर खुलता है [1]। फुल-डुप्लेक्स का मतलब है कि दोनों पक्ष जब चाहें संदेश भेज सकते हैं — सिर्फ़ किसी अनुरोध के जवाब में नहीं। यही वह हिस्सा है जो वेब के सामान्य मानसिक मॉडल को तोड़ देता है।

इसकी तुलना उस तरीके से करें जिस तरह से आप शायद अपने पूरे करियर में वेब ट्रैफ़िक के बारे में सोचते आए हैं:

• क्लाइंट एक अनुरोध भेजता है।
• सर्वर एक जवाब वापस भेजता है।
• कनेक्शन (तार्किक रूप से) बंद हो जाता है या अगले अनुरोध तक निष्क्रिय पड़ा रहता है।

वेबसॉकेट के साथ, एक बार कनेक्शन खुल जाने के बाद, कोई भी पक्ष किसी भी क्षण डेटा भेज सकता है — पहले किसी अनुरोध की ज़रूरत नहीं। सर्वर आपको यह पूछने का इंतज़ार किए बिना ही, कि “कुछ नया है क्या?”, कुछ होते ही तुरंत संदेश भेज सकता है [2]।

क्या वेबसॉकेट एक प्रोटोकॉल है? हाँ — और यह एक असली मानक है

यह वह हिस्सा है जिसके बारे में मैं वाकई अनिश्चित था। वेबसॉकेट कोई जावास्क्रिप्ट तरकीब या लाइब्रेरी फ़ीचर नहीं है — यह एक मानकीकृत प्रोटोकॉल है, जिसे 2011 में IETF द्वारा RFC 6455 में परिभाषित किया गया [1][3]। इसकी अपनी URI स्कीमें भी हैं: सामान्य वेबसॉकेट ट्रैफ़िक के लिए ws:// (डिफ़ॉल्ट पोर्ट 80) और TLS पर वेबसॉकेट के लिए wss:// (डिफ़ॉल्ट पोर्ट 443, यानी एन्क्रिप्टेड संस्करण जिसे आपको प्रोडक्शन में वास्तव में इस्तेमाल करना चाहिए) [1]।

स्टैक में इसकी जगह की बात करें तो: HTTP और वेबसॉकेट दोनों ही एप्लिकेशन-लेयर (लेयर 7) प्रोटोकॉल हैं जो TCP (लेयर 4) के ऊपर चलते हैं [4]। तो वेबसॉकेट न तो TCP की जगह ले रहा है और न ही मूलभूत स्तर पर HTTP से प्रतिस्पर्धा कर रहा है — यह HTTP का एक सहोदर प्रोटोकॉल है जो संयोग से अपनी ज़िंदगी की शुरुआत HTTP बोलकर करता है।

“वेबसॉकेट प्रोटोकॉल एक नियंत्रित वातावरण में अविश्वसनीय कोड चला रहे क्लाइंट और एक दूरस्थ होस्ट के बीच, जिसने उस कोड से संचार के लिए सहमति दी हो, द्विदिश संचार सक्षम करता है।” — RFC 6455 [3]

वह “सहमति दी हो” वाला वाक्यांश महत्वपूर्ण है — सर्वर को प्रोटोकॉल बदलने के लिए स्पष्ट रूप से सहमत होना पड़ता है। यही हमें हैंडशेक तक ले आता है।

हैंडशेक: एक HTTP अनुरोध वेबसॉकेट में कैसे बदलता है

यह डिज़ाइन का सबसे चतुर हिस्सा है, और ईमानदारी से कहूं तो यही वजह है कि वेबसॉकेट मौजूदा इंटरनेट पर इतनी अच्छी तरह काम करता है। एक बिल्कुल नया कनेक्शन तंत्र गढ़ने के बजाय, जिसे फायरवॉल, प्रॉक्सी और कॉर्पोरेट नेटवर्क सभी को नए सिरे से सीखना पड़ता, वेबसॉकेट खुद को Upgrade हेडर का इस्तेमाल करते हुए एक सामान्य HTTP अनुरोध के ज़रिए बूटस्ट्रैप करता है [5][6]।

असली क्रम इस तरह है:

1. क्लाइंट एक सामान्य दिखने वाला HTTP GET अनुरोध भेजता है, लेकिन उसमें अतिरिक्त हेडर होते हैं: Upgrade: websocket, Connection: Upgrade, और एक यादृच्छिक रूप से बना Sec-WebSocket-Key [1][6]।
2. यदि सर्वर वेबसॉकेट को सपोर्ट करता है, तो वह HTTP/1.1 101 Switching Protocols के साथ जवाब देता है, जिसमें Upgrade: websocket और Connection: Upgrade को दोहराया जाता है, साथ ही एक Sec-WebSocket-Accept हेडर भी होता है [6]।
3. वह Sec-WebSocket-Accept मान मनमाना नहीं होता — सर्वर क्लाइंट की कुंजी लेता है, उसमें एक निश्चित “मैजिक” GUID (258EAFA5-E914-47DA-95CA-C5AB0DC85B11) जोड़ता है, उसे SHA-1 से गुज़ारता है, और परिणाम को base64 में एन्कोड करता है। इससे यह साबित होता है कि सर्वर ने वाकई वेबसॉकेट अनुरोध को समझा है, न कि कोई भी रैंडम सर्वर सिर्फ़ हेडर वापस भेज रहा है [6]।
4. इस बिंदु से आगे, वही अंतर्निहित TCP सॉकेट HTTP बोलना पूरी तरह बंद कर देता है और वेबसॉकेट फ्रेम का आदान-प्रदान शुरू कर देता है — एक हल्का बाइनरी फ्रेमिंग फ़ॉर्मेट जिसमें प्रति संदेश मात्र 2-6 बाइट्स का ओवरहेड होता है, और जो टेक्स्ट फ्रेम, बाइनरी फ्रेम, तथा कंट्रोल फ्रेम (ping/pong/close) को सपोर्ट करता है [2][1]।

एक बार यह हैंडशेक पूरा हो जाने पर, कनेक्शन अब “एक HTTP कनेक्शन जो संयोग से कुछ खास करता है” नहीं रह जाता। यह पूरी तरह से एक वेबसॉकेट कनेक्शन बन चुका होता है — वही TCP पाइप, लेकिन उस पर चल रहा एक बिल्कुल अलग प्रोटोकॉल।

वेबसॉकेट बनाम HTTP — असली अंतर

यहीं से यह दिलचस्प हो जाता है, क्योंकि दोनों प्रोटोकॉल मूलभूत रूप से अलग-अलग समस्याएं हल करते हैं, भले ही एक दूसरे के ज़रिए बूटस्ट्रैप होता हो।

सबसे बड़ा अंतर है “बातचीत शुरू करने की इजाज़त किसे है।” HTTP में, सर्वर कभी भी आपको खुद से संदेश नहीं भेज सकता — उसे पूछे जाने का इंतज़ार करना पड़ता है। यही वजह है कि जिन ऐप्स को सादे HTTP पर लाइव अपडेट चाहिए होते हैं, वे पोलिंग (हर कुछ सेकंड में “कुछ नया है क्या?” पूछना) या लॉन्ग-पोलिंग (पूछना और सर्वर को अनुरोध तब तक खुला रखने देना जब तक कुछ न हो जाए) जैसी तरकीबों का सहारा लेते हैं। दोनों काम करती हैं, लेकिन वे खाली प्रतिक्रियाओं पर बैंडविड्थ बर्बाद करती हैं और आपके पोलिंग अंतराल के अनुपात में देरी जोड़ती हैं [7]।

वेबसॉकेट इस बाधा को पूरी तरह हटा देता है। हैंडशेक पूरा होते ही, सर्वर कुछ होते ही तुरंत पाइप में संदेश डाल सकता है — कोई पोलिंग नहीं, कोई इंतज़ार नहीं, “कुछ नया नहीं” वाले बेकार राउंड ट्रिप नहीं [7]।

आप वेबसॉकेट का इस्तेमाल वास्तव में कब करेंगे

ईमानदारी से कहूं — ज़्यादातर CRUD ऐप्स और डैशबोर्ड्स के लिए, जो हर कुछ सेकंड में रिफ्रेश होते हैं, पोलिंग या लॉन्ग-पोलिंग के साथ सादा HTTP चलाना ज़्यादा आसान और काफ़ी है [7]। वेबसॉकेट तब अपनी जटिलता को सही ठहराते हैं जब अपडेट की आवृत्ति और दिशा अनुरोध-प्रतिक्रिया मॉडल को बोझिल बना देती है:

• चैट एप्लिकेशन — किसी भी प्रतिभागी के संदेश को बाकी सभी तक लगभग तुरंत पहुंचना ज़रूरी होता है, और यहां मानक तरीका वेबसॉकेट ही है, और इसकी अच्छी वजह भी है [7]।
• मल्टीप्लेयर गेमिंग — गेम की स्थिति को अक्सर प्रति सेकंड 20–60 बार सिंक करना पड़ता है; इसके अलावा कुछ भी एक स्थायी सॉकेट की प्रति-फ्रेम क्षमता के आसपास नहीं पहुंचता।
• सहयोगी संपादन (collaborative editing) — हर कीस्ट्रोक को न्यूनतम देरी के साथ प्रसारित होना ज़रूरी है (जैसे Google Docs जैसे टूल्स)।
• वित्तीय ट्रेडिंग / लाइव प्राइस फ़ीड — उसी कनेक्शन पर ऑर्डर सबमिट करने की क्षमता के साथ 100 मिलीसेकंड से कम के अपडेट [7]।
• लाइव नोटिफ़िकेशन और डैशबोर्ड जिन्हें वाकई समय-समय पर रिफ्रेश के बजाय हर सेकंड पुश की ज़रूरत होती है।

अगर आपकी “रियल-टाइम” ज़रूरत असल में सिर्फ़ “हर 30 सेकंड में अपडेट होना ठीक है” है, तो सिर्फ़ इसलिए वेबसॉकेट मत अपनाइए कि यह आधुनिक लगता है। यह ट्रेड-ऑफ असली है — वेबसॉकेट के लिए आपको कनेक्शन स्टेट, पुनर्संयोजन (reconnection) तर्क, और हज़ारों लंबे समय तक चलने वाले सॉकेट्स को स्केल करना पड़ता है, जो लोड बैलेंसर के पीछे चल रहे स्टेटलेस HTTP सर्वरों की तुलना में एक सार्थक रूप से अलग परिचालन बोझ है [7]।

एन्क्रिप्शन पर एक संक्षिप्त नोट

जिस तरह HTTP का HTTPS होता है, उसी तरह वेबसॉकेट का wss:// होता है, जो वेबसॉकेट प्रोटोकॉल को TLS पर चलाता है [1]। प्रोडक्शन में ws:// भेजने की कोई अच्छी वजह नहीं है — wss:// का इस्तेमाल वैसे ही कीजिए जैसे आप सादे http:// पर लॉगिन फ़ॉर्म भेजने से इनकार करेंगे। हैंडशेक अब भी अपग्रेड होने से पहले एक HTTPS अनुरोध के रूप में शुरू होता है, इसलिए आपको वही प्रमाणपत्र-आधारित विश्वास मॉडल मिलता है जिसके आप पहले से अभ्यस्त हैं।

समापन

वेबसॉकेट HTTP पर जोड़ी गई कोई जुगाड़ नहीं है — यह अपने आप में एक IETF-मानकीकृत प्रोटोकॉल (RFC 6455) है, जो HTTP के Upgrade तंत्र का इस्तेमाल बस यह विनम्रता से पूछने के तरीके के रूप में करता है कि “क्या हम इस बातचीत के लिए ज़्यादा उपयुक्त किसी चीज़ पर स्विच कर सकते हैं?” [1][3][6]। एक बार जब सर्वर 101 Switching Protocols के साथ हां कह देता है, तो आप अब बिल्कुल भी HTTP-लोक में नहीं रहते — आप एक ऐसे कनेक्शन पर हल्के फ्रेमों का आदान-प्रदान कर रहे होते हैं जो खुला रहता है और दोनों पक्षों को जब चाहें बात करने देता है [6][2]।

क्या आपको वाकई इसकी ज़रूरत है, यह सवाल इससे अलग है कि यह सुनने में कितना दिलचस्प लगता है। ज़्यादातर चीज़ों के लिए, आपको ज़रूरत नहीं है। चैट, गेम्स, और लाइव सहयोगी टूल्स के लिए, आपको वाकई ज़रूरत है।

स्रोत

1. WebSocket Protocol: RFC 6455 Handshake, Frames & More — WebSocket.org
2. WebSockets vs HTTP: Key Differences Explained — Postman Blog
3. RFC 6455 — The WebSocket Protocol (RFC Editor)
4. What is a WebSocket? — IP With Ease
5. Protocol upgrade mechanism — HTTP — MDN Web Docs
6. Writing WebSocket servers — Web APIs — MDN Web Docs
7. Long Polling vs WebSockets: Choosing the Right Transport for Real-Time Feeds — GetStream