IPv4 में महारत हासिल करें: प्रोटोकॉल फंडामेंटल्स और पैकेट हैंडलिंग के लिए डेवलपर गाइड

इंटरनेट प्रोटोकॉल वर्जन 4 (IPv4) इंटरनेट और अन्य पैकेट-स्विच्ड नेटवर्क में मानक-आधारित इंटरनेटवर्किंग मेथड्स के मुख्य प्रोटोकॉल में से एक है। IPv4 अभी भी सबसे व्यापक रूप से तैनात इंटरनेट प्रोटोकॉल है। Google के IPv6 आंकड़े दर्शाते हैं कि 24 अप्रैल, 2025 को Google सेवाओं पर 44.29% ट्रैफिक IPv6 पर है, जिसका अर्थ है 55.71% IPv4 पर जाता है।

यह हैंडबुक आपको IPv4 के हर पहलू के माध्यम से ले जाएगी, IP एड्रेस समझने से लेकर पैकेट हेडर और फ्रैगमेंटेशन की जांच तक। आप सीखेंगे:

• IP एड्रेस कैसे काम करते हैं और उनके विभिन्न फॉर्मेट

• फिक्स्ड-लेंथ से CIDR तक नेटवर्क एड्रेसिंग स्कीम

• विशेष IPv4 एड्रेस और उनके उपयोग

• IPv4 हेडर में हर फील्ड की संरचना और उद्देश्य

• IPv4 विभिन्न नेटवर्क में पैकेट फ्रैगमेंटेशन को कैसे संभालता है

चाहे आप नेटवर्क इंजीनियर हों, सॉफ्टवेयर डेवलपर हों, या IT प्रोफेशनल हों, मॉडर्न कंप्यूटर नेटवर्क के साथ काम करने के लिए IPv4 को समझना महत्वपूर्ण है।

हम क्या कवर करेंगे:

1. पृष्ठभूमि

2. IP एड्रेस को समझना

3. नेटवर्क ID और होस्ट ID

4. नेटवर्क बनाम होस्ट भागों को कैसे निर्धारित करें

   • फिक्स्ड-लेंथ दृष्टिकोण

   • यहां क्या नुकसान हैं? 🤔

5. क्लासफुल एड्रेसिंग

   • IP एड्रेस असाइनमेंट

   • यहां क्या नुकसान हैं? 🤔

6. CIDR: क्लासलेस इंटरडोमेन रूटिंग

   • वास्तविक दुनिया का उदाहरण

7. सबनेट मास्क

8. अंतरिम सारांश - IPv4 एड्रेस

9. स्वयं टेस्ट करें

   • प्रीफिक्स नोटेशन और सबनेट मास्क के बीच परिवर्तित करना

   • सबनेट मास्क के साथ पीछे की ओर काम करना

   • नॉन-बाइट-अलाइन्ड प्रीफिक्स

   • नेटवर्क सदस्यता निर्धारित करना

10. विशेष IPv4 एड्रेस

    • "इस होस्ट" एड्रेस: 0.0.0.0

    • "इस नेटवर्क" एड्रेस

    • ब्रॉडकास्ट एड्रेस

    • लूपबैक एड्रेस: 127.0.0.0/8

    • विशेष IPv4 एड्रेस का सारांश

11. IPv4 हेडर

    • हेडर संरचना

    • IPv4 हेडर - अंतरिम सारांश

12. IPv4 फ्रैगमेंटेशन

    • फ्रैगमेंटेशन की आवश्यकता क्यों है

    • IP में फ्रैगमेंटेशन कैसे काम करता है

    • आइडेंटिफिकेशन फील्ड

    • फ्रैगमेंट ऑफसेट

    • मोर फ्रैगमेंट्स और डोंट फ्रैगमेंट फ्लैग्स

    • फ्रैगमेंटेशन उदाहरण

    • IPv4 फ्रैगमेंटेशन - सारांश

13. सारांश - IPv4

    • एड्रेसिंग और नेटवर्क संरचना

    • IPv4 हेडर संरचना

    • फ्रैगमेंटेशन

    • अंतिम शब्द

14. लेखक के बारे में

15. अतिरिक्त संदर्भ

शुरू करने से पहले त्वरित नोट्स

1. कंप्यूटर नेटवर्क के बारे में अधिक कंटेंट मेरे YouTube चैनल पर पा सकते हैं: Computer Networks Playlist

2. मैं कंप्यूटर नेटवर्क पर एक किताब पर काम कर रहा हूं! क्या आप प्रारंभिक संस्करण पढ़ने और फीडबैक प्रदान करने में रुचि रखते हैं? मुझे ईमेल भेजें: gitting.things@gmail.com

पृष्ठभूमि

IP का अर्थ "इंटरनेट प्रोटोकॉल" है, इसलिए IPv4 इंटरनेट प्रोटोकॉल वर्जन 4 है। इसे IETF द्वारा RFC 791 में वर्णित किया गया था, सितंबर 1981 में प्रकाशित, और 1982 में SATNET (अटलांटिक पैकेट सैटेलाइट नेटवर्क) पर प्रोडक्शन के लिए पहली बार तैनात किया गया, जो एक प्रारंभिक सैटेलाइट नेटवर्क था जिसने इंटरनेट का प्रारंभिक खंड बनाया।

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

IP एड्रेस को समझना

IP एड्रेस पदानुक्रमित, लॉजिकल एड्रेस हैं जो आज अधिकांश इंटरनेट कनेक्शन को शक्ति प्रदान करते हैं। प्रत्येक में 4 बाइट्स, या 32 बिट्स होते हैं। वे आमतौर पर डॉटेड डेसीमल नोटेशन में लिखे जाते हैं, उदाहरण के लिए:

स्वयं टेस्ट करें - क्या निम्नलिखित एड्रेस एक वैध IP एड्रेस दर्शाता है?

नहीं। चूंकि डॉट्स अलग-अलग बाइट्स को अलग करते हैं, प्रत्येक मान 0 और 255 के बीच होना चाहिए। चूंकि संख्या 392, 255 से बड़ी है, इसे एक बाइट में दर्शाया नहीं जा सकता।

नेटवर्क ID और होस्ट ID

IP एड्रेस के दो भाग होते हैं: एक नेटवर्क आइडेंटिफायर (या नेटवर्क ID) जो नेटवर्क में सभी होस्ट्स से संबंधित होता है और एक होस्ट आइडेंटिफायर (या होस्ट ID) जो इस नेटवर्क में विशिष्ट होस्ट की पहचान करता है।

नेटवर्क आइडेंटिफायर नेटवर्क में सभी होस्ट्स के लिए समान होगा, और इसे "प्रीफिक्स" भी कहा जाता है। उदाहरण के लिए, 201.22.3 के नेटवर्क आइडेंटिफायर पर विचार करें। चूंकि यह नेटवर्क प्रीफिक्स है, निम्नलिखित एड्रेस:

201.22.3.15 201.22.3.91

एक ही नेटवर्क का हिस्सा हैं, क्योंकि वे समान प्रीफिक्स साझा करते हैं। पहला एड्रेस इस नेटवर्क में होस्ट नंबर 15 से संबंधित है, और दूसरा होस्ट नंबर 91 से संबंधित है।

इस एड्रेस का एक अलग प्रीफिक्स, या एक अलग नेटवर्क आइडेंटिफायर है, और इस प्रकार यह एक अलग नेटवर्क से संबंधित है:

201.22.14.50

उपरोक्त उदाहरणों में, 3 बाइट्स या 24 बिट्स का एक नेटवर्क आइडेंटिफायर है, और 1 बाइट या 8 बिट्स का एक होस्ट आइडेंटिफायर है।

नेटवर्क बनाम होस्ट भागों को कैसे निर्धारित करें

एक प्रश्न उठता है: आप कैसे जानते हैं कि कौन से बिट्स नेटवर्क ID का हिस्सा हैं, और कौन से होस्ट ID का हिस्सा हैं? इस चुनौती को संबोधित करने के लिए समय के साथ कई दृष्टिकोण विकसित हुए हैं।

फिक्स्ड-लेंथ दृष्टिकोण

आइए इस समाधान पर विचार करें: प्रत्येक IP एड्रेस के लिए, पहला, सबसे महत्वपूर्ण बाइट नेटवर्क ID को दर्शाएगा, और शेष तीन, कम महत्वपूर्ण बाइट्स होस्ट ID को दर्शाएंगे। इस तरह IP एड्रेस पढ़ना वास्तव में आसान है। उदाहरण के लिए इस एड्रेस के लिए:

20.12.1.92

आप जानते हैं कि यह नेटवर्क 20 का वर्णन करता है, और उस नेटवर्क के अंदर होस्ट 12.1.92। कोई भी IP एड्रेस जो 20 से शुरू नहीं होता, जैसे 22.1.2.3, एक अलग नेटवर्क में होगा, और कोई भी IP एड्रेस जो 20 से शुरू होता है, जैसे 20.1.2.3, उसी नेटवर्क के भीतर होगा।

यहां क्या नुकसान हैं? 🤔

नेटवर्क ID को दर्शाने के लिए केवल एक बाइट (8 बिट्स) के साथ, आपके पास केवल 2^8, या 256, अलग-अलग नेटवर्क हैं। बेशक, वास्तविक दुनिया में इससे कहीं अधिक नेटवर्क हैं। इंटरनेट के शुरुआती दिनों में भी, विश्वविद्यालयों और बड़ी कंपनियों को प्रत्येक को अपने नेटवर्क आइडेंटिफायर की आवश्यकता थी।

सामान्य तौर पर, नेटवर्क ID के लिए एक निश्चित लंबाई और होस्ट ID के लिए एक निश्चित लंबाई का उपयोग करना पर्याप्त लचीला नहीं है। यदि आप तय करते हैं कि दो सबसे महत्वपूर्ण बाइट्स नेटवर्क ID को दर्शाएंगे और दो कम महत्वपूर्ण बाइट्स होस्ट ID को दर्शाएंगे, तो आप 2^16, या 65,536 नेटवर्क तक दर्शा सकते हैं, जो भी पर्याप्त नहीं है। इसके अलावा, कुछ नेटवर्क, जैसे बड़ी कंपनियों के, को 65,536 से अधिक होस्ट IDs की आवश्यकता हो सकती है।

क्लासफुल एड्रेसिंग

समाधान कुछ लचीलापन प्रदान करने में निहित है। "क्लासफुल एड्रेसिंग" नामक एक अन्य दृष्टिकोण पर विचार करें। इस दृष्टिकोण में, नेटवर्क ID के लिए समर्पित बिट्स की संख्या एक एड्रेस से दूसरे में बदलती है, और आप एड्रेस के पहले, सबसे महत्वपूर्ण बाइट को देखकर नेटवर्क ID बता सकते हैं।

• 1 और 127 के बीच की संख्या से शुरू होने वाला कोई भी एड्रेस "क्लास A" से संबंधित है, जिसका अर्थ है कि उसका नेटवर्क ID 1 बाइट का है, जिससे होस्ट ID के लिए 3 बाइट्स बचते हैं।

• 128 और 191 के बीच की संख्या से शुरू होने वाला कोई भी एड्रेस "क्लास B" से संबंधित है, जिसका अर्थ है कि उसका नेटवर्क ID 2 बाइट्स लंबा है, और उसका होस्ट ID भी 2 बाइट्स लंबा है।

• 192 और 223 के बीच की संख्या से शुरू होने वाला कोई भी एड्रेस "क्लास C" से संबंधित है, इसलिए इसमें 3 बाइट्स का नेटवर्क ID, और 1 बाइट होस्ट ID है।

आप इस दृष्टिकोण का पूर्ण प्रतिनिधित्व नीचे दी गई तालिका में देख सकते हैं:

उदाहरण के लिए, यह एड्रेस किस क्लास से संबंधित है?

(1) 130.12.204.5

चूंकि यह 130 से शुरू होता है, जो 128 और 191 के बीच है, यह "क्लास B" से संबंधित है। इसका मतलब है कि इसका नेटवर्क ID 130.12 है, और इसका होस्ट ID 204.5 है। आइए इसे "एड्रेस नंबर 1" के रूप में चिह्नित करें।

क्या यह एड्रेस और निम्नलिखित एड्रेस (2) एक ही नेटवर्क से संबंधित हैं?

(2) 130.90.2.40

नहीं, चूंकि उनके नेटवर्क आइडेंटिफायर अलग हैं, वे एक ही नेटवर्क के भीतर नहीं हैं।

निम्नलिखित एड्रेस किस क्लास से संबंधित है?

(3) 200.1.1.9

यह क्लास C से संबंधित है, क्योंकि इसके पहले बाइट का मान, 200, 192 और 223 के बीच है। इसका मतलब है कि इसका नेटवर्क आइडेंटिफायर 200.1.1 है, और इस प्रीफिक्स से शुरू होने वाला कोई भी एड्रेस उसी नेटवर्क के भीतर होगा। यह विशिष्ट एड्रेस इस नेटवर्क के भीतर होस्ट 9 का वर्णन करता है।

तस्वीर पूरी करने के लिए, 224 और 239 के बीच मान से शुरू होने वाले एड्रेस "क्लास D" से संबंधित हैं - यानी, मल्टीकास्ट एड्रेस - एड्रेस जो कई डिवाइसेज से संबंधित हैं। 240 और 255 के बीच मान से शुरू होने वाले एड्रेस भविष्य के उपयोग के लिए रिजर्व्ड थे। 0 से शुरू होने वाले एड्रेस विशेष एड्रेस हैं।

IP एड्रेस असाइनमेंट

प्रारंभिक इंटरनेट में, IPv4 एड्रेस Internet Assigned Numbers Authority (IANA) द्वारा संगठनों को असाइन किए गए थे। जैसे-जैसे इंटरनेट बढ़ा, यह जिम्मेदारी पांच रीजनल इंटरनेट रजिस्ट्रीज (RIRs) को वितरित की गई जो विभिन्न भौगोलिक क्षेत्रों के लिए एड्रेस आवंटन को संभालते हैं। बड़े संगठनों को उनकी आवश्यकताओं के आधार पर एड्रेस ब्लॉक प्राप्त होते थे, जिसमें एड्रेस क्लास इन ब्लॉक्स के आकार को निर्धारित करते थे।

यहां क्या नुकसान हैं? 🤔

जबकि क्लासफुल एड्रेसिंग फिक्स्ड-लेंथ दृष्टिकोण की तुलना में अधिक लचीलापन अनुमति देता है, फिर भी यह दृष्टिकोण पर्याप्त लचीला नहीं है।

इस परिदृश्य पर विचार करें: सिर्फ दो संस्थापकों वाली एक छोटी स्टार्टअप कंपनी को एक नेटवर्क आइडेंटिफायर की आवश्यकता है। उन्हें किस क्लास की आवश्यकता होगी?

क्लास A या क्लास B प्राप्त करना अत्यधिक होगा, इसलिए उन्हें क्लास C मिल सकता है - जिससे 256 एड्रेस की अनुमति मिलती है। यह वर्तमान में आवश्यकता से अधिक है, लेकिन कुछ विस्तार की अनुमति देता है। क्या होता है अगर स्टार्टअप 256 से अधिक कर्मचारियों (और डिवाइसेज) तक बढ़ता है?

इस बिंदु पर, उन्हें क्लास B एड्रेस की आवश्यकता होगी, जिससे 65,536 एड्रेस से कम नहीं मिलते, जब उन्हें केवल 256 से थोड़ा अधिक एड्रेस की आवश्यकता होती है। इसका मतलब है 60,000 से अधिक एड्रेस बर्बाद करना।

यह 1990 के दशक की शुरुआत में एक वास्तविक समस्या बन गई जब इंटरनेट तेजी से बढ़ रहा था। अधिक IP एड्रेस की आवश्यकता स्पष्ट हो गई, और IPv4 एड्रेस स्पेस की आसन्न थकावट थी। जिन मामलों में 60,000 एड्रेस बर्बाद हो रहे थे, उन्हें अब बर्दाश्त नहीं किया जा सकता था।

CIDR: क्लासलेस इंटरडोमेन रूटिंग

एड्रेस की इस कमी को संभालने के उपायों में से एक 1993 में क्लासफुल एड्रेसिंग को छोड़ना और CIDR - क्लासलेस इंटरडोमेन रूटिंग नामक एक अन्य दृष्टिकोण पर स्विच करना था। यह दृष्टिकोण आज भी उपयोग किया जाता है।

CIDR नेटवर्क ID और होस्ट ID चुनते समय लचीलापन अनुमति देता है। यह नेटवर्क एडमिनिस्ट्रेटर्स को क्लास A, B, या C तक सीमित होने के बजाय ठीक सही आकार के सबनेट बनाने देता है।

