作者：王继波 野狗科技运维总监，曾在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

也欢迎大家关注野狗，和我们多多交流。