किसी वेबसाइट से जुड़ने के लिए विस्तृत OSI मॉडल चरण क्या हैं?

Question

किसी वेबसाइट से जुड़ने में शामिल विस्तृत कदम क्या हैं, जैसे कि एक नए जुड़े कंप्यूटर (http, और कुछ भी नहीं है) का उपयोग करके superuser.com होम पेज? ईथरनेट पर भेजे जाने वाले अंतिम बिट के निर्माण के लिए पृष्ठभूमि में वास्तव में क्या हो रहा है?

मैं समझता हूं कि, उदाहरण के लिए, एक कनेक्शन (Fayer 7) को IP पते (Layer 7) या कनेक्शन स्थापित करने के लिए तीन-तरफ़ा हैंडशेक के लिए FQDN को हल करने के लिए DNS क्वेरी बनाई जाती है (Layer 4)। लेकिन बिट के निर्माण के दौरान यह कैसे होता है? क्या विभिन्न परतें उस डेटा को रखती हैं जो अंतिम बिट का एक हिस्सा होगा, जबकि वे स्वयं प्रासंगिक जानकारी इकट्ठा करने / कनेक्शन बनाने के लिए ईथरनेट पर प्रश्न / डेटा भेजते हैं, आदि? यह बिल्कुल कैसे काम करता है?

जब ओएसआई मॉडल, या टीसीपी / आईपी मॉडल पर चर्चा की जाती है, तो चीजें आम तौर पर डेटा अनुक्रमिक रूप से प्रस्तुत की जाती हैं और परतों को तब तक प्रवाहित किया जाता है जब तक कि इसे एक बिट के रूप में बाहर नहीं भेजा जाता है, लेकिन मैं अधिक विस्तृत विवरण नहीं पा सका हूं एक वेबसाइट से कनेक्ट करने के रूप में एक सरल उदाहरण में, प्रत्येक पहलू से जुड़े विवरण के रूप में।

Comments

मैं इस सवाल का जवाब देने के लिए किस स्तर पर निर्णय ले सकता हूं। मैं इस नतीजे पर पहुंच रहा हूं कि यह बहुत व्यापक है, जब तक कि मैं केवल इसकी सतह को कवर नहीं करता। सीधे शब्दों में कहें, तो आप कोडर के रूप में कुछ अनुभव के बिना परतों के वास्तविक कार्यान्वयन को समझ नहीं सकते हैं। सॉकेट्स एपीआई में देखें, क्योंकि यह आपको बेहतर समझ देगा। उदाहरण के लिए एक ऐप एक पोर्ट L4 बनाने के लिए सॉकेट्स सॉकेट () को कॉल करता है, और फिर उस पोर्ट को L3 सॉकेट से टाई करने के लिए सॉकेट्स.बाइंड () को कॉल करता है। इसके बाद रिमोट आईपी से कनेक्ट करने के लिए सॉकेट्स कनेक्ट करें ()। तब ऐप सिर्फ सॉकेट के माध्यम से आईओ धाराओं को पढ़ता और लिखता है।

— फ्रैंक थॉमस

@Frank आपको उत्तर के रूप में पोस्ट करना चाहिए। मुझे नहीं लगता कि यह इससे बेहतर हो सकता है।

— रयान बाबशिन

Answer 1

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

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

इसलिए, जैसा कि मैंने अपनी टिप्पणी में कहा था, अधिकांश आधुनिक ऐप बर्कले सॉकेट्स एपीआई मानक के एक संस्करण का उपयोग करते हैं । इस लाइब्रेरी में OSI API के लिए OSI परतों 7, 4, 3 और हुक पर काम करने वाले तरीके हैं।

1. एप्लिकेशन Sockets.Socket(type)एक नया पोर्ट बनाने के लिए कॉल करेगा , और नए पोर्ट नंबर वापस कर दिया जाएगा। यह एक लेयर 4 फ़ंक्शन है।

2. एप्लिकेशन ओएस से पूछेगा कि उसका आईपी पता क्या है, और फिर Sockets.Bind(newPort, localIPAddr, addrLen)नए सॉकेट को आईपी इंटरफेस में संलग्न करने के लिए कॉल करें । यह एक लेयर 3 फ़ंक्शन है।

