HTTP / 3: नींव और एक बहादुर नई दुनिया को तोड़ना

अब 20 से अधिक वर्षों के लिए, हम HTTP प्रोटोकॉल का उपयोग करके वेब पेज देख रहे हैं। अधिकांश उपयोगकर्ता इस बारे में बिल्कुल नहीं सोचते हैं कि यह क्या है और यह कैसे काम करता है। दूसरों को पता है कि कहीं HTTP के तहत टीएलएस है, और इसके तहत टीसीपी है, जिसके तहत आईपी और इतने पर। और तीसरा - विधर्मी - मानते हैं कि टीसीपी पिछली शताब्दी है, वे कुछ तेज, अधिक विश्वसनीय और अधिक सुरक्षित चाहते हैं। लेकिन एक नए आदर्श प्रोटोकॉल का आविष्कार करने के अपने प्रयासों में, वे 80 के दशक की प्रौद्योगिकियों पर लौट आए और उन पर अपनी बहादुर नई दुनिया बनाने की कोशिश कर रहे हैं।

थोड़ा सा इतिहास: HTTP / 1.1

1997 में, HTTP संस्करण 1.1 टेक्स्ट एक्सचेंज प्रोटोकॉल ने अपना RFC प्राप्त किया। उस समय, प्रोटोकॉल का उपयोग कई वर्षों तक ब्राउज़र द्वारा किया गया था, और नया मानक एक और पंद्रह तक चला। प्रोटोकॉल केवल अनुरोध-प्रतिक्रिया के आधार पर काम करता था और प्राथमिक रूप से पाठ्य सूचना प्रेषित करने के उद्देश्य से था।

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

HTTP / 1.0 में, टीसीपी कनेक्शन प्रत्येक अनुरोध के बाद बंद कर दिया गया था। यह तब से बेहद बेकार था टीसीपी कनेक्शन (3-वे-हैंडशेक) स्थापित करना एक त्वरित प्रक्रिया नहीं है। HTTP / 1.1 ने जीवित-तंत्र को पेश किया, जो आपको कई अनुरोधों के लिए एकल कनेक्शन का पुन: उपयोग करने की अनुमति देता है। हालाँकि, चूंकि यह आसानी से अड़चन बन सकता है, एक ही होस्ट के लिए कई टीसीपी / आईपी कनेक्शन विभिन्न HTTP / 1.1 कार्यान्वयन में अनुमति दी जाती है। उदाहरण के लिए, क्रोम में और फ़ायरफ़ॉक्स के हाल के संस्करणों में, छह कनेक्शन तक की अनुमति है।

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

बादल का चित्रण

इस प्रकार, HTTP / 1.1 में कई समस्याएं थीं:

• धीमा कनेक्शन सेटअप।
• एक अनुरोध के लिए एक टीसीपी कनेक्शन का उपयोग किया जाता है, जिसका अर्थ है कि बाकी अनुरोधों को या तो एक अन्य कनेक्शन खोजना होगा, या जब तक कि वर्तमान अनुरोध इसे जारी नहीं करता है तब तक प्रतीक्षा करें।
• केवल पुल मॉडल का समर्थन किया जाता है। सर्वर-पुश के बारे में मानक में कुछ भी नहीं है।
• शीर्षक पाठ में प्रेषित होते हैं।

यदि सर्वर-पुश को किसी भी तरह से WebSocket प्रोटोकॉल का उपयोग करके लागू किया जाता है, तो बाकी समस्याओं को अधिक मौलिक रूप से निपटाया जाना था।

आधुनिकता का एक सा: HTTP / 2

2012 में, Google के आंतों में SPDY प्रोटोकॉल (उच्चारण "गति") पर काम शुरू हुआ। प्रोटोकॉल HTTP / 1.1 की बुनियादी समस्याओं को हल करने के लिए डिज़ाइन किया गया था और एक ही समय में पिछड़े संगतता को बनाए रखना था। 2015 में, IETF कार्य समूह ने SPDY प्रोटोकॉल पर आधारित HTTP / 2 विनिर्देश पेश किया। यहाँ HTTP / 2 में अंतर हैं:

• द्विआधारी क्रमांकन।
• एक ही टीसीपी कनेक्शन में कई HTTP अनुरोधों को मल्टीप्लेक्स करना।
• सर्वर-आउट बॉक्स से बाहर (बिना WebSocket के)।

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

हालांकि, गुणन एक और आधारशिला समस्या की ओर जाता है। कल्पना करें कि हम अतुल्यकालिक रूप से एक सर्वर पर 5 अनुरोधों को निष्पादित करते हैं। HTTP / 2 का उपयोग करते समय, इन सभी अनुरोधों को एक ही टीसीपी कनेक्शन के भीतर निष्पादित किया जाएगा, जिसका अर्थ है कि यदि किसी भी अनुरोध का कोई सेगमेंट खो गया है या गलत तरीके से आता है, तो सभी अनुरोधों और प्रतिक्रियाओं का प्रसारण तब तक बंद हो जाएगा जब तक कि खोए हुए सेगमेंट को बहाल नहीं किया जाता है। जाहिर है, कनेक्शन की गुणवत्ता बदतर, धीमी HTTP / 2 काम करती है। डैनियल स्टैनबर्ग के अनुसार , ऐसी स्थिति में जहां खोए हुए पैकेट सभी का 2% बनाते हैं, एक ब्राउज़र में HTTP / 1.1 HTTP / 2 से बेहतर प्रदर्शन करता है क्योंकि यह 6 कनेक्शन खोलता है, और एक नहीं।

इस समस्या को "हेड-ऑफ-लाइन ब्लॉकिंग" कहा जाता है और, दुर्भाग्य से, टीसीपी का उपयोग करके इसे हल करना संभव नहीं है।

डैनियल स्टाइनबर्ग का चित्रण

नतीजतन, HTTP / 2 मानक के डेवलपर्स ने बहुत अच्छा काम किया और लगभग वह सब कुछ किया जो OSX मॉडल के आवेदन स्तर पर किया जा सकता था। परिवहन स्तर पर जाने और एक नए परिवहन प्रोटोकॉल का आविष्कार करने का समय आ गया है।

हमें एक नया प्रोटोकॉल चाहिए: यूडीपी बनाम टीसीपी

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

और यहाँ एक व्यक्ति दे सकता है और कह सकता है कि "हम, निश्चित रूप से, प्राथमिकता और शिष्टाचार के साथ एक नया HTTP / 3 का आविष्कार करेंगे, लेकिन इसे 10-15 वर्षों में लागू किया जाएगा (इस समय के बाद अधिकांश ग्रंथियों को बदल दिया जाएगा"), लेकिन वहाँ एक नहीं सबसे अधिक है स्पष्ट विकल्प: यूडीपी प्रोटोकॉल का उपयोग करें। हां, हां, वही प्रोटोकॉल जिसके अनुसार हमने नब्बे के दशक के अंत और शून्य की शुरुआत में एक लैन पर फाइलें फेंक दीं। आज के लोहे के लगभग सभी टुकड़े इसके साथ काम करना जानते हैं।

टीसीपी पर यूडीपी के क्या फायदे हैं? सबसे पहले, हमारे पास परिवहन स्तर का सत्र नहीं है जिसके बारे में लोहा जानता है। यह हमें स्वयं समापन बिंदु पर सत्र को निर्धारित करने और वहां उत्पन्न होने वाले संघर्षों को हल करने की अनुमति देता है। यही है, हम एक या कई सत्रों (टीसीपी के रूप में) तक सीमित नहीं हैं, लेकिन हम उन्हें उतना ही बना सकते हैं जितना हमें जरूरत है। दूसरे, UDP पर डेटा ट्रांसमिशन टीसीपी की तुलना में तेज़ है। इस प्रकार, सिद्धांत रूप में, हम HTTP / 2 में प्राप्त आज की गति सीमा के माध्यम से तोड़ सकते हैं।

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

HTTP / 2 के साथ, 2012 में Google पर एक नया प्रोटोकॉल बनाने का काम शुरू हुआ, यानी लगभग उसी समय जब SPDY पर काम शुरू हुआ। 2013 में, जिम रोसकाइंड ने QUIC प्रोटोकॉल (क्विक यूडीपी इंटरनेट कनेक्शन) को आम जनता के लिए पेश किया, और 2015 में पहले से ही इंटरनेट ड्राफ्ट को IETF मानकीकृत करने के लिए पेश किया गया था। पहले से ही उस समय, Google पर Roskind द्वारा विकसित प्रोटोकॉल मानक एक से बहुत अलग था, इसलिए Google संस्करण को gQUIC कहा जाता था।

