वेब्सॉकेट क्या है? हैंडशेक, फ्रेम और फुल-डुप्लेक्स डेटा

परिचय

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

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

उद्घाटन हैंडशेक

क्लाइंट Upgrade, Connection, Sec-WebSocket-Key, Sec-WebSocket-Version, और अक्सर Origin और उपप्रोटोकॉल प्राथमिकताओं के साथ एक HTTP अनुरोध भेजता है। एक सर्वर जो स्वीकार करता है आवश्यक Sec-WebSocket-Accept मान की गणना करता है और 101 स्विचिंग प्रोटोकॉल लौटाता है।

उस प्रतिक्रिया के बाद, सामान्य HTTP संदेश सेमांटिक्स अब उस कनेक्शन पर डेटा को फ्रेम नहीं करती हैं। RFC 6455 वेब्सॉकेट प्रोटोकॉल को परिभाषित करता है, हैंडशेक फ़ील्ड, पंजीकृत URI योजनाएं, फ्रेम लेआउट, और क्लोज कोड सहित।

फ्रेम और संदेश

एप्लिकेशन डेटा पाठ या बाइनरी संदेशों में ले जाया जाता है। एक संदेश एक फ्रेम में या कई फ्रेमों के बीच खंडित हो सकता है। नियंत्रण फ्रेम क्लोज, पिंग, और पॉन्ग सिग्नल ले जाते हैं और ऐसे बाधाएं होती हैं जो कनेक्शन प्रबंधन को प्रतिक्रियाशील बनाए रखती हैं।

ब्राउज़र क्लाइंट वे सर्वर को भेजे गए फ्रेम को मास्क करते हैं; सर्वर क्लाइंट को भेजे गए फ्रेम को मास्क नहीं करते। मास्किंग एन्क्रिप्शन नहीं है। wss का उपयोग करें ताकि TLS गोपनीयता, अखंडता, और सर्वर प्रमाणीकरण प्रदान करे। संदेश लोड वैलिडेशन अभी भी एप्लिकेशन का हिस्सा है।

फुल डुप्लेक्स API आकार को बदलता है

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

एक आदेश को यह बताना चाहिए कि क्या यह पुष्टि, परिणाम, या अपडेट की धारा की अपेक्षा करता है। घटनाओं में पर्याप्त पहचान और संस्करण जानकारी शामिल होना चाहिए ताकि इसे इडेम्पोटेंट रूप से लागू किया जा सके। एक स्पष्ट अनुबंध के बिना, एक सॉकेट अस्पष्ट JSON वस्तुओं की धारा बन जाती है जो विकसित होने में कठिन होती है।

कनेक्शन जीवनचक्र और स्थिति पुनर्प्राप्ति

एक वेब्सॉकेट क्लोज हो सकता है क्योंकि एप्लिकेशन नीति, सर्वर तैनाती, शांत नेटवर्क स्थिति, उपकरण सोना, प्रॉक्सी व्यवहार, या पथ हानि के कारण। पिंग और पॉन्ग फ्रेम जीवंतता का परीक्षण कर सकते हैं, लेकिन वे छूटी हुई व्यावसायिक घटनाओं को पुनर्स्थापित नहीं करते हैं।

पुन: कनेक्शन को स्थिति समन्वय से अलग डिजाइन करें। एक नए कनेक्शन के बाद, क्लाइंट एक अंतिम-देखा गया ईवेंट ID भेज सकता है, एक स्नैपशॉट का अनुरोध कर सकता है, या विषयों के लिए फिर से सदस्यता ले सकता है। WHATWG वेब्सॉकेट मानक ब्राउज़र API के व्यवहार को परिभाषित करता है जबकि एप्लिकेशन पुनर्प्राप्ति को सेवा के लिए छोड़ देता है।

सुरक्षा सीमाएँ

ब्राउज़र क्लाइंट के लिए मूल सत्यापित करें, उपयोगकर्ता को प्रमाणीकरण करें, प्रत्येक सदस्यता और आदेश को अधिकृत करें, संदेश-आकार सीमाएँ लागू करें, और unsupported उपप्रोटोकॉल को अस्वीकार करें। एक कनेक्टेड सॉकेट स्थायी प्राधिकरण नहीं है; अनुमतियाँ और सत्र की समाप्ति खुला रहने के दौरान बदल सकती है।

