CDN কী, কেন

গল্পে বুঝি

পুরান ঢাকার ফারাবির মিষ্টির দোকানের নাম পুরো দেশে ছড়িয়ে গেছে। রসমালাই, কাঁচাগোল্লা, সন্দেশ সব তৈরি হয় একটাই রান্নাঘরে, নাজিরা বাজারের পেছনের গলিতে। প্রথম দিকে রাজশাহী, সিলেট, খুলনা থেকে অর্ডার এলে ফারাবি প্রতিটা অর্ডার আলাদা করে কুরিয়ারে পাঠাত। রাজশাহীর খদ্দের সিনা অর্ডার দিয়ে দুই দিন অপেক্ষা করত, আর প্রায়ই মিষ্টি পৌঁছাত একটু চুপসে। ঈদের আগের সপ্তাহে অবস্থা আরও খারাপ: সারা দেশের অর্ডার একসাথে এসে পড়ত একটাই রান্নাঘরের ঘাড়ে, কারিগররা রাত জেগেও কুলাতে পারত না, আর কুরিয়ারের বিল দেখে ফারাবির মাথায় হাত।

তারপর ফারাবির ছেলে রাজি একটা বুদ্ধি দিল। প্রতিটা বড় জেলা শহরে একটা ছোট কাউন্টার খোলা হোক, ফ্রিজসহ। মূল রান্নাঘর রোজ সকালে একবার ট্রাকে করে প্রতিটা কাউন্টারে মিষ্টি পাঠাবে। রাজশাহীর সিনা এখন বাড়ির পাশের কাউন্টার থেকে দশ মিনিটে রসমালাই কেনে। কাউন্টারে না থাকলে কাউন্টারের লোক ঢাকায় ফোন করে চেয়ে নেয়, পরের ট্রাকে চলে আসে, আর তখন বাড়তি কয়েক বাক্স রেখে দেয় পরের খদ্দেরের জন্য। ঈদের ভিড় এখন ভাগ হয়ে যায় চল্লিশটা কাউন্টারে; মূল রান্নাঘর শুধু তৈরি করে, বিক্রির ভিড় সামলায় না। কুরিয়ারের খরচও নেমে আসে, কারণ এক ট্রাক অনেক বাক্স বয়, প্রতিটা বাক্সের জন্য আলাদা যাত্রা নয়।

কিন্তু রাজি একটা জিনিস খেয়াল করল। কেউ কেউ চায় “আমার নাম লেখা জন্মদিনের কেক, আজকেই।” সেটা কোনো কাউন্টারের ফ্রিজে আগে থেকে থাকতে পারে না; অর্ডারটা রান্নাঘরেই যেতে হয়। কাউন্টার শুধু অর্ডারটা দ্রুত পৌঁছে দিতে পারে, কেক বানাতে পারে না। আর রান্নাঘরের কারিগর যদি নিজেই ধীর হয়, তাহলে চল্লিশটা কাউন্টার খুলেও সেই কেক তাড়াতাড়ি হবে না।

মিলিয়ে নিই: নাজিরা বাজারের রান্নাঘর হলো origin সার্ভার, যেখানে আসল কন্টেন্ট তৈরি হয়। জেলা শহরের প্রতিটা কাউন্টার হলো একেকটা PoP (Point of Presence), আর কাউন্টারের ফ্রিজ হলো এজ ক্যাশ। পুরো কাউন্টার নেটওয়ার্কটাই CDN (Content Delivery Network)। সিনার বাড়ির পাশের কাউন্টারে দশ মিনিট বনাম ঢাকা থেকে দুই দিন হলো লেটেন্সি কমানো। ঈদের ভিড় কাউন্টারে ভাগ হওয়া হলো origin অফলোড, আর এক ট্রাকে অনেক বাক্স হলো ব্যান্ডউইথ খরচ কমানো। কাউন্টারে না থাকলে ঢাকায় চেয়ে নেওয়া হলো cache miss আর pull CDN। নাম লেখা কেক হলো ডায়নামিক, ব্যক্তিগত কন্টেন্ট, যা ক্যাশ করা যায় না, আর ধীর কারিগর হলো ধীর origin, যা CDN সারাতে পারে না। বাস্তবে প্রতিটা বড় ওয়েবসাইট, ভিডিও প্ল্যাটফর্ম আর অ্যাপ স্টোর এই কাঠামোতেই চলে।

