javascript - HTTP मतदान, लंबी मतदान, HTTP स्ट्रीमिंग और वेबसाकेट की मेरी समझ




web-applications websocket comet http-streaming (5)

मैंने अपने प्रश्न शीर्षक में कीवर्ड के बारे में SO और वेब पर कई पोस्ट पढ़ी हैं और उनसे बहुत कुछ सीखा है। मेरे द्वारा पढ़े गए कुछ प्रश्न विशिष्ट कार्यान्वयन चुनौतियों से संबंधित हैं जबकि अन्य सामान्य अवधारणाओं पर ध्यान केंद्रित करते हैं। मैं बस यह सुनिश्चित करना चाहता हूं कि मैं सभी अवधारणाओं और तर्क को समझता हूं कि प्रौद्योगिकी एक्स पर प्रौद्योगिकी एक्स का आविष्कार क्यों किया गया था। तो यहां जाता है:

एचटीपी मतदान: मूल रूप से AJAX, XmlHttpRequest का उपयोग कर।

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

एचटीपी स्ट्रीमिंग: लंबे मतदान के समान, लेकिन सर्वर "ट्रांसफर एन्कोडिंग: खंडित" के साथ एक शीर्षलेख के साथ प्रतिक्रिया करता है और इसलिए जब भी सर्वर कुछ डेटा भेजता है (और इसलिए अतिरिक्त शीर्षलेख ओवरहेड को सहेजता है) तो हमें एक नया अनुरोध शुरू करने की आवश्यकता नहीं होती है। यहां पर दोष यह है कि हमें सर्वर द्वारा भेजे गए कई हिस्सों के बीच अंतर करने के लिए डेटा की संरचना को समझना और समझना है।

जावा एप्लेट, फ्लैश, सिल्वरलाइट: वे टीसीपी / आईपी पर सॉकेट सर्वर से कनेक्ट करने की क्षमता प्रदान करते हैं, लेकिन चूंकि वे प्लगइन हैं, डेवलपर्स उन पर निर्भर नहीं रहना चाहते हैं।

वेबसाकेट्स: वे एक नई एपीआई हैं जो उपर्युक्त तरीकों की छोटी कमियों को निम्नलिखित तरीके से संबोधित करने का प्रयास करती है:

  • जावा एप्लेट्स, फ्लैश या सिल्वरलाइट जैसे प्लगइन पर वेबसाकेट का एकमात्र लाभ यह है कि वेबसाकेट मूल रूप से ब्राउज़र में बनाए जाते हैं और प्लगइन पर भरोसा नहीं करते हैं।
  • Http स्ट्रीमिंग पर वेबसाकेट का एकमात्र लाभ यह है कि आपको "समझने" और प्राप्त डेटा को पार्स करने का प्रयास करने की आवश्यकता नहीं है।
  • लॉन्ग पोलिंग पर वेबसाकेट का एकमात्र लाभ यह है कि अनुरोध के लिए अतिरिक्त हेडर आकार और खोलने और सॉकेट कनेक्शन को बंद करने का उन्मूलन है।

क्या कोई अन्य महत्वपूर्ण अंतर है जो मुझे याद आ रही है? मुझे खेद है कि अगर मैं पहले से ही एक प्रश्न में एसओ पर कई प्रश्न पूछ रहा हूं या संयोजन कर रहा हूं, लेकिन मैं इन अवधारणाओं के बारे में SO और वेब पर मौजूद सभी जानकारी से बिल्कुल सही समझना चाहता हूं।

धन्यवाद!


Answers

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

वेबसाकेट एक टीसीपी-आधारित प्रोटोकॉल हैं और इस तरह से इस HTTP-स्तर कनेक्शन सीमा से पीड़ित नहीं हैं (लेकिन, ज़ाहिर है, ब्राउज़र समर्थन वर्दी नहीं है)।


आपके द्वारा पहचाने गए लोगों की तुलना में अधिक अंतर हैं।

द्वैध / दिशात्मक:

  • यूनी-दिशात्मक: HTTP मतदान, लंबे मतदान, स्ट्रीमिंग।
  • द्वि-direcitonal: वेबसाइकिल, प्लगइन नेटवर्किंग

