WeTest 導(dǎo)讀

2017年1月1日起，蘋果公司將強制使用HTTPS協(xié)議傳輸。本文通過對HTTPS基礎(chǔ)原理和通信過程內(nèi)容的講解，介紹APP開發(fā)者在這個背景下的應(yīng)對辦法。

幾周前，我們在《https大勢已來？看騰訊專家如何在高并發(fā)壓測中支持https》中介紹了騰訊WeTest在基于epoll的高并發(fā)機器人框架中加入openssl的方法支持HTTPS接口測試的方法，不僅介紹了具體的使用辦法，并且了解到HTTPS注定會是未來的主流趨勢。

而隨著2016年行將結(jié)束，我們發(fā)現(xiàn)，這一天，已經(jīng)越來越近了。

隨著全球互聯(lián)網(wǎng)安全意識的進一步覺醒，越來越多的公司意識到網(wǎng)絡(luò)信息安全的重要性，只有絕對的加密才能保證在線交易和商務(wù)活動的安全進行?；ヂ?lián)網(wǎng)無疑是個人信息和隱私泄露最頻繁的場合，各種以竊取信息為方式而展開的網(wǎng)絡(luò)犯罪是互聯(lián)網(wǎng)發(fā)展所面臨的最大挑戰(zhàn)。在這樣一個大環(huán)境下，蘋果公司首先做出應(yīng)對，在蘋果全球開發(fā)者大會（WWDC）的一場安全演示會上，蘋果公司公布了一個最后期限——2017 年 1 月 1 日——即 App Store 當中的所有應(yīng)用必須啟用 App Transport Security （ATS）安全功能。

蘋果公司強制所有iOS App在2017年1月1日前使用HTTPS加密，這就意味著，如果您的APP如果仍采用HTTP傳輸，那么，在Apple Store中您的APP將不再能被用戶下載使用。

App Transport Security，簡稱 ATS，是蘋果在 iOS 9 當中首次推出的一項安全功能。在啟用 ATS 之后，它會強制應(yīng)用通過 HTTPS（而不是 HTTP）連接網(wǎng)絡(luò)服務(wù)，這能夠通過加密來保障用戶數(shù)據(jù)安全。

HTTPS 當中的“S”代表的是“安全”（secure），在登錄銀行或電郵賬號時，你會常常看到它出現(xiàn)在瀏覽器地址欄。不過，移動應(yīng)用在網(wǎng)絡(luò)連接安全性上面沒有那么透明，用戶很難知道應(yīng)用連接網(wǎng)絡(luò)時使用的是 HTTP 還是 HTTPS。

ATS 由此登場，它在 iOS 9 當中是默認開啟的。然而，開發(fā)者仍然能夠關(guān)閉 ATS，讓自己的應(yīng)用通過 HTTP 連接傳輸數(shù)據(jù)——現(xiàn)在的情況是，這招在年底之后就行不通了。（技術(shù)人員注意：ATS 要求使用 TLS v 1.2，但那些已經(jīng)經(jīng)過加密的批量數(shù)據(jù)例外，比如流媒體數(shù)據(jù)。）

在今年年底時，蘋果將要求所有提交到 App Store 的應(yīng)用強制開啟 ATS。現(xiàn)在有了明確的最終期限，那些一直 想知道 HTTP 會在什么時候遭此重擊的應(yīng)用開發(fā)者可以松一口氣了，而用戶也能安心地知道，他們的 iPhone 和 iPad 應(yīng)用將默認使用安全連接。

企業(yè)對于網(wǎng)絡(luò)信息安全的也越來越高，只有保證絕對的加密傳輸才能確保在線交易及用戶個人隱私數(shù)據(jù)的安全性。由于HTTP明文傳輸帶來的安全事件頻發(fā)，企業(yè)對于HTTP已無信任可言，只有通過HTTPS加密傳輸才能有效的防釣魚，防篡改，防監(jiān)聽，防劫持使網(wǎng)站安全可信。

