HTTPS वेबसाइट के प्रदर्शन को कैसे प्रभावित करता है

HTTPS वेबसाइट के प्रदर्शन को कैसे प्रभावित करता है

HTTPS में “S” का अर्थ “सुरक्षित” है और यह सुरक्षा SSL (उर्फ TLS) द्वारा प्रदान की जाती है। यह समझ में आता है कि आप अपनी साइट को सुरक्षित करना चाहते हैं, है ना? आखिरकार, हर मिनट वर्डप्रेस साइटों पर 90,000 तक हमले होते हैं।

लेकिन किसी कारण से, एक व्यापक मिथक है कि एसएसएल धीमा है। आपकी साइट पर एक एसएसएल प्रमाणपत्र स्थापित करने से बहुत अधिक ओवरहेड और धीमी चीजें शुरू हो जाएंगी। हो सकता है कि एक दशक से अधिक समय पहले ऐसा ही रहा हो, लेकिन यह 2018 है और Google खोज अब डिफ़ॉल्ट रूप से HTTPS पर 40,000 खोज क्वेरी प्रति सेकंड के लिए की जाती है।

वास्तव में, जब Google ने डिफ़ॉल्ट रूप से हर चीज के लिए HTTPS पर स्विच किया, तो खोज दिग्गज ने अतिरिक्त मशीनों या विशेष हार्डवेयर को तैनात नहीं किया। Google के HTTPS सर्विंग इंफ्रास्ट्रक्चर और Chrome के नेटवर्क स्टैक पर काम करने वाले सीनियर स्टाफ़ सॉफ़्टवेयर इंजीनियर एडम लैंगली लिखते हैं कि SSL का वेब प्रदर्शन पर सीमित प्रभाव पड़ता है:

हमारे उत्पादन फ्रंट-एंड मशीनों पर, एसएसएल / टीएलएस सीपीयू लोड के 1% से कम, प्रति कनेक्शन 10KB से कम मेमोरी और नेटवर्क ओवरहेड के 2% से कम के लिए खाते हैं।

अगर Google SSL लागू कर सकता है, तो आप भी कर सकते हैं। साथ ही, आपको – जुलाई से जब क्रोम 68 जारी किया गया है, तो HTTPS का उपयोग नहीं करने वाली वेबसाइटों को पता बार में “सुरक्षित नहीं” के रूप में लेबल किया जाएगा।

इस पोस्ट में, हम देखेंगे कि HTTPS वेबसाइट के प्रदर्शन को कैसे प्रभावित करता है, साथ ही साथ आप अपनी साइट के लिए HTTPS के प्रदर्शन को कैसे सुधार सकते हैं, इसके बारे में कुछ सुझाव भी देंगे।

एसएसएल और टीएलएस के बीच क्या अंतर है?

लेकिन पहले, आप सोच रहे होंगे कि एसएसएल (सिक्योर सॉकेट लेयर) और टीएलएस (ट्रांसपोर्ट लेयर सिक्योरिटी) में क्या अंतर है। दिलचस्प बात यह है कि इसमें कोई अंतर नहीं है।

टीएलएस को 1999 में एसएसएल 3.0 के उत्तराधिकारी के रूप में पेश किया गया था और एसएसएल प्रोटोकॉल में असुरक्षा को हल करने के लिए डिजाइन किया गया था।

तो इतने समय के बाद भी लोग टीएलएस के बजाय एसएसएल क्यों कहते हैं?

सुरक्षा उद्योग में लोग एसएसएल को इतना पसंद करते हैं कि वे संक्षिप्त नाम का उपयोग करना जारी रखते हैं और आज भी करते हैं। कोमोडो जैसी कंपनियों ने एसएसएल सर्टिफिकेट का नाम बदलकर टीएलएस सर्टिफिकेट नहीं किया। सॉफ़्टवेयर जो SSL को एक सर्वर पर सक्षम करता है, जैसे कि OpenSSL, ने अपना नाम OpenTLS में नहीं बदला। एसएसएल नाम जड़ जमाया हुआ था और बस अटक गया था।

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