आइए एक सरल उदाहरण से शुरू करें। CIDR नोटेशन में, हम एक सफिक्स जोड़ते हैं जो दर्शाता है कि नेटवर्क भाग के लिए कितने बिट्स उपयोग किए जाते हैं:

(4) 200.8.3.1/16

यह स्लैश नोटेशन निर्दिष्ट करता है कि कितने बिट्स नेटवर्क ID का वर्णन करते हैं। उपरोक्त उदाहरण (4) में, पहले 16 बिट्स (या 2 बाइट्स) का उपयोग नेटवर्क ID के लिए किया जाता है। तो, इस मामले में, 200.8 नेटवर्क आइडेंटिफायर है, और 3.1 होस्ट आइडेंटिफायर है। तथ्य यह है कि 200.8 नेटवर्क ID है इसका मतलब है कि 200.8.0.0 से 200.8.255.255 तक के सभी एड्रेस इस नेटवर्क में हैं।

इन अतिरिक्त एड्रेस पर विचार करें:

(5) 200.2.13.5 (6) 200.8.21.6

इस एड्रेस प्रीफिक्स के 16 बिट्स, या 2 बाइट्स दिए गए, इनमें से कौन से एड्रेस उदाहरण (4) (200.8.3.1/16) के समान नेटवर्क से संबंधित हैं?

पहला एड्रेस (5) (200.2.13.5) इस नेटवर्क से संबंधित नहीं है, क्योंकि इसके पहले 16 बिट्स - 200.2, उदाहरण एड्रेस के पहले 16 बिट्स से अलग हैं।

दूसरा एड्रेस (6) (200.8.21.6) उदाहरण एड्रेस के समान नेटवर्क से संबंधित है।

वास्तविक दुनिया का उदाहरण

अभ्यास में, एक ISP को RIR से 104.16.0.0/12 जैसा एक बड़ा ब्लॉक प्राप्त हो सकता है। यह उन्हें 104.16.0.0 से 104.31.255.255 तक के सभी एड्रेस पर नियंत्रण देता है। ISP तब ग्राहकों को छोटे सबनेट आवंटित कर सकता है, जैसे एक छोटे व्यवसाय को /24 सबनेट देना जिसमें 256 एड्रेस हों, या एक बड़ी कंपनी को /20 सबनेट देना जिसमें 4,096 एड्रेस हों।

सबनेट मास्क

नेटवर्क प्रीफिक्स को व्यक्त करने का एक और तरीका सबनेट मास्क का उपयोग करना है, जैसे:

255.255.0.0

बाइनरी में परिवर्तित होने पर, डेसीमल में 255 बाइनरी में आठ 1s के बराबर होता है - इसलिए सभी बिट्स ऑन हैं। तो यदि आप इस मास्क को बाइनरी में अनुवाद करते हैं, तो आपको मिलता है:

11111111 11111111 00000000 00000000

दूसरे शब्दों में, 16 बिट्स ऑन हैं, जिसका अर्थ है 16 बिट्स का नेटवर्क प्रीफिक्स। दोनों कन्वेंशन (CIDR नोटेशन और सबनेट मास्क) बहुत बार उपयोग किए जाते हैं।

CIDR के साथ, एक एड्रेस अलग-अलग नेटवर्क प्रीफिक्स या सबनेट मास्क दिए जाने पर विभिन्न नेटवर्क में रह सकता है। यदि आप उसी उदाहरण एड्रेस को एक अलग प्रीफिक्स के साथ मानते हैं, मान लें 8 बिट्स का - दोनों अतिरिक्त एड्रेस एक ही नेटवर्क से संबंधित होंगे, क्योंकि वे सभी पहले 8 बिट्स - 200 साझा करते हैं।

8 बिट्स के नेटवर्क प्रीफिक्स को सबनेट मास्क के रूप में कैसे प्रस्तुत करेंगे? आपको पहले 8 बिट्स को ऑन करने की आवश्यकता है, इसलिए डेसीमल में इसका अर्थ 255 है, और शेष बिट्स ऑफ हैं, जिसके परिणामस्वरूप यह सबनेट मास्क प्राप्त होता है:

255.0.0.0

क्या होता है यदि आप 24 बिट्स के नेटवर्क प्रीफिक्स का उपयोग करते हैं? पहले, आप इसे सबनेट मास्क के रूप में कैसे व्यक्त करेंगे? आपको 24 बिट्स को ऑन करने की आवश्यकता है, इसलिए वह 3 बार 8 बिट्स ऑन हैं, जिसके परिणामस्वरूप:

255.255.255.0

अब, न तो अतिरिक्त एड्रेस उदाहरण एड्रेस के समान नेटवर्क में रहते हैं, क्योंकि वे इसके नेटवर्क ID 200.8.3 को साझा नहीं करते।

ध्यान दें कि नेटवर्क प्रीफिक्स को पूर्ण बाइट्स दर्शाने की आवश्यकता नहीं है। उदाहरण के लिए, आप 12 बिट्स, या 11 बिट्स, या 22 बिट्स के नेटवर्क प्रीफिक्स का उपयोग कर सकते हैं। जब प्रीफिक्स लंबाई 8 का गुणक नहीं होती, तो सबनेट मास्क की स्थितियों में से एक में 0 या 255 के अलावा कोई मान होगा।

यह स्टार्टअप कंपनी के मुद्दे को संबोधित करता है। यदि एक स्टार्टअप के 300 कर्मचारी हैं, तो उन्हें 23-बिट्स नेटवर्क ID प्राप्त करने की आवश्यकता होगी, जिससे उनके नेटवर्क के भीतर होस्ट्स के लिए 9 बिट्स बचेंगे। इसका अर्थ है 2^9, या 512 एड्रेस, जो पर्याप्त होना चाहिए।

अंतरिम सारांश - IPv4 एड्रेस

इस खंड में, आपने IPv4 एड्रेस के बारे में सीखा। IP एड्रेस पदानुक्रमित, लॉजिकल एड्रेस हैं जो 4 बाइट्स से बने होते हैं। IP एड्रेस के दो भाग होते हैं: एक नेटवर्क आइडेंटिफायर जो नेटवर्क में सभी होस्ट्स से संबंधित होता है, और एक होस्ट आइडेंटिफायर जो नेटवर्क में विशिष्ट होस्ट की पहचान करता है।

आपने नेटवर्क आइडेंटिफायर और होस्ट आइडेंटिफायर निर्धारित करने के लिए विभिन्न विकल्पों का पता लगाया है:

1. फिक्स्ड-लेंथ दृष्टिकोण - बहुत कठोर और सीमित

2. क्लासफुल एड्रेसिंग दृष्टिकोण - बेहतर लेकिन अभी भी बर्बादी वाला

3. CIDR (क्लासलेस इंटरडोमेन रूटिंग) - लचीला और कुशल

CIDR बहुत अधिक लचीलापन प्रदान करता है और IPv4 एड्रेस की कमी की महत्वपूर्ण समस्या को दूर करने में मदद करता है। हालांकि, CIDR IPv4 एड्रेस की कमी को संबोधित करने का केवल एक हिस्सा है, अन्य समाधानों में NAT (नेटवर्क एड्रेस ट्रांसलेशन) और अंततः, IPv6 शामिल हैं।

अगला खंड विशेष IPv4 एड्रेस का पता लगाएगा और फिर IPv4 पैकेट के हेडर की जांच करेगा।

स्वयं टेस्ट करें

अब उन कॉन्सेप्ट्स का अभ्यास करें जो आपने सीखे हैं और सुनिश्चित करें कि आप उनके साथ सहज महसूस करते हैं।

निम्नलिखित प्रश्नों का उत्तर देने का प्रयास करने के लिए एक क्षण लें, फिर उत्तर जांचें।

प्रीफिक्स नोटेशन और सबनेट मास्क के बीच परिवर्तित करना

16 बिट्स के नेटवर्क प्रीफिक्स को, जिसे इस तरह लिखा जाता है /16, सबनेट मास्क के रूप में कैसे दर्शाएंगे?

आपको 16 बिट्स चाहिए जो ऑन हों। जब 8 बिट्स ऑन होते हैं तो आपको डेसीमल में 255 मिलता है, इसलिए आप उपयोग करेंगे:

255.255.0.0

