सिस्को प्रशिक्षण 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 प्रस्ताव पठाइन्छ, यसले २ 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 ठेगाना आरक्षित गरेको छ। एकचोटि यसले ग्राहकको प्रसारण अनुरोध प्राप्त गरेपछि, यसले असफलताको बारेमा थाहा पाउनेछ र त्यो आईपी ठेगानालाई पूलमा फिर्ता राख्नेछ ताकि यसले अर्को अनुरोध प्राप्त गरेमा अर्को ग्राहकलाई तोक्न सक्छ।

यी 4 महत्वपूर्ण सन्देशहरू हुन् जुन DHCP ले IP ठेगानाहरू तोक्ने क्रममा आदानप्रदान गर्दछ। अर्को, DHCP सँग २ थप जानकारी सन्देशहरू छन्। दोस्रो चरणमा 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 महिना लाग्छ।" अलि बढी समय बित्नेछ र विन्डोजले भन्नेछ: "मलाई लाग्छ कि म १ महिनामा फाइल स्थानान्तरण गर्न सक्षम हुन सक्छु।" यो सन्देश "1 दिन", "1 घण्टा", "6 घण्टा", "3 घण्टा", "1 मिनेट", "20 मिनेट", "10 मिनेट" पछि आउनेछ। वास्तवमा, सम्पूर्ण फाइल स्थानान्तरण प्रक्रिया मात्र 3 मिनेट लाग्नेछ। यो कसरी भयो? सुरुमा, जब तपाईंको यन्त्रले अर्को यन्त्रसँग सञ्चार गर्ने प्रयास गर्छ, यसले एउटा प्याकेट पठाउँछ र पुष्टिको लागि पर्खन्छ। यदि यन्त्रले पुष्टिकरणको लागि लामो समय पर्ख्यो भने, यो सोच्दछ: "यदि मैले यो गतिमा 3 GB डाटा स्थानान्तरण गर्नु पर्छ भने, यो लगभग 2 वर्ष लाग्नेछ।" केहि समय पछि, तपाईको उपकरणले ACK प्राप्त गर्छ र सोच्छ, "ठीक छ, मैले एउटा प्याकेट पठाएँ र ACK प्राप्त गरें, त्यसैले प्रापकले 2 प्याकेट प्राप्त गर्न सक्छ। अब म उसलाई एउटाको सट्टा १० प्याकेट पठाउने प्रयास गर्नेछु। प्रेषकले 1 प्याकेटहरू पठाउँछ र केहि समय पछि प्राप्त गर्ने उपकरणबाट ACK पुष्टिकरण प्राप्त गर्दछ, जसको मतलब प्राप्तकर्ता अर्को, 10 औं प्याकेटको लागि पर्खिरहेको छ। प्रेषक सोच्छन्: "ठूलो, प्राप्तकर्ताले एकै पटकमा 10 प्याकेट ह्यान्डल गरेको हुनाले, अब म उसलाई दशको सट्टा 11 प्याकेट पठाउने प्रयास गर्नेछु।" उसले 10 प्याकेटहरू पठाउँछ, र प्राप्तकर्ताले जवाफ दिन्छ कि उसले ती प्राप्त गरेको छ र अहिले 100 प्याकेटहरू पर्खिरहेको छ। यसैले, समय संग, प्रसारित प्याकेट संख्या बढ्छ।

यही कारणले गर्दा तपाईंले मूल रूपमा भनिएको तुलनामा फाइल प्रतिलिपि समयमा द्रुत कमी देख्नुहुन्छ - यो ठूलो मात्रामा डाटा स्थानान्तरण गर्ने क्षमताको कारणले हो। यद्यपि, त्यहाँ एक बिन्दु आउँछ जब प्रसारण भोल्युममा थप वृद्धि असम्भव हुन्छ। मानौं तपाईंले 10000 प्याकेटहरू पठाउनुभयो, तर प्रापकको उपकरण बफरले 9000 मात्र स्वीकार गर्न सक्छ। यस अवस्थामा, प्राप्तकर्ताले सन्देशको साथ ACK पठाउँछ: "मैले 9000 प्याकेटहरू प्राप्त गरेको छु र अब 9001 प्राप्त गर्न तयार छु।" यसबाट, प्रेषकले निष्कर्ष निकाल्छ कि प्राप्त गर्ने उपकरणको बफरको क्षमता 9000 मात्र छ, जसको मतलब अब देखि म एक पटकमा 9000 भन्दा बढी प्याकेटहरू पठाउने छैन। यस अवस्थामा, प्रेषकले 9000 प्याकेटको अंशमा डेटाको बाँकी रकम स्थानान्तरण गर्न लाग्ने समयको तुरुन्तै गणना गर्छ र 3 मिनेट दिन्छ। यी तीन मिनेट वास्तविक प्रसारण समय हो। TCP Windowing ले के गर्छ।

