HTTP बनाम HTTPS प्रदर्शन

Question

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

Comments

आपको HTTP2 की भी जांच करनी चाहिए, जो वर्तमान में केवल HTTPS के साथ उपयोग किए जाने पर ब्राउज़र समर्थन करते हैं। en.wikipedia.org/wiki/HTTP/2

— लुका स्टीब

httpsहमेशा http(या बहुत धीमी) से धीमी है।

— --६

अगर कुछ पारदर्शी कैशिंग हो रही है (उदाहरण के लिए विद्रूप) तो यह महत्वपूर्ण हो सकता है। प्रोटोकॉल ही, मुझे नहीं लगता कि यह एक बड़ा उपरि है।

— रॉल्फ

Answer 1

इसका एक बहुत ही सरल उत्तर है: अपने वेब सर्वर के प्रदर्शन को देखने के लिए कि आपके विशेष स्थिति के लिए प्रदर्शन का दंड क्या है।HTTP बनाम HTTPS सर्वर (JMeter और Visual Studio का ध्यान रखें) के प्रदर्शन की तुलना करने के लिए कई उपकरण हैं और वे उपयोग करने में काफी आसान हैं।

आपकी वेब साइट, हार्डवेयर, सॉफ़्टवेयर और नेटवर्क कॉन्फ़िगरेशन की प्रकृति के बारे में कुछ जानकारी के बिना कोई भी आपको सार्थक जवाब नहीं दे सकता है।

जैसा कि दूसरों ने कहा है, एन्क्रिप्शन के कारण कुछ हद तक ओवरहेड हो जाएगा, लेकिन यह अत्यधिक निर्भर है:

• हार्डवेयर
• सर्वर सॉफ्टवेयर
• गतिशील बनाम स्थिर सामग्री का अनुपात
• क्लाइंट की सर्वर से दूरी
• विशिष्ट सत्र लंबाई
• आदि (मेरा व्यक्तिगत पसंदीदा)
• ग्राहकों का कैशिंग व्यवहार

मेरे अनुभव में, डायनेमिक कंटेंट पर भारी होने वाले सर्वर HTTPS से कम प्रभावित होते हैं क्योंकि कंटेंट जेनरेशन टाइम की तुलना में एनक्रिप्टेड (एसएसएल-ओवरहेड) खर्च किया गया समय काफी कम होता है।

सर्वर जो कि स्थिर पृष्ठों के एक छोटे से सेट की सेवा पर भारी हैं, जिन्हें आसानी से मेमोरी में कैश्ड किया जा सकता है, बहुत अधिक ओवरहेड (एक मामले में, थ्रूपुट को "इंट्रानेट" पर रखा गया था) से पीड़ित हैं।

संपादित करें: एक बिंदु जो कई अन्य लोगों द्वारा लाया गया है, वह यह है कि SSL हैंडशेकिंग HTTPS की प्रमुख लागत है। यह सही है, यही वजह है कि "विशिष्ट सत्र की लंबाई" और "ग्राहकों के कैशिंग व्यवहार" महत्वपूर्ण हैं।

कई, बहुत ही कम सत्रों का मतलब है कि हैंडशेकिंग समय किसी भी अन्य प्रदर्शन कारकों को प्रभावित करेगा। लंबे सत्रों का अर्थ होगा सत्र की शुरुआत में हाथ मिलाने की लागत होगी, लेकिन बाद के अनुरोधों में अपेक्षाकृत कम ओवरहेड होगा।

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

Comments

जेम्स, उम्मीद कर रहा था कि आप इस aSSL समाधान की तुलनात्मक गति पर एक संक्षिप्त टिप्पणी प्रदान करने में सक्षम हो सकते हैं: assl.sullof.com/assl अपने सिर के ऊपर से, क्या प्रदर्शन-वार कुछ हासिल हुआ है? धन्यवाद!

— मैट गार्डनर

पुनश्च: यह मेरी समझ है कि इस समाधान के लिए क्लाइंट साइड की (जिसे वेबकिट / टाइटेनियम ऐप के मामले में लागू किया जा सकता है) की आवश्यकता होती है, लक्ष्य केवल आपके द्वारा उल्लिखित अन्य लोगों के साथ गति समीकरण के इस घटक को अधिकतम करने के लिए है।

— मैट गार्डनर

