Long Polling: ما هو، كيف يعمل وأين يستخدم

ما هو Long Polling

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

ظهرت تقنية Long Polling كتطور تدريجي لـ Short Polling لتقليل عدد طلبات HTTP الفارغة. في الاستعلام التقليدي، يرسل العميل طلبات كل N ثانية، ويستجيب الخادم حتى عند عدم وجود بيانات جديدة. في Long Polling، يستخدم الخادم آلية احتفاظ الاتصال، مما يقلل حجم المرور غير المفيد بشكل جذري.

تاريخ Long Polling

قبل ظهور WebSocket في 2011، كان Long Polling هو الطريقة الرئيسية للاتصال الفوري على الويب. شركات مثل Facebook و Gmail استخدمت هذه التقنية لدردشتها وإشعاراتها في أوائل عام 2010. وفقًا لـ High Performance Browser Networking (Grigorik, 2013)، كان Long Polling يتعامل مع نسبة تصل إلى 95% من جميع الاتصالات الفورية في تطبيقات الويب الرئيسية في تلك الفترة.

المبدأ الأساسي لـ Long Polling

يرسل العميل طلب HTTP قياسيًا إلى الخادم. عند استلام الطلب، لا يعيد الخادم استجابة فورًا — بل يضع الطلب في قائمة انتظار. عند حدوث حدث على الخادم (رسالة جديدة، تغير بيانات)، يقوم الخادم بتكوين استجابة وإرسالها إلى العميل. بعد استلام الاستجابة، يقوم العميل فورًا بإنشاء طلب Long Polling جديد، ويتكرر الدورة.

كيف يعمل Long Polling

Long Polling يعمل وفقًا للتسلسل التالي من الخطوات. يرسل العميل طلب HTTP GET إلى نقطة نهاية الخادم. عند استلام الطلب، يتحقق الخادم من وجود بيانات جديدة في قائمة الأحداث. إذا لم تكن هناك بيانات، يحتفظ الخادم بالطلب في حالة انتظار، دون إرسال استجابة فورًا. تعتمد آلية الاحتفاظ على تنفيذ الخادم — غالبًا ما يتم استخدام المعالجة غير المتزامنة مع استدعاءات الإرجاع أو الهندسة القائمة على الأحداث.

عند حدوث حدث على جانب الخادم (على سبيل المثال، أرسل مستخدم رسالة في الدردشة)، يقوم الخادم بتكوين استجابة HTTP بمحتوى يحتوي على هذه البيانات وينهي الاتصال. يتلقى العميل الاستجابة، يعالج البيانات ويبدأ فورًا طلبًا جديدًا. إذا لم تظهر بيانات أثناء فترة الانتظار، يرسل الخادم استجابة فارغة بعد انتهاء الوقت المحدد، ويعيد العميل أيضًا إنشاء الاتصال. عادة ما يكون الوقت المحدد 30–60 ثانية للتوازن بين الحمل وزمن الاستجابة.

المهل الزمني وإدارة الاتصال

من المعلمات الأساسية لتكوين Long Polling هو وقت الانتظار. يؤدي وقت انتظار قصير جدًا (أقل من 10 ثوانٍ) إلى زيادة عدد الطلبات، مما يقرب التقنية من Short Polling. قد يتسبب وقت انتظار طويل جدًا (أكثر من 120 ثانية) في قطع الاتصال بواسطة الوكلاء المتوسطين وموازنات الحمل. القيمة الموصى بها لمعظم السيناريوهات هي 30–45 ثانية.

معالجة الأحداث المتعددة

إذا وقعت أحداث متعددة على الخادم خلال طلب Long Polling واحد، يجب على الخادم نقلها جميعًا في استجابة واحدة أو تنظيم قائمة أحداث على جانب العميل. لهذا الغرض، يتم استخدام تخزين الأحداث مؤقتًا: يقوم الخادم بتجميع الأحداث التي وقعت أثناء وقت احتفاظ الطلب ويقوم بنقلها كمصفوفة بيانات في جسم الاستجابة.

مثال تنفيذ Long Polling باستخدام JavaScript

دعنا ننظر إلى تنفيذ بسيط لـ Long Polling على جانب العميل باستخدام Fetch API الحديثة. ترسل دالة العميل طلبًا وتستدعي نفسها بشكل تكراري بعد استلام الاستجابة.

async function longPoll(url) {
    try {
        const response = await fetch(url);
        const data = await response.json();

        handleData(data);
        longPoll(url);
    } catch (error) {
        console.error("خطأ Long Polling", error);
        setTimeout(() => longPoll(url), 3000);
    }
}

function handleData(data) {
    if (data.events && data.events.length > 0) {
        data.events.forEach(event => {
            console.log("حدث جديد:", event);
        });
    }
}

longPoll("/api/events");

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

تنفيذ الخادم على Node.js

على جانب الخادم، من الضروري احتفاظ الطلب حتى حدوث حدث أو انتهاء الوقت المحدد. مثال تنفيذ باستخدام EventEmitter في Node.js يوضح هذه الآلية.

const express = require("express");
const EventEmitter = require("events");
const app = express();

const eventBus = new EventEmitter();

app.get("/api/events", (req, res) => {
    const timeout = setTimeout(() => {
        res.json({ events: [] });
    }, 30000);

    eventBus.once("new-event", (data) => {
        clearTimeout(timeout);
        res.json({ events: [data] });
    });
});

