阿里云云盾证书是什么？很多站长对于阿里云云盾证书比较陌生，但肯定都知道或者听说过SSL证书，其实阿里云云盾证书就是SSL证书。SSL证书是数字证书的一种，类似于驾驶证、护照和营业执照的电子副本。因为配置在服务器上，也称为SSL服务器证书。SSL 证书就是遵守 SSL协议，由受信任的数字证书颁发机构CA，在验证服务器身份后颁发，具有服务器身份验证和数据传输加密功能。 云盾证书有什么作用？SSL证书（SSL Certificates）为网站和移动应用（APP）提供HTTPS保护，对网站流量进行加密，防止数据被窃取。阿里云SSL证书一直致力于为企业提供更全面的网站安全能力及解决方案，目前已有数十万用户选择我们的证书进行网站HTTPS加密及网站安全的综合解决方案。要了解或者购买阿里云云盾证书，可以点击进入云盾证书详情介绍页面了解。 阿里云SSL证书（SSL Certificates）由阿里云联合中国及中国以外地域多家数字证书管理和颁发的权威机构，在阿里云平台上直接提供的服务器数字证书，并且给您提供额外的一键式HTTPS、证书扩展服务和证书托管等增值服务，帮助您以最小的成本将您的服务从HTTP转换成HTTPS，实现网站或移动应用的身份验证和数据加密传输。 证书类型阿里云SSL证书提供DV证书、OV证书和EV证书三种类型。有关证书的选型案例请参见证书选型案例。 数字证书 适用网站类型 公信等级 认证强度 安全性DV SSL 个人网站 一般 CA机构审核个人网站真实性、不验证企业真实性 一般OV SSL 政府组织、企业、教育机构等 高 CA机构审核组织及企业真实性 高EV SSL 大型企业、金融机构等 最高 严格认证 最高（地址栏绿色） 功能特性功能模块 为您提供的价值 功能详情网站HTTPS化 防劫持、防篡改、防监听。 使用SSL证书可实现网站的HTTPS化，对网站用户与网站间的交互访问全链路数据进行加密，从而实现传输数据的防劫持、防篡改、防监听。 提升网站的搜索排名。 使用SSL证书实现HTTPS加密的网站在搜索引擎显示结果中的排名将会更高，有利于提升网站的搜索排名和站点的可信度。提升网站的访问流量。 使用SSL证书实现网站的HTTPS化，可以强化网站在用户侧的身份可信程度，使网站用户能更安心地访问网站，从而提升网站的访问流量。证书高效管理 提高证书运维效率。 提供上传证书和私钥功能，实现在阿里云平台统一管理各种数字证书、提交审核、查看证书绑定域名和到期时间、修改证书名称、删除已过期的证书等一站式服务，帮助您有效提高证书运维效率。 一键部署SSL证书到其他阿里云产品。 提供在阿里云平台上一键部署SSL证书到其他阿里云产品的功能，帮助您实现低成本部署SSL证书。具体请参见已签发证书部署到阿里云产品。证书便捷吊销。 按照标准的证书吊销流程，经过CA认证中心审核后，安全、快捷地吊销服务器SSL证书。具体请参见吊销证书。 提供的增值服务阿里云SSL证书除了为您提供SSL证书外，还为您提供一键HTTPS、证书扩展服务和证书托管的增值服务。 增值服务 为您提供的价值 详细介绍一键式HTTPS SSL证书支持一键式HTTPS服务，帮助您自动解决SSL证书安装部署、证书到期更新、证书私钥安全存储及TLS加速等问题，无需您进行手动操作，避免因证书安装和更新等复杂操作带来的问题。 证书扩展服务 阿里云提供的SSL证书扩展服务，新增了支持通过API调用的方式申请和签发证书，使您不再只能使用控制台进行证书申请和签发。同时，您还可以通过证书扩展服务一次性下单购买不限数量的SSL证书。 证书托管服务 证书托管服务可以帮助您自动延长证书的有效期，避免因证书更新不及时从而导致浏览器将您的网站识别为不安全的网站。 证书托管服务 支持的国家和地域阿里云SSL证书适用于以下国家和地域： 中国内地所有地域澳大利亚（悉尼）日本（东京）德国（法兰克福）阿联酋（迪拜）印度（孟买）

前言 Apple从2016年逐步要求HTTPS，SSL相关证书等，上月的JSPatch封杀更是引起广大开发者的注意，整体来说多是为了安全考虑，那么SSL证书是硬需，考虑到上一篇：HTTPS时代已来，老司机手把手指导申请免费SSL证书 介绍了阿里云的相关证书，为了不仅仅依赖一家证书，特此又研究了一下又拍云的SSL-TrustAsia证书申购申购地址，希望能帮助到你！ 第一步： 绑定域名并解析域名 创建服务-添加域名-解析域名 提示：记得选择全网加速服务，不要问为什么，因为它免费，也方便绑定域名与解析 提示1：解析的域名最好是备案好的，不然后期证书可能会导致失败，现在所有的国内域名都严格要求起来了，包括阿里云，万网，新网，主机屋等等等等，总之名不正言不顺，备案一下一劳永逸，这里我测试的是我已备案好的 提示2：添加过域名记得及时解析CNAME操作，不然可能影响后期证书，最近收到又拍云升级通知： 第二步： 证书申购（免费） 申购的是免费版的TrustAsia证书（苹果认证可放心使用） 第三步： 证书配置 选择TrustAsia证书，其他不用操作，接着下一步 第四步： 补全资料 填入第一步绑定的域名，由于第一步已解析域名证明了域名所有权，直接点击提交即可！ 第五部：审核结果查看 审核通过的如下： 温馨提示：又拍云免费SSL证书申购是通过第三方提交审核的，所以官网不受控制，甚至由于解析错误未能审核通过状态也不显示和邮件提醒，所以特此提醒开发者，正常审核周期是一个工作日，若你的申购一直处于待审核，原因可能有两点：1.解析域名时，顶级域名和带www的域名解析是要和又拍云保持一致的；2.未绑定解析域名，或者节假日延后，更多问题可以咨询官方客服。 第六步： 证书的管理 上一篇：HTTPS时代已来，老司机手把手指导申请免费SSL证书 更多：每周更新关注新浪微博！ 手机加iOS开发者交流QQ群： 446310206