खरीद-फरोख्त के एक हिस्से के रूप में, हमें एसएसएल 3.0 में कुछ बदलाव करने पड़े (ताकि यह [Internet Engineering Task Force] आईईटीएफ सिर्फ नेटस्केप के प्रोटोकॉल को रबरस्टैम्प कर रहा था), और हमें प्रोटोकॉल का नाम बदलना पड़ा (उसी कारण से)। और इस प्रकार टीएलएस 1.0 का जन्म हुआ (जो वास्तव में एसएसएल 3.1 था)। और हां, अब, पीछे मुड़कर देखने पर, पूरी बात मूर्खतापूर्ण लगती है।

और इस तरह टीएलएस का जन्म हुआ। लेकिन फिर भी हर कोई एसएसएल कहता रहा।

टिप्पणी: इस पोस्ट के बाकी हिस्सों के लिए, मैं एसएसएल और टीएसएल का परस्पर उपयोग करूँगा।

एचटीटीपी बनाम एचटीटीपीएस?

HTTP का अर्थ है हाइपरटेक्स्ट ट्रांसफ़र प्रोटोकॉल. जब आप अपने एड्रेस बार में http: // से पहले एक URL दर्ज करते हैं, तो यह ब्राउज़र को HTTP के माध्यम से वेबसाइट से कनेक्ट करने के लिए कहता है। बदले में, HTTP उस साइट को लोड करने के लिए वेब पर डेटा पैकेट भेजने और प्राप्त करने के लिए ट्रांसमिशन कंट्रोल प्रोटोकॉल (TCP) का उपयोग करता है जिसे आप एक्सेस करना चाहते हैं।

HTTPS का मतलब है हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल सिक्योर. जब आप https: // से पहले एक URL दर्ज करते हैं, तो यह ब्राउज़र को HTTPS के माध्यम से कनेक्ट करने के लिए कहता है, जो TCP का भी उपयोग करता है। लेकिन ऐसा टीएलएस द्वारा एन्क्रिप्ट किए गए कनेक्शन के भीतर होता है।

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

एसएसएल परत के दो मुख्य उद्देश्य हैं:

  • यह सत्यापित करता है कि आप सीधे उस सेवा से संचार कर रहे हैं जिसके बारे में आपको लगता है कि आप बात कर रहे हैं, और
  • यह सुनिश्चित करता है कि केवल सर्वर ही पढ़ सकता है कि आप इसे क्या भेजते हैं और केवल आप ही पढ़ सकते हैं जो यह वापस भेजता है।

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

टीएलएस हैंडशेक

जब आप HTTPS पर स्विच करते हैं तो कुछ विलंबता जुड़ जाती है – प्रारंभिक TLS हैंडशेक के लिए कनेक्शन स्थापित होने से पहले दो अतिरिक्त राउंड ट्रिप की आवश्यकता होती है, जबकि एक अनएन्क्रिप्टेड HTTP पोर्ट के माध्यम से। लेकिन, जैसा कि Google के उदाहरण में मैंने पहले उल्लेख किया है, यह न्यूनतम है।

2010 में, Google ने झूठी शुरुआत की शुरुआत की, एक ऐसी तकनीक जिसने टीएलएस हैंडशेक की विलंबता को 30% कम कर दिया। लेकिन इसने एक साल बाद इस परियोजना को छोड़ दिया क्योंकि यह बड़ी संख्या में ऐसी वेबसाइटों के साथ असंगत रही जो एसएसएल टर्मिनेटर का उपयोग करती थीं, जो सर्वर से एसएसएल प्रसंस्करण को ऑफलोड करती हैं।

