जावास्क्रिप्ट में लॉन्ग पोलिंग की समस्याएं और उनसे निपटने के तरीके

होम » अजगर » जावास्क्रिप्ट में लॉन्ग पोलिंग की समस्याएं और उनसे निपटने के तरीके

जावास्क्रिप्ट में लॉन्ग पोलिंग देखने में बेहद सरल लगती है: एक HTTP अनुरोध को तब तक खुला रखें जब तक सर्वर के पास कुछ कहने के लिए न हो, डेटा वापस करें और तुरंत एक नया अनुरोध खोलें। बाहर से देखने पर यह लगभग वास्तविक समय के संचार जैसा लगता है, इसलिए इसमें कोई आश्चर्य नहीं कि चैट ऐप्स, डैशबोर्ड, गेम और नोटिफिकेशन सिस्टम वर्षों से इस पर निर्भर रहे हैं। लेकिन आंतरिक रूप से इसमें कुछ सूक्ष्म प्रदर्शन, स्केलेबिलिटी और विश्वसनीयता संबंधी कमियां हैं जो आपके ऐप के उपयोगकर्ताओं की संख्या कुछ ही लोगों से अधिक होने पर सामने आने लगती हैं।

जावास्क्रिप्ट में लॉन्ग पोलिंग की वास्तविक समस्याओं को समझने का मतलब है कि बुनियादी "क्लाइंट अनुरोध भेजता है, सर्वर प्रतीक्षा करता है, सर्वर प्रतिक्रिया देता है" विवरण से आगे बढ़कर HTTP सिमेंटिक्स, ब्राउज़र सीमाओं, प्रॉक्सी, टाइमआउट और वेबसॉकेट, HTTP स्ट्रीमिंग और सर्वर-सेंट इवेंट्स जैसे विकल्पों को देखना। इस गाइड में हम इस बात की गहराई से पड़ताल करेंगे कि लॉन्ग पोलिंग कैसे काम करती है, आईईटीएफ और प्रमुख विक्रेताओं द्वारा किन मुद्दों की पहचान की गई है, और यह कैसे तय किया जाए कि इसका उपयोग कब करना है, इसे कब अनुकूलित करना है और इसे पूरी तरह से कब बदलना है।

जावास्क्रिप्ट में लॉन्ग पोलिंग वास्तव में क्या है?

सरल शब्दों में कहें तो, लॉन्ग पोलिंग सामान्य HTTP पर आधारित एक पैटर्न है, जिसमें ब्राउज़र एक अनुरोध भेजता है और सर्वर जानबूझकर प्रतिक्रिया में तब तक देरी करता है जब तक कि नया डेटा उपलब्ध न हो जाए या टाइमआउट समाप्त न हो जाए। जैसे ही ब्राउज़र को प्रतिक्रिया मिलती है, वह डेटा को संसाधित करता है और तुरंत एक और अनुरोध भेजता है, जिससे कनेक्शन "लगभग हमेशा" लंबित रहता है।

यह प्रक्रिया पारंपरिक शॉर्ट पोलिंग से बहुत अलग है, जहां क्लाइंट एक निश्चित अंतराल पर सर्वर से बार-बार पूछता है, "क्या कुछ नया है?" चाहे कोई अपडेट हो या न हो। लॉन्ग पोलिंग के साथ, सर्वर निष्क्रियता की अवधि के दौरान अनुरोध को खुला रखता है, इसलिए क्लाइंट को बार-बार खाली पोल भेजने की आवश्यकता नहीं होती है जब कुछ भी नहीं बदला होता है।

एक सामान्य जावास्क्रिप्ट लॉन्ग पोलिंग लूप एक रिकर्सिव सब्सक्राइब फ़ंक्शन की तरह दिखता है जो फ़ेच (या XMLHttpRequest) को कॉल करता है, प्रतिक्रिया की प्रतीक्षा करता है, पेलोड को संभालता है, और फिर खुद को फिर से कॉल करता है। यदि नेटवर्क बाधित हो जाता है या कोई त्रुटि उत्पन्न होती है, तो कोड तुरंत या थोड़ी देर बाद पुनः प्रयास करता है, और उस लंबित कनेक्शन को यथासंभव लंबे समय तक चालू रखने की कोशिश करता है।

यह दृष्टिकोण तब विशेष रूप से कारगर होता है जब संदेश अपेक्षाकृत कम आते हैं, क्योंकि कनेक्शन पर निष्क्रिय समय सॉकेट को खुला रखने की लागत से अधिक नेटवर्क ट्रैफ़िक या सीपीयू लोड उत्पन्न नहीं करता है। उपयोगकर्ता को लगभग तुरंत अपडेट मिलते हैं, जबकि सर्वर को लगातार पोलिंग जांचों से होने वाले बोझ से मुक्ति मिलती है।