সমস্যাটা: দূরত্ব আর আলোর গতি

ধরুন আপনার সার্ভার আমেরিকার Virginia-তে (অনেক ক্লাউড রিজিয়ন ওখানেই), আর আপনার ইউজার ঢাকায়। দুই শহরের সোজা দূরত্ব মোটামুটি ১২,৯০০ কিলোমিটার। অপটিক্যাল ফাইবারে আলো চলে মোটামুটি সেকেন্ডে ২ লাখ কিলোমিটার (শূন্যস্থানের প্রায় দুই-তৃতীয়াংশ গতিতে)। তাহলে একবার যাওয়া-আসা, মানে একটা round trip (RTT):

distance (one way)     ≈ 12,900 km
light in fiber         ≈ 200,000 km/s
one-way minimum        ≈ 12,900 / 200,000 s ≈ 65 ms
round trip minimum     ≈ 130 ms   (physics floor, cannot be beaten)

এটা পদার্থবিদ্যার সর্বনিম্ন সীমা। বাস্তবে সাবমেরিন কেবল সোজা পথে যায় না, মাঝে রাউটার, কিউ, আর ISP-এর পথ বাছাই থাকে, তাই ঢাকা থেকে US East-এ বাস্তব RTT সাধারণত এর চেয়ে অনেক বেশি (মোটামুটি দুইশো থেকে তিনশো মিলিসেকেন্ডের ঘরে দেখা যায়, আপনার নেটওয়ার্কে ping চালিয়ে নিজে মেপে নিন)।

তুলনা করুন কাছের শহরগুলোর সাথে, একই হিসাবে (শুধু পদার্থবিদ্যার সীমা):

আর ঢাকার ভেতরেই যদি একটা সার্ভার থাকে? RTT নেমে আসে কয়েক মিলিসেকেন্ডে। CDN-এর মূল আইডিয়া এটুকুই: কন্টেন্টকে ইউজারের কাছে নিয়ে আসা, যাতে প্রতিটা round trip ছোট হয়।

একটা পেজ লোডে কয়টা round trip?

একটা RTT ১৩০ ms হলে ভাবতে পারেন, “এক সেকেন্ডের সাত ভাগের এক ভাগ, সমস্যা কী?” সমস্যা হলো একটা নতুন HTTPS কানেকশনে প্রথম বাইট পেতেই একাধিক round trip লাগে:

1. DNS lookup                  ~1 RTT (to the resolver, often cached)
2. TCP handshake (SYN/SYN-ACK) 1 RTT
3. TLS 1.3 handshake           1 RTT   (TLS 1.2 needed 2)
4. HTTP request → first byte   1 RTT + server think time
                               ─────
                               ≈ 3–4 RTT before the first byte arrives

ঢাকা থেকে Virginia-তে বাস্তব RTT যদি ২৫০ ms হয় (উদাহরণ হিসেবে), তাহলে প্রথম বাইট আসতেই প্রায় এক সেকেন্ড। তারপর HTML পড়ে ব্রাউজার CSS, JS, ছবি চাইবে, আর TCP-এর slow start প্রথম দিকে অল্প অল্প ডেটা পাঠায়, তাই বড় ফাইলে আরও কয়েকটা round trip যোগ হয়। প্রতিটা ধাপ RTT দিয়ে গুণ হয়। RTT ২৫০ থেকে ১০-এ নামালে পুরো গুণফলটাই নামে।

curl -so /dev/null -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer}\n' https://example.com/

CDN আসলে কী

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

শব্দভান্ডার

এই ট্র্যাক জুড়ে এই শব্দগুলো বারবার আসবে:

CDN কী কী সমস্যা সমাধান করে

১. লেটেন্সি

ওপরের হিসাবটাই। স্ট্যাটিক ফাইল (ছবি, CSS, JS, ফন্ট, ভিডিও সেগমেন্ট) এজ থেকে এলে প্রতিটা ফাইলের দূরত্ব হাজার কিলোমিটার থেকে নেমে আসে কয়েক কিলোমিটারে।

এমনকি ক্যাশ করা যায় না এমন রিকোয়েস্টেও লাভ আছে। TCP আর TLS হ্যান্ডশেক হয় ইউজার আর কাছের এজের মধ্যে, ছোট RTT-তে। এজ আর origin-এর মধ্যে CDN আগে থেকেই খোলা, গরম কানেকশন রেখে দেয়, তাই origin পর্যন্ত বাকি পথে নতুন হ্যান্ডশেকের খরচ লাগে না।

২. Origin অফলোড

hit ratio যদি ৯৫% হয়, তাহলে প্রতি ১০০টা রিকোয়েস্টের মাত্র ৫টা আপনার সার্ভারে পৌঁছায়। মানে একই সার্ভার কুড়ি গুণ বেশি ট্রাফিক সামলাতে পারছে। একটা ছোট VPS দিয়ে লাখো ভিজিটরের সাইট চালানো সম্ভব হয় শুধু এই কারণেই।

requests/sec at the edge:     10,000
hit ratio:                    95 %
requests/sec at the origin:   10,000 × (1 − 0.95) = 500

hit ratio ৯৫ থেকে ৯৯ হলে origin-এর চাপ ৫০০ থেকে ১০০-তে নামে, মানে আরও পাঁচ গুণ কম। তাই hit ratio-র শেষ কয়েক শতাংশ সবচেয়ে দামি।

৩. ব্যান্ডউইথ খরচ

ক্লাউড প্রোভাইডাররা সাধারণত সার্ভার থেকে ইন্টারনেটে বের হওয়া ডেটার (egress) জন্য টাকা নেয়। CDN থাকলে বেশিরভাগ বাইট বের হয় CDN-এর এজ থেকে, আপনার origin থেকে নয়। CDN-এর নিজের বিলিং মডেল আলাদা আলাদা (প্রতি GB, ফ্ল্যাট রেট, রিকোয়েস্ট প্রতি), আর দাম প্রায়ই বদলায়, তাই নির্দিষ্ট সংখ্যার জন্য প্রোভাইডারের প্রাইসিং পেজ দেখুন। খরচের মডেল নিয়ে চ্যাপ্টার ১৫-তে বিস্তারিত আছে।

৪. ভিড় আর আক্রমণ সামলানো

হঠাৎ ভাইরাল হওয়া একটা পোস্ট, বা ঈদের সেল, বা DDoS আক্রমণ: সব ক্ষেত্রেই ট্রাফিক ছড়িয়ে পড়ে শত শত PoP-এ। একটা origin সার্ভার যা কখনো সহ্য করতে পারত না, সেটা CDN-এর বিশাল মোট ক্যাপাসিটি শুষে নেয়। (চ্যাপ্টার ১২)

৫. রিলায়েবিলিটি

origin কিছুক্ষণের জন্য ডাউন হলে CDN চাইলে পুরনো ক্যাশ করা কপি দেখিয়ে যেতে পারে (stale-if-error, চ্যাপ্টার ৩ ও ৬)। ইউজার হয়তো টেরই পায় না।

Pull CDN বনাম Push CDN

কন্টেন্ট এজে পৌঁছায় দুইভাবে:

Pull CDN (বেশিরভাগ ওয়েবসাইটের ডিফল্ট): আপনি শুধু origin-এর ঠিকানা বলে দেন। প্রথম রিকোয়েস্ট এলে এজ origin থেকে “টেনে” আনে, ক্যাশ করে, পরের রিকোয়েস্টগুলোকে ক্যাশ থেকে দেয়। কিছু আগে থেকে আপলোড করতে হয় না। দুর্বলতা: প্রতিটা PoP-এ প্রথম রিকোয়েস্টটা ধীর (cold cache)।

