随着搜索引擎巨头百度、谷歌等大力倡导网站https加密访问,以及加强互联网信息安全建设的需要，越来越多的网站、系统开始实现https加密。网站实现https加密需要用到SSL证书，那么网站SSL证书如何申请?如何选择SSL证书颁发机构等成为广大站长关心的问题，本文给大家介绍网站SSL证书如何申请以及具体的SSL证书申请流程。网站SSL证书如何申请?主要有下面几个步骤。1、生成证书请求文件CSRCSR(Certificate Secure Request)就是证书请求文件，站长进行SSL证书申请的第一步就是要生成CSR证书请求文件，系统会产生2个密钥，一个是公钥就是这个CSR文件，另外一个是私钥，存放在服务器上。要生成CSR文件，站长可以参考WEB SERVER的文档，一般APACHE等，使用OPENSSL命令行来生成KEY+CSR2个文件，Tomcat，JBoss，Resin等使用KEYTOOL来生成JKS和CSR文件，IIS通过向导建立一个挂起的请求和一个CSR文件。申请沃通SSL证书，在数字证书商店 已经支持CSR文件由系统自动生成，用户无需事先在Web服务器上生成CSR文件。2、选择CA机构申请SSL证书CA机构(Certificate Authority )，也就是SSL证书审核签发机构，也称证书授权机构，作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。如何选择CA机构呢?建议考虑以下几点：(1)全球可信，通过WebTrust国际认证。SSL证书通用性要好，支持更多的浏览器。(2)服务响应快速，24小时提供技术支持。因为SSL证书关系到网站的安全、可信、正常的运行，关系到网站的信誉和销售，一旦出现问题必须第一时间解决，所以要求CA厂商的服务和技术支持必须24小时提供。(3)支持中文和英文。因为国内大部分网站面向的客户群体是能看懂中文的客户群体，支持中文的SSL证书能够很好的提高客户对公司购买SSL证书保护其信息安全的认知度和公司品牌影响力。(4)性价比要高。因为SSL证书是网站特别是电商金融网站长期需要的信息安全基础保护措施，需要一定的成本，所以性价比也是要考虑的。3、将CSR提交给CA机构认证CA机构一般有2种认证方式：(1)域名认证。一般通过对管理员邮箱认证的方式，这种方式认证速度快，但是签发的证书中没有企业的名称，只显示网站域名，也就是我们经常说的域名型SSL证书。(2)企业文档认证。需要提供企业的营业执照。国外SSL证书申请CA认证一般需要1-5个工作日，国内比如沃通CA只需要一小时之内，紧急时5分钟，效率比国外SSL证书申请高很多。同时认证以上2种方式的证书，叫EV SSL证书，EV SSL证书可以使浏览器地址栏变成绿色，所以认证也最严格。EV SSL证书多应用于金融、电商、证券等对信息安全保护要求较高的领域。4、获取SSL证书并安装在收到CA机构签发的SSL证书后，将SSL证书部署到服务器上，一般APACHE文件直接将KEY+CER复制到文件上，然后修改HTTPD.CONF文件;TOMCAT等需要将CA签发的证书CER文件导入JKS文件后，复制到服务器，然后修改SERVER.XML;IIS需要处理挂起的请求，将CER文件导入。

前言由于微信小程序在体验版和上线版本，需要用https连接，所以你需要申请一个域名，并为这个域名申请证书。怎么利用acme.sh免费申请证书在上篇文章有提到利用acme.sh免费建立https连接，这里就记录一下Spring Boot中配置HTTPS，再利用Docker进行部署。实现步骤1.生成PKCS12格式的证书文件上一篇中acme.sh免费申请证书后会生成两个文件example.com.key和fullchain.cerexample.com.key是私钥文件fullchain.cer是包含公钥证书和中间证书链的证书文件把这两个文件放在同一目录下，并执行一下命令，合并成一个 PKCS12 格式的证书文件：openssl pkcs12 -export -in fullchain.cer -inkey example.com.key -out your_keystore.p12 -name your_alias复制代码your_keystore.p12 是你要生成的 PKCS12 格式的证书文件名your_alias 是你的证书别名然后会让你设置一个密码来保护生成的 PKCS12 格式的证书文件，这个密码要记下来！！！这时候当前目录下就会生成 your_keystore.p12文件2.配置application.yml文件先把证书文件放到application.yml同一目录下server: port: 9898 ssl:key-store-type: pkcs12 key-store: classpath:your_keystore.p12 key-store-password: xxxxxxx key-alias: your_alias复制代码3.Docker部署把打包好的jar包上传到服务器，并把证书文件也放在你服务器上在jar包目录生成一个Dockerfile文件，内容如下：FROM java:8-alpineARG JAR_FILECOPY 你jar包的名称.jar app.jarENTRYPOINT ["java","-jar","/app.jar"]复制代码在当前目录下执行构建，并部署sudo docker build -t <镜像名称> . #记得后面有个点 .我将镜像映射到我服务器的9898端口sudo docker run -d -p 9898:9898 -v /root/your_keystore.p12:/app/your_keystore.p12 -e "SERVER_SSL_KEY_STORE_TYPE=PKCS12" -e "SERVER_SSL_KEY_STORE=classpath:your_keystore.p12" -e "SERVER_SSL_KEY_STORE_PASSWORD=xxxxxx" -e "SERVER_SSL_KEY_ALIAS=your_alias" <镜像名称>复制代码/root/your_keystore.p12要替换成你证书所在服务器的地址SERVER_SSL_KEY_STORE，SERVER_SSL_KEY_STORE_PASSWORD，SERVER_SSL_KEY_ALIAS都要改成你自己的配置到这里已经完成所有的部署啦4.测试在postman或在网页中测试，输入https://example.com:9898就能看到数据啦但是对于微信小程序来说还没有可以正常发起连接5.服务器域名配置需要到官方的微信小程序后台的 开发管理 -> 开发设置-> 服务器域名配置将自己的域名配置上去，就完结撒花啦END恭喜你，看完这两篇文章，应该就能学会免费建立https连接，和前后端部署微信小程序，并进行联调了希望这篇文章可以帮助到有需要的小伙伴们，有问题可以评论或私信我呀

