वेबसॉकेट्स म्हणजे काय आणि ते HTTP पेक्षा कसे वेगळे आहेत?

“रिअल-टाइम गोष्टींसाठी वेबसॉकेट्स वापरा” हे मी सतत ऐकत होतो, पण प्रत्यक्षात वायरवर काय घडतं हे कोणीच नीट सांगत नव्हतं. म्हणून मी RFC वाचलं, काही सर्व्हर्स तपासले आणि जे समजलं ते लिहून काढायचं ठरवलं — यात मला सर्वात जास्त गोंधळात टाकणारा भाग म्हणजे: वेबसॉकेट हा स्वतःचा एक स्वतंत्र प्रोटोकॉल आहे की HTTP वर केलेली एक चलाख युक्ती?

तर वेबसॉकेट म्हणजे नक्की काय?

वेबसॉकेट म्हणजे ब्राउझर (किंवा कोणताही क्लायंट) आणि सर्व्हर यांच्यातील, एकाच TCP कनेक्शनवरून उघडलेला, टिकून राहणारा, फुल-डुप्लेक्स संवाद-मार्ग आहे [1]. फुल-डुप्लेक्स म्हणजे दोन्ही बाजू कधीही, हवं तेव्हा संदेश पाठवू शकतात — फक्त विनंतीला उत्तर म्हणून नाही. हाच भाग वेबबद्दलची आपली नेहमीची मानसिक रचना मोडतो.

तुम्ही आजवर वेब ट्रॅफिकबद्दल जसा विचार केला असेल, त्याच्याशी याची तुलना करूया:

क्लायंट विनंती पाठवतो.
सर्व्हर त्याला प्रतिसाद पाठवतो.
कनेक्शन (तार्किकदृष्ट्या) बंद होतं किंवा पुढच्या विनंतीपर्यंत निष्क्रिय राहतं.

वेबसॉकेट्समध्ये मात्र, एकदा कनेक्शन उघडलं की कोणतीही बाजू कधीही डेटा पाठवू शकते — आधी विनंतीची गरज नसते. काही घडताक्षणीच सर्व्हर तुम्हाला संदेश पाठवू शकतो, “काही नवीन आहे का?” असं तुम्ही विचारण्याची वाट न पाहता [2].

वेबसॉकेट्स हा एक प्रोटोकॉल आहे का? हो — आणि तो खराखुरा मानक आहे

हाच भाग मला खरोखर साशंक करत होता. वेबसॉकेट ही जावास्क्रिप्टची युक्ती किंवा एखाद्या लायब्ररीचं वैशिष्ट्य नाही — तो एक प्रमाणित प्रोटोकॉल आहे, जो IETF ने 2011 मध्ये RFC 6455 मध्ये परिभाषित केला आहे [1][3]. त्याला स्वतःचे URI स्कीमही आहेत: साध्या वेबसॉकेट ट्रॅफिकसाठी ws:// (डीफॉल्ट पोर्ट 80) आणि TLS वरून चालणाऱ्या वेबसॉकेटसाठी wss:// (डीफॉल्ट पोर्ट 443, जो प्रत्यक्ष उत्पादन वातावरणात वापरायला हवा असा एन्क्रिप्टेड प्रकार) [1].

स्टॅकमध्ये याचं स्थान पाहिलं तर: HTTP आणि वेबसॉकेट दोन्हीही अॅप्लिकेशन-लेयर (लेयर 7) प्रोटोकॉल असून ते TCP (लेयर 4) वर चालतात [4]. म्हणजे वेबसॉकेट हा TCP ची जागा घेत नाही किंवा मूलभूत पातळीवर HTTP शी स्पर्धाही करत नाही — तो HTTP चा एक सहोदर प्रोटोकॉल आहे, जो योगायोगाने आपलं आयुष्य HTTP बोलूनच सुरू करतो.

“WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code.” — RFC 6455 [3]

त्यातला “opted-in” हा शब्द महत्त्वाचा आहे — सर्व्हरला प्रोटोकॉल बदलण्यासाठी स्पष्टपणे संमती द्यावी लागते. यावरून आपण हँडशेककडे वळूया.

हँडशेक: HTTP विनंती वेबसॉकेटमध्ये कशी रूपांतरित होते

