সাধারণ HTTP-এর পরিবর্তে আপনি কখন WebSockets, SSE, বা long-polling ব্যবহার করবেন?

Question

IT Interview Practice · Accepted Answer

সাধারণ HTTP হলো **request/response**: client জিজ্ঞেস করে, server উত্তর দেয়, শেষ। এটি **real-time** ফিচারের (chat, live dashboard, notification, collaborative editing) জন্য দুর্বলভাবে মানানসই, যেখানে *server*-এর যখনই নতুন কিছু থাকে তখনই ডেটা push করা দরকার। বিকল্পগুলো হলো HTTP-এর client-সূচিত মডেলকে ঘুরিয়ে যাওয়ার উপায়, জটিলতার একটি বর্ণালী বরাবর:

```text
Long-polling   client ──req──▶ server ...holds... ──resp──▶ then immediately re-asks
               (near-real-time over plain HTTP; one message per held request)

SSE            client ──req──▶ server ═══stream of events═══▶ (one-way, server→client)
               (HTTP-based, text, auto-reconnect; NO client→server on same channel)

WebSocket      client ──handshake──▶ server ══full-duplex, both directions══▶
               (persistent TCP; low overhead; binary or text; you build the rest)
```

**Long-polling** হলো সেই fallback যা সর্বত্র কাজ করে: client একটি সাধারণ request করে যা server ডেটা না-আসা পর্যন্ত খোলা রাখে, তারপর client অবিলম্বে আবার request করে। এটি সাধারণ HTTP-এর উপর push-এর কাছাকাছি যায় কিন্তু প্রতি message-এ একটি request চক্র নষ্ট করে এবং latency যোগ করে।

**SSE (Server-Sent Events)** হলো একটি হালকা, প্রমিত **একমুখী** stream (server → client) একটি একক দীর্ঘ-জীবী HTTP response-এর উপর। এটি আদর্শ যখন কেবল server push করে — live feed, notification, progress, streaming LLM token। এটি সরল, সাধারণ HTTP/2-এর উপর চলে (কোনো বিশেষ infrastructure দরকার নেই), এবং স্বয়ংক্রিয়ভাবে পুনঃসংযোগ করে। সীমা: এটি একমুখী এবং কেবল text।

**WebSockets** একটি একক HTTP কানেকশনকে একটি স্থায়ী, **full-duplex** TCP চ্যানেলে উন্নীত করে যেখানে উভয় পক্ষ ন্যূনতম per-message overhead-এ যেকোনো সময় পাঠায়। প্রকৃতপক্ষে দ্বিমুখী, low-latency ইন্টারঅ্যাকশনের জন্য এটি ব্যবহার করুন: chat, multiplayer game, collaborative editor, trading। খরচ পরিচালনাগত — এটি একটি stateful কানেকশন যার জন্য proxy, load balancer, ও autoscaler কনফিগার করতে হয়, এবং আপনাকে নিজে reconnection, heartbeat, ও backpressure তৈরি করতে হয়।

**অঙ্গুষ্ঠের নিয়ম:** ডিফল্ট হিসেবে সাধারণ HTTP ব্যবহার করুন; server→client streaming-এর জন্য **SSE** ব্যবহার করুন; কেবল যখন আপনার সত্যিই দ্বিমুখী real-time দরকার তখনই **WebSockets**-এর দিকে যান; সর্বজনীন fallback হিসেবে **long-polling** রাখুন।

## এটি কেন গুরুত্বপূর্ণ

একটি real-time transport বাছাই একটি ধ্রুপদী senior design সিদ্ধান্ত যেখানে সরল উত্তরটি ("সবকিছুর জন্য শুধু WebSockets ব্যবহার করো") সাধারণত ভুল। ইন্টারভিউয়াররা দেখতে চান আপনি টুলটিকে *যোগাযোগের প্যাটার্নের* সাথে মেলান কিনা — একমুখী vs দ্বিমুখী, latency চাহিদা, message ভলিউম — এবং আপনি stateful, দীর্ঘ-জীবী কানেকশনের **পরিচালনাগত খরচ** ওজন করেন কিনা: sticky session, scaling, proxy timeout, এবং reconnection logic। এটি চেনা যে SSE প্রায়ই "server আপডেট push করে"-কে WebSockets-এর চেয়ে সহজে ঢেকে দেয়, এবং long-polling একটি মজবুত fallback থেকে যায়, তা সবচেয়ে চকচকে বিকল্পের দিকে ঝাঁপ দেওয়ার বদলে প্রকৃত production অভিজ্ঞতার ইঙ্গিত দেয়।

এটি কেন গুরুত্বপূর্ণ

সম্পর্কিত প্রশ্ন