सिस्को ट्रेनिंग 200-125 CCNA v3.0. दिवस 6: रिक्त जागा भरणे (DHCP, TCP, हँडशेक, सामान्य पोर्ट क्रमांक)

आजचे व्हिडिओ ट्यूटोरियल सुरू करण्यापूर्वी, मी YouTube वर माझ्या कोर्सच्या लोकप्रियतेसाठी योगदान दिलेल्या प्रत्येकाचे आभार मानू इच्छितो. जेव्हा मी हे सुमारे 8 महिन्यांपूर्वी सुरू केले तेव्हा मला अशा यशाची अपेक्षा नव्हती - आज माझे धडे 312724 लोकांनी पाहिले आहेत, माझे 11208 सदस्य आहेत. ही विनम्र सुरुवात एवढ्या उंचीवर पोहोचेल असे स्वप्नातही वाटले नव्हते. पण वेळ वाया घालवू नका आणि थेट आजच्या धड्याकडे जाऊया. आज आपण शेवटच्या 7 व्हिडिओ धड्यांमधील अंतर भरून काढू. आजचा दिवस 6वा असला तरी, दिवस 3 3 व्हिडिओ धड्यांमध्ये मोडला गेला आहे, त्यामुळे आज तुम्ही आठवा व्हिडिओ धडा प्रत्यक्षात पाहाल.

आज आम्ही 3 महत्त्वाचे विषय कव्हर करणार आहोत: DHCP, TCP वाहतूक आणि सर्वात सामान्य पोर्ट क्रमांक. आम्ही आधीच IP पत्त्यांबद्दल बोललो आहोत, आणि IP पत्ता कॉन्फिगरेशनमधील सर्वात महत्त्वाचा घटक म्हणजे DHCP.

DHCP म्हणजे डायनॅमिक होस्ट कॉन्फिगरेशन प्रोटोकॉल आणि हा एक प्रोटोकॉल आहे जो होस्टसाठी डायनॅमिकली IP पत्ते कॉन्फिगर करण्यात मदत करतो. तर आपण सर्वांनी ही विंडो पाहिली आहे. जेव्हा तुम्ही "स्वयंचलितपणे IP पत्ता मिळवा" पर्यायावर क्लिक करता, तेव्हा संगणक त्याच सबनेटवर कॉन्फिगर केलेला DHCP सर्व्हर शोधतो आणि IP पत्त्यासाठी विविध पॅकेट आणि विनंत्या पाठवतो. DHCP प्रोटोकॉलमध्ये 6 संदेश आहेत, त्यापैकी 4 IP पत्ता नियुक्त करण्यासाठी महत्त्वपूर्ण आहेत.

पहिला संदेश DHCP डिस्कवरी संदेश आहे. DHCP शोध संदेश शुभेच्छा संदेशासारखाच आहे. जेव्हा एखादे नवीन उपकरण नेटवर्कमध्ये सामील होते, तेव्हा ते नेटवर्कवर DHCP सर्व्हर आहे का ते विचारते.

तुम्ही स्लाइडमध्ये जे पाहता ते ब्रॉडकास्ट विनंतीसारखे दिसते जेथे डिव्हाइस नेटवर्कवरील सर्व डिव्हाइसेसशी संपर्क साधते जे DHCP सर्व्हर शोधत आहेत. मी म्हटल्याप्रमाणे, ही एक प्रसारण विनंती आहे, त्यामुळे नेटवर्कवरील सर्व उपकरणे ती ऐकू शकतात.

नेटवर्कवर DHCP सर्व्हर असल्यास, ते एक पॅकेट पाठवते - DHCP ऑफर ऑफर. प्रस्तावाचा अर्थ असा आहे की DHCP सर्व्हर, शोध विनंतीला प्रतिसाद म्हणून, क्लायंटला एक कॉन्फिगरेशन पाठवते, क्लायंटला विशिष्ट IP पत्ता स्वीकारण्यास सांगते.

DHCP सर्व्हर एक IP पत्ता राखून ठेवतो, या प्रकरणात 192.168.1.2, तो प्रदान करत नाही, उलट हा पत्ता डिव्हाइससाठी राखून ठेवतो. त्याच वेळी, ऑफर पॅकेजमध्ये DHCP सर्व्हरचा स्वतःचा IP पत्ता असतो.

या नेटवर्कवर एकापेक्षा जास्त DHCP सर्व्हर असल्यास, दुसरा DHCP सर्व्हर, क्लायंटची ब्रॉडकास्ट विनंती प्राप्त केल्यानंतर, त्याचा IP पत्ता देखील देऊ करेल, उदाहरणार्थ, 192.168.1.50. एकाच नेटवर्कवर दोन भिन्न DHCP सर्व्हर कॉन्फिगर करणे सामान्य नाही, परंतु कधीकधी असे घडते. त्यामुळे जेव्हा क्लायंटला DHCP ऑफर पाठवली जाते, तेव्हा त्याला 2 DHCP ऑफर मिळतात आणि आता त्याला कोणती DHCP ऑफर स्वीकारायची आहे हे ठरवावे लागेल.