首先需要選擇合適的證書為部署https證書做決策，然后調(diào)整后臺應(yīng)用實現(xiàn)后臺應(yīng)用全站https，協(xié)調(diào)運營及開發(fā)完成部署完善服務(wù)端應(yīng)用部署及Web服務(wù)器配置，最后以安全方式發(fā)布應(yīng)用完成應(yīng)用改造，重新發(fā)布應(yīng)用。

為了讓大家更好的理解上述措施，下面具體介紹一下相關(guān)的HTTPS基礎(chǔ)原理和通信過程。

HTTPS(Secure Hypertext Transfer Protocol) 安全超文本傳輸協(xié)議 它是一個安全通信通道，它基于 HTTP 開發(fā)，用于在客戶計算機和服務(wù)器之間交換信息。它使用安全套接字層(SSL)進行信息交換，簡單來說它是 HTTP 的安全版,是使用 TLS/SSL 加密的 HTTP 協(xié)議。

HTTP 協(xié)議采用明文傳輸信息，存在信息竊聽、信息篡改和信息劫持的風險，而協(xié)議 TLS/SSL 具有身份驗證、信息加密和完整性校驗的功能，可以避免此類問題。

TLS/SSL 全稱安全傳輸層協(xié)議 Transport Layer Security, 是介于 TCP 和 HTTP 之間的一層安全協(xié)議，不影響原有的 TCP 協(xié)議和 HTTP 協(xié)議，所以使用 HTTPS 基本上不需要對 HTTP 頁面進行太多的改造。

1、TLS/SSL 原理

HTTPS 協(xié)議的主要功能基本都依賴于 TLS/SSL 協(xié)議，本節(jié)分析安全協(xié)議的實現(xiàn)原理。

TLS/SSL 的功能實現(xiàn)主要依賴于三類基本算法：散列函數(shù) Hash、對稱加密和非對稱加密，其利用非對稱加密實現(xiàn)身份認證和密鑰協(xié)商，對稱加密算法采用協(xié)商的密鑰對數(shù)據(jù)加密，基于散列函數(shù)驗證信息的完整性。

散列函數(shù) Hash，常見的有 MD5、SHA1、SHA256，該類函數(shù)特點是函數(shù)單向不可逆、對輸入非常敏感、輸出長度固定，針對數(shù)據(jù)的任何修改都會改變散列函數(shù)的結(jié)果，用于防止信息篡改并驗證數(shù)據(jù)的完整性；對稱加密，常見的有 AES-CBC、DES、3DES、AES-GCM等，相同的密鑰可以用于信息的加密和解密，掌握密鑰才能獲取信息，能夠防止信息竊聽，通信方式是1對1；非對稱加密，即常見的 RSA 算法，還包括 ECC、DH 等算法，算法特點是，密鑰成對出現(xiàn)，一般稱為公鑰(公開)和私鑰(保密)，公鑰加密的信息只能私鑰解開，私鑰加密的信息只能公鑰解開。因此掌握公鑰的不同客戶端之間不能互相解密信息，只能和掌握私鑰的服務(wù)器進行加密通信，服務(wù)器可以實現(xiàn)1對多的通信，客戶端也可以用來驗證掌握私鑰的服務(wù)器身份。

在信息傳輸過程中，散列函數(shù)不能單獨實現(xiàn)信息防篡改，因為明文傳輸，中間人可以修改信息之后重新計算信息摘要，因此需要對傳輸?shù)男畔⒁约靶畔⒄M行加密；對稱加密的優(yōu)勢是信息傳輸1對1，需要共享相同的密碼，密碼的安全是保證信息安全的基礎(chǔ)，服務(wù)器和 N 個客戶端通信，需要維持 N 個密碼記錄，且缺少修改密碼的機制；非對稱加密的特點是信息傳輸1對多，服務(wù)器只需要維持一個私鑰就能夠和多個客戶端進行加密通信，但服務(wù)器發(fā)出的信息能夠被所有的客戶端解密，且該算法的計算復(fù)雜，加密速度慢。

