वेबसॉकेट

WebSocket कंप्यूटर संचार प्रोटोकॉल है, जो एकल प्रसारण नियंत्रण प्रोटोकॉल कनेक्शन पर पूर्ण-द्वैध संचार चैनल प्रदान करता है। WebSocket प्रोटोकॉल को इंटरनेट इंजीनियरिंग टास्क फोर्स द्वारा मानकीकृत किया गया था 2011 में। वेब अनुप्रयोगों को इस प्रोटोकॉल का उपयोग करने की अनुमति देने वाले वर्तमान API विनिर्देश को WebSockets के रूप में जाना जाता है। यह वेब हाइपरटेक्स्ट एप्लिकेशन टेक्नोलॉजी वर्किंग ग्रुप द्वारा बनाए रखा गया जीवन स्तर है और विश्वव्यापी वेब संकाय से वेबसॉकेट एपीआई का उत्तराधिकारी है। वेबसॉकेट हाइपरटेक्स्ट परहस्त शिष्टाचार से अलग है। दोनों प्रोटोकॉल OSI मॉडल में परत 7 पर स्थित हैं और परत 4 पर टीसीपी पर निर्भर हैं। हालांकि वे अलग हैं, बताता है कि WebSocket को HTTP पोर्ट 443 और 80 पर काम करने के साथ-साथ HTTP प्रॉक्सी और बिचौलियों का समर्थन करने के लिए डिज़ाइन किया गया है, इस प्रकार यह HTTP के साथ संगत बनाता है। संगतता प्राप्त करने के लिए, वेबसाकेट हाथ मिलाना (कंप्यूटिंग) HTTP/1.1 अपग्रेड शीर्षलेख का उपयोग करता है HTTP प्रोटोकॉल से WebSocket प्रोटोकॉल में बदलने के लिए।

WebSocket प्रोटोकॉल वेब ब्राउज़र (या अन्य क्लाइंट (कंप्यूटिंग) एप्लिकेशन) और HTTP मतदान (कंप्यूटर विज्ञान) जैसे आधे-द्वैध विकल्पों की तुलना में कम ओवरहेड वाले वेब सर्वर के बीच बातचीत को सक्षम बनाता है, जिससे सर्वर से और सर्वर पर रीयल-टाइम डेटा ट्रांसफर की सुविधा मिलती है।. क्लाइंट द्वारा पहले अनुरोध किए बिना क्लाइंट को सामग्री भेजने के लिए सर्वर के लिए मानकीकृत तरीका प्रदान करके और कनेक्शन को खुला रखते हुए संदेशों को आगे और पीछे भेजने की अनुमति देकर इसे संभव बनाया गया है। इस तरह, क्लाइंट और सर्वर के बीच दो तरफा बातचीत हो सकती है। संचार आमतौर पर टीसीपी पोर्ट (कंप्यूटर नेटवर्किंग) संख्या 443 (या असुरक्षित कनेक्शन के मामले में 80) पर किया जाता है, जो उन वातावरणों के लिए फायदेमंद है जो फ़ायरवॉल (कंप्यूटिंग) का उपयोग करके गैर-वेब इंटरनेट कनेक्शन को ब्लॉक करते हैं। धूमकेतु (प्रोग्रामिंग) या एडोब फ्लैश प्लेयर जैसी स्टॉपगैप तकनीकों का उपयोग करके गैर-मानकीकृत तरीकों से इसी तरह के दो-तरफ़ा ब्राउज़र-सर्वर संचार प्राप्त किए गए हैं। अधिकांश ब्राउज़र प्रोटोकॉल का समर्थन करते हैं, जिनमें Google Chrome, Firefox, Microsoft Edge, Internet Explorer, Safari (वेब ​​ब्राउज़र) और ओपेरा वेब ब्राउज़र शामिल हैं। HTTP के विपरीत, WebSocket पूर्ण-द्वैध संचार प्रदान करता है। इसके अतिरिक्त, WebSocket TCP के शीर्ष पर संदेशों की स्ट्रीम सक्षम करता है। टीसीपी अकेले बाइट्स की धाराओं से संबंधित है जिसमें संदेश की कोई अंतर्निहित अवधारणा नहीं है। WebSocket से पहले, धूमकेतु (प्रोग्रामिंग) चैनलों का उपयोग करके पोर्ट 80 पूर्ण-द्वैध संचार प्राप्य था; हालांकि, धूमकेतु का कार्यान्वयन गैर-तुच्छ है, और टीसीपी हैंडशेक और एचटीटीपी हेडर ओवरहेड के कारण, यह छोटे संदेशों के लिए अक्षम है। WebSocket प्रोटोकॉल का उद्देश्य वेब की सुरक्षा धारणाओं से समझौता किए बिना इन समस्याओं को हल करना है।

