TLS False Start到底是如何加速網站的

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

也歡迎你們關注野狗，和咱們多多交流。