HTTPS基本原理介绍

一、什么是HTTPS

HTTPS全称超文本传输​​安全协议，是HTTP的加密版本，也就是HTTP+SSL。HTTPS在HTTP的基础上，通过增加传输加密和身份认证，保证了传输过程的安全性。
近些年来，随着越来越多免费TLS证书的推广，HTTPS协议在国内越发流行起来，国内外的许多大型互联网公司都已经开启了全站HTTPS。
HTTPS在我们的日常生产生活中随处可见，却又默认“隐身”。今时今日，我们随意访问一个靠谱些的网站地址，都是支持https的。例如访问www.baidu.com，我们只需要输入这个地址，浏览器会自动默认我们访问的是443端口，随后补全网站的全部地址即https://www.baidu.com:443。HTTPS可谓是默默守护我们的个人隐私和网络安全，深藏功与名。当然，我们不能完全无视它的复出，还是有必要稍微学习一下这个“最熟悉的陌生人”。
在学习HTTPS之前，我们先复习一下http的基本概念。我们使用wireshark捕获一次本地的http请求，可以看到一个完整的http请求抓包如下图所示：

首先可以看到的是三个TCP协议的数据包，分别是SYN、SYN+ACK、ACK，也就是我们熟知的三次握手。随后就是HTTP请求，这里可以看到有一个POST REQUEST请求和对应的 RESPONSE。在每一个HTTP请求之后，还跟着一个TCP数据包，用于表示请求已经收到的ACK。实际上，HTTP协议是应用层的概念，在传输层和物理层上，还是属于TCP/IP协议。当我们发起一次HTTP请求时，浏览器或者客户端，将我们的请求按照HTTP协议的要求，拼装出了HTTP数据，再调用下层TCP API，将HTTP数据封装到TCP协议中，再封装到IP协议中发送。
从抓包可以看到，HTTP底层使用TCP传输，比较稳定，且数据直接明文传输，抓到包就可以解析出全部内容。这样的优点是简单高效、可读性和扩展性很强，缺点也非常明显，HTTP协议毫无安全可言。在实际的网络环境下，网络请求会通过各种中间代理服务器、路由器、wifi等进行转发， 在其中任意一个节点，都有被劫持的可能性。如果请求被劫持，别有用心的人可以非常轻松的解读内容或者篡改数据，在客户端和服务器毫无察觉的情况下，就可以窥探隐私甚至篡改命令。毕竟，你也不想被黑客掏空你网银里的三瓜俩枣吧。
在一些不设防的简单数据传输中，HTTP仍然有他的用武之地，但是在例如支付、查询隐私数据等高风险应用场景下，我们需要更加有效的安全、隐私的处理方式，HTTPS协议就应运而生了。

二、如何保证信息安全

在学习HTTPS之前，我们需要了解到底什么是（信息）安全呢？我们用一个例子来学习一下。

小王和对象小花吵架了，小王想跟小花道歉，苦于放不下面子，只能写了一个字条放到小花的桌上，等小花收到后，看看能不能原谅自己，字条写着***”小花，是我的错“。这时意外发生了，情敌老王意外偷看到了纸条的内容，他知道小王和小花吵架了，觉得机会来了。他模仿小王的笔迹，将纸条内容修改为了”小花，不是我的错“***。小花收到纸条后勃然大怒，两人告吹。可能事后他们可以发现事情的真相，但是造成的损失已经无法挽回。

