1. TLS/DTLS概述：网络安全背景、定义、发展历史与标准、应用场景对比
1.1 为什么我们需要TLS？——网络安全的现实困境
先问一个问题：你在网上输入密码、转账、发私信时，数据是怎么走的？
说白了，互联网从设计之初就没考虑「安全」这件事。TCP/IP协议栈的核心目标是「连通」，不是「保密」。数据包在网络里就像明信片——每个中间节点都能拆开看。
我早年做网络监控项目时，亲眼见过一个运维同事在机房抓包，直接看到了隔壁公司ERP系统的明文登录密码。嗯，那家公司用的还是HTTP Basic Auth。从那以后，我对「明文传输」这四个字就特别敏感。
核心问题：互联网通信面临三大安全威胁——
- 窃听（Eavesdropping）：数据在传输过程中被第三方截获并读取。
- 篡改（Tampering）：中间人修改数据包内容，接收方浑然不知。
- 冒充（Impersonation）：攻击者伪装成服务器或客户端，骗取信任。
你想想看，如果没有加密和认证，你的银行APP怎么确认连的是真银行？你的邮件客户端怎么知道收到的不是伪造的？
这就是TLS要解决的问题。
1.2 TLS与DTLS的定义——它们到底是什么？
TLS（Transport Layer Security，传输层安全协议），前身是SSL。它工作在传输层之上、应用层之下。用大白话说：它在TCP连接外面包了一层加密壳，让HTTP、FTP、SMTP这些应用协议的数据变得「只有通信双方能看懂」。
DTLS（Datagram Transport Layer Security，数据报传输层安全协议），是TLS在UDP上的变体。UDP本身不可靠、无连接，DTLS在保留UDP低延迟特性的同时，加上了加密和认证能力。
我的理解：TLS是给「打电话」用的（建立连接、保证顺序），DTLS是给「发快递」用的（每个包裹独立、可能丢件、可能乱序）。两者目标一致，但实现路径不同。
我曾经在一个物联网项目中踩过坑：设备端用UDP上报传感器数据，直接裸传。后来客户要求加密，我第一反应是上TLS，结果发现UDP连不上TLS握手——因为TLS依赖TCP的可靠传输。最后换成了DTLS，问题解决。这个教训让我记住了：选协议之前，先搞清楚底层传输层是什么。
1.3 发展历史与标准——从SSL 1.0到TLS 1.3
这段历史挺有意思，我简单梳理一下。
| 版本 | 发布年份 | 关键变化 | 现状 |
|---|---|---|---|
| SSL 1.0 | 1994（未公开） | Netscape内部版本，有严重安全漏洞 | 从未正式发布 |
| SSL 2.0 | 1995 | 首次公开，但存在多个设计缺陷 | 已废弃（RFC 6176） |
| SSL 3.0 | 1996 | 大幅改进，引入HMAC、证书链验证 | 已废弃（RFC 7568） |
| TLS 1.0 | 1999 | 基于SSL 3.0，标准化为RFC 2246 | 已废弃（PCI DSS禁止使用） |
| TLS 1.1 | 2006 | 修复CBC攻击，增加IV保护 | 已废弃 |
| TLS 1.2 | 2008 | 支持AEAD、SHA-256、GCM模式 | 广泛使用（推荐） |
| TLS 1.3 | 2018 | 握手从2-RTT降到1-RTT，移除不安全算法 | 最新标准（强烈推荐） |
DTLS的发展相对晚一些：
- DTLS 1.0（RFC 4347，2006年）：基于TLS 1.1，适配UDP场景。
- DTLS 1.2（RFC 6347，2012年）：基于TLS 1.2，是目前主流版本。
- DTLS 1.3（RFC 9147，2022年）：与TLS 1.3对齐，握手更快、更安全。
避坑提醒：我曾经在审计一个老旧系统时发现，对方还在用SSL 3.0。POODLE攻击（2014年）就是针对SSL 3.0的，攻击者可以解密HTTPS流量中的Cookie。如果你现在还在用SSL 3.0或TLS 1.0，请立刻升级。这不是建议，是要求。
1.4 核心知识体系——一张图看懂TLS/DTLS
下面这张SVG图，我把TLS/DTLS的核心模块和关系画了出来。建议你保存下来，后面每学一章都可以回来对照。
1.5 应用场景对比——什么时候用TLS，什么时候用DTLS？
这个问题我经常被问到。直接上对比表：
| 对比维度 | TLS | DTLS |
|---|---|---|
| 底层传输 | TCP（可靠、保序） | UDP（不可靠、不保序） |
| 握手延迟 | TLS 1.2：2-RTT；TLS 1.3：1-RTT | DTLS 1.2：2-RTT；DTLS 1.3：1-RTT（支持0-RTT） |
| 丢包处理 | TCP重传保证 | 应用层自行处理丢包和重排序 |
| 典型场景 | HTTPS、FTPS、SMTP、LDAPS | VoIP、视频会议、在线游戏、IoT传感器 |
| 实时性要求 | 低（容忍延迟） | 高（低延迟优先） |
| 实现复杂度 | 相对成熟，库支持完善 | 略复杂（需处理乱序、重放） |
我的选择原则：
- 如果你的应用层协议跑在TCP上（比如HTTP、FTP），无脑选TLS。
- 如果你的应用层协议跑在UDP上（比如RTP、CoAP），或者你需要极低握手延迟（比如游戏登录），选DTLS。
- 如果你不确定——选TLS。TLS的生态更成熟，调试工具更多，踩坑成本更低。
我记得有一次帮一个直播平台做安全加固。他们的信令服务用的是WebSocket over TCP，自然用了TLS。但媒体流用的是UDP + SRTP，他们问我能不能也用TLS？我说不行，UDP上跑不了TLS，得用DTLS-SRTP。后来他们改用了DTLS 1.2做媒体流的密钥协商，效果不错。
1.6 本章小结——你该带走什么？
- TLS和DTLS的本质：都是在不可信网络上建立可信通道的工具。TLS面向TCP，DTLS面向UDP。
- 版本选择：能用TLS 1.3就别用1.2，能用DTLS 1.3就别用1.2。旧版本有已知漏洞，不值得冒险。
- 场景决定协议：不要为了「用DTLS而用DTLS」。如果你的应用不需要UDP的特性，TLS是更稳妥的选择。
一句话总结：TLS是「可靠的加密管道」，DTLS是「快速的加密包裹」。选哪个，取决于你的传输层是TCP还是UDP，以及你对延迟和可靠性的容忍度。