Stateless বনাম stateful — session, sticky session আর token

১ · State কী — সার্ভার যা মনে রাখে

একটি ব্যাংকের তিনটি কাউন্টারের কথা ভাবুন। প্রথম ব্যবস্থায় প্রতিটি ক্যাশিয়ার নিজের খাতায় অর্ধেক-শেষ কাজ লিখে রাখেন: “রহিম সাহেবের চেক যাচাই হয়েছে, টাকা দেওয়া বাকি।” রহিম সাহেবকে তখন ঠিক সেই কাউন্টারেই ফিরতে হবে। ক্যাশিয়ার দুপুরের খাবারে গেলে কাজ আটকে থাকে, অসুস্থ হলে খাতাসহ সব হারায়। দ্বিতীয় ব্যবস্থায় সব হিসাব থাকে ব্যাংকের কেন্দ্রীয় খাতায়, আর গ্রাহকের হাতে থাকে একটি টোকেন নম্বর। যেকোনো কাউন্টার টোকেন দেখে কেন্দ্রীয় খাতা থেকে বাকিটা জেনে নেন। নতুন কাউন্টার খোলা বা একটি বন্ধ করা তখন সহজ।

প্রথমটি stateful কাউন্টার, দ্বিতীয়টি stateless. State হলো সেই তথ্য, যা একটি অনুরোধ শেষ হওয়ার পরও টিকে থাকে আর পরের অনুরোধের উত্তর বদলে দেয়। প্রায় প্রতিটি অ্যাপেই state আছে; তাই আসল প্রশ্ন “state আছে কি না” নয়, বরং state কোথায় থাকে. অ্যাপ সার্ভারের নিজের memory বা disk-এ থাকলে সার্ভারটি stateful. Database, cache, object storage বা client-এর কাছে সরিয়ে দিলে অ্যাপ সার্ভার stateless.

Stateful সার্ভার কেন বাধা হয়ে দাঁড়ায়

• Scale out আটকে যায়: নতুন সার্ভার যোগ করলে সে খালি। পুরোনো ব্যবহারকারীরা পুরোনো সার্ভারেই বাঁধা, তাই নতুন যন্ত্র সঙ্গে সঙ্গে ভার নেয় না। আর autoscaling-এ সার্ভার কমানো মানে তার ব্যবহারকারীদের state হারানো।
• Failover অর্থহীন হয়: সার্ভার পড়লে তার memory-ও যায়। পাশের replica সুস্থ থাকলেও তার কাছে সেই state নেই।
• Deploy মানে লগআউট: rolling deployment-এ প্রতিটি সার্ভার একবার restart হয়, আর প্রতিবার কিছু মানুষের কাজ হারায়।

পর্ব ১৩-এ stateless নীতি দেখেছি: যেকোনো কপি যেকোনো অনুরোধ সামলাবে, তবেই horizontal scaling সহজ। এই পর্বের প্রশ্ন তার পরের ধাপ: নীতিটি মানলে state যায় কোথায়?

HTTP নিজেই stateless — সার্ভার আগের অনুরোধ মনে রাখে না (REST-এর এই নিয়ম পর্ব ৮-এ)। তাই সার্ভার Set-Cookie header-এ একটি ছোট নাম-মান — cookie — পাঠায়, আর ব্রাউজার পরের প্রতিটি অনুরোধে সেটি ফেরত দেয় (ইতিহাস ভাবনার প্রশ্ন ১-এ, খুঁটিনাটি CN কোর্সের HTTP পর্বে)। এভাবে পরপর কয়েকটি অনুরোধকে “একই মানুষের একই বসা” হিসেবে জোড়াই session.

২ · Sticky session — সহজ পথ, আর তার দাম

সবচেয়ে কম পরিশ্রমের সমাধান: session সার্ভারের memory-তেই থাক, শুধু load balancer নিশ্চিত করুক একই মানুষ সবসময় একই সার্ভারে যান। একে বলে sticky session বা session affinity. Load balancer-এর algorithm আর L4-L7-এর পার্থক্য পর্ব ১৪-এ; এখানে শুধু বাঁধনের দুটি উপায়:

• Cookie-ভিত্তিক: প্রথম উত্তরে load balancer নিজে একটি cookie বসায় (যেমন SRV=s2), পরের অনুরোধে সেটি দেখে একই সার্ভারে পাঠায়। এর জন্য HTTP পড়তে হয়, অর্থাৎ L7 load balancer লাগে।
• IP-ভিত্তিক (IP hash): client-এর ঠিকানার hash থেকে সার্ভার — cookie লাগে না, L4-এও চলে। কিন্তু CGNAT-এর পেছনে হাজারো মোবাইল ব্যবহারকারী একই public IP ভাগ করেন, সবাই পড়েন এক সার্ভারে; Nginx-এর ip_hash তো IPv4-এর প্রথম তিন অংশ (octet) দেখে। আর Wi-Fi থেকে মোবাইল ডেটায় গেলে IP বদলায়, বাঁধন ছুটে যায়।

