HTTPS Transmission Optimization Detailed dynamic TLS Record Size

In the past, the author has analyzed many methods which can reduce the delay of HTTPS transmission, such as the reuse of distributed Session;

With HSTS enabled, the client opens HTTPS jump by default, adopts HTTP/2 transport protocol, and uses chacha20-poly1305 algorithm to reduce the CPU time of the mobile terminal.

These methods can greatly optimize the delay of HTTPS in transmission, and bring a better experience to the users of the website.

Recently, I have also considered reducing the HTTPS transmission delay by dynamically adjusting the TLS Record Size.

TLS and TCP

The TLS protocol is composed of the record layer (TLS record layers) and the handshake layer (TLS handshake layer), the record layer is at the bottom of the protocol, provides a secure and reliable connection for the TLS protocol, and provides support for the basic functions of data encapsulation, compression and encryption for the high-level protocol. The handshake Layer protocol is above the record layer protocol, the function of the handshake layer protocol can make the client and server authenticate each other, negotiate the encryption algorithm and generate the encryption key before the real application data transfer. In general, the maximum TLS record size is 16KB, and each TLS record contains a 5Byte header.

TCP (transmission Control Protocol Transmission Protocol) is a reliable, IP-based transport layer protocol that is oriented towards connectivity (connection-oriented).

TLS is built on the basis of reliable data transfer, running on top of the TCP layer, a TLS record size consisting of multiple TCP packets, as can be seen through the WireShark capture Packet, a TLS record size of 16408 Byte, is divided into 12 A TCP packet.

WireShark Grab Bag

Dynamic TLS Record Size adjustment principle

Nginx default ssl_buffer_size size is 16KB (dynamic adjustment is not supported), this is the size of a TLS Record size. For example, if the size of a resource file is 1600KB, it will be split into 100 TLS Record transfers to the client.

This problem occurs during the transfer process:

1. The larger the TLS record size, the more TCP packets are split, and in transit, if TCP drops, the TLS record arrives at the client for longer, and the client must wait until the full TLS record is received to decrypt it; TLS R The relationship between the Ecord and TCP packets is as follows:

Image source: igvita.com

2. If the TLS record Size is small, the effect of TCP drops on the TLS record is small, but at the same time, the TLS record header becomes much more and may also reduce the throughput of the connection.

In summary, it can be known that a small record size will incur additional consumption, while a large record size will cause a delay. The author thinks that the reasonable adjustment of TLS Record size according to TCP window size can effectively reduce the delay caused by HTTPS transmission.

How to make a Record size adjustment

Based on the above argument, we can conclude that the TLS Record Size can be resized in the TCP slow-start process, because the TCP link has a smaller congestion window (CWnd), and the TCP link has less throughput; After the TCP connection ends slow booting, the TLS The size of the record can be increased, and over time, the TLS record is eventually resized to the maximum (or 16KB).

The approximate algorithm rules are:

1. In the new connection and the TCP slow start phase, the TLS Record size is resized to approximately 1 TCP packets;
2. At a certain stage, after sending a certain number of record size, the larger TLS record size is used;
3. Over time, the largest TLS Record size, or 16KB, is used.

WireShark Capture Package Verification

This process is validated by WireShark grasping the package:

Phase one: At the beginning, the TLS Record Size is 1393 Byte.

Stage two: After some time, the TLS Record Size is 4253 Byte.

Phase three: Finally, the TLS Record Size dynamically becomes 16408 Byte.

The three-stage capture results validate the algorithm rules for the dynamic TLS record size, which can effectively reduce the delay of HTTPS transmission by dynamically adjusting the TLS record size, and bring a better experience to the customer.

At present, the Pat Cloud CDN platform has fully supported the dynamic adjustment of TLS record size, the speed of the site more demanding friends can open and Pat Cloud CDN, to use the dynamic TLS Record size, so that the site transfer faster, to give users a better experience.

Recommended reading:

From HTTP to HTTPS to HSTS

HTTPS series of Dry Goods (a): HTTPS principle of explanation

HTTPS Transmission Optimization Detailed dynamic TLS Record Size