HTTP的前世今生HTTP是全球最大规模的分布式系统网络的基础之一，也采用了传统的服务器-客户端的通信设计模式。从1.0版本到1.1版本再到2.0版本，HTTP始终占据着分布式系统通信领域重要的一席之地。HTTP的设计思路首先，在报文编码方式上，HTTP采用了面向程序员的文本(（ASCII)编码方式而非面向计算机的二进制编码方式。该设计非常关键，这是因为文本编码数据很直观，文本编码协议甚至不用编写额外冗长的接口说明文档就很容易被程序员理解，也非常方便我们准备模拟数据编写单元测试，而当线上系统出现 Bug时，运维人员也很容易根据客户端记录的文本报文日志来快速定位故障。文本编码协议正因为有这么多优点，所以始终在网络协议中占据着重要的位置，而很多复杂的分布式系统可能会同时采用文本与二进制这两种编码方式的协议。其次，HTTP是无状态的请求-应答协议。在笔者看来，无状态的设计是个严重缺乏前瞻性的设计，但考虑到在HTTP诞生之初网上没什么资源，也根本不存在可以跟用户交互的网站，因此这个设计思路也是完全可以理解的。最初的HTTP (0.9版）只提供了GET方法，这是因为其作者认为网上所有的资源（网页）都是静态的，远程用户是不能修改的，浏览器所能做的就是从远程服务器上“获取（GET)”指定网页并以只读方式展示给用户，在用户获取网页之后就立即中断与服务器的连接，从而节省宽带和服务器的宝贵资源。随着Internet的加速发展，特别是图片和音视频等多媒体内容的出现和流行，原先只面向文本资源对象的HTTP已不能满足人们的需求，所以HTTP做了一个较大的升级（1.0版本):首先，增加了POST方法，使得客户端可以提交(上传）文件到服务器端;其次，通过引入Content-Type这个Header,支持除文本外的多媒体数据的传输支持。需要注意的是,此时在HTTP的报文里是可以出现二进制数据的，比如文件附件，但从整体来看，HTTP报文仍然是文本协议的报文，只是在报文的尾部可以增加一些二进制编码数据。在增加POST方法并且支持文件上传功能之后，在HTTP里出现了一个概率Bug 的设计。原本的问题如下:如果用户通过POST方式可以上传多个文件，那么我们应该怎么设计HTTP来支持它?”一个非计算机系的人面对这个问题，可能会这样考虑:既然HTTP一开始是没有考虑二进制传输的，那么现在的确存在二进制传输这种新的需求，所以我们应该考虑如何引入新的二进制传输协议来支持此需求，比如文件传输的数据可以用[文件名][长度][文件内容]这样的二进制编码格式定义，就很容易支持多个文件传输。但对于典型的“IT直男”来说，上面这种突变的设计与之前的设计格格不入，直接违背了他们遵循的一致性审美原则，同时增加了代码实现的复杂度，这就很难让人接受了。所以，他们把电子邮件协议(SMTP&Pop3）中处理二机制附件的做法照搬了过来。电子邮件协议采用的是文本协议,用一个随机生成的boundary字符串来区分多个文件(附件)的数据。这个boundary字符串虽然是随机生成的，也有一定长度，但谁也无法保证它永远不会跟文件内容中的一段字符串重复，这就导致了随机 Bug 的问题。很有意思的是，当初制定电子邮件协议的人们也从程序逻辑思维的角度制定出来一个无限层附件嵌套附件的协议规范。笔者当初开发Java版的邮件服务器时，特意模拟过一个3层嵌套的电子邮件，结果让163等常见的Web Mail都挂了，因为其无法识别嵌套的邮件附件。HTTP在1.0版本中引入了一个重要的设计，即在报文中增加了Header属性列表，每个Header都是一个Key/Value键值对，整个Header列表可以被视为一个 Map的数据结构，用来在客户端(浏览器)与服务器端传递控制类数据。由于Header 与请求或应答的正文内容相互独立，并且用户可以灵活扩展，增加新的Header属性，同时这些Header数据会被HTTP代理服务器透传到远程服务器中，所以用HTTP构建分布式系统具有其他应用层协议没有的独特优势。HTTP最大的优势可以一句话概括为:采用了HTTP作为通信协议的分布式系统天然具备了无侵入性的基础设施能力全面改进的优势。上述优势使得HTTP在大规模的分布式系统，特别是目前越来越热的云原生系统中得到应用。随着HTTP 2.0的进一步升级和发展，基于HTTP 2.0的微服务架构、服务网格风起云涌。所以理解HTTP，有助于我们深入理解常见的分布式系统架构的设计与原理实现。HTTP 如何保持状态我们都知道，HTTP在设计之初就是无状态的协议，但随着互联网的快速发展，越来越多的软件开始以 Web网站的方式提供服务，一个 Web网站同时服务成千上万个互联网用户。此时，编程人员开始面对一个棘手的问题，即如何识别同一个用户的连续多次的请求?比如在典型的网购行为中，客户登录系统，挑选商品，将商品添加购物车，最后下单付款。一个客户网购的整个过程会涉及几十次甚至上百次的网页交互，这就意味着我们必须为无状态的HTTP引入某种状态机制，而具体的实现机制就是HTTP Cookie。HTTP Cookie新增了两个扩展性的HTTP Header，其中一个是Set-Cookie。Set-Cookie是服务端专用的 Header，用来告知客户端（浏览器):“刚才的用户通过了身份验证，我现在设置了一个Cookie，里面记录了他的身份信息及有效期，你必须把它的内容保存下来，当该用户继续发送请求给我时，你自动在每个请求的HTTP Header上添加这个Cookie的内容后再发送过来，这样我就可以持续跟踪这个用户的后续请求了，请务必遵守要求，直到Cooker有效期结束才能删除Cookie，我不想用户反复登录及证明身份。”下面是一个典型的Set-Cookie的完整内容，其中，id给出了用户的标识，Expires部分则指出了该Cookie的有效期，有效期越长，用户越方便，但风险越大:Set-Cookie: id-a3fWa;Expires=Wed,21 0ct2015 07:28:00 GMT;Java开发人员最熟悉的是下面这种Set-Cookie例子:Set-Cookie: jsessionid=5AC6268DD8D4D5D1FDF5D41E9F2FD960; Expires=Wed,21 0ct2015 07:28:00GMT;Secure; Httponly注意，jsessionid是Tomcat服务器用来标识用户的，而其他JEE Server 各有各的名称，在PHP中则通常使用phpsessionid。浏览器在收到服务器的响应时，会检查在响应报文中的Header里是否有Set-Cookie指令，如果有,就会遵守规范,从中抽出相关的Cookie信息,并且在该用户随后的HTTP请求的Header中自动加入新的Cookie Header，再发送给服务器端。下面是一个对应的例子:Cookie: jsessionid=5AC6268DD8D4D5D1FDF5D41E9F2FD960服务器在收到上述请求后，就会检查Cookie里的数据，抽取用户ID 并对应到服务器端的用户会话(Session）对象。通常在Session中会保存更多的用户数据，比如用户的昵称、角色、权限及更多的特定数据。与在 Cookie中保存的数据相比，在Session中保存的内容通常是一些复杂的对象和结构体。因此，Cookie与Session 的关系再清楚不过了:一个用来在浏览器端保存用户状态数据，一个则用来在服务器端保存用户会话数据，两者相辅相成，实现了有状态的HTTP。对于Cookie，我们需要注意以下事实。Set-Cookie可以多次使用，并且可以放置更多的 Key-Value数据，其中的每一个Key-Value数据项都是一个独立的 Cookie，服务器通常会传送多个不同的Cookie到浏览器端，每个Cookie都对应特定的业务目标。Cookie的值虽然都是字符串,但可以很长,具体多长呢?RFC规范没有给出具体的值，但一些测试表明，绝大多数浏览器都支持4096个字节长度的Cookie的内容。Cookies 的内容是需要被保存在浏览器中的，通常浏览器会用本地文件保存这些Cookie的内容。同时，服务器端需要提供Session对象，因此用户的状态是由浏览器与服务器双方配合实现的，任何一方的缺失都会导致用户状态信息的缺失。在Cookies中不要存储用户的敏感（机密）信息，特别注意不要存储用户的明文密码，但可以考虑存储某种安全加密的信息，并且定期自动更新，避免被盗用和破解。一个有趣的问题:在开发电商（类似的）系统时，我们是否可以把用户的购物车列表数据放入Cookie中呢?会带来哪些意想不到的好处?又面临哪些新问题?欢迎探讨。Session的秘密对于很多Web开发人员甚至架构师来说，服务器端的Session很神秘:只知道应用服务器会给每个用户都创建一个 Session会话来保持其状态，可以放置任意对象到Session中，也可以查找这些对象来实现业务逻辑判断并渲染用户页面，但往往不太清楚其具体工作原理和工作机制。1.Session究竟是什么Cookie是由RFC6265标准规范规定的一个概念,有对应的呈现标准和呈现方式,总体来说，我们可以将Cookie理解为HTTP的一部分，因此所有人都可以准确理解、表达并且进行标准化实现。与Cookie不同，Session属于Web应用开发中一个抽象的概念，它对应Cookie，用来在应用服务器端表示和保存用户的信息。但是，Session并没有标准化的定义及实现方式，因此在不同的 Web编程语言里都有不同的理解和实现方式，即使在同一种 Web编程语言中，不同的应用服务器的实现方式也有所不同。这就导致了一个显而易见的事实:不同厂家的应用服务器不通过某种第三方手段是无法做到“单点登录”的，虽然单点登录存在Session、鉴权和相互信任的复杂问题。2.Session是在什么时候被创建的从前一节Cookie的分析中我们知道，Set-Cookie指令是服务器第一次验证用户身份后回应给浏览器的，此时服务器已经生成用户的身份信息（如 jsessionid)，因此我们可以确定一个事实:该用户对应的Session 会话此时也生成了，并且由我们的Web Server 控制整个生命周期。3.Session 中的数据被存储在哪里Session中的数据通常被存储在应用服务器的内存中，准确理解这一点对于我们编程和设计架构来说很关键!哪些用户数据适合被放在Session中?能放多少数据?什么时候清理这些数据?对于这些问题的答案，需要综合考虑业务层面的要求、性能及内存占用等几个关键因素。这里主要分析Session中数据占用服务器内存对系统所造成的影响,因为我们在具体实践中经常忽略了这个问题，导致Session被滥用。在用户量突然增加以后，很多系统都无法支撑高并发，会出现内存溢出的严重问题，而且这个问题很难从根本上解决，只能在前期加以规范和引导并在开发阶段予以杜绝。以电商系统的购物车为例，如果我们把用户购物车对象放入Session 中，则以Java为例，定义如下数据结构（对象):public class ShopCartItem{ private long id; private String title;private long picId;private double price; private short count; }以ShopCartItem的title为10个中文字符为例,则上述Java对象占据的实际内存将超过2000个字节，而不是几十个字节!一个用户的购物车里平均有5件商品，则每个用户的购物车对象占用的内存超过1万个字节，如果我们有10万个用户，则仅这些用户的购物车对象占用的内存将达到1GB左右!考虑到这还是个很简单的Java对象，当我们把某些翻页查询的结果集都随意放入Session中时，后果会有多严重?这也是为什么目前Go这种非面向对象的编程语言会在Web 服务器领域发力并且对Java造成一定的冲击。从上面的分析结果来看，面对大规模的用户访问，我们能做的有以下几方面。尽可能少放“大尺寸”的数据在用户Session中，并且尽可能及早清除无效数据，释放Session占用的内存。考虑到把更多的Session数据转移到浏览器端的Cookie中，所以通过“甩锅”方式减少服务器端的压力。前端积极采用HTML5技术，Cookie不适合用于大量数据的存储，并且Cookie每次都会被增加到HTTP的请求头中并传输到服务器端，这也增加了网络流量的压力，因此HTML5提供了在用户端的浏览器中存储数据的新方法: localStorage与 sessionStorage,后者就是专门解决服务器端Session存储难题的“利器”。考虑到引入分布式存储机制，所以可以采用集群方式来应对单一服务器的Session存储瓶颈。再谈Token通过前面的学习,我们知道用户会话中的用户身份标识(如SessionID)信息被存放在Cookie中并保留在用户端的浏览器上。实际上，Cookie的内容是被存放在磁盘中的，其他人是有可能直接访问到Cookie文件的;另外，Cookie中的信息是明文保存的，意味着攻击者可以通过猜测并伪造Cookie数据破解系统。避免这种漏洞的直接防护手段就是用数字证书对敏感数据进行加密签名，在加密签名后这串字符串就是我们所说的Token，这样攻击者就无法伪造 Token了，因此Token在本质上是Session (SessionID)的改进版。与Session将用户状态保留在服务器端的常规做法不同，Token机制则把用户状态信息保存在Token字符串里，服务器端不再维护客户状态，服务器端就可以做到无状态，集群也更容易扩展。那么，Token 数据是被放在哪里的呢?标准的做法是将其放在专用的 HTTP Header“X-Auth-Token”中保存并传输，但客户端在拿到Token以后可以将其在本地保存，比如在 App程序中，Token信息可以被保存在手机中，而Web应用中，Token也可以被保存到H5的 localstorage中。需要注意，Token与Cookie是完全无关的!总结下来，Token有以下特点。在Token中包含足够多的用户信息，JWT能轻松实现单点登录，因为用户的状态已经被传送到了客户端。不存在 Cookie跨域的限制问题，也不存在Cookie相关的一些攻击漏洞，例如 CSRF。因为有签名，所以JWT可以防止被篡改。适用于API的安全机制，适用于移动客户端与PC客户端的开发，此时Cookie是不被支持的;Token方案则简单有效，可以用一套Token认证代码来应对浏览器类客户端和非浏览器类客户端。Token已经标准化，有成熟的标准化规范——JSON Web Token (JWT)，多种主流语言也都提供了支持（如.NET、Ruby、Java、Python、PHP)。目前被广泛使用的JWT规范是一个轻量级的规范，每个完整的JWT对象实际上都是一个字符串，它由三部分组成:头部（Header)、载荷( Payload）与签名（Signature)，其中 Header声明了该JWT所用的签名算法是哪种:对称加密算法(HMAC SHA256，简称HS256）还是非对称加密算法(RSA)。需要注意的是，虽然JWT支持对称加密算法来做签名，但正常情况下，我们都应该使用非对称加密算法即私钥来签名，并且我们要妥善保管私钥，谨防泄密，客户端用公钥证书去验证签名。Payload部分是我们重点关注的内容，我们可以将Payload理解为一个Map字典，里面的exp字段表明JWT的失效时间，是确保安全的重要字段。此外，我们可以在Payload里增加自定义的私有字段，用来保存更多的用户特定信息，特别注意的是，Payload是明文传输的，所以我们不能把私密信息放入Payload里，比如用户密码。Signature部分则是将Header 与 Payload 的内容加在一起，用在 Header 里声明的签名算法进行签名而得到的一个字符串，即完整的JWT字符串组成为:Header(明文) .Payload(明文） . Signature(签名/密文)。任何一方在收到这个JWT字符串的Token后,都可以通过解析得到Header 与 Payload的完整内容。为了证实这两段信息是否是某个组织所发出的真实信息，我们可以用该组织的公钥证书对签名信息进行验证。JWT标准是不加密的，但我们可以再加密，即在生成原始JWT Token后再把这个字符串当作普通字符串加密,但这种做法的意义不大,因为加密解密会涉及大量CPU计算，增加系统的负载。此外，我们需要注意，JWT一旦签发，在有效期内将会一直有效，有效期的长短也会影响安全的级别。因此，可考虑不同安全等级要求的API接口给予不同时效的Token，对于某些重要的API接口，用户在使用时应该每次都进行身份验证。为了减少盗用和窃取，JWT不建议使用HTTP来传输代码，而是使用加密的HTTPS传输代码。如何采用JWT Token机制代替普通的Session机制呢﹖答案很简单，就是在用户访问时拦截请求，检查HTTP Header 中的Token是否有效，如果无效则重定向到登录界面，在登录成功后，服务端生成JWT Token 并将其放入Header中返还客户端，客户端保存JWT Token并在随后的请求里带上Header 发起访问即可，如下图所示。注意，如果Token接近失效时间，则需要重新访问服务端获取新的Token。Client在访问系统的内部Service时,通过API网关来完成统一的服务鉴权功能。首先,Client通过Auth Server 获取合法的Token;然后，持有此Token，在后面发起服务调用请求时都带上此Token;在API网关拦截到请求时，先验证Token的有效性，再转发请求到具体的Service。如果想要更深入地了解JWT相关的技术与应用，则建议继续学习OAuth 2.0与OpenID 的相关技术。分布式Session最早的成熟的分布式Session技术被应用于J2EE领域,主要采用Session复制的技术(SessionReplication)将用户会话的数据复制到J2EE集群的其他机器上。考虑到复制的代价和内存占用成本，一个用户的Session通常只会被复制到集群中的一台服务器上，即主从复制模式。这种方式类似于MySQL 的主从复制技术，当集群中的机器数量多于2台时，必须要求前置的负载均衡器（软件或硬件）支持会话亲和性(Session Affinity)，可以准确地把不同用户的请求转到对应的两台服务器上。应用Session复制技术的典型代表之一是Weblogic Server，但是Session复制的技术从总体来看相对复杂，而且集群的整体性能下降很明显，因此在J2EE领域之外很少被使用。另外一种应用更广泛的分布式Session技术就是把Session数据彻底从应用服务器中“剥离”，单独集中存储在外部的内存中间件（如 Redis、Memcache、JBossCache)中，这样做的好处是整体架构更加清晰，也更加灵活，集群的数量可以轻松达到几十台甚至上百台的规模。同时，整个系统的运维变得更有条理性，故障排查和故障恢复也更为容易。采用这种分布式Session的系统，其整体规模、性能、特性主要取决于不同的后端存储中间件的能力。目前应用非常广泛的后端存储为Redis，并通过Redis集群来获取更大规模的用户量支持能力。如下图所示是一个典型的基于Spring Boot的分布式Session集群架构案例。HTTP与Service MeshService Mesh可以说是当前最热门的一个架构了，自带云原生的光环，一经问世就立刻吸引了Google与 IBM这两个软件巨头，他们联合发起了相关的重量级开源项目——Istio。不过，在Service Mesh的各种实现类产品中一致选择了HTTP作为服务之间的基础通信协议，而不是其他二进制通信协议。并且，Service Mesh的核心功能或特性几乎全部依赖HTTP的特性才得以实现。为什么呢?笔者的答案是:围绕HTTP建立一个所有编程语言都适用的、高度统一并且足够灵活的微服务架构，是非常容易成功的选择。所以，Service Mesh 从一开始就是围绕HTTP而“精准”构建的新框架!如下所示是一张简化版的Service Mesh架构图，在该图中特意将SideCar(边车）画成U型，这是为了方便表示Sidecar其实“包围但又不是完全包裹”它对应的Service实例的这一关键特性。即在进程角度，Sidecar是完全独立的进程（可以是一个或多个)，与对应的Service实例不产生任何进程和代码级别的纠缠，非常像一个独立进程的代理。考虑到我们的Service其实是一个HTTP服务器进程（微服务)，我们可以理解把 SideCar理解为一个特殊定制的Nginx 代理。另外一个细节需要注意:进入任意一个Service实例的请求都要从SideCar 代理后才能抵达 Service实例本身，在这个过程中，SideCar可以做任何 HTTP能做的事情，比如黑白名单的检查、服务限速及服务路由等功能，这些恰恰就是Service Mesh的核心特性之一。而借助于HTTP的特性，整个过程无须修改业务代码本身，只需要配置一些规则（类似于Nginx的配置）即可生效。下面以Service Mesh的核心功能之一服务路由为例来简单说明其中的实现原理。在如下所示的示例中，Service B有两个实例。ServiceB的虚拟地址为http:/lserviceb:8080，两个实例的地址分别为 http://192.168.18.1:8080 及 http://192.168.18.2:8080，当Service A调用ServiceB时会有路由选择问题。此时，Service A 上的SideCar会配置类似于如下路由规则（示例):Route To :http://serviceb:8080Endpoints: http://192.168.18.1:8080 http://192.168.18.2:8080然后，当ServiceA发出对ServiceB的服务调用(HTTP请求http://serviceb:8080)时, ServiceA的SideCar 代理进程先通过iptables规则“劫持”这一请求，在对照自己的路由配置规则后发现有两个地址，于是按照默认的轮询机制选择一个目的地址转发出去。比如到达了192.168.18.2这台机器，此时Service B对应的SideCar进程也采用同样方式“劫持”进来的请求流量，在经过一定的处理逻辑后，再转给Service B进程处理。这就实现了基本的负载均衡功能。在这个过程中，已有的用户业务进程如Service A、Service B等都无须有任何代码改造，这一切都通过基本的HTTP代理机制即可完成。其他诸如金丝雀流量控制，比如有10%的流量到某个服务的升级版本，有90%的流量到老版本，以及基于不同的终端用户(或者HTTP URL&Param)来实现更细粒度的路由控制，这对HTTP的代理来说简直是小菜一碟。我们知道，大规模的分布式系统都存在一个很难解决的问题，即一旦在运行中出现性能问题或者故障，则很难快速诊断和发现问题的成因。因为在微服务架构下，一个调用链从终端到达最终的服务端，中间可能跨越十几个远程调用，这意味着我们需要把分布在这十几台机器上的独立请求都“精确串联”起来，才能知道问题出在哪个环节。解决这个问题的思路有以下两种。第1种思路，在编程时在调用发起的地方手工生成唯一的TraceID，确保这个TraceID被正确传递到后端的所有调用;准确记录每段调用的耗时、是否异常等必要诊断信息，并在日志中打印出来;最后通过日志分析和汇总每条链路的信息。第2种思路，采用面向AOP编程的思路，由框架来实现第1种思路的所有编程。毫无疑问，第⒉种思路是最好的，但这里面临一个棘手的问题:如何在不侵入业务代码的情况下完整地将每个TraceID都传输到后面的调用过程中?答案是用HTTP的自定义Header来实现统一注入TraceID和其他相关参数,并通过SideCar 的代理拦截能力去实现所需的细节和数据收集工作。可以说，Service Mesh之前的任何一种通用的分布式架构都没能完美解决安全问题，除了ZeroC Ice。很巧的是，二者实现安全机制的做法异曲同工，都是通过自动包裹（代理)SSL安全连接来实现远程调用的安全加密能力。其中,ZeroC Ice采用的是SSL+TCP; Istio等主流ServiceMesh的实现则采用了HTTPS+HTTP来实现自动加密功能，这些只需简单配置文件和CA证书即可实现。本文给大家讲解的内容是架构解密从分布式到微服务：深入理解网络，HTTP的前世今生本文就是愿天堂没有BUG给大家分享的内容，大家有收获的话可以分享下，想学习更多的话可以到微信公众号里找我，我等你哦。