大家都知道，HTTP 本身是明文传输的，没有经过任何安全处理，网站HTTPS解决方案通过在HTTP协议之上引入证书服务，完美解决网站的安全问题。本文将为大家介绍阿里云CDN HTTPS安全加速传输的基础概念、解决方案、技术优势和优化实践。 关于HTTPS的那些基本概念 需求推进技术革命，互联网是如此诞生，HTTPS也是这样。人们有在互联网上分享和浏览信息的需求，所以信息的传输技术由此诞生并不断升级。后来，人们位互联网上的信息传输制定了一些准则，也就是网络协议HTTP。从最早1991年发布的HTTP/0.9版本，直到最新的HTTP/2，传输速度也在不断升级。下面，我们来看下关于HTTP都有哪些基本的概念。 HTTP是什么?HTTP是互联网上应用最为广泛的一种网络协议，是一个客户端和服务器端请求和应答的标准（TCP），用于从WWW服务器传输超文本到本地浏览器的传输协议，它可以使浏览器更加高效，使网络传输减少。 HTTPS是什么?HTTPS是安全超文本传输协议，英文全称：Hyper Text Transfer Protocol over Secure Socket Layer，它是以安全为目标的HTTP通道，简单讲是HTTP的安全版。它的工作原理是将HTTP用SSL/TLS协议进行封装，主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。 SSL是什么？SSL是Secure Sockets Layer的缩写，它是一个安全套接层。架构于TCP之上的安全通讯协定，它可以有效协助Internet应用软件提升通讯时的资料完整性以及安全性。后来，标准化之后的SSL名称改为 TLS（是“Transport Layer Security”的缩写），中文叫做“传输层安全协议”。很多相关的文章都把这两者并列称呼（SSL/TLS），因为这两者可以视作同一个东西的不同阶段。 什么是握手？在加密传输之前，客户端和服务器首先必须建立连接和交换参数，校验通过之后进行协商密钥和传输数据，这个过程叫做握手（handshake）。 什么是加密和解密？“加密”的过程，就是把“明文”变成“密文”的过程；反之，“解密”的过程，就是把“密文”变为“明文”。在这两个过程中，都需要一个关键的东西——叫做“密钥”——来参与数学运算。 总结：简单来说，HTTPS就是HTTP的安全增强版本，是HTTP协议与SSL加密协议的结合，所以也被称为HTTP over SSL。 为什么要使用HTTPS HTTPS概念其实已经提出来好多年了，但直到近两年，才开始被主流应用。所以，我们在给大家介绍CDN HTTPS解决方案之前，要先搞清楚，为什么要选择使用HTTPS来替换掉HTTP。 第一， HTTPS是更具安全性的传输协议，可以防止网站被篡改和劫持，这是最基本的功能。Chrome和Firefox未来将HTTP标记为不安全的协议。第二， Apple ATS，要求IOS的 9.0或10.0的版本的APP使用HTTPS传输。第三， 主流的浏览器已经支持基于TLS的HTTP/2。第四， Google会给使用了HTTPS的网站进行搜索排名的加权，在鼓励大家使用。第五， 美英政府的网站官网都已经转向HTTPS。 我们可以看到，从用户需求到整个行业大趋势，都是在推送HTTPS的应用。那么阿里云CDN HTTPS的解决方案是怎样的呢？ CDN HTTPS解决方案 HTTPS能够有效的防止网站内容被篡改被劫持，加强了网站的安全性。所以在阿里云CDN内容分发网络中，我们已经引入HTTPS安全加速解决方案。 举个例子，在一个具有两级节点的CDN分发架构中，从Client到L1节点再到L2，再回源到源站，一共具有三段TCP连接，每一段都支持了HTTPS。在这中间，在第一段Client到L1节点的时候，需要用户自己的证书。L1到L2节点的时候使用的是我们的证书，保证了数据加密。回到源站的时候，如果用户也希望用HTTPS，我们也可以通过配置实现整个链路的HTTPS，充分保证了网站内容的防篡改、防劫持。 以上方案，用户需要将证书和私钥传输到CDN的证书管理中心来去处理HTTPS的请求。同时，我们还有更进一步的方案。对于对自己的证书和私钥敏感性很高的用户，希望将私钥保存在自己的服务器上，减少泄露的风险。针对这种情况，我们推出了无私钥解决方案。首先，用户搭建私钥服务器，当CDN和Client之间产生了HTTPS握手的时候，CDN处理的时候会提取SNI，域名配置拿到后，向私钥服务器（KeyServer）请求签名或者解密预主密钥。这个方案，我们其实是把私钥的部分剥离出来，通过KeyServer来实现。目前，阿里云已经实现了自己的KeyServer，用户只需要在自己的私钥服务器上安装一下KeyServer的rpm和配置一下即可。 阿里云CDN 提供HTTPS安全加速方案，仅需开启安全加速模式后上传加速域名证书/私钥，实现全网数据加密传输功能。 CDN HTTPS的技术优势 • 支持HTTP/2功能HTTP/2是对HTTP/1.x进行加强，阿里云CDN 现已全平台支持 HTTP/2，使用阿里云 HTTPS 加速服务的域名，即可免费享受 HTTP/2服务。HTTP/2是一个二进制的协议，支持头部压缩的功能，多路复用以及服务器推送，能够有效提升传输效率。 • 丰富的HTTPS配置项阿里云CDN HTTPS可以以实现动态设置。举个例子，在实践中发现有些用户的APP对HTTP/2协议实现的不够完美，一种解法就是用户修改自己的APP，把问题修复。另一种解法就是CDN通过配置把APP的HTTP/2协议给关掉，走HTTP/1.1协议，给用户足够的选择。 • KeyServer无私钥解决方案前文提到，对于对自己证书和私钥敏感度很高的用户，可保障证书和私钥安全性，支持自建KeyServer，提供KeyServer解决方案和源码。 • 安全功能HTTPS协议是由HTTP+SSL协议组合构建的需身份认证的加密传输网络协议，可全方位保障安全性，防止敏感信息泄露，防止传输过程中流量被劫持，篡改，确保数据的完整性。 • 动态证书支持动态证书，一个用户，如果想使用HTTPS，在上传完证书和私钥之后，全网1分钟就可以生效了。提供多规格证书，支持免费证书、证书过期提醒、证书属性预览。并且与阿里云证书中心CAS联动，可以申请免费证书。 • 灵活付费方式有后付费和预付费两种形式，后付费HTTPS 0.05元/万次请求，预付费请求包也有450元，4000元，35000元各种规格，规格为1亿次、10亿次、100亿次（双十一折扣）。 HTTPS相对于HTTP传输具有如此多的优势，那HTTPS在性能方面是否也同样超越HTTP呢？我们知道，阿里云CDN HTTPS可以减少回源率，提升通信效率，提高验证效率，减少跳转耗时，这些是通过哪些技术来实现优化的呢？下面我们来看看CDN HTTPS的优化实践。 CDN HTTPS优化实践 首先，我们知道，阻碍HTTPS的性能提升的关键因素是传输变慢，因为TCP连接握手了之后，还要进行SSL的握手，多层的数据加解密以及证书传输。 那么HTTPS一定会变慢吗？下图，是淘宝和天猫使用了HTTPS后的一些性能提升数据。其实我们可以看到，淘宝首页和搜索、聚划算、天猫等页面中，性能都是正向提升的。所以接下来，我们看看CDN HTTPS在性能方面到底做了哪些优化？ 第一， 我们知道，SSL在握手阶段是非常消耗资源的，SSL本身也支持了session ID和session ticket这两种方式，第一种session ID是在sever端存储会话ID，client端下次请求时候如果携带了同样的ID，就可以恢复以前的会话，省去了大量的握手环节。但是一个client访问不同sever的时候，存在ID共享的问题，实现起来比较复杂。第二种session ticket可以把会话的信息发给client，client去保存信息，不会依赖于某个sever了。第二， 我们需要把HTTP/2协议用起来，多路复用和头部压缩都是可以提升传输效率的。第三， 域名合并，对于主站和用户域名比较多的情况，我们就倾向于把域名做合并，合并成一个泛域名中做处理。这样可以减少SSL握手，提升重用，进而提升效率。第四， 协议栈优化，这是各大CDN公司都在做的功能。传统协议栈是逐渐的试探并且越来越多发送数据的过程，初始化窗口会比较小。我们现在会针对性进行调整，并且提升快速重传的效率。第五， 优先算法，优先预制ECDSA的算法，在产生相同加密强度的时候，数据量更少。 以上，都是为了更高效的传输和减少数据量，CDN HTTPS所进行的一些优化实践。 另外，在峰值的应对上，除了自身的HTTPS优化，我们还需要在Cache系统上进行预热，全部都加载到一级节点，就不存在回源的问题了。另外，调度系统中，我们业务系统要给出预判峰值，同时CDN需要做热点地区的统计，与临近非热点地区分摊，依据节点能力按比例进行分配。当然，针对峰值情况，我们也需要做限流。 如何更好的使用HTTPS 说了这么多HTTPS的好处，那用户可以如何更好的使用HTTPS呢？第一， 证书的申请，根据域名的类型来申请，阿里云也提供证书服务，可签发Symantec、CFCA、GeoTrust证书。证书的分类有三种：DV、OV和EV。DV是指基于域名级别的证书，机构只需要验证域名的所有者，安全级别比较低。OV和EV是企业级别证书，除了验证域名所有者还要验证企业信息。EV的证书，在访问时能够显示公司名字。第二， 源站改造，包括页面资源的改造，TLS版本选择1.0以上，关于session ID和session ticket的优化配置，证书上支持SHA256等工作。另外，实际应用中，有一个问题，当用户输入域名，我们可以通过配置强制HTTPS访问。 以上就是关于HTTPS的介绍，在用户访问安全、内容传输安全等使用场景中，阿里云CDN都可以提供相应的HTTPS安全加速解决方案，降低用户成本，实现加速与安全的双重效果。目前，阿里云CDN HTTPS已经全面降价，后付费HTTPS 0.05元/万次请求。为了迎接双11，预付费资源包也推出新购特惠：双十一当天30元购买1千万次HTTPS请求数资源包。欢迎大家登录双11会场进行选购。 本文部分内容整理自：阿里云CDN高级技术专家容恪分享