QUIC क्या है

सबसे पहले, जैसा कि पहले ही उल्लेख किया गया है, यह यूडीपी पर एक आवरण है। QUIC- कनेक्शन UDP से ऊपर उठता है, जिसमें HTTP / 2 के साथ सादृश्य द्वारा, कई धाराएँ मौजूद हो सकती हैं। ये धाराएँ केवल समापन बिंदु पर मौजूद होती हैं और स्वतंत्र रूप से परोसी जाती हैं। यदि पैकेट नुकसान एक स्ट्रीम में हुआ, तो यह किसी भी तरह से दूसरों को प्रभावित नहीं करेगा।

डैनियल स्टाइनबर्ग का चित्रण

दूसरे, एन्क्रिप्शन अब एक अलग स्तर पर लागू नहीं किया गया है, लेकिन प्रोटोकॉल में शामिल है। यह आपको एक कनेक्शन स्थापित करने और एक ही हैंडशेक में सार्वजनिक कुंजी का आदान-प्रदान करने की अनुमति देता है, और आपको मुश्किल 0-RTT हैंडशेक तंत्र का उपयोग करने की अनुमति देता है और आमतौर पर हाथ मिलाने में देरी से बचता है। इसके अलावा, व्यक्तिगत डेटा पैकेट अब एन्क्रिप्ट किए जा सकते हैं। यह आपको स्ट्रीम से डेटा प्राप्त करने के पूरा होने की प्रतीक्षा करने की अनुमति नहीं देता है, लेकिन प्राप्त पैकेटों को स्वतंत्र रूप से डिक्रिप्ट करने की अनुमति देता है। ऑपरेशन का यह तरीका टीसीपी में बिल्कुल भी संभव नहीं था, क्योंकि टीएलएस और टीसीपी ने स्वतंत्र रूप से एक दूसरे के साथ काम किया, और टीएलएस को पता नहीं चल सका कि टीसीपी डेटा किन टुकड़ों में काटेगा। और इसलिए, मैं अपने सेगमेंट तैयार नहीं कर सका ताकि वे एक से एक टीसीपी सेगमेंट में फिट हो सकें और स्वतंत्र रूप से डिक्रिप्ट हो सकें। ये सभी सुधार QUIC को TCP की तुलना में विलंबता को कम करने की अनुमति देते हैं।

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

चौथा, QUIC आवेदन स्तर पर लागू किया जाता है, ऑपरेटिंग सिस्टम पर नहीं। यह, एक तरफ, प्रोटोकॉल में तेज बदलाव की अनुमति देता है, जैसा कि अपडेट प्राप्त करने के लिए, बस ओएस के एक नए संस्करण की प्रतीक्षा करने के बजाय, लाइब्रेरी को अपडेट करें। दूसरी ओर, यह प्रोसेसर की खपत में मजबूत वृद्धि की ओर जाता है।

और अंत में, सुर्खियों में। हैडर संपीड़न सिर्फ उन बिंदुओं को संदर्भित करता है जो QUIC और gQUIC में भिन्न होते हैं। मुझे इसके लिए बहुत समय समर्पित करने का कोई कारण नहीं दिखता है, मैं केवल यह कह सकता हूं कि मानकीकरण के लिए प्रस्तुत संस्करण में, हेडर संपीड़न को HTTP / 2 में हेडर संपीड़न के समान संभव बनाया गया था। अधिक विवरण यहां पढ़ा जा सकता है ।

कितना तेज है?

यह एक पेचीदा सवाल है। तथ्य यह है कि जब हमारे पास कोई मानक नहीं है, तो मापने के लिए कुछ विशेष नहीं है। शायद हमारे पास केवल वही आँकड़े हैं जो Google के आँकड़े हैं, जो 2013 से और 2016 में GQUIC का उपयोग कर रहे हैं और IETF को सूचित किया कि क्रोम ब्राउज़र से उनके सर्वर पर जाने वाला लगभग 90% ट्रैफ़िक अब QUIC का उपयोग कर रहा है। उसी प्रस्तुति में, वे रिपोर्ट करते हैं कि gQUIC के माध्यम से, पृष्ठ लगभग 5% तेजी से लोड होते हैं, और स्ट्रीमिंग वीडियो में टीसीपी की तुलना में 30% कम जमा होते हैं।

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

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

