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

ما هو Short Polling

Short Polling هو نمط تواصل يرسل فيه العميل بشكل دوري طلبات HTTP إلى الخادم بفاصل زمني محدد مسبقاً، ويعالج الخادم كل طلب بشكل متزامن ويعيد النتيجة فوراً. يُحدد فاصل الاستقصاء من جانب العميل باستخدام المؤقتات ويتراوح عادةً من 1 إلى 60 ثانية حسب متطلبات حداثة البيانات.

Short Polling هو أول آلية زمنياً لتنظيم الاتصال في الوقت الحقيقي في تطبيقات الويب. في أوائل العقد الأول من القرن الحادي والعشرين، قبل الجيل الثاني من XMLHttpRequest، كانت صفحات الويب تستخدم <meta http-equiv="refresh"> أو إعادة تحميل iframe دورياً لتحديث المحتوى. مع ظهور تقنية AJAX (Asynchronous JavaScript and XML) في عام 2005، أصبح Short Polling النهج القياسي لتحديث البيانات دون إعادة تحميل الصفحة بالكامل.

هندسة Short Polling

تشمل هندسة Short Polling ثلاثة مكونات: مؤقت العميل، طلب HTTP، ومعالج الخادم. يبدأ العميل مؤقتاً دورياً، وعند كل تفعيل له يُرسل طلب GET إلى الخادم. ينفذ الخادم استعلاماً لقاعدة البيانات أو مصدر آخر، يُشكل استجابة، ويعيدها فوراً إلى العميل. يُحدّث العميل الواجهة وينتظر التفعيل التالي للمؤقت. تتكرر هذه الدورة إلى ما لا نهاية طالما أن التطبيق نشط.

مشكلة الطلبات الزائدة

المشكلة الرئيسية لـ Short Polling هي الطلبات الفارغة الحتمية. إذا كانت البيانات تتغير نادراً، فإن معظم الطلبات تعيد نتيجة "لا تغييرات"، مما يهدر سعة النطاق الترددي للشبكة ووقت المعالجة. مع 10,000 عميل بفاصل استقصاء 5 ثوانٍ، يتلقى الخادم 2,000 طلب في الثانية — جزء كبير منها غير مفيد إذا كان تردد التحديث حدثاً واحداً في الدقيقة.

كيف يعمل Short Polling

Short Polling يعمل بدورة بسيطة: يضبط العميل مؤقتاً دورياً بفترة محددة (مثلاً 5000 مللي ثانية). عند كل تفعيل للمؤقت، يُشكل العميل طلب GET HTTP إلى نقطة نهاية الخادم، عادةً مع معلمة الطابع الزمني لآخر تحديث. يستلم الخادم الطلب، ويتحقق من وجود بيانات جديدة بعد الطابع الزمني المحدد، ويعيد استجابة — إما ببيانات جديدة أو بمؤشر على عدم وجود تحديثات.

معلمة حاسمة في إعداد Short Polling هي فاصل الاستقصاء. فاصل قصير جداً (أقل من 3 ثوانٍ) يُنشئ حملاً عالياً على الخادم والشبكة. فاصل طويل جداً (أكثر من 30 ثانية) يُقلل من حداثة البيانات. يعتمد الفاصل الأمثل على السيناريو: للوحات المراقبة — 5–15 ثانية، لخلاصات الأخبار — 30–60 ثانية، للتنبيهات الحرجة — 1–3 ثوانٍ. اختيار الفاصل هو دائماً مفاضلة بين حداثة البيانات وحمل البنية التحتية.

فاصل الاستقصاء التكيفي

لتقليل الحمل أثناء الخمول، يُستخدم الفاصل التكيفي: إذا أعادت عدة طلبات متتالية نتيجة فارغة، يزداد الفاصل (مثلاً من 5 إلى 15 ثانية). عند ظهور بيانات جديدة، يُعاد تعيين الفاصل إلى القيمة الدنيا. تتيح خوارزمية التراجع الأسي (exponential backoff) تقليل عدد الطلبات الفارغة بمقدار 3–5 مرات أثناء التحديثات النادرة.

مثال تنفيذ Short Polling في JavaScript

لننظر إلى تنفيذ Short Polling من جانب العميل باستخدام setInterval و Fetch API. تستقبل الدالة عنوان URL لنقطة النهاية وفاصل الاستقصاء بالمللي ثانية.

