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 證書會更小。
- 避免同一張證書綁定過多域名
每增加一個域名都會增加證書的大小，對於大量域名來說會有明顯的影響。
2.3 吊銷檢查
雖然證書吊銷狀態在不斷變化，並且用戶代理對證書吊銷的行為差異很大，但是作為服務器，要做的就是盡可能快地傳遞吊銷信息。
- 使用 OCSP
信息的證書 OCSP 被設計用於提供實時查詢，允許用戶代理只請求訪問網站的吊銷信息，查詢簡短而快速（一個HTTP請求）。相比之下 CRL 是一個包含大量被吊銷證書的列表。
- 使用具有快速且可靠的 OCSP 響應程序的 CA
不同 CA 之間的 OCSP 響應程序性能不同，在你向 CA 提交之前先檢查他們的歷史 OCSP 響應程序。 另一個選擇 CA 的標准是它更新 OCSP 響應程序的速度。
- 部署 OCSP stapling
OCSP stapling 是一種允許在 TLS 握手中包含吊銷信息（整個OCSP響應）的協議功能。啟用之后，通過給予用戶代理進行吊銷檢查的全部信息以帶來更好地性能，可以省去用戶代理通過獨立的連接獲取 CA 的 OCSP 響應程序來查詢吊銷信息。
2.4 協議兼容
如果你的服務器與一些新版本協議的特性（例如TLS 1.2）不兼容，瀏覽器可能需要通過與服務器進行多次嘗試，才能協商一個加密的連接。確保良好的 TLS 性能的最好方式是升級最新的 TLS 協議棧以支持較新的協議版本和擴展。
2.5 硬件加速
隨着 CPU 速度的不斷提高，基於軟件的 TLS 實現在普通 CPU 上已經運行得足夠快，無需專門的加密硬件就能處理大量的 HTTPS 請求。但安裝加速卡或許能夠提升速度。
參考文章
《HTTPS權威指南：在服務器和Web應用上部署SSL/TLS和PKI》