थोड़ा सा भविष्य: HTTP / 3 के बारे में क्या?

और यहां सब कुछ क्रिस्टल स्पष्ट है: एपीआई किसी भी तरह से नहीं बदलेगा। सब कुछ ठीक वैसा ही रहेगा जैसा कि HTTP / 2 में था। ठीक है, अगर एपीआई समान रहता है, तो HTTP / 3 पर संक्रमण का फैसला बैकएंड पर QUIC के माध्यम से लाइब्रेरी सपोर्ट ट्रांसपोर्ट के नवीनतम संस्करण का उपयोग करके करना होगा। सच है, लंबे समय तक आपको HTTP के पुराने संस्करणों में कमबैक करना होगा, क्योंकि इंटरनेट अब यूडीपी के पूर्ण स्विच के लिए तैयार नहीं है।

जो पहले से ही समर्थन कर रहा है

यहां मौजूदा QUIC कार्यान्वयनों की एक सूची दी गई है। एक मानक की कमी के बावजूद, सूची खराब नहीं है।

वर्तमान में कोई भी ब्राउज़र रिलीज़ में QUIC का समर्थन नहीं करता है। हाल ही में जानकारी थी कि क्रोम में HTTP / 3 समर्थन शामिल है, लेकिन अभी तक केवल कैनरी में है।

बैकेंड्स में , HTTP / 3 केवल Caddy और Cloudflare का समर्थन करता है, लेकिन अब तक प्रायोगिक तौर पर। NGINX ने देर से वसंत 2019 में घोषणा की कि उन्होंने HTTP / 3 समर्थन पर काम शुरू कर दिया है, लेकिन अभी तक इसे पूरा नहीं किया है।

क्या दिक्कतें हैं?

हम वास्तविक दुनिया में रहते हैं, जहां प्रतिरोध का सामना किए बिना एक भी बड़ी तकनीक जनता के पास नहीं जा सकती है, और QUIC कोई अपवाद नहीं है।

सबसे महत्वपूर्ण बात, आपको किसी तरह ब्राउज़र को समझाने की ज़रूरत है कि "https: //" अब एक ऐसा तथ्य नहीं है जो 443 वें टीसीपी पोर्ट की ओर ले जाता है। हो सकता है कि टीसीपी बिल्कुल न हो। ऐसा करने के लिए, Alt-Svc हेडर का उपयोग करें। यह ब्राउज़र को सूचित करने की अनुमति देता है कि यह वेबसाइट ऐसे और इस तरह के पते पर ऐसे प्रोटोकॉल पर भी उपलब्ध है। सिद्धांत रूप में, यह एक घड़ी की तरह काम करना चाहिए, लेकिन व्यवहार में, हम इस तथ्य पर ठोकर खाते हैं कि यूडीपी हो सकता है, उदाहरण के लिए, फ़ायरवॉल पर अक्षम डीडीओएस हमलों से बचने के लिए।

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

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

इसके अलावा, जैसा कि पहले ही वर्णित है, QUIC प्रोसेसर के उपयोग को बहुत बढ़ाता है। डैनियल स्टैनबर्ग ने प्रोसेसर पर तीन गुना तक वृद्धि का मूल्यांकन किया ।

जब HTTP / 3 आता है

वे मई 2020 तक मानक अपनाना चाहते हैं , लेकिन यह देखते हुए कि जुलाई 2019 के लिए निर्धारित दस्तावेज अपूर्ण हैं, हम कह सकते हैं कि तारीख सबसे संभावित रूप से स्थगित है।

ठीक है, Google 2013 से अपने gQUIC के कार्यान्वयन का उपयोग कर रहा है। यदि आप Google खोज इंजन को भेजे गए HTTP अनुरोध को देखते हैं, तो आप इसे देख सकते हैं:

निष्कर्ष

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

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

भविष्य दूर नहीं है!