从这个例子，我们学习一下，如何才能保证信息传输的安全性。首先是传输的隐私内容，例如两个人悄悄话，如果迫不得已无法点对点通信，那么即使意外被第三方劫持了，他们也应该无法看懂内容，这就是信息安全的机密性；其次是传输的内容，应该保证不能被其他人篡改，就算被篡改了，也能被收件人发现，并拒绝处理，这就是信息安全的完整性，例子中老王仅仅需要加一个不字，就将原本内容的意思完全颠覆；其次是收件人应该能验证发信人的身份，也就是信息安全需要可以做到身份认证，例子中老王模仿小王的笔记，小花并没有识别出来不对，说明收件人并没有做好身份认证这一步骤；最后，假如以上三点都能保证，那就一旦收到了请求，进行了处理，那么这次交流就不能抵赖，说了什么就是什么，不能不认账，这就是信息安全的不可否认性。
那么我们应该从这个例子中吸取哪些教训？
对于机密性，最直接的方法，当然就是对信息进行加密。小王和小花需要约定一套独属于他们的暗号，例如道歉就是”给你买包“，继续吵架就是”你要这么想我没办法“；机密性并不能保证内容不能被人篡改，老王虽然不知道”给你买包“是用来道歉的，但是他仍然可以搞破坏，比如加个不字，变成”不给你买包“，此时需要保证信息的完整性。小王和小花可以约定，在每句话前加上全文字数，用于表示实际内容的字数，例如“五：她只是妹妹”，“四：给你买包“等等方式，对方收到信息后，验证内容字数和头部字数是否相同，如果不对，说明经过删改。除此之外还是不够，我们的老王实在太坏了，如果他知道了两个人的小暗号呢（谁告诉他的暗号，我不说）？他也可以照着暗号来搞破坏。小花和小王还需要可以识别和验证写信人的身份。为了防老王，小王可以练就一手谁都无法模仿的烂字，或者更严谨点，在每个字上按上指纹——这么搞下来，老王就实在没辙了。保证了机密性、完整性和身份可认证性后，那么小花和小王可以确保收到的纸条内容就是对方的真实想法，那么写了什么就是什么，绝对不可以抵赖——当然，可以假装没收到，那就不是信息安全问题了，是他们的感情问题了。
通过这个例子，我们知道了保证信息安全需要保证以上四点，接下来，我们就根据这四点，分析一下，一个好的信息安全"S"协议，应该怎么做呢？

2.1 机密性

机密性可以说是信息安全的基础了。http是明文传输的，如果在信息传输过程中报文被劫持窥探，甚至劫持者还可以篡改传输的信息且不被双方察觉，这就是中间人攻击。那么如何加密呢？最容易想到的办法，就是对称加密。什么是对称加密呢，简单说，就是一个密钥既可以加密信息，也可以解密信息，客户端和服务器都持有这个密钥，对所有传输的内容进行加密解密。如果可以确保双方都知道密钥，且能够妥善保管，确保不被第三方知道，那么对称加密理论上是非常安全有效的。如下图所示，就是一套对称加密过程。

但是在现实的网络环境下，一个服务器通常需要面对多个客户端，如果给每个客户端都配置一个密钥，那么显然工作量很大，也不够高效。此时就需要引入一个**”公钥“和”私钥“**的概念——也就是非对称加密。每一把私钥对应一把公钥，用公钥加密的内容，必须用私钥才可以解密，反之，私钥加密的内容只有公钥可以解开。这样一来，我们只需要在服务器配置一把私钥，再把公钥发给所有客户端，客户端发给服务器的所有数据，只需要先使用公钥加密，再传给服务器，由于只有服务器持有私钥，那么也就只有服务器可以解密这个内容。如下图所示，就是非对称加密的流程

这样一来，好像确实解决了客户端向服务器传输数据的安全性问题。但是由于服务器需要首先让客户端知道公钥，所以公钥只能明文传输，那么公钥就有泄露的可能，假如公钥被中间人劫持了，自然就可以解密服务器下发的内容了。怎么保证服务器给客户端传输内容的安全性呢？
拍脑袋想想，我们用两组公钥和私钥不就解决了吗！假设服务器拥有公钥A和私钥a，客户端拥有公钥B和私钥b。

1. 客户端向服务器请求时，将公钥B传给服务器，服务器将公钥A传给知客户端；
2. 客户端之后的任何请求，都用公钥A加密，服务器收到后用私钥a解密；
3. 服务器之后的任何响应，都用公钥B加密，客户端收到以后用私钥b解密；

