[performance] HTTP 대 HTTPS 성능

Program / 글쓴이

http와 https의 성능에 큰 차이가 있습니까? HTTPS가 HTTP보다 5 배 빠를 수 있다는 점을 기억하는 것 같습니다. 현재 세대의 웹 서버 / 브라우저에서 유효합니까? 그렇다면이를 지원할 백서가 있습니까?

답변

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

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

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

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

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

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

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

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

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

답변

HTTPS에는 초기 핸드 셰이크가 필요하며 매우 느릴 수 있습니다. 핸드 셰이크의 일부로 전송되는 실제 데이터 양은 크지 않지만 (일반적으로 5kB 미만) 매우 작은 요청의 경우 약간의 오버 헤드가 발생할 수 있습니다. 그러나 핸드 셰이크가 완료되면 매우 빠른 형태의 대칭 암호화가 사용되므로 오버 헤드가 최소화됩니다. 결론 : HTTPS를 통해 짧은 요청을 많이하는 것은 HTTP보다 약간 느리지 만 단일 요청으로 많은 양의 데이터를 전송하면 그 차이는 중요하지 않습니다.

그러나 keepalive는 HTTP / 1.1의 기본 동작이므로 단일 핸드 셰이크 를 수행 한 다음 동일한 연결을 통해 많은 요청을 수행합니다. 이것은 HTTPS에 큰 차이를 만듭니다. 아마도 다른 사람들이 제안한대로 사이트를 프로파일 링해야하지만 성능 차이가 눈에 띄지 않을 것으로 생각됩니다.

답변

HTTPS가 대기 시간을 늘리는 방법을 실제로 이해하려면 HTTPS 연결 설정 방법을 이해해야합니다. 여기 좋은 다이어그램이 있습니다. 중요한 점은 클라이언트가 2 개의 “다리”(데이터를 1 회 왕복, 요청을 보내고 서버가 응답을 보낸 후) 후에 데이터를 가져 오는 대신 클라이언트가 최소 4 개의 다리 (2 회 왕복)까지 데이터를받지 못한다는 것입니다. . 따라서 클라이언트와 서버간에 패킷이 이동하는 데 100ms가 걸리면 첫 번째 HTTPS 요청에 최소 500ms가 걸립니다.

물론 이는 HTTPS 연결 (브라우저가 수행해야 함)을 다시 사용하여 완화 할 수 있지만 HTTPS 웹 사이트를로드 할 때 초기 중단의 일부를 설명합니다.

답변

오버 헤드는 암호화로 인한 것이 아닙니다. 최신 CPU에서는 SSL에 필요한 암호화가 쉽지 않습니다.

오버 헤드는 SSL 핸드 셰이크에 기인하며, HTTP 핸드 셰이크를 통한 HTTPS 세션에 필요한 왕복 횟수가 길고 크게 증가합니다.

서버가 시뮬레이션 된 대기 시간이 긴 링크의 끝에있는 동안 페이지로드 시간을 측정 (Firebug와 같은 도구를 사용하여)하십시오. 대기 시간이 긴 링크를 시뮬레이트하기위한 도구가 존재합니다. Linux에는 “netem”이 있습니다. 동일한 설정에서 HTTP와 HTTPS를 비교하십시오.

대기 시간은 다음을 통해 어느 정도 완화 할 수 있습니다.

  • 서버가 HTTP Keepalives를 사용하고 있는지 확인-클라이언트가 SSL 세션을 재사용 할 수 있으므로 다른 핸드 셰이크가 필요하지 않습니다.
  • 가능한 한 리소스를 결합하고 (예 : .js 포함 파일, CSS) 클라이언트 측 캐싱을 장려하여 요청 수를 가능한 한 줄입니다.
  • 예를 들어 페이지에 필요하지 않은 데이터를로드하고 (아마 숨겨진 HTML 요소로) 클라이언트 스크립트를 사용하여 표시하는 등의 페이지로드 수를 줄입니다.

답변

2014 년 12 월 업데이트

AnthumChris 의 HTTP vs HTTPS 테스트 웹 사이트를 사용하여 자체 브라우저에서 HTTP와 HTTPS 성능의 차이를 쉽게 테스트 할 수 있습니다 .“이 페이지는 안전하지 않은 HTTP 및 암호화 된 HTTPS 연결에 대한로드 시간을 측정합니다. 두 페이지 모두 캐시되지 않은 360 개의 고유 이미지를로드합니다 (총 2.04MB).”

결과는 당신을 놀라게 할 수 있습니다.

Let ‘s Encrypt 인증 기관은 Mozilla, Akamai, Cisco, Electronic Frontier Foundation 및 IdenTrust 덕분에 2015 년 여름 무료, 자동화 및 공개 SSL 인증서 발급을 시작 하기 때문에 HTTPS 성능에 대한 최신 정보를 알고 있어야합니다 .

2015 년 6 월 업데이트

Let ‘s Encrypt에 대한 업데이트-2015 년 9 월 도착 :

트위터에 대한 추가 정보 : @letsencrypt

HTTPS 및 SSL / TLS 성능에 대한 자세한 내용은 다음을 참조하십시오.

HTTPS 사용의 중요성에 대한 자세한 내용은 다음을 참조하십시오.

이를 요약하면, 내가 인용하자 일리야 그리고 릭을 : “TLS는 정확히 하나의 성능 문제가 있습니다 : 그것은 충분히 넓게 사용되지 않는 모든 다른 최적화 할 수 있습니다..”

아래의 의견에 대해 HTTP – HTTPS 테스트 벤치 마크 작성자 인 Chris 에게 감사 합니다.

답변

현재 최고 답변 이 완전히 정확하지 않습니다.

다른 사람들이 지적했듯이 https에는 핸드 쉐이킹이 필요하므로 더 많은 TCP / IP 왕복이 필요합니다.

WAN 환경에서는 일반적으로 대기 시간이 서버의 CPU 사용량 증가가 아니라 제한 요소가됩니다.

유럽에서 미국까지의 대기 시간은 약 200ms (토론 트립 시간) 일 수 있습니다.

HTTPWatch를 사용하여 (단일 사용자의 경우)이를 쉽게 측정 할 수 있습니다 .

답변

지금까지 언급 한 모든 것 외에도 일부 (모든?) 웹 브라우저는 보안상의 이유로 HTTPS를 통해 얻은 캐시 된 컨텐츠를 로컬 하드 드라이브에 저장하지 않습니다. 이는 정적 콘텐츠가 많은 사용자의 관점 페이지에서 브라우저가 다시 시작된 후 느리게로드되는 것으로 나타나고 서버의 관점에서 HTTPS를 통한 정적 컨텐츠 요청의 양이 HTTP를 통한 것보다 많음을 의미합니다.