পাঠ ৩৩ · ৫৭-এর মধ্যে · মডিউল ৬

DHCP — ডায়নামিক হোস্ট কনফিগারেশন

DHCP — Dynamic Host Configuration Protocol
৭ মিনিট পড়া মধ্যবর্তী · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • DHCP সমাধান করে এমন সমস্যা — ম্যানুয়াল IP কনফিগারেশন কেন স্কেল করে না
  • DORA প্রক্রিয়ার চারটি ধাপ — Discover, Offer, Request, Acknowledge
  • লিজ টাইম ও রিনিউয়ালের ধারণা — কেন IP অ্যাড্রেস "ভাড়া দেওয়া" হয়, স্থায়ীভাবে বরাদ্দ করা হয় না
  • Python দিয়ে একটি শেয়ার্ড IP পুল থেকে একাধিক ক্লায়েন্টে DORA সিমুলেশন

১ · সমস্যা — প্রতিটি ডিভাইসের একটি IP দরকার

নেটওয়ার্কে যোগাযোগ করতে হলে প্রতিটি ডিভাইসের একটি IP অ্যাড্রেস (M4/L14), সাবনেট মাস্ক, ডিফল্ট গেটওয়ে এবং DNS সার্ভারের ঠিকানা (M6/L30) দরকার। প্রতিটি ডিভাইসে এগুলো হাতে বসিয়ে দেওয়া একটি ছোট নেটওয়ার্কে সম্ভব হলেও — শত শত ডিভাইসের অফিস, বা একটি কফি শপের WiFi-এ প্রতিদিন শত শত নতুন ফোন যোগ হওয়া — এই স্কেলে ম্যানুয়াল কনফিগারেশন বাস্তবিকভাবে অসম্ভব।

DHCPDynamic Host Configuration Protocolএকটি অ্যাপ্লিকেশন-লেয়ার প্রোটোকল যা নেটওয়ার্কে যোগদানকারী ডিভাইসগুলোকে স্বয়ংক্রিয়ভাবে IP অ্যাড্রেস ও অন্যান্য কনফিগারেশন বরাদ্দ করে। ঠিক এই সমস্যার সমাধান — নতুন কোনো ডিভাইস নেটওয়ার্কে যোগ দিলে DHCP সার্ভার স্বয়ংক্রিয়ভাবে তাকে একটি উপলব্ধ IP ও প্রয়োজনীয় সব কনফিগারেশন বরাদ্দ করে দেয়, কোনো মানুষের হস্তক্ষেপ ছাড়াই।

২ · DORA প্রক্রিয়া — চার ধাপে IP বরাদ্দ

DHCP ঠিক চারটি ধাপে কাজ করে, যাকে সংক্ষেপে DORA বলা হয় —

১. Discover
ক্লায়েন্ট পুরো নেটওয়ার্কে ব্রডকাস্ট করে — "কোনো DHCP সার্ভার আছে কি?"
২. Offer
একজন DHCP সার্ভার সাড়া দিয়ে একটি উপলব্ধ IP ও কনফিগারেশন প্রস্তাব করে।
৩. Request
ক্লায়েন্ট সেই নির্দিষ্ট প্রস্তাবিত IP আনুষ্ঠানিকভাবে অনুরোধ করে (একাধিক সার্ভার সাড়া দিতে পারে বলে এই ধাপ প্রয়োজন)।
৪. Acknowledge
সার্ভার বরাদ্দ নিশ্চিত করে, সাধারণত একটি লিজ টাইমসহ যার পর ক্লায়েন্টকে রিনিউ করতে হবে।

৩ · লিজ টাইম ও রিনিউয়াল

