क्या HTTP / 2 वेबस्केट को अप्रचलित बनाता है?

Question

मैं HTTP / 2 प्रोटोकॉल के बारे में सीख रहा हूं। यह छोटे संदेश फ्रेम के साथ एक बाइनरी प्रोटोकॉल है। यह एकल टीसीपी कनेक्शन पर स्ट्रीम मल्टीप्लेक्सिंग की अनुमति देता है। वैचारिक रूप से यह वेबसॉकेट के समान ही लगता है।

क्या अप्रचलित वेबस्केट्स की योजना है और उन्हें किसी प्रकार के शीर्ष लेख रहित HTTP / 2 अनुरोधों और सर्वर द्वारा शुरू किए गए पुश संदेशों से बदल दिया जाए? या WebSockets HTTP / 2 के पूरक होंगे?

Comments

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

— वबजनेर

Answer 1

HTTP / 2 जो मुझे समझ में आया, वह वेबसैट के लिए प्रतिस्थापन नहीं है, लेकिन इसका उद्देश्य SPDY प्रोटोकॉल को मानकीकृत करना है।

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

ये समान चीजें नहीं हैं, और उन्हें एक दूसरे का पूरक होना चाहिए।

Comments

आपके उत्तर के लिए धन्यवाद गिलौम। हालाँकि मैं सोच रहा हूं कि क्या आप (या कोई) HTTP / 2 विनिर्देश से कुछ संदर्भ जोड़ सकते हैं। मैंने ब्लॉग और इतने से क्या पढ़ा है - HTTP / 2 के साथ एक सच्चा द्विदिश संचार है?

— मार्टिन मेसेर

यह सुनिश्चित न करें कि HTTP / 2 युक्ति HTTP / 2 की उत्पत्ति के बारे में विवरण देने के लिए सही जगह है और यह वेबस्कैट से कैसे भिन्न है। हालाँकि, आप आसानी से देख सकते हैं कि HTTP / 2 के साथ हम एक अप्रत्यक्ष संचार का उपयोग कर रहे हैं: goo.gl/IJVxWS (पेज 6 और 13)

— गिलौम डी।

HTTP / 2 वास्तव में द्विदिश है, लेकिन सममित नहीं है, जिसका अर्थ है कि केवल ग्राहक एक उचित अनुरोध भेज सकता है और सर्वर प्रतिक्रियाएं और वादे (पुश) भेज सकता है। यह वेबस्कोट को इस मायने में अलग बनाता है कि दोनों पक्षों को भेजने / प्राप्त करने की अनुमति के संदर्भ में अधिक "समान" हैं।

— जॉर्ज एंटोनियाडिस

HTTP2 की उत्पत्ति के बारे में IEEE के सॉफ्टवेयर इंजीनियरिंग रेडियो पर एक उत्कृष्ट पॉडकास्ट है। मुझे लगता है कि यह है: se-radio.net/2015/07/episode-232-mark-nottingham-on-http2

— मैक्स मर्फी

पूर्ण विवरण के साथ इसी तरह के उत्तर इस InfoQ लेख में यहां देखे जा सकते हैं: infoq.com/articles/websocket-and-http2-coexist

— mantrid

Answer 2

HTTP / 2 युक्ति को पढ़ने के समाप्त होने के बाद , मुझे लगता है कि HTTP / 2 ज्यादातर उपयोग के मामलों के लिए अप्रचलित वेबस्कैट करता है, लेकिन शायद सभी नहीं।

PUSH_PROMISE(बोलचाल की भाषा में सर्वर पुश के रूप में जाना जाता है) यहां मुद्दा नहीं है। यह सिर्फ एक प्रदर्शन अनुकूलन है।

एक ब्राउज़र में वेबसोकेट के लिए मुख्य उपयोग मामला डेटा की द्विदिश स्ट्रीमिंग को सक्षम करने के लिए है। इसलिए, मुझे लगता है कि ओपी का सवाल यह है कि क्या HTTP / 2 ब्राउज़र में द्विदिश स्ट्रीमिंग को सक्षम करने का बेहतर काम करता है, और मुझे लगता है कि हाँ, यह करता है।

सबसे पहले, यह है द्वि-di। बस धाराओं खंड का परिचय पढ़ें :