क्लायंटने पहिला अर्ज स्वीकारला असे गृहीत धरू. याचा अर्थ असा की क्लायंट DHCP REQUEST विनंती पाठवतो ज्यामध्ये अक्षरशः "मी DHCP सर्व्हर 192.168.1.2 द्वारे ऑफर केलेला IP पत्ता 192.168.1.1 स्वीकारतो."

विनंती प्राप्त झाल्यावर, 192.168.1.1 DHCP सर्व्हर “ठीक आहे, मी कबूल करतो” असे प्रतिसाद देतो, म्हणजेच तो विनंती मान्य करतो आणि क्लायंटला हा DHCP ACK पाठवतो. परंतु आम्हाला आठवते की दुसऱ्या DHCP सर्व्हरने क्लायंटसाठी 1.50 चा IP पत्ता राखून ठेवला आहे. एकदा त्याला क्लायंटची ब्रॉडकास्ट विनंती प्राप्त झाली की, त्याला अयशस्वी झाल्याबद्दल कळेल आणि तो IP पत्ता पुन्हा पूलमध्ये टाकला जाईल जेणेकरुन त्याला दुसरी विनंती प्राप्त झाल्यास तो दुसऱ्या क्लायंटला नियुक्त करू शकेल.

हे 4 गंभीर संदेश आहेत जे DHCP IP पत्ते नियुक्त करताना एक्सचेंज करते. पुढे, DHCP कडे आणखी 2 माहिती संदेश आहेत. क्लायंटला दुसऱ्या चरणात DHCP ऑफर क्लॉजमध्ये मिळालेल्या माहितीपेक्षा अधिक माहिती हवी असल्यास माहिती संदेश जारी केला जातो. जर सर्व्हरने DHCP ऑफरमध्ये पुरेशी माहिती दिली नसेल किंवा क्लायंटला ऑफर पॅकेटमध्ये असलेल्या माहितीपेक्षा अधिक माहिती हवी असेल, तर तो अतिरिक्त DHCP माहितीची विनंती करतो. क्लायंट सर्व्हरला पाठवणारा आणखी एक संदेश आहे - हा DHCP रिलीझ आहे. हे तुम्हाला सूचित करते की क्लायंटला त्याचा विद्यमान IP पत्ता सोडायचा आहे.

तथापि, बहुतेकदा असे होते की क्लायंटला सर्व्हरवर DHCP रिलीझ पाठवण्याची वेळ येण्यापूर्वी वापरकर्ता नेटवर्कवरून डिस्कनेक्ट होतो. जेव्हा आपण संगणक बंद करता तेव्हा असे होते, जे आम्ही करतो. या प्रकरणात, नेटवर्क क्लायंट, किंवा संगणकाकडे, वापरलेला पत्ता सोडण्यासाठी सर्व्हरला सूचित करण्यासाठी फक्त वेळ नाही, म्हणून DHCP रिलीझ ही आवश्यक पायरी नाही. IP पत्ता प्राप्त करण्यासाठी आवश्यक पायऱ्या आहेत: DHCP शोध, DHCP ऑफर, DHCP विनंती आणि DHCP हँडशेक.

पुढील धड्यांपैकी एकामध्ये मी तुम्हाला DNCP पूल तयार करताना DHCP सर्व्हर कसा कॉन्फिगर करतो ते सांगेन. पूलिंग करून आमचा अर्थ असा आहे की तुम्ही सर्व्हरला 192.168.1.1 ते 192.168.1.254 या श्रेणीतील IP पत्ते नियुक्त करण्यास सांगता. अशा प्रकारे, DHCP सर्व्हर एक पूल तयार करेल, त्यात 254 IP पत्ते ठेवेल आणि फक्त या पूलमधून नेटवर्कवरील क्लायंटना पत्ते नियुक्त करण्यास सक्षम असेल. तर हे प्रशासकीय सेटिंगसारखे काहीतरी आहे जे वापरकर्ता करू शकतो.

आता TCP ट्रांसमिशन पाहू. मला माहित नाही की तुम्ही चित्रात दाखवलेल्या "टेलिफोन"शी परिचित आहात की नाही, परंतु आम्ही लहान असताना एकमेकांशी बोलण्यासाठी स्ट्रिंगने जोडलेले हे टिनचे डबे वापरायचो.

दुर्दैवाने, आजच्या पिढीला अशी “लक्झरी” परवडत नाही. म्हणजे आजची मुलं वयाच्या एका वर्षापासून टीव्हीसमोर असतात, ते PSP खेळतात आणि कदाचित हे वादातीत आहे पण मला वाटतं की आमचं बालपण उत्तम होतं, आम्ही खरं तर बाहेर जाऊन खेळ खेळलो आणि आजच्या मुलांना सोफ्यापासून दूर खेचता येत नाही. .

