متى تستخدم WebSockets أو SSE أو long-polling بدلاً من HTTP العادي؟

Question

IT Interview Practice · Accepted Answer

الـ HTTP العادي هو **طلب/استجابة (request/response)**: يسأل العميل، يجيب الخادم، انتهى. وهذا لا يناسب ميزات **الزمن الحقيقي (real-time)** (الدردشة، لوحات المعلومات الحيّة، الإشعارات، التحرير التشاركي) حيث يحتاج *الخادم* إلى دفع بيانات كلما توفّر جديد لديه. الخيارات طرقٌ للالتفاف حول نموذج HTTP الذي يبدأه العميل، على طيف من التعقيد:

```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** هو الخيار الاحتياطي الذي يعمل في كل مكان: يرسل العميل طلباً عادياً يبقيه الخادم مفتوحاً حتى تتوفّر بيانات، ثم يعيد العميل الطلب فوراً. يقارب هذا الدفع فوق HTTP العادي لكنه يهدر دورة طلب لكل رسالة ويضيف زمن استجابة.

الـ **SSE (أحداث مُرسَلة من الخادم، Server-Sent Events)** تدفّق **أحادي الاتجاه** خفيف ومُعياري (server → client) عبر استجابة HTTP واحدة طويلة العمر. وهو مثالي حين يدفع الخادم فقط — الخلاصات الحيّة، الإشعارات، التقدّم، بثّ رموز نماذج اللغة الكبيرة (LLM). وهو بسيط، ويعمل فوق HTTP/2 العادي (دون بنية تحتية خاصة)، ويعيد الاتصال تلقائياً. الحدّ: أنه أحادي الاتجاه ونصّي فقط.

يرقّي **WebSockets** اتصال HTTP واحداً إلى قناة TCP دائمة **ثنائية الاتجاه الكاملة (full-duplex)** حيث يرسل الطرفان في أيّ وقت بعبء ضئيل لكل رسالة. استخدمه للتفاعل ثنائي الاتجاه حقاً منخفض زمن الاستجابة: الدردشة، الألعاب متعدّدة اللاعبين، المحرّرات التشاركية، التداول. والثمن تشغيلي — فهو اتصال ذو حالة يجب إعداد البروكسيات وموازنات الحِمل والموسّعات التلقائية له، وعليك أن تبني إعادة الاتصال ونبضات القلب (heartbeats) والضغط العكسي (backpressure) بنفسك.

**قاعدة إبهام:** الافتراضي HTTP العادي؛ استخدم **SSE** للبثّ من الخادم إلى العميل؛ والجأ إلى **WebSockets** فقط حين تحتاج فعلاً إلى زمن حقيقي ثنائي الاتجاه؛ وأبقِ **long-polling** خياراً احتياطياً شاملاً.

## لماذا يهم

اختيار نقل زمن حقيقي قرار تصميم كلاسيكي بمستوى كبير (senior) حيث تكون الإجابة الساذجة ("استخدم WebSockets لكل شيء") خاطئة عادةً. يريد المُحاوِرون أن يروا أنك تطابق الأداة مع *نمط الاتصال* — أحادي مقابل ثنائي الاتجاه، احتياجات زمن الاستجابة، حجم الرسائل — وأنك توازن **التكلفة التشغيلية** للاتصالات ذات الحالة طويلة العمر: الجلسات اللاصقة، والتوسيع، ومُهَل البروكسي، ومنطق إعادة الاتصال. إن إدراك أن SSE كثيراً ما يغطّي "دفع الخادم للتحديثات" أبسط من WebSockets، وأن long-polling يبقى خياراً احتياطياً متيناً، يدلّ على خبرة إنتاج حقيقية بدلاً من التهافت على الخيار الأكثر بريقاً.

لماذا يهم

أسئلة ذات صلة