标签：公钥 加密 证书 秘钥 非对称 加密技术 服务端 客户端

本章是《隐私计算加密技术基础》系列文章的最后一篇，感慨下，终于写完了，这个春节假期除了陪家人就是写着三篇文章了。其实写之前并没有觉得是多么难的事情，感觉这些原理自己都比较清楚，但是随着写的过程中，却发现自己有些确实理解的不是非常到位，看来有些知识是需要通过花更多的时间来锤炼的，突然想起几年前看的电源《阿甘正传》，对于阿甘的纯粹与坚持十分向往，我想在技术的道路上也应该多多学习下阿甘吧，路要一步一步的走，水要一口一口的喝，很多道理都非常简单，只是我们自己给想的复杂了而已。

在本系列前面两章中我们介绍了数论的基础知识、对称加密与非对称加密算法的推导过程，那么至此，我们已经掌握了密码学的基础理论。“是时候展现真正的才艺了！哈哈”。所以在阅读本章前，请仔细阅读下前面两个章节，积累坚实的理论基础，这样看起本章来大抵更会感觉。

从数据的声明生命来看，可以将数据分为三态，每态的安全要求都不一样。

• 存储态：存储在本地或者服务器的磁盘阵列中，相对来说较为安全，需要从网络攻防与权限控制进行保护。
• 计算态：从本地或者云端的磁盘阵列获取，加载到内存中，进行计算，相对来说较为安全，需要从网络攻防与权限控制进行保护，另外考虑内存攻击与信道攻击，隐私计算的TEE可信计算从硬件进行保护，对于这种模式较为友好，有兴趣的同学可以了解下。
• 传输态：无论是存储态还是计算态，都是相对短距离的本域或者本服移动，但是相对来说，传输态会将数据在公网进行广泛的传播，数据就会遍布互联网，我们如果不想我们的数据信息被全网皆知，就需要一个强有力的加密手法。

本章主要从数据的传输态进行数据安全保护的角度讲解，文章布局按照渐进式的方式进行推进，也符合人们以前在处理这个问题的时候的思考历程，最大程度的带大家一起从始到终的走一遍数据传输态的加密历程，看看大神们是如何将这些问题一一解决的。很多概念或者技术点，需要下大功夫去思考与验证，很多时候看完一个技术点，感觉懂了，但是一说又说不出来，其实这种情况下就是没有懂。

加密从来不是一个简单的事情，比如现在的HTTPS他不仅仅是使用对称加密、非对称加密，还综合应用了数字签名、数字证书、证书链等一系列机制保障整个链路的安全，是几门技术的优雅组合，进行全方位的立体式防护。下面我就娓娓道来。

1 为何需要加密

在数据的传输态，比如在万物互联的Internet冲浪的过程中，通过电子商务网站进行购物、通过数字支付进行资产管理、通过聊天软件进行私密沟通，这些数据都在整个网络上流动，一旦泄露造成的影响是巨大的，财产的损失、商机的泄露等等；

以前我们以前经常使用HTTP浏览网站。但是因为HTTP的内容是明文传输的，在广阔的互联网上，明文数据将会经过各种中间代理服务器、路由器、通信服务运营商等众多物理节点，任何一个环节都有可能出现问题，从数学的角度来说，安全的概率系数是极低的。

如果中间的物理节点，将传输的内容进行Dump，信息就会被泄露，可能某些重要的商机或者机密会被竞对得知，造成巨大的损失。同时如果信息在传输过程中被恶意劫持，那么劫持者还可以篡改传输的信息且不被双方察觉，（中间人攻击），从而可能造成非常严重的影响，比如修改金融账户、篡改重要商业信息等。

综上，需要在数据的传输态使用加密技术进行安全保障，那么应该如何加密保障呢？应该使用什么样的技术呢？

