HTTP एप्लिकेशन लेयर प्रोटोकॉल इंटरनेट को रेखांकित करता है। इसने 1991 में HTTP / 0.9 के रूप में अपना जीवन शुरू किया, और 1999 तक यह HTTP / 1.1 में बदल गया, जिसे इंटरनेट इंजीनियरिंग काउंसिल (IETF) द्वारा मानकीकृत किया गया था।
HTTP / 1.1 ने सभी को लंबे समय तक संतुष्ट किया, लेकिन वेब की बढ़ती जरूरतों के लिए उन्नयन की आवश्यकता थी - और 2015 में HTTP / 2 को अपनाया। कहानी यहीं खत्म नहीं हुई: अभी हाल ही में, IETF ने HTTP / 3 के एक नए संस्करण की घोषणा की। कुछ के लिए, यह एक आश्चर्य के रूप में आया और कुछ भ्रम का कारण बना। यदि आप IETF की निगरानी नहीं कर रहे हैं, तो ऐसा लग सकता है कि HTTP / 3 कहीं से नहीं आया है। फिर भी, हम प्रयोगों के इतिहास और वेब प्रोटोकॉल के विकास के अनुसार इसकी उत्पत्ति का पता लगा सकते हैं, विशेष रूप से, QUIC परिवहन प्रोटोकॉल।
यदि आप QUIC से परिचित नहीं हैं, तो मेरे Cloudflare सहयोगियों ने कुछ पहलुओं में विभिन्न पहलुओं को शामिल किया है: उदाहरण के लिए,
आधुनिक HTTP की
वास्तविक खामियों और
परिवहन परत प्रोटोकॉल पर विवरण देखें । हमने इन्हें और अन्य सामग्रियों को
cloudflare-quic.com पर
एकत्र किया है । और यदि आप रुचि रखते हैं, तो बाहर की जाँच अवश्य करें: यह हमारे स्वयं के क्विक का कार्यान्वयन है, जो खुले स्रोत कोड के साथ रस्ट में लिखा गया है।
HTTP / 3 - आवेदन परत के लिए QUIC परिवहन प्रोटोकॉल का अनुवाद। ड्राफ्ट (
ड्राफ्ट- ietf-quic-http-17 ) के 17 वें संस्करण में HTTP / 3 नाम को आधिकारिक तौर पर हाल ही में अनुमोदित किया गया था। यह अक्टूबर 2018 के अंत में प्रस्तावित किया गया था, और सर्वसम्मति से नवंबर में बैंकॉक में IETF 103 की बैठक में पहुंच गया था।
पहले, HTTP / 3 को QUIC द्वारा HTTP के रूप में जाना जाता था, और उससे पहले - जैसे HTTP / 2 को gQUIC द्वारा, और इससे पहले भी - SPDY को gQUIC द्वारा। लेकिन लब्बोलुआब यह है कि HTTP / 3 सिर्फ नया HTTP सिंटैक्स है जो IETF QUIC प्रोटोकॉल, UDP पर आधारित एक मल्टीप्लेक्स और सुरक्षित परिवहन पर चलता है।
इस लेख में, हम पिछले कुछ HTTP / 3 नामों के इतिहास को देखेंगे और अंतिम नाम परिवर्तन के लिए प्रेरणा का परिचय देंगे। आइए, HTTP के पहले दिनों और इस दौरान हुई सब कुछ पर वापस जाएं। यदि आप पूरी तस्वीर प्राप्त करना चाहते हैं, तो आप तुरंत लेख के अंत में जा सकते हैं या
एसवीजी के इस बहुत विस्तृत संस्करण को खोल सकते हैं।
HTTP / 3 लेयर केकअसबाब
HTTP पर ध्यान केंद्रित करने से ठीक पहले, यह याद रखने योग्य है कि QUIC नामक दो प्रोटोकॉल हैं। जैसा कि हमने पहले ही
बताया है , gQUIC का उपयोग आमतौर पर Google QUIC (स्रोत प्रोटोकॉल) के लिए एक संक्षिप्त नाम के रूप में किया जाता है, और QUIC एक IETF संस्करण के रूप में होता है, जो gQUIC से भिन्न होता है।
90 के दशक की शुरुआत से, इंटरनेट की जरूरतों में बदलाव आया है। हमारे पास HTTP के नए संस्करण और TLS प्रोटोकॉल (ट्रांसपोर्ट लेयर सिक्योरिटी) के रूप में सुरक्षा का एक नया स्तर है। इस लेख में, हम केवल टीएलएस को कवर करेंगे, और हमारे ब्लॉग के
अन्य लेखों में आप इस विषय पर अधिक विस्तार से अध्ययन कर सकते हैं।
HTTP और TLS के इतिहास को तारीखों की एक सरल सूची के साथ व्यक्त नहीं किया जा सकता है, क्योंकि कुछ शाखाएं समानांतर में विकसित हुईं और समय के साथ ओवरलैप हुईं। जब आप इंटरनेट के इतिहास के लगभग 30 वर्षों में सभी बिंदुओं को जोड़ने का प्रयास करते हैं, तो आप विज़ुअलाइज़ेशन के बिना नहीं कर सकते। इसलिए मैंने यह शेड्यूल बनाया: Cloudflare Secure Web Timeline। (नोट: तकनीकी रूप से यह एक
क्लैडोग्राम है , हालांकि लोग "ग्राफ" शब्द से अधिक परिचित हैं)।
सुंदरता के लिए, मैंने कुछ सूचनाएँ गिरा दीं, केवल IETF स्पेस में सफल शाखाओं पर ध्यान केंद्रित किया। उदाहरण के लिए, डब्ल्यू 3 कंसोर्टियम के HTTP-NG वर्किंग ग्रुप के प्रयासों के साथ-साथ कुछ विदेशी तकनीकों, जिनमें से लेखक अभी भी समझाने की कोशिश कर रहे हैं, यहाँ नहीं दिखाए गए हैं:
HMURR ("हमर" (
WAKA (उच्चारण "वाह-काह") का उच्चारण)।
निम्नलिखित अनुभागों में, हम इस क्लैडोग्राम के माध्यम से जाएंगे और HTTP के इतिहास में कुछ टिपिंग बिंदुओं को देखेंगे। मुझे उम्मीद है कि यह समझने में मदद करता है कि मानकीकरण हर किसी के लिए फायदेमंद क्यों है, और IETF इस मुद्दे पर कैसे पहुंचता है। इसलिए, हम अनुसूची में लौटने से पहले विषय के बहुत संक्षिप्त अवलोकन से शुरू करते हैं। यदि आप पहले से ही IETF से परिचित हैं, तो अगले भाग को छोड़ दें।
इंटरनेट मानक के प्रकार
आमतौर पर, मानक सामान्य क्षमता, कार्यक्षेत्र, सीमाएं, प्रयोज्यता और अन्य विचारों को परिभाषित करते हैं। मानक कई आकारों और आकारों में मौजूद हैं। वे अनौपचारिक हो सकते हैं (डी वास्तविक मानक) या औपचारिक (सहमत होने पर / आईईटीएफ, आईएसओ या एमपीईजी जैसे संगठन सेटिंग मानकों द्वारा प्रकाशित)। कई क्षेत्रों में मानकों का उपयोग किया जाता है, यहां तक कि चाय बनाने के लिए एक औपचारिक ब्रिटिश मानक भी है - बीएस 6008।
पहले HTTP और SSL प्रोटोकॉल परिभाषाएँ IETF के बाहर प्रकाशित की गई थीं: उन्हें ग्राफ़ में
लाल रेखाओं के साथ चिह्नित किया गया है। लेकिन व्यापक उपयोग ने उन्हें वास्तविक मानक बना दिया है।
कुछ बिंदु पर, उन्होंने इन प्रोटोकॉल को औपचारिक रूप देने का फैसला किया (कुछ कारण नीचे वर्णित हैं)। इंटरनेट मानकों को आमतौर पर IETF में परिभाषित किया जाता है, जो वास्तविक जीवन के इंटरनेट अनुप्रयोगों पर आधारित "अनुकरणीय आम सहमति और वर्तमान कोड" के अनौपचारिक सिद्धांत द्वारा निर्देशित होता है। यह साफ कमरे के दृष्टिकोण से अलग है जब कोई वैक्यूम में आदर्श प्रोटोकॉल विकसित करने की कोशिश कर रहा है।
IETF मानकों को आमतौर पर RFC के रूप में जाना जाता है। इसे संक्षेप में समझाना कठिन है, इसलिए मैं क्विक वर्किंग ग्रुप मार्क नॉटिंघम के सह-अध्यक्ष से
"आरएफसी कैसे पढ़ें" लेख की सिफारिश करता हूं। एक कार्यसमूह या WG अनिवार्य रूप से सिर्फ एक मेलिंग सूची है।
प्रत्येक वर्ष सभी कार्य समूहों के सदस्यों की व्यक्तिगत बैठकों के लिए तीन बैठकें होती हैं, यदि वे चाहें तो। इन हफ्तों के लिए एजेंडा बहुत व्यस्त हो सकता है, तकनीकी मुद्दों की गहन चर्चा के लिए पर्याप्त समय नहीं है। इसलिए, कुछ आईईटीएफ सामान्य बैठकों के बीच अधिक मध्यावधि बैठकों की मेजबानी करना पसंद करते हैं। QUIC वर्किंग ग्रुप ने 2017 से कई अंतरिम बैठकें की हैं, पूरी सूची
मीटिंग पेज पर उपलब्ध है।
इन बैठकों में अन्य संगठनों के विशेषज्ञों के साथ मिलने का अवसर होता है, जैसे
कि इंटरनेट आर्किटेक्चर काउंसिल (IAB) या
इंटरनेट टेक्नोलॉजी रिसर्च ग्रुप (IRTF)। हाल के वर्षों में, IETF से पहले सप्ताहांत परंपरागत रूप से
IETF हैकथॉन आयोजित किया गया है। वास्तविक कोड यहां विकसित किया गया है और, महत्वपूर्ण रूप से, संगतता परीक्षण पास करते हैं। यह उन विशिष्टताओं में समस्याओं को खोजने में मदद करता है जिन पर सीधे बैठक में चर्चा की जा सकती है।
यह समझना महत्वपूर्ण है कि आरएफसी कहीं से भी उत्पन्न नहीं होता है। वे एक पूरी प्रक्रिया से गुजरते हैं। यह आमतौर पर IETF इंटरनेट ड्राफ्ट (आईडी) के मसौदे से शुरू होता है, जिसे समीक्षा के लिए प्रस्तुत किया जाता है। उस मामले में जहां विनिर्देश पहले ही प्रकाशित हो चुका है, एक आईडी तैयार करना एक साधारण सुधारक बन जाएगा। आईडी की सेवा का जीवन प्रकाशन की तारीख से 6 महीने है। इसे सक्रिय रखने के लिए, आपको नए संस्करण प्रकाशित करने होंगे। व्यवहार में, यह ठीक है कि आईडी की समय सीमा समाप्त हो रही है। ऐसा अक्सर होता है। दस्तावेज़ अभी भी IETF वेबसाइट पर संग्रहीत हैं और सभी के लिए खुले हैं।
क्लैडोग्राम पर, ड्राफ्ट
बैंगनी रंग में प्रस्तुत किए जाते हैं। प्रारूप के
मसौदे में प्रत्येक का
अपना नाम
है- {लेखक} - {कार्यसमूह} - {विषय} - {संस्करण} । WG फ़ील्ड वैकल्पिक है, यह भविष्य के IETF कार्य समूह को इंगित कर सकता है, और कभी-कभी बदलता है। यदि आईडी IETF द्वारा अनुमोदित है या IETF के अंदर सीधे शुरू की गई है, तो मसौदे को
मसौदा-ietf- {कार्यसमूह} - {विषय} - {संस्करण} कहा जाता है । आईडी शाखा, विलय, या फीका कर सकते हैं। संस्करण 00 से शुरू होता है और एक-एक करके प्रत्येक नई परियोजना के साथ बढ़ता है। उदाहरण के लिए, चौथे मसौदे को संस्करण संख्या 03 प्राप्त होगी। हर बार जब आईडी नाम बदल दिया जाता है, तो इसका संस्करण 00 पर रीसेट हो जाता है।
यह ध्यान रखना महत्वपूर्ण है कि कोई भी अपना मसौदा IETF को प्रस्तुत कर सकता है: उन्हें मानकों के रूप में नहीं माना जा सकता है। लेकिन अगर मानकीकरण प्रक्रिया आम सहमति तक पहुंचती है और अंतिम दस्तावेज परीक्षण पास करता है, तो हमें एक आरएफसी मिलेगा। इस बिंदु पर, नाम फिर से बदलता है। प्रत्येक RFC को एक अद्वितीय संख्या मिलती है, जैसे
RFC 7230 । इस स्थिति वाले दस्तावेज़ों को
नीली रेखाओं के रूप में दिखाया गया है।
RFC को बदलना मना है। यही है, RFC में बदलाव के लिए एक नए नंबर के साथ दस्तावेज़ को अपनाने की आवश्यकता होती है। केवल संपादकीय या तकनीकी त्रुटियों के सुधार या सरल लेआउट अनुकूलन के लिए परिवर्तन की अनुमति है। नए आरएफसी पूरी तरह से पुराने को बदल सकते हैं या उन्हें पूरक कर सकते हैं।
सभी IETF दस्तावेज़
http://tools.ietf.org पर सार्वजनिक रूप से उपलब्ध हैं। व्यक्तिगत रूप से, यह मुझे
IETF डेटाट्रैकर की तुलना में थोड़ा अधिक सुविधाजनक लगता है, क्योंकि ID से RFC तक दस्तावेज़ पथ नेत्रहीन वहाँ प्रदर्शित होता है।
नीचे एक उदाहरण है जो
RFC 1945 मानक के विकास को दर्शाता है, अर्थात HTTP / 1.0।
IFCF डेटाट्रैकर इंटरफ़ेस पर RFC 1945 का इतिहासदिलचस्प है, काम के दौरान, मैंने पाया कि उपरोक्त दृश्य गलत है। किसी कारण से,
ड्राफ्ट- ietf-http-v10-spec-05 गायब है। चूंकि आईडी 6 महीने पुरानी है, यह संभवतः RFC के गोद लेने से पहले समाप्त हो गई है, हालांकि वास्तव में मसौदा अगस्त 1996 तक सक्रिय था।
एक क्लैडोग्राम का अध्ययन
एक छोटे से सैद्धांतिक परिचय के बाद, हम क्लैडोग्राम का अध्ययन करना शुरू कर सकते हैं। यह खंड सबसे महत्वपूर्ण भागों के साथ कुछ अंश प्रस्तुत करता है। प्रत्येक बिंदु दस्तावेज़ या फ़ंक्शन प्रदान किए जाने की तारीख को इंगित करता है। स्पष्टता के लिए, IETF दस्तावेज़ परियोजना संख्या को छोड़ देते हैं, लेकिन वे सभी
पूर्ण संस्करण में हैं ।
HTTP 1991 में HTTP / 0.9 प्रोटोकॉल के रूप में दिखाई दिया, और 1994 में,
मसौदा-क्षेत्ररक्षण-http-spec-00 प्रकाशित किया गया था। जल्द ही इसे IETF द्वारा स्वीकार कर लिया गया, जिसके परिणामस्वरूप नाम बदलकर
मसौदा-ietf-http-v10-spec-00 हो गया । मसौदे के छह संस्करणों के बाद,
RFC 1945 मानक, HTTP / 1.0, 1996 में अपनाया गया था।
हालाँकि, HTTP / 1.0 पर काम पूरा होने से पहले ही, एक अलग HTTP / 1.1 परियोजना शुरू की गई थी।
प्रारूप-आईईटीएफ-http-v11-spec-00 का मसौदा संस्करण नवंबर 1995 में प्रकाशित किया गया था, और आधिकारिक तौर पर 1997 में
आरएफसी 2068 के रूप में अपनाया गया था। उत्सुक आंख नोटिस करेगी कि क्लैडोग्राम घटनाओं के इस क्रम को नहीं दर्शाता है - दृश्य उपकरण का एक असफल गड़बड़। मैंने जब भी संभव हो ऐसी समस्याओं को कम करने की कोशिश की।
1997 के मध्य में, HTTP / 1.1 का संशोधन
मसौदा-ietf-http-v11-spec-Rev-00 के रूप में शुरू हुआ। यह
RFC 2616 के प्रकाशन के साथ 1999 में समाप्त हुआ। 2007 तक, IETF HTTP दुनिया में सब कुछ शांत था। हम थोड़ी देर बाद इस पर वापस आते हैं।
एसएसएल और टीएलएस इतिहास
हम अपना ध्यान SSL प्रक्षेपवक्र की ओर मोड़ते हैं। हम देखते हैं कि SSL 2.0 विनिर्देश 1995 के आसपास जारी किया गया था, और SSL 3.0 नवंबर 1996 में जारी किया गया था। दिलचस्प बात यह है कि SSL 3.0
RFC 6101 में स्वीकृत है, जो अगस्त 2011 में ही प्रदर्शित हुआ था। यह
ऐतिहासिक खंड में स्थित है।
IETF के अनुसार , इसे "उन विचारों को दस्तावेजित करने के लिए बनाया गया था जिन्हें माना और त्याग दिया गया था, या प्रोटोकॉल जो पहले से मौजूद थे जब तक कि उन्हें दस्तावेज करने का फैसला नहीं किया गया था।" इस मामले में, मुझे एक IETF दस्तावेज़ की आवश्यकता है जो एसएसएल 3.0 का वर्णन करता है ताकि इसे हर जगह एक विहित लिंक के रूप में उपयोग किया जा सके।
हम इस बात में अधिक रुचि रखते हैं कि किस तरह एसएसएल ने इंजीनियरों को टीएलएस विकसित करने के लिए प्रेरित किया, जो नवंबर 1996 में
ड्राफ्ट-आईटीएफ-टीएलएस-प्रोटोकॉल -200 के साथ शुरू हुआ। यह 6 ड्राफ्ट संस्करणों के माध्यम से चला गया और 1999 की शुरुआत में
RFC 2246 - TLS 1.0 के रूप में प्रकाशित हुआ।
1995-1999 में, एसएसएल और टीएलएस का इस्तेमाल इंटरनेट पर HTTP कनेक्शन की सुरक्षा के लिए किया गया था। यह एक वास्तविक मानक के रूप में महान काम करता है। केवल जनवरी 1998 में HTTPS के आधिकारिक मानकीकरण का
मसौदा-ietf-tls-https-00 के प्रकाशन के साथ शुरू हुआ। मई 2000 में
RFC 2616 के प्रकाशन के साथ कार्य पूरा हुआ - TLS पर HTTP।
टीएलएस 1.1 और 1.2 को अपनाने के साथ 2000 से 2007 तक टीएलएस का विकास जारी रहा। तब टीएलएस प्रोटोकॉल के अगले संस्करण पर काम शुरू होने से पहले सात साल का ठहराव था, जिसे अप्रैल 2014 में
ड्राफ्ट-आईटीएफ-टीएलएस-टीएलएस 13-00 के रूप में प्रकाशित किया जाएगा, और 28 ड्राफ्ट के बाद इसे अगस्त 2018 में
पीपीपी 8446 - टीएलएस 1.3 के रूप में
अनुमोदित किया जाएगा।
इंटरनेट मानकीकरण प्रक्रिया
क्लैडोग्राम के साथ एक छोटे से परिचित होने के बाद, मुझे आशा है कि यह समझना बेहतर होगा कि आईईटीएफ कैसे काम करता है। मानक बनाते समय, शोधकर्ता या इंजीनियर विशिष्ट उपयोग के मामलों के लिए प्रयोगात्मक प्रोटोकॉल विकसित करते हैं। विभिन्न स्तरों पर, वे सार्वजनिक या निजी प्रोटोकॉल के साथ प्रयोग करते हैं। प्राप्त जानकारी आपको समस्याओं की पहचान करने या प्रोटोकॉल में सुधार करने की अनुमति देती है। काम का प्रकाशन विशेषज्ञों के एक व्यापक सर्कल के प्रयोग, बैठक की राय या अन्य कलाकारों की मदद खोजने के लिए समझाने में मदद करता है। यदि अन्य प्रतिभागी इस कार्य को प्रारंभिक अवस्था में स्वीकार करते हैं, तो यह वास्तविक मानक बन जाएगा, और अंततः आधिकारिक मानकीकरण के लिए पर्याप्त गति होगी।
प्रोटोकॉल की आधिकारिक स्थिति संगठनों के लिए एक महत्वपूर्ण कारक है जो इसका उपयोग करने के बारे में सोचते हैं। औपचारिक मानकीकरण प्रक्रिया डी वास्तविक मानक को अधिक आकर्षक बनाती है क्योंकि यह आमतौर पर स्थिरता प्रदान करती है। एक प्रतिष्ठित संगठन जैसे कि IETF, जो कई प्रतिभागियों के हितों और अनुभव को दर्शाता है, नेतृत्व और नेतृत्व लेता है। लेकिन यह ध्यान दिया जाना चाहिए कि सभी औपचारिक मानक सफल नहीं होते हैं।
एक मानक बनाने की प्रक्रिया लगभग मानक के रूप में ही महत्वपूर्ण है। प्रारंभिक विचार को संसाधित करना, व्यापक ज्ञान, अनुभव और मामलों का उपयोग करने वाले लोगों के साथ चर्चा करने का निमंत्रण - यह सब व्यापक दर्शकों के लिए कुछ अधिक उपयोगी बनाने में मदद करता है। हालांकि, मानकीकरण प्रक्रिया हमेशा आसान नहीं होती है। नुकसान और बाधाएं हैं। कभी-कभी एक प्रक्रिया में इतना समय लगता है कि परिणाम अब प्रासंगिक नहीं है।
मानकों को परिभाषित करने वाले प्रत्येक संगठन की अपनी प्रक्रिया है, जो गतिविधि और प्रतिभागियों के क्षेत्र पर केंद्रित है। इस लेख के दायरे से परे IETF कैसे काम करता है, के सभी विवरणों को समझाते हुए। यदि आप रुचि रखते हैं, तो IETF की वेबसाइट पर
"हाउ वी वर्क" पेज एक शानदार शुरुआत है। हमेशा की तरह, यह पता लगाने का सबसे अच्छा तरीका है कि आप खुद हिस्सा लें। मेलिंग सूची में शामिल होने के लिए पर्याप्त है या उपयुक्त गिटहॉस रिपॉजिटरी में चर्चा करें।
Cloudflare कार्य कोड
क्लाउडफ्लेयर नए प्रोटोकॉल पेश करने वाले पहले में से एक होने पर गर्व है, जैसा कि
HTTP / 2 और अन्य प्रौद्योगिकियों के मामले में था। हम प्रायोगिक परीक्षण भी करते हैं और अभी तक अनुमोदित नहीं हैं, जैसे
टीएलएस 1.3 और
एसपीडीवाई ।
वास्तविक कोड चलाना आपको यह समझने में मदद करता है कि प्रैक्टिस में प्रोटोकॉल कितना अच्छा काम करेगा। हम कोड को बेहतर बनाने में मदद करने के लिए प्रायोगिक जानकारी के साथ विशेषज्ञ ज्ञान को जोड़ते हैं और जहां यह समझ में आता है, समस्या या कार्य समूह में सुधार की रिपोर्ट करता है जो प्रोटोकॉल को मानकीकृत करता है।
परीक्षण नवाचार केवल प्राथमिकता नहीं है। एक सच्चा इनोवेटर हमेशा जानता है कि बेहतर समय तक नवाचार को कब स्थगित करना है। यह कभी-कभी सुरक्षा-उन्मुख प्रोटोकॉल पर लागू होता है: उदाहरण के लिए, Cloudflare ने POODLE भेद्यता के कारण
डिफ़ॉल्ट रूप से SSLv3 को अक्षम कर दिया। अन्य मामलों में, प्रोटोकॉल को तकनीकी रूप से उन्नत लोगों द्वारा प्रतिस्थापित किया जाता है: उदाहरण के लिए, हमने
SPDY को HTTP / 2 से बदल दिया है ।
Cloudflare पर प्रोटोकॉल को सक्षम और अक्षम करना
नारंगी रेखाओं द्वारा दर्शाया गया है। संबंधित IETF दस्तावेजों के साथ वर्टिकल लैंडस्केप क्लाउडफ़्लारे घटनाओं को सहसंबद्ध करने में मदद करता है। उदाहरण के लिए, Cloudflare ने सितंबर 2016 में TLS 1.3 समर्थन पेश किया, और अंतिम
RFC 8446 लगभग दो साल बाद अगस्त 2018 में प्रकाशित हुआ।
Refactoring: HTTPbis
HTTP / 1.1 एक बहुत ही सफल प्रोटोकॉल है। ग्राफ 1999 के बाद आईईटीएफ की विशेष गतिविधि नहीं दिखाता है। लेकिन वास्तव में, प्रोटोकॉल के सक्रिय उपयोग के वर्षों ने अनुभव दिया और कुछ अनुकूलता समस्याओं सहित RFC 2616 की छिपी हुई समस्याओं का खुलासा किया। इसके अलावा, प्रोटोकॉल का विस्तार अन्य RFC द्वारा किया गया है, जैसे कि 2817 और 2818। परिणामस्वरूप, 2007 में HTTP विनिर्देश को बेहतर बनाने के लिए गतिविधियों को शुरू करने का निर्णय लिया गया। इसे HTTPbis कहा जाता है (जहाँ "bis" लैटिन शब्द "दो", "दो बार" या "दोहराना") से आता है। नए काम करने वाले समूह के प्रारंभिक
चार्टर में उन समस्याओं का अच्छी तरह से वर्णन किया गया है जिन्हें वह हल करने की कोशिश कर रहा था।
सामान्य तौर पर, HTTPbis ने
RFC 2616 को फिर से शुरू करना शुरू कर दिया है। इसमें बग फिक्स और अन्य विनिर्देशों से कुछ पहलुओं को लागू करना शामिल है जो एक ही समय में प्रकाशित होते हैं। दस्तावेज़ को भागों में विभाजित करने का निर्णय लिया गया। परिणामस्वरूप, छह ड्राफ्ट दिसंबर 2007 में प्रकाशित हुए थे:
- मसौदा-IETF-httpbis-p1-संदेश
- मसौदा-IETF-httpbis-p2-अर्थ विज्ञान
- मसौदा-IETF-httpbis-पी 4-सशर्त
- मसौदा-IETF-httpbis-P5 दूरी
- मसौदा-IETF-httpbis-p6-कैश
- मसौदा-IETF-httpbis-p7 लेखन
आरेख दिखाता है कि सात साल की लंबी विकास प्रक्रिया में काम कैसे आगे बढ़ा। अंतिम मानकीकरण से पहले, 27 ड्राफ्ट को अपनाया गया था। जून 2014 में, तथाकथित RFC 723x श्रृंखला (जहाँ x 0 से 5 तक होती है) को रिलीज़ किया गया था। HTTPbis वर्किंग ग्रुप के अध्यक्ष ने इस उपलब्धि को
"RFC2616 मर चुका है" वाक्यांश के साथ नोट किया। अगर किसी को समझ नहीं आया, तो नए दस्तावेजों को पुराने
आरएफसी 2616 के संग्रह में भेजा गया था।
HTTP / 3 के साथ इसका क्या करना है?
जबकि IETF RFC 723x को अंतिम रूप दे रहा था, दुनिया स्थिर नहीं थी। लोग HTTP का विस्तार और पूरक करते रहे। इनमें Google इंजीनियर भी शामिल हैं, जिन्होंने SPDY नामक अपने स्वयं के प्रोटोकॉल के साथ प्रयोग करना शुरू किया (उच्चारण "शीघ्र")। उन्होंने कहा कि यह प्रोटोकॉल वेब पेजों को लोड करने की गति बढ़ाता है, जो HTTP की एक आवश्यक विशेषता है। 2009 के अंत में, पहले संस्करण की घोषणा की गई थी, और 2010 में SPDY v2 जल्दी से दिखाई दिया।
मैं SPDY के तकनीकी विवरणों में नहीं जाना चाहता, लेकिन यह समझना महत्वपूर्ण है कि SPDY ने मूल HTTP प्रतिमानों को लिया और अनुकूलन के लिए विनिमय प्रारूप को थोड़ा बदल दिया। पीछे मुड़कर देखें, तो हम देखते हैं कि HTTP में शब्दार्थ और वाक्य-विन्यास के बीच स्पष्ट अंतर है। शब्दार्थ, अनुरोधों और प्रतिक्रियाओं के आदान-प्रदान की अवधारणा का वर्णन करता है, जिसमें विधियाँ, स्थिति कोड, शीर्ष लेख फ़ील्ड (मेटाडेटा) और निकाय (उपयोगी डेटा) शामिल हैं। सिंटैक्स वर्णन करता है कि नेटवर्क पर बाइट्स को मैप कैसे करें।
HTTP / 0.9, 1.0 और 1.1 में बहुत सारे सामान्य शब्दार्थ हैं। वे टीसीपी कनेक्शन पर भेजे गए चरित्र तार के रूप में भी सामान्य वाक्यविन्यास का उपयोग करते हैं। SPDY ने HTTP / 1.1 के शब्दार्थ को लिया और वाक्यविन्यास को बाइनरी में बदल दिया। यह वास्तव में एक दिलचस्प विषय है, लेकिन आज हम इस खरगोश के छेद में नहीं जाएंगे।
SPDY के साथ प्रयोग से पता चला है कि HTTP सिंटैक्स को बदलने से वास्तव में प्रभाव पड़ता है। इसी समय, मौजूदा शब्दार्थ को बनाए रखना महत्वपूर्ण है। उदाहरण के लिए,
https:// का उपयोग करने के लिए URL प्रारूप को सहेजना कई समस्याओं से बचा है जो HTTPS के कार्यान्वयन को प्रभावित कर सकता है।
कुछ सकारात्मक परिणामों को देखने के बाद, IETF ने निर्णय लिया कि HTTP / 2.0 के विकल्पों पर विचार करने का समय आ गया है। मार्च 2012 में IETF 83 की बैठक के दौरान HTTPbis सत्र की
स्लाइड्स डेवलपर्स द्वारा खुद के लिए निर्धारित आवश्यकताओं और लक्ष्यों को दर्शाती हैं। यह स्पष्ट रूप से बताता है: "HTTP / 2.0 का अर्थ केवल यह है कि परिवहन प्रोटोकॉल (वायर प्रारूप) HTTP / 1.x के साथ संगत नहीं है"
इस बैठक के दौरान, समुदाय को अपने विचारों को व्यक्त करने के लिए आमंत्रित किया गया था। सबमिट किए गए
ड्राफ्ट में
ड्राफ्ट-एमबलेश-httpbis-spdy-00 ,
ड्राफ्ट-मोंटेनेग्रो-httpbis-speed-mobility-00 और
ड्राफ्ट-टारयू-httpbis-network-friendly-00 शामिल थे । अंत में, SPDY के मसौदे को स्वीकार कर लिया गया, और नवंबर 2012 में
मसौदा-ietf-httpbis-http2-00 पर काम शुरू हुआ। 18 ड्राफ्ट के बाद,
RFC 7540 - HTTP / 2 दो वर्षों में थोड़ा दिखाई दिया। 2015 तक, HTTP / 2 सिंटैक्स HTTP / 2 और SPDY को असंगत बनाने के लिए पर्याप्त रूप से चला गया था।
ये वर्ष वर्किंग समूहों के लिए बहुत तनावपूर्ण अवधि बन गए हैं जिन्होंने एक साथ HTTP / 1.1 को फिर से शुरू किया और HTTP / 2 को अपनाया। यह 2000 के दशक की शुरुआत में शांत के वर्षों के विपरीत है। वास्तव में किए गए काम की मात्रा की सराहना करने के लिए पूर्ण क्लैडोग्राम की जांच करना सुनिश्चित करें।
HTTP / 2 के मानकीकरण के बावजूद, SPDY के साथ प्रयोग अभी भी उपयोगी हैं। Cloudflare ने अगस्त 2012 में SPDY समर्थन की शुरुआत की और इसे फरवरी 2018 में ही हटा दिया, जब हमारे आँकड़ों ने दिखाया कि 4% से भी कम वेब क्लाइंट इसका अनुरोध करते हैं। इस बीच, दिसंबर 2015 में आरएफसी के प्रकाशन के तुरंत बाद, हमने HTTP / 2 समर्थन पेश किया, जब विश्लेषण ने वेब क्लाइंट के लिए महत्वपूर्ण समर्थन दिखाया।
SPDY और HTTP / 2 प्रोटोकॉल डिफ़ॉल्ट रूप से TLS का उपयोग करते हैं। सितंबर 2014 में
यूनिवर्सल एसएसएल की शुरूआत ने हमें यह गारंटी दी कि सभी क्लाउडफेयर उपयोगकर्ता नए प्रोटोकॉल का उपयोग करेंगे क्योंकि वे पेश किए गए हैं।
gQUIC
Google ने प्रयोग जारी रखा और 2015 तक SPDY v3 और v3.1 का दूसरा संस्करण जारी किया। उन्होंने gQUIC प्रोटोकॉल पर भी काम शुरू किया, जिसका पहला मसौदा 2012 की शुरुआत में प्रकाशित हुआ था।
GQUIC के पुराने संस्करणों में HTTP SPDY v3 सिंटैक्स का उपयोग किया गया था। इस विकल्प से समझ में आया क्योंकि HTTP / 2 अभी तक स्वीकृत नहीं हुआ है। एसपीडीवाई बाइनरी सिंटैक्स को क्विक पैकेट में पैक किया जाता है जो यूडीपी डेटाग्राम में भेजे जाते हैं। यह टीसीपी परिवहन से एक प्रस्थान है जिसे HTTP ने पारंपरिक रूप से भरोसा किया है। पूरी विधानसभा प्रणाली इस तरह दिखी:
GDIC द्वारा SPDY स्तरित पाईGQUIC ने प्रदर्शन बढ़ाने के लिए ट्रिक्स का इस्तेमाल किया। उनमें से एक आवेदन और परिवहन के बीच स्पष्ट रेखा को धुंधला करना है। व्यवहार में, इसका मतलब यह था कि gQUIC केवल HTTP का समर्थन करता है। यह कनेक्शन इतना मजबूत था कि जीआईसीआईसी, जिसे उस समय QUIC कहा जाता था, को HTTP के अगले संस्करण के लिए एक उम्मीदवार के रूप में देखा गया था। यद्यपि भविष्य में QUIC में कई परिवर्तन किए गए थे, लेकिन आज तक, कई लोगों का मानना है कि यह केवल HTTP का समर्थन करता है। दुर्भाग्य से, यह प्रोटोकॉल की चर्चा करते समय निरंतर भ्रम की ओर जाता है।
GQUIC का विकास जारी रहा और अंततः HTTP / 2 के बहुत अधिक सिंटैक्स में बदल गया। इतने करीब कि ज्यादातर लोग इसे "HTTP / 2 बाय QUIC" कहने लगे। लेकिन तकनीकी सीमाओं के कारण, कुछ बहुत ही सूक्ष्म अंतर दिखाई दिए। एक उदाहरण HTTP हेडर का क्रमांकन और विनिमय है। यह एक मामूली अंतर है, लेकिन व्यवहार में इसका मतलब है कि gQUIC HTTP / 2 IETF HTTP / 2 के साथ संगत नहीं है।
अंतिम लेकिन कम से कम, आपको हमेशा इंटरनेट प्रोटोकॉल के सुरक्षा पहलुओं पर विचार करना चाहिए। और gQUIC के डेवलपर्स ने QUIC Crypto नामक एक अन्य दृष्टिकोण के पक्ष में TLS को छोड़ने का फैसला किया। दिलचस्प नवाचारों में से एक हैंडशेक को तेज करने की एक नई विधि है। सर्वर के साथ एक सुरक्षित सत्र स्थापित करने के बाद, ग्राहक जानकारी का पुन: उपयोग कर सकता है और हैंडशेक के समय, यानी 0-RTT को ठीक कर सकता है। इस ट्रिक को बाद में टीएलएस 1.3 प्रोटोकॉल में शामिल किया गया।
क्या मुझे अंततः पता चल सकता है कि HTTP / 3 क्या है?
लगभग।
अब हम समझते हैं कि मानकीकरण कैसे काम करता है। इसलिए, समान विचारधारा उसी परिदृश्य के अनुसार चली गई। जून 2015 में, "QUIC: सिक्योर एंड रिलायबल यूडीपी-बेस्ड ट्रांसपोर्ट फॉर HTTP / 2," का पहला
ड्राफ्ट-tsvwg-quic-Protocol-00 ड्राफ्ट पेश किया गया था। लेकिन यह मत भूलो कि अंत में HTTP / 2 के साथ प्रोटोकॉल सिंटैक्स को संगतता में लाया जाता है।
Google ने
घोषणा की है कि "BoF प्राग में IETF 93 बैठक में आयोजित किया जाएगा।" यदि आप रुचि रखते हैं कि BoF क्या है, तो कृपया
RFC 6771 देखें। संक्षेप में, BoF (
बर्ड्स ऑफ ए फेदर ) एक सम्मेलन में एक अनौपचारिक बैठक है।
IETF के साथ चर्चा के परिणामस्वरूप, यह निर्णय लिया गया कि QUIC के परिवहन स्तर पर कई फायदे हैं, आपको इस प्रोटोकॉल को HTTP से अलग करना चाहिए और परतों के बीच एक स्पष्ट अलगाव को फिर से प्रस्तुत करना चाहिए। इसके अलावा, इस प्रोटोकॉल के लिए उन्होंने टीएलएस के आधार पर हैंडशेक लौटाने का फैसला किया (जो इतना बुरा नहीं है, क्योंकि उस समय तक 0-आरटीटी योजना के साथ टीएलएस 1.3 पहले ही विकसित हो चुका था)।
लगभग एक साल बाद, 2016 में, ड्राफ्ट का एक नया सेट जारी किया गया:
यह वह जगह है जहां भ्रम फिर से आया है:
ड्राफ्ट-शेड-क्विक-http2-मैपिंग -2017 को "HTTP / 2
सेमेंटिक्स क्विक ट्रांसपोर्ट प्रोटोकॉल का उपयोग करना" कहा जाता है और "HTTP / 2 सिमेंटिक मैपिंग ओवर क्विक" का वर्णन करता है। हालाँकि, यह गलत नाम है। HTTP / 2 का सार शब्दार्थ को बनाए रखते हुए वाक्यविन्यास को बदलना है। इसके अलावा, "HTTP / 2 gQUIC द्वारा" कभी भी वाक्यविन्यास का सटीक विवरण नहीं रहा है, उन कारणों के लिए जिन्हें मैंने पहले उल्लिखित किया है। भविष्य की घटनाओं से परिचित होने पर इसे ध्यान में रखें।
IETF से QUIC का यह संस्करण पूरी तरह से नया परिवहन प्रोटोकॉल बनना चाहिए। यह एक गंभीर उद्यम है, इसलिए IETF ने अपने सदस्यों से परियोजना में रुचि का मूल्यांकन करने की कोशिश की। ऐसा करने के लिए, 2016 में बर्लिन में IETF 96 बैठक में, एक BoF सत्र (
स्लाइड्स ) आयोजित किया गया था। मैं व्यक्तिगत रूप से बैठक में भाग लेने के लिए भाग्यशाली था, जिसने
एडम रोच की
तस्वीर के सबूत के रूप में सैकड़ों प्रतिभागियों को आकर्षित किया। परिणामस्वरूप, आम सहमति बन गई: QUIC को IETF द्वारा अपनाया और मानकीकृत किया जाएगा।
HTTP को
क्वेट ट्रांसपोर्ट में ट्रांसलेट करने के लिए पहला ड्राफ्ट IETF QUIC
ड्राफ्ट- ietf-quic-http-00 ने तार्किक रूप से प्रोटोकॉल नाम को "HTTP ओवर क्विक" (HTTP ओवर क्विक) के रूप में सरल बनाया। दुर्भाग्य से, काम पूरा नहीं हुआ था, इसलिए पूरे संगठन में विभिन्न HTTP / 2 शब्दों का उपयोग किया गया था। नए मानक ड्राफ्ट रिपॉजिटरी के संपादक माइक बिशप ने समस्या को देखा और गलत HTTP / 2 संदर्भों को सही करना शुरू किया। प्रोटोकॉल के अगले संस्करण में, वर्णन "HTTP शब्दार्थों की QUIC पर मैपिंग" में बदल गया।
धीरे-धीरे, समय और नए संस्करणों के साथ, "HTTP / 2" शब्द का उपयोग कम बार किया जाने लगा, यदि आवश्यक हो, तो बस
RFC 7540 की ओर इशारा करते हुए। दो साल बाद, अक्टूबर 2018 में, प्रारूप के सत्रहवें संस्करण (संख्या 16) को जारी किया गया था। यद्यपि QUIC प्रोटोकॉल पर HTTP HTTP / 2 जैसा दिखता है, यह अनिवार्य रूप से एक स्वतंत्र और असंगत HTTP सिंटैक्स है। फिर भी, ऐसे लोग जो IETF के काम की बारीकी से निगरानी नहीं करते हैं (और यह दुनिया की आबादी का एक बहुत बड़ा प्रतिशत है), दस्तावेज़ का शीर्षक इस अंतर को प्रतिबिंबित नहीं करता है। मानकीकरण के मुख्य कार्यों में से एक संचार और अंतर की पदोन्नति है। और नामकरण जैसी सरल बात समुदाय में भ्रम का मुख्य कारण बन गई है।
2012 में जो कहा गया था उसे याद करें: "HTTP / 2.0 का अर्थ केवल यह है कि प्रारूप HTTP / 1.x परिवहन के लिए संगत नहीं है।" IETF ने इस मिसाल का पालन किया है। IETF 103 सम्मेलन के पहले और दौरान बहुत चर्चा के बाद, एक सहमति अभी भी HTTP / 3 के लिए "HTTP ओवर QUIC" का नाम बदलने पर पहुंची थी।
दुनिया बेहतर हो गई है, और हम अधिक महत्वपूर्ण चर्चाओं पर आगे बढ़ सकते हैं।
लेकिन RFC 7230 और 7231 शब्दार्थ और वाक्यविन्यास की आपकी परिभाषा से सहमत नहीं हैं!
कभी-कभी दस्तावेजों के नाम भ्रामक हो सकते हैं। यहाँ HTTP डॉक्स हैं जो वाक्य रचना और शब्दार्थ का वर्णन करते हैं:
- RFC 7230 - हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल (HTTP / 1.1): संदेश सिंटैक्स और रूटिंग
- RFC 7231 - हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल (HTTP / 1.1): शब्दार्थ और सामग्री
ऐसे नामों से, यह माना जा सकता है कि HTTP का मौलिक शब्दार्थ HTTP के एक विशिष्ट संस्करण के लिए विशिष्ट है, अर्थात HTTP / 1.1। लेकिन यह HTTP परिवार के पेड़ का एक यादृच्छिक दुष्प्रभाव है। अच्छी खबर यह है कि HTTPbis वर्किंग ग्रुप समस्या को हल करने की कोशिश कर रहा है। कुछ बहादुर डब्ल्यूजी सदस्यों ने दस्तावेज़ को संशोधित करने का एक और दौर शुरू किया। यह कार्य अभी चल रहा है और इसे HTTP कोर कार्य के रूप में जाना जाता है (आपने इस कार्यसमूह के बारे में सुना होगा जिनके नाम HTTPtre या HTTPter: सब कुछ यहाँ भी अस्पष्ट है) उनके प्रयासों से आप छह ड्राफ्ट को तीन में संक्षिप्त कर सकेंगे:
- HTTP शब्दार्थ (ड्राफ्ट- ietf-httpbis- शब्दार्थ)
- HTTP कैशिंग (ड्राफ्ट- ietf-httpbis-caching)
- HTTP / 1.1 संदेश सिंटैक्स और रूटिंग (ड्राफ़्ट-ietf-httpbis- संदेश)
इस नए ढांचे के हिस्से के रूप में, यह अधिक स्पष्ट हो जाता है कि HTTP / 2 और HTTP / 3 HTTP के सामान्य शब्दार्थों के लिए वाक्यात्मक परिभाषाएं हैं। इसका मतलब यह नहीं है कि वाक्य रचना के बाहर उनके अपने कार्य नहीं हैं, लेकिन इससे आगे की चर्चा में मदद मिलनी चाहिए।
यह सब एक साथ रखना
इस लेख में पिछले तीन दशकों में IETF में HTTP मानकीकरण प्रक्रिया का सतही वर्णन किया गया है। विशेष रूप से तकनीकी विवरणों को छूने के बिना, मैंने यह समझाने की कोशिश की कि अब हम HTTP / 3 पर कैसे पहुंचे। यदि आप बीच में चूक गए हैं और एक वाक्यांश में सार को देखा है, तो यह यहां है:
HTTP / 3 सिर्फ एक नया HTTP सिंटैक्स है जो IETF QUIC पर काम करता है, जो कि यूडीपी पर आधारित एक मल्टीप्लेक्स और सुरक्षित परिवहन है । कई दिलचस्प तकनीकी बारीकियां हैं, लेकिन आपको उन्हें एक और समय के लिए स्थगित करना होगा।
हमने HTTP और TLS को विकसित करने में महत्वपूर्ण कदमों की जांच की, लेकिन एक दूसरे से अलग। अब लेख के अंत में हम फिर से पूरा क्लैडोग्राम प्रकाशित कर रहे हैं। आप शांत और ध्यान से एक आरामदायक सेटिंग में इसका अध्ययन कर सकते हैं। और सुपरसिस्ट्रेनर्स के लिए: यहां
ड्राफ्ट सहित एक पूर्ण संस्करण है ।