WebSockets والتطبيقات الفورية

مقدمة إلى الويب في الوقت الفعلي

18 دقيقة الدرس 1 من 35

ما هو التواصل في الوقت الفعلي؟

يشير التواصل في الوقت الفعلي على الويب إلى التبادل الفوري للبيانات بين العميل والخادم مع الحد الأدنى من التأخير. على عكس تطبيقات الويب التقليدية حيث يجب على المستخدمين تحديث الصفحة لرؤية التحديثات، تدفع التطبيقات في الوقت الفعلي التحديثات فورًا عند حدوثها.

أمثلة على الوقت الفعلي: تطبيقات الدردشة، نتائج الرياضة المباشرة، أسعار الأسهم، أدوات التحرير التعاوني (مستندات جوجل)، الألعاب عبر الإنترنت، وأنظمة الإشعارات تعتمد جميعها على التواصل في الوقت الفعلي.

قيود بروتوكول HTTP

يتبع بروتوكول HTTP التقليدي نموذج طلب-استجابة له قيود متأصلة للتواصل في الوقت الفعلي:

مبادرة العميل: يجب أن يبدأ العميل دائمًا الاتصال؛ لا يمكن للخادم دفع البيانات إلى العميل بدون طلب
عديم الحالة: كل طلب مستقل، يتطلب إرسال الرؤوس والمصادقة بشكل متكرر
حمل عالي: تضيف رؤوس HTTP حملاً كبيرًا لكل دورة طلب/استجابة
دورة حياة الاتصال: عادة ما تكون الاتصالات قصيرة الأمد وتُغلق بعد كل استجابة

// طلب HTTP تقليدي
GET /api/messages HTTP/1.1
Host: example.com
Authorization: Bearer token123
Accept: application/json

// استجابة الخادم
HTTP/1.1 200 OK
Content-Type: application/json
{
  "messages": [...]
}
// يُغلق الاتصال بعد الاستجابة

الاستقصاء (Polling): المحاولة الأولى للوقت الفعلي

الاستقصاء هو تقنية يرسل فيها العميل بشكل متكرر طلبات HTTP على فترات منتظمة للتحقق من التحديثات:

// تطبيق استقصاء بسيط
function pollForUpdates() {
  setInterval(async () => {
    const response = await fetch('/api/messages');
    const data = await response.json();
    updateUI(data);
  }, 3000); // استقصاء كل 3 ثوانٍ
}

عيوب الاستقصاء:

مُهدر: معظم الطلبات لا تُرجع بيانات جديدة
تأخير عالي: يمكن تأخير التحديثات بواسطة فترة الاستقصاء
كثيف الموارد: يخلق حملاً غير ضروري على الخادم وحركة الشبكة
استنزاف البطارية: الطلبات المستمرة تستنزف بطاريات الأجهزة المحمولة

الاستقصاء الطويل (Long-Polling): تحسين

يحسن الاستقصاء الطويل من الاستقصاء العادي من خلال الحفاظ على اتصال HTTP مفتوحًا حتى تتوفر بيانات جديدة:

// تطبيق الاستقصاء الطويل
async function longPoll() {
  try {
    const response = await fetch('/api/messages?timeout=30');
    const data = await response.json();

    updateUI(data);
    longPoll(); // إعادة الاتصال فورًا
  } catch (error) {
    setTimeout(longPoll, 5000); // إعادة المحاولة بعد تأخير
  }
}

كيف يعمل: يحتفظ الخادم بالطلب مفتوحًا حتى تصل بيانات جديدة أو تحدث مهلة زمنية. بمجرد أن يتلقى العميل استجابة، يرسل طلبًا جديدًا على الفور.

يقلل الاستقصاء الطويل من الطلبات غير الضرورية مقارنة بالاستقصاء العادي ولكنه لا يزال يتطلب حمل رؤوس HTTP على كل إعادة اتصال وأكثر تعقيدًا للتنفيذ بشكل صحيح.

أحداث الخادم المرسلة (SSE)

توفر أحداث الخادم المرسلة طريقة موحدة للخوادم لدفع التحديثات إلى العملاء عبر اتصال HTTP واحد:

// تطبيق SSE من جانب العميل
const eventSource = new EventSource('/api/stream');

eventSource.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log('تم الاستلام:', data);
};

eventSource.onerror = (error) => {
  console.error('خطأ SSE:', error);
};

خصائص SSE:

أحادي الاتجاه: من الخادم إلى العميل فقط
نصي: يستخدم نوع محتوى text/event-stream
إعادة الاتصال التلقائي: تعيد المتصفحات الاتصال تلقائيًا عند الفشل
مبني على HTTP: يعمل من خلال معظم الوكلاء وجدران الحماية

