DNS प्रोटोकॉल के संबंध में HTTP GET विधि कैसे काम करती है?


18

मैं टीसीपी / आईपी स्टैक में एप्लिकेशन लेयर प्रोटोकॉल को समझने की कोशिश कर रहा हूं। मुझे पता है कि HTTP और DNS प्रोटोकॉल दोनों शीर्ष स्तर (एप्लीकेशन लेयर) पर बने रहते हैं। इसलिए, जब कोई ब्राउज़र किसी संसाधन का उपयोग करना चाहता है, तो उसे HTTP सर्वर को एक अनुरोध भेजना होगा, उदाहरण के लिए:

GET www.pippo.it/hello.htm HTTP/1.1

HTTP प्रोटोकॉल के नियमों का पालन करते हुए यह अनुरोध करते हुए, यह पृष्ठ URL का उपयोग करता है, आईपी पते का नहीं।

मुझे पता है कि URL को IP में बदलने के लिए DNS अनुरोध आवश्यक है। तो मेरा सवाल है: क्या HTTP DNS प्रोटोकॉल को लागू करता है? यह मेरे लिए असंभव लगता है, क्योंकि दोनों ही शीर्ष स्तर के प्रोटोकॉल हैं (इसलिए DNS HTTP को सेवा प्रदान नहीं कर सकते हैं)। उसी तरह यहां तक ​​कि टीसीपी (जो निचले स्तर पर रहता है) डीएनएस जैसे उच्च स्तर के प्रोटोकॉल पर सेवा के लिए नहीं कह सकता है।

तो DNS अनुरोध कब होता है? और ऐसा अनुरोध कौन करता है?


1
क्या आप इनमें से किसी एक प्रश्न को स्पष्ट करने के लिए कोई उत्तर स्वीकार कर सकते हैं?
०३०

जवाबों:


38

सवाल में HTTP अनुरोध वास्तव में मान्य नहीं है जब तक कि ब्राउज़र एक मध्यस्थ (प्रॉक्सी) से बात नहीं कर रहा हो।

यदि आपका ब्राउज़र सीधे वेब सर्वर से बात कर रहा है तो आपका उदाहरण थोड़ा और निम्नलिखित होगा:

GET /hello.htm HTTP/1.1
Host: www.pippo.it

अब, इसे परिप्रेक्ष्य में रखें, OSI मॉडल पर विचार करें:

OSI मॉडल

हमारे पास 3 सिस्टम हैं:

  • एक क्लाइंट जो ब्राउज़र चला रहा है
  • एक वेब सर्वर साइट की सेवा
  • एक DNS सर्वर साइट का आईपी पता जानता है

इसमें शामिल प्रोटोकॉल नीचे से ऊपर (न्यूनतम प्रासंगिक सेट ओपी पर) हैं:

  • आईपी
  • टीसीपी, यूडीपी
  • HTTP, DNS

HTTP संचार टीसीपी प्रोटोकॉल के ऊपर किया जाता है (टीसीपी आईपी प्रोटोकॉल के शीर्ष पर है) जबकि DNS संचार, इस मामले में यूडीपी प्रोटोकॉल पर किया जाता है (यूडीपी भी आईपी प्रोटोकॉल के शीर्ष पर है)।