माझा मुलगा फक्त एक वर्षाचा आहे आणि मी आधीच पाहू शकतो की त्याला आयपॅडचे व्यसन आहे, म्हणजे तो अजूनही खूप लहान आहे परंतु मला वाटते की आजची मुले इलेक्ट्रॉनिक गॅझेट्स कशी हाताळायची हे आधीच जाणून घेतात. म्हणून, मला असे म्हणायचे होते की लहान मुले म्हणून आपण खेळत असताना टिनच्या डब्यात छिद्रे पाडायचो आणि जेव्हा आपण त्यांना दोरीने बांधून एका डब्यात काहीतरी म्हटलो तर दुसऱ्या टोकाला त्या व्यक्तीला काय बोलले जात आहे ते ऐकू येईल. त्याला, फक्त त्याच्या कानाला कॅन लावून. त्यामुळे ते नेटवर्क कनेक्शनसारखेच आहे.

आज, TCP हस्तांतरणामध्ये देखील कनेक्शन असणे आवश्यक आहे जे वास्तविक डेटा हस्तांतरण सुरू होण्यापूर्वी स्थापित करणे आवश्यक आहे. आपण मागील धड्यांमध्ये चर्चा केल्याप्रमाणे, TCP हे कनेक्शन-ओरिएंटेड ट्रान्समिशन आहे तर UDP हे कनेक्शन-ओरिएंटेड ट्रान्समिशन आहे. तुम्ही असे म्हणू शकता की UDP जिथे मी बॉल टाकतो आणि तुम्ही तो पकडू शकता की नाही हे पाहणे तुमच्यावर अवलंबून आहे. तू ते करायला तयार आहेस की नाही हा माझा प्रश्न नाही, मी फक्त त्याला सोडणार आहे.

TCP हे असे आहे की तुम्ही एखाद्या मुलाशी बोलत आहात आणि त्याला आगाऊ चेतावणी दिली आहे की तुम्ही बॉल फेकणार आहात, त्यामुळे तुम्ही एक बाँड तयार कराल आणि नंतर तुम्ही बॉल फेकता जेणेकरून तुमचा पार्टनर तो पकडण्यासाठी तयार होण्याची शक्यता जास्त असते. त्यामुळे TCP प्रत्यक्षात कनेक्शन बनवते आणि नंतर प्रत्यक्ष ट्रान्समिशन सुरू करते.

हे असे कनेक्शन कसे तयार करते ते पाहूया. कनेक्शन तयार करण्यासाठी हा प्रोटोकॉल 3-वे हँडशेक वापरतो. ही फारशी तांत्रिक संज्ञा नाही, परंतु ती TCP कनेक्शनचे वर्णन करण्यासाठी फार पूर्वीपासून वापरली जात आहे. क्लायंट सर्व्हरला SYN ध्वज असलेले पॅकेट पाठवताना पाठवणाऱ्या यंत्राद्वारे 3-वे हँडशेक सुरू केला जातो.

आपण म्हणू या की अग्रभागी असलेली मुलगी, जिचा चेहरा आपण पाहू शकतो, हे डिव्हाइस A आहे आणि पार्श्वभूमीतील मुलगी, जिचा चेहरा दिसत नाही, हे डिव्हाइस B आहे. मुलगी A मुलीला B ला SYN पॅकेट पाठवते आणि ती म्हणते: "उत्तम, कोण- मग त्याला माझ्याशी संवाद साधायचा आहे. तर, मला उत्तर द्यावे लागेल की मी संवाद साधण्यास तयार आहे!” ते कसे करायचे? एखादे दुसरे SYN पॅकेट आणि नंतर मूळ SYN पॅकेटची पावती दर्शविणारी ACK परत पाठवू शकते. परंतु स्वतंत्रपणे ACK पाठवण्याऐवजी, सर्व्हर SYN आणि ACK असलेले एक सामान्य पॅकेट तयार करतो आणि नेटवर्कवर प्रसारित करतो.

त्यामुळे या टप्प्यावर, डिव्हाइस A ने SYN पॅकेट पाठवले आहे आणि SYN/ACK पॅकेट परत प्राप्त केले आहे. आता डिव्हाइस A ने डिव्हाइस B ला एक ACK पॅकेट पाठवणे आवश्यक आहे, म्हणजेच संप्रेषण प्रस्थापित करण्यासाठी डिव्हाइस B कडून संमती मिळाली आहे याची पुष्टी करा. अशा प्रकारे, दोन्ही उपकरणांना SYN आणि ACK पॅकेट्स प्राप्त झाले आणि आता आम्ही असे म्हणू शकतो की कनेक्शन स्थापित केले गेले आहे, म्हणजेच, TCP प्रोटोकॉल वापरून 3-स्टेज हँडशेक पूर्ण झाले आहे.

पुढे आपण TCP विंडोिंग तंत्रज्ञान पाहू. सोप्या भाषेत सांगायचे तर, ही एक पद्धत आहे जी TCP/IP मध्ये प्रेषक आणि प्राप्तकर्त्याच्या क्षमतांची वाटाघाटी करण्यासाठी वापरली जाते.