WebSocket प्रोटोकॉल विनिर्देश परिभाषित करता है  (वेबसॉकेट) और   (वेबसॉकेट सिक्योर) दो नई समान संसाधन पहचानकर्ता (यूआरआई) योजनाओं के रूप में जिनका उपयोग क्रमशः अनएन्क्रिप्टेड और एन्क्रिप्टेड कनेक्शन के लिए किया जाता है। इसके अलावा योजना का नाम और टुकड़ा पहचानकर्ता (यानी।   समर्थित नहीं है), शेष यूआरआई घटकों को पथ खंड का उपयोग करने के लिए परिभाषित किया गया है। ब्राउज़र डेवलपर टूल का उपयोग करके, डेवलपर WebSocket हैंडशेक के साथ-साथ WebSocket फ़्रेम का निरीक्षण कर सकते हैं।

इतिहास
टीसीपी-आधारित सॉकेट एपीआई के लिए प्लेसहोल्डर के रूप में आप ऊब जाएंगे 5 विनिर्देश में वेबसाकेट को पहली बार टीसीपी कनेक्शन के रूप में संदर्भित किया गया था। जून 2008 में, माइकल कार्टर (उद्यमी) द्वारा चर्चाओं की श्रृंखला का नेतृत्व किया गया, जिसके परिणामस्वरूप प्रोटोकॉल का पहला संस्करण वेबसॉकेट के रूप में जाना गया। WebSocket नाम इयान हिकसन और माइकल कार्टर द्वारा शीघ्र ही #whatwg IRC चैट रूम पर सहयोग के माध्यम से गढ़ा गया था, और बाद में इयान हिकसन द्वारा HTML5 विनिर्देशन में शामिल करने के लिए लिखा गया। दिसंबर 2009 में, Google Chrome 4 मानक के लिए पूर्ण समर्थन देने वाला पहला ब्राउज़र था, जिसमें डिफ़ॉल्ट रूप से WebSocket सक्षम था। WebSocket प्रोटोकॉल का विकास बाद में W3C और WHATWG समूह से फरवरी 2010 में IETF में स्थानांतरित कर दिया गया था, और इयान हिकसन के तहत दो संशोधनों के लिए तैयार किया गया था। प्रोटोकॉल को कई ब्राउज़रों में डिफॉल्ट रूप से शिप और सक्षम करने के बाद, को दिसंबर 2011 में इयान फेट के तहत अंतिम रूप दिया गया था।

ने प्रति-संदेश के आधार पर DEFLATE एल्गोरिथम का उपयोग करके WebSocket के लिए कंप्रेशन एक्सटेंशन पेश किया।

ब्राउज़र कार्यान्वयन
WebSocket प्रोटोकॉल का सुरक्षित संस्करण Firefox 6 में लागू किया गया है, सफारी 6, गूगल क्रोम 14, ओपेरा (वेब ​​​​ब्राउज़र) 12.10 और इंटरनेट एक्सप्लोरर 10। विस्तृत प्रोटोकॉल टेस्ट सूट रिपोर्ट विशिष्ट प्रोटोकॉल पहलुओं के लिए उन ब्राउज़रों की अनुरूपता सूचीबद्ध करता है।

प्रोटोकॉल का पुराना, कम सुरक्षित संस्करण ओपेरा 11 और सफारी (वेब ​​​​ब्राउज़र) 5 के साथ-साथ आईओएस 4.2 में सफारी के मोबाइल संस्करण में लागू किया गया था। OS7 में BlackBerry Browser WebSockets को लागू करता है। भेद्यता के कारण, इसे Firefox 4 और 5 में अक्षम कर दिया गया था, और ओपेरा 11।

वेब सर्वर कार्यान्वयन
Nginx ने 2013 से WebSockets का समर्थन किया है, जिसे संस्करण 1.3.13 में लागू किया गया है वेबसॉकेट अनुप्रयोगों के रिवर्स प्रॉक्सी और लोड संतुलन (कंप्यूटिंग) के रूप में कार्य करना शामिल है। Apache HTTP सर्वर ने जुलाई, 2013 से WebSockets का समर्थन किया है, जिसे संस्करण 2.4.5 में लागू किया गया है इंटरनेट सूचना सेवाओं ने संस्करण 8 में वेबसॉकेट के लिए समर्थन जोड़ा जो कि विंडोज सर्वर 2012 के साथ जारी किया गया था। lighttpd ने 2017 से WebSockets का समर्थन किया है, जिसे संस्करण 1.4.46 में लागू किया गया है। lighttpd mod_proxy रिवर्स प्रॉक्सी के रूप में कार्य कर सकता है और WebSocket एप्लिकेशन के लोड बैलेंसर के रूप में कार्य कर सकता है। lighttpd mod_wstunnel बैकएंड एप्लिकेशन के लिए JSON प्रारूप सहित मनमाना डेटा संचारित करने के लिए WebSocket सुरंगों का निर्माण कर सकता है।

