वेबसॉकेट

वेब साॅकेट मुख्य रूप से कंप्यूटर संचार प्रोटोकॉल है, जो एकल प्रसारण नियंत्रण प्रोटोकॉल कनेक्शन पर पूर्ण रूप से द्वैध संचार चैनल प्रदान करने में सहायक है। इस प्रकार वेब साॅकेट प्रोटोकॉल को इंटरनेट इंजीनियरिंग टास्क फोर्स द्वारा 2011 में मानकीकृत किया गया था। इस प्रकार वेब अनुप्रयोगों को इस प्रोटोकॉल का उपयोग करने की अनुमति देने वाले वर्तमान समय में एपीआई विनिर्देश को वेब साॅकेट के रूप में जाना जाता है। यह वेब हाइपरटेक्स्ट एप्लिकेशन टेक्नोलॉजी वर्किंग ग्रुप द्वारा बनाए रखा गया जीवन स्तर है और विश्वव्यापी वेब संकाय से वेबसॉकेट एपीआई का उत्तराधिकारी है।

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

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

अधिकांश ब्राउज़र प्रोटोकॉल का समर्थन करते हैं, जिनमें गूगल क्रोम, फायर फाॅक्स, माइक्रोसाॅफ्ट एज, इंटरनेट एक्सप्लोरर, सफारी (वेब ​​ब्राउज़र) और ओपेरा वेब ब्राउज़र सम्मिलित हैं। एटीटीपी के विपरीत, वेब साॅकेट पूर्ण-द्वैध संचार प्रदान करता है। इसके अतिरिक्त, वेब साॅकेट TCP के शीर्ष पर संदेशों की स्ट्रीम सक्षम करता है। टीसीपी अकेले बाइट्स की धाराओं से संबंधित है जिसमें संदेश की कोई अंतर्निहित अवधारणा नहीं है। इस प्रकार वेब साॅकेट से पहले, काॅमेड (प्रोग्रामिंग) चैनलों का उपयोग करके पोर्ट 80 पूर्ण-द्वैध संचार प्राप्य था, चूंकि, काॅमेड का कार्यान्वयन गैर-तुच्छ है, और टीसीपी हैंडशेक और एचटीटीपी हेडर ओवरहेड के कारण, यह छोटे संदेशों के लिए अक्षम है। वेब साॅकेट प्रोटोकॉल का उद्देश्य वेब की सुरक्षा धारणाओं से समझौता किए बिना इन समस्याओं को हल करना है।

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

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

इस प्रकार प्रोटोकॉल को कई ब्राउज़रों में डिफॉल्ट रूप से शिप और सक्षम करने के पश्चात को दिसंबर 2011 में इयान फेट के अनुसार अंतिम रूप दिया गया था।

ने प्रति-संदेश के आधार पर डेफलेट एल्गोरिथम का उपयोग करके वेब साॅकेट के लिए कंप्रेशन एक्सटेंशन प्रस्तुत किया था।

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

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

वेब सर्वर कार्यान्वयन
एनजीनिक्स ने 2013 से वेब साॅकेट का समर्थन किया है, जिसे संस्करण 1.3.13 में लागू किया गया है वेबसॉकेट अनुप्रयोगों के रिवर्स प्रॉक्सी और लोड संतुलन (कंप्यूटिंग) के रूप में कार्य करना सम्मिलित है। अपाची एटीटीपी सर्वर ने जुलाई, 2013 से वेब साॅकेट का समर्थन किया है, जिसे संस्करण 2.4.5 में लागू किया गया है इंटरनेट सूचना सेवाओं ने संस्करण 8 में वेबसॉकेट के लिए समर्थन जोड़ा जो कि विंडोज सर्वर 2012 के साथ प्रस्तुत किया गया था।

एलआईजीएटीटीपीडी ने 2017 से वेब साॅकेट का समर्थन किया है, जिसे संस्करण 1.4.46 में लागू किया गया है। इस प्रकार एलआईजीएटीटीपीडी माॅड प्राॅक्सी रिवर्स प्रॉक्सी के रूप में कार्य कर सकता है, और वेब साॅकेट एप्लिकेशन के लोड बैलेंसर के रूप में कार्य कर सकता है। इस प्रकार एलआईजीएटीटीपीडी mod_wstunnel बैकएंड एप्लिकेशन के लिए जेसाॅन प्रारूप सहित डेटा संचारित करने के लिए वेब साॅकेट टनल का निर्माण कर सकता है।

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

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

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

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

आरएफसी6455 के लिए आवश्यक है कि कुंजी के भिन्न तरीकों से चयनित 16-बाइट मान से युक्त होनी चाहिए जो बेस 64-एन्कोडेड है, वह बेस 64 में 24 बाइट्स है, जोअंतिम दो बाइट्स होने के साथ  उपयोग की जाती हैं, चूंकि इस प्रकार एटीटीपी सर्वर स्माल की को प्रस्तुत करने की अनुमति देते हैं, कई आधुनिक एटीटीपी सर्वर अमान्य   शीर्षलेख त्रुटि के साथ अनुरोध को अस्वीकार कर देंगे।

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


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

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


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


 * मास्क
 * यदि पेलोड डेटा छिपा हुआ है तो 1 पर सेट करें।
 * 1b


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


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


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


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

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

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

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

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

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

यदि अनएन्क्रिप्टेड वेब साॅकेट ट्रैफ़िक वेब साॅकेट समर्थन के बिना स्पष्ट या पारदर्शी प्रॉक्सी सर्वर के माध्यम से प्रवाहित होता है, तो कनेक्शन विफल हो जाएगा।

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

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

यह भी देखें

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

बाहरी संबंध

 * आईईटीएफ Hypertext-Bidirectional (HyBi) working group
 * The वेब साॅकेट protocol - Proposed Standard published by the आईईटीएफ HyBi Working Group
 * The वेब साॅकेट protocol - Internet-Draft published by the आईईटीएफ HyBi Working Group
 * The वेब साॅकेट protocol - Original protocol proposal by Ian Hickson
 * The वेब साॅकेट एपीआई - W3C Working Draft specification of the एपीआई
 * The वेब साॅकेट एपीआई - W3C Candidate Recommendation specification of the एपीआई
 * वेब साॅकेट.org वेब साॅकेट demos, loopback tests, general information and community