function startPolling(url, intervalMs) {
    const lastTimestamp = new Date().toISOString();

    const timerId = setInterval(async () => {
        try {
            const params = new URLSearchParams({
                since: lastTimestamp
            });
            const response = await fetch(url + "?" + params);
            const data = await response.json();

            if (data.updates && data.updates.length > 0) {
                renderUpdates(data.updates);
                console.log("تم الاستلام", data.updates.length, "updates");
            }
        } catch (error) {
            console.error("فشل الاستقصاء:", error);
        }
    }, intervalMs);

    return timerId;
}

const timer = startPolling("/api/updates", 5000);
// clearInterval(timer) للإيقاف

ينشئ الكود فاصل استقصاء قدره 5 ثوانٍ ويمرر الطابع الزمني لآخر تحديث إلى الخادم. يمكن للخادم استخدام هذه المعلمة لتصفية البيانات وإرجاع السجلات الجديدة فقط، مما يُقلل من كمية المعلومات المنقولة. تُعيد الدالة معرّف المؤقت لإمكانية إيقاف الاستقصاء.

الجانب الخادمي لـ Short Polling

التنفيذ من جانب الخادم لـ Short Polling بسيط للغاية — إنها نقطة نهاية REST عادية تستقبل طلبات GET وتُعيد استجابة JSON بالحالة الحالية أو البيانات التي تغيرت بعد الطابع الزمني المحدد.

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

let items = [];

app.get("/api/updates", (req, res) => {
    const since = req.query.since;
    const filtered = items.filter(item => item.timestamp > since);
    res.json({ updates: filtered });
});

app.listen(3000);

يستلم الخادم المعامل since ويصفّي السجلات التي يتجاوز طابعها الزمني القيمة المحددة. هذا النهج يُقلل كمية البيانات في كل استجابة، معيداً فقط التغييرات التزايدية. عند عدم وجود بيانات جديدة، يُعيد الخادم مصفوفة فارغة، ويواصل العميل الاستقصاء وفقاً للجدول.

Short Polling مقابل Long Polling

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

يعتمد الاختيار بين التقنيات على تردد التحديثات للبيانات. إذا كانت الأحداث تحدث أكثر من مرة كل 10 ثوانٍ — يعطي كلا النهجين حملاً مشابهاً، وقد يكون Short Polling أبسط. إذا كانت الأحداث نادرة (ساعات أو دقائق بين التغييرات) — يُفضل Long Polling لأنه لا يُنشئ طلبات فارغة. للسيناريوهات المتوسطة، يعتمد الاختيار على قيود البنية التحتية وإمكانية استخدام WebSocket.

متى يُستخدم Short Polling

Short Polling يُستخدم في السيناريوهات حيث تكون متطلبات حداثة البيانات منخفضة ولبساطة التنفيذ أولوية على الكفاءة. الحالات الأكثر شيوعاً هي لوحات الإدارة الداخلية، أنظمة المراقبة بتردد منبهات منخفض، والتطبيقات حيث يكون التأخير من 15–30 ثانية مقبولاً.

• لوحات المراقبة — لوحات بمقاييس تُحدّث كل 10–30 ثانية، لا تتطلب رداً فورياً على التغييرات.
• صفحات الحالة — صفحات فحص توفر الخدمات حيث تُحدّث البيانات كل 30–60 ثانية والتأخير غير حرج.
• تقارير التحليلات — أنظمة تحليلات داخلية مع جمع دوري للبيانات حيث حداثة حتى دقيقة واحدة مقبولة.
• ألعاب بسيطة — ألعاب متعددة اللاعبين بنظام الأدوار دون متطلبات زمن حقيقي، حيث يُحدّث الدور كل بضع ثوانٍ.
• الاختبار — سيناريوهات اختبار التحميل والتصحيح حيث يُستخدم Short Polling كطريقة استقصاء مرجعية للمقارنة مع التقنيات الأخرى.

قيود مهمة — Short Polling غير مناسب للتطبيقات الحساسة للوقت (محطات التداول، أنظمة الإنذار الطارئ) حيث حتى تأخير ثانية واحدة غير مقبول. في مثل هذه السيناريوهات، يجب استخدام WebSocket أو Server-Sent Events أو Long Polling. عند تصميم نظام مع Short Polling، يجب حساب ميزانية الطلبات: مع 1,000 عميل بفاصل 5 ثوانٍ، يعالج الخادم 12,000 طلب في الدقيقة، مما يتطلب قاعدة موارد مناسبة.