HTTPS 是互聯(lián)網(wǎng)安全的基礎(chǔ)之一，然而引入 HTTPS 卻會帶來性能上的損耗。本文作者深入解析了 HTTPS 協(xié)議優(yōu)化的各個方面，對實戰(zhàn)很有幫助。

2012 年斯諾登（Edward Snowden）爆出棱鏡門事件后，互聯(lián)網(wǎng)安全問題日益得到大家的重視。去年 Apple 宣布 2017 年 1 月 1 日之前實現(xiàn)所有的 App 能夠安全地接入服務(wù)器，這項聲明來自于 iOS9 時代的應(yīng)用程序安全傳輸功能（App Transport Security）。逾期沒有采用 HTTPS 的 app 將無法通過審核并遭到下架。同年美圖也在 11 月完成了全網(wǎng)的 HTTPS 改造，將服務(wù)的安全級別到了一個新的高度。

本文將科普式的介紹 HTTPS 協(xié)議以及美圖在 HTTPS 優(yōu)化方面的探索與實踐。

Abstract

限于篇幅，本文不對 TLS/SSL 協(xié)議的安全性做過多的假設(shè)與討論，將圍繞 HTTPS 的體驗（速度）優(yōu)化介紹一下幾個方面：

• TLS/SSL 協(xié)議淺析

• HTTPS 優(yōu)化探索

• HTTPS 優(yōu)化實踐

SSL：安全套接字層

概述

聽到 SSL 協(xié)議很多同學(xué)可能立刻會想起一個問題：SSL 協(xié)議和 TLS 協(xié)議到底有什么區(qū)別呢？

HTTPS是基于SSL的加密傳輸協(xié)議，使用SSL來協(xié)商加密密鑰。 SSL 協(xié)議最早是由網(wǎng)景公司（Netscape）開發(fā)，但是隨著網(wǎng)景的沒落，現(xiàn)在由 IETF 負責(zé)維護，最初的版本也已經(jīng)重新冠名TLS（安全傳輸層協(xié)議） 1.0（1999 年）。因此現(xiàn)在大部分協(xié)議是基于 TLS 的，盡管是相似的東西。所以這兩個協(xié)議其實是同一個東西，叫什么名字都可以。

為了方便記錄，本文后續(xù)將使用 SSL協(xié)議來代指SSL/TLS 協(xié)議。

截止目前 SSL/TLS協(xié)議族中有7種協(xié)議：

SSL v1, SSL v2, SSL v3, TLS v1.0, TLS v1.1, TLS v1.2, TLS v1.3(draft):

• SSL v1 從未正式公開。

• SSL v2 協(xié)議設(shè)計有缺陷，不安全。

• SSL v3 老舊過時，缺乏一些新的密鑰特性。

• TLS v1.0 在很大程度上是安全的，至少沒有曝光重大的安全漏洞。

• TLS v1.1 和 TLS v1.2 目前都沒有著名的安全漏洞曝光。

• TLS v1.3 仍然在草案階段，而且有待時間檢驗。

常用 Linux 發(fā)行版默認 OpenSSL 版本：

協(xié)議棧關(guān)系

我們先來看看 SSL 協(xié)議到底工作在哪里。

TCP 7 層協(xié)議棧是我們都熟悉的內(nèi)容，SSL 協(xié)議是工作在 表示層的協(xié)議。這也就是說 SSL 需TCP/UDP之上工作；在HTTP/FTP/SNMP等協(xié)議之前創(chuàng)建會話。顧名思義 HTTPS 就是基于 SSL 協(xié)議的加密的HTTP協(xié)議。

SSL 協(xié)議棧內(nèi)容

整個 SSL 協(xié)議棧包含了 三種類型的協(xié)議：

• 握手協(xié)議：用于協(xié)商 SSL 密鑰

• 記錄協(xié)議：用于記錄 SSL 會話相關(guān)信息

• 警報協(xié)議：用于通知對端停止 SSL 會話

這里我們結(jié)合抓包來重點看一下 握手協(xié)議的工作過程。

SSL：握手過程

先來一張圖，看一看 SSL 握手的過程:

圖上藍色部分是 TCP 的握手，灰色部分是應(yīng)用層加密的數(shù)據(jù)傳輸（HTTPS 數(shù)據(jù)）。可以看到，整個握手過程設(shè)計， server 與 client 交互的過程大致有一下幾個部分：