एक "स्ट्रीम" एक HTTP / 2 कनेक्शन के भीतर क्लाइंट और सर्वर के बीच एक्सचेंज किए गए फ्रेम का एक स्वतंत्र, द्विदिश अनुक्रम है। धाराओं की कई महत्वपूर्ण विशेषताएं हैं:

एक एकल HTTP / 2 कनेक्शन में कई समवर्ती खुली धाराएं हो सकती हैं, जिसमें कई धाराओं से अंत: बिंदु इंटरलेविंग फ़्रेम होते हैं।

धाराओं को एकतरफा रूप से स्थापित और उपयोग किया जा सकता है या क्लाइंट या सर्वर द्वारा साझा किया जा सकता है।

धाराओं को समापन बिंदु द्वारा बंद किया जा सकता है।

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

यह वेबसोकेट्स से बहुत अलग नहीं है: क्लाइंट को सर्वर पर डेटा भेजने से पहले भी वेबसोकेट अपग्रेड अनुरोध शुरू करना होगा।

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

(यह गलत लेख यह भी कहता है कि वेबसोकेट मानक का बहुसंकेतन है। नहीं, यह नहीं है। यह वास्तव में यह पता लगाना कठिन नहीं है कि बस वेबसोकेट RFC 6455 खोलें और ⌘-F दबाएं, और "मल्टीप्लेक्स" टाइप करें। आपके पढ़ने के बाद।

प्रोटोकॉल एक्स्टेंसिबल होने का इरादा है; भविष्य के संस्करणों की संभावना मल्टीप्लेक्सिंग जैसी अतिरिक्त अवधारणाओं को पेश करेगी।

आप पाएंगे कि वेबसोकेट मल्टीप्लेक्सिंग के लिए 2013 का मसौदा विस्तार है । लेकिन मुझे नहीं पता कि कौन से ब्राउज़र, यदि कोई है, तो उसका समर्थन करें। मैं अपने एसपीए वेबैप को उस एक्सटेंशन के पीछे बनाने की कोशिश नहीं करूंगा, विशेष रूप से HTTP / 2 आने के साथ, समर्थन कभी नहीं आ सकता है)।

मल्टीप्लेक्सिंग ठीक उसी तरह की चीज है जो आपको सामान्य रूप से अपने आप से करनी होती है जब भी आप बीड़ी के लिए एक वेबसोकेट खोलते हैं, कहते हैं, एक प्रतिक्रियाशील रूप से अपडेट करने के लिए सिंगल पेज ऐप को अपडेट करें। मुझे खुशी है कि यह HTTP / 2 कल्पना में है, एक बार और सभी के लिए ध्यान रखा गया है।

यदि आप जानना चाहते हैं कि HTTP / 2 क्या कर सकता है, तो बस gRPC को देखें। gRPC को HTTP / 2 पर लागू किया गया है। विशेष रूप से आधे और पूर्ण द्वैध स्ट्रीमिंग विकल्पों को देखें जो कि जीआरपीसी प्रदान करता है। (ध्यान दें कि वर्तमान में gRPC ब्राउज़र में काम नहीं करता है, लेकिन यह वास्तव में है क्योंकि ब्राउज़र (1) क्लाइंट जावास्क्रिप्ट के लिए HTTP / 2 फ्रेम को उजागर नहीं करते हैं, और (2) आम तौर पर ट्रेलरों का समर्थन नहीं करते हैं, जिनका उपयोग किया जाता है GRPC कल्पना।)

अब भी वेबस्केट में जगह हो सकती है? बड़ा सर्वर है-> ब्राउज़र ने बाइनरी डेटा को धकेल दिया। HTTP / 2 सर्वर-> ब्राउज़र को बाइनरी डेटा को धकेलने की अनुमति देता है, लेकिन यह ब्राउज़र JS में उजागर नहीं होता है। ऑडियो और वीडियो फ्रेम को धक्का देने जैसे अनुप्रयोगों के लिए, यह वेबसोकेट का उपयोग करने का एक कारण है।

संपादित करें: १ Edit जनवरी २०२०

समय के साथ यह उत्तर धीरे-धीरे ऊपर तक पहुंच गया है (जो अच्छा है, क्योंकि यह उत्तर कमोबेश सही है)। हालाँकि, अभी भी कभी-कभार यह कहते हुए टिप्पणी की जाती है कि यह विभिन्न कारणों से सही नहीं है, आमतौर पर PUSH_PROMISEकिसी एक पृष्ठ ऐप में संदेश-उन्मुख सर्वर -> क्लाइंट पुश के बारे में या वास्तव में उपभोग करने के बारे में कुछ भ्रम से संबंधित है । और, एक ब्राउज़र में वेबस्कैट के लिए उपयोग-मामला है, जो सर्वर-पुश बाइनरी डेटा है। JSON सहित पाठ डेटा के लिए, वेबस्कैट का उपयोग न करें, SSE का उपयोग करें।