यह पोस्ट वास्तव में सवाल का जवाब नहीं देता है। ऐसा लगता है कि जिम ज्यूर्ट्स स्वयं HTTP और HTTPS के प्रदर्शन की प्रकृति के बारे में पूछ रहे हैं, विशेष कार्यान्वयन नहीं। HTTPS निर्विवाद रूप से धीमा है क्योंकि यह अधिक काम करता है। तो सवाल यह है कि कितना धीमा है? हर कोई जानता है कि यदि आप अधिक चर जोड़ते हैं, तो आपको अलग-अलग परिणाम मिलते हैं।

— इलियट कैमरन

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

— बोब्बोबो

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

— Jarek Przygódzki

Answer 2

HTTPS के लिए एक प्रारंभिक हैंडशेक की आवश्यकता होती है जो बहुत धीमा हो सकता है। हैंडशेक के हिस्से के रूप में हस्तांतरित डेटा की वास्तविक राशि बहुत बड़ी नहीं है (आमतौर पर 5 kB के तहत), लेकिन बहुत छोटे अनुरोधों के लिए, यह काफी अधिक ओवरहेड हो सकता है। हालांकि, एक बार हैंडशेक करने के बाद, सममित एन्क्रिप्शन का एक बहुत तेज़ रूप उपयोग किया जाता है, इसलिए ओवरहेड न्यूनतम है। नीचे पंक्ति: HTTPS पर बहुत से छोटे अनुरोध करना HTTP की तुलना में थोड़ा धीमा होगा, लेकिन यदि आप एक ही अनुरोध में बहुत अधिक डेटा स्थानांतरित करते हैं, तो अंतर महत्वहीन होगा।

हालाँकि, HTTP / 1.1 में मूलभूत व्यवहार डिफ़ॉल्ट रखा जाता है, इसलिए आप a करेंगे ही कनेक्शन पर ही हैंडशेक करेंगे और फिर बहुत सारे अनुरोध करेंगे। यह HTTPS के लिए एक महत्वपूर्ण अंतर बनाता है। आपको यह सुनिश्चित करने के लिए शायद आपकी साइट (जैसा कि दूसरों ने सुझाव दिया है) को प्रोफाइल करना चाहिए, लेकिन मुझे संदेह है कि प्रदर्शन अंतर ध्यान देने योग्य नहीं होगा।

Comments

यह पता चलता है कि एक ही सर्वर से कई कनेक्शनों का उपयोग करने वाले अधिकांश ब्राउज़रों के कारण, इस हैंडशेकिंग लागत का भुगतान प्रति सत्र लगभग 4-10x भुगतान किया जाएगा। एक ब्राउज़र के लिए https-Keep-ज़िंदा कितने समय तक निर्भर करता है, यह सत्र के दौरान बार-बार हो सकता है।

— जेम्स स्कैच

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

— ज़कार्तिक

@JamesSchek कई कनेक्शनों को एक ही एसएसएल सत्र का पुन: उपयोग करना चाहिए , जिससे तस्वीर काफी बदल जाती है। भले ही HTTP रखें-जीवित काम नहीं कर रहा है, तो भी लागू होता है

— लोर्ने की

@EJP यह सच है। और 2013 में, अधिकांश ब्राउज़र / सर्वर और एसएसएल / टीएलएस कार्यान्वयन सत्र पुनः उपयोग का उपयोग करते हैं। 2008 में, यह हमेशा एक सुरक्षित धारणा नहीं थी।

— जेम्स स्कैख

यह प्रश्न Google में "http बनाम https प्रदर्शन" के लिए उच्च दिखाता है। जबकि 2008 में ऊपर दिया गया उत्तर सही था, अब यह 2015 में सही नहीं है और इसे https का उपयोग करने से बचने के लिए निर्णय के आधार के रूप में उपयोग नहीं किया जाना चाहिए।

— पॉल Schreiber

Answer 3

वास्तव में यह समझने के लिए कि HTTPS आपकी विलंबता को कैसे बढ़ाएगा, आपको यह समझना होगा कि HTTPS कनेक्शन कैसे स्थापित होते हैं। यहाँ एक अच्छा चित्र है । कुंजी यह है कि क्लाइंट को 2 "पैर" (एक दौर की यात्रा के बाद डेटा प्राप्त करने के बजाय, आप एक अनुरोध भेजते हैं, सर्वर एक प्रतिक्रिया भेजता है), ग्राहक को कम से कम 4 पैर (2 गोल यात्राएं) तक डेटा नहीं मिलेगा । इसलिए, यदि क्लाइंट और सर्वर के बीच एक पैकेट को स्थानांतरित करने में 100 एमएस लगते हैं, तो आपका पहला HTTPS अनुरोध कम से कम 500 एमएस होगा।