समजा विंडोजमध्ये आम्ही एक मोठी फाईल, 2 जीबी आकाराची, एका ड्राइव्हवरून दुसऱ्या ड्राइव्हवर स्थानांतरित करण्याचा प्रयत्न करीत आहोत. हस्तांतरणाच्या अगदी सुरुवातीला, सिस्टम आम्हाला सूचित करेल की फाइल हस्तांतरणास अंदाजे 1 वर्ष लागेल. परंतु काही सेकंदांनंतर सिस्टम स्वतःला दुरुस्त करेल आणि म्हणेल: "अरे, एक मिनिट थांबा, मला वाटते की यास एक वर्ष नव्हे तर सुमारे 6 महिने लागतील." आणखी थोडा वेळ जाईल आणि Windows म्हणेल: "मला वाटते की मी 1 महिन्यात फाइल हस्तांतरित करू शकेन." यानंतर “1 दिवस”, “6 तास”, “3 तास”, “1 तास”, “20 मिनिटे”, “10 मिनिटे”, “3 मिनिटे” असा संदेश येईल. खरं तर, संपूर्ण फाइल हस्तांतरण प्रक्रियेस फक्त 3 मिनिटे लागतील. हे कसे घडले? सुरुवातीला, जेव्हा तुमचे डिव्हाइस दुसऱ्या डिव्हाइसशी संवाद साधण्याचा प्रयत्न करते, तेव्हा ते एक पॅकेट पाठवते आणि पुष्टीकरणाची प्रतीक्षा करते. जर डिव्हाइस पुष्टीकरणासाठी बराच वेळ वाट पाहत असेल, तर ते विचार करते: "जर मला या वेगाने 2 GB डेटा हस्तांतरित करायचा असेल तर त्याला सुमारे 2 वर्षे लागतील." काही काळानंतर, तुमच्या डिव्हाइसला ACK प्राप्त होतो आणि विचार करतो, “ठीक आहे, मी एक पॅकेट पाठवले आणि एक ACK प्राप्त केला, म्हणून प्राप्तकर्ता 1 पॅकेट प्राप्त करू शकतो. आता मी त्याला एका ऐवजी 10 पॅकेट पाठवण्याचा प्रयत्न करेन. प्रेषक 10 पॅकेट पाठवतो आणि काही काळानंतर प्राप्तकर्त्याकडून ACK पुष्टीकरण प्राप्त होते, याचा अर्थ प्राप्तकर्ता पुढील 11 व्या पॅकेटची वाट पाहत आहे. प्रेषक विचार करतो: "छान, प्राप्तकर्त्याने एकाच वेळी 10 पॅकेट हाताळल्यापासून, आता मी त्याला दहा ऐवजी 100 पॅकेट पाठवण्याचा प्रयत्न करेन." तो 100 पॅकेट पाठवतो, आणि प्राप्तकर्ता प्रतिसाद देतो की त्याला ती मिळाली आणि आता 101 पॅकेटची वाट पाहत आहे. अशा प्रकारे, कालांतराने, प्रसारित पॅकेट्सची संख्या वाढते.

यामुळेच तुम्हाला फाइल कॉपी वेळेत मूलत: सांगितलेल्या तुलनेत झपाट्याने घट झालेली दिसते - हे मोठ्या प्रमाणात डेटा हस्तांतरित करण्याची क्षमता वाढल्यामुळे आहे. तथापि, एक मुद्दा येतो जेव्हा ट्रान्समिशन व्हॉल्यूममध्ये आणखी वाढ करणे अशक्य होते. समजा तुम्ही 10000 पॅकेट पाठवले आहेत, परंतु प्राप्तकर्त्याचे डिव्हाइस बफर केवळ 9000 स्वीकारू शकतात या प्रकरणात, प्राप्तकर्ता संदेशासह ACK पाठवतो: "मला 9000 पॅकेट मिळाले आहेत आणि आता मी 9001 प्राप्त करण्यास तयार आहे." यावरून, प्रेषकाने असा निष्कर्ष काढला की प्राप्त करणाऱ्या उपकरणाच्या बफरची क्षमता फक्त 9000 आहे, याचा अर्थ असा की आतापासून मी एका वेळी 9000 पेक्षा जास्त पॅकेट पाठवणार नाही. या प्रकरणात, प्रेषक 9000 पॅकेट्सच्या भागांमध्ये उर्वरित डेटा हस्तांतरित करण्यासाठी लागणारा वेळ पटकन मोजतो आणि 3 मिनिटे देतो. ही तीन मिनिटे प्रत्यक्ष प्रसारण वेळ आहेत. TCP Windowing हेच करते.

ही त्या ट्रॅफिक थ्रॉटलिंग यंत्रणेपैकी एक आहे जिथे पाठवणारे उपकरण अखेरीस वास्तविक नेटवर्क क्षमता काय आहे हे समजते. तुम्ही विचार करत असाल की रिसीव्हिंग डिव्हाईसची क्षमता काय आहे यावर ते आधीच सहमत का होऊ शकत नाहीत? वस्तुस्थिती अशी आहे की हे तांत्रिकदृष्ट्या अशक्य आहे कारण नेटवर्कवर विविध प्रकारचे डिव्हाइसेस आहेत. समजा तुमच्याकडे आयपॅड आहे आणि त्यात आयफोनपेक्षा वेगळा डेटा ट्रान्सफर/रिसीव्हर स्पीड आहे, तुमच्याकडे वेगवेगळ्या प्रकारचे फोन असू शकतात किंवा तुमच्याकडे खूप जुना संगणक असू शकतो. त्यामुळे प्रत्येकाची नेटवर्क बँडविड्थ वेगवेगळी असते.

