real-time অ্যাপ — WebSocket আর Server-Sent Events

১ · সার্ভার কেন নিজে থেকে খবর দিতে পারে না — request–response-এর সীমা

পর্ব ৩৫-এ আপনি HTTP-র মূল নিয়ম দেখেছেন: client (ব্রাউজার) একটি অনুরোধ পাঠায়, server একটি উত্তর দেয়, কথা শেষ। পর্ব ৫০-এ Express দিয়ে যে REST API বানানো হয়েছে, সেটিও এই ছাঁচে চলে। নিয়মটির একটি গোপন শর্ত আছে — কথা শুরু করে সবসময় client. সার্ভারের কাছে নতুন খবর থাকলেও সে ব্রাউজারকে ডাকতে পারে না; অপেক্ষা করতে হয়, কবে ব্রাউজার আবার জিজ্ঞেস করবে।

বেশিরভাগ পাতায় এতে সমস্যা নেই। কিন্তু কিছু কাজে খবরের মূল্য তার সময়ে:

এই কাজগুলোকে বলা হয় real-time — খবর তৈরি হওয়া আর পর্দায় পৌঁছানোর মাঝের দেরি (latency) যতটা সম্ভব কম। ব্যবহারিক ভাষায়, সার্ভারকে খবর push করতে হয়, client-কে বারবার pull করতে নয়। ওয়েবে এর তিনটি প্রধান পথ আছে, আর সেগুলো একটি সিঁড়ির মতো — সরল থেকে শক্তিশালী।

পুরো পর্বের মূল প্রশ্ন তাই একটি: আপনার কাজে খবর কোন দিকে যায়, আর কত ঘন ঘন? সিঁড়ির প্রতিটি ধাপে ক্ষমতার সাথে জটিলতাও বাড়ে।

২ · Polling আর long polling — পুরোনো পথ আর তার খরচ

পর্ব ৩৬-এ polling আর long polling-এর পরিচয় পেয়েছেন। এবার খরচের হিসাবটা করা যাক, কারণ সিদ্ধান্ত নিতে হিসাব লাগে।

একটি খাবার-ডেলিভারি অ্যাপ ধরুন। সন্ধ্যার ভিড়ে ১০,০০০ জন গ্রাহক অর্ডারের পাতা খুলে রেখেছেন, আর পাতাটি প্রতি ৫ সেকেন্ডে জিজ্ঞেস করে “অবস্থা বদলেছে?” তাহলে সার্ভারে আসে সেকেন্ডে ১০,০০০ ÷ ৫ = ২,০০০টি request. একটি অর্ডারের অবস্থা গোটা ৪০ মিনিটে হয়তো ৪–৫ বার বদলায়; অর্থাৎ ৪৮০টি প্রশ্নের মধ্যে ৪৭৫টির উত্তর “না, কিছু বদলায়নি”। প্রতিটির সাথে যায় cookie আর header, প্রতিটিতে লগইন যাচাই আর ডেটাবেস খোঁজা — তবু খবর আসে গড়ে আড়াই সেকেন্ড দেরিতে। বিরতি কমালে দেরি কমে, খরচ বাড়ে; এই টানাপোড়েনই polling-এর মূল সমস্যা।

Long polling-এ ব্রাউজার জিজ্ঞেস করে, আর সার্ভার উত্তর আটকে রাখে যতক্ষণ না খবর আসে বা একটি সময়সীমা পেরোয়। খবর এলে উত্তর যায়, ব্রাউজার সাথে সাথে নতুন request পাঠায়। দেরি কম, কিন্তু একটি সূক্ষ্ম ফাঁক আছে: উত্তর পাঠানো আর নতুন request আসার মাঝের মুহূর্তে আরেকটি খবর তৈরি হলে সেটি কোথায় থাকবে? সমাধান হলো প্রতিটি খবরের একটি ক্রমিক id রাখা, আর client প্রতিবার বলে দেবে “আমি ১৭ পর্যন্ত পেয়েছি”। এই ধারণাটি মনে রাখুন — SSE-র Last-Event-ID ঠিক এটাই, তবে তৈরি অবস্থায়।

৩ · Server-Sent Events — একটি খোলা HTTP সংযোগে একমুখী ধারা

Server-Sent Events (SSE)-এর বুদ্ধিটি খুব সাদামাটা: ব্রাউজার একটি সাধারণ GET request পাঠায়, আর সার্ভার উত্তর দেয় — কিন্তু উত্তর শেষ করে না. সংযোগ খোলা রেখে সে মাঝে মাঝে কয়েক লাইন লেখা পাঠাতে থাকে। প্রতিটি লেখার টুকরো একটি event. নতুন কোনো প্রোটোকল নেই, নতুন port নেই — শুধু একটি লম্বা HTTP উত্তর, যার header-এ লেখা Content-Type: text/event-stream.

