SSL/TLS深度解析--TLS性能優(yōu)化

TCP 優(yōu)化

Linux系統(tǒng)內(nèi)核參數(shù)優(yōu)化

[root@www ~]# cat /etc/redhat-release;uname -r
CentOS Linux release 7.5.1804 (Core) 
3.10.0-862.11.6.el7.x86_64

TLS 的下一層是 TCP 協(xié)議，所以對(duì) TCP 的優(yōu)化是可以直接影響到 TLS 的性能效率。

在對(duì) TCP 的優(yōu)化中，主要涉及以下幾個(gè)概念：

（1）擁塞控制（congestion control）機(jī)制：在一個(gè) TCP 連接開(kāi)始時(shí)，不知道對(duì)方的速度有多快。如果有足夠大的帶寬，服務(wù)器端可以用最快的速度傳送數(shù)據(jù)，但是如果對(duì)方的網(wǎng)絡(luò)很慢，服務(wù)器發(fā)送的數(shù)據(jù)太多的話(huà)，會(huì)壓跨連接，導(dǎo)致連接中斷。所以，每個(gè) TCP 連接都有一個(gè)稱(chēng)為擁塞窗口（cwnd = congestion window）的速度極限。這個(gè)窗口最初較小，在通信的過(guò)程中，如果雙方都能接受這個(gè)速度，那么會(huì)加大這個(gè)擁塞窗口的值（初期增長(zhǎng)很快，翻倍增長(zhǎng)），這種機(jī)制被叫做慢啟動(dòng)（slow start）。

擁塞控制機(jī)制對(duì)于 TLS 連接的影響比較大，TLS 握手消耗了寶貴的初始連接字節(jié)（當(dāng)擁塞窗口較小時(shí)）；如果擁塞窗口足夠大，那么慢啟動(dòng)不會(huì)有額外的延遲。但是，如果握手消息長(zhǎng)度超過(guò)了擁塞窗口大小，發(fā)送方將必須把這個(gè)長(zhǎng)信息拆分成兩塊，先發(fā)送一塊，等待確認(rèn)（1個(gè)往返），增加擁塞窗口，然后再發(fā)送剩下的部分。這樣就增加了由 TLS 握手造成的延時(shí)。

(2) 慢啟動(dòng)閾值 ssthresh（避免 cwnd 增長(zhǎng)過(guò)快，網(wǎng)絡(luò)無(wú)法承擔(dān)，造成丟包）

如果 cwnd 小于 ssthresh，表示在慢啟動(dòng)階段，cwnd是翻倍增長(zhǎng)的；如果 cwnd 大于 ssthresh，那么表示在擁塞避免階段，這時(shí)候 cwnd 不再像慢啟動(dòng)階段那樣翻倍增長(zhǎng)，而是線(xiàn)性增長(zhǎng)，盡量避免網(wǎng)絡(luò)擁塞。

(3) 接收窗口（rwnd），用來(lái)表示最多能保存多少數(shù)據(jù)，實(shí)際中接收窗口rwnd的合理值取決于BDP的大小，也就是帶寬和延遲的乘積。如果帶寬是 80Mbps，延遲是 100ms，那么計(jì)算過(guò)程如下：

BDP = 80Mbps 100ms = (80 / 8) (100 / 1000) = 1MB = 1024KB = 1048576B

TCP 用16位來(lái)記錄窗口大小，也就是說(shuō)最大值是64KB，如果超過(guò)這個(gè)值，就需要 tcp_window_scaling 機(jī)制（默認(rèn)是開(kāi)啟）。配置內(nèi)核參數(shù)中接收緩沖的大小，就可以控制接收窗口的大?。?/h5>

net.ipv4.tcp_rmem = <MIN> <DEFAULT> <MAX>