प्रोटोकॉल हैंडशेक
WebSocket कनेक्शन स्थापित करने के लिए, क्लाइंट WebSocket हैंडशेक अनुरोध भेजता है, जिसके लिए सर्वर WebSocket हैंडशेक प्रतिक्रिया देता है, जैसा कि नीचे दिए गए उदाहरण में दिखाया गया है। क्लाइंट अनुरोध (बिल्कुल HTTP की तरह, प्रत्येक पंक्ति के साथ समाप्त होता है  और अंत में अतिरिक्त रिक्त पंक्ति होनी चाहिए):

सर्वर प्रतिक्रिया:

हैंडशेक HTTP अनुरोध/प्रतिक्रिया से शुरू होता है, जिससे सर्वर HTTP कनेक्शन के साथ-साथ उसी पोर्ट पर WebSocket कनेक्शन को संभालने की अनुमति देता है। बार कनेक्शन स्थापित हो जाने के बाद, संचार द्विदिश बाइनरी प्रोटोकॉल पर स्विच हो जाता है जो HTTP प्रोटोकॉल के अनुरूप नहीं होता है।

निम्न के अलावा  हेडर, क्लाइंट भेजता है   हेडर में बेस 64-एन्कोडेड रैंडम बाइट्स होते हैं, और सर्वर कुंजी के हैश फंकशन के साथ उत्तर देता है   शीर्ष लेख। इसका उद्देश्य कैशे (कंप्यूटिंग) HTTP प्रॉक्सी को पिछले WebSocket वार्तालाप को फिर से भेजने से रोकना है, और कोई प्रमाणीकरण, गोपनीयता या अखंडता प्रदान नहीं करता है। हैशिंग फ़ंक्शन निश्चित स्ट्रिंग को जोड़ता है   (एक UUID) से मूल्य के लिए   हेडर (जो बेस64 से डिकोड नहीं किया गया है), SHA-1 हैशिंग फ़ंक्शन लागू करता है, और बेस64 का उपयोग करके परिणाम को एन्कोड करता है। RFC6455 के लिए आवश्यक है कि कुंजी बेतरतीब ढंग से चयनित 16-बाइट मान से युक्त होनी चाहिए जो बेस 64-एन्कोडेड है, वह बेस 64 में 24 बाइट्स है (अंतिम दो बाइट्स होने के साथ ). हालांकि कुछ आराम से HTTP सर्वर छोटी कुंजियों को प्रस्तुत करने की अनुमति देते हैं, कई आधुनिक HTTP सर्वर अमान्य Sec-WebSocket-Key शीर्षलेख त्रुटि के साथ अनुरोध को अस्वीकार कर देंगे।

बेस फ़्रेमिंग प्रोटोकॉल
एक बार कनेक्शन स्थापित हो जाने के बाद, क्लाइंट और सर्वर डुप्लेक्स (दूरसंचार) | फुल-डुप्लेक्स मोड में वेबसाकेट डेटा या टेक्स्ट फ्रेम आगे और पीछे भेज सकते हैं। पेलोड (कंप्यूटिंग) के बाद छोटे हेडर के साथ डेटा को न्यूनतम रूप से तैयार किया गया है। WebSocket प्रसारण को संदेशों के रूप में वर्णित किया जाता है, जहां संदेश को वैकल्पिक रूप से कई डेटा फ़्रेमों में विभाजित किया जा सकता है। यह उन संदेशों को भेजने की अनुमति दे सकता है जहां प्रारंभिक डेटा उपलब्ध है लेकिन संदेश की पूरी लंबाई अज्ञात है (यह अंत तक पहुंचने और फिन बिट के साथ प्रतिबद्ध होने तक के बाद डेटा फ्रेम भेजता है)।
 * फिन
 * संदेश में अंतिम अंश को इंगित करता है। 1 बिट।


 * आरएसवी
 * MUST 0 होना चाहिए जब तक कि किसी एक्सटेंशन द्वारा परिभाषित न किया गया हो। 1बी।

 ओपकोड
 * ओपकोड। 4ख।


 * 0
 * निरंतरता फ्रेम
 * 1
 * टेक्स्ट फ्रेम
 * 2
 * बाइनरी फ्रेम
 * 8
 * कनेक्शन बंद
 * 9
 * गुनगुनाहट
 * ए
 * पोंग
 * वगैरह।
 * आरक्षित


 * नकाब
 * यदि पेलोड डेटा छिपा हुआ है तो 1 पर सेट करें। 1बी।


 * पेलोड की लंबाई
 * पेलोड डेटा की लंबाई। 7ख।


 * 0-125
 * यह पेलोड लंबाई है।
 * 126
 * निम्नलिखित 2 बाइट्स पेलोड लंबाई हैं।
 * 127
 * निम्नलिखित 8 बाइट पेलोड लंबाई हैं।


 * मास्किंग कुंजी
 * क्लाइंट द्वारा भेजे गए सभी फ़्रेमों को इस कुंजी द्वारा मास्क किया जाना चाहिए। यदि मास्क बिट 0. 4B पर सेट है तो यह फ़ील्ड अनुपस्थित है।


 * पेलोड डेटा
 * खंड का पेलोड डेटा।