在保护您的 Web 应用程序时，SSL 证书是您需要考虑的最重要因素之一。SSL 证书是浏览器和搜索引擎用来验证网站真实性的数字证书。如果没有 SSL 证书，任何人都可以轻松冒充您的网站并窃取敏感的用户数据。如果您的应用程序可供网络外部的用户使用，那么您还必须使用 SSL 证书。这样，您就可以相信用户正在连接到您的服务器，而不是可能伪装成它的人。这篇文章将涵盖所有内容，从如何生成您自己的 SSL 证书，以便您可以使用 SSL 加密来保护您的应用程序和 HTTPS 链接。到最后，您将准确了解如何使用 SSL 加密设置和保护您的 Node.js 应用程序。什么是 SSL 证书？SSL 证书代表安全套接字层证书是一种数字证书，可在 Web 浏览器和 Web 服务器之间启用加密通信。数以百万计的在线企业和个人使用它来降低敏感信息（例如，信用卡号、用户名、密码、电子邮件等）被黑客和身份窃贼窃取或篡改的风险。有两种类型的 SSL 证书：自签名：由应用程序生成并用于测试环境CA 签名：由 CA（证书颁发机构）生成和签名。它用于生产。在这篇文章中，我们将重点关注自签名 SSL 证书。设置 Node.js 开发环境在生成我们自己的 SSL 证书之前，让我们创建一个简单的 ExpressJs 应用程序。要创建一个新的 Express 项目，让我们创建一个名为node-ssl -server 的目录，并使用此命令在终端中打开node-ssl-server目录。cd node-ssl-server 复制代码然后运行这个命令来初始化一个新的 npm 项目：npm init --y 复制代码现在让我们安装依赖项 ie express ，为此运行此命令：npm install --save express 复制代码现在让我们在 package.json 中创建一个启动脚本，只需将这一行添加到“script{}”中，如下所示："scripts": { "start":"node index.js" }, 复制代码将 index.js 文件添加到我们的应用程序并在其中添加几行，如下所示：const express= require('express') const https=require('https') const fs=require('fs') const path=require('path') const app=express(); app.use('/',(req,res,next)=>{ res.send('hello I am SSL Server !') }) const options={ key: '', cert: '' } const sslServer=https.createServer(options,app); sslServer.listen(1337,()=>{ console.log('Secure server is listening on port 1337') }) 复制代码让我们生成 SSL 证书在我们继续之前，让我们创建一个目录来将证书存储在我们的应用程序文件夹中。mkdir cert 复制代码现在使用 cd 命令移动到 cert 目录：cd cert 复制代码要生成 SSL 证书，我们需要按照以下步骤操作：生成私钥使用私钥创建 CSR（证书签名请求）。从 CSR 生成 SSL 证书生成私钥要生成私钥，我们需要在本地计算机上安装OpenSSL，这是一个用于传输层安全性 (TLS) 和安全套接字层 (SSL) 协议的全功能工具包。这些文章可以帮助您安装它。Windows - Ubuntu。安装完成后，我们需要运行如下所示的命令来生成私钥：openssl genrsa -out key.pem 复制代码运行上述命令后，它将生成私钥并将其保存在 cert 目录内的key.pem文件中，并在终端中提供此类消息。Generating RSA private key, 2048 bit long modulus ...+++ .................+++ e is 65537 (0x10001) 复制代码创建 CSR（证书签名请求）由于我们是自己的证书颁发机构，因此我们需要使用 CSR 来生成我们的证书。为此，我们需要运行以下命令。openssl req -new -key key.pem -out csr.pem 复制代码运行此命令后，它会询问几个问题，如下所示：如果您想提供可以提供的详细信息，您可以通过简单地按 enter else 来跳过任何问题，这完全取决于您。完成这些问题后，它将在cert文件夹内的 csr.pem文件中生成 CSR 。**生成 SSL 证书现在进行最后的步骤，我们需要使用key.pem和csr.pem文件来生成我们的 SSL 证书。让我们运行下面的命令来生成它。openssl x509 -req -days 365 -in csr.pem -signkey key.pem -out cert.pem 复制代码注意：我们使用 x509，因为它是定义公钥证书格式的标准。我们将证书的有效期设置为 365 天。运行上述命令后，它将证书保存在 cert 文件夹内的cert.pem文件中。 现在您可以删除csr.pem文件，也可以保留它。在 Express 中集成 SSL 证书现在让我们使用文件系统 (fs) 和路径模块在我们的应用程序中使用这些证书。为此，我们需要在我们的应用程序中编辑几行，如下所述。早些时候我们创建了一个常量变量选项。现在我们将通过在其中添加生成的证书的路径来更新该部分代码，如下所示。前：const options = { key:'', cert:'' } 复制代码后：const options = { key:fs.readFileSync(path.join(__dirname,'./cert/key.pem')), cert:fs.readFileSync(path.join(__dirname,'./cert/cert.pem')) } 复制代码完成后保存并运行服务器：npm start 复制代码您可以通过从这个 URL 访问它来检查 HTTPS 是否正常工作：https://localhost:1337结论尽管我们有一个有效的证书，但您可能会在浏览器中看到“不安全”，这只是因为我们已经生成了证书，而它不是由某些已知的证书颁发机构生成的，因此，您的浏览器不信任您作为有效证书权威。但是我们通常应该将此过程用于开发目的，而对于生产，我们应该使用由证书颁发机构生成的证书。

