ECC 椭圆加密算术相比普通的离散对数计算速度性能要强不少。下表是 NIST 推荐的密钥长度对照表。对称密钥大小 | RSA 和 DH 密钥大小 | ECC 密钥大小----|------|---- 80|1024|160| 112|2048|224 128|3072|256 192|7680|384 256|15360|521 表格 2 NIST 推荐用的密钥长度对于 RSA 算法来讲，现在至少用 2048 位以上的密钥长度才能保证安全性。ECC 仅需用 224 位长度的密钥就能达成 RSA2048 位长度的安全强度。在进行相同的模指数运算时速度显然要快不少。
一般来讲，新版的 openssl 相比老版的计算速度和安全性都会有提高。譬如 openssl1.0.2 使用了 intel 最新的优化成就，椭圆曲线 p256 的计算性能提高了 4 倍。/Openssl 2014 年就升级了 5 次，基本都是为了修复达成上的 BUG 或者算法上的漏洞而升级的。所以尽可能用最新版本，防止安全上的风险。
目前比较常见的 TLS 硬件加速策略主要有两种HTTPS 计算性能优化
支持算法有限。譬如不支持 ECC，不支持 GCM 等。
升级本钱高。
出现新的加密算法或者协议时，硬件加速策略没办法准时升级。
出现比较大的安全漏洞时，部分硬件策略在没办法在短期内升级解决。譬如 2014 年暴露的 heartbleed 漏洞。
没办法充分借助硬件加速性能。硬件加速程序一般都运行在内核态，计算结果传递到应用层需要 IO 和内存拷贝开销，即便硬件计算性能很好，上层的同步等待和 IO 开销也会致使整体性能达不到预期，没办法充分借助硬件加速卡的计算能力。
维护性差。硬件驱动及应用层 API 大多数是由安全厂商提供，出现问题后还需要厂商跟进。用户没办法学会核心代码，比较被动。不像开源的 openssl，不管算法还是协议，用户都能学会。
也正是由于上述缘由，百度达成了专用的 SSL 硬件加速集群。基本思路是HTTPS 计算性能优化
RSA 中的加解密计算。
ECC 算法中的公私钥生成。
ECC 算法中的共享密钥生成。
优化硬件计算部分。硬件计算不涉及协议及状况交互，仅需处置大数运算。
Web server 到 TLS 计算集群之间的任务是异步的。即 web server 将待计算内容发送给加速集群后，依旧可以继续处置其他请求，整个过程是异步非阻塞的。
本文名字HTTPS 计算性能优化