3. आवेदन Sockets.Connect(newPort, remoteAddrandPort, addrlen)टीसीपी तीन तरह से हाथ मिलाने के माध्यम से एक कनेक्शन शुरू करने के लिए कॉल करेगा ।

4. यह सब पूरा होने के बाद, एप्लिकेशन सॉकेट को पढ़ने और लिखने के लिए Sockets.Send()और Sockets.Recv()कार्यों का उपयोग कर सकता है, हालांकि यह एक IO स्टीम था। आंतरिक रूप से, भेजें () / Recv () सॉकेट्स लाइब्रेरी के भीतर परिभाषित निजी तरीकों को कॉल करें जो प्रत्येक परत पर डेटा को एन्कैप करते हैं, पिछली संरचना के आउटपुट का उपयोग इनपुट के रूप में अगले निचले हिस्से तक करते हैं, जब तक कि यह स्थानीय आईपी स्टैक को भेजने के लिए नहीं कहता है। पैकेट। ज्यादातर मामलों में, एप्लिकेशन परत 3 के नीचे की किसी भी चीज के बारे में नहीं जानते हैं या उसकी देखभाल नहीं करते हैं, और जब वे लेयर 3 या 4 की देखभाल करते हैं, तो यह केवल मान्य पैरामीटर मान प्रदान करने के लिए होता है।

एप्लिकेशन प्रोटोकॉल कमांड अनुक्रमों के लिए भी जिम्मेदार है। उदाहरण के लिए, सुपरयुसर से कनेक्ट करने के लिए, एप्लिकेशन को HTTP कमांड अनुक्रम में संवाद करना होगा ।

यहाँ पर superuser.com पर डिफ़ॉल्ट पृष्ठ पुनः प्राप्त करने के लिए, ब्राउज़र अनुक्रम का निर्माण करेगा:

GET / \HTTP/1.1;

एप्लिकेशन बस उस स्ट्रिंग को पोर्ट पर लिख सकता है, और यह स्वचालित रूप से एक टीसीपी सेगमेंट, और एक आईपी पैकेट, और 802.11 एन फ्रेम में समझाया जाएगा, और हार्डवेयर द्वारा विद्युत सिग्नल में परिवर्तित हो जाएगा।

एप्लिकेशन नेटवर्क IO स्ट्रीम से पढ़ सकता है जैसे कि एक प्रतिक्रिया प्राप्त करने के लिए

200: <!DOCTYPE html> <html itemscope itemtype="http://schema.org/QAPage"> <head> <title>networking - What are the detailed OSI model....

ब्राउज़र तब 200 को हटा देता है (यह दर्शाता है कि HTTP कमांड ने काम किया है, और मार्कअप इस प्रकार है), और पेज को रेंडर करता है।

इसलिए, मैं इस जवाब से पूरी तरह से संतुष्ट नहीं हूं, क्योंकि इसके लिए मुझे नेटवर्किंग और कोडिंग दोनों में सालों-साल लगे और एक समग्र मानसिक तस्वीर मिली कि यह सब वास्तविकता में कैसे काम करता है (जैसा कि अत्यधिक सार OSI के विपरीत है) और मुझे पता है कि वहाँ कम से कम 3 अलग-अलग दृष्टिकोण हैं जो आप नेटवर्क कनेक्टिविटी को देख सकते हैं। इस मामले में सिग्नल प्रोसेसिंग सही है, और ऐसा लगता है कि आप नेटवर्किंग पेशेवरों के परिप्रेक्ष्य के बारे में पहले से ही सीख रहे हैं, इसलिए उम्मीद है कि यह परिप्रेक्ष्य आपकी समझ को समझने में मदद करेगा जहां सिद्धांत वास्तविकता से मिलता है।

संपादित करें:

