Web cache, proxy আর CDN — কাছে রাখলেই দ্রুত

১ · কেন cache — দূরের জিনিস কাছে রাখা

পর্ব ৩৬-এ দেখেছেন, ব্রাউজার একটি HTTP অনুরোধ পাঠায় আর সার্ভার উত্তর দেয়। কিন্তু একটি জনপ্রিয় সংবাদ-সাইটের লোগো দিনে কয়েক লাখ মানুষ চায়, আর প্রতিবার সেই একই কয়েক কিলোবাইট। প্রতিটি অনুরোধ যদি সমুদ্রের ওপারের মূল সার্ভারে যায়, তাহলে একই জিনিস লাখ বার সাগর পাড়ি দেয়। Cache-এর ধারণা সরল: একবার আনা জিনিসের একটি কপি কাছে রেখে দিন, পরের বার সেখান থেকেই দিন।

চারটি লাভ

Cache কাজ করে কারণ ওয়েবের চাহিদা সমান ভাগে ছড়ানো নয়। অল্প কিছু জিনিস (জনপ্রিয় পাতা, লোগো, JavaScript লাইব্রেরি, ভাইরাল ভিডিও) বারবার চাওয়া হয়, আর বিপুল সংখ্যক জিনিস কদাচিৎ। গবেষণায় ওয়েবের জনপ্রিয়তাকে প্রায়ই Zipf-ধাঁচের বণ্টন দিয়ে আন্দাজ করা হয় — প্রথম কয়েকটি জিনিস মোট অনুরোধের বড় অংশ নেয়। তাই ছোট একটি cache-ও অনেক অনুরোধ সামলাতে পারে। একে বলে লোকালিটি (locality): যা এইমাত্র চাওয়া হয়েছে বা যা জনপ্রিয়, তা আবার চাওয়ার সম্ভাবনা বেশি — OS-এর page cache আর CPU cache-ও এই একই নীতিতে চলে।

২ · Cache কোথায় কোথায় থাকে — ব্রাউজার থেকে CDN edge

একটি অনুরোধ ব্রাউজার থেকে origin পর্যন্ত যেতে পথে কয়েকটি cache পেরোতে পারে। কে কার পক্ষে কাজ করে, আর কে কার তথ্য দেখতে পায় — এটাই তাদের আলাদা করে।

Forward proxy ক্লায়েন্টের দিকে বসে: প্রতিষ্ঠানের সব কম্পিউটার তার মাধ্যমে বাইরে যায়, আর সে জনপ্রিয় জিনিস জমিয়ে রাখে। ব্রাউজারে proxy-র ঠিকানা লেখা থাকতে পারে, বা নেটওয়ার্ক নিজেই ট্রাফিক ঘুরিয়ে proxy-তে পাঠাতে পারে (transparent proxy). Reverse proxy উল্টো দিকে: ক্লায়েন্ট ভাবে এটিই সার্ভার; এটি পেছনের সার্ভারগুলোর হয়ে উত্তর দেয়, cache রাখে, load ভাগ করে, কখনো TLS-ও সামলায়। CDN-কে বলা যায় বিশ্বজুড়ে ছড়ানো reverse proxy-র নেটওয়ার্ক।

একটি অনুরোধের যাত্রা — তিন স্তরের cache

রাজশাহীর এক পাঠক shop.example.com-এর লোগো চাইছেন। সাইটটি একটি CDN ব্যবহার করে, যার একটি edge server ঢাকায়; origin ইউরোপে। সংখ্যাগুলো উদাহরণ: ব্রাউজার থেকে edge-এর RTT ১০ ms, edge থেকে origin-এর RTT ১৮০ ms (বাস্তবে পথভেদে অনেক বদলায়)। সংযোগ আর TLS-এর সময় এখানে বাদ রাখা হলো।

৩ · প্রতিষ্ঠানের access link — link বাড়াবেন, না cache বসাবেন?

এটি বিশ্ববিদ্যালয়ের Computer Networks পরীক্ষা আর চাকরির লিখিত পরীক্ষায় বারবার আসা একটি ক্লাসিক অঙ্ক (Kurose-Ross-এর পাঠ্যবইয়ে এর একটি রূপ আছে; নিচের সংখ্যাগুলো আমাদের নিজের)। এটি পর্ব ৫-এর traffic intensity আর queuing delay-এর সরাসরি প্রয়োগ।

সমস্যা

একটি বিশ্ববিদ্যালয়ের ভেতরের নেটওয়ার্ক (LAN) 100 Mbps. বাইরে যাওয়ার access link মাত্র 10 Mbps. ধরে নিন:

• প্রতিটি ওয়েব-বস্তুর (object) গড় আকার L = 0.8 Mbit (১০০ কিলোবাইট)।
• পুরো ক্যাম্পাস থেকে গড়ে a = 12টি অনুরোধ প্রতি সেকেন্ডে, প্রতিটির উত্তর access link দিয়ে ভেতরে আসে।
• Access link-এর বাইরের router থেকে origin পর্যন্ত গিয়ে উত্তর ফিরতে গড়ে ১ সেকেন্ড (“Internet delay”, দূরের সার্ভার আর পথের সব delay মিলিয়ে ধরা একটি মান)।
• LAN-এর ভেতরের delay প্রায় ০.০১ সেকেন্ড (0.8 Mbit ÷ 100 Mbps = 8 ms transmission, সাথে সামান্য বাকি)।

Access link-এ queuing delay কত, তা বের করতে একটি মডেল লাগে। পর্ব ৫-এ দেখেছেন, এলোমেলো আগমনে গড় অপেক্ষা (1 − ρ) হর-এ রাখে। এখানে আমরা সবচেয়ে প্রচলিত সরল মডেল M/M/1 নেব: access link-এ একটি বস্তুর গড় মোট সময় (অপেক্ষা + নিজের transmission):

এটি একটি আনুমানিক মডেল — বাস্তবের আগমন আর বস্তুর আকার এত সরল নয়। পাঠ্যবই অনেক সময় মডেল ছাড়াই শুধু বলে “ρ ১-এর কাছে হলে delay বিশাল, ০.৬-এর মতো হলে কয়েক দশ মিলিসেকেন্ড” — পরীক্ষায় প্রশ্ন যেভাবে চায় সেভাবে লিখবেন, কিন্তু কোন মডেল ধরলেন তা স্পষ্ট লিখবেন।

নিচের ক্যালকুলেটর একই মডেলে কয়েকটি পরিস্থিতি একসাথে হিসাব করে — hit rate ০, ০.৪, ০.৬, আর অনুরোধ সামান্য বাড়লে কী হয়।

// Institutional cache problem. Access link R bit/s, objects of L bits, a requests/s.
// Model (an approximation, M/M/1): access-link delay = (L/R) / (1 - rho), rho = L*a/R.
// Only cache MISSES cross the access link, so rho is multiplied by (1 - hit).
const L = 0.8e6;            // object size: 0.8 Mbit (100 KB)
const lanDelay = 0.01;      // s, inside the 100 Mbps LAN
const internetDelay = 1.0;  // s, outside router -> origin -> back (assumed)

function scenario(name, R, a, hit) {
  const rho = (1 - hit) * L * a / R;
  const access = rho < 1 ? (L / R) / (1 - rho) : Infinity;
  const avg = hit * lanDelay + (1 - hit) * (lanDelay + access + internetDelay);
  const f = (x) => isFinite(x) ? x.toFixed(3) + " s" : "infinite";
  console.log(name.padEnd(27) + String(hit).padEnd(5) + rho.toFixed(3).padEnd(8) +
              f(access).padEnd(11) + f(avg));
}
console.log("scenario                   hit  rho     access     avg delay");
scenario("10 Mbps, no cache", 10e6, 12, 0);
scenario("10 Mbps, no cache, 12.5/s", 10e6, 12.5, 0);
scenario("A: upgrade to 100 Mbps", 100e6, 12, 0);
scenario("B: cache, hit 0.4", 10e6, 12, 0.4);
scenario("B: cache, hit 0.6", 10e6, 12, 0.6);

scenario                   hit  rho     access     avg delay
10 Mbps, no cache          0    0.960   2.000 s    3.010 s
10 Mbps, no cache, 12.5/s  0    1.000   infinite   infinite
A: upgrade to 100 Mbps     0    0.096   0.009 s    1.019 s
B: cache, hit 0.4          0.4  0.576   0.189 s    0.723 s
B: cache, hit 0.6          0.6  0.384   0.130 s    0.462 s

৪ · HTTP caching-এর নিয়ম ১ — freshness: কতক্ষণ বিশ্বাস করা যায়

HTTP-র caching নিয়ম এখন লেখা আছে RFC 9111-এ (জুন ২০২২, আগের RFC 7234-এর জায়গায়), আর শর্তযুক্ত অনুরোধ ও ETag-এর অর্থ RFC 9110-এ। মূল কাঠামো দুই ভাগে: freshness — কোনো প্রশ্ন না করে কতক্ষণ কপি ব্যবহার করা যায়; আর validation — মেয়াদ ফুরালে সস্তায় কীভাবে জিজ্ঞেস করা যায় “বদলেছে কি?”। একটি কপি fresh যতক্ষণ তার বয়স (age) freshness lifetime-এর কম; তারপর সে stale. Stale মানে বাতিল নয় — মানে ব্যবহারের আগে সাধারণত যাচাই লাগবে।

Cache-Control — সার্ভারের নির্দেশনা

সার্ভার response-এর header-এ Cache-Control দিয়ে নির্দেশনা (directive) দেয়। সবচেয়ে দরকারিগুলো:

Expires, Age আর heuristic freshness