DHCP-এ IP অ্যাড্রেস স্থায়ীভাবে বরাদ্দ করা হয় না — একটি নির্দিষ্ট লিজ টাইম-এর জন্য "ভাড়া" দেওয়া হয়। যদি একটি ডিভাইস নেটওয়ার্ক ছেড়ে চলে যায় এবং তার লিজ রিনিউ না করে, নির্দিষ্ট সময় পর সেই অ্যাড্রেসটি আবার উপলব্ধ পুলে ফিরে যায় এবং অন্য কোনো নতুন ডিভাইসকে বরাদ্দ করা যায়। এই লিজ-ভিত্তিক মডেলই একটি সীমিত IP পুল (যেমন একটি কফি শপের WiFi, যেখানে প্রতিদিন শত শত ভিন্ন গ্রাহকের ডিভাইস আসা-যাওয়া করে) কার্যকরভাবে শেয়ার করা সম্ভব করে।

মূল অন্তর্দৃষ্টি

Request ধাপটি (শুধু Offer গ্রহণ করলেই যথেষ্ট মনে হতে পারে) আসলে প্রয়োজনীয়, কারণ একই Discover ব্রডকাস্টের উত্তরে একাধিক DHCP সার্ভার Offer পাঠাতে পারে — Request ধাপে ক্লায়েন্ট স্পষ্টভাবে জানিয়ে দেয় ঠিক কোন সার্ভারের কোন প্রস্তাব সে গ্রহণ করছে, যাতে বাকি সার্ভারগুলো তাদের অফার করা IP আবার মুক্ত করে দিতে পারে।

Python
# DHCP-এর DORA প্রক্রিয়ার একটি সরল, ধাপে-ধাপে সিমুলেশন

def dhcp_discover_offer_request_ack(client_id, pool, leases):
    print(f"--- DHCP DORA: {client_id} ---")
    # ১. Discover
    print(f"[Discover]  {client_id} -> ব্রডকাস্ট: 'কোনো DHCP সার্ভার আছে?'")

    if not pool:
        print("[Offer]     কোনো IP অবশিষ্ট নেই!")
        return None

    # ২. Offer
    offered_ip = pool[0]
    print(f"[Offer]     সার্ভার -> {client_id}: IP {offered_ip} প্রস্তাব করছি")

    # ৩. Request
    print(f"[Request]   {client_id} -> সার্ভার: আমি {offered_ip} নিতে চাই")

    # ৪. Acknowledge
    pool.remove(offered_ip)
    leases[client_id] = offered_ip
    print(f"[Ack]       সার্ভার -> {client_id}: {offered_ip} নিশ্চিত করা হলো (লিজ টাইম: ২৪ ঘণ্টা)")
    return offered_ip


available_pool = ["192.168.1.10", "192.168.1.11", "192.168.1.12"]
leases = {}

ip_a = dhcp_discover_offer_request_ack("ল্যাপটপ-A", available_pool, leases)
print()
ip_b = dhcp_discover_offer_request_ack("ফোন-B", available_pool, leases)

print("\nবরাদ্দকৃত লিজসমূহ:", leases)
print("অবশিষ্ট পুল:       ", available_pool)
print("দুই ক্লায়েন্ট কি ভিন্ন IP পেয়েছে?", ip_a != ip_b)

    
লক্ষ্য করুন — প্রতিটি ক্লায়েন্টের জন্য পুরো চার-ধাপের DORA প্রক্রিয়া আলাদাভাবে চলেছে, এবং উভয় ক্লায়েন্ট একই শেয়ার্ড available_pool থেকে ঠিকই ভিন্ন-ভিন্ন IP পেয়েছে — বাস্তবে এটিই একটি DHCP সার্ভার শত শত ডিভাইসের জন্য একযোগে করে।
মূল কথা · Key takeaway

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

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ DORA-এর "Request" ধাপটি কেন প্রয়োজনীয় — শুধু "Offer" পেয়েই ক্লায়েন্ট IP ব্যবহার শুরু করে দিলে সমস্যা কী হতো?

