एचटीटीपी/2 के बारे में जानकारी

इल्या ग्रिगोरिक
इलिया ग्रिगोरिक

एचटीटीपी/2, हमारे ऐप्लिकेशन को तेज़, आसान, और ज़्यादा मज़बूत बनाएगा. यह एक दुर्लभ कॉम्बिनेशन है, जो हमारे ऐप्लिकेशन में पहले से इस्तेमाल किए गए एचटीटीपी/1.1 के समाधानों को पहले जैसा करता है. साथ ही, ट्रांसपोर्ट लेयर में ही इन समस्याओं को ठीक करता है. इतना ही नहीं, इससे हमें अपने ऐप्लिकेशन को ऑप्टिमाइज़ करने और परफ़ॉर्मेंस को बेहतर बनाने के कई नए अवसर भी मिलते हैं!

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

एचटीटीपी/2, एचटीटीपी के ऐप्लिकेशन सिमैंटिक में किसी भी तरह का बदलाव नहीं करता. एचटीटीपी के तरीके, स्टेटस कोड, यूआरआई, और हेडर फ़ील्ड जैसे सभी मुख्य कॉन्सेप्ट अब भी अपनी जगह पर बने रहेंगे. इसके बजाय, एचटीटीपी/2 यह बदलाव करता है कि डेटा को कैसे फ़ॉर्मैट (फ़्रेम) किया जाता है और क्लाइंट और सर्वर के बीच कैसे ट्रांसपोर्ट किया जाता है. ये दोनों ही पूरी प्रोसेस को मैनेज करते हैं और नई फ़्रेमिंग लेयर में हमारे ऐप्लिकेशन से आने वाली जटिलता को छिपाते हैं. इस वजह से, सभी मौजूदा ऐप्लिकेशन बिना कोई बदलाव किए डिलीवर किए जा सकते हैं.

एचटीटीपी/1.2 क्यों नहीं?

एचटीटीपी वर्किंग ग्रुप के सेट किए गए परफ़ॉर्मेंस लक्ष्यों को हासिल करने के लिए, एचटीटीपी/2 एक नई बाइनरी फ़्रेमिंग लेयर लॉन्च करता है जो पिछले एचटीटीपी/1.x सर्वर और क्लाइंट के साथ पुराने सिस्टम के साथ काम नहीं करती. इसलिए, प्रोटोकॉल के मेजर वर्शन को एचटीटीपी/2 में बढ़ा दिया गया है.

हालांकि, अगर रॉ टीसीपी सॉकेट के साथ काम करके वेब सर्वर (या कस्टम क्लाइंट) को लागू किया जा रहा है, तो आपको कोई अंतर नहीं दिखेगा: सभी नई, लो-लेवल फ़्रेमिंग को आपकी तरफ़ से क्लाइंट और सर्वर करते हैं. सिर्फ़

एसपीडी और एचटीटीपी/2 के बारे में कम शब्दों में जानकारी

SPDY एक प्रयोग के तौर पर शुरू किया गया प्रोटोकॉल था. इसे Google में बनाया गया था और साल 2009 के मध्य में इसका एलान किया गया था. इसका मुख्य मकसद एचटीटीपी/1.1 की परफ़ॉर्मेंस से जुड़ी कुछ समस्याओं को हल करके, वेब पेजों के लोड होने में लगने वाले समय को कम करना था. खास तौर पर, प्रोजेक्ट के लिए बताए गए लक्ष्य इस तरह सेट किए गए थे:

  • पेज लोड होने के समय (पीएलटी) को 50% कम करने का लक्ष्य रखें.
  • वेबसाइट के लेखकों की ओर से, कॉन्टेंट में किसी तरह का बदलाव करने की ज़रूरत से बचें.
  • डिप्लॉयमेंट की जटिलता को कम करें और नेटवर्क इन्फ़्रास्ट्रक्चर में बदलाव करने से बचें.
  • ओपन-सोर्स कम्यूनिटी के साथ मिलकर इस नए प्रोटोकॉल पर काम करें.
  • एक्सपेरिमेंटल प्रोटोकॉल की पुष्टि करने के लिए, असल परफ़ॉर्मेंस डेटा इकट्ठा करें.

शुरुआती घोषणा के कुछ ही समय बाद, Google के सॉफ़्टवेयर इंजीनियर माइक बेलशे और रॉबर्टो पियोन ने नए SPDY प्रोटोकॉल को लागू करने के लिए अपने पहले नतीजे, दस्तावेज़ और सोर्स कोड शेयर किए:

अभी तक हमने लैब की स्थितियों में ही एसपीडीवाई की जांच की है. शुरुआती नतीजे बहुत दिलचस्प हैं: जब हम सिम्युलेटेड होम नेटवर्क कनेक्शन पर टॉप 25 वेबसाइटें डाउनलोड करते हैं, तो हमें परफ़ॉर्मेंस में काफ़ी सुधार दिखता है. पेजों को 55% तक तेज़ी से लोड किया जाता है. (Chromium ब्लॉग)

साल 2012 में, Chrome, Firefox, और Opera में नए प्रयोग के तौर पर शुरू किए गए प्रोटोकॉल का इस्तेमाल किया जा रहा था. बड़ी तेज़ी से बढ़ रही साइटों (जैसे कि Google, Twitter, Facebook) और छोटी साइटों ने अपने इन्फ़्रास्ट्रक्चर में एसपीडीवाई को डिप्लॉय किया. असल में, इंडस्ट्री को अपनाते हुए SPDY एक वास्तविक मानक बनाने की राह पर था.

