मैं पंजीकृत उपयोगकर्ताओं के लिए सार्वजनिक सामग्री और व्यक्तिगत / अनुकूलित सामग्री के साथ काफी मानक वेब साइट पर काम कर रहा हूं। मुझे पता है कि जब उपयोगकर्ता लॉग इन कर रहे हैं या क्रेडिट कार्ड का विवरण भेज रहे हैं तो मुझे HTTPS का उपयोग करने की आवश्यकता है। क्या कोई कारण है कि मुझे पूरी साइट के लिए HTTPS का उपयोग नहीं करना चाहिए?
जवाबों:
हां, एक कारण है कि आपको इसे पूरी साइट के लिए उपयोग नहीं करना चाहिए। कुछ ब्राउज़र (ब्रांड और संस्करण के आधार पर) HTTPS अनुरोधों से डिस्क पर सामग्री को कैश नहीं करेंगे, जो उपयोगकर्ताओं के लिए ब्राउज़िंग अनुभव को गंभीरता से धीमा कर सकता है, क्योंकि स्थिर संपत्ति हर पेज अनुरोध (स्टाइल-शीट, जावास्क्रिप्ट, हेडर इमेज आदि) के साथ लोड की जाएगी। । उदाहरण के लिए, मोज़िला बताता है कि:
"डिस्क कैशिंग डाउनलोड की गई फ़ाइलों की प्रतियों को हार्ड ड्राइव पर सहेजता है, ताकि उन्हें फिर से डाउनलोड करने की आवश्यकता न हो। इन पृष्ठों को कैश फ़ोल्डर की अनुमति वाले किसी भी व्यक्ति द्वारा देखा जा सकता है। SSL एन्क्रिप्शन के साथ प्रेषित पृष्ठों में अक्सर संवेदनशील जानकारी होती है। डिस्क पर इन पृष्ठों को कैशिंग करने से गोपनीयता का जोखिम हो सकता है। यह वरीयता नियंत्रित करती है कि क्या उन डिस्क पृष्ठों को कैश किया जाए जो एसएसएल एन्क्रिप्शन से संचरित थे। "
कैसे व्यक्तिगत ब्राउज़र कैश HTTPS कुछ विवादित है, लेकिन अभी भी एक अच्छा मौका है कि कई उपयोगकर्ता HTTPS अनुरोधों के लिए डिस्क कैशिंग अक्षम होंगे।
दूसरे, HTTPS को प्रत्येक अनुरोध के लिए " हैंडशेक " की आवश्यकता होती है और यह कुछ ओवरहेड के साथ आता है, जो प्रदर्शन को प्रभावित करेगा और अनुरोधों को बड़ा करेगा (आमतौर पर केवल कुछ केबी द्वारा - लेकिन यह हर अनुरोध के लिए है और यह आगे बढ़ता है)। HTTP KeepAlive इसे सीमित कर सकता है, लेकिन यह अभी भी एक ओवरहेड है जिसे आपको गैर-सुरक्षित सामग्री की आवश्यकता नहीं है।
यदि आप पूर्ण एसएसएल चलाने की योजना बना रहे हैं, तो सुनिश्चित करें कि आपके द्वारा उपयोग की जा रही कोई भी तृतीय पक्ष सेवाएँ (विज्ञापन सर्वर, विश्लेषिकी, साझाकरण उपकरण, आदि) में एसएसएल संस्करण उपलब्ध हैं, या आपको कुछ ब्राउज़रों पर मिश्रित सामग्री की चेतावनी मिलेगी।
एक और समस्या यह है कि आप जो कुछ भी किसी भी पेज से प्राप्त करते हैं, उसे वास्तव में एसएसएल से गुजरना पड़ता है, जिसमें तीसरे पक्ष के संसाधन भी शामिल हैं। हमने पाया है कि यह उदाहरण के लिए YouTube जैसी वास्तविक समस्या है। चूँकि Google YouTube वीडियो को SSL के माध्यम से उपलब्ध नहीं कराता है, इसका मतलब है कि आप जो भी YouTube वीडियो अपनी साइट पर एक पृष्ठ पर एम्बेड करना चाहते हैं, वह "इस पृष्ठ में सुरक्षित और गैर-सुरक्षित सामग्री" चेतावनी का कारण होगा। जब तक यह अधिकांश ब्राउज़रों में सूक्ष्म है, यह IE में एक विशाल संवाद है और कुछ उपयोगकर्ताओं को आपकी साइट को बहुत तेज़ी से छोड़ने का कारण बन सकता है, डर में अपने डेटा को उनके सीने से जकड़ कर।
आपको ग्रोथ के बारे में भी सोचना चाहिए। एक बार जब आपके पास एक से अधिक वेबसर्वर हैं, तो आपको यह तय करना होगा: क्या आप प्रत्येक व्यक्तिगत सर्वर पर HTTPS प्रदान करना चाहते हैं, और यदि ऐसा है, तो क्या आप एक ही प्रमाण पत्र या प्रति सर्वर पर एक प्रमाण पत्र का उपयोग कर रहे हैं जैसा कि अक्सर अनुशंसित होता है। मैंने अधिक सामान्य सेटअप देखे हैं जहां कम HTTPS सर्वर हैं क्योंकि वे आमतौर पर केवल संवेदनशील विवरण और अधिक HTTP सर्वर के प्रसंस्करण के लिए उपयोग किए जाते हैं क्योंकि वे ट्रैफ़िक के थोक प्राप्त करते हैं। HTTPS आपके प्रत्येक सेटअप में थोड़ी अधिक जटिलता जोड़ता है। सिर्फ मन में रखने वाली कुछ बातें।
जैसा कि मैं इसे देखता हूं, आपकी पूरी साइट पर HTTPS का उपयोग न करने का एकमात्र कारण यह है कि यह आपके सर्वर को धीमा कर देगा और आगंतुकों को थोड़ा धीमा ब्राउज़िंग अनुभव होगा। कहा जा रहा है, वहाँ लाभ कर रहे हैं। विशेष रूप से:
एक अनएन्क्रिप्टेड पेज पर सुरक्षित डेटा दिखाने के बारे में चिंता न करने के लिए अपने डेवलपर्स के लिए इसे आसान बनाने से परे, वास्तव में हर पेज पर HTTPS का उपयोग करने का कोई तकनीकी कारण नहीं है । उसी तर्क से, बहुत कम कारण है कि नहीं।
अंतिम लेकिन कम से कम, कई नियोक्ता "एन्क्रिप्टेड" https साइटों पर अपने साम्राज्यियों को ब्राउज़ करना पसंद नहीं करते हैं। यह रक्षा / सुरक्षा कंपनियों और संगठनों का मामला है, इसलिए यदि आपके पास "केवल https" वेबसाइट है, तो आप इनमें से कुछ आगंतुकों / ग्राहकों को ढीला कर सकते हैं, क्योंकि उनका नेटवर्क बस उन्हें आपकी साइट ब्राउज़ नहीं करने देगा।