HTTPS之TLS性能調優

HTTPS之TLS性能調優

HTTPS（HTTP over SSL）是以安全爲目標的 HTTP 通道，能夠理解爲 HTTP + SSL/TLS，即在 HTTP 下加入 SSL/TLS 層做爲安全基礎。其中 TLS 的前身是 SSL，目前普遍使用的是 TLS 1.2。

TLS性能調優

TLS 被廣泛認爲會使服務變慢，主要是早期 CPU 還很慢，只有少數站點買得起加密服務。可是今天計算能力再也不是 TLS 的瓶頸。2010年，Google 默認狀況下對其電子郵件服務上啓用了加密，以後他們表示 SSL/TLS 再也不花費昂貴的計算成本：

在咱們的前端服務上，SSL/TLS 計算只佔 CPU 負載的不到 1%，每一個鏈接只佔不到 10KB 的內存，以及不到 2% 的網絡開銷。

一、延遲和鏈接管理

網絡通信的速度由兩個主要因素決定：帶寬和延遲。

帶寬：用來衡量在單位時間內有多少數據可發送
延遲：描述一個消息從一端發送到另外一端接收所需的時間
其中，帶寬是次要因素，由於一般你能夠隨時購買更多帶寬；而延遲則是沒法避免的，由於它是在數據經過網絡鏈接傳輸時被強加的限制。

延遲對 TLS 影響特別大，由於它有本身精心設計的握手，在鏈接初始化的時候額外增長了兩個往返。

1.1 TCP優化

每一個 TCP 鏈接都有一個稱爲 擁塞窗口 的速度極限，這個窗口最初時較小，在可靠性能保證的狀況下隨時間增加。這種機制被稱爲 慢啓動。

所以，對於全部的 TCP 鏈接，啓動速度很慢，對於 TLS 鏈接狀況則更糟糕，由於 TLS 握手協議消耗了寶貴的初始鏈接字節（當擁塞窗口較小時）。若是擁塞窗口足夠大，那麼慢啓動不會有額外的延遲。可是，若是較長的握手協議超過了擁塞窗口的大小，發送方必須將它拆分爲兩塊，先發送一塊，等待確認（一個往返），增長擁塞窗口，而後再發送剩下的部分。

1.1.1 擁塞窗口調優

啓動速度限制被稱爲 初始擁塞窗口。RFC6928 建議初始擁塞窗口設置爲10個網絡段（約15KB）。早期的建議是使用2-4個網絡段起步。

在舊版本的Linux平臺上，能夠改變路由的初始擁塞窗口：

1.1.2 防止空閒時慢啓動

在 Linux 上，能夠在鏈接空閒時禁用慢啓動：

能夠經過將該設置添加到 /etc/sysctl.conf 配置使其永久生效。

1.2 長鏈接

大部分狀況下 TLS 性能影響集中在每個鏈接的開始握手階段。一個重要的優化技術是在鏈接數容許的狀況下儘量保持每一個鏈接不斷開。

如今的趨勢是使用事件驅動的 WEB 服務器，經過使用固定的線程池（甚至單個線程）處理全部通信，從而減小每一個鏈接的成本以及被攻擊的可能性。

長鏈接的缺點是在最後一個 HTTP 鏈接完成以後，服務器在關閉鏈接以前會等待必定時間，雖然一個鏈接不會消耗太多的資源，可是下降了服務器的整體伸縮性。長鏈接適用於客戶端突發大量請求的場景。

當配置較大的長鏈接超時時間時，限制併發鏈接數以避免服務器超負荷是相當重要的。經過測試調整服務器，使其運行在容量限制內。若是 TLS 是由OpenSSL 處理的，請確保服務器正確設置 SSL_MODE_RELEASE_BUFFERS 標識。

1.3 HTTP/2.0

HTTP/2.0 是 二進制協議，具有 多路複用 和 頭部壓縮 等特性，能夠提高性能。

1.4 CDN

使用 CDN 能夠實現世界級的性能，它利用地理上分散的服務器提供邊緣緩存和流量優化。

當用戶離你的服務器越遠，訪問網絡就越慢，在這種狀況下鏈接創建是一個很大的限制因素。爲了服務器儘量靠近最終用戶，CDN 經營着大量的地理分佈的服務器，它能夠提供兩種下降延遲的方式，即邊緣緩存和鏈接管理。

1.4.1 邊緣緩存

因爲 CDN 服務器貼近用戶，能夠將你的文件提供給用戶，就像你的服務器真的在那裏同樣。

1.4.2 鏈接管理

若是你的內容是動態的、用戶特定的，那麼久沒法經過 CDN 緩存數據。可是，一個不錯的 CDN 即便沒有任何緩存，也能經過鏈接管理提供幫助，那就是它能夠經過長時間保持的長鏈接消除大部分創建鏈接的成本。