इस ट्रेंड को देखते हुए, एचटीटीपी वर्किंग ग्रुप (एचटीटीपी-डब्ल्यूजी) ने एसपीडीवाई से सीखे गए सबक लेने, उन्हें बनाने और उनमें सुधार करने, और आधिकारिक "एचटीटीपी/2" स्टैंडर्ड देने के लिए नई कोशिश की. एक नया चार्टर ड्राफ़्ट किया गया, एचटीटीपी/2 प्रपोज़ल के लिए ओपन कॉल किया गया. साथ ही, वर्क ग्रुप में काफ़ी चर्चा करने के बाद, नए एचटीटीपी/2 प्रोटोकॉल को शुरुआती पॉइंट के तौर पर अपनाया गया.

अगले कुछ सालों में SPDY और HTTP/2 साथ-साथ काम करते रहे. SPDY एक प्रयोग के तौर पर काम करता रहा. इसका इस्तेमाल एचटीटीपी/2 स्टैंडर्ड के लिए नई सुविधाओं और प्रस्तावों की जांच करने के लिए किया गया. हो सकता है कि पेपर पर जो अच्छा लगता है वह काम न करे और इसका उलटा भी काम न हो. इस वजह से, एसपीडीवाई ने एचटीटीपी/2 स्टैंडर्ड में शामिल किए जाने से पहले हर प्रस्ताव की जांच और आकलन करने के लिए एक रूट ऑफ़र किया. कुल मिलाकर, यह प्रक्रिया तीन साल तक चली और इसके चलते एक दर्जन से ज़्यादा इंटरमीडिएट ड्राफ़्ट तैयार हुए:

  • मार्च 2012: HTTP/2 के लिए प्रस्तावों के लिए कॉल करें
  • नवंबर 2012: एचटीटीपी/2 का पहला ड्राफ़्ट (एसपीडीवाई पर आधारित)
  • अगस्त 2014: HTTP/2 ड्राफ़्ट-17 और HPACK ड्राफ़्ट-12 पब्लिश किए गए
  • अगस्त 2014: वर्किंग ग्रुप ने एचटीटीपी/2 के लिए आखिरी कॉल की
  • फ़रवरी 2015: IESG से स्वीकृत HTTP/2 और HPACK ड्राफ़्ट
  • मई 2015: आरएफ़सी 7540 (एचटीटीपी/2) और आरएफ़सी 7541 (एचपीएके) पब्लिश किए गए

2015 की शुरुआत में, IESG ने पब्लिकेशन के लिए नए एचटीटीपी/2 स्टैंडर्ड की समीक्षा की और उसे मंज़ूरी दी. इसके कुछ समय बाद ही, Google Chrome टीम ने TLS के लिए, SPDY और NPN एक्सटेंशन को बंद करने के अपने शेड्यूल का एलान किया:

एचटीटीपी/1.1 से एचटीटीपी/2 के मुख्य बदलाव बेहतर परफ़ॉर्मेंस पर फ़ोकस करते हैं. कुछ प्रमुख सुविधाओं जैसे कि मल्टीप्लेक्सिंग, हेडर कंप्रेस करना, प्राथमिकता देना, और प्रोटोकॉल नेगोशिएशन का विकास उस काम से लिया गया है जो पहले से खुला होता है. हालांकि, एसपीडीवाई नाम का एक नॉन-स्टैंडर्ड प्रोटोकॉल भी होता है. Chrome 6 के बाद से ही SPDY का इस्तेमाल कर रहा है, लेकिन ज़्यादातर फ़ायदे एचटीटीपी/2 में दिए गए हैं. इसलिए, अब इसे बंद करना है. हमने 2016 की शुरुआत में एसपीडीवाई के लिए सहायता हटाने और Chrome में ALPN के लिए NPN नाम के TLS एक्सटेंशन के लिए सहायता हटाने की भी योजना बनाई है. सर्वर डेवलपर को सलाह दी जाती है कि वे एचटीटीपी/2 और एएलपीएन का इस्तेमाल करें.

हमें ओपन स्टैंडर्ड प्रोसेस में योगदान देने पर खुशी हो रही है. इस प्रोसेस की वजह से एचटीटीपी/2 को शुरू किया गया. हमें उम्मीद है कि स्टैंडर्ड तय करने और लागू करने में इंडस्ट्री की भागीदारी को देखते हुए, इस प्रोसेस का बड़े पैमाने पर इस्तेमाल किया जाएगा. (Chromium ब्लॉग)

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

डिज़ाइन और तकनीकी लक्ष्य

एचटीटीपी प्रोटोकॉल के पिछले वर्शन को आसानी से लागू करने के लिए जान-बूझकर डिज़ाइन किया गया था: एचटीटीपी/0.9, वर्ल्ड वाइड वेब को बूटस्ट्रैप करने के लिए एक लाइन वाला प्रोटोकॉल था; एचटीटीपी/1.0 ने सूचना के स्टैंडर्ड के हिसाब से, एचटीटीपी/0.9 के लोकप्रिय एक्सटेंशन को दस्तावेज़ के तौर पर शामिल किया था; एचटीटीपी/1.1 ने एक आधिकारिक आईईटीएफ़ स्टैंडर्ड लॉन्च किया था; एचटीटीपी का छोटा इतिहास देखें. एचटीटीपी/0.9-1.x ने ठीक वैसा ही काम किया है जैसा इसके लिए सेट किया गया था: एचटीटीपी इंटरनेट पर सबसे ज़्यादा स्वीकार किए जाने वाले ऐप्लिकेशन प्रोटोकॉल में से एक है.