# HAProxy-ধাঁচ: load balancer নিজে SRV cookie বসায়
backend app
    balance roundrobin
    cookie SRV insert indirect nocache httponly secure
    server s1 10.0.1.11:8080 check cookie s1
    server s2 10.0.1.12:8080 check cookie s2
    server s3 10.0.1.13:8080 check cookie s3

# Nginx-ধাঁচ: client IP-র hash (IPv4-এর প্রথম তিন octet)
upstream app {
    ip_hash;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
    server 10.0.1.13:8080;
}

দাম চার রকম

1. অসম ভার: সমান সংখ্যক session মানেই সমান ভার নয় — কেউ মিনিটে ২টি অনুরোধ করেন, কেউ (ধরুন একটি দোকানের POS যন্ত্র) কয়েকশো, আর sticky-তে তাঁর পুরো ভার একটি সার্ভারেই।
2. সার্ভার পড়লে session হারায়: memory-র সব session, cart আর অর্ধেক-ভরা ফর্ম উধাও।
3. Deploy-এর যন্ত্রণা: restart-এর আগে হয় সবাইকে লগআউট, নয়তো session শেষ হওয়া পর্যন্ত অপেক্ষা — ৩০ মিনিটের idle timeout হলে প্রতি সার্ভারে প্রায় ৩০ মিনিট; ফেরার পর সার্ভারটি খালি।
4. Scale in কঠিন: ভিড় কমলে কোন সার্ভার বন্ধ করবেন? প্রতিটিতেই কারও না কারও session আছে।

নিচের ডায়াগ্রামে তিনটি সার্ভারে ২০০ করে session; রিনা S2-তে বাঁধা, তাঁর cart-এ বাজার। “পরে” চেপে দেখুন S2 পড়লে কী ঘটে:

৩ · Shared session store — cookie-তে শুধু চাবি, তথ্য store-এ

অংশ ১-এর দ্বিতীয় ব্যাংকটিই এখানে নকশা। ব্রাউজারের হাতে শুধু একটি টোকেন — session ID; তাতে কোনো তথ্য লেখা নেই, শুধু একটি দীর্ঘ এলোমেলো নম্বর। আসল তথ্য (কে, কোন ভূমিকা, CSRF token) থাকে সব সার্ভারের ভাগ করা session store-এ, ID ধরে। এই store হতে পারে Redis বা Memcached-ধাঁচের in-memory key-value store, কিংবা ছোট অ্যাপে একটি database টেবিল (Redis-এর গভীরে DBMS কোর্সের Redis পর্ব)।

Session ID কেমন হবে

• অনুমান-অযোগ্য: নিরাপদ random generator থেকে। OWASP-এর session management নির্দেশিকা অন্তত ৬৪ বিট entropy চায়; অনেক দল ১২৮ বিট নেয় — Base64URL-এ ঠিক ২২ অক্ষর। ID-তে user ID, সময় বা ক্রমিক নম্বর নয়।
• Login-এর মুহূর্তে নতুন ID: login-এর আগের ID পরে চলতে দিলে session fixation-এর ঝুঁকি — আগে থেকে ID জানা কেউ লগইন-করা session পেয়ে যান। একই কারণে ভূমিকা বদলালেও (যেমন admin হলে) নতুন ID দেওয়া হয়।
• Session-এ শুধু “আপনি কে”: cart, অর্ডার বা ব্যালান্স ব্যবসার ডেটা — database-এ, user ID ধরে। Session ছোট হলে store ছোট, দ্রুত আর হারালেও ক্ষতি কম।

Cookie-র পাঁচটি flag

Chrome, Edge-এর মতো Chromium-ভিত্তিক ব্রাউজার SameSite না লিখলে Lax ধরে, কিন্তু Firefox আর Safari-র ডিফল্ট আলাদা (সংস্করণভেদে বদলায়) — তাই নিজে লিখুন; CSRF-এর পুরো আলোচনা CN কোর্সের HTTP পর্বের অংশ ৮-এ।

POST /login HTTP/1.1
Host: shop.example
Content-Type: application/x-www-form-urlencoded

user=rina&password=••••••••

HTTP/1.1 303 See Other
Location: /orders
Set-Cookie: __Host-sid=q7Lx2-Vd9KfT0mWbA8sR4u; Path=/; Secure; HttpOnly; SameSite=Lax

GET /orders HTTP/1.1
Host: shop.example
Cookie: __Host-sid=q7Lx2-Vd9KfT0mWbA8sR4u

SET sess:q7Lx2-Vd9KfT0mWbA8sR4u '{"uid":1042,"role":"customer","csrf":"Pq9…"}' EX 1800 NX
GET sess:q7Lx2-Vd9KfT0mWbA8sR4u            # প্রতিটি অনুরোধে, যেকোনো সার্ভার থেকে
TTL sess:q7Lx2-Vd9KfT0mWbA8sR4u            # → 640 (বাকি সেকেন্ড)
EXPIRE sess:q7Lx2-Vd9KfT0mWbA8sR4u 1800    # sliding: বাকি মেয়াদ অর্ধেকের কম হলে নবায়ন
DEL sess:q7Lx2-Vd9KfT0mWbA8sR4u            # logout: সঙ্গে সঙ্গে বাতিল