दिए गए नेटवर्क प्रीफिक्स के साथ, क्या ये एड्रेस एक ही नेटवर्क से संबंधित हैं?

हां, वे करते हैं, क्योंकि वे समान सबसे महत्वपूर्ण 16 बिट्स, या दो बाइट्स साझा करते हैं।

क्या यह एड्रेस पिछले एड्रेस के समान नेटवर्क से संबंधित है?

हां, यह करता है। फिर से, यह समान दो सबसे महत्वपूर्ण बाइट्स साझा करता है।

इसके बारे में क्या? क्या यह पिछले एड्रेस के समान नेटवर्क से संबंधित है?

नहीं, क्योंकि पहले दो बाइट्स 42.31 नहीं हैं - यह एक अलग नेटवर्क है। तो यह एड्रेस नेटवर्क 42.32 के भीतर होस्ट 1.2 का वर्णन करता है।

सबनेट मास्क के साथ पीछे की ओर काम करना

आइए दूसरे तरीके से प्रयास करें। आपके पास यह सबनेट मास्क है:

255.255.255.0

इसे नेटवर्क प्रीफिक्स का उपयोग करके कैसे व्यक्त करेंगे?

आपके पास 255 के तीन उदाहरण हैं, जिसका अर्थ है तीन बार 8 बिट्स जो ऑन हैं, इसलिए कुल मिलाकर आपके पास 24 बिट्स ऑन हैं। तो आप /24 भी लिख सकते हैं। इसका अर्थ 3 बाइट्स है।

दिए गए सबनेट मास्क के साथ, क्या उपरोक्त एड्रेस (1) और (3) एक ही नेटवर्क से संबंधित हैं?

वे करते हैं, क्योंकि उन दोनों में समान सबसे महत्वपूर्ण तीन बाइट्स हैं - नेटवर्क 42.31.93।

एड्रेस (1) और (2) के बारे में क्या?

दिए गए नेटवर्क प्रीफिक्स के साथ, वे एक ही नेटवर्क से संबंधित नहीं हैं। पहला एड्रेस नेटवर्क 42.31.93 से संबंधित है, और दूसरा एड्रेस नेटवर्क 42.31.1 से संबंधित है।

नॉन-बाइट-अलाइन्ड प्रीफिक्स

नेटवर्क प्रीफिक्स को 8 बिट्स, या पूर्ण बाइट्स के साथ संरेखित करने की आवश्यकता नहीं है। मान लें कि आपके पास 14 बिट्स का नेटवर्क प्रीफिक्स है। आप इसे सबनेट मास्क में कैसे परिवर्तित करेंगे?

खैर, पहला बाइट स्पष्ट है: आपके पास 8 बिट्स ऑन हैं, इसलिए पहला बाइट 255 है। अगले के बारे में क्या?

बाइनरी में, आप छह अतिरिक्त 1s, और फिर 2 0s चाहेंगे - तो बाइनरी में आप लिखेंगे:

11111100

डेसीमल में परिवर्तित करने पर, यह बाइनरी संख्या 252 को दर्शाती है। तो आपका सबनेट मास्क है:

255.252.0.0

यह परिवर्तन करने का एक और तरीका: आप जानते हैं कि बाइनरी में आठ 1s डेसीमल में 255 को दर्शाते हैं। आप यह भी जानते हैं कि बाइनरी में 11 डेसीमल में 3 है, इसलिए आप बस 3 को 255 से घटा सकते हैं और 252 प्राप्त कर सकते हैं।

अब, दूसरे तरीके से प्रयास करें। आपके पास निम्नलिखित सबनेट मास्क है:

255.255.224.0

कितने बिट्स नेटवर्क प्रीफिक्स को दर्शाते हैं?

पहले दो बाइट्स स्पष्ट हैं: आपके पास 16 बिट्स हैं। तीसरे बाइट को बाइनरी में परिवर्तित करना: डेसीमल में 224 बाइनरी में 11100000 है। इसका मतलब है आपके पास तीन अतिरिक्त 1s हैं, इसलिए आप उपरोक्त सबनेट मास्क को /19 बिट्स के प्रीफिक्स के रूप में लिख सकते हैं - दो 255 बाइट्स के लिए 16 बिट्स, और 224 बाइट के लिए 3 अतिरिक्त बिट्स।

नेटवर्क सदस्यता निर्धारित करना

निम्नलिखित एड्रेस पर विचार करें:

क्या वे एक ही नेटवर्क का हिस्सा हैं? 🤔

यह सबनेट मास्क पर निर्भर करता है।

यदि नेटवर्क प्रीफिक्स /8 है, तो वे एक ही नेटवर्क का हिस्सा हैं, क्योंकि वे समान नेटवर्क ID साझा करते हैं।

दूसरी ओर, यदि नेटवर्क प्रीफिक्स /16 है, तो उनके नेटवर्क IDs अलग हैं, और इस प्रकार वे एक ही नेटवर्क से संबंधित नहीं हैं। लेकिन बीच के प्रीफिक्स के साथ क्या होता है? क्या वे /9 के प्रीफिक्स के लिए एक ही नेटवर्क में रहेंगे? /14?

इस प्रश्न का दृष्टिकोण इन एड्रेस के दूसरे बाइट को बाइनरी में परिवर्तित करना है। पहले एड्रेस के लिए, यह बाइट 24 है, जो बाइनरी में है:

00011000

दूसरे एड्रेस के लिए, दूसरा बाइट 23 है, जो बाइनरी में है:

00010111

आप देख सकते हैं कि दूसरे बाइट के भीतर सबसे महत्वपूर्ण 4 बिट्स समान हैं। यदि आप एड्रेस के पहले 8 बिट्स जोड़ते हैं, तो आप देखते हैं कि इन एड्रेस के सबसे महत्वपूर्ण 12 बिट्स समान हैं।

तो, यदि आपके पास /11 का नेटवर्क प्रीफिक्स है, तो क्या ये एड्रेस एक ही नेटवर्क से संबंधित हैं?

हां, वे करते हैं - उनके सबसे महत्वपूर्ण 11 बिट्स समान हैं।

/13 के बारे में क्या?

नहीं, इस नेटवर्क प्रीफिक्स के साथ, वे समान नेटवर्क आइडेंटिफायर साझा नहीं करते, क्योंकि उनका 13वां बिट अलग है।

यह अभ्यास आपको सबनेट मास्क और नेटवर्क प्रीफिक्स के साथ सहज महसूस करने में मदद करेगा। अगले खंड में, आप विशेष IP एड्रेस के बारे में जानेंगे और फिर IP पैकेट के हेडर की जांच करेंगे।

विशेष IPv4 एड्रेस

अब जब आप IP एड्रेस और सबनेट मास्क के साथ सहज हैं, तो आइए कुछ IP एड्रेस का पता लगाएं जिनके विशेष अर्थ हैं।

"इस होस्ट" एड्रेस: 0.0.0.0

एड्रेस 0.0.0.0 का अर्थ "यह होस्ट" है और दो परिदृश्यों में उपयोग किया जाता है:

पहला, जब कोई मशीन बूट होती है और उसके पास अभी तक IP एड्रेस नहीं होता। IP एड्रेस लॉजिकल एड्रेस हैं जिन्हें मशीन को असाइन करने की आवश्यकता होती है। इस असाइनमेंट से पहले, डिवाइस के पास बिल्कुल भी IP एड्रेस नहीं होता। यदि इस चरण में डिवाइस को संवाद करने की आवश्यकता है, तो यह इस विशेष एड्रेस, 0.0.0.0 का उपयोग कर सकता है।

दूसरा, नेटवर्क एप्लिकेशन लिखते समय जो सभी नेटवर्क इंटरफेस पर इनकमिंग कनेक्शन सुनने की आवश्यकता होती है। उदाहरण के लिए, यदि किसी मशीन के दो इंटरफेस हैं - एक IP एड्रेस 1.1.1.1 के साथ, और दूसरा एड्रेस 2.2.2.2 के साथ - 0.0.0.0 एड्रेस पर सुनने का मतलब है कि कनेक्शन स्वीकार करना चाहे कोई भी नेटवर्क इंटरफेस उन्हें प्राप्त करे।

"इस नेटवर्क" एड्रेस

विशेष एड्रेस का एक अन्य वर्ग वे हैं जो शून्य से शुरू होते हैं, जहां शून्य का अर्थ "यह नेटवर्क" है।