• client hello

• server hello

• client key exchange

• change cipher spec

概括起來，前兩個過程 生成了非對稱加密的重要參數(shù)，創(chuàng)建了非對稱密鑰。后兩個過程交換了非對稱加密的公鑰。

欲詳細了解握手的過程是如何發(fā)生的，交換了哪些內(nèi)容，請參考我的另一篇博客：

從 TCP 建立連接到 HTTPS 接收到第一個數(shù)據(jù)包，到底發(fā)生了什么？[1]

接下來讓我們通過簡單的抓包我們可以看到整個 SSL 協(xié)議握手與創(chuàng)建會話的全過程。

wireshark是我最喜歡的抓包工具之一，另一個是tcpdump。為了生動形象更易閱讀，我們用wireshark來抓包了解整個過程。

client hello (client)

server hello + certificate exchange (server)

change cipher spec + finished (client)

change cipher sped + fihished (server)

通過抓包，往往我們可以清楚地看到從建立 TCP 連接到 TCP 連接斷開，整個 SSL 握手的過程。這個過程是艱辛復(fù)雜的，從握手開始到真正的加密數(shù)據(jù)發(fā)送，之間有多個 RoundTrip。因此我們的優(yōu)化過程就是從這里開始入手。

SSL 流量優(yōu)化

順著這樣一個思路，先來看下優(yōu)化到底能從哪些地方入手：

• 優(yōu)化 SSL 握手之前過程

  • TCP 優(yōu)化

• 優(yōu)化 SSL 握手過程

  • False start

  • 優(yōu)化握手流程

  • 加快密鑰計算

• 優(yōu)化 SSL 握手之后過程

  • HTTP/2 || SPDY

  • 內(nèi)容壓縮

  • 對稱加密套件選擇

優(yōu)化 SSL 握手前的過程

TCP Fast Open

TCP Fast Open(一下簡稱 TFO)目的在于簡化 TCP 握手的過程，通過一定的協(xié)商過程（SYN 攜帶 cookie 信息）使得下一次握手的時候在 SYN 包中就可以攜帶數(shù)據(jù)，同時 Server 可以在發(fā)出 SYN ACK 之后立即開始發(fā)送數(shù)據(jù)。因此如果我們的 SSL 握手建立 TCP 連接的時候能夠啟用 TFO，那么我們的 SSL 握手流量就可以減少 至少一個 RTT。

但是，由于 Server linux 內(nèi)核過于低，有的內(nèi)核并沒有支持 TFO。這點在我編譯 nginx 的時候就遇到了服務(wù)端內(nèi)核過低的問題。

TCP_FASTOPEN 特性在 kernel-3.6 被客戶端支持，在 kernel-3.7 被服務(wù)端支持。

想要開啟 TFO，先要檢查下你的內(nèi)核是否支持。

TCP 參數(shù)調(diào)優(yōu)

大家都知道 TCP 的幾個重要的算法，這里要說的就是 TCP 的慢啟動（Slow-Start）算法。

由于存在慢啟動的特征，開始時的 TCP 窗口可能較為小，因此如果我們的 SSL 握手包非常的大，那么潛在的可能就是發(fā)生 TCP 分片，相當(dāng)于增加了一個額外的 RTT。因此，如果能在不影響其他服務(wù)的情況下，調(diào)整窗口的大小，也是一種優(yōu)化的思路。

關(guān)于一點，我們在后面還會繼續(xù)說明。

優(yōu)化 SSL 握手的過程

優(yōu)化 SSL 握手過程是整個過程的核心，這里也是重點優(yōu)化的方向。我們有以下幾個思考優(yōu)化的點：

• TLS False Start

• HSTS

• Session Resumption

• OCSP Stapling

• 證書優(yōu)化

• 非對稱加密運算加速

SSL False Start

在 SSL 握手完成之前率先開始加密的 application 數(shù)據(jù)交互。這種思想很像剛剛提及的TFO思路。通過節(jié)省掉一次交互過程從而節(jié)省 RTT。實現(xiàn)的基礎(chǔ)是 client 拿到server radom 之后（server hello）其實就已經(jīng)有了生成非對稱加密所需要的密鑰的 3 個關(guān)鍵：

server random，client random，pre-master-secret。

未開啟 False Start

開啟了 False Start