बेशक, यह HTTPS कनेक्शन (जो ब्राउज़र को करना चाहिए) का फिर से उपयोग करके कम किया जा सकता है, लेकिन यह HTTPS वेब साइट को लोड करते समय उस प्रारंभिक स्टाल का हिस्सा समझाता है।

Comments

A जावा क्लाइंट के संदर्भ में, कोई HTTPS कनेक्शन को पुन: प्रयोज्य कैसे बना सकता है? मेरा मतलब है, क्या मैं HttpsConnection की एक स्थिर वस्तु बना सकता हूं और इसका फिर से उपयोग कर सकता हूं? (एक वेब अनुप्रयोग संदर्भ में)

— निक्स

5 साल बाद, अच्छा +1 चित्र का लिंक काम नहीं करता है, क्या कोई इसे ढूंढ सकता है और लिंक के बजाय उत्तर में रख सकता है?

— जिम वोल्फ

@FRoZen को वैकल्पिक लिंक मिला

— स्टीफन एल

इसके अलावा, मुझे लगता है कि यह पृष्ठ http का एक बहुत अच्छा चित्र पूरी तस्वीर को बेहतर ढंग से समझने के लिए है: blog.catchpoint.com/2010/09/17/anatomyhttp

— दृश्य

@ निखिल जावा स्वचालित रूप से अंतर्निहित कनेक्शन का पुन: उपयोग करता है और इसे अनुरोधों में साझा करता है, जब तक कि उपयोगकर्ता द्वारा मजबूर नहीं किया जाता है disconnect। डॉक्स की जाँच करें ।

— मोहनीश

Answer 4

ओवरहेड एन्क्रिप्शन के कारण नहीं है। आधुनिक सीपीयू पर, SSL द्वारा आवश्यक एन्क्रिप्शन तुच्छ है।

ओवरहेड एसएसएल हैंडशेक के कारण होता है, जो एक HTTP पर HTTPS सत्र के लिए आवश्यक राउंड-ट्रिप की संख्या को काफी लंबा और काफी बढ़ाता है।

उपाय (सर्वर जैसे फायरबग का उपयोग करके) पृष्ठ लोड समय जबकि सर्वर एक नकली उच्च-विलंबता लिंक के अंत में है। उच्च अक्षांश लिंक को अनुकरण करने के लिए उपकरण मौजूद हैं - लिनक्स के लिए "नेटेम" है। एक ही सेटअप पर एचटीटीपीएस के साथ एचटीटीपी की तुलना करें।

विलंबता को कुछ हद तक कम किया जा सकता है:

• यह सुनिश्चित करना कि आपका सर्वर HTTP कीपेलिव्स का उपयोग कर रहा है - यह क्लाइंट को SSL सत्रों का पुन: उपयोग करने की अनुमति देता है, जो दूसरे हैंडशेक की आवश्यकता से बचा जाता है
• जहां तक ​​संभव हो - अनुरोधों की संख्या को कम करना - जहां संभव हो संसाधनों को मिलाकर (जैसे .js में फाइलें, सीएसएस शामिल हैं) और क्लाइंट-साइड कैशिंग को प्रोत्साहित करना।
• पृष्ठ लोड की संख्या को कम करें, उदाहरण के लिए पृष्ठ में डेटा लोड करने की आवश्यकता नहीं है (शायद एक छिपे हुए HTML तत्व में) और फिर क्लाइंट-स्क्रिप्ट का उपयोग करके इसे दिखा रहा है।

Comments

मैं @MarkR के साथ बहुत कॉनक्योर करता हूं। मेरे होमपेज के मेरे हालिया प्रोफाइल, HTTP बनाम HTTPS, औसत लोड समय क्रमशः 1.5s और 4.5s थे। जब कनेक्शन के विवरण को देखते हैं, तो बड़े हैंडसम कारक SSL हैंडशेक के कारण अतिरिक्त राउंड ट्रिप थे। 3G से अधिक मोबाइल ब्राउज़र और भी बदतर थे। संख्या क्रमशः 5s और 9s थी।

— क्लिंट पच

Answer 5

दिसंबर 2014 अपडेट

आप आसानी से HTTP और HTTPS प्रदर्शन के बीच अंतर को अपने खुद के ब्राउज़र में HTTP बनाम HTTPS Test वेबसाइट पर AnthumChris द्वारा प्रयोग कर सकते हैं : “यह पृष्ठ असुरक्षित HTTP और एन्क्रिप्टेड HTTPS कनेक्शन पर अपने लोड समय को मापता है। दोनों पृष्ठ 360 अद्वितीय, गैर-कैश्ड चित्र (2.04 MB कुल) लोड करते हैं। ”

