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 월 도착 :

• 출시 일정을 암호화합시다 (2015 년 6 월 16 일)
• 루트 및 중간 인증서를 암호화합니다 (2015 년 6 월 4 일)
• 초안 구독자 계약을 암호화하자 (2015 년 5 월 21 일)

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

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

• TLS는 아직 빠른가?
• 고성능 브라우저 네트워킹, 4 장 : 전송 계층 보안
• 오버 클럭킹 SSL
• SSL 처리의 분석 및 성능

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

• 왜 모든 것이 HTTPS인가?(HTTPS 전용 표준)
• 암호화하자 (인터넷 보안 연구 그룹)
• HTTPS Everywhere (전자 프론티어 재단)

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

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

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

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

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

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

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

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

이에 대한 단일 답변이 없습니다.

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

대량 암호화보다 비용이 많이 듭니다. 새로운 연결은 훨씬 더 많은 CPU를 소비합니다. 세션 재개를 통해 기존 세션 비밀이 만료 될 때까지 유지하면서이를 줄일 수 있습니다. 다시 말하지 않는 클라이언트의 작은 요청이 가장 비싸다는 것을 의미합니다.

교차 인터넷 트래픽의 경우 사용 가능한 대역폭이 너무 낮아 데이터 속도에서이 비용을 인식하지 못할 수 있습니다. 그러나 사용량이 많은 서버의 CPU 사용량에서 분명히 알 수 있습니다.

SSL을 통한 동일한 페이지가 일반 HTTP보다 몇 배 느리다는 것을 전화 접속 사용자로 알 수 있습니다 ...

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

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

나는 작은 실험을하고 플리커 (233 kb)에서 동일한 이미지에 대해 16 %의 시간 차이를 얻었습니다.

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

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

물론이 숫자는 컴퓨터 성능, 연결 속도, 서버로드, 경로의 QoS (브라우저에서 서버로 가져 오는 특정 네트워크 경로)와 같은 많은 요소에 따라 달라 지지만 HTTPS는 HTTP보다 느리므로 HTTP보다 느립니다. 더 많은 작업을 완료하도록 요청합니다 (SSL 핸드 쉐이킹 및 데이터 인코딩 / 디코딩).

다음은 SSL 핸드 셰이크 대기 시간에 대한 훌륭한 기사입니다 (조금 늙었지만 여전히 훌륭합니다). 인터넷 연결 속도가 느린 경우 내 앱을 사용하는 클라이언트의 주요 원인으로 SSL을 식별하는 데 도움이되었습니다.

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

내 프로젝트에 대해 동일한 문제를 조사하고 있으므로이 슬라이드를 찾았습니다. 더 오래되었지만 흥미로운 :

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

혼란스러운 Wi-Fi를 통한 Ajax

Ajax는 일반적으로 KeepAlive가 20 초 후에 시간 초과되었음을 의미합니다. 그러나 wifi는 (이상적으로 빠른) ajax 연결이 여러 번 왕복해야한다는 것을 의미합니다. 더구나, 와이파 이는 종종 패킷을 잃어 버리고 TCP 재전송이있다. 이 경우 HTTPS는 실제로 매우 나쁩니다!

TLS는 아직 빠릅니까? 예.

• 보기 : https://www.youtube.com/watch?v=0EB7zh_7UE4
• 읽기 : https://istlsfastyet.com/

라인을 흐리게하고 HTTPS를 빠르게 만드는 것을 목표로하는 많은 프로젝트가 있습니다. SPDY 및 mod-spdy 처럼 .

HTTP 대 HTTPS 성능 비교

평범한 오래된 HTTP와 비교할 때 항상 페이지로드 시간이 느린 HTTPS를 연결했습니다. 웹 개발자로서 웹 페이지 성능은 나에게 중요하며 웹 페이지 성능을 저하시키는 것은 절대 아닙니다.

관련된 성능 영향을 이해하기 위해 아래 다이어그램은 HTTPS를 사용하여 리소스를 요청할 때 발생하는 기본 작업에 대한 기본 아이디어를 제공합니다.

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

성능에 미치는 영향을 이해하고 성능에 미치는 영향이 큰지 여부를 확인하기 위해이 사이트를 테스트 플랫폼으로 사용했습니다. webpagetest.org로 가서 시각적 비교 도구를 사용하여 HTTPS와 HTTP를 사용하여이 사이트 로딩을 비교했습니다.

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

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

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

