Http2 स्पष्टीकरण

दूसरे दिन, डैनियल श्टेनबर्ग, HTTPbis IETF समूह के सदस्यों में से एक, जो http2 प्रोटोकॉल विकसित कर रहा है, ने अपने ब्लॉग पर एक बेहद दिलचस्प दस्तावेज "http2 समझाया" प्रकाशित किया। एक बहुत ही सुलभ भाषा में 26 पृष्ठों पर एक छोटा पीडीएफ दस्तावेज़ परिसर और http2 प्रोटोकॉल के कार्यान्वयन के विवरण के बारे में बात करता है।



यह मुझे लगता है कि आज यह http2 प्रोटोकॉल क्या है, इसकी आवश्यकता के बारे में सबसे अच्छी व्याख्याओं में से एक है, यह वेब विकास को कैसे प्रभावित करेगा और भविष्य में इंटरनेट के लिए क्या उपस्थिति रखता है। मुझे लगता है कि वेब डेवलपमेंट और वेब बिल्डिंग से जुड़े सभी लोग जानकारी को उपयोगी पाएंगे, क्योंकि यह उम्मीद है कि http2 मानक इस साल जून में न्यूयॉर्क में HTTPbis समूह की अंतिम बैठक के बाद अपनाया जाएगा।



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



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

http2

इतिहास, प्रोटोकॉल, कार्यान्वयन और भविष्य

daniel.haxx.se/http2

कहानी

यह एक तकनीकी और प्रोटोकॉल स्तर के दृष्टिकोण से http2 का वर्णन करने वाला एक दस्तावेज है। यह मूल रूप से एक प्रस्तुति के रूप में दिखाई दिया जिसे मैंने अप्रैल 2014 में स्टॉकहोम में प्रस्तुत किया था। तब से मुझे उन लोगों से प्रस्तुति की सामग्री के बारे में कई सवाल मिले हैं जो घटना में शामिल नहीं हो सकते थे, इसलिए मैंने इसे विवरण और उचित स्पष्टीकरण के साथ एक पूर्ण दस्तावेज़ में बदलने का फैसला किया।

लेखन के समय (28 अप्रैल, 2014), अंतिम http2 विनिर्देशन न तो पूरा हुआ और न ही जारी किया गया। ड्राफ्ट के वर्तमान संस्करण को ड्राफ्ट -12 कहा जाता है, लेकिन हम http2 के पूरा होने से पहले कम से कम एक और संस्करण देखने की उम्मीद करते हैं। यह दस्तावेज़ वर्तमान स्थिति का वर्णन करता है, जो अंतिम विनिर्देश में बदल भी सकता है और नहीं भी। इस दस्तावेज़ की सभी त्रुटियां मेरी अपनी हैं, जो मेरी गलती के कारण दिखाई दीं। कृपया मुझे उनके बारे में बताएं और मैं एक पैच अपडेट जारी करूंगा।



इस दस्तावेज़ का संस्करण 1.2 है।

लेखक

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



ईमेल: daniel@haxx.se

ट्विटर: @ हैंडबैग

वेब: daniel.haxx.se

ब्लॉग: daniel.haxx.se/blog

मदद!

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



यह दस्तावेज़ daniel.haxx.se/http2 पर उपलब्ध है

लाइसेंस

यह दस्तावेज़ क्रिएटिव कॉमन्स एट्रिब्यूशन 4.0 लाइसेंस के तहत लाइसेंस प्राप्त है: creativecommons.org/licenses/by/4.0

HTTP आज

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

HTTP 1.1 बहुत बड़ा है

जब HTTP बना और दुनिया के लिए जारी किया गया था, तो यह संभवतः एक सरल और सरल प्रोटोकॉल के रूप में अधिक माना जाता था, लेकिन समय ने दिखाया है कि यह नहीं है। RFC 1945 में HTTP 1.0 1996 में जारी विनिर्देशन का 60 पृष्ठ है। RFC 2616, जिसमें HTTP 1.1 का वर्णन किया गया था, 1999 में केवल तीन साल बाद जारी किया गया था और यह 176 पृष्ठों तक बढ़ गया है। इसके अलावा, जब हम आईईटीएफ में विनिर्देश को अद्यतन करने पर काम कर रहे थे, तो यह कुल छह और अधिक पृष्ठों वाले छह दस्तावेजों में विभाजित हो गया। एक शक के बिना, HTTP 1.1 बड़ा है और इसमें विवरणों, सूक्ष्मताओं और कम वैकल्पिक अनुभागों के असंख्य शामिल हैं।

विकल्पों की दुनिया

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

बाद में जब ग्राहकों और सर्वरों ने इन विशेषताओं का अधिक सक्रिय रूप से उपयोग करना शुरू किया तो यह अनुकूलता का कारण बना। HTTP पाइपलाइनिंग ( HTTP पाइपलाइनिंग ) इस तरह की विशेषताओं का सबसे अच्छा उदाहरण है।

टीसीपी का अवर उपयोग

HTTP 1.1 वास्तव में टीसीपी द्वारा प्रदान की जाने वाली शक्ति और प्रदर्शन का सही लाभ उठाने के लिए एक लंबा रास्ता तय कर चुका है। पृष्ठ लोड समय को कम करने के तरीके खोजने के लिए HTTP क्लाइंट और ब्राउज़र को वास्तव में आविष्कारशील होना चाहिए।



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



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

पारेषण का आकार और वस्तुओं की संख्या

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



जैसा कि चार्ट दिखाता है, प्रवृत्ति बढ़ रही थी, लेकिन बाद में कोई संकेत नहीं हैं कि यह बदलता रहेगा।

देरी मारता है

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



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







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

ब्लॉक कतार शुरू

