সিসকো ট্রেনিং 200-125 CCNA v3.0. দিন 6: শূন্যস্থান পূরণ করা (DHCP, TCP, হ্যান্ডশেক, সাধারণ পোর্ট নম্বর)

আজকের ভিডিও টিউটোরিয়াল শুরু করার আগে, আমি YouTube-এ আমার কোর্সের জনপ্রিয়তায় অবদান রাখার জন্য সবাইকে ধন্যবাদ জানাতে চাই। প্রায় 8 মাস আগে যখন আমি এটি শুরু করেছি, আমি এমন সাফল্য আশা করিনি - আজ আমার পাঠ 312724 জন দেখেছে, আমার 11208 জন গ্রাহক রয়েছে। আমি স্বপ্নেও ভাবিনি যে এই বিনয়ী সূচনা এত উচ্চতায় পৌঁছে যাবে। তবে আসুন সময় নষ্ট না করে সরাসরি আজকের পাঠে চলে যাই। আজ আমরা শেষ 7টি ভিডিও পাঠে যে শূন্যস্থানগুলি ঘটেছে তা পূরণ করব। যদিও আজ মাত্র 6 তম দিন, দিন 3টি 3টি ভিডিও পাঠে বিভক্ত করা হয়েছিল, তাই আজ আপনি আসলে অষ্টম ভিডিও পাঠটি দেখতে পাবেন।

আজ আমরা 3টি গুরুত্বপূর্ণ বিষয় কভার করব: DHCP, TCP পরিবহন এবং সবচেয়ে সাধারণ পোর্ট নম্বর। আমরা ইতিমধ্যেই IP ঠিকানা সম্পর্কে কথা বলেছি, এবং IP ঠিকানা কনফিগারেশনের সবচেয়ে গুরুত্বপূর্ণ কারণগুলির মধ্যে একটি হল DHCP।

DHCP হল ডায়নামিক হোস্ট কনফিগারেশন প্রোটোকল এবং এটি একটি প্রোটোকল যা হোস্টের জন্য আইপি ঠিকানাগুলি গতিশীলভাবে কনফিগার করতে সহায়তা করে। তাই আমরা সব এই উইন্ডো দেখেছি. আপনি যখন "স্বয়ংক্রিয়ভাবে একটি আইপি ঠিকানা প্রাপ্ত করুন" বিকল্পে ক্লিক করেন, কম্পিউটারটি একই সাবনেটে কনফিগার করা একটি ডিএইচসিপি সার্ভারের সন্ধান করে এবং আইপি ঠিকানার জন্য বিভিন্ন প্যাকেট এবং অনুরোধ পাঠায়। DHCP প্রোটোকলটিতে 6টি বার্তা রয়েছে, যার মধ্যে 4টি একটি IP ঠিকানা নির্ধারণের জন্য গুরুত্বপূর্ণ।

প্রথম বার্তাটি একটি DHCP আবিষ্কার বার্তা৷ DHCP আবিষ্কার বার্তা একটি অভিবাদন বার্তার অনুরূপ। যখন একটি নতুন ডিভাইস নেটওয়ার্কে যোগদান করে, তখন এটি জিজ্ঞাসা করে যে নেটওয়ার্কে একটি DHCP সার্ভার আছে কিনা।

আপনি স্লাইডে যা দেখছেন তা একটি সম্প্রচার অনুরোধের মতো দেখায় যেখানে ডিভাইসটি নেটওয়ার্কের সমস্ত ডিভাইসের সাথে যোগাযোগ করে যা একটি DHCP সার্ভার খুঁজছে৷ আমি যেমন বলেছি, এটি একটি সম্প্রচার অনুরোধ, তাই নেটওয়ার্কের সমস্ত ডিভাইস এটি শুনতে পারে৷

নেটওয়ার্কে একটি DHCP সার্ভার থাকলে, এটি একটি প্যাকেট পাঠায় - একটি DHCP অফার অফার৷ প্রস্তাবের অর্থ হল ডিএইচসিপি সার্ভার, একটি আবিষ্কারের অনুরোধের প্রতিক্রিয়া হিসাবে, ক্লায়েন্টকে একটি কনফিগারেশন পাঠায়, ক্লায়েন্টকে একটি নির্দিষ্ট আইপি ঠিকানা গ্রহণ করতে বলে।

