वेबसॉकेट

From alpha
Jump to navigation Jump to search
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. 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. 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. 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.


बाहरी संबंध