एप्लिकेशन को स्टेटलेस कैसे रखें

Question

यह एक जटिल प्रश्न हो सकता है, लेकिन मैं स्टेटलेसनेस की बेहतर समझ प्राप्त करने की कोशिश कर रहा हूं।

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

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

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

Comments

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

— मार्क रोजर्स

@MarkRogers क्यों? स्टैब्लिशनेस का पुनर्जन्म से कोई लेना-देना नहीं है। और स्टेटलेस होने से उच्च प्रयास नहीं होता है।

— पॉल वासिल्वेस्की

@PaWWasilewski: और स्टेटलेस होने से उच्च प्रयास नहीं होता। => यह करता है, एक स्टेटफुल एप्लिकेशन के साथ आप हर चीज को सेशन से बांध कर रखते हैं। यह अच्छी तरह से पैमाने पर नहीं है, हालांकि सत्र पिनिंग के साथ काम करता है, लेकिन यह बहुत आसान है। जब सर्वर को एक-दूसरे के बीच सूचनाओं का आदान-प्रदान शुरू करना होता है, तो परेशानी शुरू हो जाती है।

— मथिउ एम।

अमेज़ॅन को देखते हुए, आप देखेंगे कि यदि आप कंप्यूटर बदलते हैं तो भी आपकी कार्ट बनी हुई है, इसलिए यह कुकी में संग्रहीत नहीं है, बल्कि डेटाबेस में है।

— njzk2

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

— डॉगमैटिस्ट

Answer 1

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

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

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

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

क्या प्रमुख वेबसाइटें (अमेज़न, गूगल, फेसबुक, ट्विटर आदि) वास्तव में स्टेटलेस हैं? क्या वे टोकन या कुकीज़ (या दोनों) का उपयोग करते हैं?

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

Comments

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

— डेरेक एल्किन्स

"[...] लेकिन फिर आपके पास सर्वर के बजाय क्लाइंट पर फिर से राज्य है।" यह बेहतर स्केलेबिलिटी और उपलब्धता को प्राप्त करने के लिए सर्वर साइड पर कोई राज्य नहीं होने के बारे में है। यदि कोई राज्य क्लाइंट साइड पर संग्रहीत है, तो कोई फर्क नहीं पड़ता।

— पॉल वासिल्वेस्की

@ njzk2 क्या आप इतना विस्तृत कर सकते हैं कि यह बेतुका नहीं लगता? उपयोगकर्ता अधिक नाम खरीदने के लिए अमेज़न पर नहीं जाते हैं। और, जब वे अपनी खरीदारी करते हैं, तो कुछ गायब हो जाता है जो खरीदारी करते समय केवल अस्तित्व में था। यदि वह चीज "एप्लिकेशन की स्थिति" नहीं है, तो वह क्या है? यदि आवेदनों में राज्य नहीं है, तो उनके पास क्या है?

@nocomprende: मुझे लगता है कि njzk2 की सामान्य जानकारी यह है कि आपके कार्ट की सामग्री, जैसे कि आपका पूरा नाम है, वह डेटा है जो एक वेबएप सर्वर की तरफ बना रहता है। जब लोग कहते हैं, "वेबैप्स स्टेटलेस होना चाहिए", तो वे आम तौर पर "वेबैप्स से अलग नहीं होना चाहिए, जो आपके उपयोगकर्ता नाम के साथ जुड़ा हुआ एक डेटाबेस तक नहीं जाना चाहिए"। ठीक है कि वे क्या करते द्वारा "स्टेटलेस" शायद तुच्छता से परिभाषित नहीं है, एक बार के बाद से आपको लगता है कि डेटाबेस है बकवास है कि तुम वहाँ में जारी रहती है सकता है, ज्यादा-जटिल एप्लिकेशन राज्य का समर्थन करने के सभी प्रकार की है, लेकिन ऐसा करना चाहिए नहीं ;-) मतलब

— स्टीव जेसप

@nocomprende: डेटाबेस को वापस लाकर एक अंडे को अनचेक करें: चूंकि हमारा वेबैप स्टेटलेस है, यह पहले की तरह फिर से शुरू हो सकता है ;-)

— स्टीव जेसप

Answer 2

