HTTP Connections - Non-Persistent and Persistent Connections

HTTP कनेक्शन मुख्य रूप से दो प्रकार के होते हैं: नॉन-पर्सिस्टेंट कनेक्शन (Non-Persistent Connection) और पर्सिस्टेंट कनेक्शन (Persistent Connection)। इन दोनों को नीचे विस्तार से समझाया गया है:

  1. नॉन-पर्सिस्टेंट कनेक्शन (Non-Persistent Connection):
  • विशेषताएं:
    • प्रत्येक HTTP रिक्वेस्ट और रिस्पांस के लिए एक नया TCP कनेक्शन स्थापित किया जाता है।
    • रिक्वेस्ट पूरी होने और रिस्पांस प्राप्त होने के बाद कनेक्शन तुरंत बंद कर दिया जाता है।
    • यह HTTP/1.0 का डिफ़ॉल्ट व्यवहार था।
  • प्रक्रिया:
    1. क्लाइंट TCP 3-वे हैंडशेक शुरू करता है।
    2. HTTP रिक्वेस्ट भेजता है (जैसे, एक वेबपेज के लिए GET रिक्वेस्ट)।
    3. सर्वर रिस्पांस भेजता है (जैसे, HTML फाइल)।
    4. कनेक्शन बंद हो जाता है।
    5. अगर वेबपेज में अन्य संसाधन (जैसे, इमेज, CSS, JS) हैं, तो प्रत्येक के लिए अलग-अलग नया TCP कनेक्शन बनता है।
  • लाभ:
    • साधारण और स्पष्ट प्रक्रिया।
    • सर्वर पर कम संसाधन उपयोग, क्योंकि कनेक्शन तुरंत बंद हो जाता है।
  • नुकसान:
    • बार-बार TCP कनेक्शन स्थापित करने में समय और नेटवर्क संसाधन खर्च होते हैं (3-वे हैंडशेक की लागत)।
    • प्रदर्शन धीमा हो सकता है, खासकर उन वेबपेजों के लिए जिनमें कई संसाधन होते हैं।
  • उदाहरण:
    • HTTP/1.0 में, अगर एक वेबपेज में 10 इमेज हैं, तो 10 अलग-अलग TCP कनेक्शन बनते हैं।
  1. पर्सिस्टेंट कनेक्शन (Persistent Connection):
  • विशेषताएं:
    • एक ही TCP कनेक्शन का उपयोग करके कई HTTP रिक्वेस्ट और रिस्पांस भेजे जा सकते हैं।
    • कनेक्शन रिक्वेस्ट पूरी होने के बाद तुरंत बंद नहीं होता, बल्कि एक निश्चित समय तक या स्पष्ट निर्देश तक खुला रहता है।
    • यह HTTP/1.1 का डिफ़ॉल्ट व्यवहार है और इसे "Keep-Alive" मैकेनिज्म के रूप में भी जाना जाता है।
  • प्रक्रिया:
    1. क्लाइंट TCP 3-वे हैंडशेक शुरू करता है और एक कनेक्शन स्थापित करता है।
    2. HTTP रिक्वेस्ट भेजता है (जैसे, HTML पेज के लिए)।
    3. सर्वर रिस्पांस भेजता है।
    4. कनेक्शन खुला रहता है, और क्लाइंट उसी कनेक्शन पर अन्य रिक्वेस्ट (जैसे, इमेज, CSS, JS) भेज सकता है।
    5. कनेक्शन तब बंद होता है जब या तो समय समाप्त हो जाता है (timeout) या कोई पक्ष स्पष्ट रूप सेConnection: close हेडर भेजता है।
  • लाभ:
    • बार-बार TCP कनेक्शन स्थापित करने की आवश्यकता नहीं पड़ती, जिससे समय और नेटवर्क संसाधन बचते हैं।
    • तेज़ प्रदर्शन, क्योंकि एक ही कनेक्शन पर कई रिक्वेस्ट प्रोसेस हो सकते हैं।
    • पाइपलाइनिंग (HTTP/1.1 में) का समर्थन, जहां क्लाइंट कई रिक्वेस्ट एक साथ भेज सकता है बिना रिस्पांस का इंतज़ार किए।
  • नुकसान:
    • सर्वर पर अधिक संसाधन उपयोग, क्योंकि कनेक्शन लंबे समय तक खुला रहता है।
    • अगर ठीक से प्रबंधन न हो, तो बहुत सारे खुले कनेक्शन सर्वर को धीमा कर सकते हैं।
  • उदाहरण:
    • HTTP/1.1 में, एक वेबपेज के लिए HTML, इमेज, CSS, और JS सभी एक ही TCP कनेक्शन के माध्यम से लोड हो सकते हैं।