लॉग में अंत बिंदुओं को दिखाई दे सकते हैं इसलिए URLs में स्थायी रहस्य डालने से बचें। प्रत्येक पहचान के लिए दर और सह-अवधि सीमाएँ लागू करें, payloads को सावधानीपूर्वक पार्स करें, और नियंत्रित कोड के साथ कनेक्शन बंद करें। TLS परिवहन की सुरक्षा करता है, जबकि व्यवसाय प्राधिकरण संसाधनों की सुरक्षा करता है।

स्तरीकरण और बैकप्रेशर

एक वेब्सॉकेट सर्वर कई क्लाइंट के लिए कनेक्शन स्थिति रखता है। मल्टी-इंस्टेंस तैनातों को एक राउटिंग या प्रकाशन-सदस्यता परत की आवश्यकता होती है ताकि एक नोड पर उत्पन्न इवेंट एक अन्य द्वारा स्वामित्व वाले कनेक्शन तक पहुँच सके। तैनाती के दौरान कनेक्शन को खत्म करना भी एक स्पष्ट प्रक्रिया की आवश्यकता होती है।

एक धीमा क्लाइंट आउटबाउंड संदेशों को तेजी से जमा कर सकता है जितना कि नेटवर्क उन्हें स्वीकार करता है। प्रत्येक भेजने की कतार को सीमित करें, प्रतिस्थापनीय स्थिति अपडेट को संयोजित करें, और उन्हें डिस्कनेक्ट करें जो एक प्रलेखित नीति के तहत बनाए रख नहीं सकते। MDN का वेब्सॉकेट API संदर्भ नोट करता है कि क्लासिक ब्राउज़र इंटरफ़ेस में अंतर्निहित बैकप्रेशर उपलब्ध नहीं है।

वेबस्केट क्या है? हैंडशेक, फ़्रेम और पूर्ण-डुप्लेक्स डेटा मान्यता योजना

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

पहली डिज़ाइन धारणा को विफलता व्यायाम में बदलें: उत्पादन अंत बिंदुओं के लिए wss की आवश्यकता है। फिर दूसरी धारणा के चारों ओर संसाधन दबाव की जांच करें: ब्राउज़र मूल मानों को मान्य करें। एक सही कार्यान्वयन को प्रलेखित सीमाओं के भीतर विफल होना चाहिए, कनेक्शन और बफ़र स्थिति को मुक्त करना चाहिए, और उस परिणाम की व्याख्या करते हुए एक ट्रेस छोड़ना चाहिए जिसमें क्रेडेंशियल्स या निजी.payloads का पता नहीं चलता।

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

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

जहाँ वेबस्केट क्या है? हैंडशेक, फ़्रेम और पूर्ण-डुप्लेक्स डेटा व्यवहार में प्रकट होता है

वेबस्केट क्या है? हैंडशेक, फ़्रेम और पूर्ण-डुप्लेक्स डेटा उत्पादन चेकलिस्ट

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

निष्कर्ष

वेब सॉकेट पूर्ण द्विदिश है। ग्राहक और सर्वरHandshake के बाद स्वतंत्र रूप से भेज सकते हैं। एप्लिकेशन अपने खुद के अनुबंध को परिभाषित करते हैं। प्रोटोकॉल फ़्रेमिंग विषय, आदेश, अनुमतियां, या पुनः播放 नहीं बनाता है। उन दो तथ्यों को स्पष्ट सीमाओं, प्रेक्षणीय स्थिति, और एक ऐसा फॉलबैक लागू करें जो प्रतिनिधि ग्राहकों द्वारा परीक्षण किया गया हो न कि कॉन्फ़िगरेशन से अनुमानित।

संदर्भ

• Scrapeless स्क्रैपिंग ब्राउज़र दस्तावेज़ीकरण
• Scrapeless स्क्रैपिंग ब्राउज़र उत्पाद अवलोकन
• Scrapeless वेब सॉकेट फ़्रेम कैप्चर गाइड