यहाँ संक्षेप में संचार अनुक्रम है:

  1. ग्राहक , ब्राउज़र चल रहा है, पूछता है DNS सर्वर एक के लिए Aके लिए रिकॉर्ड www.pippo.it, यूडीपी प्रोटोकॉल का उपयोग।

    1.1। क्लाइंट पर, यह ऑपरेटिंग सिस्टम है जो हल करने वाला हिस्सा करता है और ब्राउज़र से वापस बात करता है --- ब्राउज़र कभी भी DNS सर्वर से सीधे बात नहीं करता है, बल्कि ओएस के माध्यम से gethostbyname () या नए getaddrinfo () को इनवाइट करता है । विंडोज पर, जिस क्रम में ओएस पते को हल करता है, वह संभवतः इस तरह से परिभाषित किया जाता है , जबकि लिनक्स पर संकल्प पूर्ववर्ती द्वारा परिभाषित किया जाता है/etc/nsswitch.conf

  2. DNS सर्वर , यूडीपी प्रोटोकॉल, का जवाब का उपयोग कर ग्राहक , एक रिकार्ड / आईपी पते के साथ यदि वह मौजूद है

  3. ग्राहक के पोर्ट 80 पर एक TCP कनेक्शन खोलता वेब सर्वर और निम्न पाठ लिखते हैं:

    HTTP अनुरोध:

    GET /hello.htm HTTP/1.1
    Host: www.pippo.it
    

    आप अपने कंसोल या कमांड प्रॉम्प्ट में कुछ इस तरह से कर सकते हैं।

    > telnet www.pippo.it 80
    Trying 195.128.235.49...
    Connected to www.pippo.it.
    Escape character is '^]'.
    GET /hello.htm HTTP/1.1
    Host: www.pippo.it
    

    दो खाली लाइनों के बाद। यदि अनुरोधित सामग्री मौजूद है, तो वेब सर्वर इसे स्क्रीन पर प्रिंट करेगा। यदि दूसरी तरफ एक ब्राउज़र है, तो प्रतिक्रिया पाठ ब्राउज़र द्वारा पार्स हो जाता है, और सभी टैग, लिंक, स्क्रिप्ट और छवियां प्रदान की जाती हैं जिसे हम एक वेब पेज कहते हैं।

वास्तव में, कुछ और विवरण हैं, उदाहरण के लिए, यदि आप पहले से ही कुछ डोमेन पर गए हैं, तो ब्राउज़र आईपी पते को कैश कर सकते हैं, ताकि DNS निराकरण अनावश्यक हो जाए। इसके अलावा, आधुनिक ब्राउज़र आपके ब्राउज़िंग को गति देने के लिए वास्तव में इसे ( DNS prefetching ) करने से पहले आपको हल करने का प्रयास कर सकते हैं ।

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


4
@trikly: यही 'होस्ट' हेडर है। इसके बिना आपके पास प्रति आईपी पते पर केवल एक वेबसाइट हो सकती है। यह HTTP / 1.0 और HTTP / 1.1 के बीच एक महत्वपूर्ण अंतर है। शुक्र है कि HTTP / 1.0 ब्राउज़र अब दुर्लभ हैं - लेकिन अगर आप उनके लिए पूरा करना चाहते हैं, तो आपको प्रत्येक साइट के लिए एक अलग आईपी पते की आवश्यकता है (वे अभी भी उसी सर्वर पर होस्ट किए जा सकते हैं)।
AE

1
@ ईरान धन्यवाद। मुझे लगता है कि मैं अपने प्रश्न में स्पष्ट नहीं था, और यही कारण है कि ह्रीवो को समझ नहीं आया कि मैं क्या कह रहा था। (मुझे URL के बजाय डोमेन कहना चाहिए था)। मुझे खुशी है कि आप अभी भी समझ रहे हैं।
त्रिकली

1
आप कहते हैं, " यह HTTP अनुरोध सही नहीं है ", और यह ज्यादातर सच है, लेकिन यह आपके द्वारा की तुलना में करीब है: " HTTP के भविष्य के संस्करणों में सभी अनुरोधों में निरपेक्षता के लिए संक्रमण की अनुमति देने के लिए, सभी HTTP / 1.1 सर्वरों को निरपेक्ष रूप से स्वीकार करना होगा अनुरोध ”। (RFC 2616 .15.1.2) तो GET http://www.pippo.it/hello.htm HTTP/1.1यह एक वैध होगा, यदि असामान्य हो तो निवेदन करें। यह HTTP प्रॉक्सी के लिए एक वैध और सामान्य अनुरोध भी होगा।
wufulk

1
gethostbyname()कुछ पुराना है। बेहतर होगा एक का उपयोग getaddrinfo()...
glglgl