पुनरावृत्ति करने के लिए: HTTP / 2 प्रोटोकॉल पूर्ण द्वि-दी है। हालाँकि, आधुनिक वेब ब्राउज़र फ़्रेम-उन्मुख HTTP / 2 प्रोटोकॉल को जावास्क्रिप्ट में उजागर नहीं करते हैं । कभी-कभी, यदि आप HTTP / 2 कनेक्शन पर एक ही मूल के लिए कई अनुरोध करते हैं, तो हुड के तहत उस ट्रैफ़िक का एक कनेक्शन पर कई गुना हो रहा है (और यही वह है जिसकी हम परवाह करते हैं!)।

इसलिए यदि आपको एक वास्तविक समय चैट ऐप बनाने की आवश्यकता है, तो आइए हम बताते हैं कि आपको चैट रूम में सभी क्लाइंट के लिए नए चैट संदेशों को प्रसारित करने की आवश्यकता है, जिनके खुले कनेक्शन हैं, आप (और शायद) वेबस्केट के बिना ऐसा कर सकते हैं।

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

अधिक संसाधन कुशल होने और वेबस्कैट हैंडशेक की तुलना में कम प्रारंभिक विलंबता होने के अलावा, सर्वर द्वारा भेजे गए घटनाक्रम में अच्छी संपत्ति है कि वे स्वचालित रूप से वापस आते हैं और HTTP / 1.1 पर काम करते हैं। लेकिन जब आपके पास HTTP / 2 कनेक्शन होता है तो वे अविश्वसनीय रूप से अच्छी तरह से काम करते हैं।

यहाँ एक अच्छा लेख है जिसमें प्रतिक्रियाशील-अद्यतन एसपीए को पूरा करने का एक वास्तविक दुनिया उदाहरण है।

Comments

यह उत्तर स्वीकार किए गए सहित अन्य लोगों के साथ आंशिक रूप से असहमत है, और यह सबसे अच्छा जवाब भी है क्योंकि यह प्रत्यक्ष स्रोतों पर आधारित है।

— सूदो

मैं इस जवाब और टिप्पणी से पूरी तरह सहमत हूं। HTTP / 2 को द्विदिश स्ट्रीम किया गया है।

— मार्टिन मेसेर

वास्तव में सही उत्तर, स्रोत और वास्तविक विश्व अनुप्रयोग (जीपीसी) की जांच करने के लिए परेशान व्यक्ति

— व्लादिमीर

Websockets में, सर्वर तब तक मनमाने बाइट्स पुश करना शुरू नहीं कर सकता, जब तक कि ग्राहक एक websocket उन्नयन अनुरोध आरंभ नहीं करता, लेकिन तब वह किसी भी समय धक्का दे सकता है। HTTP / 2 में, सर्वर तब तक बाइट्स पुश करना शुरू नहीं कर सकता जब तक क्लाइंट डेटा कनेक्शन शुरू नहीं करता, लेकिन तब वह किसी भी समय बाइट्स को पुश कर सकता है। कार्यात्मक अंतर क्या है? जैसा कि मैंने बताया है, PUSH_PROMISE क्षमता एक लाल हेरिंग है। यह कारण नहीं है कि HTTP / 2 वेब सॉकेट के लिए एक प्रतिस्थापन क्यों है। यह सिर्फ एक मामूली प्रदर्शन के पक्ष में अनुकूलन है। इसका HTTP / 2 के दिल से कोई लेना-देना नहीं है, जो कि बीड़ी स्ट्रीमिंग है।

— 19

यह उत्तर केवल गलत है। यह इतने पहलुओं को भ्रमित करता है कि यह आसानी से भ्रमित हो जाता है। हालाँकि, इस मामले की जड़ यह है कि "बीड़ी" HTTP / 2 स्ट्रीम अनुरोध-प्रतिक्रिया चालित (और संख्या में सीमित) हैं, जबकि WebSockets प्रोटोकॉल एक सच्चा संदेश आधारित बीड़ी प्रोटोकॉल है (यह अनुरोध-प्रतिक्रिया आधारित नहीं है, हेंडशेक चरण को छोड़कर)। यह एक बहुत बड़ा अंतर है जिसे केवल विनिर्देशन को गलत तरीके से फैलाया नहीं जा सकता है (जैसा कि @masonk अनजाने में किया गया प्रतीत होता है)।