यो ती ट्राफिक थ्रोटलिंग संयन्त्रहरू मध्ये एक हो जहाँ पठाउने उपकरणले अन्ततः वास्तविक नेटवर्क क्षमता के हो भनेर बुझ्दछ। तपाईले सोचिरहनुभएको हुन सक्छ किन तिनीहरूले प्राप्त गर्ने उपकरणको क्षमता के हो भनेर पहिले नै सहमत हुन सक्दैनन्? तथ्य यो हो कि यो प्राविधिक रूपमा असम्भव छ किनभने नेटवर्कमा विभिन्न प्रकारका उपकरणहरू छन्। मानौं तपाईंसँग आईप्याड छ र यसमा आईफोन भन्दा फरक डाटा ट्रान्सफर/रिसीभर स्पीड छ, तपाईंसँग विभिन्न प्रकारका फोनहरू हुन सक्छन्, वा तपाईंसँग धेरै पुरानो कम्प्युटर छ। त्यसैले, सबैसँग फरक नेटवर्क ब्यान्डविथ छ।

यसैले TCP विन्डोइङ टेक्नोलोजी विकसित गरिएको थियो, जब डाटा प्रसारण कम गतिमा वा न्यूनतम संख्याको प्याकेटको प्रसारणको साथ सुरु हुन्छ, बिस्तारै ट्राफिक "विन्डो" बढ्दै। तपाईले एउटा प्याकेट, 5 प्याकेट, 10 प्याकेट, 1000 प्याकेट, 10000 प्याकेटहरू पठाउनुहुन्छ र बिस्तारै त्यो सञ्झ्याललाई थप र धेरै खोल्नुहोस् जबसम्म "खुल्ने" निश्चित अवधिमा पठाइएको ट्राफिकको अधिकतम सम्भावित मात्रामा पुग्दैन। यसरी, Windowing को अवधारणा TCP प्रोटोकल को सञ्चालन को एक हिस्सा हो।

अर्को हामी सबैभन्दा सामान्य पोर्ट नम्बरहरू हेर्नेछौं। क्लासिक स्थिति हो जब तपाईंसँग 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 मा जस्तै काम गर्ने उद्देश्य होइन। तपाईंले यो सूचीलाई हृदयबाट सिक्न आवश्यक छैन, यो सम्झन असम्भव छ, तर तपाईंले केही लोकप्रिय र सबैभन्दा सामान्य पोर्ट नम्बरहरू जान्न आवश्यक छ। मैले भनेझैं, यी पोर्टहरू मध्ये केहीको आधिकारिक उद्देश्य छ, जुन मापदण्डहरूमा वर्णन गरिएको छ, र केहीको अनौपचारिक उद्देश्य छ, जस्तै क्रोमियमको मामलामा।

त्यसोभए, यो तालिकाले सबै सामान्य पोर्ट नम्बरहरू सूचीबद्ध गर्दछ, र यी नम्बरहरू विशिष्ट अनुप्रयोगहरू प्रयोग गर्दा ट्राफिक पठाउन र प्राप्त गर्न प्रयोग गरिन्छ।

अब हामीले थाहा पाएको थोरै जानकारीको आधारमा डाटा नेटवर्कमा कसरी सर्छ भनेर हेरौं। मानौं कि कम्प्युटर 10.1.1.10 ले यो कम्प्युटर, वा यो सर्भरलाई सम्पर्क गर्न चाहन्छ, जसको ठेगाना 30.1.1.10 छ। प्रत्येक यन्त्रको IP ठेगाना तल यसको MAC ठेगाना छ। म केवल अन्तिम 4 क्यारेक्टरहरू भएको MAC ठेगानाको उदाहरण दिन्छु, तर व्यवहारमा यो 48 क्यारेक्टरहरू भएको 12-बिट हेक्साडेसिमल नम्बर हो। यी प्रत्येक संख्यामा 4 बिटहरू समावेश भएको हुनाले, 12 हेक्साडेसिमल अंकहरूले 48-बिट नम्बरलाई प्रतिनिधित्व गर्दछ।