माफ़ करें, आसानी से लागू करने की वजह से भी ऐप्लिकेशन की परफ़ॉर्मेंस पर असर पड़ता है: एचटीटीपी/1.x क्लाइंट को एक साथ कई कनेक्शन का इस्तेमाल करना पड़ता है. इससे, एक साथ कई काम करने और इंतज़ार का समय कम करने में मदद मिलती है. एचटीटीपी/1.x, अनुरोध और रिस्पॉन्स हेडर को कंप्रेस नहीं करता है. इसकी वजह से ग़ैर-ज़रूरी नेटवर्क ट्रैफ़िक आता है; एचटीटीपी/1.x, संसाधनों को प्राथमिकता देने की असरदार सुविधा नहीं देता है, जिसकी वजह से टीसीपी कनेक्शन का खराब इस्तेमाल होता है.

ये सीमाएं घातक नहीं थीं, लेकिन जैसे-जैसे वेब ऐप्लिकेशन का हमारे दैनिक जीवन में दायरा, जटिलता, और महत्व बढ़ता जा रहा है, उन्होंने वेब के डेवलपर और उपयोगकर्ताओं, दोनों पर बोझ बढ़ा दिया है. यह वही अंतर है जिसे ठीक करने के लिए एचटीटीपी/2 को डिज़ाइन किया गया था:

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

नतीजे में मिलने वाला प्रोटोकॉल, नेटवर्क के लिए ज़्यादा आसान होता है, क्योंकि एचटीटीपी/1.x की तुलना में कम टीसीपी कनेक्शन का इस्तेमाल किया जा सकता है. इसका मतलब है कि अन्य फ़्लो के साथ कम प्रतिस्पर्धा और लंबे समय तक कनेक्शन बने रहने की वजह से, उपलब्ध नेटवर्क की क्षमता का बेहतर इस्तेमाल किया जा सकता है. आखिर में, एचटीटीपी/2 बाइनरी मैसेज फ़्रेमिंग का इस्तेमाल करके मैसेज को बेहतर तरीके से प्रोसेस करने में भी मदद करता है. (हाइपरटेक्स्ट ट्रांसफ़र प्रोटोकॉल वर्शन 2, ड्राफ़्ट 17)

इस बात पर ध्यान देना ज़रूरी है कि एचटीटीपी/2, एचटीटीपी स्टैंडर्ड के पिछले स्टैंडर्ड की जगह नहीं ले रहा है, बल्कि मौजूदा एचटीटीपी स्टैंडर्ड को बढ़ा रहा है. एचटीटीपी के ऐप्लिकेशन सिमैंटिक एक जैसे ही होते हैं और ऑफ़र की गई सुविधाओं या एचटीटीपी के तरीकों, स्टेटस कोड, यूआरआई, और हेडर फ़ील्ड जैसे मुख्य कॉन्सेप्ट में कोई बदलाव नहीं किया गया है. ये बदलाव साफ़ तौर पर एचटीटीपी/2 के दायरे से बाहर थे. हालांकि, हाई-लेवल एपीआई में कोई बदलाव नहीं होता है, लेकिन यह समझना ज़रूरी है कि निचले लेवल में होने वाले बदलाव, पिछले प्रोटोकॉल की परफ़ॉर्मेंस से जुड़ी सीमाओं को कैसे खत्म करते हैं. चलिए, बाइनरी फ़्रेमिंग लेयर और इसकी सुविधाओं के बारे में जानते हैं.

बाइनरी फ़्रेमिंग लेयर

एचटीटीपी/2 की परफ़ॉर्मेंस को बेहतर बनाने की सभी सुविधाओं में सबसे अहम है, बाइनरी फ़्रेमिंग की नई लेयर. यह लेयर बताती है कि क्लाइंट और सर्वर के बीच एचटीटीपी मैसेज कैसे एनकैप्सुलेट और ट्रांसफ़र किए जाते हैं.

एचटीटीपी/2 बाइनरी फ़्रेमिंग लेयर

"लेयर" का मतलब है, सॉकेट इंटरफ़ेस और हमारे ऐप्लिकेशन में दिखने वाले ज़्यादा एचटीटीपी एपीआई के बीच, ऑप्टिमाइज़ किया गया कोड में बदलाव करने का नया तरीका पेश करने के लिए डिज़ाइन के विकल्प का मतलब है: वर्ब, तरीके, और हेडर जैसे एचटीटीपी सिमैंटिक पर कोई असर नहीं पड़ता है. हालांकि, ट्रांज़िट के दौरान उन्हें कोड में बदलने का तरीका अलग होता है. न्यूलाइन सीमांकित सादा टेक्स्ट एचटीटीपी/1.x प्रोटोकॉल से अलग, एचटीटीपी/2 का पूरा कम्यूनिकेशन छोटे मैसेज और फ़्रेम में बंटा होता है. इनमें से हर मैसेज बाइनरी फ़ॉर्मैट में एन्कोड होता है.