ओह, और चूंकि आपने DNS का उल्लेख किया है, इसलिए अधिकांश अनुप्रयोग सॉक्स getaddrinfo / getnameinfo विधियों का उपयोग त्वरित dns क्वेरी करने के लिए करते हैं, इनपुट के रूप में FQDN लेते हैं। ये तरीके आंतरिक रूप से बनाते हैं, बाइंड (), कनेक्ट (), एक यूडीपी डेटाग्राम (नोट, डीएनएस हम आमतौर पर यूडीपी पर प्रदर्शन करते हैं, हालांकि अधिकांश सिस्टम टीसीपी का उपयोग करने के लिए कॉन्फ़िगर किए जा सकते हैं) और इसे भेजें, प्रतिक्रिया के लिए सुनें, इसे पार्स करें एक संरचना, और इसे सभी को एक कॉल के साथ आवेदन पर लौटा दें। यह बहुत साफ है। वास्तव में, अब जब मैं इसके बारे में सोचता हूं, तो इसका मतलब है कि एनकैप्सुलेशन का मतलब क्या है।

Answer 2

मैं आपके पहले पैराग्राफ की अनदेखी कर रहा हूं, जो उपयोगी था, क्योंकि ऐसा लगता है कि आप दूसरे पैराग्राफ में अधिक विशिष्ट प्राप्त करने की कोशिश कर रहे थे। तो वह पैराग्राफ है जिसका मैं विस्तार से उत्तर देता हूं।

लेकिन बिट के निर्माण के दौरान यह कैसे होता है?

आपने अगले प्रश्न के साथ अपना उत्तर प्रस्तावित किया।

क्या विभिन्न परतें उस डेटा को रखती हैं जो अंतिम बिट का एक हिस्सा होगा, जबकि वे स्वयं प्रासंगिक जानकारी इकट्ठा करने / कनेक्शन बनाने के लिए ईथरनेट पर प्रश्न / डेटा भेजते हैं, आदि?

हाँ।

यह बिल्कुल कैसे काम करता है?

उपयोगकर्ता ने वेब ब्राउज़र को बताया कि जानकारी किसी वेबसाइट से वांछित है। जैसा कि उपयोगकर्ता इस पते को पता बार में टाइप करता है, कोई नेटवर्किंग अभी तक शामिल नहीं है; OSI Model इसे OSI Model Layer 7: Application Layer मानता है।

वेब ब्राउज़र ने निर्दिष्ट किया कि एक असुरक्षित संचार ठीक है। (यदि सुरक्षा की आवश्यकता होती है, तो HTTPS किया गया होगा। हालाँकि, HTTP असुरक्षित संचार प्रदान करने के लिए काम करेगा।) इसलिए HTTP है कि संचार कैसे होना चाहिए (प्रस्तुति परत, परत 6, अभी भी आमतौर पर अनुप्रयोग द्वारा नियंत्रित किया जाता है)। HTTP ईबीसीडीईसी का उपयोग नहीं करता है; संचार ASCII (प्रेजेंटेशन लेयर, ओएसआई मॉडल लेयर 6. से संबंधित एक और विवरण) का उपयोग करेगा।

विश्वसनीय संचार होना चाहिए। हम एक सत्र का उपयोग करेंगे, इसलिए एक HTTP "कनेक्शन" पर बातचीत होगी जिसमें कई पैकेट शामिल हो सकते हैं। उस संबंध के विचार सत्र परत (OSI मॉडल परत 5) है

परिवहन संचार एक ही आईपी पते पर कई वार्तालापों (जैसे कई युगपत डेटा स्थानांतरण) की अनुमति देता है। जब कोई आवक या जावक डेटा होता है, तो इन वार्तालापों को कई "पोर्ट" नंबरों का उपयोग करके ट्रैक किया जाता है। वेब ब्राउज़र निर्दिष्ट करता है कि वह www.superuser.com टीसीपी पोर्ट 80 पर बातचीत करना चाहता है। पोर्ट नंबर निर्दिष्ट करना ट्रांसपोर्ट लेयर (OSI MOdel लेयर 4) के दायरे में आ रहा है।