म्हणूनच टीसीपी विंडोिंग तंत्रज्ञान विकसित केले गेले आहे, जेव्हा डेटा ट्रान्समिशन कमी वेगाने सुरू होते किंवा कमीतकमी पॅकेट्सच्या प्रेषणासह, हळूहळू "विंडो" रहदारी वाढते. तुम्ही एक पॅकेट, 5 पॅकेट्स, 10 पॅकेट्स, 1000 पॅकेट्स, 10000 पॅकेट्स पाठवा आणि "ओपनिंग" ठराविक कालावधीत पाठवलेल्या रहदारीच्या जास्तीत जास्त संभाव्य व्हॉल्यूमपर्यंत पोहोचेपर्यंत हळूहळू ती विंडो अधिकाधिक उघडा. अशा प्रकारे, विंडोिंगची संकल्पना टीसीपी प्रोटोकॉलच्या ऑपरेशनचा एक भाग आहे.

पुढे आपण सर्वात सामान्य पोर्ट क्रमांक पाहू. तुमच्याकडे 1 मुख्य सर्व्हर, कदाचित डेटा सेंटर असते तेव्हा क्लासिक परिस्थिती असते. यात फाइल सर्व्हर, वेब सर्व्हर, मेल सर्व्हर आणि DHCP सर्व्हर समाविष्ट आहे. आता, जर क्लायंट संगणकांपैकी एकाने चित्राच्या मध्यभागी असलेल्या डेटा सेंटरशी संपर्क साधला तर ते क्लायंट डिव्हाइसेसवर फाइल सर्व्हर रहदारी पाठविण्यास सुरवात करेल. ही रहदारी लाल रंगात दर्शविली आहे आणि विशिष्ट सर्व्हरवरून विशिष्ट अनुप्रयोगासाठी विशिष्ट पोर्टवर प्रसारित केली जाईल.

ठराविक ट्रॅफिक कुठे जावे हे सर्व्हरला कसे कळले? डेस्टिनेशन पोर्ट नंबरवरून तो हे शिकतो. तुम्ही फ्रेम पाहिल्यास, तुम्हाला दिसेल की प्रत्येक डेटा ट्रान्सफरमध्ये गंतव्य पोर्ट नंबर आणि स्त्रोत पोर्ट नंबरचा उल्लेख आहे. आपण पाहू शकता की निळा आणि लाल रहदारी आणि निळा रहदारी वेब सर्व्हर रहदारी आहे, दोन्ही एकाच भौतिक सर्व्हरवर जातात, ज्यामध्ये भिन्न सर्व्हर स्थापित आहेत. जर हे डेटा सेंटर असेल तर ते व्हर्च्युअल सर्व्हर वापरते. मग त्यांना कसे कळले की लाल ट्रॅफिक त्या आयपी पत्त्यासह त्या डाव्या लॅपटॉपवर परत जायचे आहे? पोर्ट नंबरमुळे त्यांना हे माहित आहे. तुम्ही विकिपीडिया लेख "TCP आणि UDP पोर्ट्सची सूची" चा संदर्भ घेतल्यास, तुम्हाला दिसेल की ते सर्व मानक पोर्ट क्रमांकांची सूची देते.

तुम्ही हे पेज खाली स्क्रोल केल्यास ही यादी किती मोठी आहे ते तुम्ही पाहू शकता. त्यात अंदाजे 61 संख्या आहेत. 000 ते 1 पर्यंतचे पोर्ट क्रमांक सर्वात सामान्य पोर्ट क्रमांक म्हणून ओळखले जातात. उदाहरणार्थ, पोर्ट 1024/TCP हे ftp कमांड्स पाठवण्यासाठी आहे, पोर्ट 21 ssh साठी आहे, पोर्ट 22 टेलनेटसाठी आहे, म्हणजेच एनक्रिप्ट न केलेले संदेश पाठवण्यासाठी आहे. अतिशय लोकप्रिय पोर्ट 23 HTTP वरून डेटा वाहून नेतो, तर पोर्ट 80 HTTPS वर एनक्रिप्टेड डेटा वाहून नेतो, जो HTTP च्या सुरक्षित आवृत्तीसारखाच आहे.
काही पोर्ट TCP आणि UDP दोन्हीसाठी समर्पित आहेत आणि काही कनेक्शन TCP किंवा UDP आहे यावर अवलंबून भिन्न कार्ये करतात. तर, अधिकृतपणे TCP पोर्ट 80 HTTP साठी वापरले जाते आणि अनधिकृतपणे UDP पोर्ट 80 HTTP साठी वापरले जाते, परंतु वेगळ्या HTTP प्रोटोकॉल अंतर्गत - QUIC.