WebSockets: التواصل الثنائي الحقيقي

توفر WebSockets قناة اتصال كاملة الازدواج عبر اتصال TCP واحد، مما يتيح تبادل البيانات في الوقت الفعلي ثنائي الاتجاه:

// اتصال WebSocket أساسي
const socket = new WebSocket('ws://example.com/socket');

socket.onopen = () => {
  console.log('متصل');
  socket.send('مرحبًا أيها الخادم!');
};

socket.onmessage = (event) => {
  console.log('تم الاستلام:', event.data);
};

مزايا WebSocket:

تأخير منخفض: الاتصال المستمر يلغي حمل المصافحة
ثنائي الاتجاه: يمكن للعميل والخادم إرسال الرسائل في أي وقت
فعال: حمل تأطير ضئيل (2-14 بايت لكل إطار)
دعم ثنائي: يمكن نقل البيانات النصية أو الثنائية

حالات استخدام التطبيقات في الوقت الفعلي

1. الدردشة والمراسلة

تتطلب المراسلة الفورية التسليم الفوري للرسائل، ومؤشرات الكتابة، وتحديثات حالة الوجود.

2. التحرير التعاوني

يحتاج المستخدمون المتعددون الذين يحررون نفس المستند في وقت واحد إلى رؤية تغييرات بعضهم البعض في الوقت الفعلي مع خوارزميات التحويل التشغيلي أو CRDT.

3. لوحات البيانات المباشرة

تعرض لوحات التحكم المالية ومنصات التحليلات وأنظمة المراقبة تدفقات البيانات المتحدثة باستمرار.

4. الألعاب عبر الإنترنت

تتطلب الألعاب متعددة اللاعبين اتصالات منخفضة التأخير للغاية لمواقع اللاعبين والإجراءات ومزامنة حالة اللعبة.

5. الإشعارات والتنبيهات

إشعارات الدفع لتحديثات وسائل التواصل الاجتماعي أو تنبيهات النظام أو الأخبار العاجلة يتم تسليمها على الفور إلى العملاء المتصلين.

6. إنترنت الأشياء وبيانات المستشعرات

أجهزة إنترنت الأشياء تبث بيانات المستشعرات والقياس عن بُعد وأوامر التحكم في الوقت الفعلي.

جدول المقارنة

التقنية          | التأخير | الحمل      | ثنائي الاتجاه | التعقيد
-----------------------------------------------------------------
الاستقصاء        | عالي    | عالي جداً  | لا            | منخفض
الاستقصاء الطويل | متوسط   | عالي       | لا            | متوسط
SSE              | منخفض   | متوسط      | لا            | منخفض
WebSockets       | منخفض جداً| منخفض جداً | نعم           | متوسط

تمرين: فكر في تطبيق تستخدمه يوميًا. حدد ما إذا كان يستخدم التواصل في الوقت الفعلي وما التقنية التي قد يستخدمها. ضع في اعتبارك:

هل يعرض تحديثات فورية بدون تحديث الصفحة؟
هل الاتصال أحادي الاتجاه أم ثنائي الاتجاه؟
ماذا سيحدث إذا استخدم الاستقصاء بدلاً من WebSockets؟

متى تستخدم WebSockets

حالات استخدام جيدة:

الحاجة إلى اتصال ثنائي الاتجاه متكرر
التأخير المنخفض أمر بالغ الأهمية
تكرار رسائل عالي
ميزات التعاون في الوقت الفعلي

متى لا تستخدم WebSockets:

تحديثات غير متكررة (SSE أو الاستقصاء قد يكفي)
تدفق بيانات أحادي الاتجاه (SSE أبسط)
نمط RESTful API مفضل
الحاجة إلى فوائد التخزين المؤقت وCDN

أفضل ممارسة: ابدأ بأبسط حل يلبي متطلباتك. قد يكون SSE أو الاستقصاء الطويل كافيًا للعديد من حالات الاستخدام قبل إدخال تعقيد WebSockets.

الملخص

تطور التواصل في الوقت الفعلي على الويب من الاستقصاء غير الفعال إلى تطبيقات WebSocket المتطورة. فهم قيود HTTP، والتحسينات التي يوفرها الاستقصاء الطويل وSSE، وقدرات WebSockets أمر ضروري لبناء تطبيقات حديثة في الوقت الفعلي. في الدرس التالي، سنتعمق في بروتوكول WebSocket نفسه.