互联网寒冬真的来了!!! 往年金三银四跳槽涨薪的好时机，今年却不见了，各大招聘网站一片萧条之景...

前几天看了下近期一二线大厂的面试题，发现里面包含了很多【计算机网络】相关的问题，下面的题目大家可以轻松回答出来吗？

HTTP和HTTPS的区别是什么？
为什么说HTTPS比HTTP安全呢？
说一下你对对称加密和非对称加密的理解
HTTP请求什么时候用的对称加密什么时候非对称加密？
对称加密的原理
...

此文主要用于帮助小白快速深入的理解HTTPS的加密传输原理，如有错误之处，欢迎大家指正

我相信很多人都碎片化的学习过SSL通信，了解过对称加密和非对称加密，听说过CA证书，查阅过签名摘要... 可最终始终无法将这些碎片化的知识串联起来，构成一个完整的HTTPS知识体系，每次面试的时候针对面试官提出的疑问还是无从找到好的切入口回答。不如跟我一起来看看下面这张图，或许可以解答你的疑惑！

为什么需要HTTPS?

众所周知，HTTP是实现网络通信的一种协议，它的协议简单且灵活，被广泛应用于浏览器和服务器之间传递数据；

但HTTP的通信传输过程是明文的，因此在信息传输过程中就会带来以下的安全性问题：

易被监听
易被篡改
易被劫持

HTTPS的出现正是为了解决上述问题

HTTPS是什么？

HTTPS = HTTP + SSL(安全套接层) / TLS(安全层传输协议)

HTTPS的优缺点

优点：通信过程中可以对数据进行加密，相比于HTTP更安全；

缺点：当用SSL时，服务器和客户端均会消耗更多的资源，导致负载增强；网络通信也会变慢，整体性能下降；

HTTPS主要用到的加密算法

对称加密

通信双方使用相同的密钥对数据进行加密解密；

优点：计算量小，加密速度快，破译困难，效率高；

问题：数据发送前，接收方和发送方需要商定好密钥并进行传递；在传递密钥的过程中，可能存在不安全因素，导致密钥被篡改；

常用的算法：AES ChaCha20

说明：AES的密钥长度可以是128、192或256位；ChaCha20密钥长度固定是256位

非对称加密

通信双方使用不同的密钥对数据进行加密解密（公钥+私钥）；两者之间解析可逆；

优点：安全性更好；

问题：性能开销相比于对称加密更大

常用的算法：RSA、DH、ECC、DHA等

说明：RSA是其中最著名的一个，它长度至少需要2048位，其安全性是基于“整数分解”的数学难题，因此想要从公钥推算出私钥是非常困难的；

说明：ECC也是近年来比较著名的一个算法，它基于“椭圆曲线离散对数”的数学难题，使用特定的曲线方程和基点生成公钥和私钥，子算法 ECDHE 用于密钥交换。

Hash算法

摘要算法可以保证，对于同一段数据，生成的摘要都是唯一且确定的；因此如果有人更改过数据，那么生成的摘要一定就会不同，从而可以用于校验数据的完整性；（严格来说它不能算作是一种加密算法，因为它没有解密一说）

常用的算法：MD5、SHA-1、SHA-2

HTTPS的加密方案—— 对称加密 + 非对称加密混合使用

基本流程：

开始通信的时候使用RSA、ECDHE等非对称加密的算法，用来保证密钥可以安全交换；
使用随机数产生对称算法使用的会话密钥，将此密钥用非对称加密的公钥加密发送；
接收方使用私钥解密后可以得到对称算法的会话密钥；
此时双方都安全的收到了对称加密的密钥，之后传递数据不再使用非对称密钥，全部改为使用对称密钥进行加密传递；

说明：这样既可以保证密钥的安全传递，可以解决单纯使用非对称加密的性能消耗问题。

CA证书认证机构

为什么会出现CA证书认证机构？

众所周知，公钥是服务器签发给客户端的，但是如何保证客户端收到的公钥一定是该目标服务器签发的呢？

如果存在代理服务器，那它会不会将公钥篡改，再派发给客户端，形成安全隐患，就像下面这样：

CA认证机构：

CA是具有权威性和公正性的第三方信任机构，由它们来签发和管理网站的数字证书；

说明：比较知名的机构有DigiCert、VeriSign、Entrust等，它们签发的证书分为三种： DV、OV、EV ，区别在于可信程度；DV 可信度是最低的，只是域名级别的可信；EV 可信度是最高的，网站经过了严格核查，可以证明网站拥有者的身份；

CA认证机构作用：

CA机构的出现就是为服务器签发数字证书，以确保网站真实可信；

CA机构如何证明自己？

小一点的 CA 可以让大 CA 签名认证，形成一个证书体系，但链条的最后，也就是 Root CA，就只能自己证明自己了，这个就叫“自签名证书”（Self-Signed Certificate）或者“根证书”（Root Certificate）

有了这个证书体系，浏览器内又预先内置了各大 CA 的根证书，所以上网的时候只要服务器发过来它的证书，我们就可以针对证书里面的签名进行验证，然后顺着证书链一层层地校验，直到找到根证书，从而确定证书是可信的，证书里的公钥也是可信的；

具体流程：