यह सही है कि वेब एप्लिकेशन स्टेटलेस होना चाहिए। हालाँकि, सत्र चर, कुकीज़ और टोकन इस का उल्लंघन नहीं करते हैं जब वे क्लाइंट (वेब ​​ब्राउज़र) पर संग्रहीत होते हैं। वे अनुरोध में पैरामीटर हो सकते हैं।

यहाँ एक सरलीकृत मॉडल है:

Web Browser (has state) <-> Web Server (stateless) <-> Database (has state)

यह सॉफ्टवेयर इंजीनियरिंग स्टैक एक्सचेंज के लिए काम कर सकता है । यह उत्तर मैं टाइप कर रहा हूं जो मेरे वेब ब्राउजर की स्थिति का हिस्सा है। इसलिए जब तक यह एकमात्र ऐसा स्थान है जहां यह है, यह किसी के लिए सुलभ नहीं है, लेकिन मुझे। लेकिन जैसे ही मैंने मारा Post your Answerमेरा ब्राउज़र इसे वेब सर्वर को भेजता है। वेब सर्वर अपने स्वयं के किसी भी राज्य का उपयोग करके पोस्ट को संसाधित करता है। यह सीखता है कि मैं अपने ब्राउज़र से और डेटाबेस से कौन हूं। एक बार जब यह मेरे पोस्ट की जाँच कर लेता है, और इसे डेटाबेस में जोड़ देता है, तो वेब सर्वर तुरंत मेरे बारे में भूल जाता है।

यही स्टेटलेस का मतलब है। सर्वर इस के किसी भी याद करने के लिए ज़िम्मेदार नहीं है। वह इसका काम नहीं है।

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

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

Comments

मुझे नहीं पता ... यह जवाब कुछ कहने जैसा लगता है: " एक्सेल आपकी स्प्रेडशीट को संग्रहीत नहीं करता है, डिस्क ड्राइव करता है!" हा हा, क्या वेब सर्वर का डेटाबेस हिस्सा नहीं है, जहां तक ​​अधिकांश लोग चिंतित हैं? स्पष्ट रूप से राज्य सीपीयू या सर्वर के कोड में संग्रहीत नहीं है, और यह सब स्मृति में रखना बहुत मूर्खतापूर्ण है।

@nocomprende नहीं, डेटाबेस आमतौर पर आपके वेब सर्वर का हिस्सा नहीं होता है। हाँ, एक डेटाबेस बहुत संभव सीमा समग्र आवेदन की क्षमता में राज्य भंडारण, लेकिन अपेक्षाकृत कुछ अनुप्रयोगों कि ऑफलोड कर सकते हैं देखते हैं सभी ग्राहक पर अपने राज्य (या यहां तक कि सभी "प्रति उपयोगकर्ता" राज्य) की। डेटाबेस सर्वरों को विशेष रूप से कैंडिड ऑरेंज स्टेट्स के रूप में स्केलेबल रूप से राज्य को संभालने के लिए डिज़ाइन किया गया है, वे आमतौर पर वेब सर्वरों की तुलना में बेहतर संरक्षित, प्रोविज़न किए जाते हैं, और वीटो किए जाते हैं। आसानी से वेब सर्वरों को स्केल करने में सक्षम होने के लाभ हैं, हालांकि यह सभी स्केलेबिलिटी समस्याओं को हल नहीं करता है।

— डेरेक एल्किंस

@nocomprende: यह कहने का बिंदु कि डेटाबेस वेबसर्वर का हिस्सा नहीं है, आप 1, 2, 3, .... वेबसर्वर के लिए एक एकल डेटाबेस (या डेटाबेस क्लस्टर) रख सकते हैं। स्केलेबिलिटी बढ़ाने के लिए स्टैटिबल होने का मतलब यह है: आप डेटाबेस क्लस्टर और वेबसर्वर की संख्या को स्वतंत्र रूप से माप सकते हैं।

— Matthieu M.

"यह सही है कि वेब एप्लिकेशन स्टेटलेस होना चाहिए।" नहीं, यह पूरी बकवास है।

— svidgen

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

— कैट

Answer 3

वेब एप्लिकेशन स्टेटलेस होना चाहिए

बकवास। वेब अनुरोध स्टेटलेस होना चाहिए। या अधिक सही, वेब अनुरोध कर रहे हैं राज्यविहीन।

लेकिन, यह कहते हुए कि एक पूरा आवेदन स्टेटलेस होना चाहिए पूरी बकवास है।

प्रत्येक अनुरोध को एक स्वतंत्र लेनदेन के रूप में माना जाता है।

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

