腾讯视频 WEB 站点 HTTPS 改造：总结篇
时间：2023-07-14 00:03:01 | 来源：网站运营
时间：2023-07-14 00:03:01 来源：网站运营
腾讯视频 WEB 站点 HTTPS 改造：总结篇：作者：朱宁 腾讯高级工程师
一、改造背景
业务运营中经常碰到劫持问题，许多网站选择支持 HTTPS 以应对。像百度、淘宝、Qzone 均已支持 HTTPS，而微信、Apple 也在推广 HTTPS，HTTPS 正在成为一种趋势。
今年 6 月份我们启动了腾讯视频 V 站( 腾讯视频-中国领先的在线视频媒体平台,海量高清视频在线观看 ) 的 HTTPS 改造，由于历史原因，V 站改造涉及了 50 多个 CGI 域名、10 多个静态资源域名；而牵扯的人员也十分广，视频相关的很多前端/后台开发、运维/运营以及 CDN/TRP、STGW、企业 IT 部等相关同学均参与其中。
二、改造范围
据不完全统计，
http://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 还低
测试结果：
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）
四、改造内容
1. 解决性能问题
HTTPS 虽然让信息传输变得更加安全，但同时会带来巨大的性能损耗，使得用户体验变得比较差，这也是一直制约着 HTTPS 普及的重要原因之一。我们主要从 优化单个 HTTPS 连接性能、减少 HTTPS 连接数量 两方面进行优化。
1 ) 优化单个 HTTPS 连接性能
http://v.qq.com 比较极端情况下的 HTTPS 请求如图所示：(有的访问可能还会多一个步骤②)
相对于 HTTP 来说，很可能会额外增加②到⑧的开销。而其中完全握手阶段的性能消耗占 HTTPS 整体性能消耗的 90%以上，所以这块也是需要重点优化的地方，我们使用的是 CDN/STGW 提供的优化方案。
会话复用策略通过对已经建立 TLS 会话的合理复用，不需要进行非对称密钥交换计算减少了 CPU 消耗，同时不需要进行完全握手阶段二⑧，节省一个 RTT 和计算耗时，可大幅提高服务器的 TLS 性能。
CDN/STGW 对于 session ID 和 session ticket 两种会话复用机制均支持，默认使用的是 session ticket。session ticket 占用服务器资源很少，支持多机间分布式缓存；但需要服务器和客户端都支持。
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 的兼容性：Can I use... Support tables for HTML5, CSS3, etc
对于素材 css、js 文件，文件比较小但是请求的数量很多，通过 nginx 的 combo 请求合并功能，前端同学将多个素材资源请求合并成单个请求，可以有效的减少页面中的 HTTPS 请求数量。
2. 模块化接入管理
由于涉及改造的域名众多，牵扯的业务范围、人员很广，为避免各个域名改造规范不统一，同时保障改造进度，我们将域名按业务功能进行分类，通过对其中的一个搜索功能模块进行规范化改造，然后复制到其他模块，进而推动多个模块同时进行规范化改造。
接入平台：新业务接入 CDN 或者 STGW
证书策略：通配符域名证书 各个模块的多域名证书
之所以使用通配符域名 多域名证书的管理方式，是因为全部加入通配符证书中维护成本很高，而且新增域名时可能会影响到其他域名，证书拆分可以同时兼顾了域名申请的时间、费用成本且可以缩小证书变更对业务的影响范围。
通配符证书可以匹配的域名包括
. http://video.qq.com 、 .
http://v.qq.com、*.
http://tv.qq.com。通配符证书可覆盖核心功能改造中的 30 多个域名。新申请的腾讯视频业务域名需使用通配符证书。
3.监控排错
目前的监控主要包括页面测速、域名失败率/性能监控，以及 CDN/STGW 的证书监控。
- 证书监控
目前依赖于 CDN、STGW 的证书监控，由于该监控只针对其平台的机器，如果业务混合部署在 CDN、STGW、TRP 甚至自有的机器上，则可能存在监控覆盖不全的情况，因此我们也在规划基于域名的证书一致性、过期监控。
- 页面测速监控
前端开发同学在页面中设置监控点，将数据上报到 ITIL 平台
http://v.qq.com 的数据上报共包括 5 个点：
- dns 耗时(对应 ITIL 的首屏)：domainLookupEnd-domainLookupStart
- 请求耗时(对应 ITIL 的整页)：responseStart-requestStart
- 返回内容下载耗时(对应 ITIL 的 3)：responseEnd-responseStart
- 首屏加载耗时(对应 ITIL 的 4)：从建立连接开始到浏览器渲染好首屏（播放器 视频标题）
- 整页耗时(对应 ITIL 的 5)：从建立连接开始到播放器抛出 oninited
ITIL 效果如下图：
前端开发同学将
http://v.qq.com 调用各个 CGI 接口的返回信息抽样上报到 BOSS 数据平台。
http://v.qq.com 的数据上报属性如下：
啄木鸟工具是我们基于华佗定制化的一个故障定位工具。主要为 OMG 业务提供一套简单、高效的 HTTP/HTTPS 协议类服务异常问题的分析和诊断方案，这些解决方案包括 HTTP/HTTPS 服务异常情况下的网络连接、请求调度、服务端会话日志信息收集等问题，从而协助业务快速缩小问题范围，协助排查业务问题。
结语：经过大半年的改造，
http://v.qq.com 的核心功能已经基本支持 HTTPS 了，我们终究还是踏出了这一小步，但我们离全站 HTTPS 的路还很长。值得欣慰的是 HTTPS 也并非传说中的那么笨重，通过适当优化，它也一样可以变得很轻快。
推荐阅读：鹅厂上万节点大规模集群的跨城自动迁移（上） - 腾云阁 - 腾讯云
微服务架构: 微服务架构的核心概念 ( 一 )
日志易：金融支付行业日志大数据分析案例解读 - 腾云阁 - 腾讯云
海云捷迅的教育云实战经验分享 - 腾云阁 - 腾讯云
在线咨询
