পাঠ ৫১ · ৫৭-এর মধ্যে · মডিউল ১১
Home / Courses / Computer Networks / CDN ও এজ নেটওয়ার্কিং

CDN ও এজ নেটওয়ার্কিং

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

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

  • CDN কী এবং কেন এজ সার্ভার ব্যবহার করে
  • ল্যাটেন্সি ও অরিজিন-লোড কমানোয় CDN-এর ভূমিকা
  • DNS-ভিত্তিক জিওগ্রাফিক রিডাইরেকশন কীভাবে কাজ করে
  • Anycast রাউটিং — DNS-রিডাইরেকশনের একটি বিকল্প/পরিপূরক কৌশল
  • Python দিয়ে একটি geo_resolve_dns ফাংশনের সিমুলেশন

১ · CDN কী ও কেন — কাছাকাছি কনটেন্ট, কম ল্যাটেন্সি

CDNContent Delivery Networkভৌগোলিকভাবে বিতরণকৃত সার্ভারের একটি নেটওয়ার্ক যা কনটেন্ট ব্যবহারকারীর কাছাকাছি ক্যাশ করে রাখে, ল্যাটেন্সি কমায় ও অরিজিন সার্ভারের লোড কমায়। (system-design ও cloud-devops কোর্সেও দেখা এই ধারণাটি এখানে নেটওয়ার্ক-মেকানিক্স-এর দৃষ্টিকোণ থেকে দেখব) হলো ভৌগোলিকভাবে বিতরণকৃত এজ সার্ভারEdge Serverব্যবহারকারীর ভৌত অবস্থানের কাছাকাছি বসানো একটি সার্ভার, যা জনপ্রিয় কনটেন্টের একটি ক্যাশড কপি রাখে।-এর একটি নেটওয়ার্ক, যা জনপ্রিয় কনটেন্টের কপি ব্যবহারকারীর ভৌত অবস্থানের কাছাকাছি রাখে। এর দুটি সরাসরি সুবিধা — কম ল্যাটেন্সি (কম ভৌত দূরত্ব মানে কম propagation delay, L42-এর ল্যাটেন্সি-উপাদানগুলোর সরাসরি প্রয়োগ) এবং অরিজিন সার্ভারের উপর কম লোড (বেশিরভাগ অনুরোধ এজ সার্ভার থেকেই সন্তুষ্ট হয়, মূল সার্ভার পর্যন্ত পৌঁছাতে হয় না)।

২ · DNS-ভিত্তিক জিওগ্রাফিক রিডাইরেকশন

L30-এর DNS আলোচনা মনে করুন — একটি ডোমেইন নেম একটি IP অ্যাড্রেসে resolve হয়। CDN এই একই DNS ব্যবস্থাকে একটি চমৎকার উপায়ে কাজে লাগায় — একজন ব্যবহারকারী যখন cdn.example.com resolve করতে চায়, CDN-এর DNS সার্ভার সেই ব্যবহারকারীর ভৌগোলিক/নেটওয়ার্ক-টপোলজিক্যাল অবস্থান বিবেচনা করে ভিন্ন ভিন্ন ব্যবহারকারীকে ভিন্ন ভিন্ন IP অ্যাড্রেস ফেরত দেয় — একই ডোমেইন নেমের জন্য, কিন্তু প্রতিটি উত্তর সেই নির্দিষ্ট ব্যবহারকারীর সবচেয়ে কাছের এজ সার্ভারের দিকে নির্দেশ করে। এটি DNS-এর নমনীয়তার একটি বাস্তব, চমৎকার প্রয়োগ — DNS শুধু স্ট্যাটিক hostname-to-IP ম্যাপিং নয়, এটি ডায়নামিক, প্রসঙ্গ-সচেতন সিদ্ধান্তও নিতে পারে।

৩ · Anycast — একটি পরিপূরক কৌশল

AnycastAnycastএকটি রাউটিং কৌশল যেখানে একই IP অ্যাড্রেস একাধিক ভৌত অবস্থান থেকে ঘোষণা করা হয়, আর স্বাভাবিক রাউটিং প্রতিটি ব্যবহারকারীকে টপোলজিক্যালি নিকটতম অবস্থানে পৌঁছে দেয়। হলো "নিকটতম কপিতে পৌঁছানো"র আরেকটি উপায় — একই IP অ্যাড্রেস একাধিক ভৌত অবস্থান থেকে একসাথে ঘোষণা করা হয় (BGP-এর মাধ্যমে, L20 মনে করুন), আর স্বাভাবিক রাউটিং (M4) স্বয়ংক্রিয়ভাবেই প্রতিটি ব্যবহারকারীর ট্রাফিক টপোলজিক্যালি নিকটতম অবস্থানে পৌঁছে দেয় — কোনো DNS-স্তরের সিদ্ধান্তের দরকার হয় না। DNS-ভিত্তিক রিডাইরেকশন ও anycast একই লক্ষ্যের দুটি ভিন্ন, একে অপরের পরিপূরক কৌশল।