Linux本身有一個(gè)緩沖大小自動(dòng)調(diào)優(yōu)的機(jī)制，窗口的實(shí)際大小會(huì)自動(dòng)在最小值和最大值之間變化，找到性能和資源的平衡點(diǎn)。確認(rèn)緩沖大小自動(dòng)調(diào)優(yōu)機(jī)制（0：關(guān)閉、1：開(kāi)啟）：sysctl -a | grep tcp_moderate_rcvbuf。如果緩沖大小自動(dòng)調(diào)優(yōu)機(jī)制設(shè)置成關(guān)閉狀態(tài)，那么就把緩沖的 DEFAULT 值設(shè)置為 BDP；如果緩沖大小自動(dòng)調(diào)優(yōu)機(jī)制設(shè)置成開(kāi)啟狀態(tài)，那么就把緩沖的 MAX 設(shè)置為 BDP。

(4) 存儲(chǔ) TCP 連接本身一些信息的額外開(kāi)銷(xiāo)：net.ipv4.tcp_adv_win_scale 的值可能是 1 或者 2，如果是 1 的話(huà)，則表示二分之一的緩沖被用來(lái)做額外開(kāi)銷(xiāo)，如果是 2 的話(huà)，則表示四分之一的緩沖被用來(lái)做額外開(kāi)銷(xiāo)。按照這個(gè)邏輯，緩沖最終的合理值的具體計(jì)算方法如下：result=BDP / (1 – 1 / 2^tcp_adv_win_scale)。

(5) 空閑連接回到慢啟動(dòng)：慢啟動(dòng)在一段時(shí)間內(nèi)沒(méi)有任何流量的連接上起作用，達(dá)到降低速度的效果，并且速度下降非?？臁Ｋ^的“一段時(shí)間”可以是非常小的，比如1秒鐘，但在實(shí)際場(chǎng)景中，每一個(gè)長(zhǎng)連接（例如使用 HTTP 長(zhǎng)連接）的速度都有可能被調(diào)到很慢！為了保持速度建議禁用這個(gè)功能。

在 Linux 上，可以在連接空閑時(shí)禁用慢啟動(dòng)： 0表示否,1表示開(kāi)啟慢啟動(dòng)，默認(rèn)是1

可以通過(guò)一下命令使其臨時(shí)生效，但重啟以后就失效了，查看：sysctl -a | gerp slow_start_after_idle

臨時(shí)：sysctl -w net.ipv4.tcp_slow_start_after_idle=0

永久生效：將 net.ipv4.tcp_slow_start_after_idle=0 設(shè)置添加到 /etc/sysctl.conf 配置文件中。

對(duì)擁塞窗口（cwnd）初始值調(diào)優(yōu)：

啟動(dòng)速度限制被稱(chēng)為初始擁塞窗口（initial congestion window， initcwnd ）。2013年4月發(fā)布的 RFC6928，google 建議默認(rèn)情況下初始擁塞窗口設(shè)置為10個(gè) MSS（約15 KB）。【Centos 7默認(rèn)是10MSS】早期的建議是使用2或4個(gè)MSS(約3—6KB)。MSS 是 TCP 層上的概念，大小是 1460 字節(jié)。IP 層上是 MTU，1500字節(jié)。

[root@www ~]# sysctl -a |grep ssthresh
net.ipv4.tcp_max_ssthresh = 0   #在虛擬機(jī)中
[root@www ~]# sysctl -a |grep tcp_window_scaling
net.ipv4.tcp_window_scaling = 1
[root@www ~]# cat /proc/sys/net/ipv4/tcp_rmem    # rwnd值
4096    87380   6291456
[root@www ~]# sysctl -a |grep tcp_moderate_rcvbuf        
net.ipv4.tcp_moderate_rcvbuf = 1
[root@www ~]# sysctl -a |grep adv_win_scale
net.ipv4.tcp_adv_win_scale = 1
[root@www ~]# sysctl -a |grep start_after_idle
net.ipv4.tcp_slow_start_after_idle = 1