通過抓包可以發(fā)現(xiàn)，在剛收到 437 號包協(xié)商還沒結(jié)束的時候，應(yīng)用層的數(shù)據(jù)已經(jīng)開始了傳輸 （439-442 號包），而到443號包才完成了握手。

在現(xiàn)代的 SSL False Start 實現(xiàn)中，主要有兩種方式：

• NPN：Next Protocol Negotiation 協(xié)議文檔[2]

  NPN 最早引入 false start 思想，是 SSL 的擴展部分。不過 Chrome 51 中移除將會 NPN，因此應(yīng)該盡快支持 ALPN來替代

• ALPN Application Layer Protocol Negotiation

  ALPN 是 Google 根據(jù) HTTP2 設(shè)計的，計劃替代 npn 的新協(xié)議，目的與 npn 相同，通過協(xié)商，優(yōu)化 SSL 握手的過程。然而，ALPN 需要 OpenSSL 1.0.2支持，當(dāng)前主流服務(wù)器操作系統(tǒng)基本都沒有內(nèi)置這個版本。所以需要進行升級。

這兩者本身設(shè)計用于協(xié)議協(xié)商的，因此也可以用于支持 HTTP2。但是他們之間有一些差異：

• NPN 是服務(wù)端發(fā)送所支持的 HTTP 協(xié)議列表，由客戶端選擇

• NPN 的協(xié)商結(jié)果是在 Change Cipher Spec之后加密發(fā)送給服務(wù)端

• ALPN 是客戶端發(fā)送所支持的 HTTP 協(xié)議列表，由服務(wù)端選擇

• ALPN 的協(xié)商結(jié)果是通過 Server Hello 明文發(fā)給客戶端

這兩個協(xié)議用于 SSL False Start 本身就是使用了副作用。不過，為了開啟 False Start，加密套件必須支持前向保密，例如 ECDHE_RSA加密套件。

HTTP Strict Transport Security

HTTP Strict Transport Security（簡稱HSTS）是一個安全功能，告訴瀏覽器只能通過 HTTPS 訪問當(dāng)前資源，禁止 HTTP 方式。最初目的防范降級攻擊（Downgrade attack）或中間人攻擊（Man-in-the-middle attack）

我們肯定遇到過這樣的情況：訪問一個 HTTP 開頭的網(wǎng)站，然后瀏覽器自動幫我們跳轉(zhuǎn)到了HTTPS 頁面。這意味著一次潛在的重定向。

HSTS 通過內(nèi)置的 preload list 保存了一份可以定期更新的列表，對于列表中的域名，即使用戶之前沒有訪問過，也會使用 HTTPS 協(xié)議。如果你的服務(wù)端開啟了 HSTS 這個選項，那么客戶端可以直接訪問 HTTPS 頁面，從而避免了一次無謂的跳轉(zhuǎn)，其實也是加速了訪問的過程。

這樣做的好處是帶來安全性的同時，避免了潛在的重定向帶來的一次額外 RTT。

然而全站 HTTPS + HSTS，導(dǎo)致一旦更換回 HTTP，處于 list 的老用戶會被無限重定向。

chrome 查看本地 hsts preload list 的方式是訪問 chrome://net-internals/#hsts

SSL Session Resumption

這里使我們優(yōu)化大點的重點。Session Resumption意為會話恢復(fù)。顧名思義，這里的會話正是指恢復(fù)先前的 SSL 會話。通過會話恢復(fù)技術(shù)我們可以以最小的代價，規(guī)避最耗時的握手過程。收益可觀。

我們先上抓包:

通過抓包可以看到，開啟了 Session Resumption 的 SSL 握手，在 2 個 RTT 的時候就已經(jīng)完成了握手。這是如何做到的呢？

我們先來看3個名詞概念：

• Session ID：會話 ID，用于唯一標識一個 SSL 會話。

• Session Ticket：會話憑據(jù)，記錄了本次會話相關(guān)的密鑰與認證信息。

• Session Cache：會話緩存，用于緩存會話相關(guān)的信息。

目前實現(xiàn)會話恢復(fù)大致有 2 種方式：Session ID 恢復(fù)會話和 Session Ticket 恢復(fù)會話。

Session ID 方式

TLS 握手中生成的 Session ID，服務(wù)端可以將 Session ID 和 協(xié)商后的信息對應(yīng)存起來。同時，瀏覽器也可以保存 Session ID，并在后續(xù)的 ClientHello 握手中帶上它，如果服務(wù)端能找到與之匹配的信息，就可以完成一次快速握手。