এজ সার্ভার
ব্যবহারকারীর কাছাকাছি বসানো ক্যাশড কনটেন্টের কপি।
DNS রিডাইরেকশন
একই ডোমেইন, ভিন্ন ব্যবহারকারীর জন্য ভিন্ন IP উত্তর।
Anycast
একই IP, একাধিক অবস্থান — রাউটিং নিজেই নিকটতমটি বেছে নেয়।
Python
# DNS-ভিত্তিক জিওগ্রাফিক রিডাইরেকশনের সিমুলেশন (ইন-মেমরি ফেক CDN ম্যাপ)

cdn_map = {
    "asia": "103.21.55.10",
    "europe": "185.60.10.24",
    "north_america": "13.107.6.5",
}
default_region = "north_america"

def geo_resolve_dns(user_region, cdn_map, default_region):
    """ব্যবহারকারীর অঞ্চল অনুযায়ী নিকটতম এজ সার্ভারের IP ফেরত দেয়;
    অঞ্চল অজানা হলে default_region-এর এজ সার্ভার ব্যবহার করে।"""
    if user_region in cdn_map:
        return cdn_map[user_region]
    return cdn_map[default_region]

print("ডোমেইন: cdn.abcltech.com — একই ডোমেইন, ভিন্ন অঞ্চল থেকে অনুসন্ধান করলে ভিন্ন IP:")
print("-" * 60)
for region in ["asia", "europe", "north_america", "antarctica"]:
    resolved_ip = geo_resolve_dns(region, cdn_map, default_region)
    known = "পরিচিত অঞ্চল" if region in cdn_map else f"অজানা অঞ্চল -> ডিফল্ট ({default_region}) ব্যবহৃত"
    print(f"  {region:15s} -> {resolved_ip:15s}  [{known}]")

    
cdn.abcltech.com (DNS) এশিয়া ব্যবহারকারী -> 103.21.55.10 ইউরোপ ব্যবহারকারী -> 185.60.10.24 উ. আমেরিকা ব্যবহারকারী -> 13.107.6.5 একই ডোমেইন নেম, ভিন্ন ভিন্ন উত্তর — প্রশ্নকারীর অবস্থান অনুযায়ী
DNS-ভিত্তিক জিওগ্রাফিক রিডাইরেকশন — একই hostname, ভিন্ন resolved IP, নিকটতম এজ সার্ভারের দিকে।
লক্ষ্য করুন — geo_resolve_dns "antarctica"-এর মতো অপরিচিত অঞ্চলের জন্য নিঃশব্দে ব্যর্থ না হয়ে default_region-এ fallback করে। বাস্তব CDN-এও ঠিক এই নীতি অনুসরণ করা হয় — কোনো ব্যবহারকারীর নির্দিষ্ট নিকটতম এজ সার্ভার খুঁজে না পাওয়া গেলেও একটি যুক্তিসঙ্গত ডিফল্ট (সাধারণত ভৌগোলিকভাবে কেন্দ্রীয় বা সবচেয়ে বড় ক্যাপাসিটির এজ) সবসময় ব্যবহারযোগ্য থাকে।
মূল কথা · Key takeaway

CDN কোনো নতুন প্রোটোকল নয় — এটি L30-এর DNS ও M4-এর রাউটিং নীতির (এই ক্ষেত্রে anycast-এর মাধ্যমে) একটি চতুর, প্রায়োগিক সমন্বয়, যা "ব্যবহারকারীর কাছাকাছি কনটেন্ট রাখো" এই সাধারণ লক্ষ্যকে নেটওয়ার্কের বিদ্যমান মেকানিজম দিয়েই বাস্তবায়ন করে।

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

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

প্র ০১ DNS-ভিত্তিক জিওগ্রাফিক রিডাইরেকশন কেন L30-এর সাধারণ DNS ব্যবহারের একটি সম্প্রসারণ, ব্যতিক্রম নয়?

