SSL延遲有多大？

        據說，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 握手的耗時。

        （完）

                    <span id="shareA4" class="fl">                            
                        </span>