हालांकि, जैसे ही घटनाएं बार-बार होने लगती हैं, प्रत्येक घटना एक पूरे HTTP प्रतिक्रिया चक्र को ट्रिगर करती है - स्थिति पंक्ति, हेडर, प्रमाणीकरण, बॉडी - इसलिए प्रति संदेश लागत में भारी वृद्धि हो सकती है और ट्रैफ़िक पैटर्न अनुरोध/प्रतिक्रिया स्पाइक्स के आरी-दांत जैसा दिखने लगता है। यहीं से वास्तविक दुनिया के अनुप्रयोगों में स्केलिंग और ओवरहेड से संबंधित समस्याएं सामने आने लगती हैं।

संक्षिप्त मतदान बनाम दीर्घकालिक मतदान बनाम स्ट्रीमिंग

समस्या को सही मायने में समझने के लिए, लॉन्ग पोलिंग की तुलना शॉर्ट पोलिंग और HTTP स्ट्रीमिंग से करना मददगार होता है, क्योंकि ये तीनों ही HTTP जैसे मूल रूप से अनुरोध/प्रतिक्रिया प्रोटोकॉल पर "पुश" का दिखावा करने के तरीके हैं।

शॉर्ट पोलिंग इसका सरल रूप है: क्लाइंट समय-समय पर HTTP अनुरोध भेजता है (उदाहरण के लिए हर 5-10 सेकंड में) और सर्वर पिछले पोल के बाद से आए किसी भी संदेश के साथ तुरंत जवाब देता है। यदि कुछ भी उपलब्ध नहीं है, तो भी सर्वर प्रतिक्रिया देता है, अक्सर एक खाली पेलोड के साथ, और क्लाइंट बस अगले अंतराल तक प्रतीक्षा करता है।

इस मॉडल की दो स्पष्ट कमियां हैं: संदेश विलंबता मतदान अंतराल जितनी अधिक हो सकती है, और सर्वर को नए डेटा न होने पर भी बार-बार अनुरोधों को संभालने के लिए मजबूर होना पड़ता है। छोटे या कम ट्रैफिक वाले सिस्टम के लिए यह स्वीकार्य हो सकता है, लेकिन बड़े पैमाने पर यह सीपीयू साइकल, नेटवर्क बैंडविड्थ को बर्बाद करता है और उपयोगकर्ताओं के लिए ध्यान देने योग्य देरी पैदा कर सकता है।

लॉन्ग पोलिंग इस सुविधा को और बेहतर बनाती है क्योंकि यह सर्वर को प्रत्येक अनुरोध को तब तक "खुला रखने" की अनुमति देती है जब तक कि कुछ दिलचस्प न हो जाए - जैसे कि डिलीवर करने के लिए कोई इवेंट या टाइमआउट सीमा। नए संदेशों के लिए विलंबता अब एक एकल नेटवर्क राउंड ट्रिप के लगभग बराबर है, और खाली प्रतिक्रियाएं बहुत कम बार होती हैं, जिससे व्यर्थ ट्रैफिक कम हो जाता है।

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

HTTP/1.1 में इसे आमतौर पर चंक्ड ट्रांसफर एन्कोडिंग के माध्यम से लागू किया जाता है, जहां सर्वर Transfer-Encoding: chunked सेट करता है और फिर डेटा के प्रत्येक भाग को अपने स्वयं के लेंथ हेडर के साथ एक अलग चंक के रूप में भेजता है। HTTP/1.0 शैली के सेटअप में, कंटेंट-लेंथ को छोड़कर और कनेक्शन बंद होने को स्ट्रीम के अंत के मार्कर के रूप में उपयोग करके भी स्ट्रीमिंग प्राप्त की जा सकती है।

महत्वपूर्ण अंतर यह है कि लॉन्ग पोलिंग प्रत्येक संदेश के बाद प्रतिक्रिया को बंद कर देती है, जिससे अगले इवेंट के लिए एक नया अनुरोध करना पड़ता है, जबकि स्ट्रीमिंग उसी प्रतिक्रिया को सक्रिय रखती है और संदेशों के घटित होते ही उन्हें आगे बढ़ाती है। इसका विलंबता, मेमोरी उपयोग, प्रॉक्सी और एप्लिकेशन लेयर पर संदेशों को तैयार करने के तरीके पर महत्वपूर्ण प्रभाव पड़ता है।

HTTP लॉन्ग पोलिंग आंतरिक रूप से कैसे काम करती है

HTTP प्रोटोकॉल के दृष्टिकोण से, लॉन्ग पोलिंग किसी भी नए मेथड या स्टेटस कोड को पेश नहीं करता है; यह केवल एक ऐसे अनुरोध के सामान्य अर्थ को विस्तारित करता है जो प्रतिक्रिया की प्रतीक्षा करता है। आईईटीएफ द्वारा "द्विदिशात्मक एचटीटीपी" के विश्लेषण से यह स्पष्ट होता है कि लॉन्ग पोलिंग अभी भी वैध एचटीटीपी 1.0/1.1 है, लेकिन यह मॉडल को उसकी सीमाओं के करीब ले जाता है।

