वेबसॉकेट: Difference between revisions

From Vigyanwiki
No edit summary
No edit summary
 
(3 intermediate revisions by 3 users not shown)
Line 15: Line 15:
}}
}}


WebSocket कंप्यूटर [[संचार प्रोटोकॉल]] है, जो एकल [[ प्रसारण नियंत्रण प्रोटोकॉल |प्रसारण नियंत्रण प्रोटोकॉल]] कनेक्शन पर पूर्ण-द्वैध संचार चैनल प्रदान करता है। WebSocket प्रोटोकॉल को [[इंटरनेट इंजीनियरिंग टास्क फोर्स]] द्वारा मानकीकृत किया गया था {{IETF RFC|6455}} 2011 में। वेब अनुप्रयोगों को इस प्रोटोकॉल का उपयोग करने की अनुमति देने वाले वर्तमान API विनिर्देश को WebSockets के रूप में जाना जाता है।<ref>{{Cite web |title=वेबसॉकेट मानक|url=https://websockets.spec.whatwg.org/ |access-date=2022-05-16 |website=websockets.spec.whatwg.org}}</ref> यह [[वेब हाइपरटेक्स्ट एप्लिकेशन टेक्नोलॉजी वर्किंग ग्रुप]] द्वारा बनाए रखा गया जीवन स्तर है और [[ विश्वव्यापी वेब संकाय |विश्वव्यापी वेब संकाय]] से वेबसॉकेट एपीआई का उत्तराधिकारी है।<ref>{{Cite web |title=वेबसाकेट एपीआई|url=https://www.w3.org/TR/2021/NOTE-websockets-20210128/Overview.html |access-date=2022-05-16 |website=www.w3.org |language=en}}</ref>
'''वेब साॅकेट''' मुख्य रूप से कंप्यूटर [[संचार प्रोटोकॉल]] है, जो एकल [[ प्रसारण नियंत्रण प्रोटोकॉल |प्रसारण नियंत्रण प्रोटोकॉल]] कनेक्शन पर पूर्ण रूप से द्वैध संचार चैनल प्रदान करने में सहायक है। इस प्रकार वेब साॅकेट प्रोटोकॉल को [[इंटरनेट इंजीनियरिंग टास्क फोर्स]] द्वारा {{IETF RFC|6455}} 2011 में मानकीकृत किया गया था। इस प्रकार वेब अनुप्रयोगों को इस प्रोटोकॉल का उपयोग करने की अनुमति देने वाले वर्तमान समय में एपीआई विनिर्देश को वेब साॅकेट के रूप में जाना जाता है।<ref>{{Cite web |title=वेबसॉकेट मानक|url=https://websockets.spec.whatwg.org/ |access-date=2022-05-16 |website=websockets.spec.whatwg.org}}</ref> यह [[वेब हाइपरटेक्स्ट एप्लिकेशन टेक्नोलॉजी वर्किंग ग्रुप]] द्वारा बनाए रखा गया जीवन स्तर है और [[ विश्वव्यापी वेब संकाय |विश्वव्यापी वेब संकाय]] से वेबसॉकेट एपीआई का उत्तराधिकारी है।<ref>{{Cite web |title=वेबसाकेट एपीआई|url=https://www.w3.org/TR/2021/NOTE-websockets-20210128/Overview.html |access-date=2022-05-16 |website=www.w3.org |language=en}}</ref>
वेबसॉकेट [[ हाइपरटेक्स्ट परहस्त शिष्टाचार |हाइपरटेक्स्ट परहस्त शिष्टाचार]] से अलग है। दोनों प्रोटोकॉल OSI मॉडल में परत 7 पर स्थित हैं और परत 4 पर टीसीपी पर निर्भर हैं। हालांकि वे अलग हैं, {{IETF RFC|6455}} बताता है कि WebSocket को HTTP पोर्ट 443 और 80 पर काम करने के साथ-साथ HTTP प्रॉक्सी और बिचौलियों का समर्थन करने के लिए डिज़ाइन किया गया है, इस प्रकार यह HTTP के साथ संगत बनाता है। संगतता प्राप्त करने के लिए, वेबसाकेट [[ हाथ मिलाना (कंप्यूटिंग) |हाथ मिलाना (कंप्यूटिंग)]] HTTP/1.1 अपग्रेड शीर्षलेख का उपयोग करता है<ref>{{Cite IETF |title=RFC 6455 The WebSocket Protocol |publisher = [[Internet Engineering Task Force|IETF]] |section=1.7 |sectionname=Relationship to TCP and HTTP |rfc=6455 |date=December 2011|author1=Ian Fette |author2=Alexey Melnikov}}</ref> HTTP प्रोटोकॉल से WebSocket प्रोटोकॉल में बदलने के लिए।


WebSocket प्रोटोकॉल [[वेब ब्राउज़र]] (या अन्य [[क्लाइंट (कंप्यूटिंग)]] एप्लिकेशन) और HTTP [[ मतदान (कंप्यूटर विज्ञान) |मतदान (कंप्यूटर विज्ञान)]] जैसे आधे-द्वैध विकल्पों की तुलना में कम ओवरहेड वाले [[वेब सर्वर]] के बीच बातचीत को सक्षम बनाता है, जिससे सर्वर से और सर्वर पर रीयल-टाइम डेटा ट्रांसफर की सुविधा मिलती है। . क्लाइंट द्वारा पहले अनुरोध किए बिना क्लाइंट को सामग्री भेजने के लिए सर्वर के लिए मानकीकृत तरीका प्रदान करके और कनेक्शन को खुला रखते हुए संदेशों को आगे और पीछे भेजने की अनुमति देकर इसे संभव बनाया गया है। इस तरह, क्लाइंट और सर्वर के बीच दो तरफा बातचीत हो सकती है। संचार आमतौर पर टीसीपी [[पोर्ट (कंप्यूटर नेटवर्किंग)]] संख्या 443 (या असुरक्षित कनेक्शन के मामले में 80) पर किया जाता है, जो उन वातावरणों के लिए फायदेमंद है जो [[फ़ायरवॉल (कंप्यूटिंग)]] का उपयोग करके गैर-वेब इंटरनेट कनेक्शन को ब्लॉक करते हैं। [[ धूमकेतु (प्रोग्रामिंग) |धूमकेतु (प्रोग्रामिंग)]] या [[एडोब फ्लैश प्लेयर]] जैसी स्टॉपगैप तकनीकों का उपयोग करके गैर-मानकीकृत तरीकों से इसी तरह के दो-तरफ़ा ब्राउज़र-सर्वर संचार प्राप्त किए गए हैं।<ref>{{Cite web |title=Adobe Flash Platform – Sockets |url=https://help.adobe.com/en_US/as3/dev/WSb2ba3b1aad8a27b0-181c51321220efd9d1c-8000.html |url-status=live |access-date=2021-07-28 |website=help.adobe.com |quote=TCP connections require a “client” and a “server”. Flash Player can create client sockets.}}</ref>
वेबसॉकेट [[ हाइपरटेक्स्ट परहस्त शिष्टाचार |हाइपरटेक्स्ट]] से अलग है। इसमें दोनों प्रोटोकॉल ओएसआई मॉडल में परत 7 पर स्थित हैं और परत 4 पर टीसीपी पर निर्भर हैं। चूंकि वे अलग हैं, {{IETF RFC|6455}} बताता है कि वेब साॅकेट को एटीटीपी पोर्ट 443 और 80 पर काम करने के साथ-साथ एटीटीपी प्रॉक्सी और बिचौलियों का समर्थन करने के लिए डिज़ाइन किया गया है, इस प्रकार यह एटीटीपी के साथ संगत बनाता है। इस प्रकार संगतता प्राप्त करने के लिए, वेबसाकेट [[ हाथ मिलाना (कंप्यूटिंग) |हाथ मिलाना (कंप्यूटिंग)]] एटीटीपी/1.1 अपग्रेड शीर्षलेख का उपयोग करता है<ref>{{Cite IETF |title=RFC 6455 The WebSocket Protocol |publisher = [[Internet Engineering Task Force|IETF]] |section=1.7 |sectionname=Relationship to TCP and HTTP |rfc=6455 |date=December 2011|author1=Ian Fette |author2=Alexey Melnikov}}</ref> एटीटीपी प्रोटोकॉल से वेब साॅकेट प्रोटोकॉल में परिवर्तित करने के लिए सहायक हैं।
अधिकांश ब्राउज़र प्रोटोकॉल का समर्थन करते हैं, जिनमें [[Google Chrome]], [[Firefox]], [[Microsoft Edge]], [[Internet Explorer]], Safari (वेब ​​ब्राउज़र) और [[ओपेरा वेब ब्राउज़र]] शामिल हैं।<ref>{{Cite web |date=2023-04-06 |title=वेबसाकेट एपीआई (वेबसॉकेट)|url=https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API |url-status=live |archive-url=https://web.archive.org/web/20210728161324/https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API |archive-date=2021-07-28 |access-date=2021-07-26 |website=MDN Web Docs |publisher=Mozilla Developer Network |language=en-US}}</ref>
HTTP के विपरीत, WebSocket पूर्ण-द्वैध संचार प्रदान करता है।<ref>{{cite web |url=https://developer.mozilla.org/en-US/docs/Glossary/WebSockets |publisher=Mozilla Developer Network |date=2015 |title=Glossary: WebSockets}}</ref><ref name=quantum>{{Cite web |url=http://www.websocket.org/quantum.html |title=HTML5 WebSocket – A Quantum Leap in Scalability for the Web |website=www.websocket.org |access-date=2016-01-08 |archive-date=2021-04-01 |archive-url=https://web.archive.org/web/20210401044556/http://www.websocket.org/quantum.html |url-status=dead }}</ref>
इसके अतिरिक्त, WebSocket TCP के शीर्ष पर संदेशों की स्ट्रीम सक्षम करता है। टीसीपी अकेले बाइट्स की धाराओं से संबंधित है जिसमें संदेश की कोई अंतर्निहित अवधारणा नहीं है। WebSocket से पहले, धूमकेतु (प्रोग्रामिंग) चैनलों का उपयोग करके पोर्ट 80 पूर्ण-द्वैध संचार प्राप्य था; हालांकि, धूमकेतु का कार्यान्वयन गैर-तुच्छ है, और टीसीपी हैंडशेक और एचटीटीपी हेडर ओवरहेड के कारण, यह छोटे संदेशों के लिए अक्षम है। WebSocket प्रोटोकॉल का उद्देश्य वेब की सुरक्षा धारणाओं से समझौता किए बिना इन समस्याओं को हल करना है।


WebSocket प्रोटोकॉल विनिर्देश परिभाषित करता है <code>ws</code> (वेबसॉकेट) और <code>wss</code> (वेबसॉकेट सिक्योर) दो नई समान संसाधन पहचानकर्ता (यूआरआई) योजनाओं के रूप में<ref>{{cite web |url=https://www.iana.org/assignments/uri-schemes.html |title=IANA यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर (URI) योजनाएँ|publisher=[[Internet Assigned Numbers Authority]] |date=2011-11-14 |access-date=2011-12-10 |editor=Graham Klyne}}</ref> जिनका उपयोग क्रमशः अनएन्क्रिप्टेड और एन्क्रिप्टेड कनेक्शन के लिए किया जाता है। इसके अलावा योजना का नाम और [[टुकड़ा पहचानकर्ता]] (यानी। <code>#</code> समर्थित नहीं है), शेष यूआरआई घटकों को [[पथ खंड]] का उपयोग करने के लिए परिभाषित किया गया है।<ref>{{Cite IETF |title=RFC 6455 The WebSocket Protocol |publisher=[[Internet Engineering Task Force|IETF]] |section=3 |sectionname=WebSocket URIs |rfc=6455 |date=December 2011 |author1=Ian Fette |author2=Alexey Melnikov}}</ref>
वेब साॅकेट प्रोटोकॉल [[वेब ब्राउज़र]] (या अन्य [[क्लाइंट (कंप्यूटिंग)]] एप्लिकेशन) और एटीटीपी [[ मतदान (कंप्यूटर विज्ञान) |पोलिंग (कंप्यूटर विज्ञान)]] जैसे आधे-द्वैध विकल्पों की तुलना में कम ओवरहेड वाले [[वेब सर्वर]] के बीच बातचीत को सक्षम बनाता है, जिससे सर्वर से और सर्वर पर रीयल-टाइम डेटा ट्रांसफर की सुविधा मिलती है। इस प्रकार क्लाइंट द्वारा पहले अनुरोध किए बिना क्लाइंट को सामग्री भेजने के लिए सर्वर के लिए मानकीकृत तरीका प्रदान करके और कनेक्शन को ओपेन रखते हुए संदेशों को आगे और पीछे भेजने की अनुमति देकर इसे संभव बनाया गया है। इस प्रकार क्लाइंट और सर्वर के बीच दोनो दिशाओं से संचरण हो सकता है। इस प्रकार संचार सामान्यतः टीसीपी [[पोर्ट (कंप्यूटर नेटवर्किंग)]] संख्या 443 (या असुरक्षित कनेक्शन की स्थिति में 80) पर किया जाता है, जो उन वातावरणों के लिए लाभप्रद है जो [[फ़ायरवॉल (कंप्यूटिंग)]] का उपयोग करके गैर-वेब इंटरनेट कनेक्शन को ब्लॉक करते हैं। [[ धूमकेतु (प्रोग्रामिंग) |काॅमेड (प्रोग्रामिंग)]] या [[एडोब फ्लैश प्लेयर]] जैसी स्टॉपगैप तकनीकों का उपयोग करके गैर-मानकीकृत तरीकों से इसी तरह के दो-तरफ़ा ब्राउज़र-सर्वर संचार प्राप्त किए गए हैं।<ref>{{Cite web |title=Adobe Flash Platform – Sockets |url=https://help.adobe.com/en_US/as3/dev/WSb2ba3b1aad8a27b0-181c51321220efd9d1c-8000.html |url-status=live |access-date=2021-07-28 |website=help.adobe.com |quote=TCP connections require a “client” and a “server”. Flash Player can create client sockets.}}</ref>
ब्राउज़र डेवलपर टूल का उपयोग करके, डेवलपर WebSocket हैंडशेक के साथ-साथ WebSocket फ़्रेम का निरीक्षण कर सकते हैं।<ref>{{cite book |last1=Wang |first1=Vanessa |last2=Salim |first2=Frank |last3=Moskovits |first3=Peter |title=The Definitive Guide to HTML5 WebSocket |chapter-url=http://my.safaribooksonline.com/book/-/9781430247401/appendix-a-inspecting-websocket-traffic/sec1_xhtml |access-date=7 April 2013 |date=February 2013 |publisher=Apress |isbn=978-1-4302-4740-1 |chapter=APPENDIX A: WebSocket Frame Inspection with Google Chrome Developer Tools |archive-date=31 December 2015 |archive-url=https://web.archive.org/web/20151231184436/http://my.safaribooksonline.com/book/-/9781430247401/appendix-a-inspecting-websocket-traffic/sec1_xhtml |url-status=dead }}</ref>
 
अधिकांश ब्राउज़र प्रोटोकॉल का समर्थन करते हैं, जिनमें [[Google Chrome|गूगल क्रोम]], [[Firefox|फायर फाॅक्स]], [[Microsoft Edge|माइक्रोसाॅफ्ट एज]], [[Internet Explorer|इंटरनेट एक्सप्लोरर]], सफारी (वेब ​​ब्राउज़र) और [[ओपेरा वेब ब्राउज़र]] सम्मिलित हैं।<ref>{{Cite web |date=2023-04-06 |title=वेबसाकेट एपीआई (वेबसॉकेट)|url=https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API |url-status=live |archive-url=https://web.archive.org/web/20210728161324/https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API |archive-date=2021-07-28 |access-date=2021-07-26 |website=MDN Web Docs |publisher=Mozilla Developer Network |language=en-US}}</ref> एटीटीपी के विपरीत, वेब साॅकेट पूर्ण-द्वैध संचार प्रदान करता है।<ref>{{cite web |url=https://developer.mozilla.org/en-US/docs/Glossary/WebSockets |publisher=Mozilla Developer Network |date=2015 |title=Glossary: WebSockets}}</ref><ref name="quantum">{{Cite web |url=http://www.websocket.org/quantum.html |title=HTML5 WebSocket – A Quantum Leap in Scalability for the Web |website=www.websocket.org |access-date=2016-01-08 |archive-date=2021-04-01 |archive-url=https://web.archive.org/web/20210401044556/http://www.websocket.org/quantum.html |url-status=dead }}</ref> इसके अतिरिक्त, वेब साॅकेट TCP के शीर्ष पर संदेशों की स्ट्रीम सक्षम करता है। टीसीपी अकेले बाइट्स की धाराओं से संबंधित है जिसमें संदेश की कोई अंतर्निहित अवधारणा नहीं है। इस प्रकार वेब साॅकेट से पहले, काॅमेड (प्रोग्रामिंग) चैनलों का उपयोग करके पोर्ट 80 पूर्ण-द्वैध संचार प्राप्य था, चूंकि, काॅमेड का कार्यान्वयन गैर-तुच्छ है, और टीसीपी हैंडशेक और एचटीटीपी हेडर ओवरहेड के कारण, यह छोटे संदेशों के लिए अक्षम है। वेब साॅकेट प्रोटोकॉल का उद्देश्य वेब की सुरक्षा धारणाओं से समझौता किए बिना इन समस्याओं को हल करना है।
 
वेब साॅकेट प्रोटोकॉल विनिर्देश परिभाषित करता है <code>ws</code> (वेबसॉकेट) और <code>wss</code> (वेबसॉकेट सिक्योर) दो नई समान संसाधन पहचानकर्ता (यूआरआई) योजनाओं के रूप में किया गया था,<ref>{{cite web |url=https://www.iana.org/assignments/uri-schemes.html |title=IANA यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर (URI) योजनाएँ|publisher=[[Internet Assigned Numbers Authority]] |date=2011-11-14 |access-date=2011-12-10 |editor=Graham Klyne}}</ref> जिनका उपयोग क्रमशः अनएन्क्रिप्टेड और एन्क्रिप्टेड कनेक्शन के लिए किया जाता है। इसके अतिरिक्त योजना का नाम और [[टुकड़ा पहचानकर्ता]] (अर्ताथ <code>#</code> समर्थित नहीं है), इस प्रकार शेष यूआरआई घटकों को [[पथ खंड]] का उपयोग करने के लिए परिभाषित किया गया है।<ref>{{Cite IETF |title=RFC 6455 The WebSocket Protocol |publisher=[[Internet Engineering Task Force|IETF]] |section=3 |sectionname=WebSocket URIs |rfc=6455 |date=December 2011 |author1=Ian Fette |author2=Alexey Melnikov}}</ref> ब्राउज़र डेवलपर टूल का उपयोग करके, डेवलपर वेब साॅकेट हैंडशेक के साथ-साथ वेब साॅकेट फ़्रेम का निरीक्षण कर सकते हैं।<ref>{{cite book |last1=Wang |first1=Vanessa |last2=Salim |first2=Frank |last3=Moskovits |first3=Peter |title=The Definitive Guide to HTML5 WebSocket |chapter-url=http://my.safaribooksonline.com/book/-/9781430247401/appendix-a-inspecting-websocket-traffic/sec1_xhtml |access-date=7 April 2013 |date=February 2013 |publisher=Apress |isbn=978-1-4302-4740-1 |chapter=APPENDIX A: WebSocket Frame Inspection with Google Chrome Developer Tools |archive-date=31 December 2015 |archive-url=https://web.archive.org/web/20151231184436/http://my.safaribooksonline.com/book/-/9781430247401/appendix-a-inspecting-websocket-traffic/sec1_xhtml |url-status=dead }}</ref>
== इतिहास ==
== इतिहास ==
टीसीपी-आधारित सॉकेट एपीआई के लिए प्लेसहोल्डर के रूप में [[आप ऊब जाएंगे]] 5 विनिर्देश में वेबसाकेट को पहली बार टीसीपी कनेक्शन के रूप में संदर्भित किया गया था।<ref>{{Cite web|url=https://www.w3.org/TR/2008/WD-html5-20080610/comms.html#tcp-connections|title=HTML 5|website=www.w3.org|access-date=2016-04-17}}</ref> जून 2008 में, [[माइकल कार्टर (उद्यमी)]] द्वारा चर्चाओं की श्रृंखला का नेतृत्व किया गया, जिसके परिणामस्वरूप प्रोटोकॉल का पहला संस्करण वेबसॉकेट के रूप में जाना गया।<ref>{{Cite web|url=https://lists.w3.org/Archives/Public/public-whatwg-archive/2008Jun/0165.html|title=[whatwg] TCPConnection feedback from Michael Carter on 2008-06-18 (whatwg.org from June 2008)|website=lists.w3.org|access-date=2016-04-17}}</ref>
टीसीपी पर आधारित सॉकेट एपीआई के लिए प्लेसहोल्डर के रूप में [[आप ऊब जाएंगे]] 5 विनिर्देश में वेबसाकेट को पहली बार टीसीपी कनेक्शन के रूप में संदर्भित किया गया था।<ref>{{Cite web|url=https://www.w3.org/TR/2008/WD-html5-20080610/comms.html#tcp-connections|title=HTML 5|website=www.w3.org|access-date=2016-04-17}}</ref> इसके कारण जून 2008 में, [[माइकल कार्टर (उद्यमी)]] द्वारा चर्चाओं की श्रृंखला का नेतृत्व किया गया, जिसके परिणामस्वरूप प्रोटोकॉल का पहला संस्करण वेबसॉकेट के रूप में जाना गया।<ref>{{Cite web|url=https://lists.w3.org/Archives/Public/public-whatwg-archive/2008Jun/0165.html|title=[whatwg] TCPConnection feedback from Michael Carter on 2008-06-18 (whatwg.org from June 2008)|website=lists.w3.org|access-date=2016-04-17}}</ref> इस प्रकार वेब साॅकेट नाम [[इयान हिकसन]] और माइकल कार्टर द्वारा शीघ्र ही वाट डब्ल्यूजी आईआरसी चैट रूम पर सहयोग के माध्यम से उत्पन्न किया गया था,<ref>{{Cite web|url=http://krijnhoetmer.nl/irc-logs/whatwg/20080618#l-1145|title=IRC logs: freenode / #whatwg / 20080618|website=krijnhoetmer.nl|access-date=2016-04-18}}</ref> और बाद में इयान हिकसन द्वारा एचटीएमएल5 विनिर्देशन में सम्मिलित करने के लिए लिखा गया। दिसंबर 2009 में, गूगल क्रोम 4 मानक के लिए पूर्ण समर्थन देने वाला पहला ब्राउज़र था, जिसमें डिफ़ॉल्ट रूप से वेब साॅकेट सक्षम था।<ref>{{Cite web|url=https://blog.chromium.org/2009/12/web-sockets-now-available-in-google.html|title=वेब सॉकेट अब गूगल क्रोम में उपलब्ध है|website=Chromium Blog|language=en-US|access-date=2016-04-17}}</ref> इस प्रकार वेब साॅकेट प्रोटोकॉल का विकास बाद में W3C और [[WHATWG|वाट डब्ल्यूजी]] समूह से फरवरी 2010 में आईईटीएफ में स्थानांतरित कर दिया गया था, और इयान हिकसन के अनुसार दो संशोधनों के लिए तैयार किया गया था।<ref>{{Cite journal|url=https://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-75|title=वेबसॉकेट प्रोटोकॉल|last=<ian@hixie.ch>|first=Ian Hickson|newspaper=Ietf Datatracker|date=6 May 2010|access-date=2016-04-17}}</ref>
WebSocket नाम [[इयान हिकसन]] और माइकल कार्टर द्वारा शीघ्र ही #whatwg IRC चैट रूम पर सहयोग के माध्यम से गढ़ा गया था,<ref>{{Cite web|url=http://krijnhoetmer.nl/irc-logs/whatwg/20080618#l-1145|title=IRC logs: freenode / #whatwg / 20080618|website=krijnhoetmer.nl|access-date=2016-04-18}}</ref> और बाद में इयान हिकसन द्वारा HTML5 विनिर्देशन में शामिल करने के लिए लिखा गया। दिसंबर 2009 में, Google Chrome 4 मानक के लिए पूर्ण समर्थन देने वाला पहला ब्राउज़र था, जिसमें डिफ़ॉल्ट रूप से WebSocket सक्षम था।<ref>{{Cite web|url=https://blog.chromium.org/2009/12/web-sockets-now-available-in-google.html|title=वेब सॉकेट अब गूगल क्रोम में उपलब्ध है|website=Chromium Blog|language=en-US|access-date=2016-04-17}}</ref> WebSocket प्रोटोकॉल का विकास बाद में W3C और [[WHATWG]] समूह से फरवरी 2010 में IETF में स्थानांतरित कर दिया गया था, और इयान हिकसन के तहत दो संशोधनों के लिए तैयार किया गया था।<ref>{{Cite journal|url=https://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-75|title=वेबसॉकेट प्रोटोकॉल|last=<ian@hixie.ch>|first=Ian Hickson|newspaper=Ietf Datatracker|date=6 May 2010|access-date=2016-04-17}}</ref>
 
प्रोटोकॉल को कई ब्राउज़रों में डिफॉल्ट रूप से शिप और सक्षम करने के बाद, {{IETF RFC|6455}} को दिसंबर 2011 में इयान फेट के तहत अंतिम रूप दिया गया था।
इस प्रकार प्रोटोकॉल को कई ब्राउज़रों में डिफॉल्ट रूप से शिप और सक्षम करने के पश्चात {{IETF RFC|6455}} को दिसंबर 2011 में इयान फेट के अनुसार अंतिम रूप दिया गया था।


{{IETF RFC|7692}} ने प्रति-संदेश के आधार पर [[DEFLATE]] एल्गोरिथम का उपयोग करके WebSocket के लिए कंप्रेशन एक्सटेंशन पेश किया।
{{IETF RFC|7692}} ने प्रति-संदेश के आधार पर [[DEFLATE|डेफलेट]] एल्गोरिथम का उपयोग करके वेब साॅकेट के लिए कंप्रेशन एक्सटेंशन प्रस्तुत किया था।


== ब्राउज़र कार्यान्वयन ==
== ब्राउज़र कार्यान्वयन ==
WebSocket प्रोटोकॉल का सुरक्षित संस्करण Firefox 6 में लागू किया गया है,<ref>{{cite web | url=https://developer.mozilla.org/en/WebSockets | title=WebSocket enabled in Firefox 6 | author=Dirkjan Ochtman | date=May 27, 2011 | work=Mozilla.org | access-date=2011-06-30 | archive-date=2012-05-26 | archive-url=https://web.archive.org/web/20120526230019/https://developer.mozilla.org/en/WebSockets | url-status=dead }}</ref> सफारी 6, गूगल क्रोम 14,<ref>{{cite web | url=https://www.chromium.org/developers/web-platform-status | title=क्रोमियम वेब प्लेटफ़ॉर्म स्थिति| access-date=2011-08-03 }}</ref> ओपेरा (वेब ​​​​ब्राउज़र) 12.10 और इंटरनेट एक्सप्लोरर 10।<ref>{{cite web|url=https://msdn.microsoft.com/en-us/library/ie/hh673567(v=vs.85).aspx |title=वेबसाकेट (विंडोज़)|publisher=Microsoft |date=2012-09-28 |access-date=2012-11-07}}</ref> विस्तृत प्रोटोकॉल टेस्ट सूट रिपोर्ट<ref name="autobahn">{{cite web |url=http://autobahn.ws/testsuite/reports/clients/index.html |title=वेबसॉकेट प्रोटोकॉल टेस्ट रिपोर्ट|publisher=Tavendo.de |date=2011-10-27 |access-date=2011-12-10 |archive-date=2016-09-22 |archive-url=https://web.archive.org/web/20160922040928/http://autobahn.ws/testsuite/reports/clients/index.html |url-status=dead }}</ref> विशिष्ट प्रोटोकॉल पहलुओं के लिए उन ब्राउज़रों की अनुरूपता सूचीबद्ध करता है।
वेब साॅकेट प्रोटोकॉल का सुरक्षित संस्करण फायर फाॅक्स 6 में लागू किया गया है,<ref>{{cite web | url=https://developer.mozilla.org/en/WebSockets | title=WebSocket enabled in Firefox 6 | author=Dirkjan Ochtman | date=May 27, 2011 | work=Mozilla.org | access-date=2011-06-30 | archive-date=2012-05-26 | archive-url=https://web.archive.org/web/20120526230019/https://developer.mozilla.org/en/WebSockets | url-status=dead }}</ref> जिसमें सफारी 6, गूगल क्रोम 14,<ref>{{cite web | url=https://www.chromium.org/developers/web-platform-status | title=क्रोमियम वेब प्लेटफ़ॉर्म स्थिति| access-date=2011-08-03 }}</ref> ओपेरा (वेब ​​​​ब्राउज़र) 12.10 और इंटरनेट एक्सप्लोरर 10।<ref>{{cite web|url=https://msdn.microsoft.com/en-us/library/ie/hh673567(v=vs.85).aspx |title=वेबसाकेट (विंडोज़)|publisher=Microsoft |date=2012-09-28 |access-date=2012-11-07}}</ref> विस्तृत प्रोटोकॉल टेस्ट सूट रिपोर्ट<ref name="autobahn">{{cite web |url=http://autobahn.ws/testsuite/reports/clients/index.html |title=वेबसॉकेट प्रोटोकॉल टेस्ट रिपोर्ट|publisher=Tavendo.de |date=2011-10-27 |access-date=2011-12-10 |archive-date=2016-09-22 |archive-url=https://web.archive.org/web/20160922040928/http://autobahn.ws/testsuite/reports/clients/index.html |url-status=dead }}</ref> विशिष्ट प्रोटोकॉल पहलुओं के लिए उन ब्राउज़रों की अनुरूपता सूचीबद्ध करता है।


प्रोटोकॉल का पुराना, कम सुरक्षित संस्करण ओपेरा 11 और सफारी (वेब ​​​​ब्राउज़र) 5 के साथ-साथ आईओएस 4.2 में सफारी के मोबाइल संस्करण में लागू किया गया था।<ref>{{cite web | url=https://www.appleinsider.com/articles/10/11/23/apple_adds_accelerometer_websockets_support_to_safari_in_ios_4_2.html | title=Apple adds accelerometer, WebSockets support to Safari in iOS 4.2 | author=Katie Marsal | date=November 23, 2010 | work=AppleInsider.com | access-date=2011-05-09 }}</ref> OS7 में BlackBerry Browser WebSockets को लागू करता है।<ref>{{cite web|title=वेब सॉकेट एपीआई|url=http://docs.blackberry.com/en/developers/deliverables/29271/Web_Sockets_support_1582781_11.jsp |publisher=[[BlackBerry Limited|BlackBerry]] |access-date=8 July 2011 |url-status=dead |archive-url=https://web.archive.org/web/20110610191150/http://docs.blackberry.com/en/developers/deliverables/29271/Web_Sockets_support_1582781_11.jsp |archive-date=June 10, 2011 }}</ref> भेद्यता के कारण, इसे Firefox 4 और 5 में अक्षम कर दिया गया था,<ref>{{cite web | url=https://hacks.mozilla.org/2010/12/websockets-disabled-in-firefox-4/ | title=WebSocket disabled in Firefox 4 | author=Chris Heilmann | date=December 8, 2010 | work=Hacks.Mozilla.org | access-date=2011-05-09 }}</ref> और ओपेरा 11।<ref>{{cite web | url=http://my.opera.com/chooseopera/blog/2010/12/10/regarding-websocket | title=वेबसॉकेट के संबंध में| author=Aleksander Aas | date=December 10, 2010 | work=My Opera Blog | access-date=2011-05-09 |archive-url=https://web.archive.org/web/20101215010748/http://my.opera.com/chooseopera/blog/2010/12/10/regarding-websocket|archive-date=2010-12-15}}</ref>
प्रोटोकॉल का पुराना, कम सुरक्षित संस्करण ओपेरा 11 और सफारी (वेब ​​​​ब्राउज़र) 5 के साथ-साथ आईओएस 4.2 में सफारी के मोबाइल संस्करण में लागू किया गया था।<ref>{{cite web | url=https://www.appleinsider.com/articles/10/11/23/apple_adds_accelerometer_websockets_support_to_safari_in_ios_4_2.html | title=Apple adds accelerometer, WebSockets support to Safari in iOS 4.2 | author=Katie Marsal | date=November 23, 2010 | work=AppleInsider.com | access-date=2011-05-09 }}</ref> OS7 में ब्लैकबेरी ब्राउज़र वेब साॅकेट को लागू करता है।<ref>{{cite web|title=वेब सॉकेट एपीआई|url=http://docs.blackberry.com/en/developers/deliverables/29271/Web_Sockets_support_1582781_11.jsp |publisher=[[BlackBerry Limited|BlackBerry]] |access-date=8 July 2011 |url-status=dead |archive-url=https://web.archive.org/web/20110610191150/http://docs.blackberry.com/en/developers/deliverables/29271/Web_Sockets_support_1582781_11.jsp |archive-date=June 10, 2011 }}</ref> इसकी भेद्यता के कारण, इसे फायर फाॅक्स और ओपेरा 11 को 4 और 5 में अक्षम कर दिया गया था।<ref>{{cite web | url=https://hacks.mozilla.org/2010/12/websockets-disabled-in-firefox-4/ | title=WebSocket disabled in Firefox 4 | author=Chris Heilmann | date=December 8, 2010 | work=Hacks.Mozilla.org | access-date=2011-05-09 }}</ref><ref>{{cite web | url=http://my.opera.com/chooseopera/blog/2010/12/10/regarding-websocket | title=वेबसॉकेट के संबंध में| author=Aleksander Aas | date=December 10, 2010 | work=My Opera Blog | access-date=2011-05-09 |archive-url=https://web.archive.org/web/20101215010748/http://my.opera.com/chooseopera/blog/2010/12/10/regarding-websocket|archive-date=2010-12-15}}</ref>


{| class="wikitable"
{| class="wikitable"
|+ Implementation status
|+ Implementation status
! Protocol, version
! प्रोटोकाॅल संस्करण
! Draft date
! ड्राफ्टिंग दिनांक
! Internet Explorer
! इंटरनेट एक्सप्लोरर
! Firefox<ref>{{cite web |url=https://developer.mozilla.org/en/WebSockets |title=WebSockets (support in Firefox) |publisher=Mozilla Foundation |website=developer.mozilla.org |date=2011-09-30 |access-date=2011-12-10 |archive-date=2012-05-26 |archive-url=https://web.archive.org/web/20120526230019/https://developer.mozilla.org/en/WebSockets |url-status=dead }}</ref> (PC)
! फायर फाॅक्स<ref>{{cite web |url=https://developer.mozilla.org/en/WebSockets |title=WebSockets (support in Firefox) |publisher=Mozilla Foundation |website=developer.mozilla.org |date=2011-09-30 |access-date=2011-12-10 |archive-date=2012-05-26 |archive-url=https://web.archive.org/web/20120526230019/https://developer.mozilla.org/en/WebSockets |url-status=dead }}</ref> (पीसी)
! Firefox (Android)
! फायर फाॅक्स (एंड्रॉइड)
! Chrome (PC, Mobile)
! क्रोम (पीसी, मोबाइल)
! Safari (Mac, iOS)
! सफारी
! Opera (PC, Mobile)
(मैक, आईओएस)
! Android Browser
! ओपेरा (पीसी, मोबाइल)
! एंड्रॉइड ब्राउज़र
|-
|-
! [https://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-75 hixie-75]
! [https://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-75 hixie-75]
| February 4, 2010
| फरवरी 4, 2010
|
|
|
|
Line 60: Line 60:
|-
|-
! [https://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-76 hixie-76]<br />[https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-00 hybi-00]
! [https://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-76 hixie-76]<br />[https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-00 hybi-00]
| May 6, 2010<br />May 23, 2010
| मई 6, 2010<br />मई 23, 2010
|
|
| 4.0 (disabled)
| 4.0 (निर्योग्य)
|
|
| 6
| 6
| 5.0.1
| 5.0.1
| 11.00 (disabled)
| 11.00 (निर्योग्य)
|
|
|-
|-
! [https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-07 hybi-07], v7
! [https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-07 hybi-07], v7
| April 22, 2011
| अप्रैलl 22, 2011
|
|
| 6<ref>{{cite web|url=https://bugzilla.mozilla.org/show_bug.cgi?id=640003 |title=Bug 640003 - WebSockets - upgrade to ietf-06 |publisher=Mozilla Foundation |date=2011-03-08 |access-date=2011-12-10}}</ref>{{Efn|name="mozwebsocket"|Gecko-based browsers versions 6–10 implement the WebSocket object as "MozWebSocket",<ref>{{cite web |url=https://developer.mozilla.org/en/WebSockets |title=WebSockets - MDN |website=developer.mozilla.org |publisher=Mozilla Foundation |date=2011-09-30 |access-date=2011-12-10 |archive-date=2012-05-26 |archive-url=https://web.archive.org/web/20120526230019/https://developer.mozilla.org/en/WebSockets |url-status=dead }}</ref> requiring extra code to integrate with existing WebSocket-enabled code.}}
| 6<ref>{{cite web|url=https://bugzilla.mozilla.org/show_bug.cgi?id=640003 |title=Bug 640003 - WebSockets - upgrade to ietf-06 |publisher=Mozilla Foundation |date=2011-03-08 |access-date=2011-12-10}}</ref>{{Efn|name="mozwebsocket"|Gecko-based browsers versions 6–10 implement the WebSocket object as "MozWebSocket",<ref>{{cite web |url=https://developer.mozilla.org/en/WebSockets |title=WebSockets - MDN |website=developer.mozilla.org |publisher=Mozilla Foundation |date=2011-09-30 |access-date=2011-12-10 |archive-date=2012-05-26 |archive-url=https://web.archive.org/web/20120526230019/https://developer.mozilla.org/en/WebSockets |url-status=dead }}</ref> requiring extra code to integrate with existing WebSocket-enabled code.}}
Line 80: Line 80:
|-
|-
! [https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10 hybi-10], v8
! [https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10 hybi-10], v8
| July 11, 2011
| जुलाई 11, 2011
|
|
| 7<ref>{{cite web|url=https://bugzilla.mozilla.org/show_bug.cgi?id=640003#c91 |title=Bug 640003 - WebSockets - upgrade to ietf-07(comment 91)|publisher=Mozilla Foundation|date=2011-07-22}}</ref>{{Efn|name="mozwebsocket"}}
| 7<ref>{{cite web|url=https://bugzilla.mozilla.org/show_bug.cgi?id=640003#c91 |title=Bug 640003 - WebSockets - upgrade to ietf-07(comment 91)|publisher=Mozilla Foundation|date=2011-07-22}}</ref>{{Efn|name="mozwebsocket"}}
Line 90: Line 90:
|-
|-
! {{IETF RFC|6455}}, v13
! {{IETF RFC|6455}}, v13
| December, 2011
| दिसम्बर, 2011
| 10<ref>{{cite web|url=https://blogs.msdn.com/b/ie/archive/2012/03/19/websockets-in-windows-consumer-preview.aspx |title=WebSockets in Windows Consumer Preview |publisher=Microsoft|work=IE Engineering Team |date=2012-03-19 |access-date=2012-07-23}}</ref>
| 10<ref>{{cite web|url=https://blogs.msdn.com/b/ie/archive/2012/03/19/websockets-in-windows-consumer-preview.aspx |title=WebSockets in Windows Consumer Preview |publisher=Microsoft|work=IE Engineering Team |date=2012-03-19 |access-date=2012-07-23}}</ref>
| 11
| 11
Line 99: Line 99:
| 4.4
| 4.4
|}
|}
== जावास्क्रिप्ट क्लाइंट उदाहरण ==
== जावास्क्रिप्ट क्लाइंट उदाहरण ==
<syntaxhighlight lang="javascript">
<syntaxhighlight lang="javascript">
Line 129: Line 127:
};
};
</syntaxhighlight>
</syntaxhighlight>
== वेब सर्वर कार्यान्वयन ==
[[Nginx|एनजीनिक्स]] ने 2013 से वेब साॅकेट का समर्थन किया है, जिसे संस्करण 1.3.13 में लागू किया गया है<ref>{{cite web |url=http://nginx.org/en/CHANGES |title=नगनेक्स में आपका स्वागत है!|website=nginx.org |access-date=3 February 2022 |archive-url=https://archive.today/20120717014311/http://nginx.org/en/CHANGES |archive-date=17 July 2012 |url-status=dead}}</ref> वेबसॉकेट अनुप्रयोगों के [[रिवर्स प्रॉक्सी]] और [[लोड संतुलन (कंप्यूटिंग)]] के रूप में कार्य करना सम्मिलित है।<ref>{{Cite web|url=https://www.nginx.com/blog/websocket-nginx/|title=वेबसाकेट प्रॉक्सी के रूप में एनजीआईएनएक्स का उपयोग करना|date=May 17, 2014|website=NGINX}}</ref> अपाची एटीटीपी सर्वर ने जुलाई, 2013 से वेब साॅकेट का समर्थन किया है, जिसे संस्करण 2.4.5 में लागू किया गया है<ref>{{Cite web|url=http://httpd.apache.org/docs/trunk/new_features_2_4.html|title=Overview of new features in Apache HTTP Server 2.4|website=Apache}}</ref><ref>{{Cite web|url=https://www.apachelounge.com/Changelog-2.4.html|title=Changelog Apache 2.4|website=Apache Lounge}}</ref> इंटरनेट सूचना सेवाओं ने संस्करण 8 में वेबसॉकेट के लिए समर्थन जोड़ा जो कि [[विंडोज सर्वर 2012]] के साथ प्रस्तुत किया गया था।<ref>{{cite web | url=https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-8/iis-80-websocket-protocol-support | title=IIS 8.0 WebSocket Protocol Support | date=28 November 2012 | work=Microsoft Docs | access-date=2020-02-18}}</ref>


 
[[lighttpd|एलआईजीएटीटीपीडी]] ने 2017 से वेब साॅकेट का समर्थन किया है, जिसे संस्करण 1.4.46 में लागू किया गया है।<ref>{{cite web | url=https://redmine.lighttpd.net/projects/lighttpd/wiki/Release-1_4_46 | title=Release-1 4 46 - Lighttpd - lighty labs }}</ref> इस प्रकार एलआईजीएटीटीपीडी माॅड प्राॅक्सी रिवर्स प्रॉक्सी के रूप में कार्य कर सकता है, और वेब साॅकेट एप्लिकेशन के लोड बैलेंसर के रूप में कार्य कर सकता है। इस प्रकार एलआईजीएटीटीपीडी mod_wstunnel बैकएंड एप्लिकेशन के लिए [[JSON|जेसाॅन]] प्रारूप सहित डेटा संचारित करने के लिए वेब साॅकेट टनल का निर्माण कर सकता है।
== वेब सर्वर कार्यान्वयन ==
[[Nginx]] ने 2013 से WebSockets का समर्थन किया है, जिसे संस्करण 1.3.13 में लागू किया गया है<ref>{{cite web |url=http://nginx.org/en/CHANGES |title=नगनेक्स में आपका स्वागत है!|website=nginx.org |access-date=3 February 2022 |archive-url=https://archive.today/20120717014311/http://nginx.org/en/CHANGES |archive-date=17 July 2012 |url-status=dead}}</ref> वेबसॉकेट अनुप्रयोगों के [[रिवर्स प्रॉक्सी]] और [[लोड संतुलन (कंप्यूटिंग)]] के रूप में कार्य करना शामिल है।<ref>{{Cite web|url=https://www.nginx.com/blog/websocket-nginx/|title=वेबसाकेट प्रॉक्सी के रूप में एनजीआईएनएक्स का उपयोग करना|date=May 17, 2014|website=NGINX}}</ref>
Apache HTTP सर्वर ने जुलाई, 2013 से WebSockets का समर्थन किया है, जिसे संस्करण 2.4.5 में लागू किया गया है<ref>{{Cite web|url=http://httpd.apache.org/docs/trunk/new_features_2_4.html|title=Overview of new features in Apache HTTP Server 2.4|website=Apache}}</ref><ref>{{Cite web|url=https://www.apachelounge.com/Changelog-2.4.html|title=Changelog Apache 2.4|website=Apache Lounge}}</ref>
इंटरनेट सूचना सेवाओं ने संस्करण 8 में वेबसॉकेट के लिए समर्थन जोड़ा जो कि [[विंडोज सर्वर 2012]] के साथ जारी किया गया था।<ref>{{cite web | url=https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-8/iis-80-websocket-protocol-support | title=IIS 8.0 WebSocket Protocol Support | date=28 November 2012 | work=Microsoft Docs | access-date=2020-02-18}}</ref>
[[lighttpd]] ने 2017 से WebSockets का समर्थन किया है, जिसे संस्करण 1.4.46 में लागू किया गया है।<ref>{{cite web | url=https://redmine.lighttpd.net/projects/lighttpd/wiki/Release-1_4_46 | title=Release-1 4 46 - Lighttpd - lighty labs }}</ref> lighttpd mod_proxy रिवर्स प्रॉक्सी के रूप में कार्य कर सकता है और WebSocket एप्लिकेशन के लोड बैलेंसर के रूप में कार्य कर सकता है। lighttpd mod_wstunnel बैकएंड एप्लिकेशन के लिए [[JSON]] प्रारूप सहित मनमाना डेटा संचारित करने के लिए WebSocket सुरंगों का निर्माण कर सकता है।


== प्रोटोकॉल ==
== प्रोटोकॉल ==


=== प्रोटोकॉल हैंडशेक ===
=== प्रोटोकॉल हैंडशेक ===
WebSocket कनेक्शन स्थापित करने के लिए, क्लाइंट WebSocket हैंडशेक अनुरोध भेजता है, जिसके लिए सर्वर WebSocket हैंडशेक प्रतिक्रिया देता है, जैसा कि नीचे दिए गए उदाहरण में दिखाया गया है।<ref>{{Cite IETF |title=RFC 6455 The WebSocket Protocol|publisher = [[Internet Engineering Task Force|IETF]] |section=1.2|sectionname=Protocol Overview|rfc=6455|date=December 2011|author1=Ian Fette|author2=Alexey Melnikov}}</ref>
वेब साॅकेट कनेक्शन स्थापित करने के लिए, क्लाइंट वेब साॅकेट हैंडशेक अनुरोध भेजता है, जिसके लिए सर्वर वेब साॅकेट हैंडशेक प्रतिक्रिया देता है, जैसा कि नीचे दिए गए उदाहरण में दिखाया गया है।<ref>{{Cite IETF |title=RFC 6455 The WebSocket Protocol|publisher = [[Internet Engineering Task Force|IETF]] |section=1.2|sectionname=Protocol Overview|rfc=6455|date=December 2011|author1=Ian Fette|author2=Alexey Melnikov}}</ref> इसके फलस्वरूप क्लाइंट अनुरोध (बिल्कुल [[HTTP|एटीटीपी]] के समान प्रत्येक पंक्ति के साथ समाप्त होता है <code>[[\r\n]]</code> और अंत में अतिरिक्त रिक्त पंक्ति होनी चाहिए):
क्लाइंट अनुरोध (बिल्कुल [[HTTP]] की तरह, प्रत्येक पंक्ति के साथ समाप्त होता है <code>[[\r\n]]</code> और अंत में अतिरिक्त रिक्त पंक्ति होनी चाहिए):


<syntaxhighlight lang="http">
<syntaxhighlight lang="http">
Line 162: Line 156:
Sec-WebSocket-Protocol: chat
Sec-WebSocket-Protocol: chat
</syntaxhighlight>
</syntaxhighlight>
हैंडशेक HTTP अनुरोध/प्रतिक्रिया से शुरू होता है, जिससे सर्वर HTTP कनेक्शन के साथ-साथ उसी पोर्ट पर WebSocket कनेक्शन को संभालने की अनुमति देता है। बार कनेक्शन स्थापित हो जाने के बाद, संचार द्विदिश बाइनरी प्रोटोकॉल पर स्विच हो जाता है जो HTTP प्रोटोकॉल के अनुरूप नहीं होता है।
हैंडशेक एटीटीपी अनुरोध/प्रतिक्रिया से शुरू होता है, जिससे सर्वर एटीटीपी कनेक्शन के साथ-साथ उसी पोर्ट पर वेब साॅकेट कनेक्शन को संभालने की अनुमति देता है। इस प्रकार इस कनेक्शन के स्थापित हो जाने के पश्चात संचार द्विदिश बाइनरी प्रोटोकॉल पर स्विच हो जाता है जो एटीटीपी प्रोटोकॉल के अनुरूप नहीं होता है।
 
निम्न के अतिरिक्त <code>Upgrade</code> हेडर, क्लाइंट भेजता है, जो मुख्य रूप से <code>Sec-Web-Socket-Key</code> हेडर में [[बेस 64]]-एन्कोडेड रैंडम बाइट्स होते हैं, और सर्वर कुंजी के [[हैश फंकशन]] के साथ उत्तर देता है <code>Sec-Web-Socket-Accept</code> शीर्ष लेख होता हैं। इसका उद्देश्य कैशे (कंप्यूटिंग) एटीटीपी प्रॉक्सी को पिछले वेब साॅकेट वार्तालाप को फिर से भेजने से रोकना है,<ref>{{cite web |url=https://trac.tools.ietf.org/wg/hybi/trac/wiki/FAQ |title=WebSocket प्रोटोकॉल का मुख्य लक्ष्य|publisher=IETF |access-date=25 July 2015 |quote=The computation [...] is meant to prevent a caching intermediary from providing a WS-client with a cached WS-server reply without actual interaction with the WS-server.}}</ref> और कोई प्रमाणीकरण, गोपनीयता या अखंडता प्रदान नहीं करता है। हैशिंग फ़ंक्शन निश्चित स्ट्रिंग को जोड़ता है, इस प्रकार <code>258EAFA5-E914-47DA-95CA-C5AB0DC85B11</code> ([[UUID]]) से मान के लिए <code>Sec-Web-Socket-Key</code> हेडर (जो बेस64 से डिकोड नहीं किया गया है), [[SHA-1]] हैशिंग फ़ंक्शन लागू करता है, और इस प्रकार बेस64 का उपयोग करके परिणाम को एन्कोड करता है।<ref>{{Cite IETF |title=RFC 6455 The WebSocket Protocol |page=8 |publisher=[[Internet Engineering Task Force|IETF]] |section=1.3 |sectionname=Opening Handshake |rfc=6455 |date=December 2011 |author1=Ian Fette |author2=Alexey Melnikov}}</ref>


निम्न के अलावा <code>Upgrade</code> हेडर, क्लाइंट भेजता है <code>Sec-WebSocket-Key</code> हेडर में [[बेस 64]]-एन्कोडेड रैंडम बाइट्स होते हैं, और सर्वर कुंजी के [[हैश फंकशन]] के साथ उत्तर देता है <code>Sec-WebSocket-Accept</code> शीर्ष लेख। इसका उद्देश्य कैशे (कंप्यूटिंग) HTTP प्रॉक्सी को पिछले WebSocket वार्तालाप को फिर से भेजने से रोकना है,<ref>{{cite web |url=https://trac.tools.ietf.org/wg/hybi/trac/wiki/FAQ |title=WebSocket प्रोटोकॉल का मुख्य लक्ष्य|publisher=IETF |access-date=25 July 2015 |quote=The computation [...] is meant to prevent a caching intermediary from providing a WS-client with a cached WS-server reply without actual interaction with the WS-server.}}</ref> और कोई प्रमाणीकरण, गोपनीयता या अखंडता प्रदान नहीं करता है। हैशिंग फ़ंक्शन निश्चित स्ट्रिंग को जोड़ता है <code>258EAFA5-E914-47DA-95CA-C5AB0DC85B11</code> (एक [[UUID]]) से मूल्य के लिए <code>Sec-WebSocket-Key</code> हेडर (जो बेस64 से डिकोड नहीं किया गया है), [[SHA-1]] हैशिंग फ़ंक्शन लागू करता है, और बेस64 का उपयोग करके परिणाम को एन्कोड करता है।<ref>{{Cite IETF |title=RFC 6455 The WebSocket Protocol |page=8 |publisher=[[Internet Engineering Task Force|IETF]] |section=1.3 |sectionname=Opening Handshake |rfc=6455 |date=December 2011 |author1=Ian Fette |author2=Alexey Melnikov}}</ref>
आरएफसी6455 के लिए आवश्यक है कि कुंजी के भिन्न तरीकों से चयनित 16-बाइट मान से युक्त होनी चाहिए जो बेस 64-एन्कोडेड है,<ref>{{Cite IETF |title=RFC 6455 The WebSocket Protocol |page=21 |publisher=[[Internet Engineering Task Force|IETF]] |section=1.3 |sectionname=Opening Handshake |rfc=6455 |date=December 2011 |author1=Ian Fette |author2=Alexey Melnikov}}</ref> वह बेस 64 में 24 बाइट्स है, जोअंतिम दो बाइट्स होने के साथ <code>==</code> उपयोग की जाती हैं, चूंकि इस प्रकार एटीटीपी सर्वर स्माल की को प्रस्तुत करने की अनुमति देते हैं, कई आधुनिक एटीटीपी सर्वर अमान्य <code>Sec-Web-Socket-Key</code> शीर्षलेख त्रुटि के साथ अनुरोध को अस्वीकार कर देंगे।
RFC6455 के लिए आवश्यक है कि कुंजी बेतरतीब ढंग से चयनित 16-बाइट मान से युक्त होनी चाहिए जो बेस 64-एन्कोडेड है,<ref>{{Cite IETF |title=RFC 6455 The WebSocket Protocol |page=21 |publisher=[[Internet Engineering Task Force|IETF]] |section=1.3 |sectionname=Opening Handshake |rfc=6455 |date=December 2011 |author1=Ian Fette |author2=Alexey Melnikov}}</ref> वह बेस 64 में 24 बाइट्स है (अंतिम दो बाइट्स होने के साथ <code>==</code>). हालांकि कुछ आराम से HTTP सर्वर छोटी कुंजियों को प्रस्तुत करने की अनुमति देते हैं, कई आधुनिक HTTP सर्वर अमान्य Sec-WebSocket-Key शीर्षलेख त्रुटि के साथ अनुरोध को अस्वीकार कर देंगे।


=== बेस फ़्रेमिंग प्रोटोकॉल ===
=== बेस फ़्रेमिंग प्रोटोकॉल ===
एक बार कनेक्शन स्थापित हो जाने के बाद, क्लाइंट और सर्वर [[डुप्लेक्स (दूरसंचार)]] | फुल-डुप्लेक्स मोड में वेबसाकेट डेटा या टेक्स्ट फ्रेम आगे और पीछे भेज सकते हैं। [[पेलोड (कंप्यूटिंग)]] के बाद छोटे हेडर के साथ डेटा को न्यूनतम रूप से तैयार किया गया है।<ref>{{Cite IETF |title=RFC 6455 The WebSocket Protocol|publisher = [[Internet Engineering Task Force|IETF]] |section=5.2|sectionname=Base Framing Protocol|rfc=6455|date=December 2011|author1=Ian Fette|author2=Alexey Melnikov}}</ref> WebSocket प्रसारण को संदेशों के रूप में वर्णित किया जाता है, जहां संदेश को वैकल्पिक रूप से कई डेटा फ़्रेमों में विभाजित किया जा सकता है। यह उन संदेशों को भेजने की अनुमति दे सकता है जहां प्रारंभिक डेटा उपलब्ध है लेकिन संदेश की पूरी लंबाई अज्ञात है (यह अंत तक पहुंचने और फिन बिट के साथ प्रतिबद्ध होने तक के बाद डेटा फ्रेम भेजता है)।
एक बार कनेक्शन स्थापित हो जाने के पश्चात क्लाइंट और सर्वर [[डुप्लेक्स (दूरसंचार)]] या फुल-डुप्लेक्स मोड में वेबसाकेट डेटा या टेक्स्ट फ्रेम आगे और पीछे भेज सकते हैं। [[पेलोड (कंप्यूटिंग)]] के पश्चात छोटे हेडर के साथ डेटा को न्यूनतम रूप से तैयार किया गया है।<ref>{{Cite IETF |title=RFC 6455 The WebSocket Protocol|publisher = [[Internet Engineering Task Force|IETF]] |section=5.2|sectionname=Base Framing Protocol|rfc=6455|date=December 2011|author1=Ian Fette|author2=Alexey Melnikov}}</ref> इस प्रकार वेब साॅकेट प्रसारण को संदेशों के रूप में वर्णित किया जाता है, जहां संदेश को वैकल्पिक रूप से कई डेटा फ़्रेमों में विभाजित किया जा सकता है। यह उन संदेशों को भेजने की अनुमति दे सकता है जहां प्रारंभिक डेटा उपलब्ध है अपितु संदेश की पूरी लंबाई अज्ञात है (यह अंत तक पहुंचने और फिन बिट के साथ प्रतिबद्ध होने तक के बाद डेटा फ्रेम भेजता है)।
{| class="wikitable" align="right" style="text-align: center;"
{| class="wikitable" align="right" style="text-align: center;"
! 0 !! 1 !! 2 !! 3 !! 4 !! 5 !! 6 !! 7 !! 8 !! 9 !! A !! B !! C !! D !! E !! F
! 0 !! 1 !! 2 !! 3 !! 4 !! 5 !! 6 !! 7 !! 8 !! 9 !! A !! B !! C !! D !! E !! F
Line 176: Line 171:
| colspan="7" | Payload length
| colspan="7" | Payload length
|-
|-
| colspan="16" | Extended payload length (optional)
| colspan="16" | विस्तारित पेलोड लंबाई (वैकल्पिक)
|-
|-
| colspan="16" | Masking key (optional)
| colspan="16" | मास्किंग कुंजी (वैकल्पिक)
|-
|-
| colspan="16" | Payload data
| colspan="16" | पेलोड डेटा
|}
|}
; फिन
; फिन
Line 188: Line 183:
<div class= mw-collapsible mw-collapsed data-expandtext= detail style= डिस्प्ले: इनलाइन-ब्लॉक; >
<div class= mw-collapsible mw-collapsed data-expandtext= detail style= डिस्प्ले: इनलाइन-ब्लॉक; >
[[ओपकोड]]
[[ओपकोड]]
: ओपकोड। 4ख।
: ओपकोड। 4b।
<div class = mw-collapsible-content >
<div class = mw-collapsible-content >
:; 0
:; 0
Line 199: Line 194:
:: कनेक्शन बंद
:: कनेक्शन बंद
:; 9
:; 9
:: गुनगुनाहट
:: पिगं
:; ए
:: पोंग
:: पोंग
:; वगैरह।
:; etc
:: आरक्षित
:: आरक्षित
</div>
</div>
</div>
</div>
; नकाब
; मास्क
: यदि पेलोड डेटा छिपा हुआ है तो 1 पर सेट करें। 1बी।
: यदि पेलोड डेटा छिपा हुआ है तो 1 पर सेट करें।  
:1b
<div class= mw-collapsible mw-collapsed data-expandtext= detail style= डिस्प्ले: इनलाइन-ब्लॉक; >
<div class= mw-collapsible mw-collapsed data-expandtext= detail style= डिस्प्ले: इनलाइन-ब्लॉक; >
; पेलोड की लंबाई
; पेलोड की लंबाई
: पेलोड डेटा की लंबाई। 7ख।
: पेलोड डेटा की लंबाई।  
:7b
<div class = mw-collapsible-content >
<div class = mw-collapsible-content >
:; 0-125
:; 0-125
Line 223: Line 219:
: क्लाइंट द्वारा भेजे गए सभी फ़्रेमों को इस कुंजी द्वारा मास्क किया जाना चाहिए। यदि मास्क बिट 0. 4B पर सेट है तो यह फ़ील्ड अनुपस्थित है।
: क्लाइंट द्वारा भेजे गए सभी फ़्रेमों को इस कुंजी द्वारा मास्क किया जाना चाहिए। यदि मास्क बिट 0. 4B पर सेट है तो यह फ़ील्ड अनुपस्थित है।
; पेलोड डेटा
; पेलोड डेटा
: खंड का पेलोड डेटा।
: खंड का पेलोड डेटा
प्रोटोकॉल के विस्तार के साथ, इसका उपयोग कई धाराओं को साथ मल्टीप्लेक्स करने के लिए भी किया जा सकता है (उदाहरण के लिए बड़े पेलोड के लिए सॉकेट के एकाधिकार उपयोग से बचने के लिए)।<ref>{{cite IETF|draft=draft-ietf-hybi-websocket-multiplexing |title=WebSockets के लिए एक मल्टीप्लेक्सिंग एक्सटेंशन|author1=John A. Tamplin |author2=Takeshi Yoshino |publisher=[[Internet Engineering Task Force|IETF]] |year=2013}}</ref>
प्रोटोकॉल के विस्तार के साथ, इसका उपयोग कई धाराओं को साथ मल्टीप्लेक्स करने के लिए भी किया जा सकता है, इस प्रकार उदाहरण के लिए बड़े पेलोड के लिए सॉकेट के एकाधिकार उपयोग से बचने के लिए उपयोग किया जाता हैं।<ref>{{cite IETF|draft=draft-ietf-hybi-websocket-multiplexing |title=WebSockets के लिए एक मल्टीप्लेक्सिंग एक्सटेंशन|author1=John A. Tamplin |author2=Takeshi Yoshino |publisher=[[Internet Engineering Task Force|IETF]] |year=2013}}</ref>
 
 
=== क्लाइंट टू सर्वर मास्किंग ===
=== क्लाइंट टू सर्वर मास्किंग ===
क्लाइंट से भेजे गए पेलोड डेटा को मास्किंग की द्वारा मास्क किया जाना चाहिए। मास्किंग कुंजी क्लाइंट द्वारा चुना गया 4 बाइट्स का यादृच्छिक मान है और अप्रत्याशित होना चाहिए। दुर्भावनापूर्ण एप्लिकेशन को पहले से दिखाई देने वाले बाइट्स को चुनने से रोकने के लिए मास्किंग कुंजी की अप्रत्याशितता आवश्यक है। नीतभार डेटा को ढकने के लिए निम्नलिखित एल्गोरिद्म लागू किया जाता है।
क्लाइंट से भेजे गए पेलोड डेटा को मास्किंग की द्वारा मास्क किया जाना चाहिए। इस प्रकार मास्किंग कुंजी क्लाइंट द्वारा चुना गया 4 बाइट्स का यादृच्छिक मान है और अप्रत्याशित होना चाहिए। दुर्भावनापूर्ण एप्लिकेशन को पहले से दिखाई देने वाले बाइट्स को चुनने से रोकने के लिए मास्किंग कुंजी की अप्रत्याशितता आवश्यक है। इस प्रकार नीतभार डेटा को ढकने के लिए निम्नलिखित एल्गोरिद्म लागू किया जाता है।
  जे = आई एमओडी 4
  4j = i MOD 4
  रूपांतरित-ऑक्टेट [i] = मूल-ऑक्टेट [i] XOR मास्किंग-की-ऑक्टेट [जे]
  transformed-octet[i] = original-octet[i] XOR masking-key-octet[j]


== सुरक्षा विचार ==
== सुरक्षा विचार ==
नियमित क्रॉस-डोमेन HTTP अनुरोधों के विपरीत, WebSocket अनुरोध समान-मूल नीति द्वारा प्रतिबंधित नहीं हैं। इसलिए, क्रॉस-साइट वेबसॉकेट हाइजैकिंग हमलों (क्रॉस-साइट अनुरोध जालसाजी के समान) से बचने के लिए, वेबसाकेट सर्वर को कनेक्शन स्थापना के दौरान अपेक्षित उत्पत्ति के खिलाफ उत्पत्ति शीर्षलेख को सत्यापित करना चाहिए, जो संभव हो सकता है जब कनेक्शन [[HTTP कुकी]] या HTTP प्रमाणीकरण के साथ प्रमाणित हो। . संवेदनशील (निजी) डेटा को WebSocket पर स्थानांतरित किए जाने पर WebSocket कनेक्शन को प्रमाणित करने के लिए टोकन या समान सुरक्षा तंत्र का उपयोग करना बेहतर होता है।<ref>{{cite web |url=https://www.christian-schneider.net/CrossSiteWebSocketHijacking.html#main |title=क्रॉस-साइट वेबसॉकेट हाइजैकिंग (CSWSH)|author=Christian Schneider |work=Web Application Security Blog |date=August 31, 2013}}</ref> भेद्यता का जीवंत उदाहरण 2020 में [[केबल अड्डा]] के रूप में देखा गया।
नियमित क्रॉस-डोमेन एटीटीपी अनुरोधों के विपरीत, वेब साॅकेट अनुरोध समान-मूल नीति द्वारा प्रतिबंधित नहीं हैं। इसलिए इस प्रकार के क्रॉस-साइट वेबसॉकेट हाइजैकिंग अटैक के कारण क्रॉस-साइट अनुरोध करके इस प्रकार से बचने के लिए, वेबसाकेट सर्वर को कनेक्शन स्थापना के समय अपेक्षित उत्पत्ति के विरुद्ध उत्पत्ति शीर्षलेख को सत्यापित करना चाहिए, जो संभव हो सकता है, जब कनेक्शन [[HTTP कुकी|एटीटीपी कुकी]] या एटीटीपी प्रमाणीकरण के साथ प्रमाणित हो जाता । संवेदनशील (निजी) डेटा को वेब साॅकेट पर स्थानांतरित किए जाने पर वेब साॅकेट कनेक्शन को प्रमाणित करने के लिए टोकन या समान सुरक्षा तंत्र का उपयोग करना उत्तम होता है।<ref>{{cite web |url=https://www.christian-schneider.net/CrossSiteWebSocketHijacking.html#main |title=क्रॉस-साइट वेबसॉकेट हाइजैकिंग (CSWSH)|author=Christian Schneider |work=Web Application Security Blog |date=August 31, 2013}}</ref> भेद्यता का जीवंत उदाहरण 2020 में [[केबल अड्डा|केबल हांट]] के रूप में देखा गया हैं।


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


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


यदि अनएन्क्रिप्टेड WebSocket ट्रैफ़िक WebSockets समर्थन के बिना स्पष्ट या पारदर्शी प्रॉक्सी सर्वर के माध्यम से प्रवाहित होता है, तो कनेक्शन विफल हो जाएगा।<ref>{{cite web |url=http://www.infoq.com/articles/Web-Sockets-Proxy-Servers |title=How HTML5 Web Sockets Interact With Proxy Servers |website=Infoq.com |date= March 16, 2010 |publisher=C4Media Inc. |author=Peter Lubbers |access-date=2011-12-10}}</ref>
यदि अनएन्क्रिप्टेड वेब साॅकेट ट्रैफ़िक वेब साॅकेट समर्थन के बिना स्पष्ट या पारदर्शी प्रॉक्सी सर्वर के माध्यम से प्रवाहित होता है, तो कनेक्शन विफल हो जाएगा।<ref>{{cite web |url=http://www.infoq.com/articles/Web-Sockets-Proxy-Servers |title=How HTML5 Web Sockets Interact With Proxy Servers |website=Infoq.com |date= March 16, 2010 |publisher=C4Media Inc. |author=Peter Lubbers |access-date=2011-12-10}}</ref>
यदि एन्क्रिप्टेड WebSocket कनेक्शन का उपयोग किया जाता है, तो WebSocket Secure कनेक्शन में [[ परिवहन परत सुरक्षा |परिवहन परत सुरक्षा]] (TLS) का उपयोग सुनिश्चित करता है कि <code>HTTP CONNECT</code> आदेश तब जारी किया जाता है जब ब्राउज़र स्पष्ट प्रॉक्सी सर्वर का उपयोग करने के लिए कॉन्फ़िगर किया गया हो। यह टनल सेट करता है, जो वेबसॉकेट सिक्योर क्लाइंट और वेबसॉकेट सर्वर के बीच HTTP प्रॉक्सी के माध्यम से निम्न-स्तरीय एंड-टू-एंड टीसीपी संचार प्रदान करता है। पारदर्शी प्रॉक्सी सर्वर के मामले में, ब्राउज़र प्रॉक्सी सर्वर से अनभिज्ञ है, इसलिए नहीं <code>HTTP CONNECT</code> भेजा जाता है। हालाँकि, चूंकि वायर ट्रैफ़िक एन्क्रिप्ट किया गया है, मध्यवर्ती पारदर्शी प्रॉक्सी सर्वर केवल एन्क्रिप्टेड ट्रैफ़िक की अनुमति दे सकते हैं, इसलिए इस बात की बहुत बेहतर संभावना है कि WebSocket Secure का उपयोग करने पर WebSocket कनेक्शन सफल हो जाएगा। एन्क्रिप्शन का उपयोग संसाधन लागत से मुक्त नहीं है, लेकिन अक्सर उच्चतम सफलता दर प्रदान करता है, क्योंकि यह सुरक्षित सुरंग के माध्यम से यात्रा कर रहा होगा।


2010 के मध्य के मसौदे (संस्करण हिक्सी-76) ने शीर्षलेखों के बाद कुंजी डेटा के आठ बाइट शामिल करके रिवर्स प्रॉक्सी और गेटवे के साथ संगतता तोड़ दी, लेकिन उस डेटा को विज्ञापन में शामिल नहीं किया <code>Content-Length: 8</code> शीर्ष लेख।<ref>{{cite web |url=https://www.ietf.org/mail-archive/web/hybi/current/msg02149.html |title=WebSocket -76 is incompatible with HTTP reverse proxies |website=ietf.org |publisher=Internet Engineering Task Force|date=2010-07-06 |access-date=2011-12-10 |author=Willy Tarreau |type=email}}</ref> यह डेटा सभी इंटरमीडिएट्स द्वारा अग्रेषित नहीं किया गया था, जिससे प्रोटोकॉल विफलता हो सकती है। अधिक हाल के ड्राफ्ट (जैसे, hybi-09<ref>{{cite IETF |url=https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09#section-11.4 |title=The WebSocket protocol, draft hybi-09 |sectionname=Sec-WebSocket-Key |section=11.4 |date=June 13, 2011 |access-date=June 15, 2011 |author=Ian Fette}}</ref>) मुख्य डेटा को a में रखें <code>Sec-WebSocket-Key</code> शीर्षलेख, इस समस्या को हल करना।
यदि एन्क्रिप्टेड वेब साॅकेट कनेक्शन का उपयोग किया जाता है, तो वेब साॅकेट सुरक्षित कनेक्शन में [[ परिवहन परत सुरक्षा |परिवहन परत सुरक्षा]] (TLS) का उपयोग सुनिश्चित करता है कि <code>ATTP CONNECT</code> कमांड तब प्रस्तुत किया जाता है जब ब्राउज़र स्पष्ट प्रॉक्सी सर्वर का उपयोग करने के लिए कॉन्फ़िगर किया गया हो। इस प्रकार यह टनल सेट करता है, जो वेबसॉकेट सिक्योर क्लाइंट और वेबसॉकेट सर्वर के बीच एटीटीपी प्रॉक्सी के माध्यम से निम्न-स्तरीय एंड-टू-एंड टीसीपी संचार प्रदान करता है। पारदर्शी प्रॉक्सी सर्वर की स्थिति में ब्राउज़र प्रॉक्सी सर्वर से अनभिज्ञ है, इसलिए नहीं <code>ATTP CONNECT</code> भेजा जाता है। चूंकि वायर ट्रैफ़िक एन्क्रिप्ट किया गया है, जिसके मध्यवर्ती पारदर्शी प्रॉक्सी सर्वर टनलल एन्क्रिप्टेड ट्रैफ़िक की अनुमति दे सकते हैं, इसलिए इस बात की बहुत उत्तम संभावना है कि वेब साॅकेट सुरक्षा का उपयोग करने पर वेब साॅकेट कनेक्शन सफल हो जाता हैं। इस प्रकार एन्क्रिप्शन का उपयोग संसाधन लागत से मुक्त नहीं है, अपितु अधिकांशतः उच्चतम सफलता दर प्रदान करता है, क्योंकि यह सुरक्षित टनल के माध्यम से यात्रा कर रहा होगा।
 
2010 के मध्य के आधार पर (संस्करण हिक्सी-76) ने शीर्षलेखों के पश्चात कुंजी डेटा के आठ बाइट सम्मिलित करके रिवर्स प्रॉक्सी और गेटवे के साथ संगतता तोड़ दी, अपितु इस प्रकार उस डेटा को विज्ञापन में सम्मिलित नहीं किया, जो  <code>Content-Length: 8</code> के शीर्ष लेख में देख सकते हैं।<ref>{{cite web |url=https://www.ietf.org/mail-archive/web/hybi/current/msg02149.html |title=WebSocket -76 is incompatible with HTTP reverse proxies |website=ietf.org |publisher=Internet Engineering Task Force|date=2010-07-06 |access-date=2011-12-10 |author=Willy Tarreau |type=email}}</ref> इस प्रकार यह डेटा सभी इंटरमीडिएट्स द्वारा अग्रेषित नहीं किया गया था, जिससे प्रोटोकॉल विफलता हो सकती है। इस प्रकार के ड्राफ्ट (जैसे, hybi-09<ref>{{cite IETF |url=https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09#section-11.4 |title=The WebSocket protocol, draft hybi-09 |sectionname=Sec-WebSocket-Key |section=11.4 |date=June 13, 2011 |access-date=June 15, 2011 |author=Ian Fette}}</ref>) मुख्य डेटा को a में रखें <code>Sec-वेब साॅकेट-Key</code> शीर्षलेख, इस समस्या को हल करता हैं।


== यह भी देखें ==
== यह भी देखें ==
Line 251: Line 246:
* वेबसाकेट कार्यान्वयन की तुलना
* वेबसाकेट कार्यान्वयन की तुलना
* [[नेटवर्क सॉकेट]]
* [[नेटवर्क सॉकेट]]
* धक्का प्रौद्योगिकी
* पुश प्रौद्योगिकी
* [[सर्वर द्वारा भेजे गए ईवेंट]]
* [[सर्वर द्वारा भेजे गए ईवेंट]]
* [[XMLHttpRequest]]
* [[एक्सएमएल एचटीटीपी रिक्विस्ट]]
* एचटीटीपी/2
* एचटीटीपी/2
* [[इंटरनेट प्रोटोकॉल सूट]]
* [[इंटरनेट प्रोटोकॉल सूट]]
Line 267: Line 262:


== बाहरी संबंध ==
== बाहरी संबंध ==
* [https://datatracker.ietf.org/wg/hybi/charter/ IETF Hypertext-Bidirectional (HyBi) working group]
* [https://datatracker.ietf.org/wg/hybi/charter/ आईईटीएफ Hypertext-Bidirectional (HyBi) working group]
** {{IETF RFC|6455}} The WebSocket protocol - Proposed Standard published by the IETF HyBi Working Group
** {{IETF RFC|6455}} The वेब साॅकेट protocol - Proposed Standard published by the आईईटीएफ HyBi Working Group
** [https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol The WebSocket protocol] - Internet-Draft published by the IETF HyBi Working Group
** [https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol The वेब साॅकेट protocol] - Internet-Draft published by the आईईटीएफ HyBi Working Group
** [https://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-76 The WebSocket protocol] - Original protocol proposal by Ian Hickson
** [https://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-76 The वेब साॅकेट protocol] - Original protocol proposal by Ian Hickson
* [https://dev.w3.org/html5/websockets/ The WebSocket API] {{Webarchive|url=https://web.archive.org/web/20150607035919/http://dev.w3.org/html5/websockets/ |date=2015-06-07 }} - W3C [[W3C recommendation#Working Draft (WD)|Working Draft]] specification of the API
* [https://dev.w3.org/html5/websockets/ The वेब साॅकेट एपीआई] {{Webarchive|url=https://web.archive.org/web/20150607035919/http://dev.w3.org/html5/websockets/ |date=2015-06-07 }} - W3C [[W3C recommendation#Working Draft (WD)|Working Draft]] specification of the एपीआई
* [http://www.w3.org/TR/websockets/ The WebSocket API] - W3C [[W3C recommendation#Candidate Recommendation (CR)|Candidate Recommendation]] specification of the API
* [http://www.w3.org/TR/websockets/ The वेब साॅकेट एपीआई] - W3C [[W3C recommendation#Candidate Recommendation (CR)|Candidate Recommendation]] specification of the एपीआई
* [https://www.websocket.org/ WebSocket.org] {{Webarchive|url=https://web.archive.org/web/20180916101105/http://websocket.org/ |date=2018-09-16 }} WebSocket demos, loopback tests, general information and community
* [https://www.websocket.org/ वेब साॅकेट.org] {{Webarchive|url=https://web.archive.org/web/20180916101105/http://websocket.org/ |date=2018-09-16 }} वेब साॅकेट demos, loopback tests, general information and community
[[Category: अनुप्रयोग परत प्रोटोकॉल]] [[Category: आप ऊब जाएंगे]] [[Category: इंटरनेट शब्दावली]] [[Category: नेटवर्क सॉकेट]] [[Category: रीयल-टाइम वेब]] [[Category: वेब विकास]] [[Category: कंप्यूटिंग में 2011]]
 
 


[[Category: Machine Translated Page]]
[[Category:CS1 English-language sources (en)]]
[[Category:CS1 maint]]
[[Category:Created On 16/06/2023]]
[[Category:Created On 16/06/2023]]
[[Category:Lua-based templates]]
[[Category:Machine Translated Page]]
[[Category:Multi-column templates]]
[[Category:Official website not in Wikidata]]
[[Category:Pages using div col with small parameter]]
[[Category:Pages with script errors]]
[[Category:Templates Vigyan Ready]]
[[Category:Templates that add a tracking category]]
[[Category:Templates that generate short descriptions]]
[[Category:Templates using TemplateData]]
[[Category:Templates using under-protected Lua modules]]
[[Category:Webarchive template wayback links]]
[[Category:Wikipedia fully protected templates|Div col]]
[[Category:अनुप्रयोग परत प्रोटोकॉल]]
[[Category:आप ऊब जाएंगे]]
[[Category:इंटरनेट शब्दावली]]
[[Category:कंप्यूटिंग में 2011]]
[[Category:नेटवर्क सॉकेट]]
[[Category:रीयल-टाइम वेब]]
[[Category:वेब विकास]]

Latest revision as of 17:20, 30 June 2023

WebSocket
Websocket connection.png
A diagram describing a connection using WebSocket
International standardRFC 6455
Developed byIETF
IndustryComputer science
Connector typeTCP
WebsiteOfficial website

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

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

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

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

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

इतिहास

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

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

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

ब्राउज़र कार्यान्वयन

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

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

Implementation status
प्रोटोकाॅल संस्करण ड्राफ्टिंग दिनांक इंटरनेट एक्सप्लोरर फायर फाॅक्स[24] (पीसी) फायर फाॅक्स (एंड्रॉइड) क्रोम (पीसी, मोबाइल) सफारी

(मैक, आईओएस)

ओपेरा (पीसी, मोबाइल) एंड्रॉइड ब्राउज़र
hixie-75 फरवरी 4, 2010 4 5.0.0
hixie-76
hybi-00
मई 6, 2010
मई 23, 2010
4.0 (निर्योग्य) 6 5.0.1 11.00 (निर्योग्य)
hybi-07, v7 अप्रैलl 22, 2011 6[25][lower-alpha 1]
hybi-10, v8 जुलाई 11, 2011 7[27][lower-alpha 1] 7 14[28]
RFC 6455, v13 दिसम्बर, 2011 10[29] 11 11 16[30] 6 12.10[31] 4.4

जावास्क्रिप्ट क्लाइंट उदाहरण

// Creates new WebSocket object with a wss URI as the parameter
const socket = new WebSocket('wss://game.example.com/ws/updates');

// Fired when a connection with a WebSocket is opened
socket.onopen = function () {
  setInterval(function() {
    if (socket.bufferedAmount == 0)
      socket.send(getUpdateData());
  }, 50);
};

// Fired when data is received through a WebSocket
socket.onmessage = function(event) {
  handleUpdateData(event.data);
};

// Fired when a connection with a WebSocket is closed
socket.onclose = function(event) {
  onSocketClose(event);
};

// Fired when a connection with a WebSocket has been closed because of an error
socket.onerror = function(event) {
  onSocketError(event);
};

वेब सर्वर कार्यान्वयन

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

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

प्रोटोकॉल

प्रोटोकॉल हैंडशेक

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

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com

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

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat

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

निम्न के अतिरिक्त Upgrade हेडर, क्लाइंट भेजता है, जो मुख्य रूप से Sec-Web-Socket-Key हेडर में बेस 64-एन्कोडेड रैंडम बाइट्स होते हैं, और सर्वर कुंजी के हैश फंकशन के साथ उत्तर देता है Sec-Web-Socket-Accept शीर्ष लेख होता हैं। इसका उद्देश्य कैशे (कंप्यूटिंग) एटीटीपी प्रॉक्सी को पिछले वेब साॅकेट वार्तालाप को फिर से भेजने से रोकना है,[39] और कोई प्रमाणीकरण, गोपनीयता या अखंडता प्रदान नहीं करता है। हैशिंग फ़ंक्शन निश्चित स्ट्रिंग को जोड़ता है, इस प्रकार 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 (UUID) से मान के लिए Sec-Web-Socket-Key हेडर (जो बेस64 से डिकोड नहीं किया गया है), SHA-1 हैशिंग फ़ंक्शन लागू करता है, और इस प्रकार बेस64 का उपयोग करके परिणाम को एन्कोड करता है।[40]

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

बेस फ़्रेमिंग प्रोटोकॉल

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

0 1 2 3 4 5 6 7 8 9 A B C D E F
FIN RSV1 RSV2 RSV3 Opcode Mask Payload length
विस्तारित पेलोड लंबाई (वैकल्पिक)
मास्किंग कुंजी (वैकल्पिक)
पेलोड डेटा
फिन
संदेश में अंतिम अंश को इंगित करता है। 1 बिट।
आरएसवी
MUST 0 होना चाहिए जब तक कि किसी एक्सटेंशन द्वारा परिभाषित न किया गया हो। 1बी।

ओपकोड

ओपकोड। 4b।
0
निरंतरता फ्रेम
1
टेक्स्ट फ्रेम
2
बाइनरी फ्रेम
8
कनेक्शन बंद
9
पिगं
पोंग
etc
आरक्षित
मास्क
यदि पेलोड डेटा छिपा हुआ है तो 1 पर सेट करें।
1b
पेलोड की लंबाई
पेलोड डेटा की लंबाई।
7b
0-125
यह पेलोड लंबाई है।
126
निम्नलिखित 2 बाइट्स पेलोड लंबाई हैं।
127
निम्नलिखित 8 बाइट पेलोड लंबाई हैं।
मास्किंग कुंजी
क्लाइंट द्वारा भेजे गए सभी फ़्रेमों को इस कुंजी द्वारा मास्क किया जाना चाहिए। यदि मास्क बिट 0. 4B पर सेट है तो यह फ़ील्ड अनुपस्थित है।
पेलोड डेटा
खंड का पेलोड डेटा

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

क्लाइंट टू सर्वर मास्किंग

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

4j = i MOD 4
transformed-octet[i] = original-octet[i] XOR masking-key-octet[j]

सुरक्षा विचार

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

प्रॉक्सी ट्रैवर्सल

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

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

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

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

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

यह भी देखें

टिप्पणियाँ

  1. 1.0 1.1 Gecko-based browsers versions 6–10 implement the WebSocket object as "MozWebSocket",[26] requiring extra code to integrate with existing WebSocket-enabled code.

संदर्भ

  1. "वेबसॉकेट मानक". websockets.spec.whatwg.org. Retrieved 2022-05-16.
  2. "वेबसाकेट एपीआई". www.w3.org (in English). Retrieved 2022-05-16.
  3. Ian Fette; Alexey Melnikov (December 2011). "Relationship to TCP and HTTP". RFC 6455 The WebSocket Protocol. IETF. sec. 1.7. doi:10.17487/RFC6455. RFC 6455.
  4. "Adobe Flash Platform – Sockets". help.adobe.com. Retrieved 2021-07-28. TCP connections require a "client" and a "server". Flash Player can create client sockets.{{cite web}}: CS1 maint: url-status (link)
  5. "वेबसाकेट एपीआई (वेबसॉकेट)". MDN Web Docs (in English). Mozilla Developer Network. 2023-04-06. Archived from the original on 2021-07-28. Retrieved 2021-07-26.
  6. "Glossary: WebSockets". Mozilla Developer Network. 2015.
  7. "HTML5 WebSocket – A Quantum Leap in Scalability for the Web". www.websocket.org. Archived from the original on 2021-04-01. Retrieved 2016-01-08.
  8. Graham Klyne, ed. (2011-11-14). "IANA यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर (URI) योजनाएँ". Internet Assigned Numbers Authority. Retrieved 2011-12-10.
  9. Ian Fette; Alexey Melnikov (December 2011). "WebSocket URIs". RFC 6455 The WebSocket Protocol. IETF. sec. 3. doi:10.17487/RFC6455. RFC 6455.
  10. Wang, Vanessa; Salim, Frank; Moskovits, Peter (February 2013). "APPENDIX A: WebSocket Frame Inspection with Google Chrome Developer Tools". The Definitive Guide to HTML5 WebSocket. Apress. ISBN 978-1-4302-4740-1. Archived from the original on 31 December 2015. Retrieved 7 April 2013.
  11. "HTML 5". www.w3.org. Retrieved 2016-04-17.
  12. "[whatwg] TCPConnection feedback from Michael Carter on 2008-06-18 (whatwg.org from June 2008)". lists.w3.org. Retrieved 2016-04-17.
  13. "IRC logs: freenode / #whatwg / 20080618". krijnhoetmer.nl. Retrieved 2016-04-18.
  14. "वेब सॉकेट अब गूगल क्रोम में उपलब्ध है". Chromium Blog (in English). Retrieved 2016-04-17.
  15. <ian@hixie.ch>, Ian Hickson (6 May 2010). "वेबसॉकेट प्रोटोकॉल". Ietf Datatracker. Retrieved 2016-04-17.
  16. Dirkjan Ochtman (May 27, 2011). "WebSocket enabled in Firefox 6". Mozilla.org. Archived from the original on 2012-05-26. Retrieved 2011-06-30.
  17. "क्रोमियम वेब प्लेटफ़ॉर्म स्थिति". Retrieved 2011-08-03.
  18. "वेबसाकेट (विंडोज़)". Microsoft. 2012-09-28. Retrieved 2012-11-07.
  19. "वेबसॉकेट प्रोटोकॉल टेस्ट रिपोर्ट". Tavendo.de. 2011-10-27. Archived from the original on 2016-09-22. Retrieved 2011-12-10.
  20. Katie Marsal (November 23, 2010). "Apple adds accelerometer, WebSockets support to Safari in iOS 4.2". AppleInsider.com. Retrieved 2011-05-09.
  21. "वेब सॉकेट एपीआई". BlackBerry. Archived from the original on June 10, 2011. Retrieved 8 July 2011.
  22. Chris Heilmann (December 8, 2010). "WebSocket disabled in Firefox 4". Hacks.Mozilla.org. Retrieved 2011-05-09.
  23. Aleksander Aas (December 10, 2010). "वेबसॉकेट के संबंध में". My Opera Blog. Archived from the original on 2010-12-15. Retrieved 2011-05-09.
  24. "WebSockets (support in Firefox)". developer.mozilla.org. Mozilla Foundation. 2011-09-30. Archived from the original on 2012-05-26. Retrieved 2011-12-10.
  25. "Bug 640003 - WebSockets - upgrade to ietf-06". Mozilla Foundation. 2011-03-08. Retrieved 2011-12-10.
  26. "WebSockets - MDN". developer.mozilla.org. Mozilla Foundation. 2011-09-30. Archived from the original on 2012-05-26. Retrieved 2011-12-10.
  27. "Bug 640003 - WebSockets - upgrade to ietf-07(comment 91)". Mozilla Foundation. 2011-07-22.
  28. "Chromium bug 64470". code.google.com. 2010-11-25. Retrieved 2011-12-10.
  29. "WebSockets in Windows Consumer Preview". IE Engineering Team. Microsoft. 2012-03-19. Retrieved 2012-07-23.
  30. "WebKit Changeset 97247: WebSocket: Update WebSocket protocol to hybi-17". trac.webkit.org. Retrieved 2011-12-10.
  31. "A hot Opera 12.50 summer-time snapshot". Opera Developer News. 2012-08-03. Archived from the original on 2012-08-05. Retrieved 2012-08-03.
  32. "नगनेक्स में आपका स्वागत है!". nginx.org. Archived from the original on 17 July 2012. Retrieved 3 February 2022.
  33. "वेबसाकेट प्रॉक्सी के रूप में एनजीआईएनएक्स का उपयोग करना". NGINX. May 17, 2014.
  34. "Overview of new features in Apache HTTP Server 2.4". Apache.
  35. "Changelog Apache 2.4". Apache Lounge.
  36. "IIS 8.0 WebSocket Protocol Support". Microsoft Docs. 28 November 2012. Retrieved 2020-02-18.
  37. "Release-1 4 46 - Lighttpd - lighty labs".
  38. Ian Fette; Alexey Melnikov (December 2011). "Protocol Overview". RFC 6455 The WebSocket Protocol. IETF. sec. 1.2. doi:10.17487/RFC6455. RFC 6455.
  39. "WebSocket प्रोटोकॉल का मुख्य लक्ष्य". IETF. Retrieved 25 July 2015. The computation [...] is meant to prevent a caching intermediary from providing a WS-client with a cached WS-server reply without actual interaction with the WS-server.
  40. Ian Fette; Alexey Melnikov (December 2011). "Opening Handshake". RFC 6455 The WebSocket Protocol. IETF. p. 8. sec. 1.3. doi:10.17487/RFC6455. RFC 6455.
  41. Ian Fette; Alexey Melnikov (December 2011). "Opening Handshake". RFC 6455 The WebSocket Protocol. IETF. p. 21. sec. 1.3. doi:10.17487/RFC6455. RFC 6455.
  42. Ian Fette; Alexey Melnikov (December 2011). "Base Framing Protocol". RFC 6455 The WebSocket Protocol. IETF. sec. 5.2. doi:10.17487/RFC6455. RFC 6455.
  43. John A. Tamplin; Takeshi Yoshino (2013). WebSockets के लिए एक मल्टीप्लेक्सिंग एक्सटेंशन. IETF. I-D draft-ietf-hybi-websocket-multiplexing.
  44. Christian Schneider (August 31, 2013). "क्रॉस-साइट वेबसॉकेट हाइजैकिंग (CSWSH)". Web Application Security Blog.
  45. Peter Lubbers (March 16, 2010). "How HTML5 Web Sockets Interact With Proxy Servers". Infoq.com. C4Media Inc. Retrieved 2011-12-10.
  46. Willy Tarreau (2010-07-06). "WebSocket -76 is incompatible with HTTP reverse proxies". ietf.org (email). Internet Engineering Task Force. Retrieved 2011-12-10.
  47. Ian Fette (June 13, 2011). "Sec-WebSocket-Key". The WebSocket protocol, draft hybi-09. sec. 11.4. Retrieved June 15, 2011.


बाहरी संबंध