DHCP সার্ভার একটি IP ঠিকানা সংরক্ষণ করে, এই ক্ষেত্রে 192.168.1.2, এটি প্রদান করে না, বরং ডিভাইসের জন্য এই ঠিকানাটি সংরক্ষণ করে। একই সময়ে, অফার প্যাকেজে DHCP সার্ভারের নিজস্ব IP ঠিকানা রয়েছে।

যদি এই নেটওয়ার্কে একাধিক DHCP সার্ভার থাকে, অন্য DHCP সার্ভার, ক্লায়েন্টের সম্প্রচারের অনুরোধ পাওয়ার পরে, এটিকে তার IP ঠিকানাও অফার করবে, উদাহরণস্বরূপ, 192.168.1.50। একই নেটওয়ার্কে দুটি ভিন্ন DHCP সার্ভার কনফিগার করা সাধারণ নয়, তবে কখনও কখনও এটি ঘটে। তাই যখন একটি DHCP অফার একজন ক্লায়েন্টকে পাঠানো হয়, তখন এটি 2টি DHCP অফার পায় এবং এখনই সিদ্ধান্ত নিতে হবে যে এটি কোন DHCP অফারটি গ্রহণ করতে চায়।

ধরা যাক ক্লায়েন্ট প্রথম আবেদন গ্রহণ করেছে। এর মানে হল যে ক্লায়েন্ট একটি DHCP অনুরোধ অনুরোধ পাঠায় যা আক্ষরিকভাবে বলে "আমি DHCP সার্ভার 192.168.1.2 দ্বারা প্রস্তাবিত আইপি ঠিকানা 192.168.1.1 গ্রহণ করি।"

অনুরোধ প্রাপ্তির পর, 192.168.1.1 DHCP সার্ভার "ঠিক আছে, আমি স্বীকার করছি" সাড়া দেয়, অর্থাৎ, এটি অনুরোধটি স্বীকার করে এবং এই DHCP ACK ক্লায়েন্টকে পাঠায়। কিন্তু আমরা মনে রাখি যে অন্য DHCP সার্ভার ক্লায়েন্টের জন্য 1.50 এর একটি IP ঠিকানা সংরক্ষিত করেছে। একবার এটি একটি ক্লায়েন্টের সম্প্রচারের অনুরোধ গ্রহণ করলে, এটি ব্যর্থতা সম্পর্কে জানবে এবং সেই আইপি ঠিকানাটিকে পুলে ফিরিয়ে দেবে যাতে এটি অন্য ক্লায়েন্টকে অন্য অনুরোধ গ্রহণ করলে এটিকে বরাদ্দ করতে পারে।

এই 4টি গুরুত্বপূর্ণ বার্তা যা DHCP আইপি ঠিকানা নির্ধারণ করার সময় বিনিময় করে। পরবর্তী, DHCP-এর আরও 2টি তথ্য বার্তা রয়েছে৷ একটি তথ্য বার্তা ক্লায়েন্ট দ্বারা জারি করা হয় যদি দ্বিতীয় ধাপে DHCP অফার ক্লজে প্রাপ্ত তথ্যের চেয়ে বেশি তথ্যের প্রয়োজন হয়। সার্ভার যদি DHCP অফারে পর্যাপ্ত তথ্য প্রদান না করে, অথবা যদি ক্লায়েন্টের অফার প্যাকেটে থাকা তথ্যের চেয়ে বেশি তথ্যের প্রয়োজন হয়, তাহলে এটি অতিরিক্ত DHCP তথ্যের অনুরোধ করে। আরও একটি বার্তা রয়েছে যা ক্লায়েন্ট সার্ভারে পাঠায় - এটি হল DHCP রিলিজ। এটি আপনাকে জানায় যে ক্লায়েন্ট তার বিদ্যমান আইপি ঠিকানা প্রকাশ করতে চায়।