त्यामुळे, TCP मधील पोर्ट क्रमांक नेहमी UDP प्रमाणेच करायचे नसतात. तुम्हाला ही यादी मनापासून शिकण्याची गरज नाही, लक्षात ठेवणे अशक्य आहे, परंतु तुम्हाला काही लोकप्रिय आणि सर्वात सामान्य पोर्ट क्रमांक माहित असणे आवश्यक आहे. मी म्हटल्याप्रमाणे, यापैकी काही बंदरांचा अधिकृत उद्देश आहे, ज्याचे वर्णन मानकांमध्ये केले आहे, आणि काहींचा अनधिकृत हेतू आहे, जसे Chromium च्या बाबतीत आहे.

तर, या तक्त्यामध्ये सर्व सामान्य पोर्ट क्रमांकांची सूची आहे आणि हे क्रमांक विशिष्ट अनुप्रयोग वापरताना रहदारी पाठवण्यासाठी आणि प्राप्त करण्यासाठी वापरले जातात.

आता आपल्याला माहीत असलेल्या थोड्या माहितीच्या आधारे नेटवर्कवर डेटा कसा हलतो ते पाहू. समजा की संगणक 10.1.1.10 या संगणकाशी किंवा या सर्व्हरशी संपर्क साधू इच्छितो, ज्याचा पत्ता 30.1.1.10 आहे. प्रत्येक उपकरणाच्या IP पत्त्याच्या खाली त्याचा MAC पत्ता आहे. मी फक्त शेवटच्या 4 वर्णांसह MAC पत्त्याचे उदाहरण देत आहे, परंतु व्यवहारात तो 48 वर्णांसह 12-बिट हेक्साडेसिमल क्रमांक आहे. यातील प्रत्येक क्रमांकामध्ये ४ बिट्स असल्याने १२ हेक्साडेसिमल अंक ४८-बिट संख्या दर्शवतात.

आम्हाला माहित आहे की, जर हे डिव्हाइस या सर्व्हरशी संपर्क साधू इच्छित असेल तर, 3-वे हँडशेकची पहिली पायरी आधी केली पाहिजे, म्हणजे, SYN पॅकेट पाठवणे. जेव्हा ही विनंती केली जाते, तेव्हा संगणक 10.1.1.10 स्त्रोत पोर्ट क्रमांक निर्दिष्ट करेल, जो Windows गतिशीलपणे तयार करतो. Windows यादृच्छिकपणे 1 आणि 65,000 मधील पोर्ट क्रमांक निवडते. परंतु 1 ते 1024 या श्रेणीतील प्रारंभिक संख्या सर्वत्र ज्ञात असल्याने, या प्रकरणात सिस्टम 25000 पेक्षा जास्त संख्यांचा विचार करेल आणि एक यादृच्छिक स्त्रोत पोर्ट तयार करेल, उदाहरणार्थ, क्रमांक 25113.

पुढे, सिस्टम पॅकेटमध्ये गंतव्य पोर्ट जोडेल, या प्रकरणात ते पोर्ट 21 आहे, कारण या FTP सर्व्हरशी कनेक्ट करण्याचा प्रयत्न करत असलेल्या अनुप्रयोगास माहित आहे की त्याने FTP रहदारी पाठविली पाहिजे.

पुढे, आमचा संगणक म्हणतो, "ठीक आहे, माझा IP पत्ता 10.1.1.10 आहे आणि मला IP पत्ता 30.1.1.10 शी संपर्क साधण्याची आवश्यकता आहे." हे दोन्ही पत्ते SYN विनंती तयार करण्यासाठी पॅकेटमध्ये देखील समाविष्ट केले आहेत आणि कनेक्शन संपेपर्यंत हे पॅकेट बदलणार नाही.

संपूर्ण नेटवर्कवर डेटा कसा हलतो हे तुम्ही या व्हिडिओवरून समजून घ्यावे अशी माझी इच्छा आहे. जेव्हा आमचा संगणक विनंती पाठवणारा स्त्रोत IP पत्ता आणि गंतव्य IP पत्ता पाहतो, तेव्हा ते समजते की गंतव्य पत्ता त्या स्थानिक नेटवर्कवर नाही. मी हे सांगायला विसरलो की हे सर्व /24 IP पत्ते आहेत. म्हणून तुम्ही /24 IP पत्ते पाहिल्यास, तुमच्या लक्षात येईल की 10.1.1.10 आणि 30.1.1.10 संगणक एकाच नेटवर्कवर नाहीत. अशा प्रकारे, विनंती पाठवणाऱ्या संगणकाला हे समजते की हे नेटवर्क सोडण्यासाठी, त्याने 10.1.1.1 गेटवेशी संपर्क साधला पाहिजे, जो राउटर इंटरफेसपैकी एकावर कॉन्फिगर केलेला आहे. त्याला माहित आहे की त्याने 10.1.1.1 वर जावे आणि त्याचा 1111 चा MAC पत्ता माहित आहे, परंतु गेटवे 10.1.1.1 चा MAC पत्ता माहित नाही. तो काय करत आहे? हे ब्रॉडकास्ट एआरपी विनंती पाठवते जे नेटवर्कवरील सर्व डिव्हाइसेसना प्राप्त होईल, परंतु केवळ IP पत्ता 10.1.1.1 असलेले राउटर त्यास प्रतिसाद देईल.