text/event-stream ফরম্যাট — চারটি field আর একটি ফাঁকা লাইন

এই event-stream ফরম্যাট UTF-8 লেখার কয়েকটি লাইন। প্রতিটি লাইন field: মান, আর একটি ফাঁকা লাইন মানে “এই event শেষ, এবার পাঠাও”। Field মোট চারটি:

retry: 3000

id: 1
event: status
data: {"step":"cooking","text":"রান্না হচ্ছে"}

: এটি একটি comment — ব্রাউজার উপেক্ষা করে, সংযোগ সজাগ রাখতে কাজে লাগে

id: 2
event: status
data: {"step":"on-the-way",
data: "text":"রাইডার রওনা দিয়েছেন"}

ব্রাউজারে EventSource

ব্রাউজারের EventSource API এই ফরম্যাট পড়ে প্রতিটি event-কে একটি DOM event বানিয়ে দেয়। নামহীন event আসে onmessage-এ, আর নাম থাকলে addEventListener("নাম", …) দিয়ে ধরতে হয় — onmessage সেগুলো পায় না, নতুনদের একটি সাধারণ বিভ্রান্তি:

const es = new EventSource("/orders/42/events");   // একই origin — cookie নিজে থেকেই যায়

es.addEventListener("status", (e) => {
  const { step, text } = JSON.parse(e.data);
  showStep(text);                                   // "রাইডার রওনা দিয়েছেন"
  if (step === "delivered") es.close();             // কাজ শেষ — আর reconnect নয়
});
es.onmessage = (e) => console.log("নামহীন event:", e.data, e.lastEventId);
es.onerror = () => console.log("সংযোগে সমস্যা, readyState =", es.readyState);
// readyState: 0 = CONNECTING (আবার চেষ্টা চলছে), 1 = OPEN, 2 = CLOSED

এখানে সবচেয়ে মূল্যবান অংশটি কোডে দেখাই যায় না: স্বয়ংক্রিয় reconnection. নেটওয়ার্ক কাটলে বা সার্ভার উত্তর শেষ করে দিলে EventSource নিজেই retry-এর সময় (না দিলে ব্রাউজারের ঠিক করা কয়েক সেকেন্ড) অপেক্ষা করে আবার সংযোগ করে, আর নতুন request-এ একটি header যোগ করে: Last-Event-ID, যার মান শেষ পাওয়া id. সার্ভার সেটি দেখে শুধু বাকি event-গুলো পাঠায়। সার্ভার যদি চায় ব্রাউজার আর চেষ্টা না করুক, সে HTTP 204 No Content দেয়; ভুল status বা ভুল Content-Type পেলেও ব্রাউজার চেষ্টা থামিয়ে দেয়।

GET /orders/42/events HTTP/1.1
Accept: text/event-stream
Cookie: session=…

← HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache

retry: 3000

id: 1
event: status
data: রান্না হচ্ছে

id: 2
event: status
data: রাইডার রওনা দিয়েছেন
… (সংযোগ খোলা)

es.readyState      → 0 (CONNECTING)
es.onerror         → একবার ডাকা হলো
মনে রাখা lastEventId = "2"
অপেক্ষা: retry = 3000 ms

GET /orders/42/events HTTP/1.1
Accept: text/event-stream
Last-Event-ID: 2

id: 3
event: status
data: পৌঁছে গেছে
ব্রাউজার: step === "delivered" → es.close()

নিজে চালিয়ে দেখুন — Node.js-এ SSE সার্ভার আর client একসাথে

নিচের প্রোগ্রামে একটি আসল SSE সার্ভার (node:http) আর একই প্রোগ্রামে একটি client আছে। Node 20-এ EventSource নেই, তাই client fetch দিয়ে res.body-কে ReadableStream হিসেবে পড়ে আর নিজে লাইন ধরে ফরম্যাটটি parse করে — EventSource ভেতরে ঠিক এই কাজই করে। সার্ভার প্রথম সংযোগে দুটি event পাঠিয়ে উত্তর শেষ করে দেয় (সংযোগ কাটার নকল), তারপর client Last-Event-ID নিয়ে ফিরে আসে:

const http = require("node:http");
const updates = ["রান্না হচ্ছে", "রাইডার রওনা দিয়েছেন", "পৌঁছে গেছে"];
let visits = 0;
const server = http.createServer((req, res) => {
  res.writeHead(200, { "Content-Type": "text/event-stream", "Cache-Control": "no-cache" });
  const from = Number(req.headers["last-event-id"] ?? 0) + 1;   // কোথা থেকে আবার শুরু
  const to = ++visits === 1 ? 2 : updates.length;               // প্রথম সংযোগ ২টির পরে কাটে
  for (let id = from; id <= to; id++) res.write(`id: ${id}\nevent: status\ndata: ${updates[id - 1]}\n\n`);
  res.end();
});
let lastId;                                                      // EventSource যা মনে রাখে
async function listen(url) {
  const res = await fetch(url, { headers: lastId ? { "Last-Event-ID": lastId } : {} });
  let buf = "", ev = {};
  for await (const text of res.body.pipeThrough(new TextDecoderStream())) {
    const lines = (buf + text).split("\n"); buf = lines.pop();  // অসম্পূর্ণ শেষ লাইন রেখে দিন
    for (const line of lines) {
      if (line) { const i = line.indexOf(":"); ev[line.slice(0, i)] = line.slice(i + 2); continue; }
      console.log(`#${ev.id} ${ev.event}: ${ev.data}`); lastId = ev.id; ev = {};  // ফাঁকা লাইন
    }
  }
}
server.listen(0, "127.0.0.1", async () => {
  const url = `http://127.0.0.1:${server.address().port}/orders/42/events`;
  await listen(url);
  console.log(`সংযোগ কেটে গেল — Last-Event-ID: ${lastId} দিয়ে আবার`);
  await listen(url);
  server.close();
});

৪ · বাস্তবের SSE সার্ভার — Express, proxy আর সীমাবদ্ধতা

পর্ব ৫০-এর Express-এ একটি SSE route দেখতে প্রায় সাধারণ route-এর মতোই; পার্থক্য হলো res.json()-এর বদলে বারবার res.write(), আর ব্রাউজার চলে গেলে পরিষ্কার করা:

app.get("/orders/:id/events", requireLogin, async (req, res) => {
  if (!(await canSeeOrder(req.user, req.params.id))) return res.sendStatus(403);
  res.set({
    "Content-Type": "text/event-stream",
    "Cache-Control": "no-cache",
    "X-Accel-Buffering": "no",                 // nginx-কে বলুন: জমিয়ে রাখবেন না
  });
  res.flushHeaders();                          // header এখনই পাঠান
  const send = (e) => res.write(`id: ${e.seq}\nevent: status\ndata: ${JSON.stringify(e)}\n\n`);
  const lastId = Number(req.get("Last-Event-ID") ?? 0);
  (await orderEvents.since(req.params.id, lastId)).forEach(send);   // হারানোগুলো আগে
  const unsubscribe = orderEvents.subscribe(req.params.id, send);   // তারপর নতুনগুলো
  const ping = setInterval(() => res.write(": ping\n\n"), 25_000);  // comment — সংযোগ সজাগ
  req.on("close", () => { clearInterval(ping); unsubscribe(); });   // না করলে memory leak
});

Proxy আর buffering — “লোকালে চলে, সার্ভারে চলে না”

SSE-র সবচেয়ে প্রচলিত অভিযোগ: লোকালে সব ঠিক, কিন্তু deploy করার পরে event আসে একসাথে, অনেক দেরিতে, বা উত্তর শেষ হলে একবারে। কারণ প্রায় সবসময় মাঝখানের কেউ উত্তরটি জমিয়ে রাখছে। nginx reverse proxy ডিফল্টভাবে backend-এর উত্তর buffer করে — এই proxy buffering সাধারণ পাতার জন্য ভালো, stream-এর জন্য মারাত্মক। সমাধান: সেই location-এ proxy_buffering off;, অথবা উপরের মতো X-Accel-Buffering: no header; সাথে proxy_read_timeout বাড়ানো। Express-এর compression middleware-ও লেখা জমায় — stream route-এ বন্ধ রাখুন।

SSE-র সীমা

• একমুখী। সার্ভার থেকে ব্রাউজারে শুধু। ব্রাউজারের কিছু পাঠাতে হলে সাধারণ fetch POST — যা আসলে বেশিরভাগ অ্যাপে যথেষ্ট (চ্যাটেও বার্তা POST করে, নতুন বার্তা SSE-তে পাওয়া যায়)।
• শুধু লেখা (UTF-8), শুধু GET, নিজের header নয়। EventSource-এ Authorization header বসানো যায় না। তাই authentication চলে cookie দিয়ে (ভিন্ন origin হলে { withCredentials: true } আর CORS), বা একটি স্বল্পমেয়াদি token URL-এ। POST বা header দরকার হলে fetch দিয়ে stream পড়ে নিজে parse করুন — AI চ্যাট-অ্যাপগুলো এভাবেই করে।
• HTTP/1.1-এ সংযোগের সীমা। HTTP/1.1-এ ব্রাউজার একটি domain-এ একসাথে সাধারণত ৬টির বেশি সংযোগ খোলে না — সব tab মিলিয়ে। ৭টি tab-এ একই সাইট খোলা থাকলে সপ্তমটি আটকে থাকতে পারে। HTTP/2-তে একটি TCP সংযোগের ভেতরে অনেকগুলো stream চলে (সাধারণত ১০০ বা তার বেশি), তাই সমস্যাটি প্রায় মুছে যায় — production-এ HTTP/2 চালু রাখুন।