उदाहरण के लिए, यदि आपके पास एड्रेस वाली मशीन है:

12.34.55.55

और 16 बिट्स का नेटवर्क प्रीफिक्स, यह मशीन नेटवर्क पर किसी अन्य डिवाइस को उसके पूर्ण एड्रेस का उपयोग करके पैकेट भेज सकती है, उदाहरण के लिए 12.34.66.66, या वैकल्पिक रूप से विशेष शून्य नोटेशन का उपयोग करके पैकेट भेज सकती है:

0.0.66.66

इसका अर्थ है "इस नेटवर्क पर होस्ट 66.66 को पैकेट भेजें।" बेशक, प्राप्तकर्ता को इस एड्रेस को सही ढंग से समझने के लिए प्रासंगिक नेटवर्क प्रीफिक्स भी पता होना चाहिए।

ब्रॉडकास्ट एड्रेस

एड्रेस 255.255.255.255, जहां सभी बिट्स 1 पर सेट हैं, स्थानीय नेटवर्क में सभी होस्ट्स का एड्रेस है - ब्रॉडकास्ट एड्रेस। यह Ethernet (FF:FF:FF:FF:FF:FF) में ब्रॉडकास्ट एड्रेस के समान है। दोनों मामलों में, सभी बिट्स 1 पर सेट हैं।

एक उचित नेटवर्क आइडेंटिफायर का उपयोग करना जहां होस्ट आइडेंटिफायर सभी 1s पर सेट हैं, का उपयोग रिमोट नेटवर्क पर ब्रॉडकास्ट पैकेट भेजने के लिए किया जा सकता है। उदाहरण के लिए, नेटवर्क 12.34.0.0/16 और 12.35.0.0/16 नेटवर्क ID वाले एक अन्य नेटवर्क पर विचार करें। यदि 12.34.55.55 पर एक मशीन दूसरे नेटवर्क में सभी डिवाइसेज को पैकेट भेजना चाहती है, तो यह डेस्टिनेशन एड्रेस का उपयोग कर सकती है: 12.35.255.255।

भले ही यह IP स्पेसिफिकेशन (RFC) के अनुसार अनुमत है, व्यवहार में यह सुविधा अक्सर अक्षम होती है क्योंकि यह सुरक्षा कमजोरियां पैदा कर सकती है।

लूपबैक एड्रेस: 127.0.0.0/8

127.0.0.0/8 नेटवर्क में सभी एड्रेस (यानी, 127 से शुरू होने वाले सभी एड्रेस) लूपबैक एड्रेस हैं। इनमें से किसी भी एड्रेस पर भेजे गए पैकेट्स को फिजिकल नेटवर्क पर नहीं डाला जाता बल्कि ऑपरेटिंग सिस्टम के भीतर स्थानीय रूप से प्रोसेस किया जाता है। यह डेवलपमेंट और डीबगिंग के लिए अत्यंत उपयोगी है।

उदाहरण के लिए, एक साधारण चैट प्रोग्राम विकसित करते समय, आपको डेटा एक्सचेंज करने वाले दो क्लाइंट्स की आवश्यकता होती है। एक दृष्टिकोण दो अलग-अलग फिजिकल कंप्यूटर्स का उपयोग करना होगा, लेकिन यह थकाऊ है - आपको एक कंप्यूटर पर संदेश लिखना होगा, यह देखने के लिए दूसरे कंप्यूटर की जांच करनी होगी कि क्या यह प्राप्त हुआ, फिर दूसरे कंप्यूटर पर संदेश लिखें, और रसीद को मान्य करने के लिए पहले पर वापस जाएं।

एक बहुत सरल दृष्टिकोण लूपबैक एड्रेस का उपयोग करना है। दोनों क्लाइंट्स एक ही मशीन पर चल सकते हैं और एक दूसरे से जुड़ सकते हैं। आप एक ही फिजिकल कंप्यूटर पर दो अलग-अलग क्लाइंट प्रोग्राम चला सकते हैं और अतिरिक्त मशीन की आवश्यकता के बिना उनके बीच संदेशों का आदान-प्रदान कर सकते हैं।

उदाहरण के लिए, आप एड्रेस 127.0.0.1 का उपयोग कर सकते हैं, एक क्लाइंट पोर्ट 1337 पर सुन रहा है और दूसरा पोर्ट 1338 पर। जब क्लाइंट A क्लाइंट B को पैकेट भेजता है, तो यह पैकेट कभी भी आपके नेटवर्क कार्ड को नहीं छोड़ता बल्कि ऑपरेटिंग सिस्टम के भीतर रहता है। क्लाइंट B पैकेट को लूपबैक इंटरफेस से प्राप्त करता है जैसे कि यह फिजिकल नेटवर्क से प्राप्त हुआ हो।

डीबगिंग पूरी होने के बाद, आपके क्लाइंट कोड को बदलने की आवश्यकता नहीं है - एकमात्र अंतर यह है कि वे लूपबैक एड्रेस के बजाय वास्तविक IP एड्रेस का उपयोग करके संवाद करेंगे।

विशेष IPv4 एड्रेस का सारांश

आपने जिन विशेष IPv4 एड्रेस के बारे में सीखा है, उन्हें सारांशित करने के लिए:

अगले खंड में, आप IPv4 हेडर की संरचना के बारे में जानेंगे।

अब जब आप IP एड्रेस, सबनेट और विशेष एड्रेस को समझते हैं, तो IPv4 हेडर संरचना की विस्तार से जांच करने का समय आ गया है।

उपरोक्त आरेख RFC 791 में परिभाषित IPv4 के हेडर को दर्शाता है। आइए प्रत्येक फील्ड की जांच करें:

Version (4 बिट्स)

हेडर Version फील्ड से शुरू होता है, जिसमें चार बिट्स होते हैं। IPv4 पैकेट के लिए, वर्जन 4 है, इसलिए यह फील्ड हमेशा 4 का मान लेगा (या बाइनरी में 0100)।

❓ हेडर Version फील्ड से क्यों शुरू होता है? 🤔

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

कारण यह है कि शेष फील्ड वर्जन के अनुसार भिन्न हो सकते हैं। यदि कोई नेटवर्क डिवाइस एक IP पैकेट पढ़ता है और वर्जन फील्ड 4 का मान लेता है, तो यह पैकेट के शेष भाग से IPv4 संरचना का पालन करने की उम्मीद करेगा। यदि यह 6 जैसे किसी अन्य मान को लेता है, तो शेष फील्ड भिन्न होते हैं, जैसे IPv6 में।

यह फील्ड हेडर की लंबाई को दर्शाता है।

❓ हमें लंबाई निर्दिष्ट करने की आवश्यकता क्यों है? 🤔

Ethernet के विपरीत, जहां हेडर साइज निश्चित होता है, IPv4 हेडर की लंबाई वैकल्पिक फील्ड्स के कारण भिन्न हो सकती है। विशेष विकल्पों के बिना IP पैकेट के लिए, हेडर में 20 बाइट्स होते हैं, जो सबसे आम मामला है।

IHL फील्ड लंबाई को बाइट्स में सीधे नहीं बल्कि 4-बाइट वर्ड्स की इकाइयों में निर्दिष्ट करता है। इसलिए 20 बाइट्स की लंबाई निर्दिष्ट करने के लिए, मान 5 होगा (5 × 4 = 20)। यह एन्कोडिंग फील्ड को केवल 4 बिट्स का उपयोग करते हुए 60 बाइट्स तक की हेडर लंबाई निर्दिष्ट करने की अनुमति देता है (जब IHL = 15)।

एक सामान्य IPv4 पैकेट इसलिए बाइट 0x45 से हेक्साडेसिमल में शुरू होता है, जिसका अर्थ है कि यह IP प्रोटोकॉल का वर्जन 4 है, और हेडर 20 बाइट्स लंबा है।

Type of Service (TOS) (8 बिट्स)

इस फील्ड के पीछे विचार यह है कि सभी पैकेट समान रूप से महत्वपूर्ण नहीं हैं। आप कुछ पैकेट्स को दूसरों पर प्राथमिकता देना चाह सकते हैं।

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

Type of Service फील्ड सेंडर्स को अपने पैकेट्स की प्राथमिकता दर्शाने की अनुमति देता है। हालांकि, पब्लिक इंटरनेट पर, इस फील्ड को अक्सर राउटर्स द्वारा अनदेखा किया जाता है क्योंकि कोई भी सेंडर कोई भी प्राथमिकता मान सेट कर सकता है। अधिकांश मामलों में, यह फील्ड 0 का मान लेता है।