राउटर त्याच्या AAAA MAC पत्त्यासह प्रतिसाद देईल आणि दोन्ही स्त्रोत आणि गंतव्य MAC पत्ते देखील या फ्रेममध्ये ठेवले जातील. फ्रेम तयार झाल्यावर, नेटवर्क सोडण्यापूर्वी एक CRC डेटा इंटिग्रिटी चेक, जे एरर शोधण्यासाठी चेकसम शोधण्यासाठी अल्गोरिदम आहे, केले जाईल.
चक्रीय रिडंडंसी सीआरसी म्हणजे SYN पासून शेवटच्या MAC पत्त्यापर्यंत ही संपूर्ण फ्रेम हॅशिंग अल्गोरिदमद्वारे चालविली जाते, MD5 म्हणा, परिणामी हॅश मूल्य मिळते. हॅश व्हॅल्यू, किंवा MD5 चेकसम, नंतर फ्रेमच्या सुरुवातीला ठेवले जाते.

मी त्याला FCS/CRC असे लेबल केले कारण FCS हा फ्रेम चेक सिक्वेन्स आहे, चार-बाइट CRC मूल्य. काही लोक पदनाम FCS वापरतात आणि काही CRC वापरतात, म्हणून मी फक्त दोन्ही पदनामांचा समावेश केला आहे. पण मुळात ते फक्त एक हॅश मूल्य आहे. नेटवर्कवर प्राप्त झालेल्या सर्व डेटामध्ये त्रुटी नाहीत याची खात्री करणे आवश्यक आहे. म्हणून, जेव्हा ही फ्रेम राउटरपर्यंत पोहोचते, तेव्हा राउटर स्वतः चेकसमची गणना करेल आणि प्राप्त केलेल्या फ्रेममध्ये असलेल्या FCS किंवा CRC मूल्याशी तुलना करेल. अशा प्रकारे तो तपासू शकतो की नेटवर्कवर प्राप्त झालेल्या डेटामध्ये त्रुटी नाहीत, त्यानंतर तो फ्रेममधून चेकसम काढून टाकेल.

पुढे, राउटर MAC पत्ता पाहील आणि म्हणेल, "ठीक आहे, MAC पत्ता AAAA म्हणजे फ्रेम मला उद्देशून आहे," आणि MAC पत्त्यांचा समावेश असलेला फ्रेमचा भाग हटवा.

गंतव्य IP पत्ता 30.1.1.10 पाहता, तो समजेल की हे पॅकेट त्याला उद्देशून नाही आणि त्याला राउटरमधून पुढे जाणे आवश्यक आहे.

आता राउटर "विचार करतो" की 30.1.1.10 पत्ता असलेले नेटवर्क कोठे आहे हे पाहणे आवश्यक आहे. आम्ही अद्याप राउटिंगची संपूर्ण संकल्पना कव्हर केलेली नाही, परंतु आम्हाला माहित आहे की राउटरमध्ये राउटिंग टेबल आहे. या तक्त्यामध्ये ३०.१.१.० पत्त्यासह नेटवर्कसाठी एंट्री आहे. जसे तुम्हाला आठवते, हा होस्ट IP पत्ता नाही, परंतु नेटवर्क ओळखकर्ता आहे. राउटर 30.1.1.0 मधून जाऊन 30.1.1.0/24 पत्त्यावर पोहोचू शकतो असा राउटर "विचार" करेल.

तुम्ही विचाराल, त्याला हे कसे कळते? फक्त लक्षात ठेवा की जर तुम्ही ॲडमिनिस्ट्रेटर म्हणून स्टॅटिक रूट कॉन्फिगर केला असेल तर ते राउटिंग प्रोटोकॉल किंवा तुमच्या सेटिंग्जमधून हे कळेल. परंतु कोणत्याही परिस्थितीत, या राउटरच्या राउटिंग टेबलमध्ये योग्य एंट्री आहे, त्यामुळे हे पॅकेट 20.1.1.2 वर पाठवावे हे त्याला माहीत आहे. राउटरला गंतव्य MAC पत्ता आधीच माहित आहे असे गृहीत धरून, आम्ही फक्त पॅकेट फॉरवर्ड करणे सुरू ठेवू. त्याला हा पत्ता माहित नसल्यास, तो पुन्हा ARP सुरू करेल, राउटरचा MAC पत्ता 20.1.1.2 प्राप्त करेल आणि फ्रेम पाठवण्याची प्रक्रिया पुन्हा सुरू राहील.

म्हणून आम्ही असे गृहीत धरतो की त्याला आधीपासूनच MAC पत्ता माहित आहे, नंतर आमच्याकडे BBB स्त्रोत MAC पत्ता आणि CCC गंतव्य MAC पत्ता असेल. राउटर पुन्हा FCS/CRC ची गणना करतो आणि फ्रेमच्या सुरुवातीला ठेवतो.

