HTTP के बारे में सरल भाषा

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

HTTP एक व्यापक डेटा ट्रांसफर प्रोटोकॉल है, जो मूल रूप से हाइपरटेक्स्ट दस्तावेज़ों के हस्तांतरण के लिए अभिप्रेत है (अर्थात, ऐसे दस्तावेज़ जिनमें लिंक हो सकते हैं जो आपको अन्य दस्तावेज़ों में संक्रमण को व्यवस्थित करने की अनुमति देते हैं)।

संक्षिप्त नाम HTTP हाइपर टेक्स्ट ट्रांसफर प्रोटोकॉल के लिए है , "हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल ।" ओएसआई विनिर्देश के अनुसार, HTTP एक एप्लिकेशन (ऊपरी, 7 वां) परत प्रोटोकॉल है। प्रोटोकॉल का वर्तमान संस्करण, HTTP 1.1, RFC 2616 विनिर्देश में वर्णित है।

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

HTTP प्रोटोकॉल का उपयोग करके पारंपरिक रूप से हल किया जाने वाला कार्य एक उपयोगकर्ता एप्लिकेशन के बीच डेटा का आदान-प्रदान है जो वेब संसाधनों (आमतौर पर एक वेब ब्राउज़र) और एक वेब सर्वर तक पहुंचता है। वर्तमान में, यह HTTP प्रोटोकॉल के लिए धन्यवाद है कि वर्ल्ड वाइड वेब समर्थित है।

इसके अलावा, HTTP का उपयोग अक्सर एसओएपी, एक्सएमएल-आरपीसी और वेबदाव जैसे अन्य एप्लिकेशन लेयर प्रोटोकॉल के लिए सूचना हस्तांतरण प्रोटोकॉल के रूप में किया जाता है। इस मामले में, वे कहते हैं कि HTTP प्रोटोकॉल का उपयोग "परिवहन" के रूप में किया जाता है।

कई सॉफ्टवेयर उत्पादों के एपीआई का अर्थ डेटा ट्रांसफर के लिए HTTP के उपयोग से भी है - डेटा स्वयं किसी भी प्रारूप में हो सकता है, उदाहरण के लिए, XML या JSON।

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

HTTP रिक्वेस्ट कैसे भेजें?

HTTP प्रोटोकॉल से निपटने का सबसे आसान तरीका मैन्युअल रूप से वेब संसाधन तक पहुंचने का प्रयास करना है। कल्पना कीजिए कि आप एक ब्राउज़र हैं और आपके पास एक उपयोगकर्ता है जो वास्तव में अनातोली अलिज़ार के लेख पढ़ना चाहता है।

मान लें कि उसने पता बार में निम्नलिखित दर्ज किया है:

http://alizar.habrahabr.ru/

तदनुसार, एक वेब ब्राउज़र के रूप में, अब आपको alizar.habrahabr.ru पर वेब सर्वर से कनेक्ट करने की आवश्यकता है।

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

telnet alizar.habrahabr.ru 80

मैं तुरंत स्पष्ट कर दूंगा कि यदि आप अचानक अपना दिमाग बदलते हैं, तो Ctrl + "] दबाएं" और फिर दर्ज करें - यह आपको HTTP कनेक्शन को बंद करने की अनुमति देगा। टेलनेट के अलावा, आप स्वाद के लिए एनसी (या एनसीएटी) की कोशिश कर सकते हैं।

सर्वर से कनेक्ट होने के बाद, आपको HTTP अनुरोध भेजने की आवश्यकता है। यह, वैसे, बहुत आसान है - HTTP अनुरोधों में केवल दो लाइनें शामिल हो सकती हैं।

HTTP अनुरोध उत्पन्न करने के लिए, आपको एक स्टार्ट लाइन बनाने की आवश्यकता है, साथ ही कम से कम एक हेडर निर्दिष्ट करना होगा - यह होस्ट हेडर है, जिसकी आवश्यकता है और प्रत्येक अनुरोध में मौजूद होना चाहिए। तथ्य यह है कि डोमेन नाम क्लाइंट पक्ष पर एक आईपी पते में बदल जाता है, और, तदनुसार, जब आप एक टीसीपी कनेक्शन खोलते हैं, तो दूरस्थ सर्वर को इस बात की कोई जानकारी नहीं होती है कि कनेक्शन के लिए किस पते का उपयोग किया गया था: यह उदाहरण के लिए हो सकता है। , पता alizar.habrahabr.ru, habrahabr.ru या m.habrahabr.ru है - और इन सभी मामलों में उत्तर भिन्न हो सकते हैं। हालांकि, वास्तव में, सभी मामलों में नेटवर्क कनेक्शन होस्ट 212.24.43.44 के साथ खुलता है, और भले ही कनेक्शन शुरू करते समय डोमेन नाम शुरू में निर्दिष्ट नहीं किया गया था, सर्वर को इसके बारे में बिल्कुल भी सूचित नहीं किया जाता है - और इसीलिए यह पता आवश्यक है होस्ट हेडर में पास करें।