Total Length (16 बिट्स)

यह फील्ड IP पैकेट की कुल लंबाई निर्दिष्ट करता है, जिसमें हेडर और पेलोड (डेटा) दोनों शामिल हैं।

❓ लंबाई निर्दिष्ट करने के लिए इसकी आवश्यकता क्यों है? 🤔

दुर्भाग्य से, IP लेयर यह जरूरी नहीं जानता कि पैकेट में कुछ बाइट्स वास्तव में सेकंड लेयर का पैडिंग हैं। मैंने इसे पिछले पोस्ट में विस्तार से बताया, जहां मैंने दिखाया कि Ethernet प्रोटोकॉल में, कुछ मामलों में, प्राप्त करने वाली Ethernet इकाई यह नहीं बता सकती कि कौन से बाइट्स पेलोड से संबंधित हैं और कौन से बाइट्स केवल पैडिंग हैं। IP लेयर को ठीक से पता होना चाहिए कि कौन से बाइट्स वास्तविक पैकेट से संबंधित हैं, इसलिए Total Length फील्ड।

❓ IPv4 पैकेट का अधिकतम आकार क्या है? 🤔

चूंकि यह फील्ड 16 बिट्स लंबा है, एक IPv4 पैकेट में अधिकतम 2^16-1 बाइट्स, या 65,535 बाइट्स हो सकते हैं, जिसमें हेडर शामिल है। न्यूनतम आकार 20 बाइट्स है, जिसमें केवल हेडर होता है बिना विकल्प या पेलोड के।

फ्रैगमेंटेशन फील्ड्स (32 बिट्स)

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

Time to Live (8 बिट्स)

इसके नाम के बावजूद, यह फील्ड वास्तव में समय को मापता नहीं है बल्कि रूटिंग हॉप्स की अधिकतम संख्या को मापता है जो एक पैकेट डिस्कार्ड होने से पहले पार कर सकता है।

इसके उद्देश्य को समझने के लिए, इस परिदृश्य पर विचार करें: यदि मशीन A राउटर्स की एक श्रृंखला के माध्यम से मशीन B को पैकेट भेजती है, लेकिन एक रूटिंग लूप है जहां राउटर 2 राउटर 3 को भेजता है, जो राउटर 4 को भेजता है, जो वापस राउटर 2 को भेजता है, तो पैकेट अनिश्चित काल तक घूम सकता है, बैंडविड्थ का उपभोग करता है और कभी भी अपने गंतव्य तक नहीं पहुंचता।

TTL फील्ड इस पर एक सीमा निर्धारित करके इसे रोकता है कि एक पैकेट कितने हॉप्स ले सकता है:

1. सेंडर एक प्रारंभिक TTL मान सेट करता है (अक्सर 64 या 128)

2. पैकेट को संभालने वाला प्रत्येक राउटर TTL को 1 से घटाता है

3. यदि कोई राउटर TTL = 1 के साथ पैकेट प्राप्त करता है, तो वह इसे 0 तक घटाता है और पैकेट को डिस्कार्ड करता है

4. राउटर तब मूल सेंडर को ICMP "Time Exceeded" संदेश वापस भेजता है

यह रूटिंग लूप की अंतर्निहित समस्या को हल नहीं करता, लेकिन यह पैकेट्स को हमेशा के लिए घूमने से रोकता है।

IPv6 में, इस फील्ड का नाम बदलकर "Hop Limit" कर दिया गया है, जो इसके कार्य का अधिक सटीक वर्णन करता है।

Protocol (8 बिट्स)

यह फील्ड IPv4 पैकेट के पेलोड का वर्णन करता है। उदाहरण के लिए:

• 6 का मान पेलोड TCP होने का अर्थ है

• 17 का मान पेलोड UDP होने का अर्थ है

यह प्राप्त करने वाले सिस्टम को यह जानने में मदद करता है कि कौन सा प्रोटोकॉल हैंडलर पैकेट की सामग्री को प्रोसेस करना चाहिए। यह Ethernet में Type फील्ड के समान है, जो Ethernet फ्रेम के भीतर एनकैप्सुलेटेड प्रोटोकॉल को निर्दिष्ट करता है।

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

❓ प्रत्येक राउटर द्वारा चेकसम की पुनर्गणना की जानी चाहिए। ऐसा क्यों है? 🤔

क्योंकि TTL फील्ड प्रत्येक हॉप पर बदलता है। उदाहरण के लिए, यदि कोई पैकेट TTL = 7 से शुरू होता है, तो प्रत्येक राउटर करेगा:

1. TTL = 7 के आधार पर वर्तमान चेकसम सत्यापित करें

2. TTL को 6 तक घटाएं

3. TTL = 6 के आधार पर एक नया चेकसम गणना करें

4. नए चेकसम के साथ पैकेट को फॉरवर्ड करें

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

Source और Destination Addresses (प्रत्येक 32 बिट्स)

इन फील्ड्स में क्रमशः स्रोत और गंतव्य IPv4 एड्रेस होते हैं। प्रत्येक 4 बाइट्स (32 बिट्स) लंबा होता है, जैसा कि आपने IPv4 एड्रेसिंग पर पिछले खंडों में सीखा।

Options (वेरिएबल लेंथ)

अधिकांश IPv4 पैकेट्स में विकल्प शामिल नहीं होते, लेकिन जब मौजूद होते हैं, तो वे अतिरिक्त कार्यक्षमता प्रदान कर सकते हैं:

• Record Route: पैकेट को संभालने वाला प्रत्येक राउटर इस विकल्प में अपना एड्रेस जोड़ता है, जिससे पैकेट के पथ का पता चलता है

• Source Routing: सेंडर को पैकेट का रूट निर्दिष्ट करने की अनुमति देता है:

  • Strict Source Routing: संपूर्ण रूट का सटीक पालन किया जाना चाहिए

  • Loose Source Routing: कुछ राउटर्स को पार किया जाना चाहिए, लेकिन उनके बीच सटीक पथ लचीला है

Padding

कुछ मामलों में, हेडर पैडिंग बाइट्स (आमतौर पर 0s) के साथ समाप्त होता है।

❓ IPv4 हेडर में पैडिंग क्यों होती है?🤔

जैसा कि पहले बताया गया है, IHL फील्ड हेडर लंबाई को 4-बाइट इकाइयों में निर्दिष्ट करता है, इसलिए कुल हेडर लंबाई 4 बाइट्स का गुणक होना चाहिए। यदि विकल्प हेडर लंबाई को 4 से विभाज्य नहीं बनाते हैं, तो अगले 4 के गुणक तक पहुंचने के लिए पैडिंग बाइट्स (आमतौर पर 0) जोड़े जाते हैं।

उदाहरण के लिए, यदि आपके पास 3 बाइट्स के विकल्प हैं, तो कुल हेडर लंबाई को 4 बाइट्स का गुणक बनाने के लिए 1 बाइट पैडिंग की आवश्यकता होगी।

अब आप IPv4 हेडर की संरचना के बारे में जान चुके हैं, फ्रैगमेंटेशन फील्ड्स को छोड़कर जिसे मैं अगले खंड में कवर करूंगा।

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

अगले खंड में, आप IPv4 फ्रैगमेंटेशन के बारे में जानेंगे।

IPv4 फ्रैगमेंटेशन

पिछले खंड में, आपने IPv4 हेडर संरचना के अधिकांश भाग के बारे में सीखा, 32 बिट्स के अपवाद के साथ जो फ्रैगमेंटेशन के लिए समर्पित हैं। यह विषय विशेष ध्यान देने योग्य है, क्योंकि यह प्रकट करता है कि IP पैकेट विभिन्न नेटवर्क में कैसे यात्रा करते हैं।

फ्रैगमेंटेशन की आवश्यकता क्यों है

यह समझने के लिए कि फ्रैगमेंटेशन क्या है और इसकी आवश्यकता क्यों है, निम्नलिखित नेटवर्क परिदृश्य पर विचार करें:

इस आरेख में, आपके पास दो अलग-अलग नेटवर्क हैं जहां मशीन A एक नेटवर्क में रहती है और मशीन B दूसरे में। एक राउटर इन दो नेटवर्क के बीच पैकेट फॉरवर्ड करता है।