Expires হলো HTTP/1.0 যুগের header: একটি নির্দিষ্ট তারিখ-সময়, যেমন Expires: Thu, 01 Jan 2026 00:00:00 GMT. এর সমস্যা — ক্লায়েন্ট আর সার্ভারের ঘড়ি না মিললে হিসাব ভুল হয়। তাই max-age থাকলে নিয়ম অনুযায়ী সেটিই প্রাধান্য পায়, Expires উপেক্ষিত হয়। Shared cache উত্তরের সাথে Age header যোগ করে, যাতে জানা যায় কপিটি সেখানে কত সেকেন্ড ধরে আছে: CDN থেকে max-age=600 আর Age: 100 এলে ব্রাউজারের কাছে কপিটি আর ৫০০ সেকেন্ড fresh.

সার্ভার কোনো মেয়াদ না দিলে? RFC 9111 cache-কে নিজে আন্দাজ করার (heuristic freshness) অনুমতি দেয়, যদি response-টি এমনিতে cache-যোগ্য হয় (যেমন 200, 301, 404). একটি প্রচলিত কৌশল RFC-তেই উদাহরণ হিসেবে আছে: Last-Modified-এর পর থেকে এখন পর্যন্ত যত সময় গেছে তার একটি ভগ্নাংশ — সাধারণত প্রায় ১০% — freshness ধরা। ফাইলটি ১০ দিন আগে শেষ বদলালে প্রায় ১ দিন। ব্রাউজারভেদে বাস্তব আচরণ আলাদা হতে পারে, তাই নিজের সাইটে কখনো এই আন্দাজের ওপর ভরসা করবেন না; স্পষ্ট Cache-Control দিন।

৫ · নিয়ম ২ — validation: ETag, Last-Modified আর 304

Stale কপি ফেলে দিয়ে আবার পুরো ফাইল আনা অপচয় — বেশিরভাগ সময় ফাইলটি বদলায়নি। তাই cache একটি conditional request পাঠায়: “আমার কাছে এই সংস্করণ আছে; বদলালে নতুনটি দিন, না বদলালে শুধু জানান।” দুই রকম চিহ্ন দিয়ে এটি হয়:

• ETag → If-None-Match: সার্ভার প্রতিটি সংস্করণে একটি চিহ্ন দেয়, যেমন ETag: "33a7" (প্রায়ই বিষয়বস্তুর hash বা সংস্করণ নম্বর)। Cache পরে পাঠায় If-None-Match: "33a7". চিহ্ন মিললে উত্তর 304 Not Modified, body ছাড়া।
• Last-Modified → If-Modified-Since: সময় দিয়ে তুলনা। সেকেন্ডের চেয়ে সূক্ষ্ম পার্থক্য ধরতে পারে না, আর একই ফাইল কয়েকটি সার্ভারে ভিন্ন সময়ে লেখা হলে ভুল করতে পারে। দুটো একসাথে এলে সার্ভার If-None-Match-কে প্রাধান্য দেয়।

ETag দুই রকম: strong ("33a7") — বাইট বাইট একই; weak (W/"33a7") — অর্থে একই, বাইটে সামান্য আলাদা হতে পারে (যেমন ভিন্ন compression). আর একটি সতর্কতা: অনেক সার্ভারের পুরোনো সংস্করণে ETag-এ inode বা সার্ভার-নির্দিষ্ট তথ্য থাকত, ফলে load balancer-এর পেছনের দুই সার্ভার একই ফাইলের দুই আলাদা ETag দিত আর 304 প্রায় কখনো আসত না। ETag বিষয়বস্তু থেকে বানানোই নিরাপদ।

এবার একটি ছোট cache simulator. এতে তিন রকম URL: একটি লোগো (max-age=60, origin-এ ১৩০ সেকেন্ডে বদলায়), একটি নামে-hash-যুক্ত JavaScript ফাইল (এক বছর, immutable), আর একটি ব্যক্তিগত অ্যাকাউন্ট-পাতা (no-store).

// A tiny HTTP cache (like a browser or proxy) in front of an origin server.
// Origin: what the server would send for each URL; logo.png changes at t = 130 s.
function origin(url, t) {
  if (url === "/account") return { etag: '"u7"', cc: "no-store" };
  if (url === "/app.3f9a2c.js") return { etag: '"a1"', cc: "max-age=31536000, immutable" };
  return { etag: t < 130 ? '"v1"' : '"v2"', cc: "max-age=60" };
}
const cache = new Map();                    // url -> { etag, maxAge, storedAt }
function get(url, t) {
  const e = cache.get(url);
  if (e && t - e.storedAt < e.maxAge)
    return `HIT fresh (age ${t - e.storedAt}s < max-age ${e.maxAge}s), 0 bytes from origin`;
  const r = origin(url, t);
  if (r.cc.includes("no-store")) return "BYPASS: no-store -> 200 from origin, not stored";
  const maxAge = Number(r.cc.match(/max-age=(\d+)/)[1]);
  if (e) {                                  // stale: ask "has it changed?"
    const msg = `STALE (age ${t - e.storedAt}s) -> If-None-Match: ${e.etag} -> `;
    if (r.etag === e.etag) { e.storedAt = t; return msg + "304 Not Modified, reuse body"; }
    cache.set(url, { etag: r.etag, maxAge, storedAt: t });
    return msg + `200 OK, new body ETag ${r.etag}`;
  }
  cache.set(url, { etag: r.etag, maxAge, storedAt: t });
  return `MISS -> 200 OK, stored ETag ${r.etag}, ${r.cc}`;
}
const trace = [[0, "/logo.png"], [5, "/app.3f9a2c.js"], [30, "/logo.png"],
  [90, "/logo.png"], [120, "/logo.png"], [200, "/logo.png"], [210, "/account"],
  [215, "/app.3f9a2c.js"], [220, "/account"]];