結(jié)合三類算法的特點，TLS 的基本工作方式是，客戶端使用非對稱加密與服務(wù)器進行通信，實現(xiàn)身份驗證并協(xié)商對稱加密使用的密鑰，然后對稱加密算法采用協(xié)商密鑰對信息以及信息摘要進行加密通信，不同的節(jié)點之間采用的對稱密鑰不同，從而可以保證信息只能通信雙方獲取。

2、PKI 體系

（1）RSA 身份驗證的隱患

身份驗證和密鑰協(xié)商是 TLS 的基礎(chǔ)功能，要求的前提是合法的服務(wù)器掌握著對應(yīng)的私鑰。但 RSA 算法無法確保服務(wù)器身份的合法性，因為公鑰并不包含服務(wù)器的信息，存在安全隱患：

客戶端 C 和服務(wù)器 S 進行通信，中間節(jié)點 M 截獲了二者的通信；

節(jié)點 M 自己計算產(chǎn)生一對公鑰 pub_M 和私鑰 pri_M;

C 向 S 請求公鑰時，M 把自己的公鑰 pub_M 發(fā)給了 C;

C 使用公鑰 pub_M 加密的數(shù)據(jù)能夠被 M 解密，因為 M 掌握對應(yīng)的私鑰 pri_M，而 C 無法根據(jù)公鑰信息判斷服務(wù)器的身份，從而 C 和 M 之間建立了”可信”加密連接；

中間節(jié)點 M 和服務(wù)器S之間再建立合法的連接，因此 C 和 S 之間通信被M完全掌握，M 可以進行信息的竊聽、篡改等操作。

另外，服務(wù)器也可以對自己的發(fā)出的信息進行否認，不承認相關(guān)信息是自己發(fā)出。

因此該方案下至少存在兩類問題：中間人攻擊和信息抵賴。

幾周前，我們在《https大勢已來？看騰訊專家如何在高并發(fā)壓測中支持https》中介紹了騰訊WeTest在基于epoll的高并發(fā)機器人框架中加入openssl的方法支持HTTPS接口測試的方法，不僅介紹了具體的使用辦法，并且了解到HTTPS注定會是未來的主流趨勢。

而隨著2016年行將結(jié)束，我們發(fā)現(xiàn)，這一天，已經(jīng)越來越近了。

隨著全球互聯(lián)網(wǎng)安全意識的進一步覺醒，越來越多的公司意識到網(wǎng)絡(luò)信息安全的重要性，只有絕對的加密才能保證在線交易和商務(wù)活動的安全進行?；ヂ?lián)網(wǎng)無疑是個人信息和隱私泄露最頻繁的場合，各種以竊取信息為方式而展開的網(wǎng)絡(luò)犯罪是互聯(lián)網(wǎng)發(fā)展所面臨的最大挑戰(zhàn)。在這樣一個大環(huán)境下，蘋果公司首先做出應(yīng)對，在蘋果全球開發(fā)者大會（WWDC）的一場安全演示會上，蘋果公司公布了一個最后期限——2017 年 1 月 1 日——即 App Store 當中的所有應(yīng)用必須啟用 App Transport Security （ATS）安全功能。

（2）身份驗證-CA 和證書

解決上述身份驗證問題的關(guān)鍵是確保獲取的公鑰途徑是合法的，能夠驗證服務(wù)器的身份信息，為此需要引入權(quán)威的第三方機構(gòu) CA。CA 負責核實公鑰的擁有者的信息，并頒發(fā)認證”證書”，同時能夠為使用者提供證書驗證服務(wù)，即 PKI 體系。

基本的原理為，CA 負責審核信息，然后對關(guān)鍵信息利用私鑰進行”簽名”，公開對應(yīng)的公鑰，客戶端可以利用公鑰驗證簽名。CA 也可以吊銷已經(jīng)簽發(fā)的證書，基本的方式包括兩類 CRL 文件和 OCSP。CA 使用具體的流程如下：

