الاتصالات عبر ويب سوكيت مقابل إرسال بيانات متسلسلة (SSE) مقابل التصويت الطويل — التفاعل في الوقت الحقيقي دون التوتر

يُلجأ معظم المطورين إلى WebSockets بشكل افتراضي. لكن ذلك عادةً ما يكون خاطئًا.

ليس لأن WebSockets سيئة — فهي ممتازة في ما تفعله. لكنها تُحمل تكلفة بنية تحتية حقيقية: جلسات متماسكة على موزعات الأحمال، وبيئة تحقق تلقائيًا للبُنية، وطرق تحقق التحقق من الهوية، وتكوين مُحَوّل يُعمل بشكل جيد حتى يُفتح تطبيقك في مكتب شركة. بالنسبة لمعظم متطلبات "الاتصال الحقيقي"، فإن هذه التكلفة لا تُبرر.

النسخة المختصرة: إذا تدفق البيانات فقط من الخادم إلى العميل، فاستخدم "مُرسلات من الخادم إلى العميل" (SSE). إذا كان العميل يحتاج إلى إرسال بيانات عكسية بسرعة منخفضة، فاستخدم WebSockets. إذا كان معدل التحديث يُقاس بالثواني وترغب في التثبيت البسيط، فإن طريقة التصويت الطويل (Long Polling) لا تزال تعمل — ولا يُعتبر ذلك خطاً.

المقارنة

التصويت الطويل

التصويت الطويل هو تطبيق تصفح HTTP القياسي حيث يُحتفظ بالطلب مفتوحًا حتى يُمكن إرجاع شيء ما — أو يُنفَّذ وقت انتظار. يُرسل العميل طلبًا، ينتظر الخادم، ويُرجع الرد عند توفر البيانات، ثم يُرسل العميل طلبًا فوريًا للطلب التالي. إنه حلقة مُختلطة مع طلب شبكة.

هذا مقبول حقًا لعدد من الحالات الاستخدام:

• أيقونات الإشعارات — عددها غير المُقرَّر يُحدّث كل 30 ثانية لا يحتاج إلى اتصال مستمر.
• لوحات تحكم للمسؤولين مع توازن في الوضوح — مُتّسِعات تُحدّث كل 15 إلى 60 ثانية تعمل بشكل جيد مع التصويت.
• تطبيقات موبايل على اتصال غير موثوق — يتم قتل الاتصالات المستمرة من قبل إدارة الشبكة المُعَدّة؛ يُعيد التصويت بسلاسة مع كل طلب.
• خلف مُحَوّلات مكتبية — تُ-buffer أو تُغلق مُتّصلات غير معيارية. التصويت باستخدام HTTP يعمل في كل الأماكن، دون استثناءات.

القيود المتعلقة بالتوسع هي حقيقية. كل طلب مُحتفظ به يُشغل مساحة اتصال. على الخوادم المُقَسَّمة، يصبح هذا مكلفًا؛ على الخوادم التي تستخدم حلقة (مثل Node.js، Tornado، Go مع مُتَّسِعات)، فهو مُمكن لكن ليس مجانيًا. عند تواجد عشرات الآلاف من المستخدمين المتواجدين، تبدأ الأرقام المتعلقة بالموارد على الخادم أن تُصبح مهمة.

مُرسلات من الخادم إلى العميل (SSE)

SSE هي الخيار الذي يُستبعد غالبًا من قبل المطورين أثناء الانتقال إلى WebSockets. هذا خطأ في أي حالة استخدام تتدفق فيها البيانات من الخادم إلى العميل.

يُستخدم على HTTP القياسي. يُحدد الخادم Content-Type: text/event-stream ويعمل على كتابة رسائل مفصولة بخط جديد في جسم الاستجابة بشكل مستمر. تُعالج وحدة المتصفح المُدمجة EventSource لإعادة الاتصال تلقائيًا — بما في ذلك Last-Event-ID الرأسية بحيث يمكن للخادم استئناف التدفق بعد انقطاع الاتصال. تُحصل على أنواع أحداث مُسمّاة، فترات إعادة المحاولة المُحددة، ولا حاجة إلى مكتبة.

