ক্লায়েন্ট-সার্ভার মডেল ও DNS

Client-server model & DNS

৭ মিনিট পড়া মধ্যম · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

এক নজরে · TL;DR

ক্লায়েন্ট-সার্ভার মডেলClient-Server Modelএকটি আর্কিটেকচার যেখানে ক্লায়েন্ট রিকোয়েস্ট শুরু করে এবং সার্ভার সেই রিকোয়েস্টের উত্তর দেয় — ভূমিকাগুলো স্পষ্টভাবে আলাদা। — ক্লায়েন্ট রিকোয়েস্ট শুরু করে, সার্ভার উত্তর দেয়। এই মডিউলের (M2) প্রতিটি পাঠ এই যোগাযোগ কীভাবে কাজ করে তা নিয়ে।
DNSDomain Name Systemএকটি হায়ারার্কিক্যাল, ডিস্ট্রিবিউটেড সিস্টেম যা মানুষের পড়ার-যোগ্য ডোমেইন নেইমকে (যেমন abcltech.com) মেশিন-পঠনযোগ্য IP অ্যাড্রেসে রূপান্তর করে। ডোমেইন নেইমকে IP অ্যাড্রেসে রূপান্তর করে — একটি হায়ারার্কিক্যাল সিস্টেম (root → TLD → authoritative সার্ভার)।
DNS রেজাল্ট বিভিন্ন স্তরে (ব্রাউজার, OS, ISP resolver) TTL অনুযায়ী ক্যাশ হয় — প্রতিটি DNS কোয়েরি নতুন করে পুরো হায়ারার্কি ঘুরে আসতে হয় না।
রাউন্ড-রবিন DNS একটি সহজ (কিন্তু কাঁচা) লোড ব্যালেন্সিং কৌশল — একই ডোমেইনের জন্য বিভিন্ন কোয়েরিতে ঘুরিয়ে-ফিরিয়ে ভিন্ন IP রিটার্ন করে।

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

ক্লায়েন্ট-সার্ভার মডেল কী এবং এটি P2P (পিয়ার-টু-পিয়ার) থেকে কীভাবে ভিন্ন
DNS-এর হায়ারার্কিক্যাল রেজোলিউশন প্রক্রিয়া (root → TLD → authoritative)
সাধারণ DNS রেকর্ড টাইপ — A, AAAA, CNAME, MX
TTL-ভিত্তিক DNS ক্যাশিং কীভাবে কাজ করে
রাউন্ড-রবিন DNS কীভাবে একটি কাঁচা লোড ব্যালেন্সার হিসেবে কাজ করে — Python সিমুলেশন

১ · ক্লায়েন্ট-সার্ভার মডেল

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

এটি P2PPeer-to-Peerএমন একটি আর্কিটেকচার যেখানে প্রতিটি অংশগ্রহণকারী (peer) একই সাথে ক্লায়েন্ট ও সার্ভার উভয়ের ভূমিকা পালন করতে পারে — কোনো কেন্দ্রীয় সার্ভার ছাড়াই সরাসরি একে অপরের সাথে যোগাযোগ করে। (peer-to-peer) মডেলের বিপরীত, যেখানে কোনো কেন্দ্রীয় সার্ভার নেই — প্রতিটি নোড একই সাথে ক্লায়েন্ট ও সার্ভার (যেমন BitTorrent)। এই কোর্সের প্রায় সব সিস্টেম ক্লায়েন্ট-সার্ভার মডেল অনুসরণ করে, কারণ এটি নিয়ন্ত্রণ, নিরাপত্তা ও স্কেলিং (লোড ব্যালেন্সিং, L11) অনেক সহজ করে তোলে।

২ · DNS — ডোমেইন নেইম থেকে IP

যখন আপনি ব্রাউজারে abcltech.com টাইপ করেন, ব্রাউজারের আসলে দরকার একটি IP অ্যাড্রেস — সংখ্যার একটি ঠিকানা যেখানে সার্ভার আছে। DNS হলো ইন্টারনেটের "ফোনবুক" যা এই রূপান্তর করে।

DNS রেজোলিউশন — রিকার্সিভ রিজলভার ধাপে ধাপে root → TLD → authoritative সার্ভার জিজ্ঞেস করে শেষে IP অ্যাড্রেস পায়, যা ক্লায়েন্টে ফেরত যায় ও TTL অনুযায়ী ক্যাশ হয়।

রেজোলিউশন ধাপে ধাপে হয় —

Root সার্ভার — জানে কোন TLD (.com, .org, .net) সার্ভার কোথায়।
TLD সার্ভার (.com) — জানে abcltech.com-এর authoritative সার্ভার কোনটি।
Authoritative সার্ভার — চূড়ান্ত উত্তর দেয়, "abcltech.com এর IP হলো X.X.X.X"।