1
@Utku दुर्भाग्य से नहीं, क्योंकि SSH दूसरे छोर को एसएसएच प्रोटोकॉल बोलता है जबकि टेलनेट सादा पाठ प्रोटोकॉल है और किसी भी अन्य सादे प्रोटोकॉल जैसे कि POP3, IMAP से बात करने के लिए इस्तेमाल किया जा सकता है जब तक कि वे एसएसएल / टीएलएस का उपयोग नहीं करते हैं, जिस स्थिति में आप को टेलनेट सेशन को sllwrap या कुछ इसी तरह के हेल्पर के साथ लपेटना होगा।
हीरोवो atपोलर

12

HTTP को TCP पर ले जाया जाता है, जो एक IP प्रोटोकॉल है। HTTP अनुरोध करने के लिए, ब्राउज़र को एक टीसीपी कनेक्शन खोलना पड़ता है, और उसके लिए, उसे गंतव्य आईपी पते (यानी सर्वर का आईपी पता) की आवश्यकता होती है। सर्वर के होस्टनाम को हल करने के लिए, इस प्रकार एक DNS अनुरोध जारी करना होता है (आमतौर पर DNS अनुरोध खुद ऑपरेटिंग सिस्टम द्वारा भेजा जाता है जब कोई प्रोग्राम अपने नाम रिज़ॉल्यूशन फ़ंक्शन को कॉल करता है; हालांकि, कुछ भी प्रोग्राम को DNS द्वारा DNS अनुरोधों को स्वयं भेजने से रोकता है; सर्वर)। एक बार कनेक्शन स्थापित हो जाने के बाद, यह अपना HTTP अनुरोध भेज सकता है, जिसमें अनुरोधित संसाधन का पथ होता है, और सर्वर के होस्टनाम के साथ होस्ट फ़ील्ड (जैसे, Host: www.pippo.it)। होस्टनाम अनुरोध रेखा पर नहीं जाता है (यह वास्तव में होगाGET /hello.htm HTTP/1.1), जब एक HTTP प्रॉक्सी के लिए अनुरोध भेजा जाता है (और इस मामले में, पूरा URL मौजूद है, सिवाय प्रोटोकॉल भाग सहित, उदाहरण के लिए GET http://www.pippo.it/hello.htm HTTP/1.1)


धन्यवाद, अब यह स्पष्ट है, लेकिन पूरी तरह से नहीं। आप लिखते हैं कि ब्राउज़र को DNS अनुरोध जारी करना होगा। ठीक है, लेकिन DNS सर्वर से आईपी प्राप्त करने के बाद, यह इसका उपयोग कैसे करता है? मेरा मतलब है, इस तरह के आईपी HTTP अनुरोध में दिखाई नहीं देते हैं। इसलिए मुझे लगता है कि HTTP अनुरोध जारी करने से पहले अभी भी एक और कदम है और मुझे लगता है कि यह कनेक्शन का उद्घाटन है। यह बिंदु मेरे लिए बहुत स्पष्ट नहीं है ... एक बार फिर धन्यवाद!
जियानकार्लो पेरो

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

1
अनुमानित अनुरोधों को होस्ट हेडर का उपयोग करना चाहिए, पूरा URL जीईटी लाइन में नहीं डालना चाहिए।
ऑरेंजडॉग

1
@ ऑरेंजडॉग: नहीं, इसके विपरीत। RFC 7230 (खंड 5.3.2) स्पष्ट रूप से कहता है कि प्रॉक्सी से अनुरोध करने वाला ग्राहक अनुरोध पंक्ति में निरपेक्ष-URI का उपयोग करता है। ( अनुरोध पंक्ति से एक होस्ट हेडर की डुप्लिकेट जानकारी अभी भी होनी चाहिए ; धारा 5.4)।
हमाखोल

8

प्रक्रिया इस प्रकार है:

  1. उपयोगकर्ता (आप) ब्राउज़र को एक URL देता है, जैसे http://www.pippo.it/hello.htm
  2. ब्राउज़र तीन भागों में विभाजित होता है:

    • मसविदा बनाना http
    • होस्ट का नाम www.pippo.it
    • URL पथ /hello.htm

    (एक अधिक जटिल URL के अन्य भाग भी हो सकते हैं, मैं इस संभावना को अभी अनदेखा करूंगा)

  3. ब्राउज़र जानता है कि एक आईपी कनेक्शन बनाने के लिए, उसे एक आईपी पते की आवश्यकता है। एक आईपी पता प्राप्त करने के लिए, इसे DNS (जब तक इसका पता कैश न हो) का उपयोग करने की आवश्यकता होती है।

    1. ब्राउज़र एक DNS सर्वर के आईपी पते के लिए ऑपरेटिंग सिस्टम पूछता है; मान लीजिए कि यह हो जाता है 8.8.8.8
    2. ब्राउज़र निम्न बहुस्तरीय कनेक्शन का निर्माण करता है:

      • IP लेयर: से कनेक्ट करें 8.8.8.8
      • यूडीपी परत: गंतव्य पोर्ट 53 के लिए सेट पैकेट
      • DNS परत: Aहोस्टनाम के लिए रिकॉर्ड के लिए DNS अनुरोध बनाएँwww.pippo.it

      बेशक, मैं बहुत सारे विवरणों को छोड़ रहा हूं जैसे कि पैकेट के सटीक प्रारूप।

    3. ब्राउज़र को एक DNS प्रतिसाद (IP के शीर्ष पर स्तरित UDP के शीर्ष पर स्तरित) प्राप्त होता है, जिसके लिए IP पता देता है www.pippo.it, आइए इसे कहते हैं10.11.12.13
  4. ब्राउज़र जानता है कि टीसीपी कनेक्शन बनाने के लिए, उसे पोर्ट नंबर की आवश्यकता है। पोर्ट नंबर प्राप्त करने के लिए, यह httpअपनी आंतरिक तालिका में प्रोटोकॉल को देखता है और सीखता है कि इसे पोर्ट 80 का उपयोग करना चाहिए।
  5. ब्राउज़र निम्न बहुस्तरीय कनेक्शन का निर्माण करता है:

    • IP लेयर: से कनेक्ट करें 10.11.12.13
    • टीसीपी परत: पोर्ट 80 के गंतव्य के लिए पैकेट सेट करें
    • HTTP लेयर: /hello.htmहोस्ट पर URL के लिए एक HTTP अनुरोध बनाएं www.pippo.it(क्योंकि कंप्यूटर में 10.11.12.13कई डोमेन होस्ट किए जा सकते हैं, इसलिए यह जानना आवश्यक है कि कौन सा वांछित है)

      GET /hello.htm HTTP/1.1
      Host: www.pippo.it
      ...
      

    बेशक मैं टीसीपी हैंडशेक और इस तरह के सभी विवरणों को छोड़ रहा हूं।

  6. ब्राउज़र एक HTTP प्रतिसाद प्राप्त करता है (IP आदि के ऊपर स्तरित TCP के शीर्ष पर स्तरित) जिसमें की सामग्री है hello.htm

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


4
चरण 3 वास्तव में कुछ ऐसा नहीं है जो एप्लिकेशन स्वयं करता है। एप्लिकेशन बस कुछ का उपयोग करता है getaddrinfoया इसके gethostbynameलिए पता हल करने के लिए ओएस से पूछने के लिए उपयोग करता है । इसके अलावा, ओएस आमतौर पर डीएनएस ही नहीं, नामों को देखने की कोशिश करने के लिए कई तंत्रों का उपयोग करता है। (आमतौर पर DNS के अलावा कम से कम होस्ट फ़ाइल।)
हांक लिंडक्विस्ट

धन्यवाद! यह वास्तव में प्रभावशाली और विस्तृत उत्तर है और बहुत उपयोगी भी है!
जियानकार्लो पेरो

यह सबसे अच्छा जवाब है।
शिन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.