प्रोटोकॉल के विस्तार के साथ, इसका उपयोग कई धाराओं को साथ मल्टीप्लेक्स करने के लिए भी किया जा सकता है (उदाहरण के लिए बड़े पेलोड के लिए सॉकेट के एकाधिकार उपयोग से बचने के लिए)।

क्लाइंट टू सर्वर मास्किंग
क्लाइंट से भेजे गए पेलोड डेटा को मास्किंग की द्वारा मास्क किया जाना चाहिए। मास्किंग कुंजी क्लाइंट द्वारा चुना गया 4 बाइट्स का यादृच्छिक मान है और अप्रत्याशित होना चाहिए। दुर्भावनापूर्ण एप्लिकेशन को पहले से दिखाई देने वाले बाइट्स को चुनने से रोकने के लिए मास्किंग कुंजी की अप्रत्याशितता आवश्यक है। नीतभार डेटा को ढकने के लिए निम्नलिखित एल्गोरिद्म लागू किया जाता है। जे = आई एमओडी 4 रूपांतरित-ऑक्टेट [i] = मूल-ऑक्टेट [i] XOR मास्किंग-की-ऑक्टेट [जे]

सुरक्षा विचार
नियमित क्रॉस-डोमेन HTTP अनुरोधों के विपरीत, WebSocket अनुरोध समान-मूल नीति द्वारा प्रतिबंधित नहीं हैं। इसलिए, क्रॉस-साइट वेबसॉकेट हाइजैकिंग हमलों (क्रॉस-साइट अनुरोध जालसाजी के समान) से बचने के लिए, वेबसाकेट सर्वर को कनेक्शन स्थापना के दौरान अपेक्षित उत्पत्ति के खिलाफ उत्पत्ति शीर्षलेख को सत्यापित करना चाहिए, जो संभव हो सकता है जब कनेक्शन HTTP कुकी या HTTP प्रमाणीकरण के साथ प्रमाणित हो।. संवेदनशील (निजी) डेटा को WebSocket पर स्थानांतरित किए जाने पर WebSocket कनेक्शन को प्रमाणित करने के लिए टोकन या समान सुरक्षा तंत्र का उपयोग करना बेहतर होता है। भेद्यता का जीवंत उदाहरण 2020 में केबल अड्डा के रूप में देखा गया।

प्रॉक्सी ट्रैवर्सल
WebSocket प्रोटोकॉल क्लाइंट कार्यान्वयन यह पता लगाने की कोशिश करता है कि क्या उपयोगकर्ता एजेंट को गंतव्य होस्ट और पोर्ट से कनेक्ट करते समय प्रॉक्सी का उपयोग करने के लिए कॉन्फ़िगर किया गया है, और यदि ऐसा है, तो HTTP टनल#HTTP कनेक्ट विधि का उपयोग लगातार टनल सेट करने के लिए करता है।