এই পুরো প্রক্রিয়া করে একটি রিকার্সিভ রিজলভার (সাধারণত আপনার ISP বা Google/Cloudflare-এর পাবলিক DNS, যেমন 8.8.8.8), ক্লায়েন্টের পক্ষে।

৩ · DNS রেকর্ড টাইপ

A
ডোমেইন → IPv4 অ্যাড্রেস

AAAA
ডোমেইন → IPv6 অ্যাড্রেস

CNAME
একটি ডোমেইনকে আরেকটি ডোমেইনের অ্যালিয়াস বানায় (যেমন www → root ডোমেইন)

MX
ডোমেইনের মেইল সার্ভার নির্দেশ করে

৪ · TTL ও DNS ক্যাশিং

প্রতিবার DNS কোয়েরি করলে যদি পুরো root → TLD → authoritative প্রক্রিয়া চালাতে হতো, ইন্টারনেট অসম্ভব ধীর হয়ে যেত। তাই প্রতিটি DNS রেকর্ডের একটি TTL (Time To Live, সেকেন্ডে) থাকে — এই সময়ের মধ্যে ব্রাউজার, অপারেটিং সিস্টেম, এবং ISP resolver — সবাই ফলাফল নিজ নিজ স্তরে ক্যাশ করে রাখে। TTL শেষ হলেই শুধু আবার পুরো রেজোলিউশন প্রক্রিয়া চলে। এটি L19-এ শেখা cache-aside প্যাটার্নের মতোই একটি ধারণা — শুধু TTL-ভিত্তিক ইনভ্যালিডেশন (L21)।

৫ · রাউন্ড-রবিন DNS — একটি কাঁচা লোড ব্যালেন্সার

একটি ডোমেইনের জন্য একাধিক IP অ্যাড্রেস (একাধিক সার্ভার) DNS রেকর্ডে যোগ করা যায়। DNS সার্ভার প্রতিটি কোয়েরির জবাবে ঘুরিয়ে-ফিরিয়ে ভিন্ন ভিন্ন ক্রমে IP রিটার্ন করে — এভাবে ভিন্ন ভিন্ন ক্লায়েন্ট মোটামুটি সমানভাবে বিভিন্ন সার্ভারে ছড়িয়ে পড়ে। এটি একটি প্রকৃত লোড ব্যালেন্সারের (L11) মতো নিখুঁত নয় — এটি সার্ভার স্বাস্থ্য জানে না, কানেকশন কাউন্টও জানে না — কিন্তু সহজ ও সস্তা একটি প্রাথমিক লোড-বিতরণ কৌশল।

Python

server_ips = ["10.0.0.1", "10.0.0.2", "10.0.0.3"]

def round_robin_dns(call_number, ips):
    # প্রতিটি কোয়েরিতে ঘুরিয়ে-ফিরিয়ে পরবর্তী IP রিটার্ন করা
    return ips[call_number % len(ips)]

distribution = {ip: 0 for ip in server_ips}

print("ক্রমিক DNS কোয়েরির ফলাফল:")
for call_number in range(12):
    ip = round_robin_dns(call_number, server_ips)
    distribution[ip] += 1
    print(f"কোয়েরি #{call_number + 1}: {ip}")

print()
print("প্রতিটি IP কতবার রিটার্ন হলো:")
for ip, count in distribution.items():
    print(f"{ip}: {count} বার")

assert all(count == 4 for count in distribution.values())

লক্ষ্য করুন — ৩টি IP-এর মধ্যে ১২টি কোয়েরি ছড়িয়ে দিলে প্রতিটি ঠিক ৪ বার পড়ে — নিখুঁতভাবে সমান বিতরণ, কিন্তু শুধু এই কারণে যে ১২ ঠিক ৩ দিয়ে বিভাজ্য এবং সব সার্ভার সমান লোড হ্যান্ডল করতে পারে ধরে নেওয়া হয়েছে। বাস্তবে DNS ক্যাশিং (উপরের TTL আলোচনা) এই বিতরণকে অসম করে দিতে পারে — একই ক্লায়েন্ট বারবার একই ক্যাশড IP ব্যবহার করবে, তাই রাউন্ড-রবিন DNS প্রকৃত পার-রিকোয়েস্ট লোড ব্যালেন্সিং নয়, বরং মোটামুটি পার-ক্লায়েন্ট বিতরণ।

মূল কথা · Key takeaway

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

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

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

প্র ০১ DNS TTL খুব ছোট (যেমন ৫ সেকেন্ড) সেট করলে কী সুবিধা ও অসুবিধা হবে?