一 背景随着越来越多的国际通用密码算法屡屡被传出被破解、被攻击的传闻，存在较高的安全风险。此外，当前我国金融系统大多采用国外制定的加密算法，存在着大量的不可控因素，一旦被不法分子利用攻击，所产生的损失将不可估量。所以国密改造提上日程。国密SSL通信依据的协议是中国人民共和国密码行业标准《SSL VPN技术规范GM/T 0024--2014》协议(链接)。其协议流程和传统的使用RSA证书的TLS协议流程基本一致，但是过程中使用的核心算法已经全部切换到国密相关的算法实现上，为了保证通信的安全监管机构开始推动国内金融行业进行国密改造。我们和客户一起进行了多个国密项目的改造之后，这里整理了国密HTTPS 和国密SSL 相关知识，做下分享。二 国密SSL/TLS1. HTTPS首先标准的 HTTPS （Secure Hypertext Transfer Protocol）是由HTTP + SSL/TLS组成的安全超文本传输协议，利用 SSL/TLS 加密数据包，经 HTTP 进行通信。其设计主要目的是，提供对网站服务器的身份认证、保护交换数据的隐私与完整性。HTTPS安全是由一套安全机制来保证的，主要包含这4个特性：机密性、完整性、真实性和不可否认性。 机密性：指传输的数据是采用Session Key（会话密钥）加密的，在网络上是看不到明文的。完整性：指为了避免网络中传输的数据被非法篡改，使用MAC算法来保证消息的完整性。真实性：指通信的对方是可信的，利用了PKI（Public Key Infrastructure 即『公钥基础设施』）来保证公钥的真实性。不可否认性：无法伪装和否认，使用了签名的技术来保证的。2. SSL/TLSSSL（Secure Socket Layer） 1994年由 浏览器开发商Netscape（网景通信公司） 率先倡导研发，为数据通讯提供安全支持，开发了最初的几个版本SSL 1.0、SSL 2.0、SSL 3.0。TLS（Transport Layer Security）前身为SSL，1999年从 3.1 开始被 IETF（Internet Engineering Task Force，Internet）标准化并改名，发展至今已经有 TLS 1.0、TLS 1.1、TLS 1.2、TLS 1.3 四个版本。目前互联网上被广泛使用的是TLS 1.1、TLS 1.2、TLS 1.3，TLS 协议的版本号v1.0 表示为0x0301，v1.1表示为0x0302，以此类推。值得一提的是，在TLS 1.3 中 client version 字段仍旧是 0x0303（v1.2 的一致），而是使用了supported_versions这个扩展来标识对于TLS v1.3的支持。国密 SSL 规范主要是基于TLS v1.1版本，部分内容基于 TLS v1.2 版本，即是TLS 1.1和TLS 1.2的混合体，为了避免冲突选择了版本号 0x0101。这在实现上带来一定的麻烦，现有很多网络库会认为这是一个无效的协议版本，需要一一将判断修改过来。3. 国密SSL握手清楚了国密SSL 的协议后，我们就可以完整的看一下国密 SSL/TLS 的握手过程了，国密SSL/TLS 握手的过程大致可分为以下几个步骤：Client HelloClient——>Server 客户端向服务端发送 Client Hello 消息。Server HelloServer——>Client 服务端向客户端发送 Server Hello 消息。CertificateServer——>Client 服务端下发 公钥证书。Server Key ExchangeServer——>Client 服务端下发秘钥交换的额外数据。Server Hello DoneServer——>Client 服务端握手信息发送完毕。证书合法性校验Client 对 Server下发的公钥证书进行合法性校验。协商加密秘钥Client——>Server 协商计算客户端、服务端通信的 加密秘钥enc_key，包括Client Key EXchange、Change Cipher Spec Protocol、Encrypted Handshake Message 三块流程。Change Cipher Spec ProtocolServer——>Client 服务端告知客户端后续的通信都采用协商的 秘钥enc_key 与 （商定的）算法 进行加密通信。Encrypted Handshake MessageServer——>Client 服务端用 秘钥enc_key 加密，发出的第一条加密消息。Application DataClient——>Server SSL/TLS 握手完成，所有后续通信均采用 秘钥enc_key 加密。国密SSL/TLS 完整握手流程如下图所示：4. 国密 Wireshark 抓包普通的wireshark 抓TCP/IP 包只能抓标准TLS 协议的，国密SSL/TLS 的版本号为 0x0101，默认会认为这是无效版本号，好在已经有支持国密版本的wireshark 版了，下面从抓包结果一步步查看国密SSL/TLS 的请求过程。4.1. Client HelloClient Hello（ Client——>Server ）： 客户端向服务端发送 Client Hello 消息。消息中包含客户端的 TSL版本信息、秘钥随机数、加密套件候选列表、压缩算法候选列表、扩展字段等信息，相关信息抓包如下：各字段详细描述如下：Version : TSL协议版本；Random：随机数 random_C 用于后续的密钥协商;Session ID：有或者无，有则客户端传上一次session的id可以恢复session；Cipher Suite：客户端支持的密码算法列表，供服务器选择；Compression Methods：客户端支持的压缩算法列表，用于后续的信息压缩传输；extensions：扩展字段；4.2. Server HelloServer Hello（ Server——>Client ）： 服务端向客户端发送 Server Hello 消息。消息中包括服务端选择使用的TSL协议版本、选择的加密套件、选择的压缩算法、服务端生成的随机数等，相关信息抓包如下：Version：服务器选择的版本；Random：随机数 random_S 用于后续的密钥协商;Session ID：有或者无，有则客户端传上一次session的id可以恢复session；Cipher Suite：服务端选择的密钥算法；Compression Methods：服务端选择的压缩算法；4.3. CertificateCertificate（ Server——>Client ）： 服务端下发 公钥证书 给客户端。相关信息抓包如下：Certificate: 服务端的公钥证书；4.4. Server Key EXchangeServer Key Exchange（ Server——>Client ）: 该消息的目的是 携带 密钥交换 的 额外数据。该消息在协商的不同的算法套件会存在差异：对于使用DHE/ECDHE非对称密钥协商算法的SSL握手，服务器发送其使用的DH（DH密钥交换）参数；国密算法采用的是ECDHE（在RSA 算法、DH、ECDH不会发送server key exchange，DH、ECDH 是非前向安全性，已逐步废弃）。4.5. Server Hello DoneServer Hello Done（ Server——>Client ）:通知 Client，Server端已经将所有握手消息发送完毕。4.6. 证书校验客户端拿到 服务端 的 公钥证书 后，需对该证书的合法性进行校验。校验内容如下：证书链的可信性；证书是否吊销；证书有效期；证书域名校验，核查证书域名是否与当前的访问域名匹配;4.7. 协商通信秘钥Client——>Server： 这里包含三步，主要是协商计算客户端、服务端通信的加密秘钥。Client Key Exchange：Change Cipher Spec：Encrypted Handshake Message：Client Key Exchange证书合法性验证通过之后，客户端产生随机数字 Pre-master。计算生成秘钥 enc_key {Fuc(random_C, random_S, Pre-Master) } 。将 Pre-master 与 enc_key 用 证书公钥加密（非对称算法）发送给服务端;Change Cipher Spec Protocol客户端 通知 服务端 后续的通信都采用协商的 秘钥enc_key 和商定好的 加密算法 进行加密通信;Encrypted Handshake Message客户端：客户端将之前 所有的握手数据（包括接受、发送）生成摘要；然后用 秘钥enc_key 加密（对称算法），发送给对应的服务端。服务端：服务端收到消息后，会用 秘钥enc_key 解密 客户端的摘要信息；然后用与客户端相同的算法生成 服务端摘要信息，最后对比两个摘要信息相同，则验证通过。4.8. 服务端告知客户端并发送加密消息Server——>Client： 这里包含两步：Change Cipher Spec Protocol: 服务器同样发送 Change Cipher Spec Protocol 告知客户端后续的通信都采用协商的 秘钥enc_key 与 算法 进行加密通信;Encrypted Handshake Message：服务端：服务端会将握手过程的消息生成摘要再用 秘钥enc_key 加密，这是服务端发出的第一条加密消息;客户端：客户端接收后会用 秘钥enc_key 解密，能解出来说明协商的秘钥是一致的。4.9. Application DataApplication Data Client——>Server ）： 双方已安全地协商出了同一份 秘钥enc_key，所有的应用层数据都会用这个秘钥加密后再通过 TCP 进行可靠传输。三 国密证书校验1. 数字证书1.1. 证书规范数字证书简单的理解就是被信任的认证机构颁发且符合制定规范的数字签名证书，目前使用最广泛的证书是标准为ITU和ISO联合制定的X.509的 v3版本规范 (RFC5280）， 其中定义了如下证书信息：X.509数字证书：CertificateVersion Number （版本号）Serial Number （序列号）Signature Algorithm ID （证书签名算法ID）Issuer Name （证书颁发者）Validity period （证书有效时间）Subject name （证书主体名称）Subject Public Key Info （证书主体公钥信息）Public Key Algorithm （证书公钥算法）Subject Public Key （证书公钥）Issuer Unique Identifier (optional) （发行商唯一ID）Subject Unique Identifier (optional) （主体唯一ID）Extensions (optional) （扩展）Certificate Signature Algorithm （证书签名算法）Certificate Signature （证书签名值）1.2. 国密证书目前国密证书也是采用的x509 规范格式，证书后缀一般用pem 或者cer。编码格式分为:X.509 DER(Distinguished Encoding Rules)编码，后缀为：.der .cer .crtX.509 BASE64编码(PEM格式)，后缀为：.pem .cer .crtDER 二进制格式的 Base64 编码，并在编码头尾加上起始行 -----BEGIN CERTIFICATE----- 和结束行 -----END CERTIFICATE-----可以使用openssl 工具命令：openssl x509 -in ca.pem -inform pem -noout -text，将证书内容解析出来，下面是某一国密CA 证书的解析内容示例：Certificate:    Data:        Version: 3 (0x2)        Serial Number:            32:7d:61:de:92:84:90:e2:f2:ea:c3:2a:67:ec:3d:d2:ef:54:6d:b1    Signature Algorithm: 1.2.156.10197.1.501        Issuer: C=CN, O=\xE5\x8C\x97\xE4\xBA\xAC\xE5\xA4\xA9\xE5\xA8\x81\xE8\xAF\x9A\xE4\xBF\xA1\xE7\x94\xB5\xE5\xAD\x90\xE5\x95\x86\xE5\x8A\xA1\xE6\x9C\x8D\xE5\x8A\xA1\xE6\x9C\x89\xE9\x99\x90\xE5\x85\xAC\xE5\x8F\xB8, CN=vTrus SM2 Root CA G1        Validity            Not Before: Sep 15 09:13:37 2020 GMT            Not After : Sep 15 09:13:37 2040 GMT        Subject: C=CN, O=\xE5\x8C\x97\xE4\xBA\xAC\xE5\xA4\xA9\xE5\xA8\x81\xE8\xAF\x9A\xE4\xBF\xA1\xE7\x94\xB5\xE5\xAD\x90\xE5\x95\x86\xE5\x8A\xA1\xE6\x9C\x8D\xE5\x8A\xA1\xE6\x9C\x89\xE9\x99\x90\xE5\x85\xAC\xE5\x8F\xB8, CN=vTrus SM2 OV SSL CA        Subject Public Key Info:            Public Key Algorithm: id-ecPublicKey            Public-Key: (256 bit)                pub:                     04:c9:22:69:31:8a:d6:6c:ea:da:c3:7f:2c:ac:a5:                    af:c0:02:ea:81:cb:65:b9:fd:0c:6d:46:5b:c9:1e:                    ed:b2:ac:2a:1b:4a:ec:80:7b:e7:1a:51:e0:df:f7:                    c7:4a:20:7b:91:4b:20:07:21:ce:cf:68:65:8c:c6:                    9d:3b:ef:d5:c1                ASN1 OID: prime256v1                NIST CURVE: P-256        X509v3 extensions:            X509v3 Subject Key Identifier:                 E2:8E:F7:A1:B3:95:65:83:52:D6:C1:37:19:C1:DE:71:17:05:A4:AA            X509v3 Authority Key Identifier:                 keyid:E2:A5:14:62:46:BD:C6:E4:7D:FF:FD:E6:1B:F5:4E:B7:7E:31:45:7D            X509v3 Basic Constraints: critical                CA:TRUE, pathlen:0            X509v3 Key Usage: critical                Certificate Sign, CRL Sign            X509v3 Extended Key Usage:                 TLS Web Server Authentication, TLS Web Client Authentication            Authority Information Access:                 OCSP - URI:http://vtocsp-CDN.itrus.com.cn/ocsp/ocsp/ocsp                CA Issuers - URI:http://vtca-cafiles.itrus.com.cn/ca/vTrusSM2RootCAG1.cer            X509v3 CRL Distribution Points:                 Full Name:                  URI:http://vtca-cafiles.itrus.com.cn/crl/vTrusSM2RootCAG1.crl            X509v3 Certificate Policies:                 Policy: X509v3 Any Policy                  CPS: https://www.itrus.com.cn/repository    Signature Algorithm: 1.2.156.10197.1.501         30:45:02:20:41:11:a8:06:e0:78:b0:0c:fd:06:22:cd:0b:cf:         68:38:85:bb:3c:04:6d:27:6e:80:72:8e:3a:e8:e3:32:a6:4d:         02:21:00:b4:81:62:9c:3f:af:12:46:d2:8e:a2:90:e0:5a:0b:         7b:7f:28:96:8d:d6:7c:4f:8a:12:59:3e:3e:3c:35:ae:842. 国密证书校验客户端（预置有CA 国密证书）验证服务端下发的证书，主要包括以下几个方面：校验证书是否是 受信任 的 CA根证书 颁发机构颁发；校验证书是否在上级证书的 吊销列表；校验证书 是否过期；校验证书 域名 是否 一致。2.1. 证书可信性校验国密证书是否可信：校验国密证书是否是由受信任的CA根证书颁发机构颁发（目前只要是CFCA）。为了确保 客户端 获取到的 服务端公钥 不被篡改，需要权威的 CA 机构。CA机构负责 核实 公钥 拥有者 信息、颁发证书 (对服务端公钥进行签名)、同时为使用者 提供证书验证 服务。服务方S 向第三方机构CA 提交公钥、组织信息、个人信息(域名)等信息并申请认证;（不交私钥）CA 通过线上、线下等多种手段 验证 申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等；如信息审核通过，CA 会向申请者签发认证文件（证书）。证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构CA的信息、有效时间、证书序列号等信息的明文，同时包含一个签名；签名算法：首先使用散列函数计算公开的明文信息的信息摘要，然后使用 CA的私钥 对信息摘要进行加密，密文即签名；客户端 C 向服务器 S 发出请求时，服务器 S 返回证书；客户端 C 读取证书中的相关的明文信息，采用相同的散列函数 计算得到 信息摘要，然后用本地信任的 CA证书公钥 解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即公钥合法；客户端 然后验证证书相关的域名信息、有效时间等信息;证书 = 公钥（服务方生成密码对中的公钥）+ 申请者与颁发者信息 + 签名（用CA机构生成的密码对的私钥进行签名）;2.2. 证书吊销CA机构 能够 签发证书，同样也存在机制 宣布 以往签发的 证书无效。若证书的申请主体出现：私钥丢失、申请证书无效等情况，CA机构需要废弃该证书。证书是有生命周期的，如果私钥泄漏了那这个证书就得吊销，主要存在两类吊销方式：CRL 与 OCSP。CRL（Certificate Revocation List）证书吊销列表：是一个单独的文件，该文件包含了 CA机构 已经吊销的证书序列号与吊销日期；证书中一般会包含一个 URL 地址 CRL Distribution Point，通知使用者去哪里下载对应的 CRL 以校验证书是否吊销。该吊销方式的优点是不需要频繁更新，但是不能及时吊销证书，因为 CRL 更新时间一般是几天，这期间可能已经造成了极大损失。OCSP（Online Certificate Status Protocol）证书状态在线查询协议：一个实时查询证书是否吊销的方式。请求者发送证书的信息并请求查询，服务器返回正常、吊销或未知中的任何一个状态。证书中一般也会包含一个 OCSP 的 URL 地址，但这就要求查询服务器需要具有良好的性能。2.3. 证书过期校验证书的有效期是否已经过期：主要判断证书中 Validity period 字段是否过期。3. 国密证书链在 CA 根证书和服务器证书中间增加一级证书机构，即中间证书，证书的产生和验证原理不变，只是增加一层验证，只要最后能够被任何信任的 CA根证书 验证合法即可。服务器证书、中间证书与根证书在一起组合成一条合法的证书链，证书链的验证是自下而上的信任传递的过程。中间证书结构存在的优势：减少根证书结构的管理工作量，可以更高效的进行证书的审核与签发;根证书一般预置在客户端 中，私钥一般离线存储，一旦私钥泄露，则吊销过程非常困难，无法及时补救;中间证书结构的私钥泄露，则可以快速在线吊销，并重新为用户签发新的证书;证书链四级以内一般不会对 HTTPS 的性能造成明显影响。3.1. 证书链特点同一本服务器证书可能存在多条合法的证书链。 因为证书的生成和验证基础是公钥和私钥对，如果采用相同的公钥和私钥生成不同的中间证书，针对被签发者而言，该签发机构都是合法的 CA，不同的是中间证书的签发机构不同;不同证书链的层级不一定相同，可能二级、三级或四级证书链。 中间证书的签发机构可能是根证书机构也可能是另一个中间证书机构，所以证书链层级不一定相同。3.2. 证书链校验客户端 通过 服务器证书 中 签发机构信息，获取到 中间证书公钥；利用 中间证书公钥 进行 服务器证书 的签名验证。中间证书公钥解密 服务器签名，得到证书摘要信息；摘要算法计算 服务器证书 摘要信息；对比两个摘要信息。客户端 通过 中间证书 中 签发机构信息，客户端本地查找到 根证书公钥；利用 根证书公钥 进行 中间证书 的签名验证。四 小结通过上面章节描述，我们已经清楚的了解了国密HTTPS 和国密SSL 链路的完整机制。目前市场上已有的国密厂商种类繁多，有纯提供硬件的厂商、软件国密资质的厂商、和提供后端硬件及对应软件接入的厂商。为了能解决客户国密SSL 改造的需求，我们也对市场主流的国密厂商的实现机制、方案等做了考察和研究，后面会整理一篇对应的国密改造实践文档也一并分享，谢谢。

前言前期有讲过Tomcat和Nginx分别部署SSL证书，但也有好多小伙伴们私信我说，帮忙出一期宝塔面板部署SSL证书的教程，毕竟宝塔的用户体量也是蛮大的，于是宠粉的博主，当然会满足粉丝的任何要求啦～如果有帮助，请点赞收藏➕关注哦～证书下载我们先需要到腾讯云后台的SSL证书里，下载SSL证书，这里就选择腾讯云宝塔面板，点击下载。这里就给一个直达下载地的链接：https://console.cloud.tencent.com/ssl/dsc/detail?id=vH4bBk8C#下载到本地计算机解压后，文件夹内会有这四种文件cloud.tencent.comt_bundle.crt 证书文件cloud.tencent.com_bundle.pem 证书文件（本安装部署流程中不使用，可忽略）cloud.tencent.com.key 私钥文件cloud.tencent.com.csr CSR 文件注释：cloud.tencent.com 为演示域名，实际上为你的域名。宝塔配置SSL接下来，我们可以进入到宝塔面板内：如图所示，进入到项目的设置内：在弹出的“ 站点修改” 窗口中，依次单击 SSL > 其他证书，填写密钥以及证书文件。如下图所示：然后我们分别在密钥（KEY）和证书（PEM格式）内填入，刚刚下载好的证书文件内容。密钥（KEY）：使用文本编辑器打开 .key 私钥文件，并复制内容至对应区域，证书（PEM 格式）：使用文本编辑器打开 .crt 证书文件，并复制内容至对应区域。然后单击保存并显示以下信息，即可部署成功。部署成功后，即可使用 https://您的域名 进行访问。如果浏览器地址栏显示安全锁标识，则说明证书安装成功。如下图所示：注意事项防火墙需要提前开启443 和 80 端口，并且服务器上的安全组需要放开443和80端口证书不要下错了，记得有个小伙伴私信博主，让博主帮忙排查问题，结果最后发现下的证书是Nginx的证书。哭笑不得。整体来说，宝塔上部署SSL证书，还是比Nginx和Tomcat部署要容易许多的，跟着教程走，应该不会出错，如果有问题，欢迎骚扰博主哦～

1. 引言自 2013 年 ALLIN 无线到今天，已经走过 10 个年头，手淘终端统一网络库 AWCN (Ali Wireless Connection Network) 从淘内孵化，一路过来伴随着手淘业务的发展，经历集团 IPv6 战役、协议升级演进等，逐步沉淀为阿里集团终端网络通用解决方案，是兼具高性能、多协议、可容灾、可观测的终端网络基础统一设施。面对移动互联网络下复杂多变的网络环境，如何提供更稳定可靠的请求性能，保障用户的加载浏览体验、更好的支撑业务发展，是我们始终探索的命题。本文将介绍淘宝 APP 统一网络库演进的过程，讲述如何围绕体验持续构建南北向从监测到加速一体化的终端网络架构，通过构建 NPM 弱网诊断感知能力，落地原生多通道技术/多协议择优调度手段，贴合厂商附能网络请求加速，实现去 SPDY 及规模化 IPv6/H3 协议簇的平滑过渡，为用户提供弱网更好、好网更优的 APP 加载浏览体验，支撑业务创造更多的可能性。2. 终端架构介绍2.1 MobileSDN 理念在介绍 AWCN 之前，笔者想先这里普及下 SDN 架构的概念。SDN（Software Defined Network，软件定义网络） 是一种将网络资源抽象到虚拟化系统中的 IT 基础架构，SDN 将网络转发功能与网络控制功能分开，其目标是创建可集中管理和可编程的网络，核心理念是 希望应用软件可以参与对网络的控制管理，满足上层业务需求，简化使用和运维成本。有一个较为形象的类比，如果说现在的网络系统是功能机，系统和硬件出厂时就被捆绑在一起，那么 SDN 就是 Android 系统，可以在很多手机设备上安装&升级，同时还能安装更多更强大的手机 App（SDN 应用层部署）。回到移动应用领域，我们的目标是搭建统一的终端网络解决方案，上层业务不需要关心内部的协议如何转发、请求超时降级等复杂逻辑，做到好用、易用、可观测、体验好。显然，这与传统 SDN 架构理念不谋而合。2.2 AWCN 终端网络架构因此，围绕以上理念和目标，我们进一步构建起南北向从监测到加速一体化的 MobileSDN 架构，以减少业务的接入/运维成本，提升用户的浏览体验。从 MobileSDN 架构展开来，接下来简要介绍下各分层模块承担的角色与其中作用。网络应用：面向多种应用场景衍生出的网络组件，如统一 RPC 网关（MTOP）、消息 PUSH 通道（ACCS）、上传（AUS）、下载（TBDownloader）、图片加载（Phenix）、远程配置（Orange）等能力；网络北向接口：上层调用和内部实现的桥梁，提供统一同步/异步对外 API 接口和无痕 Hook 方式，用于上层网络应用/业务场景接入调用网络基础能力；网络控制器：请求策略管控中心，架构大脑，负责请求端到端链路的调度和优化决策，有着举足轻重的作用，控制器提供完备的网络加速能力，从节点调度/连接选择/请求管理多个环节进行网络请求加速；网络南向接口：控制面与基础协议转发的桥梁，对协议及数据进行了通用抽象，以应对不同系统框架/不同协议的统一处理；网络协议转发：多个基础协议和网络框架的统一适配实现，兼容各类请求场景下的最优选择调度，支持标准 HTTP/1.1、HTTP/2、HTTP/3，以及集团自研的 HTTP/2+SSSL 和 H3-XQUIC 协议；网络性能管理：网络数据及性能观测中心，NPM（Network Performance Management），负责设备网络状态/质量/信号强度的感知、业务请求数据的统计上报、PING/TRACE/NSLookup 等网络时延探测诊断、用户网络诊断/请求抓包等工具建设。2.3 行业分析纵观行业内一些与之对标的移动网络框架，如腾讯维纳斯 WNS、微信 Mars、Chromium cronet、Square Okhttp 等，AWCN 和它们在一些思路上可以说是殊途同归，通过提供更优的 IP 策略调度、多协议连接管理策略及请求超时等控制加速请求，建设网络诊断、网络质量监控等手段加强网络可观测能力。微信 Mars：STN 负责请求任务管理/IP 排序/网络策略等能力优化请求体验，SDT 为网络诊断模块，一定程度上与 AWCN 中网络控制器、网络性能管理两块部分承担角色相近。2.4 规模总览淘宝统一网络库作为基础组件在集团内被广泛应用，集团内涵盖千级以上规模应用支撑，包含且不限于手淘、闲鱼、优酷、天猫、Lazada、高德、UC浏览器、饿了么等 APP，同时通过阿里云 EMAS、友盟对三方应用开放接入，如海底捞/杭州银行等企业应用。作为移动网络解决方案，网络请求的体验是重中之重，因此，笔者将重点讲述网络控制器如何围绕请求构建完整链路上的加速技术，介绍如何从节点调度/连接选择/请求管理/系统调度进行业务网络体验优化，确保请求在各类复杂网络状况下高可用。3. 网络加速体系详解前面提到，网络控制器是作为整体架构上的大脑，承担着请求端到端链路的调度和优化决策，相当于掌舵手和发动机的角色。一次完整的请求网络传输大致可以分为以下链路，即DNS->建连->发送数据->等待首包响应->接收数据，过程中 IP 策略调度、连接管理、请求管理及厂商全局调度加速子模块各承担着不同的作用，笔者将逐一介绍阐述。IP 策略调度：负责 IP/节点的选择和调度，职责是选择最优的 IP 策略，减少 DNS 带来的耗时，同时具备切流容灾的能力；连接及协议管理：负责连接池生命周期的管理和各类协议的选择，职责是连接择优且高可用；请求管理：负责请求的调度，涵盖超时、降级、重试恢复等流程控制，职责是让请求更快的被执行；厂商加速：负责对接各大厂商系统侧的网络能力，结合系统赋予的网络加速能力（如更精准的网络质量状态/双频 WiFi 聚合加速/流加速等），进一步优化复杂网络下请求调度的策略决策，是自研与厂商原生网络能力之间的沟通枢纽。3.1 IP 策略调度：减少 DNS 耗时，选择更优 IP众所周知，传统的 LocalDNS 方式存在各类隐患问题，如：解析慢/失败率高、更新不及时、域名劫持、缺少精准流量调度及容灾能力，AMDC（Ali Mobile Dispatch Center）是阿里自建的无线域名解析调度服务，在手淘和集团绝大多数应用中广泛应用。依托 HTTPDNS 实现无线调度功能就够了吗？远没有那么理想化，如何在端侧处理好 IP 策略的选取/容灾/安全性/服务 QPS 压力等环节，都至关重要。IP 选取及缓存汰换策略IP 选择机制上，基于服务下发+端侧动态排序的机制运行服务端下发：根据单元化/运营商/就近接入/网络协议栈等维度，下发一组可用的 IP 列表。同时具备通过端侧跑马算法，生成最优的策略 IP。端侧动态排序：根据端侧 IP 策略使用记录（成功&失败&耗时等维度）进行优先级排序，建连错误次数多的策略在排序优先级上进行降权操作，与之相对应的，建连成功率高性能好的策略优先级提高。缓存和汰换机制上，考虑到频繁 AMDC 调度带来服务压力、异步请求 AMDC 带来的生效率问题，端侧对策略进行了缓存，根据用户网络粒度进行独立存储，应用启动和网络事件切换情况下加载所需的策略记录；根据前面所提及的建连记录动态排序能力，自然也产生了对应的淘汰替换机制。淘汰机制：同一 IP 在 5min 中连续失败 xx 次，进入禁用淘汰的情况更新机制：域名粒度携带 TTL（Time To Live）下发，超过 TTL 的域名进行异步更新，同时更新机制按照域名的优先级也拥有不同的模式。新态势下的挑战及升级CASE 1：高版本设备对于 WiFi 网络唯一标识的获取限制前面提及的端侧缓存策略基于用户网络粒度做独立存储，对于 WiFi 网络环境 BSSID 是端侧的标识主键，但随着系统升级带来的一系列用户权限收敛：Android 8 及以上版本开始，需要用户授权定位等权限，才可以拿到 Wi-Fi SSID/BSSID 等相关信息，否则返回 02:00:00:00:00:00 默认值iOS 14 起，必须接入 network extension，否则无论通过任何手段都无法获取到 wifi 相关信息，对接 NE 成本太高。这意味着现有网络存储结构不再具备唯一标识用户网络的能力，无法正常获取 BSSID 信息的这些设备上存在着策略混用，甚至跨运营商的问题，从而导致请求性能变慢/出现异常，线上约有 20%+的用户受潜在影响。因此，对于端侧无法直接获取 BSSID 的设备，引入新的存储主 key，即用户无线接入点 AccessPoint 信息，流程涉及 AMDC 端到端协同升级，大致流程如图所示。数据上，图片等 CDN 类请求平均耗时优化 4.439%，耗时分位 P90 优化1.932%，P99 优化 2.230%，P999 优化 2.668% 。CASE 2: 应对更复杂协议/更精细化调度诉求下的协议演进当现有协议结构无法满足日益复杂和精细的调度诉求，且无法在现有模型上持续长期迭代时，就需要对协议进行重构升级。我们在移动网络虚拟化项目中切实遇到如上的问题，协议重构对于端上来说，是对整个存储数据模型的改变，这意味着升级新协议的用户可能无法继续使用旧版本存储策略，直接丢弃老协议存储是最简单有效的手段，但这会导致升级后一段时间内用户出现降级 LocalDNS 的问题，这对我们不能容忍。重新实现一个协议不难，难的是如何确保新老协议平稳升级过渡，避免请求出现 LocalDNS 降级。因此，方案的关键在于如何对新老协议做数据迁移，其中涉及升级链路和降级链路(如稳定性问题功能回退场景)。3.2 连接管理：更快建连，保障连接高可用连接建立除了常规的串行建连和并发建连方式，我们提供了热域名预建和复合连接的方式，应对各种复杂的场景。热域名预建机制：启动场景下的关键请求加速复合连接机制：IPv6 规模化背景下的体验保障当手淘作为 IPv6 示范性应用跑在最前面时，我们发现国内存在部分双栈网络 IPv6 质量差甚至不通的情况，Android 的舆情反馈尤为突出，原因在于 iOS 系统侧实现了 Happy Eyeballs 机制确保快速 rollback 回 IPv4 链路，而 Android 设备没有。复合连接思路也因此来源于 IPv6 Happy Eyeballs 算法实现，详见RFC 6555[1]。When a server's IPv4 path and protocol are working, but the server's IPv6 path and protocol are not working, a dual-stack client application experiences significant connection delay compared to an IPv4-only client. This is undesirable because it causes the dual-stack client to have a worse user experience. This document specifies requirements for algorithms that reduce this user-visible delay and provides an algorithm.复合连接的两个核心目标：双栈环境体验：从 IPv6 和 IPv4 中为用户选择一个最快的链接，且保证优先使用 IPv6减少后端压力：避免同时对两地址发起请求，造成网络破坏；数据上，针对 MTOP 和图片请求，双栈情况下其建连性能平均耗时降低 22.12%，99 分位性能降低 60.19%，请求数据平均耗时降低了1.23%，P99 分位耗时降低 6.077%。连接调度按照不同的通道应用场景，连接可以区分为两种形态，保活连接与常规连接。保活连接：需要时刻保证连接存活，随时可用，适用于上下行推拉结合的场景，如消息；常规连接：不需要时刻保活，空闲及时回收减少资源占用，适用于仅主动上行调用的场景，如 RPC。针对建立好的连接，不同形态的维护管理方式也不同。面向保活可用：假连检测，动态心跳通过对连接的多场景可用性检测，增强连接质量的感知，当出现连接异常时能够快速的恢复重建。检测的手段基本为心跳 PING 包方式，分位定时心跳（前后台间隔不同）、分场景心跳（切换前台、业务上行超时等）。面向空闲回收：闲时状态检查，及时关闭对于不需要主动下行推送的场景，建连时刻保持对于用户带宽和功耗存在一定影响，因此针对此类连接增加了空闲状态的检查，当发现建连超过一定时间没有数据包传输时会进行连接的关闭回收，以减少资源占用，释放有限带宽。3.3 请求管理：弹性超时控制，请求补偿恢复动态超时精细控制：在请求各个链路上，具有独立超时控制，每个阶段精细化控制，快速感知超时情况；动态调配：针对 不同域名请求/网络类型/不同质量 的环境下动态超时时长处理。多路竞争&择优选用对于请求超时或慢的场景，AWCN 会通过多种方式进行择优选用和请求补偿，确保链路最优，保障体验：传输协议：运营商对于 HTTP/3（UDP）的网络质量保证远不及 TCP，常常遇到各类 UDP 穿透性、请求超时等问题，因此必要时需快速决策，切回 HTTP/2、HTTP/1.1 的 TCP 传输链路；底层框架：自研传输库(TNET)带来的好处是协议的自建和调优，但也因此导致协议非标(如 HTTP/2+SSSL 私有加密协议)，运营商拦截丢包、端到端链路稳定性等问题，必要时决策回退至系统原生库；网络通道：以往对于用户网络不通导致的问题，优化的手段有限，但随着系统开放多通道选择的能力之后，上层也拥有了切换网络通道的能力，当检测 WiFi 不通环境下，会将请求切换至蜂窝网络通道恢复。以传输协议择优选用为例，对于 H3 协议在手淘的规模化过程用户体验不受损，AWCN 网络库建立起完善的择优选用和补偿兜底机制。3.4 厂商加速：拥抱原生，系统级调度加速近年来，国内几家厂商前后对上层应用开放了系统级的网络优化能力，包括网络带宽调度、数据流加速、QoE 状态反馈、弱网预测、双 WiFi 聚合能力等，从系统侧调度提升请求性能。厂商能力融合的思考与决策作为淘宝终端网络基础设施，一直以来我们都专精于应用策略及协议上，致力如何更好的调度、管理连接/协议让请求更快。随着国内厂商的发展，我们发现，脱离厂商的自研之路并不顺畅：一方面，不同厂商的限制和表现异同常让我们对各厂商做一些 hack 和兼容性的事情；另一方面，用户的网络资源有限，手淘作为单一应用，能调配和控制的资源有限。如何扩大我们的调度域得以让我们的应用内请求更好，是我们常在思考的事情。因此我们选择拥抱厂商，通过系统赋予的调度加速能力，深度合作，为应用提供更好的网络体验。为了屏蔽不同厂商之间的能力差异和接入方式不同，AWCN 提供厂商加速模块的通用能力抽象，通过运行期对不同设备和厂商能力的解决，动态组织支持的系统能力列表。目前，我们已经和 OPPO 完成接入和上线工作，协同厂商侧紧锣密鼓的放量验证中。4. 手淘弱网破障实践4.1 指标定义：明确弱网/卡顿请求过往我们基于网络请求 1s 法则作为优化的指标衡量，目前业务请求秒出率超过 95%，当网络体验进入深水区，弱网/长尾等卡顿负向请求成为我们关注和突破重点。通过梳理完整请求的调用链路，我们在思考如何通过指标化的方式衡量出这部分对业务/用户体验有损的请求，在明确目前线上相关负向卡顿请求的规模的前提下，再进行进一步的优化及效果观测。因此，基于用户/业务视角，将请求全链路阶段内出现异常报错、耗时长尾定义为卡顿请求：异常报错：失败的请求，无论何种原因失败，网络超时、服务端未返回等；耗时长尾：响应超过 xx 秒未返回、没有结束的请求。4.2 诊断体系：更快识别、定位各类复杂网络问题经常有一些线上用户反馈网络类的舆情：为什么 WIFI 下访问慢，切换到 4G 网络就恢复了？我的网络没问题，为什么手淘等淘系应用加载慢，其他 APP 正常？为什么 xx 页面加载很慢，其他页面没问题？。。。其中导致的原因很多，如用户路由器的配置、淘系域名被营商 IP 封禁、业务调用链路超时等，为了更好的定位/分析各类网络类问题， 我们针对移动互联网下用户网络类体验问题的复杂性，进一步建设 NPM 诊断技术体系，加强相关技术和数据的应用。领域模型：用户体验问题的技术面穷举拆解、沉淀；能力构建：诊断原子能力及工具链，运维提效；规模应用：多维用户网络数据，IPv6/MTU/UDP 大盘。4.3 弱网技术：复杂网络下的网络体验针对移动复杂网络环境，除了前面网络加速体系所提到的相关能力之外，这里笔者将重点对典型弱网靶向性优化技术展开。4.3.1 网络多通道：手淘规模化应用当请求没有响应/接收慢的情况下，一般会触发超时机制进行请求重放。但在用户 WIFI 信号差&弱网环境下，我们反而要谨慎重试，一方面重试会加重系统上的负载，另一方面重试会导致请求重新开始，对弱网传输慢的情况不友好，反而加剧卡慢的情况。因此，在寻求更友好的方式上，我们发现系统提供了一种多通道传输的能力，即允许设备在 WIFI 环境下将请求切换蜂窝网卡的能力，网络应用层可以利用该技术，减少请求的超时等一类错误，提升请求的成功率。优化数据目前多通道技术在手淘核心浏览链路上已规模化应用，严格按照AB 实验得出数据，双十一期间双端日对请求超时率减少 30%以上。4.3.2 原生 HTTP/2：突破系统限制，实现 H2 协议支持相对于 HTTP/1.1 协议，HTTP/2、HTTP/3 的协议性能优势不言而喻，HTTP/2 协议在手淘和集团内早已支持多年，HTTP/3 协议同样在持续规模扩量中，但目前手淘内仍然存有 10%左右 HTTP1.1 流量。通过分析，主要有以下原因导致：HTTP/2 协议非标准化实现，加密方式为私有 slight-ssl，域名支持需服务端部署，未明确知晓是否支持的域名只能走 HTTP/1.1 协议；鉴于非标的影响，请求链路上需要强依赖 AMDC，必须通过 AMDC 配置明确支持 h2+sssl 方式的域名下发后才能支持；非标协议的兼容性存在小概率问题，个别运营商针对非标协议会进行劫持处理导致请求失败降级到短连。过往很多业务反馈，为什么域名在 chrome 浏览器上访问支持 HTTP/2，而手淘里是仍然是 HTTP/1.1 的原因就在于此。那么，如何在不需要服务端部署、不强依赖 AMDC 的前提下，让请求实现长连加速？标准 HTTP2 的实现是必经之路。如何支持标准 HTTP/2？iOS 通过升级 URLSession 系统调用方式，可低成本的迁移到 H2/H3 协议上，但对于 Android 来说，系统侧提供的 HttpUrlconnection 仅支持到 HTTP/1.1 协议。因此，灵魂三问：标准协议的完整实现，必然要加入人力投入开发，稳定性验证和上线是一个较长的周期，如何减少支持的成本？考虑引入稳定的能力实现，如 Okhttp。稳定库引入必定会增加包大小，这对目前严控包大小的现状有较大冲突，如何解决？需尽可能不增加包大小的情况下支持。既要考虑成本和稳定性验证等规模化问题，又要避免给手淘包大小过大的增幅。既要马儿跑，又要马儿不吃草。如何实现？源码突破通过对系统源码的分析，我们发现 Android 系统 5.0 之后，系统 API HttpUrlconnection 底层已经通过 okhttp 进行托管实现，也就是说 Android 系统本身支持通过 okhttp 访问不需要额外引入三方库进行，只要找到可以 hook 的点。灰度过程我们发现一些因为 Okhttp 导致的 IndexOutOfBoundsException 稳定性问题，bug 来源于特定场景下没有拿到证书列表且未对容器判空导致，详细记录在：https://github.com/square/okhttp/issues/4208。官方在版本 3.12.2+上修复，但 android 源码仍使用 2.x 版本导致无法修复。了规避系统侧问题，我们摒弃 okhttp 提供异步调用的 api，改为同步调用+异常捕获+上层转异步的方式进行处理。此外，针对不同应用，若存在三方 okhttp 依赖，会自动桥接到三方实现上，体验高版本 okhttp 的稳定性；对于手淘这种不依赖三方 okhttp 的应用，再桥接到系统版本实现。优化数据标准 H2 升级率先在 Feeds 接口域名覆盖，农场整体舆情月环比下降 23%，请求耗时优化 21.4%，成功率提升 0.3pt。4.4 小结截至目前，日改善卡顿请求(网络错误/耗时>x 秒) PV 10 亿+ ，达成全年目标 10 亿(统计口径严格按照 AB 实验桶对比计算)，MOTP 请求超时率较去年 4 月优化了近50%。5. 后续方向与展望对于移动网络体验的探索是无止境的，今年我们围绕弱网和体验加速做了一些工作，有些内容因为篇幅和侧重点考虑所以没有进一步展开讲述，后期再通过另外专题文章进行侧重讲解。但即便如此，面对亿万用户各类复杂多变的环境，仍存在着加载慢、卡顿、空白的声音，作为淘宝和集团统一的终端基础网络设施，如何让用户浏览体验再更上一层楼，我们要做的还很多。5.1 更精准的网络状态感知准确掌握用户的网络状态是一切手段的前提，以往我们围绕 NPM 搭建诊断体系，对端到端链路的连通性和质量进行检测，在实时性、准确度和可用性仍有提升空间。结合厂商系统侧更精准可靠的网络质量反馈：依托提供 QoE 网络质量能力，提供更实时的 WiFi/蜂窝网络信号质量和强度反馈;提供用户更友好的网络感知手段：当用户出现“潜在”的网络问题，我们希望大部分情况用户可以自行知道哪里出问题、怎么解决。

在腾讯云打开控制台-ssl证书，然后下载下载好的证书解压后会有四个目录文件，分别对应不同服务器版本，我们这里是Apache，打开Apache文件夹，将里面证书文件改名上传到服务器/etc/httpd/ssl目录下：然后在服务器端安装Apache的SSL模块（yum install -y mod-ssl）打开/etc/httpd/conf.d目录下的ssl.conf配置文件设置https监听端口 443设置服务器名称端口配置SSL证书，配置对应如下，记得修改后的文件对应文件SSLCertificateFile /etc/httpd/ssl/2_www.domain.com_cert.crt SSLCertificateKeyFile /etc/httpd/ssl/3_www.domain.com.key SSLCertificateChainFile /etc/httpd/ssl/1_root_bundle.crt重启服务器，然后浏览器输入https://www.你的域名.com访问成功即可！

@toc1、前提条件服务器已经开启了443端口(HTTPS服务的默认端口)服务器上已安装了http_ssl_module模块2、nginx安装http_ssl_module模块2.1 查看是否安装过http_ssl_module进入nginx安装目录执行如下命令./nginx -V若出现“--with-http_ssl_module”说明已经安装过，否则继续执行下列步骤2.2 进入nginx源文件目录cd /usr/local/nginx/nginx-1.18.0/2.3 重新编译nginx./configure --with-http_ssl_module再执行如下命令：make这里一定不要执行make install,否则会覆盖掉原来的nginx2.4 用新的nginx覆盖旧的会多一个objs文件夹执行覆盖命令(先停止nginx,./nginx -s stop) cp ./objs/nginx /usr/local/nginx/sbin/3、https配置(SSL证书安装)3.1 下载证书文件和密钥文件我自己用的百度云的免费SSL证书，下载证书，这里格式选择PEM_Nginx解压完之后有两个文件，如下所示。证书文件（以.cer或crt为后缀或文件类型）密钥文件（以.key为后缀或文件类型）3.2 服务器上创建cert文件夹在nginx的安装目录创建cert文件夹，并将下载的证书文件，和密钥文件拷贝到cert目录中。这里我创建到了nginx/conf下面了，这是试了好几次报错后的结果。3.3 配置nginx.conf打开Nginx安装目录 > conf文件夹 > nginx.conf文件，在nginx.conf文件中找到以下属性将注释放开，并修改内容如下： # 以下属性中以ssl开头的属性代表与证书配置有关，其他属性请根据自己的需要进行配置。 server { listen 443 ssl; server_name codeleader.top; # localhost修改为您证书绑定的域名。 # ssl on; #设置为on启用SSL功能。 root html; index index.html index.htm; ssl_certificate cert/codeleader.top.crt; #将domain.pem替换成您证书的文件名。 ssl_certificate_key cert/codeleader.top.key; #将domain.key替换成您证书的密钥文件名。 ssl_session_timeout 5m; ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4; #使用此加密套件。 ssl_protocols TLSv1 TLSv1.1 TLSv1.2; #使用该协议进行配置。 ssl_prefer_server_ciphers on; location / { proxy_pass http://halo; proxy_set_header HOST $host; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }这里我并没有隐藏我的域名，希望懂行的大佬不要恶意攻击，我也只是用服务器部署小项目测试，并不是生产服务器，攻击对您也没啥收益。3.4 设置http请求自动跳转https在需要跳转的http站点下添加以下rewrite语句，实现http访问自动跳转到https页面#设置http请求自动跳转https rewrite ^(.*)$ https://$host$1 permanent;3.5 重启测试./nginx -s reload证书安装完成后，可通过登录证书绑定域名的方式验证证书是否安装成功。https://domain:port #domain替换成证书绑定的域名,默认443端口可以忽略不输入如果网页地址栏出现绿色小锁标志，表示证书安装成功。

python秒起https 文件服务器前几天博客有个秒级启动http web服务器： python -m http.server 6666 结果有同事想要求换成https web服务器，所以就有了下文文章在这里：python实现秒级启动http、ftp服务器一、windows版本：1.安装opensslopenssl官方下载地址下载msi版本，一路下一步，最后一步全部取消勾选，这里有坑配置环境变量就和python一样了第二天我会上传到工作群，openssl安装包2.生成证书openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout key.pem -out cert.pem3.启动https服务# coding=utf-8 """ @Project ：pachong-master @File ：httpserver.py @Author ：gaojs @Date ：2022/8/17 22:29 @Blogs : https://www.gaojs.com.cn """ import http.server import ssl def https_web_server(): """ https服务器 :return: """ server_ip = 'localhost' # 这里port不要写成字符串，我刚开始给成字符串，报错搞了好一会 server_port = 5001 server_address = (server_ip, server_port) # 生成证书步骤： # openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout key.pem -out cert.pem server_cert = "./cert.pem" server_key = "./key.pem" httpd = http.server.HTTPServer(server_address, http.server.SimpleHTTPRequestHandler) httpd.socket = ssl.wrap_socket( httpd.socket, server_side=True, certfile=server_cert, keyfile=server_key, ssl_version=ssl.PROTOCOL_TLS) print("Server HTTPS on " + server_ip + " port " + str(server_port) + " (https://" + server_ip + ":" + str(server_port) + ") ... ") httpd.serve_forever() if __name__ == '__main__': https_web_server() 4.结果如下二、linux版本1.生成证书我这里使用的是阿里云的镜像，所以默认自带opensslopenssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout key.pem -out cert.pem2.启动https服务器# coding=utf-8 """ @Project ：pachong-master @File ：httpserver.py @Author ：gaojs @Date ：2022/8/17 22:29 @Blogs : https://www.gaojs.com.cn """ import http.server import ssl def https_web_server(): """ https服务器 :return: """ server_ip = 'localhost' server_port = 5001 server_address = (server_ip, server_port) # 生成证书步骤： # openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout key.pem -out cert.pem server_cert = "./cert.pem" server_key = "./key.pem" httpd = http.server.HTTPServer(server_address, http.server.SimpleHTTPRequestHandler) httpd.socket = ssl.wrap_socket( httpd.socket, server_side=True, certfile=server_cert, keyfile=server_key, ssl_version=ssl.PROTOCOL_TLS) print("Server HTTPS on " + server_ip + " port " + str(server_port) + " (https://" + server_ip + ":" + str(server_port) + ") ... ") httpd.serve_forever() if __name__ == '__main__': https_web_server() 三、加入腾讯云自媒体分享计划我的博客即将同步至腾讯云开发者社区，邀请大家一同入驻：https://cloud.tencent.com/developer/support-plan?invite_code=1otwwvb9ht470