HTTP 1.1 के लिए प्रारंभ (प्रारंभिक) अनुरोध पंक्ति निम्नानुसार बनाई गई है:

HTTP URI विधि / संस्करण

उदाहरण के लिए (इस तरह की एक शुरुआत रेखा यह संकेत दे सकती है कि साइट के मुख्य पृष्ठ का अनुरोध किया जा रहा है):

GET / HTTP/1.1

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

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

OPTIONS * HTTP/1.1

संस्करण निर्धारित करता है कि HTTP मानक के किस संस्करण के अनुसार अनुरोध किया गया है। यह एक डॉट (उदाहरण के लिए 1.1 ) द्वारा अलग किए गए दो नंबरों के रूप में इंगित किया गया है।

किसी विशिष्ट पते पर एक वेब पेज तक पहुँचने के लिए (इस मामले में, संसाधन का मार्ग "/" है), हमें निम्नलिखित अनुरोध भेजना चाहिए:

GET / HTTP/1.1
Host: alizar.habrahabr.ru

ध्यान रखें कि लाइन लपेटने के लिए आपको कैरिज रिटर्न चरित्र का उपयोग करना होगा, उसके बाद लाइन फीड चरित्र। अंतिम हेडर घोषित होने के बाद, लाइन ब्रेक के लिए वर्णों का क्रम दो बार जोड़ा जाता है।

हालाँकि, HTTP विनिर्देश में, यह अनुशंसा की जाती है कि HTTP सर्वर को इस तरह से प्रोग्राम किया जाए कि प्रोसेसिंग अनुरोधों के दौरान, LF वर्ण को लाइन विभाजक के रूप में लिया जाए, और पिछले CR वर्ण, यदि कोई हो, को अनदेखा किया जाता है। तदनुसार, व्यवहार में, अधिकांश सर्वर इस तरह के अनुरोध को सही ढंग से संसाधित करेंगे, जहां हेडर एलएफ प्रतीक द्वारा अलग किए जाते हैं, और अंतिम हेडर घोषित होने के बाद इसे दो बार जोड़ा जाता है।

यदि आप विनिर्देश के अनुसार कड़ाई से एक अनुरोध भेजना चाहते हैं, तो आप बच अनुक्रम \ r और \ n का उपयोग कर सकते हैं:

echo -en "GET / HTTP/1.1\r\nHost: alizar.habrahabr.ru\r\n\r\n" | ncat alizar.habrahabr.ru 80

जवाब कैसे पढ़ें?

प्रतिक्रिया की आरंभ रेखा में निम्नलिखित संरचना है:

HTTP / संस्करण स्थिति कोड स्पष्टीकरण

प्रोटोकॉल संस्करण अनुरोध के अनुसार यहां निर्दिष्ट किया गया है।

स्थिति कोड - तीन अंक (जिनमें से पहला स्थिति वर्ग इंगित करता है) जो अनुरोध के परिणाम को निर्धारित करता है। उदाहरण के लिए, यदि GET विधि का उपयोग किया गया था, और सर्वर निर्दिष्ट पहचानकर्ता के साथ एक संसाधन प्रदान करता है, तो यह स्थिति कोड 200 का उपयोग करके सेट की जाती है। यदि सर्वर रिपोर्ट करता है कि ऐसा संसाधन मौजूद नहीं है - 404. यदि सर्वर रिपोर्ट करता है कि यह नहीं है क्लाइंट के लिए आवश्यक विशेषाधिकारों की कमी के कारण इस संसाधन तक पहुंच प्रदान कर सकता है, कोड 403 का उपयोग किया जाता है। HTTP 1.1 विनिर्देशन 40 अलग-अलग HTTP कोड को परिभाषित करता है, और प्रोटोकॉल का विस्तार करना और अतिरिक्त स्थिति कोड का उपयोग करना भी संभव है।

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

शुरुआत के बाद हेडर, साथ ही प्रतिक्रिया का शरीर। उदाहरण के लिए:

 HTTP/1.1 200 OK Server: nginx/1.2.1 Date: Sat, 08 Mar 2014 22:53:46 GMT Content-Type: application/octet-stream Content-Length: 7 Last-Modified: Sat, 08 Mar 2014 22:53:30 GMT Connection: keep-alive Accept-Ranges: bytes Wisdom 

अंतिम शीर्षलेख के बाद प्रतिक्रिया निकाय दो पंक्ति विराम का अनुसरण करता है। प्रतिक्रिया निकाय के अंत को निर्धारित करने के लिए, सामग्री-लंबाई के हेडर के मूल्य का उपयोग किया जाता है (इस मामले में, प्रतिक्रिया में 7 ऑक्टल बाइट्स होते हैं: शब्द "बुद्धि" और लाइन ब्रेक चरित्र)।

लेकिन हम पहले किए गए अनुरोध के अनुसार, वेब सर्वर कोड 200 के साथ नहीं, बल्कि कोड 302 के साथ उत्तर लौटाएंगे। इस प्रकार, यह क्लाइंट को सूचित करता है कि इस संसाधन को एक अलग पते पर एक्सेस करना आवश्यक है।

