2009-11-16 12 views
24

चूंकि HTTP एक स्टेटलेस प्रोटोकॉल है, जब कोई क्लाइंट सर्वर के लिए कई अनुरोध करता है, तो सर्वर समय-समय पर किसी विशेष ग्राहक के अनुरोधों की पहचान कैसे करता है, टी 1, टी 2, टी 3 ..HTTP सत्र ट्रैकिंग

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

उत्तर

38

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

कुकीज़ का उपयोग करते समय, सर्वर क्लाइंट को Set-Cookie HTTP प्रतिक्रिया शीर्षलेख सेट करके कुकी स्टोर करने के लिए कहता है। यह कुकी अद्वितीय सत्र आईडी है कि ग्राहक को असाइन किया गया होता है - इस उदाहरण स्ट्रिंग में 'ABAD1D':

Set-Cookie: JSESSIONID=ABAD1D;path=/ 

कुकी है तो प्रत्येक अनुरोध पर Cookie HTTP अनुरोध हेडर का उपयोग कर ग्राहक द्वारा सर्वर से वापस भेज दिया और इस प्रकार सर्वर को वर्तमान में क्लाइंट को सौंपा गया सत्र आईडी प्रत्येक अनुरोध पर सूचित किया जाता है।

Cookie: JSESSIONID=ABAD1D 

यूआरएल पुनर्लेखन का उपयोग करते समय, यह वही सत्र आईडी यूआरएल में कहीं कहीं भेजा जाता है। फिर, सर्वर इतना है कि यह एक विशेष ग्राहक के लिए सत्र देखने कर सकते हैं यूआरएल से सत्र ID निकालता है:

http://my.app.com/index.jsp;JSESSIONID=ABAD1D 

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

ध्यान दें कि सत्र समाप्त हो सकते हैं। इसका अर्थ यह है कि यदि सर्वर समय के लिए किसी दिए गए सत्र आईडी को 'नहीं' देखता है, तो यह संसाधनों को संरक्षित करने के लिए सत्र डेटा को हटा सकता है।

+0

जानकारी के लिए धन्यवाद .. :) – dexter

+2

@RickNZ SO में विश्वास खोना नहीं है - मैंने आपके उत्तर की प्रतिलिपि नहीं बनाई है। यदि आप मेरे संशोधन के माध्यम से जांचते हैं तो आप देखेंगे कि मैंने HTTP सत्रों को समझाकर शुरू किया था। मैंने फिर कुकीज़ और यूआरएल दोनों में JSESSIONID के उदाहरण स्वरूपों की जांच करने और HTTP शीर्षलेख नामों की पुष्टि करने में कुछ समय बिताया। तब मैंने इन्हें अपनी पोस्ट में जोड़ा जब मुझे विश्वास था कि वे सही थे। यह आश्चर्यजनक नहीं है कि इस तरह के प्रश्न समान उत्तर प्राप्त करेंगे लेकिन यदि आप अभी भी परेशान महसूस करते हैं तो मैं खुशी से अपना जवाब हटाने के लिए वोट दूंगा। – teabot

+1

@teabot: कोई चिंता नहीं; यह सब अच्छा है। – RickNZ

2

सत्र ट्रैकिंग एक सर्वर की ओर की बात है।

एक वेब सर्वर ब्राउज़र पर वापस आने वाले कुछ सत्र पहचानकर्ता को जारी करता है। ब्राउज़र प्रत्येक अनुरोध के साथ इस सत्र पहचानकर्ता को प्रस्तुत करता है।

यह शायद उपयोगकर्ता के लिए पारदर्शी कुकीज़ का उपयोग करके किया जाता है।

1

सत्र प्रबंधन को क्लाइंट में cookie भेजकर संभाला जाता है। उस कुकी को उस विशेष ग्राहक से प्रत्येक अनुरोध पर सर्वर पर वापस भेजा जाएगा।

session id सर्वर पक्ष (फ़ाइल, रैम स्पेस) पर कुछ संसाधनों से जुड़ा होगा, इसलिए कुकी में session id पढ़कर सर्वर इस संसाधन को ढूंढ सकता है और फिर यह पता कर सकता है कि यह कौन सा क्लाइंट था।

9

विशेष रूप से HTTP अनुरोध और प्रतिक्रिया का कौन सा हिस्सा सत्र ट्रैकिंग के लिए उपयोग किया जाएगा?

HTTP प्रतिक्रिया में, सर्वर एक कुकी सेट कर सकता है। यह सेट-कुकी हेडर के साथ ऐसा करता है। उदाहरण के लिए:

Set-Cookie: session=12345; path=/ 

ग्राहक तो सभी कुकीज़ कि गुण है कि कुकी के साथ स्थापित किया गया है, जो पथ (ऊपर के रूप में) और डोमेन शामिल कर सकते हैं, और जो अभी तक समाप्त नहीं किया है से मेल का मान देता है।

कुकी को HTTP शीर्षकों के हिस्से के रूप में सर्वर पर वापस भेजा जाता है। उदाहरण के लिए:

Cookie: session=12345 

कोई भी मूल संपत्ति जानकारी कुकी के साथ वापस नहीं भेजी जाती है।

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

+0

जो वास्तव में सहायक था। thanx .. – dexter

0

में खोजें पर्याप्त विवरण here

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

Http सत्र सत्र = request.getSession(); // वर्तमान सत्र या नया सत्र

सत्र का समय समाप्त हो सकता है (web.xml में कॉन्फ़िगर किया गया है) या मैन्युअल रूप से अमान्य।

संबंधित मुद्दे