সুবিধা: যেকোনো পরিবর্তন (যেমন সার্ভার পরিবর্তন বা রাউন্ড-রবিন আপডেট) দ্রুত সব ক্লায়েন্টের কাছে প্রোপাগেট হবে, কারণ ক্যাশ দ্রুত এক্সপায়ার হয়। অসুবিধা: প্রতি ৫ সেকেন্ডে একবার পুরো রেজোলিউশন প্রক্রিয়া চালাতে হবে, যা root/TLD/authoritative সার্ভারে বিশাল বাড়তি লোড তৈরি করবে এবং প্রতিটি রিকোয়েস্টে সামান্য বাড়তি লেটেন্সি (L03) যোগ করবে। তাই বাস্তবে একটি ভারসাম্য বেছে নেওয়া হয় — স্ট্যাটিক রেকর্ডের জন্য বড় TTL (ঘণ্টা/দিন), দ্রুত পরিবর্তনযোগ্য রেকর্ডের জন্য ছোট TTL (মিনিট)।

প্র ০২ রাউন্ড-রবিন DNS কেন একটি "নিখুঁত" লোড ব্যালেন্সার নয় — একটি প্রকৃত L7 লোড ব্যালেন্সারের (L11) সাথে এর মূল পার্থক্য কী?

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

প্র ০৩ ক্লায়েন্ট-সার্ভার মডেল কেন বেশিরভাগ ওয়েব সিস্টেমের জন্য P2P-এর চেয়ে বেশি ব্যবহারিক, যদিও P2P-তে কোনো একক ব্যর্থতা-বিন্দু (single point of failure) নেই?

ক্লায়েন্ট-সার্ভার মডেলে নিয়ন্ত্রণ কেন্দ্রীভূত থাকে বলে অ্যাক্সেস কন্ট্রোল, ডেটা সামঞ্জস্যতা, আপডেট রোলআউট ও মনিটরিং (L41) অনেক সহজ — একটি জায়গায় পরিবর্তন করলেই সব ইউজার সেটা পায়। P2P সিস্টেমে প্রতিটি পিয়ারকে নির্ভর করতে হয় অন্য পিয়ারদের উপর, যাদের আপটাইম/আচরণ নিয়ন্ত্রণ করা যায় না, এবং কনসিস্টেন্সি (L04) বজায় রাখা জটিল হয়ে যায়। বেশিরভাগ ব্যবসায়িক অ্যাপ্লিকেশনে (ব্যাংকিং, সোশ্যাল মিডিয়া, ই-কমার্স) কেন্দ্রীভূত নিয়ন্ত্রণের সুবিধা single-point-of-failure-এর ঝুঁকির চেয়ে বেশি গুরুত্বপূর্ণ — এবং সেই ঝুঁকি রেপ্লিকেশন (L16) ও ফেইলওভার (L37) দিয়ে সামলানো যায়।

অনুশীলন

চিন্তা করুন: একটি ওয়েবসাইটের A রেকর্ডের TTL ৩৬০০ সেকেন্ড (১ ঘণ্টা)। সার্ভার মাইগ্রেশনের আগে ইঞ্জিনিয়াররা কেন সাধারণত মাইগ্রেশনের কয়েক ঘণ্টা আগে TTL কমিয়ে (যেমন ৬০ সেকেন্ডে) দেন?

কারণ TTL শুধু নতুন কোয়েরির জন্য প্রযোজ্য — যেসব ক্যাশ আগে থেকেই পুরনো TTL (৩৬০০ সেকেন্ড) দিয়ে রেজাল্ট সংরক্ষণ করেছে, তারা মাইগ্রেশনের পরেও পুরনো IP ব্যবহার করতে থাকবে যতক্ষণ না সেই ক্যাশ এক্সপায়ার হয়। TTL আগে থেকে কমিয়ে দিলে, মাইগ্রেশনের সময় নাগাদ বেশিরভাগ ক্যাশ ছোট TTL নিয়ে রিফ্রেশ হয়ে যায়, ফলে মাইগ্রেশনের পর নতুন IP দ্রুত সবার কাছে পৌঁছায় এবং ডাউনটাইম বা ব্যর্থ রিকোয়েস্ট কমে।
কোড পরিবর্তন করুন: উপরের কোড সেলে server_ips-এ একটি চতুর্থ IP ("10.0.0.4") যোগ করুন এবং কল সংখ্যা ১২ থেকে বাড়িয়ে ১৬ করুন। চালানোর আগে হাতে অনুমান করুন প্রতিটি IP কতবার রিটার্ন হবে, তারপর কোড চালিয়ে মিলিয়ে দেখুন।

৪টি IP-এর মধ্যে ১৬টি কোয়েরি সমানভাবে ভাগ হবে — প্রতিটি IP ঠিক ৪ বার রিটার্ন হবে (১৬ ÷ ৪ = ৪), যেহেতু ১৬ ঠিক ৪ দিয়ে বিভাজ্য। এটি নিশ্চিত করে call_number % len(ips) যুক্তিটি IP সংখ্যা বদলালেও সঠিকভাবে কাজ করে, যতক্ষণ মোট কল সংখ্যা IP সংখ্যার গুণিতক থাকে।