एचटीटीपी/2 हमारे ऐप्लिकेशन को तेज़, आसान, और ज़्यादा मज़बूत बनाएगा. यह हमारे ऐप्लिकेशन में पहले किए गए कई एचटीटीपी/1.1 समाधानों को पहले जैसा करने और ट्रांसपोर्ट लेयर में मौजूद समस्याओं को दूर करने की अनुमति देता है. हालांकि, ऐसा बहुत कम होता है. अच्छी बात यह है कि इससे हमारे ऐप्लिकेशन को ऑप्टिमाइज़ करने और परफ़ॉर्मेंस को बेहतर बनाने के कई नए अवसर भी मिलते हैं!
एचटीटीपी/2 के मुख्य लक्ष्य, पूरे अनुरोध और रिस्पॉन्स के लिए मल्टीप्लेक्सिंग की सुविधा चालू करके इंतज़ार के समय को कम करना, एचटीटीपी हेडर फ़ील्ड को बेहतर तरीके से कंप्रेस करके प्रोटोकॉल के ओवरहेड को कम करना, और अनुरोध की प्राथमिकता तय करने और सर्वर पुश करने के लिए सहायता जोड़ना है. इन ज़रूरी शर्तों को लागू करने के लिए, अन्य प्रोटोकॉल एनवायरमेंट की मदद से काफ़ी मदद मिलती है. जैसे, नए फ़्लो कंट्रोल, गड़बड़ियों को मैनेज करना, और अपग्रेड करने के तरीके. हालांकि, ये सबसे अहम सुविधाएं हैं, जिन्हें हर वेब डेवलपर को अपने ऐप्लिकेशन में समझना और उनका फ़ायदा उठाना चाहिए.
एचटीटीपी/2 किसी भी तरह से एचटीटीपी के ऐप्लिकेशन सिमेंटिक्स में बदलाव नहीं करता है. एचटीटीपी के तरीके, स्टेटस कोड, यूआरआई, और हेडर फ़ील्ड जैसे सभी मुख्य कॉन्सेप्ट पहले जैसे ही बने रहते हैं. इसके बजाय, एचटीटीपी/2 यह बदलाव करता है कि क्लाइंट और सर्वर के बीच डेटा को कैसे फ़ॉर्मैट (फ़्रेम किया जाता है) और ट्रांसफ़र किया जाता है. ये दोनों पूरी प्रोसेस को मैनेज करते हैं और नई फ़्रेमिंग लेयर में, हमारे ऐप्लिकेशन की सारी जटिलता को छिपा देते हैं. नतीजे के तौर पर, सभी मौजूदा ऐप्लिकेशन बिना किसी बदलाव के डिलीवर किए जा सकते हैं.
एचटीटीपी/1.2 क्यों नहीं है?
एचटीटीपी वर्किंग ग्रुप ने परफ़ॉर्मेंस के लिए जो लक्ष्य तय किए हैं उन्हें हासिल करने के लिए, एचटीटीपी/2 एक नया बाइनरी फ़्रेमिंग लेयर लॉन्च करता है. यह बाइनरी फ़्रेमिंग लेयर, पिछले एचटीटीपी/1.x सर्वर और क्लाइंट के साथ काम नहीं करता है. इसलिए, एचटीटीपी/2 में प्रोटोकॉल वर्शन में खास बढ़ोतरी हुई है.
हालांकि, जब तक आप रॉ टीसीपी सॉकेट के साथ काम करके वेब सर्वर (या कस्टम क्लाइंट) लागू नहीं करते, तब तक आपको कोई अंतर नहीं दिखेगा: क्लाइंट और सर्वर, आपकी ओर से सभी नई, लो-लेवल फ़्रेमिंग को पूरा करते हैं. सिर्फ़ अनुरोध की प्राथमिकता, फ़्लो कंट्रोल, और सर्वर पुश जैसी नई सुविधाओं की उपलब्धता और परफ़ॉर्मेंस में सुधार होगा.
SPDY और HTTP/2 का संक्षिप्त इतिहास
SPDY एक प्रयोग के तौर पर शुरू किया गया प्रोटोकॉल था, जिसे Google ने बनाया था और इसे 2009 के मध्य में घोषणा की गई थी. इसका मुख्य लक्ष्य एचटीटीपी/1.1 की परफ़ॉर्मेंस की कुछ जाने-माने समस्याओं को हल करके वेब पेजों के लोड होने में लगने वाला समय कम करना था. खास तौर पर, प्रोजेक्ट के लिए आउटलाइन किए गए लक्ष्य इस तरह से सेट किए गए थे:
- पेज लोड होने में लगने वाले समय (पीएलटी) में 50% की कमी करने का टारगेट.
- वेबसाइट के लेखकों को कॉन्टेंट में किसी भी तरह का बदलाव करने से बचें.
- डिप्लॉयमेंट की जटिलता को कम करें और नेटवर्क इन्फ़्रास्ट्रक्चर में बदलावों से बचें.
- ओपन-सोर्स समुदाय के साथ मिलकर इस नए प्रोटोकॉल को बनाएं.
- एक्सपेरिमेंट के प्रोटोकॉल की पुष्टि करने के लिए, परफ़ॉर्मेंस का असल डेटा इकट्ठा करें.
शुरुआती घोषणा के कुछ ही समय बाद, Google के दोनों सॉफ़्टवेयर इंजीनियर माइक बेलशे और रॉबर्टो पीऑन ने नए SPDY प्रोटोकॉल को आज़माने के लिए, अपने शुरुआती नतीजे, दस्तावेज़, और सोर्स कोड शेयर किए:
अब तक हमने केवल प्रयोगशाला स्थितियों में SPDY का परीक्षण किया है. शुरुआती नतीजे काफ़ी हौसला बढ़ाने वाले हैं: जब हम सिम्युलेटेड होम नेटवर्क कनेक्शन से शीर्ष 25 वेबसाइटें डाउनलोड करते हैं, तो हमें परफ़ॉर्मेंस में काफ़ी सुधार देखने को मिलता है—पेज 55% तक तेज़ी से लोड होते हैं. (Chromium ब्लॉग)
साल 2012 में, एक्सपेरिमेंट के तौर पर उपलब्ध नया प्रोटोकॉल Chrome, Firefox, और Opera में काम करता था. साथ ही, बड़ी और छोटी, दोनों तरह की साइटों (उदाहरण के लिए, Google, Twitter, Facebook) और छोटी साइटों की संख्या तेज़ी से बढ़ रही थी. ये प्रोटोकॉल, अपने इन्फ़्रास्ट्रक्चर में SPDY का इस्तेमाल कर रहे थे. इस तरह से, इंडस्ट्री में बढ़ते हुए बदलावों के ज़रिए, SPDY एक असल मानक बनने के लिए तैयार था.
इस रुझान को देखते हुए, एचटीटीपी वर्किंग ग्रुप (एचटीटीपी-डब्ल्यूजी) ने SPDY से सीखे गए सबक लेने, उन्हें बनाने और उनमें सुधार करने, और आधिकारिक "एचटीटीपी/2" स्टैंडर्ड डिलीवर करने की नई कोशिश की. एक नया चार्टर ड्राफ़्ट किया गया, एचटीटीपी/2 प्रस्तावों के लिए एक ओपन कॉल किया गया, और वर्किंग ग्रुप में हुई काफ़ी चर्चा के बाद, नए एचटीटीपी/2 प्रोटोकॉल को शुरू करने के लिए SPDY स्पेसिफ़िकेशन को अपनाया गया.
अगले कुछ सालों तक SPDY और HTTP/2 में एक साथ काम करना जारी रहा. SPDY, प्रयोग के तौर पर शुरू की गई ब्रांच के तौर पर काम करता रहा. इसका इस्तेमाल, एचटीटीपी/2 स्टैंडर्ड के लिए नई सुविधाओं और प्रस्तावों की जांच करने के लिए किया गया. ऐसा हो सकता है कि कागज़ पर जो अच्छा लगता हो, वह असल में काम न करे. इसी तरह, SPDY ने हर प्रस्ताव की जांच और आकलन करने के लिए एक तरीका बताया. उसे एचटीटीपी/2 स्टैंडर्ड में शामिल करने से पहले ऐसा किया जा सकता है. आखिर में, इस प्रोसेस को तीन साल पूरा हुआ और इस प्रोसेस के एक दर्जन से ज़्यादा इंटरमीडिएट ड्राफ़्ट तैयार हुए:
- मार्च 2012: HTTP/2 के प्रस्तावों के लिए अनुरोध
- नवंबर 2012: एचटीटीपी/2 का पहला ड्राफ़्ट (SPDY पर आधारित)
- अगस्त 2014: एचटीटीपी/2 ड्राफ़्ट-17 और HPACK ड्राफ़्ट-12 पब्लिश किए गए हैं
- अगस्त 2014: एचटीटीपी/2 के लिए वर्किंग ग्रुप का आखिरी कॉल
- फ़रवरी 2015: IEG ने HTTP/2 और HPACK ड्राफ़्ट को मंज़ूरी दी
- मई 2015: RFC 7540 (HTTP/2) और RFC 7541 (HPACK) प्रकाशित किए गए हैं
साल 2015 की शुरुआत में आईईएसजी ने पब्लिकेशन के लिए, नए एचटीटीपी/2 स्टैंडर्ड की समीक्षा की और उसे मंज़ूरी दी. इसके कुछ ही समय बाद, Google Chrome टीम ने TLS के लिए SPDY और NPN एक्सटेंशन को रोकने के अपने शेड्यूल की घोषणा की:
एचटीटीपी/1.1 से एचटीटीपी/2 के मुख्य बदलाव, बेहतर परफ़ॉर्मेंस पर फ़ोकस करते हैं. मल्टीप्लेक्सिंग, हेडर कंप्रेशन, प्राथमिकता, और प्रोटोकॉल से जुड़ी बातचीत जैसी कुछ मुख्य सुविधाएं, SPDY नाम के नॉन-स्टैंडर्ड प्रोटोकॉल में काम करने से बेहतर हुई हैं. Chrome, Chrome 6 से SPDY के साथ काम कर रहा है, लेकिन एचटीटीपी/2 में होने वाले ज़्यादातर फ़ायदे, अब इसे बंद करने का समय है. हम 2016 की शुरुआत में ही SPDY के लिए सहायता बंद करने की योजना बना रहे हैं. साथ ही, Chrome में ALPN के लिए NPN नाम के TLS एक्सटेंशन के साथ भी काम करना बंद कर देंगे. हमारा सुझाव है कि सर्वर डेवलपर को एचटीटीपी/2 और ALPN का ही इस्तेमाल करें.
हमें खुशी है कि हमने ओपन स्टैंडर्ड की प्रोसेस में योगदान दिया है जिसकी वजह से एचटीटीपी/2 शुरू हुआ है. साथ ही, हमें उम्मीद है कि स्टैंडर्डाइज़ेशन और लागू करने के लिए, इंडस्ट्री में बड़े पैमाने पर जुड़ने की वजह से, हम इसे बड़े पैमाने पर स्वीकार करेंगे. (Chromium ब्लॉग)
SPDY और एचटीटीपी/2 की सुविधा वाले सर्वर, ब्राउज़र, और साइट डेवलपर के साथ मिलकर नए प्रोटोकॉल को डेवलप करते समय, इसका इस्तेमाल असल ज़िंदगी में करने का अनुभव पाने के लिए किया गया. इसलिए, एचटीटीपी/2 स्टैंडर्ड को मौजूदा समय के लिए सबसे बेहतर और बड़े पैमाने पर टेस्ट किए गए स्टैंडर्ड में से एक माना जाता है. एचटीटीपी/2 को आईईएसजी से मंज़ूरी मिलने तक, क्लाइंट और सर्वर को अच्छी तरह से जांचा-परखा और प्रोडक्शन के लिए तैयार किया गया था. दरअसल, आखिरी प्रोटोकॉल को मंज़ूरी मिलने के कुछ ही हफ़्तों बाद, कई लोगों को इसके फ़ायदे मिलने शुरू हो गए थे. ऐसा कई लोकप्रिय ब्राउज़र (और कई साइटों) के तौर पर किया जा रहा था, जिनमें एचटीटीपी/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 की परफ़ॉर्मेंस को बेहतर बनाने के लिए किए गए सभी बेहतर कामों में सबसे अहम है नई बाइनरी फ़्रेमिंग लेयर. यह बताता है कि एचटीटीपी मैसेज को कैसे एनकैप्सुलेट किया जाता है और क्लाइंट और सर्वर के बीच ट्रांसफ़र किया जाता है.
"लेयर" का मतलब है, सॉकेट इंटरफ़ेस और हमारे ऐप्लिकेशन में दिखाए गए सबसे ऊपर के एचटीटीपी एपीआई के बीच, ऑप्टिमाइज़ किया गया नया एन्कोड करने का तरीका उपलब्ध कराना: एचटीटीपी सिमेंटिक्स, जैसे कि क्रिया, मेथड, और हेडर पर कोई असर नहीं पड़ता. हालांकि, ट्रांज़िट के दौरान उन्हें एन्कोड करने का तरीका अलग होता है. न्यूलाइन डीलिमिटेड सादा टेक्स्ट एचटीटीपी/1.x प्रोटोकॉल से अलग, हर एचटीटीपी/2 मैसेज को छोटे मैसेज और फ़्रेम में बांटा जाता है. हर मैसेज और फ़्रेम को बाइनरी फ़ॉर्मैट में एन्कोड किया जाता है.
ऐसे में, क्लाइंट और सर्वर को एक-दूसरे को समझने के लिए, नई बाइनरी एन्कोडिंग प्रोसेस का इस्तेमाल करना होगा: एक एचटीटीपी/1.x क्लाइंट, सिर्फ़ एचटीटीपी/2 सर्वर को नहीं समझ पाएगा. इसी तरह, क्लाइंट और सर्वर को एक-दूसरे को समझने के लिए, नई बाइनरी एन्कोडिंग प्रोसेस का इस्तेमाल करना होगा. शुक्र है कि हमारे ऐप्लिकेशन इन सभी बदलावों के बारे में अनजान रहते हैं, क्योंकि क्लाइंट और सर्वर हमारी ओर से सभी ज़रूरी फ़्रेमिंग काम करते हैं.
स्ट्रीम, मैसेज, और फ़्रेम
बाइनरी फ़्रेमिंग की नई तकनीक आने से, क्लाइंट और सर्वर के बीच डेटा ट्रांसफ़र करने का तरीका बदल गया है. इस प्रोसेस के बारे में बताने के लिए, आइए हम खुद को HTTP/2 शब्दावली के बारे में जानें:
- स्ट्रीम: पहले से मौजूद कनेक्शन में बाइट का दोतरफ़ा फ़्लो, जिसमें एक या एक से ज़्यादा मैसेज हो सकते हैं.
- मैसेज: फ़्रेम का पूरा क्रम जो लॉजिकल रिक्वेस्ट या रिस्पॉन्स मैसेज पर मैप करता है.
- फ़्रेम: HTTP/2 में कम्यूनिकेशन की सबसे छोटी इकाई. हर एक में फ़्रेम हेडर होता है, जो कम से कम उस स्ट्रीम की पहचान करता है जिससे फ़्रेम जुड़ा है.
इन दोनों शब्दों के बीच संबंध के बारे में इस तरह से जानकारी दी जा सकती है:
- सभी कम्यूनिकेशन एक ही टीसीपी कनेक्शन पर किए जाते हैं, जिसमें कई दोतरफ़ा स्ट्रीम हो सकती हैं.
- हर स्ट्रीम का एक यूनीक आइडेंटिफ़ायर और प्राथमिकता वाली वैकल्पिक जानकारी होती है. इसका इस्तेमाल दोतरफ़ा मैसेज दिखाने के लिए किया जाता है.
- हर मैसेज एक लॉजिकल एचटीटीपी मैसेज होता है, जैसे कि कोई अनुरोध या रिस्पॉन्स. इसमें एक या एक से ज़्यादा फ़्रेम होते हैं.
- फ़्रेम, कम्यूनिकेशन की सबसे छोटी यूनिट है.इसमें खास तरह का डेटा होता है. जैसे, एचटीटीपी हेडर, मैसेज पेलोड वगैरह. अलग-अलग स्ट्रीम के फ़्रेम इंटरलीव किए जा सकते हैं और फिर उन्हें हर फ़्रेम के हेडर में एम्बेड किए गए स्ट्रीम आइडेंटिफ़ायर की मदद से फिर से जोड़ा जा सकता है.
एचटीटीपी/2, एचटीटीपी प्रोटोकॉल कम्यूनिकेशन को बाइनरी-एन्कोडेड फ़्रेम के एक्सचेंज में बांट देता है. इसके बाद, इन फ़्रेम को किसी खास स्ट्रीम से जुड़े मैसेज पर मैप किया जाता है. ये सभी एक टीसीपी कनेक्शन के अंदर मल्टीप्लेक्स होते हैं. यही वह आधार है जो एचटीटीपी/2 प्रोटोकॉल से मिलने वाली अन्य सभी सुविधाओं और परफ़ॉर्मेंस को ऑप्टिमाइज़ करता है.
मल्टीप्लेक्सिंग का अनुरोध और जवाब
एचटीटीपी/1.x के साथ, अगर क्लाइंट परफ़ॉर्मेंस को बेहतर बनाने के लिए एक साथ कई अनुरोध करना चाहता है, तो एक से ज़्यादा टीसीपी कनेक्शन का इस्तेमाल करना ज़रूरी है (एक से ज़्यादा टीसीपी कनेक्शन का इस्तेमाल करना देखें). यह व्यवहार एचटीटीपी/1.x डिलीवरी मॉडल का सीधा नतीजा है, जो यह पक्का करता है कि हर कनेक्शन के लिए एक बार में सिर्फ़ एक जवाब (रिस्पॉन्स की सूची बनाना) दिया जाए. इससे भी बदतर स्थिति में, हेड-ऑफ़-लाइन ब्लॉक करने की समस्या होती है और पहले से मौजूद टीसीपी कनेक्शन का गलत तरीके से इस्तेमाल होता है.
एचटीटीपी/2 में नई बाइनरी फ़्रेमिंग लेयर, इन सीमाओं को हटा देती है. साथ ही, क्लाइंट और सर्वर को एचटीटीपी मैसेज को अलग-अलग फ़्रेम में बांटने, उन्हें इंटरलीव करने, और दूसरी ओर फिर से जोड़ने की अनुमति देकर, पूरे अनुरोध और रिस्पॉन्स के लिए मल्टीप्लेक्सिंग की सुविधा चालू करती है.
स्नैपशॉट एक ही कनेक्शन में फ़्लाइट में कई स्ट्रीम कैप्चर करता है. क्लाइंट, सर्वर को DATA फ़्रेम (स्ट्रीम 5) भेज रहा है, जबकि सर्वर 1 और 3 स्ट्रीम के लिए, क्लाइंट को फ़्रेम का इंटरलीव किया गया क्रम भेज रहा है. इस वजह से, फ़्लाइट में तीन स्ट्रीम पैरलल हैं.
एचटीटीपी/2 मैसेज को अलग-अलग फ़्रेम में बांटने, उन्हें इंटरलीव करने, और दूसरी ओर फिर से इकट्ठा करने की सुविधा ही सबसे अहम है. असल में, इससे सभी वेब टेक्नोलॉजी के स्टैक पर कई परफ़ॉर्मेंस को लेकर कई फ़ायदे मिलते हैं, जिससे हम ये काम कर पाते हैं:
- किसी एक पर ब्लॉक किए बिना, एक साथ कई अनुरोधों को इंटरलीव करें.
- किसी एक पर ब्लॉक किए बिना, एक साथ कई जवाबों को इंटरलीव करें.
- एक साथ कई अनुरोध और जवाब देने के लिए एक ही कनेक्शन का इस्तेमाल करें.
- एचटीटीपी/1.x के गैर-ज़रूरी तरीके हटाएं (एचटीटीपी/1.x के लिए ऑप्टिमाइज़ करना देखें, जैसे कि जोड़ी गई फ़ाइलें, इमेज स्प्राइट, और डोमेन शार्डिंग).
- बेवजह की देरी को हटाकर और उपलब्ध नेटवर्क क्षमता के इस्तेमाल को बेहतर बनाकर, पेज लोड होने में लगने वाले समय को कम किया जा सकता है.
- अन्य फ़ायदे भी पाएं...
एचटीटीपी/2 में नई बाइनरी फ़्रेमिंग लेयर, एचटीटीपी/1.x में मिली हेड-ऑफ़-लाइन ब्लॉकिंग समस्या को ठीक करती है. साथ ही, अनुरोधों और जवाबों की पैरलल प्रोसेसिंग और डिलीवरी के लिए, एक से ज़्यादा कनेक्शन की ज़रूरत नहीं पड़ती है. नतीजतन, इससे हमारे ऐप्लिकेशन को डिप्लॉय करना आसान, तेज़, और कम हो जाता है.
स्ट्रीम की प्राथमिकता
एक बार एचटीटीपी मैसेज को कई अलग-अलग फ़्रेम में बांटा जा सकता है और हम एक से ज़्यादा स्ट्रीम के फ़्रेम को मल्टीप्लेक्स करने की अनुमति देते हैं. इसके बाद, क्लाइंट और सर्वर, दोनों के फ़्रेम इंटरलीव और डिलीवर किए जाने का क्रम अहम हो जाता है. यह सुविधा उपलब्ध कराने के लिए, एचटीटीपी/2 स्टैंडर्ड हर स्ट्रीम में एक वेट और डिपेंडेंसी जोड़ने की अनुमति देता है:
- हर स्ट्रीम को 1 से 256 के बीच का कोई पूर्णांक असाइन किया जा सकता है.
- हर स्ट्रीम को किसी दूसरी स्ट्रीम पर साफ़ तौर पर निर्भरता दी जा सकती है.
स्ट्रीम डिपेंडेंसी और वेट के कॉम्बिनेशन की मदद से, क्लाइंट एक "प्राथमिकता ट्री" बना सकता है और उसे कम्यूनिकेट कर सकता है. इससे यह पता चलता है कि उपयोगकर्ता को किस तरह से जवाब मिलने चाहिए. इससे सर्वर इस जानकारी का इस्तेमाल, स्ट्रीमिंग की प्रोसेस को प्राथमिकता देने के लिए कर सकता है. ऐसा करने के लिए, सीपीयू, मेमोरी, और अन्य संसाधनों को असाइन किया जाता है. रिस्पॉन्स डेटा उपलब्ध होने के बाद, क्लाइंट को ज़्यादा प्राथमिकता वाले जवाबों की बेहतर डिलीवरी पक्का करने के लिए बैंडविथ का बंटवारा किया जा सकता है.
एचटीटीपी/2 में स्ट्रीम डिपेंडेंसी का एलान, किसी दूसरी स्ट्रीम के यूनीक आइडेंटिफ़ायर को उसकी पैरंट स्ट्रीम के तौर पर देकर किया जाता है. अगर आइडेंटिफ़ायर को छोड़ दिया जाता है, तो स्ट्रीम को "रूट स्ट्रीम" पर निर्भर माना जाता है. स्ट्रीम डिपेंडेंसी का एलान करने से यह पता चलता है कि अगर मुमकिन हो, तो पैरंट स्ट्रीम को इसकी डिपेंडेंसी से पहले संसाधन असाइन किए जाने चाहिए. दूसरे शब्दों में कहें, "कृपया जवाब C से पहले जवाब D प्रोसेस करें और उसे डिलीवर करें".
एक ही पैरंट स्ट्रीम (दूसरे शब्दों में कहें, तो सिबलिंग स्ट्रीम) में किए जाने वाले संसाधनों को उनके वज़न के हिसाब से बांटा जाना चाहिए. उदाहरण के लिए, अगर स्ट्रीम A का वज़न 12 है और उसकी एक सिबलिंग B का वज़न 4 है, तो इन स्ट्रीम में मिलने वाले संसाधनों का अनुपात तय करने के लिए:
- सभी वज़नों को जोड़ें:
4 + 12 = 16 - हर स्ट्रीम के वज़न को कुल वज़न से विभाजित करें:
A = 12/16, B = 4/16
इसका मतलब है कि स्ट्रीम A को तीन चौथाई और स्ट्रीम B को उपलब्ध संसाधनों का एक चौथाई हिस्सा और स्ट्रीम B को स्ट्रीम A के लिए तय संसाधनों का एक तिहाई मिलेगा. आइए, ऊपर दी गई इमेज में कुछ और व्यावहारिक उदाहरणों के बारे में बात करते हैं. बाएं से दाएं:
- स्ट्रीम A और B, दोनों में से किसी भी पैरंट डिपेंडेंसी के बारे में नहीं बताया जाता है. इन्हें इंप्लिसिट "रूट स्ट्रीम" पर निर्भर माना जाता है. A का वज़न 12 है और B का वज़न 4 है. इसलिए, आनुपातिक वेट के आधार पर: स्ट्रीम B को, स्ट्रीम A के लिए असाइन किए गए एक तिहाई रिसॉर्स मिलना चाहिए.
- स्ट्रीम D, रूट स्ट्रीम पर निर्भर करती है. C, D पर निर्भर करती है. इसलिए, D को संसाधनों का पूरा बंटवारा C से पहले मिलना चाहिए. दोनों वैल्यू एक-दूसरे से मेल नहीं खातीं, क्योंकि C की डिपेंडेंसी से ज़्यादा अहम फ़ैक्टर के बारे में पता चलता है.
- स्ट्रीम D को सभी संसाधन, C से पहले मिलने चाहिए. C को सभी संसाधन A और B से पहले मिलने चाहिए. स्ट्रीम B को, स्ट्रीम A के लिए तय संसाधनों का एक तिहाई हिस्सा मिलना चाहिए.
- स्ट्रीम D को संसाधनों का पूरा बंटवारा, E और C से पहले मिलना चाहिए. E और C को A और B से पहले बराबर बंटवारा मिलना चाहिए. A और B को उनके महत्व के आधार पर अनुपात का बराबर हिस्सा मिलना चाहिए.
जैसा कि ऊपर दिए गए उदाहरण में बताया गया है, स्ट्रीम डिपेंडेंसी और वेट का कॉम्बिनेशन, संसाधन की प्राथमिकता के बारे में साफ़ तौर पर जानकारी देता है. यह ब्राउज़िंग परफ़ॉर्मेंस को बेहतर बनाने के लिए एक अहम सुविधा है, जहां हमारे पास अलग-अलग डिपेंडेंसी और वेट वाले कई तरह के संसाधन होते हैं. इससे भी अच्छी बात यह है कि एचटीटीपी/2 प्रोटोकॉल से क्लाइंट को किसी भी समय इन प्राथमिकताओं को अपडेट करने की अनुमति भी मिल जाती है. इससे ब्राउज़र में ज़्यादा ऑप्टिमाइज़ेशन की सुविधा चालू हो जाती है. दूसरे शब्दों में, हम डिपेंडेंसी बदल सकते हैं और उपयोगकर्ता इंटरैक्शन और दूसरे सिग्नल के मुताबिक वेट फिर से तय कर सकते हैं.
हर ऑरिजिन के लिए एक कनेक्शन
बाइनरी फ़्रेमिंग के नए तरीके की वजह से, एचटीटीपी/2 को अब एक साथ मल्टीप्लेक्स स्ट्रीम के लिए कई टीसीपी कनेक्शन की ज़रूरत नहीं है. हर स्ट्रीम को कई फ़्रेम में बांटा जाता है, जिन्हें इंटरलीव किया जा सकता है और प्राथमिकता दी जा सकती है. इस वजह से, सभी एचटीटीपी/2 कनेक्शन स्थायी होते हैं और हर ऑरिजिन के लिए सिर्फ़ एक कनेक्शन की ज़रूरत होती है. इससे परफ़ॉर्मेंस को कई फ़ायदे मिलते हैं.
SPDY और HTTP/2 दोनों के लिए किलर सुविधा, सिंगल वेल कंजेशन कंट्रोल चैनल पर आर्बिट्रेरी मल्टीप्लेक्सिंग है. मुझे हैरानी होती है कि यह कितना ज़रूरी है और कितनी अच्छी तरह से काम करता है. इसकी सबसे अच्छी मेट्रिक, उन कनेक्शन का हिस्सा है जो सिर्फ़ एक एचटीटीपी लेन-देन पूरा करते हैं (और इस तरह, वह लेन-देन पूरा ओवरहेड देते हैं). एचटीटीपी/1 के लिए, हमारे 74% ऐक्टिव कनेक्शन में सिर्फ़ एक ट्रांज़ैक्शन होता है. स्थायी कनेक्शन, उतने मददगार नहीं होते जितने हम सभी चाहते हैं. हालांकि, एचटीटीपी/2 में यह संख्या गिरकर 25% हो गई है. यह ओवरहेड कम करने के लिए एक बहुत बड़ी उपलब्धि है. (एचटीटीपी/2, Firefox में लाइव है, पैट्रिक McManus)
ज़्यादातर एचटीटीपी ट्रांसफ़र कम समय के होते हैं और उनमें डेटा बर्स्ट होता है. वहीं, टीसीपी को लंबे समय तक चलने वाले बल्क डेटा ट्रांसफ़र के लिए ऑप्टिमाइज़ किया जाता है. एक ही कनेक्शन का दोबारा इस्तेमाल करके, एचटीटीपी/2 हर टीसीपी कनेक्शन का बेहतर तरीके से इस्तेमाल कर सकता है. साथ ही, प्रोटोकॉल के ओवरहेड को भी काफ़ी कम कर सकता है. इसके अलावा, कम कनेक्शन का इस्तेमाल करने से पूरे कनेक्शन पाथ (दूसरे शब्दों में, क्लाइंट, मध्यस्थ, और ऑरिजिन सर्वर) पर मेमोरी और प्रोसेसिंग फ़ुटप्रिंट कम हो जाते हैं. इससे ऑपरेशन की कुल लागत कम होती है और नेटवर्क का इस्तेमाल बेहतर होता है. साथ ही, उसकी क्षमता भी बेहतर होती है. नतीजतन, एचटीटीपी/2 का इस्तेमाल करने से नेटवर्क पर होने वाले असर को कम करना चाहिए. साथ ही, नेटवर्क को बेहतर बनाने और ऑपरेशनल लागत को कम करने में भी मदद मिलेगी.
फ़्लो कंट्रोल
फ़्लो कंट्रोल एक ऐसा तरीका है, जिससे भेजने वाले को रिसीवर पर बहुत ज़्यादा दबाव डालने से रोका जाता है. ऐसा हो सकता है कि वह डेटा को प्रोसेस न कर पाए या उसे प्रोसेस न कर पाए: हो सकता है कि कॉन्टेंट पाने वाला व्यस्त हो, बहुत ज़्यादा लोड हो या किसी खास स्ट्रीम के लिए सिर्फ़ एक तय संख्या में संसाधन तय करने को तैयार हो. उदाहरण के लिए, हो सकता है कि क्लाइंट ने ज़्यादा प्राथमिकता वाली एक बड़ी वीडियो स्ट्रीम का अनुरोध किया हो, लेकिन उपयोगकर्ता ने वीडियो को रोक दिया हो और क्लाइंट अब गैर-ज़रूरी डेटा को फ़ेच और बफ़र होने से बचाने के लिए, उसकी डिलीवरी को सर्वर से रोकना या उसे कम करना चाहता है. इसके अलावा, एक प्रॉक्सी सर्वर के पास तेज़ डाउनस्ट्रीम और धीमे अपस्ट्रीम कनेक्शन हो सकते हैं और इसी तरह वह यह कंट्रोल करना चाहता है कि डाउनस्ट्रीम डेटा को कितनी तेज़ी से डिलीवर करे, ताकि रिसॉर्स के इस्तेमाल को कंट्रोल किया जा सके और अपस्ट्रीम की स्पीड एक जैसी हो.
क्या ऊपर दी गई ज़रूरी शर्तें आपको टीसीपी फ़्लो कंट्रोल की याद दिलाती हैं? दोनों एक जैसे ही होने चाहिए. (फ़्लो कंट्रोल देखें). हालांकि, एक ही टीसीपी कनेक्शन में एचटीटीपी/2 स्ट्रीम मल्टीप्लेक्स होने की वजह से, टीसीपी फ़्लो कंट्रोल ज़्यादा विस्तृत नहीं होता है. साथ ही, यह अलग-अलग स्ट्रीम की डिलीवरी को कंट्रोल करने के लिए ज़रूरी ऐप्लिकेशन लेवल एपीआई उपलब्ध नहीं कराता है. इस समस्या को ठीक करने के लिए, एचटीटीपी/2 सामान्य बिल्डिंग ब्लॉक का एक सेट उपलब्ध कराता है. इससे क्लाइंट और सर्वर, स्ट्रीम और कनेक्शन लेवल के फ़्लो कंट्रोल को अपने हिसाब से लागू कर सकते हैं:
- फ़्लो कंट्रोल एक दिशा-निर्देश होता है. कॉन्टेंट पाने वाला व्यक्ति, हर स्ट्रीम और पूरे कनेक्शन के लिए अपनी पसंद के हिसाब से किसी भी विंडो साइज़ को सेट कर सकता है.
- फ़्लो कंट्रोल क्रेडिट पर आधारित होता है. हर पाने वाला अपने शुरुआती कनेक्शन और स्ट्रीम फ़्लो कंट्रोल विंडो का विज्ञापन करता है (बाइट में), जो तब कम हो जाता है, जब भेजने वाला व्यक्ति
DATAफ़्रेम बनाता है और पाने वाले की तरफ़ से भेजे गएWINDOW_UPDATEफ़्रेम के ज़रिए बढ़ता है. - फ़्लो कंट्रोल को बंद नहीं किया जा सकता. एचटीटीपी/2 कनेक्शन के इंस्टॉल होने के बाद, क्लाइंट और सर्वर एक्सचेंज
SETTINGSफ़्रेम सेट कर देता है. इससे फ़्लो कंट्रोल विंडो का साइज़ दोनों दिशाओं में सेट हो जाता है. फ़्लो कंट्रोल विंडो की डिफ़ॉल्ट वैल्यू 65,535 बाइट पर सेट है. हालांकि, डेटा पाने वाला व्यक्ति, विंडो का ज़्यादा से ज़्यादा साइज़ (2^31-1बाइट) सेट कर सकता है. साथ ही, डेटा मिलने परWINDOW_UPDATEफ़्रेम भेजकर इसे मैनेज कर सकता है. - फ़्लो कंट्रोल पूरी तरह से नहीं, बल्कि रुक-रुककर चलता है. इसका मतलब है कि मध्यस्थ उसका इस्तेमाल, संसाधनों के इस्तेमाल को कंट्रोल करने और अपने संसाधनों के बंटवारे की प्रोसेस को लागू करने के लिए कर सकता है. यह मैकेनिज़्म अपनी ज़रूरत के हिसाब से तय किया जाता है.
एचटीटीपी/2, फ़्लो कंट्रोल को लागू करने के लिए किसी खास एल्गोरिदम के बारे में नहीं बताता है. इसके बजाय, यह सेवा के आसान बिल्डिंग ब्लॉक और क्लाइंट और सर्वर को लागू होने से रोकता है. यह उसका इस्तेमाल संसाधनों के इस्तेमाल और बंटवारे को नियंत्रित करने के लिए कस्टम रणनीतियों को लागू करने में कर सकता है. साथ ही, डिलीवरी की नई क्षमताओं को लागू करने में मदद कर सकता है, जो हमारे वेब ऐप्लिकेशन की असल और अनुमानित परफ़ॉर्मेंस, दोनों को बेहतर बनाने में मदद कर सकते हैं. स्पीड, परफ़ॉर्मेंस, और लोगों के नज़रिए देखें.
उदाहरण के लिए, ऐप्लिकेशन-लेयर फ़्लो कंट्रोल, ब्राउज़र को किसी खास संसाधन के किसी हिस्से को फ़ेच करने की अनुमति देता है. साथ ही, स्ट्रीम फ़्लो की कंट्रोल विंडो को शून्य तक कम करके, फ़ेच करने की प्रोसेस को होल्ड पर रख देता है और बाद में प्रोसेस को फिर से शुरू कर सकता है. दूसरे शब्दों में कहें, तो यह ब्राउज़र को इमेज की झलक या पहली बार स्कैन करने की सुविधा देता है. साथ ही, इसे दिखाने और ज़्यादा ज़रूरी रिसॉर्स के लोड होने पर, फ़ेच करने की प्रोसेस को फिर से शुरू करने की सुविधा भी देता है.
सर्वर पुश
एचटीटीपी/2 की एक और बेहतरीन सुविधा है. यह सुविधा है कि सर्वर किसी एक क्लाइंट के अनुरोध पर कई जवाब भेज सकता है. इसका मतलब है कि मूल अनुरोध के रिस्पॉन्स के साथ-साथ, सर्वर क्लाइंट को अतिरिक्त रिसॉर्स (इमेज 12-5) भी भेज सकता है. इसके लिए, क्लाइंट को हर एक अनुरोध के लिए साफ़ तौर पर अनुरोध नहीं करना पड़ता.
हमें ब्राउज़र में इस तरह के तरीके की ज़रूरत क्यों है? आम तौर पर, किसी वेब ऐप्लिकेशन में कई संसाधन होते हैं. इन संसाधनों को क्लाइंट, सर्वर से मिले दस्तावेज़ की जांच करके खोजता है. इस वजह से, क्यों न इस प्रक्रिया में लगने वाले समय की अतिरिक्त ज़रूरत को हटाकर, सर्वर से जुड़े रिसॉर्स को समय से पहले भेज दिया जाए? सर्वर को पहले से ही पता होता है कि क्लाइंट को किन रिसॉर्स की ज़रूरत होगी; इसी सर्वर पुश को कहते हैं.
यही नहीं, अगर आपने कभी भी डेटा यूआरआई के ज़रिए सीएसएस, JavaScript या किसी दूसरे एसेट को इनलाइन किया है (संसाधन इनलाइनिंग देखें), तो इसका मतलब है कि आपको सर्वर पुश करने का व्यावहारिक अनुभव पहले से ही है. रिसॉर्स को दस्तावेज़ में मैन्युअल तरीके से इनलाइन करके, हम क्लाइंट के अनुरोध करने का इंतज़ार किए बिना उस रिसॉर्स को क्लाइंट को भेजते हैं. HTTP/2 के साथ भी हम ऐसे ही नतीजे मिल सकते हैं, लेकिन परफ़ॉर्मेंस में दूसरे फ़ायदे भी मिलेंगे. पुश रिसॉर्स ये हो सकते हैं:
- क्लाइंट ने कैश मेमोरी में सेव किया
- अलग-अलग पेजों पर फिर से इस्तेमाल किया गया
- अन्य संसाधनों के साथ मल्टीप्लेक्स
- सर्वर की प्राथमिकता
- क्लाइंट ने अस्वीकार कर दिया
PUSH_PROMISE 101
सभी सर्वर पुश स्ट्रीम PUSH_PROMISE फ़्रेम से शुरू की जाती हैं. इससे सर्वर को, बताए गए संसाधनों को क्लाइंट तक पहुंचाने के इरादे से सिग्नल भेजा जाता है. साथ ही, उसे रिस्पॉन्स डेटा से पहले डिलीवर करना पड़ता है जो पुश किए गए संसाधनों के लिए अनुरोध करता है. डिलीवरी का यह
ऑर्डर ज़रूरी है: क्लाइंट को यह जानना ज़रूरी है कि सर्वर
किन रिसॉर्स को पुश करने पर काम करता है, ताकि इन रिसॉर्स के लिए डुप्लीकेट
अनुरोध न किए जाएं. इस ज़रूरी शर्त को पूरा करने का सबसे आसान तरीका यह है कि आप सभी PUSH_PROMISE फ़्रेम भेजें, जिनमें बताए गए संसाधन के सिर्फ़ एचटीटीपी हेडर होते हैं. इन्हें माता-पिता के जवाब से पहले (दूसरे शब्दों में, DATA फ़्रेम) भेजें.
PUSH_PROMISE फ़्रेम मिलने के बाद, क्लाइंट अगर चाहे, तो स्ट्रीम को (RST_STREAM फ़्रेम के ज़रिए) अस्वीकार कर सकता है. (उदाहरण के लिए, ऐसा इसलिए हो सकता है, क्योंकि
संसाधन पहले से ही कैश मेमोरी में मौजूद है.) यह HTTP/1.x पर
एक अहम सुधार है. इसके उलट, रिसॉर्स इनलाइनिंग का इस्तेमाल, जो एचटीटीपी/1.x के लिए एक लोकप्रिय "ऑप्टिमाइज़ेशन" है. यह "ज़बरदस्ती पुश" की तरह काम करता है: क्लाइंट, ऑप्ट-आउट नहीं कर सकता, उसे रद्द नहीं कर सकता या इनलाइन रिसॉर्स को अलग से प्रोसेस नहीं कर सकता.
एचटीटीपी/2 के साथ क्लाइंट के पास यह तय करने का पूरा अधिकार रहता है कि सर्वर पुश का इस्तेमाल कैसे किया जाए. क्लाइंट एक साथ पुश की गई स्ट्रीम की संख्या को सीमित कर सकता है; स्ट्रीम को पहली बार खोलने पर, उपयोगकर्ता को भेजे जाने वाले डेटा को कंट्रोल करने के लिए, शुरुआती फ़्लो कंट्रोल विंडो में बदलाव कर सकता है या सर्वर पुश को पूरी तरह से बंद कर सकता है. इन प्राथमिकताओं को एचटीटीपी/2 कनेक्शन की शुरुआत में SETTINGS फ़्रेम के ज़रिए बताया जाता है और इन्हें किसी भी समय अपडेट किया जा सकता है.
पुश किया गया हर संसाधन एक ऐसी स्ट्रीम है जो इनलाइन संसाधन से अलग है. इसकी मदद से क्लाइंट इसे अलग-अलग मल्टीप्लेक्स, प्राथमिकता, और प्रोसेस कर पाता है. ब्राउज़र के ज़रिए लागू की गई सुरक्षा से जुड़ी पाबंदी सिर्फ़ यह होती है कि पुश किए गए रिसॉर्स के लिए भी एक ही ऑरिजिन वाली नीति का पालन करना ज़रूरी है. दिए गए कॉन्टेंट के लिए, सर्वर आधिकारिक तौर पर भरोसेमंद होना चाहिए.
हेडर कंप्रेशन
हर एचटीटीपी ट्रांसफ़र में हेडर का एक सेट होता है, जो ट्रांसफ़र किए गए रिसॉर्स और उसकी प्रॉपर्टी के बारे में बताता है. एचटीटीपी/1.x में, इस मेटाडेटा को हमेशा सामान्य टेक्स्ट के तौर पर भेजा जाता है. इसमें हर ट्रांसफ़र में 500–800 बाइट ओवरहेड जोड़ा जाता है. अगर एचटीटीपी कुकी का इस्तेमाल किया जा रहा है, तो कभी-कभी यह किलोबाइट ज़्यादा भी हो सकता है. (प्रोटोकॉल ओवरहेड को मेज़र और कंट्रोल करना देखें.) इस ओवरहेड को कम करने और परफ़ॉर्मेंस को बेहतर बनाने के लिए, एचटीटीपी/2 अनुरोध और रिस्पॉन्स हेडर मेटाडेटा को कंप्रेस करता है. इसके लिए, HPACK के कंप्रेशन फ़ॉर्मैट का इस्तेमाल किया जाता है. इसमें दो आसान, लेकिन असरदार तकनीकों का इस्तेमाल किया जाता है:
- यह भेजे गए हेडर फ़ील्ड को स्टैटिक हफ़मैन कोड की मदद से कोड में बदलने की अनुमति देता है. इससे, भेजे गए हेडर का साइज़ छोटा हो जाता है.
- इसके लिए यह ज़रूरी है कि क्लाइंट और सर्वर, दोनों पहले देखे गए हेडर फ़ील्ड की इंडेक्स की गई सूची को बनाए रखें और उसे अपडेट करें. दूसरे शब्दों में कहें, तो यह एक शेयर किया गया कंप्रेशन कॉन्टेक्स्ट सेट अप करता है. इसके बाद, पहले भेजी गई वैल्यू को बेहतर तरीके से कोड में बदलने के लिए इस सूची का इस्तेमाल किया जाता है.
हफ़मैन कोडिंग की मदद से, ट्रांसफ़र किए जाने पर अलग-अलग वैल्यू को कंप्रेस किया जा सकता है. पहले ट्रांसफ़र की गई वैल्यू की इंडेक्स की गई सूची की मदद से, हम इंडेक्स वैल्यू को ट्रांसफ़र करके डुप्लीकेट वैल्यू को कोड में बदल सकते हैं. इन वैल्यू का इस्तेमाल, पूरे हेडर कुंजियों और वैल्यू को बेहतर तरीके से खोजने और उन्हें फिर से बनाने के लिए किया जा सकता है.
एक और ऑप्टिमाइज़ेशन के तौर पर, HPACK कंप्रेशन कॉन्टेक्स्ट में एक स्टैटिक और डाइनैमिक टेबल शामिल होती है: स्टैटिक टेबल को स्पेसिफ़िकेशन में बताया जाता है.साथ ही, ऐसे सामान्य एचटीटीपी हेडर फ़ील्ड की सूची दी जाती है जिनका इस्तेमाल सभी कनेक्शन कर सकते हैं (जैसे कि मान्य हेडर नाम). डाइनैमिक टेबल शुरुआत में खाली होती है और उसे किसी खास कनेक्शन में एक्सचेंज की गई वैल्यू के आधार पर अपडेट किया जाता है. नतीजे के तौर पर, ऐसी वैल्यू के लिए स्टैटिक हफ़मैन कोडिंग का इस्तेमाल करके, हर अनुरोध का साइज़ कम कर दिया जाता है जो पहले नहीं देखे गए हैं. साथ ही, उन वैल्यू के लिए इंडेक्स की जगह भी घटा दी जाती है जो हर साइड पर स्टैटिक या डाइनैमिक टेबल में पहले से मौजूद हैं.
HPACK की सुरक्षा और परफ़ॉर्मेंस
एचटीटीपी/2 और SPDY के शुरुआती वर्शन, सभी एचटीटीपी हेडर को कंप्रेस करने के लिए कस्टम डिक्शनरी के साथ zlib का इस्तेमाल करते थे. इससे ट्रांसफ़र किए गए हेडर डेटा के साइज़ में 85% से 88% की कमी आई और पेज लोड होने में लगने वाले समय में काफ़ी सुधार हुआ:
लोअर बैंडविथ वाले DSL लिंक, जिसमें अपलोड लिंक सिर्फ़ 375 केबीपीएस का होता है, खास तौर पर हेडर को कंप्रेस करने के अनुरोध की वजह से कुछ साइटों (दूसरे शब्दों में, वे साइटें जिनसे बहुत ज़्यादा संसाधन अनुरोध किए गए) के पेज लोड होने के समय में काफ़ी सुधार हुआ. हमने पाया है कि हेडर कंप्रेशन की वजह से, पेज लोड होने में लगने वाले समय में 45 से 1142 मि॰से॰ की कमी आई. (SPDY व्हाइट पेपर, chromium.org)
हालांकि, 2012 की गर्मियों में, TLS और SPDY कंप्रेशन एल्गोरिदम के ख़िलाफ़ एक "CRIME" सुरक्षा हमला पब्लिश किया गया. इसकी वजह से, सेशन हाइजैक हो सकता था. नतीजतन, zlib कंप्रेशन एल्गोरिदम को HPACK से बदल दिया गया. इसे खास तौर पर इस तरह से डिज़ाइन किया गया था: सुरक्षा से जुड़ी समस्याओं को ठीक करना, बेहतर तरीके से काम करना, और उन्हें सही तरीके से लागू करना. साथ ही, एचटीटीपी हेडर मेटाडेटा को अच्छे से कंप्रेस करना.
HPACK कंप्रेशन एल्गोरिदम की पूरी जानकारी के लिए, IETF HPACK - हेडर कंप्रेशन for HTTP/2 को देखें.
इसके बारे में और पढ़ें
- "HTTP/2" – इल्या ग्रिगोरिक का पूरा लेख
- "एचटीटीपी/2 सेट अप करना" – Surma की मदद से अलग-अलग बैकएंड में एचटीटीपी/2 को कैसे सेट अप करें
- "एचटीटीपी/2 आ गया है, आइए इसे ऑप्टिमाइज़ करें!" – वेलोसिटी 2015 से इल्या ग्रीगोरिक का प्रज़ेंटेशन
- "रूल ऑफ़ थंब फ़ॉर एचटीटीपी/2 पुश" – टॉम बर्गन, साइमन पेलचैट, और माइकल ब्यूटनर का एक विश्लेषण. इसमें बताया गया है कि पुश का इस्तेमाल कब और कैसे करना है.