1. HTTPS가 느린 이유
TLS handshake는 브라우저와 서버 간에 어떻게 통신할지 결정하고 보안 연결을 수립하는 과정이다. 그 과정에서 다음과 같은 일을 한다.
- server의 신원을 확인
- cipher, signature을 비롯한 여러 옵션을 서로 얘기하고 무엇을 사용할지 결정
- 이후 데이터 교환 시에 데이터를 암호화할 key 생성 및 교환
그 과정을 간단하게 정리한 다이어그램이다.
성능에 더 영향을 미치는 것은 TLS handshake에 걸리는 시간보다 그 과정이 이루어지는 타이밍이다. 이 과정이 보안 연결을 생성하는 것이기 때문에 데이터가 교환되기 전에 완료되어야 한다. 그렇기 때문에 HTML page를 가져올 수가 없고 CSS file, image 등을 동시에 다운로드하는 것도 불가능하다. 즉, TSL handshake는 브라우저가 아무것도 하지 못하는 시간을 늘리게 된다.
게다가 TLS handshake는 모든 새로운 HTTP 연결마다 발생한다. 그런데 브라우저는 자원들을 병렬적으로 다운로드 받기 때문에 여러 HTTP 연결을 수립하고 이에 대해 모두 각각의 TLS handshake를 해야 한다. 따라서 하나의 페이지를 방문할 때도 여러 번의 TLS handshake를 해야 하는 것이다.
TLS handshake 과정을 최적화하는 방법은 그리 많지 않다. 우리가 최적화할 수 있는 부분은 서버의 신원을 확인하는 부분이다.
2. certificate chain
디지털 서명 & 인증서에서 설명한 것처럼 서버의 신원을 확인하는 데는 인증서가 필요하다. CA를 비롯한 신뢰할 수 있는 기관에서 발급한 인증서를 브라우저는 이미 built-in list의 형태로 갖고 있다. 어떤 서버의 인증서가 해당 리스트에 없다면, 그 인증서를 어디서 서명을 해주었는지 계속 타고 올라가다보면 신뢰할 수 있는 기관이 나온다. 이러한 certificate chain의 길이를 짧게 할 수 있는 인증서를 사용하면 서버의 신원을 확인하는 시간을 줄일 수 있다.
3. Avoiding full TLS handshakes
최근에 연결을 맺었던 클라이언트와 서버 간에 TLS handshake를 다시 거치는 것은 비효율적이다. 어떤 블로그에 TLS handshake를 거쳐 접속했다고 하자. 거기에서 여러 컨텐츠를 다운로드하기 위해 여러 번의 handshake를 거쳤을 것이다. 거기서 같은 사이트 내의 다른 페이지로 이동할 때 다시 TLS handshake를 하는 것은 비효율적이다.
그래서 TLS session resumption(재개)라는 개념이 도입되었다. 기존의 TLS handshake는 클라이언트와 서버 간 2번의 왕복이 필요하지만 resumption에서는 한 번만 왕복하면 된다. 이를 위해서는 Session Identifier 또는 Session ticket을 이용한다. 모든 웹 브라우저는 이들 모두를 지원하고, 웹 서버들은 일부만 이 기능을 지원한다.
4. 기타 방법들
1) persistent connections
persistent connection으로 하나의 HTTP connection에 여러 요청을 만들어낼 수가 있다. 이는 브라우저가 페이지를 빠르게 로드할 수 있게 해주기 때문에 요청을 빠르게 만들어낼 수 있다. 게다가 TLS handshake 횟수를 줄여줄 수도 있다. persistent connection을 하면 web server가 connection: close를 안 하기 때문에 그에 따라 TLS connection도 유지된다.
2) CSS, javascript file 합치기
이렇게 파일들을 합치면 http connection을 맺어야 하는 횟수가 줄어들기 때문에 TLS handshake 획수도 같이 줄어들게 된다.
참고