प्रमुख अंतर:

विशेषता

नॉन-पर्सिस्टेंट

पर्सिस्टेंट

TCP कनेक्शन

प्रत्येक रिक्वेस्ट के लिए नया कनेक्शन

एक कनेक्शन पर कई रिक्वेस्ट

प्रदर्शन

धीमा (कनेक्शन स्थापना की लागत)

तेज़ (कनेक्शन दोबारा नहीं बनता)

संसाधन उपयोग

कम (कनेक्शन तुरंत बंद)

अधिक (कनेक्शन खुला रहता है)

डिफ़ॉल्ट संस्करण

HTTP/1.0

HTTP/1.1

हेडर

Connection: close (अक्सर)

Connection: keep-alive (डिफ़ॉल्ट)

आधुनिक संदर्भ:

  • HTTP/2 और HTTP/3: ये नए संस्करण पर्सिस्टेंट कनेक्शन को और बेहतर बनाते हैं। HTTP/2 में मल्टीप्लेक्सिंग के साथ कई रिक्वेस्ट समानांतर में भेजे जा सकते हैं, और HTTP/3 UDP-आधारित QUIC प्रोटोकॉल का उपयोग करता है, जो कनेक्शन स्थापना को और तेज़ करता है।
  • आजकल, नॉन-पर्सिस्टेंट कनेक्शन का उपयोग बहुत कम होता है, क्योंकि पर्सिस्टेंट कनेक्शन अधिक कुशल और तेज़ हैं।

संक्षेप में:

  • नॉन-पर्सिस्टेंट कनेक्शनहर रिक्वेस्ट के लिए नया TCP कनेक्शन बनाता और बंद करता है, जो धीमा और संसाधन-गहन है।
  • पर्सिस्टेंट कनेक्शनएक ही TCP कनेक्शन पर कई रिक्वेस्ट हैंडल करता है, जो तेज़ और कुशल है, और आधुनिक वेब के लिए डिफ़ॉल्ट है।


मान लीजिए कि क्लाइंट ने एचटीएमएल पेज का रिक्वेस्ट भेजा और उस पेज पर तीन इमेज फाइल है तो नॉन परसिस्टेंट में कितना राउंड ट्रिप होगा और परसिस्टेंट में कितना राउंड ट्रिप होगा?

यह समझने के लिए कि नॉन-पर्सिस्टेंट और पर्सिस्टेंट कनेक्शन में कितने राउंड-ट्रिप टाइम (RTT) लगेंगे, हमें HTTP रिक्वेस्ट की प्रक्रिया को ध्यान में रखना होगा। मान लीजिए क्लाइंट ने एक HTML पेज का रिक्वेस्ट भेजा, और उस पेज में तीन इमेज फाइलें हैं। हम यह भी मानते हैं कि DNS रिज़ॉल्यूशन पहले ही हो चुका है, और केवल TCP कनेक्शन स्थापना और HTTP रिक्वेस्ट-रिस्पांस के RTT पर विचार करेंगे।

