HTTP कैसे स्टेटलेस हो जाता है?

Question

HTTP को स्टेटलेस कहा जाता है। मतलब, यह डेटा के प्रसारण के लिए जानकारी संग्रहीत करने की आवश्यकता नहीं है।

लेकिन HTTP टीसीपी का उपयोग करता है, जो राज्य उन्मुख है।

अगर ऐसा है, तो HTTP स्टेटलेस कैसे हो जाता है?

Comments

सुपर यूजर द्वारा लॉन्च किए जाने के 5 साल बाद तक यह कैसे नहीं है?

— पीटर मोर्टेंसन

क्योंकि ज्यादातर दुपट्टे StackOverflow पर हैं? मैं सिर्फ अनुमान लगा रहा हूं।

— ट्रिक्स

सिर्फ इसलिए कि यह केबलों (दूसरों के बीच) के माध्यम से चलता है, इसे या तो एक इलेक्ट्रिक प्रोटोकॉल नहीं बनाता है

— हेगन वॉन एटिजन

stackoverflow.com/questions/13200152/…

— अली 786

Answer 1

HTTP की परवाह नहीं की जाती है और यह स्वतंत्र है - निम्न-स्तरीय प्रोटोकॉल में से कोई भी स्वयं को परिवहन करने के लिए उपयोग किया जाता है, भले ही वह स्वयं ही स्टेटलेस हो।

परिवहन तकनीक टीसीपी, या नोवेल के पुराने एसपीएक्स, या एससीटीपी, या जो भी आप सपने देख सकते हैं, और एचटीटीपी अभी भी वही काम करेंगे। HTTP को एक स्ट्रीमिंग या कनेक्शन-उन्मुख प्रोटोकॉल की आवश्यकता होती है - और URL पर resolvable होने पर निर्भर करता है - लेकिन यह ध्यान नहीं देता कि यह कैसे पूरा होता है।

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

सिर्फ इसलिए कि एक निचले स्तर का प्रोटोकॉल स्टेटफुल है इसका मतलब यह नहीं है कि इसके शीर्ष पर कुछ भी स्वचालित रूप से स्टेटफुल हो जाता है या स्टेटफुल होना आवश्यक है।

HTTP अपने आप में स्टेटलेस है। तो इसका मतलब है कि अनुप्रयोगों को राज्य स्थापित करने के लिए HTTP के शीर्ष पर एक और परत को लागू करना होगा। यह आमतौर पर सत्र कुकीज़ के साथ किया जाता है।

Comments

रूटिंग टीसीपी / आईपी स्तर पर होती है।

— फियास्को लैब्स

यह छवि इसे अच्छी तरह से समझाती है। vichargrave.com/wp-content/uploads/2013/01/…

— जेकगोल्ड

संयोगवश, यह तथ्य कि HTTP अंतर्निहित कनेक्शन (जो लगभग हमेशा टीसीपी होगा) की राज्य-योग्यता की अनदेखी करता है, जो कि विभिन्न HTTP2 दृष्टिकोणों को संबोधित करने की कोशिश कर रहे प्रमुख प्रदर्शन में से एक है ।

— स्कोलिमा

@ फ़िस्को: सख्ती से बोलना, आईपी स्तर पर रूटिंग होता है। रूटिंग इंटरनेट पते पर आधारित है, टीसीपी परत से कोई भी जानकारी बुनियादी रूटिंग में उपयोग नहीं की जाती है।

— RedGrittyBrick

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

— रयान

Answer 2

"HTTP स्टेटलेस है" इसका मतलब है कि प्रत्येक HTTP लेनदेन (अनुरोध-प्रतिक्रिया जोड़ी) को पिछले अनुरोध-प्रतिक्रिया जोड़ी से किसी भी राज्य में स्वतंत्र रूप से संसाधित किया जा सकता है।

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

लेकिन लेन-देन की सीमा के पार, कोई राज्य नहीं है। क्लाइंट कनेक्शन को छोड़ सकता है और अगले अनुरोध के लिए एक नया स्थापित कर सकता है। वास्तव में जो शुरुआती संस्करणों में एकमात्र विकल्प था और यह अभी भी उसी तरह काम करता है यदि क्लाइंट Connection: keep-aliveहेडर को शामिल नहीं करता है ।

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

Comments