इस वजह से, क्लाइंट और सर्वर, दोनों को एक-दूसरे को समझने के लिए नई बाइनरी एन्कोडिंग तकनीक का इस्तेमाल करना होगा: एचटीटीपी/1.x क्लाइंट सिर्फ़ एचटीटीपी/2 सर्वर को नहीं समझेगा. इसी तरह, क्लाइंट और सर्वर, दोनों को सिर्फ़ एचटीटीपी/2 सर्वर को समझने के लिए नए बाइनरी तरीके का इस्तेमाल नहीं करना होगा. शुक्र है कि हमारे ऐप्लिकेशन को इन सभी बदलावों की जानकारी नहीं होती है, क्योंकि क्लाइंट और सर्वर हमारी ओर से सभी ज़रूरी फ़्रेमिंग का काम करते हैं.

स्ट्रीम, मैसेज, और फ़्रेम

बाइनरी फ़्रेमिंग के नए तरीके के आने से, क्लाइंट और सर्वर के बीच डेटा को ट्रांसफ़र करने का तरीका बदल गया है. इस प्रोसेस की जानकारी पाने के लिए, आइए एचटीटीपी/2 शब्दावली के बारे में अच्छे से जान लें:

  • स्ट्रीम: पहले से मौजूद कनेक्शन में बाइट का दो-तरफ़ा फ़्लो. इसमें एक या एक से ज़्यादा मैसेज हो सकते हैं.
  • मैसेज: फ़्रेम का पूरा क्रम, जो लॉजिकल अनुरोध या जवाब मैसेज पर मैप करते हैं.
  • फ़्रेम: HTTP/2 में संचार की सबसे छोटी इकाई, जिसमें हर एक में एक फ़्रेम हेडर होता है. यह कम से कम उस स्ट्रीम की पहचान करता है जिससे फ़्रेम जुड़ा है.

इन शब्दों के संबंध की खास जानकारी इस तरह मिल सकती है:

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

एचटीटीपी/2 स्ट्रीम, मैसेज, और फ़्रेम

कम शब्दों में कहें, तो एचटीटीपी/2, एचटीटीपी प्रोटोकॉल कम्यूनिकेशन को बाइनरी-एन्कोडेड फ़्रेम के एक्सचेंज में बांट देता है. इसके बाद, इन्हें किसी खास स्ट्रीम से जुड़े मैसेज के साथ मैप किया जाता है. ये सभी एक ही टीसीपी कनेक्शन में मल्टीप्लेक्स होते हैं. यही वह फ़ाउंडेशन है जो एचटीटीपी/2 प्रोटोकॉल से मिलने वाली अन्य सभी सुविधाओं और परफ़ॉर्मेंस को ऑप्टिमाइज़ करता है.

अनुरोध और रिस्पॉन्स मल्टीप्लेक्सिंग

एचटीटीपी/1.x के साथ, अगर क्लाइंट परफ़ॉर्मेंस को बेहतर बनाने के लिए एक साथ कई अनुरोध करना चाहता है, तो एक से ज़्यादा टीसीपी कनेक्शन का इस्तेमाल किया जाना चाहिए (एक से ज़्यादा टीसीपी कनेक्शन का इस्तेमाल करना देखें). ऐसा, एचटीटीपी/1.x डिलीवरी मॉडल की वजह से होता है. इससे यह पक्का होता है कि हर कनेक्शन के लिए एक बार में एक ही रिस्पॉन्स (जवाब की सूची में शामिल) दिया जा सकता है. इससे भी बुरा यह है कि इसकी वजह से हेड-ऑफ़-लाइन ब्लॉक हो जाता है और दिए गए टीसीपी कनेक्शन का गलत इस्तेमाल होता है.

एचटीटीपी/2 में नई बाइनरी फ़्रेमिंग लेयर इन सीमाओं को हटा देती है. साथ ही, क्लाइंट और सर्वर को एचटीटीपी मैसेज को अलग-अलग फ़्रेम में बांटने, इंटरलीव करने, और फिर उन्हें दूसरे सिरे पर जोड़ने की अनुमति देकर, पूरे अनुरोध और रिस्पॉन्स को मल्टीप्लेक्सिंग देती है.

शेयर किए गए कनेक्शन में एचटीटीपी/2 अनुरोध और रिस्पॉन्स मल्टीप्लेक्सिंग

स्नैपशॉट में एक ही कनेक्शन में फ़्लाइट के दौरान कई स्ट्रीम कैप्चर की गई हैं. क्लाइंट स्ट्रीम 1 और 3 के लिए, फ़्रेम के इंटरलीव किए गए क्रम को क्लाइंट को भेज रहा है. इसी दौरान, क्लाइंट सर्वर पर DATA फ़्रेम (स्ट्रीम 5) भेज रहा है. इस वजह से, फ़्लाइट में एक साथ तीन स्ट्रीम होती हैं.

एचटीटीपी मैसेज को अलग-अलग फ़्रेम में बांटने, इंटरलीव करने, और दूसरी तरफ़ जोड़ने की क्षमता, एचटीटीपी/2 को बेहतर बनाने के लिए सबसे अहम है. असल में, यह सभी वेब टेक्नोलॉजी के स्टैक में मौजूद परफ़ॉर्मेंस से जुड़े कई फ़ायदों का रिपल इफ़ेक्ट पेश करता है, ताकि हम:

  • किसी भी अनुरोध को ब्लॉक किए बिना, एक साथ कई अनुरोध शामिल करें.
  • किसी एक को ब्लॉक किए बिना एक से ज़्यादा जवाब साथ-साथ इंटरलीव करें.
  • एक साथ कई अनुरोध और जवाब देने के लिए, एक ही कनेक्शन का इस्तेमाल करें.
  • ग़ैर-ज़रूरी HTTP/1.x समाधानों को हटाएं (HTTP/1.x के लिए ऑप्टिमाइज़ करना देखें, जैसे कि जोड़ी गई फ़ाइलें, इमेज स्प्राइट, और डोमेन शार्डिंग).
  • पेज लोड होने में लगने वाला समय कम करके, इंतज़ार का समय खत्म करें. साथ ही, उपलब्ध नेटवर्क की क्षमता के इस्तेमाल को बेहतर बनाएं.
  • अन्य सुविधाएं पाएं...