৫ · WebSocket — handshake, frame আর ব্রাউজার API

SSE-তে ব্রাউজার শুধু শোনে। সাপোর্ট চ্যাটে দুজনেই লেখেন, “টাইপ করছেন…” সেকেন্ডে কয়েকবার বদলায় — প্রতিটির জন্য আলাদা POST মানে প্রতিবার পুরো header আর লগইন যাচাই। WebSocket একটি TCP সংযোগকে খোলা রেখে দুই পক্ষকে যেকোনো সময়, একই সাথে কথা বলতে দেয় — একে বলে full-duplex. প্রতিটি বার্তার সাথে বাড়তি মাত্র কয়েক byte যায়, header-এর কয়েকশো byte নয়।

Handshake — HTTP দিয়ে শুরু, তারপর অন্য প্রোটোকল

WebSocket আলাদা port বা নতুন ধরনের সংযোগ দিয়ে শুরু হয় না। শুরু হয় একটি সাধারণ HTTP GET দিয়ে, যাতে লেখা থাকে “চলুন প্রোটোকল বদলাই” — এই protocol upgrade-এর ফলে একই port (80 বা 443), একই firewall নিয়ম আর একই সার্ভার ব্যবহার করা যায়। সার্ভার রাজি হলে উত্তর দেয় 101 Switching Protocols, আর সেই মুহূর্ত থেকে ওই TCP সংযোগে HTTP আর চলে না — চলে WebSocket-এর frame.

GET /support HTTP/1.1
Host: chat.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Origin: https://shop.example.com
Cookie: session=…

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
← এখান থেকে আর HTTP নয়

→ [text, masked]  {"type":"chat","text":"আমার অর্ডার কোথায়?"}
← [text]          {"type":"typing","from":"করিম"}
← [text]          {"type":"chat","from":"করিম","text":"দেখছি…"}
client → server frame সবসময় masked; উল্টো দিকে নয়

← [ping]   (সার্ভার, প্রতি ৩০ সেকেন্ডে)
→ [pong]   (ব্রাউজার স্বয়ংক্রিয়ভাবে)
pong না এলে সার্ভার সংযোগটিকে মৃত ধরে বন্ধ করে

→ [close] code 1000, reason "চ্যাট শেষ"
← [close] code 1000
তারপর TCP সংযোগ বন্ধ; ws.onclose → e.code 1000, e.wasClean true

অভিজ্ঞ পাঠকদের জন্য — Sec-WebSocket-Accept-এর হিসাব Node-এ তিন লাইনের। RFC 6455-এর নিজের উদাহরণের key দিলে নিচের মানটিই আসে (চালানো যায় না এমন উদাহরণ; লোকাল Node-এ যাচাই করা):

const { createHash } = require("node:crypto");
const GUID = "258EAFA5-E914-47DA-95CA-C5AB0DC85B11";     // RFC 6455-এ লেখা স্থির মান
const key = "dGhlIHNhbXBsZSBub25jZQ==";                  // ব্রাউজারের Sec-WebSocket-Key
console.log(createHash("sha1").update(key + GUID).digest("base64"));
// প্রত্যাশিত আউটপুট: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Frame-এর ধরন আর ws:// বনাম wss://

ws:// হলো খোলা লেখায় WebSocket (HTTP-র মতো), আর wss:// হলো TLS-এ মোড়া (HTTPS-এর মতো, port 443). Production-এ সবসময় wss://: চ্যাটের লেখা আর token পথে কেউ পড়তে পারে না, HTTPS পাতা থেকে ws:// খোলা ব্রাউজার আটকে দেয় (mixed content), আর এনক্রিপ্ট করা সংযোগ মাঝের proxy খুলে দেখতে বা ভাঙতে পারে না।

ব্রাউজারের WebSocket API

const ws = new WebSocket("wss://chat.example.com/support");
ws.binaryType = "arraybuffer";                    // binary এলে Blob-এর বদলে ArrayBuffer

ws.onopen = () => ws.send(JSON.stringify({ type: "hello", v: 1, token: getShortToken() }));
ws.onmessage = (e) => {
  const msg = JSON.parse(e.data);
  if (msg.type === "chat") addBubble(msg.from, msg.text);   // ভেতরে textContent — innerHTML নয়
};
ws.onclose = (e) => console.log("বন্ধ:", e.code, e.reason, e.wasClean);
ws.onerror = () => console.log("ভুল — কারণ ইচ্ছা করেই জানানো হয় না; onclose-এর code দেখুন");