और, उन कारणों से, प्रत्येक अनुरोध जो स्टेटलेस हो सकता है, "स्टेटलेस" होना चाहिए।

नतीजतन, सत्र और कुकीज़ को टाला जाना चाहिए (जैसा कि दोनों स्टेटफुल हैं)। बेहतर तरीका यह है कि आप टोकन का उपयोग करें

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

इसका मतलब है कि कम से कम कभी-कभी , सत्र और कुकीज़ टोकन के रूप में "बेहतर" हैं!

[टोकन] स्टेटलेस हैं क्योंकि सर्वर पर कुछ भी संग्रहीत नहीं है।

हां इसी तरह। यही "स्टेटलेसनेस" हठधर्मिता है। हालांकि, स्पष्ट होने के लिए, यह सर्वर पर "कुछ भी" संग्रहीत करने के बारे में नहीं है, यह सर्वर पर सत्र स्थिति को संग्रहीत नहीं करने के बारे में है।

उदाहरण के लिए, मेरा Gmail इनबॉक्स एक स्थिति में है। और यह लानत है बेहतर सर्वर पर संग्रहीत किया जा सकता है! लेकिन, यह सत्र राज्य नहीं है।

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

अब, यदि वह अवस्था छोटी है, तो शायद ठीक है। कुछ मामलों में यह बहुत अच्छा है।

और फिर, निश्चित रूप से, ऐसी चीजें हैं जो हम उम्मीद करते हैं कि हम राज्य के ...

जब मेरे सत्र (जैसे खरीदारी कार्ट में आइटम) के लिए रखा जा रहा है, तो वेब एप्लिकेशन कैसे निष्क्रिय हो सकते हैं? क्या ये वास्तव में कहीं डेटाबेस में संग्रहीत किए जा रहे हैं और फिर समय-समय पर शुद्ध किए जा रहे हैं?

दो विकल्प। या तो आपके पास एक सत्र है, या आप इनकार कर रहे हैं!

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

वास्तविक रूप से गंभीरता के लिए: एक बड़ी डिग्री है जिसमें "राज्यसत्ता" बस वह है जिसे हम इसे कहते हैं जब दो संचार एजेंट एक वार्तालाप में संदेशों को संदर्भित कर सकते हैं। और एक सत्र, जिसे पारंपरिक रूप से समझा जाता है, बस वही है जिसे हम आमतौर पर तंत्र कहते हैं जिसके द्वारा ऐसा होता है।

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

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

शायद दोनों। लेकिन, आम तौर पर बोलते हुए, वे वास्तव में वही करते हैं जो आप करते हैं: वे बड़े पैमाने पर "सत्र" डेटाबेस में "राज्य" रिकॉर्ड की पहचान करने के लिए कुकीज़ सेट करते हैं।

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

Comments

इस बात से सहमत। यह मुझे "अपरिवर्तनीय डेटा" विचार की याद दिलाता है। यदि यह अपरिवर्तनीय है, तो इसे एक चट्टान में तराशें, ऐसा करने के लिए कंप्यूटर को बर्बाद न करें। कंप्यूटर को डेटा के साथ सामान करने दें! यही कारण है कि हम उन्हें बनाया! एप्लिकेशन डेटा के साथ काम करते हैं। डेटा जो निरंतर है बेकार है।

@nocomprende FYI करें, मैं बाद में इसके लिए एक परिशिष्ट बनाऊंगा। मुझे ओपी के अंतर्निहित प्रश्न के मेरे उत्तर के लापता हिस्से की तरह महसूस होता है। क्योंकि, वहाँ है एक कानूनी "स्टेटलेस आवेदन" विचार के पीछे चल चिंता का विषय। लेकिन, उत्तर की तर्ज पर है, जब लोग 'स्टेटलेस' कहते हैं, तो उनके कहने का मतलब 'सर्वर-साइड सत्रों पर न्यूनतम निर्भर करता है।'

— 19

@nocomprende: अपरिवर्तनीय डेटा स्ट्रक्चर्स कुछ अलग है, और मेमोरी ऑब्जेक्ट्स के जीवनचक्र को प्रबंधित करने के लिए उपयोग किया जाने वाला उपकरण है।

— whatsisname

