Long Polling: यह क्या है, कैसे काम करता है और कहाँ उपयोग किया जाता है

Long Polling क्या है

Long Polling एक क्लाइंट-सर्वर आर्किटेक्चर में एक संचार पैटर्न है जहां क्लाइंट HTTP अनुरोध शुरू करता है, और सर्वर नए डेटा उपलब्ध होने या निर्दिष्ट टाइमआउट समाप्त होने तक प्रतिक्रिया भेजने में विलंब करता है। प्रतिक्रिया प्राप्त करने के बाद, क्लाइंट तुरंत अगला अनुरोध भेजता है, जो एक निरंतर कनेक्शन का प्रभाव पैदा करता है।

Long Polling तकनीक खाली HTTP अनुरोधों की संख्या को कम करने के लिए Short Polling के विकासशील विकास के रूप में उभरी। पारंपरिक पोलिंग में, क्लाइंट हर N सेकंड में अनुरोध भेजता है, और सर्वर नए डेटा न होने पर भी जवाब देता है। Long Polling में, सर्वर कनेक्शन होल्डिंग तंत्र का उपयोग करता है, जो बेकार ट्रैफिक को नाटकीय रूप से कम करता है।

Long Polling का इतिहास

2011 में WebSocket के आगमन से पहले, 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 अनुरोध के दौरान सर्वर पर एकाधिक घटनाएँ होती हैं, तो सर्वर को उन्हें एक ही प्रतिक्रिया में भेजना चाहिए या क्लाइंट पक्ष पर एक इवेंट क्यू व्यवस्थित करना चाहिए। इसके लिए, इवेंट बफ़रिंग का उपयोग किया जाता है: सर्वर अनुरोध की होल्डिंग अवधि के दौरान होने वाली घटनाओं को इकट्ठा करता है और उन्हें प्रतिक्रिया बोडी में डेटा की एक श्रृंखला के रूप में भेजता है।

JavaScript में Long Polling कार्यान्वयन उदाहरण

आगे की ओर, आधुनिक Fetch API का उपयोग करके क्लाइंट पक्ष पर एक सरल Long Polling कार्यान्वयन देखते हैं। क्लाइंट फ़ंक्शन एक अनुरोध भेजता है और प्रतिक्रिया प्राप्त करने के बाद रिकर्सिवली स्वयं को कॉल करता है।

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 पर सर्वर कार्यान्वयन

सर्वर पक्ष पर, एक घटना होने या टाइमआउट समाप्त होने तक अनुरोध को रोकना आवश्यक है। Node.js में EventEmitter का उपयोग करने का एक उदाहरण इस तंत्र को प्रदर्शित करता है।

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);

सर्वर भाग नए डेटा दिखाई देने पर प्रतीक्षारत Long Polling कनेक्शनों को सूचित करने के लिए EventEmitter का उपयोग करता है। 30 सेकंड टाइमआउट तक पहुँचने पर, सर्वर घटनाओं की एक खाली श्रृंखला लौटाता है, और क्लाइंट एक नया अनुरोध बनाता है।

Long Polling कब उपयोग किया जाता है

Long Polling का उपयोग उन परिदृश्यों में किया जाता है जहां रियल-टाइम डेटा डेलीवरी आवश्यक है लेकिन तकनीकी या अवसंरचनात्मक कारणों से WebSocket का उपयोग संभव नहीं है। सबसे आम मामले कॉर्करेट प्रॉक्सी और फ़ायरवॉल हैं जो WebSocket कनेक्शन्स को ब्लॉक करते हैं, साथ ही सर्वर पक्ष पर सीमित प्रोटोकॉल समर्थन वाले वातावरण हैं।

• चैट और मेसेंजर — Long Polling वेब संस्करणों में संदेश डेलीवरी प्रदान करता है जो WebSocket के बिना HTTP पर काम करते हैं।
• डैशबॉर्ड पैनल — 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 एक पूर्ण द्वि-दिशात्मक रियल-टाइम प्रोटोकॉल है जो प्रारंभिक HTTP हैंडशेक के बाद TCP पर काम करता है। Long Polling के विपरीत, WebSocket एक ही स्थायी कनेक्शन स्थापित करता है और सर्वर को बिना नया HTTP अनुरोध बनाए किसी भी समय क्लाइंट को डेटा भेजने की अनुमति देता है।

Long Polling और WebSocket के बीच चयन कई कारकों पर निर्भर करता है। अनुकूलता: Long Polling किसी भी प्रॉक्सी और फ़ायरवॉल के माध्यम से काम करता है, जबकि WebSocket कॉर्परेट नेटवर्क्स द्वारा अवरुद्ध हो सकता है। प्रदर्शन: WebSocket में कम ओवरहेड (पूर्ण HTTP हेडर की तुलना में 2 बाईट प्रति फ़्रेम) है, जो उच्च संदेश आवृत्ति पर महत्वपूर्ण है। स्केलेबिलिटी: Long Polling को अनेक कनेक्शन्स रखने के कारण सर्वर पक्ष पर अधिक संसाधनों की आवश्यकता होती है, जबकि WebSocket प्रति सेशन एक निश्चित कनेक्शन का उपयोग करता है।

• Long Polling — कम घटना आवृत्ति (1–10 घटनाएँ प्रति मिनट), सीमित बुनियादी ढांचा या पुराने ब्राउज़रों का समर्थन करने की आवश्यकता वाले एप्लिकेशन्स के लिए सबसे अच्छा विकल्प।
• WebSocket — सौंं मेसेज प्रति सेकंड वाले उच्च-भार रियल-टाइम एप्लिकेशन्स (शेयर बाजार डेटा, ऑनलाइन गेम्स, सहयोगिता संपादक) के लिए इष्टतम हल।
• हाइब्रिड दृष्टिकोण — कुछ एप्लिकेशन्स स्वचालित प्रोटोकॉल स्विचिंग के साथ, WebSocket का समर्थन न करने वाले क्लाइंट्स के लिए Long Polling का उपयोग फ़ॉलबैक के रूप में करते हैं।

Mozilla Developer Network (2024) के अनुसार, WebSocket को 2011–2015 के संस्करणों से सभी आधुनिक ब्राउज़रों द्वारा समर्थित किया जाता है, लेकिन कॉर्परेट प्रॉक्सी (उदाहरण Symantec Blue Coat) 15–20% कॉर्परेट नेटवर्क्स में इसे ब्लॉक करना जारी रखते हैं, जो Long Polling को एक फ़ॉलबैक हल के रूप में प्रासंगिक रखता है।