कुछ बुनियादी बातें:

  • राउंड-ट्रिप टाइम (RTT): एक क्लाइंट से सर्वर तक डेटा भेजने और उसका जवाब प्राप्त करने में लगने वाला समय।
  • TCP 3-वे हैंडशेक: इसमें 1 RTT लगता है (SYN → SYN-ACK → ACK)।
  • HTTP रिक्वेस्ट-रिस्पांस: एक रिक्वेस्ट भेजने और उसका रिस्पांस प्राप्त करने में 1 RTT लगता है।
  • HTML पेज और प्रत्येक इमेज फाइल के लिए अलग-अलग रिक्वेस्ट भेजने पड़ते हैं।
  1. नॉन-पर्सिस्टेंट कनेक्शन:
  • नॉन-पर्सिस्टेंट कनेक्शन में, प्रत्येक रिसोर्स (HTML पेज और प्रत्येक इमेज) के लिए एक नया TCP कनेक्शन स्थापित करना पड़ता है।
  • प्रत्येक रिसोर्स के लिए:
    • 1 RTTTCP कनेक्शन स्थापना के लिए (3-वे हैंडशेक)।
    • 1 RTTHTTP रिक्वेस्ट भेजने और रिस्पांस प्राप्त करने के लिए।
    • कुल:2 RTT प्रति रिसोर्स।
  • हमारे मामले में:
    • 1 HTML पेज → 2 RTT (1 TCP + 1 HTTP)।
    • 3 इमेज फाइलें → प्रत्येक के लिए 2 RTT, यानी 3 × 2 = 6 RTT।
  • कुल RTT:
    • HTML पेज: 2 RTT
    • तीन इमेज: 6 RTT
    • कुल = 2 + 6 = 8 RTT
  1. पर्सिस्टेंट कनेक्शन (बिना पाइपलाइनिंग):
  • पर्सिस्टेंट कनेक्शन में, एक ही TCP कनेक्शन का उपयोग सभी रिक्वेस्ट के लिए किया जाता है।
  • प्रक्रिया:
    • 1 RTTTCP कनेक्शन स्थापना के लिए (केवल एक बार, क्योंकि कनेक्शन खुला रहता है)।
    • प्रत्येक रिसोर्स (HTML पेज और इमेज) के लिए1 RTT HTTP रिक्वेस्ट-रिस्पांस के लिए।
  • हमारे मामले में:
    • TCP कनेक्शन स्थापना: 1 RTT।
    • HTML पेज रिक्वेस्ट-रिस्पांस: 1 RTT।
    • तीन इमेज फाइलों के लिए रिक्वेस्ट-रिस्पांस: 3 × 1 = 3 RTT।
  • कुल RTT:
    • TCP कनेक्शन: 1 RTT
    • HTML पेज: 1 RTT
    • तीन इमेज: 3 RTT
    • कुल = 1 + 1 + 3 = 5 RTT
  1. पर्सिस्टेंट कनेक्शन (पाइपलाइनिंग के साथ, वैकल्पिक):
  • यदि HTTP/1.1 में पाइपलाइनिंग सक्षम है, तो क्लाइंट HTML पेज के रिस्पांस का इंतज़ार किए बिना सभी इमेज रिक्वेस्ट एक साथ भेज सकता है।
  • प्रक्रिया:
    • 1 RTTTCP कनेक्शन स्थापना के लिए।
    • 1 RTTHTML पेज और सभी इमेज रिक्वेस्ट भेजने और उनके रिस्पांस प्राप्त करने के लिए (क्योंकि सभी रिक्वेस्ट एक साथ भेजे जाते हैं और रिस्पांस क्रमबद्ध आते हैं)।
  • कुल RTT:
    • TCP कनेक्शन: 1 RTT
    • HTML + तीन इमेज (एक साथ): 1 RTT
    • कुल = 1 + 1 = 2 RTT
  • नोट: पाइपलाइनिंग का उपयोग वास्तविक दुनिया में सीमित है, क्योंकि यह सभी सर्वरों द्वारा समर्थित नहीं होती और इसमें हेड-ऑफ-लाइन ब्लॉकिंग जैसी समस्याएं हो सकती हैं।

तुलना:

प्रकार

कुल RTT

नॉन-पर्सिस्टेंट कनेक्शन

8 RTT

पर्सिस्टेंट कनेक्शन (बिना पाइपलाइनिंग)

5 RTT

पर्सिस्टेंट कनेक्शन (पाइपलाइनिंग के साथ)

2 RTT

मान्यताएं और स्पष्टीकरण:

  • हमने मान लिया कि HTML पेज के रिस्पांस से इमेज फाइलों की जानकारी मिलती है, इसलिए इमेज रिक्वेस्ट HTML रिक्वेस्ट के बाद ही भेजे जाते हैं।
  • पाइपलाइनिंग को वैकल्पिक माना गया है, क्योंकि यह हमेशा लागू नहीं होती।
  • यदि कोई अतिरिक्त देरी (जैसे, सर्वर प्रोसेसिंग समय) हो, तो वह RTT में शामिल नहीं है, क्योंकि हम केवल नेटवर्क RTT गिन रहे हैं।
  • HTTPS के मामले में TLS हैंडशेक के लिए अतिरिक्त RTT (1-2 RTT) जोड़े जा सकते हैं, लेकिन यह दोनों प्रकार के कनेक्शन के लिए समान होगा।

निष्कर्ष:

  • नॉन-पर्सिस्टेंट: 8 RTT, क्योंकि प्रत्येक रिसोर्स (HTML + 3 इमेज) के लिए नया TCP कनेक्शन और रिक्वेस्ट-रिस्पांस चाहिए।
  • पर्सिस्टेंट (बिना पाइपलाइनिंग): 5 RTT, क्योंकि एक TCP कनेक्शन पर सभी रिक्वेस्ट क्रमबद्ध भेजे जाते हैं।

पर्सिस्टेंट (पाइपलाइनिंग के साथ): 2 RTT, क्योंकि सभी रिक्वेस्ट एक साथ भेजे जाते हैं, लेकिन यह कम आम है।

आधुनिक वेब में पर्सिस्टेंट कनेक्शन (HTTP/1.1 या HTTP/2) का उपयोग आम है, क्योंकि यह कम RTT के साथ तेज़ प्रदर्शन देता है।


टिप्पणियाँ

एक टिप्पणी भेजें

इस ब्लॉग से लोकप्रिय पोस्ट