const source = new EventSource('/api/events');

source.addEventListener('priceUpdate', (e) => {
  const { price, symbol } = JSON.parse(e.data);
  updateTicker(symbol, price);
});

source.onerror = () => {
  // EventSource reconnects automatically — nothing to do here
};

ما يُحققه SSE:

• HTTP القياسي — يعمل عبر موزعات الأحمال، مُحَوّلات عكسية، وخدمات CDN بدون أي إعداد. لا حاجة لجلسات متماسكة.
• إعادة الاتصال تلقائيًا — مدمجة في المواصفة. قم بتعيين retry: في التدفق لضبط الفاصل؛ يُدير العميل باقي الإجراءات.
• تعدد الاتصالات في HTTP/2 — يُزيل الحد القديم لـ 6 اتصالات لكل نطاق في HTTP/1.1. إذا كنت على HTTP/2 (يجب أن تكون)، فإن هذا ليس مُهمًا.
• تنفيذ بسيط على الخادم — احتفظ باتصال مفتوح وقم بكتابة على هذا الاتصال. لا حاجة لاستجابة بروتوكول، لا حاجة لتحليل الإطار، ولا حاجة لمنطق التحقق من الاتصال.

القيود الوحيدة: SSE هو اتجاه واحد. لا يمكن للعملاء إرسال بيانات عبر اتصال SSE. في الممارسة، هذا لا يشكل مشكلة — استخدم طلبات POST عادية لأي شيء يحتاجه العميل، مع اتصال SSE للحصول على أحداث الخادم. يمكن أن يُستخدمان معًا دون مشاكل.

الحد المحدد لاتصالات HTTP/1.1 يُعرف. يُحدّد المتصفح بحد أقصى 6 اتصالات متوازية لكل نطاق عبر جميع أوراق المتصفح. ثلاثة أوراق متصفح كل منها يستخدم اتصالين لـ SSE = حد مُخالف. يُزيل HTTP/2 هذا عبر التعدد. إذا لم تتمكن من ضمان توصيل HTTP/2 (أكوام قديمة من مُحَوّلات CDN، بعض المُحَوّلات المكتبية)، فاحتفظ بهذا في الاعتبار.

WebSockets

WebSockets هي الأداة المناسبة عندما تحتاج إلى تبادل ثنائي الاتجاه بسرعة منخفضة. الحالات التي تبرر التعقيد:

• الدردشة — يجب أن تصل رسائل كل مستخدم إلى الآخرين في وقت قريب جدًا. WebSockets هي المعيار هنا لسبب جيد.
• الألعاب المتعددة المُشاركين — يتم توازن حالة اللعبة بين العملاء باستمرار، غالبًا بـ 20 إلى 60 تحديثًا في الثانية. لا توجد طريقة أخرى تقترب من كفاءة كل إطار.
• التحرير المعاكس — التحرير الحقيقي المبني على CRDT أو OT (مثل Notion، Figma، Google Docs) يتطلب أن تُنقل كل مفتاح بسرعة منخفضة.
• مُعدات التداول — تدفقات أسعار أقل من 100 مللي ثانية مع إرسال الأوامر على نفس الاتصال. تم بناء WebSockets لهذا.

التكلفة البنية التي تتجنبها SSE وطريقة التصويت:

• جلسات متماسكة — اتصالات WebSockets هي متماسكة ومتصلة بعملية خادم واحدة. يحتاج موزع الأحمال إلى توازن الجلسة (مُقاس بعنوان IP أو مُبنى على ملفات) لاتجاه إعادة الاتصال بشكل صحيح. بدون ذلك، قد يُوجه العميل المُعيد الاتصال إلى خادم لا يعرف عن جلسته.
• تكوين المُحَوّلات والخدمات المُتاحة — تدعم Nginx، HAProxy، وCloudflare WebSockets لكنها تتطلب إعدادًا صريحًا (Upgrade و Connection أو proxy_http_version 1.1 في Nginx). تُحظر بعض الحواجز المكتبية 101 Switching Protocols. ستجد هذا في رسائل الدعم من المستخدمين في مكاتب معينة.
• التعقيد في التحقق من الهوية — لا يمكن لـ WebSockets إرسال رؤوس مخصصة بعد التبادل الأولي. غالبًا ما يتم تمرير الرمز في سلسلة الاستعلام (مُزعج، شائع) أو في الرسالة الأولى بعد الاتصال (أفضل، لكنه يتطلب منطق تحقق على الخادم).
• التحقق من الاتصالات — لا يتطلب المواصفة تحققًا للاتصالات. بدون منطق تحقق مخصص، لن تكتشف اتصالات ميتة حتى فشل الرسالة التالية. إما أن تُنفذ تحققًا للاتصالات أو أن تقبل اتصالات ميتة تراكم بشكل سلبي.

لا تُعتبر هذه العوائق مُحجبة — فهي قابلة للحل. هذه التعقيدات لا توجد في SSE أو التصويت باستخدام HTTP. إذا كنت تختار WebSockets لخدمة إشعار أو لوحة تحكم حية، فأنت تدفع لهذه التكلفة دون سبب.

كيفية الاختيار

أعد تمرير هذه النقاط بالترتيب:

1. هل يحتاج العميل إلى إرسال بيانات إلى الخادم بسرعة عالية، أم أن التأخير أقل من 200 مللي ثانية مهم؟ لا → تجاهل WebSockets.
2. هل تتدفق البيانات فقط من الخادم إلى العميل؟ نعم → فإن SSE هو الخيار المناسب بالتأكيد.
3. هل تستخدم HTTP/2؟ إذا كانت الإجابة نعم، فإن SSE لا تمتلك قيودًا ذات معنى في معظم الحالات. إذا لم تكن كذلك، فاعمل على توازن الحد المحدد لـ 6 اتصالات.
4. هل تُستخدم خدمة مُتَّسِعة أو وراء بنية تحتية لا تدعم اتصالات مُستمرة؟ SSE تعمل على معظم منصات الخدمة المُتَّسِعة (Vercel، Cloudflare Workers عبر واجهة التدفق)؛ بينما يتطلب WebSockets على الخدمة المُتَّسِعة إضافات.
5. هل تُقاس مدة التحديث 15 ثانية أو أكثر؟ التصويت الطويل. احتفظ بالبساطة.

إذا تمرّرت بهذه الأسئلة وتمّ التأكيد على أنك تستخدم WebSockets — جيد. الآن تستخدمها لأسباب مناسبة بدلًا من الافتراض.

فحص محتوى الأحداث

SSE data: مجالات الرسائل والرسائل عبر WebSockets تُحمل غالبًا JSON. عند تدقيق سلوك تدفق غير سليم، فإن نسخة الرسالة الخام في IO Tools’ JSON Formatter هي الطريقة السريعة لرؤية الهيكل بسرعة — خاصةً في حالات الأحداث المُستوية حيث يُفقد تحليل مفقود أو فاصل زائد يُؤثر على التحليل بشكل سلبي.

قد يعجبك أيضاً

جديد

تحقق من معايير OpenAPI: استشر أخطاء في ملف Swagger قبل أن تُعطل العملاء

اقرأ المزيد »

تحديث في أغسطس 9، 2026

جديد

سجلات وصول الخادم — قصة كل طلب استلمه تطبيقك

اقرأ المزيد »

تحديث في أغسطس 9، 2026

جديد

كودات حالة HTTP التي تُلقي بسَلَمك — 301 مقابل 302، 401 مقابل 403، والمنطقة الخطرة من الكودات 5xx

اقرأ المزيد »

نُشرت في 8 يونيو 2026

جديد

قيود التقييم: كيفية التوقف عن تلقي الرسائل 429 من كل واجهة برمجة تطبيقات تستخدمها

اقرأ المزيد »

نُشرت في 8 يونيو 2026