HTTPS 之 TLS 效能調優

https（http over ssl）是以安全為目標的 http 通道，可以理解為 http + ssl/tls，即在 http 下加入 ssl/tls 層作為安全基礎。其中 tls 的前身是 ssl，目前廣泛使用的是 tls 1.2。

tls 被普遍認為會使服務變慢，主要是早期 cpu 還很慢，只有少數站點買得起加密服務。但是今天計算能力不再是 tls 的瓶頸。2023年，google 預設情況下對其電子郵件服務上啟用了加密，之後他們表示 ssl/tls 不再花費昂貴的計算成本：

在我們的前端服務上，ssl/tls 計算只佔 cpu 負載的不到 1%，每個連線只佔不到 10kb 的記憶體，以及不到 2% 的網路開銷。

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

每個 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

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

# sysctl -w net.ipv4.tcp_slow_start_after_idle=0

大部分情況下 tls 效能影響集中在每乙個連線的開始握手階段。乙個重要的優化技術是在連線數允許的情況下盡可能保持每個連線不斷開。

現在的趨勢是使用事件驅動的 web 伺服器，通過使用固定的執行緒池（甚至單個執行緒）處理所有通訊，從而減少每個連線的成本以及被攻擊的可能性。

長連線的缺點是在最後乙個 http 連線完成之後，伺服器在關閉連線之前會等待一定時間，雖然乙個連線不會消耗太多的資源，但是降低了伺服器的總體伸縮性。長連線適用於客戶端突發大量請求的場景。

當配置較大的長連線超時時間時，限制併發連線數以免伺服器超負荷是至關重要的。通過測試調整伺服器，使其執行在容量限制內。如果 tls 是由 openssl 處理的，請確保伺服器正確設定 ssl_mode_release_buffers 標識。

使用 cdn 可以實現世界級的效能，它利用地理上分散的伺服器提供邊緣快取和流量優化。

當使用者離你的伺服器越遠，訪問網路就越慢，在這種情況下連線建立是乙個很大的限制因素。為了伺服器盡可能靠近終端使用者，cdn 經營著大量的地理分布的伺服器，它可以提供兩種降低延遲的方式，即邊緣快取和連線管理。

1.4.1 邊緣快取

由於 cdn 伺服器貼近使用者，可以將你的檔案提供給使用者，就像你的伺服器真的在那裡一樣。

1.4.2 連線管理

建立連線期間大部分的時間都花在等待上面。為了盡量較少等待，cdn 通過自己的基礎設定將流量路由到距離目的地最近的乙個點。因為是 cdn 自己完全可控的伺服器，它可以內部保持長連線很長一段時間。

當使用 cdn 時，使用者連線到最近的 cdn 節點，這只有很短的距離，tls 握手的網路延遲也很短；而 cdn 與伺服器之間可以直接復用已有的遠距離長連線。這意味著與 cdn 快速初始 tls 握手後，使用者與伺服器就建立了有效連線。

在連線管理之後我們可以專注於 tls 的效能特徵，具備對 tls 協議進行安全和速度調優的知識。

使用 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位安全等級。

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

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

證書鏈裡的每個證書都會增大握手資料報，證書鏈中包含太多證書有可能導致 tcp 初始擁塞視窗溢位。

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

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

因為 ecdsa 私鑰長度使用更少的位，所以 ecdsa 證書會更小。

每增加乙個網域名稱都會增加證書的大小，對於大量網域名稱來說會有明顯的影響。

雖然證書吊銷狀態在不斷變化，並且使用者**對證書吊銷的行為差異很大，但是作為伺服器，要做的就是盡可能快地傳遞吊銷資訊。

資訊的證書ocsp 被設計用於提供實時查詢，允許使用者**只請求訪問**的吊銷資訊，查詢簡短而快速（乙個http請求）。相比之下 crl 是乙個包含大量被吊銷證書的列表。

不同 ca 之間的 ocsp 響應程式效能不同，在你向 ca 提交之前先檢查他們的歷史 ocsp 響應程式。另乙個選擇 ca 的標準是它更新 ocsp 響應程式的速度。

ocsp stapling 是一種允許在 tls 握手中包含吊銷資訊（整個ocsp響應）的協議功能。啟用之後，通過給予使用者**進行吊銷檢查的全部資訊以帶來更好地效能，可以省去使用者**通過獨立的連線獲取 ca 的 ocsp 響應程式來查詢吊銷資訊。

如果你的伺服器與一些新版本協議的特性（例如tls 1.2）不相容，瀏覽器可能需要通過與伺服器進行多次嘗試，才能協商乙個加密的連線。確保良好的 tls 效能的最好方式是公升級最新的 tls 協議棧以支援較新的協議版本和擴充套件。

隨著 cpu 速度的不斷提高，基於軟體的 tls 實現在普通 cpu 上已經執行得足夠快，無需專門的加密硬體就能處理大量的 https 請求。但安裝加速卡或許能夠提公升速度。

《https權威指南：在伺服器和web應用上部署ssl/tls和pki》

Spark效能調優之Shuffle調優總結

spark底層shuffle的傳輸方式是使用netty傳輸，netty在進行網路傳輸的過程會申請堆外記憶體 netty是零拷貝 所以使用了堆外記憶體。shuffle過程中常出現的問題 常見問題一 reduce oom?問題原因 reduce task 去map端獲取資料，reduce一邊拉取資料一邊...

Spark效能調優 之 運算元調優（二）

map 表示每乙個元素 rrd.foreache 表示每乙個元素 rrd.forpartitions 表示每個分割槽的資料組成的迭代器 在生產環境中，通常使用foreachpartition運算元來完成資料庫的寫入，通過foreachpartition運算元的特性，可以優化寫資料庫的效能。如果使用f...

調優 Nginx效能調優

一.nginx優化配置 1.主配置檔案優化 注 部分配置詳解 worker processes 8 nginx程序數，建議按照cpu數目來指定，一般為它的倍數。worker cpu affinity 00000001 00000010 00000100 00001000 00010000 00100...