परिणाम आपको चौंका सकते हैं।

HTTPS प्रदर्शन के बारे में जानकारी रखना महत्वपूर्ण है, क्योंकि लेट्स एनक्रिप्ट सर्टिफिकेट अथॉरिटी समर 2015 में फ्री, ऑटोमेटेड और ओपन एसएसएल सर्टिफिकेट जारी करना शुरू कर देगी, जिसका श्रेय मोज़िला, अकमाई, सिस्को, इलेक्ट्रॉनिक फ्रंटियर फाउंडेशन और आइडेंटट्रस्ट को दिया जाएगा।

जून 2015 अपडेट

आइए एनक्रिप्ट पर अपडेट करें - सितंबर 2015 तक पहुंचने:

• चलो लॉन्च अनुसूची को एन्क्रिप्ट करें (जून 16, 2015)
• आइए एन्क्रिप्ट करें रूट और इंटरमीडिएट प्रमाण पत्र (जून 4, 2015)
• ड्राफ़्ट सब्सक्राइबर एग्रीमेंट को एन्क्रिप्ट करें (21 मई, 2015)

ट्विटर पर अधिक जानकारी: @letsencrypt

HTTPS और SSL / TLS प्रदर्शन के बारे में अधिक जानकारी के लिए देखें:

• क्या टीएलएस फास्ट है फिर भी?
• उच्च प्रदर्शन ब्राउज़र नेटवर्किंग, अध्याय 4: परिवहन परत सुरक्षा
• ओवरक्लॉकिंग एसएसएल
• एसएसएल प्रसंस्करण का एनाटॉमी और प्रदर्शन

HTTPS उपयोग के महत्व के बारे में अधिक जानकारी के लिए देखें:

• सब कुछ के लिए HTTPS क्यों? (HTTPS- ओनली स्टैंडर्ड)
• आइए एनक्रिप्ट (इंटरनेट सुरक्षा अनुसंधान समूह)
• HTTPS एवरीवन (इलेक्ट्रॉनिक फ्रंटियर फाउंडेशन)

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

क्रिस के लिए धन्यवाद - HTTP बनाम एचटीटीपीएस टेस्ट बेंचमार्क के लेखक - अपनी टिप्पणियों के लिए नीचे।

Comments

यह "HTTP बनाम HTTPS टेस्ट" जानबूझकर धोखा दे रहा है, कृपया इसे लिंक न करें। वह पृष्ठ जो वास्तव में करता है, HTTP की तुलना SPDY से करता है । यह सच है, यदि आप मुझ पर विश्वास नहीं करते हैं, तो इसे IE में आज़माएं और देखें कि यह क्या कहता है। ऐसी कोई स्थिति नहीं है जहां एचटीटीपी अनुरोध समकक्ष एचटीटीपीएस अनुरोध की तुलना में तेज है।

— orrd

Google ने SPDY को केवल राजनीतिक कारणों के लिए सुरक्षित कनेक्शन का उपयोग करने के लिए मजबूर किया, न कि तकनीकी लोगों के लिए। HTTP / 2 (जो SPDY की समान गति सुधार तकनीकों का उपयोग करता है) एक असुरक्षित कनेक्शन का उपयोग कर सकता है, और जब यह होता है तो यह थोड़ा तेज़ होता है। एक असुरक्षित कनेक्शन अभी भी एक ही प्रोटोकॉल का उपयोग करके सुरक्षित कनेक्शन की तुलना में हमेशा कम से कम थोड़ा तेज होता है। "HTTP बनाम HTTPS टेस्ट" जानबूझकर भ्रामक और भ्रामक है।

— orrd

वेबसाइट वास्तविक संख्याओं के साथ एक मात्रात्मक तुलना प्रदान करती है, और यह अधिक से अधिक लोगों को HTTPS के साथ अपने उपयोगकर्ताओं की सुरक्षा के लिए प्रोत्साहित करने का एक प्रयास है। राय केवल हमें इतनी दूर ले जाती है, और हमें हमेशा HTTP पर IE के लिए धीमी, असुरक्षित एप्लिकेशन बनाने की स्वतंत्रता है। मैं हमेशा HTTPS के साथ Chrome / Firefox के लिए तेज़, ब्लीडिंग-एज और सुरक्षित वेब एप्लिकेशन के निर्माण के लिए मतदान करूंगा।

