去年某电商平台被拖库，数据泄露了 1200 万条用户记录。传输事后复盘发现，加密数据库里存的数据手机号居然还是明文。开发团队的传输解释是“内网环境，没必要加密”。加密这种想法在中小团队里太常见了——等出事再补，数据往往已经晚了。传输

数据传输加密这件事，加密落到实操层面，数据绕不开三种方式。传输它们各有各的加密脾气，用错了地方，数据要么白费力气，传输要么拖垮性能。加密

对称加密：快，但钥匙不好给

AES 是目前对称加密里的绝对主力。它的逻辑很直白：一把钥匙锁门，同一把钥匙开门。加密和解密用同一个密钥，速度快得惊人。我实测过，在一台普通服务器上，AES-256 的加解密吞吐量能跑到 1GB/s 以上。这意味着你拿它加密数据库里的敏感字段，几乎感觉不到延迟。

问题出在密钥分发上。你跟服务器通信，密钥怎么传过去？直接发？那中间人截获密钥就等于拿到了所有数据。所以对称加密很少单独出现在传输场景里，它更像是一个干重活的角色，需要别人帮它把钥匙安全送到。

有个细节值得注意：AES 有不同的工作模式。ECB 模式对相同明文块产生相同密文块，能看出图片轮廓那种，千万别用。CBC 需要随机初始化向量，GCM 还自带完整性校验。选错了模式，加密效果打对折。

非对称加密：解决钥匙传递，但慢得让人着急

RSA 和 ECC 属于这一类。公钥随便发，私钥自己留着。你用我的公钥加密，只有我的私钥能解开。密钥分发的问题一下就没了。

代价是速度。RSA-2048 的加解密速度比 AES 慢了好几个数量级。拿它加密大文件？不现实。我见过有人用 RSA 直接加密 HTTP 响应体，QPS 直接掉到个位数，CPU 跑满。非对称加密的正确用法是加密“对称加密的密钥”，而不是加密数据本身。

ECC 比 RSA 更划算。256 位的 ECC 密钥强度约等于 3072 位的 RSA，计算量小得多。移动端和 IoT 设备上，ECC 几乎是默认选择。但 ECC 的实现复杂度高，曲线参数选不好会留后门——当年 Dual_EC_DRBG 那事就是个教训。

TLS/SSL：把前两种打包成一套工程方案

你每天访问 HTTPS 网站，背后就是 TLS 在干活。它没有发明新的加密算法，而是把对称和非对称捏在一起，加上证书体系，形成一套可落地的协议。

握手阶段用非对称加密（或 ECDHE 密钥交换）协商出一个会话密钥，之后的数据传输全部用对称加密。证书由 CA 签发，解决“我拿到的公钥到底是不是你的”这个问题。这套组合拳打下来，既安全又够快。

TLS 1.3 把握手过程压缩到一次往返，甚至支持 0-RTT 恢复。但 0-RTT 有重放攻击的风险，不是所有场景都能开。我见过一些团队为了追求性能强行开 0-RTT，结果被安全扫描扫出漏洞，又灰溜溜关掉。

选哪种方式，取决于你的场景。内网服务间通信，mTLS 加上短有效期证书，够用。用户密码存库，bcrypt 或 argon2 这类慢哈希更合适，别拿 AES 去加密密码——那是另一回事。移动端 API，ECC 证书加 TLS 1.3，兼顾安全和电量。

加密不是银弹。密钥管理、证书轮换、算法升级，这些脏活累活才是真正吃功夫的地方。见过太多团队加密算法选得漂亮，密钥硬编码在代码里，等于没加密。