a.服務(wù)方 S 向第三方機構(gòu)CA提交公鑰、組織信息、個人信息(域名)等信息并申請認證；

b.CA 通過線上、線下等多種手段驗證申請者提供信息的真實性，如組織是否存在、企業(yè)是否合法，是否擁有域名的所有權(quán)等；

c.如信息審核通過，CA 會向申請者簽發(fā)認證文件-證書。

證書包含以下信息：申請者公鑰、申請者的組織信息和個人信息、簽發(fā)機構(gòu) CA 的信息、有效時間、證書序列號等信息的明文，同時包含一個簽名；

簽名的產(chǎn)生算法：首先，使用散列函數(shù)計算公開的明文信息的信息摘要，然后，采用 CA 的私鑰對信息摘要進行加密，密文即簽名；

d.客戶端 C 向服務(wù)器 S 發(fā)出請求時，S 返回證書文件；

e.客戶端 C 讀取證書中的相關(guān)的明文信息，采用相同的散列函數(shù)計算得到信息摘要，然后，利用對應(yīng) CA 的公鑰解密簽名數(shù)據(jù)，對比證書的信息摘要，如果一致，則可以確認證書的合法性，即公鑰合法；

f.客戶端然后驗證證書相關(guān)的域名信息、有效時間等信息；

g.客戶端會內(nèi)置信任 CA 的證書信息(包含公鑰)，如果CA不被信任，則找不到對應(yīng) CA 的證書，證書也會被判定非法。

那么在完成了全站HTTPS，完成了后臺和服務(wù)器端的部署之后，如何快速的對“新站“進行快速的測試，檢測APP接口的承載能力？

騰訊WeTest提供了針對https的服務(wù)器性能測試功能，使用方法如下：

1、點擊服務(wù)器性能測試產(chǎn)品首頁（http://wetest.qq.com/gaps/ ）中的快捷入口：HTTP直壓。模式選擇簡單模式，名稱和描述可以自己填寫。（圖中示例起始人數(shù)50人，每隔60秒增加50人，加到200人為上限）

點擊左側(cè)“HTTP直壓“進入壓測

輸入合適的測試標題和測試設(shè)置

2、新建一個客戶端請求，接口壓測包括讀寫接口，讀接口基本是GET請求，寫接口基本是POST請求。GET請求使用url請求參數(shù)，填寫測試用例的基礎(chǔ)數(shù)值，選擇正確的URL

配置頁面header信息

3、隨后進行Header的配置，Header的名稱在選定URL的內(nèi)，打開URL的鏈接（推薦使用chrome瀏覽器），敲擊F12并刷新頁面，選定Network-Name-Headers-Request Headers（Header的名稱與值均在內(nèi)查看，如下圖所示）

查看頁面header信息

到這里，基本就完成了對https的配置過程了，是不是很簡單？下面動圖可以再回顧一下操作的流程：

gif動態(tài)圖展示操作的流程

在對HTTPS協(xié)議頁面進行了測試之后，下面再介紹一些HTTPS頁面性能優(yōu)化的方法。

1、HTTPS 性能損耗

HTTPS的優(yōu)勢在于進行完身份驗證、信息加密與完整性校驗等操作后，可以不對 TCP 和 HTTP 協(xié)議做任何修改。但通過增加新協(xié)議以實現(xiàn)更安全的通信必然需要付出代價，HTTPS 協(xié)議的性能損耗主要體現(xiàn)如下：

（1）增加延時

分析前面的握手過程，一次完整的握手至少需要兩端依次來回兩次通信，至少增加延時2 RTT，利用會話緩存從而復(fù)用連接，延時也至少1 RTT*。

（2）消耗較多的 CPU 資源

除數(shù)據(jù)傳輸之外，HTTPS 通信主要包括對對稱加解密、非對稱加解密(服務(wù)器主要采用私鑰解密數(shù)據(jù))；壓測 TS8 機型的單核 CPU：對稱加密算法AES-CBC-256 吞吐量 600Mbps，非對稱 RSA 私鑰解密200次/s。不考慮其它軟件層面的開銷，10G 網(wǎng)卡為對稱加密需要消耗 CPU 約17核，24核CPU最多接入 HTTPS 連接 4800；

