腾讯视频 WEB 站点 HTTPS 改造:总结篇

更多腾讯海量技术文章,请关注云加社区:https://cloud.tencent.com/developer

作者:朱宁

一、改造背景

业务运营中经常碰到劫持问题,许多网站选择支持 HTTPS 以应对。像百度、淘宝、Qzone 均已支持 HTTPS,而微信、Apple 也在推广 HTTPS,HTTPS 正在成为一种趋势。

2016年 6 月份我们启动了腾讯视频 V 站( http://v.qq.com ) 的 HTTPS 改造,由于历史原因,V 站改造涉及了 50 多个 CGI 域名、10 多个静态资源域名;而牵扯的人员也十分广,视频相关的很多前端/后台开发、运维/运营以及 CDN/TRP、STGW、企业 IT 部等相关同学均参与其中。

二、改造范围

据不完全统计,v.qq.com 用到了 60 多个域名,而且流媒体业务使用的是 IP 调度,全站改造的成本非常高且时间不可控,所以我们第一期只针对播放页、首页、搜索页、列表页等核心功能进行改造。这些功能覆盖绝大部分用户使用场景,整体占比约 60%--70%。

三、改造效果

目前,视频 V 站的播放页、首页、搜索页 HTTPS 入口均已切换完成,防劫持效果比较明显,但性能损耗不明显,整体表现符合预期。

1. 劫持数量:

防劫持效果比较明显,劫持数量从灰度前的约 600W/天降至约 30W/天(截止 2017 年 4 月: 约 13W/天)

2.页面测速:

HTTPS 和 HTTP 的耗时区别不大,性能损耗不明显

V 站整页耗时分布图(ITIL 测速): HTTP、HTTPS 耗时分布区间基本相同

V 站整页耗时趋势图(ITIL 测速):HTTP、HTTPS 的耗时区别不大

3. WebPageTest 测试耗时图:

多次抽样测试发现 HTTPS 首次加载时间比 HTTP 还低

测试结果:

https://www.webpagetest.org/result/161024_KZ_DCC/ (HTTPS Load Time: 8.911s)

https://www.webpagetest.org/result/161024_P2_DCF/ (HTTP Load Time: 10.477s)

四、改造内容

1. 解决性能问题

HTTPS 虽然让信息传输变得更加安全,但同时会带来巨大的性能损耗,使得用户体验变得比较差,这也是一直制约着 HTTPS 普及的重要原因之一。我们主要从 优化单个 HTTPS 连接性能、减少 HTTPS 连接数量两方面进行优化。

1 ) 优化单个 HTTPS 连接性能

v.qq.com 比较极端情况下的 HTTPS 请求如图所示:(有的访问可能还会多一个步骤)

相对于 HTTP 来说,很可能会额外增加到的开销。而其中完全握手阶段的性能消耗占 HTTPS 整体性能消耗的 90%以上,所以这块也是需要重点优化的地方,我们使用的是 CDN/STGW 提供的优化方案。

Session 会话复用策略

会话复用策略通过对已经建立 TLS 会话的合理复用,不需要进行非对称密钥交换计算减少了 CPU 消耗,同时不需要进行完全握手阶段二,节省一个 RTT 和计算耗时,可大幅提高服务器的 TLS 性能。

CDN/STGW 对于 session ID 和 session ticket 两种会话复用机制均支持,默认使用的是 session ticket。session ticket 占用服务器资源很少,支持多机间分布式缓存;但需要服务器和客户端都支持。

TLS 远程解密 + SSL 硬件加速

HTTPS 协议中最消耗 CPU 计算资源的就是非对称密钥交换的计算,通过对 Nginx 源码进行改造,将最消耗 CPU 的加解密计算过程剥离出来,避免在本地 CPU 上进行同步计算,而使用远程 SSL 硬件加速集群进行异步计算。整个过程是异步的,上层应用程序(Nginx)不需要等待 RSA 计算结果的返回就能接收其他请求。这也是 CDN/STGW 用于大规模 HTTPS 接入的

杀手锏

解决方案之一。

HSTS、OCSP Stapling 等其他优化 ( 暂未实施 )

除了这些性能提升明显的核心优化,我们后续也将考虑 HSTS、OCSP Stapling 等优化。

HSTS 跳转:

基于快速回退考虑,我们目前是在服务器端做 302 跳转,跳转到 HTTPS。但这个 302 跳转存在两个问题:使用不安全的 HTTP 协议进行通信并且增加一个 Round-Trip Time。

而 HSTS 是 HTTP Strict Transport Security 的缩写,服务器端配置支持 HSTS 后,会在给浏览器返回的 HTTP Header 中携带 HSTS 字段,浏览器在获取到该信息后,在接下来的一段时间内,对该网站的所有 HTTP 访问,浏览器都将请求在内部做 307 跳转到 HTTPS,而无需任何网络过程。

OCSP Stapling:

在 HTTPS 通信过程时,浏览器会去验证服务器端下发的证书链是否已经被撤销。验证的方法有两种:CRL 和 OCSP。OCSP Stapling 是对 OCSP 缺陷的弥补,服务器可事先模拟浏览器对证书链进行验证,并将带有 CA 机构签名的 OCSP 响应保存到本地,然后在握手阶段,将 OCSP 响应和证书链一起下发给浏览器,省去浏览器的在线验证过程。

2 ) 减少 HTTPS 连接数量

除了使单个 HTTPS 连接变得更快,HTTPS 请求数量方面也是不错的优化点。

链路复用

HTTP/2 是 IETF 基于 SPDY 开发的下一代 HTTP 协议。HTTPS 传输在增加 SSL 握手、加解密开销时延后,HTTP/2 采用了二进制分帧层、请求优先级、链路复用、服务器推送、首部压缩等技术来提升 HTTPS 的性能。

其中链路复用的方式能将多个请求在同一个连接上一起发出去,对 HTTPS 通信效率提升明显。链路复用配合域名收敛效果更加,理论上域名收敛越好,链路复用性能提升越明显。使用 HTTP/2 需要特别注意头部信息的变化,HTTP/2 的头部使用小写字母键值对的方式,和 HTTP/1.x 区别还是比较大。

我们目前接入 STGW 的 CGI 域名基本都开启了 HTTP/2,后续也会对 CDN 的静态业务开启 HTTP/2。CGI、静态资源有进行域名收敛,不过力度还不大,这也是我们后续性能优化的重点。

浏览器对 HTTP/2 的兼容性:http://caniuse.com/#search=spdy

请求合并

对于素材 css、js 文件,文件比较小但是请求的数量很多,通过 nginx 的 combo 请求合并功能,前端同学将多个素材资源请求合并成单个请求,可以有效的减少页面中的 HTTPS 请求数量。

2. 模块化接入管理

由于涉及改造的域名众多,牵扯的业务范围、人员很广,为避免各个域名改造规范不统一,同时保障改造进度,我们将域名按业务功能进行分类,通过对其中的一个搜索功能模块进行规范化改造,然后复制到其他模块,进而推动多个模块同时进行规范化改造。

接入平台:新业务接入 CDN 或者 STGW

证书策略:通配符域名证书 各个模块的多域名证书

之所以使用通配符域名 多域名证书的管理方式,是因为全部加入通配符证书中维护成本很高,而且新增域名时可能会影响到其他域名,证书拆分可以同时兼顾了域名申请的时间、费用成本且可以缩小证书变更对业务的影响范围。

通配符证书可以匹配的域名包括 . video.qq.com 、 .v.qq.com、*.tv.qq.com。通配符证书可覆盖核心功能改造中的 30 多个域名。新申请的腾讯视频业务域名需使用通配符证书。

3.监控排错

目前的监控主要包括页面测速、域名失败率/性能监控,以及 CDN/STGW 的证书监控。

证书监控

目前依赖于 CDN、STGW 的证书监控,由于该监控只针对其平台的机器,如果业务混合部署在 CDN、STGW、TRP 甚至自有的机器上,则可能存在监控覆盖不全的情况,因此我们也在规划基于域名的证书一致性、过期监控。

页面测速监控

前端开发同学在页面中设置监控点,将数据上报到 ITIL 平台

v.qq.com 的数据上报共包括 5 个点:

dns 耗时(对应 ITIL 的首屏):domainLookupEnd-domainLookupStart

请求耗时(对应 ITIL 的整页):responseStart-requestStart

返回内容下载耗时(对应 ITIL 的 3):responseEnd-responseStart

首屏加载耗时(对应 ITIL 的 4):从建立连接开始到浏览器渲染好首屏(播放器 视频标题)

整页耗时(对应 ITIL 的 5):从建立连接开始到播放器抛出 oninited

ITIL 效果如下图:

域名错误率/性能监控

前端开发同学将 v.qq.com 调用各个 CGI 接口的返回信息抽样上报到 BOSS 数据平台。v.qq.com 的数据上报属性如下:

数据经过处理后的部分彩虹报表监控视图如下:

注:原始的 BOSS 报表可能不符合业务需求,此监控报表是将原始数据处理入库后,使用彩虹报表重新开发

啄木鸟定位工具

啄木鸟工具是我们基于华佗定制化的一个故障定位工具。主要为 OMG 业务提供一套简单、高效的 HTTP/HTTPS 协议类服务异常问题的分析和诊断方案,这些解决方案包括 HTTP/HTTPS 服务异常情况下的网络连接、请求调度、服务端会话日志信息收集等问题,从而协助业务快速缩小问题范围,协助排查业务问题。

结语:经过大半年的改造,v.qq.com 的核心功能已经基本支持 HTTPS 了,我们终究还是踏出了这一小步,但我们离全站 HTTPS 的路还很长。值得欣慰的是 HTTPS 也并非传说中的那么笨重,通过适当优化,它也一样可以变得很轻快。

  • 发表于:
  • 原文链接:http://kuaibao.qq.com/s/20180111A07Q1O00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券