作者：王继波
野狗科技运维总监，曾在360、TP-Link从事网络运维相关工作，在网站性能优化、网络协议研究上经验丰富。
野狗官博：https://blog.wilddog.com/
野狗官网：https://www.wilddog.com/
公众订阅号：wilddogbaas
我们是一群认真执着的小野狗，任何体验和性能的提升，我们都非常关注。今天我们来介绍HTTPS网站加速中的一个重要功能-TLS False Start，这当然已经在野狗所有网站上实现。
先来说说优化HTTPS网站三个基本出发点：
使用更少的网络通信往返；
更少更快的加解密计算；
更小的网络延迟。
而TLS False Start功能对HTTPS网站的加速正是通过减少通信RT（Round Trip）实现的。
TLS False Start是什么？
首先我们来看看HTTP和HTTPS通信对比。
在最不理想状况下，一个正常HTTP到达TTFB（Time To First Byte）需要经过以下过程：1个DNS查询RT、1个TCP握手RT，至少一个HTTP请求和响应RT。我们假设浏览器和服务器之间的RTT为50ms（50ms也是中国网络从南到北延迟值），这里我们暂且不考虑DNS，所以在这个假设下，HTTP到达TTFB需要100ms。
我们再来看看HTTPS过程，相比于HTTP，HTTPS多出两个RTT用来协商TLS隧道（这里忽略加解密计算和OCSP等时间因素），同样不考虑DNS，在这个假设下，HTTPS到达TTTFB需要200ms。
可以看到，HTTPS通信时间是HTTP的整整两倍，这也是认为HTTPS慢的重要原因之一。
HTTPS通信过程
试想，如果能够减少HTTPS通信过程的RT，将时间从200ms提高到150ms，那直接减少了1/4的时间消耗，这对于高并发高负载的服务器性能提升和带宽节省是显而易见的。
这当然是有办法的，这就是今天要介绍的TLS False Start的作用。
TLS False Start是Google提出来的优化方法，其做法是：在TLS协商第二阶段，浏览器发送ChangeCipherSpec和Finished后，立即发送加密的应用层数据，而无需等待服务器端的确认。
下图是启用TLS False Start之后的HTTPS通信过程。
HTTPS通信过程启用TLS False Start
下面理论结合实际，通过抓包的方法来分析。分别对未启用TLS False Start的京东登录页面和启用TLS False Start的野狗WildDog首页(https://www.wilddog.com)抓包。
先来看下未启用TLS False Start的京东登录页面通信过程。
在上图框出两处可以看到，浏览器端在发送ChangeCipherSpec和Finished后，处于等待状态，直到服务器的确认包到达，才进行加密的应用数据传输。
再来看下enable TLS False Start的野狗WildDog首页通信过程。
在上图框出两处可以看到，浏览器在发送ChangeCipherSpec和Finished后，并没有等待服务器端的确认就立即发送了加密应用数据。这样就省去了一个RT。
如何启用TLS False Start？
开启TLS False Start需要浏览器端和服务器端同时满足条件。
Chrome和Firefox需要支持NPN/ALPN，并且服务器端配置支持前向安全（Forward Secrecy）；
Safari从OSX 10.9开始支持，并需要服务器端开启前向安全配合；
IE使用黑名单和超时机制实现。
Chrome和Firefox的最新版本都是默认支持NPN/ALPN的，这也可以通过抓包看到的，在数据包的扩展字段中。
那如何在服务器端开启Forward Secrecy？
不同的WEB服务器有不同的方法，这里以Nginx为例说明，开启方法其实不麻烦。
ssl_prefer_server_ciphers on;
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256…..（加密套件的选择具有很大灵活度，不列举详细列表）
详细的TLS False Start说明可以参见IETF的文档。
https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00
也欢迎大家关注野狗，和我们多多交流。