# 設(shè)置cwnd
[root@www ~]# ip route
default via 172.16.216.2 dev ens33 
169.254.0.0/16 dev ens33 scope link metric 1002 
172.16.216.0/24 dev ens33 proto kernel scope link src 172.16.216.188 
[root@www ~]# ip route | while read p; do ip route change $p initcwnd 10; done
[root@www ~]# ip route
default via 172.16.216.2 dev ens33 initcwnd 10 
169.254.0.0/16 dev ens33 scope link metric 1002 initcwnd 10 
172.16.216.0/24 dev ens33 proto kernel scope link src 172.16.216.188 initcwnd 10
# initcwnd 10:初始化cwnd
# 單方面提升發(fā)送端 cwnd 的大小并不一定有效，因?yàn)榫W(wǎng)絡(luò)中實(shí)際傳輸?shù)奈唇?jīng)確認(rèn)的數(shù)據(jù)大小取決于  rwnd 和 cwnd 中的最小值，所以一旦接收方的 rwnd 比較小的話(huà)，會(huì)抑制 cwnd 的發(fā)揮。

# 設(shè)置initrwnd（linux kernel 2.6.33 and newer）
[root@www ~]# ip route
default via 172.16.216.2 dev ens33 
169.254.0.0/16 dev ens33 scope link metric 1002 
172.16.216.0/24 dev ens33 proto kernel scope link src 172.16.216.188 
[root@www ~]# ip route | while read p; do ip route change $p initrwnd 10; done 
[root@www ~]# ip route
default via 172.16.216.2 dev ens33 initrwnd 10 
169.254.0.0/16 dev ens33 scope link metric 1002 initrwnd 10 
172.16.216.0/24 dev ens33 proto kernel scope link src 172.16.216.188 initrwnd 10 

# 一些系統(tǒng)的rwnd值:
# Linux 2.6.32                                      3*MSS (usually 4380)
# Linux 3.0.0                                       10*MSS (usually 14600)
# Windows NT 6.1    (Windows 7 or Server 2008 R2)   8192 ^ 2

• 優(yōu)化 tcp time_wait ，減少time_wait 狀態(tài)的連接。主動(dòng)關(guān)閉的一方會(huì)出現(xiàn)time_wait狀態(tài)。

  time_wait 狀態(tài)的連接要等待2個(gè) MSL 的時(shí)間才會(huì) close，會(huì)占用資源，盡量避免連接進(jìn)入 time_wait 狀態(tài)。linux 里 MSL一般是30秒，2 個(gè)MSL 是1分鐘，這個(gè)數(shù)值是硬編碼在內(nèi)核中的，除非重新編譯內(nèi)核，否則沒(méi)法修改。注：MSL最長(zhǎng)報(bào)文生命周期：Maximum Segment Lifetime，MSL 。

  修改 fin_wait2 的值，減少 fin_wait2 的等待時(shí)間，超時(shí)以后會(huì)回收連接。

  開(kāi)啟長(zhǎng)連接：絕大多是瀏覽器在開(kāi)啟長(zhǎng)連接的情況下，接收到服務(wù)器斷開(kāi)連接的fin以后，會(huì)恢復(fù)一個(gè) ack；而不會(huì)不發(fā)送自己這一端的 fin ，這樣服務(wù)器一端就會(huì)等待 fin_timeout 時(shí)間后，回收連接。

  若不開(kāi)啟長(zhǎng)連接，服務(wù)器端關(guān)閉鏈接以后，鏈接的狀態(tài)會(huì)從 fin_wait2 轉(zhuǎn)換到 time_wait 。

  還可以考慮促使客戶(hù)端關(guān)閉鏈接，配置 keepalive_timeout 20s 10s; （nginx 配置），使客戶(hù)端的超時(shí)小于服務(wù)器端，瀏覽器會(huì)先關(guān)閉鏈接，這樣time_wait 狀態(tài)就會(huì)在客戶(hù)端，不過(guò)通過(guò)實(shí)驗(yàn)看出只有火狐瀏覽器支持，狐火瀏覽器會(huì)識(shí)別 Keep-Alive: timeout=time 這個(gè)參數(shù)，而別的瀏覽器不會(huì)。

  不要設(shè)置回收 recycle=1 和 重用 reuse=1，NAT模式下會(huì)造成連接失敗（ SYN 包不會(huì)被響應(yīng)）

  time_wait 狀態(tài)的連接被重用（reuse）的條件是如下2個(gè)之一：

  1）初始序列號(hào)比time_wait狀態(tài)的老連接最末的序列號(hào)大。

  2）如果使用時(shí)間戳，那么新到來(lái)的連接的時(shí)間戳比老連接的時(shí)間戳大。

  tcp_tw_reuse和tcp_tw_recycle要生效，必須 tcp_timestamps 是開(kāi)啟的，默認(rèn)也是開(kāi)啟的。

