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 به endpoint سرور ارسال می‌کند. سرور پس از دریافت درخواست، وجود داده‌های جدید را در صف رویداد بررسی می‌کند. اگر داده‌ای وجود نداشته باشد، سرور درخواست را در حالت انتظار نگه می‌دارد و فوراً پاسخ نمی‌دهد. مکانیزم نگه‌داشتن به پیاده‌سازی سرور بستگی دارد — اغلب از پردازش ناهمگام با callback یا معماری رویدادمحور استفاده می‌شود.

هنگامی که رویدادی در سمت سرور رخ می‌دهد (مثلاً کاربر پیامی در چت ارسال کرد)، سرور یک پاسخ HTTP با بدنه حاوی آن داده‌ها تشکیل می‌دهد و اتصال را پایان می‌دهد. کلاینت پاسخ را دریافت می‌کند، داده‌ها را پردازش می‌کند و بلافاصله یک درخواست جدید آغاز می‌کند. اگر در طول انتظار داده‌ای ظاهر نشود، سرور پس از انقضای مهلت زمانی یک پاسخ خالی ارسال می‌کند و کلاینت نیز اتصال را دوباره ایجاد می‌کند. Timeout معمولاً 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، لاگ‌ها و هشدارها، جایی که به‌روزرسانی داده با تأخیر ۱–۵ ثانیه مهم است.
• اعلان‌ها — تحویل اعلان‌ها در مرورگر بدون استفاده از Service Workers و Push API.
• فیدهای فعالیت — شبکه‌های اجتماعی و فیدهای خبری با به‌روزرسانی خودکار محتوا هنگام ظهور نوشته‌های جدید.
• کار گروهی — ویرایشگرهای مشابه Google Docs با همگام‌سازی پایه تغییرات بین کاربران.

عامل کلیدی انتخاب Long Polling سازگاری معکوس است. همه کلاینت‌ها و سرورهای HTTP از این روش پشتیبانی می‌کنند، که آن را به یک راه‌حل جهانی برای بلادرنگ بدون وابستگی‌های اضافی تبدیل می‌کند. بر اساس HTTP Archive (2024)، حدود ۸٪ از تمام وب‌سایت‌ها همچنان از Long Polling برای عملکرد پایه بلادرنگ استفاده می‌کنند.

Long Polling در مقابل Short Polling

Long Polling و Short Polling یک وظیفه را حل می‌کنند — تحویل داده از سرور به کلاینت — اما از نظر مکانیزم و کارایی تفاوت اساسی دارند. Short Polling از یک بازه پرس‌وجوی ثابت استفاده می‌کند، که در آن کلاینت درخواست‌های HTTP را در فواصل زمانی مساوی بدون توجه به ظهور داده‌های جدید روی سرور ارسال می‌کند.

Short Polling در پیاده‌سازی ساده‌تر است، اما با همان فرکانس به‌روزرسانی داده، بار قابل توجهی بیشتری روی سرور و شبکه ایجاد می‌کند. اگر تأخیر کمتر از ۵ ثانیه مورد نیاز باشد، Short Polling ده‌ها درخواست در دقیقه تولید می‌کند، در حالی که Long Polling از یک درخواست به ازای هر رویداد یا مهلت زمانی استفاده می‌کند. برای برنامه‌هایی با رویدادهای نادر، Long Polling از نظر ترافیک به مراتب کارآمدتر است.

Long Polling در مقابل WebSocket

WebSocket یک پروتکل بلادرنگ دوطرفه کامل است که پس از دست‌دهی اولیه HTTP روی TCP کار می‌کند. برخلاف Long Polling، WebSocket یک اتصال ثابت برقرار می‌کند و به سرور اجازه می‌دهد در هر لحظه بدون ایجاد یک درخواست HTTP جدید، داده را به کلاینت ارسال کند.

انتخاب بین Long Polling و WebSocket به چند عامل بستگی دارد. سازگاری: Long Polling از طریق هر پروکسی و فایروالی کار می‌کند، WebSocket ممکن است توسط شبکه‌های شرکتی مسدود شود. عملکرد: WebSocket سربار کمتری دارد (۲ بایت به ازای هر فریم در مقایسه با هدرهای کامل HTTP)، که در فرکانس بالای پیام‌ها حیاتی است. مقیاس‌پذیری: Long Polling به دلیل نگه‌داشتن اتصالات متعدد به منابع بیشتری در سمت سرور نیاز دارد، WebSocket از یک اتصال ثابت به ازای هر جلسه استفاده می‌کند.

• Long Polling — بهترین انتخاب برای برنامه‌هایی با فرکانس پایین رویداد (۱–۱۰ رویداد در دقیقه)، زیرساخت محدود یا نیاز به پشتیبانی از مرورگرهای قدیمی.
• WebSocket — راه‌حل بهینه برای برنامه‌های بلادرنگ با بار بالا (داده‌های بورس، بازی‌های آنلاین، ویرایشگرهای مشارکتی) با صدها پیام در ثانیه.
• رویکرد ترکیبی — برخی برنامه‌ها از Long Polling به عنوان fallback برای کلاینت‌هایی که از WebSocket پشتیبانی نمی‌کنند، با تعویض خودکار پروتکل استفاده می‌کنند.

به گفته Mozilla Developer Network (2024)، WebSocket توسط همه مرورگرهای مدرن از نسخه‌های ۲۰۱۱–۲۰۱۵ پشتیبانی می‌شود، اما پروکسی‌های شرکتی (مانند Symantec Blue Coat) همچنان آن را در ۱۵–۲۰٪ از شبکه‌های سازمانی مسدود می‌کنند که ارتباط Long Polling را به عنوان یک راه‌حل fallback حفظ می‌کند.