这是不是看似完美无缺了？既保证了请求后保证了响应的机密性。确实，这种方式的安全性的确有了相当程度的保证，但是坏就坏在，非对称加密相比对称加密，非常耗时，在大规模互联网背景下，这种方式似乎效率很低。那么我们再改良一下，结合非对称加密和对称加密呢？
服务器的思路不变，我们让客户端使用对称加密，如下图所示

1. 服务器持有公钥A和私钥a，当客户端来请求时，将公钥A传给客户端；
2. 客户端随机生成一个密钥X，用公钥A加密后，传给服务器
3. 服务器收到后，使用私钥a解密，得到密钥X
4. 双方的之后请求和响应，都是用密钥X进行对称加密

这就是HTTPS采用的方案——我全都要。你是不是以为这样就高枕无忧了？
不行，我们网络上的人实在太坏了。这又牵扯到了公钥的信任问题，我们稍后再表。

2.2 完整性

机密性貌似已经解决了（实际还有漏洞），接下来就该解决完整性了——我们怎么确保传输的内容是完整的，没有被人多加内容或者删减内容？我们需要一点手段，来保证传输的内容不被人篡改，或者说就算被篡改，也能马上发现。此时需要引入数字签名。数字签名中最重要的就是摘要算法，其实也就是我们常说的哈希算法或者哈希函数，它的作用是将任意长度的数据映射成一串固定长度的字符串，它是用于校验数据完整性的重要技术。摘要算法有以下几个特点：

运算单向性，无法通过计算出来的字符串反推出原文。也就是运算不可逆。
雪崩效应，原文任意一个小小的改动，都会让计算出的字符串完全不同，无法通过规律逆推
抵抗冲突，我们知道有一定概率，两个内容通过哈希后得到相同的哈希值，这就是哈希冲突，而抵抗冲突是摘要算法的一个重要指标，好的摘要算法冲突概率必须要非常低。
我们在传输报文时，首先使用摘要算法（哈希函数）将报文内容生成一个数字摘要，然后将数字摘要和报文一起传输给接收方，接收方在获取到报文后，使用相同的哈希算法，得到数字摘要，然后将自己计算出的和收到的数字摘要一对比，就能知道报文是否被人篡改过了。这就保证了信息传输的完整性。

2.3 身份认证

那么有人问了，如果有人丧心病狂的把报文和数字摘要都改了呢？此时我们就需要引入数字签名，对摘要进行上锁，不能让人轻易修改。也就是完整性和机密性的结合。当服务器需要给客户端发送一个报文时，首先使用哈希函数，将报文生成一个摘要，在公钥已经提前安全发给客户端的前提下（注意重点，这要考），用服务器的私钥对摘要进行加密，这个加密后的摘要和报文一起发给客户端；接收方收到后，首先使用相同的哈希函数，将报文生成一份摘要，然后使用发送方的公钥解密收到的摘要，再将两个摘要进行对比，判断完整性。其中，对传送数据生成摘要并使用私钥进行加密的过程，就是生成数字签名的过程，这里经过加密的数字摘要，也就是我们常说的数字签名。这样，即使中间人截获了摘要，但由于无法得知加密使用的私钥，所以它无法伪造数字签名。这样一来，通过数字签名，既可以保证消息的完整性，又可以确认消息确实时目标服务器发送过来的。

2.4 不可否认

由于数字签名的存在，一旦验签成功，证明消息确实对方发送过来的，那么就无法抵赖了。可以说前面三点是基础，如果保证了机密性、完整性和可验证性，那么不可否认应当是应有之义。

三、最后的漏洞

3.1 公钥的信任问题

