सेशन (कंप्यूटर विज्ञान): Difference between revisions
(Created page with "{{refimprove|date=July 2014}} विशेष रूप से कंप्यूटर विज्ञान और कंप्यूटर नेटवर्क म...") |
No edit summary |
||
| Line 1: | Line 1: | ||
विशेष रूप से [[कंप्यूटर विज्ञान]] और [[कंप्यूटर नेटवर्क]] में, एक सत्र समय-सीमांकित दो-तरफा लिंक है, इंटरनेट प्रोटोकॉल सूट में व्यावहारिक (अपेक्षाकृत उच्च) परत है। टीसीपी/आईपी प्रोटोकॉल दो या दो से अधिक संचार उपकरणों के बीच इंटरैक्टिव अभिव्यक्ति और सूचना विनिमय को सक्षम करता है। या समाप्त - चाहे वे कंप्यूटर हों, [[स्वचालन]] हों, या लाइव सक्रिय उपयोगकर्ता हों ([[लॉगिन सत्र]] देखें)। एक निश्चित समय पर सत्र स्थापित किया जाता है, और फिर कुछ बाद के बिंदु पर 'टूट डाउन' - समाप्त कर दिया जाता है। स्थापित संचार सत्र में प्रत्येक दिशा में एक से अधिक संदेश शामिल हो सकते हैं। सत्र आम तौर पर [[स्टेटफुल]] होता है, जिसका अर्थ है कि कम से कम संवाद करने वाले पक्ष को वर्तमान स्थिति की जानकारी रखने और संवाद करने में सक्षम होने के लिए सत्र इतिहास के बारे में जानकारी सहेजने की आवश्यकता होती है, जैसा कि [[स्टेटलेस सर्वर]] संचार के विपरीत होता है, जहां संचार में स्वतंत्र अनुरोध-प्रतिक्रिया शामिल होती है। प्रतिक्रियाओं के साथ। | |||
विशेष रूप से [[कंप्यूटर विज्ञान]] और [[कंप्यूटर नेटवर्क]] में, एक सत्र | |||
[[कनेक्शन-उन्मुख संचार]] करने के लिए | [[कनेक्शन-उन्मुख संचार]] करने के लिए स्थापित सत्र बुनियादी आवश्यकता है। [[कनेक्शन रहित संचार]] मोड में संचारण के लिए सत्र भी बुनियादी कदम है। हालाँकि, कोई भी यूनिडायरेक्शनल ट्रांसमिशन सत्र को परिभाषित नहीं करता है।<ref>[http://www.freepatentsonline.com/5771353.html Sessionless-oriented protocol and session-oriented protocol]</ref> | ||
संचार परिवहन को अनुप्रयोग स्तर पर, सत्र स्तर पर या OSI मॉडल में परिवहन स्तर पर प्रोटोकॉल और सेवाओं के भाग के रूप में लागू किया जा सकता है। | संचार परिवहन को अनुप्रयोग स्तर पर, सत्र स्तर पर या OSI मॉडल में परिवहन स्तर पर प्रोटोकॉल और सेवाओं के भाग के रूप में लागू किया जा सकता है। | ||
* आवेदन परत उदाहरण: | * आवेदन परत उदाहरण: | ||
| Line 10: | Line 9: | ||
** एक सत्र आरंभ प्रोटोकॉल (एसआईपी) आधारित [[इंटरनेट फोन]] कॉल | ** एक सत्र आरंभ प्रोटोकॉल (एसआईपी) आधारित [[इंटरनेट फोन]] कॉल | ||
* परिवहन परत उदाहरण: | * परिवहन परत उदाहरण: | ||
** एक [[ट्रांसमिशन कंट्रोल प्रोटोकॉल]] सत्र, जो | ** एक [[ट्रांसमिशन कंट्रोल प्रोटोकॉल]] सत्र, जो टीसीपी [[वर्चूअल सर्किट]], टीसीपी कनेक्शन या एक स्थापित टीसीपी [[इंटरनेट सॉकेट]] का पर्याय है। | ||
परिवहन प्रोटोकॉल के मामले में जो औपचारिक सत्र परत (उदाहरण के लिए, उपयोगकर्ता डेटाग्राम प्रोटोकॉल) को लागू नहीं करते हैं या जहां आवेदन परत पर सत्र आम तौर पर बहुत ही कम रहते हैं (उदाहरण के लिए, HTTP), सत्र | परिवहन प्रोटोकॉल के मामले में जो औपचारिक सत्र परत (उदाहरण के लिए, उपयोगकर्ता डेटाग्राम प्रोटोकॉल) को लागू नहीं करते हैं या जहां आवेदन परत पर सत्र आम तौर पर बहुत ही कम रहते हैं (उदाहरण के लिए, HTTP), सत्र उच्च स्तरीय कार्यक्रम द्वारा बनाए रखा जाता है। एक्सचेंज किए जा रहे डेटा में परिभाषित विधि। उदाहरण के लिए, ब्राउज़र और दूरस्थ होस्ट के बीच HTTP एक्सचेंज में एक [[HTTP कुकी]] शामिल हो सकती है जो स्थिति की पहचान करती है, जैसे कि एक अद्वितीय [[सत्र आईडी]], उपयोगकर्ता की प्राथमिकताओं या प्राधिकरण स्तर के बारे में जानकारी। | ||
HTTP/1.0 को | HTTP/1.0 को वेब/HTTP सत्र के दौरान केवल एक ही अनुरोध और प्रतिक्रिया की अनुमति देने के बारे में सोचा गया था। प्रोटोकॉल संस्करण HTTP/1.1 ने [[कॉमन गेटवे इंटरफ़ेस]] (CGI) को पूरा करके इसमें सुधार किया, जिससे वेब सत्र को बनाए रखना और HTTP कुकीज़ और फ़ाइल अपलोड का समर्थन करना आसान हो गया। | ||
अधिकांश क्लाइंट-सर्वर सत्र [[ट्रांसपोर्ट परत]] द्वारा बनाए जाते हैं - एक सत्र के लिए एक कनेक्शन। हालाँकि वेब/HTTP सत्र का प्रत्येक लेन-देन चरण एक अलग कनेक्शन बनाता है। चरणों के बीच सत्र की निरंतरता बनाए रखने के लिए सत्र आईडी की आवश्यकता होती है। सत्र आईडी [[गतिशील वेब पेज]] के <A HREF> या <FORM> लिंक के भीतर एम्बेड की जाती है ताकि इसे वापस CGI को पास किया जा सके। CGI तब लेन-देन चरणों के बीच सत्र की निरंतरता सुनिश्चित करने के लिए सत्र आईडी का उपयोग करता है। | अधिकांश क्लाइंट-सर्वर सत्र [[ट्रांसपोर्ट परत]] द्वारा बनाए जाते हैं - एक सत्र के लिए एक कनेक्शन। हालाँकि वेब/HTTP सत्र का प्रत्येक लेन-देन चरण एक अलग कनेक्शन बनाता है। चरणों के बीच सत्र की निरंतरता बनाए रखने के लिए सत्र आईडी की आवश्यकता होती है। सत्र आईडी [[गतिशील वेब पेज]] के <A HREF> या <FORM> लिंक के भीतर एम्बेड की जाती है ताकि इसे वापस CGI को पास किया जा सके। CGI तब लेन-देन चरणों के बीच सत्र की निरंतरता सुनिश्चित करने के लिए सत्र आईडी का उपयोग करता है। कनेक्शन-प्रति-चरण का फायदा यह है कि यह कम बैंडविड्थ (मॉडेम) कनेक्शन पर अच्छी तरह से काम करता है। | ||
== सॉफ्टवेयर कार्यान्वयन == | == सॉफ्टवेयर कार्यान्वयन == | ||
टीसीपी सत्र आमतौर पर [[बाल प्रक्रिया]]ओं और/या थ्रेड (कंप्यूटर विज्ञान) का उपयोग करके सॉफ़्टवेयर में कार्यान्वित किए जाते हैं, जहां कंप्यूटर द्वारा सत्र स्थापित करने या उसमें शामिल होने पर | टीसीपी सत्र आमतौर पर [[बाल प्रक्रिया]]ओं और/या थ्रेड (कंप्यूटर विज्ञान) का उपयोग करके सॉफ़्टवेयर में कार्यान्वित किए जाते हैं, जहां कंप्यूटर द्वारा सत्र स्थापित करने या उसमें शामिल होने पर नई प्रक्रिया या थ्रेड बनाया जाता है। HTTP सत्र आमतौर पर प्रति सत्र थ्रेड का उपयोग करके लागू नहीं किए जाते हैं, लेकिन डेटाबेस के माध्यम से प्रत्येक सत्र की स्थिति के बारे में जानकारी होती है। कई प्रक्रियाओं या थ्रेड्स के साथ लाभ सॉफ्टवेयर की जटिल जटिलता है, क्योंकि प्रत्येक थ्रेड [[वस्तु (कंप्यूटर विज्ञान)]] है जिसका अपना इतिहास और इनकैप्सुलेटेड चर है। सिस्टम संसाधनों के मामले में नुकसान बड़ा ओवरहेड है, और यदि सिस्टम पुनरारंभ होता है तो सत्र बाधित हो सकता है। | ||
जब कोई क्लाइंट सर्वर के क्लस्टर में किसी भी सर्वर से जुड़ सकता है, तो सर्वर को सत्र स्थिति बनाए रखने के दौरान निरंतरता बनाए रखने में | जब कोई क्लाइंट सर्वर के क्लस्टर में किसी भी सर्वर से जुड़ सकता है, तो सर्वर को सत्र स्थिति बनाए रखने के दौरान निरंतरता बनाए रखने में विशेष समस्या का सामना करना पड़ता है। क्लाइंट को सत्र की अवधि के लिए या तो उसी सर्वर पर निर्देशित किया जाना चाहिए, या सर्वर को साझा फ़ाइल सिस्टम या डेटाबेस के माध्यम से सर्वर-साइड सत्र की जानकारी संचारित करनी चाहिए। अन्यथा, क्लाइंट सत्र शुरू करने वाले सर्वर से अलग सर्वर से फिर से कनेक्ट हो सकता है, जो समस्या पैदा करेगा जब नए सर्वर के पास पुराने सर्वर की संग्रहीत स्थिति तक पहुंच नहीं होगी। | ||
== सर्वर-साइड वेब सत्र == | == सर्वर-साइड वेब सत्र == | ||
| Line 27: | Line 26: | ||
सर्वर-साइड सत्र आसान और कुशल होते हैं, लेकिन लोड-बैलेंसिंग/उच्च-उपलब्धता सिस्टम के संयोजन के साथ संभालना मुश्किल हो सकता है और बिना स्टोरेज वाले कुछ एम्बेडेड सिस्टम में उपयोग करने योग्य नहीं होते हैं। लोड-बैलेंसिंग समस्या को साझा भंडारण का उपयोग करके या क्लस्टर में प्रत्येक क्लाइंट और एकल सर्वर के बीच मजबूर पीयरिंग लागू करके हल किया जा सकता है, हालांकि यह सिस्टम दक्षता और लोड वितरण से समझौता कर सकता है। | सर्वर-साइड सत्र आसान और कुशल होते हैं, लेकिन लोड-बैलेंसिंग/उच्च-उपलब्धता सिस्टम के संयोजन के साथ संभालना मुश्किल हो सकता है और बिना स्टोरेज वाले कुछ एम्बेडेड सिस्टम में उपयोग करने योग्य नहीं होते हैं। लोड-बैलेंसिंग समस्या को साझा भंडारण का उपयोग करके या क्लस्टर में प्रत्येक क्लाइंट और एकल सर्वर के बीच मजबूर पीयरिंग लागू करके हल किया जा सकता है, हालांकि यह सिस्टम दक्षता और लोड वितरण से समझौता कर सकता है। | ||
मास-स्टोरेज के बिना सिस्टम में सर्वर-साइड सत्र का उपयोग करने का | मास-स्टोरेज के बिना सिस्टम में सर्वर-साइड सत्र का उपयोग करने का तरीका सत्र डेटा के भंडारण के लिए रैम के हिस्से को आरक्षित करना है। यह विधि सीमित संख्या में ग्राहकों के साथ सर्वर के लिए लागू होती है (उदाहरण के लिए एक समय में एक से अधिक क्लाइंट के लिए दुर्लभ या अस्वीकृत पहुंच वाले राउटर या एक्सेस प्वाइंट)। | ||
== क्लाइंट-साइड वेब सत्र == | == क्लाइंट-साइड वेब सत्र == | ||
| Line 40: | Line 39: | ||
इसे पूरा करने के लिए, सर्वर को क्लाइंट को भेजने से पहले सत्र डेटा को एन्क्रिप्ट करने की आवश्यकता होती है, और किसी अन्य पार्टी द्वारा ऐसी जानकारी के संशोधन को क्रिप्टोग्राफ़िक माध्यमों से रोका जाना चाहिए। | इसे पूरा करने के लिए, सर्वर को क्लाइंट को भेजने से पहले सत्र डेटा को एन्क्रिप्ट करने की आवश्यकता होती है, और किसी अन्य पार्टी द्वारा ऐसी जानकारी के संशोधन को क्रिप्टोग्राफ़िक माध्यमों से रोका जाना चाहिए। | ||
कुकी का आकार छोटा होने पर प्रत्येक अनुरोध के साथ राज्य को आगे और आगे प्रसारित करना ही व्यावहारिक है। संक्षेप में, प्रत्येक वेब अनुरोध के लिए आवश्यक अतिरिक्त बैंडविड्थ के लिए क्लाइंट-साइड सत्र व्यापार सर्वर डिस्क स्थान। इसके अलावा, वेब ब्राउज़र कुकीज़ की संख्या और आकार को सीमित करते हैं जिन्हें | कुकी का आकार छोटा होने पर प्रत्येक अनुरोध के साथ राज्य को आगे और आगे प्रसारित करना ही व्यावहारिक है। संक्षेप में, प्रत्येक वेब अनुरोध के लिए आवश्यक अतिरिक्त बैंडविड्थ के लिए क्लाइंट-साइड सत्र व्यापार सर्वर डिस्क स्थान। इसके अलावा, वेब ब्राउज़र कुकीज़ की संख्या और आकार को सीमित करते हैं जिन्हें वेब साइट द्वारा संग्रहीत किया जा सकता है। दक्षता में सुधार करने और अधिक सत्र डेटा की अनुमति देने के लिए, सर्वर कुकी बनाने से पहले डेटा को कंप्रेस कर सकता है, बाद में जब क्लाइंट द्वारा कुकी लौटाई जाती है तो इसे डीकंप्रेस कर सकता है। | ||
== HTTP सत्र टोकन == | == HTTP सत्र टोकन == | ||
एक सत्र टोकन | एक सत्र टोकन अद्वितीय पहचानकर्ता है जो वर्तमान इंटरैक्शन सत्र की पहचान करने के लिए [[सर्वर (कंप्यूटिंग)]] से [[क्लाइंट (कंप्यूटिंग)]] को उत्पन्न और भेजा जाता है। क्लाइंट आमतौर पर HTTP कुकी के रूप में टोकन को स्टोर और भेजता है और/या इसे GET या POST प्रश्नों में पैरामीटर के रूप में भेजता है। सत्र टोकन का उपयोग करने का कारण यह है कि क्लाइंट को केवल पहचानकर्ता को संभालना होता है - सभी सत्र डेटा उस पहचानकर्ता से जुड़े सर्वर (आमतौर पर [[डेटाबेस]] में, जिसमें क्लाइंट की सीधी पहुंच नहीं होती है) पर संग्रहीत होती है। कुछ प्रोग्रामिंग भाषाएँ अपनी HTTP कुकी का नामकरण करते समय जिन नामों का उपयोग करती हैं, उनमें JSESSIONID ([[JavaServer Pages]]), [[PHP]]SESSID (PHP), CGISESSID (कॉमन गेटवे इंटरफ़ेस), और ASPSESSIONID ([[सक्रिय सर्वर पेज]]) शामिल हैं। | ||
== सत्र प्रबंधन == | == सत्र प्रबंधन == | ||
| Line 50: | Line 49: | ||
मानव-कंप्यूटर इंटरैक्शन में, सत्र प्रबंधन [[कंप्यूटर प्रणाली]] के साथ बातचीत के सत्रों में उपयोगकर्ता की गतिविधि का ट्रैक रखने की प्रक्रिया है। | मानव-कंप्यूटर इंटरैक्शन में, सत्र प्रबंधन [[कंप्यूटर प्रणाली]] के साथ बातचीत के सत्रों में उपयोगकर्ता की गतिविधि का ट्रैक रखने की प्रक्रिया है। | ||
[[डेस्कटॉप वातावरण]] में विशिष्ट सत्र प्रबंधन कार्यों में यह ट्रैक रखना शामिल है कि कौन से एप्लिकेशन खुले हैं और प्रत्येक एप्लिकेशन ने कौन से दस्तावेज़ खोले हैं, ताकि उपयोगकर्ता द्वारा लॉग आउट करने और बाद में लॉग इन करने पर उसी स्थिति को पुनर्स्थापित किया जा सके। किसी वेबसाइट के लिए, | [[डेस्कटॉप वातावरण]] में विशिष्ट सत्र प्रबंधन कार्यों में यह ट्रैक रखना शामिल है कि कौन से एप्लिकेशन खुले हैं और प्रत्येक एप्लिकेशन ने कौन से दस्तावेज़ खोले हैं, ताकि उपयोगकर्ता द्वारा लॉग आउट करने और बाद में लॉग इन करने पर उसी स्थिति को पुनर्स्थापित किया जा सके। किसी वेबसाइट के लिए, ss | ||
=== डेस्कटॉप सत्र प्रबंधन === | === डेस्कटॉप सत्र प्रबंधन === | ||
डेस्कटॉप सेशन मैनेजर एक प्रोग्राम है जो डेस्कटॉप सेशन को सेव और रीस्टोर कर सकता है। | डेस्कटॉप सेशन मैनेजर एक प्रोग्राम है जो डेस्कटॉप सेशन को सेव और रीस्टोर कर सकता है। डेस्कटॉप सत्र वर्तमान में चल रही सभी विंडो और उनकी वर्तमान सामग्री है। [[Linux]]-आधारित सिस्टम पर सत्र प्रबंधन X सत्र प्रबंधक द्वारा प्रदान किया जाता है। [[Microsoft Windows]] सिस्टम पर, सत्र प्रबंधक सबसिस्टम (smss.exe) द्वारा सत्र प्रबंधन प्रदान किया जाता है; उपयोगकर्ता सत्र की कार्यक्षमता को थर्ड-पार्टी एप्लिकेशन जैसे कि [[जुड़वाँ खेल]] द्वारा बढ़ाया जा सकता है। | ||
=== ब्राउज़र सत्र प्रबंधन === | === ब्राउज़र सत्र प्रबंधन === | ||
सत्र प्रबंधन | सत्र प्रबंधन [[वेब ब्राउज़र]] में विशेष रूप से उपयोगी है जहां उपयोगकर्ता सभी खुले पृष्ठों और सेटिंग्स को सहेज सकता है और उन्हें बाद की तारीख में या किसी भिन्न कंप्यूटर पर पुनर्स्थापित कर सकता है ([[डेटा पोर्टेबिलिटी]] देखें)। | ||
सिस्टम या एप्लिकेशन क्रैश से पुनर्प्राप्त करने में सहायता के लिए, पृष्ठ और सेटिंग्स को अगले रन पर भी पुनर्स्थापित किया जा सकता है। Google क्रोम, [[मोज़िला फ़ायरफ़ॉक्स]], [[इंटरनेट एक्स्प्लोरर]], [[ओमनीव]]ेब और [[ओपेरा (वेब ब्राउज़र)]] वेब ब्राउज़र के उदाहरण हैं जो सत्र प्रबंधन का समर्थन करते हैं। सत्र प्रबंधन को अक्सर HTTP कुकी के अनुप्रयोग के माध्यम से प्रबंधित किया जाता है। | सिस्टम या एप्लिकेशन क्रैश से पुनर्प्राप्त करने में सहायता के लिए, पृष्ठ और सेटिंग्स को अगले रन पर भी पुनर्स्थापित किया जा सकता है। Google क्रोम, [[मोज़िला फ़ायरफ़ॉक्स]], [[इंटरनेट एक्स्प्लोरर]], [[ओमनीव]]ेब और [[ओपेरा (वेब ब्राउज़र)]] वेब ब्राउज़र के उदाहरण हैं जो सत्र प्रबंधन का समर्थन करते हैं। सत्र प्रबंधन को अक्सर HTTP कुकी के अनुप्रयोग के माध्यम से प्रबंधित किया जाता है। | ||
| Line 64: | Line 63: | ||
=== वेब सर्वर सत्र प्रबंधन === | === वेब सर्वर सत्र प्रबंधन === | ||
[[हाइपरटेक्स्ट परहस्त शिष्टाचार]] (HTTP) स्टेटलेस है। सत्र प्रबंधन वेब डेवलपर द्वारा स्टेटलेस HTTP प्रोटोकॉल सपोर्ट सेशन स्टेट बनाने के लिए उपयोग की जाने वाली तकनीक है। उदाहरण के लिए, | [[हाइपरटेक्स्ट परहस्त शिष्टाचार]] (HTTP) स्टेटलेस है। सत्र प्रबंधन वेब डेवलपर द्वारा स्टेटलेस HTTP प्रोटोकॉल सपोर्ट सेशन स्टेट बनाने के लिए उपयोग की जाने वाली तकनीक है। उदाहरण के लिए, उपयोगकर्ता को वेब सर्वर पर प्रमाणित कर दिए जाने के बाद, उपयोगकर्ता का अगला HTTP अनुरोध (GET या POST) वेब सर्वर को उपयोगकर्ता के खाते और पासवर्ड के लिए फिर से पूछने का कारण नहीं बनना चाहिए। इसे पूरा करने के लिए उपयोग की जाने वाली विधियों की चर्चा के लिए HTTP कुकी और सत्र आईडी देखें | ||
ऐसी स्थितियों में जहां कई वेब सर्वरों को सत्र स्थिति का ज्ञान साझा करना चाहिए (जैसा कि [[कंप्यूटर क्लस्टर]] वातावरण में सामान्य है) वेब सर्वर सॉफ़्टवेयर चलाने वाले क्लस्टर नोड्स के बीच सत्र जानकारी साझा की जानी चाहिए। क्लस्टर में नोड्स के बीच सत्र स्थिति साझा करने के तरीकों में शामिल हैं: सदस्य नोड्स को मल्टीकास्टिंग सत्र जानकारी (इस तकनीक के | ऐसी स्थितियों में जहां कई वेब सर्वरों को सत्र स्थिति का ज्ञान साझा करना चाहिए (जैसा कि [[कंप्यूटर क्लस्टर]] वातावरण में सामान्य है) वेब सर्वर सॉफ़्टवेयर चलाने वाले क्लस्टर नोड्स के बीच सत्र जानकारी साझा की जानी चाहिए। क्लस्टर में नोड्स के बीच सत्र स्थिति साझा करने के तरीकों में शामिल हैं: सदस्य नोड्स को मल्टीकास्टिंग सत्र जानकारी (इस तकनीक के उदाहरण के लिए [[JGroups]] देखें), वितरित साझा मेमोरी या [[मेमोरी वर्चुअलाइजेशन]] का उपयोग करके पार्टनर नोड के साथ सत्र जानकारी साझा करना, नोड्स के बीच सत्र जानकारी साझा करना नेटवर्क सॉकेट, साझा फ़ाइल सिस्टम पर सत्र जानकारी संग्रहीत करना जैसे [[वितरित फ़ाइल सिस्टम]] या वैश्विक फ़ाइल सिस्टम, या डेटाबेस में क्लस्टर के बाहर सत्र जानकारी संग्रहीत करना। | ||
यदि सत्र की जानकारी को क्षणिक, अस्थिर डेटा माना जाता है जो लेन-देन की गैर-अस्वीकृति के लिए आवश्यक नहीं है और इसमें डेटा शामिल नहीं है जो अनुपालन ऑडिटिंग के अधीन है (उदाहरण के लिए यू.एस. में, [[स्वास्थ्य बीमा सुवाह्यता और जवाबदेही अधिनियम]] और सरबनेस-ऑक्सले देखें दो कानूनों के उदाहरण के लिए अधिनियम जो अनुपालन ऑडिटिंग की आवश्यकता होती है) तो सत्र की जानकारी संग्रहीत करने की किसी भी विधि का उपयोग किया जा सकता है। हालाँकि, यदि सत्र की जानकारी ऑडिट अनुपालन के अधीन है, तो सत्र भंडारण, प्रतिकृति और क्लस्टरिंग के लिए उपयोग की जाने वाली विधि पर विचार किया जाना चाहिए। | यदि सत्र की जानकारी को क्षणिक, अस्थिर डेटा माना जाता है जो लेन-देन की गैर-अस्वीकृति के लिए आवश्यक नहीं है और इसमें डेटा शामिल नहीं है जो अनुपालन ऑडिटिंग के अधीन है (उदाहरण के लिए यू.एस. में, [[स्वास्थ्य बीमा सुवाह्यता और जवाबदेही अधिनियम]] और सरबनेस-ऑक्सले देखें दो कानूनों के उदाहरण के लिए अधिनियम जो अनुपालन ऑडिटिंग की आवश्यकता होती है) तो सत्र की जानकारी संग्रहीत करने की किसी भी विधि का उपयोग किया जा सकता है। हालाँकि, यदि सत्र की जानकारी ऑडिट अनुपालन के अधीन है, तो सत्र भंडारण, प्रतिकृति और क्लस्टरिंग के लिए उपयोग की जाने वाली विधि पर विचार किया जाना चाहिए। | ||
| Line 74: | Line 73: | ||
=== [[एसएमएस]] === पर सत्र प्रबंधन | === [[एसएमएस]] === पर सत्र प्रबंधन | ||
जैसे HTTP | जैसे HTTP [[स्टेटलेस प्रोटोकॉल]] है, वैसे ही एसएमएस भी है। जैसे ही 1999 में प्रतिद्वंद्वी नेटवर्कों पर एसएमएस इंटरऑपरेबल हो गया,<ref>{{citation |publisher=CTIA |title=InterCarrier Messaging Guidelines |url=http://files.ctia.org/pdf/Inter-Carrier_SMS_Guidelines_V3.1_As_Adopted_May_2012-final.pdf |access-date=2018-06-02}}</ref> और टेक्स्ट मैसेजिंग ने संचार का सर्वव्यापी वैश्विक रूप बनने की दिशा में अपनी शुरुआत की,<ref>Hppy bthdy txt! BBC News World Edition, http://news.bbc.co.uk/2/hi/uk_news/2538083.stm 3 December 2002.</ref> विभिन्न उद्यम व्यावसायिक उद्देश्यों के लिए एसएमएस चैनल का उपयोग करने में रुचि रखते हैं। प्रारंभिक सेवाओं के लिए सत्र प्रबंधन की आवश्यकता नहीं थी क्योंकि वे केवल एकतरफा संचार थे (उदाहरण के लिए, 2000 में, मोबाइल फोन#फीचर्स)। आज, इन अनुप्रयोगों को संक्षिप्त संदेश सेवा#एप्लीकेशन-टू-पर्सन (A2P) SMS|एप्लीकेशन-टू-पीयर (A2P) संदेश के रूप में संदर्भित किया जाता है, जो [[लघु संदेश पीयर-टू-पीयर]]|पीयर-टू-पीयर (P2P) से अलग है। संदेश। इंटरैक्टिव उद्यम अनुप्रयोगों के विकास के लिए सत्र प्रबंधन की आवश्यकता होती है, लेकिन क्योंकि एसएमएस जीएसएम मानकों द्वारा परिभाषित स्टेटलेस प्रोटोकॉल है,<ref>GSM Doc 28/85 "Services and Facilities to be provided in the GSM System" rev2, June 1985</ref> आरंभिक कार्यान्वयनों को अंत-उपयोगकर्ताओं द्वारा आदेश और सेवा पहचानकर्ताओं को मैन्युअल रूप से दर्ज करने के द्वारा [[ग्राहक की ओर]] नियंत्रित किया गया था। | ||
== यह भी देखें == | == यह भी देखें == | ||
Revision as of 19:24, 31 January 2023
विशेष रूप से कंप्यूटर विज्ञान और कंप्यूटर नेटवर्क में, एक सत्र समय-सीमांकित दो-तरफा लिंक है, इंटरनेट प्रोटोकॉल सूट में व्यावहारिक (अपेक्षाकृत उच्च) परत है। टीसीपी/आईपी प्रोटोकॉल दो या दो से अधिक संचार उपकरणों के बीच इंटरैक्टिव अभिव्यक्ति और सूचना विनिमय को सक्षम करता है। या समाप्त - चाहे वे कंप्यूटर हों, स्वचालन हों, या लाइव सक्रिय उपयोगकर्ता हों (लॉगिन सत्र देखें)। एक निश्चित समय पर सत्र स्थापित किया जाता है, और फिर कुछ बाद के बिंदु पर 'टूट डाउन' - समाप्त कर दिया जाता है। स्थापित संचार सत्र में प्रत्येक दिशा में एक से अधिक संदेश शामिल हो सकते हैं। सत्र आम तौर पर स्टेटफुल होता है, जिसका अर्थ है कि कम से कम संवाद करने वाले पक्ष को वर्तमान स्थिति की जानकारी रखने और संवाद करने में सक्षम होने के लिए सत्र इतिहास के बारे में जानकारी सहेजने की आवश्यकता होती है, जैसा कि स्टेटलेस सर्वर संचार के विपरीत होता है, जहां संचार में स्वतंत्र अनुरोध-प्रतिक्रिया शामिल होती है। प्रतिक्रियाओं के साथ।
कनेक्शन-उन्मुख संचार करने के लिए स्थापित सत्र बुनियादी आवश्यकता है। कनेक्शन रहित संचार मोड में संचारण के लिए सत्र भी बुनियादी कदम है। हालाँकि, कोई भी यूनिडायरेक्शनल ट्रांसमिशन सत्र को परिभाषित नहीं करता है।[1] संचार परिवहन को अनुप्रयोग स्तर पर, सत्र स्तर पर या OSI मॉडल में परिवहन स्तर पर प्रोटोकॉल और सेवाओं के भाग के रूप में लागू किया जा सकता है।
- आवेदन परत उदाहरण:
- HTTP#HTTP सत्र, जो व्यक्तिगत आगंतुकों के साथ जानकारी को संबद्ध करने की अनुमति देता है
- एक टेलनेट दूरस्थ लॉगिन सत्र
- सत्र परत उदाहरण:
- एक सत्र आरंभ प्रोटोकॉल (एसआईपी) आधारित इंटरनेट फोन कॉल
- परिवहन परत उदाहरण:
- एक ट्रांसमिशन कंट्रोल प्रोटोकॉल सत्र, जो टीसीपी वर्चूअल सर्किट, टीसीपी कनेक्शन या एक स्थापित टीसीपी इंटरनेट सॉकेट का पर्याय है।
परिवहन प्रोटोकॉल के मामले में जो औपचारिक सत्र परत (उदाहरण के लिए, उपयोगकर्ता डेटाग्राम प्रोटोकॉल) को लागू नहीं करते हैं या जहां आवेदन परत पर सत्र आम तौर पर बहुत ही कम रहते हैं (उदाहरण के लिए, HTTP), सत्र उच्च स्तरीय कार्यक्रम द्वारा बनाए रखा जाता है। एक्सचेंज किए जा रहे डेटा में परिभाषित विधि। उदाहरण के लिए, ब्राउज़र और दूरस्थ होस्ट के बीच HTTP एक्सचेंज में एक HTTP कुकी शामिल हो सकती है जो स्थिति की पहचान करती है, जैसे कि एक अद्वितीय सत्र आईडी, उपयोगकर्ता की प्राथमिकताओं या प्राधिकरण स्तर के बारे में जानकारी।
HTTP/1.0 को वेब/HTTP सत्र के दौरान केवल एक ही अनुरोध और प्रतिक्रिया की अनुमति देने के बारे में सोचा गया था। प्रोटोकॉल संस्करण HTTP/1.1 ने कॉमन गेटवे इंटरफ़ेस (CGI) को पूरा करके इसमें सुधार किया, जिससे वेब सत्र को बनाए रखना और HTTP कुकीज़ और फ़ाइल अपलोड का समर्थन करना आसान हो गया।
अधिकांश क्लाइंट-सर्वर सत्र ट्रांसपोर्ट परत द्वारा बनाए जाते हैं - एक सत्र के लिए एक कनेक्शन। हालाँकि वेब/HTTP सत्र का प्रत्येक लेन-देन चरण एक अलग कनेक्शन बनाता है। चरणों के बीच सत्र की निरंतरता बनाए रखने के लिए सत्र आईडी की आवश्यकता होती है। सत्र आईडी गतिशील वेब पेज के <A HREF> या <FORM> लिंक के भीतर एम्बेड की जाती है ताकि इसे वापस CGI को पास किया जा सके। CGI तब लेन-देन चरणों के बीच सत्र की निरंतरता सुनिश्चित करने के लिए सत्र आईडी का उपयोग करता है। कनेक्शन-प्रति-चरण का फायदा यह है कि यह कम बैंडविड्थ (मॉडेम) कनेक्शन पर अच्छी तरह से काम करता है।
सॉफ्टवेयर कार्यान्वयन
टीसीपी सत्र आमतौर पर बाल प्रक्रियाओं और/या थ्रेड (कंप्यूटर विज्ञान) का उपयोग करके सॉफ़्टवेयर में कार्यान्वित किए जाते हैं, जहां कंप्यूटर द्वारा सत्र स्थापित करने या उसमें शामिल होने पर नई प्रक्रिया या थ्रेड बनाया जाता है। HTTP सत्र आमतौर पर प्रति सत्र थ्रेड का उपयोग करके लागू नहीं किए जाते हैं, लेकिन डेटाबेस के माध्यम से प्रत्येक सत्र की स्थिति के बारे में जानकारी होती है। कई प्रक्रियाओं या थ्रेड्स के साथ लाभ सॉफ्टवेयर की जटिल जटिलता है, क्योंकि प्रत्येक थ्रेड वस्तु (कंप्यूटर विज्ञान) है जिसका अपना इतिहास और इनकैप्सुलेटेड चर है। सिस्टम संसाधनों के मामले में नुकसान बड़ा ओवरहेड है, और यदि सिस्टम पुनरारंभ होता है तो सत्र बाधित हो सकता है।
जब कोई क्लाइंट सर्वर के क्लस्टर में किसी भी सर्वर से जुड़ सकता है, तो सर्वर को सत्र स्थिति बनाए रखने के दौरान निरंतरता बनाए रखने में विशेष समस्या का सामना करना पड़ता है। क्लाइंट को सत्र की अवधि के लिए या तो उसी सर्वर पर निर्देशित किया जाना चाहिए, या सर्वर को साझा फ़ाइल सिस्टम या डेटाबेस के माध्यम से सर्वर-साइड सत्र की जानकारी संचारित करनी चाहिए। अन्यथा, क्लाइंट सत्र शुरू करने वाले सर्वर से अलग सर्वर से फिर से कनेक्ट हो सकता है, जो समस्या पैदा करेगा जब नए सर्वर के पास पुराने सर्वर की संग्रहीत स्थिति तक पहुंच नहीं होगी।
सर्वर-साइड वेब सत्र
सर्वर-साइड सत्र आसान और कुशल होते हैं, लेकिन लोड-बैलेंसिंग/उच्च-उपलब्धता सिस्टम के संयोजन के साथ संभालना मुश्किल हो सकता है और बिना स्टोरेज वाले कुछ एम्बेडेड सिस्टम में उपयोग करने योग्य नहीं होते हैं। लोड-बैलेंसिंग समस्या को साझा भंडारण का उपयोग करके या क्लस्टर में प्रत्येक क्लाइंट और एकल सर्वर के बीच मजबूर पीयरिंग लागू करके हल किया जा सकता है, हालांकि यह सिस्टम दक्षता और लोड वितरण से समझौता कर सकता है।
मास-स्टोरेज के बिना सिस्टम में सर्वर-साइड सत्र का उपयोग करने का तरीका सत्र डेटा के भंडारण के लिए रैम के हिस्से को आरक्षित करना है। यह विधि सीमित संख्या में ग्राहकों के साथ सर्वर के लिए लागू होती है (उदाहरण के लिए एक समय में एक से अधिक क्लाइंट के लिए दुर्लभ या अस्वीकृत पहुंच वाले राउटर या एक्सेस प्वाइंट)।
क्लाइंट-साइड वेब सत्र
क्लाइंट-साइड सत्र HTTP_cookie और क्रिप्टोग्राफ़िक तकनीकों का उपयोग सर्वर पर अधिक डेटा संग्रहीत किए बिना स्थिति को बनाए रखने के लिए करते हैं। डायनेमिक वेब पेज प्रस्तुत करते समय, सर्वर कुकी के रूप में क्लाइंट (वेब ब्राउज़र) को वर्तमान स्थिति डेटा भेजता है। क्लाइंट कुकी को स्मृति या डिस्क पर सहेजता है। प्रत्येक क्रमिक अनुरोध के साथ, क्लाइंट कुकी को सर्वर पर वापस भेजता है, और सर्वर उस विशिष्ट क्लाइंट के लिए एप्लिकेशन की स्थिति को याद रखने और उचित प्रतिक्रिया उत्पन्न करने के लिए डेटा का उपयोग करता है।
यह तंत्र कुछ संदर्भों में अच्छा काम कर सकता है; हालाँकि, क्लाइंट पर संग्रहीत डेटा उपयोगकर्ता या सॉफ़्टवेयर द्वारा छेड़छाड़ करने के लिए असुरक्षित है जिसकी क्लाइंट कंप्यूटर तक पहुँच है। क्लाइंट-साइड सत्रों का उपयोग करने के लिए जहां गोपनीयता और अखंडता की आवश्यकता होती है, निम्नलिखित की गारंटी होनी चाहिए:
- गोपनीयता: सर्वर के अलावा कुछ भी सत्र डेटा की व्याख्या करने में सक्षम नहीं होना चाहिए।
- डेटा अखंडता: सर्वर के अलावा कुछ भी सत्र डेटा (गलती से या दुर्भावनापूर्ण रूप से) में हेरफेर नहीं करना चाहिए।
- प्रामाणिकता: सर्वर के अलावा कुछ भी वैध सत्र आरंभ करने में सक्षम नहीं होना चाहिए।
इसे पूरा करने के लिए, सर्वर को क्लाइंट को भेजने से पहले सत्र डेटा को एन्क्रिप्ट करने की आवश्यकता होती है, और किसी अन्य पार्टी द्वारा ऐसी जानकारी के संशोधन को क्रिप्टोग्राफ़िक माध्यमों से रोका जाना चाहिए।
कुकी का आकार छोटा होने पर प्रत्येक अनुरोध के साथ राज्य को आगे और आगे प्रसारित करना ही व्यावहारिक है। संक्षेप में, प्रत्येक वेब अनुरोध के लिए आवश्यक अतिरिक्त बैंडविड्थ के लिए क्लाइंट-साइड सत्र व्यापार सर्वर डिस्क स्थान। इसके अलावा, वेब ब्राउज़र कुकीज़ की संख्या और आकार को सीमित करते हैं जिन्हें वेब साइट द्वारा संग्रहीत किया जा सकता है। दक्षता में सुधार करने और अधिक सत्र डेटा की अनुमति देने के लिए, सर्वर कुकी बनाने से पहले डेटा को कंप्रेस कर सकता है, बाद में जब क्लाइंट द्वारा कुकी लौटाई जाती है तो इसे डीकंप्रेस कर सकता है।
HTTP सत्र टोकन
एक सत्र टोकन अद्वितीय पहचानकर्ता है जो वर्तमान इंटरैक्शन सत्र की पहचान करने के लिए सर्वर (कंप्यूटिंग) से क्लाइंट (कंप्यूटिंग) को उत्पन्न और भेजा जाता है। क्लाइंट आमतौर पर HTTP कुकी के रूप में टोकन को स्टोर और भेजता है और/या इसे GET या POST प्रश्नों में पैरामीटर के रूप में भेजता है। सत्र टोकन का उपयोग करने का कारण यह है कि क्लाइंट को केवल पहचानकर्ता को संभालना होता है - सभी सत्र डेटा उस पहचानकर्ता से जुड़े सर्वर (आमतौर पर डेटाबेस में, जिसमें क्लाइंट की सीधी पहुंच नहीं होती है) पर संग्रहीत होती है। कुछ प्रोग्रामिंग भाषाएँ अपनी HTTP कुकी का नामकरण करते समय जिन नामों का उपयोग करती हैं, उनमें JSESSIONID (JavaServer Pages), PHPSESSID (PHP), CGISESSID (कॉमन गेटवे इंटरफ़ेस), और ASPSESSIONID (सक्रिय सर्वर पेज) शामिल हैं।
सत्र प्रबंधन
मानव-कंप्यूटर इंटरैक्शन में, सत्र प्रबंधन कंप्यूटर प्रणाली के साथ बातचीत के सत्रों में उपयोगकर्ता की गतिविधि का ट्रैक रखने की प्रक्रिया है।
डेस्कटॉप वातावरण में विशिष्ट सत्र प्रबंधन कार्यों में यह ट्रैक रखना शामिल है कि कौन से एप्लिकेशन खुले हैं और प्रत्येक एप्लिकेशन ने कौन से दस्तावेज़ खोले हैं, ताकि उपयोगकर्ता द्वारा लॉग आउट करने और बाद में लॉग इन करने पर उसी स्थिति को पुनर्स्थापित किया जा सके। किसी वेबसाइट के लिए, ss
डेस्कटॉप सत्र प्रबंधन
डेस्कटॉप सेशन मैनेजर एक प्रोग्राम है जो डेस्कटॉप सेशन को सेव और रीस्टोर कर सकता है। डेस्कटॉप सत्र वर्तमान में चल रही सभी विंडो और उनकी वर्तमान सामग्री है। Linux-आधारित सिस्टम पर सत्र प्रबंधन X सत्र प्रबंधक द्वारा प्रदान किया जाता है। Microsoft Windows सिस्टम पर, सत्र प्रबंधक सबसिस्टम (smss.exe) द्वारा सत्र प्रबंधन प्रदान किया जाता है; उपयोगकर्ता सत्र की कार्यक्षमता को थर्ड-पार्टी एप्लिकेशन जैसे कि जुड़वाँ खेल द्वारा बढ़ाया जा सकता है।
ब्राउज़र सत्र प्रबंधन
सत्र प्रबंधन वेब ब्राउज़र में विशेष रूप से उपयोगी है जहां उपयोगकर्ता सभी खुले पृष्ठों और सेटिंग्स को सहेज सकता है और उन्हें बाद की तारीख में या किसी भिन्न कंप्यूटर पर पुनर्स्थापित कर सकता है (डेटा पोर्टेबिलिटी देखें)।
सिस्टम या एप्लिकेशन क्रैश से पुनर्प्राप्त करने में सहायता के लिए, पृष्ठ और सेटिंग्स को अगले रन पर भी पुनर्स्थापित किया जा सकता है। Google क्रोम, मोज़िला फ़ायरफ़ॉक्स, इंटरनेट एक्स्प्लोरर, ओमनीवेब और ओपेरा (वेब ब्राउज़र) वेब ब्राउज़र के उदाहरण हैं जो सत्र प्रबंधन का समर्थन करते हैं। सत्र प्रबंधन को अक्सर HTTP कुकी के अनुप्रयोग के माध्यम से प्रबंधित किया जाता है।
वेब सर्वर सत्र प्रबंधन
हाइपरटेक्स्ट परहस्त शिष्टाचार (HTTP) स्टेटलेस है। सत्र प्रबंधन वेब डेवलपर द्वारा स्टेटलेस HTTP प्रोटोकॉल सपोर्ट सेशन स्टेट बनाने के लिए उपयोग की जाने वाली तकनीक है। उदाहरण के लिए, उपयोगकर्ता को वेब सर्वर पर प्रमाणित कर दिए जाने के बाद, उपयोगकर्ता का अगला HTTP अनुरोध (GET या POST) वेब सर्वर को उपयोगकर्ता के खाते और पासवर्ड के लिए फिर से पूछने का कारण नहीं बनना चाहिए। इसे पूरा करने के लिए उपयोग की जाने वाली विधियों की चर्चा के लिए HTTP कुकी और सत्र आईडी देखें
ऐसी स्थितियों में जहां कई वेब सर्वरों को सत्र स्थिति का ज्ञान साझा करना चाहिए (जैसा कि कंप्यूटर क्लस्टर वातावरण में सामान्य है) वेब सर्वर सॉफ़्टवेयर चलाने वाले क्लस्टर नोड्स के बीच सत्र जानकारी साझा की जानी चाहिए। क्लस्टर में नोड्स के बीच सत्र स्थिति साझा करने के तरीकों में शामिल हैं: सदस्य नोड्स को मल्टीकास्टिंग सत्र जानकारी (इस तकनीक के उदाहरण के लिए JGroups देखें), वितरित साझा मेमोरी या मेमोरी वर्चुअलाइजेशन का उपयोग करके पार्टनर नोड के साथ सत्र जानकारी साझा करना, नोड्स के बीच सत्र जानकारी साझा करना नेटवर्क सॉकेट, साझा फ़ाइल सिस्टम पर सत्र जानकारी संग्रहीत करना जैसे वितरित फ़ाइल सिस्टम या वैश्विक फ़ाइल सिस्टम, या डेटाबेस में क्लस्टर के बाहर सत्र जानकारी संग्रहीत करना।
यदि सत्र की जानकारी को क्षणिक, अस्थिर डेटा माना जाता है जो लेन-देन की गैर-अस्वीकृति के लिए आवश्यक नहीं है और इसमें डेटा शामिल नहीं है जो अनुपालन ऑडिटिंग के अधीन है (उदाहरण के लिए यू.एस. में, स्वास्थ्य बीमा सुवाह्यता और जवाबदेही अधिनियम और सरबनेस-ऑक्सले देखें दो कानूनों के उदाहरण के लिए अधिनियम जो अनुपालन ऑडिटिंग की आवश्यकता होती है) तो सत्र की जानकारी संग्रहीत करने की किसी भी विधि का उपयोग किया जा सकता है। हालाँकि, यदि सत्र की जानकारी ऑडिट अनुपालन के अधीन है, तो सत्र भंडारण, प्रतिकृति और क्लस्टरिंग के लिए उपयोग की जाने वाली विधि पर विचार किया जाना चाहिए।
सेवा-उन्मुख आर्किटेक्चर में, एक्सटेंसिबल मार्कअप लैंग्वेज (XML) संदेशों के साथ निर्मित सिंपल ऑब्जेक्ट एक्सेस प्रोटोकॉल या SOAP संदेशों का उपयोग उपभोक्ता अनुप्रयोगों द्वारा वेब सर्वरों को सत्र बनाने के लिए किया जा सकता है।
=== एसएमएस === पर सत्र प्रबंधन
जैसे HTTP स्टेटलेस प्रोटोकॉल है, वैसे ही एसएमएस भी है। जैसे ही 1999 में प्रतिद्वंद्वी नेटवर्कों पर एसएमएस इंटरऑपरेबल हो गया,[2] और टेक्स्ट मैसेजिंग ने संचार का सर्वव्यापी वैश्विक रूप बनने की दिशा में अपनी शुरुआत की,[3] विभिन्न उद्यम व्यावसायिक उद्देश्यों के लिए एसएमएस चैनल का उपयोग करने में रुचि रखते हैं। प्रारंभिक सेवाओं के लिए सत्र प्रबंधन की आवश्यकता नहीं थी क्योंकि वे केवल एकतरफा संचार थे (उदाहरण के लिए, 2000 में, मोबाइल फोन#फीचर्स)। आज, इन अनुप्रयोगों को संक्षिप्त संदेश सेवा#एप्लीकेशन-टू-पर्सन (A2P) SMS|एप्लीकेशन-टू-पीयर (A2P) संदेश के रूप में संदर्भित किया जाता है, जो लघु संदेश पीयर-टू-पीयर|पीयर-टू-पीयर (P2P) से अलग है। संदेश। इंटरैक्टिव उद्यम अनुप्रयोगों के विकास के लिए सत्र प्रबंधन की आवश्यकता होती है, लेकिन क्योंकि एसएमएस जीएसएम मानकों द्वारा परिभाषित स्टेटलेस प्रोटोकॉल है,[4] आरंभिक कार्यान्वयनों को अंत-उपयोगकर्ताओं द्वारा आदेश और सेवा पहचानकर्ताओं को मैन्युअल रूप से दर्ज करने के द्वारा ग्राहक की ओर नियंत्रित किया गया था।
यह भी देखें
- HTTPS के
- आराम
- सत्र आईडी
- सत्रीकरण
- सत्र निर्धारण
- सत्र विषाक्तता
संदर्भ
- ↑ Sessionless-oriented protocol and session-oriented protocol
- ↑ InterCarrier Messaging Guidelines (PDF), CTIA, retrieved 2018-06-02
- ↑ Hppy bthdy txt! BBC News World Edition, http://news.bbc.co.uk/2/hi/uk_news/2538083.stm 3 December 2002.
- ↑ GSM Doc 28/85 "Services and Facilities to be provided in the GSM System" rev2, June 1985