एचटीटीपी/2 में नई बाइनरी फ़्रेमिंग लेयर, एचटीटीपी/1.x में मिलने वाली हेड-ऑफ़-लाइन ब्लॉक करने की समस्या को हल करती है. साथ ही, अनुरोधों और जवाबों की समानांतर प्रोसेसिंग और डिलीवरी को चालू करने के लिए, एक से ज़्यादा कनेक्शन की ज़रूरत को खत्म करती है. इस वजह से, इससे हमारे ऐप्लिकेशन तेज़ी से, ज़्यादा आसान, और कम खर्च में डिप्लॉय हो जाते हैं.

स्ट्रीम की प्राथमिकता तय करना

जब एक एचटीटीपी मैसेज को कई अलग-अलग फ़्रेम में बांटा जा सकता है और हम कई स्ट्रीम के फ़्रेम को मल्टीप्लेक्स करने की अनुमति देते हैं, तो फ़्रेम को इंटरलीव करने और डिलीवर करने का क्रम, क्लाइंट और सर्वर, दोनों पर लागू होता है. यह सुविधा देने के लिए, एचटीटीपी/2 स्टैंडर्ड हर स्ट्रीम को एक अलग वज़न और डिपेंडेंसी देता है:

  • हर स्ट्रीम को 1 से 256 के बीच का पूर्णांक असाइन किया जा सकता है.
  • हर स्ट्रीम को किसी दूसरी स्ट्रीम पर खास तौर पर निर्भर किया जा सकता है.

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

एचटीटीपी/2 स्ट्रीम डिपेंडेंसी और वेट

एचटीटीपी/2 में स्ट्रीम डिपेंडेंसी का एलान किसी दूसरी स्ट्रीम के यूनीक आइडेंटिफ़ायर को उसके पैरंट के तौर पर करके किया जाता है. अगर आइडेंटिफ़ायर को शामिल नहीं किया जाता है, तो स्ट्रीम को "रूट स्ट्रीम" पर निर्भर माना जाता है. स्ट्रीम की डिपेंडेंसी का एलान करने से यह पता चलता है कि अगर मुमकिन हो, तो पैरंट स्ट्रीम को उसकी डिपेंडेंसी से पहले ही संसाधन दिए जाने चाहिए. दूसरे शब्दों में, "कृपया प्रोसेस करें और जवाब D से पहले जवाब D दें".

एक ही पैरंट शेयर वाली स्ट्रीम (दूसरे शब्दों में कहें, तो सिबलिंग स्ट्रीम) को उनके वज़न के हिसाब से संसाधन दिए जाने चाहिए. उदाहरण के लिए, अगर स्ट्रीम A का वेट 12 है और इसकी एक सिबलिंग B का वज़न 4 है, तो इन सभी स्ट्रीम को मिलने वाले रिसॉर्स का अनुपात तय करें:

  1. सभी भारों का योग करें: 4 + 12 = 16
  2. हर स्ट्रीम के वेट को कुल वज़न से भाग दें: A = 12/16, B = 4/16

इसलिए, स्ट्रीम A को तीन-चौथाई और स्ट्रीम B को एक-चौथाई उपलब्ध संसाधन मिलने चाहिए. वहीं, स्ट्रीम B को स्ट्रीम A के लिए दिए गए संसाधनों का एक-तिहाई हिस्सा मिलना चाहिए. आइए, ऊपर दी गई इमेज में मौजूद कुछ और उदाहरण देखते हैं. बाएं से दाएं:

  1. न तो स्ट्रीम A और न ही B, पैरंट डिपेंडेंसी के बारे में बताते हैं और न ही इन्हें इंप्लिसिट "रूट स्ट्रीम" पर निर्भर माना जाता है; A का वेट 12 और B का वज़न 4 है. इसलिए, अनुपात के हिसाब से अहमियत: स्ट्रीम B को स्ट्रीम A के लिए तय किए गए संसाधनों का एक-तिहाई हिस्सा मिलना चाहिए.
  2. स्ट्रीम D, रूट स्ट्रीम पर निर्भर करती है और C, D पर निर्भर करती है. इसलिए, D को C से पहले संसाधनों का पूरा बंटवारा मिलना चाहिए. भार गैर-ज़रूरी हैं, क्योंकि C की डिपेंडेंसी ज़्यादा प्राथमिकता तय करती है.
  3. स्ट्रीम D को C से पहले संसाधनों का पूरा बंटवारा मिलना चाहिए; C को A और B से पहले संसाधनों का पूरा बंटवारा मिलना चाहिए; स्ट्रीम B को स्ट्रीम A के लिए तय संसाधनों का एक-तिहाई हिस्सा मिलना चाहिए.
  4. स्ट्रीम D को E और C से पहले संसाधनों का पूरा बंटवारा मिलना चाहिए; E और C को A और B से पहले बराबर बंटवारा मिलना चाहिए; A और B को उनके वेट के आधार पर आनुपातिक आवंटन मिलना चाहिए.

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

हर ऑरिजिन के लिए एक कनेक्शन