যাইহোক, প্রায়শই যা ঘটে তা হল ক্লায়েন্ট সার্ভারে একটি DHCP রিলিজ পাঠানোর সময় পাওয়ার আগেই ব্যবহারকারী নেটওয়ার্ক থেকে সংযোগ বিচ্ছিন্ন করে। আপনি কম্পিউটার বন্ধ করলে এটি ঘটে, যা আমরা করি। এই ক্ষেত্রে, নেটওয়ার্ক ক্লায়েন্ট, বা কম্পিউটারের, ব্যবহৃত ঠিকানা প্রকাশ করার জন্য সার্ভারকে জানানোর সময় নেই, তাই DHCP রিলিজ একটি প্রয়োজনীয় পদক্ষেপ নয়। একটি আইপি ঠিকানা পাওয়ার প্রয়োজনীয় পদক্ষেপগুলি হল: DHCP আবিষ্কার, DHCP অফার, DHCP অনুরোধ এবং DHCP হ্যান্ডশেক৷

পরবর্তী পাঠগুলির মধ্যে একটিতে আমি আপনাকে বলব কিভাবে আমরা একটি DNCP পুল তৈরি করার সময় একটি DHCP সার্ভার কনফিগার করি। পুলিং দ্বারা আমরা বোঝাতে চাই যে আপনি সার্ভারকে 192.168.1.1 থেকে 192.168.1.254 রেঞ্জের মধ্যে IP ঠিকানা বরাদ্দ করতে বলবেন। এইভাবে, DHCP সার্ভার একটি পুল তৈরি করবে, এতে 254টি আইপি ঠিকানা রাখবে এবং শুধুমাত্র এই পুল থেকে নেটওয়ার্কে ক্লায়েন্টদের ঠিকানা বরাদ্দ করতে সক্ষম হবে। তাই এটি একটি প্রশাসনিক সেটিং মত কিছু যে ব্যবহারকারী করতে পারেন.

এখন আসুন TCP ট্রান্সমিশন দেখি। আমি জানি না আপনি ছবিতে চিত্রিত "টেলিফোন" এর সাথে পরিচিত কিনা, তবে আমরা যখন শিশু ছিলাম তখন আমরা একে অপরের সাথে কথা বলার জন্য একটি স্ট্রিং দ্বারা সংযুক্ত এই টিনের ক্যানগুলি ব্যবহার করতাম।

দুর্ভাগ্যবশত, আজকের প্রজন্ম এই ধরনের "বিলাসিতা" বহন করতে পারে না। আমি বলতে চাচ্ছি যে আজ বাচ্চারা এক বছর বয়স থেকে টিভির সামনে, তারা পিএসপি খেলে এবং সম্ভবত এটি বিতর্কিত কিন্তু আমি মনে করি আমাদের শৈশব সেরা ছিল, আমরা আসলে বাইরে গিয়ে গেম খেলতাম এবং আজকের বাচ্চাদের সোফা থেকে দূরে টেনে নেওয়া যায় না .

আমার ছেলের বয়স মাত্র এক বছর এবং আমি ইতিমধ্যে দেখতে পাচ্ছি যে সে আইপ্যাডে আসক্ত, আমি বলতে চাচ্ছি যে সে এখনও খুব ছোট কিন্তু আমি মনে করি যে আজকের শিশুরা ইতিমধ্যেই ইলেকট্রনিক গ্যাজেটগুলি কীভাবে পরিচালনা করতে হয় তা জেনে জন্ম নিয়েছে। তাই, আমি বলতে চেয়েছিলাম যে ছোটবেলায়, আমরা যখন খেলতাম, আমরা টিনের ক্যানে গর্ত করতাম, এবং যখন আমরা একটি স্ট্রিং দিয়ে বেঁধে একটি ক্যানে কিছু বলতাম, তখন অন্য প্রান্তে লোকটি শুনতে পায় যা বলা হচ্ছে। তার কাছে, কেবল তার কানের কাছে ক্যানটি রেখে। সুতরাং এটি একটি নেটওয়ার্ক সংযোগের অনুরূপ।

