Optimizing for TLS

TLS에 응용프로그램을 배포하는 것은 TLS를 통해 전달을 책임지는 인프라의 환경설정과 응용프로그램 두가지의 추가적인 작업이 필요하다. 잘 튜닝된 개발환경은 성능, 사용자경험, 운영비용 등을 모니터링하면 수많은 긍정적인 차이점을 가져온다. 자세한 사항들은 아래의 내용들을 통해 살펴보자

Reduce Computational Costs

암호화된 채널의 연결수립과 유지는 상호간의 추가적인 CPU 비용을 발생시킨다. 특히 처음 비대칭키가 사용될어 handshake가 이뤄질때와, 처음 공유된 비밀키가 수립된이후 모든 TLS 레코드를 암호화 하기 위해 대칭키가 사용될 때도 비용이 발생한다.

처음에 언급했듯이 공개키 암호화는 대칭키 암호화에 비교해서 좀더 많은 비용이 발생한다. 웹 환경의 초기에는 SSL Offloading을 수행할 수 있는 추가적인 하드웨어가 필요했다. 하지만 지금은 필요하지 않으며, CPU가 그 역할을 대신할 수 있다. 페이스북 트위터 구글고 같은 큰 회사들은 수십억 사용자들에게 TLS를 제공하기 위해 클라우드를 통해 모든 필요한 TLS 협상과 소프트웨어 컴퓨팅을 수행한다.

개발환경에서 최고의 결과를 얻기위해서는 TLS Session Resumption 을 배포하고 측정하여 최족화해야한다. 모든 Handshake 과정에서 공개키 암호화 과정에 비용적으로 수행되는 필요를 최소화하는것은 컴퓨팅과 TLS 지연의 비용을 줄이는데 가장 중요하다. CPU 사이클을 필요하지 않은 작업으로 소비하는데 비용을 들일 필요가 없다.

Enable 1-RTT TLS Handshakes

최적화되지 않은 TLS 배포를 통해 추가적인 RTT와 사용자의 심각한 지연을 발생시킬수 있다. 예를들면 다중 RTT handshake나 늦고 비효율적인 인증서 폐기 확인, 여러차례의 RTT가 필요한 크기가 큰 TLS 레코드 등등... 그런 사이트들보다 더 좋은 사이트를 만들어라!!

적절하게 튜닝된 TLS 환경은 TLS 연결 협상을 위해 새로운 연결이든, 재사용이든 상관없이 다른 지연의 발생을 피하기 위해 반드시 1번의 추가 RTT를 수행한다. Session Resumption과 TLS False Start를 설정하도록 하자.

Optimize Connection Reuse

TLS+TCP 의 새로운 연결을 수행할 때 지연과 컴퓨팅 오버헤드를 최소화하는 최고의 방법은 연결을 재사용 하는 것이다. 요청들과 사용자에게 보다더 빠른 경험을 제공하는 분할하는 것이다.

Server와 Proxy 환경설정이 keepalive Connection 설정인지 확인하고 timeout 설정을 확인해야 한다. 많은 인기있는 서버들은 Connection 불필요한 재협상의 비용을 줄여주는 Timeout을 공격적으로 설정한다. (Apache의 기본 timeout은 5초이다.) 최고의 결과를 위해 로그와 통계를 확인하여 최적의 timeout 시간을 결정해야한다.

Leverage Early Termination

Primer on Latency and Bandwidth 에서 얘기했던 것 처럼 패킷의 전송속도를 빠르게 할수없지만 전송거리를 단축시킬수는 있다. edge서버를 사용자에 가까이 위치시킴으로써 RTT를 줄이고 TCP, TLS handshake 비용을 줄일 수 있다.

CDN 서비스를 통해 쉽게 구현할 수 있다. CDN 서비스는 전세계에 위치한 edge 서버 풀을 유지하고 배포하는 시스템이다. 사용자가 대륙이나 해양을 건너 원본 서버에 연결하는 대신 가까이 있는 CDN 서버에 연결할 수 있고, RTT시간을 줄일 수 있다. 이 기술은 정적 \/ 동적 데이터를 제공하는데 유용하고 중요한 기술이다. 정적 데이터는 edge 서버에 캐시되어 제공되며, 동적 데이터 요청은 edge 서버 와 연결된 원본 서버로 라우팅 될수 있다.

Configure Session Caching and Sateless Resumption

사용자에게 더 가까이 연결하는 것은 모든 경우에 지연을 감소시킬수 있다. TLS Session 캐싱과 resumption은 전체 RTT 지연을 없애고 재문자의 CPU 오버헤드를 감소시킨다.

TLS session 캐싱의 Session 식별자 SSL2.0에 도입되었고 대부분의 Client와 Server들을 지원해왔다. 서버에 TLS를 세팅했다면 기본값으로 session이 지원된다고 가정해서는 안된다. 사실 기본적으로 대부분의 서버들은 Session 기능이 꺼져있는 경우가 보통이다. 그래서 반드시 Server, Proxy, CDN 설정들을 확인해야 한다.

• 멀티 프로세스나 스레드를 구현한 서버들은 반드시 공유된 Session Cache를 사용해야만 한다.
• 공유된 Sesion Cache의 크기는 트래픽의 양에 따라 조정되어야ㅑ 한다.
• Session Timeout이 설정되어 있어야 한다.
• 다중서버 환경에서 동일한 Client IP나 TLS Session ID를 라우팅하는 것은 하나의 방법을 통해 동일한 서버로 향해야 하고 좋은 세션 캐시 기능을 제공해야 한다.

실제로 최선의 결과를 위해서는 session caching과 session ticket 방법 둘다 설정해야만한다. 이 방법은 새로운 Client나 기존의 Client둘다를 포용하는 효과를 제공한다.