网站会拿着自己的公钥及相关信息去CA机构进行认证；认证成功后，CA机构会使用它自己的私钥对你提供的数据进行加密并签发数字证书；
客户端第一次向服务器发送请求，网站返回证书链；(不包括根证书，根证书已预置在浏览器中)
浏览器可以使用信任的根证书（根公钥）解析证书链的根证书得到一级证书的公钥+摘要验签，然后拿一级证书的公钥解密一级证书拿到二级证书的公钥和摘要验签，再然后拿二级证书的公钥解密二级证书得到服务器的公钥和摘要验签，验证过程就结束了；

说明：
    CA证书中心会对你网站的公钥、网站的域名地址、证书的到期时间等一些相关信息一起加密签发数字证书，从而保证网站的安全性；

浏览器会对证书进行如下检测：

签发证书机构的权威性
证书是否到期
正在访问的网站和证书记载的网址是否一致等
...

数字签名——解决证书的安全性问题

CA证书虽然可以证明对方是否是我们要访问的网站，但如果证书本身被篡改，那也会产生安全性问题；

数字签名就是经过私钥加密后的摘要，用来验证CA证书本身是否被篡改过

具体流程：

先用CA自带的Hash算法计算出证书内容的一个摘要（值唯一），并使用CA私钥进行加密，组成数字签名；
当接收方收到证书后可以用相同的Hash算法再生成一次摘要，并用CA的公钥解密之前已经生成的摘要；
将两个摘要进行对比；
若两者内容一致，则表示CA证书没有被篡改，是安全可靠的；

CA机构为什么要对摘要使用私钥加密后再发送给请求方？

因为黑客如果对CA证书进行篡改，那么可以在修改数据内容的同时把摘要也修改掉，这样摘要就起不到任何作用了，所以要对摘要进行加密，防止被同时替换内容和摘要；

为什么摘要使用私钥加密，公钥解密？

因为私钥是保密，黑客无法获取到私钥；所以就算窃取了数字签名并对签名进行了修改，修改后的签名也无法用公钥解开，那么客户端也就会发现证书被篡改了，由此黑客便无法伪造CA证书了。

最后我们来说一说TLS的通信机制

在HTTP协议中，当浏览器向服务端发出请求后，通过DNS解析获得IP地址，并使用三次握手与TCP建立连接后，客户端与服务器便会建立连接，进行通信；

但在HTTPS协议中，除此之外还需要在TCP上建立安全连接，即TLS连接，之后双方才可以进行通信；

TLS协议的组成：

TLS协议由一些子协议组成，常用的子协议如下：

记录协议
- 规定了TLS收发数据的基本单位：即一个记录；
- 所有其他子协议均需要通过记录协议发出；
- 多个记录数据可以在一个TCP包里一次性发出；
警报协议
- 用于发出警报信息，可以终止连接；
握手协议
- 双方经过一系列的协商后得到会话密钥，用于后续的加密通信；
变更密码规范协议
- 用于告知对方之后的数据使用加密传输;

TLS需要几次握手：

最多经过两次就可以完成握手

ECDHE 握手过程（主流）

【TCP包1】

TCP 建立连接之后，客户端会首先发一个“Client Hello”消息跟服务器打招呼；

其中包含客户端本次会话支持的TLS版本号及支持的密码套件，以及一个生成的随机数（"Client Random"），用于稍后生成会话密钥。

【TCP包2】

服务器收到“Client Hello”后会返回一个“Server Hello”消息；

和客户端一样，响应报文中包含使用的TLS版本号，确认本次通信中要使用的密码套件，保存客户端发送过去的随机数并生成第二个随机数（"Server Random"）；

还会将服务器证书一起发送过来；

因为服务器选择了 ECDHE 算法，所以它会在证书后发送"Server Key Exchange"消息，里面是椭圆曲线的公钥（"Server Params"），用来实现密钥交换算法，再加上自己的私钥签名认证；

最后是"Server Hello Done"消息；

【一次握手结束】:结果是客户端和服务器通过明文共享了三个信息：Client Random、Server Random 和 Server Params

【TCP包3】

客户端用“Client Key Exchange”消息将椭圆曲线的公钥发送给服务器

到目前为止，客户端和服务器目前都拿到了密钥交换算法的两个参数（"Client Params、Server Params"），并用 ECDHE 算法，算出另一个随机数——"pre-master"

现在，客户端和服务器手里有了三个随机数："Client Random、Server Random 和 Pre-Master"。用这三个作为原始材料，就可以生成用于加密会话的主密钥——"Master Secret"。而黑客因为拿不到"Pre-Master"，所以也就得不到主密钥。

客户端发送Change Cipher Spec消息，该报文会告知服务器之后的通信双方会采用加密的方式，按照已商定好的加密算法和会话密钥进行加密传输；

客户端发送Finished报文，表示客户端握手已结束；

该报文中会包含连接至今的所有数据做个摘要并进行加密，让服务器进行验证；

【TCP包4】

服务器也是同样的操作，发“Change Cipher Spec”，以告知客户端后续的通信都采用协商的密钥与算法进行加密通信;；

发送“Finished”消息，表示握手结束；

该报文中会包含连接至今的所有数据做个摘要并进行会话加密，客户端若可以正确解密该报文则表示握手协商成功

后面就收发使用对称加密的 HTTP 请求和响应了。

RSA 握手过程

【TCP包1】