HTTP / 2 मानक को अपनाने में साढ़े तीन साल बीत चुके हैं:
RFC 7540 विनिर्देश मई 2015 में प्रकाशित हुआ था, लेकिन अभी तक इसका उपयोग हर जगह नहीं किया गया है। प्रोटोकॉल
2015 के अंत से सभी ब्राउज़रों में लागू किया गया है, और तीन साल बाद 10 मिलियन सबसे लोकप्रिय इंटरनेट साइटों में से केवल
31.2% HTTP / 2 का समर्थन करते हैं। सबसे लोकप्रिय साइटों में से, Google, Youtube, Wikipedia, Twitter, Vk.com और अन्य ने इसे बंद कर दिया है।
फिर भी, प्रगति अभी भी नहीं है - और HTTP / 3 के अगले संस्करण पर काम पहले से ही चल रहा है। जैसा कि यह अब
ज्ञात हो गया है , दो वैकल्पिक विकल्पों के डेवलपर्स ने संगतता हासिल की है, और HTTP-ओवर-QUIC प्रोटोकॉल अब इसका नाम बदल देता है और
आधिकारिक तौर पर HTTP / 3 कहा जाता है । तदनुसार, HTTP के भविष्य के संस्करण में, टीसीपी परिवहन को QUIC द्वारा प्रतिस्थापित किया जाएगा।
विभिन्न QUIC विकल्पों के साथ भ्रम
QUIC एक TCP प्रतिस्थापन है जो UDP के शीर्ष पर काम करता है। प्रारंभ में, यह तकनीक Google इंजीनियरों द्वारा पिछले SPDY प्रोटोकॉल की तरह बनाई गई थी, जो HTTP / 2 की नींव बन गई थी। सबसे पहले, QUIC को "HTTP / 2-एन्क्रिप्टेड-ओवर-UDP" कहा जाता था।
मानकीकरण के लिए QUIC विकास को IETF में स्थानांतरित कर दिया गया। यहाँ इसे दो भागों में विभाजित किया गया था: परिवहन और HTTP। विचार यह है कि परिवहन प्रोटोकॉल का उपयोग अन्य डेटा को स्थानांतरित करने के लिए भी किया जा सकता है, न केवल विशेष रूप से HTTP या HTTP-जैसे प्रोटोकॉल के लिए। हालाँकि, नाम वही रहता है: QUIC। परिवहन प्रोटोकॉल इंटरनेट इंजीनियरिंग काउंसिल (IETF) के QUIC वर्किंग ग्रुप द्वारा विकसित किया गया है।
उसी समय, Google ने अपने स्वयं के कार्यान्वयन पर काम करना जारी रखा - और इसे क्रोम ब्राउज़र में लागू किया। हालाँकि परीक्षण बताते हैं कि
Google का QUIC कार्यान्वयन टीसीपी से काफी खराब है, अगर नेटवर्क पैकेट वितरण की गारंटी नहीं देता है ।
112 एमएस आरटीटी और 10 एमएस जिटर, स्रोत वाले नेटवर्क पर टीसीपी (प्रतिशत में) के साथ QUIC के बीच प्रदर्शन अंतरआरटीटी 112 एमएस और 10 एमएस घबराना वाले नेटवर्क पर टीसीपी (प्रतिशत में) के साथ QUIC के बीच प्रदर्शन अंतर, जो पैकेट, स्रोत के क्रम को बदलता हैकुछ डेवलपर्स आमतौर पर यूडीपी पर QUIC के किसी भी संस्करण को
"बेतहाशा प्रयोग" कहते हैं ।
QUIC संस्करणों में नामकरण और नामकरण
को डैनियल स्टेनबर्ग
द्वारा समझाया गया है , जो मोज़िला के प्रमुख कर्ल डेवलपर हैं जो लंबे समय से इस कहानी का अनुसरण कर रहे हैं।
उनके अनुसार, QUIC के दो संस्करणों के अनौपचारिक नाम डेवलपर्स के बीच फैल गए हैं, क्योंकि IETF और Google के विकल्प कार्यान्वयन विवरणों में काफी भिन्न हैं:
- IQUIC (IETF संस्करण)
- gQUIC (Google संस्करण)
IQUIC (IETF संस्करण) पर HTTP भेजने के प्रोटोकॉल को लंबे समय तक "hq" (HTTP-over-QUIC) कहा जाता रहा है।
सामान्य तौर पर, विभिन्न संस्करणों के लिए कोई स्थापित नाम नहीं था। QUIC वर्कशॉप सेमिनार में, माइक बिशप ने सभी को एक स्लाइड से डराया जैसे यह एक लोगो था।
माइक बिशप की प्रस्तुति से स्लाइडकार्यशाला के सूत्रधारों
ने माइक से कहा कि इसे फिर कभी न दिखाएं ।
हालांकि, 7 नवंबर, 2018 को, प्रोटोकॉल के प्रमुख डेवलपर्स में से एक, दिमित्री तिखोनोव
ने घोषणा की कि लाइटस्पीड टेक और फेसबुक ने प्रोटोकॉल संगतता हासिल की थी, और अब उसी तर्ज पर विकास जारी रहेगा।
सितंबर में HTTP / 3 नामक iQUIC और gQUIC का संयोजन मार्क नॉटिंघम
द्वारा प्रस्तावित किया गया था, जो सबसे प्रभावशाली IETF इंजीनियरों में से एक है, जो कई वेब मानकों के सह-लेखक हैं। उनके अनुसार, यह QIUC परिवहन और HTTP के लिए QUIC आवरण के बीच भ्रम को समाप्त करने में मदद करेगा।
इस प्रकार,
HTTP / 3 HTTP का नया संस्करण है जो QUIC ट्रांसपोर्ट का उपयोग करेगा ।
QUIC ट्रांसपोर्ट
टीसीपी पर QUIC परिवहन प्रोटोकॉल के क्या फायदे हैं? कई फायदे हैं, और मार्क नॉटिंघम के अनुसार, पुराने टीसीपी से नए प्रोटोकॉल में संक्रमण बस अपरिहार्य है, क्योंकि अब यह स्पष्ट है कि टीसीपी अक्षमता समस्याओं से पीड़ित है।
“चूंकि टीसीपी एक पैकेट वितरण प्रोटोकॉल है, इसलिए एक पैकेट का नुकसान बफर से आवेदन के लिए बाद के पैकेट के वितरण में हस्तक्षेप कर सकता है। मल्टीप्लेक्स प्रोटोकॉल में, यह प्रदर्शन में एक बड़ा नुकसान हो सकता है, ”मार्क नॉटिंघम
बताते हैं । "क्विक UDP के ऊपर (HTTP / 2 स्ट्रीम मॉडल के कुछ पहलुओं के साथ) टीसीपी के शब्दार्थों को प्रभावी ढंग से पुनर्निर्मित करके इस समस्या को हल करने की कोशिश कर रहा है।"
टीसीपी से यूडीपी तक ट्रैफ़िक की एक महत्वपूर्ण मात्रा को स्विच करने के अलावा, Google QUIC (gQUIC) और IETF QUIC (iQUIC) दोनों को एन्क्रिप्शन की आवश्यकता होती है:
अनएन्क्रिप्टेड QUIC बिल्कुल भी मौजूद नहीं है । iQUIC सत्र कुंजियों को सेट करने के लिए TLS 1.3 का उपयोग करता है और फिर प्रत्येक पैकेट को एन्क्रिप्ट करता है। लेकिन चूंकि यह यूडीपी पर आधारित है, इसलिए टीसीपी में खोले गए सत्र की अधिकांश जानकारी और मेटाडेटा QUIC में एन्क्रिप्टेड है।
लेख
"इंटरनेट प्रोटोकॉल का भविष्य" में, मार्क नॉटिंघम QUIC के स्विच के साथ महत्वपूर्ण सुरक्षा सुधार के बारे में बात करता है:
वास्तव में, वर्तमान "शॉर्ट हेडर" iQUIC - जो हैंडशेक को छोड़कर सभी पैकेटों के लिए उपयोग किया जाता है - केवल पैकेट नंबर, वैकल्पिक कनेक्शन पहचानकर्ता और स्टेटस बाइट देता है, जो एन्क्रिप्शन कुंजी और पैकेट प्रकार (जिसे एन्क्रिप्ट भी किया जा सकता है) को बदलने जैसी प्रक्रियाओं के लिए आवश्यक है। बाकी सब कुछ एन्क्रिप्टेड है - जिसमें एसीके पैकेट भी शामिल हैं, जो ट्रैफिक विश्लेषण के साथ हमलों के लिए बार उठाता है।
इसके अलावा, केवल कनेक्शन की निगरानी करके RTT और पैकेट हानि का निष्क्रिय मूल्यांकन करना असंभव हो जाता है; इसके लिए पर्याप्त जानकारी नहीं है।
अवलोकन की कमी ने दूरसंचार ऑपरेटरों के समुदाय के कुछ प्रतिनिधियों के बीच गंभीर चिंता पैदा की। उनका कहना है कि इस तरह के निष्क्रिय माप डिबगिंग और उनके नेटवर्क का विश्लेषण करने के लिए महत्वपूर्ण हैं।
इस समस्या को हल करने के लिए सुझावों में से एक स्पिन बिट का परिचय है। यह हेडर में एक सा है जो राउंड-ट्रिप पर एक बार अपना मूल्य बदलता है, ताकि पर्यवेक्षक RTT का मूल्यांकन कर सके। चूंकि यह एप्लिकेशन की स्थिति से बंधा नहीं है, इसलिए इसे नेटवर्क स्थान के अनुमानित अनुमान के अलावा, समापन बिंदुओं के बारे में कोई जानकारी नहीं देनी चाहिए।
शायद QUIC मानक को अपनाने का काम पहले हुआ होता अगर Google क्रोम ब्राउज़र में इसके कार्यान्वयन को लागू करने के लिए जल्दी नहीं करता, इसलिए अब iQUIC खातों का मालिकाना संस्करण 7% से अधिक इंटरनेट ट्रैफ़िक के लिए होता।
फिर भी, प्रगति अपरिहार्य है - और आने वाले वर्षों में, QUIC परिवहन पर HTTP / 3 सहित विभिन्न नई पीढ़ी के प्रोटोकॉल का मानकीकरण और व्यापक कार्यान्वयन निश्चित रूप से जारी रहेगा।