HTTP पाइपलाइनिंग एक अन्य अनुरोध भेजने का एक तरीका है, पहले से ही पिछले अनुरोध के जवाब की प्रतीक्षा कर रहा है। यह सुपरमार्केट या बैंक में कैशियर के लिए एक लाइन की तरह दिखता है। आप नहीं जानते कि आपके सामने किस तरह के लोग हैं: तेज ग्राहक या कष्टप्रद लोग जिन्हें सेवा पूरी करने के लिए अंतहीन समय की आवश्यकता है - कतार की शुरुआत को अवरुद्ध करना।







बेशक, आप सावधानी से एक कतार चुन सकते हैं और अंततः एक को चुन सकते हैं जो आपको लगता है कि सही है, और कभी-कभी आप अपनी खुद की कतार बना सकते हैं, लेकिन अंत में, आप एक निर्णय लेने से बच नहीं सकते हैं और एक बार जब आप कतार का चयन करते हैं, तो आप इसे बदल नहीं सकते हैं।



नई कतार का निर्माण प्रदर्शन और संसाधनों के भुगतान के साथ जुड़ा हुआ है, और इसे बहुत कम संख्या में कतारों से आगे नहीं बढ़ाया जा सकता है। इस कार्य का कोई सही समाधान नहीं है।



आज भी, 2014 में, अधिकांश डेस्कटॉप वेब ब्राउजर डिफ़ॉल्ट रूप से अक्षम HTTP पाइपलाइन के साथ आते हैं।



इस समस्या की अतिरिक्त जानकारी फ़ायरफ़ॉक्स बग ट्रैकर नंबर 264354 के तहत मिल सकती है ।

देरी को दूर करने के लिए उठाए गए कदम

हमेशा की तरह, जब लोग त्रुटियों का सामना करते हैं, तो वे वर्कअराउंड ढूंढने के लिए टीम बनाते हैं। कुछ वर्कअराउंड चतुर और उपयोगी होते हैं, कुछ बस बैसाखी से डरते हैं।

स्प्रिट निर्माण

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







साइट इस चाल का उपयोग गति बढ़ाने के लिए करती है। एक बड़ा अनुरोध प्राप्त करना HTTP 1.1 में एक सौ अलग-अलग छोटी तस्वीरें प्राप्त करने की तुलना में बहुत तेज़ है।



बेशक, इस साइट के उन पृष्ठों के लिए इसकी कमियां हैं जिनके लिए केवल एक या दो छोटे चित्रों की आवश्यकता होती है। यह संभवतया कुछ सबसे अधिक उपयोग किए जाने के बजाय, कैश से सभी चित्रों को मिटा देता है।

एम्बेडिंग

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

