it-swarm.dev

HTTP 대 HTTPS 성능

Http와 https 사이에 성능에 큰 차이가 있습니까? 나는 HTTPS가 HTTP만큼 빠르다는 것을 읽은 것을 기억하는 것 같다. 현재 세대의 웹 서버/브라우저에서 유효합니까? 그렇다면 지원할 백서가 있습니까?

356
Jim Geurts

이것에 대한 간단한 대답이 있습니다 : ) 웹 서버의 성능을 프로파일 링하여 특정 상황에 대해 성능 저하가 무엇인지 확인하십시오. 여러 도구가 있습니다. HTTP vs HTTPS 서버 (JMeter 및 Visual Studio를 염두에 두어야합니다)의 성능을 비교할 수 있으며 사용하기가 쉽습니다.

어느 누구도 웹 사이트, 하드웨어, 소프트웨어 및 네트워크 구성의 특성에 대해 some 정보가 없으면 의미있는 대답을 줄 수 없습니다.

다른 사람들이 말했듯이, 암호화로 인해 일정 수준의 오버 헤드가있을 수 있지만 다음에 크게 의존합니다.

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

내 경험에 비추어 볼 때, 동적 콘텐츠에 무거운 서버는 HTTPS로 인해 영향을 덜받는 경향이 있습니다. 암호화 시간 (SSL 오버 헤드)이 콘텐츠 생성 시간에 비해 중요하지 않기 때문입니다.

메모리에 쉽게 캐싱 될 수있는 상당히 작은 정적 페이지 세트를 제공하는 데 많은 부하를받는 서버는 훨씬 높은 오버 헤드로 고통을 겪습니다 (하나의 경우 "인트라넷"에서 처리량이 발생 함).

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

매우 짧은 세션이 많기 때문에 핸드 셰이 킹 시간이 다른 성능 요소를 압도하게됩니다. 세션이 길어질수록 세션 시작시 핸드 셰이크 비용이 발생하지만 후속 요청의 경우 상대적으로 낮은 오버 헤드가 발생합니다.

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

226
James Schek

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

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

214
Graeme Perrow

HTTPS가 대기 시간을 증가시키는 방식을 실제로 이해하려면 HTTPS 연결 설정 방법을 이해해야합니다. 여기에 멋진 다이어그램 가 있습니다. 열쇠는 클라이언트가 2 "다리"(1 왕복, 요청 보내기, 서버가 응답) 후에 데이터를 가져 오는 대신 클라이언트가 적어도 4 다리 (2 왕복)까지 데이터를 얻지 못한다는 것입니다. . 따라서 패킷이 클라이언트와 서버간에 이동하는 데 100ms가 걸리면 첫 번째 HTTPS 요청에 적어도 500ms가 걸립니다.

물론 이것은 HTTPS 연결을 재사용함으로써 완화 될 수 있지만 HTTPS 웹 사이트를로드 할 때 초기 정지의 일부를 설명합니다.

100
twk

오버 헤드는 암호화로 인한 것이 아닙니다. 최신 CPU의 경우 SSL에 필요한 암호화는 간단합니다.

오버 헤드는 SSL 핸드 셰이크에 기인합니다. 길기 때문에 HTTP보다 HTTPS 세션에 필요한 왕복 횟수가 크게 늘어납니다.

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

대기 시간은 다음과 같이 어느 정도 완화 될 수 있습니다.

  • 서버가 HTTP 킵 얼라이브를 사용하는지 확인 - 클라이언트가 SSL 세션을 재사용 할 수 있으므로 다른 핸드 쉐이크가 필요 없습니다.
  • 요청 수를 최대한 줄입니다. - 가능한 한 리소스 (예 : .js 파일, CSS 포함)를 결합하고 클라이언트 측 캐싱 권장
  • 페이지로드 수를 줄입니다. 페이지에 필요없는 데이터 (예 : 숨겨진 HTML 요소)를로드 한 다음 클라이언트 스크립트를 사용하여 페이지를 표시합니다.
76
MarkR