लॉन्ग पोलिंग इंटरैक्शन का मूल जीवनचक्र कुछ इस तरह दिखता है: क्लाइंट एक प्रारंभिक अनुरोध भेजता है और रुक जाता है, सर्वर किसी घटना, स्थिति परिवर्तन या टाइमआउट होने तक प्रतिक्रिया को स्थगित कर देता है, फिर सर्वर घटना डेटा के साथ एक पूर्ण HTTP प्रतिक्रिया (अक्सर 200 OK) लौटाता है, और अंत में क्लाइंट तुरंत एक नया अनुरोध जारी करता है।

यह पैटर्न स्थायी या गैर-स्थायी HTTP कनेक्शन दोनों पर चल सकता है; स्थायी कनेक्शन के साथ, आप एक ही सॉकेट का कई लंबे पोल के लिए पुन: उपयोग करके बार-बार TCP हैंडशेक के ओवरहेड से बचते हैं। व्यवहार में, प्रदर्शन के लिहाज से एक ही टीसीपी कनेक्शन को चालू रखना लगभग हमेशा बेहतर होता है।

लॉन्ग पोलिंग को लागू करने वाले सर्वरों को आमतौर पर प्रति क्लाइंट दो संसाधन समूहों का प्रबंधन करना होता है: स्वयं टीसीपी कनेक्शन और किसी कतार या इवेंट लूप में प्रतीक्षारत एचटीटीपी अनुरोध। ऑपरेटिंग सिस्टम आमतौर पर बड़ी संख्या में खुले सॉकेट को कुशलतापूर्वक संभाल सकते हैं, लेकिन कुछ HTTP सर्वर या गेटवे प्रति अनुरोध काफी मेमोरी आवंटित करते हैं, जो वास्तविक बाधा बन सकती है।

लॉन्ग पोलिंग की एक दिलचस्प विशेषता यह है कि भारी लोड के तहत यह पूरी तरह से विफल होने के बजाय विलंबता बढ़ाकर धीरे-धीरे अपनी कार्यक्षमता कम कर लेता है। यदि सर्वर धीमा है, तो किसी क्लाइंट के लिए भेजे जाने वाले संदेश तब तक कतार में लगे रहेंगे जब तक कि प्रतिक्रिया नहीं भेजी जा सकती; कई कतारबद्ध घटनाओं को एक ही लंबी पोल प्रतिक्रिया में बैच किया जा सकता है, जिससे प्रति संदेश ओवरहेड कम हो जाता है।

लंबी मतदान प्रक्रिया की समस्याएं और सीमाएं

व्यवहार में व्यापक रूप से उपयोग और मानकीकृत होने के बावजूद, लॉन्ग पोलिंग कई जानी-मानी तकनीकी समस्याओं को जन्म देती है, जो जावास्क्रिप्ट में सावधानी न बरतने पर आसानी से उत्पन्न हो सकती हैं। ये समस्याएं बैंडविड्थ के उपयोग, विलंबता, कनेक्शन प्रबंधन और प्रॉक्सी और कैश जैसे मध्यस्थों के व्यवहार में दिखाई देती हैं।

हेडर ओवरहेड पहली लागत है जिसका आपको सामना करना पड़ता है: प्रत्येक लॉन्ग पोल अनुरोध और प्रतिक्रिया एक पूर्ण HTTP संदेश होता है, जिसमें आमतौर पर कुकीज़, प्रमाणीकरण हेडर और अन्य मेटाडेटा शामिल होते हैं जो वास्तविक पेलोड को बौना कर सकते हैं। छोटे, अनियमित संदेशों के लिए यह अतिरिक्त लागत स्वीकार्य हो सकती है, लेकिन मात्रा-आधारित बिलिंग परिदृश्यों या बैंडविड्थ-बाधित नेटवर्क में, हेडर आकार और पेलोड आकार के बीच का अंतर महंगा साबित हो सकता है।

अधिकतम विलंबता एक और सूक्ष्म मुद्दा है: जबकि नई घटनाओं के लिए लंबी पोलिंग की औसत विलंबता लगभग एक नेटवर्क ट्रांजिट होती है, सबसे खराब स्थिति में देरी तीन ट्रांजिट से अधिक हो सकती है। यदि सर्वर द्वारा प्रतिक्रिया भेजने के तुरंत बाद कोई संदेश आता है, तो सर्वर को उस संदेश को भेजने से पहले क्लाइंट से अगले अनुरोध की प्रतीक्षा करनी होगी, और टीसीपी पैकेट हानि या पुनः प्रसारण इस समय को और भी बढ़ा सकता है।

कनेक्शन स्थापित करना अक्सर एक चिंता का विषय होता है, खासकर जब लोग लॉन्ग पोलिंग की तुलना वेबसॉकेट से करते हैं। यदि प्रत्येक लॉन्ग पोल प्रतिक्रिया के कारण HTTP कनेक्शन (और अंतर्निहित TCP कनेक्शन) बंद हो जाता, तो बार-बार सॉकेट खोलने की लागत बहुत अधिक होती। सौभाग्य से, लॉन्ग पोलिंग को परसिस्टेंट कनेक्शन के ऊपर लेयर किया जा सकता है और किया जाना चाहिए, ताकि प्रतिक्रियाओं के बीच के संक्षिप्त अंतराल को निष्क्रियता के रूप में न समझा जाए; इससे ट्रांसपोर्ट खुला और पुन: उपयोग योग्य बना रहता है।

