WebSockets, SSE ও Long Polling
- ●সাধারণ HTTP-তে server নিজে থেকে data পাঠাতে পারে না; real-time-এর জন্য বিশেষ কৌশল লাগে।
- ●Long polling, SSE, আর WebSocket — তিনটি ভিন্ন উপায়, যাদের প্রতিটির আলাদা trade-off আছে।
- ●WebSocket full-duplex (দুই দিকেই), SSE শুধু server→client, আর polling সবচেয়ে সরল কিন্তু অপচয়মূলক।
সমস্যাটা কী?
সাধারণ HTTP কাজ করে request-response মডেলে: client চায়, server দেয়। কিন্তু server নিজে থেকে client-কে কিছু পাঠাতে পারে না। এখন ভাবো একটা chat app — অন্যজন message পাঠালে তোমার স্ক্রিনে সঙ্গে সঙ্গে দেখাতে হবে। কিন্তু server তো জানে না তুমি কখন message পাবে, আর সে নিজে থেকে তোমাকে ডাকতে পারে না।
এই "server থেকে client-এ তাৎক্ষণিক push" সমস্যার সমাধানেই এসেছে কয়েকটা কৌশল — short polling, long polling, Server-Sent Events, আর WebSocket। লাইভ স্কোর, নোটিফিকেশন, stock price, collaborative editing — সবখানে এদের দরকার।
মূল ধারণা
Real-time যোগাযোগ মানে server-এ কিছু ঘটার সাথে সাথে client সেটা জেনে যাওয়া, client-কে বারবার জিজ্ঞেস করতে না হয়ে।
মূল পার্থক্যটা যোগাযোগের দিক ও connection-এর ধরন নিয়ে:
- Half-duplex — একসময় একদিকে data যায় (walkie-talkie-র মতো)।
- Full-Duplex — দুই দিকেই একসাথে data যেতে পারে (ফোন কলের মতো, দুজন একসাথে কথা বলতে পারে)।
WebSocket full-duplex দেয়, SSE শুধু একমুখী (server→client), আর polling তো আসলে বারবার HTTP request।
কীভাবে কাজ করে
Short Polling
Client প্রতি কয়েক সেকেন্ডে জিজ্ঞেস করে "নতুন কিছু আছে?"। বেশিরভাগ সময় উত্তর "না"। সরল, কিন্তু প্রচুর অপ্রয়োজনীয় request — server-এও চাপ, latency-ও বেশি (দুই poll-এর মাঝে নতুন data বসে থাকে)।
Long Polling
Long Polling হলো এমন কৌশল যেখানে client request পাঠায় আর server সঙ্গে সঙ্গে উত্তর না দিয়ে data আসা পর্যন্ত connection খোলা রাখে; data এলে উত্তর দেয়, তারপর client আবার request পাঠায়।
এতে খালি উত্তরের অপচয় কমে। কিন্তু প্রতিবার data পাঠানোর পর নতুন connection বানাতে হয়, আর server-এ অনেক খোলা request ধরে রাখতে হয়। সত্যিকারের push নয়, push-এর কাছাকাছি একটা কৌশল।
Server-Sent Events (SSE)
Server-Sent Events হলো একটি HTTP-ভিত্তিক প্রযুক্তি যেখানে একটিমাত্র দীর্ঘস্থায়ী connection দিয়ে server ক্রমাগত client-এ event পাঠাতে থাকে, একমুখীভাবে।
Client EventSource দিয়ে একটা connection খোলে, server সেই খোলা connection দিয়ে যখন খুশি data stream করে। সুবিধা: সাধারণ HTTP-র উপর চলে, browser নিজে auto-reconnect করে, সরল। সীমা: শুধু server→client; client-কে কিছু পাঠাতে আলাদা HTTP request লাগবে। আর text-only।
WebSocket
WebSocket হলো একটি protocol যা একটি persistent, full-duplex connection তৈরি করে, যেখানে client ও server উভয়েই যেকোনো সময় একে অপরকে message পাঠাতে পারে।
WebSocket শুরু হয় একটা সাধারণ HTTP request দিয়ে যাতে থাকে Upgrade: websocket header — একে বলে handshake। Server রাজি হলে connection-টা HTTP থেকে WebSocket protocol-এ "upgrade" হয়, তারপর সেই খোলা TCP connection-এ দুই দিকেই হালকা frame-এ message চলে, প্রতিবার header-এর ভার ছাড়াই।
ভাবো তুমি বন্ধুর খবর জানতে চাও। Short polling — প্রতি ৫ মিনিটে ফোন দিয়ে জিজ্ঞেস করছ "নতুন কিছু?", বেশিরভাগ সময়ই "না"। Long polling — ফোন করে লাইনে থেকে গেলে, খবর হলে বন্ধু বলবে, তারপর ফোন কেটে আবার ফোন দাও। SSE — বন্ধু একটা রেডিও চ্যানেলে শুধু ঘোষণা দিয়ে যাচ্ছে, তুমি শুনছ কিন্তু কথা বলতে পারছ না। WebSocket — দুজনের মধ্যে একটা খোলা ফোন লাইন, যে কেউ যেকোনো সময় কথা বলতে পারো — এটাই full-duplex।
কৌশল — তুলনামূলক টেবিল
| বৈশিষ্ট্য | Short Polling | Long Polling | SSE | WebSocket |
|---|---|---|---|---|
| দিক | দুই দিক (request-response) | দুই দিক | একমুখী (server→client) | full-duplex |
| Connection | বারবার নতুন | দীর্ঘ, তারপর নতুন | একটি দীর্ঘস্থায়ী | একটি দীর্ঘস্থায়ী |
| Protocol | HTTP | HTTP | HTTP | WebSocket (ws/wss) |
| Latency | বেশি | মাঝারি | কম | সবচেয়ে কম |
| Auto-reconnect | প্রযোজ্য নয় | manual | built-in | manual |
| জটিলতা | কম | কম | কম | বেশি |
| ব্যবহার | কালেভদ্রে আপডেট | মাঝারি real-time | live feed, notification | chat, game, collab |
কখন ব্যবহার করবে / করবে না
- Short polling — খুব কম ও অনিয়মিত আপডেট, সরলতা চাইলে।
- Long polling — WebSocket সমর্থন নেই এমন পরিবেশে fallback হিসেবে।
- SSE — একমুখী live stream: news feed, notification, dashboard, log streaming, AI token streaming।
- WebSocket — সত্যিকারের দ্বিমুখী real-time: chat, multiplayer game, collaborative document, live trading।
WebSocket সবসময় "সেরা" নয়। এটা persistent connection ধরে রাখে, তাই হাজারো একসাথে যুক্ত ব্যবহারকারীর জন্য server-এ অনেক memory ও connection-management খরচ। শুধু server→client একমুখী data লাগলে SSE অনেক সহজ ও সস্তা — অহেতুক WebSocket-এ গিয়ে জটিলতা বাড়িও না। আর load balancer/proxy-তে WebSocket-এর জন্য আলাদা কনফিগারেশন লাগে।
বাস্তব উদাহরণ
ধরো তুমি একটা food-delivery app বানাচ্ছ:
- Order tracking map — rider-এর অবস্থান শুধু server থেকে client-এ যাচ্ছে, একমুখী। এখানে SSE যথেষ্ট ও সরল।
- Customer-rider chat — দুজনই message পাঠাবে, তাৎক্ষণিক। এখানে WebSocket (full-duplex) দরকার।
- পুরোনো ব্রাউজার যেখানে WebSocket চলে না, সেখানে long polling-এ fallback রাখা হলো।
- ব্যাকগ্রাউন্ড promo banner যা ঘণ্টায় একবার বদলায় — এর জন্য সাধারণ polling-ই যথেষ্ট, real-time দরকার নেই।
Interview-এ "real-time কীভাবে করবে?" জিজ্ঞেস করলে সরাসরি WebSocket বলে ফেলো না। আগে জিজ্ঞেস করো: data কি একমুখী না দ্বিমুখী? একমুখী হলে SSE, দ্বিমুখী/low-latency হলে WebSocket — এই trade-off দেখাতে পারলে তুমি engineering judgment দেখাচ্ছ, শুধু buzzword নয়।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. WebSocket-এর প্রধান বৈশিষ্ট্য কোনটি?
2. শুধু server থেকে client-এ একমুখী stream-এর জন্য সবচেয়ে উপযুক্ত কোনটি?
3. Short polling-এর প্রধান সমস্যা কী?