अपने स्पष्टीकरण की पहली पंक्ति से प्यार करें। जब हम किसी चीज़ पर चर्चा करते हैं, तो प्रत्येक मौखिक बयान जो हम तुरंत करते हैं वह गुमनामी में मर जाता है। लेकिन किसी तरह, हम अभी भी एक बातचीत पर ले जाने में सक्षम हैं, एह? यह जादू है!

@nocomprende यह एक दिलचस्प चर्चा है, लेकिन मुझे लगता है कि हमें इसे यहां जारी नहीं रखना चाहिए।

— पेब्रम्स

Answer 4

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

statelessness

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

सर्वर पर स्थिति

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

ग्राहक पर राज्यवार प्रतिक्रिया

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

टोकन वी। कुकीज़

कुकीज़ क्लाइंट डिवाइस / ब्राउज़र के लिए पहचानकर्ता के रूप में कार्य करते हैं। उनका उपयोग सभी प्रकार की चीजों को स्टोर करने के लिए किया जा सकता है, लेकिन आम तौर पर वे पहचानकर्ता के कुछ रूप को स्टोर करते हैं, जैसे कि CFML / CFTOKEN CFML ऐप में। कुकीज़ को उपयोगकर्ता के ब्राउज़र में लंबे समय तक रहने के लिए सेट किया जा सकता है, जिससे ब्राउज़र सत्रों के बीच ऐप पर प्रमाणीकरण बनाए रखने जैसे काम करना संभव हो जाता है। कुकीज़ को मेमोरी में भी सेट किया जा सकता है-केवल इसलिए जब उपयोगकर्ता ब्राउज़र बंद करता है तो वे समाप्त हो जाते हैं।

टोकन आम तौर पर उस उपयोगकर्ता के बारे में जानकारी की पहचान करते हैं जो सर्वर पर उत्पन्न होते हैं (जानकारी का उपयोग करने के लिए एन्क्रिप्शन का उपयोग करते हुए), क्लाइंट को पास किया गया, और बाद के अनुरोध के साथ सर्वर पर वापस आ गया। उन्हें अनुरोध और प्रतिक्रिया के शीर्षलेख में पारित किया जा सकता है, जो एकल पृष्ठ अनुप्रयोगों में एक सामान्य पैटर्न है। आदर्श रूप से, प्रत्येक अनुरोध / प्रतिक्रिया के परिणामस्वरूप एक नया टोकन उत्पन्न होता है, इसलिए टोकन को किसी हमलावर द्वारा बाद में अवरोधन और उपयोग नहीं किया जा सकता है।

सिंगल पेज एप्स और क्लाइंट स्टेट

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

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

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

शॉपिंग कार्ट और पसंद है

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

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

क्षमा करें, यदि यह उत्तर थोड़ा सा विचलित करता है, लेकिन स्थिति एक जटिल विषय है।

Answer 5

सत्र और कुकीज़ को टाला नहीं जाना चाहिए। आप अभी भी उन्हें स्टेटलेस वेब एप्लिकेशन के साथ रख सकते हैं।

पटरियों पर जावा और रूबी के बीच एक बड़ा अंतर है। जावा ऐप्स कुकी में संग्रहीत सत्र कुंजी का उपयोग करके सत्र को मेमोरी में संग्रहीत करेगा। यह उपयोगकर्ता राज्य और शॉपिंग कार्ट को पुनः प्राप्त करने के लिए तेज़ है। हालांकि, आपको हमेशा अपने सत्र के साथ एक ही सर्वर को हिट करना होगा।

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

तो आप चालाक तकनीकों के माध्यम से, और इच्छाशक्ति को बढ़ाने की क्षमता जोड़ सकते हैं।

Answer 6

प्रोटोकॉल राज्यविहीन है।

लेकिन इससे यह जरूरी नहीं है कि प्रोटोकॉल का उपयोग करने वाले एप्लिकेशन स्टेटलेस होने चाहिए।

यहाँ संबंधित StackOverflow के कुछ जवाब दिए गए हैं जो अंतर को अच्छी तरह से समझाते हैं:

• https://stackoverflow.com/questions/34675027/stateless-web-application-an-urban-legend/34678600#34678600
• https://stackoverflow.com/questions/34675027/stateless-web-application-an-urban-legend/34677668#34677668

Answer 7

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

एक स्टेटलेस कम्युनिकेशन के कई फायदे हैं, खासकर स्केलेबिलिटी और उपलब्धता के बारे में।

