作者：王繼波
野狗科技運維總監，曾在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

也歡迎大家關注野狗，和我們多多交流。