這樣做帶來的弊端也很明顯：

• 由于目前大多是大型互聯(lián)網(wǎng)結(jié)構(gòu)。負載均衡中，多機之間往往沒有同步 Session 信息，如果客戶端兩次請求沒有落在同一臺機器上就無法找到匹配的信息，導(dǎo)致失敗。

• 服務(wù)端存儲 Session ID 對應(yīng)的信息不好控制失效時間，太短起不到作用，太長又占用服務(wù)端大量資源。

為了解決這個問題，可以通過 IP hash 來負載，但是依然容易因為網(wǎng)絡(luò)環(huán)境變化導(dǎo)致握手的失敗。通過 Session cache 共享也是一種解決方案，nginx 提供了本機的共享，但是跨節(jié)點的共享就需要通過一個中心化的 Session cache 來實現(xiàn)。這無疑增加了跟多的成本。

Session Ticket 方式

Session Ticket 是通過服務(wù)端安全密鑰加密過的會話信息，最終保存在 client。瀏覽器如果在 ClientHello 時帶上了 Session Ticket，只要服務(wù)器能成功解密就可以完成快速握手。這種方式緩解了 Session ID 帶來的潛在的握手失敗的風(fēng)險。

然而，Session Ticket 的加密使得 必須保證所有 server 上的加密密鑰相同否則負載均衡到不同機器的時候因為無法解密一樣會導(dǎo)致失敗。

看似，Session Ticket 更容易解決 Session id 的一些痛點。然而在我們的抓包中，很容易發(fā)現(xiàn)，因為 Session Ticket 信息過大，導(dǎo)致 TCP 分片。特別是在開始階段門限值小，更容易出現(xiàn)這個問題。

OCSP Stapling

OCSP stapling 是 OCSP 的一個擴展協(xié)議，那么什么是 OCSP 呢？

在 SSL 握手階段，客戶端驗證證書有效狀態(tài)通常有兩個方式：

• CRL（Certificate Revocation List，證書撤銷名單）

• OCSP（Online Certificate Status Protocol，在線證書狀態(tài)協(xié)議）

CRL 時效性差，而且 list 會越來越大，瀏覽器更新通常不及時（以天為單位）。

OCSP 是為了解決舊的證書檢查協(xié)議的弊端的實時協(xié)議，實時解析證書的有效性。

然而，某些客戶端會在 SSL 握手階段進一步協(xié)商時，實時查詢 OCSP 接口，并在獲得結(jié)果前阻塞后續(xù)流程，這對性能影響很大。OCSP stapling 正是為了解決這些問題：將對于證書的驗證過程代理到 server上，減少 client 的壓力。查詢后打包下發(fā)client。同時 OCSP stapling 支持 Certificate Transparency，證書安全性有保障。

通過 OpenSSL 內(nèi)置工具可以查詢服務(wù)端 OCSP Stalping 的狀態(tài)：

openssl s_client -connect varycloud.com:443 -servername varycloud.com -status -tlsextdebug < /dev/ 2>&1 | grep -i "OCSP response" OCSP response: OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response

同一個請求，第一次可能沒有開啟 OCSP Stapling，原因在于 server 會先去獲取OCSP 的狀態(tài)，這需要一個過程。

證書優(yōu)化

證書優(yōu)化是指減小不必要的握手開銷，這里我們先不討論加密運算的消耗。通常我們有一個證書的原則，證書包含中間證書但是不包含根證書，這是最小化的證書配置，因為根證書瀏覽器一般都會內(nèi)置。而中間證書如果不一同下發(fā)，那么瀏覽器會遞歸的查詢請求中間證書，這也是無意義的消耗。

通常來說，我們常用的非對稱加密算法是 RSA 。可以說，RSA也是我們信息安全的基石。然而RSA的密鑰長度是非常巨大的，計算量也是驚人的。

一種更新的解決方案是使用 DH 加密。這也是一種非對稱加密。對于DH 加密，常常與橢圓曲線一起使用被稱為 ECDH。通過橢圓曲線優(yōu)化之后的的 DH 加密有更好的性能同時占用更小的密鑰長度。