टोकन का उपयोग करने के लिए एक बेहतर तरीका है, जो स्टेटलेस हैं क्योंकि सर्वर पर कुछ भी संग्रहीत नहीं है।

यह सच है (कुछ प्रमाणीकरण और प्राधिकरण प्रोटोकॉल के लिए)। किसी उपयोगकर्ता को प्रमाणित करने या किसी कार्रवाई को अधिकृत करने के लिए अनुरोध के भीतर टोकन (लेकिन प्रति नहीं) सभी जानकारी प्रदान कर सकते हैं। एक उदाहरण के लिए JWT पर एक नज़र डालें ।

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

शॉपिंग कार्ट उदाहरण के बारे में। यह एक सत्र या कुकीज़ का उपयोग किए बिना क्लाइंट साइड पर सभी कार्ट आइटम संग्रहीत करने के लिए कोई समस्या नहीं है। आप smashingmagazine.com पर एक उदाहरण पा सकते हैं । लेकिन कुकीज़ के साथ एक स्टेटलेस शॉपिंग कार्ट का एहसास करना संभव है (कम से कम यदि आपका वर्गीकरण इतना बड़ा नहीं है और 4kb स्टोरेज आपके लिए पर्याप्त है)।

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

आमतौर पर, टोकन का उपयोग कार्ट आइटम जैसी जानकारी संग्रहीत करने के लिए नहीं किया जाता है। उनका उपयोग एक सांख्यिकीय प्रमाणीकरण और प्राधिकरण के लिए किया जाता है।

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

यदि आप पूछ रहे हैं कि क्या वे प्रमाणीकरण के लिए कुकीज़ या टोकन का उपयोग कर रहे हैं, तो जवाब है कि वे दोनों का उपयोग करते हैं। उपयोगकर्ताओं के लिए ज्यादातर तकनीकी ग्राहकों के लिए कुकीज़ का उपयोग किया जाता है।

Answer 8

ठीक है, आपके द्वारा उद्धृत नियम तकनीकी रूप से गलत है। वेब एप्लिकेशन की सभी परतों में स्थिति होती है।

नियम का आशय "प्रति सत्र राज्य सर्वर पक्ष न रखना" है।

एएसपी , सत्र चर , जो आमतौर पर टोकरी / उपयोगकर्ता नाम, आदि में वस्तुओं जैसे काम करने के लिए उपयोग किया जाता था।

कारण यह है कि आप सर्वर पर मेमोरी से बाहर चले जाएंगे क्योंकि आपके एप्लिकेशन को अधिक उपयोगकर्ता प्राप्त होते हैं। स्टोरेज को डेटाबेस या शेयर्ड कैश में ले जाना समस्या को हल नहीं करता है क्योंकि आपके पास अभी भी अड़चन है।

इस समस्या को पूरा किए बिना प्रति-उपयोगकर्ता एप्लिकेशन स्थिति बनाए रखने के लिए, राज्य को क्लाइंट की ओर ले जाएं। उदाहरण के लिए, बास्केट आइटम को कुकी या अधिक उन्नत क्लाइंट-साइड स्टोरेज में रखें।

क्‍योंकि ग्राहकों की संख्‍या के साथ तराजू की तादाद, आपके आवेदन के रूप में एक अड़चन नहीं होगी और अच्‍छी तरह से मापी जाएगी।

Comments

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

— डेरेक एल्किंस

हम्म की तरह यदि आपके पास सर्वर पर प्रति उपयोगकर्ता जानकारी है, भले ही इसके वितरित आपको अभी भी एक स्केलेबिलिटी की समस्या है।

— इवान

बहुत कुछ है अगर आप डिस्क से डेटा खींच रहे हैं जैसे कि कैशिंग।

— 21 दिसंबर को जेएफओ

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

— इवान

गर्म आलू से बचने की कोशिश करने के बारे में यह सारी चर्चा वास्तव में मुझे रहस्यमय बनाती है। जो कुछ भी पुरानी कहावत है, "हिरन यहाँ रुक जाता है"? कुछ को डेटा का प्रबंधन करना है, मेरा बैंक मुझे अपने सभी वित्तीय लेनदेन की जानकारी केवल अपने लैपटॉप पर रखना पसंद नहीं करेगा। हर कोई डेटा से चिल्लाकर क्यों भाग रहा है? यही कारण है कि हमारे पास कंप्यूटर हैं! पागल।