विलंबता (अनुमानित) बढ़ने के क्रम में:

  • WebSockets
  • प्लगइन नेटवर्किंग
  • HTTP स्ट्रीमिंग
  • HTTP लंबे मतदान
  • HTTP मतदान

सीओआरएस (क्रॉस-मूल समर्थन):

  • वेबसाकेट: हाँ
  • प्लगइन नेटवर्किंग: पॉलिसी अनुरोध के माध्यम से फ्लैश (दूसरों के बारे में निश्चित नहीं)
  • HTTP * (कुछ हालिया समर्थन)

मूल बाइनरी डेटा (टाइप किए गए सरणी, ब्लब्स):

  • वेबसाकेट: हाँ
  • प्लगइन नेटवर्किंग: फ़्लैश के साथ नहीं (बाहरी इंटरफेस में यूआरएल एन्कोडिंग की आवश्यकता है)
  • HTTP *: बाइनरी प्रकार के समर्थन को सक्षम करने के लिए हालिया प्रस्ताव

कम दक्षता में बैंडविड्थ:

  • प्लगइन नेटवर्किंग: आरंभिक नीति अनुरोध को छोड़कर फ्लैश सॉकेट कच्चे हैं
  • वेबसाकेट: कनेक्शन सेटअप हैंडशेक और प्रति फ्रेम कुछ बाइट्स
  • HTTP स्ट्रीमिंग (सर्वर कनेक्शन का पुनः उपयोग)
  • HTTP लंबे मतदान: प्रत्येक संदेश के लिए कनेक्शन
  • HTTP मतदान: प्रत्येक संदेश के लिए कनेक्शन + कोई डेटा संदेश नहीं

मोबाइल डिवाइस का समर्थन:

जावास्क्रिप्ट उपयोग जटिलता (सबसे सरल से सबसे जटिल)। माना जाता है कि जटिलता उपायों कुछ हद तक व्यक्तिपरक हैं।

  • WebSockets
  • HTTP मतदान
  • प्लगइन नेटवर्किंग
  • HTTP लंबे मतदान, स्ट्रीमिंग

यह भी ध्यान रखें कि सर्वर-प्रेषित घटनाओं नामक HTTP स्ट्रीमिंग को मानकीकृत करने के लिए डब्ल्यू 3 सी प्रस्ताव है। यह वर्तमान में इसके विकास में काफी शुरुआती है और इसे वेबस्केट्स के तुलनात्मक सादगी के साथ मानक जावास्क्रिप्ट एपीआई प्रदान करने के लिए डिज़ाइन किया गया है।


अगर मैं एक अतिरिक्त चीज़ पूछ सकता हूं: मैं कहीं किसी लेख में आया था जो कहता है कि http स्ट्रीमिंग प्रॉक्सी द्वारा भी कैश की जा सकती है जबकि websockets नहीं हैं। इसका क्या मतलब है?

( टिप्पणी प्रतिक्रियाओं के आकार को सीमित करता है, इसलिए मुझे इनलाइन के बजाय यहां जवाब देना पड़ा।)

ये एक अच्छा बिंदु है। इसे समझने के लिए, पारंपरिक HTTP परिदृश्य के बारे में सोचें ... कल्पना करें कि ब्राउज़र ने एक वेब पेज खोला है, इसलिए यह http://example.com का अनुरोध करता है। सर्वर HTTP के साथ प्रतिक्रिया करता है जिसमें पृष्ठ के लिए HTML शामिल है। फिर ब्राउजर देखता है कि पेज में संसाधन हैं, इसलिए यह सीएसएस फाइलों, जावास्क्रिप्ट फाइलों और पाठ्यक्रम की छवियों का अनुरोध करना शुरू कर देता है। वे सभी स्थैतिक फाइलें हैं जो उन सभी ग्राहकों के लिए अनुरोध करने के लिए समान होंगी।