আজ, এমনকি TCP স্থানান্তরের একটি সংযোগ থাকতে হবে যা প্রকৃত ডেটা স্থানান্তর শুরু হওয়ার আগে অবশ্যই স্থাপন করতে হবে। যেমনটি আমরা পূর্ববর্তী পাঠে আলোচনা করেছি, TCP হল সংযোগ-ভিত্তিক ট্রান্সমিশন যখন UDP হল সংযোগ-ভিত্তিক ট্রান্সমিশন। আপনি বলতে পারেন যে UDP যেখানে আমি বল নিক্ষেপ করি এবং আপনি এটি ধরতে পারেন কিনা তা আপনার ব্যাপার। আপনি এটি করতে প্রস্তুত কিনা তা আমার সমস্যা নয়, আমি কেবল তাকে ছেড়ে চলে যাচ্ছি।

TCP অনেকটা এমন যে আপনি একজন লোকের সাথে কথা বলছেন এবং তাকে আগাম সতর্ক করেছেন যে আপনি একটি বল ছুঁড়তে চলেছেন, তাই আপনি একটি বন্ধন তৈরি করেন এবং তারপর আপনি বলটি ছুঁড়ে দেন যাতে আপনার সঙ্গী এটি ধরার জন্য প্রস্তুত হওয়ার সম্ভাবনা বেশি থাকে। তাই TCP আসলে সংযোগ তৈরি করে এবং তারপর প্রকৃত ট্রান্সমিশন করা শুরু করে।

আসুন দেখি কিভাবে এটি এমন একটি সংযোগ তৈরি করে। এই প্রোটোকল একটি সংযোগ তৈরি করতে একটি 3-উপায় হ্যান্ডশেক ব্যবহার করে। এটি একটি খুব প্রযুক্তিগত শব্দ নয়, তবে এটি দীর্ঘকাল ধরে একটি TCP সংযোগ বর্ণনা করতে ব্যবহৃত হয়েছে। ক্লায়েন্ট সার্ভারে একটি SYN পতাকা সহ একটি প্যাকেট প্রেরণের সাথে একটি 3-উপায় হ্যান্ডশেক প্রেরণকারী ডিভাইস দ্বারা শুরু হয়।

ধরা যাক যে সামনের অংশে থাকা মেয়েটি, যার মুখটি আমরা দেখতে পাচ্ছি, সেটি হল ডিভাইস A, এবং ব্যাকগ্রাউন্ডের মেয়েটি, যার মুখ দৃশ্যমান নয়, সেটি হল B ডিভাইস। মেয়ে A একটি SYN প্যাকেট মেয়ে B কে পাঠায় এবং সে বলে: "দারুণ, কে- তাহলে সে আমার সাথে যোগাযোগ করতে চায়। সুতরাং, আমাকে উত্তর দিতে হবে যে আমি যোগাযোগের জন্য প্রস্তুত!" এটা কিভাবে করতে হবে? কেউ কেবল আরেকটি SYN প্যাকেট ফেরত পাঠাতে পারে এবং তারপরে একটি ACK নির্দেশ করে আসল SYN প্যাকেটের রসিদ। কিন্তু আলাদাভাবে ACK পাঠানোর পরিবর্তে, সার্ভার SYN এবং ACK সম্বলিত একটি সাধারণ প্যাকেট তৈরি করে এবং নেটওয়ার্কের মাধ্যমে তা প্রেরণ করে।

তাই এই মুহুর্তে, ডিভাইস A একটি SYN প্যাকেট পাঠিয়েছে এবং একটি SYN/ACK প্যাকেট ফেরত পেয়েছে। এখন ডিভাইস A অবশ্যই ডিভাইস B কে একটি ACK প্যাকেট পাঠাতে হবে, অর্থাৎ নিশ্চিত করুন যে এটি যোগাযোগ স্থাপনের জন্য ডিভাইস B থেকে সম্মতি পেয়েছে। এইভাবে, উভয় ডিভাইসই SYN এবং ACK প্যাকেট পেয়েছে এবং এখন আমরা বলতে পারি যে সংযোগটি প্রতিষ্ঠিত হয়েছে, অর্থাৎ, TCP প্রোটোকল ব্যবহার করে একটি 3-পর্যায়ের হ্যান্ডশেক সম্পন্ন হয়েছে।