মেয়াদ — TTL, sliding আর absolute

• TTL: store নিজেই মেয়াদ শেষে key মুছে দেয়; পুরোনো session পরিষ্কারের আলাদা কাজ লাগে না।
• Sliding expiration: সক্রিয় থাকলে মেয়াদ নবায়ন, ৩০ মিনিট নিষ্ক্রিয় থাকলে শেষ। দাম: প্রতিটি পড়া একটি লেখাও হয়ে যায় — তাই বাকি মেয়াদ অর্ধেকের নিচে নামলে তবেই নবায়ন।
• Absolute timeout: নবায়ন যতই চলুক, login-এর ধরা যাক ১২ ঘণ্টা পর আবার login — চুরি যাওয়া session অনন্তকাল চলে না। ব্যাংকিং অ্যাপে idle timeout আরও ছোট, কয়েক মিনিট।

জীবিত session কতগুলো, তা পর্ব ৪-এর Little-এর সূত্র থেকেই আসে: জীবিত session = নতুন login-এর হার × একটি session-এর গড় আয়ু. সেকেন্ডে ৫০০টি login, আর গড়ে ৭০ মিনিট ব্যবহার + ৩০ মিনিট idle timeout = ১০০ মিনিট (৬,০০০ সেকেন্ড) আয়ু হলে ৫০০ × ৬,০০০ = ৩০ লাখ session — অংশ ৪-এর হিসাব এই সংখ্যা দিয়েই।

এবার পথ ক ধাপে ধাপে। খেয়াল করুন, login হলো App 1-এ, অথচ পরের অনুরোধ গেল App 3-এ — তবু কিছু হারাল না:

দুই পথ পাশাপাশি — একটি seeded simulation

এবার মাপি। ৬০০ জন ব্যবহারকারী, তিনটি সার্ভার; মিনিটে অনুরোধের সংখ্যা ভারী-লেজের (Pareto) বণ্টন থেকে — বেশিরভাগ হালকা, অল্প কয়েকজন খুব ব্যস্ত; ৩০%-এর cart-এ জিনিস — সব ধরা যাক। Sticky-তে login-এর সময় প্রত্যেকে সবচেয়ে কম session-এর সার্ভারে বাঁধা হন; shared store-এ load balancer প্রতিটি অনুরোধ আলাদাভাবে round robin-এ পাঠায়। Seed নির্দিষ্ট, তাই প্রতিবার একই ফল:

// Sticky sessions vs a shared session store: S2 crashes, then restarts empty (seeded)
function mulberry32(a) { return () => { a = (a + 0x6D2B79F5) | 0;
  let t = Math.imul(a ^ (a >>> 15), 1 | a); t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
  return ((t ^ (t >>> 14)) >>> 0) / 4294967296; }; }
const SERVERS = 3, USERS = 600, NEW = 150, rand = mulberry32(15);
// ধরা যাক: requests/min per user are heavy-tailed (Pareto, alpha 1.5, min 2); 30% have a cart
const rate = Array.from({ length: USERS + NEW }, () => Math.round(2 / (1 - rand()) ** (1 / 1.5)));
const cart = rate.map(() => rand() < 0.3);
function show(label, load, note = "") {
  const live = load.filter(x => x !== null), avg = live.reduce((s, x) => s + x, 0) / live.length;
  console.log(label.padEnd(16) + load.map((x, i) => ("S" + (i + 1) + "=" + (x === null ? "down" : x)).padStart(9)).join("") +
    "   max/avg " + (Math.max(...live) / avg).toFixed(2) + note);
}
// ---- (a) sticky: at login a user is pinned to the live server holding the fewest sessions
const up = Array(SERVERS).fill(true), pin = [];
const count = s => pin.filter(p => p === s).length;
const login = u => { let best = -1;
  for (let s = 0; s < SERVERS; s++) if (up[s] && (best < 0 || count(s) < count(best))) best = s; pin[u] = best; };
const sticky = () => up.map((ok, s) => ok ? rate.reduce((sum, x, u) => sum + (pin[u] === s ? x : 0), 0) : null);
console.log("req/min per server: " + USERS + " users log in; S2 dies; S2 returns, " + NEW + " new users log in");
for (let u = 0; u < USERS; u++) login(u);
show("sticky  before", sticky());
up[1] = false; const lost = pin.map((p, u) => p === 1 ? u : -1).filter(u => u >= 0);
lost.forEach(login);                                   // they must log in again elsewhere
show("sticky  S2 dead", sticky(), "   lost " + lost.length + " sessions, " + lost.filter(u => cart[u]).length + " carts");
up[1] = true; for (let u = USERS; u < USERS + NEW; u++) login(u);
show("sticky  S2 back", sticky(), "   sessions " + up.map((_, s) => count(s)).join("/"));
// ---- (b) shared store: any server reads any session, so the LB spreads every request
const shared = (users, alive) => { const total = rate.slice(0, users).reduce((s, x) => s + x, 0);
  const k = alive.filter(Boolean).length; let i = 0;
  return alive.map(ok => ok ? Math.floor(total / k) + (i++ < total % k ? 1 : 0) : null); };