2014 년 12 월 업데이트

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

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

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

2015 년 6 월 업데이트

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

트위터에 대한 자세한 정보 : @ letsencrypt

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

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

요약하자면 Ilya Grigorik : "TLS에는 한 가지 성능 문제가 있습니다. 널리 사용되지는 않습니다. 다른 모든 것들은 최적화 할 수 있습니다."

Chris 덕분에 HTTP vs HTTPS 테스트 벤치 마크 작성자-아래의 의견에 감사드립니다.

25
rsp

현재의 최상위 답변 이 완전히 올바르지 않습니다.

다른 사람들이 지적했듯이, https는 핸드 쉐이킹을 필요로하므로 더 많은 TCP/IP 라운드 트립을 수행합니다.

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

유럽에서 미국까지의 대기 시간은 약 200 밀리 초 (torundtrip time) 일 수 있습니다.

HTTPWatch 를 사용하면이 단일 사용자의 경우에 대해 쉽게 측정 할 수 있습니다.

23
kohlerm

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

12
Alexander

많은 경우에 SSL 핸드 셰이크의 성능 영향은 SSL 세션이 양 끝 (데스크톱 및 서버)에 캐시 될 수 있다는 사실로 인해 완화됩니다. 예를 들어, Windows 시스템에서 SSL 세션은 최대 10 시간 동안 캐시 될 수 있습니다. 참조 http://support.Microsoft.com/kb/247658/EN-US . 일부 SSL 가속기에는 세션이 캐시되는 시간을 조정할 수있는 매개 변수가 있습니다.

고려해야 할 또 다른 영향은 HTTPS를 통해 제공되는 정적 콘텐츠가 프록시에 의해 캐시되지 않으며 동일한 프록시를 통해 사이트에 액세스하는 여러 사용자의 성능을 저하시킬 수 있다는 것입니다. 이는 데스크톱에서 정적 컨텐츠도 캐시되므로 인터넷 익스플로러 버전 6 및 7은 캐싱 가능한 HTTPS 정적 컨텐츠를 캐시하지 않는 한 (도구 메뉴/인터넷 옵션/고급/보안/암호화 된 페이지를 저장하지 않음) 지시하지 않는 한 완화 할 수 있습니다. 디스크에).

6
ZX81

이것에 대한 대답은 하나도 없습니다.

암호화는 항상 더 많은 CPU를 소비합니다. 이것은 많은 경우에 전용 하드웨어로 오프로드 될 수 있으며 선택된 알고리즘에 따라 비용이 달라집니다. 예를 들어, 3des는 AES보다 비쌉니다. 일부 알고리즘은 암호 해독기보다 암호화기에 더 비쌉니다. 일부는 반대 비용이 있습니다.

벌크 암호화보다 더 비싼 것은 핸드 셰이크 비용입니다. 새로운 연결은 더 많은 CPU를 소비합니다. 만료 될 때까지 이전 세션 비밀을 유지하는 비용으로 세션 재개로이를 줄일 수 있습니다. 즉, 다시 돌아 오지 않는 클라이언트의 작은 요청이 가장 비쌉니다.

교차 인터넷 트래픽의 경우 사용 가능한 대역폭이 너무 낮기 때문에 데이터 요금에서이 비용을 알 수 없습니다. 그러나 바쁜 서버의 CPU 사용량에 확실히 주목할 것입니다.

6
Darron

나는 (전화 접속 사용자로서) SSL을 통한 동일한 페이지가 일반 HTTP를 통한 것보다 몇 배 더 느리다는 것을 말할 수있다.

6
Brian Knoblauch

나는 작은 실험을했고 flickr (233 kb)에서 같은 이미지에 대해 16 %의 시간차를 보았습니다.

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

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

enter image description here

물론이 숫자는 컴퓨터 성능, 연결 속도, 서버로드, 경로상의 QoS (브라우저에서 서버로 가져온 특정 네트워크 경로)와 같은 여러 요인에 따라 달라 지지만 일반적인 생각을 보여줍니다. HTTPS는 HTTP보다 느리므로 HTTP입니다. 완료 할 더 많은 작업을 요청합니다 (SSL 핸드 쉐이킹 및 데이터 인코딩/해독).