कुछ प्रॉक्सी स्थिर संसाधनों को कैश करेंगे ताकि अन्य क्लाइंट के बाद के अनुरोध प्रॉक्सी से उन स्थिर संसाधनों को प्राप्त कर सकें, ताकि वे उन्हें प्राप्त करने के लिए केंद्रीय वेब सर्वर पर वापस जा सकें। यह कैशिंग है, और यह आपकी केंद्रीय सेवाओं से अनुरोधों को बंद करने और प्रसंस्करण करने की एक महान रणनीति है।

तो क्लाइंट # 1 अनुरोध http://example.com/images/logo.gif , कहें। वह अनुरोध केंद्रीय वेब सर्वर पर प्रॉक्सी के माध्यम से जाता है, जो logo.gif परोसता है। चूंकि logo.gif प्रॉक्सी से गुज़रता है, प्रॉक्सी उस छवि को सहेज लेगी और इसे http://example.com/images/logo.gif पते से संबद्ध करेगी।

जब ग्राहक # 2 साथ आता है और http://example.com/images/logo.gif भी अनुरोध करता है, तो प्रॉक्सी छवि वापस कर सकता है और केंद्र में वेब सर्वर पर कोई संचार आवश्यक नहीं है। यह अंतिम उपयोगकर्ता को तेज प्रतिक्रिया देता है, जो हमेशा महान होता है, लेकिन इसका मतलब यह भी है कि केंद्र पर कम भार होता है। इससे हार्डवेयर लागत कम हो सकती है, नेटवर्किंग लागत कम हो सकती है, इसलिए यह एक अच्छी बात है।

समस्या उत्पन्न होती है जब logo.gif वेब सर्वर पर अद्यतन किया जाता है। प्रॉक्सी पुरानी छवि को अनजान करने के लिए जारी रहेगी कि एक नई छवि है। यह समाप्ति के आसपास एक पूरी चीज की ओर जाता है ताकि प्रॉक्सी केवल "समाप्त हो जाने से पहले" थोड़ी देर के लिए छवि को कैश करे और अगला अनुरोध प्रॉक्सी के माध्यम से वेब सर्वर पर जाता है, जो प्रॉक्सी के कैश को रीफ्रेश करता है। ऐसे कई उन्नत समाधान भी हैं जहां एक केंद्रीय सर्वर ज्ञात कैशों को धक्का दे सकता है, और इसी तरह चीजें बहुत परिष्कृत हो सकती हैं।

यह आपके प्रश्न में कैसे जुड़ा हुआ है?

आपने HTTP स्ट्रीमिंग के बारे में पूछा जहां सर्वर क्लाइंट को HTTP स्ट्रीम कर रहा है। लेकिन स्ट्रीमिंग HTTP नियमित HTTP की तरह है, सिवाय इसके कि आप डेटा भेजना बंद नहीं करते हैं। यदि कोई वेब सर्वर किसी छवि परोसता है, तो वह उस क्लाइंट को HTTP भेजता है जो अंततः समाप्त होता है: आपने पूरी छवि भेजी है। और यदि आप डेटा भेजना चाहते हैं, तो यह वही है, लेकिन सर्वर बस वास्तव में लंबे समय तक भेजता है (जैसे कि यह एक विशाल विशाल छवि है, कहें) या यहां तक ​​कि कभी खत्म नहीं होता है।

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

इसलिए यदि आपके ग्राहक ने स्टॉक की कीमतों के लिए अनुरोध किया है, तो कहें, और एक प्रतिक्रिया मिली, तो अगला ग्राहक एक ही अनुरोध कर सकता है और कैश डेटा प्राप्त कर सकता है। शायद आप जो चाहते हैं नहीं! यदि आप स्टॉक की कीमतों का अनुरोध करते हैं तो आप नवीनतम डेटा चाहते हैं, है ना?

तो यह एक समस्या है।

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


बहुत से जमीन को कवर करने वाले दूसरों से कुछ महान जवाब। यहां थोड़ा अतिरिक्त है।

जावा एप्लेट्स, फ्लैश या सिल्वरलाइट जैसे प्लगइन पर वेबसाकेट का एकमात्र लाभ यह है कि वेबसाकेट मूल रूप से ब्राउज़र में बनाए जाते हैं और प्लगइन पर भरोसा नहीं करते हैं।

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

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

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

उन सॉकेट विकल्प (जावा, फ्लैश, और सिल्वरलाइट) को क्रॉस-मूल आर्किटेक्चर में सुरक्षित रूप से उपयोग करना मुश्किल होता है। इस प्रकार लोग अक्सर उन्हें क्रॉस-उत्पत्ति का उपयोग करने का प्रयास करते हैं, इसे सुरक्षित रूप से करने के प्रयासों की बजाय असुरक्षा को सहन करेंगे।

उन्हें खोलने के लिए अतिरिक्त "गैर-मानक" बंदरगाहों की आवश्यकता भी हो सकती है (कुछ प्रशासक करने के लिए नाराज हैं) या पॉलिसी फाइल जिन्हें प्रबंधित करने की आवश्यकता है।

संक्षेप में, सॉकेट कनेक्टिविटी के लिए जावा, फ्लैश या सिल्वरलाइट का उपयोग करना काफी समस्याग्रस्त है कि आप इसे अक्सर गंभीर आर्किटेक्चर में तैनात नहीं देखते हैं। फ्लैश और जावा में कम से कम 10 वर्षों के लिए यह क्षमता थी, और फिर भी यह प्रचलित नहीं है।

वेबसॉकेट मानक उन प्रतिबंधों को ध्यान में रखते हुए एक नए दृष्टिकोण से शुरू करने में सक्षम था, और उम्मीद है कि उनसे कुछ सबक सीख चुके हैं।

कुछ वेबसाकेट कार्यान्वयन फ्लैश (या संभवतः सिल्वरलाइट और / या जावा) का उपयोग उनके फॉलबैक के रूप में करते हैं जब वेबसॉकेट कनेक्टिविटी स्थापित नहीं की जा सकती है (जैसे कि जब पुराने ब्राउज़र में चल रहा हो या जब मध्यस्थ हस्तक्षेप करता हो)।

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

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

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

Http स्ट्रीमिंग पर वेबसाकेट का एकमात्र लाभ यह है कि आपको "समझने" और प्राप्त डेटा को पार्स करने का प्रयास करने की आवश्यकता नहीं है।

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

इसलिए यदि आप क्लाइंट को कई संदेश भेज रहे हैं, तो यह संभव है कि क्लाइंट एप्लिकेशन को तब तक डेटा प्राप्त नहीं होगा जब तक कि 50 संदेशों के डेटा प्राप्त नहीं हो जाते हैं, उदाहरण के लिए। यह बहुत वास्तविक समय नहीं है।

जबकि वेब स्ट्रीमिंग उपलब्ध नहीं होने पर HTTP स्ट्रीमिंग व्यवहार्य विकल्प हो सकती है, यह पैनासिया नहीं है। वास्तविक दुनिया की स्थितियों में वेब के खराब स्थानों में एक मजबूत तरीके से काम करने के लिए इसे अच्छी समझ की जरूरत है।

क्या कोई अन्य महत्वपूर्ण अंतर है जो मुझे याद आ रही है?

एक और बात है कि किसी ने अभी तक उल्लेख नहीं किया है, इसलिए मैं इसे लाऊंगा।

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

उदाहरण के लिए, आप वेबसॉकेट पर एएमक्यूपी या एक्सएमपीपी कर सकते हैं, क्योंकि लोग पहले से ही कर चुके हैं। तो एक ग्राहक एएमक्यूपी ब्रोकर से संदेश प्राप्त कर सकता है जैसे कि यह सीधे ब्रोकर से जुड़ा हुआ था (और कुछ मामलों में यह है)।

या यदि आपके पास कुछ कस्टम प्रोटोकॉल के साथ एक मौजूदा सर्वर है, तो आप उस वेबस्केट पर ट्रांसपोर्ट कर सकते हैं, इस प्रकार वेब पर उस बैक-एंड सर्वर को विस्तारित कर सकते हैं। प्रायः एंटरप्राइज़ में लॉक किया गया एक मौजूदा एप्लिकेशन वेबस्केट का उपयोग करके किसी भी बैक-एंड इंफ्रास्ट्रक्चर को बदलने के बिना इसकी पहुंच को बढ़ा सकता है।