docker 加速器 <font color="red">首先 1、他是永久免费的。 2、版本支持 linux \ windows \ macOS</font> 一、为什么要用加速器呢？ 使用 Docker 的时候，需要经常从官方获取镜像，但是由于显而易见的网络原因，拉取镜像的过程非常耗时，严重影响使用 Docker 的体验。因此 DaoCloud 推出了加速器工具解决这个难题，通过智能路由和缓存机制，极大提升了国内网络访问 Docker Hub 的速度，目前已经拥有了广泛的用户群体，并得到了 Docker 官方的大力推荐。如果您是在国内的网络环境使用 Docker，那么 Docker 加速器一定能帮助到您。 二、Docker 加速器对 Docker 的版本有要求吗？ 需要 Docker 1.8 或更高版本才能使用，如果您没有安装 Docker 或者版本较旧，请安装或升级。 三、如何获得加速器？ 这里使用的 DaoCloud 提供的加速器https://www.daocloud.io/mirror#accelerator-doc 四、linux 直接输入： curl -sSL https://get.daocloud.io/daotools/set_mirror.sh | sh -s http://5a13675a.m.daocloud.io 这就可以了，这个是我的，你们也可以自己去注册，申请一个自己的。

前言 Apple从2016年逐步要求HTTPS，SSL相关证书等，上月的JSPatch封杀更是引起广大开发者的注意，整体来说多是为了安全考虑，那么SSL证书是硬需，考虑到上一篇：HTTPS时代已来，老司机手把手指导申请免费SSL证书 介绍了阿里云的相关证书，为了不仅仅依赖一家证书，特此又研究了一下又拍云的SSL-TrustAsia证书申购申购地址，希望能帮助到你！ 第一步： 绑定域名并解析域名 创建服务-添加域名-解析域名 提示：记得选择全网加速服务，不要问为什么，因为它免费，也方便绑定域名与解析 提示1：解析的域名最好是备案好的，不然后期证书可能会导致失败，现在所有的国内域名都严格要求起来了，包括阿里云，万网，新网，主机屋等等等等，总之名不正言不顺，备案一下一劳永逸，这里我测试的是我已备案好的 提示2：添加过域名记得及时解析CNAME操作，不然可能影响后期证书，最近收到又拍云升级通知： 第二步： 证书申购（免费） 申购的是免费版的TrustAsia证书（苹果认证可放心使用） 第三步： 证书配置 选择TrustAsia证书，其他不用操作，接着下一步 第四步： 补全资料 填入第一步绑定的域名，由于第一步已解析域名证明了域名所有权，直接点击提交即可！ 第五部：审核结果查看 审核通过的如下： 温馨提示：又拍云免费SSL证书申购是通过第三方提交审核的，所以官网不受控制，甚至由于解析错误未能审核通过状态也不显示和邮件提醒，所以特此提醒开发者，正常审核周期是一个工作日，若你的申购一直处于待审核，原因可能有两点：1.解析域名时，顶级域名和带www的域名解析是要和又拍云保持一致的；2.未绑定解析域名，或者节假日延后，更多问题可以咨询官方客服。 第六步： 证书的管理 上一篇：HTTPS时代已来，老司机手把手指导申请免费SSL证书 更多：每周更新关注新浪微博！ 手机加iOS开发者交流QQ群： 446310206

之前做好的asp.net部署后,发现 访问数据库时: 异常:已捕获: "已成功与服务器建立连接，但是在登录过程中发生错误。 (provider: SSL Provider, error: 0 - 接收到的消息异常，或格式不正确。)" (System.Data.SqlClient.SqlException)捕获到一个 System.Data.SqlClient.SqlException: "已成功与服务器建立连接，但是在登录过程中发生错误。 (provider: SSL Provider, error: 0 - 接收到的消息异常，或格式不正确。)" 包括在Visual studio 里面添加数据库连接时也会出现该异常,造成vs崩溃.   解决方法: 网友都说可能是因为安装某网络软件之后影响了电脑的LPS， 于是我在命令行里执行netsh winsock reset重置命令然后重启电脑，问题解决。 听说360安全卫士之类的软件带了LPS修复功能，应该也能解决。   ps: LSP是什么 LSP是什么？LSP的中文名叫分层服务提供程序，是TCP/IP等协议的接口。浏览器，聊天工具等等都要通过这个接口来获取相应的信息，LSP的功能就相当于生活中的插座。当LSP出现异常时，这个调用的接口就没办法正常工作，就会出现只能上qq不能打开网页，巨盾拦拦不能使用或者一些网游加速器无法正常使用的情况。

什么是HTTPS？ HTTP协议以明文方式发送内容，不提供任何方式的数据加密。HTTPS协议是以安全为目标的HTTP通道，简单来说，HTTPS是HTTP的安全版，即将HTTP用SSL/TLS协议进行封装，HTTPS的安全基础是SSL/TLS协议。HTTPS提供了身份验证与加密通讯方法，被广泛用于万维网上安全敏感的通讯，例如交易支付。根据2017年EFF（Electronic Frontier Foundation）发布的报告，目前全球已有超过一半的网页端流量采用了加密的HTTPS进行传输。更多HTTPS的信息请参考阿里云CDN官方帮助文档什么是HTTPS加速。 CDN如何HTTPS加速 使用了CDN以后，域名解析到了CDN，因此必须要在CDN侧配置HTTPS证书。如果CDN上没有配置HTTPS证书，则CDN只支持HTTP访问；如果CDN上配置了HTTPS证书，则CDN支持HTTP和HTTPS访问。具体配置请参考帮助文档“配置HTTPS证书”。 源站已经配置了HTTPS，CDN上是否还需要配置 HTTPS是客户端和服务端的交互，没有用CDN前，是客户端直接和源站交互，因此源站需要配置HTTPS。使用CDN以后，是客户端和CDN交互，因此如果需要HTTPS访问CDN，则CDN上必须要配置HTTPS证书。源站配置了HTTPS证书只是支持CDN以HTTPS回源到源站。 为什么配置了HTTPS，客户端还是HTTP访问的 客户端是HTTP访问还是HTTPS访问完全是客户端的行为，如果希望客户端强制用HTTPS访问，可以在CDN上开启强制HTTPS跳转。 申请CDN免费HTTPS证书失败 在阿里云CDN控制台中申请免费HTTPS证书时，存在一些限制。您可以参考“在CDN的HTTPS设置中申请免费证书失败”的文档去排查和解决。 CDN配置HTTPS以后还是无法访问 （1）如果是购买证书以后自定义上传的情况，需要特别注意SSL证书根据其适用范围可以分为：通配符域名、单个域名和多个域名。根据其名称即可查看购买的证书分别适用于主域名下某个级别的全部子域名、单个域名或者多个域名。用户是需要保证购买的证书必须适用于加速域名后续才可以添加在CDN中生效。如下图所示的即是添加的SSL证书（适用于www域名）与CDN加速域名（video的子域名）是不相匹配的，因此会抛出NET::ERR_CERT_COMMON_NAME_INVALID的错误。 （2）CA机构提供的证书为了兼容性可能会提供多种形式的证书，CDN支持的证书仅有PEM格式，并且私钥需要RSA格式。如果客户获取得到的是其他格式的证书是需要转换后然后提交到CDN服务中的，常见格式切换格式请参考：CDN 证书格式说明，而其中的私钥文件如果是-----BEGIN PRIVATE KEY-----, -----END PRIVATE KEY-----样式的话是需要通过如下命令转换成RSA格式：openssl rsa -in old_server_key.pem -out new_server_key.pem （3）CDN是不支持设置密码的私钥。如图3所示即是经过加密的私钥，这类私钥文件是需要经过解密后才可以正常使用，因此CDN是无法正常使用的。 （4）证书链需要补全中间证书。对于中级CA机构提供的证书，那么拿到的证书将包括多份证书，而CDN需要添加的是包括中间证书的完整证书链，拼接规则为：服务器证书放第一份，中间证书放第二份，中间不要有空行。另外有一些中间证书CA机构提供了不同的服务器使用的证书，由于CDN是基于Tengine提供服务的，因此用户是需要使用Nginx对应的证书到视频中心的。 （5）CDN的HTTPS技术是基于SNI技术实现的。SNI技术主要是用来在同一台服务器上配置多个证书的需求，而SNI是需要客户端发送请求的时候带有SNI的信息以标识是哪个域名的SSL请求，因此SNI技术对客户端有一定的要求，部分低版本系统中的低版本浏览器不满足该要求。SNI技术对于客户端的限制详细请参考：SNI对客户端浏览器限制。 为什么网站开启HTTPS以后显示不全 打开浏览器开发者模式，切换到console页面，如果看到Mixed Content错误，则说明是浏览器安全限制导致的。浏览器要求Https的页面里只能加载Https的地址，不能加载Http的资源。如果您的Https的页面里加载了很多http的资源，这些资源加载不出来的，因此会引起网站显示异常，这种情况需要网站技术人员把htm代码里加载的资源地址都改成https的。