हालाँकि, फाल्स स्टार्ट पूरी तरह से मृत नहीं है – यह अभी भी उन साइटों के लिए काम करता है जो NPN एक्सटेंशन का समर्थन करते हैं।

असममित एन्क्रिप्शन

ब्राउज़र और सर्वर के बीच एक एन्क्रिप्शन प्रक्रिया भी होती है जिसमें वे असममित एन्क्रिप्शन नामक प्रक्रिया का उपयोग करके सूचनाओं का आदान-प्रदान करते हैं। यह एक सुरक्षित संचार चैनल स्थापित करता है जिसके माध्यम से एक सत्र कुंजी का आदान-प्रदान किया जाता है, जिससे ब्राउज़र और सर्वर को सममित एन्क्रिप्शन के रूप में ज्ञात तेज़ एन्क्रिप्शन प्रक्रिया पर स्विच करने की अनुमति मिलती है।

असममित एन्क्रिप्शन पूर्व की लंबी कुंजी लंबाई और उपयोग किए गए एन्क्रिप्शन एल्गोरिदम की जटिलता के कारण सममित एन्क्रिप्शन की तुलना में धीमा है। हालाँकि, एन्क्रिप्टेड और अनएन्क्रिप्टेड कनेक्शन के बीच परीक्षण केवल 5ms का अंतर प्रकट करते हैं और CPU उपयोग में केवल 2% की चरम वृद्धि करते हैं। दर्जनों समानांतर अनुरोधों और सैकड़ों अनुक्रमिक अनुरोधों के साथ, परीक्षणों के दौरान सीपीयू का उपयोग कभी भी 5% से अधिक नहीं हुआ।

सत्र की बहाली

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

टीएलएस दो सत्र बहाली तंत्र प्रदान करता है: सत्र आईडी (जहां सर्वर और क्लाइंट प्रत्येक अपनी गुप्त स्थिति को संग्रहीत करते हैं) और सत्र टिकट (जहां क्लाइंट सर्वर द्वारा एन्क्रिप्टेड सर्वर की स्थिति को संग्रहीत करता है)।

सत्र आईडी के मामले में, सर्वर को पिछले सत्रों का ट्रैक रखने की आवश्यकता होती है जो किसी समय पर जारी रह सकते हैं। इससे सर्वर को अतिरिक्त काम करना पड़ता है।

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

सत्र टिकटों का उपयोग करके सत्र फिर से शुरू करना कई कारणों से एक लाभदायक तकनीक है – कम राउंड ट्रिप, कम संगणनाएं, और एक कम भीड़ वाली खिड़की, यह सब आपके सर्वर पर बोझ डाले बिना।

HTTPS प्रदर्शन में सुधार

दी, एसएसएल/टीएलएस और एचटीटीपीएस कुछ मामूली देरी पेश करते हैं जो आपकी साइट की पृष्ठ लोड गति को प्रभावित कर सकते हैं। लेकिन गति में देरी इतनी मामूली है कि सुरक्षा लाभ गति पर किसी भी संभावित प्रभाव को पछाड़ देते हैं।

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

1. एचटीटीपी/2

HTTP/2 HTTP प्रोटोकॉल का एक प्रमुख संशोधन है और HTTP/1.1 की कई कमियों और अनम्यताओं को हल करने का प्रयास करता है। इसके लाभ और सुविधाओं में शामिल हैं:

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

यदि आप यह जांचना चाहते हैं कि आपका सर्वर या सीडीएन HTTP/2 का समर्थन करता है या नहीं, तो KeyCDN के पास एक बेहतरीन मुफ्त HTTP/2 परीक्षण उपकरण है।

2. ब्रोटली कम्प्रेशन

Brotli Gzip, Zopfli और Deflate के विकल्प के रूप में Google द्वारा विकसित एक खुला स्रोत दोषरहित संपीड़न एल्गोरिथ्म है जो बैंडविड्थ की खपत को कम करता है और सामग्री को तेज़ी से लोड करने में मदद करता है।

