據說，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.com TCP handshake: 0.022, SSL handshake: 0.064

上面命令中的w參數表示指定輸出格式，time_connect變量表示TCP握手的耗時，time_appconnect變量表示SSL握手的耗時（更多變量請查看文檔和實例），s參數和o參數用來關閉標準輸出。

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

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

?

OpenSSL詳解（使用及解釋）:http://www.ibm.com/developerworks/cn/linux/l-openssl.html

轉載于:https://www.cnblogs.com/wfwenchao/p/5498008.html

總結

以上是生活随笔為你收集整理的SSL延迟有多大 (Https)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。