Differences between in-process and out-of-process hosting models

ASP.NET Core: इन-प्रोसेस और आउट-ऑफ-प्रोसेस होस्टिंग मॉडल में अंतर ASP.NET Core में सेल्फ-होस्टिंग मॉडल और आउट-प्रोसेस होस्टिंग मॉडल दो अलग-अलग तरीके हैं जिनका उपयोग आप अपने वेब एप्लिकेशन को होस्ट करने के लिए कर सकते हैं। सेल्फ-होस्टिंग मॉडल सेल्फ-होस्टिंग मॉडल में, ASP.NET Core एप्लिकेशन अपने आप में एक वेब सर्वर की भूमिका निभाता है। इसका मतलब है कि एप्लिकेशन अपने आप HTTP रिक्वेस्ट को सीधे हैंडल करता है और उन्हें प्रोसेस करता है। सेल्फ-होस्टिंग के लिए Kestrel नामक एक क्रॉस-प्लेटफ़ॉर्म वेब सर्वर का उपयोग किया जाता है। आउट-प्रोसेस होस्टिंग मॉडल आउट-प्रोसेस होस्टिंग मॉडल में, ASP.NET Core एप्लिकेशन एक अलग प्रोसेस में चलता है, और एक बाहरी वेब सर्वर (जैसे कि आईआईएस या एनजिनएक्स) HTTP रिक्वेस्ट को प्राप्त करता है और उन्हें एप्लिकेशन को फॉरवर्ड करता है। इस मॉडल में, एप्लिकेशन और वेब सर्वर अलग-अलग प्रोसेस में चलते हैं। अब इनके बारे में विस्तार से समझते हैं - 1. इन-प्रोसेस होस्टिंग (In-Process Hosting) कार...
Read more »

Web Fundamental Concepts in Hindi for Beginners - FAQs with their Answers Part-1

List of Consolidated Questions Question 1. वेब एप्लीकेशन को होस्ट करने की आवश्यकता होती है जबकि डेस्कटॉप एप्लीकेशन के साथ ऐसा नहीं होता है ऐसा क्यों? Question 2. वेब एप्लीकेशन को होस्ट करने के लिए एक वेब सर्वर की जरूरत होती है क्यों? इसके अलावा वेब एप्लीकेशन को डाटाबेस सर्वर की भी आवश्यकता पड़ती है क्यों? Question 3. वेब सर्वर के अलावा और किन-किन प्रकार के सर्वर की आवश्यकता वेब एप्लीकेशन को पड़ती है? Question 4. एक वेब एप्लीकेशन को एक से अधिक सर्वर पर कई बार क्यों होस्ट किया जाता है? Question 5. वेब एप्लीकेशन और वेब सेवा में क्या अंतर है या दोनों एक ही चीज है? Question 6. क्या यह सच है कि एक वेब एप्लीकेशन एक या एक से अधिक वेब सेवाओं का उपयोग कर सकता है? Question 7. वेब एप्लीकेशन के संदर्भ में गेटवे क्या होता है? Question 8. ...
Read more »

Introduction to ASP.NET Core and Web Frameworks

वेब एप्लीकेशन और .NET Core का परिचय वेब एप्लीकेशन हर जगह उपलब्ध हैं, चाहे वह सोशल मीडिया हो या आपका फ़ोन; हर जगह आपको वेब एप्लीकेशन दिखाई देंगे। वेब एप्लीकेशन के पीछे की दुनिया सर्वर की दुनिया है। सर्वर पर कोई वेब एप्लीकेशन होस्ट किया जाता है, तत्पश्चात वेब एप्लीकेशन रन होता है। .NET Core को आधुनिक युग की आवश्यकताओं के अनुसार डिज़ाइन किया गया है। चाहे कोई साधारण सा वेबसाइट हो या कोई जटिल ई-कॉमर्स एप्लीकेशन अथवा डिस्ट्रीब्यूटेड माइक्रो सर्विसेज, एक बार जब आप .NET Core सीख जाते हैं तो इस तरह के कोई भी एप्लीकेशन आप बना सकते हैं। अब सवाल है कि .NET Core क्या है? ASP.NET Core माइक्रोसॉफ्ट का नया वेब फ्रेमवर्क है जिसकी सहायता से विभिन्न प्रकार के वेब एप्लीकेशन को बनाना बहुत ही सरल है। माइक्रोसॉफ्ट ने ASP.NET Core को जून 2016 में रिलीज़ किया था। इसके बाद निरंतर माइक्रोसॉफ्ट की टीम ने .NET Core में सुधार करके या अपग्रेड करके बाजार में नए-नए वर्जन जारी किए हैं. वेब फ्रेमवर्क क्या है? ...
Read more »