for (const [t, url] of trace)
  console.log(`t=${String(t).padStart(3)}s GET ${url.padEnd(15)} ${get(url, t)}`);

t=  0s GET /logo.png       MISS -> 200 OK, stored ETag "v1", max-age=60
t=  5s GET /app.3f9a2c.js  MISS -> 200 OK, stored ETag "a1", max-age=31536000, immutable
t= 30s GET /logo.png       HIT fresh (age 30s < max-age 60s), 0 bytes from origin
t= 90s GET /logo.png       STALE (age 90s) -> If-None-Match: "v1" -> 304 Not Modified, reuse body
t=120s GET /logo.png       HIT fresh (age 30s < max-age 60s), 0 bytes from origin
t=200s GET /logo.png       STALE (age 110s) -> If-None-Match: "v1" -> 200 OK, new body ETag "v2"
t=210s GET /account        BYPASS: no-store -> 200 from origin, not stored
t=215s GET /app.3f9a2c.js  HIT fresh (age 210s < max-age 31536000s), 0 bytes from origin
t=220s GET /account        BYPASS: no-store -> 200 from origin, not stored

একই কাজ সত্যিকারের socket-এ — C-তে origin আর caching proxy

এবার Linux-এ দুটি প্রক্রিয়া: fork করা একটি ছোট origin সার্ভার (127.0.0.1-এর একটি খালি port-এ), আর parent প্রক্রিয়া একটি caching proxy-র ভূমিকায়। প্রথম অনুরোধে proxy origin থেকে আনে আর জমায়; দ্বিতীয়টি memory থেকে দেয়; তৃতীয়টিতে ধরে নেওয়া হয়েছে max-age পেরিয়েছে, তাই If-None-Match পাঠায়। Socket-এর খুঁটিনাটি পর্ব ৪১-এ।

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <arpa/inet.h>
#include <sys/wait.h>
/* An origin server (child) and a caching proxy (parent) on 127.0.0.1 */
static struct sockaddr_in a = { .sin_family = AF_INET };
static void fetch(const char *req, char *resp) {      /* one request, one connection */
    int s = socket(AF_INET, SOCK_STREAM, 0), n = -1;
    if (connect(s, (struct sockaddr *)&a, sizeof a) == 0 && write(s, req, strlen(req)) > 0)
        n = read(s, resp, 511);
    close(s); resp[n > 0 ? n : 0] = 0;
}
int main(void) {
    char buf[512], body[64], etag[16], req[128]; socklen_t len = sizeof a;
    a.sin_addr.s_addr = htonl(INADDR_LOOPBACK); int ls = socket(AF_INET, SOCK_STREAM, 0);
    bind(ls, (struct sockaddr *)&a, sizeof a); listen(ls, 4); fflush(stdout);
    getsockname(ls, (struct sockaddr *)&a, &len);       /* kernel chose a free port */
    if (fork() == 0) {                                   /* ORIGIN: 2 connections */
        for (int i = 0; i < 2; i++) {
            int c = accept(ls, NULL, NULL), n = read(c, buf, 511); buf[n > 0 ? n : 0] = 0;
            const char *r = strstr(buf, "If-None-Match: \"v1\"") ? "HTTP/1.1 304 Not Modified\r\n\r\n"
                : "HTTP/1.1 200 OK\r\nETag: \"v1\"\r\nCache-Control: max-age=60\r\n\r\nHello from origin";
            n = (int)write(c, r, strlen(r)); close(c); if (n < 0) return 1;
        } return 0;
    }
    close(ls); fetch("GET /hello HTTP/1.1\r\nHost: localhost\r\n\r\n", buf);
    sscanf(strstr(buf, "ETag: ") + 6, "%15s", etag); strcpy(body, strstr(buf, "\r\n\r\n") + 4);
    printf("req 1: MISS  -> origin: %.15s, stored ETag %s, body \"%s\"\n", buf, etag, body);
    printf("req 2: HIT   -> \"%s\" served from memory, origin not contacted\n", body);
    snprintf(req, sizeof req, "GET /hello HTTP/1.1\r\nHost: localhost\r\nIf-None-Match: %s\r\n\r\n", etag);
    fetch(req, buf);                                     /* req 3: assume max-age passed */
    printf("req 3: STALE -> If-None-Match %s, origin: %.25s, served stored \"%s\"\n", etag, buf, body);
    wait(NULL); return 0;
}