— मिस्ट्री

Answer 3

मैं कहता हूं कि Nay ( Websockets अप्रचलित नहीं हैं )।

पहला और सबसे अधिक बार नजरअंदाज किया गया मुद्दा यह है कि HTTP / 2 पुश लागू नहीं है और इसे प्रॉक्सी, राउटर, अन्य बिचौलियों या यहां तक ​​कि ब्राउज़र द्वारा अनदेखा किया जा सकता है।

यानी (HTTP2 ड्राफ्ट से):

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

इसलिए, HTTP / 2 पुश WebSockets को प्रतिस्थापित नहीं कर सकता है।

इसके अलावा, HTTP / 2 कनेक्शन कुछ समय बाद बंद हो जाते हैं।

यह सच है कि मानक कहता है कि:

HTTP / 2 कनेक्शन लगातार हैं। सर्वश्रेष्ठ प्रदर्शन के लिए, यह उम्मीद की जाती है कि ग्राहक तब तक कनेक्शन बंद नहीं करेंगे जब तक यह निर्धारित न हो जाए कि सर्वर के साथ कोई और संचार आवश्यक नहीं है (उदाहरण के लिए, जब कोई उपयोगकर्ता किसी विशेष वेब पेज से दूर होता है) या जब तक सर्वर कनेक्शन बंद नहीं कर देता।

परंतु...

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

भले ही वही कनेक्शन कंटेंट को पुश करने की अनुमति देता है, जबकि यह खुला है और भले ही HTTP / 2, HTTP / 1.1 के 'कीप-लाइव' द्वारा पेश किए गए कुछ प्रदर्शन मुद्दों को हल करता है ... HTTP / 2 कनेक्शन को अनिश्चित काल तक खुला नहीं रखा जाता है ।

न ही एक वेबपेज एक HTTP / 2 कनेक्शन को एक बार बंद करने के लिए फिर से शुरू कर सकता है (जब तक कि हम लंबे समय तक वापस नहीं आए, वह है)।

EDIT (2017, दो साल बाद)

HTTP / 2 के कार्यान्वयन से पता चलता है कि कई ब्राउज़र टैब / विंडो एक ही HTTP / 2 कनेक्शन को साझा करते हैं, जिसका अर्थ है कि pushयह कभी पता नहीं चलेगा कि यह किस टैब / विंडो से संबंधित है, इसके उपयोग को समाप्त कर रहा हैpush वेबस्केट के प्रतिस्थापन रूप ।

EDIT (2020)

मुझे यकीन नहीं है कि लोगों ने उत्तर को अस्वीकार करना शुरू कर दिया। यदि कुछ भी हो, तो उत्तर के बाद के वर्षों को शुरू में यह साबित कर दिया गया था कि HTTP / 2 वेबसॉकेट्स को प्रतिस्थापित नहीं कर सकता है और ऐसा करने के लिए डिज़ाइन नहीं किया गया था।

दी गई, HTTP / 2 का उपयोग WebSocket कनेक्शन को टनल करने के लिए किया जा सकता है , लेकिन इन सुरंग वाले कनेक्शनों को अभी भी WebSocket प्रोटोकॉल की आवश्यकता होगी और वे HTTP / 2 कंटेनर के व्यवहार के तरीके को प्रभावित करेंगे।

Comments

WS सॉकेट्स हमेशा के लिए खुले नहीं रहेंगे। अंतर धाराएँ हैं; HTTP / 2 आपको कई धारा प्रवाह प्रदान करता है जिसका अर्थ है कि सर्वर पर प्रवाह नियंत्रण बहुत अलग और अक्सर लॉकलेस होता है। WS (एक प्रोटोकॉल के रूप में) में अनबाउंड इनबाउंड प्रोसेसिंग होना आवश्यक है। प्रवाह नियंत्रण को स्टैक के ऊपर लागू किया जाता है। सुरक्षा और सर्वर अखंडता के लिए, HTTP / 2, WS से बेहतर है।

— बंधन '