const all = Array(SERVERS).fill(true), s2down = all.map((_, s) => s !== 1);
show("shared  before", shared(USERS, all));
show("shared  S2 dead", shared(USERS, s2down), "   lost 0 sessions, 0 carts");
show("shared  S2 back", shared(USERS + NEW, all));

req/min per server: 600 users log in; S2 dies; S2 returns, 150 new users log in
sticky  before    S1=1121  S2=1032  S3=1658   max/avg 1.31
sticky  S2 dead   S1=1688  S2=down  S3=2123   max/avg 1.11   lost 200 sessions, 67 carts
sticky  S2 back   S1=1688   S2=696  S3=2123   max/avg 1.41   sessions 300/150/300
shared  before    S1=1271  S2=1270  S3=1270   max/avg 1.00
shared  S2 dead   S1=1906  S2=down  S3=1905   max/avg 1.00   lost 0 sessions, 0 carts
shared  S2 back   S1=1503  S2=1502  S3=1502   max/avg 1.00

৪ · Session store-এর মাপ, HA আর store বিকল হলে

Store-এ কত memory লাগবে, তা পর্ব ৩-এর ধাঁচে হিসাব করা যায়। প্রতি session-এ খরচ = key + value + store-এর নিজের হিসাব-খাতা (প্রতি key-তে কয়েক দশ বাইট, সংস্করণভেদে আলাদা), তার ওপর memory allocator-এর ভাঙা জায়গা, অর্থাৎ fragmentation; তারপর replica-র জন্য গুণ। নিচে ৩০ লাখ জীবিত session ধরে চারটি value-আকারে হিসাব; সব সংখ্যা ধরা যাক:

// Session store sizing — ধরা যাক: every input is an assumption; measure your own store
const active = 3000000;         // sessions alive (inside their TTL) at peak
const keyBytes = 48;            // "sess:" + a 22-character random id, plus a prefix
const perKeyOverhead = 80;      // the store's own bookkeeping per key (version-dependent)
const frag = 1.25;              // memory allocator fragmentation factor
const copies = 2;               // primary + 1 replica (survive one node)
const nodeGiB = 32, maxUse = 0.6;   // per node; keep 40% headroom (snapshot, spikes, failover)
const qps = 40000;              // requests/s that read the session
const GiB = 1024 ** 3, usable = nodeGiB * maxUse;
console.log("usable per node: " + usable.toFixed(1) + " GiB");
console.log("value B  bytes/session  one copy  all copies  shards  nodes  read MB/s");
for (const value of [512, 2048, 8192, 32768]) {
  const per = (keyBytes + value + perKeyOverhead) * frag;
  const one = active * per / GiB, shards = Math.ceil(one / usable);
  console.log(String(value).padStart(7) + String(per).padStart(15) + (one.toFixed(1) + " GiB").padStart(10) +
    ((one * copies).toFixed(1) + " GiB").padStart(12) + String(shards).padStart(8) +
    String(shards * copies).padStart(7) + (qps * (keyBytes + value) / 1e6).toFixed(1).padStart(11));
}

usable per node: 19.2 GiB
value B  bytes/session  one copy  all copies  shards  nodes  read MB/s
    512            800   2.2 GiB     4.5 GiB       1      2       22.4
   2048           2720   7.6 GiB    15.2 GiB       1      2       83.8
   8192          10400  29.1 GiB    58.1 GiB       2      4      329.6
  32768          41120 114.9 GiB   229.8 GiB       6     12     1312.6

Store এখন নতুন single point of failure

সব অ্যাপ সার্ভার stateless হলো, কিন্তু state গিয়ে জমল এক জায়গায়। Store পড়লে একসাথে সবাই লগআউট বা সব অনুরোধ ব্যর্থ — নতুন single point of failure. তাই:

• Replica আর স্বয়ংক্রিয় failover: Redis-এ Sentinel বা Cluster primary-র মৃত্যু টের পেয়ে replica-কে primary বানায়; Memcached-এর মূল প্রকল্পে replication নেই, তাই node হারালে তার session-ও হারায়।
• Asynchronous replication-এর ফাঁক: Redis-এর replication ডিফল্টে asynchronous — primary পড়ার মুহূর্তের শেষ লেখাগুলো replica-তে না-ও পৌঁছাতে পারে, ফলে সদ্য login করা কয়েকজনকে আবার login করতে হয়। Session-এ এটি সাধারণত চলে, টাকার হিসাবে নয় (তত্ত্ব পর্ব ২২-এ)।
• Shard: এক node-এ না ধরলে session ID-র hash দিয়ে কয়েকটি shard-এ ভাগ — কোন key কোন node-এ, আর node যোগ করলে কত key সরে, তা পরের পর্ব ১৬-এ। Session ID এলোমেলো বলে hot key প্রায় হয় না (বাকিটা পর্ব ৩০-এ)।

৫ · JWT — স্বাক্ষর করা token, state থাকে client-এর হাতে

