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を送信

以上の通信で暗号通信が確立し、以降でアプリケーションのデータ送受信が開始されます。