ECDH 算法使用較短的密鑰即可達到相同程度的安全性，這是因為它依賴橢圓曲線而不是對數(shù)曲線。ECC 是建立在基于橢圓曲線的離散對數(shù)問題上的密碼體制，給定橢圓曲線上的一個點 P，一個整數(shù) k，求解 Q = kP 很容易；給定一個點 P、Q，知道 Q = kP，求整數(shù) k 確是一個難題。

OpenSSL 1.0.2 采用了 Intel 最新的優(yōu)化成果。這個優(yōu)化特性只是在 1.0.1L 之后才加入的，下圖表格中 OpenSSL 的 1.0.1e 版本 ecdh(nistp256) 的性能只有 2548，而 OpenSSL 的 1.1.0b 版本 ecdh(nistp256) 性能能達到 10271，提高了 4 倍。

非對稱加密運算加速

RSA 和 ECDHERSA 為什么會消耗CPU資源？

RSA 主要是對客戶端發(fā)回來 pre_master_secret 進行解密，它消耗 CPU 資源的過程是私鑰解密的計算；而 ECDHERSA 則有兩個步驟：

生成 ECC 橢圓曲線的公鑰和幾個重要的參數(shù)；

對這幾個參數(shù)進行簽名，客戶端要確保參數(shù)是服務(wù)端發(fā)過來的，就是通過 RSA 的簽名來保證。

RSA 簽名為什么消耗 CPU 呢？RSA 簽名同樣有兩個步驟：

首先它通過 SHA1 進行 Hash 計算；

對 Hash 結(jié)果進行私鑰加密，也就是最終消耗 CPU 的過程是私鑰解密和私鑰加密的計算。這兩個計算為什么消耗 CPU？看下圖公式，如果 e 或者 d 這個指數(shù)是一個接近 2 的 2048 次方的天文數(shù)字，那就非常消耗 CPU。這也就是 RSA 算法為什么消耗 CPU 的最直接的數(shù)學(xué)解釋。

對于非對稱加密的優(yōu)化，常見的方式有

• 硬件加速卡

• GPU 加速集群代理計算

專門的硬件優(yōu)化可以節(jié)約大量的時間，這點相信了解計算機原理的同學(xué)都能明白。同樣 GPU 代理計算是將計算與握手分離，同樣是專用集群專門加速，因此效率更高。

因為對這些具體的硬件沒有專門的測試和了解，就不過多的討論。

優(yōu)化 SSL 握手之后的流程

在通過了握手之后，我們的流量進入了安全的通信通道。此時還有可以優(yōu)化的空間么？

• 對稱加密算法優(yōu)化

• HTTP2 / SPDY （TCP 多路復(fù)用）

對稱加密算法優(yōu)化

經(jīng)過了 SSL 握手之后的流量就進入了加密的通信通道，因此對稱加密算法的效率其實也是十分重要的。然而因為大多數(shù)的對稱加密算法并沒有很大的優(yōu)化空間，這里的優(yōu)化往往得不到足夠的重視。我們這里以一種特殊的加密算法為例進行介紹。

ChaCha20-Poly1305 是 Google 所采用的一種新式加密算法，性能強大，在 CPU 為精簡指令集的 ARM 平臺上尤為顯著（ARM v8前效果較明顯），在同等配置的手機中表現(xiàn)是 AES 的 4 倍。可減少加密解密所產(chǎn)生的數(shù)據(jù)量進而可以改善用戶體驗，減少等待時間，節(jié)省電池壽命等。

ARM v8 之后加入了 AES 指令。所以在這些平臺上的設(shè)備，AES 方式反而比 chacha20 方式更快，性能更好。因此作為一個可選的方案，chacha20 可能對于一些老舊的機型（向嵌入式大牛咨詢過之后了解到，目前來說還有很多在使用 arm v7 的硬件）來說更具優(yōu)勢。

SPDY || HTTP/2

對于流量的優(yōu)化還有一種思路，那就是 TCP\SSL 鏈接的復(fù)用。講到http的多路復(fù)用，就繞不開 HTTP/2。這次，我們從HTTP/2的始祖 SPDY 說起。

傳統(tǒng)的http請求模型類似于 1:1 形式，單個 TCP（SSL） 鏈接服務(wù)一個 HTTP 請求，很多情況下，TCP 鏈接資源并沒有得到充分的利用。HTTP 多路復(fù)用能夠有效地提高 TCP 鏈路的效率。