通过以上四点，我们发现，好像通过数字签名+对称加密+非对称加密，我们完全解决了信息安全？不行，还有漏洞。以上一切，无论是数字签名还是协商对称加密密钥，都是基于一个假设，也就是服务器公钥准确无误。那么我们如何把服务器公钥安全地交到用户手中？
假设在服务器向客户端传输公钥的过程中，中间带恶人又出现了。中间人截获服务器的公钥A，保存下来，然后把劫持到的数据修改一下，将公钥A替换成自己的公钥H，自己持有私钥h。然后把这个公钥H告诉客户端“你收好了，这就是服务器的公钥”。而客户端收到后完全不知道已经被替换了，傻乎乎地生产密钥X，然后用H加密后，又传给了中间人。中间人这下啥都知道了，再把密钥X使用公钥A加密后传给服务器，服务器收到后也毫不知情啊，仍然使用私钥a解密得到密钥X。客户端和服务器都毫不知情，之后继续用密钥X进行加密解密，殊不知，密钥X早早就被中间人获取了。
根本原因就是，客户端，无法确认收到的公钥到底是不是服务器告知的，还是被中间人掉包的。
有人会说，简单啊，我再把公钥加密一下……等等，禁止套娃。
很明显，这个问题光靠协议或者算法已经解决不了，需要有第三方介入——CA，Certification Authority就闪亮登场了。

3.2 CA

CA就是一个证书服务机构，是一个专门用于颁发证书的权威机构。有了CA之后，服务器发送给客户端的公钥，不再仅仅是公钥，而是包含了服务器域名、服务器持有者、服务器公钥等一系列信息。这些信息不再直接发送，而是首先经过CA的认证，也就是CA使用自己的私钥对其进行加密，生成密文签名，然后将签名与原始明文一起传给客户端，这就是所谓的TLS证书。例如，我们查看百度的证书

浏览器收到这个证书以后，不是选择直接相信，而是先进行验证。浏览器使用CA提供的公钥，解密签名，然后验证解密后的内容和证书中明文是否相符，如果相符，那么愉快地开始加密通信，如果不符，就要先甩锅了风险提示就出现了——你要访问的话，出了问题别怪我。有的网站自己给自己颁发证书，例如我们的vhpa，那么浏览器根本不认。

CA的出现，确实使得攻击者再也无从下手了。如果攻击者拦截了证书，将证书中的公钥替换为自己的，浏览器收到后解密得到的公钥和证书中的明文公钥不符，那么就明显有问题；如果攻击者还不死心，直接去CA申请一个证书，将目标服务器的证书替换为自己的，这样虽然解密得到的内容和明文对的上，但是证书域名和浏览器的目标服务器域名不匹配，那么还是无所遁形。

3.3 禁止套娃——CA的信任问题

我们可以看到，CA的权力如此之大，那么我们怎么信任CA呢，万一CA也瞎搞呢？
CA的信任涉及到两个问题：
首先是CA机构的权威性，难道什么阿猫阿狗都能成为CA机构吗？不行，我们看看有哪些CA机构——谷歌、微软、中国金融认证中心、中国互联网络信息中心……无一不是国家背书或者大佬机构。这些机构不会随随便便给服务器颁发证书，CA机构颁发证书时，会仔细校验申请人的信息和身份，确保不会把某个域名的证书颁发给错误的人，通常需要结合官方邮箱、营业执照、域名登记信息等线上线下手段综合判断，最后才会慎重颁发——当然，天下没有免费的午餐，我给你担保，你就得拿钱。这些权威机构原则上没有作假的可能，毕竟出了问题，会影响到自己的商业信誉。
其次是CA公钥的安全性，解密签名需要用到CA公钥，那么CA的公钥哪里来呢？直接去CA官网请求公钥可行吗？不可行，首先是CA官网承受不了如此大的压力，其次，又怎么保证CA的公钥在传输过程中不被人篡改呢？为了杜绝CA的公钥在传输过程中不被篡改，CA直接省略了传输过程，改成了内置。没错，CA机构直接将公钥内置。例如微软、苹果、安卓等等操作系统提供商或浏览器提供商，早早地将CA的公钥存储到系统或者浏览器中，客户端再收到证书后，直接使用内置的CA公钥进行验证解密，至此，CA的担保工作就结束了，服务器也将公钥准确安全地传给了客户端。
在windows客户端中，我们直接在cmd输入certmgr.msc，可以看到许多内置的CA证书：