2 应用对称加密

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-v4XiGx5K-1644370003352)(https://tse1-mm.cn.bing.net/th/id/R-C.924c11c95643aade32d18a6a8771c145?rik=nFvrUVqKJB0Z%2fg&riu=http%3a%2f%2fimage.bubuko.com%2finfo%2f201901%2f20190112232927692894.png&ehk=8OxP4nq6U3eLpkJugJTPoliz6IBKoIvHoWDJvpSkD%2fM%3d&risl=&pid=ImgRaw&r=0)]

数据的传输态需要一个安全可靠的加密方式，防止被中间人偷窥与篡改（中间人攻击）。那么我们先来看看是否可以使用对称加密的方式。

从本系列的第一篇文章《隐私计算加密技术基础知识》上中我们得知，对称加密的算法是公开的，大家都可以得到，但是对称加密的秘钥却是需要严格保密的，只能有加密与解密的双方知道，其他人严禁知晓，这个非常关键！

其中这个理论就非常棒，前提就是只要不泄露秘钥，但是双方还都需要这个秘钥，所以实现起来确实比较蛋疼的，下面描述下使用对称加密的上网冲浪的流程：

1. 第一步，服务端生成一个密钥M，用于后续链路的数据加密。
2. 第二步，服务端将这个秘钥M明文传递给访问它的客户端浏览器，进行秘钥协商。
3. 第三步，客户端浏览器确收到这个秘钥M，并且确认使用这个秘钥M。
4. 第四步，基于服务端和客户端都确认使用这个秘钥M进行数据传递，协商完毕。
5. 最后，双方用这个秘钥M进行加密数据传输。

从安全角度来说，这个流程里面有个非常大的漏洞，那就是在双方协商好秘钥之前，都是明文传输（因为没有一个双方互知的秘钥M）。但是第二步的传输过程中密钥M被中间人劫持了怎么办？之后他就能用密钥M解开双方传输的所有内容了，所有的秘密就再无秘密可言，那么就会天下无秘。

这里的关键问题在于秘钥的传递的安全性，这个时候，有些同学可能会说，没问题，可以先预置。但是这样仍然有两个问题，

• 如果世界上有100亿的网站，我们需要在客户端的浏览器预制（100亿 * 用户数）的秘钥（假设每个对于同一个网站都一样的秘钥，如果不同那么会更多），而且还有新增与下架网站，这种模式对于存储和时效都有很大的挑战，对于秘钥的管理非常繁琐，基本不可能。
• 如果所有网站A的访问者都是一个固定不变的秘钥的话，只要有一个泄露，就全泄露了，这个网站的秘钥就得更换。

所以，仅仅使用对称加密无法做到数据的传输态的安全保障，既然对称加密我们尝试过了，那不妨试试非对称加密是否可以解决，俗话说“人是要有理想的，万一 … 实现不了呢”，哈哈，开个玩笑！

3 应用非对称加密

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lgp3wzr8-1644370003353)(https://tse1-mm.cn.bing.net/th/id/R-C.924c11c95643aade32d18a6a8771c145?rik=nFvrUVqKJB0Z%2fg&riu=http%3a%2f%2fimage.bubuko.com%2finfo%2f201901%2f20190112232927692894.png&ehk=8OxP4nq6U3eLpkJugJTPoliz6IBKoIvHoWDJvpSkD%2fM%3d&risl=&pid=ImgRaw&r=0)]

不同于对称加密，非对称加密有两个秘钥（公钥与私钥），下面我们考虑如何使用非对称加密进行加密数据的传输态，流程大致：

1. 第一步，服务端生成非对称加密的秘钥对，公钥e（E，N），私钥d（D，N）；（详见上个章节的描述）
2. 第二步，服务端将公钥e（E，N）传递给客户端浏览器，进行秘钥协商；
3. 第三步，客户端收到公钥e（E，N）后，确认秘钥协商，后续的传输使用这个公钥e（E，N）进行加密；
4. 第四步，服务端收到加密信息后，使用私钥d（D，N）进行解密。（计算过程详见上个章节）；
5. 第五步，服务端将要发送的数据使用私钥d（D，N）进行加密，传递给客户端浏览器；
6. 第六步，客户端浏览器使用公钥e（E，N）进行解密。
7. 最后，重复上面的流程进行数据的传递。

• 漏洞分析：

• 服务端向客户端传递数据：由于在第二步传输的时候，仍然是明文传输公钥e（E，N），若这个时候遭遇中间人攻击，那么后续的服务端加密的数据都可以被他解开，造成信息的泄露。
• 客户端向服务端传递数据：由于客户端使用的是公钥e（E，N）进行加密，根据非对称加密的性质，只有私钥d（D，N）才可以解开，私钥一直保存在服务端没有被传递，所以从客户端到服务端侧的传输在正常情况下是安全可靠的。

对比上面的对称加密算法，单纯使用非对称加密算法是有着不小的进步的，最起码保障了半个通道的安全可靠（客户端到服务端，但是其实还是会有中间人攻击、劫持篡改的情况，这个问题不依靠加密算法本身解决，后续通过数字签名、数字证书以及证书链解决），但是仍然满足不了我们的需求。

从上面的流程中，可能有些细心的读者会说，既然一对秘钥保证了一半的链路，那么我们是不是可以使用秘钥来进行规避呢？那么我们推导下这个流程：

1. 第一步，服务端生成非对称秘钥对（e，d），客户端生成非对称秘钥对（e‘，d’）；
2. 第二步，服务端明文传输公钥e给客户端，客户端明文传输公钥e‘给服务端；
3. 第三步，客户端使用自己的秘钥d’加密传输数据，并且传递给服务端；
4. 第四步，服务端使用客户端的公钥e‘解密客户端传递数据；
5. 第五步，服务端使用自己的秘钥d加密传输数据，并且传递给客户端；
6. 第六步，客户端使用服务端的公钥e解密服务端传递的数据；
7. 最后，重复上面的流程；

• 分析

• 安全性：双向链路基本保障安全，但是还是会有中间人攻击、劫持篡改的情况（这个问题不依靠加密算法本身解决，后续通过数字签名、数字证书以及证书链解决）。
• 性能：非对称加密的性能较之对称加密要慢，笔者曾经写过一个RSA对比AES的加密，基本外部依赖相同的情况下，对称加密算法比非对称加密算法快大约1000倍以上。所以对于某些对于延迟敏感的业务来说不适用。

4 对称加密+非对称加密

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UH2PzDUu-1644370003353)(https://sslmagic.com/blog/wp-content/uploads/2021/01/ssl.jpg)]

中国人讲解中庸之道，不左不右，那么我们也可以本着这个理念进行思考，既然对称加密和非对称加密单独的情况下都有这样与那样的问题，那么为何不组合在一起使用呢？

那么可能的流程大致如下。

1. 第一步，服务端生成非对称秘钥对（e，d），并且将公钥e传递给客户端；
2. 第二步，客户端生成对称加密的秘钥m，并且使用公钥e对这个秘钥m进行加密；
3. 第三步，客户端将这个用公钥e加密的对称加密秘钥m传递给服务端；
4. 第四步，服务端使用秘钥解密客户端传递过来的对称加密秘钥m；
5. 第五步，客户端和服务端都有对称加密秘钥m，后续的通信使用这个秘钥m进行加密传递。

• 分析

这个流程可以看做一个简化的HTTPS使用的流程，但是这个流程仍然有问题，比如中间人攻击、劫持与篡改。所以还需要使用数字证书、客户端证书链以及数字签名进行辅助加固。

5 中间人攻击

上节已经介绍了使用对称加密+非对称加密的方式进行信道传输保障，但是还是会有中间人攻击的问题，下面介绍下加密场景下的中间人攻击是如何做的？

在上面的方案中，数据传递过程中即使中间人劫持到了数据，但是他无法获取客户端生成的对称加密的密钥m，因为密钥m是被服务端的公钥e加密了，劫持者没有服务端的秘钥，所以无法解开。但是可以绕过这个流程，做个中间欺骗，流程如下：

1. 第一步，服务端生成非对称秘钥对（e，d）;
2. 第二步，中间人非对称加密秘钥对（e’，d‘）；
3. 第三步，客户端端请求服务端的公钥e，中间人监听信道进行劫持，获得服务端传递给客户端的公钥e，并且将数据包中的公钥e，替换成自己的公钥e’;
4. 第四步，客户端收到中间人的公钥e’，但是他以为是服务端签发的公钥e。所以客户端生成对称加密秘钥M，并且使用中间人公钥e‘（客户端以为是服务端公钥e）进行加密，并且传递给服务端；
5. 第五步，中间人持续劫持传输信道，获得客户端加密的对称秘钥，使用自己的私钥d’进行解密获取M；
6. 第六步，中间人使用服务端的公钥e对对客户端生成的称加密秘钥M进行加密，并且传递给服务端；
7. 第七步，服务端使用自己的私钥解密得到秘钥M，以后客户端与服务端都是用秘钥M进行加密；
8. 至此，由于中间人已经知晓这个加密的秘钥M，所以整个传输都被中间人了然于胸。

同时在这种情况下双方都不会发现异常，中间人通过套娃的操作，替换了服务端的公钥，进而得到了双方传输的对称加密秘钥m。根本原因是浏览器无法确认收到的公钥是不是服务端的，因为公钥本身是明文传输的，难道还得对公钥的传输进行加密？这似乎变成鸡生蛋、蛋生鸡的问题了。

6 解决之道

上面讲过，中间人攻击是替换掉了服务端的公钥，那么如何防范呢？方案就是将公钥封装起来，并且通过一些其他的手段进行多方位、多角度的辅助验证与保障。笔者通过阅读大量文献，总结出几点比较重要的地方；

• 数字证书：权威的官方CA机构签发数字证书（包含元信息：公钥 私钥 签名 网站信息等）。
• 客户端证书链：通过在客户端浏览器设置证书链（官方的CA机构授信），保障证书的安全，验证证书的合法性、过期与吊销等。比如我们访问A网站，中间人掉包并且换成自己制作的非官方证书，客户端浏览器在验证的时候会弹出警告；

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-l6oFDAEV-1644370003354)(https://tse1-mm.cn.bing.net/th/id/R-C.082fb91449c97eea178cc0eb01e945ff?rik=5WJYUQBM%2fhU3Xg&riu=http%3a%2f%2fwww.wosign.com%2fimage%2fwhy4_alert-1.jpg&ehk=PNx4Curuv%2bGrcj4WIfrkeMt0C7ffC%2fjUODkuHKj01hU%3d&risl=&pid=ImgRaw&r=0)]

• 数字签名：数字证书里面包含公钥 私钥 签名 网站信息等，这些信息用于相互自校验，比如我们访问A网站，中间人掉包后换成自己网站的CA证书（官方），下发的证书里面的网站信息就不是我们签发的信息，浏览器校验会失败；

通过上面这三个手段，保障证书的合法性，也就保证了公钥的合规性，从而保证不被中间人攻击，保障信道的安全。

7 数字证书

数字证书从本质上来说是一种电子文档，是由电子商务认证中心（以下简称为CA中心所颁发的一种较为权威与公正的证书，对电子商务活动有重要影响，例如我们在各种电子商务平台进行购物消费时，必须要在电脑上安装数字证书来确保资金的安全性。 现在的认可合法的CA组织，主要有Symantec(其中有VeriSign和GeoTrust)、Comodo SSL、Go Daddy 和 GlobalSign ，清一色的国外机构。

那么虽然我们目前有了认可的权威机构进行数字证书的签发，但是攻击者都是非常生猛的，通过购买几次证书，进行破解，然后伪造成这几个权威机构不就行了吗？那么如何进行防范呢？请看下节《客户端证书链》。

8 客户端证书链

大家都知道SSL证书由浏览器中“受信任的根证书颁发机构”在验证服务器身份后颁发,具有网站身份验证和加密传输双重功能的一种数字证书，能有效保障数据传输安全，保障数据不会被伪造，篡改和窃取。目前在网络安全中是网站安全中必不可少的组成部分。网站一旦安装了证书，可以通过浏览器小锁查看证书的详细信息，包括证书有效期，颁发机构以及证书信任链等。接下来带大家详细的去探究下证书链。

什么是证书信任链？什么是证书链？

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-H7eHDasg-1644370003355)(https://www.anxinssl.com/wp-content/uploads/2020/08/ZxdG.png)]

如图所示就是一个由根证书，中间证书，用户证书等组成一条完整证书信任链。只有当整个证书信任链上的各个证书都有效时，浏览器才会认定当前颁发给用户的证书是有效和受信任的。而证书链文件是指除了用户证书以外中间证书和根证书组成的证书文件称之为证书链文件。证书链文件是证书部署和验证证书是否可信环节中最重要的组成部分。

根证书 –是受信任CA证书颁发机构给自己颁发的证书,是信任链的起始点。浏览器判断根证书是否受信任主要是通过检索浏览器的根证书库可信任列表里是否存在。如果存在浏览器就会信任该根证书。目前有的浏览器会自建根证书库，例如火狐浏览器，有的浏览器会使用其他浏览器的根证书库或者调用操作系统的根证书库，例如谷歌浏览器。根证书信息查看可以通过点击根证书后查看证书信息后显示根证书的颁发者以及有效期等信息如下图所示：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jgiOToj6-1644370003356)(https://www.anxinssl.com/wp-content/uploads/2020/08/STDHSETH.png)]

中间证书 –中间证书是根证书颁发机构CA对中间证书颁发机构的公钥进行数字签名得到的证书。中间证书的作用主要是为了保护根证书。因为如果直接采用根证书签发证书，一旦发生根证书泄露，将造成极大的安全问题。中间证书可以不止一个，目前我们经常看到有两级中间证书的，原则上中间证书层数越多，根证书越安全。但是一般情况下最多也不超过2级。中间证书信息查看如下：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kj8js7EF-1644370003356)(https://www.anxinssl.com/wp-content/uploads/2020/08/GNH.png)]

用户证书 –用户证书是由中间证书CA签发给用户的证书。用户证书由中间证书证明可信。用户证书是浏览器上实际体现和使用的证书。用户证书可以通过点击小锁后查看到该证书颁发给哪个域名或者ip，证书有效期，颁发机构等信息。如下图所示：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-IfrqIVNh-1644370003356)(https://www.anxinssl.com/wp-content/uploads/2020/08/GNZ.png)]

有关信任链的验证流程，可以参考下图，客户端会预置和更新证书链的相关信息，在与服务端交互的过程中，会进行证书校验，比如公钥校验、签名校验等，中间篡改或者伪造后，在客户端不会被通过。所以即使你伪造了某个权威机构的证书，但是权威机构没有收录，客户端的证书链依赖不认可你，所以你伪造也用。（除非添加受信，不过这个就是用户的自我行为了，浏览器会进行风险提示，但是不强制不允许访问）

9 数字签名

前面的客户端证书链保障了证书的合法性，里面用到了数字签名的技术，那么数字签名到底是个什么技术，又是如何在这里面起到作用呢？

数字签名就是附加在数据单元上的一些数据,或是对数据单元所作的密码变换。这种数据或变换允许数据单元的接收者用以确认数据单元的来源和数据单元的完整性并保护数据,防止被人(例如接收者)进行伪造。它是对电子形式的消息进行签名的一种方法,一个签名消息能在一个通信网络中传输。基于公钥密码体制和私钥密码体制都可以获得数字签名,主要是基于公钥密码体制的数字签名。

数字签名是个加密的过程，数字签名验证是个解密的过程。

1. 数字证书签名生成的步骤：

   1. 第一步，获取撰写证书的元信息：签发人、地址、签发时间、过期失效等等；

   2. 第二步，通过通用的hash算法将信息摘要提取出来，比如sha1或者md5；

   3. 第三步，Hash摘要通过签发者的私钥进行非对称加密，生成一个签名密文；

   4. 最后一步，将签名密文attach到文件证书上，使之变成一个签名过的证书。

2. 数字证书签名验证的步骤：

   1. 第一步，浏览器获得服务端从CA签发的证书；
   2. 第二步，将其解压后分别获得“元数据”和“签名密文”；
   3. 第三步，将同样的Hash算法应用到“元数据”生成摘要信息；
   4. 最后一步，将证书“密文签名”通过公钥（非对称算法）解密获得同样的摘要值，并且进行对比，同时也可以与客户端证书链里面的签名摘要信息对比。

10 基于非对称加密与对称加密的HTTPS传输流程

前面通过渐进式的方式基本将数据传输态安全传输需要的技术点讲解清楚，本节将会将前面的知识融会贯通，通过目前时下最为流行的HTTPS的全流程，将整个传输信道加密讲解清晰。

10.1 SSL/TLS介绍

1. SSL：（Secure Socket Layer，安全套接字层），位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。该协议由两层组成：SSL记录协议和SSL握手协议。
2. TLS：(Transport Layer Security，传输层安全协议)，用于两个应用程序之间提供保密性和数据完整性。该协议由两层组成：TLS记录协议和TLS握手协议。

SSL是Netscape开发的专门用户保护Web通讯的，目前版本为3.0。最新版本的TLS 1.0是IETF(工程任务组)制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本。两者差别极小，可以理解为SSL 3.1，它是写入了RFC的。

10.2 SSL/TLS 握手过程

下面来看 TLS 握手的详细过程，是如何一步一步实现安全性的，下面的描述比较粗略，实际的交互过程比较复杂，大概需要发送十几个包。下面从整体流程上进行描述。

1. "Client hello"消息：客户端通过发送"Client Hello"消息向服务器发起握手请求，该消息包含了可用版本号、当前时间、客户端随机数、会话ID、可用的密码套件清单、可用的压缩方式清单等能力。

2. "Server Hello"消息：服务器发送"Server Hello"消息对客户端进行回应，该消息包含了数字证书，使用的版本号、当前时间、服务器随机数、会话ID、使用的密码套件、使用的压缩方式

3. 验证：客户端对服务器发来的证书进行验证，确保对方的合法身份，验证过程可以细化为以下几个步骤：

   1. 检查数字签名
   2. 检查证书的状态等

4. “Premaster Secret"字符串：客户端向服务器发送另一个随机字符串"Premaster Secret (预主密钥)”，这个字符串是经过服务器的公钥加密过的，只有对应的私钥才能解密。

5. 使用私钥：服务器使用私钥解密"Premaster Secret"。

6. 生成共享密钥：客户端和服务器均使用 Client Random，Server Random 和 Premaster Secret，并通过相同的算法生成相同的共享密钥 KEY。

7. 客户端就绪：客户端发送经过共享密钥 KEY加密过的"Finished"信号。

8. 服务器就绪：服务器发送经过共享密钥 KEY加密过的"Finished"信号。

9. 达成安全通信：握手完成，双方使用对称加密进行安全通信。

到目前为止，整个通道完成了证书验证阶段，握手成功，双方可以愉快的使用协商出来的动态的对称秘钥进行通信通道的加密，大家可以愉快的安全上网冲浪了。

11 番外篇

个人介绍：杜宝坤，隐私计算行业从业者，从0到1带领团队构建了京东的联邦学习解决方案9N-FL，同时主导了联邦学习框架与联邦开门红业务。
框架层面：实现了电商营销领域支持超大规模的工业化联邦学习解决方案，支持超大规模样本PSI隐私对齐、安全的树模型与神经网络模型等众多模型支持。
业务层面：实现了业务侧的开门红业务落地，开创了新的业务增长点，产生了显著的业务经济效益。
个人比较喜欢学习新东西，乐于钻研技术。基于从全链路思考与决策技术规划的考量，研究的领域比较多，从工程架构、大数据到机器学习算法与算法框架均有涉及。欢迎喜欢技术的同学和我交流，邮箱：baokun06@163.com

一切有为法，如梦幻泡影，如露亦如电，应作如是观

标签：公钥,加密,证书,秘钥,非对称,加密技术,服务端,客户端
来源： https://blog.csdn.net/qq_22054285/article/details/122835312

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。