Push CDN: আপনি নিজে ফাইলগুলো CDN-এর স্টোরেজে আপলোড করেন, CDN সেখান থেকে সার্ভ করে। origin বলে আলাদা কিছু লাগে না। বড়, কম বদলানো ফাইলের জন্য ভালো (সফটওয়্যার ডাউনলোড, গেম প্যাচ, ভিডিও লাইব্রেরি)। দুর্বলতা: আপলোড আর মুছে ফেলার দায়িত্ব আপনার।

বাস্তবে অনেক প্রোভাইডারে দুটোই মিশে যায়: আপনি object storage-এ ফাইল রাখেন (push-এর মতো), আর CDN সেটাকে origin হিসেবে pull করে।

CDN কী ক্যাশ করে, আর কী শুধু পার করে দেয়

প্রতিটা রিকোয়েস্টে এজ একটা সিদ্ধান্ত নেয়: এটা জমা রাখা যাবে কি না। মোটামুটি তিন রকম রিকোয়েস্ট আছে:

1. ক্যাশেবল স্ট্যাটিক কন্টেন্ট: app.3f9a1c.js, ছবি, ফন্ট। সবার জন্য একই, অনেক দিন বদলায় না। এজ ক্যাশ করে। CDN-এর আসল জাদু এখানেই।
2. ক্যাশেবল কিন্তু ঘনঘন বদলায়: হোমপেজের HTML, পাবলিক API (যেমন বাজারদর)। কয়েক সেকেন্ড বা মিনিটের জন্য ক্যাশ করা যায়। সঠিক TTL বাছাই করাটাই কৌশল।
3. ক্যাশ করা যায় না: লগইন করা ইউজারের ড্যাশবোর্ড, কার্টে কী আছে, পেমেন্ট। প্রতিটা ইউজারের জন্য আলাদা। এজ এগুলো সোজা origin-এ পাঠিয়ে দেয় (pass বা bypass), শুধু কানেকশনের সুবিধাটুকু দেয়।

কোন রিকোয়েস্ট কোন দলে পড়বে, সেটা মূলত ঠিক করে origin-এর পাঠানো Cache-Control হেডার (চ্যাপ্টার ৩) আর CDN-এর নিজস্ব নিয়ম। ভুল দলে ফেললে দুই রকম বিপদ:

• ক্যাশেবল জিনিস ক্যাশ না হলে: CDN থেকেও কোনো লাভ নেই, origin-এ পুরো চাপ।
• ব্যক্তিগত জিনিস ক্যাশ হয়ে গেলে: এক ইউজারের তথ্য আরেকজনের কাছে চলে যায়। এটা সবচেয়ে মারাত্মক CDN বাগ (চ্যাপ্টার ৯ ও ১৪)।

CDN যা সারাতে পারে না

গল্পের নাম লেখা কেক আর ধীর কারিগরকে মনে রাখুন। CDN কোনো জাদু নয়:

• ধীর origin, ক্যাশ না হওয়া রিকোয়েস্টে। আপনার API যদি একটা রিকোয়েস্টে দুই সেকেন্ড ডেটাবেস কুয়েরি চালায়, CDN থাকলেও সেই দুই সেকেন্ড থাকবে। CDN শুধু নেটওয়ার্কের অংশটা ছোট করে।
• খারাপ ফ্রন্টএন্ড। ৫ MB JavaScript এজ থেকে দ্রুত আসবে, কিন্তু ফোনের CPU সেটা পার্স আর রান করতে একই সময় নেবে।
• ভুল ক্যাশ হেডার। ওপরে বললাম: CDN আপনার নির্দেশ মানে।
• ডেটাবেসের লেখা। অর্ডার প্লেস করা, কমেন্ট পোস্ট করা: এগুলো সবসময় origin-এ যায়।
• একমাত্র ডেটা সেন্টার ডাউন হলে ডায়নামিক অংশ। স্ট্যাটিক অংশ হয়তো stale-if-error দিয়ে টিকে থাকবে, কিন্তু লগইন বা চেকআউট চলবে না।