req 1: MISS  -> origin: HTTP/1.1 200 OK, stored ETag "v1", body "Hello from origin"
req 2: HIT   -> "Hello from origin" served from memory, origin not contacted
req 3: STALE -> If-None-Match "v1", origin: HTTP/1.1 304 Not Modified, served stored "Hello from origin"

৬ · Cache key, Vary, cache busting — আর যা কখনো cache করা যাবে না

Cache key আর Vary

Cache জমানো কপি খোঁজে একটি key দিয়ে — সাধারণত method (প্রায় সবসময় GET) আর পুরো URL, query string-সহ। কিন্তু একই URL-এর উত্তর কখনো request header-এর ওপর নির্ভর করে: যে ব্রাউজার Accept-Encoding: br পাঠায় সে Brotli-তে চাপা ফাইল পায়, যে পাঠায় না সে চাপহীন ফাইল। সার্ভার তখন response-এ লেখে Vary: Accept-Encoding — মানে “এই header-ও key-র অংশ”। না লিখলে একটি cache চাপা ফাইল জমিয়ে এমন ক্লায়েন্টকে দিতে পারে যে খুলতেই পারে না।

Cache busting — দীর্ঘ cache, তবু তাৎক্ষণিক হালনাগাদ

দ্বন্দ্বটি এরকম: CSS আর JavaScript এক বছর cache করলে সাইট দ্রুত, কিন্তু নতুন সংস্করণ ছাড়লে পুরোনো কপি এক বছর ধরে চলবে। সমাধান: ফাইলের বিষয়বস্তু বদলালে URL-ই বদলে দিন — একে বলে cache busting. সবচেয়ে প্রচলিত রূপ fingerprinting: build-এর সময় বিষয়বস্তুর hash নামে বসানো।

index.html            Cache-Control: no-cache                  (প্রতিবার যাচাই, 304 সস্তা)
  └─ <script src="/assets/app.3f9a2c.js">
/assets/app.3f9a2c.js Cache-Control: public, max-age=31536000, immutable

নতুন সংস্করণ ছাড়লে:
index.html            (নতুন ETag → 200, ছোট ফাইল)
  └─ <script src="/assets/app.b71e04.js">   ← নতুন নাম, তাই নতুন cache key
/assets/app.3f9a2c.js আর কেউ চায় না — নিজে থেকে একসময় eviction-এ সরে যায়

এই নকশার যুক্তি: HTML ছোট আর সবসময় যাচাই হয়, তাই হালনাগাদ তাৎক্ষণিক; বড় ফাইলগুলো এক বছর বিনা প্রশ্নে চলে, কারণ একটি নামের বিষয়বস্তু কখনো বদলায় না। সরল বিকল্প হলো query দিয়ে সংস্করণ — style.css?v=20261028. এতে ফাইলের নাম বদলাতে হয় না, শুধু রেফারেন্স; এই সাইটের নিজের CSS-ও এভাবে চলে। দুর্বলতা: কেউ সংস্করণ বাড়াতে ভুলে গেলে পুরোনো কপি চলে, আর কিছু পুরোনো proxy একসময় query-যুক্ত URL cache করত না বা CDN-এ query বাদ দিয়ে key বানানোর সেটিং থাকতে পারে — নিজের CDN-এর নীতি যাচাই করে নিন।

কী কখনো shared cache-এ যাবে না

লগইন-করা ব্যবহারকারীর পাতা — প্রোফাইল, ব্যাংক-বিবরণী, অর্ডারের তালিকা, যেকোনো পাতা যাতে নাম, ফোন নম্বর বা টোকেন আছে — shared cache-এ জমলে পরের ব্যবহারকারী আগের জনের তথ্য দেখবেন। এমন response-এ Cache-Control: private (ব্রাউজারে রাখা চললে) বা no-store (কোথাও না); আর Set-Cookie-যুক্ত response-কে CDN-এ cache-যোগ্য না রাখা নিরাপদ অভ্যাস।

৭ · CDN — বিশ্বজুড়ে ছড়ানো cache, আর কাছের edge খুঁজে পাওয়া

একটি CDN (Content Delivery Network) হলো বহু শহরে, বহু নেটওয়ার্কের ভেতরে বসানো হাজারো cache সার্ভারের একটি পরিকল্পিত নেটওয়ার্ক, যা সাইটের মালিকের পক্ষে কাজ করে। লাভ তিন দিকে: (১) দূরত্ব কমে, তাই RTT কমে — আর প্রতিটি নতুন TCP/TLS বা QUIC সংযোগে কয়েকটি RTT লাগে বলে এর প্রভাব কয়েক গুণ; (২) নেটওয়ার্কের সীমানা কম পেরোতে হয় — edge যদি ISP-র ভেতরে বা IXP-তে থাকে, ট্রাফিক বিদেশি transit link-এ ওঠেই না (পর্ব ২৫-এর peering); (৩) ভার আর আক্রমণ ছড়িয়ে যায় — হঠাৎ ভিড় বা DDoS হাজার সার্ভারে ভাগ হয়।