SPDY 是 Google 開發(fā)的基于 TCP 的傳輸層協(xié)議，用以最小化網(wǎng)絡(luò)延遲，提升網(wǎng)絡(luò)速度，優(yōu)化用戶的網(wǎng)絡(luò)使用體驗。IETF 對谷歌提出的 SPDY 協(xié)議進行了標準化，于 2015 年 5 推出了類似于 SPDY 協(xié)議的 HTTP 2.0 協(xié)議標準（簡稱HTTP/2）。谷歌因此宣布放棄對 SPDY 協(xié)議的支持，轉(zhuǎn)而支持 HTTP/2。

簡而言之，無論是 SPDY 還是 HTTP/2 目的都在于提高鏈接的效率。而且，HTTP/2 天然支持 SSL false start 和 HTTPS，安全性和效率上都提供了保障。

HTTPS 優(yōu)化實踐

這里我們將通過數(shù)據(jù)的對比來檢驗 SSL 優(yōu)化的效果。我們從以下 3 個測試結(jié)果來分析 SSL 優(yōu)化的效果。

• SSL Session Resumption

• OCSP stapling

• 加密算法優(yōu)化與分析

測試方案

采用壓力測試的方式，對比不同配置下，相同壓力服務(wù)端的服務(wù)能力和延遲表現(xiàn)。

服務(wù)端配置

• CPU Info E5 6 核心 12 線程（超線程）

• 32G RAM

• Intel Corporation 82574L Gigabit Network 千兆網(wǎng)卡

測試 Server版本

• Linux kernel

  • 2.6.32-573.el6.x86_64

• nginx

  • version: nginx/1.10.2

• OpenSSL

  • OpenSSL 1.0.2l

• 壓測工具

  • wrk 是一個專門用于測試 HTTP 請求響應(yīng)的工具。功能強大，但是對于 HTTPS 支持不夠友好。

  • wrk-go 是我使用 go 和自己的測試框架 perfm 重新實現(xiàn)的一個測試工具，專門增加了 HTTPS 相關(guān)的選項，方便測試。

  • 文后有 wrk-go 鏈接，歡迎大家一起完善它！(這不是廣告 ^ ^) [3]

SSL Session Resumption

測試結(jié)果

未開啟會話恢復(fù)

./wrk -c 24 -t 24 -d 3m -H "Connection: Close" https://varycloud.com Running 3m test @ https://varycloud.com 24 threads and 24 connections Thread Stats Avg Stdev Max +/- Stdev Latency 4.76ms 8.34ms 174.25ms 97.01% Req/Sec 51.91 10.48 90.00 69.50% 223479 requests in 3.00m, 67.99MB read Non-2xx or 3xx responses: 223479 Requests/sec: 1240.95 Transfer/sec: 386.58KB

開啟會話恢復(fù)

./wrk -c 24 -t 24 -d 3m -H "Connection: Close" https://varycloud.com Running 3m test @ https://varycloud.com 24 threads and 24 connections Thread Stats Avg Stdev Max +/- Stdev Latency 1.71ms 10.17ms 165.85ms 98.78% Req/Sec 360.06 53.23 545.00 82.35% 1544216 requests in 3.00m, 469.78MB read Non-2xx or 3xx responses: 1544216 Requests/sec: 8574.25 Transfer/sec: 2.61MB

通過對比可以看到，SSL 會話恢復(fù)如果能夠被成功復(fù)用，那么提升非常可觀。相比基準數(shù)據(jù)能夠提升大約 64%。

同時由于略過了最消耗 CPU 的運算過程，可以看到系統(tǒng)的負載明顯降低，同時 IO 明顯提升，這說明服務(wù)能力得到了提高。

綜上可以得出，Session Resumption效果是非常明顯的。

OCSP Stapling 測試分析

OCSP Stapling 是我們感興趣的另一個特性。下面給出開啟 OCSP Stapling 的表現(xiàn)測試數(shù)據(jù)。具體統(tǒng)計了平均耗時 avg，耗時差異diff，數(shù)據(jù)包大小Data Length。

上圖中白框圈中的部分為開啟 OCSP后握手步驟的差別及耗時相差最多的階段。<---表示當(dāng)前握手步驟和箭頭指向的握手步驟是在同一個數(shù)據(jù)包。

分析

然而測試結(jié)十分令我們困惑：

