3. TLS下的数据封装：TLS记录层如何封装应用数据、TLS记录头结构

好，我们进入第三讲。这一章咱们聊聊TLS记录层——说白了，就是应用数据在TLS连接里到底是怎么被“打包”的。

我记得刚接触TLS协议栈那会儿，总觉得握手过程很复杂，记录层嘛，不就是加个头、分个片？后来在项目中排查一个粘包问题，才发现记录层的封装细节直接决定了拆包能不能拆对。嗯，这一章我们把它彻底讲透。

3.1 TLS记录层的位置与职责

TLS协议分两层：上层是握手、告警、ChangeCipherSpec等子协议，下层就是记录层。记录层是所有上层数据的“运输工”。

它的核心职责就三条：

分片：把上层消息切成不超过2^14字节（16KB）的片段
压缩（可选，现代TLS基本不用）
加密与完整性保护：用当前会话的密钥加密，并附加MAC

你想想看，应用层发过来的数据可能很大，比如一个HTTP POST请求体有几十KB。TLS记录层会把它切成多个记录，每个记录独立加密、独立传输。这就是粘包拆包问题的根源之一——接收方必须知道每个记录的边界。

关键认知：TLS记录层是面向记录的，不是面向流的。每个记录都有明确的长度字段，这是拆包的基础。

3.2 TLS记录头结构

每个TLS记录前面都有一个5字节的固定头部。结构非常简单，我直接给你看：

字段	长度	说明
Content Type	1字节	上层协议类型（20=ChangeCipherSpec, 21=Alert, 22=Handshake, 23=Application Data）
Protocol Version	2字节	TLS版本号，如TLS 1.2为0x0303，TLS 1.3为0x0304
Length	2字节	记录负载的长度（不包括头部），最大16384字节

就这么简单？对，就这么简单。但别小看这5个字节，它是拆包的唯一依据。

我在项目中遇到过一个问题：客户端和服务器的TLS版本不一致，服务端发了TLS 1.2的记录，客户端却用TLS 1.3的解析方式去读版本字段，结果长度解析错了，整个连接直接断开。所以版本字段虽然只有2字节，但校验不能省。

3.3 应用数据的封装流程

应用数据从上层到达记录层，经历以下步骤：

分片：如果应用数据超过16KB，切成多个片段，每个片段单独封装
压缩（TLS 1.3已移除，TLS 1.2中也很少启用）
添加MAC：计算消息认证码，用于完整性校验
填充（仅流密码或CBC模式）：使明文长度符合块大小
加密：使用当前会话的加密密钥加密
添加记录头：加上5字节头部，形成完整的TLS记录

下面这张图展示了TLS 1.2中一个应用数据记录的完整结构：

我的经验：在TLS 1.2中，MAC长度取决于协商的哈希算法。SHA-1是20字节，SHA-256是32字节。如果你在拆包时硬编码了MAC长度，遇到不同算法就会出问题。我建议从密码套件中动态获取。

3.4 记录边界与拆包的关系

为什么讲记录层要提拆包？因为TCP是流协议，没有消息边界。而TLS记录层恰好提供了这个边界——每个记录头部都有Length字段。

拆包的基本思路就是：

先读5字节，解析出Length
再读Length字节，得到完整的记录负载
解密、验证、处理

听起来很简单对吧？但实际项目中坑不少。我曾经遇到一个情况：客户端发了两个TLS记录，但TCP粘包了，第一个记录的最后几个字节和第二个记录的头混在一起。如果我的拆包逻辑没处理好，就会把第二个记录的头当成第一个记录的负载来解析，直接导致解密失败。

注意：TLS记录的最大长度是16384字节（2^14），但实际中很多服务器会限制更小。比如我见过一些CDN节点把记录限制在4096字节以内。拆包时不要假设接收缓冲区一定能装下整个记录，要做好分次读取的准备。

3.5 代码示例：解析TLS记录头

下面是一个简单的Python示例，演示如何从字节流中解析TLS记录头：

import struct

def parse_tls_record_header(data):
    """
    解析TLS记录头
    返回 (content_type, version, length) 或 None
    """
    if len(data) < 5:
        return None
    
    # 解包：B=1字节无符号整数，H=2字节无符号整数（网络字节序）
    content_type, version_major, version_minor, length = struct.unpack('!BBH', data[:5])
    
    version = (version_major, version_minor)
    
    # 校验Content Type
    if content_type not in (20, 21, 22, 23):
        print(f"警告：未知的Content Type {content_type}")
        return None
    
    # 校验版本
    if version_major != 3:
        print(f"警告：非TLS版本 major={version_major}")
        return None
    
    # 校验长度
    if length > 16384:
        print(f"警告：记录长度 {length} 超过最大限制")
        return None
    
    return {
        'content_type': content_type,
        'version': f"TLS 1.{version_minor - 1}",
        'length': length
    }

# 示例用法
raw_header = b'\x17\x03\x03\x00\x80'  # Application Data, TLS 1.2, 128字节负载
header = parse_tls_record_header(raw_header)
print(header)
# 输出：{'content_type': 23, 'version': 'TLS 1.2', 'length': 128}

避坑指南：我曾经在解析时忘了校验Length字段，结果一个恶意客户端发了个Length=65535的伪造记录，我的缓冲区直接爆了。从那以后，我每次解析都会做三层校验：Content Type合法、版本合法、Length不超过16384。

3.6 TLS 1.3对记录层的简化

TLS 1.3在记录层做了不少简化，我简单列一下：

移除了压缩：压缩在TLS 1.2中就是安全漏洞的重灾区（还记得CRIME攻击吗？），1.3直接砍掉了
AEAD成为唯一加密方式：不再有单独的MAC字段，认证和加密合二为一
记录类型加密：握手后的记录，Content Type字段被加密保护，防止流量分析
版本固定：记录头中的版本字段始终写0x0303（TLS 1.2），实际版本在握手时协商

这些变化对拆包有什么影响？嗯，最大的影响是——你不能再依赖Content Type来判断记录类型了。在TLS 1.3中，握手完成后的所有记录，Content Type都显示为Application Data（23），真正的类型藏在加密负载里。

所以如果你要支持TLS 1.3，拆包逻辑需要调整：先根据Length拆出完整记录，解密后再解析内部类型。顺序不能搞反。

3.7 小结

这一章我们讲了TLS记录层的核心：5字节的头部结构、应用数据的封装流程、以及记录边界对拆包的意义。说白了，记录层就是TLS的“打包工”，它把应用数据切成块、加密、加头，然后交给TCP传输。接收方要做的，就是根据头部Length字段，一块一块地拆出来。

📚 课程目录

3. TLS下的数据封装：TLS记录层如何封装应用数据、TLS记录头结构

3.1 TLS记录层的位置与职责

3.2 TLS记录头结构

3.3 应用数据的封装流程

3.4 记录边界与拆包的关系

3.5 代码示例：解析TLS记录头

3.6 TLS 1.3对记录层的简化

3.7 小结