function sendChat(text) {
  if (ws.readyState !== WebSocket.OPEN) return queueForLater(text);  // CONNECTING হলে send ভুল ছুড়ে
  ws.send(JSON.stringify({ type: "chat", v: 1, text }));
}

Node.js-এর দিক থেকে একটি খবর: Node 22 থেকে ব্রাউজারের মতো global WebSocket client আছে (Node 21-এ একটি flag-এর পেছনে ছিল), কিন্তু WebSocket সার্ভার Node-এ আজও built-in নয় — তার জন্য সাধারণত ws প্যাকেজ।

৬ · WebSocket সার্ভার, বার্তার প্রোটোকল, room আর presence

WebSocket আপনাকে শুধু একটি পাইপ দেয় — “বার্তা পাঠাও, বার্তা পাও”। কোন বার্তার অর্থ কী, কে কোন room-এ আছে, কে কাকে পাঠাতে পারে — এসব আপনার নকশা। প্রথমে ws প্যাকেজে একটি সার্ভারের কাঠামো (npm প্যাকেজ লাগে, তাই এখানে চালানো যায় না):

import { createServer } from "node:http";
import { WebSocketServer } from "ws";                 // npm install ws

const server = createServer(app);                     // পর্ব ৫০-এর Express app-ও হতে পারে
const wss = new WebSocketServer({ noServer: true, maxPayload: 16 * 1024 });  // বার্তা ≤ 16 KB
const ALLOWED_ORIGINS = new Set(["https://shop.example.com"]);

server.on("upgrade", async (req, socket, head) => {
  const user = await userFromCookie(req);              // সংযোগের আগেই পরিচয়
  if (!ALLOWED_ORIGINS.has(req.headers.origin) || !user) {
    socket.write("HTTP/1.1 403 Forbidden\r\n\r\n");
    return socket.destroy();
  }
  wss.handleUpgrade(req, socket, head, (ws) => wss.emit("connection", ws, user));
});

wss.on("connection", (ws, user) => {
  ws.on("message", (data, isBinary) => {
    if (isBinary) return ws.close(1003, "text only");
    hub.receive(user, data.toString());                // parse, যাচাই, তারপর broadcast
  });
  ws.on("close", () => hub.leaveAll(user, ws));
});
server.listen(8080);

noServer: true আর "upgrade" event দিয়ে 101 পাঠানোর আগেই Origin আর লগইন যাচাই করা যায়। maxPayload না দিলে ws-এর ডিফল্ট সীমা অনেক বড় (১০০ MiB).

বার্তার প্রোটোকল — প্রতিটি বার্তায় type আর version

HTTP-তে URL আর method বলে দেয় কোন কাজ। WebSocket-এ সব বার্তা একই পাইপে আসে, তাই প্রতিটি বার্তাকে নিজেই বলতে হয় সে কী। প্রচলিত নকশা হলো একটি JSON “খাম” (envelope) — এটিই আপনার message protocol:

{ "type": "chat",     "v": 1, "room": "order-42", "text": "আমার অর্ডার কোথায়?", "clientId": "c-17" }
{ "type": "chat",     "v": 1, "room": "order-42", "id": 981, "from": "রিনা", "text": "…", "clientId": "c-17" }
{ "type": "typing",   "v": 1, "room": "order-42", "from": "করিম" }
{ "type": "presence", "v": 1, "room": "order-42", "online": ["রিনা", "করিম"] }
{ "type": "error",    "v": 1, "code": "TOO_LONG", "reason": "বার্তা ২০০ অক্ষরের বেশি" }

Room, broadcast আর presence

সাপোর্ট চ্যাটে প্রতিটি অর্ডারের কথোপকথন একটি room: গ্রাহক আর সেই অর্ডারের এজেন্ট। একটি বার্তা room-এর সবার কাছে পাঠানো — এক থেকে অনেকে ছড়িয়ে দেওয়া — একে বলে fan-out বা broadcast. আর room-এ এখন কে কে আছেন, সেই তালিকা হলো presence. ধাপে ধাপে একটি বার্তার যাত্রা দেখুন:

এবার এই হাবের মূল যুক্তি নিজে চালিয়ে দেখুন। আসল নেটওয়ার্কের বদলে প্রতিটি “সংযোগ” এখানে একটি সাধারণ function, যা পাওয়া বার্তা ছাপে — কিন্তু room, presence, যাচাই আর fan-out-এর যুক্তি হুবহু একটি আসল সার্ভারের মতো:

class ChatHub {
  #rooms = new Map(); #seq = 0;                           // room → Map(user → send); message id
  #send(room, msg, onlyTo) {                              // onlyTo না থাকলে রুমের সবাইকে
    for (const [user, send] of this.#rooms.get(room) ?? [])
      if (!onlyTo || user === onlyTo) send(JSON.stringify(msg));
  }
  join(room, user, send) {
    this.#rooms.set(room, (this.#rooms.get(room) ?? new Map()).set(user, send));
    this.#send(room, { type: "presence", online: [...this.#rooms.get(room).keys()] });
  }
  receive(room, user, raw) {                              // client-এর বার্তা কখনো বিশ্বাস নয়
    let msg = null;
    try { msg = JSON.parse(raw); } catch {}
    if (msg?.type !== "chat" || typeof msg.text !== "string" || msg.text.length > 200)
      return this.#send(room, { type: "error", reason: "অবৈধ বার্তা" }, user);
    this.#send(room, { type: "chat", id: ++this.#seq, from: user, text: msg.text });
  }
}
const hub = new ChatHub();
const inbox = (name) => (data) => console.log(`${name} ← ${data}`);
hub.join("order-42", "রিনা", inbox("রিনা"));
hub.join("order-42", "করিম", inbox("করিম"));
hub.join("order-77", "সাকিব", inbox("সাকিব"));
hub.receive("order-42", "রিনা", '{"type":"chat","text":"আমার অর্ডার কোথায়?"}');
hub.receive("order-42", "রিনা", "<img src=x onerror=alert(1)>");

৭ · নির্ভরযোগ্যতা — heartbeat, reconnection আর backpressure

বাস্তবে মোবাইল ঘুমায়, নেটওয়ার্ক বদলায়, load balancer অলস সংযোগ কাটে, সার্ভার deploy হয়। SSE-র EventSource এসব নিজে সামলায়; WebSocket কিছুই সামলায় না। তিনটি জিনিস আপনাকে বানাতে হবে।

Heartbeat — আধমরা সংযোগ চেনা

সবচেয়ে বিপজ্জনক অবস্থা হলো “half-open” সংযোগ: ফোনের ব্যাটারি শেষ বা নেটওয়ার্ক হঠাৎ উধাও, কোনো close frame যায়নি। সার্ভারের চোখে সংযোগটি তখনো খোলা — সে বার্তা পাঠিয়েই যায়, presence-এ ব্যবহারকারীকে “অনলাইন” দেখায়, মেমরি ধরে রাখে। TCP নিজে থেকে এটি ধরতে অনেক সময় নেয়। সমাধান heartbeat: সার্ভার নির্দিষ্ট সময় পরপর ping পাঠায়; পরের ping-এর সময় পর্যন্ত pong না এলে সংযোগটি মৃত ধরে বন্ধ করে। ws প্যাকেজের প্রচলিত রূপ:

wss.on("connection", (ws) => {
  ws.isAlive = true;
  ws.on("pong", () => { ws.isAlive = true; });        // উত্তর এল — বেঁচে আছে
});
setInterval(() => {                                    // প্রতি ৩০ সেকেন্ডে
  for (const ws of wss.clients) {
    if (!ws.isAlive) { ws.terminate(); continue; }      // আগের ping-এর উত্তর নেই — মৃত
    ws.isAlive = false;
    ws.ping();
  }
}, 30_000);

নিয়মিত ping-এর ফলে proxy-র idle timeout-ও সংযোগ কাটে না। ব্রাউজারের দিক থেকে সার্ভার মৃত কি না জানতে একটি অ্যাপ-স্তরের {"type":"ping"} পাঠান, উত্তর না এলে close() করে আবার জুড়ুন।

Reconnection — exponential backoff আর jitter

সংযোগ কাটলে সাথে সাথে আবার চেষ্টা করা স্বাভাবিক মনে হয়। কিন্তু সার্ভার deploy-এর সময় এক লাখ সংযোগ একসাথে কাটে — সবাই একই মুহূর্তে ফিরলে নতুন সার্ভার জন্মেই ভেঙে পড়ে। এটিই পর্ব ৩৬-এর thundering herd, আর সমাধানও সেখানেই: exponential backoff আর jitter.

function connect(url, onMessage) {
  let attempt = 0, lastId = null, ws;
  function open() {
    ws = new WebSocket(url);
    ws.onopen = () => {
      attempt = 0;                                       // সফল — অপেক্ষা আবার শুরু থেকে
      ws.send(JSON.stringify({ type: "hello", v: 1, token: getShortToken(), lastId }));
    };
    ws.onmessage = (e) => {
      const msg = JSON.parse(e.data);
      if (msg.id) lastId = msg.id;                       // কোথা পর্যন্ত পেয়েছি
      onMessage(msg);
    };
    ws.onclose = (e) => {
      if (e.code === 1000 || e.code === 4001) return;    // ইচ্ছাকৃত বন্ধ বা লগইন ব্যর্থ — আর নয়
      const cap = Math.min(30_000, 500 * 2 ** attempt++);
      setTimeout(open, Math.random() * cap);             // full jitter: ০ থেকে cap-এর মধ্যে
    };
  }
  open();
  return { close: () => ws.close(1000) };
}