পরবর্তীতে আমরা TCP Windowing প্রযুক্তি দেখব। সহজ কথায়, এটি প্রেরক এবং প্রাপকের ক্ষমতা নিয়ে আলোচনা করার জন্য TCP/IP-এ ব্যবহৃত একটি পদ্ধতি।

ধরা যাক যে উইন্ডোজে আমরা একটি বড় ফাইল স্থানান্তর করার চেষ্টা করছি, বলুন 2 জিবি সাইজ, এক ড্রাইভ থেকে অন্য ড্রাইভে। ট্রান্সফারের একদম শুরুতে, সিস্টেম আমাদের জানিয়ে দেবে যে ফাইল ট্রান্সফার হতে প্রায় 1 বছর সময় লাগবে। কিন্তু কয়েক সেকেন্ড পরে সিস্টেমটি নিজেকে সংশোধন করবে এবং বলবে: "ওহ, এক মিনিট অপেক্ষা করুন, আমি মনে করি এটি প্রায় 6 মাস সময় নেবে, এক বছর নয়।" আরও কিছু সময় কেটে যাবে এবং উইন্ডোজ বলবে: "আমি মনে করি আমি 1 মাসের মধ্যে ফাইল স্থানান্তর করতে সক্ষম হতে পারি।" এর পরে "1 দিন", "6 ঘন্টা", "3 ঘন্টা", "1 ঘন্টা", "20 মিনিট", "10 মিনিট", "3 মিনিট" বার্তা আসবে। প্রকৃতপক্ষে, সম্পূর্ণ ফাইল স্থানান্তর প্রক্রিয়া মাত্র 3 মিনিট সময় লাগবে। এটা কিভাবে ঘটলো? প্রাথমিকভাবে, যখন আপনার ডিভাইস অন্য ডিভাইসের সাথে যোগাযোগ করার চেষ্টা করে, তখন এটি একটি প্যাকেট পাঠায় এবং নিশ্চিতকরণের জন্য অপেক্ষা করে। যদি ডিভাইসটি নিশ্চিতকরণের জন্য দীর্ঘ সময় অপেক্ষা করে, তবে এটি মনে করে: "যদি আমাকে এই গতিতে 2 জিবি ডেটা স্থানান্তর করতে হয় তবে এটি প্রায় 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 প্যাকেট পাঠান এবং ধীরে ধীরে সেই উইন্ডোটি আরও বেশি করে খুলুন যতক্ষণ না "খোলা" নির্দিষ্ট সময়ের মধ্যে প্রেরিত ট্রাফিকের সর্বাধিক সম্ভাব্য পরিমাণে পৌঁছায়। এইভাবে, Windowing ধারণাটি TCP প্রোটোকলের অপারেশনের অংশ।

পরবর্তীতে আমরা সবচেয়ে সাধারণ পোর্ট নম্বরগুলি দেখব। ক্লাসিক পরিস্থিতি হল যখন আপনার 1টি প্রধান সার্ভার থাকে, সম্ভবত একটি ডেটা সেন্টার। এতে একটি ফাইল সার্ভার, ওয়েব সার্ভার, মেল সার্ভার এবং DHCP সার্ভার অন্তর্ভুক্ত রয়েছে। এখন, যদি ক্লায়েন্ট কম্পিউটারগুলির মধ্যে একটি ডেটা সেন্টারের সাথে যোগাযোগ করে, যা ছবির মাঝখানে অবস্থিত, এটি ক্লায়েন্ট ডিভাইসগুলিতে ফাইল সার্ভার ট্র্যাফিক পাঠাতে শুরু করবে। এই ট্র্যাফিকটি লাল রঙে দেখানো হয়েছে এবং একটি নির্দিষ্ট সার্ভার থেকে একটি নির্দিষ্ট অ্যাপ্লিকেশনের জন্য একটি নির্দিষ্ট পোর্টে প্রেরণ করা হবে।