एप्लिकेशन (वेब ​​ब्राउज़र) "टीसीपी / आईपी नेटवर्किंग स्टैक" के साथ संचार करता है, जिसे आम तौर पर ऑपरेटिंग सिस्टम में बनाया जाता है (इन दिनों ... विंडोज 3.1 के दिनों में, आपको "ट्रम्पेट विनसॉक" स्थापित करने की आवश्यकता हो सकती है, एक) थर्ड पार्टी स्टैक, या Microsoft के स्टैक का उपयोग करें जो Win 3.1 के लिए एमएस इंटरनेट एक्सप्लोरर के साथ स्थापित किया जा सकता है)।

नेटवर्किंग स्टैक को पता चलता है कि "www.superuser.com" एक नेटवर्क नाम है। इसलिए "रिज़ॉल्वर" कोड का उपयोग किया जाता है। यह नाम "नाम समाधान" ("रिज़ॉल्वर") कैश में नहीं है, और इसे "होस्ट फ़ाइल" में देखने की कोशिश करने से नाम प्रकट नहीं होता है। तो एक DNS क्वेरी भेजी जाएगी।

आह, हाँ, आपके प्रश्न ने "http" और "DNS" का संदर्भ दिया, इसलिए यह उत्तर DNS संचार और HTTP संचार दोनों को देखकर थोड़ा और जटिल हो जाता है। हम DNS संचार को पहले देखेंगे, क्योंकि, OSI मॉडल लेयर 3 का किसी भी HTTP ट्रैफ़िक से कोई लेना-देना नहीं है, ठीक है।

रिज़ॉल्वर DNS संचार बनाने की प्रक्रिया शुरू करता है। कंप्यूटर DNS डेटाग्राम (UDP पोर्ट 53, ट्रांसपोर्ट लेयर, लेयर 4) के रूप में प्रतिक्रिया प्राप्त करने जा रहा है।

DNS सर्वर कंप्यूटर पर है। हम ऐसा दिखावा करेंगे जैसे यह एक दूरस्थ कंप्यूटर पर है। तो यह एक अलग कंप्यूटर के आईपी पते के साथ संचार को शामिल करने जा रहा है। तो एक आईपी पैकेट का इस्तेमाल होने वाला है (वह है नेटवर्क लेयर, OSI मॉडल लेयर 3)। बस मज़े के लिए, मान लें कि यह एक IPv4 पैकेट है (कोई कारण नहीं)। (वास्तव में, मैंने इसे IPv6 के रूप में लिखना शुरू किया ... मैंने छोटे नमूना पते के लिए IPv4 को वापस करने का फैसला किया। लेकिन इसके बजाय IPv6 किया जा सकता है।)

आइए दिखाते हैं जैसे कंप्यूटर एक राउटर है। लेयर 3 आईपी पते के आधार पर, हम उस मार्ग को नहीं लेना चाहते हैं जो यातायात को किशोरी के बेडरूम तक ऊपर भेजेगा। हम एक मार्ग लेना चाहते हैं जो इंटरनेट पर जाएगा। यह IPv4 पैकेट वायरलेस नेटवर्क या वायर्ड नेटवर्क पर भेजा जा सकता है। हम IPv4 पते का उपयोग करना चुनेंगे जो वायर्ड नेटवर्क का उपयोग करता है।

चूंकि DNS सर्वर एक अलग सबनेट पर है, इसलिए हमें ट्रैफ़िक को एक गेटवे पर भेजना होगा। चूँकि मेरे पास अधिक विशिष्ट मार्ग नहीं है (उदाहरण के लिए, किशोरी के शयनकक्ष में), मैं एक "डिफ़ॉल्ट गेटवे" का उपयोग करूँगा जिसका उपयोग तब किया जाता है जब कोई अधिक विशिष्ट विकल्प उपलब्ध नहीं होता है। यह जानने के लिए कि यातायात भेजने का कौन सा तरीका "रूटिंग" है, लेयर 3 की प्रमुख विशेषता है।