इन दो नेटवर्क में अलग-अलग Maximum Transmission Units (MTUs) हैं। MTU एक नेटवर्क में ट्रांसमिट किए जा सकने वाले फ्रेम के अधिकतम आकार को संदर्भित करता है। उदाहरण के लिए:

• मशीन B एक Ethernet नेटवर्क से जुड़ी है जिसका MTU 1500 बाइट्स है

• मशीन A एक अलग नेटवर्क से जुड़ी है जिसका MTU 2000 बाइट्स है

विभिन्न MTUs विभिन्न नेटवर्क के विभिन्न प्रोटोकॉल और हार्डवेयर से उत्पन्न होते हैं। Ethernet का MTU 1500 बाइट्स है। यह अधिकतम आकार इसलिए चुना गया था क्योंकि 1970 के दशक के अंत में जब Ethernet की योजना बनाई गई थी तब RAM महंगा था, और यदि फ्रेम बड़ा हो सकता था तो रिसीवर को अधिक RAM की आवश्यकता होगी। अन्य नेटवर्क अलग-अलग समय पर विकसित किए गए थे जहां RAM की कीमतें कम हो सकती थीं, या बस अन्य विचार हैं जो MTU को प्रभावित करते हैं।

अब, इस परिदृश्य पर विचार करें: मशीन A मशीन B को पैकेट भेजना चाहती है। यह पैकेट 1800 बाइट्स लंबा है। A के दृष्टिकोण से, कोई समस्या नहीं है क्योंकि इसका नेटवर्क इस आकार के पैकेट का समर्थन करता है। मशीन A पैकेट ट्रांसमिट करती है।

जब राउटर इस पैकेट को प्राप्त करता है, तो यह एक समस्या का सामना करता है: यह केवल पैकेट को B के नेटवर्क पर फॉरवर्ड नहीं कर सकता क्योंकि पैकेट नेटवर्क के MTU के लिए बहुत बड़ा है। राउटर को पैकेट को फ्रैगमेंट करना होगा - इसे 1500 बाइट्स तक के छोटे टुकड़ों में विभाजित करना होगा, जिन्हें मशीन B द्वारा पुनः असेंबल किया जाएगा।

IP में फ्रैगमेंटेशन कैसे काम करता है

आइए परिदृश्य की आगे जांच करें। राउटर को 1800 बाइट्स के IP पैकेट को दो फ्रैगमेंट्स में विभाजित करने की आवश्यकता है, प्रत्येक में अधिकतम 1500 बाइट्स। यदि मशीन A मशीन B को 1800 बाइट्स का एक और पैकेट भेजती है, तो राउटर को उसे भी विभाजित करना होगा - जिसके परिणामस्वरूप चार अलग-अलग फ्रैगमेंट्स होंगे जिन्हें दो अलग-अलग पैकेट्स में पुनः असेंबल किया जाएगा।

जब मशीन B इन फ्रैगमेंट्स को प्राप्त करती है, तो उसे यह सुनिश्चित करना होगा कि वह पैकेट A के फ्रैगमेंट #1 को पैकेट A के फ्रैगमेंट #2 के साथ, और पैकेट B के फ्रैगमेंट #1 को पैकेट B के फ्रैगमेंट #2 के साथ पुनः असेंबल करे - और नहीं, उदाहरण के लिए, पैकेट A के फ्रैगमेंट #1 को पैकेट B के फ्रैगमेंट #2 के साथ। उसे सही क्रम में फ्रैगमेंट्स को भी पुनः असेंबल करना होगा - ताकि पैकेट की संरचना #1#2 हो न कि #2#1।

आइडेंटिफिकेशन फील्ड