— एंथुमक्रिस

Httpvshttps.com पर अंकगणित गलत दिखता है: 34 सेकंड की तुलना में 1.7 सेकंड "95% तेज" नहीं है। यह 20 × तेज़ या 1900% तेज़ है। इसे अवधि की बजाय गति की तुलना करनी चाहिए।

— कर्नल पैनिक

परीक्षण भ्रामक और धोखा देने वाला है। प्रति टूल्स.ietf.org/html/rfc7540#section-3.2 कोई कारण नहीं है कि HTTP / 2 का उपयोग गैर-सुरक्षित कनेक्शन पर नहीं किया जा सकता है। बड़ी कंपनियां यूनिवर्सल HTTPS के उपयोग पर जोर दे रही हैं। कारण अलग-अलग होते हैं। लेकिन तथ्य यह है। जब तक पृष्ठ पर व्यक्तिगत डेटा नहीं है तब तक एसएसएल चलाने का कोई कारण नहीं है। और हाँ, आज के कंप्यूटरों के साथ एसएसएल हैंडशेक तुच्छ है। अगर हम यह कहना शुरू करते हैं और यह तुच्छ सामान है तो बस टूट जाएगा। HTTP / 1.1 बनाम HTTP / 1.1 SSL और HTTP / 2 बनाम HTTP / 2 SSL का 1: 1 परीक्षण करें। फिर चर्चा करें।

— शिन्राइ

Answer 6

वर्तमान शीर्ष उत्तर पूरी तरह से सही नहीं है।

जैसा कि अन्य लोगों ने यहां बताया है, https के लिए हैंडशेकिंग की आवश्यकता होती है और इसलिए अधिक TCP / IP राउंडट्रिप्स करता है।

WAN परिवेश में आमतौर पर तब विलंबता सीमित कारक बन जाती है और सर्वर पर CPU उपयोग में वृद्धि नहीं होती है।

बस यह ध्यान रखें कि यूरोप से अमेरिका तक की विलंबता लगभग 200 एमएस (टोरंडट्रिप समय) हो सकती है।

आप इसे (एकल उपयोगकर्ता मामले के लिए) HTTPWatch के साथ आसानी से माप सकते हैं ।

Answer 7

अब तक बताई गई हर चीज के अलावा, कृपया ध्यान रखें कि कुछ (सभी?) वेब ब्राउजर सुरक्षा कारणों से स्थानीय हार्ड-ड्राइव पर HTTPS पर प्राप्त कैश्ड कंटेंट को स्टोर नहीं करते हैं। इसका अर्थ यह है कि ब्राउज़र के पुनः आरंभ होने के बाद उपयोगकर्ता के परिप्रेक्ष्य पृष्ठों से बहुत सारी स्थिर सामग्री धीमी हो जाएगी, और आपके सर्वर के दृष्टिकोण से HTTPS पर स्थिर सामग्री के लिए अनुरोधों की मात्रा HTTP से अधिक हो जाएगी।

Comments

हेडर "कैच-कंट्रोल: मैक्स-एज = एक्स, पब्लिक" को भेजना, सामग्री को कैश करने के लिए आधुनिक ब्राउज़रों (बस परीक्षित FF4, Chrome12, IE8, IE9) का कारण होगा। हालाँकि, मैंने देखा कि ये ब्राउज़र एक सशर्त GET भेजते हैं, जो अतिरिक्त दौर की यात्राओं के लिए अतिरिक्त विलंबता पैदा कर सकता है, खासकर अगर एक SSL कनेक्शन कैश नहीं किया गया है (Keep Alive)।

— क्लिंट पाच

Answer 8

इसके लिए एक भी उत्तर नहीं है।

एन्क्रिप्शन हमेशा अधिक CPU का उपभोग करेगा। यह कई मामलों में समर्पित हार्डवेयर को लोड किया जा सकता है, और चयनित एल्गोरिथ्म की लागत अलग-अलग होगी। उदाहरण के लिए, एईएस की तुलना में 3 गुना अधिक महंगा है। कुछ एल्गोरिदम डिक्रिप्टर की तुलना में एनक्रिप्ट के लिए अधिक महंगे हैं। कुछ की विपरीत लागत है।

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

क्रॉस इंटरनेट ट्रैफ़िक के लिए आप अपने डेटा दर में इस लागत को नहीं देख सकते हैं, क्योंकि उपलब्ध बैंडविड्थ बहुत कम है। लेकिन आप इसे व्यस्त सर्वर पर सीपीयू उपयोग में अवश्य देखेंगे।