Backpressure — পাঠানোর গতি গ্রহণের গতির চেয়ে বেশি হলে

ws.send() সাথে সাথে ফেরে, কিন্তু তার মানে বার্তা পৌঁছেছে নয় — বার্তা একটি queue-তে বসেছে মাত্র। দুর্বল 3G-র ব্যবহারকারীর কাছে সেকেন্ডে ১০০টি আপডেট গেলে queue শুধু বাড়ে। এই সমস্যার নাম backpressure. ব্রাউজারে bufferedAmount জানায় কত byte এখনো পাঠানো বাকি; সার্ভারে ws-এর সংযোগেও একই নামের property আছে। নিয়ম: সীমা পেরোলে নতুন বার্তা জমাবেন না — পুরোনো আপডেট ফেলে শুধু সর্বশেষ অবস্থা পাঠান (স্কোরের ক্ষেত্রে পুরোনো স্কোরের কোনো মূল্য নেই), বা খুব পিছিয়ে পড়া client-এর সংযোগ বন্ধ করে দিন, যাতে সে নতুন করে সর্বশেষ অবস্থা নিয়ে শুরু করে।

function sendScore(ws, score) {
  if (ws.bufferedAmount > 64 * 1024) { pending.set(ws, score); return; }  // শুধু সর্বশেষটি রাখুন
  ws.send(JSON.stringify({ type: "score", v: 1, ...score }));
}

৮ · নিরাপত্তা — লগইন, Origin আর প্রতিটি বার্তা যাচাই

HTTP API-তে প্রতিটি request middleware-এর মধ্য দিয়ে যায়; WebSocket-এ একবার handshake-এর পরে হাজার বার্তা আসে middleware ছাড়াই।

Authentication — কোথায় token রাখবেন

• Cookie: একই site-এ ব্রাউজার handshake-এ নিজে থেকেই cookie পাঠায় — সবচেয়ে সরল, HttpOnly cookie JavaScript চুরি করতে পারে না। কিন্তু ঠিক এই কারণেই নিচের CSWSH-এর ঝুঁকি।
• স্বল্পমেয়াদি ticket URL-এ: আগে একটি সাধারণ HTTPS API থেকে ৩০ সেকেন্ডের এককালীন ticket নিন, তারপর wss://…?ticket=…. URL সার্ভার আর proxy-র log-এ লেখা থাকতে পারে, তাই দীর্ঘমেয়াদি JWT কখনো URL-এ নয়।
• প্রথম বার্তায় token: সংযোগ খোলার পরে প্রথম বার্তা {"type":"hello","token":…}; কয়েক সেকেন্ডের মধ্যে বৈধ hello না এলে সার্ভার 4001 দিয়ে বন্ধ করে। সংযোগের মাঝে token-এর মেয়াদ শেষ হলে কী হবে, তাও ঠিক করুন।

Origin যাচাই আর CSWSH

পর্ব ৪৩-এ দেখেছেন, same-origin policy আর CORS অন্য সাইটের JavaScript-কে আপনার API-র উত্তর পড়তে দেয় না। কিন্তু WebSocket-এ CORS প্রযোজ্য নয় — evil.example-এর পাতা new WebSocket("wss://chat.yoursite.com") খুলতে পারে, আর ব্রাউজার তাতে আপনার সাইটের cookie-ও জুড়ে দিতে পারে। সার্ভার শুধু cookie দেখে রাজি হলে দুষ্ট পাতা ব্যবহারকারীর নামে চ্যাট করতে পারে। এর নাম Cross-Site WebSocket Hijacking (CSWSH) — WebSocket-এর CSRF. প্রতিরক্ষা: handshake-এ Origin header নিজের অনুমোদিত তালিকার সাথে মেলান (অংশ ৬-এর কোডের মতো), আর cookie-তে SameSite রাখুন। মনে রাখবেন, Origin যাচাই ব্রাউজারের ব্যবহারকারীকে রক্ষা করে; ব্রাউজারের বাইরের একটি script যেকোনো Origin লিখে পাঠাতে পারে, তাই এটি লগইনের বিকল্প নয়।

প্রতিটি বার্তা একটি অবিশ্বস্ত request

৯ · Scaling, Socket.IO আর কখন কোনটি বাছবেন

একটি সার্ভারে সব সহজ: সব সংযোগ একই process-এর মেমরিতে, ChatHub সবাইকে চেনে। ব্যবহারকারী বাড়লে দুটি বা দশটি সার্ভার লাগে, সামনে একটি load balancer. তখন দুটি নতুন সমস্যা দেখা দেয়।

