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% 的網路開銷。

1. 延遲和連接管理

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

• 帶寬：用來衡量在單位時間內有多少數據可發送
• 延遲：描述一個消息從一端發送到另一端接收所需的時間

其中，帶寬是次要因素，因為通常你可以隨時購買更多帶寬；而延遲則是無法避免的，因為它是在數據通過網路連接傳輸時被強加的限制。

延遲對 TLS 影響特別大，因為它有自己精心設計的握手，在連接初始化的時候額外增加了兩個往返。

1.1 TCP優化

每個 TCP 連接都有一個稱為 擁塞視窗 的速度極限，這個視窗最初時較小，在可靠性能保證的情況下隨時間增長。這種機制被稱為 慢啟動。

因此，對於所有的 TCP 連接，啟動速度很慢，對於 TLS 連接情況則更糟糕，因為 TLS 握手協議消耗了寶貴的初始連接位元組（當擁塞視窗較小時）。如果擁塞視窗足夠大，那麼慢啟動不會有額外的延遲。但是，如果較長的握手協議超過了擁塞視窗的大小，發送方必須將它拆分為兩塊，先發送一塊，等待確認（一個往返），增加擁塞視窗，然後再發送剩下的部分。

1.1.1 擁塞視窗調優

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

在舊版本的Linux平臺上，可以改變路由的初始擁塞視窗：

# ip route | while read p; do ip route change $p initcwnd 10; done

1.1.2 防止空閑時慢啟動

慢啟動可以作用於一段時間內沒有任何流量的連接上，降低其速度，並且速度下降地非常快。 在 Linux 上，可以在連接空閑時禁用慢啟動：

# sysctl -w net.ipv4.tcp_slow_start_after_idle=0

可以通過將該設置添加到 /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 握手後，用戶與伺服器就建立了有效連接。

2. 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 證書會更小。

• 避免同一張證書綁定過多功能變數名稱