.icon1 { background: url(data:image/png;base64,<data>) no-repeat; } .icon2 { background: url(data:image/png;base64,<data>) no-repeat; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

संघ

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



डेवलपर्स की घोषणा करना और उन्हें इन आवश्यकताओं को पूरा करने के लिए मजबूर करना, ज़ाहिर है, "सिर्फ" शामिल लोगों के लिए एक दर्द है और किसी भी प्रदर्शन ग्राफ़ में नहीं दिखाया गया है।

sharding

अंतिम चाल, जिसका मैं उल्लेख करूंगा, जिसका उपयोग साइट के मालिक ब्राउज़रों में डाउनलोड सुधारने के लिए करते हैं, अक्सर इसे "शार्डिंग" कहा जाता है। यह मूल रूप से संभव के रूप में कई अलग अलग मेजबान भर में अपनी सेवा फैलाने का मतलब है। पहली नज़र में यह पागल लगता है, लेकिन इसका एक सरल कारण है!



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



समय के साथ, यह प्रतिबंध विनिर्देश से हटा दिया गया था और आज ग्राहक प्रति होस्ट 6-8 कनेक्शन का उपयोग करते हैं, लेकिन फिर भी प्रतिबंध है, इसलिए साइटें कनेक्शन की संख्या बढ़ाने की तकनीक जारी रखती हैं। जैसे-जैसे ऑब्जेक्ट्स की संख्या बढ़ी, जैसा कि मैंने पहले दिखाया था, बड़ी संख्या में कनेक्शन का उपयोग केवल यह सुनिश्चित करने के लिए किया जाने लगा कि HTTP अच्छा कर रहा है और साइट को तेज़ बनाता है। इस तकनीक का उपयोग करके साइटों के लिए 50 या 100 से अधिक यौगिकों का उपयोग करना असामान्य नहीं है।



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



नीचे दिया गया आंकड़ा बताता है कि स्वीडन की शीर्ष वेबसाइटों में से एक को देखने के दौरान पैकेट रिकॉर्ड कैसा दिखता है और कई मेजबानों पर कैसे अनुरोध वितरित किए जाते हैं।

HTTP अद्यतन

क्या उन्नत प्रोटोकॉल बनाना बेहतर नहीं होगा? जिसमें निम्नलिखित शामिल होंगे ...

1. एक प्रोटोकॉल बनाएं जो RTT के प्रति कम संवेदनशील हो
2. पाइपलाइनिंग को ठीक करें और कतार अवरुद्ध समस्या शुरू करें
3. प्रत्येक होस्ट के लिए कनेक्शन की संख्या बढ़ाने की आवश्यकता और इच्छा को रोकें
4. मौजूदा इंटरफ़ेस, सभी सामग्री, URI प्रारूप और स्कीमाओं को पुनः प्राप्त करें
5. इसे IETF HTTPbis वर्कग्रुप के अंदर करें

IETF और HTTPbis वर्कग्रुप

इंटरनेट इंजीनियरिंग काउंसिल (IETF) एक ऐसा संगठन है जो इंटरनेट मानकों को विकसित और बढ़ावा देता है। अधिकतर प्रोटोकॉल स्तर पर। वे RFC दस्तावेज़ों की एक श्रृंखला के लिए अच्छी तरह से जाने जाते हैं, जो टीसीपी, डीएनएस, एफ़टीपी से लेकर सर्वोत्तम प्रथाओं, एचटीटीपी, और कई प्रोटोकॉल विकल्पों में से सभी का दस्तावेजीकरण करते हैं जो कहीं भी लागू नहीं किए गए हैं।



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



HTTPbis वर्किंग ग्रुप 2007 की गर्मियों के दौरान बनाया गया था और HTTP 1.1 विनिर्देशन को अद्यतन करने वाला था - इसलिए "bis" प्रत्यय था। HTTP प्रोटोकॉल के नए संस्करण के समूह में चर्चा वास्तव में 2012 के अंत में शुरू हुई। HTTP 1.1 को अपडेट करने का काम 2014 की शुरुआत में पूरा हो गया था।



HTTP2 विनिर्देशन के संस्करण की अपेक्षित अंतिम रिलीज़ से पहले HTTPbis वर्किंग ग्रुप के लिए अंतिम बैठक जून 2014 की शुरुआत में न्यूयॉर्क में आयोजित की जाएगी।



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

प्रत्यय "बिस"

समूह को HTTPbis कहा जाता है, जहाँ प्रत्यय "bis" लैटिन क्रिया विशेषण से आता है, जिसका अर्थ है "दो।" Bis को अक्सर IETF के अंदर एक प्रत्यय या नाम के भाग के रूप में अद्यतन करने के लिए या एक विनिर्देश पर काम करने के लिए दूसरे प्रयास के रूप में उपयोग किया जाता है। जैसे HTTP 1.1 के साथ।

http2 की शुरुआत SPDY से हुई थी

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



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

Http2 अवधारणा

तो http2 किसके लिए बनाया गया है? HTTPbis समूह का दायरा सीमित करने वाली सीमाएँ कहाँ हैं?

वे वास्तव में, काफी स्पष्ट हैं और टीम को नया करने की क्षमता पर महत्वपूर्ण प्रतिबंध लगाते हैं।

• यह HTTP प्रतिमानों का समर्थन करना चाहिए। यह अभी भी प्रोटोकॉल है जहां क्लाइंट टीसीपी पर सर्वर को अनुरोध भेजते हैं।
• Http: // और https: // लिंक को बदला नहीं जा सकता है। आप एक नया सर्किट नहीं जोड़ सकते हैं या कुछ भी समान नहीं कर सकते हैं। इस तरह के पते का उपयोग करने वाली सामग्री की मात्रा कभी भी इस तरह के बदलाव की उम्मीद करने के लिए बहुत बड़ी है।
• HTTP1 सर्वर और क्लाइंट दशकों तक मौजूद रहेंगे, हमें उन्हें http2- सर्वर पर प्रॉक्सी करने में सक्षम होना चाहिए।
• नतीजतन, परदे के पीछे क्लाइंट के लिए HTTP 1.1 के लिए वन-टू-वन http2 कन्वर्ट करने में सक्षम होना चाहिए।
• प्रोटोकॉल में वैकल्पिक भागों की संख्या को हटाएं या कम करें। SPDY और Google टीम से आए मंत्र के रूप में इसकी इतनी आवश्यकता भी नहीं है। जोर देकर कहा कि सभी आवश्यकताएं अनिवार्य हैं, आपके पास अब कुछ करने का अवसर नहीं होगा, और फिर जाल में गिर जाएगी।
• अधिक मामूली संस्करण नहीं। यह निर्णय लिया गया कि क्लाइंट और सर्वर या तो http2 संगत हो सकते हैं या नहीं। यदि यह पता चला है कि आपको प्रोटोकॉल का विस्तार करने या इसे बदलने की आवश्यकता है, तो CANp3 दिखाई देगा। Http2 में अब मामूली संस्करण नहीं होंगे।

मौजूदा URI योजनाओं के लिए http2

जैसा कि पहले उल्लेख किया गया है, मौजूदा यूआरआई योजनाओं को संशोधित नहीं किया जा सकता है, इसलिए http2 केवल उनका उपयोग करना चाहिए। आज के बाद से वे HTTP 1.x के लिए उपयोग किए जाते हैं, हमें प्रोटोकॉल को http2 में अपडेट करने के लिए एक स्पष्ट तरीके की आवश्यकता है या किसी तरह सर्वर से पुराने प्रोटोकॉल के बजाय http2 का उपयोग करने के लिए कहें।



HTTP 1.1 के पास पहले से ही इसके लिए एक पूर्वनिर्धारित विधि है, तथाकथित अपग्रेड हेडर, जो सर्वर को पुराने प्रोटोकॉल का उपयोग करके समान अनुरोध प्राप्त होने पर नए प्रोटोकॉल का उपयोग करके प्रतिक्रिया भेजने की अनुमति देता है। एकल अनुरोध-प्रतिक्रिया पुनरावृत्ति की कीमत पर।



अनुरोध-प्रतिसाद समय को पुनःप्रकाशित करना कुछ ऐसा नहीं था जिससे SPDY टीम सहमत हो सके, और चूंकि उन्होंने SPDY को TLS के शीर्ष पर विकसित किया, इसलिए उन्होंने एक नया TLS एक्सटेंशन बनाया जिसका उपयोग सुलह को कम करने के लिए किया गया था। नेक्स्ट प्रोटोकॉल नेगोशिएशन से एनपीएन नामक इस एक्सटेंशन का उपयोग करते हुए, क्लाइंट सर्वर को बताता है कि वह कौन से प्रोटोकॉल के साथ संवाद करना चाहता है और सर्वर सबसे बेहतर लोगों के साथ प्रतिक्रिया कर सकता है जो वह जानता है।

http2 के लिए http: //

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



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







अनिवार्य टीएलएस का विषय मेलिंग सूचियों और बैठकों पर बहुत सारे हाथ के झूलों और अभियान कॉल को स्पष्ट करता है - यह अच्छा है या बुरा? यह एक व्यथा विषय है - इसे याद रखें यदि आप सीधे HTTPbis सदस्य से यह प्रश्न पूछने का निर्णय लेते हैं!

टीएलएस पर http2 बातचीत

अगला प्रोटोकॉल नेगोशिएशन (NPN) वह प्रोटोकॉल है जिसका उपयोग SPDY TLS सर्वर के साथ बातचीत करने के लिए किया जाता है। चूंकि यह एक सच्चा मानक नहीं था, इसलिए इसे IETF और ALPN द्वारा पुन: डिज़ाइन किया गया: अनुप्रयोग स्तर प्रोटोकॉल नेगोशिएशन इसके स्थान पर दिखाई दिया। ALPN http2 में उपयोग के लिए जोर दे रहा है, जबकि SPDY क्लाइंट और सर्वर अभी भी NPN का उपयोग कर रहे हैं।

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

http2 http: // के लिए

जैसा कि पहले संक्षेप में कहा गया है, पाठ्यपुस्तक HTTP 1.1 के लिए, http2 बातचीत के लिए सर्वर को अपग्रेड हेडर के साथ भेजने की आवश्यकता होती है। यदि सर्वर http2 को समझता है, तो यह "101 स्विचिंग" स्थिति के साथ प्रतिक्रिया करेगा और फिर कनेक्शन में http2 का उपयोग करना शुरू कर देगा। बेशक, आप समझते हैं कि यह अद्यतन प्रक्रिया एक पूर्ण नेटवर्क अनुरोध-प्रतिक्रिया के समय के लायक है, लेकिन दूसरी ओर, HTTP2 कनेक्शन को बनाए रखा जा सकता है और सामान्य HTTP1 कनेक्शन की तुलना में लंबे समय तक पुन: उपयोग किया जा सकता है।



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

Http2 प्रोटोकॉल

परिसर, इतिहास और राजनीति के बारे में पर्याप्त कहा गया है, और अब हम यहां हैं। चलो प्रोटोकॉल की बारीकियों में गोता लगाएँ। वे भाग और अवधारणाएँ जो http2 की रचना करते हैं।

बाइनरी प्रोटोकॉल

http2 एक बाइनरी प्रोटोकॉल है।



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



http2 पैकेट बन्धन को आसान बनाने के लिए द्विआधारी है। पैकेज की शुरुआत और अंत का निर्धारण HTTP 1.1 में सबसे कठिन काम है और सिद्धांत रूप में सभी पाठ प्रोटोकॉल में से एक है। वैकल्पिक स्थान से हटकर और एक ही तरह की चीजों को लिखने के सभी प्रकार के तरीकों से, हम कार्यान्वयन को आसान बनाते हैं।



इसके अलावा, प्रोटोकॉल से जुड़े हिस्सों और डेटा पैकेट को अलग करना बहुत आसान हो जाता है, जो कि HTTP1 में बेतरतीब ढंग से मिलाया जाता है।



तथ्य यह है कि प्रोटोकॉल संपीड़न के उपयोग की अनुमति देता है और अक्सर टीएलएस के शीर्ष पर चलता है, पाठ के मूल्य को भी कम करता है, क्योंकि किसी भी मामले में आप अब तारों में सादे पाठ नहीं देखेंगे। हमें बस समझ में आने की जरूरत है कि हमें http2 में प्रोटोकॉल स्तर पर क्या होता है, यह जानने के लिए Wireshark विश्लेषक या कुछ समान का उपयोग करने की आवश्यकता है।



इस प्रोटोकॉल के डिबगिंग की संभावना यूटिलिटीज जैसे कि कर्ल, या विर्सार्क http2-dissector के साथ नेटवर्क स्ट्रीम का विश्लेषण करके या कुछ इसी तरह की होगी।

बाइनरी प्रारूप

http2 फ्रेम भेजता है। कई अलग-अलग फ्रेम हैं, लेकिन उन सभी में एक ही संरचना है:

प्रकार, लंबाई, झंडे, स्ट्रीम पहचानकर्ता, और फ़्रेम पेलोड।







वर्तमान http2 ड्राफ्ट में बारह अलग-अलग फ्रेम प्रकार हैं, जिनमें दो, शायद सबसे महत्वपूर्ण हैं, जो HTTP 1.1: DATA (डेटा) और HEADERS (हेडर) से जुड़े हैं। मैं नीचे कुछ फ्रेमों के बारे में अधिक विस्तार से वर्णन करूंगा।

स्ट्रीम मल्टीप्लेक्सिंग

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



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



मल्टीप्लेक्सिंग स्ट्रीम का मतलब है कि एक ही कनेक्शन के भीतर कई स्ट्रीम के पैकेट मिलाए जाते हैं। दो (या अधिक) अलग-अलग डेटा ट्रेनों को एक ट्रेन में इकट्ठा किया जाता है और फिर दूसरी तरफ अलग किया जाता है। यहाँ दो ट्रेनें हैं:







वे मिश्रित मोड में एक कनेक्शन पर एक साथ मिलते हैं:







Http2 में हम दसियों और सैकड़ों एक साथ धाराएँ देखेंगे। एक स्ट्रीम बनाने की लागत बहुत कम है।

प्राथमिकताएँ और निर्भरताएँ

प्रत्येक थ्रेड में एक प्राथमिकता होती है जिसका उपयोग एक्सचेंज में अन्य प्रतिभागी को दिखाने के लिए किया जाता है जो कि थ्रेड्स को अधिक महत्वपूर्ण माना जाता है।



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



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

हैडर कम्प्रेशन

HTTP एक स्टेटलेस प्रोटोकॉल है। संक्षेप में, इसका मतलब यह है कि प्रत्येक अनुरोध में अधिकतम विवरण होना चाहिए जिसमें सर्वर को पिछले अनुरोध से बहुत सारे मेटाडेटा को सहेजे बिना अनुरोध को पूरा करना होगा। चूंकि http2 इन प्रतिमानों में से कोई भी परिवर्तन नहीं करता है, इसलिए इसे भी करना होगा।



यह HTTP को दोहराव देता है। जब कोई ग्राहक किसी एकल सर्वर से कई संसाधनों का अनुरोध करता है, जैसे कि वेब पेज की छवि, तो यह अनुरोधों की एक बड़ी श्रृंखला में बदल जाता है जो लगभग समान दिखते हैं। लगभग समान ही कुछ की एक श्रृंखला के लिए, संपीड़न खुद को बताता है।







जैसा कि मैंने उल्लेख किया है, जैसे-जैसे पृष्ठ पर वस्तुओं की संख्या बढ़ती है, कुकीज़ का उपयोग और अनुरोधों का आकार भी बढ़ता रहता है। कुकीज़ को भी सभी अनुरोधों में शामिल किया जाना चाहिए, लगभग हमेशा कई अनुरोधों पर एक जैसा।



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

संपीड़न एक आसान विषय नहीं है।

HTTPS और SPDY संपीड़न BREACH और CRIME हमलों के लिए असुरक्षित थे। ज्ञात पाठ को स्ट्रीम में सम्मिलित करने और यह देखने के द्वारा कि एन्क्रिप्टेड आउटपुट कैसे बदलता है, हमलावर यह पता लगा सकता है कि क्या भेजा गया था।



ज्ञात हमलों में से एक के संपर्क में आने के जोखिम के बिना प्रोटोकॉल में गतिशील सामग्री के लिए संपीड़न करने के लिए गंभीर विचार-विमर्श और सावधानी की आवश्यकता होती है। यह वही है जो HTTPbis टीम करने की कोशिश कर रही है।



तो HPACK दिखाई दिया, HTTP / 2 के लिए हैडर संपीड़न , जो कि, जैसा कि इसके नाम से पता चलता है, विशेष रूप से http2 हेडर के लिए डिज़ाइन किया गया एक संपीड़न प्रारूप है, और कड़ाई से बोलते हुए, यह एक अलग इंटरनेट ड्राफ्ट विनिर्देश है। नया प्रारूप, अन्य प्रतिवादों के साथ, जैसे कि विशेष झंडे जो बिचौलियों को कुछ हेडर को संपीड़ित न करने और वैकल्पिक रूप से संपीड़न हमले को जटिल करने के लिए फ़्रेम में अतिरिक्त खाली डेटा जोड़ने के लिए कहते हैं।

डेटा संपीड़न

ड्राफ्ट 12 जारी होने के तुरंत पहले, गज़िप संपीड़ित के डेटा फ्रेम के लिए समर्थन जोड़ा गया था। प्रत्येक फ्रेम को व्यक्तिगत रूप से संकुचित किया जाता है, इसलिए उनके बीच कोई सामान्य संदर्भ नहीं है, लेकिन यह संपीड़न के स्तर को थोड़ा कम करता है। यह सुविधा HTTP 1.1 में ट्रांसफर-एन्कोडिंग में gzip के उपयोग के अनुरूप है। एक विशेषता जो शायद ही कभी उपयोग की जाती है, लेकिन अक्सर चर्चा की जाती है, प्रोटोकॉल में कुछ दोष है, कम से कम ब्राउज़रों के लिए।

रीसेट - अपना मन बदल दिया

HTTP 1.1 का एक दोष, जब एक HTTP संदेश एक निश्चित लंबाई की सामग्री-लंबाई हेडर के साथ भेजा जाता है, तो आप इसे इतनी आसानी से रोक नहीं सकते हैं। बेशक, आप अक्सर (लेकिन हमेशा नहीं - मैं यहां एक लंबी व्याख्या छोड़ दूंगा कि ऐसा क्यों है) एक टीसीपी कनेक्शन को डिस्कनेक्ट करने के लिए, लेकिन एक नए टीसीपी कनेक्शन पर फिर से बातचीत करने की कीमत पर।

अब आप बस भेजने को रद्द कर सकते हैं और एक नया संदेश शुरू कर सकते हैं। यह एक RST_STREAM http2 फ्रेम भेजकर प्राप्त किया जा सकता है, जो इस प्रकार बैंडविड्थ की बर्बादी और डिस्कनेक्ट करने की आवश्यकता को रोक देगा।

सर्वर पुश

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

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

वैकल्पिक सेवाएं

HTTP2 के अनुकूलन के बाद, यह अपेक्षा करने के कारण हैं कि टीसीपी कनेक्शन HTTP 1.x कनेक्शनों की तुलना में लंबे और लंबे समय तक काम करने की स्थिति में होंगे। क्लाइंट बहुत कुछ करने में सक्षम होगा जो वह प्रत्येक होस्ट / साइट पर एक कनेक्शन के ढांचे के भीतर चाहता है और यह कनेक्शन संभवतः बहुत लंबे समय तक खुला रहेगा।



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



सर्वर एक वैकल्पिक सेवा की उपलब्धता के बारे में क्लाइंट को सूचित करते हुए Alt-Svc हेडर (या http2 में ALTSVC फ्रेम) भेजता है। एक अलग सेवा, होस्ट और पोर्ट नंबर का उपयोग करके एक ही सामग्री के लिए एक अतिरिक्त मार्ग।



यह उम्मीद की जाती है कि ग्राहक एसिंक्रोनस रूप से सेवा से जुड़ने की कोशिश करेगा और यदि यह सामान्य रूप से काम करता है तो वैकल्पिक सेवा का उपयोग करना शुरू कर देगा।

अवसरवादी टी.एल.एस.

Alt-Svc हैडर सर्वर को अनुमति देता है, जो क्लाइंट को http: // के माध्यम से सामग्री प्रदान करता है, जिससे टीएलएस कनेक्शन पर उपलब्ध समान सामग्री की उपस्थिति के बारे में ग्राहक को सूचित किया जा सके।



यह आंशिक रूप से एक विवादास्पद अवसर है। ऐसा कनेक्शन अनधिकृत TLS करता है और इसे कहीं भी "सुरक्षित" चिह्नित नहीं किया जाएगा: यह प्रोग्राम इंटरफ़ेस में लॉक नहीं दिखाएगा और उपयोगकर्ता को किसी भी तरह से सूचित नहीं करेगा कि यह सामान्य पुराना खुला HTTP नहीं है। लेकिन यह अवसरवादी टीएलएस होगा और कुछ लोग बहुत आत्मविश्वास से इस अवधारणा का विरोध करते हैं।

प्रवाह नियंत्रण

Http2 में प्रत्येक व्यक्तिगत स्ट्रीम की अपनी घोषित स्ट्रीम विंडो है, जिसे दूसरे पक्ष ने डेटा ट्रांसफर के लिए अनुमति दी है। यदि आप कल्पना कर सकते हैं कि एसएसएच कैसे काम करता है, तो यह बहुत समान है और उसी भावना और शैली में निष्पादित होता है।

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

ताला

ड्राफ्ट -12 ड्राफ्ट में, लंबी चर्चा के बाद, BLOCKED नामक एक फ्रेम जोड़ा गया था। इसे एक बार http2 प्रतिभागी द्वारा भेजा जा सकता है जब इसके पास भेजने के लिए डेटा होता है, लेकिन प्रवाह नियंत्रण इसे किसी भी डेटा को भेजने से रोकता है। विचार यह है कि यदि आपके कार्यान्वयन को इस तरह का एक फ्रेम प्राप्त होता है, तो आपको यह समझना चाहिए कि आपके कार्यान्वयन में कुछ चूक हुई है और / या आप इसके कारण उच्च डेटा अंतरण दर प्राप्त नहीं कर सकते हैं।



ड्राफ्ट -12 ड्राफ्ट से उद्धरण:

प्रयोग की आसानी के लिए BLOCKED फ्रेम इस ड्राफ्ट संस्करण में शामिल है। यदि प्रयोग का परिणाम सकारात्मक परिणाम नहीं देता है, तो इसे हटा दिया जाएगा।

विश्व http2

जब http2 स्वीकार किया जाता है तो यह कैसा दिखेगा? क्या इसे स्वीकार किया जाएगा?

Http2 आम लोगों को कैसे प्रभावित करता है?

http2 . . SPDY , .







http2 -, .



, …



, , .



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



हम कितना तेज और कितना बेहतर देखेंगे। मुझे नहीं लगता कि हम अब तक ऐसा कहने के लिए तैयार हैं। सबसे पहले, प्रौद्योगिकी अभी भी युवा है, और दूसरी बात, हमने अभी तक ग्राहकों और सर्वरों के स्वच्छ कार्यान्वयन को नहीं देखा है जो नए प्रोटोकॉल प्रदान करने वाली सभी शक्ति का सही उपयोग करते हैं।

Http2 वेब विकास को कैसे प्रभावित करेगा?

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



इन वर्कअराउंड में से अधिकांश जो टूल और डेवलपर्स अब बिना किसी हिचकिचाहट के डिफ़ॉल्ट रूप से उपयोग करते हैं, http2 के प्रदर्शन को हिट करने की संभावना है, या कम से कम http2 की नई महाशक्ति का पूरा लाभ नहीं उठा सकते हैं। स्प्रिट और एम्बेडिंग को http2 के साथ साझा नहीं किया जाना चाहिए। Http2 के लिए हानिकारक होने के कारण शेयरिंग की संभावना कम है, क्योंकि http2 कम कनेक्शन का उपयोग करने से लाभान्वित होता है।



यहाँ समस्या यह है कि वेब डेवलपर्स को ऐसी दुनिया में वेबसाइटों को विकसित करने और लागू करने की आवश्यकता होगी, जहाँ, कम से कम समय के लिए, HTTP 1.1 और http2 दोनों क्लाइंट हों, और सभी उपयोगकर्ताओं के लिए अधिकतम प्रदर्शन प्राप्त करने के लिए, दो अलग-अलग साइट विकल्पों की पेशकश करना महंगा होगा।



अकेले इस कारण से, मुझे संदेह है कि http2 की पूरी क्षमता देखने से पहले हमें कुछ समय लगेगा।

http2 कार्यान्वयन

बेशक, इस तरह के दस्तावेजों में विशिष्ट कार्यान्वयन का प्रयास करना पूरी तरह से बेकार काम है जो विफलता के लिए बर्बाद है और बहुत कम समय में अप्रचलित हो जाएगा। इसके बजाय, मैं स्थिति को व्यापक अर्थों में समझाऊंगा और पाठकों को http2 वेबसाइट पर कार्यान्वयन की सूची में निर्देशित करूंगा।



पहले से ही, बड़ी संख्या में कार्यान्वयन हुए हैं और जैसे ही आप http2 पर काम करते हैं, दिन-प्रतिदिन उनकी संख्या बढ़ती जा रही है। उसी समय, लेखन के समय, 19 कार्यान्वयन होते हैं और उनमें से कुछ नवीनतम मसौदा विनिर्देश को लागू करते हैं।



फ़ायरफ़ॉक्स हमेशा नवीनतम ड्राफ्ट संस्करणों में सबसे आगे एक ब्राउज़र रहा है, ट्विटर http2 पर सेवाएं प्रदान करना जारी रखता है। Google ने अप्रैल में अपनी कुछ सेवाओं पर ड्राफ्ट -10 का समर्थन शुरू किया था।



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

Http2 की विशिष्ट आलोचना

प्रोटोकॉल को विकसित करने की प्रक्रिया में, बार-बार बहस छिड़ गई, और निश्चित रूप से, ऐसे कई लोग हैं जो मानते हैं कि प्रोटोकॉल पूरी तरह से गलत निकला। मैं उनके खिलाफ कुछ सबसे आम शिकायतों और तर्कों को उजागर करना चाहूंगा:

"प्रोटोकॉल Google द्वारा डिज़ाइन और बनाया गया है"

ऐसे रूपांतर भी हैं जिनका अर्थ है कि दुनिया Google द्वारा और भी अधिक निर्भर और नियंत्रित है। यह सच नहीं है। एक प्रोटोकॉल IETF द्वारा आंतरिक रूप से उसी तरह विकसित किया गया है जिस तरह से पिछले 30 वर्षों में प्रोटोकॉल विकसित किए गए हैं। हालाँकि, हम सभी SPDY पर उत्कृष्ट कार्य के लिए Google के आभारी हैं, जिसने न केवल यह साबित किया कि इस तरह से नए प्रोटोकॉल को लागू करना संभव है, बल्कि हम जो प्राप्त कर सकते हैं, उसका अनुमान लगाने में भी मदद मिली है।

"प्रोटोकॉल केवल ब्राउज़रों और महान सेवाओं के लिए उपयोगी है"

कुछ हद तक, ऐसा है। HTTP2 के विकास के पीछे मुख्य कारणों में से एक HTTP पाइपलाइनिंग के लिए फिक्स है। यदि आपके मामले में पाइपलाइनिंग की आवश्यकता नहीं थी, तो http2 आपके लिए विशेष रूप से उपयोगी नहीं होगा।

यह निश्चित रूप से प्रोटोकॉल की एकमात्र उपलब्धि नहीं है, लेकिन सबसे महत्वपूर्ण है।



जैसे ही सेवाएं एक कनेक्शन में मल्टीप्लेक्स धाराओं की पूरी शक्ति और क्षमताओं को समझना शुरू करती हैं, मुझे उम्मीद है कि हम http2 का उपयोग करके अनुप्रयोगों की संख्या में वृद्धि देखेंगे।



छोटे REST API और HTTP 1.x के सरल सॉफ्टवेयर अनुप्रयोगों को http2 पर माइग्रेट करने के बड़े लाभ नहीं मिलेंगे। लेकिन, फिर भी, अधिकांश उपयोगकर्ताओं के लिए बहुत कम नुकसान होंगे।

"TLS के उपयोग से यह धीमा हो जाता है"

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



http2 आपको टीएलएस का उपयोग करने के लिए बाध्य नहीं करता है, इसलिए हमें शर्तों का मिश्रण नहीं करना चाहिए।

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

"नहीं ASCII प्रोटोकॉल सब कुछ बिगाड़ देता है"

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



यदि आप वास्तव में बाइनरी प्रोटोकॉल को स्वीकार नहीं कर सकते हैं, तो आप टीएलएस और HTTP 1.x में कम्प्रेशन दोनों को स्वीकार नहीं कर सकते हैं, जो लगभग कुछ समय से है।

क्या http2 व्यापक हो जाएगा?

यह निश्चित रूप से कहने के लिए बहुत जल्दी है, लेकिन मैं अनुमान लगा सकता हूं और सराहना कर सकता हूं, और यही मैं यहां करने जा रहा हूं।

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



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



http2, SPDY के समान मूल प्रतिमानों के आधार पर, मुझे यकीन है कि संभवतः इसे और भी सक्रिय रूप से लागू किया जाएगा, क्योंकि यह आधिकारिक IETF प्रोटोकॉल है। SPDY के कार्यान्वयन को हमेशा "यह Google प्रोटोकॉल है" के कलंक द्वारा वापस आयोजित किया गया है।

रिलीज़ के पीछे कई प्रसिद्ध ब्राउज़र हैं। फ़ायरफ़ॉक्स, क्रोम और इंटरनेट एक्सप्लोरर के कम से कम प्रतिनिधियों ने http2 का समर्थन करने वाले ब्राउज़र को जारी करने की इच्छा व्यक्त की है।



कई सर्वर प्रदाता हैं जो शायद जल्द ही Google, ट्विटर, और फेसबुक सहित http2 की पेशकश करेंगे, और हम Apache HTTP सर्वर और nginx जैसे लोकप्रिय वेब सर्वर कार्यान्वयन में http2 समर्थन देखने की उम्मीद करते हैं।

फ़ायरफ़ॉक्स में http2

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

इसे पहले चालू करें

एड्रेस बार में “about: config” टाइप करें और “network.http.spdy.enabled.http2draft” नामक विकल्प की तलाश करें। सुनिश्चित करें कि यह सही पर सेट है।

केवल टीएलएस

याद रखें कि फ़ायरफ़ॉक्स केवल HTTP2 को TLS पर लागू करता है। जब आप http: // साइट्स पर जाते हैं, तो आप केवल http2 को फ़ायरफ़ॉक्स में http2 का समर्थन करते हुए देखेंगे।

पारदर्शी!

इंटरफ़ेस में कहीं भी कोई भी तत्व यह नहीं कहेगा कि आप http2 का उपयोग कर रहे हैं। आप इसे इतनी आसानी से नहीं समझ सकते। "वेब डेवलपमेंट-> नेटवर्क" को चालू करके पता लगाने का केवल एक ही तरीका है, प्रतिक्रिया हेडर की जांच करें और देखें कि आपको सर्वर से क्या मिला ... प्रतिक्रिया में "HTTP / 2.0" के बारे में कुछ है और फ़ायरफ़ॉक्स अपने हेडर को "X-" नाम के साथ सम्मिलित करता है। फ़ायरफ़ॉक्स-स्पडी ”, जैसा कि इस पहले से पुराने स्क्रीनशॉट में दिखाया गया है।







Http2 पर संचार करते समय नेटवर्क हेडर में जो हेडर आप देखते हैं, वे http2 से पुराने HTTP1.x जैसे हेडर में परिवर्तित हो जाते हैं।

http2 कर्ल में

सितंबर 2013 से शुरू होने वाले कर्ल प्रोजेक्ट ने http2 समर्थन के साथ प्रयोग करना शुरू किया।



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

HTTP 1.x जैसा दिखता है

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

सादा पाठ

कर्ल अपग्रेड हेडर का उपयोग करके अनएन्क्रिप्टेड http2 का समर्थन करता है। यदि आप एक HTTP अनुरोध कर रहे हैं और HTTP 2 का अनुरोध कर रहे हैं, तो कर्ल सर्वर को HTTP 2 से कनेक्शन को अपग्रेड करने के लिए कहेगा, यदि संभव हो तो।

टीएलएस और पुस्तकालय चयन

कर्ल अपने टीएलएस बैकेंड के रूप में विभिन्न टीएलएस पुस्तकालयों की एक विस्तृत श्रृंखला का समर्थन करता है, और यह http2 समर्थन के लिए अभी भी सही है। Http2 के लिए टीएलएस के साथ समस्या एपीएलएन समर्थन की उपलब्धता है और, कुछ हद तक, एनपीएन समर्थन।



ALPN और NPN समर्थन प्राप्त करने के लिए OpenSSL या NSS के आधुनिक संस्करणों के साथ कर्ल बनाएं। GnuTLS का उपयोग करते समय, आपको ALPN का समर्थन मिलेगा, लेकिन NPN का नहीं।

कमांड लाइन का उपयोग

कर्ल को समझाने के लिए कि आपको http2 का उपयोग करना शुरू करना चाहिए, दोनों सादे पाठ में और TLS के माध्यम से, आप --http2 विकल्प ("हाइफ़न हाइफ़न http2") का उपयोग कर सकते हैं।

लिबकर्ल विकल्प

आपका एप्लिकेशन, हमेशा की तरह, https: // या http: // URL का उपयोग करता है, लेकिन आप curl_easy_setopt CURLOPT_HTTP_VERSION से CURL_HTTP_VERSION_2 तक विकल्प सेट कर सकते हैं - libcurl http2 का उपयोग करने का प्रयास करता है। यदि वह कर सकता है तो वह http2 के साथ काम करने के लिए हर संभव प्रयास करने की कोशिश करेगा, लेकिन वह अभी भी HTTP 1.1 पर काम करेगा।

Http2 के बाद

Http2 में बड़ी संख्या में कठिन निर्णय और समझौता किए गए। Http2 को तैनात करने के बाद, प्रोटोकॉल के अन्य कामकाजी संस्करणों को अपग्रेड करने का एक तरीका है, जो बाद में प्रोटोकॉल के और अधिक संशोधन बनाने की संभावना को खोलता है। यह एक दृश्य और बुनियादी ढांचा भी लाता है जो एक साथ कई अलग-अलग प्रोटोकॉल संस्करणों का समर्थन कर सकता है। हो सकता है कि जब हम नया निर्माण करते हैं तो हमें पुराने को पूरी तरह से हटाने की आवश्यकता नहीं है?



HTTP 1 और HTTP2 के बीच सभी दिशाओं में प्रॉक्सी ट्रैफ़िक की क्षमता को संरक्षित करने की इच्छा के कारण http2 में अभी भी बहुत सारी विरासत HTTP 1 है। इस विरासत में से कुछ आगे के विकास और नवाचारों को मुश्किल बनाते हैं। शायद Canp3 उनमें से कुछ को छोड़ने में सक्षम होगा?



आपको क्या लगता है कि http में अभी भी कमी है?

आगे पढ़ रहे हैं

यदि आपको लगता है कि यह दस्तावेज़ सामग्री या तकनीकी विवरण में थोड़ा सा देहाती है, तो निम्नलिखित अतिरिक्त संसाधन हैं जो आपकी जिज्ञासा को संतुष्ट करेंगे:

• HTTPbis मेलिंग सूची और उसके अभिलेखागार: lists.w3.org/Archives/Public/ietf-http.wg
• HTTP2 मसौदा और HTTPbis समूह के संबंधित दस्तावेजों की वर्तमान विशिष्टता: datatracker.ietf.org/wg/httpbis
• फ़ायरफ़ॉक्स http2 नेटवर्किंग विवरण: wiki.mozilla.org/Networking/http2
• कर्ल http2 कार्यान्वयन विवरण: curl.haxx.se/dev/readme-http2.html
• वेबसाइट http2: http2.github.io