app.post("/api/events", (req, res) => {
    eventBus.emit("new-event", req.body);
    res.send({ status: "ok" });
});

app.listen(3000);

يستخدم جزء الخادم EventEmitter لإشعار اتصالات Long Polling المنتظرة عند ظهور بيانات جديدة. عند الوصول إلى وقت انتظار مدته 30 ثانية، يعيد الخادم مصفوفة فارغة من الأحداث، ويقوم العميل بإنشاء طلب جديد.

متى يستخدم Long Polling

Long Polling يستخدم في السيناريوهات حيث يكون توصيل البيانات في الوقت الفعلي مطلوبًا ولكن استخدام WebSocket غير ممكن لأسباب تقنية أو بنيوية. أكثر الحالات شيوعًا هي الوكلاء الميدانيون وجدار الحماية الذين يحجبون اتصالات WebSocket، والبيئات ذات الدعم المحدود للبروتوكول على جانب الخادم.

• الدردشة والمراسلة — يوفر Long Polling توصيل الرسائل في إصدارات الويب للمراسلات التي تعمل عبر HTTP بدون WebSocket.
• لوحات المراقبة — أنظمة فورية لمقاييس DevOps، سجلات الأحداث والتنبيهات حيث تكون حداثة البيانات مع تأخير من 1 إلى 5 ثوانٍ أمرًا مهمًا.
• الإشعارات — توصيل شبيه بالدفع للتنبيهات في المتصفح دون استخدام Service Workers و Push API.
• خلاصات النشاط — شبكات التواصل الاجتماعي وخلاصات الأخبار مع تحديث تلقائي للمحتوى عند ظهور منشورات جديدة.
• العمل المشترك — محررات مثل Google Docs مع مزامنة أساسية للتغييرات بين المستخدمين.

العامل الرئيسي في اختيار Long Polling هو التوافق العكسي. جميع عملاء وخوادم HTTP تدعم هذه الطريقة، مما يجعلها حلًا عالميًا للوظائف في الوقت الفعلي دون تبعيات إضافية. وفقًا لـ HTTP Archive (2024)، حوالي 8% من جميع مواقع الويب تستمر في استخدام Long Polling للوظائف الأساسية في الوقت الفعلي.

Long Polling vs Short Polling

Long Polling و Short Polling يحلان نفس المشكلة — توصيل البيانات من الخادم إلى العميل — ولكنهما يختلفان جوهريًا في الآلية والكفاءة. يستخدم Short Polling فاخر استعلام ثابت حيث يرسل العميل طلبات HTTP على فواصل زمنية متساوية بغض النظر عن ظهور بيانات جديدة على الخادم.

Short Polling أبسط في التنفيذ ولكنه يخلق حملًا أكبر بشكل ملحوظ على الخادم والشبكة بنفس تردد تحديث البيانات. إذا كان زمن الاستجابة أقل من 5 ثوانٍ مطلوبًا، فإن Short Polling يولّد عشرات الطلبات في الدقيقة، بينما Long Polling يستخدم طلبًا واحدًا لكل حدث أو وقت محدد. بالنسبة للتطبيقات ذات الأحداث نادرة، Long Polling أكثر كفاءة بمراتب من حيث حجم المرور.

Long Polling vs WebSocket

WebSocket هو بروتوكول فوري كامل ثنائي الاتجاه يعمل فوق TCP بعد مصافحة HTTP أولية. على عكس Long Polling، ينشئ WebSocket اتصالاً واحدًا مستمرًا ويسمح للخادم بإرسال البيانات إلى العميل في أي وقت دون إنشاء طلب HTTP جديد.

يعتمد الاختيار بين Long Polling و WebSocket على عدة عوامل. التوافق: Long Polling يعمل من خلال أي وكيل وجدار حماية، بينما قد يكون WebSocket محجوبًا بواسطة الشبكات المؤسسية. الأداء: WebSocket له تكلفة إضافية أقل (2 بايت لكل إطار مقابل ترويسات HTTP كاملة)، وهذا حاسم عند تردد عالي للرسائل. قابلية التوسع: Long Polling يتطلب مزيدًا من الموارد على جانب الخادم بسبب احتفاظ عدد كبير من الاتصالات، بينما يستخدم WebSocket اتصالًا ثابتًا لكل جلسة.

• Long Polling — أفضل خيار للتطبيقات ذات تردد منخفض للأحداث (1–10 حدث في الدقيقة)، البنية التحتية المحدودة أو الحاجة لدعم المتصفحات القديمة.
• WebSocket — الحل الأمثل للتطبيقات الفورية عالية الحمل (بيانات البورصة، الألعاب عبر الإنترنت، المحررات التعاونية) مع مئات الرسائل في الثانية.
• النهج الهجين — بعض التطبيقات تستخدم Long Polling كبديل احتياطي للعملاء الذين لا يدعمون WebSocket، مع التبديل التلقائي للبروتوكول.

وفقًا لـ Mozilla Developer Network (2024)، WebSocket مدعوم في جميع المتصفحات الحديثة منذ إصدارات 2011–2015، ولكن الوكلاء الميدانيين (على سبيل المثال Symantec Blue Coat) ما زالوا يحجبونه في 15–20% من الشبكات المؤسسية، مما يحافظ على أهمية Long Polling كحل احتياطي.