什么是HTTPS？ HTTP协议以明文方式发送内容，不提供任何方式的数据加密。HTTPS协议是以安全为目标的HTTP通道，简单来说，HTTPS是HTTP的安全版，即将HTTP用SSL/TLS协议进行封装，HTTPS的安全基础是SSL/TLS协议。HTTPS提供了身份验证与加密通讯方法，被广泛用于万维网上安全敏感的通讯，例如交易支付。根据2017年EFF（Electronic Frontier Foundation）发布的报告，目前全球已有超过一半的网页端流量采用了加密的HTTPS进行传输。更多HTTPS的信息请参考阿里云CDN官方帮助文档什么是HTTPS加速。 CDN如何HTTPS加速 使用了CDN以后，域名解析到了CDN，因此必须要在CDN侧配置HTTPS证书。如果CDN上没有配置HTTPS证书，则CDN只支持HTTP访问；如果CDN上配置了HTTPS证书，则CDN支持HTTP和HTTPS访问。具体配置请参考帮助文档“配置HTTPS证书”。 源站已经配置了HTTPS，CDN上是否还需要配置 HTTPS是客户端和服务端的交互，没有用CDN前，是客户端直接和源站交互，因此源站需要配置HTTPS。使用CDN以后，是客户端和CDN交互，因此如果需要HTTPS访问CDN，则CDN上必须要配置HTTPS证书。源站配置了HTTPS证书只是支持CDN以HTTPS回源到源站。 为什么配置了HTTPS，客户端还是HTTP访问的 客户端是HTTP访问还是HTTPS访问完全是客户端的行为，如果希望客户端强制用HTTPS访问，可以在CDN上开启强制HTTPS跳转。 申请CDN免费HTTPS证书失败 在阿里云CDN控制台中申请免费HTTPS证书时，存在一些限制。您可以参考“在CDN的HTTPS设置中申请免费证书失败”的文档去排查和解决。 CDN配置HTTPS以后还是无法访问 （1）如果是购买证书以后自定义上传的情况，需要特别注意SSL证书根据其适用范围可以分为：通配符域名、单个域名和多个域名。根据其名称即可查看购买的证书分别适用于主域名下某个级别的全部子域名、单个域名或者多个域名。用户是需要保证购买的证书必须适用于加速域名后续才可以添加在CDN中生效。如下图所示的即是添加的SSL证书（适用于www域名）与CDN加速域名（video的子域名）是不相匹配的，因此会抛出NET::ERR_CERT_COMMON_NAME_INVALID的错误。 （2）CA机构提供的证书为了兼容性可能会提供多种形式的证书，CDN支持的证书仅有PEM格式，并且私钥需要RSA格式。如果客户获取得到的是其他格式的证书是需要转换后然后提交到CDN服务中的，常见格式切换格式请参考：CDN 证书格式说明，而其中的私钥文件如果是-----BEGIN PRIVATE KEY-----, -----END PRIVATE KEY-----样式的话是需要通过如下命令转换成RSA格式：openssl rsa -in old_server_key.pem -out new_server_key.pem （3）CDN是不支持设置密码的私钥。如图3所示即是经过加密的私钥，这类私钥文件是需要经过解密后才可以正常使用，因此CDN是无法正常使用的。 （4）证书链需要补全中间证书。对于中级CA机构提供的证书，那么拿到的证书将包括多份证书，而CDN需要添加的是包括中间证书的完整证书链，拼接规则为：服务器证书放第一份，中间证书放第二份，中间不要有空行。另外有一些中间证书CA机构提供了不同的服务器使用的证书，由于CDN是基于Tengine提供服务的，因此用户是需要使用Nginx对应的证书到视频中心的。 （5）CDN的HTTPS技术是基于SNI技术实现的。SNI技术主要是用来在同一台服务器上配置多个证书的需求，而SNI是需要客户端发送请求的时候带有SNI的信息以标识是哪个域名的SSL请求，因此SNI技术对客户端有一定的要求，部分低版本系统中的低版本浏览器不满足该要求。SNI技术对于客户端的限制详细请参考：SNI对客户端浏览器限制。 为什么网站开启HTTPS以后显示不全 打开浏览器开发者模式，切换到console页面，如果看到Mixed Content错误，则说明是浏览器安全限制导致的。浏览器要求Https的页面里只能加载Https的地址，不能加载Http的资源。如果您的Https的页面里加载了很多http的资源，这些资源加载不出来的，因此会引起网站显示异常，这种情况需要网站技术人员把htm代码里加载的资源地址都改成https的。