पहले, यह सुनिश्चित करने पर ध्यान केंद्रित करें कि मशीन B एक ही पैकेट के फ्रैगमेंट्स को पुनः असेंबल करे (उदाहरण के लिए, उपरोक्त उदाहरण में पैकेट A के फ्रैगमेंट #1 और फ्रैगमेंट #2, बजाय पैकेट A के फ्रैगमेंट #1 और पैकेट B के फ्रैगमेंट #2 के)। यह IPv4 के आइडेंटिफिकेशन फील्ड का उपयोग करके प्राप्त किया जाता है। एक ही पैकेट से संबंधित फ्रैगमेंट्स का समान आइडेंटिफिकेशन मान होगा। उदाहरण के लिए, पैकेट A के दोनों फ्रैगमेंट्स का आइडेंटिफिकेशन 100 पर सेट हो सकता है, और पैकेट B के दोनों फ्रैगमेंट्स का आइडेंटिफिकेशन 200 हो सकता है।

यह ध्यान रखना महत्वपूर्ण है कि आइडेंटिफिकेशन मान साझा करना फ्रैगमेंट्स के एक ही पैकेट से संबंधित होने के लिए पर्याप्त नहीं है। एक ही पैकेट के फ्रैगमेंट्स को यह भी साझा करना होगा:

• समान स्रोत IP एड्रेस

• समान गंतव्य IP एड्रेस

• समान प्रोटोकॉल मान (यह दर्शाता है कि पेलोड TCP, UDP, आदि है)

फ्रैगमेंट ऑफसेट

चूंकि IP एक कनेक्शनलेस प्रोटोकॉल है, इस बात की कोई गारंटी नहीं है कि फ्रैगमेंट्स मशीन B पर सही क्रम में पहुंचेंगे। पैकेट A का फ्रैगमेंट #2 फ्रैगमेंट #1 से पहले पहुंच सकता है। इस समस्या को संभालने के लिए, प्रत्येक फ्रैगमेंट एक Offset फील्ड ले जाता है, जो मूल पैकेट की शुरुआत से ऑफसेट को दर्शाता है।

Offset फील्ड में 13 बिट्स होते हैं, जिसका अर्थ है कि यह 0 से 8191 (2^13-1) तक के मान ले जा सकता है। यह एक संभावित समस्या पैदा करता है, क्योंकि IP पैकेट का अधिकतम आकार 65,535 बाइट्स हो सकता है (चूंकि IP हेडर का Total Length फील्ड 16 बिट्स का होता है)।

इस सीमा को संबोधित करने के लिए, Offset फील्ड में एन्कोडेड मान वास्तव में 8 (2^3) से गुणा किया जाता है। इसका अर्थ है कि फ्रैगमेंट का न्यूनतम आकार 8 बाइट्स है, अंतिम फ्रैगमेंट के अपवाद के साथ।

❓ IP पैकेट बाइट्स में ऑफसेट के बजाय 8 से विभाजित ऑफसेट क्यों ले जाते हैं?🤔

जबकि सीक्वेंस नंबर का उपयोग सरल लग सकता है, यह समस्या पैदा करेगा जब पैकेट्स को कई बार फ्रैगमेंट करने की आवश्यकता होगी।

उदाहरण के लिए, यदि कंप्यूटर A पहले राउटर को पैकेट भेजता है, जो इसे 1480 बाइट्स और 320 बाइट्स के टुकड़ों में फ्रैगमेंट करता है, और फिर इन फ्रैगमेंट्स को एक अन्य राउटर को भेजा जाता है जिसे उन्हें और भी छोटे टुकड़ों में फ्रैगमेंट करने की आवश्यकता होती है, तो आप उन्हें कैसे नंबर देंगे?

बाइट ऑफसेट के साथ, समाधान सीधा है - यदि पहले फ्रैगमेंट का ऑफसेट 0 है और अगले का ऑफसेट 1480 है, तो यदि हमें उन्हें अधिकतम 800-बाइट फ्रैगमेंट्स में विभाजित करने की आवश्यकता है, तो हमारे पास होगा:

• पहला फ्रैगमेंट: 800 बाइट्स ऑफसेट 0 के साथ

• दूसरा फ्रैगमेंट: 680 बाइट्स ऑफसेट 800 के साथ

• तीसरा फ्रैगमेंट: 320 बाइट्स ऑफसेट 1480 के साथ

मोर फ्रैगमेंट्स और डोंट फ्रैगमेंट फ्लैग्स

जब मशीन B एक फ्रैगमेंट प्राप्त करती है, तो उसे यह जानने की आवश्यकता होती है कि यह स्वयं में एक पूरा पैकेट है या उसे अतिरिक्त फ्रैगमेंट्स की उम्मीद करनी चाहिए। इस उद्देश्य के लिए, प्रत्येक IP फ्रैगमेंट एक More Fragments (MF) बिट ले जाता है जो पैकेट के अंतिम फ्रैगमेंट नहीं होने वाले हर फ्रैगमेंट के लिए 1 पर सेट होता है। अंतिम फ्रैगमेंट के लिए, यह 0 पर सेट होता है।

यदि पैकेट में एक ही फ्रैगमेंट होता है - MF बिट 0 पर सेट होगा, और ऑफसेट फील्ड भी 0 का मान रखेगा (यानी, 13 बिट्स 0s)।

फ्रैगमेंटेशन से संबंधित एक अन्य बिट Don't Fragment (DF) बिट है। जब यह फ्लैग ऑन होता है, तो इंटरमीडिएट डिवाइसेज को मूल पैकेट को फ्रैगमेंट नहीं करना चाहिए, भले ही यह MTU से अधिक हो। इसके बजाय, उन्हें इसे ड्रॉप करना चाहिए और आमतौर पर स्रोत को ICMP "Fragmentation Needed" संदेश वापस भेजना चाहिए।

हमारे उदाहरण में, यदि मशीन A Don't Fragment बिट को 1 पर सेट करती है, तो राउटर पैकेट को ड्रॉप कर देगा, और मशीन A को इसके बारे में सूचित करेगा।

ध्यान दें कि आइडेंटिफिकेशन फील्ड के ठीक बाद और DF फ्लैग से पहले, एक रिजर्व्ड बिट है जो 0 पर सेट है। यह बिट भविष्य में किसी अज्ञात कारण के लिए रिजर्व्ड था, जो IPv4 के मूल लेखकों को पता नहीं था।

फ्रैगमेंटेशन उदाहरण

फिर से हमारे उपरोक्त उदाहरण पर विचार करें - मशीन A के साथ एक नेटवर्क में जहां MTU 2000 है, और मशीन B एक नेटवर्क में जहां MTU 1500 है। मशीन A एक पैकेट भेजती है जो 1800 बाइट्स लंबा है।

❓ क्या आप इन तालिकाओं में मान भर सकते हैं?

पहला फ्रैगमेंट:

दूसरा फ्रैगमेंट:

उपरोक्त उदाहरण के लिए, IP में प्रासंगिक फ्रैगमेंटेशन फील्ड्स के मान निम्नानुसार होंगे:

पहला फ्रैगमेंट:

• Total Length: 1500 (IP हेडर के 20 बाइट्स सहित, इसलिए 1480 बाइट्स पेलोड)

• Identification: 1337 (मनमाना मान)

• Don't Fragment बिट: 0 (ऑफ, यदि आवश्यक हो तो आगे फ्रैगमेंटेशन की अनुमति देने के लिए)

• More Fragments बिट: 1 (ऑन, क्योंकि यह अंतिम फ्रैगमेंट नहीं है)

• Offset: 0 (यह पहला फ्रैगमेंट है)

दूसरा फ्रैगमेंट:

• Total Length: 340 (IP हेडर के 20 बाइट्स सहित, इसलिए 320 बाइट्स पेलोड - पहले फ्रैगमेंट के साथ, हम 1800 बाइट्स पेलोड तक पहुंचते हैं)

• Identification: 1337 (पहले फ्रैगमेंट के समान, यह दर्शाता है कि वे एक साथ संबंधित हैं)

• Don't Fragment बिट: 0 (ऑफ, यदि आवश्यक हो तो आगे फ्रैगमेंटेशन की अनुमति देने के लिए)

• More Fragments बिट: 0 (ऑफ, क्योंकि यह अंतिम फ्रैगमेंट है)

• Offset: 185 (1480/8 = 185, या हेक्साडेसिमल में 0xB9)

IPv4 फ्रैगमेंटेशन - सारांश

अब आपने IPv4 हेडर के अंतिम भाग: फ्रैगमेंटेशन के बारे में सीखा है। फ्रैगमेंटेशन IP पैकेट्स को विभिन्न MTUs वाले नेटवर्क में यात्रा करने की अनुमति देने के लिए आवश्यक है। IPv4 हेडर में फ्रैगमेंटेशन का समर्थन करने के लिए विशेष रूप से डिज़ाइन किए गए कई फील्ड्स शामिल हैं:

• Identification (16 बिट्स): पहचानता है कि कौन से फ्रैगमेंट एक साथ संबंधित हैं

• Flags (3 बिट्स): "More Fragments" और "Don't Fragment" फ्लैग्स सहित

• Fragment Offset (13 बिट्स): दर्शाता है कि यह फ्रैगमेंट मूल पैकेट में कहां से संबंधित है

इस ज्ञान के साथ, अब आप IPv4 हेडर के हर बिट और बाइट को समझते हैं और कैसे IP पैकेट विभिन्न विशेषताओं वाले नेटवर्क को पार कर सकते हैं।

सारांश - IPv4

IPv4 के लिए इस व्यापक गाइड में, आपने इंटरनेट संचार के मौलिक बिल्डिंग ब्लॉक्स के बारे में सीखा। आइए कवर की गई प्रमुख अवधारणाओं का पुनर्कथन करें:

एड्रेसिंग और नेटवर्क संरचना

• IPv4 एड्रेस 32-बिट संख्याएं हैं जिन्हें आमतौर पर डॉटेड डेसीमल नोटेशन में लिखा जाता है

• नेटवर्क की पहचान विभिन्न तरीकों से की जा सकती है:

  • फिक्स्ड-लेंथ दृष्टिकोण (ऐतिहासिक रूप से)

  • क्लासफुल एड्रेसिंग (A, B, C, D, E क्लासेस)

  • CIDR (आधुनिक दृष्टिकोण जो लचीले नेटवर्क आकार की अनुमति देता है)

• विशेष एड्रेस विशिष्ट उद्देश्यों की पूर्ति करते हैं:

  • 0.0.0.0 "इस होस्ट" के लिए

  • 127.0.0.0/8 लूपबैक के लिए

  • 255.255.255.255 ब्रॉडकास्ट के लिए

• हेडर में पैकेट रूटिंग और प्रोसेसिंग के लिए महत्वपूर्ण फील्ड्स होते हैं:

  • हेडर व्याख्या के लिए Version और IHL

  • ट्रैफिक प्राथमिकता के लिए Type of Service

  • पैकेट साइज के लिए Total Length

  • फ्रैगमेंटेशन कंट्रोल के लिए विभिन्न फील्ड्स

  • अनंत रूटिंग लूप को रोकने के लिए TTL

  • एनकैप्सुलेटेड प्रोटोकॉल की पहचान के लिए Protocol

  • एरर डिटेक्शन के लिए Checksum

  • स्रोत और गंतव्य एड्रेस

फ्रैगमेंटेशन

• IPv4 पैकेट्स को विभिन्न MTUs वाले नेटवर्क में पार करने की अनुमति देता है

• तीन प्रमुख फील्ड्स का उपयोग करता है:

  • फ्रैगमेंट्स को ग्रुप करने के लिए Identification

  • फ्रैगमेंटेशन को नियंत्रित करने के लिए Flags

  • पैकेट्स को पुनः असेंबल करने के लिए Fragment Offset

अंतिम शब्द

जबकि IPv4 की सीमाएं हैं, विशेष रूप से इसके एड्रेस स्पेस की बाधाएं, इसके सुरुचिपूर्ण डिजाइन और मजबूत फीचर्स ने इसे चार दशकों से अधिक समय तक इंटरनेट की रीढ़ बने रहने की अनुमति दी है। IPv4 को समझना मॉडर्न नेटवर्क के साथ काम करने के लिए आवश्यक संदर्भ प्रदान करता है और IPv6 जैसे नए प्रोटोकॉल में संक्रमण में मदद करता है।

लेखक के बारे में

Omer Rosenbaum Swimm के Chief Technology Officer हैं। वे Brief YouTube Channel के लेखक हैं। वे एक साइबर ट्रेनिंग विशेषज्ञ और Checkpoint Security Academy के संस्थापक भी हैं। वे Gitting Things Done (अंग्रेजी में) और Computer Networks (हिब्रू में) के लेखक हैं। आप उन्हें Twitter पर पा सकते हैं।

अतिरिक्त संदर्भ

• Computer Networks Playlist - मेरे Brief चैनल पर

मुफ्त में कोड करना सीखें। freeCodeCamp के ओपन सोर्स करिकुलम ने 40,000 से अधिक लोगों को डेवलपर के रूप में नौकरी पाने में मदद की है। शुरू करें