ही या रचनेतली सर्वात चलाख गोष्ट आहे, आणि प्रामाणिकपणे सांगायचं झालं तर वेबसॉकेट्स विद्यमान इंटरनेटवर इतक्या सहजतेने का चालतात याचं हेच कारण आहे. फायरवॉल्स, प्रॉक्सीज आणि कॉर्पोरेट नेटवर्क्सना पूर्णपणे नवीन शिकावी लागेल अशी कनेक्शन-यंत्रणा शोधण्याऐवजी, वेबसॉकेट Upgrade हेडर वापरून सामान्य HTTP विनंतीतूनच स्वतःला सुरू करतो [5][6].

प्रत्यक्ष क्रम असा आहे:

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

websocket handshake

हा हँडशेक पूर्ण झाल्यावर, ते कनेक्शन यापुढे “विशेष काहीतरी करणारं HTTP कनेक्शन” राहत नाही. ते पूर्णपणे वेबसॉकेट कनेक्शन बनतं — तीच TCP पाइप, पण त्यावर चालणारा संपूर्णपणे वेगळा प्रोटोकॉल.

वेबसॉकेट विरुद्ध HTTP — खरोखरचे फरक

इथूनच गोष्ट रंजक होते, कारण एक प्रोटोकॉल दुसऱ्याला सुरुवात करून देत असला तरी दोन्ही प्रोटोकॉल मूलतः वेगवेगळ्या समस्या सोडवतात.

बाब	HTTP	वेबसॉकेट
संवादाची पद्धत	विनंती–प्रतिसाद, क्लायंट नेहमी सुरुवात करतो [2]	फुल-डुप्लेक्स — कोणतीही बाजू कधीही पाठवू शकते [1][2]
कनेक्शनचा कालावधी	अल्पायुषी; प्रत्येक देवाणघेवाणीसाठी उघडलं-बंद केलं जातं (किंवा पूल/पुनर्वापर केलं जातं) [2]	टिकाऊ; हँडशेकनंतर स्पष्टपणे बंद होईपर्यंत उघडं राहतं [2]
प्रति-संदेश ओव्हरहेड	प्रत्येक विनंती/प्रतिसादात शेकडो बाइट्सचे हेडर्स [2]	फक्त 2–6 बाइट्सचा फ्रेम ओव्हरहेड [2]
स्टेटफुलनेस	रचनेनुसार स्टेटलेस — प्रत्येक विनंती स्वतंत्र असते	स्टेटफुल — सर्व्हर कनेक्शन (आणि अनेकदा सेशन संदर्भ) जिवंत ठेवतो [4]
सर्व्हर-प्रवर्तित पुश	मूळतः शक्य नाही; क्लायंटलाच विचारावं लागतं	मूळभूत वैशिष्ट्य — डेटा तयार होताक्षणीच सर्व्हर तो पाठवू शकतो [2]
URI स्कीम	`http://`, `https://`	`ws://`, `wss://` [1]
अंतर्निहित ट्रान्सपोर्ट	TCP (लेयर 4), स्वतः लेयर 7	तेच TCP (लेयर 4), तोही लेयर 7 [4]

सर्वात मोठा फरक म्हणजे “बोलणं सुरू करण्याची परवानगी कोणाला आहे.” HTTP मध्ये सर्व्हर कधीही स्वतःहून तुम्हाला संदेश पाठवू शकत नाही — त्याला विचारण्याची वाट पाहावीच लागते. म्हणूनच, साध्या HTTP वर लाइव्ह अपडेट्सची गरज असणारे अॅप्स पोलिंग (दर काही सेकंदांनी “काही नवीन आहे का?” विचारणं) किंवा लाँग-पोलिंग (विचारून, काहीतरी घडेपर्यंत सर्व्हरला विनंती उघडी ठेवायला लावणं) अशा युक्त्यांचा आधार घेतात. दोन्ही पद्धती चालतात, पण त्या रिकाम्या प्रतिसादांवर बँडविड्थ वाया घालवतात आणि तुमच्या पोलिंग अंतरालाशी सुसंगत विलंब वाढवतात [7].

वेबसॉकेट्स ही मर्यादा पूर्णपणे काढून टाकतात. हँडशेक पूर्ण झाल्यावर, काही घडताक्षणीच सर्व्हर त्या पाइपमधून संदेश ढकलू शकतो — पोलिंग नाही, वाट पाहणं नाही, “काही नवीन नाही” अशा वाया जाणाऱ्या फेऱ्याही नाहीत [7].

वेबसॉकेट्स खरोखर कधी वापरावेत

