क्या कोई व्यक्ति HTTP / 2 के संबंध में मल्टीप्लेक्सिंग की व्याख्या कर सकता है और यह कैसे काम करता है?
जवाबों:
सीधे शब्दों में कहें, मल्टीप्लेक्सिंग आपके ब्राउज़र को एक ही कनेक्शन पर एक ही बार में कई अनुरोधों को बंद करने और किसी भी क्रम में अनुरोधों को प्राप्त करने की अनुमति देता है।
और अब बहुत अधिक जटिल उत्तर के लिए ...
जब आप एक वेब पेज लोड करते हैं, तो यह HTML पेज डाउनलोड करता है, यह देखता है कि इसे कुछ सीएसएस, कुछ जावास्क्रिप्ट, छवियों का एक लोड ... आदि की आवश्यकता है।
HTTP / 1.1 के तहत आप केवल एक बार अपने HTTP / 1.1 कनेक्शन पर एक डाउनलोड कर सकते हैं। तो आपका ब्राउज़र HTML डाउनलोड करता है, फिर वह CSS फ़ाइल पूछता है। जब वह लौटा तो यह जावास्क्रिप्ट फाइल के लिए पूछता है। जब वह लौटा तो यह पहली छवि फ़ाइल के लिए पूछता है ... आदि HTTP / 1.1 मूल रूप से तुल्यकालिक है - एक बार जब आप एक अनुरोध भेजते हैं तो आप तब तक अटक जाते हैं जब तक आपको कोई प्रतिक्रिया नहीं मिलती। इसका मतलब यह है कि अधिकांश समय ब्राउज़र बहुत कुछ नहीं कर रहा है, क्योंकि इसने एक अनुरोध को निकाल दिया है, एक प्रतिक्रिया की प्रतीक्षा कर रहा है, फिर एक और अनुरोध बंद कर देता है, फिर एक प्रतिक्रिया की प्रतीक्षा कर रहा है ... आदि के साथ बेशक जटिल साइटें। बहुत से जावास्क्रिप्ट को ब्राउज़र को बहुत अधिक प्रसंस्करण करने की आवश्यकता होती है, लेकिन यह जावास्क्रिप्ट पर डाउनलोड किए जाने पर निर्भर करता है, कम से कम शुरुआत के लिए, HTTP / 1.1 को विरासत में मिलने वाली देरी समस्याओं का कारण बनती है। आमतौर पर सर्वर isn '
तो वेब पर मुख्य मुद्दों में से एक आज ब्राउज़र और सर्वर के बीच अनुरोध भेजने में नेटवर्क विलंबता है। यह केवल दसियों या शायद सैकड़ों मिलीसेकंड हो सकता है, जो कि ज्यादा प्रतीत नहीं हो सकता है, लेकिन वे जोड़ते हैं और अक्सर वेब ब्राउज़िंग का सबसे धीमा हिस्सा होता है - विशेष रूप से वेबसाइटों को अधिक जटिल और अतिरिक्त संसाधनों की आवश्यकता होती है (जैसा कि वे प्राप्त कर रहे हैं) और इंटरनेट का उपयोग मोबाइल के माध्यम से तेजी से बढ़ रहा है (ब्रॉडबैंड की तुलना में धीमी विलंबता के साथ)।
एक उदाहरण के रूप में मान लें कि 10 संसाधन हैं जो HTML के लोड होने के बाद आपके वेब पेज को लोड करने की आवश्यकता है (जो कि आज के मानकों से बहुत छोटी साइट है क्योंकि 100+ संसाधन सामान्य है, लेकिन हम इसे सरल रखेंगे और इसके साथ चलेंगे उदाहरण)। और मान लें कि प्रत्येक अनुरोध इंटरनेट से वेब सर्वर और वापस यात्रा करने के लिए 100ms का समय लेता है और किसी भी छोर पर प्रसंस्करण का समय नगण्य है (आइए इस उदाहरण के लिए 0 को सादगी के लिए कहते हैं)। जैसा कि आपको प्रत्येक संसाधन भेजना होगा और एक समय में एक प्रतिक्रिया की प्रतीक्षा करनी होगी, यह पूरी साइट डाउनलोड करने के लिए 10 * 100ms = 1,000ms या 1 सेकंड का समय लगेगा।
इसके आस-पास जाने के लिए, ब्राउज़र आमतौर पर वेब सर्वर (आमतौर पर 6) के लिए कई कनेक्शन खोलते हैं। इसका मतलब है कि एक ब्राउज़र एक ही समय में कई अनुरोधों को बंद कर सकता है, जो बहुत बेहतर है, लेकिन कई कनेक्शन स्थापित करने और प्रबंधित करने की जटिलता की कीमत पर (जो ब्राउज़र और सर्वर दोनों को प्रभावित करता है)। चलो पिछले उदाहरण को जारी रखते हैं और यह भी कहते हैं कि 4 कनेक्शन हैं और सादगी के लिए, मान लें कि सभी अनुरोध समान हैं। इस स्थिति में आप सभी चार कनेक्शनों में अनुरोधों को विभाजित कर सकते हैं, इसलिए दो में 3 संसाधन होंगे, और दो के पास पूरी तरह से दस संसाधन प्राप्त करने के लिए 2 संसाधन होंगे (3 + 3 + 2 + 2 = 10)। उस मामले में सबसे खराब स्थिति 3 बार या 300ms = 0.3 सेकंड है - एक अच्छा सुधार, लेकिन इस सरल उदाहरण में उन कई कनेक्शनों को स्थापित करने की लागत शामिल नहीं है,
HTTP / 2 आपको उसी पर कई अनुरोध भेजने की अनुमति देता हैकनेक्शन - इसलिए आपको ऊपर दिए अनुसार कई कनेक्शन खोलने की आवश्यकता नहीं है। तो आपका ब्राउज़र कह सकता है "इस CSS फ़ाइल को Gimme। Gimme उस जावास्क्रिप्ट फ़ाइल को। Gimme image1.jpg। Gimme image2.jpg ... आदि ..." पूरी तरह से एक एकल कनेक्शन का उपयोग करने के लिए। यह एक नि: शुल्क कनेक्शन की प्रतीक्षा कर रहे उन अनुरोधों को भेजने में देरी न करने का स्पष्ट प्रदर्शन लाभ है। ये सभी अनुरोध इंटरनेट (लगभग) समानांतर में सर्वर के माध्यम से अपना रास्ता बनाते हैं। सर्वर हर एक को जवाब देता है, और फिर वे अपना रास्ता बनाना शुरू कर देते हैं। वास्तव में यह उस से भी अधिक शक्तिशाली है क्योंकि वेब सर्वर उन्हें किसी भी क्रम में अपनी प्रतिक्रिया दे सकता है जैसा वह महसूस करता है और विभिन्न क्रमों में फाइलें वापस भेजता है, या यहां तक कि टुकड़ों में मांगी गई प्रत्येक फाइल को तोड़ता है और फाइलों को एक साथ मिलाता है।लाइन अवरोधन मुद्दे के प्रमुख)। वेब ब्राउज़र को तब सभी टुकड़ों को एक साथ रखने का काम सौंपा जाता है। सर्वोत्तम स्थिति में (कोई बैंडविड्थ सीमा नहीं मानकर - नीचे देखें), यदि सभी 10 अनुरोधों को समानांतर में एक बार में बहुत अधिक निकाल दिया जाता है, और सर्वर द्वारा तुरंत उत्तर दिया जाता है, तो इसका मतलब है कि आपके पास मूल रूप से एक दौर की यात्रा या 100ms या 0.1 सेकंड है, सभी 10 संसाधन डाउनलोड करें। और यह कोई भी downsides कि HTTP / 1.1 के लिए कई कनेक्शन था! यह बहुत अधिक स्केलेबल है क्योंकि प्रत्येक वेबसाइट पर संसाधन बढ़ते हैं (वर्तमान में HTTP / 1.1 के तहत 6 समानांतर कनेक्शन के लिए ब्राउज़र खुलते हैं लेकिन क्या साइटों को और अधिक जटिल हो जाना चाहिए?)।
यह आरेख अंतर दिखाता है, और एक एनिमेटेड संस्करण भी है ।
नोट: HTTP / 1.1 में पाइपलाइनिंग की अवधारणा है जो कई अनुरोधों को एक बार में भेजने की अनुमति देता है। हालाँकि, अभी भी उन्हें वापस करने का आदेश दिया गया था, जो वे अपनी संपूर्णता में अनुरोध कर रहे थे, इसलिए कहीं भी HTTP / 2 जितना अच्छा नहीं है, भले ही वैचारिक रूप से यह समान हो। इस तथ्य का उल्लेख नहीं करने के लिए यह दोनों ब्राउज़रों और सर्वरों द्वारा इतनी खराब रूप से समर्थित है कि इसका उपयोग शायद ही कभी किया जाता है।
नीचे टिप्पणी में एक बात पर प्रकाश डाला गया है कि कैसे बैंडविड्थ हमें यहाँ प्रभावित करती है। बेशक आपका इंटरनेट कनेक्शन इस बात से सीमित है कि आप कितना डाउनलोड कर सकते हैं और HTTP / 2 इसे संबोधित नहीं करता है। इसलिए यदि उपरोक्त उदाहरणों में जिन 10 संसाधनों पर चर्चा की गई है, वे सभी बड़े पैमाने पर प्रिंट-गुणवत्ता वाले चित्र हैं, फिर भी वे डाउनलोड करने के लिए धीमा होंगे। हालांकि, अधिकांश वेब ब्राउज़र के लिए, बैंडविड्थ विलंबता की तुलना में किसी समस्या से कम नहीं है। इसलिए यदि वे दस संसाधन छोटे आइटम हैं (विशेषकर सीएसएस और जावास्क्रिप्ट जैसे पाठ संसाधन जिन्हें छोटे होने के लिए gzipped किया जा सकता है), जैसा कि वेबसाइटों पर बहुत आम है, तो बैंडविड्थ वास्तव में एक मुद्दा नहीं है - यह संसाधनों का सरासर मात्रा है जो अक्सर होता है समस्या और HTTP / 2 उस पते को दिखता है। यह इसलिए भी है क्योंकि HTTP / 1.1 में एक और वर्कअराउंड के रूप में कॉन्टेनेट का उपयोग किया जाता है, इसलिए उदाहरण के लिए सभी CSS अक्सर एक फाइल में एक साथ शामिल हो जाते हैं:HTTP / 2 के तहत विरोधी पैटर्न - हालांकि इसके पूरी तरह से दूर करने के भी तर्क हैं)।
इसे एक वास्तविक दुनिया उदाहरण के रूप में रखने के लिए: मान लें कि आपको होम डिलीवरी के लिए एक दुकान से 10 आइटम ऑर्डर करने होंगे:
एक कनेक्शन के साथ HTTP / 1.1 का मतलब है कि आपको उन्हें एक समय में एक ऑर्डर करना होगा और अंतिम आने तक आप अगले आइटम को ऑर्डर नहीं कर सकते। आप समझ सकते हैं कि हर चीज के माध्यम से इसे प्राप्त करने में सप्ताह लगेंगे।
कई कनेक्शन के साथ HTTP / 1.1 का मतलब है कि आपके पास एक ही समय में स्वतंत्र आदेशों की संख्या (सीमित) हो सकती है।
HTTP / 1.1 के साथ पाइपलाइनिंग का अर्थ है कि आप बिना प्रतीक्षा किए एक के बाद एक सभी 10 वस्तुओं के लिए पूछ सकते हैं, लेकिन फिर वे सभी आपके लिए पूछे गए विशिष्ट क्रम में पहुंच जाते हैं। और यदि कोई वस्तु स्टॉक से बाहर है तो आपको इसके लिए प्रतीक्षा करनी होगी इससे पहले कि आपके द्वारा ऑर्डर की गई वस्तुएं प्राप्त हो जाएं - भले ही बाद में वे आइटम वास्तव में स्टॉक में हों! यह थोड़ा बेहतर है, लेकिन अभी भी देरी के अधीन है, और चलो कहते हैं कि अधिकांश दुकानें वैसे भी आदेश देने के इस तरीके का समर्थन नहीं करती हैं।
HTTP / 2 का अर्थ है कि आप अपने सामान को किसी विशेष क्रम में - बिना किसी देरी के (जैसे ऊपर) ऑर्डर कर सकते हैं। जैसे ही वे तैयार होंगे, दुकान उन्हें भेज देगी, इसलिए वे आपके द्वारा मांगे जाने की तुलना में एक अलग क्रम में आ सकते हैं, और वे वस्तुओं को विभाजित भी कर सकते हैं, इसलिए उस क्रम के कुछ हिस्से पहले पहुंचते हैं (इसलिए ऊपर से बेहतर)। अंतत: इसका मतलब यह है कि आपको 1) सब कुछ जल्दी मिल जाएगा और 2) प्रत्येक आइटम पर काम करना शुरू कर सकता है क्योंकि यह आता है ("ओह, यह उतना अच्छा नहीं है जितना मैंने सोचा था कि यह होगा, इसलिए मैं कुछ और भी या इसके बजाय ऑर्डर करना चाहता हूं" )।
बेशक, आप अभी भी अपने डाकिया के वैन (बैंडविड्थ) के आकार तक सीमित हैं, इसलिए उन्हें अगले दिन तक कुछ पैकेज वापस छँटाई कार्यालय में छोड़ने पड़ सकते हैं, यदि वे उस दिन के लिए भरे हुए हैं, लेकिन इसकी तुलना में शायद ही कोई समस्या है। वास्तव में देरी को वापस और पीछे आदेश भेजने में। अधिकांश वेब ब्राउजिंग में भारी पैकेजों के बजाय छोटे अक्षरों को आगे और पीछे भेजना शामिल है।
उम्मीद है की वो मदद करदे।
मल्टीप्लेक्सिंग का अनुरोध करें
HTTP / 2 एकल टीसीपी कनेक्शन पर समानांतर में डेटा के लिए कई अनुरोध भेज सकता है। यह HTTP / 2 प्रोटोकॉल की सबसे उन्नत विशेषता है क्योंकि यह आपको एक सर्वर से अतुल्यकालिक रूप से वेब फ़ाइलों को डाउनलोड करने की अनुमति देता है। अधिकांश आधुनिक ब्राउज़र टीसीपी कनेक्शन को एक सर्वर तक सीमित करते हैं। यह अतिरिक्त राउंड ट्रिप टाइम (RTT) को कम करता है, जिससे आपकी वेबसाइट बिना किसी अनुकूलन के तेजी से लोड होती है, और डोमेन शार्डिंग को अनावश्यक बना देती है।
सरल उत्तर ( स्रोत ):
मल्टीप्लेक्सिंग का अर्थ है कि आपका ब्राउज़र एक से अधिक अनुरोध भेज सकता है और एकल टीसीपी कनेक्शन में कई प्रतिक्रियाएं प्राप्त कर सकता है। तो DNS लुकअप और हैंडशेक से जुड़े कार्यभार को उसी सर्वर से आने वाली फ़ाइलों के लिए सहेजा जाता है।
जटिल / विस्तृत उत्तर:
@BazzaDP द्वारा प्रदान किए गए उत्तर को देखें।
HTTP 2.0 में मल्टीप्लेक्सिंग ब्राउज़र और सर्वर के बीच संबंध का प्रकार है जो समानांतर में कई अनुरोधों और प्रतिक्रियाओं को वितरित करने के लिए एकल कनेक्शन का उपयोग करता है, इस प्रक्रिया में कई व्यक्तिगत फ्रेम बनाता है।
मल्टीप्लेक्सिंग सख्त अनुरोध-प्रतिक्रिया के शब्दार्थ से अलग हो जाता है और एक-से-कई या कई-कई रिश्तों को सक्षम करता है।
चूँकि @Juanma Menendez उत्तर सही है, जबकि उनका आरेख भ्रमित है, मैंने इसे सुधारने का फैसला किया, बहुसंकेतन और पाइपलाइनिंग के बीच के अंतर को स्पष्ट करते हुए, जो धारणाएं अक्सर भ्रमित होती हैं।
पाइपलाइनिंग (HTTP / 1.1)
एक ही HTTP कनेक्शन पर कई अनुरोध भेजे जाते हैं । उसी क्रम में प्रतिक्रियाएँ प्राप्त होती हैं। यदि पहली प्रतिक्रिया में बहुत समय लगता है, तो अन्य प्रतिक्रियाओं को लाइन में इंतजार करना पड़ता है। सीपीयू पाइपलाइनिंग के समान जहां एक निर्देश प्राप्त होता है जबकि एक दूसरे को डिकोड किया जा रहा है। एक ही समय में कई निर्देश उड़ान में हैं, लेकिन उनका क्रम संरक्षित है।
मल्टीप्लेक्सिंग (HTTP / 2)
एक ही HTTP कनेक्शन पर कई अनुरोध भेजे जाते हैं । जवाबदेही आदेश में प्राप्त होती है। धीमी प्रतिक्रिया के लिए प्रतीक्षा करने की आवश्यकता नहीं है जो दूसरों को रोक रही है। आधुनिक सीपीयू में आउट-ऑफ-ऑर्डर निर्देश निष्पादन के समान।
उम्मीद है कि बेहतर छवि अंतर स्पष्ट करती है:
