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




http2 (5)

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

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


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

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

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



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

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

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


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

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

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

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

इसके अलावा, 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 के उपयोग को समाप्त करता है।


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

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

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

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

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

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

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

धाराएँ समापन बिंदु द्वारा बंद की जा सकती हैं।

infoq.com/articles/websocket-and-http2-coexist तरह के लेख (दूसरे उत्तर में जुड़े) 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 स्पेक्स (यह एक विशाल, जटिल कल्पना) है, तो शायद वेबसोकेट बेहतर है। कार्यान्वयन कठिनाई के बारे में हमारे हाथ लहराते हुए, मुझे विश्वास है कि वेबसोकेट प्रोटोकॉल का अनुपालन हमेशा HTTP / 2 - HTTP / 2 की तुलना में कम कम्प्यूटेशनल रूप से महंगा होने वाला है, बस आपको अधिक सामान करने की आवश्यकता है।

फ़्रेम का आकार बहुत तुलनीय है। HTTP / 2 के स्थिर 9 की तुलना में वेबसोकेट फ़्रेम थोड़ा छोटा है, प्रति फ्रेम ओवरहेड 2-14 है। क्योंकि वेबसैट एक वैरिएबल लेंथ हेडर के लिए चुना गया है, यह बड़े फ्रेम को एन्कोड कर सकता है (2 ^ 64-1 बिट्स प्रति फ्रेम बनाम) HTTP / 2 2 ^ 24-1 बिट प्रति फ्रेम)। इसलिए अगर आपको बहुत सारे समारोह के बिना कुछ वसा चूसने के लिए सॉकेट की आवश्यकता होती है, जैसे, मुझे नहीं पता, शायद वीडियो फ्रेम, तो वेबस्कैट अभी भी समझ में आ सकता है। अधिकांश उपयोग के मामलों के लिए, विशेष रूप से वेब पेज से संबंधित चीजें, मुझे लगता है कि HTTP / 2 आगे बढ़ने के तरीके की तरह दिखता है।