L30-এ আমরা দেখেছি DNS একটি hostname-কে একটি IP-তে resolve করে — এখানেও ঠিক তাই ঘটছে, শুধু DNS সার্ভার কোন IP ফেরত দেবে তা নির্ধারণ করার সময় অতিরিক্ত তথ্য (প্রশ্নকারীর অবস্থান) বিবেচনা করছে। প্রোটোকলের মৌলিক আচরণ — একটি প্রশ্ন পাঠানো, একটি IP উত্তর পাওয়া — একই থাকে; শুধু সার্ভার-সাইড সিদ্ধান্ত-নেওয়ার লজিক আরও স্মার্ট হয়েছে।

প্র ০২ Anycast-এর তুলনায় DNS-ভিত্তিক রিডাইরেকশনের একটি সম্ভাব্য সীমাবদ্ধতা কী হতে পারে?

DNS-ভিত্তিক রিডাইরেকশন ব্যবহারকারীর DNS resolver-এর অবস্থানের উপর নির্ভর করে সিদ্ধান্ত নেয় — কিন্তু ব্যবহারকারীর নিজের অবস্থান আর তার ব্যবহৃত DNS resolver-এর অবস্থান সবসময় একই নাও হতে পারে (যেমন কেউ একটি দূরবর্তী পাবলিক DNS resolver ব্যবহার করলে), ফলে ভুল অঞ্চলের এজ সার্ভার বেছে নেওয়া হতে পারে। Anycast এই সমস্যা এড়ায় কারণ এটি সরাসরি নেটওয়ার্ক রাউটিং-এর উপর নির্ভর করে, DNS resolver-এর অবস্থানের উপর নয়।

প্র ০৩ উপরের কোড সেলে ফলব্যাক লজিক (default_region) না থাকলে কী সমস্যা হতো?

ফলব্যাক ছাড়া, cdn_map-এ নেই এমন কোনো অঞ্চল থেকে অনুরোধ এলে ফাংশনটি KeyError দিয়ে ক্র্যাশ করত বা কোনো IP-ই ফেরত দিত না — অর্থাৎ সেই অঞ্চলের ব্যবহারকারী সম্পূর্ণ সার্ভিস পেত না। বাস্তব CDN-এ এটি ভয়াবহ — প্রতিটি সম্ভাব্য ব্যবহারকারী-অবস্থানের জন্য আলাদা এজ সার্ভার আগে থেকে ম্যাপ করা বাস্তবসম্মত নয়, তাই একটি নিরাপদ ডিফল্ট সবসময় থাকা আবশ্যক।

অনুশীলন

  1. চিন্তা করুন: কেন একটি CDN ব্যবহারকারীর কাছাকাছি ভৌত দূরত্ব কমালে ল্যাটেন্সি কমে — L42-এর ল্যাটেন্সি-উপাদানগুলোর কোনটি এখানে সরাসরি প্রযোজ্য?

    L42-এ ল্যাটেন্সির একটি প্রধান উপাদান হলো propagation delay — সিগন্যাল ভৌত মাধ্যম দিয়ে (তার/আলো/রেডিও তরঙ্গ) ভ্রমণ করতে যে সময় নেয়, যা মূলত দূরত্বের সমানুপাতিক। ব্যবহারকারীর কাছাকাছি এজ সার্ভার থাকলে সিগন্যালকে কম দূরত্ব ভ্রমণ করতে হয়, তাই propagation delay সরাসরি কমে যায় — এটিই CDN-এর ল্যাটেন্সি-হ্রাসের মূল প্রযুক্তিগত কারণ।

  2. পরীক্ষা করুন: উপরের কোড সেলে cdn_map-এ একটি নতুন অঞ্চল "south_asia" যোগ করুন তার নিজস্ব IP-সহ, এবং লুপের অঞ্চল-তালিকায় সেটি যোগ করে দেখুন এটি সঠিক IP ফেরত দেয় কি না (ফলব্যাকে না গিয়ে)।

    যেহেতু geo_resolve_dns প্রথমে user_region in cdn_map পরীক্ষা করে, নতুন যোগ করা "south_asia" এন্ট্রি dict-এ থাকলে সেটি সরাসরি তার নিজস্ব IP ফেরত দেবে — default_region ফলব্যাকে যাবে না। এটি নিশ্চিত করে ফাংশনটি ঠিক তখনই ফলব্যাক ব্যবহার করে যখন প্রকৃতপক্ষে অঞ্চলটি অজানা।

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

আগের পাঠ
L50 · নেটওয়ার্ক ফাংশন ভার্চুয়ালাইজেশন (NFV)