में एचटीटीपी में "जीवित रहें" HTTP में HTTP की भूमिका निभाई जा सकती है। कुछ कहते हैं कि इसका इस्तेमाल अच्छा होना चाहिए, लेकिन मैं किसी भी निष्कर्ष तक पहुंचने में असमर्थ हूं। तो कृपया अपना इनपुट/उत्तर/विचार प्रदान करें ताकि मैं इसके लिए कुछ जमीन प्राप्त कर सकूं,एजेक्स एप्लिकेशन
जोखिम क्या है और क्या कोई है?
इनपुट के लिए सभी को धन्यवाद।
सर्वर से आपका कनेक्शन HTTP/1.1 का उपयोग कर रहा है तो सबसे पहले अगर आप पहले से ही "रख-रखाव" का उपयोग कर रहे हैं।
यह क्या है? तार्किक रूप से HTTP एक कनेक्शन रहित प्रोटोकॉल है। सर्वर के लिए प्रत्येक अनुरोध/प्रतिक्रिया एक नया कनेक्शन बनाता है, इसका व्यवसाय करता है और कनेक्शन छोड़ देता है। हालांकि HTTP/1.1 में डिफ़ॉल्ट व्यवहार सर्वर के बाद के अनुरोधों द्वारा कनेक्शन के उपयोग के लिए खुला रखना है। HTTP/1.0 में इस व्यवहार को चुनने के लिए "Keep-live" हेडर को HTTP/1.0 में जोड़ा गया था, सर्वर को कनेक्शन को बंद करके और/या "कनेक्शन-क्लोज़" हेडर भेजकर ऑप्ट-आउट करने की आवश्यकता है प्रतिक्रिया।
यह फायदेमंद क्यों है? एक कनेक्शन बनाना विशेष रूप से जिसे प्रमाणित करने की आवश्यकता है, कुछ समय ले सकता है। मौजूदा कनेक्शन का पुन: उपयोग करके सेटअप और प्रमाणीकरण प्रयास बहुत कम हो गया है।
यह आपके AJAX ऐप को बेहतर कैसे बना सकता है? आप शायद इससे पहले ही लाभान्वित हो रहे हैं।
जोखिम क्या हैं? किसी साझा उपकरण के माध्यम से कनेक्शन बनाते समय जो क्लाइंट की ओर से सर्वर से कनेक्शन कर सकता है, अन्य क्लाइंट के लिए कनेक्शन का पुन: उपयोग करना संभव है, हालांकि यह अन्य क्लाइंट के लिए कनेक्शन का उपयोग करने के लिए भी संभव बनाता है एक अलग उपयोगकर्ता के लिए प्रमाणित।
वास्तव में यह प्रदर्शन और संसाधन के सवालों के लिए उबलता है।
जीवित रहने वाले उच्च (एआर) का उपयोग करके अनुरोधों पर विलंबता कम हो जाती है। यह विशेष रूप से एक मुद्दा है यदि आप एसएसएल पर चल रहे हैं जहां कनेक्शन स्थापित करने के लिए अतिरिक्त हैंडशेक हैं।
ओटीओएच, इसका मतलब यह होगा कि अतिरिक्त सर्वर प्रक्रियाएं हैं। निष्क्रिय बैठे बैठे हैं, बाद के अनुरोध की प्रतीक्षा कर रहे हैं या समय-समय पर समाप्त होने की प्रतीक्षा कर रहे हैं। यह स्मृति को हॉग कर सकता है और इसलिए आपके सर्वर को धीमा कर सकता है।
तो आपको वास्तव में ब्राउज़र खेलने के बनाम सर्वर लोड में शर्तों के अनुसार स्वीकार्य है और देखने की आवश्यकता है।
प्रमाणीकरण (मूल/पाचन/सत्र आधारित) प्रासंगिक नहीं है - यह अनुरोध है जो प्रमाणीकृत है - सॉकेट कनेक्शन नहीं।
ध्यान दें कि आखिरी बार मैंने एक नया अपाचे स्थापित किया था, यह जीवित रहने के लिए 5 सेकंड की डिफ़ॉल्ट सेटिंग के साथ आया था। यह एक गैर-AJAX साइट के लिए हास्यास्पद रूप से लंबा है। मुझे समझ नहीं आता कि एक -
सी
यह "यह संभव अन्य ग्राहकों एक कनेक्शन है कि सर्वर किसी दूसरे उपयोगकर्ता के लिए प्रमाणीकृत है का उपयोग करने के लिए बनाता है"। HTTP स्टेटलेस है, तो क्या एकाधिक क्लाइंट एक ही टीसीपी कनेक्शन का उपयोग कर रहे हैं निश्चित रूप से कोई फर्क नहीं पड़ता? –
HTTP "तार्किक रूप से" स्टेटलेस है लेकिन कनेक्शन नहीं है। ज्यादातर मामलों में कनेक्शन अज्ञात है और इसमें किसी भी महत्व की स्थिति नहीं है। हालांकि प्रमाणीकरण अक्सर कनेक्शन स्तर पर किया जाता है (उदाहरण के लिए आईआईएस पर एनटीएलएम) जहां कनेक्शन स्थापित हो जाने के बाद कई अनुरोध कनेक्शन की एक ही प्रमाणित स्थिति साझा करेंगे। – AnthonyWJones
** एकाधिक अनुरोध कनेक्शन की एक ही प्रमाणीकृत स्थिति साझा करेंगे ** ** अन्य ग्राहकों के लिए एक कनेक्शन का उपयोग करने के लिए संभव नहीं है ** सर्वर एक अलग उपयोगकर्ता के लिए प्रमाणीकृत है **, मानते हैं कि एक अलग उपयोगकर्ता एक अलग प्रक्रिया है । एक कनेक्शन प्रक्रिया-विशिष्ट है और ओएस स्तर पर संरक्षित है। एक और प्रक्रिया ** ** एक ही कनेक्शन को साझा नहीं कर सकती है जिसे एक अलग प्रक्रिया के लिए प्रमाणित किया गया है। – averasko