@ इसके अलावा, मैं मानता हूं कि HTTP / 2 में ट्रांसपोर्ट लेयर के रूप में कई फायदे हैं (कई ब्राउज़र टैब में एक ही कनेक्शन साझा करना सिर्फ एक उदाहरण है)। हालाँकि, इसे संचार परत के रूप में डिज़ाइन नहीं किया गया है । यह एक कार्यात्मक प्रश्न है। दोनों प्रोटोकॉल अलग-अलग जरूरतों का जवाब देते हैं। यानी sshWebsockets का उपयोग करते समय ब्राउज़र पर टर्मिनल लागू करना एक हवा है। यह HTTP / 2 पर कुल सिरदर्द होगा, खासकर यदि एक टैब खुला है। इसके अलावा, क्या होगा यदि ब्राउज़र (या एचटीटीपी / 2 प्रॉक्सी में से एक) ने कनेक्शन बंद कर दिया है? क्या ग्राहक मान सकता है कि कोई नया डेटा उपलब्ध नहीं है? हम मतदान पर वापस आ गए हैं।

— मिस्ट्री

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

— बंधन

अंकल बेन (स्पाइडर मैन) को उद्धृत करने के लिए: "याद रखें, महान शक्ति के साथ बड़ी जिम्मेदारी आती है"। हाँ, @, आप बहुत सही हैं। Websockets, बहुत "कच्चे" प्रोटोकॉल होने के कारण, एक अधिक जिम्मेदार सर्वर डिज़ाइन की आवश्यकता होती है। और हां, WS को HTTP / 2 के रूप में आसानी से बंद किया जा सकता है, लेकिन WS oncloseकॉलबैक का समर्थन करता है , इसलिए कोई मतदान आवश्यक नहीं है। मल्टीप्लेक्सिंग के लिए, मुझे लगता है कि यह एक आवश्यकता थी बल्कि एक विकल्प था। keep-aliveविफल रहा और "प्रथम-इन-लाइन" प्रदर्शन हिट से बचने का एकमात्र तरीका मल्टीप्लेक्सिंग को जोखिम में डालना था। समय बताएगा :)

— मिस्ट्री

आउटबाउंड मल्टीप्लेक्सिंग के सर्वर डिज़ाइन बिंदु से एक जटिल और महंगी समस्या है। आंतरिक रूप से मतदान करने के लिए IO यांत्रिकी की आवश्यकता होती है जो नरक के रूप में महंगा है। जब तक आप बड़े दस्तावेज़ों को स्ट्रीम नहीं कर रहे हैं, तब तक मल्टीप्लेक्सिंग भी काम नहीं करेगा क्योंकि अनुरोध ने संभवतः जवाब दिया होगा और दूसरा पूरी तरह से उपलब्ध होने से पहले पूरी तरह से आंतरिक रूप से बफर कर दिया है और मल्टीप्लेक्स चलाने में विफल रहता है। RTMP में आउटबाउंड मल्टीप्लेक्सिंग है लेकिन केवल Adobe का सर्वर ही ऐसा करता है। यह आश्चर्यजनक है कि HTTP / 2 RTMP के कितने करीब है।

— बंधन

Answer 4

जवाब न है। दोनों के बीच का लक्ष्य बहुत अलग है। यहाँ तक कि HTTP / 2 पर WebSocket के लिए एक RFC भी है जो आपको एक ही HTTP / 2 TCP पाइप पर कई WebSocket कनेक्शन बनाने की अनुमति देता है।

HTTP / 2 पर WS नए कनेक्शन खोलने के लिए समय कम करके और अधिक सॉकेट्स, सॉफ्ट IRQ और बफ़र्स के अतिरिक्त खर्च के बिना अधिक संचार चैनलों के लिए अनुमति देकर एक संसाधन संरक्षण खेल होगा।

https://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-01

Comments

वह आश्चर्यजनक है! क्या एक जावास्क्रिप्ट क्लाइंट का कोई सार्वजनिक उदाहरण है जिसने इसे लागू किया है? मुझे कोई उदाहरण नहीं मिल रहा है। मुझे क्या करने की आवश्यकता होगी? क्या यह एक अच्छा संसाधन है? undertow.io/blog/2015/04/27/An-in-depth-overview-of-HTTP2.html

— RaisinBranCrunch

क्या किसी को 1 के बारे में उपरोक्त दावों का एक स्रोत पता है) हेडर की लंबाई, 2) क्षेत्र के नाम को कम करना?

