原書飛びまして第3章 TLS 1.2の概説箇所をまとめてみたいと思います。
TLS 1.2 はRFC5246で定義されています。関連するRFCも多数あります。原書では実際のトラフィックを観察するのが最も有効、としてポート443を単一のホストについてWiresharkでモニターするのが一案と紹介しています。
TLS 1.2の Recordプロトコル
下図はTLS 1.3のRecordプロトコルで掲載したものですが、TLS 1.2でもこの構造は共通です。

原書に掲載の各フィールドをTLS 1.2 と TLS 1.3で比較すると以下の様になります。
TLS 1.3
struct {
ContentType type;
ProtocolVersion legacy_record_version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
enum {
invalid(0),
change_cipher_spec(20),
alert(21),
handshake(22),
application_data(23),
(255)
} ContentType;
struct {
ContentType opaque_type = application_data; /* 23 */
ProtocolVersion legacy_record_version = 0x303; /* TLS 1.2 */
uint16 length;
opaque encrypted_record[TLSCiphertext.length];
} TLSCiphertext;
・ProtocolVersionはTLS 1.3 では使用されないがTLS 1.2以前とフォーマットを合わせる目的で存在しています
・TLS 1.3 ではRecordプロトコルは平文モードで開始されるが暗号化に必要なネゴシエーション完了後ただちに暗号化モードに移行します。
TLS 1.2
struct {
unit8 major;
unit8 minor;
} ProtocolVersion;
enum {
change_cipher_spec (20),
alert (21),
handshake (22),
application_data (23)
} ContentType;
struct {
ContentType type;
ProtocolVersion version ;
uint16 length; /* 最長 2^14=16,384バイト */
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
上記以外にTLS レコードには64ビットのシーケンス番号が割り当てられていますが、送受信されるデータには含まれません。通信の両側で自身のシーケンス番号を保持して相手から受信したレコードのシーケンス番号を記録しています。この方式でリプレイ攻撃に対する防御を行っています。
TLS (1.2)の役割・機能
メッセージの転送
Recordプロトコルでは別なレイヤーから渡される書式が決まっていないデータ(opaque data) を転送します。Opaque dataの最大長は16,384バイトです。これ以上長いデータはRecordプロトコルによってチャンク(塊)に分割され転送されます。(複数の転送メッセージをまとめることも行う)
暗号化及び完全性の検証
TLS 1.2 の初期の接続におけるハンドシェイク完遂以前の一連のメッセージは保護されません。厳密にいうとTLS_NULL_WITH_NULL_NULL という暗号スイートを利用しています。
圧縮
TLS 1.2(以降?)は暗号化されたデータの圧縮機能は利用されません。理由としてすでにHTTPレベルで圧縮されている場合が多い事、2012年にCRIME攻撃に利用され大きな被害が発生した事を挙げています。
拡張性
TLS 1.2 のRecordプロトコルではデータ転送と暗号処理を担います。他の機能はすべてサブプロトコルで実行します。この仕様により新しいサブプロトコルの追加が容易に可能です。Recordプロトコルで暗号化処理を行うのでサブプロトコルは基本的に全て保護されます。
TLS 1.2のサブプロトコル
TLS 1.2 の基本仕様では以下の4つのサブプロトコルが規定されています。
Handshakeプロトコル
Change Cipher Specプロトコル
Application Dataプロトコル
Alertプロトコル
上記サブプロトコル4つはTLS 1.3でも同様に存在します。