第二章：TLS协议栈结构与位置归纳

聊完TLS的基本概念，咱们得把它的“骨架”搭起来看看。说实话，很多同学学TLS只盯着握手过程，忽略了协议栈的整体结构。这就好比只学心肺复苏，却不了解人体解剖结构一样——真要抢救的时候，你都不知道该从哪里下手。

TLS在TCP/IP模型中的位置

咱们先看宏观位置。你想想看，TLS到底挂在哪一层？

标准说法是：TLS位于传输层与应用层之间。也就是说，TCP管的是可靠传输，TLS管的是安全防护。HTTP、FTP、SMTP这些应用协议，都跑在TLS之上。我个人习惯把这层叫做“安全传输适配层”，因为它既不是纯粹的网络层，也不是纯粹的应用层。

我举个例子你就明白了：

应用层     HTTP / FTP / SMTP
   ↕
安全层     TLS
   ↕
传输层     TCP
   ↕
网络层     IP

这么一个“三明治”结构。TLS夹在中间，接收上层的数据，加密后再交给TCP发送。反过来，从TCP收到的密文，由TLS解密后交给上层应用。

TLS协议栈内部结构

再往细了看，TLS自己也不是铁板一块。它内部有好几个子协议，各有各的职责。我在项目中遇到最常见的问题就是有人把这几个子协议搞混，调试的时候对着错误的日志瞎找原因。

咱们把它拆开看看：

层级	子协议	功能简述
上层	握手协议	协商密码套件、交换密钥、认证身份
	警报协议	报告错误和关闭连接
	Change Cipher Spec	通知对方切换加密策略
下层	记录协议	分片、压缩、加密、封装

你仔细看这个结构。握手协议、警报协议、Change Cipher Spec协议，它们都属于TLS的上层协议。但它们发出的数据，最终都要交给记录协议去打包、加密、发送。

说白了，记录协议就是TLS的“快递小哥”。上层协议写好信，记录协议负责封好信封、贴上锁、送到对方手上。

记录协议的核心职责

咱们重点聊记录协议。为啥？因为所有TLS流量，最终都是通过记录协议传输的。

记录协议干的事不少：

1. 分片：上层数据太大？切了再发。最大分片通常是16KB。
2. 压缩：可选功能。不过现在基本没人用，因为压缩容易带来安全问题。
3. 添加MAC：计算消息认证码，确保完整性。
4. 加密：用握手协商好的密码套件加密数据。
5. 添加记录头：标记内容类型、协议版本、长度。

每个记录的数据结构是这样的：

struct {
    ContentType type;        // 1字节，标识上层协议类型
    ProtocolVersion version; // 2字节，TLS版本
    uint16 length;           // 2字节，负载长度
    opaque fragment[TLSPlaintext.length]; // 负载数据
} TLSPlaintext;

注意这个 ContentType，它很重要。取值如下：

• 0x14 — Change Cipher Spec
• 0x15 — 警报
• 0x16 — 握手
• 0x17 — 应用数据

我曾经调试过一个诡异的TLS连接中断问题，抓包一看，某个中间设备把 ContentType 给改了，导致接收端无法识别协议类型。这种坑，你只看应用层日志是永远找不到的。

握手协议的内部结构

握手协议呢？它比记录协议复杂得多。咱们先不深入具体流程，只看它在协议栈里的位置。

握手协议发出的消息，内容包括：

struct {
    HandshakeType msg_type;    // 1字节，消息类型
    uint24 length;             // 3字节，消息体长度
    opaque body[Handshake.length]; // 消息体
} Handshake;

HandshakeType 定义了十几种类型，比如：

• client_hello (1) — 客户端问候
• server_hello (2) — 服务端问候
• certificate (11) — 证书传输
• server_key_exchange (12) — 服务端密钥交换
• finished (20) — 握手完成校验

这里有个容易搞混的地方：每条握手消息本身，也是一个记录层的数据包。也就是说，一次握手过程可能发送十几条记录，每条记录又包含一条或多条握手消息。

你想想看，如果抓包分析的时候把“记录”和“消息”混为一谈，那分析结果肯定一团糟。

协议栈总结：一张图看清全局

好了，上面讲了不少。我用一张图把整个TLS协议栈的层级关系和子协议关系总结一下。这张图我调试的时候经常拿出来对照，防止自己迷失在细节里。

这张图展示了TLS协议栈的完整层次。从上到下依次是：应用层、TLS上层子协议、TLS记录协议、TCP。每条数据从应用层下来，先经过握手/警报/Change Cipher Spec打包（或者直接是应用数据），再交给记录协议进行分片、加密、加头，最后通过TCP发出去。

反过来也一样。TCP收到密文后交给记录层，记录层解密、校验、重组，再根据ContentType判断是握手消息还是应用数据，投递给对应的上层处理。

实践中的一点感悟

我刚开始搞TLS的时候，总觉得分层是理论家的事，写代码直接调OpenSSL API就完事了。直到有一次线上出问题，客户端和服务端握手到一半就断了。我盯着API返回值看了半天，啥也没看出来。后来用抓包工具看原始记录层数据，才发现是记录层分片尺寸不一致导致的兼容性问题。

从那以后我就得了“强迫症”——无论遇到什么TLS问题，第一件事就是看记录层的 ContentType 和 length。这个习惯帮我省了不少时间。