দুই দর্শন: enter deep আর bring home

পাঠ্যবইয়ে (Kurose-Ross) CDN-এর সার্ভার বসানোর দুই দর্শনের নাম দেওয়া হয়েছে। Enter deep: সারা বিশ্বের অসংখ্য access ISP-র ভেতরে ছোট ছোট সার্ভার-গুচ্ছ বসানো, যাতে ব্যবহারকারীর একদম কাছে থাকা যায় — Akamai এই পথের পরিচিত উদাহরণ। দাম: হাজারো জায়গায় যন্ত্র রক্ষণাবেক্ষণ আর হালনাগাদ। Bring home: কম সংখ্যক জায়গায় (প্রায়ই বড় IXP-র কাছে) বড় বড় cluster — পরিচালনা সহজ, কিন্তু ব্যবহারকারী থেকে একটু দূরে; পাঠ্যবই এখানে Limelight-এর নাম নেয়। বাস্তবে আজকের বড় CDN-গুলো দুটোর মিশ্রণ, আর নামগুলো পাঠ্যবইয়ের শ্রেণিবিভাগ, শিল্পের কোনো মান নয়।

ব্যবহারকারী কীভাবে কাছের edge-এ পৌঁছান — DNS redirection

সবচেয়ে প্রচলিত কৌশল DNS দিয়ে। সাইটের মালিক নিজের নামটিকে একটি CNAME দিয়ে CDN-এর নামে পাঠান। CDN-এর নিজস্ব authoritative DNS তারপর প্রশ্নকর্তা কোথায় তা দেখে কাছের edge-এর IP দেয়। সমস্যা একটাই: CDN-এর DNS ব্যবহারকারীকে দেখে না, দেখে তাঁর recursive resolver-কে (পর্ব ৩৫)। Resolver ব্যবহারকারীর কাছে হলে ঠিক আছে; দূরে হলে ভুল edge. এর প্রতিকার EDNS Client Subnet (ECS, RFC 7871, ২০১৬): resolver ক্লায়েন্টের ঠিকানার একটি ছাঁটা অংশ (যেমন /24) জানিয়ে দেয়। সব resolver এটি পাঠায় না — গোপনীয়তার কারণে কিছু public resolver ইচ্ছা করেই পাঠায় না বা সীমিত করে।

নিচের উদাহরণে সব নাম আর ঠিকানা কাল্পনিক (documentation-এর জন্য সংরক্ষিত IP পরিসর)। চট্টগ্রামের একজন ব্যবহারকারী www.shop.example.com খুলছেন; তাঁর ISP-র resolver ঢাকায়।

বিকল্প: anycast

অন্য কৌশলে CDN সব edge থেকে একই IP prefix ঘোষণা করে (anycast, পর্ব ২৫)। BGP নিজেই প্রতিটি ব্যবহারকারীর packet-কে “সবচেয়ে কাছের” — আসলে BGP-র নীতিতে সবচেয়ে পছন্দের — edge-এ পাঠায়। সুবিধা: resolver-এর অবস্থানের সমস্যা নেই, আর একটি edge বন্ধ হলে route সরে যায়। অসুবিধা: BGP RTT মাপে না, তাই “কাছের” সবসময় দ্রুততম নয়; আর সংযোগের মাঝে route বদলালে একটি TCP সংযোগ অন্য edge-এ গিয়ে ভেঙে যেতে পারে (ছোট HTTP অনুরোধে এটি কদাচিৎ সমস্যা)। অনেক CDN দুটো মেলায়: DNS দিয়ে অঞ্চল, anycast দিয়ে অঞ্চলের ভেতরে। পর্ব ২৬-এ দেখেছেন, multicast-এর বদলে ইন্টারনেটে বড় পরিসরে একই কনটেন্ট বিতরণের ব্যবহারিক উত্তর হয়ে উঠেছে এই CDN-ই।

৮ · CDN-এর ভেতরে — স্তর, purge, TLS, edge computing আর মাপজোখ

Cache-এর স্তর: edge → shield → origin

বিশ্বজুড়ে কয়েকশো edge থাকলে, প্রতিটি edge-এর প্রথম miss origin-এ গেলে একটি নতুন ফাইলের জন্য origin কয়েকশো অনুরোধ পায়। তাই CDN মাঝখানে একটি স্তর রাখে — regional cache বা origin shield: সব edge-এর miss আগে সেখানে যায়, আর শুধু shield-এর miss origin-এ। ফলে origin একটি ফাইলের জন্য আদর্শভাবে একবারই জিজ্ঞাসিত হয়। দাম: miss-এর পথে একটি বাড়তি hop.

Request collapsing — একসাথে একশো miss, origin-এ একটি