4
Khachatur

여기 SSL 핸드 셰이크 대기 시간에 대한 훌륭한 기사가 있습니다. 느린 인터넷 연결을 통해 내 앱을 사용하는 클라이언트의 속도 저하의 주요 원인으로 SSL을 식별하는 데 도움이되었습니다.

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

3
OrPo

HTTP VS HTTPS 성능 비교

나는 항상 오래된 HTTP와 비교할 때 HTTPS를 느린 페이지로드 시간과 연관시켰다. 웹 개발자로서, 웹 페이지 성능은 나에게 중요하며 내 웹 페이지의 성능을 저하시키는 것은 아무 것도 없습니다.

성능 관련 사항을 이해하기 위해 아래 다이어그램은 HTTPS를 사용하여 리소스를 요청할 때 수행되는 작업에 대한 기본적인 아이디어를 제공합니다.

enter image description here

위의 다이어그램에서 알 수 있듯이 HTTPS를 사용할 때 일반 HTTP를 사용하는 것과 비교할 때 몇 가지 추가 단계가 필요합니다. HTTPS를 사용하여 요청을하면 요청의 신뢰성을 확인하기 위해 핸드 셰이크가 발생해야합니다. 이 핸드 쉐이크는 HTTP 요청과 비교할 때 추가 단계이며 불행히도 약간의 오버 헤드가 발생합니다.

성능 영향을 이해하고 성능 영향이 중요한지 여부를 직접 확인하기 위해이 사이트를 테스트 플랫폼으로 사용했습니다. 나는 webpagetest.org로 향했고 시각 비교 도구를 사용하여 HTTPS 대 HTTP를 사용하여이 사이트로드를 비교했습니다.

당신이 볼 수 있듯이 여기 비디오 테스트 결과입니다 HTTPS를 사용하면 페이지로드 시간에 영향을 미쳤지 만 그 차이는 무시할 만하며 300 밀리 초의 차이 만 나타났습니다. 이러한 시간은 컴퓨터 성능, 연결 속도, 서버로드 및 서버와의 거리와 같은 여러 요소에 따라 달라집니다.

사이트가 다를 수 있으므로 사이트를 철저히 테스트하고 HTTPS로 전환하는 것과 관련된 성능 영향을 확인하는 것이 중요합니다.

CAN WE 실적을 향상 시키시겠습니까? 여기를 방문하십시오 자세한 정보를 얻으려면

2
Sunny S.M

TLS는 아직 빠릅니까? 예.

거기 라인을 흐리게하고 빨리 HTTPS를 만드는 것을 목표로 많은 프로젝트가 있습니다. SPDYmod-spdy 와 같습니다.

2

여기에 끔찍한 엣지 케이스가있는 것 같습니다. 아약스가 혼잡 한 무선 랜보다.

Ajax는 대개 20 초 후에 KeepAlive가 시간 종료되었음을 의미합니다. 그러나 wifi는 (이상적으로 빠른) 아약스 연결이 여러 번의 왕복을해야 함을 의미합니다. 더 나쁜 것은 wifi가 패킷을 잃어 버리며 TCP retransmits가 있다는 것입니다. 이 경우 HTTPS가 실제로 정말 잘 수행되지 않습니다!

2
Richard

내 프로젝트에서 동일한 문제를 조사 중이므로이 슬라이드를 찾았습니다. 이전이지만 흥미 롭습니다.

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

2
Mircea Stanciu

이것을 측정 할 방법이 있습니다. jmeter라는 Apache 도구는 처리량을 측정합니다. jmeter를 사용하여 SSL을 사용하거나 사용하지 않는 제어 된 환경에서 대규모 샘플링을 설정하면 상대적 비용을 정확하게 비교해야합니다. 나는 당신의 결과에 관심이있을 것입니다.

0
dacracot