آپ سادہ HTTP کے بجائے WebSockets، SSE، یا long-polling کب استعمال کریں گے؟

Question

IT Interview Practice · Accepted Answer

سادہ HTTP **request/response** ہے: client پوچھتا ہے، server جواب دیتا ہے، بس۔ یہ **real-time** خصوصیات (چیٹ، براہِ راست dashboards، اطلاعات، اشتراکی ترمیم) کے لیے ناموزوں ہے، جہاں *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 کا تقریباً اندازہ لگاتا ہے لیکن فی پیغام ایک request کا چکر ضائع کرتا ہے اور latency کا اضافہ کرتا ہے۔

**SSE (Server-Sent Events)** ایک ہلکی، معیاری **یک طرفہ** stream (server → client) ہے جو ایک ہی دیرپا HTTP response پر ہوتی ہے۔ یہ اُس وقت مثالی ہے جب صرف server push کرتا ہو — براہِ راست فیڈز، اطلاعات، پیش رفت، سٹریمنگ LLM tokens۔ یہ سادہ ہے، عام HTTP/2 پر چلتی ہے (کوئی خاص infrastructure نہیں)، اور خود بخود دوبارہ جڑ جاتی ہے۔ حد: یہ یک طرفہ اور صرف متن ہے۔

**WebSockets** ایک ہی HTTP کنکشن کو ایک دیرپا، **full-duplex** TCP چینل میں اپ گریڈ کرتے ہیں جہاں دونوں فریق کم از کم فی-پیغام overhead کے ساتھ کسی بھی وقت بھیجتے ہیں۔ اسے حقیقتاً دو طرفہ، کم-latency تعامل کے لیے استعمال کریں: چیٹ، ملٹی پلیئر گیمز، اشتراکی ایڈیٹرز، ٹریڈنگ۔ اس کی قیمت آپریشنل ہے — یہ ایک stateful کنکشن ہے جس کے لیے proxies، load balancers، اور autoscalers کو کنفیگر کرنا پڑتا ہے، اور آپ کو reconnection، heartbeats، اور backpressure خود بنانا پڑتا ہے۔

**اصولِ عام:** پہلے سے طے شدہ طور پر سادہ HTTP پر رہیں؛ server→client سٹریمنگ کے لیے **SSE** استعمال کریں؛ **WebSockets** کی طرف صرف تب جائیں جب آپ کو واقعی دو طرفہ real-time کی ضرورت ہو؛ **long-polling** کو عالمگیر fallback کے طور پر رکھیں۔

## یہ کیوں اہم ہے

ایک real-time transport کا انتخاب ایک کلاسک سینئر ڈیزائن فیصلہ ہے جہاں سادہ جواب ("بس ہر چیز کے لیے WebSockets استعمال کرو") عموماً غلط ہوتا ہے۔ انٹرویو لینے والے دیکھنا چاہتے ہیں کہ آپ ٹول کو *مواصلاتی نمونے* سے میل کراتے ہیں — یک طرفہ بمقابلہ دو طرفہ، latency کی ضروریات، پیغام کا حجم — اور یہ کہ آپ stateful، دیرپا کنکشنز کی **آپریشنل قیمت** کو تولتے ہیں: sticky sessions، scaling، proxy timeouts، اور reconnection منطق۔ یہ پہچاننا کہ SSE اکثر "server اپ ڈیٹس push کرتا ہے" کو WebSockets سے زیادہ سادگی سے پورا کر دیتا ہے، اور یہ کہ long-polling ایک مضبوط fallback رہتا ہے، حقیقی production تجربے کی نشاندہی کرتا ہے، بجائے اس کے کہ سب سے چمکدار اختیار کی طرف لپکا جائے۔

یہ کیوں اہم ہے

متعلقہ سوالات