সার্ভার কিভাবে জানলো যে নির্দিষ্ট ট্রাফিক কোথায় যেতে হবে? তিনি এটি গন্তব্য পোর্ট নম্বর থেকে শিখেছেন। আপনি যদি ফ্রেমটি দেখেন তবে আপনি দেখতে পাবেন যে প্রতিটি ডেটা স্থানান্তরে গন্তব্য পোর্ট নম্বর এবং উত্স পোর্ট নম্বর উল্লেখ রয়েছে। আপনি দেখতে পারেন যে নীল এবং লাল ট্র্যাফিক, এবং নীল ট্র্যাফিক হল ওয়েব সার্ভার ট্র্যাফিক, উভয়ই একই শারীরিক সার্ভারে যায়, যেখানে বিভিন্ন সার্ভার ইনস্টল করা আছে। যদি এটি একটি ডেটা সেন্টার হয়, তাহলে এটি ভার্চুয়াল সার্ভার ব্যবহার করে। তাহলে তারা কীভাবে জানল যে লাল ট্র্যাফিকটি সেই আইপি ঠিকানার সাথে সেই বাম ল্যাপটপে ফিরে যাওয়ার কথা ছিল? তারা পোর্ট নম্বরের জন্য এই ধন্যবাদ জানে। আপনি যদি উইকিপিডিয়া নিবন্ধটি উল্লেখ করেন "TCP এবং UDP পোর্টের তালিকা", আপনি দেখতে পাবেন যে এটি সমস্ত স্ট্যান্ডার্ড পোর্ট নম্বর তালিকাভুক্ত করে।

আপনি যদি এই পৃষ্ঠাটি নীচে স্ক্রোল করেন তবে আপনি দেখতে পাবেন এই তালিকাটি কত বড়। এতে প্রায় ৬১,০০০ সংখ্যা রয়েছে। 61 থেকে 000 পর্যন্ত পোর্ট নম্বরগুলি সবচেয়ে সাধারণ পোর্ট নম্বর হিসাবে পরিচিত। উদাহরণস্বরূপ, পোর্ট 1/TCP হল ftp কমান্ড পাঠানোর জন্য, পোর্ট 1024 হল ssh এর জন্য, পোর্ট 21 হল টেলনেটের জন্য, অর্থাৎ এনক্রিপ্ট করা বার্তা পাঠানোর জন্য৷ খুব জনপ্রিয় পোর্ট 22 HTTP-এর মাধ্যমে ডেটা বহন করে, যখন পোর্ট 23 HTTPS-এর মাধ্যমে এনক্রিপ্ট করা ডেটা বহন করে, যা HTTP-এর সুরক্ষিত সংস্করণের মতো।
কিছু পোর্ট টিসিপি এবং ইউডিপি উভয়ের জন্য নিবেদিত, এবং কিছু সংযোগটি টিসিপি বা ইউডিপি কিনা তার উপর নির্ভর করে বিভিন্ন কাজ করে। সুতরাং, আনুষ্ঠানিকভাবে TCP পোর্ট 80 HTTP-র জন্য ব্যবহৃত হয়, এবং অনানুষ্ঠানিকভাবে UDP পোর্ট 80 HTTP-র জন্য ব্যবহৃত হয়, কিন্তু একটি ভিন্ন HTTP প্রোটোকলের অধীনে - QUIC।

তাই, TCP-এ পোর্ট নম্বরগুলি সবসময় UDP-এর মতো একই জিনিস করার উদ্দেশ্যে নয়। আপনাকে এই তালিকাটি হৃদয় দিয়ে শিখতে হবে না, এটি মনে রাখা অসম্ভব, তবে আপনাকে কিছু জনপ্রিয় এবং সবচেয়ে সাধারণ পোর্ট নম্বর জানতে হবে। আমি যেমন বলেছি, এই পোর্টগুলির মধ্যে কিছুর একটি অফিসিয়াল উদ্দেশ্য রয়েছে, যা মানদণ্ডে বর্ণিত আছে, এবং কিছুর একটি অনানুষ্ঠানিক উদ্দেশ্য রয়েছে, যেমনটি ক্রোমিয়ামের ক্ষেত্রে।

সুতরাং, এই টেবিলটি সমস্ত সাধারণ পোর্ট নম্বর তালিকাভুক্ত করে, এবং এই নম্বরগুলি নির্দিষ্ট অ্যাপ্লিকেশন ব্যবহার করার সময় ট্র্যাফিক পাঠাতে এবং গ্রহণ করতে ব্যবহৃত হয়।

