सदस्य:Atindrakn/प्रयोगपृष्ठ
- पांडित्य HTTP2 और लाभ उठाने ब्राउज़र्स स्पीड
- यह ब्राउज़र गति के HTTP 2 और उन्नति रोशनी करने के लिए एक शोध पत्र है ।
एक सॉफ्टवेयर उपकरण उपयोगकर्ता के एजेंट हर टैब के लिए प्राथमिकता है और कैशिंग विन्यास सेट करने के लिए संभाल करने के लिए एक विकल्प हो जाएगा , जहां ब्राउज़रों के लिए विकसित किया जा सकता है । यह महज ब्राउज़र के टैब के संदर्भ में वृद्धि होगी। यह है कि वे वास्तव में पर काम कर रहे हैं उपयोगकर्ताओं पूर्वाग्रह बनाने के लिए जो HTTP / 2 मानक , की दिशा में एक पहल का काम है।
परिचय संपादित करें
Http आईईटीएफ और द्वारा समन्वित किया गया था HTTP की बुनियादी अनुरोध / प्रतिक्रिया अर्थ विज्ञान.यह मानकों के विकास उपलब्ध कराने के आवेदन स्तर प्रोटोकॉल है वर्ल्ड वाइड वेब कंसोर्टियम, प्रकाशन में बनी टिप्पणी के लिए अनुरोध की एक श्रृंखला RFC की । HTTP में सुधार या क्लाइंट और सर्वर के बीच संचार को सक्षम करने के मध्यवर्ती नेटवर्क तत्वों अनुमति देने के लिए बनाया गया है। Http एक सरल लेकिन शक्तिशाली प्रोटोकॉल है कि बनाने के तीन बुनियादी विशेषताएं हैं
- HTTP संयोजन है।
- HTTP स्वतंत्र मीडिया है।
- HTTP राज्यविहीन है।
इतिहास संपादित करें
HTTP / 2 (मूल नाम HTTP / 2.0) वर्ल्ड वाइड वेब के द्वारा उपयोग किए गए HTTP नेटवर्क प्रोटोकॉल का दूसरा बड़ा संस्करण है। यह SPDY HTTP / 2 पर आधारित है इंटरनेट इंजीनियरिंग टास्क फोर्स IETF के (बीआईएस "दो बार" "दोहराने" या मतलब है जहां httpbis,) और IESG पर प्रस्तावित मानक के रूप में प्रकाशित करने के लिए इसे मंजूरी दे दी हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल कार्य समूह द्वारा विकसित किया जा रहा है। फ़रवरी 17, 2015 SPDY HTTP के आवेदन परत और डेटा के प्रवाह को नियंत्रित करने के लिए टीसीपी परिवहन के बीच रहता है जो एक "सत्र" का परिचय। HTTP के 2.0 परिवहन परत के भीतर ही इन चिंताओं समाधानों पहले हमारे अनुप्रयोगों के भीतर किया HTTP 1.1 के कई पूर्ववत और पता करने के लिए हमें की अनुमति देकर संयोजन-हमारे अनुप्रयोगों तेज़, आसान, और अधिक मजबूत-एक दुर्लभ कर देगा। इससे भी अच्छी बात है, यह भी हमारे आवेदन अनुकूलन और प्रदर्शन में सुधार करने के लिए पूरी तरह से नए अवसरों की एक पूरी मेजबान को खोलता है।
HTTP का दिलचस्प सुविधा संपादित करें
- सामग्री बातचीत (आप परिणाम चाहते हैं कि कैसे सर्वर बताओ)
- डाटा टाइपिंग (सामग्री प्रकार)
- स्वतंत्रता डेटा सामग्री
- हेडर के माध्यम से एक्सटेंसिबल
- एन्क्रिप्शन / प्रमाणीकरण (एसएसएल)
- इंफ्रास्ट्रक्चर (प्रॉक्सी गेट तरीकों)
- कनेक्शन कम / कनेक्शन पूर्ण संकर (HTTP / 1.1 में)
- सर्वर की विशाल स्थापित आधार।
SPDY के लिए लक्ष्य संपादित करें
SPDY एक प्रयोगात्मक प्रोटोकॉल, गूगल पर विकसित की है और जिसका प्राथमिक लक्ष्य HTTP 1.1 के जाने-माने प्रदर्शन सीमाओं से कुछ को संबोधित द्वारा वेब पृष्ठों की लोड प्रतीक्षा अवधि कम करने के लिए प्रयास करने के लिए किया गया था 2009 के मध्य में की घोषणा की है। इस प्रकार के रूप विशेष रूप से उल्लिखित परियोजना लक्ष्य निर्धारित किया गया:
- पृष्ठ लोड समय में 50% की कमी को लक्ष्य बनाएं।
- वेबसाइट लेखकों द्वारा सामग्री में कोई परिवर्तन करने के लिए जरूरत से बचने।
- नेटवर्क के बुनियादी ढांचे में परिवर्तन से बचने, तैनाती जटिलता को कम।
- खुले स्रोत समुदाय के साथ साझेदारी में इस नए प्रोटोकॉल का विकास करना।
- प्रयोगात्मक प्रोटोकॉल को मान्य वास्तविक प्रदर्शन के आंकड़ों के (में) को इकट्ठा करो।
SPDY डिजाइन और सुविधा संपादित करें
- SPDY एक भी टीसीपी कनेक्शन पर कई समवर्ती, अन्तथपत्रण धाराओं के लिए अनुमति देता है कि एसएसएल के ऊपर एक सत्र परत कहते हैं।
- SPDY एन्कोडिंग और तार पर डाटा संचारित करने के लिए एक नया तैयार प्रारूप निर्दिष्ट करता है।
- धाराओं यानी, द्वि-दिशात्मक हैं क्लाइंट और सर्वर के द्वारा शुरू किया जा सकता।
- SPDY (हमेशा सक्षम) बुनियादी और उन्नत (वैकल्पिक सक्षम) सुविधाओं के माध्यम से कम विलंबता को प्राप्त करना है।
SPDY डिजाइन संपादित करें
बहुसंकेतन संपादित करें
दूरसंचार और कंप्यूटर नेटवर्क में, बहुसंकेतन कई अनुरूप संदेश संकेतों या डिजिटल डेटा धाराओं एक साझा माध्यम पर एक संकेत में संयुक्त रहे हैं जिसके द्वारा एक विधि है। उद्देश्य के लिए एक महंगा संसाधन साझा करने के लिए है।
हैडर संपीड़न संपादित करें
हैडर संपीड़न अनुरोध हेडर के आकार और प्रतिक्रिया हेडर के आकार में एक ~ 85% की कमी में एक ~ 88% की कमी हुई। विशेष रूप से अपलोड लिंक केवल 375 केबीपीएस है जिसमें कम बैंडविड्थ डीएसएल लिंक, अनुरोध हेडर संपीड़न पर, कुछ साइटों के लिए महत्वपूर्ण पृष्ठ लोड समय सुधार (संसाधन अनुरोधों की बड़ी संख्या को जारी करने वाले यानी उन) का नेतृत्व किया। संपीड़न शीर्षक के बस की वजह से पेज लोड समय में 45 - 1142एमएस की कमी पाया।
सर्वर पुश संपादित करें
पुश, या सर्वर धक्का, एक दिया लेन-देन के लिए अनुरोध प्रकाशक या केंद्रीय सर्वर द्वारा शुरू की है, जहां इंटरनेट आधारित संचार की एक शैली का वर्णन करता है। यह सूचना के प्रसारण के लिए अनुरोध रिसीवर या ग्राहक द्वारा शुरू की है, जहां पुल / मिलता है, के विपरीत है।
HTTP 1.1 में कैशिंग का लक्ष्य संपादित करें
HTTP 1.1 में कैशिंग के लक्ष्य के कई मामलों में अनुरोध भेजने के लिए, और कई अन्य मामलों में पूर्ण प्रतिक्रियाओं भेजने के लिए आवश्यकता को समाप्त करने की आवश्यकता को समाप्त करने के लिए है। Http आम तौर पर प्रदर्शन प्रतिक्रिया कैश के उपयोग के द्वारा सुधार किया जा सकता है, जहां वितरित सूचना प्रणाली, के लिए प्रयोग किया जाता है। HTTP 1.1 प्रोटोकॉल कैशिंग काम करने का इरादा तत्वों की एक संख्या शामिल है।
HTTP 2.0 के लिए रास्ता संपादित करें
- SPDY HTTP के 2.0 के लिए उत्प्रेरक था, लेकिन SPDY HTTP के 2.0 नहीं है।
- HTTP के 2.0 प्रस्तावों के लिए एक खुला कॉल जल्दी 2012 में बनाया गया था।
- तब से, कई परिवर्तन और सुधार किया गया है और सरकारी HTTP 2.0 मानक के लिए किया जाना जारी रहेगा।
HTTP/2.0 से उम्मीद संपादित करें
- पर्याप्त और कुछ हद तक टीसीपी का उपयोग करने के लिए HTTP 1.1 से अधिक है, ज्यादातर मामलों में अंतिम-उपयोगकर्ता कथित विलंबता में सुधार होगा।
- HTTP में "लाइन अवरुद्ध के सिर" समस्या का समाधान।
- HTTP विधि, स्थिति कोड, उड़ी है, मौजूदा प्रलेखन का लाभ सहित (लेकिन सीमित नहीं है), HTTP के 1.1 के शब्दों को रखें, और जहां उपयुक्त हो, शीर्षक क्षेत्रों।
- स्पष्ट रूप से परिभाषित कैसे HTTP के लिए विशेष रूप से बिचौलियों में HTTP 1.x के साथ 2.0 सूचना का आदान प्रदान।
- स्पष्ट रूप से उनके उचित उपयोग के लिए किसी भी नए एक्स्टेंसिबल अंक और नीति की पहचान।
- ऐसा नहीं है, इस प्रकार, विशेष रूप से भीड़ नियंत्रण के संबंध में, टीसीपी के अपने प्रयोग में सुधार, समानता सक्षम करने के लिए एक सर्वर के लिए एकाधिक कनेक्शन की आवश्यकता है।
तकनीक और विश्लेषण संपादित करें
कई ड्राफ्ट और पहले से ही HTTP / 2 के बारे में उल्लेख किया गया है कि दस्तावेजों के माध्यम से, इसलिए मानक में आगे सुधार नहीं होता है करके।
I: कैशिंग संपादित करें
HTTP/2 के बाद से वे कैशिंग मुश्किल या असंभव या तो बना रहे हैं एक एन्क्रिप्टेड चैनल पर लगभग सब कुछ करने का प्रस्ताव किया है।
- लाभ उठाने ब्राउज़र की कैशिंग
- यदि आप एक संसाधन के लिए एक समय सीमा समाप्त हो हेडर सेट करते हैं, इस तरह के सभी जेपीईजी छवियों के रूप में, ब्राउज़र अपने कैश में उन संसाधनों की दुकान है। उन छवियों को उपलब्ध पहले से ही करनी होगी ब्राउज़र के रूप में आगंतुक वापस पृष्ठ के लिए आता है अगली बार यह तेजी से लोड होगा।
- प्रत्येक संसाधन निम्नलिखित प्रश्नों के उत्तर देता है कि एक स्पष्ट कैशिंग नीति निर्दिष्ट करना चाहिए:
- संसाधन कैश किया और किसके द्वारा कितनी देर के लिए, और यदि लागू हो, यह कुशलतापूर्वक फिर से मान्य किया जा सकता है कि कैसे कैशिंग नीति को समाप्त हो रहा है जब किया जा सकता है।
- सर्वर कोई प्रतिक्रिया देता है जब यह कैश नियंत्रण और ई-टैग हेडर प्रदान करनी चाहिए।
II: streams के पुनः प्राथमिकता संपादित करें
उपयोगकर्ताओं को अक्सर ब्राउज़र में एकाधिक टैब के बीच स्विच। उपयोगकर्ता कार्यों स्विच जब उपयोगकर्ता अब एक उच्च प्राथमिकता पर अलग अलग डेटा चाहता है के रूप में, प्रोटोकॉल प्राथमिकता में एक बदलाव के लिए अनुमति चाहिए। एक टैब के लिए संसाधनों की रिश्तेदार प्राथमिकता ही है या बड़ा होने की 100% संभावना है जो अनुरोधों की संख्या (करने के लिए आनुपातिक परिवर्तन का एक नंबर बनाने के लिए होने के बजाय एक बार में सभी प्रबंधित किया जा सकता है तो यह संभावना प्राथमिकता समूह बनाने शामिल होगा।)
- streams के पुन-प्राथमिकता
- एक टैब ब्राउज़र पर विचार करें। प्रत्येक टैब का अपना अनुरोधों के दर्जनों जारी कर सकता है। ब्राउज़र ध्यान केंद्रित टैब से अनुरोध प्राथमिकता चाहिए। पृष्ठभूमि टैब नेटवर्क संसाधनों के शेष प्राप्त करते हैं।
- स्विचिंग टैब कुशलता से उचित रूप से पुराने और नए टैब से अनुरोध फिर से प्राथमिकता चाहिए।
- प्राथमिकता एल्गोरिथ्म
- निर्दिष्ट क्रम में अनुक्रमिक (ए सी से पहले बी से पहले ...)
- (अगले पहले ए, बी, सी, लेकिन एक के सभी) कोई विशेष क्रम में अनुक्रमिक
- समांतर (ए, बी, सी, कनेक्शन पर निकालना)
- फेयरनेस (संसाधन {ए, बी, सी} और {एक्स, वाई, जेड} के बीच समान रूप से आवंटित।)
- पुनः प्राथमिकता
- समानांतर समूह निर्भरता ({ए, बी, सी}, समानांतर में, {डी, ई, एफ} से पहले, भी समानांतर में सब।
- रिक्तिपूर्व निराकरण
- प्राथमिकताओं के रूप में प्रयोग करें वजन
- सभी निर्भर धाराओं 1 और 256 (सम्मिलित) के बीच एक पूर्णांक वजन आवंटित कर रहे हैं।
स्वामी प्राथमिकता
- स्वामी प्राथमिकता
- हम अपने ही प्राथमिकता के तरीकों को परिभाषित करने और ग्राहक उनके प्रदर्शन के हिसाब से चयन करने के लिए अनुमति देता है।
कब और कैसे इसे जाना जायेगा? संपादित करें
- HTTP / 2 का एक मसौदा संस्करण पहले से ही प्रौद्योगिकी रह जाने के लिए तैयार है जिसका मतलब है कि IETF द्वारा अनुमोदित किया गया है। संभावना है कि वेबसाइटों की एक बहुत पहले से ही HTTP / 2 पर चल रहे हैं ताकि हालांकि, इस तरह के मामलों में, प्रौद्योगिकी आमतौर पर, लागू किया है और परीक्षण किया है।
- आधुनिक ब्राउज़रों नई तकनीक के साथ नाव पर पहले से ही कर रहे हैं: गूगल क्रोम पहले से ही (इस प्रकार यह डिफ़ॉल्ट रूप से अक्षम है, लेकिन आप आसानी से इसे सक्षम कर सकते हैं), मोज़िला फ़ायरफ़ॉक्स यह 36 का निर्माण शुरू करने का समर्थन करता है, और माइक्रोसॉफ्ट इंटरनेट एक्सप्लोरर संस्करण विंडोज में एम्बेडेड इसका समर्थन करता है 10 के रूप में अच्छी तरह से इसके लिए समर्थन किया है।
- HTTP / 2 जी जाने के लिए तैयार है, साइटों की एक बहुत है, इस प्रकार आप भी यह जानने के बिना पहले से ही इस्तेमाल किया जा सकता है, जो पहले से ही इसके साथ प्रयोग कर रहे हैं। साइटों orbrowsers यदि आप एक HTTP / 2 कनेक्शन या एक पारंपरिक HTTP के एक पर कर रहे हैं कि क्या संकेत नहीं हो सकता के रूप में एड्रेस बार में देख रहे हैं, या तो मदद नहीं करेगा। यह तेजी से धधकते है - इस बिंदु पर बताने के लिए एक ही रास्ता है कि आप जिस साइट पर हैं की गति से है? संभावना है कि यह HTTP / 2 चल रहा है कर रहे हैं।
निष्कर्ष संपादित करें
- कैश नियंत्रण नीति और फिर से प्राथमिकता धाराओं की मदद से हम अपने ब्राउज़र की गति और विलंबता उत्तोलन कर सकते हैं।
- सर्वर हम अब तक का निर्माण किया है और अधिक से अधिक खुफिया लागू कर सकते हैं। हम इतने पर पहले से लाई जा रही सुझाव के लिए ग्राहक नेटवर्क के बारे में जानकारी प्राप्त करने के लिए, और, सर्वर शुरू की धाराओं के क्षेत्रों में और अधिक शोध की जरूरत है।
- प्राथमिकता विधियों का प्रयोग हम कुछ हद तक बैंडविड्थ प्रदर्शन को बढ़ा सकते हैं।
- डायल-अप बैंडविड्थ दक्षता दर उच्च गति कनेक्शन दक्षता के लिए, 90% के करीब है हालांकि केवल 32% ~ के बारे में है।