(स्वाभाविक रूप से, आप सुरक्षित रूप से ऐसा करने में सक्षम होना चाहते हैं तो विक्रेता या वेबसाकेट प्रदाता से जांचें।)

कुछ लोगों ने वेबसाईट को वेब के लिए टीसीपी के रूप में संदर्भित किया है। क्योंकि टीसीपी उच्च स्तरीय प्रोटोकॉल को ट्रांसपोर्ट करता है, इसलिए वेबसॉकेट भी करता है, लेकिन इस तरह से वेब इंफ्रास्ट्रक्चर के साथ संगत है।

तो वेबसॉकेट पर सीधे जेएसओएन (या जो कुछ भी) संदेश भेजना हमेशा संभव है, किसी को भी मौजूदा प्रोटोकॉल पर विचार करना चाहिए। क्योंकि कई चीजों के लिए आप करना चाहते हैं, शायद एक प्रोटोकॉल है जिसे पहले से ही करने का विचार किया जा चुका है।

मुझे खेद है कि अगर मैं पहले से ही एक प्रश्न में एसओ पर कई प्रश्न पूछ रहा हूं या संयोजन कर रहा हूं, लेकिन मैं इन अवधारणाओं के बारे में SO और वेब पर मौजूद सभी जानकारी से बिल्कुल सही समझना चाहता हूं।

यह एक अच्छा सवाल था, और जवाब सभी जानकारीपूर्ण रहे हैं!


सबसे पहले मुझे वेबस्केट्स तत्परता को संबोधित करने दें :

Hixie-76 प्रोटोकॉल के WebSockets कार्यान्वयन को क्रोम, सफारी और आईओएस (आईफोन और आईपैड) में डिफ़ॉल्ट रूप से भेज दिया जाता है और सक्षम किया जाता है। हिक्सी -76 प्रोटोकॉल को भी भेज दिया गया है लेकिन फ़ायरफ़ॉक्स 4 और ओपेरा 11 में डिफॉल्ट रूप से अक्षम किया गया है। web-socket-js प्रोजेक्ट एक फ्लैश शिम / पॉलीफिल है जो फ्लैश के साथ किसी भी ब्राउज़र पर वेबसॉकेट (हिक्सी -76) समर्थन जोड़ता है।

दूसरे शब्दों में, वेबसाकेट जंगली में लगभग हर ब्राउज़र के लिए उपलब्ध है।

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

मोज़िला, ओपेरा, Google, और माइक्रोसॉफ्ट सभी हाइबी प्रोटोकॉल कार्यान्वयन पर काम कर रहे हैं (हालांकि माइक्रोसॉफ्ट अब के लिए एक अलग डाउनलोड के रूप में अपना रखरखाव कर रहा है)। HyBi-07 समर्थन के साथ वेब-सॉकेट-जेएस की एक शाखा है

अपडेट करें : फरवरी, 2013 तक, नवीनतम हाइबी / आईईटीएफ आरएफसी 6455 स्पेक क्रोम 14, फ़ायरफ़ॉक्स 7, आईई 10, ओपेरा 12.1, सफारी 6.0 और web-socket-js फ्लैश शिम / पॉलीफिल द्वारा समर्थित है। मोबाइल उपकरणों पर आईईटीएफ 6455 आईओएस 6.0 पर सफारी द्वारा समर्थित है, ओपेरा मोबाइल 12.1, एंड्रॉइड के लिए क्रोम 14, एंड्रॉइड के लिए फ़ायरफ़ॉक्स 7 और ब्लैकबेरी 7. मूल डिफ़ॉल्ट एंड्रॉइड ब्राउज़र में कोई वेबसेट समर्थन नहीं है।