操作系统或者浏览器在内置CA证书时，也是需要慎重考察的，一旦将一些不靠谱的CA机构证书内置，那么出了问题，自己也逃不开锅。

3.4 问题没有消失

到此为止，好像皆大欢喜，所有问题都能解决了，但是我们发现，CA机构的责任过于重点，权力也过于集中——所谓权力的集中带来腐败。黑客入侵CA机构这种戏码，仅仅是开胃小菜，真正让我们不放心的，是CA机构的腐败问题。要知道，颁发证书的最终还是人，只要是人，就有出错和腐败的可能。著名的，就有谷歌和赛门铁克互喷的好戏，谷歌说赛门铁克乱发证书，赛门铁克说谷歌夸大其词，只是想要打压其他CA机构。要知道谷歌浏览器的市场占有率已经非常高了，如果谷歌再垄断CA机构，那么它岂不是名副其实的互联网之王？其他互联网公司还敢反抗他吗？
实际上，为了弱化或者确保CA证书不会乱发证书，后来又提出了CT透明证书的概念。在CT机制下，CA证书每颁发一个证书，都要向日志服务器记录详情，日志服务器记录后返回给CA一个SCT，此后，CA颁发给服务器站点的证书又新增了一个SCT内容。浏览器拿到证书后，出了验证CA的签名，还要向日志服务验证SCT，日志服务又使用公钥私钥加密解密……有人说，这不就是套娃吗？CA可以乱发证书，难道CT就不能乱发SCT吗？解决方法其实就是去中心化，使用区块链技术。
通过区块链技术，弱化CA的权威性，让所有节点来进行监督，将信任分配到每一个利益相关方的手中。这里不再细表其中的技术原理，我们只需要知道——安全技术的发展没有停下的一天，没有绝对的安全，只有相对的信任。

四、HTTPS关键协议

前面所有的技术介绍完后，统一起来就是一套实际的网络安全传输协议，大佬们把它规定后，就成为了一套SSL协议。
HTTPS比HTTP多了一个S，这个S指的就是TLS或SSL。SSL 是 “Secure Sockets Layer” 的缩写，中文意思为“安全套接层”，而 TLS 则是标准化之后的 SSL。TLS全称安全传输协议，也是一种应用层协议，HTTPS使用TLS对HTTP的请求和响应进行加密和加密，再把数据依靠TCP进行传输，这就相当于原本的明文传输，被放进了一个保险箱中再进行传输，这个保险箱只有客户端和服务器拥有开锁的钥匙，即使请求被劫持了，黑客没有钥匙，那也无法打开我们的保险箱。
TLS 是IETL对SSL标准化后提出的，也就是RFC 2246。TLS 1.0可以认为是SSL 3.0的后续版本，两者的差距非常小，很长一段时间内，SSL和TSL会进行混用，在部分场景下，TLS可以降级到SSL3.0。一直到2014年，谷歌发布SSL 3.0的设计缺陷，建议禁用这一协议，此后，越来越多的互联网服务提供商禁止回溯兼容，强制使用TLS协议。
TLS和SSL是独立于HTTP的协议，所以不仅是HTTP协议，其他运行在应用层的协议，例如SMTP和Telnet等，都可以配合TLS/SSL来使用，目前来看，TLS/SSL协议是当今世界上应用最广泛的网络安全技术。
有了前面的了解，我们来看一下HTTPS的握手过程。所谓HTTPS协议也就是HTTP+TLS，所以HTTPS的握手过程也就是TLS的握手过程。