• 參數(shù)優(yōu)化

  net.ipv4.tcp_max_syn_backlog = 1024 #SYN隊(duì)列的長(zhǎng)度，默認(rèn)是1024，加大隊(duì)列到8192或更大，可緩存更多等待的網(wǎng)絡(luò)連接。

  net.ipv4.tcp_max_tw_buckets = 180000 #保存 TIME_WAIT 狀態(tài)的套接字的最大數(shù)量，一旦超過(guò)這個(gè)數(shù)，TIME_WAIT套接字將立刻被清除，并發(fā)出警告。

  net.ipv4.ip_local_port_range = 1024 65535 # 向外連接的端口范圍。缺省值：32768到61000，可以擴(kuò)大 1024 到 65535。

  net.ipv4.tcp_syncookies = 1 #開(kāi)啟SYN Cookies，SYN等待隊(duì)列溢出時(shí)，使用cookies來(lái)處理，可防范少量SYN***。

  net.ipv4.tcp_retries2 = 15 #TCP失敗重傳的次數(shù) ，默認(rèn)15 ，可以調(diào)小一些，例如5。

  還可以配置用于 TCP/IP 鏈接所使用的內(nèi)存，配置總內(nèi)存的話(huà)，單位是“頁(yè)” ，具體的一個(gè)頁(yè)的大小可以通過(guò) getconf PAGE_SIZE 這個(gè)命令獲??；讀寫(xiě)所占用的內(nèi)存單位是字節(jié)。

[root@www ~]# getconf PAGE_SIZE
4096

總內(nèi)存

net.ipv4.tcp_mem = 93408 124544 186816

寫(xiě)（緩沖）

net.ipv4.tcp_wmem = 4096 16384 3985408

讀（緩存）

net.ipv4.tcp_rmem = 4096 87380 3985408

[root@www ~]# cd /proc/sys/net/ipv4
[root@www ipv4]# cat tcp_fin_timeout 
60
[root@www ~]# sysctl -a |grep timestamps
net.ipv4.tcp_timestamps = 1

initcwnd

ip-sysctl

TLS 協(xié)議優(yōu)化

• 對(duì)TLS協(xié)議進(jìn)行安全和速度調(diào)優(yōu)

  1.密鑰交換

  使用TLS最大的成本除了延遲以外（多了2次往返），就是用于安全參數(shù)協(xié)商的CPU密集型操作，也就是密鑰交換（key exchange）。密鑰交換的CPU消耗很大程度上取決于服務(wù)器選擇的私鑰算法、密鑰長(zhǎng)度和密鑰交換算法。

  破解密鑰的難度取決于密鑰的長(zhǎng)度，密鑰越長(zhǎng)越安全。但是也要考慮加密與解密所消耗的計(jì)算資源。目前有兩種私鑰算法可以使用：RSA和ECDSA。

  現(xiàn)在RSA算法的密鑰仍然大量存在，即使使用它進(jìn)行密鑰交換的時(shí)候不支持前向加密。但是RSA還是可以用在身份認(rèn)證上，當(dāng)前RSA密鑰算法推薦最小長(zhǎng)度2048位，并且考慮升級(jí)到3072位（雖然升級(jí)后效率下降較多），隨著RSA密鑰的增長(zhǎng)它開(kāi)始變得越來(lái)越慢。ECDSA會(huì)快很多，越來(lái)越多的站點(diǎn)支持ECDSA，中等長(zhǎng)度256位的ECDSA提供與3072位RSA一樣的安全性，卻有更好的性能。

  推薦優(yōu)先使用：ECDSA256_ECDHE256 與 RSA2048_ECDHE256 。

  

  2. 證書(shū)