এখন দেখা যাক আমরা যে সামান্য তথ্য জানি তার উপর ভিত্তি করে নেটওয়ার্ক জুড়ে ডেটা কীভাবে চলে। ধরা যাক যে কম্পিউটার 10.1.1.10 এই কম্পিউটার, বা এই সার্ভারের সাথে যোগাযোগ করতে চায়, যার ঠিকানা 30.1.1.10 আছে। প্রতিটি ডিভাইসের আইপি ঠিকানার নিচে তার MAC ঠিকানা রয়েছে। আমি শুধুমাত্র শেষ 4টি অক্ষর সহ একটি MAC ঠিকানার উদাহরণ দিচ্ছি, কিন্তু বাস্তবে এটি 48টি অক্ষর সহ একটি 12-বিট হেক্সাডেসিমেল সংখ্যা। যেহেতু এই সংখ্যাগুলির প্রতিটি 4 বিট নিয়ে গঠিত, তাই 12টি হেক্সাডেসিমেল সংখ্যা একটি 48-বিট সংখ্যাকে উপস্থাপন করে।

আমরা জানি, এই ডিভাইসটি যদি এই সার্ভারের সাথে যোগাযোগ করতে চায়, তাহলে 3-ওয়ে হ্যান্ডশেকের প্রথম ধাপটি প্রথমে করতে হবে, অর্থাৎ একটি SYN প্যাকেট পাঠানো। এই অনুরোধ করা হলে, কম্পিউটার 10.1.1.10 উৎস পোর্ট নম্বর নির্দিষ্ট করবে, যা উইন্ডোজ গতিশীলভাবে তৈরি করে। উইন্ডোজ এলোমেলোভাবে 1 থেকে 65,000 এর মধ্যে একটি পোর্ট নম্বর নির্বাচন করে। কিন্তু যেহেতু 1 থেকে 1024 পরিসরে শুরু হওয়া সংখ্যাগুলি ব্যাপকভাবে পরিচিত, এই ক্ষেত্রে সিস্টেমটি 25000-এর বেশি সংখ্যাগুলি বিবেচনা করবে এবং একটি র্যান্ডম সোর্স পোর্ট তৈরি করবে, উদাহরণস্বরূপ, 25113 নম্বর৷

এর পরে, সিস্টেমটি প্যাকেটে একটি গন্তব্য পোর্ট যুক্ত করবে, এই ক্ষেত্রে এটি 21 পোর্ট, কারণ যে অ্যাপ্লিকেশনটি এই FTP সার্ভারের সাথে সংযোগ করার চেষ্টা করছে সে জানে যে এটি FTP ট্র্যাফিক পাঠাবে।

এরপরে, আমাদের কম্পিউটার বলে, "ঠিক আছে, আমার IP ঠিকানা হল 10.1.1.10, এবং আমাকে IP ঠিকানা 30.1.1.10-এর সাথে যোগাযোগ করতে হবে৷" এই দুটি ঠিকানাও একটি SYN অনুরোধ তৈরি করার জন্য প্যাকেটে অন্তর্ভুক্ত করা হয়েছে, এবং সংযোগ শেষ না হওয়া পর্যন্ত এই প্যাকেটটি পরিবর্তন হবে না।

আমি চাই আপনি এই ভিডিও থেকে বুঝতে পারবেন কিভাবে ডেটা নেটওয়ার্ক জুড়ে চলে। যখন আমাদের কম্পিউটার অনুরোধ পাঠানোর উৎস আইপি ঠিকানা এবং গন্তব্য আইপি ঠিকানা দেখে, তখন এটি বুঝতে পারে যে গন্তব্য ঠিকানাটি সেই স্থানীয় নেটওয়ার্কে নেই। আমি বলতে ভুলে গেছি যে এইগুলি সব /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 ডেটা ইন্টিগ্রিটি চেক, যা ত্রুটি সনাক্ত করার জন্য একটি চেকসাম খুঁজে বের করার জন্য একটি অ্যালগরিদম, নেটওয়ার্ক ছেড়ে যাওয়ার আগে সঞ্চালিত হবে।
সাইক্লিক রিডানডেন্সি সিআরসি মানে এই পুরো ফ্রেমটি, SYN থেকে শেষ MAC ঠিকানা পর্যন্ত, একটি হ্যাশিং অ্যালগরিদমের মাধ্যমে চালিত হয়, বলুন MD5, যার ফলে একটি হ্যাশ মান। হ্যাশ মান, বা MD5 চেকসাম, তারপর ফ্রেমের শুরুতে স্থাপন করা হয়।