जबकि WebSocket प्रोटोकॉल स्वयं प्रॉक्सी सर्वर और फायरवॉल से अनभिज्ञ है, यह HTTP-संगत हैंडशेक की सुविधा देता है, इस प्रकार HTTP सर्वर को अपने डिफ़ॉल्ट HTTP और HTTPS पोर्ट (क्रमशः 80 और 443) को WebSocket गेटवे या सर्वर के साथ साझा करने की अनुमति देता है। WebSocket प्रोटोकॉल क्रमशः WebSocket और WebSocket सुरक्षित कनेक्शन को इंगित करने के लिए ws: // और wss: // उपसर्ग को परिभाषित करता है। दोनों योजनाएं WebSocket प्रोटोकॉल में अपग्रेड करने के लिए HTTP/1.1 अपग्रेड हेडर का उपयोग करती हैं। कुछ प्रॉक्सी सर्वर पारदर्शी होते हैं और WebSocket के साथ ठीक काम करते हैं; अन्य WebSocket को ठीक से काम करने से रोकेंगे, जिससे कनेक्शन विफल हो जाएगा। कुछ मामलों में, अतिरिक्त प्रॉक्सी-सर्वर कॉन्फ़िगरेशन की आवश्यकता हो सकती है, और कुछ प्रॉक्सी सर्वरों को WebSocket का समर्थन करने के लिए अपग्रेड करने की आवश्यकता हो सकती है।

यदि अनएन्क्रिप्टेड WebSocket ट्रैफ़िक WebSockets समर्थन के बिना स्पष्ट या पारदर्शी प्रॉक्सी सर्वर के माध्यम से प्रवाहित होता है, तो कनेक्शन विफल हो जाएगा। यदि एन्क्रिप्टेड WebSocket कनेक्शन का उपयोग किया जाता है, तो WebSocket Secure कनेक्शन में परिवहन परत सुरक्षा (TLS) का उपयोग सुनिश्चित करता है कि  आदेश तब जारी किया जाता है जब ब्राउज़र स्पष्ट प्रॉक्सी सर्वर का उपयोग करने के लिए कॉन्फ़िगर किया गया हो। यह टनल सेट करता है, जो वेबसॉकेट सिक्योर क्लाइंट और वेबसॉकेट सर्वर के बीच HTTP प्रॉक्सी के माध्यम से निम्न-स्तरीय एंड-टू-एंड टीसीपी संचार प्रदान करता है। पारदर्शी प्रॉक्सी सर्वर के मामले में, ब्राउज़र प्रॉक्सी सर्वर से अनभिज्ञ है, इसलिए नहीं   भेजा जाता है। हालाँकि, चूंकि वायर ट्रैफ़िक एन्क्रिप्ट किया गया है, मध्यवर्ती पारदर्शी प्रॉक्सी सर्वर केवल एन्क्रिप्टेड ट्रैफ़िक की अनुमति दे सकते हैं, इसलिए इस बात की बहुत बेहतर संभावना है कि WebSocket Secure का उपयोग करने पर WebSocket कनेक्शन सफल हो जाएगा। एन्क्रिप्शन का उपयोग संसाधन लागत से मुक्त नहीं है, लेकिन अक्सर उच्चतम सफलता दर प्रदान करता है, क्योंकि यह सुरक्षित सुरंग के माध्यम से यात्रा कर रहा होगा।

2010 के मध्य के मसौदे (संस्करण हिक्सी-76) ने शीर्षलेखों के बाद कुंजी डेटा के आठ बाइट शामिल करके रिवर्स प्रॉक्सी और गेटवे के साथ संगतता तोड़ दी, लेकिन उस डेटा को विज्ञापन में शामिल नहीं किया  शीर्ष लेख। यह डेटा सभी इंटरमीडिएट्स द्वारा अग्रेषित नहीं किया गया था, जिससे प्रोटोकॉल विफलता हो सकती है। अधिक हाल के ड्राफ्ट (जैसे, hybi-09 ) मुख्य डेटा को a में रखें   शीर्षलेख, इस समस्या को हल करना।

यह भी देखें

 * बॉश (प्रोटोकॉल)
 * वेबसाकेट कार्यान्वयन की तुलना
 * नेटवर्क सॉकेट
 * धक्का प्रौद्योगिकी
 * सर्वर द्वारा भेजे गए ईवेंट
 * XMLHttpRequest
 * एचटीटीपी/2
 * इंटरनेट प्रोटोकॉल सूट
 * वेबआरटीसी

बाहरी संबंध

 * IETF Hypertext-Bidirectional (HyBi) working group
 * The WebSocket protocol - Proposed Standard published by the IETF HyBi Working Group
 * The WebSocket protocol - Internet-Draft published by the IETF HyBi Working Group
 * The WebSocket protocol - Original protocol proposal by Ian Hickson
 * The WebSocket API - W3C Working Draft specification of the API
 * The WebSocket API - W3C Candidate Recommendation specification of the API
 * WebSocket.org WebSocket demos, loopback tests, general information and community