4.1 TLS握手全过程

如下图所示，展示一次完整的TLS抓包过程：

可以看到，完整的TLS握手过程如下
1. client hello
client hello 是TLS中的第一个包，全部明文传输，如下图

其中内容包括：
1）version：TLS支持的最高版本，这里表示使用TLS 1.2
2）Random：客户端生成的随机数，用于后面生成对称加密密钥
3）Session ID：复用链接，用于之后链接加快握手速度，防止重复
4）Cipher Suites：客户端支持的加密套件列表，主要表面支持哪些加密算法
5）Compression Methods：表示支持哪些压缩算法
6）Extension：其他拓展字段，包括请求的域名信息
2. sever hello + Certifate + Server Key Exchange + Server Hello Done
sever hello是一个重头戏，也是全部明文传输，如下图

可以看到，server hello包括三个部分，分别是：
a. server hello
该部分表示服务器协商的结果，主要内容包括：
1）version：确定使用的TLS版本，这里是TLS 1.2
2）Random：服务器生成的随机数，用于后面生成对称加密密钥
3）Session ID：服务端生成的会话id，服务端会储存这个信息，如果后续客户端携带这个会话id访问，可以减少握手步骤。
4）Cipher Suites：选择的加密算法
5）Compression Methods：选择的压缩算法
6）Extension：其他拓展字段，包括请求的域名信息
b. Certificate
这一部分就是服务器返回的证书信息，也就是CA证书，包括了加密公钥，数字签名等等
c. server hello done
如果采用DH算法，则需要返回server key exchange表示使用的参数，如果采用rsa则没有这一部分，最后就是server heelo done，表示server hello结束。
3. Client key exchange + Change cipher Spec + Encrypted Handshae Message
这一部分也包括了三个部分，如下图所示

a. Client key exchange
如果采用DH算法，那么这个字段就是客户端采用DH算法生成的pre-master；如果采用rsa算法，这里是客户端生成的一个随机数pre-master。客户端使用服务器公钥加密这个随机数，发送给服务端。至此，客户端和服务器一共有三个随机数，前两个明文，最后一个是加密的，双方采用这三个随机数，生成之后对称加密使用的密钥。
b. change cipher Spec
这用于客户端通知服务端后面就使用之前协商好的密钥和加密算法进行通信。
c. Encrypted Handshae Message
客户端使用哈希函数对前面两个TLS协议部分生成摘要，并使用协商好的对称加密密钥进行加密，再传给服务器。这是密钥协商好以后，生成的第一个加密数据，服务器收到加密数据后，也进行哈希处理并比较，查看算出来的密钥是否相同。
4. Change cipher spec + Excrypted Handshake Message
最后两个服务器返回的数据，其实意义和上面是一样的，分别是通知客户端并且生成一段摘要数据，客户端验证完成后，那么加密通信就此开始。

4.2 握手协议中的关键内容

在以上完整的握手协议中，出现了两个我们不太了解的内容，分别是session复用和随机数。
session复用包括了session id 和session ticket，用于加快握手速度，减少握手过程中的性能损耗。其中session id是协议标准字段，几乎所有服务器都支持，session ticket则是扩展字段，支持率相对较低。如下图所示，携带session id后的SSL握手协议优化为：

1. 客户端与服务器成功握手后，服务器保存session id，并返回session id;
2. 客户端再次握手时在client hello中携带session id，服务器收到后进行校验，如果未检索到或已过期，则按照正常流程握手；
3. 如果服务器检索到session id，则直接返回Change cipher spec + Excrypted Handshake Message；
4. 如果客户端可以成功验证，说明可以解密，则客户端同样发送Change cipher spec + Excrypted Handshake Message；
5. 服务器验证解密通过，则握手成功