সংক্ষিপ্ত ইতিহাস

নব্বইয়ের দশকের শেষে ওয়েব যখন হঠাৎ বড় হলো, জনপ্রিয় সাইটগুলো প্রায়ই ভিড়ের চাপে বসে যেত; একে তখন বলা হতো “World Wide Wait”। MIT-এর গবেষণা থেকে ১৯৯৮ সালে Akamai তৈরি হয়, যারা প্রথম বড় বাণিজ্যিক CDN-এর একটা। আইডিয়া ছিল ঠিক গল্পের কাউন্টারগুলোর মতো: ISP-গুলোর নেটওয়ার্কের ভেতরে হাজার হাজার সার্ভার বসানো, আর DNS দিয়ে প্রতিটা ইউজারকে কাছের সার্ভারে পাঠানো।

পরের দুই দশকে CDN শুধু ছবি আর ভিডিও দেওয়া থেকে বেড়ে হয়ে ওঠে সাইটের পুরো সামনের দরজা: TLS টার্মিনেশন, DDoS সুরক্ষা, WAF, এমনকি এজে কোড চালানো (চ্যাপ্টার ১১)। আজ একটা সাধারণ ওয়েবসাইটের প্রায় প্রতিটা রিকোয়েস্টই আসলে প্রথমে কোনো না কোনো CDN-এর এজে পৌঁছায়।

আপনার কি CDN দরকার?

সাধারণত হ্যাঁ, যদি:

• আপনার ইউজাররা origin থেকে দূরে, বা অনেক দেশে ছড়ানো
• স্ট্যাটিক ফাইল বা মিডিয়া অনেক
• ট্রাফিক হঠাৎ বাড়ে-কমে
• origin ছোট আর আপনি সেটাকে আড়ালে রাখতে চান

হয়তো না, বা এখনই না, যদি:

• সব ইউজার একই শহরে, origin-ও সেখানে (যেমন শুধু ঢাকার একটা অফিসের ইন্টারনাল টুল)
• প্রায় সব রিকোয়েস্ট ব্যক্তিগত আর ক্যাশ করা যায় না, আর লেটেন্সি সমস্যা নয়
• আপনি এখনো ক্যাশ হেডার বোঝেন না। আগে চ্যাপ্টার ৩ পড়ুন, তারপর CDN চালু করুন।

ডিবাগিং: এই চ্যাপ্টারের সমস্যাগুলো

মূল শিক্ষা

1. দূরত্ব সময়। ফাইবারে আলোর গতি একটা অনতিক্রম্য সীমা; ঢাকা থেকে US East-এ শুধু পদার্থবিদ্যাই প্রতি round trip-এ ১৩০ ms নেয়, বাস্তবে আরও বেশি।
2. হ্যান্ডশেক RTT-কে গুণ করে। প্রথম বাইট আসতে ৩–৪টা round trip লাগে, তাই RTT কমানো পুরো পেজ লোড কমায়।
3. CDN = কাছের সার্ভার + ক্যাশ। PoP-এর এজ সার্ভার ইউজারের কানেকশন নেয়, যা পারে জমা রাখে, বাকিটা origin-এ পাঠায়।
4. Hit ratio-ই আসল মাপ। ৯৫% থেকে ৯৯% মানে origin-এর চাপ আরও পাঁচ গুণ কম।
5. Pull CDN নিজে থেকে origin থেকে টেনে আনে; push CDN-এ আপনি আপলোড করেন।
6. CDN আপনার হেডার মেনে চলে। ভুল হেডার মানে হয় কোনো লাভ নেই, নয়তো ব্যক্তিগত ডেটা ফাঁস।
7. CDN ধীর origin, ভারী ফ্রন্টএন্ড বা ডেটাবেসের লেখা সারায় না। ও শুধু নেটওয়ার্কের পথটা ছোট করে।