• 證書(shū)鏈

  a、TLS握手的時(shí)候，服務(wù)器端會(huì)把證書(shū)鏈發(fā)送給客戶(hù)端進(jìn)行驗(yàn)證。

  b、證書(shū)鏈盡可能短。

  c、證書(shū)鏈要完整。

  d、盡量使用橢圓曲線(xiàn)證書(shū)鏈。

• 證書(shū)吊銷(xiāo)檢查與OCSP服務(wù)

  雖然證書(shū)吊銷(xiāo)狀態(tài)在不斷變化，并且客戶(hù)端（瀏覽器）對(duì)如何檢查證書(shū)吊銷(xiāo)差異很大，但作為服務(wù)器端，要做到盡可能快的傳遞吊銷(xiāo)信息。

• 使用帶OCSP信息的證書(shū)。

  OCSP被設(shè)計(jì)用于提供實(shí)時(shí)查詢(xún)，允許客戶(hù)端訪(fǎng)問(wèn)吊銷(xiāo)信息。因此查詢(xún)簡(jiǎn)短而快速（1個(gè)HTTP請(qǐng)求）。相比之下CRL是一個(gè)包含大量被吊銷(xiāo)證書(shū)的列表。一些客戶(hù)端只有當(dāng)OCSP信息不可用的時(shí)候才下載CRL，在下載CRL的時(shí)候?yàn)g覽器與服務(wù)器端的通信將暫停，直到CRL下載完成，所消耗的時(shí)間可能會(huì)有幾十秒。

• 選擇具有快速且可靠的OCSP響應(yīng)程序的CA

  不同CA之間的OCSP響應(yīng)速度也不同。緩慢和錯(cuò)誤的OCSP響應(yīng)程序會(huì)潛在地導(dǎo)致性能下降。在決定使用OCSP響應(yīng)之后，要考察CA對(duì)OCSP響應(yīng)的性能與正確性。另一個(gè)選擇CA的標(biāo)準(zhǔn)是看更新OCSP響應(yīng)的速度，最好自己的證書(shū)一經(jīng)頒發(fā)就加入到OCSP響應(yīng)程序中，一旦出了安全隱患被吊銷(xiāo)，OCSP響應(yīng)也能迅速的更新。

[root@www ~]# openssl s_client -connect www.openssl.org:443 -status |grep -i ocsp
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify error:num=20:unable to get local issuer certificate
OCSP response: 
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response

3. 會(huì)話(huà)恢復(fù)

TLS理解兩種類(lèi)型的握手：完整握手和簡(jiǎn)短握手。理論上完整握手只會(huì)在客戶(hù)端與服務(wù)器建立TLS會(huì)話(huà)（TLS session）的時(shí)候進(jìn)行一次。后續(xù)的連接，雙方使用簡(jiǎn)短握手恢復(fù)之前協(xié)商的會(huì)話(huà)。簡(jiǎn)短握手因?yàn)椴恍枰荑€交換與密鑰生成等操作，所以會(huì)更快，并且少一次往返時(shí)間。

4.TLS的紀(jì)錄協(xié)議造成的在網(wǎng)絡(luò)傳輸中的額外開(kāi)銷(xiāo)

TLS協(xié)議的最小傳輸單位是一個(gè)TLS記錄，它最多可以包含2^14=16384字節(jié)（16K）的數(shù)據(jù)。一條記錄在不加密的情況下只有很小的開(kāi)銷(xiāo)；每個(gè)記錄以5字節(jié)的元數(shù)據(jù)開(kāi)頭，即內(nèi)容類(lèi)型（1字節(jié)）、協(xié)議版本（2字節(jié)）和數(shù)據(jù)長(zhǎng)度（2字節(jié)）。流加密、分組加密和已驗(yàn)證密碼套件加密后的TLS記錄的額外開(kāi)銷(xiāo)。

盡量避免發(fā)送小包數(shù)據(jù)。盡量緩沖應(yīng)用層數(shù)據(jù)避免額外的網(wǎng)絡(luò)開(kāi)銷(xiāo)。

5.對(duì)稱(chēng)加密對(duì)CPU資源的消耗

加密操作有明顯的CPU成本，成本由加密算法、加密模式和完整性校驗(yàn)算法三者決定。

6. TLS 記錄的緩存延遲

