WeTest 導讀
2017年1月1日起胯杭，蘋果公司將強制使用HTTPS協(xié)議傳輸驯杜。本文通過對HTTPS基礎原理和通信過程內容的講解，介紹APP開發(fā)者在這個背景下的應對辦法做个。
幾周前鸽心，我們在《https大勢已來？看騰訊專家如何在高并發(fā)壓測中支持https》中介紹了騰訊WeTest在基于epoll的高并發(fā)機器人框架中加入openssl的方法支持HTTPS接口測試的方法居暖，不僅介紹了具體的使用辦法顽频，并且了解到HTTPS注定會是未來的主流趨勢。
而隨著2016年行將結束太闺，我們發(fā)現(xiàn)糯景，這一天，已經(jīng)越來越近了。
隨著全球互聯(lián)網(wǎng)安全意識的進一步覺醒蟀淮，越來越多的公司意識到網(wǎng)絡信息安全的重要性最住，只有絕對的加密才能保證在線交易和商務活動的安全進行〉』蹋互聯(lián)網(wǎng)無疑是個人信息和隱私泄露最頻繁的場合涨缚，各種以竊取信息為方式而展開的網(wǎng)絡犯罪是互聯(lián)網(wǎng)發(fā)展所面臨的最大挑戰(zhàn)。在這樣一個大環(huán)境下策治，蘋果公司首先做出應對脓魏，在蘋果全球開發(fā)者大會（WWDC）的一場安全演示會上，蘋果公司公布了一個最后期限——2017 年 1 月 1 日——即 App Store 當中的所有應用必須啟用 App Transport Security （ATS）安全功能通惫。
一茂翔、這個舉措意味著什么？
蘋果公司強制所有iOS?App在2017年1月1日前使用HTTPS加密讽膏，這就意味著檩电，如果您的APP如果仍采用HTTP傳輸，那么府树，在Apple Store中您的APP將不再能被用戶下載使用俐末。
二、什么是App Transport Security （ATS）安全功能奄侠？
App Transport Security卓箫，簡稱 ATS，是蘋果在 iOS 9 當中首次推出的一項安全功能垄潮。在啟用 ATS 之后烹卒，它會強制應用通過?HTTPS（而不是 HTTP）連接網(wǎng)絡服務，這能夠通過加密來保障用戶數(shù)據(jù)安全弯洗。
HTTPS 當中的“S”代表的是“安全”（secure）旅急，在登錄銀行或電郵賬號時，你會常衬嫡看到它出現(xiàn)在瀏覽器地址欄藐吮。不過，移動應用在網(wǎng)絡連接安全性上面沒有那么透明逃贝，用戶很難知道應用連接網(wǎng)絡時使用的是 HTTP 還是 HTTPS谣辞。
ATS 由此登場，它在 iOS 9 當中是默認開啟的沐扳。然而泥从，開發(fā)者仍然能夠關閉 ATS，讓自己的應用通過 HTTP 連接傳輸數(shù)據(jù)——現(xiàn)在的情況是沪摄，這招在年底之后就行不通了躯嫉。（技術人員注意：ATS 要求使用 TLS v 1.2纱烘，但那些已經(jīng)經(jīng)過加密的批量數(shù)據(jù)例外，比如流媒體數(shù)據(jù)和敬。）
在今年年底時凹炸，蘋果將要求所有提交到 App Store 的應用強制開啟 ATS。現(xiàn)在有了明確的最終期限昼弟，那些一直 想知道 HTTP 會在什么時候遭此重擊的應用開發(fā)者可以松一口氣了啤它，而用戶也能安心地知道，他們的 iPhone 和 iPad 應用將默認使用安全連接舱痘。
三变骡、為什么這么做？
企業(yè)對于網(wǎng)絡信息安全的也越來越高，只有保證絕對的加密傳輸才能確保在線交易及用戶個人隱私數(shù)據(jù)的安全性。由于HTTP明文傳輸帶來的安全事件頻發(fā)拓轻，企業(yè)對于HTTP已無信任可言，只有通過HTTPS加密傳輸才能有效的防釣魚台妆，防篡改，防監(jiān)聽胖翰，防劫持使網(wǎng)站安全可信接剩。
四、開發(fā)者應該做什么萨咳？
首先需要選擇合適的證書為部署https證書做決策懊缺，然后調整后臺應用實現(xiàn)后臺應用全站https，協(xié)調運營及開發(fā)完成部署完善服務端應用部署及Web服務器配置培他，最后以安全方式發(fā)布應用完成應用改造鹃两，重新發(fā)布應用。
為了讓大家更好的理解上述措施舀凛，下面具體介紹一下相關的HTTPS基礎原理和通信過程俊扳。
五、HTTPS的基礎原理和通信過程
HTTPS(Secure Hypertext Transfer Protocol) 安全超文本傳輸協(xié)議 它是一個安全通信通道猛遍，它基于 HTTP 開發(fā)拣度，用于在客戶計算機和服務器之間交換信息。它使用安全套接字層(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ù)的結果，用于防止信息篡改并驗證數(shù)據(jù)的完整性雷猪；對稱加密睛竣，常見的有 AES-CBC、DES求摇、3DES射沟、AES-GCM等，相同的密鑰可以用于信息的加密和解密与境，掌握密鑰才能獲取信息验夯，能夠防止信息竊聽，通信方式是1對1摔刁；非對稱加密挥转，即常見的 RSA 算法，還包括 ECC共屈、DH 等算法绑谣，算法特點是，密鑰成對出現(xiàn)拗引，一般稱為公鑰(公開)和私鑰(保密)借宵，公鑰加密的信息只能私鑰解開，私鑰加密的信息只能公鑰解開矾削。因此掌握公鑰的不同客戶端之間不能互相解密信息壤玫，只能和掌握私鑰的服務器進行加密通信豁护，服務器可以實現(xiàn)1對多的通信，客戶端也可以用來驗證掌握私鑰的服務器身份欲间。
在信息傳輸過程中楚里，散列函數(shù)不能單獨實現(xiàn)信息防篡改，因為明文傳輸猎贴，中間人可以修改信息之后重新計算信息摘要班缎，因此需要對傳輸?shù)男畔⒁约靶畔⒄M行加密；對稱加密的優(yōu)勢是信息傳輸1對1嘱能，需要共享相同的密碼吝梅，密碼的安全是保證信息安全的基礎，服務器和 N 個客戶端通信惹骂，需要維持 N 個密碼記錄苏携，且缺少修改密碼的機制；非對稱加密的特點是信息傳輸1對多对粪，服務器只需要維持一個私鑰就能夠和多個客戶端進行加密通信右冻，但服務器發(fā)出的信息能夠被所有的客戶端解密，且該算法的計算復雜著拭，加密速度慢纱扭。
結合三類算法的特點，TLS 的基本工作方式是儡遮，客戶端使用非對稱加密與服務器進行通信乳蛾，實現(xiàn)身份驗證并協(xié)商對稱加密使用的密鑰，然后對稱加密算法采用協(xié)商密鑰對信息以及信息摘要進行加密通信鄙币，不同的節(jié)點之間采用的對稱密鑰不同肃叶，從而可以保證信息只能通信雙方獲取。
2十嘿、PKI 體系
（1）RSA 身份驗證的隱患
身份驗證和密鑰協(xié)商是 TLS 的基礎功能因惭，要求的前提是合法的服務器掌握著對應的私鑰。但 RSA 算法無法確保服務器身份的合法性绩衷，因為公鑰并不包含服務器的信息蹦魔，存在安全隱患：
客戶端 C 和服務器 S 進行通信，中間節(jié)點 M 截獲了二者的通信咳燕；
節(jié)點 M 自己計算產生一對公鑰 pub_M 和私鑰 pri_M;
C 向 S 請求公鑰時勿决，M 把自己的公鑰 pub_M 發(fā)給了 C;
C 使用公鑰 pub_M 加密的數(shù)據(jù)能夠被 M 解密，因為 M 掌握對應的私鑰 pri_M招盲，而 C 無法根據(jù)公鑰信息判斷服務器的身份剥险，從而 C 和 M 之間建立了”可信”加密連接；
中間節(jié)點 M 和服務器S之間再建立合法的連接宪肖，因此 C 和 S 之間通信被M完全掌握表制，M 可以進行信息的竊聽、篡改等操作控乾。
另外么介，服務器也可以對自己的發(fā)出的信息進行否認，不承認相關信息是自己發(fā)出蜕衡。
因此該方案下至少存在兩類問題：中間人攻擊和信息抵賴壤短。
幾周前，我們在《https大勢已來慨仿？看騰訊專家如何在高并發(fā)壓測中支持https》中介紹了騰訊WeTest在基于epoll的高并發(fā)機器人框架中加入openssl的方法支持HTTPS接口測試的方法久脯，不僅介紹了具體的使用辦法，并且了解到HTTPS注定會是未來的主流趨勢镰吆。
而隨著2016年行將結束帘撰，我們發(fā)現(xiàn)，這一天万皿，已經(jīng)越來越近了摧找。
隨著全球互聯(lián)網(wǎng)安全意識的進一步覺醒，越來越多的公司意識到網(wǎng)絡信息安全的重要性牢硅，只有絕對的加密才能保證在線交易和商務活動的安全進行蹬耘。互聯(lián)網(wǎng)無疑是個人信息和隱私泄露最頻繁的場合减余，各種以竊取信息為方式而展開的網(wǎng)絡犯罪是互聯(lián)網(wǎng)發(fā)展所面臨的最大挑戰(zhàn)综苔。在這樣一個大環(huán)境下，蘋果公司首先做出應對位岔，在蘋果全球開發(fā)者大會（WWDC）的一場安全演示會上如筛，蘋果公司公布了一個最后期限——2017 年 1 月 1 日——即 App Store 當中的所有應用必須啟用 App Transport Security （ATS）安全功能。
（2）身份驗證-CA 和證書
解決上述身份驗證問題的關鍵是確保獲取的公鑰途徑是合法的赃承，能夠驗證服務器的身份信息妙黍，為此需要引入權威的第三方機構 CA。CA 負責核實公鑰的擁有者的信息瞧剖，并頒發(fā)認證”證書”拭嫁，同時能夠為使用者提供證書驗證服務，即 PKI 體系抓于。
基本的原理為做粤，CA 負責審核信息，然后對關鍵信息利用私鑰進行”簽名”捉撮，公開對應的公鑰怕品，客戶端可以利用公鑰驗證簽名。CA 也可以吊銷已經(jīng)簽發(fā)的證書巾遭，基本的方式包括兩類 CRL 文件和 OCSP肉康。CA 使用具體的流程如下：
a.服務方 S 向第三方機構CA提交公鑰闯估、組織信息、個人信息(域名)等信息并申請認證吼和；
b.CA 通過線上涨薪、線下等多種手段驗證申請者提供信息的真實性，如組織是否存在炫乓、企業(yè)是否合法刚夺，是否擁有域名的所有權等；
c.如信息審核通過末捣，CA 會向申請者簽發(fā)認證文件-證書侠姑。
證書包含以下信息：申請者公鑰、申請者的組織信息和個人信息箩做、簽發(fā)機構 CA 的信息莽红、有效時間、證書序列號等信息的明文卒茬，同時包含一個簽名船老；
簽名的產生算法：首先，使用散列函數(shù)計算公開的明文信息的信息摘要圃酵，然后柳畔，采用 CA 的私鑰對信息摘要進行加密，密文即簽名郭赐；
d.客戶端 C 向服務器 S 發(fā)出請求時薪韩，S 返回證書文件；
e.客戶端 C 讀取證書中的相關的明文信息捌锭，采用相同的散列函數(shù)計算得到信息摘要俘陷，然后，利用對應 CA 的公鑰解密簽名數(shù)據(jù)观谦，對比證書的信息摘要拉盾，如果一致，則可以確認證書的合法性豁状，即公鑰合法捉偏；
f.客戶端然后驗證證書相關的域名信息、有效時間等信息泻红；
g.客戶端會內置信任 CA 的證書信息(包含公鑰)夭禽，如果CA不被信任，則找不到對應 CA 的證書谊路，證書也會被判定非法讹躯。
在這個過程注意幾點：
1.申請證書不需要提供私鑰，確保私鑰永遠只能服務器掌握；
2.證書的合法性仍然依賴于非對稱加密算法潮梯，證書主要是增加了服務器信息以及簽名骗灶；
3.內置 CA 對應的證書稱為根證書，頒發(fā)者和使用者相同秉馏，自己為自己簽名矿卑，即自簽名證書；
4.證書=公鑰+申請者與頒發(fā)者信息+簽名沃饶；
六、HTTPS接口測試
那么在完成了全站HTTPS轻黑，完成了后臺和服務器端的部署之后糊肤，如何快速的對“新站“進行快速的測試，檢測APP接口的承載能力氓鄙？
騰訊WeTest提供了針對https的服務器性能測試功能馆揉，使用方法如下：
1、點擊服務器性能測試產品首頁（http://wetest.qq.com/gaps/ ）中的快捷入口：HTTP直壓抖拦。模式選擇簡單模式升酣，名稱和描述可以自己填寫。（圖中示例起始人數(shù)50人态罪，每隔60秒增加50人噩茄，加到200人為上限）
2、新建一個客戶端請求复颈，接口壓測包括讀寫接口绩聘，讀接口基本是GET請求，寫接口基本是POST請求耗啦。GET請求使用url請求參數(shù)凿菩，填寫測試用例的基礎數(shù)值，選擇正確的URL
3帜讲、隨后進行Header的配置衅谷，Header的名稱在選定URL的內，打開URL的鏈接（推薦使用chrome瀏覽器）似将，敲擊F12并刷新頁面获黔，選定Network-Name-Headers-Request?Headers（Header的名稱與值均在內查看，如下圖所示）
到這里玩郊，基本就完成了對https的配置過程了肢执，是不是很簡單？下面動圖可以再回顧一下操作的流程：
七译红、HTTPS性能與優(yōu)化
在對HTTPS協(xié)議頁面進行了測試之后预茄，下面再介紹一些HTTPS頁面性能優(yōu)化的方法。
1、HTTPS 性能損耗
HTTPS的優(yōu)勢在于進行完身份驗證耻陕、信息加密與完整性校驗等操作后拙徽，可以不對 TCP 和 HTTP 協(xié)議做任何修改。但通過增加新協(xié)議以實現(xiàn)更安全的通信必然需要付出代價诗宣，HTTPS 協(xié)議的性能損耗主要體現(xiàn)如下：
（1）增加延時
分析前面的握手過程膘怕，一次完整的握手至少需要兩端依次來回兩次通信，至少增加延時2?RTT召庞，利用會話緩存從而復用連接岛心，延時也至少1?RTT*。
（2）消耗較多的 CPU 資源
除數(shù)據(jù)傳輸之外篮灼，HTTPS 通信主要包括對對稱加解密忘古、非對稱加解密(服務器主要采用私鑰解密數(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è)務服務器維持長連接伦腐、會話復用和鏈路質量優(yōu)化等可控方法，極大減少 HTTPS 帶來的延時失都。
（2）會話緩存
雖然前文提到 HTTPS 即使采用會話緩存也要至少1*RTT的延時柏蘑，但是至少延時已經(jīng)減少為原來的一半，明顯的延時優(yōu)化粹庞；同時咳焚，基于會話緩存建立的 HTTPS 連接不需要服務器使用RSA私鑰解密獲取 Pre-master 信息，可以省去CPU 的消耗庞溜。如果業(yè)務訪問連接集中革半，緩存命中率高，則HTTPS的接入能力講明顯提升。當前 TRP 平臺的緩存命中率高峰時期大于30%又官，10k/s的接入資源實際可以承載13k/的接入延刘，收效非常可觀六敬。
（3）硬件加速
為接入服務器安裝專用的 SSL 硬件加速卡碘赖，作用類似 GPU，釋放 CPU外构，能夠具有更高的 HTTPS 接入能力且不影響業(yè)務程序的普泡。測試某硬件加速卡單卡可以提供 35k 的解密能力，相當于175核 CPU审编，至少相當于7臺24核的服務器劫哼，考慮到接入服務器其它程序的開銷，一張硬件卡可以實現(xiàn)接近10臺服務器的接入能力割笙。
（4）遠程解密
本地接入消耗過多的 CPU 資源，浪費了網(wǎng)卡和硬盤等資源眯亦，考慮將最消耗 CPU 資源的RSA解密計算任務轉移到其它服務器伤溉，如此則可以充分發(fā)揮服務器的接入能力，充分利用帶寬與網(wǎng)卡資源妻率。遠程解密服務器可以選擇 CPU 負載較低的機器充當乱顾，實現(xiàn)機器資源復用，也可以是專門優(yōu)化的高計算性能的服務器宫静。當前也是 CDN 用于大規(guī)模HTTPS接入的解決方案之一走净。
（5）SPDY/HTTP2
前面的方法分別從減少傳輸延時和單機負載的方法提高 HTTPS 接入性能，但是方法都基于不改變 HTTP 協(xié)議的基礎上提出的優(yōu)化方法孤里，SPDY/HTTP2 利用 TLS/SSL 帶來的優(yōu)勢伏伯，通過修改協(xié)議的方法來提升 HTTPS 的性能，提高下載速度等捌袜。
騰訊WeTest服務器性能測試運用了沉淀十多年的內部實踐經(jīng)驗總結说搅，通過基于真實業(yè)務場景和用戶行為進行壓力測試，幫助游戲開發(fā)者發(fā)現(xiàn)服務器端的性能瓶頸虏等，進行針對性的性能調優(yōu)弄唧，降低服務器采購和維護成本，提高用戶留存和轉化率霍衫。
功能目前免費對外開放中候引，歡迎大家的體驗
體驗地址：http://WeTest.qq.com/gaps/
如果對使用當中有任何疑問，歡迎聯(lián)系騰訊WeTest企業(yè)qq：800024531