Answer 9

मैं आपको (एक डायलअप उपयोगकर्ता के रूप में) बता सकता हूं कि एसएसएल पर एक ही पृष्ठ नियमित HTTP की तुलना में कई गुना धीमा है ...

Comments

अच्छी बात। मैंने यह भी पाया कि मोबाइल फोन नेटवर्क (3G) के माध्यम से लोड समय भी 2x से 3x धीमा है।

— क्लिंट पाच

हां! उस उत्तर के डेढ़ साल बाद, मैं एक नए घर में चला गया और आखिरकार POTS लाइन से कम पैसे में DSL पर स्विच करने में सक्षम था!

— ब्रायन नोब्लुक

Answer 10

कई मामलों में एसएसएल हैंडशेक के प्रदर्शन प्रभाव को इस तथ्य से कम किया जाएगा कि एसएसएल सत्र को दोनों छोर (डेस्कटॉप और सर्वर) पर कैश किया जा सकता है। विंडोज मशीनों पर उदाहरण के लिए एसएसएल सत्र को 10 घंटे तक कैश किया जा सकता है। Http://support.microsoft.com/kb/247658/EN-US देखें । कुछ एसएसएल एक्सेलेरेटर में पैरामीटर भी होंगे जो आपको सत्र को कैश करने के समय को ट्यून करने की अनुमति देगा।

विचार करने के लिए एक और प्रभाव यह है कि HTTPS से अधिक स्थिर सामग्री को प्रॉक्सी द्वारा कैश नहीं किया जाएगा, और यह एक ही प्रॉक्सी पर साइट तक पहुँचने वाले कई उपयोगकर्ताओं के प्रदर्शन को कम कर सकता है। यह इस तथ्य से कम किया जा सकता है कि जब तक कि अन्यथा करने के निर्देश नहीं दिए जाते हैं, तब तक स्थिर सामग्री को डेस्कटॉप पर कैश किया जाएगा, इंटरनेट एक्सप्लोरर संस्करण 6 और 7 कैश कैशेबल एचटीटीपीएस स्थिर सामग्री। डिस्क के लिए)।

Answer 11

मैंने एक छोटा सा प्रयोग किया और फ्लिकर (233 केबी) से एक ही छवि के लिए 16% समय का अंतर मिला:

http://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg

https://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg

बेशक ये संख्या कई कारकों पर निर्भर करती है, जैसे कि कंप्यूटर का प्रदर्शन, कनेक्शन की गति, सर्वर लोड, पथ पर QoS (ब्राउज़र से सर्वर के लिए लिया गया विशेष नेटवर्क पथ) लेकिन यह सामान्य विचार दिखाता है: HTTPS धीमा है तब HTTP, तब से पूरा करने के लिए अधिक संचालन की आवश्यकता है (एसएसएल हैंडशेकिंग और एन्कोडिंग / डिकोडिंग डेटा)।

Comments

प्रत्येक के लिए 2 अनुरोधों पर आधारित सांख्यिकीय विश्लेषण मीट्रिक नहीं बना सकते।

— टॉम रोजगारो

Answer 12

यहाँ SSL हाथ मिलाना विलंबता पर एक बढ़िया लेख (थोड़ा पुराना, लेकिन अभी भी बहुत अच्छा) है। मुझे उन ग्राहकों के लिए सुस्ती के मुख्य कारण के रूप में एसएसएल की पहचान करने में मदद मिली जो धीमे इंटरनेट कनेक्शन के माध्यम से मेरे ऐप का उपयोग कर रहे थे:

http://www.semicomplete.com/blog/geekery/ssl-latency.html

Answer 13

चूंकि मैं अपने प्रोजेक्ट के लिए उसी समस्या की जांच कर रहा हूं, इसलिए मुझे ये स्लाइड मिलीं। पुराना लेकिन दिलचस्प:

http://www.cs.nyu.edu/artg/research/comparison/comparison_slides/sld001.htm

Comments

मैंने सरलीकृत आरेखों को मददगार पाया, लेकिन थोड़ी कमी भी। मुझे लगता है कि http के लिए इस पृष्ठ की दौर यात्राओं की संख्या को समझना बेहतर है: blog.catchpoint.com/2010/09/17/anatomyhttp फिर जैसे ही मैं https के लिए बता सकता हूं: हम एक राउंड ट्रिप जोड़ते हैं।

— अण्डाकार दृश्य

Answer 14

