ऐसा क्यों कहा जाता है कि "HTTP एक स्टेटलेस प्रोटोकॉल है"?


170

HTTP में HTTP Cookies है। कुकीज़ सर्वर को उपयोगकर्ता की स्थिति, कनेक्शन की संख्या, अंतिम कनेक्शन आदि को ट्रैक करने की अनुमति देती है।

HTTP में लगातार कनेक्शन (Keep-Alive) हैं जहां एक ही TCP कनेक्शन से कई अनुरोध भेजे जा सकते हैं।


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

1
क्या मुझे अब HTTP / 1.1 जोड़ना चाहिए? क्योंकि मुझे लगता है कि HTTP / 2 में स्थिति है।
जोस नोबेल

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

जवाबों:


130

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

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


1
जब सर्वर एक सत्र (सर्वर-साइड) को याद करता है और उसके अनुसार उपयोगकर्ता अनुभव को अनुकूलित करता है तो क्या होता है?
नूरशोमिक

3
@NurShomik: सत्र आमतौर पर कैसे काम करते हैं, इसकी व्याख्या के लिए stackoverflow.com/a/3521393/319403 देखें ।
cHao

12
@Andrew: HTTP "TCP" पर निर्मित नहीं है, और TCP की स्थिति HTTP की नहीं है। दोनों स्टैक में अलग-अलग परतों में पूरी तरह से अलग-अलग प्रोटोकॉल हैं। यदि आप चाहते हैं या यहां तक ​​कि फ़ाइलों को भेजकर, यदि आप इसे करने के लिए सहमत होने के लिए पर्याप्त मसोचिस्ट मिल गए, तो आप HTTP पर नामित पाइपों की सेवा कर सकते हैं, और यह ठीक काम करेगा क्योंकि HTTP ट्रांसपोर्ट-प्रोटोकॉल-अज्ञेयवादी है। उस स्तर पर, यह सब सिर्फ अनुरोधों और प्रतिक्रियाओं का है। यह HTTP खुद को स्टेटलेस बनाता है, चाहे यह हो कि निम्न-या उच्च-स्तरीय प्रोटोकॉल द्वारा किस राज्य का उपयोग / रखरखाव / आवश्यकता हो सकती है।
cHao

@cHao ठीक है, मैं मनाऊँगा। यदि हम स्टेटलेसनेस को " ऑपरेट करने के लिए राज्य की आवश्यकता नहीं है " के रूप में परिभाषित करते हैं, तो देखें (विकिपीडिया से उद्धृत HTTP के भीतर राज्य के लिए सूचीबद्ध विकल्पों के नीचे dimo414 का उत्तर देखें), और अगर हम प्रत्येक प्रोटोकॉल को अपने आप से सख्ती से देखते हैं और उसके आधार पर परतों के आधार पर नहीं। , तो हाँ, मैं सहमत हो सकता हूँ कि HTTP "स्टेटलेस" है।
एंड्रयू

101

से विकिपीडिया :

HTTP एक स्टेटलेस प्रोटोकॉल है। एक स्टेटलेस प्रोटोकॉल में सर्वर को कई अनुरोधों की अवधि के लिए प्रत्येक उपयोगकर्ता के बारे में जानकारी या स्थिति बनाए रखने की आवश्यकता नहीं होती है।

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

  • HTTP कुकीज़ का उपयोग।
  • सर्वर साइड सत्र,
  • छिपे हुए चर (जब वर्तमान पृष्ठ में एक फ़ॉर्म होता है), और
  • URI- एन्कोडेड मापदंडों, जैसे /index.php?session_id=some_unique_session_code का उपयोग करके URL-पुनर्लेखन।

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


21

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

HTTP एक स्टेटलेस प्रोटोकॉल है, जिसका अर्थ है कि लेनदेन समाप्त होने के बाद ब्राउज़र और सर्वर के बीच का कनेक्शन खो जाता है।


2
लेकिन, HTTP कुकीज़ का उपयोग करके सर्वर में जानकारी को बचा सकता है। HTTP विह कीपिंग-लिव इन रिक्वेस्ट पर क्लोज कनेक्शन नहीं है।
जोस नोबेल


18
सर्वर पर जानकारी सहेजने का मतलब यह नहीं है कि कनेक्शन लगातार जीवित है।
सर्जन

1
@ श्रीजन खैर, नहीं। इसलिए? कोई भी दावा नहीं कर रहा था।
मार्क अमेरी नोव

10

HTTP को a कहा जाता हैstateless protocol इसलिए क्योंकि प्रत्येक अनुरोध को स्वतंत्र रूप से निष्पादित किया जाता है, बिना अनुरोधों के किसी भी ज्ञान को निष्पादित करने से पहले, जिसका अर्थ है कि एक बार लेन-देन समाप्त होने के बाद ब्राउज़र और सर्वर के बीच संबंध भी खो जाता है।

प्रोटोकॉल क्या statelessहै कि इसकी मूल डिजाइन में, HTTP एक अपेक्षाकृत सरल है file transfer protocol:

  1. URL द्वारा नामित फ़ाइल के लिए अनुरोध करें,
  2. प्रतिक्रिया में फ़ाइल प्राप्त करें,
  3. डिस्कनेक्ट।

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


3

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


1
HTTP पहले से ही जीवित है, इसका मतलब है कि सर्वर कनेक्शन को बंद नहीं करता है, और क्लाइंट एक ही कनेक्शन पर कई अनुरोध कर सकता है।
जोस नोबेल

3

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


1

स्टेटलेस क्या है ??

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

स्टेटलेस क्यों ??

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

लंबे समय तक चलने वाले कनेक्शन को बनाए रखना बेहद संसाधन-गहन होता।

यदि वेब को स्टेटफुल प्रोटोकॉल चुना गया था, तो विज़िटर के कनेक्शन को बनाए रखने के लिए सर्वर पर लोड बढ़ा दिया गया होगा।


1

HTTPस्टेटलेस है। TCPस्टेटफुल है। कोई तथाकथित नहीं है HTTP connection, लेकिन केवल HTTP requestऔर HTTP response। दूसरे बनाने के लिए हमें किसी चीज की जरूरत नहीं है HTTP request। एक कनेक्शन हेडर जो "कीप-लाइव" है, TCPका अर्थ है कि बाद HTTPमें डिस्कनेक्ट करने और फिर से TCPकनेक्शन स्थापित करने के बजाय सभी अनुरोधों और प्रतिक्रियाओं का पुन: उपयोग किया जाएगा ।


0

मुझे लगता है कि किसी ने STATELESS अवधारणा के लिए बहुत दुर्भाग्यपूर्ण नाम चुना और इसीलिए पूरी गलतफहमी पैदा हुई है। यह किसी भी तरह के संसाधनों को संग्रहीत करने के बारे में नहीं है, बल्कि क्लाइंट और सर्वर के बीच संबंधों के बारे में है।

ग्राहक: मैं सभी संसाधनों को अपने पक्ष में रख रहा हूं और आपको उन सभी महत्वपूर्ण वस्तुओं की "सूची" भेजनी होगी जिन्हें संसाधित करने की आवश्यकता है। अपना काम करो।

सर्वर: बिलकुल ठीक है .. मुझे फ़िल्टर करने की जिम्मेदारी लेने दीजिए जो आपको उचित प्रतिक्रिया देने के लिए महत्वपूर्ण है।

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

https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.