can also easily be handled by different server and the client will never knowहालांकि तकनीकी रूप से सच है, यह भ्रामक है क्योंकि कई वेब अनुप्रयोग चिपचिपा सत्रों का उपयोग करते हैं, एक ही ब्राउज़िंग सत्र से एक ही सर्वर पर भविष्य के अनुरोधों को रूट करने के लिए लोड बैलेंसर की आवश्यकता होती है। HTTP के दृष्टिकोण से, सत्र अप्रासंगिक हैं, लेकिन आपका अंतिम वाक्य यह बताता है कि अंतिम-उपयोगकर्ता अनुभव अप्रभावित रहेगा, जो चिपचिपा सत्रों के साथ गलत होगा।

— ब्रैंडन

@Brandon: इस तरह के एप्लिकेशन HTTP के शीर्ष पर एक स्टेटफुल प्रोटोकॉल का निर्माण करते हैं और यह इसके लिए उनकी सजा है!

— Jan Hudec

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

— स्लीबटमैन

@ सिलेबेटमैन: हाँ, जो भी हो। HTTP में स्वयं ऐसी स्थिति नहीं है, इसलिए HTTP के लिए यह सरल है। यदि एप्लिकेशन इसकी स्वयं की कुछ स्थिति जोड़ता है, तो यह इसकी लड़ाई है।

— Jan Hudec

ठीक है, मैंने सब नहीं कहा। मैंने कुछ कहा। मैं व्यक्तिगत रूप से चिपचिपा सत्रों से बचना पसंद करता हूं, और यदि संभव हो तो, सत्रों से पूरी तरह से बचें। फिर भी, सॉफ्टवेयर मौजूद है जो हर किसी के आदर्श पर खरा नहीं उतरता है।

— ब्रैंडन

Answer 3

HTTP की "स्टेटलेस" प्रकृति का अर्थ है कि इस परत पर, कोई भी राज्य जानकारी नहीं बनाई जाती है या इसका उपयोग नहीं किया जाता है।

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

इसके विपरीत, कुकी आधारित लॉगिन तंत्र स्टेटफुल हैं, लेकिन HTTP का हिस्सा नहीं है।

Answer 4

आपको इसे रूसी गुड़िया (या यदि आप चाहें तो बक्से) के एक सेट के रूप में समझना होगा, उनमें से प्रत्येक एक दूसरे को अंदर ले जा रहा है, तो यह है कि यह कैसे काम करता है: टीसीपी HTTP "अंदर" करता है, लेकिन यह इसके बारे में परवाह नहीं करता है या यह सुविधाएँ नहीं है।

पूरी तस्वीर प्राप्त करने के लिए मैं OSI मॉडल के बारे में पढ़ने की सलाह देता हूं क्योंकि यह स्पष्ट हो जाता है।

टीसीपी ओएसआई मॉडल में HTTP के नीचे कुछ परतों को बैठता है, प्रत्येक परत वास्तव में एक अलग प्रोटोकॉल के अनुरूप होती है।

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

Comments

OSI मॉडल के साथ समस्या यह है कि यह अब सैद्धांतिक है (इसे लागू करने के लिए वास्तविक प्रयास थे, लेकिन वे अपनी जटिलता के कारण बाजार में विफल रहे)। वास्तव में, टीसीपी और एचटीटीपी के बीच कोई परत नहीं हैं। इसके अलावा, प्रस्तुति परत HTML होगी, न कि HTTP।

— एमएसल्टर्स

टीसीपी / आईपी मॉडल में, टीसीपी नेटवर्क परत में नहीं रहता है। यह आईपी के शीर्ष पर परिवहन परत में रहता है, जो बाद में नेटवर्क में है। "टीसीपी मॉडल" के लिए पहला Google हिट यह प्रदर्शित करता है: Technet.microsoft.com/en-us/library/cc786900(v=ws.10).aspx

— ब्रेंडन

@ स्तनधार: क्या टीएलएस एक परत नहीं है?

— ग्रैविटी

@MSalters: आपको महसूस होता है कि HTTPS केवल HTTP द्वारा दिया गया नाम TLS है। जैसे कि TLS HTTP के नीचे और टीसीपी के ऊपर एक परत है और TLS / SSL + HTTP कॉम्बो को HTTPS कहा जाता है।

— स्लीबटमैन

इसके अलावा, टीएलएस / एचटीटीपी कॉम्बो का एक और नया नाम है। यदि TLS जो HTTP ट्रैफ़िक को वर्चुअल सॉकेट / स्ट्रीम मल्टीप्लेक्स करता है, उसे SPDY कहा जाता है (लेकिन आपके ब्राउज़र में url अभी भी HTTPS है)।

— स्लीवेटमैन