HTTPS에는 암호화 / 암호 해독 오버 헤드가 있으므로 항상 약간 느려집니다. SSL 종료는 CPU를 많이 사용합니다. SSL을 오프로드 할 장치가있는 경우 서버의 부하에 따라 지연 시간의 차이가 거의 눈에 띄지 않을 수 있습니다.

더 중요한 성능 차이는 사용자가 연결되어있는 동안 HTTPS 세션이 계속 열려 있다는 것입니다. HTTP '세션'은 단일 항목 요청에 대해서만 지속됩니다.

많은 동시 사용자가있는 사이트를 실행 중이며 많은 메모리를 구입할 것으로 예상됩니다.

SSL에 SLL 이외의 HTTP에는 필요하지 않은 추가 암호화 단계가 필요하다는 점을 감안할 때 거의 확실합니다.

HTTPS는 실제로 페이지 속도에 영향을 미칩니다 ...

위의 인용문은 사이트 보안과 속도에 대한 많은 사람들의 어리 석음을 보여줍니다. HTTPS / SSL 서버 핸드 쉐이킹은 인터넷 연결시 초기 중단을 만듭니다. 방문자의 브라우저 화면에서 무언가가 렌더링되기 전에 지연이 느립니다. 이 지연은 Time-to-First-Byte 정보로 측정됩니다.

HTTPS 핸드 셰이크 오버 헤드가 TTFB (Time-to-First-Byte) 정보에 나타납니다. 일반적인 TTFB의 범위는 100 밀리 초 미만 (최상의 경우)에서 1.5 초 (최악의 경우) 이상입니다. 그러나 HTTPS를 사용하면 500 밀리 초 더 나빠집니다.

왕복, 무선 3G 연결은 500 밀리 초 이상이 될 수 있습니다. 추가 트립은 1 초 이상으로 두 배 지연됩니다. 이는 모바일 성능에 큰 부정적인 영향을 미칩니다. 아주 나쁜 소식입니다.

내 조언, 민감한 데이터를 교환하지 않으면 SSL이 전혀 필요하지 않지만 전자 상거래 웹 사이트를 좋아한다면 민감한 데이터가 로그인 및 체크 아웃과 같은 특정 페이지에서 교환되는 HTTPS 만 사용할 수 있습니다.

출처 : Pagepipe

브라우저는 HTTP 또는 HTTPS를 사용하여 HTTP / 1.1 프로토콜을 승인 할 수 있지만 브라우저는 HTTPS를 사용하여 HTTP / 2.0 프로토콜 만 처리 할 수 ​​있습니다. HTTP / 1.1과 HTTP / 2.0의 프로토콜 차이로 인해 HTTP / 2.0은 평균적으로 HTTP / 1.1보다 4-5 배 더 빠릅니다. 또한 HTTPS를 구현하는 사이트 중 대부분은 HTTP / 2.0 프로토콜을 통해 수행됩니다. 따라서 HTTPS는 일반적으로 사용되는 프로토콜이 다르기 때문에 거의 항상 HTTP보다 빠릅니다. 그러나 HTTP / 1.1을 통한 HTTP가 HTTP / 1.1을 통한 HTTPS와 비교되는 경우 HTTP는 평균적으로 HTTPS보다 약간 빠릅니다.

다음은 Chrome (Ver. 64)을 사용하여 비교 한 내용입니다.

HTTP / 1.1을 통한 HTTPS :

• 평균 페이지로드 시간 0.47 초
• HTTP over HTTP / 1.1보다 0.05 초 느림
• HTTP / 2.0에서 HTTPS보다 0.37 초 느림

HTTP over HTTP / 1.1

• 평균 페이지로드 시간 0.42 초
• HTTP / 1.1에서 HTTPS보다 0.05 초 빠름
• HTTP / 2.0에서 HTTPS보다 0.32 초 느림

HTTP / 2.0을 통한 HTTPS

• 평균로드 시간 0.10 초
• HTTP over HTTP / 1.1보다 0.32 초 빠름
• HTTPS / 1.1에서 HTTPS보다 0.37 초 더 빠름