靜態(tài)節(jié)點當前10G 網(wǎng)卡的 TS8 機型的 HTTP 單機接入能力約為10w/s，如果將所有的 HTTP 連接變?yōu)镠TTPS連接，則明顯 RSA 的解密最先成為瓶頸。因此，RSA 的解密能力是當前困擾 HTTPS 接入的主要難題。

2、HTTPS 接入優(yōu)化

（1）CDN 接入

HTTPS 增加的延時主要是傳輸延時 RTT，RTT 的特點是節(jié)點越近延時越小，CDN 天然離用戶最近，因此選擇使用 CDN 作為 HTTPS 接入的入口，將能夠極大減少接入延時。CDN 節(jié)點通過和業(yè)務(wù)服務(wù)器維持長連接、會話復(fù)用和鏈路質(zhì)量優(yōu)化等可控方法，極大減少 HTTPS 帶來的延時。

（2）會話緩存

雖然前文提到 HTTPS 即使采用會話緩存也要至少1*RTT的延時，但是至少延時已經(jīng)減少為原來的一半，明顯的延時優(yōu)化；同時，基于會話緩存建立的 HTTPS 連接不需要服務(wù)器使用RSA私鑰解密獲取 Pre-master 信息，可以省去CPU 的消耗。如果業(yè)務(wù)訪問連接集中，緩存命中率高，則HTTPS的接入能力講明顯提升。當前 TRP 平臺的緩存命中率高峰時期大于30%，10k/s的接入資源實際可以承載13k/的接入，收效非?？捎^。

（3）硬件加速

為接入服務(wù)器安裝專用的 SSL 硬件加速卡，作用類似 GPU，釋放 CPU，能夠具有更高的 HTTPS 接入能力且不影響業(yè)務(wù)程序的。測試某硬件加速卡單卡可以提供 35k 的解密能力，相當于175核 CPU，至少相當于7臺24核的服務(wù)器，考慮到接入服務(wù)器其它程序的開銷，一張硬件卡可以實現(xiàn)接近10臺服務(wù)器的接入能力。

（4）遠程解密

本地接入消耗過多的 CPU 資源，浪費了網(wǎng)卡和硬盤等資源，考慮將最消耗 CPU 資源的RSA解密計算任務(wù)轉(zhuǎn)移到其它服務(wù)器，如此則可以充分發(fā)揮服務(wù)器的接入能力，充分利用帶寬與網(wǎng)卡資源。遠程解密服務(wù)器可以選擇 CPU 負載較低的機器充當，實現(xiàn)機器資源復(fù)用，也可以是專門優(yōu)化的高計算性能的服務(wù)器。當前也是 CDN 用于大規(guī)模HTTPS接入的解決方案之一。

（5）SPDY/HTTP2

前面的方法分別從減少傳輸延時和單機負載的方法提高 HTTPS 接入性能，但是方法都基于不改變 HTTP 協(xié)議的基礎(chǔ)上提出的優(yōu)化方法，SPDY/HTTP2 利用 TLS/SSL 帶來的優(yōu)勢，通過修改協(xié)議的方法來提升 HTTPS 的性能，提高下載速度等。

騰訊WeTest服務(wù)器性能測試運用了沉淀十多年的內(nèi)部實踐經(jīng)驗總結(jié)，通過基于真實業(yè)務(wù)場景和用戶行為進行壓力測試，幫助游戲開發(fā)者發(fā)現(xiàn)服務(wù)器端的性能瓶頸，進行針對性的性能調(diào)優(yōu)，降低服務(wù)器采購和維護成本，提高用戶留存和轉(zhuǎn)化率。

功能目前免費對外開放中，歡迎大家的體驗

體驗地址：http://WeTest.qq.com/gaps/

如果對使用當中有任何疑問，歡迎聯(lián)系騰訊WeTest企業(yè)qq：800024531