— पिम हाइजेन

@PimHeijden HTTP / 1.x में हेडर की लंबाई का पता लगाने के लिए 4 बाइट एंड मार्कर की तलाश में सभी बाइट्स के माध्यम से लूपिंग की आवश्यकता होती है। यह बहुत महंगा है। फ़ील्ड नामों की केस-इन्सेंटिविटी का अर्थ यह भी है कि किसी भी फ़ील्ड मिलान को वर्णों के ऊपरी और निचले दोनों प्रकार के संस्करण के लिए किया जाना चाहिए। यह चेक के लिए ऊपरी और निचले मामले के लिए पूरे चारसेट का ज्ञान आवश्यक है। 2.x में आप मान सकते हैं कि वे लोअर केस हैं।

— बंध

@RaisinBranCrunch आप जावास्क्रिप्ट में से किसी को भी नियंत्रित नहीं कर सकते। ब्राउज़र आपके लिए सब कुछ करता है।

— बंध

@ मैं वर्तमान में Nginx के साथ HTTP / 2 का उपयोग कर रहा हूं, और एक सॉकेट सर्वर पर वेबसैट कनेक्शन भेजने के लिए प्रॉक्सी_पास, लेकिन जब मेरे पास वेबसाइट में एक ही उपयोगकर्ता के कई टैब खुले हैं, तो सॉकेट सर्वर इसे कई कनेक्शनों के रूप में मानता है। मुझे लगता है कि यदि HTTP / 2 एक टीसीपी पाइप पर कनेक्शन को मल्टीप्लेक्स कर रहा है, तो सर्वर इसे एक कनेक्शन के रूप में मानेगा। क्या यह गलत है? क्या यह सत्यापित करने का कोई तरीका है कि सर्वर अतिरिक्त अनावश्यक कनेक्शन नहीं बना रहा है?

— रईसब्रेनक्रंच

Answer 5

खैर, इस InfoQ लेख से उद्धृत करने के लिए :

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

और इसलिए HTTP2 पुश आपके ब्राउज़र और सर्वर के बीच वास्तव में कुछ है, जबकि Websockets वास्तव में उन API को उजागर करता है जो क्लाइंट (जावास्क्रिप्ट, यदि इसके ब्राउज़र पर चल रहे हैं) और वास्तविक डेटा डेटा को ट्रांसफर करने के लिए एप्लिकेशन कोड (सर्वर पर चल रहा है) दोनों द्वारा उपयोग किया जा सकता है।

Answer 6

संदेश विनिमय और सरल स्ट्रीमिंग (ऑडियो, वीडियो स्ट्रीमिंग नहीं) को एचटीपी / 2 मल्टीप्लेक्सिंग और वेबसॉकेट दोनों के माध्यम से किया जा सकता है। तो कुछ ओवरलैप है, लेकिन WebSockets में अच्छी तरह से स्थापित प्रोटोकॉल, बहुत सारे रूपरेखा / एपीआई और कम हेडर ओवरहेड हैं। यहाँ विषय के बारे में अच्छा लेख है ।

Answer 7

HTTP / 2 में WebSocket कार्यान्वयन होगा। https://tools.ietf.org/html/rfc8441

Comments

नहीं, वहाँ नहीं ... WebSocket कनेक्शन को HTTP / 2 के माध्यम से टनल किया जाएगा , लेकिन HTTP / 2 प्रोटोकॉल को प्रतिस्थापित नहीं करेगा, और न ही यह अप्रचलित होगा।

— मिस्ट्री

@ मिस्ट क्या मैंने ऐसा कहा है?

— दजिंटर

नहीं, आपने ऐसा नहीं कहा, मैंने किया। आपने लिखा है कि HTTP / 2 में एक WebSocket कार्यान्वयन होगा, जो IMHO बहुत छोटा लग रहा था और महत्वपूर्ण विवरणों को छोड़ने के कारण कुछ भ्रामक है।

— मिस्ट्री

Answer 8

अप्रैल 2020 तक, HTTP / 2 वेबस्केट्स को अप्रचलित नहीं बना रहा है। HTTP2 पर WebSockets का सबसे बड़ा लाभ यह है कि

HTTP/2 works only on Browser Level not Application Level