सर्वर और प्रॉक्सी संसाधन आवंटन एक प्रमुख व्यावहारिक सीमा है: प्रत्येक लंबित अनुरोध मेमोरी का उपभोग करता है और सिंक्रोनस आर्किटेक्चर में संभवतः एक थ्रेड या वर्कर का भी। कई पुराने या अवरुद्ध सर्वर हजारों समवर्ती लंबी पोलिंग के लिए पर्याप्त रूप से सक्षम नहीं होते हैं क्योंकि उनका समवर्ती मॉडल प्रत्येक अनुरोध को शीघ्रता से पूरा करने की अपेक्षा करता है; इन प्रणालियों के लिए, अतुल्यकालिक I/O या एक इवेंट-ड्रिवन डिज़ाइन लगभग अनिवार्य है।

यदि कैशिंग व्यवहार को स्पष्ट रूप से प्रतिबंधित नहीं किया जाता है, तो यह लॉन्ग पोलिंग को भी बाधित कर सकता है। मध्यवर्ती कैश प्रतिक्रियाओं का पुन: उपयोग करने या उन्हें संग्रहीत करने का निर्णय ले सकते हैं, जब तक कि आप स्पष्ट रूप से कैश-कंट्रोल: नो-कैश (और संबंधित हेडर) के साथ लॉन्ग पोल अनुरोधों और प्रतिक्रियाओं को चिह्नित नहीं करते हैं, यह सुनिश्चित करते हुए कि प्रत्येक अनुरोध वास्तव में मूल सर्वर तक पहुंचता है और उसे बासी डेटा नहीं दिया जाता है।

टाइमआउट, प्रॉक्सी और मध्यस्थ व्यवहार

जावास्क्रिप्ट में लॉन्ग पोलिंग के साथ सबसे परेशान करने वाली वास्तविक दुनिया की समस्याओं में से एक यह है कि आप ब्राउज़र और सर्वर के बीच नेटवर्क को पूरी तरह से नियंत्रित नहीं कर सकते हैं। प्रॉक्सी, गेटवे, लोड बैलेंसर और यहां तक ​​कि ब्राउज़र के डिफ़ॉल्ट भी टाइमआउट या बफरिंग रणनीतियों को लागू करते हैं जो लाइव कनेक्शन के भ्रम को तोड़ सकते हैं।

लॉन्ग पोल रिक्वेस्ट तब तक खुली रहनी चाहिए जब तक कि आपके द्वारा नियंत्रित कोई घटना या टाइमआउट न हो जाए, लेकिन वास्तविकता में कई मध्यस्थ एक छोटी, निश्चित अवधि के बाद कनेक्शन काट देते हैं। हालांकि ब्राउज़र डिफ़ॉल्ट रूप से लगभग 300 सेकंड तक की अनुमति दे सकते हैं, कुछ प्रॉक्सी बहुत कम टाइमआउट लागू करते हैं, जिसका अर्थ है कि आपका लॉन्ग पोल HTTP 504 गेटवे टाइमआउट या केवल रीसेट के साथ समाप्त हो जाएगा, जिससे क्लाइंट को आपकी अपेक्षा से अधिक बार पुनः कनेक्ट करने के लिए मजबूर होना पड़ेगा।

प्रयोगों और परिचालन अनुभव से पता चलता है कि कई वातावरणों में लगभग 30 सेकंड का टाइमआउट एक सुरक्षित समझौता है, जबकि 120 सेकंड का टाइमआउट अक्सर काम करता है लेकिन अधिक नाजुक होता है। जो नेटवर्क उपकरण विक्रेता लॉन्ग-पोल के अनुकूल होना चाहते हैं, उन्हें सामान्य मध्यम नेटवर्क ट्रांजिट समय की तुलना में काफी लंबे टाइमआउट का उपयोग करने के लिए प्रोत्साहित किया जाता है ताकि वैध लॉन्ग पोल समय से पहले समाप्त न हो जाएं।

रिवर्स प्रॉक्सी और कनेक्शन पूलिंग एक अलग तरह की समस्याएं पैदा करते हैं। कुछ प्रॉक्सी सेटअप कई क्लाइंट्स के बीच अपस्ट्रीम कनेक्शनों का एक छोटा सा पूल साझा करते हैं; यदि लंबे समय तक चलने वाले पोल उन साझा कनेक्शनों को व्यस्त रखते हैं, तो अन्य अनुरोधों को पूरा नहीं किया जा सकता है या वे उनके पीछे कतार में लग सकते हैं, जिससे पूरी साइट के प्रदर्शन पर बुरा असर पड़ सकता है।