प्रामाणिकपणे सांगायचं तर — बहुतांश CRUD अॅप्स आणि दर काही सेकंदांनी रिफ्रेश होणाऱ्या डॅशबोर्ड्ससाठी, पोलिंग किंवा लाँग-पोलिंगसह साधं HTTP चालवायला सोपं आणि पुरेसं आहे [7]. अपडेट्सची वारंवारता आणि दिशा यामुळे जेव्हा विनंती-प्रतिसाद पद्धत अवघड होते, तेव्हाच वेबसॉकेट्सची गुंतागुंत सार्थ ठरते:

चॅट अॅप्लिकेशन्स — कोणत्याही सहभागीचे संदेश जवळपास तत्काळ इतर सर्वांपर्यंत पोहोचणं गरजेचं असतं, आणि इथे प्रमाणित पद्धत म्हणजे वेबसॉकेट्स — आणि त्यामागे ठोस कारणही आहे [7].
मल्टीप्लेयर गेमिंग — गेमची स्थिती अनेकदा सेकंदाला 20–60 वेळा सिंक करावी लागते; टिकाऊ सॉकेटच्या प्रति-फ्रेम कार्यक्षमतेच्या जवळपासही दुसरं काही पोहोचत नाही.
सहयोगी संपादन (collaborative editing) — प्रत्येक कीस्ट्रोक कमीतकमी विलंबाने पसरायला हवा (Google Docs सारख्या साधनांचा विचार करा).
आर्थिक व्यापार / लाइव्ह किंमत फीड्स — 100ms पेक्षा कमी विलंबातील अपडेट्स आणि त्याच कनेक्शनवरून ऑर्डर सबमिट करण्याची क्षमता [7].
लाइव्ह नोटिफिकेशन्स आणि डॅशबोर्ड्स ज्यांना खरोखरच नियतकालिक रिफ्रेशऐवजी सेकंदा-सेकंदाला पुश हवा असतो.

जर तुमची “रिअल-टाइम” गरज प्रत्यक्षात “दर 30 सेकंदांनी अपडेट झालं तरी चालेल” अशी असेल, तर ते आधुनिक वाटतं म्हणून वेबसॉकेट्सकडे वळू नका. हा तडजोडीचा मुद्दा खरा आहे — वेबसॉकेट्ससाठी तुम्हाला कनेक्शन स्थिती, पुनर्जोडणीचं तर्कशास्त्र आणि हजारो दीर्घकालीन सॉकेट्सचं स्केलिंग सांभाळावं लागतं, जो भार लोड बॅलन्सरमागील स्टेटलेस HTTP सर्व्हर्सच्या तुलनेत लक्षणीयरीत्या वेगळा ऑपरेशनल बोजा आहे [7].

एन्क्रिप्शनबद्दल थोडक्यात

ज्याप्रमाणे HTTP कडे HTTPS आहे, त्याचप्रमाणे वेबसॉकेटकडे wss:// आहे, जो वेबसॉकेट प्रोटोकॉल TLS वरून चालवतो [1]. उत्पादन वातावरणात ws:// वापरण्याचं कोणतंही चांगलं कारण नाही — जसं तुम्ही लॉगिन फॉर्म साध्या http:// वरून पाठवायला नकार द्याल, तसंच wss:// वापरा. हँडशेक अजूनही HTTPS विनंती म्हणूनच सुरू होतो आणि नंतर अपग्रेड होतो, त्यामुळे तुम्हाला तीच प्रमाणपत्र-आधारित विश्वास-व्यवस्था मिळते जिची तुम्हाला आधीपासून सवय आहे.

शेवटी

वेबसॉकेट हा HTTP वर चिकटवलेला एखादा हॅक नाही — तो स्वतःचा असा IETF-प्रमाणित प्रोटोकॉल आहे (RFC 6455), जो फक्त “आम्ही या संभाषणासाठी अधिक योग्य अशा एखाद्या गोष्टीकडे वळू शकतो का?” असं नम्रपणे विचारण्यासाठी HTTP च्या Upgrade यंत्रणेचा वापर करतो [1][3][6]. एकदा सर्व्हरने 101 Switching Protocols सह होकार दिला, की तुम्ही पूर्णपणे HTTP-जगताबाहेर असता — तुम्ही एका टिकाऊ कनेक्शनवरून हलक्या फ्रेम्सची देवाणघेवाण करत असता, ज्यात दोन्ही बाजू हवं तेव्हा बोलू शकतात [6][2].

तुम्हाला त्याची खरोखर गरज आहे का, हा प्रश्न ते छान वाटतं का यापेक्षा वेगळा आहे. बहुतांश गोष्टींसाठी, गरज नसते. पण चॅट, गेम्स आणि लाइव्ह सहयोगी साधनांसाठी, मात्र खरोखरच असते.