本文邀请阿里云CDN HTTPS技术专家金九，分享Tengine的一些HTTPS实践经验。内容主要有四个方面：HTTPS趋势、HTTPS基础、HTTPS实践、HTTPS调试。 一、HTTPS趋势 这一章节主要介绍近几年和未来HTTPS的趋势，包括两大浏览器chrome和firefox对HTTPS的态度，以及淘宝天猫和阿里云CDN的HTTPS实践情况。 上图是 chrome 统计的HTTPS网页占比的趋势，2015年的时候，大多数国家的HTTPS网页加载次数只占了不到 50%，2016年美国这个占比到了将近60%，去年就已经超过 70%，目前已经超过 80%。最下面是日本，目前是60%左右，这里面没有统计到中国的数据，我估计中国的占比会更少，空间还有很大，但未来HTTPS趋势是明显的。 同样，Firefox 浏览器加载HTTPS网页的统计跟 chrome 差不多，全球 HTTPS网页加载占比在 70% 左右，上升趋势也很明显。 更值得关注的是，Google 在今年年初的时候在其安全博客上表明，在今年7月份左右发布的 chrome68 浏览器会将所有HTTP网站标记为不安全，现在是5月份底了，离这个时间也就一个多月的时间了。右边的截图可以看出本来是绿色的小锁变成了不安全，这种网页在输入密码时就很不安全了。 早期天猫淘宝只是在关键的登录和交易的环节上了HTTPS，但随着互联网的发展，劫持、篡改等等问题也越来越严重，试想在天猫淘宝上看的商品图片被恶意人替换了或者价格被篡改了会怎么样？这样用户、商家和平台都受到伤害，只有上了 HTTPS才能从根本上解决这些问题。所以，天猫和淘宝在2015年7月份的时候已经完成了全站HTTPS。 二、HTTPS基础 本章节主要介绍HTTPS为什么安全，包括对称加密、非对称加密、签名、证书&证书链、SSL是怎么握手的、以及私钥密钥在HTTPS中发挥什么样的作用、keyless又是解决什么样的问题等等。 HTTPS的定义 简单来讲，HTTPS就是安全的HTTP，我们知道HTTP是运行在TCP层之上的，HTTPS在HTTP层和TCP层之间加了一个SSL层，SSL向上提供加密和解密的服务，对HTTP比较透明，这样也便于服务器和客户端的实现以及升级。 HTTPS为什么安全？ HTTPS安全是由一套安全机制来保证的，主要包含这4个特性：机密性、完整性、真实性和不可否认性。 机密性是指传输的数据是采用Session Key（会话密钥）加密的，在网络上是看不到明文的。 完整性是指为了避免网络中传输的数据被非法篡改，使用MAC算法来保证消息的完整性。 真实性是指通信的对方是可信的，利用了PKI（Public Key Infrastructure 即『公钥基础设施』）来保证公钥的真实性。 不可否认性是这个消息就是你给我发的，无法伪装和否认，是因为使用了签名的技术来保证的。 对称加密和非对称加密 HTTPS有对称加密和非对称加密两种算法，目的都是把明文加密成密文，区别是密钥的个数不一样，对称加密是一把密钥，这把密钥可以加密明文，也可以解密加密后的密文，常见的对称加密算法有AES、DES、RC4，目前最常用的是AES。 非对称加密是两把密钥，分别是公钥和私钥，公钥加密的密文只有相对应的私钥才能解密，私钥加密的内容也只有相对应的公钥才能解密，其中公钥是公开的，私钥是自己保存，不能公开，常见的非对称加密算法有RSA和ECC（椭圆曲线算法）。 SSL结合了这两种加密算法的优点，通过非对称加密来协商对称加密的密钥，握手成功之后便可使用对称加密来做加密通信，对于RSA来说，客户端是用RSA的公钥把预主密钥加密后传给服务器，服务器再用私钥来解密，双方再通过相同的算法来生成会话密钥，之后的应用层数据就可以通过会话密钥来加密通信。 签名 SSL中还有一个使用非对称加密的地方就是签名，签名的目的是让对方相信这个数据是我发送的，而不是其他人发送的。 密钥安全强度与性能对比 加密之后的数据破解难度就体现在密钥的长度上，密钥越长，破解难度也越大，但是运算的时间也越长，性能也就越差。相同安全强度下，对称密钥长度在最短，ECC次之，RSA密钥长度则最长。 目前比较常用的密钥长度是：对称密钥128位、ECC 256位、RSA 2048位。 RSA和ECC在SSL中更多的是用来签名，通过测试发现，ECC 的签名性能比RSA好很多，但是RSA的验签性能比ECC更好，所以RSA更适合于验证签名频繁而签名频度较低的场景，ECC更适合于签名频繁的场景，在SSL场景中，ECC算法性能更好。 公钥基础设施（PKI） 简单的说，PKI就是浏览器和CA，CA是整个安全机制的重要保障，我们平时用的证书就是由CA机构颁发，其实就是用CA的私钥给用户的证书签名，然后在证书的签名字段中填充这个签名值，浏览器在验证这个证书的时候就是使用CA的公钥进行验签。 证书 那CA在PKI中又是怎样发挥作用的呢，首先，CA的作用就是颁发证书，颁发证书其实就是使用CA的私钥对证书请求签名文件进行签名，其次，CA颁发的证书浏览器要信任，浏览器只需要用CA的公钥进行验签成功就表示这个证书是合法可信的，这就需要浏览器内置CA的公钥，也就是内置CA的证书。一般来说，操作系统都会内置权威CA的证书，有的浏览器会使用操作系统内置的CA证书列表，有的浏览器则自己维护的CA证书列表，比如Firefox。 CA分为根CA，二级CA，三级CA，三级CA证书由二级CA的私钥签名，二级CA证书由根CA的私钥签名，根CA是自签名的，不会给用户证书签名，我们平时用的证书都是由二级CA或者三级CA签名的，这样就形成了一个证书链，浏览器在验签的时侯一层层往上验证，直到用内置的根CA证书的公钥来验签成功就可以表示用户证书是合法的证书。根证书已经内置在浏览器或者操作系统里了，在SSL握手时就不需要发根CA证书了，只需要提供中间二级三级CA证书和用户证书就可以。 交叉证书 交叉证书的应用场景是这样的：假如现在阿里云成为一个新的根CA机构，那阿里云签发的证书想要浏览器信任的话，阿里云的根证书就需要内置在各大操作系统和浏览器中，这需要较长时间的部署，那在没有完全部署完成之前，阿里云签发的证书怎么才能让浏览器信任呢，这就需要用到交叉证书了。 上图中，根证书A是一个所有浏览器都内置了的根证书，B是一个新的根证书，用户证书D是由根证书 B的二级CA B1来签发的，但是根证书B并没有在浏览器中内置，所以浏览器不会信任用户证书D，这是因为浏览器在验签时只验证到B1这一层然后找不到根证书B就无法验证下去了。如果二级CA B1证书是由根证书A来签名，那这个问题就解了，所以新的根证书机构B会将二级CA证书（准确地讲是二级CA的证书签名请求文件）给老的根证书A来签名，然后得到一个新的中间证书就是交叉证书。浏览器在验证的时侯用了新的信任链，这样就可以解决用户证书的信任问题。 当B的根证书全部部署完成后，再替换成自己的二级CA就可以了。 证书分类 证书分有三类：DV、OV、EV DV证书只校验域名的所有权，所以我们在申请DV证书的时候CA会提供几种验证域名所有权的方法：比如文件校验、DNS校验、邮件校验，DV证书支持单域名、多域名和泛域名，但不支持多个泛域名，只支持一个泛域名，一般价格比较便宜，具体价格跟域名的数量有关，域名越多价格越高。 OV证书要验证组织机构，在申请证书时CA会打电话确认这个域名是否真的属于相应的公司或者机构，OV证书是单域名、多域名、泛域名和多个泛域名都支持，价格一般比DV证书要贵。 EV证书的校验就更细了，比如组织机构的地址之类的，EV证书会在地址栏上显示组织机构的名称，EV证书只支持单域名或者多个域名，不支持泛域名，而且更贵，所以普通用户一般不会用EV证书。 证书吊销 证书是有生命周期的，如果证书的私钥泄漏了那这个证书就得吊销，一般有两种吊销方式：CRL和OCSP。 CRL是CA机构维护的一个已经被吊销的证书序列号列表，浏览器需要定时更新这个列表，浏览器在验证证书合法性的时候也会在证书吊销列表中查询是否已经被吊销，如果被吊销了那这个证书也是不可信的。可以看出，这个列表随着被吊销证书的增加而增加，列表会越来越大，浏览器还需要定时更新，实时性也比较差。 所以，后来就有了 OCSP 在线证书状态协议，这个协议就是解决了 CRL 列表越来越大和实时性差的问题而生的。有了这个协议，浏览器就可以不用定期更新CRL了，在验证证书的时候直接去CA服务器实时校验一下证书有没有被吊销就可以，是解决了CRL的问题，但是每次都要去CA服务器上校验也会很慢，在网络环境较差的时候或者跨国访问的时候，体验就非常差了，OCSP虽然解决了CRL的问题但是性能却很差。所以后来就有了OCSP stapling。 OCSP stapling主要解决浏览器OCSP查询性能差的问题，本来由浏览器去CA的OCSP服务器查询证书状态的，现在改由域名的服务器去查询，将OCSP的结果告诉浏览器即可，一般服务器的网络性能要好于用户电脑的网络，所以OCSP stapling的性能是最好的。但是并不是所有的服务器都支持OCSP stapling，所以目前浏览器还是比较依赖CRL，证书吊销的实时性要求也不是特别高，所以定期更新问题也不大。 HTTPS工作模式 对于客户端和服务器来讲，应用层协议还是HTTP，只是加了一个SSL层来做加密解密的逻辑，对应用层来说是透明的，在网络上传输的都是加密的请求和加密的响应，从而达到安全传输的目的。 这是SSL层在网络模型的位置，SSL属于应用层协议。接管应用层的数据加解密，并通过网络层发送给对方。 更细地分，SSL协议分握手协议和记录协议，握手协议用来协商会话参数（比如会话密钥、应用层协议等等），记录协议主要用来传输应用层数据和握手协议消息数据，以及做加解密处理。我们应用层的的消息数据在SSL记录协议会给分成很多段，然后再对这个片段进行加密，最后在加上记录头后就发送出去。 TLS握手协议 SSL/TLS 握手协议又细分为四个子协议，分别是握手协议、密码规格变更协议、警告协议和应用数据协议。 完整的握手流程 首先是TCP握手，TCP三次完成之后才进入SSL握手，SSL握手总是以ClientHello消息开始，就跟TCP握手总是以SYN包开始一样； ClientHello主要包含客户端支持的协议、密钥套件、session id、客户端随机数、sni、应用层协议列表（http/1.1、h2）、签名算法等等；服务器收到ClientHello之后会从中选取本次通信的协议版本、密钥套件、应用层协议、签名算法，以及服务器随机数，然后通过ServerHello消息响应，如果没有session复用，那将服务器的证书通过Certificate消息响应，如果是选用了ECC算法来做密钥交换的话，那还会将椭圆曲线参数以及签名值通过ServerKeyExchange消息发送给对方，最后通过ServerHelloDone消息来结束本次协商过程； 客户端收到这些消息之后，会生成预主密钥、主密钥和会话密钥，然后将椭圆曲线参数通过ClientKeyExchange发送给服务器，服务器拿到客户端的椭圆曲线参数也会生成预主密钥，如果是RSA的话ClientKeyExchange用来发送公钥加密的预主密钥，服务器用私钥来解密一下就可以得到预主密钥，再由预主密钥生成主密钥和会话密钥。最后双方都以ChangeCipherSpce和Finished消息来告知对方，自己已经准备好了可以进行加密通信了，然后握手完成。 可以看出，完整的SSL握手需要2个RTT，而且每次握手都用到了非对称加密算法签名或者解密的操作，比较耗CPU，所以后来就有了session复用的优化手段，后面会做介绍。 SSL的握手消息虽然比较多，但很多消息都是放在一个TCP包中发送的，从抓包可以看出完整的SSL握手需要2个RTT。 刚才通过完整的SSL握手可以看出几个缺点：1、2个RTT，首包时间较长2、每次都要做非对称加密，比较耗CPU，影响性能3、每次都要传证书，证书一般都比较大，浪费带宽 SSL握手的目的是协商会话密钥以及参数，如果能把这些会话参数缓存那就可以没有必要每次都传证书和做非对称加密计算，这样就可以提高握手性能，而且可以将RTT减到1个，提高用户体验。 所以就有了session id的复用方式，每次完整握手之后都将协商好的会话参数缓存在服务器中，客户端下次握手时会将上次握手的session id带上，服务器通过session id查询是否有会话缓存，有的话就直接复用，没有的话就重新走完整握手流程。但是session id这种方式也有缺点，比较难支持分布式缓存以及耗费服务器的内存。 而session ticket 方案，其原理可以理解为跟 http cookie 一样，服务器将协商好的会话参数加密成 session ticket，然后发送给客户端，客户端下次握手时会将这个session ticket带上，服务器解密成功就复用上次的会话参数，否则就重新走完整握手流程。可以看出session ticket这种方式不需要服务器缓存什么，支持分布式环境，有很大的优势。这种方式有一个缺点是并不是所有客户端都支持，支持率比较低，但随着客户端版本的更新迭代，以后各种客户端会都支持。因为session id客户端支持率比较高，所以目前这两种方式都在使用。 这是 session ticket 的复用，跟 session id 的区别是 client hello 会带上 Session ticket ，将近200个字节的加密数据，服务器会用session ticket 密钥来解密，解密成功则直接复用，也简化了握手流程，提升效率和性能。 这是我们上了分布式 Session id 复用的效果，session id复用的比例在没有开启分布式缓存时只占了3%左右，复用率很低，上了分布式session缓存之后，这个比例提升到20%多。握手时间也从75ms左右降低到65ms左右，性能提升效果还是很明显的。 SSL/TLS握手时的私钥用途（RSA、ECDHE） 我们知道私钥是整个SSL中最重要的东西，那私钥在SSL握手里面又是怎么使用的呢？两种使用方式分别是：使用RSA来做密钥交换和使用ECDHE来做密钥交换。对于RSA来说，客户端生成预主密钥，然后用公钥加密再发给服务器，服务器用私钥来解密得到预主密钥，然后由预主密钥生成主密钥，再由主密钥生会话密钥，最后用会话密钥来通信。 对于ECDHE来说，客户端和服务器双方是交换椭圆曲线参数，私钥只是用来签名，这是为了保证这个消息是持有私钥的人给我发的，而不是冒充的。双方交换完参数之后生成预主密钥，再生成主密钥和会话密钥。这就跟刚才RSA后面的流程一样了。 可以看出RSA和椭圆曲线密钥交换算法的私钥用途是不一样的，RSA密钥交换时是用来做加解密的，椭圆曲线密钥交换时是用来做签名的。 SSL/TLS中的密钥 预主密钥、主密钥和会话密钥，这几个密钥都是有联系的。 对于RSA来说，预主密钥是客户端生成，加密之后发给服务器，服务器用私钥来解密。对于ECDHE来说，预主密钥是双方通过椭圆曲线算法来生成。 主密钥是由预主密钥、客户端随机数和服务器随机数通过PRF函数来生成；会话密钥是由主密钥、客户端随机数和服务器随机数通过PRF函数来生成，会话密钥里面包含对称加密密钥、消息认证和CBC模式的初始化向量，但对于非CBC模式的加密算法来说，就没有用到这个初始化向量。 session 缓存和session ticket里面保存的是主密钥，而不是会话密钥，这是为了保证每次会话都是独立的，这样才安全，即使一个主密钥泄漏了也不影响其他会话。 Keyless 刚才提到RSA和ECDHE的私钥用途，对于服务器来说，密钥交换算法是RSA时，私钥是用来做解密的，ECDHE时，私钥是用来签名的。 Keyless就是将私钥参与运算的部分分离远程服务器，这样可以解决两个问题：1，公私钥分离，用户不需要将私钥给第三方，减少私钥泄露的风险。2，将非对称加密运算这种cpu密集型运算剥离到keyserver，可以在keyserver中安装ssl加速卡做硬件加速，提高性能。 HTTP/2 HTTP/2主要有这几个特性：一、二进制协议，可以做更多的优化；二、多路复用，一定程度上解决了队头阻塞的问题，提高并发和总的加载时间三、头部压缩，很多请求头或者响应头都没有必要重复传输浪费带宽，比如user-agent、cookie还有其他没有必要每次都传的头部在http2中都做了优化四、安全，虽然RFC规定HTTP/2可以运行在明文之上，但目前所有浏览器都只支持https之上的http/2，所以是安全的。 开启HTTP/2会有这几个收益： 一、加载时间的提升，我们做了这么一个测试，一张大图片分割成几百个小图片，然后用http/1.1和http/2打开，http/1.1加载完所有小图片用了五六秒，但http/2加载完所有小图片只需要不到1s的时间，有5倍左右的提升，效果还是很明显的，具体提升百分之多少这得具体看具体的业务类型。 二、头部压缩有95%左右的提升，http/1.1的平均响应头大小有500个字节左右，而http/2的平均响应头大小只有20多个字节，提升非常大，所以http/2非常适合小图片小文件的业务类型，因为小文件的http头部比重较大，而http/2对头部的压缩做了非常好的优化。 三、服务器QPS的性能有60%多的提升，这是因为http/2的连接复用和多路复用机制，可以处理更多的并发请求。 三、HTTPS实践 本章节会重点给大家讲讲 Tengine 如何配置 https、HTTP/2、TLSv1.3，以及如何实现动态证书。 Tengine如何开启HTTPS http { ssl_session_tickets on; ssl_session_ticket_key ticket.key; server { listen 443 ssl; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+ECDSA+AES128:EECDH+aRSA+AES128:RSA+AES128:EECDH+ECDSA+AES256:EECDH+aRSA+AES256:RSA+AES256:EECDH+ECDSA+3DES:EECDH+aRSA+3DES:RSA+3DES:!MD5; ssl_prefer_server_ciphers on; ssl_certificate www.alicdn.com.crt; ssl_certificate_key www.alicdn.com.key; ssl_session_cache shared:SSL:256M; ssl_session_timeout 15m; #…… } } 在Tengine中开启http2，只需要在listen的后面加上http2参数就可以了。 server { listen 443 ssl http2; http2 on; server_name a.com; #…… } server { listen 443 ssl; http2 off; server_name b.com; #…… } 但是有一个场景需要注意，因为有些域名并不想开启http2，比如上面这个配置的b.com并不想开http2，但是因为a.com开启了http2，所以b.com也被自动开启了，这是因为http2这个参数作用在ip和端口上，在ssl握手时用了a.com的配置参数，所以tengine针对这种情况做了一个域名级别的开关来做控制。 TLSv1.3——更快、更安全 1、1-RTT & 0-RTT2、只支持完全前向安全性的密钥交换算法3、ServerHello 之后的所有消息都是加密的4、淘汰 Session ID 和 Session Ticket，用 PSK 代替5、Chrome 63+, Firefox 58+ Tengine也支持了TLSv1.3，开启方式： server { ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; ssl_ciphers TLS13-AES-128-GCM-SHA256:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-256-GCM-SHA384:TLS13-AES-128-CCM-8-SHA256:TLS13-AES-128-CCM-SHA256:EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+ECDSA+AES128:EECDH+aRSA+AES128:RSA+AES128:EECDH+ECDSA+AES256:EECDH+aRSA+AES256:RSA+AES256:EECDH+ECDSA+3DES:EECDH+aRSA+3DES:RSA+3DES:!MD5; #…… } Tengine 实现与配置动态证书 动态证书主要解决的问题是接入域名太多，server块过多导致tengine reload慢的问题，lua-nginx模块提供了一个证书的lua阶段，可以在这个阶段来做证书的热加载，不需要reload tengine，这样可以提高效率和性能。 配置也比较简单，在ssl_cert.lua里面做证书的管理，在ssl握手时拿到sni，去拿这个域名的证书和私钥，再调用lua ffi接口就可以完成证书和私钥的切换。 server { ssl_certificate www.alicdn.com.crt; ssl_certificate_key www.alicdn.com.key; ssl_certificate_by_lua_file ssl_cert.lua; #…… } ssl_cert.lua:调用 lua ffi 接口设置证书和私钥 四、HTTPS调试 我们知道HTTP是明文传输，调试就很简单，抓包就可以看得清清楚楚，但HTTPS是加密的，抓包看到的是密文，这一节我告诉大家怎么去解密HTTPS抓包文件。 抓包解密 方法一：配置Wireshark： Wireshark  preferences…  Protocols  SSL  (Pre)-Master-Secret log filename => /tmp/sslkey.txt （一）： export SSLKEYLOGFILE=/tmp/sslkey.txt （二）： openssl s_client -connect 127.0.0.1:443 -servername www.alicdn.com -keylogfile /tmp/sslkey.txt （三）： echo “CLIENT_RANDOM 7EC0498BCF09E8300A1E9F8BA6C81E2A4383D7CDCFB10907B4074520FA8DF680 FA2457782F6FAECE47CF8E01BF9E0A441CEA8DCC91664F42F45F1EF5AB18ED902E35825713FF2D4D9651CE51ED885BB4 ”>> /tmp/sslkey.txt 方法二：强制使用RSA密钥交换算法，Wireshark配置私钥。 抓包解密-wireshark设置 常用命令及参数 curl 写在最后 证书的购买和申请是非常复杂耗时的，为了缩短开通周期，为开发者提供最大化便利，简化HTTPS加速设置环节，目前阿里云CDN已经支持控制台可实现一键开通HTTPS，后台将完成代理免费证书购买、证书节点部署以及证书到期之前自动续签，帮助开发者更便捷的完成全站HTTPS访问加速。 最后，金九老师所在的团队最近正在招聘系统研发专家 & HTTPS 研发专家，需要熟悉C/C++/Lua/Golang或tengine/nginx/openresty/openssl的伙伴加入，联系邮箱：zuxi.wzx@alibaba-inc.com，欢迎志同道合的技术专家们联系我们哦~ 点击观看HTTPS直播回放，听技术大神深度解读HTTPS原理与实践https://yq.aliyun.com/webinar/play/451 点击进入特惠活动专题页，CDN资源包低至6折https://m.aliyun.com/markets/aliyun/cdnhttps 点击进入HTTPS技术专题页，全面解读CDN HTTPS解决方案https://yq.aliyun.com/promotion/645

作者：王发康（毅松） 主站接入层是阿里2015年全站HTTPS项目诞生的产品，目前已经承载集团90%以上的入口流量。2016年主站接入层不仅在运维自动化、高可用领域取得重大突破，而且软件层面上也做过很多性能优化，促使2016年双11平稳度过。秉着软硬件结合的性能优化思想，2017年主站接入层在硬件加速领域迈出了第一步。在刚过去的2017年双11零点流量高峰的考验下，主站接入层Tengine Gzip硬件加速机器运行平稳、同等条件下相比于未开启QAT加速的机器性能提升21%左右。 背景介绍 众所周知，通用处理器（CPU）的摩尔定律已入暮年，而机器学习和Web服务需要的运算能力却指数级增长。随着如今硬件技术的成熟发展，普通CPU无论是在计算能力，还是资源成本上相对于一些专用加速硬件已经没有绝对优势，这也促使硬件加速技术得到各大公司的青睐，譬如三大互联网巨头百度、阿里、腾讯内部的接入层采用类似KeyLess方案来加速HTTPS的卸载，不仅提高了用户体验，还节省了机器成本。根据当前调研结果发现：目前业内各大公司接入层针对于Gzip采用硬件加速还是一片空白，阿里接入层首次结合硬件加速技术卸载Gzip不仅带来了性能提升，而且对业界在此领域的发展也有重大影响意义。 接入层Tengine当前性能瓶颈是CPU，譬如Gzip模块在Tengine中CPU占比高达15%-20%左右，相比于其它模块CPU消耗高、占比呈增长趋势（后端应用压缩逻辑后续统一前置接入层）、且集中，所以Gzip模块使用硬件卸载对于性能提升、成本优化是不可或缺。 分析与调研 分析前先简单介绍下什么是硬件加速： 硬件加速（Hardware Acceleration）就是利用硬件模块来替代软件算法以充分利用硬件所固有的快速特性（硬件加速通常比软件算法的效率要高），从而达到性能提升、成本优化目的，当前主要是如下两大加速方式： FPGA 现场可编程门阵列，可针对某个具体的软件算法进行定制化编程，譬如业内的智能网卡； ASIC 专用集成电路，它是面向专门用途的电路、专门为一个用户设计和制造的，譬如Intel的QAT卡仅支持特定加减密、压缩算法；FPGA与ASIC的对比如下表格所示： 模式 上市速度 性能 一次性成本 量产成本 可配置 FPGA 周期较短 较差(1x) 较低 高(100x) 灵活 ASIC 周期较长 好(4x) 较高 低(1x) 有限 接入层Tengine CPU消耗分析 主站接入层承载集团90%以上的入口流量，看似只是作为一个七层流量转发网关，但是却做了非常之多的事情，譬如https卸载及加速、单元化、智能流量转发策略、灰度分流、限流、安全防攻击、流量镜像、链路追踪、页面打点等等，这一系列功能的背后是Tengine众多模块的支持。由于功能点比较多，所以这就导致Tengine的CPU消耗比较分散，其主流程处理如下图所示:各模块CPU消耗占比Top 5如下表格所示： 模块名称 功能介绍 CPU占比 Gzip 解压缩 15%-20% Sinfo 流量镜像 10% TMD 限流 8% Lua lua相关业务 8% WAF 防火墙 6% 其它众多模块 ... ... 就当前接入层流量模型分析来看，Gzip单个模块CPU消耗占比达到15%-20%左右（注：主要是压缩消耗）且占比呈上升趋势，所以对Gzip使用硬件卸载迫在眉睫。 加速方案调研 Intel QAT卡 QAT(Quick Assist Technology )是Intel公司推出的一种专用硬件加速卡，不仅对SSL非对称加解密算法（RSA、ECDH、ECDSA、DH、DSA等）具有加速，而且对数据的压缩与解压也具有加速效果；QAT加速卡提供zlib压缩算法、且zlib shim对其原生zlib与QAT之间做了适配，调用方式和zlib库方式基本一致，需在上层业务中开启zlib QAT模式、相对来说对上层业务改造较少. 智能网卡 INIC（Intelligent Network Interface Card）是网络研发事业部自研产品，以网络处理器为核心的高性能网络接入卡，对于网络报文数据的处理非常合适，针对Tengine的gzip卸载有如下两种方案： 提供压缩API给host，把压缩数据返回host，由host封包发送； host和网卡约定压缩flag，host发送未压缩报文，智能网卡收到后进行压缩，并且重新封包发送； FPGA卡 FPGA（Field-Programmable Gate Array）现场可编程门阵列，需要对接入层使用的zlib算法使用硬件语言重新开发、进行电路烧写，且上层交互驱动也需要从零开发； 方案对比 智能网卡的方案1相比于QAT对zlib处理没有性能上的优势，智能网卡只是对zlib进行软件卸载、相对于QAT并不具有加速作用；其方案2需要把Tengine一部分业务逻辑抽取到网卡中做：如spdy、http2、chunked、ssl对称加密、响应body限速等逻辑，其成本及风险高，方案3的FPGA方式相对来说开发成本较高、且相关资源匮乏。 综上所述最终采用QAT加速卡对接入层Tengine的Gzip进行卸载、加速。 方案实施 QAT驱动采用UIO（Userspace I/O）技术，其大部分处于用户态、只有少部分处理硬件中断应答等逻辑处于内核态，这样不仅方便用户调试，而且还解决了内核不支持浮点数运算的问题。当然QAT加速卡也顺应了Docker虚拟化的潮流，其采用SRIOV技术，可以在虚拟机之间高效共享PCIe（Peripheral Component Interconnect Express）设备，当前DH895XCC系列芯片最高可支持32个虚拟机共享QAT，从而达到充分利用硬件资源。其次QAT属于ASIC模式相比于FPGA具有更好的加速效果，主要原因是由于FPGA为了可重构，导致其逻辑查找表、触发器众多以及相同逻辑电路在布线上延时变大。 接入层Tengine目前采用的是下图左边的实线加速链路，其中Zlib Shim、QAT User Space Api、QAT Driver作为Tengine Gzip与底层硬件QAT的通信适配层，此方式对上层业务入侵较小、其软件架构如下图所示：虽然该方案看起来比较简单，但是真正线上实施的时候还是遇到了非常多的问题（功能、性能方面），譬如： 架构不合理 使用的第一版驱动Intel-Qat2.6.0-60，当QPS为1k左右时CPU很快打满（注：正常情况下QPS为1k时，CPU消耗6%左右），且CPU消耗中90%以上都是消耗在内核态，如下图所示： 使用strace进行相关系统热点函数统计发现，其CPU主要消耗在ioctl系统函数上，如下所示： 通过perf查看ioctl主要是执行内存分配命令，由于Zlib Shim需要开辟连续的物理内存、所以出现频繁调用 compact_zone进行内碎片整理，其调用热的高达88.096%，如下图所示（注：热度表示该函数该函数自身的热度、调出： 表示被调用函数的热度总和、总体： 热度 + 调出）： 同Intel研发联调讨论后发现是由于当前Intel QAT的Zlib Shim的模型不合理所导致，通过推动其改造采用OOT的内存管理模块USDM（内部维护一个HugePage内存池）方案解决。 使用上述问题解决后的驱动intel-qatOOT31092，测试后发现CPU节省效果不佳（用户态CPU减少、但是增加了内核态的CPU），经分析、发现使用QAT加速后，部分系统函数CPU占比变高，如 open、ioctl、futex，如下图所示（注：左边的是使用QAT后各系统热点函数），使用QAT后open、ioctl、futex执行时间占比高达8.95（注：3.91 + 2.68 + 2.36），而未使用版本对应占比时间才0.44（注：0.24 + 0.14 + 0.06）； 分析其Tengine的worker进程堆栈信息发现open、ioctl都是成对出现（即一次http请求出现4次该系统调用），该现象反馈给Intel的研发同学后得知是由于新驱动的Zlib Shim导致，通过优化改造后open、ioctl调用频率明显减少。但是其futex系统调用频度却没有减少，还是导致内核态的CPU占比较高，通过strace跟踪发现一个http压缩请求后会多次调用futex、如下图所示，同Intel研发同学了解到Zlib Shim采用多线程方式，其futex操作来自zlib shim等待QAT压缩或解压缩数据返回的逻辑。 由于Tengine是多进程单线程、采用epoll异步IO事件模式，联调Intel的研发同学对Zlib Shim进行改造（去线程），最终futex系统调用也明显减少。 通过分析并推动Intel对QAT进行多次架构上的改造，才使得QAT的加速特性更好的发挥。 功能不完善 使用QAT后执行reload，可能导致请求响应异常，如下所示： 由于每个worker进程都需要分配一个QAT Instance用于数据解压缩，Tengine在reload的瞬间worker进程数可能会翻倍、而QAT Instance初始版本只有64个、所以新启动的worker进程可能分配不到Instance、导致请求失败。针对此问题Intel提供的新版本QAT，其Instance数量从64提高到256个避免此问题的发生，同时我们提出容灾保护方案：当Instance无法分配了需要自动降级为软件压缩，提高其可用性。 Zlib Shim huge page内存泄漏，导致QAT驱动core dump：Tengine使用内存池模式进行内存的管理，即调用(In)DeflateInit分配的空间无需调用(In)DeflateEnd处理、在请求结束的时候会调用请求r相关的释放操作，进行内存的归还，但是由于Zlib Shim使用的huge page必须调用(In)DeflateEnd才释放给USDM，通过改造Tengine Gzip相关代码后，该问题得以解决，而QAT驱动的core dump也是由于hugepage的泄漏导致无法成功分配导致。 Zlib Shim状态机不完善导致特定场景下的压缩、解压缩请求异常，等众多问题就不一一介绍。一路走来，通过无数次的性能优化、功能测试，多次同Intel研发同学一起探讨之后，才使得QAT在功能、性能、架构方面等众多问题得以快速解决，下面就准备上线前期准备工作。 运维梳理 部署发布采用单rpm软件包、双二进制模式，从而降低软件版与硬件加速版之间的耦合度，自动识别部署机器是否开启QAT，并选择正确的二进制执行； 容灾保护运行过程中由于某种资源的缺乏导致硬件加速版本Gzip执行失败，将会自动切换为软件版本、待资源可用时自动切换到硬件加速版本； 可维护与监控虽然上线前做过一系列压测、稳定性并未出现异常，但对硬件加速的相关资源指标进行实时监控还是必不可少； 加速效果 测试机器cpu型号：Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz 32核 内核：2.6.32 Zlib版本：zlib-1.2.8 QAT驱动版本：intel-qatOOT40052 数据对比同等条件下，开启QAT加速后CPU平均值为41%左右，未开启QAT加速的CPU平均值为48%左右，如下图所示： 相同条件下，开启QAT加速后系统load平均值为12.09，关闭QAT加速时系统load平均值为14.22，如下图所示： 相同条件下，开启与关闭QAT加速后，响应RT波动不相上下，如下所示： 同等条件下，各模块热点函数图对比如下所示，其中红色圈中的是Gzip相关函数（注：左侧是开启QAT加速）： 同比条件下Tengine Gzip使用QAT加速卡后，CPU消耗从48%下降到41%，系统负载load下降2个，且根据模块热点函数图对比发现Gzip基本上已经完全卸载。 场景 CPU消耗 系统负载load 响应时间RT（ms） 开启QAT加速 41% 12.09 58.88 关闭QAT加速 48% 14.22 59.47 结论综上数据对比，当qps为10k左右时Tengine Gzip使用QAT加速后CPU节省15%左右，且Gzip基本上完全卸载、随着其占比变高，优化效果将越好。 在双11零点高峰的考验下，接入层Tengine Gzip硬件加速机器运行平稳、同等条件下相比于未开启QAT加速的机器性能提升21%左右； 总结 接入层Tengine Gzip硬件加速项目是阿里存储技术Tair&Tengine团队及服务器研发计算团队与英特尔数据中心网络平台团队齐心协力下的产物，不仅带来了性能提升，而且使得接入层在硬件加速领域再次打下了坚实的基础、为明年SSL+Gzip架构上整合做好了沉淀，同时也填充了业内接入层对Gzip采用硬件加速的空白，对此领域的发展具有一定的影响意义。