业务运营中经常碰到劫持问题,许多网站选择支持 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 入口均已切换完成,防劫持效果比较明显,但性能损耗不明显,整体表现符合预期。
防劫持效果比较明显,劫持数量从灰度前的约 600W/天降至约 30W/天(截止 2017 年 4 月: 约 13W/天)
HTTPS 和 HTTP 的耗时区别不大,性能损耗不明显
V 站整页耗时分布图(ITIL 测速): HTTP、HTTPS 耗时分布区间基本相同
V 站整页耗时趋势图(ITIL 测速):HTTP、HTTPS 的耗时区别不大
多次抽样测试发现 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)
HTTPS 虽然让信息传输变得更加安全,但同时会带来巨大的性能损耗,使得用户体验变得比较差,这也是一直制约着 HTTPS 普及的重要原因之一。我们主要从 优化单个 HTTPS 连接性能、减少 HTTPS 连接数量两方面进行优化。
1 ) 优化单个 HTTPS 连接性能
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 跳转:
基于快速回退考虑,我们目前是在服务器端做 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 请求数量。
由于涉及改造的域名众多,牵扯的业务范围、人员很广,为避免各个域名改造规范不统一,同时保障改造进度,我们将域名按业务功能进行分类,通过对其中的一个搜索功能模块进行规范化改造,然后复制到其他模块,进而推动多个模块同时进行规范化改造。
接入平台:新业务接入 CDN 或者 STGW
证书策略:通配符域名证书 各个模块的多域名证书
之所以使用通配符域名 多域名证书的管理方式,是因为全部加入通配符证书中维护成本很高,而且新增域名时可能会影响到其他域名,证书拆分可以同时兼顾了域名申请的时间、费用成本且可以缩小证书变更对业务的影响范围。
通配符证书可以匹配的域名包括 . video.qq.com 、 .v.qq.com、*.tv.qq.com。通配符证书可覆盖核心功能改造中的 30 多个域名。新申请的腾讯视频业务域名需使用通配符证书。
目前的监控主要包括页面测速、域名失败率/性能监控,以及 CDN/STGW 的证书监控。
前端开发同学在页面中设置监控点,将数据上报到 ITIL 平台
v.qq.com 的数据上报共包括 5 个点:
ITIL 效果如下图:
前端开发同学将 v.qq.com 调用各个 CGI 接口的返回信息抽样上报到 BOSS 数据平台。v.qq.com 的数据上报属性如下:
数据经过处理后的部分彩虹报表监控视图如下:
注:原始的 BOSS 报表可能不符合业务需求,此监控报表是将原始数据处理入库后,使用彩虹报表重新开发
啄木鸟工具是我们基于华佗定制化的一个故障定位工具。主要为 OMG 业务提供一套简单、高效的 HTTP/HTTPS 协议类服务异常问题的分析和诊断方案,这些解决方案包括 HTTP/HTTPS 服务异常情况下的网络连接、请求调度、服务端会话日志信息收集等问题,从而协助业务快速缩小问题范围,协助排查业务问题。
结语:经过大半年的改造,v.qq.com 的核心功能已经基本支持 HTTPS 了,我们终究还是踏出了这一小步,但我们离全站 HTTPS 的路还很长。值得欣慰的是 HTTPS 也并非传说中的那么笨重,通过适当优化,它也一样可以变得很轻快。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
扫码关注腾讯云开发者
领取腾讯云代金券
Copyright © 2013 - 2025 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号:粤B2-20090059 深公网安备号 44030502008569
腾讯云计算(北京)有限责任公司 京ICP证150476号 | 京ICP备11018762号 | 京公网安备号11010802020287
Copyright © 2013 - 2025 Tencent Cloud.
All Rights Reserved. 腾讯云 版权所有