理論上講，OCSP Sapling 規(guī)避了一次客戶端與服務(wù)端之間的通信，時間消耗上應(yīng)該會有提升。然而卻出現(xiàn)了下降。通過分析我們發(fā)現(xiàn)了端倪。

Client與兩者的對比，在經(jīng)歷各自2000請求，發(fā)現(xiàn)與開啟OCSP Stapling的Server通信，統(tǒng)計上多消耗了10.347ms左右， 最大的差異是Client收到Certificate后再到Client Key Exchange，開啟OCSP Stapling的Server的通信多消耗了5.370ms。

對比兩者握手差異，對應(yīng)任務(wù)多了兩部分

新增加傳輸Certificate Status的數(shù)據(jù)包，包大小為619 bytes。

驗證Certificate Status的合法性

由于網(wǎng)絡(luò)傳輸耗時與所傳輸?shù)臄?shù)據(jù)量多少成正比，以到 server ping 的耗時為標準時間的話，從時間上推斷傳輸Certificate加上Certificate Status耗時大概約為16.1848

11.488 * (1514 + 619) / 1514 = 16.1848

多出來的大概 0.673ms 可認為是驗證 Certificate Status 合法性的時間（如果不考慮兩臺服務(wù)器在通信時微小的網(wǎng)絡(luò)差異的話）。

驗證內(nèi)容包括 3.2 Signed Response Acceptance Requirements[4]：

• 驗證證書一致

  在OCSP Response 中所指的證書和請求中所指證書一致。

• 驗證簽名有效

  OCSP Response 中的簽名有效。

• 簽名者身份合法

  • 簽名者的身份和相映應(yīng)接受請求者匹配。

  • 簽名者正被授權(quán)簽名回復(fù)。

• 驗證時間

  • 表示狀態(tài)被認為是正確的時間（此次更新）足夠新。

  • 如果有的話，下次更新的時間應(yīng)該晚于現(xiàn)時時間。

對比未開啟OCSP的訪問，開啟OCSP驗證后，完整的握手建連過程中，請求時長會增加5ms左右的時間，用來傳輸Certificate Status數(shù)據(jù)及驗證OCSP response是合法可信的。

加密算法優(yōu)化調(diào)研

出于減少重復(fù)勞動的原因，這里直接給出一份 ArcSummit 上騰訊大牛分享過的一份優(yōu)化測試文檔里的數(shù)據(jù)： 騰訊HTTPS性能優(yōu)化實踐

對于老舊機型，chacha20性能有顯著的提升。

參考資料

這篇文章的形成參考了很多大牛先前的實踐經(jīng)驗與總結(jié)。感謝這些 巨人的肩膀讓我們可以有更廣闊的視野：

• im.ququ 的小站關(guān)于 http https 的文章與心得 [5]

• HTTP/2 探索第一篇：概念 [6]

• 騰訊 HTTPS 性能優(yōu)化實踐

• 開始使用 ECC 證書 [7]

• Keyless SSL: The Nitty Gritty Technical Details [8]

• ECDH 算法概述（CNG 示例） [9]

• Man-in-the-middle attack [10]

我是誰：李子昂，WX: Regin (ID:Regin_110)

干啥的：美圖公司架構(gòu)通訊核心研發(fā)工程師

還有啥：美圖瘋狂招人中，C，Golang，Java，PHP……

職責(zé)：主要負責(zé)美圖后端業(yè)務(wù)研發(fā)、編解碼研發(fā)、直播相關(guān)研發(fā)、虛擬化等各種方向，優(yōu)秀的人在這里總會找到屬于你的位置，

工作地點：北京、廈門、深圳隨意挑選。 快到碗里來！

簡歷投遞：yt@meitu.com 郵件請署名投遞方向。

[1] http://blog.csdn.net/arthur_killer/article/details/71405249

[2] http://www.ietf.org/mail-archive/web/tls/current/msg05593.html

[3] https://github.com/arthurkiller/wrk-go

[4] https://www.ietf.org/rfc/rfc2560.txt

[5] https://imququ.com/post/series.html

[6] https://www.qcloud.com/community/article/164816001481011799

[7] https://imququ.com/post/ecc-certificate.html

[8] https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/

[9] https://msdn.microsoft.com/zh-cn/library/cc488016(v=vs.90).aspx

[10] https://en.wikipedia.org/wiki/Man-in-the-middle_attack

總結(jié)

以上是生活随笔為你收集整理的美图HTTPS优化探索与实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。