HTTP स्ट्रीमिंग के साथ, मध्यवर्ती बफरिंग एक और भी बड़ा जोखिम है क्योंकि प्रॉक्सी को आंशिक प्रतिक्रियाओं को बफर करने की अनुमति होती है और वे पूर्ण प्रतिक्रिया प्राप्त होने के बाद ही डेटा को आगे भेजते हैं। ऐसे में, एक स्ट्रीमिंग सर्वर जो ब्राउज़र में तत्काल निष्पादन की उम्मीद में छोटे जावास्क्रिप्ट चंक्स भेजता है, उसे पता चल सकता है कि एक मध्यस्थ कनेक्शन समाप्त होने तक सब कुछ रोक कर रखता है, जिससे वास्तविक समय का व्यवहार पूरी तरह से नष्ट हो जाता है।

ब्राउज़र सीमाएँ और कनेक्शन संख्या

जावास्क्रिप्ट से, आप कभी भी सीधे टीसीपी कनेक्शनों में हेरफेर नहीं करते हैं; आप केवल फ़ेच या XMLHttpRequest जैसी उच्च-स्तरीय संरचनाएं देखते हैं, लेकिन ब्राउज़र एक ही होस्ट से कितने समानांतर कनेक्शन खोले जा सकते हैं, इस पर सीमाएं लागू करते हैं। ऐतिहासिक रूप से यह सीमा प्रति मूल बिंदु दो कनेक्शन थी, जिसने धूमकेतु-शैली की तकनीकों को विशेष रूप से मुश्किल बना दिया था।

आधुनिक ब्राउज़रों ने इन प्रतिबंधों को शिथिल करते हुए प्रति होस्ट लगभग छह या आठ कनेक्शन तक सीमित कर दिया है, लेकिन जावास्क्रिप्ट से "कितने कनेक्शन शेष हैं?" पूछने या टैब और आईफ्रेम में उपयोग को समन्वित करने का अभी भी कोई मानक तरीका नहीं है। प्रत्येक टैब स्वतंत्र रूप से अपना स्वयं का लंबा सर्वेक्षण शुरू कर सकता है, जिससे उपलब्ध स्लॉट जल्दी समाप्त हो सकते हैं और सीएसएस, छवियों या एपीआई कॉल जैसे अन्य आवश्यक अनुरोध अवरुद्ध हो सकते हैं।

सर्वर साइड पर एक सर्वोत्तम अभ्यास यह है कि एक ही ब्राउज़र इंस्टेंस से आने वाले कई लंबे पोल का पता लगाने के लिए कुकीज़ या किसी सहसंबंध तंत्र का उपयोग किया जाए और उन सभी को स्थगित करने से बचा जाए। बहुत लंबे समय तक चलने वाले सर्वेक्षणों का तुरंत जवाब देकर और केवल एक या कुछ ही सर्वेक्षणों को रोककर, आप कनेक्शन की कमी या पाइपलाइन में रुकावट के जोखिम को कम कर सकते हैं।

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

HTTP पाइपलाइनिंग, फ्रेमिंग और संदेश क्रमबद्धता

हालांकि HTTP पाइपलाइनिंग (प्रतिक्रिया प्राप्त करने से पहले एक ही कनेक्शन पर लगातार कई अनुरोध भेजना) सैद्धांतिक रूप से लंबी पोलिंग विलंबता को कम कर सकती है, लेकिन व्यवहार में यह नाजुक है और इसे असंगत रूप से लागू किया जाता है। RFC 2616 पाइपलाइनिंग को लेकर सतर्क है, खासकर POST अनुरोधों के लिए, और मध्यस्थ या क्लाइंट इसे पूरी तरह से अक्षम कर सकते हैं।

जो प्रोटोकॉल लॉन्ग पोलिंग के लिए पाइपलाइनिंग का फायदा उठाने की कोशिश करते हैं, उन्हें सबसे पहले यह पता लगाना होगा कि पाइपलाइनिंग को शुरू से अंत तक विश्वसनीय रूप से सपोर्ट किया जाता है या नहीं; यदि नहीं, तो वे रूढ़िवादी, गैर-पाइपलाइन व्यवहार पर वापस आ जाते हैं। ब्राउज़र के जावास्क्रिप्ट वातावरण से, आपके पास इसे प्रबंधित करने के लिए हुक नहीं होते हैं, इसलिए अधिकांश जावास्क्रिप्ट-आधारित लॉन्ग पोलिंग स्टैक बस यह मान लेते हैं कि पाइपलाइनिंग उपलब्ध नहीं है।

फ्रेमिंग—जिस तरह से आप बाइट्स की एक निरंतर स्ट्रीम को अलग-अलग एप्लिकेशन संदेशों में विभाजित करते हैं—लॉन्ग पोलिंग और HTTP स्ट्रीमिंग के बीच एक और सूक्ष्म अंतर है। लॉन्ग पोलिंग के साथ, प्रत्येक HTTP प्रतिक्रिया स्वाभाविक रूप से एक या कई संदेशों को ले जाती है, इसलिए आपका फ्रेमिंग निहित है: एक प्रतिक्रिया सार्थक डेटा के एक हिस्से के बराबर है।