প্রথম — sticky session. Socket.IO-র মতো ব্যবস্থা শুরুতে long polling-এর কয়েকটি আলাদা request পাঠায়, যেগুলো একই সার্ভারে পৌঁছাতে হয় — load balancer-এর এই নিয়মের নাম sticky session. খাঁটি WebSocket একটিই TCP সংযোগ, তাই নিজে থেকেই এক সার্ভারে থাকে; শুধু load balancer-কে upgrade সমর্থন আর লম্বা idle timeout দিতে হয়।

দ্বিতীয় — ভিন্ন সার্ভারের মানুষ। রিনা সার্ভার ১-এ, করিম সার্ভার ২-এ। রিনার বার্তা সার্ভার ১-এর ChatHub পেল, কিন্তু করিমের সংযোগ তো সার্ভার ২-এর মেমরিতে! সমাধান একটি ভাগ করা বার্তা-পথ — পর্ব ৩৮-এ দেখা pub/sub নকশা, এবার সার্ভারগুলোর মধ্যে। সবচেয়ে প্রচলিত হাতিয়ার Redis-এর pub/sub:

receive("order-42", "রিনা", raw)
  → parse ✓  আকার ✓  সদস্য ✓
  → msg = { type: "chat", id: 981, from: "রিনা", … }

await pub.publish("room:order-42", JSON.stringify(msg));

room:order-42 → সার্ভার ১ (রিনার সংযোগ আছে)
room:order-42 → সার্ভার ২ (করিমের সংযোগ আছে)
সার্ভার ৩-এ এই room-এর কেউ নেই — সে subscribe করেনি

await sub.subscribe("room:order-42", (raw) =>
  localHub.deliver("order-42", raw));   // সার্ভার ১ → রিনা, সার্ভার ২ → করিম

Socket.IO — সুবিধা অনেক, কিন্তু এটি WebSocket নয়

Socket.IO Node জগতের খুব জনপ্রিয় লাইব্রেরি। এটি দেয় স্বয়ংক্রিয় reconnection, room (socket.join("order-42"), io.to("order-42").emit(…)), acknowledgement (পাঠানো বার্তার উত্তর-callback), heartbeat, আর WebSocket না চললে HTTP long polling-এ ফিরে যাওয়া; ডিফল্টভাবে long polling দিয়ে শুরু করে পরে WebSocket-এ ওঠে। একাধিক সার্ভারের জন্য আছে Redis adapter. কিন্তু মনে রাখুন: Socket.IO নিজস্ব প্রোটোকল (Engine.IO-র ওপর), যা WebSocket-কে পরিবহন হিসেবে ব্যবহার করে মাত্র। একটি সাধারণ new WebSocket() client Socket.IO সার্ভারে যুক্ত হতে পারে না, আর Socket.IO client একটি সাধারণ ws সার্ভারে পারে না — দুই পক্ষেই একই লাইব্রেরি লাগে। নিজে সার্ভার চালাতে না চাইলে আছে managed সেবা (Pusher, Ably, AWS API Gateway-এর WebSocket API, Firebase বা Supabase-এর realtime) — সংযোগ রাখার ঝামেলা তারা নেয়, বিনিময়ে মাসিক খরচ।

কখন কোনটি

সহজ নিয়ম: খবর শুধু সার্ভার থেকে এলে আগে SSE ভাবুন; দুই দিকে ঘন ঘন কথা লাগলে তবে WebSocket; খবর কদাচিৎ বদলালে polling.

১০ · AI-এর যুগে — AI-এর লেখা real-time কোড যাচাই করা

“একটি real-time চ্যাট বানিয়ে দাও” বললে AI মিনিটে একটি চলমান ডেমো দেয়। সমস্যা ধরা পড়ে প্রথম deploy, দুর্বল নেটওয়ার্ক আর দুষ্ট ব্যবহারকারীর সাথে। এই ভুলগুলো খুঁজুন:

AI-এর লেখা real-time কোড হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রযুক্তি বাছাইয়ের যুক্তি আছে — একমুখী খবরে SSE বা polling বিবেচনা করা হয়েছে
• Handshake-এ Origin আর লগইন যাচাই হয়, 101-এর আগেই
• প্রতিটি বার্তা try/catch-এ parse, schema-য় যাচাই, আকার ও হারের সীমা আছে
• প্রেরকের পরিচয় আর room সার্ভারের নিজের তথ্য থেকে, বার্তা থেকে নয়
• পাওয়া লেখা textContent দিয়ে দেখানো হয়; কোথাও innerHTML নেই
• Client-এ backoff + jitter-সহ reconnect, আর হারানো বার্তা ফেরত পাওয়ার উপায় (Last-Event-ID বা lastId)
• সার্ভারে heartbeat আছে, আর সংযোগ বন্ধ হলে timer, listener ও room-সদস্যপদ পরিষ্কার হয়
• Production-এ wss:// আর HTTPS; proxy-তে buffering আর timeout ঠিক করা