हामीलाई थाहा छ, यदि यो यन्त्रले यस सर्भरलाई सम्पर्क गर्न चाहन्छ भने, 3-तर्फी ह्यान्डशेकको पहिलो चरण पहिले गर्नुपर्छ, त्यो हो, SYN प्याकेट पठाउने। जब यो अनुरोध गरिन्छ, कम्प्युटर 10.1.1.10 ले स्रोत पोर्ट नम्बर निर्दिष्ट गर्दछ, जुन 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 आईपी ठेगानाहरू हुन्। त्यसैले यदि तपाइँ /24 आईपी ठेगानाहरू हेर्नुभयो भने, तपाइँले महसुस गर्नुहुनेछ कि कम्प्युटरहरू 10.1.1.10 र 30.1.1.10 एउटै नेटवर्कमा छैनन्। यसरी, अनुरोध पठाउने कम्प्युटरले यो नेटवर्क छोड्नको लागि, राउटर इन्टरफेसहरू मध्ये एकमा कन्फिगर गरिएको 10.1.1.1 गेटवेमा सम्पर्क गर्नुपर्छ भन्ने बुझ्छ। यो 10.1.1.1 मा जानु पर्छ र 1111 को MAC ठेगाना थाहा छ, तर गेटवे 10.1.1.1 को MAC ठेगाना थाहा छैन। ऊ के गर्दै छ? यसले प्रसारण ARP अनुरोध पठाउँछ जुन नेटवर्कमा सबै यन्त्रहरूले प्राप्त गर्नेछन्, तर IP ठेगाना 10.1.1.1 भएको राउटरले मात्र यसलाई जवाफ दिनेछ।

राउटरले यसको AAAA MAC ठेगानाको साथ प्रतिक्रिया दिनेछ, र दुबै स्रोत र गन्तव्य MAC ठेगानाहरू पनि यस फ्रेममा राखिनेछ। एकपटक फ्रेम तयार भएपछि, एक CRC डाटा अखण्डता जाँच, जुन त्रुटिहरू पत्ता लगाउन चेकसम फेला पार्नको लागि एल्गोरिदम हो, नेटवर्क छोड्नु अघि प्रदर्शन गरिनेछ।
चक्रीय रिडन्डन्सी CRC भनेको SYN देखि अन्तिम MAC ठेगाना सम्मको सम्पूर्ण फ्रेमलाई ह्यासिङ एल्गोरिदम मार्फत चलाइएको हो, MD5 भन्नुहोस्, जसको परिणामस्वरूप ह्यास मान हुन्छ। ह्यास मान, वा MD5 चेकसम, त्यसपछि फ्रेमको सुरुमा राखिएको छ।

मैले यसलाई FCS/CRC लेबल गरे किनभने FCS एक फ्रेम चेक अनुक्रम हो, एक चार-बाइट CRC मान। केही व्यक्तिहरूले पदनाम FCS प्रयोग गर्छन् र केहीले पदनाम CRC प्रयोग गर्छन्, त्यसैले मैले दुवै पदनामहरू मात्र समावेश गरेको छु। तर मूलतः यो केवल एक ह्यास मान हो। यो सुनिश्चित गर्न आवश्यक छ कि नेटवर्कमा प्राप्त सबै डाटा त्रुटिहरू समावेश गर्दैनन्। तसर्थ, जब यो फ्रेम राउटरमा पुग्छ, राउटरले गर्ने पहिलो कुरा चेकसम आफैँ गणना गर्ने र प्राप्त फ्रेममा समावेश भएको FCS वा CRC मानसँग तुलना गर्ने हो। यस तरिकाले उसले जाँच गर्न सक्छ कि नेटवर्कमा प्राप्त डाटा त्रुटिहरू समावेश गर्दैन, त्यसपछि उसले फ्रेमबाट चेकसम हटाउनेछ।

अर्को, राउटरले MAC ठेगाना हेर्नेछ र भन्नेछ, "ठीक छ, MAC ठेगाना AAAA भनेको फ्रेम मलाई सम्बोधन गरिएको छ," र MAC ठेगानाहरू भएको फ्रेमको भाग मेटाउनुहोस्।

गन्तव्य आईपी ठेगाना 30.1.1.10 हेरेर, उसले यो प्याकेट उसलाई सम्बोधन गरिएको छैन भनेर बुझ्नेछ र राउटर मार्फत अगाडि जानुपर्छ।