लगता है यहाँ एक गंदा मामला है: Ajax congested wifi पर।

अजाक्स का आमतौर पर मतलब होता है कि KeepAlive ने 20 सेकंड कहने के बाद समय समाप्त कर लिया है। हालाँकि, wifi का अर्थ है कि (आदर्श रूप से तेज़) ajax कनेक्शन को कई राउंड ट्रिप करने हैं। इससे भी बदतर, वाईफाई अक्सर पैकेट खो देता है, और टीसीपी रिट्रांसमिट होते हैं। इस मामले में, HTTPS वास्तव में बहुत खराब प्रदर्शन करता है!

Answer 15

क्या टीएलएस अभी तक तेज है?हाँ।

• देखें: https://www.youtube.com/watch?v=0EB7zh_7UE4
• पढ़ें: https://istlsfastyet.com/

वहाँ कई परियोजनाएँ हैं जिनका उद्देश्य लाइनों को धुंधला करना और एचटीटीपीएस को बस तेज करना है। जैसे SPDY और mod-spdy ।

Answer 16

HTTP VS HTTPS परफ़ॉर्मर कंपेरिजन

सादे पुराने HTTP की तुलना में मैंने धीमे पृष्ठ लोड समय के साथ HTTPS को हमेशा जोड़ा है। एक वेब डेवलपर के रूप में, वेब पेज का प्रदर्शन मेरे लिए महत्वपूर्ण है और कुछ भी जो मेरे वेब पेजों के प्रदर्शन को धीमा कर देगा, नहीं-नहीं है।

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

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

प्रदर्शन के निहितार्थ को समझने और अपने आप को देखने के लिए कि प्रदर्शन प्रभाव महत्वपूर्ण होगा या नहीं, मैंने इस साइट को परीक्षण मंच के रूप में उपयोग किया। मैं webpagetest.org की ओर गया और एचटीटीपीएस बनाम एचटीटीपी का उपयोग करके इस साइट की तुलना करने के लिए दृश्य तुलना उपकरण का उपयोग किया।

जैसा कि आप देख सकते हैं यहां कि टेस्ट वीडियो परिणाम है HTTPS का उपयोग करने से मेरे पृष्ठ लोड समय पर प्रभाव पड़ता है, हालांकि यह अंतर नगण्य है और मैंने केवल 300 मिलीसेकंड अंतर पर ध्यान दिया है। यह ध्यान रखना महत्वपूर्ण है कि ये समय कई कारकों पर निर्भर करता है, जैसे कि कंप्यूटर का प्रदर्शन, कनेक्शन की गति, सर्वर लोड और सर्वर से दूरी।

आपकी साइट अलग हो सकती है, और HTTPS पर स्विच करने में शामिल प्रदर्शन प्रभाव को अच्छी तरह से जांचना और उसकी जांच करना महत्वपूर्ण है।

Comments

सामान्य तौर पर उदाहरण अच्छा है लेकिन यह चित्रित की तुलना में अधिक शामिल है, विशेष रूप से परफेक्ट फॉरवर्ड सेक्रेसी के साथ। इसके अलावा वास्तव में उपयोग में चार सममित कुंजी हैं।

— zaph

Answer 17

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

Answer 18

HTTPS में एन्क्रिप्शन / डिक्रिप्शन ओवरहेड है इसलिए यह हमेशा थोड़ा धीमा रहेगा। SSL समाप्ति बहुत सीपीयू गहन है। यदि आपके पास एसएसएल को बंद करने के लिए उपकरण हैं, तो आपके सर्वर के लोड के आधार पर विलंब में अंतर मुश्किल से ध्यान देने योग्य हो सकता है।

Answer 19

एक और महत्वपूर्ण प्रदर्शन अंतर यह है कि एक HTTPS सत्र ketp खुला है जबकि उपयोगकर्ता जुड़ा हुआ है। एक HTTP 'सत्र' केवल एक आइटम अनुरोध के लिए रहता है।

यह आप बड़ी संख्या में समवर्ती उपयोगकर्ताओं के साथ एक साइट चला रहे हैं, बहुत सारी मेमोरी खरीदने की उम्मीद करते हैं।

Comments

गैर HTTP 1.1 में। कनेक्शन लंबे समय तक खुले छोड़ दिए जाते हैं।

— स्किलिविज

Answer 20

यह लगभग निश्चित रूप से सच होने जा रहा है कि एसएसएल को एन्क्रिप्शन के एक अतिरिक्त चरण की आवश्यकता है जो कि केवल गैर-एसएलएल एचटीटीपी द्वारा आवश्यक नहीं है।