আমি এটিকে এফসিএস/সিআরসি লেবেল দিয়েছি কারণ এফসিএস একটি ফ্রেম চেক সিকোয়েন্স, একটি চার-বাইটের সিআরসি মান। কিছু লোক উপাধি এফসিএস ব্যবহার করে এবং কেউ উপাধি সিআরসি ব্যবহার করে, তাই আমি কেবল উভয় পদবি অন্তর্ভুক্ত করেছি। কিন্তু মূলত এটা শুধু একটি হ্যাশ মান. নেটওয়ার্কের মাধ্যমে প্রাপ্ত সমস্ত ডেটাতে ত্রুটি নেই তা নিশ্চিত করার জন্য এটি প্রয়োজন। অতএব, যখন এই ফ্রেমটি রাউটারে পৌঁছায়, রাউটারটি প্রথমে যা করবে তা হল চেকসাম নিজেই গণনা করা এবং প্রাপ্ত ফ্রেমে থাকা FCS বা CRC মানের সাথে তুলনা করা। এইভাবে তিনি চেক করতে পারেন যে নেটওয়ার্কে প্রাপ্ত ডেটাতে ত্রুটি নেই, তারপরে তিনি ফ্রেম থেকে চেকসামটি সরিয়ে ফেলবেন।

এর পরে, রাউটার MAC ঠিকানাটি দেখবে এবং বলবে, "ঠিক আছে, MAC ঠিকানা AAAA মানে ফ্রেমটি আমাকে সম্বোধন করা হয়েছে," এবং MAC ঠিকানাগুলি ধারণকারী ফ্রেমের অংশটি মুছে দিন।

গন্তব্য আইপি ঠিকানা 30.1.1.10 দেখে, তিনি বুঝতে পারবেন যে এই প্যাকেটটি তার ঠিকানা নয় এবং রাউটারের মাধ্যমে আরও যেতে হবে।

এখন রাউটার "মনে করে" যে এটি 30.1.1.10 ঠিকানা সহ নেটওয়ার্কটি কোথায় অবস্থিত তা দেখতে হবে। আমরা এখনও রাউটিংয়ের সম্পূর্ণ ধারণাটি কভার করিনি, তবে আমরা জানি যে রাউটারগুলির একটি রাউটিং টেবিল রয়েছে। এই টেবিলে 30.1.1.0 ঠিকানা সহ নেটওয়ার্কের জন্য একটি এন্ট্রি রয়েছে৷ আপনি মনে রাখবেন, এটি হোস্ট আইপি ঠিকানা নয়, কিন্তু নেটওয়ার্ক শনাক্তকারী। রাউটার "মনে করবে" যে এটি রাউটার 30.1.1.0 এর মাধ্যমে 24/20.1.1.2 ঠিকানায় পৌঁছাতে পারে।

আপনি জিজ্ঞাসা করতে পারেন, তিনি কীভাবে এটি জানেন? শুধু মনে রাখবেন যে এটি রাউটিং প্রোটোকল বা আপনার সেটিংস থেকে এটি জানতে পারবে যদি আপনি একজন প্রশাসক হিসাবে একটি স্ট্যাটিক রুট কনফিগার করেন। তবে যাই হোক না কেন, এই রাউটারের রাউটিং টেবিলে সঠিক এন্ট্রি রয়েছে, তাই এটি জানে যে এটি এই প্যাকেটটি 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 কোর) 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 Intel TetraDeca-Core 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 থেকে! সম্পর্কে পড়ুন কিভাবে ইনফ্রাস্ট্রাকচার কর্পোরেশন তৈরি করা যায়। এক পয়সার জন্য 730 ইউরো মূল্যের Dell R5xd E2650-4 v9000 সার্ভার ব্যবহার করে ক্লাস?

উত্স: www.habr.com