1、加密传输概述：为什么需要加密传输、对称加密与非对称加密、HTTPS与SSL/TLS协议基础
各位同学，咱们今天正式开课。聊加密传输之前，我先讲个真事。
几年前我帮一家电商公司做安全审计，发现他们的内部API调用全是明文。说白了，用户下单时填的地址、手机号、信用卡后四位，在网络里就跟没穿衣服似的。我随手在办公楼的公共Wi-Fi上抓了个包，十分钟就还原了一笔订单的全部信息。嗯，那家公司当天晚上就紧急上了HTTPS。
你想想看，如果连传输通道都不加密，那你的防火墙、入侵检测、WAF，全都是在给一栋没有锁的门装监控——有用，但治标不治本。
1.1 为什么需要加密传输
网络传输的本质，是数据从一个节点跳到另一个节点。中间经过路由器、交换机、网关，甚至可能经过你不认识的ISP骨干网。任何一个中间节点，只要有人做了抓包操作，你的数据就是透明的。
我遇到过最典型的场景：某客户的内网部署了明文HTTP服务，运维人员图省事，所有管理接口都走80端口。结果内部员工用了一个简单的ARP欺骗工具，就把管理员的会话Cookie给劫持了。你说这是技术问题还是管理问题？其实都有，但最根本的——传输没加密。
加密传输要解决三个核心问题：
- 机密性：数据在传输过程中不能被第三方读懂。就算被抓包，看到的也是一堆乱码。
- 完整性：数据在传输过程中不能被篡改。如果有人中间改了报文，接收方能发现。
- 身份认证：你能确认和你通信的确实是对方，而不是中间人冒充的。
一句话总结：加密传输不是为了防黑客，而是为了让你在网络这个"公共走廊"里，能放心地传递私密信息。
1.2 对称加密与非对称加密
加密算法分两大类，我习惯把它们比作两种锁。
对称加密
加密和解密用同一把钥匙。就像你家的门锁，用钥匙锁门，也用同一把钥匙开门。速度快，适合加密大量数据。
常见的对称加密算法：
| 算法 | 密钥长度 | 特点 |
|---|---|---|
| AES | 128/192/256位 | 目前最主流，硬件加速支持好 |
| ChaCha20 | 256位 | 移动端性能优秀，Google力推 |
| 3DES | 168位 | 已过时，不推荐使用 |
| SM4 | 128位 | 国密标准，国内合规场景必用 |
对称加密有个致命问题：密钥怎么安全地传给对方？你想想看，如果密钥本身通过网络明文传输，那加密还有什么意义？
我的经验：对称加密适合在已经建立安全通道后使用。比如HTTPS握手完成后，后续的大量数据传输都用对称加密。速度快，开销小。
非对称加密
加密和解密用不同的钥匙。一把公钥公开，一把私钥自己藏好。公钥加密的数据，只有私钥能解开；反过来，私钥签名，公钥可以验证。
常见的非对称加密算法：
| 算法 | 密钥长度 | 特点 |
|---|---|---|
| RSA | 2048/4096位 | 应用最广，但密钥越长性能越差 |
| ECDSA | 256/384位 | 基于椭圆曲线，同等安全强度下密钥更短 |
| SM2 | 256位 | 国密标准，国内政企项目必备 |
| Ed25519 | 256位 | 现代高性能选择，签名速度快 |
非对称加密解决了密钥分发问题，但性能比对称加密慢几百倍。所以实际应用中，两者是配合使用的。
避坑指南：我曾经见过一个项目，直接用RSA加密每一条HTTP请求体，结果服务器CPU直接飙到100%。非对称加密只适合加密小数据，比如对称密钥、数字签名、证书验证。大批量数据加密，请交给AES。
混合加密：取长补短
实际生产环境用的都是混合加密。流程大致是这样：
- 客户端用非对称加密，安全地把一个临时生成的对称密钥传给服务器。
- 双方确认身份后，后续所有通信都用这个对称密钥加密。
- 对称密钥用完即弃，下次连接重新生成。
这就是HTTPS的底层逻辑。说白了，非对称加密负责"握手"，对称加密负责"传输"。
1.3 HTTPS与SSL/TLS协议基础
HTTPS不是一种新协议，它就是HTTP跑在SSL/TLS之上。SSL/TLS才是真正的加密传输协议。
我刚开始做Web开发时，总觉得HTTPS就是"装个证书就行"。直到有一次线上事故——证书过期了，整个电商网站无法下单，我才老老实实把TLS握手流程研究了一遍。
TLS握手核心流程
一个简化的TLS 1.3握手过程：
- Client Hello：客户端告诉服务器，我支持哪些TLS版本、加密套件。
- Server Hello：服务器选定版本和加密套件，发回自己的证书（含公钥）。
- 证书验证：客户端验证证书是否由可信CA签发、是否过期、域名是否匹配。
- 密钥交换：双方通过非对称加密或DH算法，协商出一个对称密钥。
- 加密通信：后续所有HTTP数据都用这个对称密钥加密传输。
关键点：TLS 1.3把握手从2-RTT降到了1-RTT，首次连接速度明显提升。如果你还在用TLS 1.2，建议尽快升级。
SSL与TLS的区别
| 协议 | 版本 | 状态 |
|---|---|---|
| SSL 2.0 | 1995年 | 已废弃，有严重安全漏洞 |
| SSL 3.0 | 1996年 | 已废弃，POODLE攻击可破解 |
| TLS 1.0 | 1999年 | 已废弃，BEAST攻击 |
| TLS 1.1 | 2006年 | 已废弃，PCI DSS禁止使用 |
| TLS 1.2 | 2008年 | 广泛使用，但建议迁移 |
| TLS 1.3 | 2018年 | 推荐使用，安全且高效 |
重要提醒：我审计过的项目中，还有不少在用TLS 1.0甚至SSL 3.0。这些协议已经公开破解多年，抓包工具可以直接解密。如果你负责的系统还在用，请立刻禁用。
证书链与信任模型
HTTPS的信任基础是CA（证书颁发机构）。服务器证书由CA签名，CA的证书又由根CA签名。客户端操作系统或浏览器内置了根证书，形成一条信任链。
我遇到过最坑的事：某公司自建了内部CA，但所有客户端都没安装根证书。结果内网HTTPS页面全部报"证书不可信"，员工只好点"继续访问"——这跟没加密有什么区别？
建议：内网自建CA没问题，但一定要通过组策略或MDM把根证书推送到所有终端。否则HTTPS就变成了"吓唬老实人"的摆设。
本章知识体系
下面这张图把本章的核心逻辑串起来了。你可以把它当作后续章节的地图。
这张图里，左边是"为什么"，中间是"用什么算法"，右边是"怎么落地"。三者缺一不可。很多工程师只关注右边的HTTPS配置，忽略了算法选择和加密目标，结果就是"配置了HTTPS但没解决安全问题"。
好了，第一章就到这里。加密传输不是玄学，是工程。后面的章节，我会带你一步步搭建真正的加密通道——从证书生成、Nginx配置、双向认证，到性能调优和故障排查。咱们下章见。