創建鏈接期間大部分的時間都花在等待上面。爲了儘可能較少等待，CDN 經過本身的基礎設置將流量路由到距離目的地最近的一個點。由於是 CDN 本身徹底可控的服務器，它能夠內部保持長鏈接很長一段時間。

當使用 CDN 時，用戶鏈接到最近的 CDN 節點，這隻有很短的距離，TLS 握手的網絡延遲也很短；而 CDN 與服務器之間能夠直接複用已有的遠距離長鏈接。這意味着與 CDN 快速初始 TLS 握手後，用戶與服務器就創建了有效鏈接。

1. TLS協議優化

---

在鏈接管理以後咱們能夠專一於 TLS 的性能特徵，具有對 TLS 協議進行安全和速度調優的知識。

2.1 密鑰交換

使用 TLS 最大的成本除了延遲之外，就是用於安全參數協商的 CPU 密集型加密操做。這部分通信稱爲密鑰交換（key exchange）。密鑰交換的 CPU 消耗很大程度上取決於服務器選擇的私鑰算法、私鑰長度和密鑰交換算法。

• 密鑰長度

破解密鑰的難度取決於密鑰的長度，密鑰越長越安全。但較長的密鑰同時也意味着須要花費更多時間進行加密和解密。

• 密鑰算法

目前有兩種密鑰算法可用：RSA 和 ECDSA。當前 RSA密鑰算法推薦最小長度2048位（112位加密強度），未來更多會部署3072位（128位加密強度）。ECDSA在性能和安全性上要優於 RSA，256位的 ECDSA （128位加密強度）提供和 3072位的 RSA 同樣的安全性，卻有更好地性能。

• 密鑰交換

目前有兩種可用的密鑰交換算法：DHE 和 ECDHE。其中 DHE 太慢不推薦使用。 密鑰交換算法的性能取決於配置的協商參數長度。對於 DHE，經常使用的1024和2048位，分別提供80和112位安全等級。對於 ECDHE，安全和性能取決於一種稱爲 曲線 的東西。secp256r1提供128位安全等級。

你在實踐中不能隨意組合密鑰鑰和密鑰交換算法，但可使用由協議指定的組合。

2.2 證書

一次完整的 TLS 握手期間，服務器會把它的證書鏈發送給客戶端驗證。證書鏈的長度和正確性對握手的性能有很大影響。

• 使用盡量少的證書

證書鏈裏的每一個證書都會增大握手數據包，證書鏈中包含太多證書有可能致使 TCP 初始擁塞窗口溢出。

• 只包含必需的證書

證書鏈裏包含非必需證書是個常見錯誤，每一個這樣的證書會給握手協議額外增長1-2KB。

• 提供完整的證書鏈

服務器必須提供一個被根證書信任的完整證書鏈。

• 使用橢圓曲線證書鏈

由於 ECDSA 私鑰長度使用更少的位，因此 ECDSA 證書會更小。

• 避免同一張證書綁定過多域名

每增長一個域名都會增長證書的大小，對於大量域名來講會有明顯的影響。

2.3 吊銷檢查

雖然證書吊銷狀態在不斷變化，而且用戶代理對證書吊銷的行爲差別很大，可是做爲服務器，要作的就是儘量快地傳遞吊銷信息。

• 使用 OCSP

OCSP 被設計用於提供實時查詢，容許用戶代理只請求訪問網站的吊銷信息，查詢簡短而快速（一個HTTP請求）。相比之下 CRL 是一個包含大量被吊銷證書的列表。

• 使用具備快速且可靠的 OCSP 響應程序的 CA

另外一個選擇 CA 的標準是它更新 OCSP 響應程序的速度。

• 部署 OCSP stapling

OCSP stapling 是一種容許在 TLS 握手中包含吊銷信息（整個OCSP響應）的協議功能。啓用以後，經過給予用戶代理進行吊銷檢查的所有信息以帶來更好地性能，能夠省去用戶代理經過獨立的鏈接獲取 CA 的 OCSP 響應程序來查詢吊銷信息。

2.4 協議兼容

若是你的服務器與一些新版本協議的特性（例如TLS 1.2）不兼容，瀏覽器可能須要經過與服務器進行屢次嘗試，才能協商一個加密的鏈接。確保良好的 TLS 性能的最好方式是升級最新的 TLS 協議棧以支持較新的協議版本和擴展。

2.5 硬件加速

隨着 CPU 速度的不斷提升，基於軟件的 TLS 實如今普通 CPU 上已經運行得足夠快，無需專門的加密硬件就能處理大量的 HTTPS 請求。但安裝加速卡或許可以提高速度。

在此我向你們推薦一個架構學習交流羣。交流學習羣號：478030634 裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化、分佈式架構等這些成爲架構師必備的知識體系。還能領取免費的學習資源，目前受益良多

注：關注做者微信公衆號，瞭解更多分佈式架構、微服務、netty、MySQL、spring、性能優化、等知識點。公衆號：《Java爛豬皮》