TLS协议概述
咱们做安全通信的，绕不开TLS。说白了，它就是给网络对话加了一层加密信封。我最早接触TLS还是1.2时代，那时候刚接手一个金融API项目，领导说“用HTTPS就行”，结果一抓包，证书链都没验——嗯，那次我写了好几页的整改报告。今天咱们从根上聊聊TLS是什么、怎么来的、用在哪，以及协议栈到底长什么样。
1.1 TLS的历史演变
TLS的前身是SSL（Secure Sockets Layer），网景公司90年代搞出来的。我记得96年出的SSL 3.0，后来IETF接手，改名TLS 1.0（1999年）。之后版本迭代：1.1（2006）、1.2（2008）、1.3（2018）。每个版本都塞了不少血泪教训。
关键版本特性对比：
| 版本 | 发布年份 | 核心改进 | 当前状态 |
|---|---|---|---|
| SSL 3.0 | 1996 | 首次公开标准 | 已弃用（POODLE攻击） |
| TLS 1.0 | 1999 | 基于SSL 3.0，规范加密套件 | 已弃用（BEAST攻击） |
| TLS 1.1 | 2006 | 防御CBC攻击，改善IV处理 | 已弃用 |
| TLS 1.2 | 2008 | 支持AEAD、SHA-256，灵活协商 | 广泛使用（推荐） |
| TLS 1.3 | 2018 | 精简握手、前向安全、移除RC4/3DES | 大力推荐 |
为什么会走到1.3？你想想看，1.2的握手要两轮RTT，1.3降到1轮，连接建立快了一倍。我做过压测，1.3在弱网环境下能把建连时间从80ms压到30ms。
1.2 应用场景
TLS早就不是HTTPS的专利了。咱们列几个常见场合：
- Web安全（HTTPS）：浏览器到服务器的加密通道，最广为人知。我调过不下50个TLS配置，说白了就是证书、套件、版本三板斧。
- 邮件传输（SMTPS/IMAPS）：给邮件传输上层锁。以前没TLS时邮件明文乱跑，现在StartTLS是标配。
- VPN隧道：OpenVPN底层就用TLS做密钥协商，不用再搞复杂的IPSec
- 物联网（MQTT over TLS）：设备端资源有限，TLS 1.3的0-RTT握手特别香
- 内部微服务：gRPC默认用TLS做双向认证。我给客户做过一套，服务间通信全走mTLS，省了独立的认证服务
1.3 协议栈结构
TLS协议栈是分层设计的，清晰得像个洋葱。从上到下：握手协议（协商密钥、认证身份）、记录协议（加密、完整性）、警报协议（异常通知）。底下跑在TCP上。
我习惯把它画成四层图。下面这张SVG结构图，你一看就明白：
你看，握手协议在上层负责“商量用什么锁”，记录协议在下层负责“上锁和验锁”。警报协议则是当出了问题（比如证书过期），双方优雅地断连。
我整理了一张表格，把分层职责说清楚：
| 协议子层 | 主要功能 | 典型消息/操作 |
|---|---|---|
| 握手协议 | 协商加密套件、交换密钥、验证身份 | ClientHello, ServerHello, Certificate, Finished |
| 警报协议 | 传递错误和关闭通知 | close_notify, fatal alert |
| 记录协议 | 数据分片、压缩、加密、MAC计算 | ApplicationData, ChangeCipherSpec |
再说个细节：记录协议里有个“内容类型”字段（1字节），指明载荷是握手消息、警报、还是应用数据。我在抓包分析时经常靠这个字段快速定位问题：如果看到type=22（握手），说明还在建连；type=23（应用数据），才真正开始传业务。
嗯，这一章的内容差不多了。我个人的建议是：无论你是刚开始学TLS，还是老手温故，先把协议栈分层记牢——它决定了后续所有安全设计和排查思路。