स्ट्रीमिंग में, आप अपने एप्लिकेशन फ्रेमिंग के रूप में HTTP चंक सीमाओं पर निर्भर नहीं रह सकते हैं, क्योंकि प्रॉक्सी डेटा स्ट्रीम को फिर से चंक कर सकते हैं, चंक को मर्ज कर सकते हैं या उन्हें अलग-अलग तरीके से विभाजित कर सकते हैं। इसका मतलब है कि ऐप को पेलोड में अपने स्वयं के सीमांकक या लंबाई उपसर्ग एम्बेड करने होंगे और क्लाइंट पर तदनुसार पार्स करना होगा।

संदेशों का क्रमबद्ध होना और उनकी विश्वसनीयता केवल लॉन्ग पोलिंग से सुनिश्चित नहीं होती; यह आपके एप्लिकेशन प्रोटोकॉल और स्टोरेज लेयर पर निर्भर करता है। यदि कोई क्लाइंट बीच में ही डिस्कनेक्ट होकर फिर से कनेक्ट होता है, तो यह सुनिश्चित करने के लिए कि कोई भी संदेश खो न जाए या गलत क्रम में वितरित न हो, आपको स्पष्ट तंत्र (जैसे अनुक्रम संख्या या अंतिम-घटना आईडी) की आवश्यकता होती है।

जावास्क्रिप्ट में लॉन्ग पोलिंग के लिए सुरक्षा संबंधी विचार

लॉन्ग पोलिंग तकनीक HTTP के मूल सुरक्षा मॉडल को नहीं बदलती है, लेकिन जिस तरह से इसे अक्सर लागू किया जाता है - विशेष रूप से जावास्क्रिप्ट का उपयोग करने वाले ब्राउज़रों में - वह अतिरिक्त जोखिमों के द्वार खोल सकता है।

कई क्रॉस-डोमेन लॉन्ग पोलिंग समाधान सर्वर से प्राप्त जावास्क्रिप्ट को निष्पादित करने पर निर्भर करते हैं, कभी-कभी JSONP-शैली के कॉलबैक या अन्य गतिशील स्क्रिप्ट इंजेक्शन के माध्यम से। यदि आपका सर्वर इंजेक्शन हमलों के प्रति संवेदनशील है, तो हमलावर संभावित रूप से उन प्रतिक्रियाओं में मनमाना कोड डाल सकता है, जिसे ब्राउज़र फिर पृष्ठ के विशेषाधिकारों के साथ चलाता है।

हर जगह HTTPS का उपयोग करना अनिवार्य है: डेटा को एन्क्रिप्ट करने से लंबे समय तक चलने वाले कनेक्शनों पर होने वाली छेड़छाड़ और जासूसी से सुरक्षा मिलती है। मजबूत प्रमाणीकरण और प्राधिकरण (उदाहरण के लिए, टोकन-आधारित प्रमाणीकरण और भूमिका-आधारित पहुंच नियंत्रण) के साथ मिलकर, आप लॉन्ग पोलिंग एंडपॉइंट्स को इच्छित क्लाइंट तक ही सीमित रख सकते हैं।

क्योंकि लॉन्ग पोलिंग कई कनेक्शनों को लंबे समय तक खुला रखती है, इसलिए यह DoS हमलों को और अधिक आकर्षक बना सकती है: एक हमलावर कई फर्जी लॉन्ग पोल खोलकर सर्वर संसाधनों को समाप्त करने का प्रयास कर सकता है। रेट लिमिटिंग, प्रति आईपी या टोकन कनेक्शन कोटा और उचित टाइमआउट आवश्यक सुरक्षात्मक उपाय हैं।

ब्राउज़र-विशिष्ट खतरे जैसे कि CSRF आमतौर पर उन शुद्ध XHR/फ़ेच लॉन्ग पोल्स के लिए कम महत्वपूर्ण होते हैं जो एम्बिएंट कुकीज़ पर निर्भर नहीं करते हैं, लेकिन यदि कुकीज़ शामिल हैं, तो भी आपको इन एंडपॉइंट्स को किसी अन्य संवेदनशील API की तरह ही मानना ​​चाहिए। SameSite कुकीज़, जहां उपयुक्त हो वहां CSRF टोकन और सख्त CORS नीतियां, ये सभी एक मजबूत सेटअप का हिस्सा हैं।

लॉन्ग पोलिंग बनाम वेबसॉकेट और सर्वर-सेंट इवेंट्स

जावास्क्रिप्ट डेवलपर के दृष्टिकोण से, लॉन्ग पोलिंग, वेबसॉकेट और सर्वर-सेंट इवेंट्स सभी "रीयल-टाइम फीलिंग" जैसी सुविधाओं को प्राप्त करने के तरीके हैं, लेकिन इनके फायदे और नुकसान काफी अलग-अलग हैं।

वेबसॉकेट ब्राउज़र और सर्वर के बीच एक सच्चा, स्थायी और फुल-डुप्लेक्स चैनल स्थापित करता है। प्रारंभिक HTTP अपग्रेड हैंडशेक के बाद, डेटा फ्रेम प्रत्येक संदेश के लिए HTTP हेडर के अतिरिक्त भार के बिना दोनों दिशाओं में प्रवाहित हो सकते हैं, जिससे प्रति-संदेश विलंबता और बैंडविड्थ उपयोग कम हो जाता है।