बाइनरी फ़्रेमिंग के नए तरीके के लागू होने के बाद, एचटीटीपी/2 को अब मल्टीप्लेक्स स्ट्रीम के लिए एक साथ कई टीसीपी कनेक्शन की ज़रूरत नहीं होगी. हर स्ट्रीम को कई फ़्रेम में बांटा जाता है. इनमें से किसी एक को इंटरलीव किया जा सकता है या फिर उसे प्राथमिकता दी जा सकती है. इस वजह से, सभी एचटीटीपी/2 कनेक्शन स्थायी होते हैं और हर ऑरिजिन के लिए सिर्फ़ एक कनेक्शन की ज़रूरत होती है. इससे परफ़ॉर्मेंस के कई फ़ायदे मिलते हैं.

एसपीडी और एचटीटीपी/2, दोनों के लिए किलर सुविधा, कुंआों को कंट्रोल करने वाले किसी एक चैनल पर आर्बिट्रेरी मल्टीप्लेक्सिंग है. मुझे यह जानकर हैरानी होती है कि यह कितना ज़रूरी है और यह कितनी अच्छी तरह काम करता है. इसका एक बेहतरीन मेट्रिक यह है कि ऐसे कनेक्शन बनाए गए हों जिनमें सिर्फ़ एक एचटीटीपी ट्रांज़ैक्शन हो. इस तरह, ट्रांज़ैक्शन का पूरा खर्च भी इस ट्रांज़ैक्शन से मिलता है. एचटीटीपी/1 के लिए, हमारे 74% ऐक्टिव कनेक्शन में सिर्फ़ एक ट्रांज़ैक्शन होता है. लगातार कनेक्शन हमारी ज़रूरत के मुताबिक काम के नहीं होते. हालांकि, एचटीटीपी/2 के मामले में यह संख्या घटकर 25% हो गई है. यह ओवरहेडिंग की कमी की एक बड़ी सफलता है. (Firefox/2 Firefox में लाइव है, पैट्रिक McManus)

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

फ़्लो कंट्रोल

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

क्या ऊपर बताई गई ज़रूरी शर्तें, आपको टीसीपी फ़्लो कंट्रोल के बारे में याद दिलाती हैं? ये होने चाहिए, क्योंकि समस्या काफ़ी हद तक एक जैसी है (फ़्लो कंट्रोल देखें). हालांकि, एचटीटीपी/2 स्ट्रीम एक ही टीसीपी कनेक्शन के अंदर मल्टीप्लेक्स किए जाते हैं, इसलिए टीसीपी फ़्लो कंट्रोल में ज़्यादा बारीकी से जानकारी नहीं होती. साथ ही, इससे अलग-अलग स्ट्रीम की डिलीवरी को रेगुलेट करने के लिए, ऐप्लिकेशन-लेवल के ज़रूरी एपीआई नहीं मिलते. इस समस्या को ठीक करने के लिए, एचटीटीपी/2 आसान बिल्डिंग ब्लॉक का एक सेट उपलब्ध कराता है. इससे क्लाइंट और सर्वर को स्ट्रीम और कनेक्शन लेवल का फ़्लो कंट्रोल लागू करने में मदद मिलती है:

  • फ़्लो कंट्रोल निर्देश देने वाला होता है. हर रिसीवर स्ट्रीम और पूरे कनेक्शन के लिए, अपनी पसंद की विंडो का साइज़ सेट कर सकता है.
  • फ़्लो कंट्रोल क्रेडिट पर आधारित होता है. हर रिसीवर अपने शुरुआती कनेक्शन और स्ट्रीम फ़्लो कंट्रोल विंडो (बाइट में) का विज्ञापन करता है, जो तब कम होता है, जब भेजने वाला एक DATA फ़्रेम से निकलता है और रिसीवर से भेजे गए WINDOW_UPDATE फ़्रेम से बढ़ता है.
  • फ़्लो कंट्रोल बंद नहीं किया जा सकता. जब एचटीटीपी/2 कनेक्शन बन जाता है, तो क्लाइंट और सर्वर एक्सचेंज SETTINGS फ़्रेम हो जाते हैं. इससे फ़्लो कंट्रोल विंडो का साइज़ दोनों तरफ़ सेट होता है. फ़्लो कंट्रोल विंडो की डिफ़ॉल्ट वैल्यू 65,535 बाइट पर सेट है. हालांकि, डेटा पाने वाला व्यक्ति विंडो का सबसे बड़ा साइज़ (2^31-1 बाइट) सेट कर सकता है. साथ ही, डेटा मिलने पर WINDOW_UPDATE फ़्रेम भेजकर उसे मैनेज कर सकता है.
  • फ़्लो कंट्रोल की सुविधा, एक-एक करके आगे-पीछे जाती है, न कि शुरू से अंत तक. इसका मतलब है कि एक मध्यस्थ इसका इस्तेमाल, संसाधन के इस्तेमाल को कंट्रोल करने और अपनी ज़रूरत और अनुभव के आधार पर संसाधनों का बंटवारा करने के तरीकों को लागू करने के लिए कर सकता है.

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