Comments

कि दोनों मामलों के बीच प्रदर्शन में अंतर है।

— डेविड द मैन

लेकिन quesiton है "क्या http और https के बीच प्रदर्शन में कोई बड़ा अंतर है?"

— स्किलिविज़

Answer 21

HTTPS वास्तव में पृष्ठ गति को प्रभावित करता है ...

ऊपर दिए गए उद्धरण साइट सुरक्षा और गति के बारे में कई लोगों की मूर्खता को प्रकट करते हैं। HTTPS / SSL सर्वर हैंडशेकिंग इंटरनेट कनेक्शन बनाने के लिए एक प्रारंभिक स्टाल बनाता है। आपके आगंतुक के ब्राउज़र स्क्रीन पर कुछ भी प्रस्तुत करने से पहले धीमी गति से देरी हो रही है। यह विलंब टाइम-टू-फर्स्ट-बाइट जानकारी में मापा जाता है।

HTTPS हैंडशेक ओवरहेड टाइम-टू-फर्स्ट-बाइट जानकारी (TTFB) में दिखाई देता है। आम TTFB 100 मिलीसेकंड (सबसे अच्छा मामला) से लेकर 1.5 सेकंड (सबसे खराब स्थिति) तक होता है। लेकिन, निश्चित रूप से, HTTPS के साथ यह 500 मिलीसेकंड खराब है।

राउंडट्रिप, वायरलेस 3 जी कनेक्शन 500 मिलीसेकंड या अधिक हो सकते हैं। अतिरिक्त यात्राएं 1 सेकंड या उससे अधिक के लिए दोहरी देरी करती हैं। यह मोबाइल प्रदर्शन पर एक बड़ा, नकारात्मक प्रभाव है। बहुत बुरी खबर है।

मेरी सलाह, यदि आप संवेदनशील डेटा का आदान-प्रदान नहीं कर रहे हैं, तो आपको एसएसएल की आवश्यकता नहीं है, लेकिन यदि आप एक ई-कॉमर्स वेबसाइट की तरह हैं, तो आप एचटीटीपीएस को उन निश्चित पृष्ठों पर सक्षम कर सकते हैं, जहां संवेदनशील डेटा लॉगिन और चेकआउट जैसे एक्सचेंज किए जाते हैं।

स्रोत: पेजपाइप

Answer 22

ब्राउज़र HTTP / 1.1 प्रोटोकॉल को HTTP या HTTPS के साथ स्वीकार कर सकते हैं, फिर भी ब्राउज़र केवल HTTPS के साथ HTTP / 2.0 प्रोटोकॉल को संभाल सकते हैं। HTTP / 1.1 से HTTP / 1.1 के प्रोटोकॉल अंतर, HTTP / 2.0 बनाते हैं, औसतन, HTTP / 1.1 से 4-5 गुना तेज। इसके अलावा, ऐसी साइटें जो HTTPS को लागू करती हैं, ज्यादातर HTTP / 2.0 प्रोटोकॉल पर ऐसा करती हैं। इसलिए, HTTPS लगभग हमेशा HTTP से अधिक तेज होने जा रहा है बस अलग-अलग प्रोटोकॉल के कारण इसका आमतौर पर उपयोग होता है। हालाँकि, अगर HTTP / 1.1 से अधिक HTTP की तुलना HTTP / 1.1 से अधिक HTTPS से की जाती है, तो HTTP, HTTPS की तुलना में औसत रूप से थोड़ा तेज़ है।

यहां कुछ तुलनाएं दी गई हैं जिन्हें मैंने क्रोम (Ver। 64) का उपयोग करके चलाया था:

HTTP / 1.1 पर HTTPS:

• 0.47 सेकंड औसत पृष्ठ लोड समय
• HTTP / 1.1 से HTTP से 0.05 सेकंड धीमा
• HTTP / 2.0 पर HTTPS से 0.37 सेकंड धीमा

HTTP / 1.1 पर HTTP

• 0.42 सेकंड औसत पृष्ठ लोड समय
• HTTP / 1.1 से अधिक HTTPS से 0.05 सेकंड
• HTTP / 2.0 पर HTTPS से 0.32 सेकंड धीमा

HTTP / 2.0 पर HTTPS

• 0.10 सेकंड औसत लोड समय
• HTTP / 1.1 से HTTP से 0.32 सेकंड तेज
• HTTPS / 1.1 से HTTPS की तुलना में 0.37 सेकंड अधिक तेज़