তৃতীয় পথ: state client-কেই বইতে দিন, কিন্তু এমনভাবে যাতে সে বদলাতে না পারে। ঈদের আগে বাসের টিকিটের কথা ভাবুন। কাউন্টার থেকে কেনা টিকিটে সিল আর সই আছে; বাসের সুপারভাইজার সই চিনলেই বিশ্বাস করেন, কাউন্টারে ফোন করেন না। কিন্তু টিকিট একবার হাতে দিলে বাতিল করা কঠিন: সুপারভাইজার জানবেন কীভাবে যে টিকিটটি ফেরত দেওয়া হয়েছে?

JWT (JSON Web Token, RFC 7519, ২০১৫) ঠিক এই টিকিট। তিনটি অংশ, ডট দিয়ে জোড়া — header.payload.signature — প্রতিটি Base64URL-এ লেখা (সাধারণ Base64-এর URL-নিরাপদ রূপ)। Payload-এর প্রতিটি নাম-মান একটি claim:

header     {"alg":"HS256","typ":"JWT"}
payload    {"sub":"u-1042","role":"customer","iat":1767225600,"exp":1767226500}
signature  HMAC-SHA256(key, base64url(header) + "." + base64url(payload))  → 32 byte

স্বাক্ষরের দুই ধরন — HMAC বনাম public key

HMAC কেন এমন জোড়া-hash

HMAC-এর সূত্র (Bellare, Canetti ও Krawczyk, ১৯৯৬; RFC 2104):

সরলভাবে H(K ‖ m) নিলে চলত না কেন? SHA-256-এর মতো Merkle–Damgård ধাঁচের hash-এর ফল আসলে শেষ অবস্থার ছবি — সেখান থেকে hash-টি “আরও কিছু যোগ করে” চালিয়ে যাওয়া যায়, চাবি না জেনেও — একে বলে length extension. ফলে H(K ‖ m) থেকে লম্বা একটি বার্তার বৈধ মান বানানো সম্ভব। HMAC-এ ভেতরের hash-এর ফলকে আরেকটি চাবি-মেশানো hash-এর ভেতরে মুড়ে দেওয়া হয়; বাইরের স্তর না ভেঙে ভেতরের ফল বাড়ানো যায় না। প্রমাণের ধারণা: compression function যদি একটি pseudorandom function-এর মতো আচরণ করে, তবে HMAC-ও করে — এটি Bellare-এর ২০০৬ সালের প্রমাণ; ১৯৯৬ সালের মূল প্রমাণে অনুমান কিছুটা ভিন্ন ছিল। Cryptography-র ভিত্তি CN কোর্সের MAC আর HMAC অংশে।

নিচের কোড কোনো library ছাড়াই SHA-256, তার ওপর HMAC, তার ওপর JWT-এর সই ও যাচাই লেখে, আর আগে test vector দিয়ে নিজেকে মিলিয়ে নেয়: RFC 4231 (২০০৫)-এর test case 2-এ চাবি "Jefe" আর বার্তা "what do ya want for nothing?"-এর HMAC-SHA256 প্রকাশিত মান 5bdcc146…ec3843. ঘড়ি স্থির — ১ জানুয়ারি ২০২৬, রাত ১২টা (UTC):

// HS256 JWT from scratch: SHA-256 (FIPS 180-4) -> HMAC (RFC 2104) -> sign / verify (RFC 7519)
const K = [], H0 = [], r = (x, n) => x >>> n | x << (32 - n);
for (let n = 2; K.length < 64; n++) { if ([...Array(n).keys()].slice(2).some(d => n % d === 0)) continue;
  if (H0.length < 8) H0.push(n ** (1 / 2) * 2 ** 32 | 0); K.push(n ** (1 / 3) * 2 ** 32 | 0); }
function sha256(bytes) {                              // array of bytes -> array of 32 bytes
  const m = [...bytes, 0x80], w = [], L = bytes.length * 8; let h = H0.slice();
  while (m.length % 64 !== 56) m.push(0); for (let i = 7; i >= 0; i--) m.push(Math.floor(L / 2 ** (8 * i)) & 255);
  for (let j = 0; j < m.length; j += 64) {
    for (let i = 0; i < 64; i++) w[i] = i < 16 ? m[j + 4 * i] << 24 | m[j + 4 * i + 1] << 16 | m[j + 4 * i + 2] << 8 | m[j + 4 * i + 3]
      : (r(w[i - 2], 17) ^ r(w[i - 2], 19) ^ w[i - 2] >>> 10) + w[i - 7] + (r(w[i - 15], 7) ^ r(w[i - 15], 18) ^ w[i - 15] >>> 3) + w[i - 16] | 0;
    let [a, b, c, d, e, f, g, k] = h; for (let i = 0; i < 64; i++) {
      const t1 = k + (r(e, 6) ^ r(e, 11) ^ r(e, 25)) + (e & f ^ ~e & g) + K[i] + w[i] | 0;
      const t2 = (r(a, 2) ^ r(a, 13) ^ r(a, 22)) + (a & b ^ a & c ^ b & c) | 0;
      k = g; g = f; f = e; e = d + t1 | 0; d = c; c = b; b = a; a = t1 + t2 | 0; }
    h = h.map((x, i) => x + [a, b, c, d, e, f, g, k][i] | 0); }
  return h.flatMap(x => [x >>> 24, x >>> 16 & 255, x >>> 8 & 255, x & 255]); }
