对于 QPS 比较高的入口, 从 HTTP 迁移到 HTTPS, 最重要的因素是要先判断这台机器的 TLS/SSL 计算能力. 你可能从一台 64G 内存的普通机器, 放个 nginx, 就能抗住百万并发, 迁移到 HTTPS 之后, CPU 的 load 完全就无法应对那么高的 TLS/SSL 握手 , 导致用户无法连接.
如何简单地判断从 HTTP 切换到 HTTPS 的成本呢? 主要看下面几点:
- 机器对 RSA 的私钥解密 (或签名) 的计算能力
- 是长连接还是短连接
- 机器对 AES 的计算能力
- 面向的客户端是否支持 SSL 的 session reuse
HTTPS 的连接的建立
简单的说, TCP 握手后, SSL 握手使用 `非对称加密` 的方式让双方都获得一个 `对称加密` 的密码, 之后的数据传输使用的是 `对称加密`. 请注意非对称加密的部分比起对称加密, 对 CPU 的计算要求高很多. TLS/SSL 的证书有很多这, 加密方法也有很多, 下文只讨论 RSA 2048 的证书, 使用 AES 256 CBC 的加密进行传输.
RSA 的解密速度
一个安全 RSA 的证书, 现在一般要有 2048 bit 的长度. 对于 RSA 的算法, 如果我们是使用 OpenSSL 这个库 (nginx 和 haproxy 都是), 可以使用:
openssl speed rsa2048
这个命令去检查所在物理机的解密速度, 比如下面就是我电脑上的 output:
sign verify sign/s verify/s
rsa 2048 bits 0.003110s 0.000079s 321.5 12699.7
对于服务端, 最重要的就是看 `sign/s` 对应的数值, 这边是 `321.5`, 这个数值说明, 在单核上面每秒钟只能用私钥解密 321 次, 这其实就决定了我的这个CPU, 单核的话, 每秒的 HTTPS 连接创建只能达到 321 个 (还要考虑 http server的其他消耗, 所以会更小).
另外, 我们还可以看看 OpenSSL 对 AES 对称加密的能力:
openssl speed aes-256-cbc
结果是这样的:
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-256 cbc 95595.93k 104182.68k 105314.10k 103842.47k 104320.15k
可见, AES 的加解密速度非常快 (这边的结果是每秒的加解密流量).
长连接还是短连接
长连接以前只是为了减少 tcp 三次握手的开销, 有了 HTTPS 之后, 还能减少 TLS/SSL 的握手开销, 相当于是减少了非对称加密的部分.
SSL session
SSL session 简单的说就是客户端可以保存之前已经商量好的对称加密秘钥, 下次如果双方都统一使用的话, 就可以跳过非对称加密握手的部分, 直接进行 AES 对称加密的内容. 这个 session 的重用要比上面的长连接更有效果, 因为它是和连接无关的.
HTTPS offload gateway 的选择
选择 haproxy 还是 nginx 去做 https 的 offload, 主要有下面这几个考虑:
- 是否支持 session cache (tls 还有 ticket 的方式我们没讲到)
- 是否支持 SNI, 如果你的公网 IP 资源有限, 又有多个域名需要考虑
- 更好的监控
前面两点, 两个代理都能做, 但是第三点, nginx没有任何能让你采集当前 ssl 的握手速度, session reuse的比例等等的指标; haproxy 有类似的指标可以使用, 是非常有用的功能. 至于代理能力两者是完全一样的. 唯一的一个缺憾是 haproxy 的多进程模型不是 master/slave 的方式, 所以在使用 TCP reuseport 的时候, 会有小概率事件导致 reload 进程的时候会产生 TCP RST.
总结
HTTPS 迁移最重要的就是预先规划计算资源, 你要了解当前的 QPS, 然后使用 OpenSSL 的工具去判断机器的计算能力, 及时的增加相应的计算资源. 大部分的至强 CPU, 比如 E5, 单核的 RSA 解密能力在 800 ~ 1000 左右, 所以一台 16 个物理核心(没超线程), 大致能接受的 HTTPS 新建连接数是 16k. 如果能做到 session reuse, 那就能做到更高的 QPS, 但是如果 session 被 flush 了, 那机器就有可能 CPU 跑高, 出现无法连接等情况.
感谢阅读.
