通常情况下，应用层数据必须等完全握手全部结束之后才能传输。这个其实比较浪费时间，那能不能类似 TFO 一样，在完全握手的第二个阶段将应用数据一起发出来呢？google 提出了 false start 来实现这个功能。详细介绍参考https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00。

　　简单概括 False start 的原理就是在 client_key_exchange 发出时将应用层数据一起发出来，能够节省一个 RTT。

　　False start 依赖于 PFS（perfect forward secrecy 完美前向加密），而 PFS 又依赖于 DHE 密钥交换系列算法（DHE_RSA, ECDHE_RSA, DHE_DSS, ECDHE_ECDSA），所以尽量优先支持 ECDHE 密钥交换算法实现 false start。

　　2.6 使用 SPDY 或者 HTTP2

　　SPDY 是 google 推出的优化 HTTP 传输效率的协议（https://www.chromium.org/spdy），它基本上沿用了 HTTP 协议的语义, 但是通过使用帧控制实现了多个特性，显著提升了 HTTP 协议的传输效率。

　　SPDY 最大的特性就是多路复用，能将多个 HTTP 请求在同一个连接上一起发出去，不像目前的 HTTP 协议一样，只能串行地逐个发送请求。Pipeline 虽然支持多个请求一起发送，但是接收时依然得按照顺序接收，本质上无法解决并发的问题。

　　HTTP2 是 IETF 2015 年 2 月份通过的 HTTP 下一代协议，它以 SPDY 为原型，经过两年多的讨论和完善最终确定。

　　本文就不过多介绍 SPDY 和 HTTP2 的收益，需要说明两点：

　　1， SPDY 和 HTTP2 目前的实现默认使用 HTTPS 协议。

　　2， SPDY 和 HTTP2 都支持现有的 HTTP 语义和 API，对 WEB 应用几乎是透明的。

　　Google 宣布 chrome 浏览器 2016 年将放弃 SPDY 协议，全面支持 HTTP2，但是目前国内部分浏览器厂商进度非常慢，不仅不支持 HTTP2，连 SPDY 都没有支持过。

　　百度服务端和百度手机浏览器现在都已经支持 SPDY3.1 协议。

　　3 HTTPS 计算性能优化

　　3.1 优先使用 ECC

　　ECC 椭圆加密算术相比普通的离散对数计算速度性能要强很多。下表是 NIST 推荐的密钥长度对照表。

　　表格 2 NIST 推荐使用的密钥长度

　　对于 RSA 算法来讲，目前至少使用 2048 位以上的密钥长度才能保证安全性。ECC 只需要使用 224 位长度的密钥就能实现 RSA2048 位长度的安全强度。在进行相同的模指数运算时速度显然要快很多。

　　3.2 使用最新版的 openssl

　　一般来讲，新版的 openssl 相比老版的计算速度和安全性都会有提升。比如 openssl1.0.2 采用了 intel 最新的优化成果，椭圆曲线 p256 的计算性能提升了 4 倍。(https://eprint.iacr.org/2013/816.pdf)

　　Openssl 2014 年就升级了 5 次，基本都是为了修复实现上的 BUG 或者算法上的漏洞而升级的。所以尽量使用最新版本，避免安全上的风险。

　　3.3 硬件加速方案

　　现在比较常用的 TLS 硬件加速方案主要有两种：

　　1， SSL 专用加速卡。

　　2， GPU SSL 加速。

　　上述两个方案的主流用法都是将硬件插入到服务器的 PCI 插槽中，由硬件完成最消耗性能的计算。但这样的方案有如下缺点：

　　1， 支持算法有限。比如不支持 ECC，不支持 GCM 等。

　　2， 升级成本高。

　　a) 出现新的加密算法或者协议时，硬件加速方案无法及时升级。

　　b) 出现比较大的安全漏洞时，部分硬件方案在无法在短期内升级解决。比如 2014 年暴露的 heartbleed 漏洞。

　　3， 无法充分利用硬件加速性能。硬件加速程序一般都运行在内核态，计算结果传递到应用层需要 IO 和内存拷贝开销，即使硬件计算性能非常好，上层的同步等待和 IO 开销也会导致整体性能达不到预期，无法充分利用硬件加速卡的计算能力。

　　4， 维护性差。硬件驱动及应用层 API 大部分是由安全厂家提供，出现问题后还需要厂家跟进。用户无法掌握核心代码，比较被动。不像开源的 openssl，不管算法还是协议，用户都能掌握。

　　3.4 TLS 远程代理计算

　　也正是因为上述原因，百度实现了专用的 SSL 硬件加速集群。基本思路是：

　　1， 优化 TLS 协议栈，剥离最消耗 CPU 资源的计算，主要有如下部分：

　　a) RSA 中的加解密计算。

　　b) ECC 算法中的公私钥生成。

　　c) ECC 算法中的共享密钥生成。

　　2， 优化硬件计算部分。硬件计算不涉及协议及状态交互，只需要处理大数运算。