उदाहरण के लिए, ऐप्लिकेशन-लेयर फ़्लो कंट्रोल, ब्राउज़र को किसी खास संसाधन के सिर्फ़ एक हिस्से को फ़ेच करने की अनुमति देता है. इसके लिए, स्ट्रीम फ़्लो कंट्रोल विंडो को कम करके शून्य करके, फ़ेच को होल्ड पर रखने और बाद में उसे फिर से शुरू करने की अनुमति देता है. दूसरे शब्दों में कहें, तो यह ब्राउज़र को किसी इमेज की झलक या पहली स्कैन को फ़ेच करने, उसे दिखाने, और ज़्यादा प्राथमिकता वाले अन्य फ़ेच को आगे बढ़ने की अनुमति देता है. साथ ही, ज़रूरी संसाधन लोड होने के बाद फ़ेच को फिर से शुरू करता है.

सर्वर पुश

HTTP/2 की एक और नई और ताकतवर सुविधा यह है कि सर्वर किसी एक क्लाइंट अनुरोध के लिए कई जवाब भेज सकता है. इसका मतलब है कि मूल अनुरोध के रिस्पॉन्स के अलावा, सर्वर क्लाइंट को अतिरिक्त संसाधन (इमेज 12-5) भेज सकता है. इसके लिए, क्लाइंट को अलग से हर अनुरोध की ज़रूरत नहीं होगी.

सर्वर, पुश रिसॉर्स के लिए नई स्ट्रीम शुरू करने का वादा करता है

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

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

  • क्लाइंट ने कैश मेमोरी में सेव किया
  • अलग-अलग पेजों पर दोबारा इस्तेमाल किया गया
  • अन्य संसाधनों के साथ मल्टीप्लेक्स किया गया
  • सर्वर की प्राथमिकता वाला
  • क्लाइंट ने इसे अस्वीकार कर दिया है

पुश प्रॉमिस 101

सभी सर्वर पुश स्ट्रीम, PUSH_PROMISE फ़्रेम से शुरू की जाती हैं. इससे यह पता चलता है कि सर्वर का इंटेंट, बताए गए संसाधनों को क्लाइंट को भेजना है. साथ ही, यह स्ट्रीम, पुश किए जाने वाले संसाधनों के लिए अनुरोध करने वाले रिस्पॉन्स डेटा से पहले दी जानी चाहिए. डिलीवरी का यह क्रम बहुत ज़रूरी है: क्लाइंट को यह जानने की ज़रूरत होती है कि सर्वर किन संसाधनों को पुश करने की कोशिश करता है, ताकि इन संसाधनों के लिए डुप्लीकेट अनुरोध बनाने से बचा जा सके. इस ज़रूरी शर्त को पूरा करने के लिए, सबसे आसान तरीका यह है कि माता-पिता के जवाब (दूसरे शब्दों में, DATA फ़्रेम) से पहले ऐसे सभी PUSH_PROMISE फ़्रेम भेजें जिनमें सिर्फ़ वादा किए गए संसाधन के एचटीटीपी हेडर होते हैं.

क्लाइंट को PUSH_PROMISE फ़्रेम मिलने के बाद, अगर वह चाहे, तो स्ट्रीम को (RST_STREAM फ़्रेम के ज़रिए) अस्वीकार कर सकता है. (उदाहरण के लिए, ऐसा इसलिए हो सकता है, क्योंकि संसाधन पहले से ही कैश मेमोरी में मौजूद है.) यह HTTP/1.x की तुलना में एक अहम सुधार है. इसके उलट, रिसॉर्स इनलाइनिंग, जो एचटीटीपी/1.x के लिए लोकप्रिय "ऑप्टिमाइज़ेशन" है, का इस्तेमाल "फ़ोर्स्ड पुश" के बराबर है: क्लाइंट ऑप्ट-आउट, इसे रद्द या इनलाइन रिसॉर्स को अलग-अलग प्रोसेस नहीं कर सकता.

एचटीटीपी/2 का इस्तेमाल करने पर, क्लाइंट इस बात का पूरा कंट्रोल रखता है कि सर्वर पुश का इस्तेमाल कैसे किया जाता है. क्लाइंट एक साथ पुश की गई स्ट्रीम की संख्या को सीमित कर सकता है; शुरुआती फ़्लो कंट्रोल विंडो को अडजस्ट करें, ताकि यह कंट्रोल किया जा सके कि पहली बार स्ट्रीम खोलने पर कितना डेटा पुश किया जाए या सर्वर पुश को पूरी तरह से बंद किया जाए. इन प्राथमिकताओं की जानकारी, एचटीटीपी/2 कनेक्शन की शुरुआत में SETTINGS फ़्रेम से दी जाती है. साथ ही, इसे किसी भी समय अपडेट किया जा सकता है.

पुश किया गया हर संसाधन एक स्ट्रीम है, जो इनलाइन संसाधन के उलट है. इससे इसे अलग से मल्टीप्लेक्स, प्राथमिकता, और प्रोसेस किया जा सकता है. ब्राउज़र के मुताबिक, सुरक्षा से जुड़ी पाबंदी सिर्फ़ यह है कि पुश किए गए रिसॉर्स को एक ही ऑरिजिन की नीति का पालन करना चाहिए: सर्वर पर उपलब्ध कॉन्टेंट के लिए, सर्वर आधिकारिक होना चाहिए.

हेडर कंप्रेस करना

