鏈接：https://zhuanlan.zhihu.com/p/25558110
來源：知乎
著作權歸作者所有，轉載請聯繫作者獲得授權。
如何簡單地判斷從 HTTP 切換到 HTTPS 的成本呢? 主要看下面幾點:
- 機器對 RSA 的私鑰解密 (或簽名) 的計算能力
- 是長連接還是短連接
- 機器對 AES 的計算能力
- 面向的客戶端是否支持 SSL 的 session reuse
HTTPS 的連接的建立
簡單的說, TCP 握手後, SSL 握手使用 `非對稱加密` 的方式讓雙方都獲得一個 `對稱加密` 的密碼, 之後的數據傳輸使用的是 `對稱加密`. 請注意非對稱加密的部分比起對稱加密, 對 CPU 的計算要求高很多. TLS/SSL 的證書有很多這, 加密方法也有很多, 下文只討論 RSA 2048 的證書, 使用 AES 256 CBC 的加密進行傳輸.
RSA 的解密速度
一個安全 RSA 的證書, 現在一般要有 2048 bit 的長度. 對於 RSA 的算法, 如果我們是使用 OpenSSL 這個庫 (nginx 和 haproxy 都是), 可以使用:
openssl speed rsa2048
這個命令去檢查所在物理機的解密速度, 比如下面就是我電腦上的 output:
sign verify sign/s verify/s
rsa 2048 bits 0.003110s 0.000079s 321.5 12699.7
對於服務端, 最重要的就是看 `sign/s` 對應的數值, 這邊是 `321.5`, 這個數值說明, 在單核上面每秒鐘只能用私鑰解密 321 次, 這其實就決定了我的這個CPU, 單核的話, 每秒的 HTTPS 連接創建只能達到 321 個 (還要考慮 http server的其他消耗, 所以會更小).
另外, 我們還可以看看 OpenSSL 對 AES 對稱加密的能力:
openssl speed aes-256-cbc
結果是這樣的:
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-256 cbc 95595.93k 104182.68k 105314.10k 103842.47k 104320.15k
可見, AES 的加解密速度非常快 (這邊的結果是每秒的加解密流量).
長連接還是短連接
長連接以前只是爲了減少 tcp 三次握手的開銷, 有了 HTTPS 之後, 還能減少 TLS/SSL 的握手開銷, 相當於是減少了非對稱加密的部分.
SSL session
SSL session 簡單的說就是客戶端可以保存之前已經商量好的對稱加密祕鑰, 下次如果雙方都統一使用的話, 就可以跳過非對稱加密握手的部分, 直接進行 AES 對稱加密的內容. 這個 session 的重用要比上面的長連接更有效果, 因爲它是和連接無關的.
HTTPS offload gateway 的選擇
選擇 haproxy 還是 nginx 去做 https 的 offload, 主要有下面這幾個考慮:
- 是否支持 session cache (tls 還有 ticket 的方式我們沒講到)
- 是否支持 SNI, 如果你的公網 IP 資源有限, 又有多個域名需要考慮
- 更好的監控
前面兩點, 兩個代理都能做, 但是第三點, nginx沒有任何能讓你採集當前 ssl 的握手速度, session reuse的比例等等的指標; haproxy 有類似的指標可以使用, 是非常有用的功能. 至於代理能力兩者是完全一樣的. 唯一的一個缺憾是 haproxy 的多進程模型不是 master/slave 的方式, 所以在使用 TCP reuseport 的時候, 會有小概率事件導致 reload 進程的時候會產生 TCP RST.