Google केस स्टडी के अनुसार, कम CPU उपयोग के साथ Zopfli पर प्रारूप 20-26% उच्च संपीड़न अनुपात प्राप्त करता है।

Brotli का उपयोग करने के लिए, क्लाइंट और सर्वर दोनों को Brotli के अनुकूल होना चाहिए और इसका उपयोग करने के लिए HTTPS कनेक्शन पर चलना चाहिए।

आप KeyCDN के नि:शुल्क परीक्षण टूल का उपयोग करके परीक्षण कर सकते हैं कि आपका सर्वर या CDN Brotli का समर्थन करता है या नहीं।

3. एचपीएक्स संपीड़न

HTTP/2 का उपयोग करने वाली साइटें HPACK कम्प्रेशन का अधिकतम लाभ उठा सकती हैं। हेडर आकार में औसत 30% की कमी प्राप्त करने के लिए यह तकनीक हफमैन एन्कोडिंग का उपयोग करती है।

HPACK का उपयोग करने के तीन मुख्य लाभ हैं:

यह कंप्रेशन-आधारित हमलों के खिलाफ लचीला है, जैसे कि CRIME (कम्प्रेशन रेशियो इंफो-लीक मेड ईज़ी,
फिक्स्ड हफ़मैन एन्कोडिंग का उपयोग करके बड़े हेडर को एनकोड करने की इसकी क्षमता, और
हर बार पूरे हेडर को फिर से भेजने के विपरीत, आमतौर पर उपयोग किए जाने वाले हेडर को चर लंबाई पूर्णांक के रूप में एन्कोड करने की क्षमता है।

4. ओसीएसपी स्टेपलिंग

ओसीएसपी स्टेपलिंग एसएसएल प्रमाणपत्र वैध है या नहीं, यह जल्दी से निर्धारित करने की एक विधि है। यह प्रमाणपत्र के विक्रेता से जानकारी का अनुरोध करने के बजाय सर्वर को अपने स्वयं के प्रमाणपत्रों की वैधता के बारे में जानकारी प्रदान करने की अनुमति देता है। यह गोपनीय डेटा की सुरक्षा और गोपनीयता सुनिश्चित करता है और ग्राहक को प्रमाण पत्र प्राधिकरण से संपर्क करने की आवश्यकता को समाप्त करता है, जिससे एक और अनुरोध कम हो जाता है।

अपने सर्वर पर OCSP स्टेपलिंग सक्षम करने के लिए, DigiCert के विस्तृत निर्देश देखें।

5. सीडीएन का प्रयोग करें

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

उपयोगकर्ता को आपके मूल देश और महासागरों को पार करने के बजाय, पास के एज सर्वर के साथ अपने कनेक्शन को समाप्त करने की अनुमति देकर, ग्राहक को छोटी राउंड ट्रिप के साथ “जल्दी समाप्ति” का लाभ मिलता है।

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

निष्कर्ष

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

एचटीटीपी/2 के साथ, एचटीटीपीएस केवल तेज़ हो रहा है इसलिए एसएसएल कनेक्शन में जो भी प्रदर्शन प्रभाव जोड़ता है वह तेजी से गिर रहा है।

मैं आपको इसके साथ छोड़ दूँगा: HTTP बनाम HTTPS परीक्षण। यह साइट एक ही पृष्ठ के असुरक्षित HTTP और एन्क्रिप्टेड HTTPS HTTP/s संस्करणों के लिए लोड समय की दृश्य तुलना प्रदान करती है। परिणाम खुद अपनी कहानी कहते हैं।



HTTPS वेबसाइट के प्रदर्शन को कैसे प्रभावित करता है HTTPS वेबसाइट के प्रदर्शन को कैसे प्रभावित करता है

प्रातिक्रिया दे

आपका ईमेल पता प्रकाशित नहीं किया जाएगा. आवश्यक फ़ील्ड चिह्नित हैं *