TLS 1.2の4つのサブプロトコルについてです。TLS 1.3との差異も（調べた範囲で）まとめてみます。
TLS 1.2のHandshakeプロトコル
TLSのハンドシェイクのパターンは大まかに以下の3つがあります
・サーバー認証を伴うフルハンドシェイク
・（前回セッションの再開時の）一部を省略したハンドシェイク
・クライアントとサーバーの認証を伴うハンドシェイク
上記パターンや利用する機能に拠りますが通常6～10のメッセージがハンドシェイク（通信確立）には必要です。
※TLS 1.3の説明ではハンドシェイクに1 RTT（または0-RTT）、とあるので比較するとTLS 1.3は非常に高速に接続が完了する仕様なのだと思います。
TLS 1.2の Handshakeプロトコルのヘッダー
TLS 1.3 のHandshakeプロトコルと基本、共通のようです。
struct {
HandshakeType msg_type; /* メッセージの種類 1バイト */
uint24 length: /*メッセージの長さ 3バイト */
HandshakeMessage message;
} Handshake;
TLS 1.2のフルハンドシェイク
以前のセッションが存在しない場合（新規の接続の場合）、クライアントとサーバーはフルハンドシェイクを実行して新しいセッションを確立します。この際実施するのは以下の4点です。
1.接続で使用したいパラメーターを双方が提示し、相互に合意する。
2.提示された証明書（1つ or 複数）、または別な方法を使って認証を行う。
3.セッションの保護に使うマスターシークレット（master secret) を共有する。
4.ハンドシェイクのメッセージ（複数ある）が第3者によってい書き換えられていないことを検証する。
TLS 1.2では上記の2.と3.は実際には1ステップでまとめて実行します。このステップを鍵交換（key exchange）と呼びます。鍵確立（key establishment）と呼ぶこともあります。
TLS 1.3ではサーバー認証と鍵交換が分離されました。TLS 1.3では通常の認証で使用するメッセージ群が他のメッセージから分離され統一されました。
原著ではTLSのセキュリティはTLSの外側にある認証の仕組みが正しく機能していることが重要（必須）という事を強調しています。
TLS 1.2 フルハンドシェイクの形態
サーバー認証モード 認証されないクライアントと認証されるサーバー間でのハンドシェイク。最も一般的な形態
クライアント認証モード クライアントが認証される場合
セッションの再開（Session resumption） 以前のセッションを再開する場合
TLS 1.2 サーバー認証モードによるフルハンドシェイク
TLS 1.3のフルハンドシェイクの例
原著のTLS 1.3の説明にあるフルハンドシェイクの例は下記です。
TLS 1.2で3RTT以上？必要だったハンドシェイク完遂までの通信が、TLS 1.3では1RTTまで短縮されています。
TLS 1.2 フルハンドシェイクの説明
上掲の説明です。
①クライアントが新規のハンドシェイクを開始する。希望する暗号スイート、鍵交換方式などのパラメーターをサーバーに送信。
②サーバーがパラメーターを決定
③サーバーが自身の証明書チェーンを送信する（サーバー認証が必要な場合のみ）
④マスターシークレットの生成に必要な情報がある場合、サーバーからクライアントに送信する。
※必要な情報は選択した鍵交換方式によって変わる。
⑤ネゴシエーションにおけるサーバー側メッセージが完了したことをクライアントに通知
⑥マスターシークレットの生成に必要な情報をクライアントからサーバーに送信
⑦クライアントが暗号通信に切り替えることをサーバーに通知
⑧クライアントから送信および受信したハンドシェイクメッセージのMACを送信
MACは改竄されていないことを確認するためのメッセージ
⑨サーバー側で暗号通信に切り替えることをクライアントに通知
⑩サーバーから送信および受信したハンドシェイクメッセージのMACを送信
以上の通信で暗号通信が確立し、以降でアプリケーションのデータ送受信が開始されます。