TLS記錄是TLS發(fā)送和接收數(shù)據(jù)的最小單位。TLS記錄的大小與下一層TCP包的大小并不匹配，一個(gè)全尺寸的TLS記錄16 KB需要被拆分成許多小的TCP包(大約12個(gè))，通常每個(gè)小于1.5 KB（1.3KB）。整個(gè)TLS記錄被分成小的TCP包后，各個(gè)小包會(huì)陸續(xù)到達(dá)，但在全部到齊之前是無(wú)法進(jìn)行解密處理的。這是因?yàn)門(mén)LS記錄同樣是數(shù)據(jù)解密和完整性檢驗(yàn)的最小單位。緩存延遲有時(shí)可能會(huì)比較大。

雖然通過(guò)TCP協(xié)議可以把丟失和延遲的數(shù)據(jù)包恢復(fù)，但仍然需要消耗一次往返。每一次額外的往返對(duì)于整個(gè)TLS記錄都意味著延遲。 初始擁塞窗口另一個(gè)觸發(fā)額外往返的延遲是在連接初期發(fā)送大量數(shù)據(jù)導(dǎo)致初始擁塞窗口溢出。一旦擁塞窗口滿(mǎn)了，發(fā)送端必須等待響應(yīng)（1次往返），等到擁塞窗口增加再發(fā)送更多數(shù)據(jù)。

如果Web服務(wù)器支持TLS記錄調(diào)整，就應(yīng)該考慮將默認(rèn)值（16 KB這么大的數(shù)值）改成更為合理的值，調(diào)整這個(gè)值由部署的密碼套件和相應(yīng)的傳輸開(kāi)銷(xiāo)決定，一般情況下設(shè)置成4 KB。如果將TLS記錄大小設(shè)置為與TCP/IP包準(zhǔn)確匹配，那就設(shè)置成1400字節(jié)左右，然后通過(guò)觀(guān)察數(shù)據(jù)包逐步調(diào)整。IP報(bào)文理論上最大是65535個(gè)字節(jié)，是很大的，但是由于IP分片效果很不好，所以TCP在三次握手中互相得知對(duì)方的MSS（MTU減IP頭部），不給IP層很大塊的數(shù)據(jù)，避免IP數(shù)據(jù)報(bào)分片

例如，數(shù)據(jù)鏈路層最大傳輸單元（maximum transfer unit，MTU）是1500字節(jié)，那么可以預(yù)見(jiàn)：

1,500 bytes MTU 去除額外開(kāi)銷(xiāo)，所傳數(shù)據(jù) 1379 —1419 bytes 。

-20 bytes IPv4 herder | - 40 bytes IPv6 header

- 32 bytes TCP header TCP 頭部 最小是20字節(jié)可拓展的是40字節(jié)，最大為60字節(jié)

- 29 bytes TLS record | - 49 bytes TLS record

---

MSS 是1460 bytes ：1460 - 32 - 29|49 = 1379 — 1399 bytes

首先MTU的值是變化的。雖然多數(shù)客戶(hù)端繼承以太網(wǎng)1500字節(jié)的限制，但也有一些協(xié)議支持更大的數(shù)據(jù)。比如，巨型幀（jumbo frame）允許多達(dá)9000字節(jié)。還有就是使用IPv4和IPv6（IPv4頭是20字節(jié)，IPv6頭是40字節(jié)）計(jì)算會(huì)略有不同，所密碼套件的變化也會(huì)影響這個(gè)數(shù)值。

另一個(gè)問(wèn)題是減小TLS記錄的大小會(huì)增加傳輸開(kāi)銷(xiāo)，也就是吞吐量會(huì)下降。如果將TLS記錄長(zhǎng)度調(diào)大（最大16K），那么由于是加密的數(shù)據(jù)，得要所有的數(shù)據(jù)（所有的IP包）都到齊了，才會(huì)順利的解密出明文，等待的時(shí)間會(huì)較長(zhǎng)，吞吐率是上去了，響應(yīng)的實(shí)時(shí)性就下降了。nginx上也有配置這個(gè)值的選項(xiàng)，只是不能動(dòng)態(tài)調(diào)整。