TLS 協定由兩層協定組成：TLS 握手協定和 TLS 記錄協定（TLS Record），TLS Record 協定在 TLS 握手協定之下。下面是 SSL/TLS 的分層結構：
所有的 TLS 上層資料（包含 TLS 握手協定消息以及更上層的應用協定資料）都由 TLS Record 來封裝和傳輸。下面是 TLS Record 協定的消息封裝流程：
一個消息會在 TLS Record 協定層被分段，然後對每個分段分别壓縮（已廢棄）和加密，最後加上 TLS Record 協定頭再通過網絡層發送出去，在 Wireshark 中可以看到：
可以看出 TLS/SSL 資料加解密是基于分段的，接收方收到一個完整的分段就可以解密，如果分段過大，那接收方必須要等到接收完整個分段的資料才能解密，當網絡不好出現丢包、擁塞、重傳等等情況下會嚴重影響時延，如果分段過小，頭部負載比重就會較大，影響吞吐率。是以，怎麼分段就比較關鍵，也就是 TLS Record Size 大小多少合适。這就涉及到兩個重要的名額：時延和吞吐率。
如果 TLS Record Size 設定較大 假如超過了 MTU，一個分段會被 TCP 層再次分段，拆分成多個包發送，那麼時延也相應地增大，但由于記錄協定頭占比很小，吞吐率也增大。 如果 TLS Record Size 設定較小 一個分段在 TCP 層沒有被再次分段，由一個包發送出去，時延會比較小，但吞吐率也會下降。
是以，對時延敏感的域名，TLS Record Size 建議設定為略小于 MTU 的大小（粗算：MTU - TLS Record Header Length - TCP Header Length - IP Header Length）。對吞吐率敏感的域名，TLS Record Size 建議設定為 16k（上限）。如果同時兼顧時延和吞吐率的話，建議設定為 8k （經驗值）。
但是，TCP 有擁塞控制機制，在 TCP 連接配接剛開始的慢啟動階段，擁塞視窗會比較小，這時較大的 TLS Record Size 會導緻 TLS Record 片段被 TCP 分成多個包來發送，進而導緻時延較大，可能就會影響網頁的首屏時間。在整個 TCP 資料傳輸過程中，可能啟動擁塞避免算法，也可能遇到資料丢失和重傳的情況，然後又重新進入慢啟動階段。
是以，更好的做法是動态調整 TLS Record Size 的大小，而不是使用固定的值。在 TCP 連接配接初期使用較小的值，等傳輸速度上來之後再使用更大的值。