वेबसॉकेट सर्वर को कार्यान्वित करना आसान है। कई स्टैंडअलोन और प्लगइन कार्यान्वयन हैं जिनमें से अधिकांश हिक्सी -76 और हाइबी प्रोटोकॉल संस्करणों का समर्थन करते हैं:

बॉश बनाम वेबसाकेट्स :

  • विलंबता : बीओएसएच मसौदा दस्तावेज बहुत कम विलंबता का दावा करता है, लेकिन बीओएसएच के लिए वेबसाकेट्स के साथ प्रतिस्पर्धा करना मुश्किल होगा। जब तक आपके पास आदर्श स्थितियां न हों, जहां HTTP / 1.1 सभी मध्यस्थों और लक्षित सर्वर द्वारा सभी तरह से समर्थित है, तो बीओएसएच क्लाइंट और कनेक्शन मैनेजर को प्रत्येक पैकेट और प्रत्येक अनुरोध टाइमआउट के बाद कनेक्शन फिर से स्थापित करने की आवश्यकता होगी। यह विलंबता और विलंबता जिटर में काफी वृद्धि करेगा। औसत विलंबता से वास्तविक समय के अनुप्रयोगों के लिए अक्सर कम जिटर अधिक महत्वपूर्ण होता है। वेबसाकेट कनेक्शन विलंबता और कच्चे टीसीपी कनेक्शन के लिए जिटर में बहुत समान होंगे। और यहां तक ​​कि आदर्श परिस्थितियों में भी, बीओएसएच संचार (और इसलिए राउंड-ट्रिप) की क्लाइंट-टू-सर्वर विलंबता हमेशा वेबसाकेट से अधिक होगी: बीओएसएच को अभी भी HTTP अनुरोध-प्रतिक्रिया अर्थशास्त्र का पालन करना होगा। HTTP स्ट्रीमिंग प्रति अनुरोध एकाधिक प्रतिक्रियाओं को सक्षम करता है (एकाधिक भागों में "सिंगल" प्रतिक्रिया को विभाजित करके) लेकिन इसके विपरीत नहीं (प्रत्येक क्लाइंट संदेश एक नया अनुरोध है)।
  • छोटे पैकेट ओवरहेड : वेबसाकेट में छोटे संदेशों के लिए ओवरहेड बनाने के दो बाइट हैं। बोश में, प्रत्येक संदेश में HTTP अनुरोध और प्रतिक्रिया शीर्षलेख होते हैं (प्रत्येक राउंड-ट्रिप के लिए आसानी से 180+ बाइट)। इसके अलावा, प्रत्येक संदेश एक्सएमएल में लपेटा जाता है (माना जाता है कि वैकल्पिक लेकिन नमूना परिभाषित नहीं करता है) कई सत्र संबंधी विशेषताओं के साथ।
  • जटिलता : जबकि बीओएसएच ब्राउज़र में मौजूदा तंत्र का उपयोग करता है, इसके लिए बोस अर्थशास्त्र को लागू करने के लिए एक जटिल जटिल जावास्क्रिप्ट लाइब्रेरी की आवश्यकता होती है। जावास्क्रिप्ट में इसे प्रबंधित करने से मूल / ब्राउज़र (या यहां तक ​​कि फ़्लैश) कार्यान्वयन की तुलना में विलंबता और जिटर भी बढ़ेगा।
  • कर्षण : बीओएसएच ने एक्सएमपीपी को और अधिक कुशल बनाने के लिए जीवन शुरू किया। यह एक्सएमपीपी समुदाय से बड़ा हुआ और मैं जो कह सकता हूं उससे उस समुदाय के बाहर बहुत कम कर्षण प्राप्त हुआ है। बीओएसएच और एक्सएमपीपी के लिए मसौदे दस्तावेजों को अलग कर दिया गया है, लेकिन एक्सएमपीपी के बिना बोश के बहुत कम वास्तविक विश्व उपयोग प्रतीत होता है।

अपडेट करें :

बस एक वीडियो मिला जहां इयान फेट चैनल एपीआई पर वेबसाकेट के फायदों पर चर्चा करता है जो बोश के समान है (44:00 बजे)





javascript web-applications websocket comet http-streaming