हर एचटीटीपी ट्रांसफ़र में, हेडर का एक सेट होता है. यह ट्रांसफ़र किए गए रिसॉर्स और उसकी प्रॉपर्टी की जानकारी देता है. एचटीटीपी/1.x में, यह मेटाडेटा हमेशा सामान्य टेक्स्ट के तौर पर भेजा जाता है. साथ ही, हर ट्रांसफ़र पर ओवरहेड के लिए, 500–800 बाइट का डेटा जोड़ता है. अगर एचटीटीपी कुकी का इस्तेमाल किया जा रहा हो, तो इसे कभी-कभी किलोबाइट ज़्यादा भी भेजा जा सकता है. (प्रोटोकॉल को मेज़र और कंट्रोल करना लेख देखें .) इस ओवरहेड को कम करने और परफ़ॉर्मेंस को बेहतर बनाने के लिए, एचटीटीपी/2, एचवीएसीके कंप्रेशन फ़ॉर्मैट का इस्तेमाल करके, अनुरोध और रिस्पॉन्स हेडर मेटाडेटा को कंप्रेस करता है. इस फ़ॉर्मैट में दो आसान लेकिन असरदार तकनीकों का इस्तेमाल किया जाता है:

  1. इससे ट्रांसमिट किए गए हेडर फ़ील्ड को स्टैटिक हफ़मैन कोड की मदद से एन्कोड किया जा सकता है. इससे उनका अलग-अलग ट्रांसफ़र साइज़ कम हो जाता है.
  2. इसके लिए यह ज़रूरी है कि क्लाइंट और सर्वर, दोनों पहले देखे गए हेडर फ़ील्ड की इंडेक्स की गई सूची को बनाए और अपडेट करें. दूसरे शब्दों में, इससे शेयर किया गया कंप्रेस करने का कॉन्टेक्स्ट तय होता है. इसके बाद, पहले ट्रांसमिट की गई वैल्यू को असरदार तरीके से कोड में बदलने के लिए, रेफ़रंस के तौर पर इस्तेमाल किया जाता है.

हफ़मैन कोडिंग की मदद से, ट्रांसफ़र किए जाने पर अलग-अलग वैल्यू को कंप्रेस किया जा सकता है. पहले ट्रांसफ़र की जा चुकी वैल्यू की इंडेक्स की गई सूची की मदद से, हम इंडेक्स वैल्यू को ट्रांसफ़र करके डुप्लीकेट वैल्यू को कोड में बदल सकते हैं. इन वैल्यू का इस्तेमाल, पूरे हेडर की कुंजियों और वैल्यू को बेहतर तरीके से खोजने और फिर से बनाने के लिए किया जा सकता है.

HPACK: एचटीटीपी/2 के लिए हेडर कंप्रेशन

इसके अलावा, एक और ऑप्टिमाइज़ेशन के तौर पर, HPACK कंप्रेशन कॉन्टेक्स्ट में स्टैटिक और डाइनैमिक टेबल होती है: स्टैटिक टेबल की जानकारी, स्पेसिफ़िकेशन में दी गई होती है.साथ ही, इसमें उन सामान्य एचटीटीपी हेडर फ़ील्ड की सूची होती है जिनका इस्तेमाल सभी कनेक्शन कर सकते हैं (जैसे, मान्य हेडर के नाम). डाइनैमिक टेबल शुरुआत में खाली होती है और इसे किसी कनेक्शन में एक्सचेंज की गई वैल्यू के आधार पर अपडेट किया जाता है. इस वजह से, हर अनुरोध का साइज़ कम करने के लिए स्टैटिक हफ़मैन कोडिंग की मदद ली जाती है. यह उन वैल्यू के लिए किया जाता है जो पहले नहीं देखी गई हैं. साथ ही, हर तरफ़ की स्टैटिक या डाइनैमिक टेबल में पहले से मौजूद वैल्यू के लिए, इंडेक्स को कम किया जाता है.

एचपीएसीके की सुरक्षा और परफ़ॉर्मेंस

HTTP/2 और SPDY के शुरुआती वर्शन में सभी एचटीटीपी हेडर को कंप्रेस करने के लिए, पसंद के मुताबिक शब्दकोश के साथ zlib का इस्तेमाल किया जाता है. इससे ट्रांसफ़र किए गए हेडर डेटा के साइज़ में 85% से 88% की कमी हुई. साथ ही, पेज लोड होने में लगने वाले समय में भी काफ़ी सुधार हुआ:

निचले बैंडविथ वाले DSL लिंक, जिसमें अपलोड लिंक सिर्फ़ 375 केबीपीएस का है, उस पर हेडर कंप्रेस करने का अनुरोध करने से कुछ साइटों के पेज लोड होने के समय में काफ़ी सुधार हुआ (दूसरे शब्दों में, वे साइटें जिन्होंने बड़ी संख्या में संसाधन अनुरोध जारी किए). हमें हेडर के कंप्रेस होने की वजह से, पेज लोड होने में 45 से 1142 मि॰से॰ की कमी आई. (SPDY वाइटपेपर, chromium.org)

हालांकि, 2012 की गर्मियों में, TLS और एसपीडीवाई कंप्रेशन एल्गोरिदम के ख़िलाफ़ "CRIME" सुरक्षा हमला पब्लिश किया गया. इस वजह से सेशन हाइजैक हो सकता था. इसलिए, zlib कंप्रेशन एल्गोरिदम को HPACK से बदल दिया गया. इसे खास तौर पर, सुरक्षा से जुड़ी समस्याओं को हल करने, असरदार और आसान तरीके से लागू करने, और एचटीटीपी हेडर मेटाडेटा को अच्छी तरह से कंप्रेस करने के लिए डिज़ाइन किया गया था.

HPACK कंप्रेस करने के एल्गोरिदम की पूरी जानकारी के लिए, IETF HPACK - एचटीटीपी/2 के लिए हेडर कंप्रेशन देखें.

इसके बारे में और पढ़ें