除了session外，还有一个比较陌生的概念，就是随机数。在整个握手协议中，一共出现了三个随机数，分别是client hello的random，server hello的random和最后Client key exchange的加密random。随机数是用于协商主密钥的，由于在client hello和server hello阶段，都是明文传输的，所有前两个随机数都有被截获的可能，那么怎么防止中间人通过截获两个随机数，再根据同样的算法，来生成最后的主密钥呢？答案就是第三个随机数，通常称这个随机数为预主密钥，也就是pre master。预主密钥是由客户端生成的，由于此时客户端已经校验了服务器证书，确认了公钥可用，所以预主密钥是使用公钥加密的，只有服务器私钥可以解密。通过第一第二和第三个预主密钥，客户端和服务器都通过相同的算法，来生成真正通信的主密钥，由于pre master是肯定安全的，所以可以保证主密钥的安全性。或许有人会问，那为什么还需要第一第二个随机数，直接生成一个pre master不就完事了？这主要是为了实现更大的随机性。我们知道，SSL证书是静态，公钥是静态的，所以十分有必要引入更多的随机性，来保证协商出的最终主密钥的随机性。SSL协议不信任任何一方可以产生完全随机的随机数，所以不管是客户端还是服务器，都需要随机数，来保证每次生产的主密钥不一样。

五、HTTPS的性能

说一千道一万，HTTPS的性能始终是他的劣势。主要原因也很好理解：

1. 对数据加密，特别是RSA加密，当qps较高的时候，非常消耗cpu资源。毕竟谁也不想做个谜语人吧？
2. SSL握手增加了流程，增加了RTT。相比于http，如果是首次握手，https会增加约7个RTT。
3. https禁用了缓存。

关于第三点，现在已经有了优化，目前的HTTPS协议，除非在头部明确规定不允许缓存，否则浏览器都默认会允许https的缓存。但是另外两点确实使用https就无法避免的问题。那么是否有什么办法可以优化https的性能呢？
简单说下，主要有以下几个优化方案：

1. 使用cdn加速。启用cdn边缘节点，可以缓解https延时大的问题，几乎已经是目前https的标配功能。
2. 使用session复用协议。前面说了，由于SSL协议性质，握手过程新增了大量RTT，因此引入了session复用功能。session复用使得客户端可以服务端可以重用之前创建的会话，减少了握手新增的RTT。
3. 启用HSTS。https性能差不仅表现在协议本身，还和用户操作有一定关系。毕竟，我们不能指望每个用户都在填写url时，手动输入https://，如果用户使用http，或者不写协议，那么可能会被认为是http请求，此时服务器会将http在跳转到https。这就会存在潜在的中间人攻击并且降低访问速度，毕竟301/302也会增加一个RTT，且浏览器跳转也会需要一定的时间。所以我们可以启用HSTS即严格传输安全协议。启用后的网站可以保证浏览器始终连接到服务器的HTTPS加密版本，不需要用户手动在地址栏填写https://。
4. 使用http2.0进行优化。这是http的二代版本，目前只用于https，这是比较新颖的概念，后续有机会再介绍。

六、总结

本文学习了一些信息安全的基础知识，也把https的一些基本原理稍加梳理。
我们不得不承认，面对复杂的网络环境，https是不得已的最优解，虽然他影响了我们的服务器处理效率，但是，为了保证安全又不得不带着使用——毕竟，谁也不想毫无隐私地在互联网中裸奔。网络安全仅限于目前的https吗？还远远不够，道高一尺魔高一丈，TLS协议一直在进步，黑客的技术也在进步，毕竟，这些安全协议都是开放透明的，你能学我能学，黑客也能学，保不齐啥时候，他们发现了其中的漏洞，甚至直接黑了https大本营——ca结构，那时候，我们只能期待有更新的安全协议出现了。当然，最重要的是我们要留一份心眼，当浏览器都开始提醒你，”与此站点的链接不安全“时，咱们就老老实实做个看客，不要把我们的隐私信息，毫无保留地告诉当前服务器了，毕竟，你不知道你告诉的到底”是人是鬼“。