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

• 避免同一張證書繫結過多域名