SSL延遲計算：為什麼HTTPs比HTTP要慢？

據說，Netscape公司當年設計SSL協議的時候，有人提過，將網際網路所有連結都變成HTTPs開頭的加密連結。

這個建議沒有得到採納，原因之一是HTTPs連結比不加密的HTTP連結慢很多。（另一個原因好像是，HTTPs連結預設不能快取。）

自從我知道這個掌故以後，腦袋中就有一個觀念：HTTPs連結很慢。但是，它到底有多慢，我並沒有一個精確的概念。直到今天我從一篇文章中，學到了測量HTTPs連結耗時的方法。

首先我解釋一下，為什麼HTTPs連結比較慢。

HTTPs連結和HTTP連結都建立在TCP協議之上。HTTP連結比較單純，使用三個握手資料包建立連線之後，就可以傳送內容資料了。

上圖中，客戶端首先傳送SYN資料包，然後伺服器傳送SYN+ACK資料包，最後客戶端傳送ACK資料包，接下來就可以傳送內容了。這三個資料包的傳送過程，叫做TCP握手。

再來看HTTPs連結，它也採用TCP協議傳送資料，所以它也需要上面的這三步握手過程。而且，在這三步結束以後，它還有一個SSL握手。

總結一下，就是下面這兩個式子。

HTTP耗時 = TCP握手

HTTPs耗時 = TCP握手 + SSL握手

所以，HTTPs肯定比HTTP耗時，這就叫SSL延遲。

命令列工具curl有一個w引數，可以用來測量TCP握手和SSL握手的具體耗時，以訪問支付寶為例。

$ curl -w "TCP handshake: %{time_connect}， SSL handshake: %{time_appconnect}\n" -so /dev/null https://www.alipay.comTCP handshake: 0.022, SSL handshake: 0.064

上面命令中的w參數列示指定輸出格式，timeconnect變數表示TCP握手的耗時，timeappconnect變數表示SSL握手的耗時（更多變數請檢視文件和例項），s引數和o引數用來關閉標準輸出。

從執行結果可以看到，SSL握手的耗時（64毫秒）大概是TCP握手（22毫秒）的三倍。也就是說，在建立連線的階段，HTTPs連結比HTTP連結要長3倍的時間，具體數字取決於CPU的快慢。

所以，如果是對安全性要求不高的場合，為了提高網頁效能，建議不要採用保密強度很高的數字證書。一般場合下，1024位的證書已經足夠了，2048位和4096位的證書將進一步延長SSL握手的耗時。