इसका मतलब है कि HTTP / 2 संचार की अनुमति देने के लिए किसी भी JS API जैसे WebSockets की पेशकश नहीं करता है और किसी प्रकार के JSON या अन्य डेटा को सीधे अनुप्रयोग (जैसे वेबसाइट) से सर्वर पर स्थानांतरित करता है। इसलिए, जहाँ तक मेरा मानना ​​है, अगर सर्वर से बात करने के लिए यह वेबसॉकेट की तरह एपीआई की पेशकश शुरू करता है, तो HTTP / 2 केवल WebSockets को अप्रचलित बना देगा। जब तक कि यह HTTP 1.1 का सिर्फ अद्यतन और तेज संस्करण है।

Answer 9

आज के रूप में, नहीं।

HTTP की तुलना में HTTP / 2, आपको सर्वर के साथ संबंध बनाए रखने की अनुमति देता है। वहां से, आप एक ही समय में डेटा की कई स्ट्रीम कर सकते हैं। आशय यह है कि आप ग्राहक से अनुरोध किए बिना भी एक ही समय में कई चीजों को आगे बढ़ा सकते हैं। उदाहरण के लिए, जब कोई ब्राउज़र एक के लिए पूछता है index.html, तो सर्वर भी धक्का दे सकता है index.cssऔरindex.js । ब्राउज़र ने इसे नहीं मांगा, लेकिन सर्वर इसे बिना पूछे प्रदान कर सकता है क्योंकि यह मान सकता है कि आप कुछ सेकंड में चाहते हैं।

यह तेजी से होने का HTTP / 1 विकल्प की तुलना में है index.html, यह पार्स करने की जरूरत है यह खोज, index.jsऔर index.cssऔर उसके बाद उन फ़ाइलों के लिए 2 अन्य अनुरोधों का निर्माण। HTTP / 2 सर्वर को उन डेटा को धक्का देता है जो क्लाइंट ने भी नहीं मांगे हैं।

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

अन्य अंतर यह है कि आपको जावास्क्रिप्ट में WebSocket तक बहुत अधिक बढ़िया ट्यून एक्सेस मिलता है, जबकि HTTP के साथ, यह ब्राउज़र द्वारा नियंत्रित किया जाता है। तुम सब HTTP के साथ मिलता है जो कुछ भी आप में फिट कर सकते हैं XHR/ fetch()। (: जैसे कि भी मतलब ब्राउज़र आप इसे नियंत्रित करने में सक्षम होने के बिना अवरोधन और संशोधित HTTP हेडर को मिलेगा Origin, Cookies, आदि)। इसके अलावा, जो HTTP / 2 पुश करने में सक्षम है, वह ब्राउज़र को भेजा जाता है। इसका मतलब है कि जेएस हमेशा नहीं होता है (यदि कभी भी) पता है कि चीजों को धक्का दिया जा रहा है। फिर से, यह समझ में आता है index.cssऔर index.jsक्योंकि ब्राउज़र इसे कैश करेगा, लेकिन डेटा पैकेट के लिए इतना नहीं।

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

---

जिस पर हम वास्तव में चर्चा नहीं कर रहे हैं वह SSE (सर्वर-प्रेषण घटनाएँ) है। एप्लिकेशन (JS) में डेटा पुश करना HTTP / 2 का आशय नहीं है, लेकिन यह SSE के लिए है। HTTP / 2 से SSE वास्तव में मजबूत होता है। लेकिन यह वेबस्केट्स के लिए एक वास्तविक प्रतिस्थापन नहीं है जब महत्वपूर्ण यह है कि डेटा स्वयं है, न कि चर समापन बिंदु तक पहुंचा जा रहा है। WebSocket के साथ प्रत्येक समापन बिंदु के लिए एक नया डेटा स्ट्रीम बनाया जाता है, लेकिन SSE के साथ यह पहले से मौजूद HTTP / 2 सत्र के बीच साझा किया जाता है।

---

यहाँ संक्षेप में प्रत्येक के लिए उद्देश्य हैं:

• HTTP - एक संपत्ति के साथ एक अनुरोध का जवाब दें
• HTTP / 2 - कई संपत्तियों के साथ एक अनुरोध का जवाब दें
• SSE - एक यूनिडायरेक्शनल टेक्स्ट (UTF-8) ईवेंट स्ट्रीम के साथ प्रतिक्रिया दें
• WebSocket - एक द्विदिश द्विआधारी डेटा स्ट्रीम बनाएँ