यह वेबसॉकेट को मल्टीप्लेयर गेमिंग, सहयोगी संपादन, या टेलीमेट्री स्ट्रीम जैसे उच्च-आवृत्ति वाले परिदृश्यों के लिए आदर्श बनाता है, जहां संदेश छोटे लेकिन बार-बार होते हैं। इसका नकारात्मक पहलू यह है कि कुछ कॉर्पोरेट फ़ायरवॉल, पुराने प्रॉक्सी या पुराने क्लाइंट अभी भी वेबसॉकेट अपग्रेड के साथ ठीक से काम नहीं करते हैं, और सर्वरों को एक अलग प्रोग्रामिंग मॉडल और बड़ी संख्या में लंबे समय तक चलने वाले सॉकेट के लिए तैयार किए गए बुनियादी ढांचे का उपयोग करना होगा।

जब आपको केवल सर्वर से क्लाइंट को संदेश भेजने की आवश्यकता होती है, तो SSE वेबसॉकेट की तुलना में सरल होता है, लेकिन यह ब्राउज़र से उसी चैनल पर संदेश वापस नहीं भेज सकता है; क्लाइंट से सर्वर संचार के लिए आपको अभी भी सामान्य HTTP अनुरोधों पर निर्भर रहना पड़ता है। इसके लिए यह भी आवश्यक है कि मध्यस्थ स्ट्रीमिंग को सहन करें और आंशिक प्रतिक्रियाओं को अत्यधिक बफर न करें।

इनकी तुलना में, लॉन्ग पोलिंग अक्सर "सबसे सरल तरीका" होता है जो पुराने ब्राउज़रों और रूढ़िवादी नेटवर्क सेटअप सहित अधिक वातावरण में काम करता है। यही कारण है कि कई रीयल-टाइम प्लेटफॉर्म ऐतिहासिक रूप से वेबसॉकेट के अवरुद्ध होने पर बैकअप के रूप में लॉन्ग पोलिंग का उपयोग करते थे, और क्षमताओं के अनुसार धीरे-धीरे कनेक्शन को अपग्रेड करते थे।

लॉन्ग पोलिंग के ऊपर वास्तविक दुनिया के प्रोटोकॉल: बेयूक्स, BOSH, SSE-जैसे API

एप्लिकेशन डेवलपर्स से जटिलता को छिपाने और एक सुसंगत एपीआई प्रदान करने के लिए लॉन्ग पोलिंग और स्ट्रीमिंग के ऊपर कई उच्च-स्तरीय प्रोटोकॉल बनाए गए हैं। वे लंबी अवधि के मतदान का उपयोग कैसे करते हैं, यह समझने से इस तकनीक की खूबियों और कमियों दोनों को स्पष्ट करने में मदद मिलती है।

कॉमेटडी प्रोजेक्ट द्वारा लोकप्रिय बनाया गया बायक्स प्रोटोकॉल, परिवहन विकल्पों के रूप में HTTP लॉन्ग पोलिंग और स्ट्रीमिंग दोनों का समर्थन करता है। एक बेयूक्स क्लाइंट आमतौर पर सर्वर से दो HTTP कनेक्शन का उपयोग करता है ताकि संदेश लंबे पोल अनुरोधों के पीछे अवरुद्ध हुए बिना दोनों दिशाओं में अतुल्यकालिक रूप से प्रवाहित हो सकें।

प्रारंभिक हैंडशेक के दौरान, क्लाइंट और सर्वर इस बात पर बातचीत करते हैं कि कौन सी द्विदिशात्मक तकनीकें समर्थित हैं—जैसे लॉन्ग पोलिंग, स्ट्रीमिंग आदि—और क्लाइंट उनमें से किसी एक को चुनता है। जावास्क्रिप्ट क्लाइंट के लिए, बेयूक्स आमतौर पर HTTP पाइपलाइनिंग पर निर्भरता से बचता है और इसके बजाय ब्राउज़र कनेक्शन सीमा संबंधी समस्याओं से बचने के लिए खुद को दो लंबित अनुरोधों तक सीमित रखता है।

BOSH (Bidirectional-streams Over Synchronous HTTP) XMPP की दुनिया से आया है और इसे लॉन्ग पोलिंग का उपयोग करके HTTP पर TCP जैसी सेशन की नकल करने के लिए डिज़ाइन किया गया था। एक BOSH कनेक्शन मैनेजर क्लाइंट के अनुरोध को खुला रखता है और एप्लिकेशन सर्वर से डेटा प्राप्त होने पर ही प्रतिक्रिया देता है; जैसे ही क्लाइंट को वह प्रतिक्रिया मिलती है, वह एक नया अनुरोध भेजता है, और लगभग हर समय कम से कम एक लंबित लॉन्ग पोल को चालू रखता है।