मान लीजिए कि वायर्ड नेटवर्क का उपयोग इस संचार के लिए किया जाएगा। IP पैकेट को DNS सर्वर (8.8.8.8, लेयर 3) तक पहुंचने की आवश्यकता है, लेकिन राउटिंग टेबल इंगित करता है कि इस तरह के कम्यूनिकेशंस गेटवे एड्रेस से 198.51.100.1 (लेयर 3) पर रूट किए जाते हैं। (वैसे, 198.51.100.1 कुछ ऐसा नहीं है जिसे आपको वास्तविक नेटवर्क पर उपयोग करना चाहिए, लेकिन मुझे इस उदाहरण के लिए इसका उपयोग करने की अनुमति है, क्योंकि मैं RFC 5737 अनुभाग 3 का अनुसरण कर रहा हूं

हम ईथरनेट फ्रेम का उपयोग करके 198.51.100.1 पर संवाद कर सकते हैं। ARP कैश (IPv4 का IPv6 के NDP के समतुल्य) में विवरण नहीं है, इसलिए हमें पता लगाने के लिए ARP WHO-HAS फ्रेम (IPv6 की पड़ोसी खोज के बराबर) की आवश्यकता होगी ताकि ईथरनेट फ्रेम को भेजा जाए। यह पड़ोसी खोज ईथरनेट प्रसारण को एफएफ-एफएफ-एफएफ-एफएफ-एफएफ-एफएफ-एफएफ (आईपीवी 6 मल्टीकास्ट को एनडीपी के हिस्से के रूप में इस्तेमाल कर सकती है) को पता लगाने के लिए भेजती है कि उस ईथरनेट पता किसके पास है। जब कोई प्रतिक्रिया वापस ली जाती है, तो जानकारी कैश में चली जाती है (एआरपी कैश ... अगर हम आईपीवी 6 का उपयोग कर रहे थे, तो यह एनडीपी कैश होगा)।

अब हम सिस्टम में एक ईथरनेट फ्रेम भेज सकते हैं जो 192.168.0.1 पर है। तो "टीसीपी / आईपी नेटवर्किंग स्टैक" यूडीपी डेटाग्राम को एक आईपी पैकेट में रखता है जो 8.8.8.8 के आईपी पते पर जाएगा, और इसे एक ईथरनेट फ्रेम में इनकैप करता है जो 01-23-45-67-89- एबी को जाता है । उस ईथरनेट फ्रेम को लेयर 2 पर भेजा जाता है।

टीसीपी / आईपी नेटवर्किंग स्टैक नेटवर्क कार्ड ड्राइवर (जो ईथरनेट के साथ संवाद कर सकता है) के साथ संचार करके परत 2 पर उस ईथरनेट फ्रेम को भेजता है। हालाँकि, TCP / IP नेटवर्किंग स्टैक उस UDP डेटाग्राम में बिट्स के बारे में भूल जाता है। आखिरकार, यूडीपी अविश्वसनीय है। टीसीपी / आईपी नेटवर्क स्टैक HTTP अनुरोध के साथ नहीं किया गया है, क्योंकि "रिज़ॉल्वर" अभी भी निवर्तमान यूडीपी पैकेट के "स्रोत" नेटवर्क पते के आधार पर प्रतिक्रिया की प्रतीक्षा कर रहा है। लेकिन टीसीपी / आईपी नेटवर्किंग स्टैक उन बिट्स की एक प्रति नहीं रखता है जो उस यूडीपी डेटाग्राम में अविश्वसनीय रूप से भेजे गए थे। (यदि यूडीपी डेटाग्राम खो जाता है, तो मेरा मानना ​​है कि "रिसॉल्वर" शायद विफल हो जाएगा, और फिर वेब ब्राउज़र को फिर से प्रयास करना पड़ सकता है। वैसे भी, "रिट्री" भाग को यूडीपी डेटाग्राम की देखभाल के अविश्वसनीय हिस्से द्वारा नियंत्रित नहीं किया जाता है। )

ईथरनेट ड्राइवर पैकेट पर लटकता है, यह सुनिश्चित करने के लिए कि पैकेट OSI मॉडल लेयर पर किसी भी ईथरनेट टकराव से दूषित नहीं होता है। एक बार ईथरनेट समस्या के बिना प्रसारित होने के बाद, नेटवर्क ड्राइवर इसके बारे में भूल जाता है।

डिफ़ॉल्ट गेटवे ईथरनेट फ्रेम प्राप्त करता है। चूँकि यह एक राउटर है, यह ट्रैफ़िक को आगे बढ़ाता है, जिसका अर्थ है कि इसे IP पैकेट पर थोड़ा देखने की आवश्यकता है जो स्वयं को संबोधित नहीं है। मैं इसे "होनहार" मानता हूं। राउटर यह देखने के लिए जाँच करता है कि ट्रैफ़िक कहाँ जाना चाहिए, और ट्रैफ़िक को दूसरे राउटर में लाने के लिए इसी तरह की प्रक्रिया का अनुसरण करता है। TTL 1 से कम होने पर IP पैकेट संशोधित हो जाता है, और राउटर Layer 2 का उपयोग करके अगले राउटर पर ट्रैफ़िक प्राप्त करता है। यह प्रक्रिया आवश्यक के रूप में कई राउटर्स के माध्यम से दोहराती है, और जब तक कि टीटीएल स्तर कम करने के लिए ठीक काम नहीं करना चाहिए, जिस स्थिति में एक आईसीएमपी "टीटीएल से अधिक" उत्तर वापस आ जाएगा। सादगी के लिए, इस उदाहरण के बाकी ऐसे बहाना करेंगे जैसे कि ऐसा नहीं हुआ।

बाद में, शायद हजारों मिलीसेकंड के बाद जो सीपीयू समय के लाखों मेगाहर्ट्ज़ लेते हैं, नेटवर्क चालक (कंप्यूटर पर वेब ब्राउज़र के साथ) एक ईथरनेट संचार को नोटिस करता है। उस ईथरनेट फ्रेम में एक डेस्टिनेशन मैक एड्रेस (OSI Model Layer 2) होता है जो वेब ब्राउजर वाले इस कंप्यूटर से संबंधित होता है। फ़्रेम में एक प्रोटोकॉल फ़ील्ड है जो कहता है कि यह एक आईपी पैकेट है; विशेष रूप से "आईपी पैकेट" शब्द एक पुराने मानक से है, और इसका अर्थ है आईपीवी 4 पैकेट (ओएसआई मॉडल लेयर 3)। चूंकि गंतव्य पता इस कंप्यूटर से मेल खाता है, इसलिए कंप्यूटर को यह जांचने की आवश्यकता नहीं है कि "प्रोमिसस मोड" में कोई सॉफ़्टवेयर चल रहा है या नहीं। इसलिए नेटवर्क ड्राइवर इसे टीसीपी / आईपी नेटवर्किंग स्टैक पर भेजता है। IP पैकेट DNS सर्वर से एक UDP डेटाग्राम (OSI मॉडल लेयर 4) युक्त होता है। तो टीसीपी / आईपी नेटवर्किंग स्टैक खुले बंदरगाहों की सूची की जांच करता है (जिसे आप यूनिक्स या माइक्रोसॉफ्ट विंडोज में "नेटस्टैट-एनएनए" चलाकर देख सकते हैं)। खुले बंदरगाहों की सूची "लिस्टेनिंग" पोर्ट के लिए जाँच की जाती है, और यह पता चलता है कि रिज़ॉल्वर द्वारा प्रतिक्रिया देखी जा रही है। तो टीसीपी / आईपी नेटवर्किंग स्टैक इस यूडीपी डेटाग्राम को रिसॉल्वर को भेजता है।

अब जबकि रिसॉल्वर ने यह पता लगा लिया है कि www.superuser.com 203.0.113.50 है (उदाहरण के लिए, RFC 5737 सेक्शन 3 की अनुमति), टीसीपी / आईपी नेटवर्किंग स्टैक टीसीपी सेगमेंट बनाने के लिए स्वतंत्र महसूस कर सकता है जिसमें एक आईपी पैकेट होगा जो 203.0.113.50 पर जाता है। बातचीत के पहले आईपी पैकेट में वास्तव में कोई दिलचस्प पेलोड नहीं होता है, और यह 3-तरह से टीसीपी हैंडशेक का हिस्सा है। एक उत्तर के बाद, टीसीपी / आईपी नेटवर्किंग स्टैक का टीसीपी-हैंडलिंग हिस्सा आईपी पैकेट के अंदर एक टीसीपी सेगमेंट भेजेगा। प्रक्रिया बहुत हद तक UDP डेटाग्राम की हैंडलिंग के समान है, सिवाय इसके कि जब टीसीपी / आईपी नेटवर्किंग स्टैक टीसीपी सेगमेंट वाले आईपी पैकेट लेता है और उन पैकेटों को नेटवर्क ड्राइवर (ईथरनेट फ्रेम को संभालने के लिए), टीसीपी / को भेजता है। आईपी ​​नेटवर्किंग स्टैक उस टीसीपी पैकेट की पूरी सामग्री को याद रखेगा, जब तक कि पैकेट को एक उत्तर टीसीपी सेगमेंट में स्वीकार नहीं किया जाता है। यदि पारगमन में टीसीपी पैकेट खो जाता है, अंत में दूरस्थ अंत में शिकायत होगी या एक समाप्ति टाइमर पूरा हो जाएगा, और टीसीपी / आईपी पैकेट आवश्यक पेलोड की डुप्लिकेट प्रति के साथ एक और टीसीपी खंड भेज देगा। "पुनः प्रयास" करने का यह प्रयास है कि टीसीपी को "विश्वसनीय" क्यों कहा जाता है।

इस बार, DNS ट्रैफ़िक वाले UDP डेटाग्राम के लिए प्रतीक्षा करने के बजाय, जो रिसोल्वर को भेजा जाता है, TCP / IP नेटवर्किंग स्टैक TCP उत्तर की प्रतीक्षा करता है। कुछ यादृच्छिक पोर्ट, जैसे पोर्ट 12345, प्रारंभिक अनुरोध के "स्रोत पोर्ट" के रूप में उपयोग किया जाता है।

आउटगोइंग टीसीपी सेगमेंट में "GET" अनुरोध शामिल है जो वेब ब्राउज़र द्वारा भेजे गए HTTP संचार का हिस्सा है।

अब, आइपी पैकेट (और ईथरनेट फ्रेम) की हैंडलिंग के माध्यम से तेजी से आगे बढ़ते हैं।

वेबसर्वर द्वारा अनुरोध प्राप्त होने के बाद, वेबसर्वर वेब ब्राउज़र को डेटा भेजेगा। यह कई टीसीपी सेगमेंट के रूप में हो सकता है। वेब सर्वर उस प्रत्येक टीसीपी सेगमेंट की सामग्री को याद रखता है, जो तब तक भेजता है, जब तक कि टीसीपी सेगमेंट उस वेब ब्राउज़र को चलाने वाले कंप्यूटर द्वारा स्वीकार नहीं कर लेता।

जैसा कि वेब ब्राउज़र वाले कंप्यूटर को वेब सर्वर से जानकारी मिलती है, यह ईथरनेट फ्रेम (OSI Layer 2) को नोटिस करता है, जिसमें IP पैकेट (OSI Layer 3) होते हैं जिनमें TCP सेगमेंट (OSI Layer 4) होते हैं जो TCP पोर्ट 80 (पर) से आते हैं। वेब ब्राउज़र) स्थानीय टीसीपी पोर्ट को सुन रहा है (उदाहरण के लिए, 12345, पहले बताया गया है)। टीसीपी / आईपी नेटवर्किंग स्टैक को एहसास होगा कि वेब ब्राउज़र में जाना चाहिए।

वेब ब्राउज़र कनेक्शन से जानकारी संसाधित करता है (लेयर 5, सत्र), यह महसूस करता है कि ट्रैफ़िक अनएन्क्रिप्टेड (लेयर 6, प्रेजेंटेशन) है, और पता बार को लाल नहीं बनाता है (जैसे कि अगर HTTPS सुरक्षा के साथ कोई समस्या थी) । एड्रेस बार के रंग पर निर्णय लेना एक "यूजर इंटरफेस" मुद्दा है, जिसे 7-लेयर OSI मॉडल के लेयर 7 का हिस्सा माना जाता है।

Comments

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

— हम्मीर