একটি খেলার স্কোর-পাতার মেয়াদ ফুরানোর ঠিক মুহূর্তে একটি edge-এ একসাথে ৫০০ অনুরোধ এল। সরল cache হলে ৫০০টি অনুরোধই origin-এ যেত (“thundering herd” বা cache stampede). Request collapsing-এ edge প্রথম অনুরোধটি origin-এ পাঠায়, বাকি ৪৯৯টি সেই উত্তরের অপেক্ষায় দাঁড় করিয়ে রাখে, তারপর একই উত্তর সবাইকে দেয়। stale-while-revalidate এর সাথে মিলে আরও ভালো: অপেক্ষাও করতে হয় না, পুরোনো কপি যায় আর পেছনে একটিমাত্র যাচাই চলে। ব্যক্তিগত বা অ-cache-যোগ্য উত্তরে collapsing বিপজ্জনক — একজনের উত্তর অন্যের কাছে চলে যেতে পারে — তাই CDN সেখানে এটি বন্ধ রাখে।

Purge — জোর করে ভুলিয়ে দেওয়া

ভুল দাম বা ভুল ছবি প্রকাশ হয়ে গেছে, আর max-age এক দিন। তখন CDN-এর API দিয়ে purge (invalidation): নির্দিষ্ট URL, URL-এর অংশ, বা ট্যাগ (surrogate key) ধরে কপি মুছে বা stale ঘোষণা করা। আধুনিক CDN সেকেন্ডের মধ্যে purge ছড়ানোর দাবি করে, কিন্তু মনে রাখবেন: purge শুধু CDN-এর কপি মোছে, ব্যবহারকারীর ব্রাউজারের কপি নয়। তাই ব্রাউজারের জন্য ছোট max-age আর CDN-এর জন্য বড় s-maxage — এটি একটি প্রচলিত কৌশল; আর fingerprinting থাকলে purge-এর দরকারই কম।

Edge-এ TLS

HTTPS সাইটের সামনে CDN থাকলে ব্রাউজারের TLS সংযোগ শেষ হয় edge-এ (TLS termination) — edge-এর কাছে সাইটের নামের certificate আর private key (বা key ব্যবহারের ব্যবস্থা) থাকে। এতে handshake-এর RTT ছোট হয় আর edge বিষয়বস্তু দেখে cache করতে পারে। Edge থেকে origin-এ আলাদা একটি সংযোগ যায় — এটিও এনক্রিপ্টেড রাখা জরুরি, নইলে ব্যবহারকারী তালা দেখলেও পথের অর্ধেক খোলা। দাম হলো বিশ্বাস: CDN আপনার ব্যবহারকারীদের ট্রাফিক খোলা অবস্থায় দেখতে পায়। TLS আর certificate-এর বিস্তারিত পর্ব ৪৮-এ।

বাংলাদেশের প্রেক্ষাপট

বাংলাদেশের বিদেশমুখী ইন্টারনেট মূলত সাবমেরিন কেবল (SEA-ME-WE সিরিজ) আর স্থলপথের কিছু সংযোগ দিয়ে যায়, আর এই international bandwidth তুলনামূলক দামি। বড় কনটেন্ট প্রতিষ্ঠানগুলোর অনেকে বিশ্বজুড়ে ISP-দের নিজেদের নেটওয়ার্কের ভেতরে cache সার্ভার বসানোর কর্মসূচি চালায় — যেমন Google Global Cache বা Netflix Open Connect নামে পরিচিত কর্মসূচিগুলো — আর দেশের অনেক ISP এমন cache রাখে বা BDIX-এর মতো দেশীয় exchange-এর মাধ্যমে দেশের ভেতরের cache থেকে কনটেন্ট পায় বলে প্রচলিত ধারণা। কোন ISP-তে ঠিক কী আছে, তা প্রতিষ্ঠানভেদে আলাদা আর সময়ের সাথে বদলায়; তাই নির্দিষ্ট দাবির আগে নিজে মেপে দেখাই ভালো — যেমন জনপ্রিয় ভিডিও-সাইটে traceroute দিলে শেষ hop-গুলো দেশের ভেতরেই থাকে কি না (পর্ব ২০)। মূল কথাটি সার্বজনীন: জনপ্রিয় কনটেন্ট যত কাছে, ব্যবহারকারীর গতি তত বেশি আর ISP-র বিদেশি bandwidth-এর খরচ তত কম।

Edge computing

CDN-এর edge এখন শুধু ফাইল জমায় না, ছোট প্রোগ্রামও চালায় — edge computing বা “edge function”: ভাষা বা দেশ দেখে redirect, header যোগ, ছবির আকার বদল, সরল A/B পরীক্ষা, bot ছাঁকা, এমনকি ছোট API. সুবিধা ব্যবহারকারীর কাছে হিসাব; সীমাবদ্ধতা — কম memory আর CPU-সময়, আর ডেটাবেস সাধারণত দূরে থেকে যায়, তাই ডেটা-নির্ভর কাজে লাভ সীমিত।

মাপজোখ: hit ratio, byte hit ratio, TTFB

