이에 대한 매우 간단한 답변이 있습니다. 웹 서버의 성능을 프로파일 링하여 특정 상황에 대한 성능 저하를 확인하십시오. HTTP와 HTTPS 서버의 성능을 비교할 수있는 몇 가지 도구가 있으며 (JMeter와 Visual Studio를 염두에두고) 사용하기 매우 쉽습니다.

아무도없이 당신에게 의미있는 대답을 줄 수없는 일부 웹 사이트, 하드웨어, 소프트웨어 및 네트워크 구성의 특성에 대한 정보를 제공합니다.

다른 사람들이 말했듯이 암호화로 인해 어느 정도의 오버 헤드가 발생하지만 다음에 크게 의존합니다.

• 하드웨어
• 서버 소프트웨어
• 동적 콘텐츠와 정적 콘텐츠의 비율
• 서버까지의 클라이언트 거리
• 일반적인 세션 길이
• 기타 (개인적으로 좋아하는 것)
• 클라이언트의 캐싱 동작

필자의 경험에 따르면 동적 콘텐츠가 많은 서버는 암호화 시간 (SSL-overhead)이 콘텐츠 생성 시간에 비해 중요하지 않기 때문에 HTTPS의 영향을 덜받는 경향이 있습니다.

메모리에 쉽게 캐싱 될 수있는 상당히 작은 정적 페이지 세트를 제공하는 데 무거운 서버는 훨씬 높은 오버 헤드를 겪게됩니다 (한 경우에는 “인트라넷”에서 처리량이 발생 함).

편집 : 여러 다른 사람들이 제기 한 한 가지 점은 SSL 핸드 쉐이킹이 HTTPS의 주요 비용이라는 것입니다. “일반적인 세션 길이”와 “클라이언트의 캐싱 동작”이 중요한 이유입니다.

매우 짧은 세션은 핸드 셰이 킹 시간이 다른 성능 요소를 압도한다는 것을 의미합니다. 세션이 길면 세션 시작시 핸드 셰이 킹 비용이 발생하지만 후속 요청의 오버 헤드는 상대적으로 낮습니다.

클라이언트 캐싱은 대규모 프록시 서버에서 개별 브라우저 캐시에 이르기까지 여러 단계로 수행 할 수 있습니다. 일반적으로 HTTPS 컨텐츠는 공유 캐시에 캐시되지 않습니다 (그러나 일부 프록시 서버는 중간자 (man-in-the-middle) 유형 동작을 이용하여이를 달성 할 수 있습니다). 많은 브라우저가 현재 세션에 대한 HTTPS 컨텐츠를 캐시하고 종종 세션 전체에 걸쳐 시간을 캐시합니다. 캐싱하지 않거나 캐싱이 적은 영향은 클라이언트가 동일한 컨텐츠를 더 자주 검색 함을 의미합니다. 따라서 동일한 수의 사용자에게 서비스를 제공하기 위해 더 많은 요청과 대역폭이 발생합니다.

답변