একই Discover ব্রডকাস্টের জবাবে একাধিক DHCP সার্ভার আলাদা-আলাদা IP প্রস্তাব করতে পারে। Request ধাপে ক্লায়েন্ট স্পষ্টভাবে ব্রডকাস্ট করে জানায় ঠিক কোন সার্ভারের কোন প্রস্তাব সে গ্রহণ করছে — এতে বাকি সার্ভারগুলো বুঝতে পারে তাদের প্রস্তাবিত IP গ্রহণ করা হয়নি এবং সেটি তাৎক্ষণিকভাবে আবার মুক্ত করে দিতে পারে, অন্যথায় সেই IP-গুলো অপ্রয়োজনে "রিজার্ভড" থেকে যেত।

প্র ০২ লিজ টাইম খুব ছোট (যেমন ৫ মিনিট) হলে বনাম খুব বড় (যেমন ৩০ দিন) হলে কী কী ট্রেড-অফ তৈরি হবে?

খুব ছোট লিজ টাইমে বারবার রিনিউয়ালের কারণে নেটওয়ার্ক ট্রাফিক ও সার্ভার লোড বাড়ে, কিন্তু আসা-যাওয়া করা ডিভাইসের জন্য IP পুল দ্রুত মুক্ত হয় (কফি শপের মতো জায়গায় উপযোগী)। খুব বড় লিজ টাইমে ওভারহেড কমে, কিন্তু কোনো ডিভাইস নেটওয়ার্ক ছেড়ে গেলেও তার IP দীর্ঘ সময় "আটকে" থাকে, ফলে সীমিত পুলে নতুন ডিভাইসের জন্য অ্যাড্রেস কমে যেতে পারে।

প্র ০৩ DHCP-এর Discover ধাপ কেন ব্রডকাস্ট হয়, ইউনিকাস্ট (নির্দিষ্ট একটি ঠিকানায় সরাসরি) নয়?

একটি নতুন ডিভাইস নেটওয়ার্কে যোগ দেওয়ার সময় তার কাছে এখনো কোনো IP অ্যাড্রেসই নেই, তাই সে জানে না কোন নির্দিষ্ট সার্ভারকে সরাসরি বার্তা পাঠাবে (এমনকি কোনো DHCP সার্ভার আদৌ আছে কি না তাও নিশ্চিত নয়) — তাই একমাত্র ব্যবহারিক উপায় হলো পুরো লোকাল নেটওয়ার্কে ব্রডকাস্ট করে জিজ্ঞেস করা, যাতে যেকোনো উপলব্ধ DHCP সার্ভার সাড়া দিতে পারে।

অনুশীলন

  1. চিন্তা করুন: আপনার বাসার WiFi রাউটার একটি DHCP সার্ভার হিসেবেও কাজ করে — এটি আপনার ফোন/ল্যাপটপকে কী কী তথ্য বরাদ্দ করে বলে আপনার ধারণা?

    সাধারণত একটি IP অ্যাড্রেস (রাউটারের নিজের সাবনেট থেকে, যেমন 192.168.1.x), সাবনেট মাস্ক, ডিফল্ট গেটওয়ে (রাউটারের নিজের IP) এবং DNS সার্ভারের ঠিকানা (প্রায়ই রাউটার নিজেই, অথবা ISP-এর DNS সার্ভার) — এই সবকিছু একটিমাত্র DORA বিনিময়ে পাওয়া যায়।

  2. পরীক্ষা করুন: উপরের কোড সেলে available_pool-এ শুধু একটিমাত্র IP রেখে তিনটি ভিন্ন ক্লায়েন্টের জন্য ফাংশন কল করে দেখুন কী হয়।

    প্রথম ক্লায়েন্ট সফলভাবে সেই একমাত্র IP পাবে; দ্বিতীয় ও তৃতীয় কলে pool খালি হয়ে যাওয়ায় ফাংশন "কোনো IP অবশিষ্ট নেই!" প্রিন্ট করে None রিটার্ন করবে — বাস্তব DHCP সার্ভারেও পুল শেষ হয়ে গেলে ঠিক এই সমস্যাই হয়, যা প্রশাসককে পুলের আকার বাড়াতে বা লিজ টাইম কমাতে বাধ্য করে।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

আগের পাঠ
FTP ও ফাইল ট্রান্সফার