BOSH सत्र की शुरुआत में बातचीत करके तय किए गए एक या दो समानांतर HTTP अनुरोध-प्रतिक्रिया युग्मों का उपयोग कर सकता है, और ब्राउज़र कनेक्शन सीमाओं का सम्मान करते हुए भी अतुल्यकालिक द्विदिश संदेश भेजने की अनुमति देते हुए उन्हें सावधानीपूर्वक प्रबंधित करता है। यह मध्यवर्ती माध्यमों में बफरिंग समस्याओं से बचने के लिए खंडित स्थानांतरण एन्कोडिंग को प्रतिबंधित करता है और दक्षता के लिए सामग्री-एन्कोडिंग के माध्यम से संपीड़न की अनुमति देता है।

सर्वर-सेंट इवेंट्स, हालांकि आमतौर पर लॉन्ग पोलिंग के बजाय स्ट्रीमिंग के माध्यम से कार्यान्वित किए जाते हैं, भावना में काफी हद तक संबंधित हैं। W3C विनिर्देश टेक्स्ट/इवेंट-स्ट्रीम प्रतिक्रियाओं के उपयोग का वर्णन करता है और HTTP चंकिंग को अक्षम करने का सुझाव देता है जब तक कि इवेंट दर पर्याप्त रूप से उच्च न हो, ताकि HTTP/1.1 पर स्ट्रीमिंग के साथ देखी जाने वाली कुछ बफरिंग और मध्यवर्ती समस्याओं से बचा जा सके।

जावास्क्रिप्ट ऐप्स में लॉन्ग पोलिंग को ऑप्टिमाइज़ करना और उसे सुरक्षित बनाना

यदि आप यह तय करते हैं कि लॉन्ग पोलिंग आपके जावास्क्रिप्ट ऐप के लिए सही विकल्प है या एक आवश्यक बैकअप है, तो इसे अधिक कुशल, स्केलेबल और मजबूत बनाने के लिए कई रणनीतियाँ हैं।

सबसे पहले, अपने टाइमआउट को सोच-समझकर निर्धारित करें। बहुत कम समय होने पर बार-बार होने वाले रीकनेक्शन को संभालने में संसाधन बर्बाद होंगे और एक साथ कई क्लाइंट्स के रीकनेक्ट होने का खतरा रहेगा; बहुत अधिक समय होने पर प्रॉक्सी या लोड बैलेंसर की सीमा तक पहुँचने की संभावना बढ़ जाती है, जिससे अप्रत्याशित डिस्कनेक्ट हो सकते हैं। व्यवहार में, वेटटाइमसेकंड्स (अमेज़ॅन SQS जैसे API में) और इसी तरह के ऐप-स्तरीय टाइमआउट के लिए 20-30 सेकंड की सीमा अक्सर एक अच्छा संतुलन प्रदान करती है।

इसके बाद, जब किसी क्लाइंट के लिए कई संदेश कतार में हों, तो सर्वर साइड पर इवेंट्स को बैच करने पर विचार करें। एक ही लंबे पोल प्रतिक्रिया में कई अपडेट देने से प्रति-संदेश ओवरहेड में काफी कमी आती है और विलंबता के बदले थ्रूपुट प्राप्त करके सिस्टम को लोड के तहत अधिक सुचारू रूप से काम करने में मदद मिल सकती है।

संपीड़न एक और आसान उपाय है: लंबे समय तक मतदान के दौरान JSON पेलोड के लिए gzip या इसी तरह की सामग्री एन्कोडिंग को सक्षम करने से बैंडविड्थ का उपयोग कम हो सकता है, खासकर जब संदेशों में दोहराव वाली संरचना हो। इसके बदले में संपीड़न के लिए अतिरिक्त सीपीयू लागत लगती है, लेकिन कई वास्तविक अनुप्रयोगों में नेटवर्क स्थानांतरण समय में कमी से यह लागत कम हो जाती है।

जावास्क्रिप्ट की दृष्टि से, मजबूत त्रुटि प्रबंधन और पुनः प्रयास तर्क अपरिहार्य हैं। आपके सब्सक्रिप्शन लूप को नेटवर्क त्रुटियों, टाइमआउट या गलत प्रतिक्रियाओं का पता लगाना चाहिए और सर्वर पर बार-बार दबाव डालने के बजाय बैकऑफ़ के साथ पुनः प्रयास करना चाहिए। आउटेज के दौरान सिंक्रोनाइज़्ड रिट्राई स्टॉर्म को रोकने के लिए जिटर के साथ एक्सपोनेंशियल बैकऑफ़ एक सामान्य पैटर्न है।

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

जावास्क्रिप्ट में लॉन्ग पोलिंग उन वातावरणों में लगभग रीयल-टाइम सुविधाएँ बनाने के लिए एक शक्तिशाली उपकरण बना हुआ है जहाँ वेबसॉकेट या एसएसई उपलब्ध नहीं हैं, लेकिन इसमें हेडर, टाइमआउट, प्रॉक्सी और संसाधन उपयोग से संबंधित कई छिपी हुई लागतें शामिल हैं जिन्हें आपको समझना और प्रबंधित करना होगा यदि आप चाहते हैं कि आपका ऐप सुचारू रूप से स्केल हो सके।