首页 > 网站建设 >

网页制作HTTPS与网站后期宣传推广之间的关系有多重要?

发布时间:2017-09-12 作者:博纳网络

网站制作众所周知,数据 HTTP 明文传输过程中,会遇到如劫持、篡改、监听、窃取等一系列问题,解决这一问题的方法就是做 HTTPS 改造。

 

HTTPS 的作用是在会话层、表示层引入 TLS/SSL 握手协议,通过数据加密、解密方式,来应对数据明文传输过程中遇到的问题,保障数据的完整性、一致性,为用户带来更安全的网络体验、更好的隐私保护。

然而,HTTPS 增加了 TLS/SSL 握手环节,再加上应用数据传输需要经过对称加密,对性能提出了更大的挑战。

作为一个好的架构,一定要均衡安全和性能两方面,如果让天秤向任何一方倾斜过多,都会影响最终的用户体验。

因此,为了兼顾安全与性能,苏宁的全站 HTTPS 改造从 2015 年底开始进行,历时一年多时间,主要做了系统 HTTPS 改造、HTTPS 性能优化和 HTTPS 灰度上线这三方面工作,让用户在 HTTPS 下访问能够获得极致体验成为了可能。

网页制作全站 HTTPS 方案概述

苏宁易购从 2015 年开始规划做 HTTPS 相关的事情,当时可借鉴的资料非常少,电商类网站相关的 HTTPS 改造的详尽案例更是难求。

如下图,是苏宁易购全站的 HTTPS 方案:

如图中所示,整个方案分三步构建,分别是系统改造、性能优化和灰度上线:

  • 系统改造。原有系统想要支持 HTTPS,必须进行改造,首先要建立 HTTPS 接入层,也就是开通 443 端口,让所有的应用系统支持 HTTPS 访问。

    在此基础上做页面资源替换,解决当一个 HTTPS 页面出现 HTTP 请求时就会出现错误的问题。做完这两件事,CDN 上证书的处理、HTTPS 测试方案等问题也就迎刃而解。

  • 性能优化。做系统改造,增加两次 TLS 握手,必然会对性能造成一定的开销和损失,如何去弥补性能的损失,达到性能和安全兼顾呢?性能优化部分包含若干优化点,下文会详细展开。

  • 灰度上线。这部分是时间花费最多的,HTTPS 一步步上线的过程中,踩坑最多,其中部分是前面没有发现的问题。

    这证明不能一次性将整个全站、全地区、全用户一次性堆成 HTTPS,可以根据流量所处的运营商和城市及用户级别去做灰度上线。

网页制作HTTPS 方案之系统改造篇

01、网站建设HTTPS 接入层定义

系统改造的头等大事是开通 443 端口,成熟的网络系统会包含 CDN、硬件负载均衡、应用防火墙、Web 服务器、应用服务器,最后到数据层。难道整个链路都要做 HTTPS?在每层都增加 SSL 握手消耗吗?答案是否定的。

所以,应该尽早完成 SSL 握手,做 SSL 过程中首要考虑的是 HTTPS 接入层的定位。

如下图,是苏宁易购架构中 HTTPS 接入层的位置:

如图中所示,我们把 HTTPS 接入层放在 CDN 和应用系统之间,采用四层+七层负载均衡的架构。

四层负载并不处理 HTTPS 卸载,它的主要职责是做 TCP 的分发。在七层负载完成整个 SSL 握手,而后面应用系统走 80 端口,这样就相当于完成了 HTTPS 整个卸载的过程。

这样做的好处,一方面,系统应用层面不需要为 HTTPS 做任何调整;另一方面,将来所有 HTTPS 的调度、优化和配置都可以在接入层完成。

02、网站制作页面资源替换

第一步,理解 Mixed Content

对于一个页面而言,请求页面的请求是用 HTTPS 加载,一旦内部页面元素有 HTTP 的性质,这时 RFC 标准里就会出现一个错误,叫 Mixed Content(混淆错误)。

所以,如果要加载一个安全的 HTTPS 页面,就不应该在其中混淆 HTTP 请求。

第二步,网站建设技巧之// 替换 http://

用 // 替换 http://,这样就可以让页面所有的元素做一个适配,去遵循原来的请求。

第三步,网页制作技巧之x-request-url 的定义和使用

当然,我们在//替换过程中也遇到了一些坑。举个例子,下图是苏宁易购单点登录系统交互的过程:

如图中所示,当用户 authID 失效,发起请求 https://xxx.suning.com/authStatus 鉴权,接入层会对所有请求做卸载,地址就会变成 HTTP。

进入业务系统做鉴权的话,Reponse 302 就会跳转到单点登录系统。这时会将第二步的页面记录为原始页面,返回到用户端,用户去请求单点登录系统,单点登录系统完成鉴权以后,再回跳时,是 HTTP 地址,最终导致用户端 MixContent。

因此,我们引入 x-request-url 解决问题,如下图:

所有原始请求协议都记录在 x-request-url 中,如果业务系统鉴权,一定要遵循 x-request-url 记录的协议,就可应对回跳导致的用户端 Mix Content 问题。

03、App 原生开发之无法识别//的问题

出现浏览器可以识别 //,但 App 原生无法识别 // 的原因很简单,因为浏览器本身做了适配。

当时,苏宁服务端有一个系统,专门提供一个接口,向各个端提供图片。做完 HTTPS 改造之后,PC 端和客户端都没有问题。但是第二天,很多用户突然就不能加载图片,原因是请求在 APP 原生情况下没法识别 //。

这里的解决方法,只能是客户端开发人员做适配,下图是 App 无法识别//的一个例子:

04、网站制作技巧之如何处理商用 CDN 上的证书和私钥?

CPN 证书的处理是大多数小型互联网企业都会遇到的问题。因为这些小企业不像阿里、京东可自建 CDN,苏宁也是一样。

苏宁的 CDN 由自建和商用两种组成,一旦使用商用 CDN,就会面临 HTTPS 如何过去的问题。

企业只要将私钥给到第三方或厂商之后,在所有厂商的 CDN 服务器都没办法控制。当有黑客攻击完厂商服务器后,加密已没任何意义,因为私钥已经泄露。

如下图,业界比较公认的应对方式分别是:双证书的策略、四层加速和 Keyless 解决方案。

  • 双证书的策略。它的思想很简单,相当于用户到 CDN 端,提供的是 CDN 的证书,做加解密。从 CDN 到应用服务器端用的是应用自有的证书来做加解密。

    这样的方式,可以保证应用端的密钥不用提供给 CDN 厂商,但根本的问题还是没有解决,那就是 CDN 厂商的证书仍然有泄露的可能。如果泄露了,用户端还是会受到影响。

  • 四层加速。很多 CDN 厂商都有能力提供 TCP 加速,做动态、还原和择优等。CDN 厂商只做四层模式和 TCP 代理,不考虑请求缓存。

    这样就没必要将证书暴露给 CDN 厂商,这种方式适用于动态回源请求,比如加入购物车、提交订单、登录等。

  • Keyless 解决方案。适用于金融,提供一台实时计算的 Key Server 。

当 CDN 要用到私钥时,通过加密通道将必要的参数传给 Key Server,由 Key Server 算出结果并返回即可。

05、网页制作技巧之HTTPS 测试策略

当引入一个新的协议,如何进行测试呢?主要步骤,如下图:

  • 源码扫描。当开发人员完成资源替换后,利用 Jenkins 遍历代码库,shell 脚本扫描出 HTTP 链接。

  • 对页面爬虫扫描。我们会写一些爬虫脚本,对测试环境的链接进行扫描。

  • 测试环境验证。自动化测试固然好,但是主要核心流程还是需要手动覆盖一遍,防止 HTTPS 对页面加载出现未知影响。

    如有些页面是用 HTTPS 去访问,可能这个系统还不支持 HTTPS,必须要手动验证。

  • 线上预发和引流测试。HTTPS 的改造版本发到线上对用户来讲是没有影响的,因为用户使用的还是 HTTP 流量。

    可以选择线上预发的方式,预发验证完毕后,通过 301 的方式,将用户的流量从 HTTP 切到 HTTPS,这个后面讲灰度时还会深入讲解。

另外,我们还引入了引流测试系统:

它的思路很简单,根据域名、用户请求做捕获,将所有捕获流量放到 Copy Server 中去扩大,放大若干倍,然后通过 Sender 再发送回到系统中。

这样的方式,可以通过用户的真实流量,来验证 HTTPS 的功能性和性能影响有多大。(全文未完详见下篇)深圳网站建设博纳网络编辑整理。

文章标题:网页制作HTTPS与网站后期宣传推广之间的关系有多重要?
本文地址:https://www.198bona.com/news/765.html
如果您觉得案例还不错请帮忙分享:

网站建设

网络推广

解决方案

域名主机

建站行业资讯