function hmac(key, msg) { if (key.length > 64) key = sha256(key); const k = [...key, ...Array(64 - key.length).fill(0)];
  return sha256([...k.map(x => x ^ 0x5c), ...sha256([...k.map(x => x ^ 0x36), ...msg])]); }
const enc = s => [...new TextEncoder().encode(s)], hex = b => b.map(x => x.toString(16).padStart(2, "0")).join("");
const b64u = b => btoa(String.fromCharCode(...b)).replace(/\+/g, "-").replace(/\//g, "_").replace(/=+$/, "");
const json = s => JSON.parse(atob(s.replace(/-/g, "+").replace(/_/g, "/")));   // ASCII-only demo
const SECRET = enc("demo-only-key: real keys are 32+ random bytes from a vault"), HEAD = b64u(enc('{"alg":"HS256","typ":"JWT"}'));
const sign = p => { const hp = HEAD + "." + b64u(enc(JSON.stringify(p))); return hp + "." + b64u(hmac(SECRET, enc(hp))); };
function verify(token, now) { const [h, p, s = ""] = token.split(".");
  if (json(h).alg !== "HS256") return "REJECT: alg not allowed";              // allow-list, never trust the header
  const good = b64u(hmac(SECRET, enc(h + "." + p))); let diff = good.length ^ s.length;
  for (let i = 0; i < good.length; i++) diff |= good.charCodeAt(i) ^ (s.charCodeAt(i) | 0);   // constant-time compare
  if (diff) return "REJECT: bad signature";
  const c = json(p); return now >= c.exp ? "REJECT: expired" : "OK  sub=" + c.sub + " role=" + c.role; }
console.log("RFC 4231 test case 2:\n" + hex(hmac(enc("Jefe"), enc("what do ya want for nothing?"))));
const now = 1767225600, t = sign({ sub: "u-1042", role: "customer", iat: now, exp: now + 900 });  // 2026-01-01 00:00 UTC
const [h, , s] = t.split("."), forged = h + "." + b64u(enc(JSON.stringify({ sub: "u-1042", role: "admin", iat: now, exp: now + 900 }))) + "." + s;
console.log("token (" + t.length + " chars):\n" + t.match(/.{1,44}/g).join("\n"));
for (const [label, tok, at] of [["1 valid, 60 s later ", t, now + 60], ["2 payload edited    ", forged, now + 60], ["3 valid, 901 s later", t, now + 901]])
  console.log(label + " : " + verify(tok, at));

RFC 4231 test case 2:
5bdcc146bf60754e6a042426089575c75a003f089d2739839dec58b964ec3843
token (172 chars):
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWI
iOiJ1LTEwNDIiLCJyb2xlIjoiY3VzdG9tZXIiLCJpYXQ
iOjE3NjcyMjU2MDAsImV4cCI6MTc2NzIyNjUwMH0.2ji
Lp1cKl-pW6qlFLS1e6DNLjLpFzJYs3Run3ZIDcn8
1 valid, 60 s later  : OK  sub=u-1042 role=customer
2 payload edited     : REJECT: bad signature
3 valid, 901 s later : REJECT: expired

আকারের দাম

উপরের ছোট token-ও প্রতি অনুরোধে Authorization: Bearer -সহ ১৯৪ বাইট; একটি session cookie (Cookie: __Host-sid= + ২২ অক্ষর) মাত্র ৪১। বাস্তবের JWT-এ RS256 স্বাক্ষর আর দশ-পনেরোটি claim থাকলে প্রায়ই কয়েকশো থেকে হাজার বাইট ছাড়ায়। ১ KB-এর token × সেকেন্ডে ৫০,০০০ অনুরোধ = সেকেন্ডে ৫০ MB, প্রায় ৪০০ Mbit/s শুধু token বইতে।

৬ · Revocation সমস্যা আর JWT-এর নিরাপদ ব্যবহার

JWT-এর শক্তিই তার দুর্বলতা। যাচাইয়ের জন্য সার্ভার কিছু মনে রাখে না — তাই কোনো token “ভুলে যেতে” বলার জায়গাও নেই। Logout, password বদল, ভূমিকা কমানো বা ফোন চুরি — সব ক্ষেত্রে আগে দেওয়া token exp পর্যন্ত বৈধই থাকে। একেই বলে token revocation-এর সমস্যা। নিচে access token-এর মেয়াদ ১৫ মিনিট, সাথে একটি refresh token:

প্রতিকার তিনটি — আর তাদের দাম

খেয়াল করুন, deny list আর token version দুটোতেই একটি shared lookup ফিরে এসেছে — এটিই সৎ trade-off: যত দ্রুত revocation চাই, তত বেশি state লাগে। OAuth 2.0, ID token আর access token-এর পার্থক্য পর্ব ৫২ (নকশায় নিরাপত্তা)-এ; এখানে প্রশ্ন শুধু state কোথায় থাকে।

JWT-এর নিরাপদ ব্যবহার — প্রতিরক্ষার নিয়ম

1. শুধু decode নয়, verify: অনেক library-তে decode স্বাক্ষর যাচাই করে না। প্রতিবার স্বাক্ষর, exp, iss, aud — সব।
2. Algorithm নিজে ঠিক করুন: সার্ভার আগে থেকেই জানবে কোন algorithm চলবে; token-এর header-এর alg-কে বিশ্বাস করবেন না, none কখনো নয়, আর প্রতিটি চাবি একটি নির্দিষ্ট algorithm-এ বাঁধা। এই নিয়মগুলো এখন RFC 8725 (২০২০)-এ লেখা; পেছনের ইতিহাস ভাবনার প্রশ্ন ২-এ।
3. শক্ত, গোপন চাবি: HS256-এ অন্তত ২৫৬ বিট এলোমেলো চাবি, কোডে বা repository-তে নয় — secret manager-এ। মনে রাখার মতো password চাবি হিসেবে চলবে না: একটি token হাতে পেলেই দুর্বল চাবি offline-এ অনুমানের চেষ্টা করা যায়।
4. Token কোথায় রাখবেন: ব্রাউজারের localStorage-এ রাখলে পাতার যেকোনো script পড়তে পারে, তাই একটি XSS-ই যথেষ্ট। HttpOnly, Secure, SameSite cookie-তে রাখলে script পড়তে পারে না, তবে তখন CSRF-এর প্রতিরক্ষা লাগে। মোবাইল অ্যাপে OS-এর নিরাপদ ভান্ডার, যেমন Android Keystore বা iOS Keychain.
5. Role পুরোনো হয়ে যায়: token-এ লেখা ভূমিকা ইস্যুর মুহূর্তের; admin থেকে সরালেও token-এ admin থেকে যায় মেয়াদ পর্যন্ত। তাই ছোট মেয়াদ বা token version, আর “এই অর্ডারটি কি এঁর?” ধরনের প্রশ্ন প্রতিবার সার্ভিসে যাচাই — একে বলে object-level authorization.

৭ · Encrypted cookie আর চার পথের তুলনা

চতুর্থ পথ JWT-এর আত্মীয়: encrypted cookie. সার্ভার পুরো session-এর তথ্য নিজের চাবিতে authenticated encryption (যেমন AES-GCM) দিয়ে বন্ধ করে cookie-তেই রেখে দেয়। Client পড়তে বা বদলাতে পারে না, যেকোনো সার্ভার একই চাবিতে খোলে — store লাগে না। ডকুমেন্টেশন অনুযায়ী Ruby on Rails-এর ডিফল্ট session ব্যবস্থা এভাবেই চলে, আর Django-তে signed cookie-র একটি ব্যবস্থা আছে যা শুধু সই করে, এনক্রিপ্ট করে না (সংস্করণভেদে আলাদা)।

সীমা তিনটি। (ক) আকার: RFC 6265 ব্রাউজারকে প্রতি cookie-তে অন্তত ৪,০৯৬ বাইট ধরতে বলে, তার বেশি নির্ভরযোগ্য নয়; আর প্রতিটি অনুরোধে — ছবি আর CSS-এরও — পুরোটা যায়। (খ) Revocation: JWT-এর মতোই কঠিন। (গ) পুরোনো cookie আবার পাঠানো: ব্যবহারকারী নিজেই আগের একটি বৈধ cookie রেখে দিয়ে পরে পাঠাতে পারেন; তাই “বাকি ফ্রি ডাউনলোড ৩” ধরনের বদলাতে থাকা অধিকার কখনো client-এর cookie-তে নয় — সেটি থাকবে সার্ভারে।

৮ · Session ছাড়াও state — আর যখন stateful-ই সঠিক

আরও যে state বাইরে সরাতে হয়

• File upload: অ্যাপ সার্ভারের local disk-এ জমালে পরের খণ্ড অন্য সার্ভারে গিয়ে হারায়। ভালো নকশায় client সরাসরি object storage-এ খণ্ড খণ্ড করে পাঠায় (multipart বা resumable upload), আর কোন খণ্ড পৌঁছেছে তা storage জানে (পর্ব ২৬)।
• Local cache: প্রতিটি কপির নিজের cache আলাদা সময়ে হালনাগাদ হয় — একই মানুষ পরপর দুটি অনুরোধে দুটি দাম দেখতে পারেন। প্রতিকার: ছোট TTL, বদলের খবর pub/sub-এ, বা shared cache; stock বা ব্যালান্স local cache-এ নয় (পর্ব ২৯, ৩০)।
• Scheduled job: প্রতিটি কপিতে cron চালালে ১০টি কপিতে ১০ বার — একই বিল দশবার ইমেইলে! প্রতিকার: আলাদা scheduler, বা lease দিয়ে একজনকেই অধিকার, আর কাজটি idempotent (পর্ব ৩৭, ৪৩)।
• Rate limit-এর counter: প্রতিটি সার্ভার নিজে গুনলে ১০টি সার্ভারে সীমা কার্যত দশ গুণ — counter থাকবে shared store-এ (পর্ব ৪৯)।
• WebSocket সংযোগ: সংযোগ নিজেই state, সরানো যায় না; তাই পাতলা gateway স্তর আর connection registry (পর্ব ১০)।

যখন stateful-ই সঠিক

কিছু কাজে state সরানোই ভুল — প্রতি পদক্ষেপে বাইরের store-এ যাওয়া খুব ধীর বা দামি:

• Database: state রাখাই তার কাজ।
• Game server: একটি ম্যাচের অবস্থান সেকেন্ডে কয়েক ডজন বার বদলায়; state থাকে একটি সার্ভারের memory-তে, আর matchmaking ম্যাচের সবাইকে সেখানেই পাঠায় (ভাবনার প্রশ্ন ৪)।
• Stream processor: চলমান যোগফল বা সময়ের window প্রতিটি event-এ বাইরে গেলে ধীর; state থাকে স্থানীয়ভাবে, আর নিয়মিত checkpoint যায় টেকসই storage-এ (পর্ব ৩৬)।

এদের সামলানোর কৌশল তিনটি। Key ধরে ভাগ: প্রতিটি key-এর (ম্যাচ, ব্যবহারকারী, partition) একজন নির্দিষ্ট মালিক; কোন key কার, তা ঠিক করে consistent hashing বা একটি partition map (পর্ব ১৬, পর্ব ২৩)। Replication: মালিকের কপি আরেক node-এ, মালিক পড়লে কপি দায়িত্ব নেয় (পর্ব ২২)। Checkpoint আর replay: নিয়মিত snapshot, তার পরের ঘটনাগুলো log থেকে আবার চালিয়ে state ফেরানো। খেয়াল করুন, এখানে “একই key সবসময় একই node-এ” — দেখতে sticky session-এর মতোই, কিন্তু পার্থক্য মৌলিক: মালিকানা জানা, কপি আছে, failover পরিকল্পিত।

Deploy-এর সময় session

• Shared store বা JWT হলে: rolling deploy সহজ। প্রতিটি সার্ভারে connection draining — load balancer আগে নতুন অনুরোধ পাঠানো বন্ধ করে, চলমান অনুরোধ শেষ হতে দেয় (ধরা যাক ৩০ সেকেন্ড), তারপর বন্ধ। Session store-এ থাকায় কেউ লগআউট হন না।
• Sticky আর memory-র session হলে: session শেষ হওয়া পর্যন্ত draining (ধীর); session migration — বন্ধের আগে session-গুলো অন্য node বা store-এ লিখে দেওয়া (Tomcat-এর cluster-এর মতো কিছু ব্যবস্থা session অন্য node-এ কপি রাখে); অথবা কিছু মানুষের লগআউট মেনে নেওয়া।
• Session-এর format বদলালে: rolling deploy-এ পুরোনো আর নতুন কোড একসাথে চলে, আর একই session দুই সংস্করণই পড়ে। নতুন field ঐচ্ছিক রাখুন, অজানা field উপেক্ষা করুন — পর্ব ১২-এর schema evolution-এর নিয়ম এখানেও।
• JWT-এর চাবি বদলালে: নতুন public key আগে JWKS-এ প্রকাশ, সব সার্ভিসের cache-এ পৌঁছানোর পর তা দিয়ে সই শুরু, আর পুরোনো চাবি সরানো যায় তার দেওয়া শেষ token-এর মেয়াদ ফুরোলে। বাকি release-কৌশল পর্ব ৫৩-এ।

৯ · AI-এর যুগে session আর token নকশা যাচাই

Login-এর নকশা চাইলে AI প্রায় নিশ্চিতভাবে লিখবে “JWT নিন, stateless হবে, সাথে Redis আর Kafka”. শব্দগুলো ভুল নয়, কিন্তু ছোট অ্যাপে প্রায়ই over-engineering — একটি database টেবিলেই session চলে — আর আসল প্রশ্ন বাদ পড়ে:

AI-এর দেওয়া session নকশা হাতে পেলে — যাচাইয়ের চেকলিস্ট

• Logout, password বদল আর চুরি যাওয়া ডিভাইস — তিনটিতেই পুরোনো session বা token কত দ্রুত অচল হয়, সংখ্যায় লিখেছি
• Session-সংখ্যা Little-এর সূত্রে আর store-এর memory overhead, fragmentation, replica ও headroom-সহ নিজে আবার হিসাব করেছি
• উদাহরণ JWT decode করে দেখেছি — গোপন বা ব্যক্তিগত কিছু নেই; algorithm allow-list, iss, aud আর exp যাচাই আছে
• Staging-এ একটি অ্যাপ সার্ভার মেরে, একটি deploy চালিয়ে আর store বন্ধ করে দেখেছি — কে লগআউট হয়, কী চালু থাকে, timeout কত
• পণ্যের সীমা (cookie-র আকার, proxy-র header-সীমা, replication-এর নিশ্চয়তা) অফিসিয়াল ডকুমেন্টেশনে মিলিয়েছি; অপ্রয়োজনীয় অংশ বাদ দিয়েছি