騰訊視頻 WEB 站點(diǎn) HTTPS 改造：總結(jié)篇
時(shí)間：2023-07-14 00:03:01 | 來源：網(wǎng)站運(yùn)營
時(shí)間：2023-07-14 00:03:01 來源：網(wǎng)站運(yùn)營
騰訊視頻 WEB 站點(diǎn) HTTPS 改造：總結(jié)篇：作者：朱寧 騰訊高級(jí)工程師
一、改造背景
業(yè)務(wù)運(yùn)營中經(jīng)常碰到劫持問題，許多網(wǎng)站選擇支持 HTTPS 以應(yīng)對(duì)。像百度、淘寶、Qzone 均已支持 HTTPS，而微信、Apple 也在推廣 HTTPS，HTTPS 正在成為一種趨勢(shì)。
今年 6 月份我們啟動(dòng)了騰訊視頻 V 站( 騰訊視頻-中國領(lǐng)先的在線視頻媒體平臺(tái),海量高清視頻在線觀看 ) 的 HTTPS 改造，由于歷史原因，V 站改造涉及了 50 多個(gè) CGI 域名、10 多個(gè)靜態(tài)資源域名；而牽扯的人員也十分廣，視頻相關(guān)的很多前端/后臺(tái)開發(fā)、運(yùn)維/運(yùn)營以及 CDN/TRP、STGW、企業(yè) IT 部等相關(guān)同學(xué)均參與其中。
二、改造范圍
據(jù)不完全統(tǒng)計(jì)，
http://v.qq.com 用到了 60 多個(gè)域名，而且流媒體業(yè)務(wù)使用的是 IP 調(diào)度，全站改造的成本非常高且時(shí)間不可控，所以我們第一期只針對(duì)播放頁、首頁、搜索頁、列表頁等核心功能進(jìn)行改造。這些功能覆蓋絕大部分用戶使用場(chǎng)景，整體占比約 60%--70%。
三、改造效果
目前，視頻 V 站的播放頁、首頁、搜索頁 HTTPS 入口均已切換完成，防劫持效果比較明顯，但性能損耗不明顯，整體表現(xiàn)符合預(yù)期。
1. 劫持?jǐn)?shù)量：
防劫持效果比較明顯，劫持?jǐn)?shù)量從灰度前的約 600W/天降至約 30W/天（截止 2017 年 4 月： 約 13W/天）
2.頁面測(cè)速：
HTTPS 和 HTTP 的耗時(shí)區(qū)別不大，性能損耗不明顯
V 站整頁耗時(shí)分布圖(ITIL 測(cè)速)： HTTP、HTTPS 耗時(shí)分布區(qū)間基本相同
V 站整頁耗時(shí)趨勢(shì)圖(ITIL 測(cè)速)：HTTP、HTTPS 的耗時(shí)區(qū)別不大
3. WebPageTest 測(cè)試耗時(shí)圖：
多次抽樣測(cè)試發(fā)現(xiàn) HTTPS 首次加載時(shí)間比 HTTP 還低
測(cè)試結(jié)果：
v.qq....ml?vid=j0021k931w0 - 10/24/16 08:44:43 (HTTPS Load Time: 8.911s)
v.qq....ml?vid=j0021k931w0 - 10/24/16 08:46:31 (HTTP Load Time: 10.477s）
四、改造內(nèi)容
1. 解決性能問題
HTTPS 雖然讓信息傳輸變得更加安全，但同時(shí)會(huì)帶來巨大的性能損耗，使得用戶體驗(yàn)變得比較差，這也是一直制約著 HTTPS 普及的重要原因之一。我們主要從 優(yōu)化單個(gè) HTTPS 連接性能、減少 HTTPS 連接數(shù)量 兩方面進(jìn)行優(yōu)化。
1 ) 優(yōu)化單個(gè) HTTPS 連接性能
http://v.qq.com 比較極端情況下的 HTTPS 請(qǐng)求如圖所示：(有的訪問可能還會(huì)多一個(gè)步驟②)
相對(duì)于 HTTP 來說，很可能會(huì)額外增加②到⑧的開銷。而其中完全握手階段的性能消耗占 HTTPS 整體性能消耗的 90%以上，所以這塊也是需要重點(diǎn)優(yōu)化的地方，我們使用的是 CDN/STGW 提供的優(yōu)化方案。
會(huì)話復(fù)用策略通過對(duì)已經(jīng)建立 TLS 會(huì)話的合理復(fù)用，不需要進(jìn)行非對(duì)稱密鑰交換計(jì)算減少了 CPU 消耗，同時(shí)不需要進(jìn)行完全握手階段二⑧，節(jié)省一個(gè) RTT 和計(jì)算耗時(shí)，可大幅提高服務(wù)器的 TLS 性能。
CDN/STGW 對(duì)于 session ID 和 session ticket 兩種會(huì)話復(fù)用機(jī)制均支持，默認(rèn)使用的是 session ticket。session ticket 占用服務(wù)器資源很少，支持多機(jī)間分布式緩存；但需要服務(wù)器和客戶端都支持。
- TLS 遠(yuǎn)程解密 + SSL 硬件加速
HTTPS 協(xié)議中最消耗 CPU 計(jì)算資源的就是非對(duì)稱密鑰交換的計(jì)算，通過對(duì) Nginx 源碼進(jìn)行改造，將最消耗 CPU 的加解密計(jì)算過程剝離出來，避免在本地 CPU 上進(jìn)行同步計(jì)算，而使用遠(yuǎn)程 SSL 硬件加速集群進(jìn)行異步計(jì)算。整個(gè)過程是異步的，上層應(yīng)用程序（Nginx）不需要等待 RSA 計(jì)算結(jié)果的返回就能接收其他請(qǐng)求。這也是 CDN/STGW 用于大規(guī)模 HTTPS 接入的 殺手锏 解決方案之一。
- HSTS、OCSP Stapling 等其他優(yōu)化 ( 暫未實(shí)施 )
除了這些性能提升明顯的核心優(yōu)化，我們后續(xù)也將考慮 HSTS、OCSP Stapling 等優(yōu)化。
HSTS 跳轉(zhuǎn)：
基于快速回退考慮，我們目前是在服務(wù)器端做 302 跳轉(zhuǎn)，跳轉(zhuǎn)到 HTTPS。但這個(gè) 302 跳轉(zhuǎn)存在兩個(gè)問題：使用不安全的 HTTP 協(xié)議進(jìn)行通信并且增加一個(gè) Round-Trip Time。
而 HSTS 是 HTTP Strict Transport Security 的縮寫，服務(wù)器端配置支持 HSTS 后，會(huì)在給瀏覽器返回的 HTTP Header 中攜帶 HSTS 字段，瀏覽器在獲取到該信息后，在接下來的一段時(shí)間內(nèi)，對(duì)該網(wǎng)站的所有 HTTP 訪問，瀏覽器都將請(qǐng)求在內(nèi)部做 307 跳轉(zhuǎn)到 HTTPS，而無需任何網(wǎng)絡(luò)過程。
OCSP Stapling：
在 HTTPS 通信過程時(shí)，瀏覽器會(huì)去驗(yàn)證服務(wù)器端下發(fā)的證書鏈?zhǔn)欠褚呀?jīng)被撤銷。驗(yàn)證的方法有兩種：CRL 和 OCSP。OCSP Stapling 是對(duì) OCSP 缺陷的彌補(bǔ)，服務(wù)器可事先模擬瀏覽器對(duì)證書鏈進(jìn)行驗(yàn)證，并將帶有 CA 機(jī)構(gòu)簽名的 OCSP 響應(yīng)保存到本地，然后在握手階段，將 OCSP 響應(yīng)和證書鏈一起下發(fā)給瀏覽器，省去瀏覽器的在線驗(yàn)證過程。
2 ） 減少 HTTPS 連接數(shù)量
除了使單個(gè) HTTPS 連接變得更快，HTTPS 請(qǐng)求數(shù)量方面也是不錯(cuò)的優(yōu)化點(diǎn)。
HTTP/2 是 IETF 基于 SPDY 開發(fā)的下一代 HTTP 協(xié)議。HTTPS 傳輸在增加 SSL 握手、加解密開銷時(shí)延后，HTTP/2 采用了二進(jìn)制分幀層、請(qǐng)求優(yōu)先級(jí)、鏈路復(fù)用、服務(wù)器推送、首部壓縮等技術(shù)來提升 HTTPS 的性能。
其中鏈路復(fù)用的方式能將多個(gè)請(qǐng)求在同一個(gè)連接上一起發(fā)出去，對(duì) HTTPS 通信效率提升明顯。鏈路復(fù)用配合域名收斂效果更加，理論上域名收斂越好，鏈路復(fù)用性能提升越明顯。使用 HTTP/2 需要特別注意頭部信息的變化，HTTP/2 的頭部使用小寫字母鍵值對(duì)的方式，和 HTTP/1.x 區(qū)別還是比較大。
我們目前接入 STGW 的 CGI 域名基本都開啟了 HTTP/2，后續(xù)也會(huì)對(duì) CDN 的靜態(tài)業(yè)務(wù)開啟 HTTP/2。CGI、靜態(tài)資源有進(jìn)行域名收斂，不過力度還不大，這也是我們后續(xù)性能優(yōu)化的重點(diǎn)。
瀏覽器對(duì) HTTP/2 的兼容性：Can I use... Support tables for HTML5, CSS3, etc
對(duì)于素材 css、js 文件，文件比較小但是請(qǐng)求的數(shù)量很多，通過 nginx 的 combo 請(qǐng)求合并功能，前端同學(xué)將多個(gè)素材資源請(qǐng)求合并成單個(gè)請(qǐng)求，可以有效的減少頁面中的 HTTPS 請(qǐng)求數(shù)量。
2. 模塊化接入管理
由于涉及改造的域名眾多，牽扯的業(yè)務(wù)范圍、人員很廣，為避免各個(gè)域名改造規(guī)范不統(tǒng)一，同時(shí)保障改造進(jìn)度，我們將域名按業(yè)務(wù)功能進(jìn)行分類，通過對(duì)其中的一個(gè)搜索功能模塊進(jìn)行規(guī)范化改造，然后復(fù)制到其他模塊，進(jìn)而推動(dòng)多個(gè)模塊同時(shí)進(jìn)行規(guī)范化改造。
接入平臺(tái)：新業(yè)務(wù)接入 CDN 或者 STGW
證書策略：通配符域名證書 各個(gè)模塊的多域名證書
之所以使用通配符域名 多域名證書的管理方式，是因?yàn)槿考尤胪ㄅ浞C書中維護(hù)成本很高，而且新增域名時(shí)可能會(huì)影響到其他域名，證書拆分可以同時(shí)兼顧了域名申請(qǐng)的時(shí)間、費(fèi)用成本且可以縮小證書變更對(duì)業(yè)務(wù)的影響范圍。
通配符證書可以匹配的域名包括
. http://video.qq.com 、 .
http://v.qq.com、*.
http://tv.qq.com。通配符證書可覆蓋核心功能改造中的 30 多個(gè)域名。新申請(qǐng)的騰訊視頻業(yè)務(wù)域名需使用通配符證書。
3.監(jiān)控排錯(cuò)
目前的監(jiān)控主要包括頁面測(cè)速、域名失敗率/性能監(jiān)控，以及 CDN/STGW 的證書監(jiān)控。
- 證書監(jiān)控
目前依賴于 CDN、STGW 的證書監(jiān)控，由于該監(jiān)控只針對(duì)其平臺(tái)的機(jī)器，如果業(yè)務(wù)混合部署在 CDN、STGW、TRP 甚至自有的機(jī)器上，則可能存在監(jiān)控覆蓋不全的情況，因此我們也在規(guī)劃基于域名的證書一致性、過期監(jiān)控。
- 頁面測(cè)速監(jiān)控
前端開發(fā)同學(xué)在頁面中設(shè)置監(jiān)控點(diǎn)，將數(shù)據(jù)上報(bào)到 ITIL 平臺(tái)
http://v.qq.com 的數(shù)據(jù)上報(bào)共包括 5 個(gè)點(diǎn)：
- dns 耗時(shí)(對(duì)應(yīng) ITIL 的首屏)：domainLookupEnd-domainLookupStart
- 請(qǐng)求耗時(shí)(對(duì)應(yīng) ITIL 的整頁)：responseStart-requestStart
- 返回內(nèi)容下載耗時(shí)(對(duì)應(yīng) ITIL 的 3)：responseEnd-responseStart
- 首屏加載耗時(shí)(對(duì)應(yīng) ITIL 的 4)：從建立連接開始到瀏覽器渲染好首屏（播放器 視頻標(biāo)題）
- 整頁耗時(shí)(對(duì)應(yīng) ITIL 的 5)：從建立連接開始到播放器拋出 oninited
ITIL 效果如下圖：
前端開發(fā)同學(xué)將
http://v.qq.com 調(diào)用各個(gè) CGI 接口的返回信息抽樣上報(bào)到 BOSS 數(shù)據(jù)平臺(tái)。
http://v.qq.com 的數(shù)據(jù)上報(bào)屬性如下：
啄木鳥工具是我們基于華佗定制化的一個(gè)故障定位工具。主要為 OMG 業(yè)務(wù)提供一套簡單、高效的 HTTP/HTTPS 協(xié)議類服務(wù)異常問題的分析和診斷方案，這些解決方案包括 HTTP/HTTPS 服務(wù)異常情況下的網(wǎng)絡(luò)連接、請(qǐng)求調(diào)度、服務(wù)端會(huì)話日志信息收集等問題，從而協(xié)助業(yè)務(wù)快速縮小問題范圍，協(xié)助排查業(yè)務(wù)問題。
結(jié)語：經(jīng)過大半年的改造，
http://v.qq.com 的核心功能已經(jīng)基本支持 HTTPS 了，我們終究還是踏出了這一小步，但我們離全站 HTTPS 的路還很長。值得欣慰的是 HTTPS 也并非傳說中的那么笨重，通過適當(dāng)優(yōu)化，它也一樣可以變得很輕快。
推薦閱讀：鵝廠上萬節(jié)點(diǎn)大規(guī)模集群的跨城自動(dòng)遷移（上） - 騰云閣 - 騰訊云
微服務(wù)架構(gòu): 微服務(wù)架構(gòu)的核心概念 ( 一 )
日志易：金融支付行業(yè)日志大數(shù)據(jù)分析案例解讀 - 騰云閣 - 騰訊云
海云捷迅的教育云實(shí)戰(zhàn)經(jīng)驗(yàn)分享 - 騰云閣 - 騰訊云
在線咨詢