HTTP 1.0 बनाम 1.1




http-1.1 http-1.0 (6)

क्या कोई मुझे HTTP 1.0 और HTTP 1.1 के बीच अंतरों का एक संक्षिप्त अवलोकन दे सकता है? मैंने दोनों आरएफसी के साथ कुछ समय बिताया है, लेकिन उनके बीच बहुत अंतर नहीं खींच पाया है। विकिपीडिया यह कहता है:

HTTP / 1.1 (1997-1999)

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

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


1.0 की तुलना में, 1.1 वेब यातायात को कम करता है


HTTP 1.1 हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल का नवीनतम संस्करण है, वर्ल्ड वाइड वेब एप्लिकेशन प्रोटोकॉल जो प्रोटोकॉल के इंटरनेट के टीसीपी / आईपी सूट के शीर्ष पर चलता है। HTTP 1.0 की तुलना में, HTTP 1.1 मूल HTTP की तुलना में वेब पृष्ठों की तेज़ डिलीवरी प्रदान करता है और वेब ट्रैफ़िक को कम करता है।

वेब यातायात उदाहरण: उदाहरण के लिए, यदि आप किसी सर्वर तक पहुंच रहे हैं। उसी समय बहुत से उपयोगकर्ता डेटा के लिए सर्वर तक पहुंच रहे हैं, फिर सर्वर को लटकाने का एक मौका है। यह वेब यातायात है।


छोटे अनुप्रयोगों के लिए (उदाहरण के लिए वेब-सक्षम थर्मामीटर से तापमान मूल्य को स्पोरैडिक रूप से पुनर्प्राप्त करना) HTTP 1.0 क्लाइंट और सर्वर दोनों के लिए ठीक है। आप कोड की लगभग 20 पंक्तियों में एक नंगे-हड्डियों सॉकेट-आधारित HTTP 1.0 क्लाइंट या सर्वर लिख सकते हैं।

अधिक जटिल परिदृश्यों के लिए HTTP 1.1 जाने का तरीका है। अधिक जटिल HTTP 1.1 प्रोटोकॉल की जटिलताओं से निपटने के लिए कोड आकार में 3 से 5 गुना वृद्धि की अपेक्षा करें। जटिलता मुख्य रूप से आती है, क्योंकि HTTP 1.1 में आपको विभिन्न शीर्षकों को बनाने, विश्लेषण करने और प्रतिक्रिया देने की आवश्यकता होगी। क्लाइंट को HTTP लाइब्रेरी का उपयोग करके, या सर्वर वेब अनुप्रयोग सर्वर का उपयोग करके आप इस जटिलता से अपने एप्लिकेशन को ढाल सकते हैं।


मेरे सिर के शीर्ष से मुझे याद किए जाने वाले पहले मतभेदों में से एक एक ही सर्वर, आंशिक संसाधन पुनर्प्राप्ति में चल रहे एकाधिक डोमेन हैं, यह आपको संसाधन के डाउनलोड को पुनर्प्राप्त करने और तेज़ करने की अनुमति देता है (यह लगभग हर डाउनलोड त्वरक करता है)।

यदि आप किसी वेबसाइट या इसी तरह के किसी एप्लिकेशन को विकसित करना चाहते हैं, तो आपको मतभेदों के बारे में बहुत ज्यादा चिंता करने की आवश्यकता नहीं है, लेकिन आपको कम से कम GET और POST क्रियाओं के बीच अंतर पता होना चाहिए

अब यदि आप ब्राउज़र विकसित करना चाहते हैं तो हाँ, आपको पूर्ण प्रोटोकॉल के साथ-साथ यदि आप HTTP सर्वर विकसित करने का प्रयास कर रहे हैं तो आपको जानना होगा।

यदि आप केवल HTTP प्रोटोकॉल को जानने में रुचि रखते हैं तो मैं आपको 1.0 के बजाय HTTP / 1.1 से शुरू करने की सलाह दूंगा।



प्रॉक्सी समर्थन और होस्ट फ़ील्ड:

HTTP 1.1 में spec द्वारा एक आवश्यक होस्ट हेडर है।

HTTP 1.0 को आधिकारिक तौर पर होस्ट हेडर की आवश्यकता नहीं होती है, लेकिन यह एक को जोड़ने में कोई दिक्कत नहीं होती है, और प्रोटोकॉल संस्करण के बावजूद होस्ट हेडर को देखने के लिए कई एप्लिकेशन (प्रॉक्सी) अपेक्षा करते हैं।

उदाहरण:

GET / HTTP/1.1
Host: www.blahblahblahblah.com

यह हेडर उपयोगी है क्योंकि यह आपको प्रॉक्सी सर्वर के माध्यम से एक संदेश रूट करने की अनुमति देता है, और यह भी कि आपका वेब सर्वर एक ही सर्वर पर विभिन्न साइटों के बीच अंतर कर सकता है।

तो इसका मतलब है कि यदि आपके पास blahblahlbah.com और helohelohelo.com दोनों एक ही आईपी को इंगित करते हैं। आपका वेब सर्वर मेजबान फ़ील्ड का उपयोग क्लाइंट मशीन की इच्छित साइट को अलग करने के लिए कर सकता है।

लगातार कनेक्शन:

HTTP 1.1 आपको लगातार कनेक्शन रखने की अनुमति देता है जिसका अर्थ है कि आपके पास एक ही HTTP कनेक्शन पर एक से अधिक अनुरोध / प्रतिक्रिया हो सकती है।

HTTP 1.0 में आपको प्रत्येक अनुरोध / प्रतिक्रिया जोड़ी के लिए एक नया कनेक्शन खोलना पड़ा। और प्रत्येक प्रतिक्रिया के बाद कनेक्शन बंद हो जाएगा। यह टीसीपी धीमी शुरुआत के कारण कुछ बड़ी दक्षता समस्याओं का कारण बनता है।

विकल्प विधि:

HTTP / 1.1 विकल्प विधि प्रस्तुत करता है। एक HTTP क्लाइंट HTTP सर्वर की क्षमताओं को निर्धारित करने के लिए इस विधि का उपयोग कर सकता है। यह ज्यादातर वेब अनुप्रयोगों में क्रॉस ओरिजिनल रिसोर्स शेयरिंग के लिए उपयोग किया जाता है।

कैशिंग:

HTTP 1.0 को शीर्षलेख के माध्यम से कैशिंग के लिए समर्थन था: यदि-संशोधित-के बाद से।

HTTP 1.1 कैशिंग समर्थन पर 'इकाई टैग' नामक किसी चीज़ का उपयोग करके बहुत अधिक विस्तार करता है। यदि 2 संसाधन समान हैं, तो उनके पास एक ही इकाई टैग होंगे।

HTTP 1.1 भी if-Unmodified- के बाद, अगर-मैच, अगर-कोई नहीं-मैच सशर्त हेडर जोड़ता है।

कैश-कंट्रोल हेडर जैसे कैशिंग से संबंधित अतिरिक्त जोड़ भी हैं।

100 जारी रखें स्थिति:

HTTP / 1.1 100 जारी रखें में एक नया रिटर्न कोड है। यह क्लाइंट को एक बड़ा अनुरोध भेजने से रोकने के लिए है जब उस क्लाइंट को यह भी सुनिश्चित नहीं है कि सर्वर अनुरोध संसाधित कर सकता है या अनुरोध को संसाधित करने के लिए अधिकृत है। इस मामले में ग्राहक केवल शीर्षलेख भेजता है, और सर्वर ग्राहक को बताएगा 100 जारी रखें, शरीर के साथ आगे बढ़ें।

बहुत अधिक:

  • डाइजेस्ट प्रमाणीकरण और प्रॉक्सी प्रमाणीकरण
  • अतिरिक्त नए स्टेटस कोड
  • चंकित स्थानांतरण एन्कोडिंग
  • कनेक्शन हेडर
  • उन्नत संपीड़न समर्थन
  • बहुत अधिक






http-1.0