Optimize TLS Record Size
TLS를 통해 전달되는 모든 응용프로그램 데이터는 TLS Record Protocol 을 통해 전송된다. 각 Record의 최대 사이즈는 16KB이고 header와 MAC, 추가적인 padidng은 암호화 종류에 따라서 20~40 byte까지 추가될수 있다. 만약 record가 TCP 패킷 하나에 꼭맞는 크기라면 TCP를 위해 IP(20byte)와 TCP (20byte) 오버헤드를 추가해야 한다. 결과적으로 각 레코드마다 60~100byte의 오버헤드가 발생한다. 보통의 최대 전송 유닛(MTU) 크기는 라인당 1500byte 이다. 이 패킷 구조는 최소 6%의 오버헤드가 발생한다.
record를 더 작게 할수록, framing 오버헤드가 증가한다. 그러나 Record의 크기를 증가시키는 것은 이상적인 방법이 아니다. 만약 Record가 다중 TCP 패킷으로 전송된다면 TLS 계층에서 데이터를 복호화 하기 전에 TCP 패킷이 더착할때까지 기다려야 한다. 만약 TCP 패킷 일부가 소실되거나 재정렬하거나 병목이 발생한다면 TLS record의 부분들은 복호화 되기 전에 저장되어야만 한다. 그 결과 추가적인 지연이 발생한다. 실제적으로 이 지연은 중요한 병목현상을 만들어낸다.
크기가 작은 레코드들은 오버헤드를 발생시키고 크기가 큰 레코드들은 지연을 발생시킨다. 이상적인 레코드 사이즈는 없지만 브라우저에서 사용되는 웹 응용프로그램에서 최고의 전략은 TCP 연결 상태에 따라 레코드 크기를 조정하는 것이 이상적인 전략이다.
- 새로운 연결이나 TCP Congestion Window가 적을때 혹은 연결이 놀고있는 상태의 경우 각 TCP 패킷은 정확하게 하나의 TLS 레코드를 전송해야 한다. 그리고 TCP에 의해 할당된 최대 Segment 크기를 차지해야만 한다.
- Congestion Window 가 크고 큰 데이터를 전송한다면, 다중 TCP 패킷을 분산하고 Client와 Server의 CPU 오버헤드를 감소시키기 위해 TCP 레코드 크기가 증가될수 있다.
상호 트레픽을 위한 최고의 성능을 위한 전략을 사용하는 것은 작은 사이즈의 레코드는 불필요한 버퍼링 지연을 없애주고, time-to-first-{HTML byte, ..., video frame} 를 증가시켜준다. 큰 사이즈의 레코드는 오래 지속되는 데이터를 위한 오버헤드 최소화를 가져도록 최적화되어야 한다.
상태에 따라 선택적 레코드 사이즈를 결정하는 것은 새로운 연결이냐 TCP 연결이 놀고있느냐의 초기 상황에 따라 달라질 수 있다.
- IPv4 프레임 오버헤드를 위해 20byte를 할당하고 IPv6은 40 byte를 할당한다.
- TCP 프레임 오버헤드로 20byte를 할당한다.
- TCP의 추가적인 오버헤드를 위해 40byte를 할당한다.
보통 MTU(Maximum Transfer Unit)를 1,500 byte로 가정하면 1,420 byte는IPv4를 통해 전달되는 TLS record를 위해 남겨두고, 1,400 byte는 IPv4를 위해 남겨둔다.
일반적으로 TLS Record 의 크기를 설정하는 것은 응용프로그램 계층에서 할수 있는 것이 아니다. 대신 컴파일 시점에 TLS 서버에서 이뤄진다. Record 크기를 결정하기 위해서는 Server 환경설정 문서를 살펴보아야 한다.
TLS optimizations at Google
2014년 초 구글의 서버들은 TCP Segment 하나에 들어 맞는 작은 TLS Record 크기를 사용했고, 최적화의 결과 16KB까지 증가했다. 비슷하게 당신의 서버들이 수많은 TLS 연결을 다룬다면 Connection 마다의 메모리 사용을 최소화 하는 것이 중요한 최적화의 요소이다. 기본적으로 OpenSSL 과 같이 유명한 라이브러리들은 Connection당 50KB 메모리를 할당할 수 있지만 문서를 확인해서 할당되는 메모리 값을 조정하는 것이 좋다. 구글은 Connection 당 OpenSSL 메모리 버퍼를 5KB로 감소시켰다.