अपने लिए देखें:

 HTTP/1.1 302 Moved Temporarily Server: nginx Date: Sat, 08 Mar 2014 22:29:53 GMT Content-Type: text/html Content-Length: 154 Connection: keep-alive Keep-Alive: timeout=25 Location: http://habrahabr.ru/users/alizar/ <html> <head><title>302 Found</title></head> <body bgcolor="white"> <center><h1>302 Found</h1></center> <hr><center>nginx</center> </body> </html> 

स्थान शीर्षक नया पता है। अब URI (संसाधन पहचानकर्ता) / उपयोगकर्ता / alizar / में बदल गया है, और इस समय आपको सर्वर को habrahabr.ru पर एक्सेस करने की आवश्यकता है (हालाँकि, इस मामले में यह समान सर्वर है), और इसे होस्ट हेडर में निर्दिष्ट करें।

वह है:

GET /users/alizar/ HTTP/1.1
Host: habrahabr.ru

इस अनुरोध के जवाब में, हब्रेब्र वेब सर्वर पहले से ही कोड 200 और एक काफी बड़े HTML दस्तावेज़ के साथ प्रतिक्रिया जारी करेगा।

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

सुरक्षा के बारे में क्या?

HTTP प्रोटोकॉल स्वयं सूचना प्रसारित करने के लिए एन्क्रिप्शन का उपयोग नहीं करता है। फिर भी, HTTP के लिए एक व्यापक विस्तार है जो क्रिप्टोग्राफिक प्रोटोकॉल एसएसएल या टीएलएस में प्रेषित डेटा की पैकेजिंग को लागू करता है।

इस एक्सटेंशन का नाम HTTPS ( HyperText Transfer Protocol Secure ) है। HTTPS कनेक्शन के लिए, TCP पोर्ट 443 का आमतौर पर उपयोग किया जाता है। HTTPS का उपयोग व्यापक रूप से सूचना को अवरोधन से बचाने के लिए किया जाता है, और, एक नियम के रूप में, यह क्लाइंट पर प्रमाण पत्र सत्यापित होने पर, मध्य-मध्य हमलों के खिलाफ सुरक्षा प्रदान करता है, और हालाँकि, प्रमाणपत्र की निजी कुंजी से समझौता नहीं किया गया था, उपयोगकर्ता ने अहस्ताक्षरित प्रमाण पत्र के उपयोग की पुष्टि नहीं की, और उपयोगकर्ता के कंप्यूटर पर हमलावर के प्रमाण पत्र प्राधिकरण के प्रमाण पत्र लागू नहीं किए गए थे।

HTTPS वर्तमान में सभी लोकप्रिय वेब ब्राउज़रों द्वारा समर्थित है।

क्या कोई अतिरिक्त विशेषताएं हैं?

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

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

क्या आप कुछ और उपयोग करते हैं, वैसे?

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

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

नवंबर 2012 में प्रकाशित HTTP 2.0 प्रोटोकॉल का मसौदा विनिर्देश (संस्करण 1.1 के बाद HTTP प्रोटोकॉल का अगला संस्करण, जिसके लिए अंतिम विनिर्देश 1999 में प्रकाशित हुआ था) SPDY प्रोटोकॉल विनिर्देश पर आधारित है।

एसपीडीवाई प्रोटोकॉल में इस्तेमाल किए गए कई वास्तुशिल्प समाधानों के साथ-साथ अन्य प्रस्तावित कार्यान्वयनों में जो कि HTTP 2.0 विनिर्देश का मसौदा तैयार करते समय httpbis कार्य समूह पर विचार किया गया था, पहले HTTP-NG प्रोटोकॉल के विकास के दौरान प्राप्त किया गया था, लेकिन HTTP-NG प्रोटोकॉल पर काम बंद कर दिया गया था। 1998 में।

फिलहाल, SPDY प्रोटोकॉल का समर्थन ब्राउज़र फ़ायरफ़ॉक्स, क्रोमियम / क्रोम, ओपेरा, इंटरनेट एक्सॉपर और अमेज़ॅन सिल्क में है।

तो क्या?

सामान्य तौर पर, हाँ। विशिष्ट तरीकों और हेडर का वर्णन करना संभव होगा, लेकिन वास्तव में इस ज्ञान की आवश्यकता होती है यदि आप कुछ विशिष्ट लिखते हैं (उदाहरण के लिए, एक वेब सर्वर या कुछ क्लाइंट सॉफ़्टवेयर जो HTTP के माध्यम से सर्वर के साथ संचार करता है), और के लिए कैसे प्रोटोकॉल काम करता है की एक बुनियादी समझ की आवश्यकता नहीं है। इसके अलावा, यह सब आप बहुत आसानी से Google के माध्यम से पा सकते हैं - यह जानकारी विनिर्देशों में है, और विकिपीडिया पर, और बहुत कुछ।

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

ठीक है, निश्चित रूप से, यह मत भूलो कि कोई भी तकनीक बहुत सरल और अधिक समझ में आ जाती है जब आप वास्तव में इसका उपयोग करना शुरू करते हैं।

सौभाग्य और फलदायी विद्या!