अब राउटरले ३०.१.१.१० ठेगाना भएको सञ्जाल कहाँ अवस्थित छ भनेर हेर्न आवश्यक छ भनेर "सोच्छ"। हामीले अहिलेसम्म राउटिङको पूर्ण अवधारणालाई कभर गरेका छैनौं, तर हामीलाई थाहा छ कि राउटरहरूमा राउटिङ तालिका छ। यो तालिकामा ३०.१.१.० ठेगाना भएको नेटवर्कको लागि प्रविष्टि छ। तपाईलाई सम्झना अनुसार, यो होस्ट आईपी ठेगाना होइन, तर नेटवर्क पहिचानकर्ता हो। राउटर 30.1.1.10 मार्फत जाँदै 30.1.1.0/30.1.1.0 ठेगानामा पुग्न सक्छ भनेर राउटरले "सोच्नेछ"।

तपाईले सोध्न सक्नुहुन्छ, उसलाई यो कसरी थाहा छ? केवल दिमागमा राख्नुहोस् कि यदि तपाइँ प्रशासकको रूपमा स्थिर मार्ग कन्फिगर गर्नुभएको छ भने यो या त रूटिङ प्रोटोकल वा तपाइँको सेटिङहरूबाट थाहा हुनेछ। तर कुनै पनि अवस्थामा, यो राउटरको राउटिङ तालिकामा सही प्रविष्टि समावेश छ, त्यसैले यसले यो प्याकेट २०.१.१.२ मा पठाउनु पर्छ भन्ने थाहा छ। राउटरलाई पहिले नै गन्तव्य MAC ठेगाना थाहा छ भनी मान्दै, हामी केवल प्याकेट फर्वार्ड गर्न जारी राख्नेछौं। यदि उसलाई यो ठेगाना थाहा छैन भने, उसले फेरि ARP सुरु गर्नेछ, राउटरको MAC ठेगाना 20.1.1.2 प्राप्त गर्नेछ, र फ्रेम पठाउने प्रक्रिया फेरि जारी रहनेछ।

त्यसोभए हामी यसलाई पहिले नै MAC ठेगाना थाहा छ भनी मान्दछौं, त्यसपछि हामीसँग BBB स्रोत MAC ठेगाना र CCC गन्तव्य MAC ठेगाना हुनेछ। राउटरले फेरि FCS/CRC गणना गर्छ र यसलाई फ्रेमको सुरुमा राख्छ।

त्यसपछि यसले यो फ्रेमलाई नेटवर्कमा पठाउँछ, फ्रेम २०.१.१२ राउटरमा पुग्छ, यसले चेकसम जाँच गर्छ, डाटा करप्ट भएको छैन भनी सुनिश्चित गर्छ, र FCS/CRC मेटाउँछ। त्यसपछि यसले MAC ठेगानाहरूलाई "छोटो" गर्छ, गन्तव्यमा हेर्छ र यो 20.1.12 हो भनेर देख्छ। उसलाई थाहा छ कि यो ठेगाना उसको इन्टरफेसमा जोडिएको छ। एउटै फ्रेम गठन प्रक्रिया दोहोर्याइएको छ, राउटरले स्रोत र गन्तव्य MAC ठेगाना मानहरू थप्छ, ह्यासिङ गर्छ, ह्यासलाई फ्रेममा संलग्न गर्छ र नेटवर्कमा पठाउँछ।

हाम्रो सर्भरले अन्ततः यसलाई सम्बोधन गरिएको SYN अनुरोध प्राप्त गरेपछि, ह्यास चेकसम जाँच गर्दछ, र यदि प्याकेटमा कुनै त्रुटि छैन भने, ह्यास मेटाउँछ। त्यसपछि उसले MAC ठेगानाहरू हटाउँछ, IP ठेगाना हेर्छ र यो प्याकेट उसलाई सम्बोधन गरिएको हो भनेर बुझ्छ।
त्यस पछि, यसले OSI मोडेलको तेस्रो तहसँग सम्बन्धित IP ठेगानाहरू काट्छ र पोर्ट नम्बरहरू हेर्छ।

उसले पोर्ट २१ देख्छ, जसको अर्थ 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 कोर) 10GB DDR4 240GB SSD 1Gbps $ 20 बाट वा कसरी सर्भर साझा गर्ने बारे सम्पूर्ण सत्य? (RAID1 र RAID10 सँग उपलब्ध, 24 कोर सम्म र 40GB DDR4 सम्म)।

VPS (KVM) E5-2650 v4 (6 कोर) 10GB DDR4 240GB SSD 1Gbps गर्मी सम्म नि:शुल्क छ महिनाको अवधिको लागि भुक्तान गर्दा, तपाइँ अर्डर गर्न सक्नुहुन्छ यहाँ.

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

स्रोत: www.habr.com