ते नंतर ही फ्रेम नेटवर्कवर पाठवते, फ्रेम राउटर 20.1.12 पर्यंत पोहोचते, ते चेकसम तपासते, डेटा दूषित नाही याची खात्री करते आणि FCS/CRC हटवते. ते नंतर MAC पत्ते "छोटे" करते, गंतव्यस्थान पाहते आणि ते 30.1.1.10 असल्याचे पाहते. हा पत्ता त्याच्या इंटरफेसशी जोडलेला आहे हे त्याला माहीत आहे. समान फ्रेम तयार करण्याची प्रक्रिया पुनरावृत्ती केली जाते, राउटर स्त्रोत आणि गंतव्य MAC पत्ता मूल्ये जोडतो, हॅशिंग करतो, हॅश फ्रेमला जोडतो आणि संपूर्ण नेटवर्कवर पाठवतो.

आमचा सर्व्हर, शेवटी त्याला संबोधित केलेली SYN विनंती प्राप्त झाल्यानंतर, हॅश चेकसम तपासतो आणि पॅकेटमध्ये त्रुटी नसल्यास, तो हॅश हटवतो. मग तो MAC पत्ते काढून टाकतो, IP पत्ता पाहतो आणि लक्षात येते की हे पॅकेट त्याला उद्देशून आहे.
त्यानंतर, ते OSI मॉडेलच्या तिसऱ्या लेयरशी संबंधित IP पत्ते कापून पोर्ट क्रमांक पाहते.

तो पोर्ट 21 पाहतो, ज्याचा अर्थ FTP रहदारी आहे, तो SYN पाहतो आणि म्हणून त्याला समजते की कोणीतरी त्याच्याशी संवाद साधण्याचा प्रयत्न करत आहे.

आता, हँडशेकबद्दल जे शिकलो त्यावर आधारित, सर्व्हर 30.1.1.10 एक SYN/ACK पॅकेट तयार करेल आणि 10.1.1.10 संगणकावर परत पाठवेल. हे पॅकेट मिळाल्यावर, डिव्हाइस 10.1.1.10 एक ACK तयार करेल, SYN पॅकेट प्रमाणे नेटवर्कमधून पास करेल आणि सर्व्हरला ACK प्राप्त झाल्यानंतर, कनेक्शन स्थापित केले जाईल.

आपल्याला एक गोष्ट माहित असणे आवश्यक आहे की हे सर्व एका सेकंदापेक्षा कमी वेळात घडते. ही एक अतिशय, अतिशय वेगवान प्रक्रिया आहे, जी मी कमी करण्याचा प्रयत्न केला आहे जेणेकरून सर्व काही तुमच्यासाठी स्पष्ट होईल.
मला आशा आहे की या ट्यूटोरियलमध्ये तुम्ही जे शिकलात ते तुम्हाला उपयुक्त वाटेल. तुम्हाला काही प्रश्न असल्यास, कृपया मला येथे लिहा [ईमेल संरक्षित] किंवा या व्हिडिओखाली प्रश्न सोडा.

पुढील धड्यापासून सुरुवात करून, मी YouTube वरून 3 सर्वात मनोरंजक प्रश्न निवडेन, ज्यांचे मी प्रत्येक व्हिडिओच्या शेवटी पुनरावलोकन करेन. आतापासून माझ्याकडे "टॉप प्रश्न" विभाग असेल त्यामुळे मी तुमच्या नावासह एक प्रश्न पोस्ट करेन आणि त्याचे थेट उत्तर देईन. मला वाटते की हे फायदेशीर ठरेल.

आमच्यासोबत राहिल्याबद्दल धन्यवाद. तुम्हाला आमचे लेख आवडतात का? अधिक मनोरंजक सामग्री पाहू इच्छिता? ऑर्डर देऊन किंवा मित्रांना शिफारस करून आम्हाला समर्थन द्या, एंट्री-लेव्हल सर्व्हरच्या अनन्य अॅनालॉगवर Habr वापरकर्त्यांसाठी 30% सवलत, ज्याचा शोध आम्ही तुमच्यासाठी लावला आहे: VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps बद्दल संपूर्ण सत्य $20 पासून किंवा सर्व्हर कसा शेअर करायचा? (RAID1 आणि RAID10 सह उपलब्ध, 24 कोर पर्यंत आणि 40GB DDR4 पर्यंत).

VPS (KVM) E5-2650 v4 (6 कोर) 10GB DDR4 240GB SSD 1Gbps उन्हाळ्यापर्यंत विनामूल्य सहा महिन्यांच्या कालावधीसाठी पैसे देताना, तुम्ही ऑर्डर करू शकता येथे.

Dell R730xd 2 पट स्वस्त? फक्त इथेच 2 x इंटेल टेट्राडेका-कोर Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 टीव्ही $199 पासून नेदरलँड मध्ये! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 पासून! बद्दल वाचा इन्फ्रास्ट्रक्चर कॉर्पोरेशन कसे तयार करावे. डेल R730xd E5-2650 v4 सर्व्हरचा वापर करून 9000 युरो किमतीचा वर्ग?

स्त्रोत: www.habr.com