• Cache hit ratio = hit ÷ মোট অনুরোধ। ১০,০০০ অনুরোধে ৯,২০০ hit হলে ০.৯২.
• Byte hit ratio = cache থেকে দেওয়া বাইট ÷ মোট বাইট। ছোট আইকনে hit বেশি কিন্তু বড় ভিডিওতে miss হলে অনুরোধের হিসাবে ভালো দেখায়, বাইটের হিসাবে খারাপ। Bandwidth-খরচ বোঝে এই সংখ্যা।
• TTFB (time to first byte): অনুরোধ শুরু থেকে উত্তরের প্রথম বাইট পর্যন্ত। এতে DNS, সংযোগ, TLS আর সার্ভারের ভাবনার সময় মেশে — তাই edge-এ hit হলে TTFB কম, origin পর্যন্ত miss গেলে বেশি। ব্রাউজারের developer tools-এর Network ট্যাবে প্রতিটি অনুরোধের এই ভাগগুলো দেখা যায়।

জায়গা ফুরালে কী সরবে — LRU আর LFU

Edge-এর disk আর memory সীমিত, তাই নতুন জিনিস রাখতে পুরোনো কিছু সরাতে হয় — eviction. দুই ক্লাসিক নিয়ম: LRU — যেটি সবচেয়ে বেশি সময় আগে শেষবার ব্যবহার হয়েছে; LFU — যেটি সবচেয়ে কম বার ব্যবহার হয়েছে। OS-এর page replacement-এও ঠিক এই প্রশ্ন আসে (অপারেটিং সিস্টেম কোর্সের page replacement পর্ব); LRU-কে O(1)-এ চালাতে hash table আর doubly linked list একসাথে লাগে। নিচের simulator একই ৩-জায়গার cache-এ দুটি ভিন্ন ধরনের অনুরোধ-ধারা চালায়।

// Edge cache with room for N = 3 objects: LRU vs LFU on two request traces.
// LRU evicts the object used longest ago; LFU evicts the one used least often
// (count kept only while cached; ties broken by older last use).
const N = 3;
function run(trace, policy) {
  const c = new Map();                      // obj -> { freq, last }
  let hits = 0; const ev = [];
  trace.forEach((o, t) => {
    if (c.has(o)) { hits++; c.get(o).freq++; c.get(o).last = t; return; }
    if (c.size === N) {
      let victim = null;
      for (const [k, v] of c) {
        const w = victim && c.get(victim);
        if (!w || (policy === "LRU" ? v.last < w.last
                   : v.freq < w.freq || (v.freq === w.freq && v.last < w.last))) victim = k;
      }
      c.delete(victim); ev.push(victim);
    }
    c.set(o, { freq: 1, last: t });
  });
  console.log(`  ${policy}: hits ${hits}/${trace.length} = ${(hits / trace.length).toFixed(3)}` +
              `  evictions ${ev.length}: ${ev.join(" ")}`);
}
const traces = {
  "1) popular A, B + one-time objects": "A B A B A C D A E B F A G B",
  "2) popularity shifts from A, B to C, D, E": "A B A B A C D C D C E D C E D",
};
for (const [name, s] of Object.entries(traces)) {
  console.log(name + ":  " + s);
  run(s.split(" "), "LRU");
  run(s.split(" "), "LFU");
}

1) popular A, B + one-time objects:  A B A B A C D A E B F A G B
  LRU: hits 4/14 = 0.286  evictions 7: B C D A E B F
  LFU: hits 7/14 = 0.500  evictions 4: C D E F
2) popularity shifts from A, B to C, D, E:  A B A B A C D C D C E D C E D
  LRU: hits 10/15 = 0.667  evictions 2: B A
  LFU: hits 3/15 = 0.200  evictions 9: C D C D C E D C E

৯ · AI-এর যুগে caching — header লেখা, মাপা আর যাচাই

“আমার সাইট দ্রুত করার একটি nginx config চাই” — AI মুহূর্তে লম্বা config দেয়। কিন্তু caching-এর ভুল নিঃশব্দ: সাইট চলে, শুধু একজনের তথ্য আরেকজন দেখে, বা হালনাগাদ এক সপ্তাহ কারও কাছে পৌঁছায় না। চেনা ভুলগুলো:

AI-এর caching পরামর্শ চালু করার আগে — চেকলিস্ট

• প্রতিটি directive-এর অর্থ RFC 9111 বা MDN-এ মিলিয়েছি; no-cache আর no-store গুলিয়ে ফেলিনি
• curl -sI দিয়ে নিজের সাইটের Cache-Control, ETag, Age আর Vary header নিজের চোখে দেখেছি
• লগইন-করা পাতা দুটি আলাদা ব্রাউজার/অ্যাকাউন্টে খুলে নিশ্চিত হয়েছি একজনের তথ্য অন্যজন পাচ্ছে না
• নতুন সংস্করণ ছেড়ে দেখেছি HTML আর fingerprinted ফাইল সত্যিই বদলেছে (developer tools-এ Disable cache ছাড়া ও সহ)
• Delay বা hit ratio-র কোনো হিসাব থাকলে নিজে ক্যালকুলেটরে আবার করেছি, আর মডেলের অনুমান লিখে রেখেছি