HTTP/3: ब्रेकिंग द ग्राउंड एंड ब्रेव न्यू वर्ल्ड

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

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

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

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

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 अनुरोधों को मल्टीप्लेक्स करना।
• सर्वर-बॉक्स से बाहर पुश करें (वेबसॉकेट के बिना)।

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

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

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

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

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

हमें एक नए प्रोटोकॉल की आवश्यकता है: यूडीपी बनाम टीसीपी

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

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

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

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

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

क्विक क्या है?

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

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

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

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

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

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

यह कितना तेज़ है?

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

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

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

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

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

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

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

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

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

क्या समस्याएं हैं?

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

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

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

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

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

HTTP/3 कब आएगा?

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

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

निष्कर्ष

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

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

भविष्य निकट ही है!

स्रोत: www.habr.com