随着建站成本的日益降低，使用Https的成本也随之下降。现在大部分网站都支持了Https，那么什么是Https？Https与Http有什么区别？Http又是如何保证通信安全的呢？本篇文章，我们将会从实战的角度解读上述问题。本文分为以下几个部分：

1. 前言
2. TCP/IP网络模型
3. TCP&UDP
   3.1 TCP
       3.1.1 三次握手
       3.1.2 四次挥手
       3.1.3 TCP的特点
       3.1.4 抓包验证
   3.2 UDP
4. Http
   4.1 Http请求的流程
   4.2 Http请求抓包的验证
5. Https
   5.1 为什么Https要存在
   5.2 处理问题的尝试
       5.2.1 是否使用对称加密
       5.2.2 是否使用非对称加密
       5.2.3 是否使用对称加密&非对称加密
       5.2.4 中间人攻击
       5.2.5 CA 认证
   5.3 Https请求流程
   5.4 数据包分析
6. 总结

1. 前言

Http协议作为目前互联网中使用最多的网络协议，掌握其工作原理是必备技能。而Https作为Http的安全版，同样是工作和面试的热点问题。要搞清楚Https，需要先搞清楚Http，而要搞清楚Http，先要搞清楚网络模型，搞清楚TCP&UDP。所以下面的文章，会按照TCP&UDP->HTTP->HTTPS这个顺序来进行。在开始正文之前，老规矩先提出几个问题：

• Q1：TCP和UDP的区别？
  TCP和UDP都是传输层的协议，不同的是TCP是可靠通讯协议，UDP是不可靠通讯协议。
• Q2：TCP三次握手的过程是什么？
  c->s syn,s->c ack syn,c->s ack
• Q3：为什么要握手？又为什么是三次，而不是两次或者者四次？
  握手(双方互相告知序列号起使值，并确认对方收到)序列号起使值的过程)就是为了保证可靠传输。之所以是三次，不是两次是由于最少要三次才能确认通信双方都能正常收发。之所以不是四次，是由于三次就能保证双方的正确性，没必要四次白费资源。
• Q4：TCP是如何做到可靠的？
  通过序列号确认（下面会详细分析）
• Q5：Http的请求流程？
  下文会详细分析
• Q6：Https的请求流程？
  下文会详细分析
• Q7：什么是中间人攻击？
  Man-in-the-MiddleAttack，简称MIT攻击”
• Q8：什么是CA认证？
  电子认证是指为电子签名相关各方提供真实性、可靠性验证的活动
• Q9：为什么我未在浏览器上安装Server端证书，却能正确发送Https请求？
  证书在建立连接的过程中通过网络传输
• Q10：有了Https就肯定是安全的吗？
  并不肯定
  

2. TCP/IP网络模型

继续下面的内容前，我们先明确两个概念：

• 网络模型：试图规范网络中的模型、推动网络普及的概念模型。将网络从通信介质传输到应用层实现分层划分。每个中间层为其上一层提供功能，其自身功能则由其下一层提供。
• 网络协议：计算机与网络设施之间要通信，双方就要基于相同的方法，比方通信语言、通信如何发起、通信如何结束等，这些商定的规则就是通信协议。

网络模型的每个层级都有不同的网络协议实现。网络模型是一种笼统的概念，网络协议是具体的实现。

1. OSI七层模型

OSI 即 open system interconnect（开放网络互联模型），是由ISO（国际标准化组织）研究的网络互联模型，为的是规范网络中的模型、推动互联网普及。

OSI七层模型将网络从最底层的物理传输介质到最上层的应用，划分为7层，按照层级由下到上的关系分别为：

• 物理层：最底层，包括物理联网媒介，如电缆连线连接器。(IEEE802.2)
• 数据链路层：提供介质访问和链路管理。(ARP、PPP)
• 网络层：IP地址及路由选择。(IP、ICMP、RIP、OSPF)
• 传输层：建立、管理、维护端到端的连接。（TCP、UDP）
• 会话层：建立、管理和维护会话。
• 表示层：数据格式转化、数据加密。
• 应用层：为应用层序提供服务。(HTTP、HTTPS、FTP、Telent、SSH、SMTP、POP3)

OSI（Open System Interconnect）七层模型.png

2. TCP/IP 五层模型
   TCP/IP是一组协议簇的总称，常见的互联网协议如：HTTP、HTTPS、Telnet、SMTP、DNS、TCP、UDP都属于该协议簇。TCP/IP模型将网络自下而上分为：物理层、数据链路层、网络层、传输层、应用层

• TCP/IP五层模型的协议分布

TCP_IP 5层模型 协议分布.png

• TCP/IP五层模型与OSI七层模型的比照

  TCP_IP 5层模型与OSI7层模型对应关系.png

3. 数据在TCP/IP协议中的传输
   假设我们有个服务端接收消息接口用来接收用户端上传的信息，那么从用户端发送到服务端接收这个过程发生了什么呢？

用户端：

• 通过Http协议组装消息，并将消息交给传输层。
• 传输层（TCP）接到消息后，会根据消息的大小选择将一个消息进行拆分成多个数据包，或者者将多个消息组合成一个数据包，并在每个包的包头加上TCP包头（包含目标端口号），将包头和Http包生成完整的TCP包，而后将TCP数据包交给网络层
• 网络层（IP）在拿到TCP的包后，在TCP包的前台加上IP包头，生成IP包（包含目标ip地址），并传给物理层网卡。
• 物理层（以太网）在收到IP包后，会在IP包前加上以太网的包头（包括mac地址）作为完整的以太网数据包，通过物理介质发送个目标主机。

服务端

• 物理层（以太网）在收到以太网数据包后，会根据mac地址判断能否是发送给自己的包，假如是发送给自己的包，则转给网络层解决。
• 网络层在拿到IP包后，根据IP包头做相应的解决，而后转给传输层解决。
• 传输层在拿到完整的传输层包后，也会根据包头做解决，如校验数据能否丢失、确定目标端口对应的应用层序。没问题后，将数据包转给对应的应用层。
• 应用层接收到相应的数据，进行数据解析，解决，并按照发送的过程再给出响应。

数据解决流程.png

3. TCP & UDP

TCP&UDP都是传输层的协议，不同的是TCP是可靠性传输协议，而UDP不可靠。先上一个完整的比照：

3.1 TCP

TCP（传输控制协议 Transmission control Protocol）是一种面向连接的，可靠的、基于字节流的传输层通信协议。从协议的定义，我们也能很显著发现协议的特点，可靠&面向连接，当我们需要保证传输的可靠性的时候，比方下载文件我们希望下载的是完整的文件而不是部分文件，再比方我们浏览网页，我们希望是按照顺序完整的展现网页的内容，而不是乱序的部分内容，在这些场景中，我们即可以使用TCP协议。那么TCP是如何保证可靠性的呢？可以从TCP连接的建立和断开中找到答案。

3.1.1 三次握手

三次握手过程

• 第一次握手：用户端向服务端发送SYN报文，请求建立连接，随后进入SYN-SENT状态。
• 第二次握手：处与Listen状态的服务端收到用户端的SYN报文后，回复SYN,ACK报文，表示“收到用户端的请求，同意建立连接”，随后进入SYN-RCVD状态。
• 第三次握手：处于SYN-SENT状态的用户端收到服务端响应后，发送ACK报文，表示“用户端收到服务端同意建立连接的响应”，随后进入ESTABLISHED状态。
• 服务端收到用户端的响应后，也进入ESTABLISHED状态，此时连接建立。

三次握手过程

为什么不是两次握手？
可能看到上面的过程，我们不经有个疑问，为什么不是两次握手呢？答案是要确认用户端和服务端都是可以正常收发的状态，这样可以避免以下两个情况1）避免服务端开启无用的连接添加服务器的开销 。2）避免已失效的连接请求报文忽然又传到了服务器，产生错误。

1. 避免服务端开启无用的连接添加服务器的开销
   假设第二次握手后就建立连接，则过程可能如下：
   • 用户端发送syn
   • 服务端发送syn,ack 并建立连接
   • 用户端因为网络起因，迟迟未收到服务端响应，超时重试
   • 用户端发起新的syn，之前服务端建立的连接无人使用，白费资源
2. 避免已失效的连接请求报文忽然又传到了服务器，产生错误
   同样假设第二次握手后就建立连接，则过程可能如下：
   • 用户端发送syn
   • 用户端发送的报文因为网络推迟，未送达服务端。
   • 用户端重试，第二次发送syn
   • 第一次发送的syn和第二次发送的syn都到达服务端，服务端建立两个连接，并回复两个syn,ack
   • 对于用户端而言，显然第一次的syn是废弃掉的，但服务端却为此创立了一个连接

为什么不是四次握手？
那么既然两次握手不行，为什么不是四次握手呢？那是由于三次握手已经能确保通信双方都是可以正常收发，并能正确确认双方的序列号的。那么就没必要进行第四次握手来白费资源了。

三次握手的浅显场景模拟

三次握手版
三胖和川普进行会面，要进行握手
三胖伸出手：川普你看，我手里没有武器，我很有诚意，我们握个手吧（SYN）
川普看了看三胖的手说：嗯，你手里的确没有武器。而后伸开手说，你看我也没有武器。（SYN,ACK）
三胖看了看川普的手说：的确你也没武器，你也有诚意，坐下来谈，别客气(ACK)。

两次握手版
三胖伸出手：川普你看，我手里没有武器，我很有诚意，我们握个手吧（SYN）
川普看了看三胖的手说：嗯，你手里的确没有武器。
三胖高兴的伸出手和川普握手，但是此时川普却从手里拿出了手枪，三胖卒…..

四次握手版
三胖和川普进行会面，要进行握手
三胖伸出手：川普你看，我手里没有武器，我很有诚意，我们握个手吧（SYN）
川普看了看三胖的手说：嗯，你手里的确没有武器。而后伸开子的手说，你看我也没有武器。（SYN,ACK）
三胖看了看川普的手说：的确你也没武器，你看我也没武器的，说完又伸出了手。
川普心想，三胖莫不是个傻子……

三次握手的关键是，确认通信双方都有正常收发的能力，这样才能确认序列号，才能尽可能保证TCP的可靠性

3.1.2 四次挥手

上面说了连接建立的过程（三次握手），那么连接断开是怎样样的一个过程呢？

• 第一次挥手：用户端向服务端发送FIN报文，请求释放TCP连接。并随之进入FIN-WAIT-1状态，并中止向服务端发送业务数据，但是此时是可以正常收到服务端数据的。
• 第二次挥手：服务端收到用户端的释放连接请求后，知道了用户端想要释放连接，随后结束ESTABLISHED状态，进入CLOSE-WAIT状态，并返回了ACK报文。因为[图片上传中…(四次挥手.gif-dfaef1-1609220464082-0)]
  是全双工协议，此时服务端还可以继续向用户端传输数据。用户端收到ACK后，知道服务端同意释放连接，则进入FIN-WAIT-2状态。
• 第三次挥手：服务端经过CLOSE-WAIT，做好了释放连接的准备后，向用户端发送FIN,ACK报文，此时服务端进入LAST-ACK阶段，并中止服务端向用户端方向的数据发送，但是此时仍可以收到用户端数据。
• 第四次挥手：用户端在收到服务端FIN,ACK报文后，知道可以释放连接了。就进入了TIME-WAIT状态，并回复ACK报文。等待2MSL（两个最大段的生存周期），假如这个时间段未收到服务端的重发请求，则进入Closed状态，服务端在收到用户端的ACK报文后，立即进入closed状态。

四次挥手.gif

为什么需要握手需要三次，而挥手却需要四次？

• 握手的时候，由于最少通过三次请求，才能确认双方都是正常收发的状态。
• 挥手的步骤中，第一步用户端发起断开请求不能少，第二步服务端回复ACK告诉用户端收到断开请求也不可少，第四部：用户端收到服务端FIN，ACK后进入time-wait状态也必不可少，至少为三步，那么为什么需要第三步的挥手呢？由于服务端在收到用户端断开请求后，并不能立即断开连接，由于可能数据还在解决中，并未传输完毕，所以要有第三步，数据解决完后通知用户端可以断开连接的过程即FIN，ACK报文。所以挥手是四次

为什么用户端要在TIME-WAIT状态等待2MSL？为什么不能直接CLOSED？

这么做是为了确保服务端正确收到用户端的ACK报文。

• 服务端会在1MSL内未收到用户端的ACK报文后，重新给用户端发送FIN，ACK报文
• 用户端假如在2MSL内重新收到服务端的FIN，ACK报文，说明服务端没收到用户端的ACK，则用户端重新发送ACK，计时器重置，重新开始2MSL的计时。
• 用户端假如在2MSL未收到服务端的FIN，ACK报文，说明服务端正常收到用户端的ACK，则用户端进入CLOSED状态，四次挥手结束。

四次挥手的浅显场景

女盆友：彦祖，该出发，看电影马上要迟到了
我：好的，我知道了，我打完这把农药
我：好了，我打完了，我们出发吧
女朋友：好的，走吧

四次挥手的关键，是服务端在准备好释放连接的时候，主动发送FIN，ACK通知用户端

3.1.3 TCP的特点

1. 面向连接
   TCP的传输数据是在建立连接的前提下，而连接又为可靠性做了基础保证。
2. 全双工通信
   TCP的用户端和服务端都能同时发送数据，而不像HTTP协议的半双工，同一个时刻只能有一端发送数据
3. 可靠性
   TCP通过序列号和确认号保证了可靠性，即每次发送数据包增加序列号，接收方在接收数据的时候按照序列号接收，同时回复一个ACK确认号，这样就保证了接收的顺序和明确了数据包能否送达，如发送的数据在正当的推迟(RTT)内未送达，则重传。
4. 拥塞控制
   当网络出现拥堵的时候，TCP能调整网络注入数据的数量和速度，降低拥塞。
5. 面向字节流
   TCP将数据包以字节流的方式传输。
6. 仅支持单播
   不支持多播和广播

3.1.4 抓包验证

上面我们说了TCP三次握手和四次挥手的过程，下面我们用wireshark抓包来验证下上面的流程。

以请求接口地址：http://www.moxieliunian.com/images/1.jpg为例

1. 三次握手

   三次握手总览

• 第一次握手，用户端发送SYN

  第一次握手

  1）代表的是传输层协议（包含源端口和目标端口），2）代表的是网络层传输协议（包含源IP和目标IP），3）代表的是数据链路层协议（包含源mac地址和目标mac地址），4）代表的是物理层协议，5）当前序列号 347723889，6）当前确认号为0，7）标识为SYN

• 第二次握手，服务端发送SYN，ACK
  image.png
  第二次握手的ack=347723889+1=347723890,seq=2517807223
• 第三次握手，用户端发送ACK
  image.png
  第三次握手，ack=2517807223+1=2517807224,seq=347723890

2. 四次挥手
   当一个Http请求结束，我们不做任何操作之后，TCP 会通过TCP Keep-Alive 来探测连接能否存活，假如到肯定的超时时间，则服务端会发起关闭连接。所以我们可以看到第一次挥手连接关闭是由服务端发起的。

• 第一次挥手，服务端发送FIN，ACK

  image.png

• 第二次挥手，用户端回复ACK

  image.png

• 第三次挥手，用户端回复FIN，ACK

  image.png

• 第四次挥手，服务端回复ACK

  image.png
  由于这里发起连接关闭的是服务端，所以上面的用户端顺序和3.1.2 中我们所说的是相反的

3.2 UDP

UDP即可使用户数据报协议，和TCP一样同为传输层协议，提供了一种无需建立连接即可以发送封装的ip数据包的方法。不提供数据包分组、组装、排序的功能，也就是说无法感知数据包能否正确送达。它有以下几个特点：

• 无需建立连接。也就说发送数据时无需通过三次握手建立连接，想发数据即可以开始发送，并且也不会对包进行任何的加工，除了增加UDP包头来标识它是一个UDP数据包
• UDP是面向报文的。UDP对应用层给到的报文，即不拆分，也不组合，直接保留原始报文的边界，应用层序必需选择大小适合的报文
• UDP是不可靠的。UDP的不可靠表现在三点：1）无需提前建立连接，都不知道接收方是否正常接收就发送数据，一定是不可靠的。2）没有ack机制，无法确认包能否正确送达。3）没有拥塞控制，网络不好的时候，可能会导致丢包。
• UDP不仅仅支持单播，还支持多播和广播

UDP不可靠.gif

UDP适合用在对实时性能要求高，但对可靠性要求不高的场景，如视频会议等

4. Http

Http 协议，即超文本传输协议，是一个基于TCP/IP协议之上的，应用层的通信协议。Http协议作为我们最常使用的协议，其请求的流程是怎样样的呢？

4.1 Http请求的流程

当我们在浏览器中，输入http://www.baidu.com的时候究竟发生了什么呢？

1. 域名解析。即将www.baidu.com 转换为 180.101.49.11:80的过程。
   • 从浏览器DNS缓存中查找域名解析记录
   • 如上面未找到，则从操作系统DNS缓存中查找域名解析记录
   • 如上面未找到，则从host文件中查找域名对应的ip
   • 如上面未找到，则请求配置的首选dns server查找域名对应ip（通过udp向dns server的53端口请求。这个过程是递归请求的）
2. 发起TCP三次握手
   • client—->server SYN seq=x（用户端请求建立连接，并且序列号为x）
   • server——>client SYN,ACK seq=y,ack=x+1（服务端同意建立连接，并且期待下次的序列号为x+1）
   • client——–>server SYN seq=x+1,ack=y+1（用户端已经收到服务端同意建立连接的响应，并且期待下次服务端发送的序列号为y+1）
3. 三次握手建立连接后，发起Http请求
4. 服务器端响应Http请求，浏览器得到Html代码
5. 浏览器解析Html代码，请求Html中引入的资源
6. 浏览器对页面进行渲染，呈现给客户
7. 连接超过keep-alive时间，四次挥手，关闭连接

4.2 Http请求抓包的验证

上面我们已经用wireshark抓了TCP三次握手的包，这里就不再赘述了。

1. 用户端发送SYNsyn.png

2. 服务端发送SYN,ACKsyn,ack.png

3. 用户端发送ACKack.png

4. Http requesthttp request.png

5. Http responsehttp response.png

通过分析Http的数据包，我看可以看到：Http是基于TCP协议的，同时Http是明文传输的。明文传输，也就意味着数据能轻易的被抓取和篡改。那么有什么处理办法吗？即下面要说的Https

5.Https

Https是在Http的基础上加了一层SSL，是基于Http+SSL实现的安全的Http协议。概括来说就是Http报文在组装好给到TCP之前，先经过TLS加密。接收方TCP在接收到数据后，在将数据返回上层HTTP之前，先将数据进行TLS解密。

5.1 为什么Https要存在

正如我们上面抓包演示的那样，Http是明文传输的，极度不安全，容易被窃听、串改、冒充，因而诞生了Https。

5.2 处理问题的尝试

上面我们说由于Http是明文传输，所以要Https，那么直接加密（对称和非对称）不就行了吗？

5.2.1 是否使用对称加密

我们尝试直接使用对称加密来处理这个问题。所谓对称加密，即加密和解密用的是同一个密钥
先看下构想图：

对称加密处理Http安全问题构想图.png
如果黑客在数据传输的过程中阻拦到我们的密文报文，能否我们的报文就是安全的呢？显然是不安全的，问题的起因如下:

1. 服务端在制定key的时候，并不知道未来用户端的数量，无法为每个用户端制定单独的key。其次为每个用户端存储单独的key，有的时候key的数量反而比业务数据更大，得不偿失，所以只能公用一个key。
2. 黑客冒充正常的用户端，同样也可以拿到公用key。此时即可以解密阻拦的数据，从而篡改数据。

所以对称加密不可行

5.2.1 是否使用非对称加密

既然对称加密行不通，我们自然会想到非对称加密。能否可行呢？
先看下构想图：

非对称加密处理Http 安全问题构想图.png

非对称加密同样是不可行的，这是由于所有人包括黑客都能拿到公钥，尽管黑客无法解密用户端发送服务端的数据包，但是黑客可以用公钥解密服务端发送用户端的响应报文，同样不安全。

5.2.3 是否使用对称加密&非对称加密

上面的分析，我们可以看到，对称加密的缺点是所有用户端公用一个key，而非对称加密的缺点是服务端给用户端发送响应报文时不安全。那么能不能综合两者，得出一个唯一key从而来处理问题呢？

对称+非对称加密处理Http安全问题构想.png

这种方式看起来很完美，每个用户端都有一个唯一的key num1，黑客由于没有私钥无法得到解密y得到唯一的num1。那么是不是真的万无一失了呢？

5.2.4 中间人攻击

5.2.3 中的解决方式，存在一个致命的错误，中间人攻击，即Man-in-the-MiddleAttack，简称“MITM攻击”。假如黑客在用户端请求pk的时候就阻拦了请求怎样办呢？

中间人攻击.png

1. 用户端请求pk。
2. 黑客阻拦请求返回自己的pk1（黑客持有自己的密钥对 pk1，sk1）
3. 黑客请求pk，服务端返回pk，黑客记录pk。
4. 用户端用pk1加密随机对称密钥num1，发送服务端。
5. 黑客阻拦num1，并用sk1解密，得到num1。
6. 黑客用pk加密num1，发送给服务端。
7. 用户端使用num1 加密数据发送给服务端
8. 黑客阻拦num1加密的后的数据，并用num1 解密，篡改数据后，再用num1加密发给服务端。

可以看到，黑客在这个请求流程中，充任了一个中间人的角色，由于他能得到了num1，也就意味着他能随便的篡改数据。

总结
对上面的几种加密方式做个总结

• 不加密=明文=裸奔
• 对称加密：key唯一=明文
• 非对称加密：用户端发送服务端时安全，服务端响应用户端时不安全。
• 非对称加密+对称加密：无法预防中间人攻击。

5.2.5 CA 认证

那么就没有一种安全的方式了吗？5.2.4中我们可以看到，中间人攻击的根本起因就是pk在网络上的传输，那么假如我们不在网络中传输pk呢

CA 认证.png

上面的流程有两个前置条件：1. CA机构提前用自己的私钥对服务器的pk进行加密，得到license，并且CA机构肯定是可信的。2. 客户的操作系统里提前写入了CA系统的公钥cpk，可以通过cpk解密license，得到pk。那么假如上述的流程中黑客介入了会怎样样呢？

• 步骤1和步骤2请求license时，黑客介入，返回被劫持后的证书，则利用操作系统的cpk解密会失败，浏览器会提醒不安全。
• 步骤3时黑客介入，由于黑客没有sk，故黑客无法解密得到num1。
• 步骤4时黑客介入，由于黑客没有num1，故黑客无法解密篡改数据。

可以看到利用CA认证，就处理了中间人攻击的问题。由于非对称加密比较耗时，先利用非对称加密协商出唯一key，再利用唯一key做数据加密传输也处理了性能问题。

5.3 Https请求流程

Https 相对于Http多了一步TLS握手的过程。其中TLS握手的流程如下

1. Client Hello。用户端向服务端发送支持TLS版本，支持的加密算法，以及随机数1。
2. Server Hello。服务端向用户端发送使用的TLS版本、使用的加密算法、随机数2。
3. Server certificate,Server Key Exchange,Server Hello Done。服务端向用户端发送证书，协商密钥的报文，以及初次握手结束的通知。
4. Client Key Exchange ,Change Cipher spec,Encrypted HandShake Message。用户端在收到服务端Server Hello Done 的报文后，进行证书的验证，验证的因素包括：证书链能否可信、证书能否吊销、证书有效期、域名。假如验证通过后，给服务端发送协商密钥的报文。
   4.1 Client Key Exchange：用户端计算产生随机数字3，并且将随机数字3用服务端公钥加密后发送服务端。用户端用随机数1和随机数2结合随机数字3，计算得出协商密钥。
   4.2 Change Cipher spec：用户端告诉服务端后续的通信都用协商密钥进行加密通信
   4.3 Encrypted HandShake Message：计算前面向服务端发送的数据生成一个hash作为摘要，并用协商密钥加密后发送给服务端做验证
5. Server Change Cipher spec,Encrypted HandShake Message。服务端在收到用户端的随机数字3后，用私钥进行解密后，而后根据随机数1和随机数2结合随机数3，生成协商密钥。而后将前用户端发过来的所有参数进行hash之后，比较摘要能否相同，从而验证握手能否合法。验证之后向用户端发送数据包。
   5.1 Change ciper spec：服务端告诉用户端以后通信都采用协商密钥进行加密。
   5.2 Encrypted HandShake Message: 服务端经自己已经发送给用户端的数据进行hash摘要后，发送给用户端做有效性认证。
6. Application Data。安全连接建立，发送加密数据。
   TLS 握手过程.png
   上面的过程简单概括就是两件事服务端向用户端传输证书，两端共同商量出一个唯一密钥。

5.4 Https 数据包分析

抓包验证一下上面的TLS握手过程。

1. Https请求数据包总览Https请求数据包总览

• 1.用户端发送支持的加密套件给服务端。
• 2.服务端发送支持的加密套件给用户端 。
• 3.服务端向用户端发送证书、协商密钥的报文及初次握手结束的通知。
• 4.用户端验证服务端的证书，验证通过后利用前面的信息生成唯一密钥，之后发送给服务端并通知服务端切换加密方式。
• 5. 服务端利用相同的方法生成唯一密钥，并校验握手的合法性，而后回复用户端切换加密方式。
• 6-7 安全连接建立，发送加密数据。

2. 用户端向服务端发送支持的加密套件和随机数Client Hello

3. 服务端向用户端发送支持的加密套件和随机数Server Hello

4. 服务端向用户端发送证书、协商密钥的报文及初次握手结束的通知。

   4.1 服务端向用户端发送证书服务端发送证书
   4.2 服务端向用户端发送协商密钥的报文及初次握手结束的通知初次握手结束

5. 用户端生成唯一密钥，并通知服务器切换加密方式

   用户端生成密钥，并将密钥发送给服务端

6. 服务端校验握手的合法性，并得到唯一密钥，同时通知用户端切换加密方式服务端得到密钥，并切换加密方式

7. 连接建立，加密数据传输连接建立，安全数据传输

6. 总结

这篇文章里我们只说了一个问题：Https是怎样做到数据安全的，为了详情这个，我们先铺垫了 网络模型、TCP&UDP、Http。同样，提出几个问题对上面的内容做个总结：

1. Https的请求流程是怎样样的？

• 用户端发送支持的加密套件和随机数
• 服务端发送支持的加密套件和随机数
• 服务端发送证书给用户端，同时选取合适的加密套件，而后通知用户端初次握手结束
• 用户端验证服务端的证书后得到公钥，同时利用上面的随机数生成唯一密钥，而后将唯一密钥用公钥加密后发送给服务端，并通知改变加密方式
• 服务端利用上面的随机数生成密钥，而后比较解密后的密钥和当前密钥，从而确定握手的合法性。之后通知用户端改变加密方式。
• 安全连接建立，数据传输。

2. Https 是如何保证安全性的？

• Https 引入了CA，保证了能得到合法的公钥，可以有效的防止篡改，防止监听、防止伪造。

3. 既然Https是安全的，是不是就不会被抓包了呢？

• Https只是保证了被抓取的数据包是加密的，但是并不能保证不被抓包

4. 有没有办法抓取并解析Https 加密数据包呢？

• 通过将浏览器协商的密钥保存到外置文件中，用抓包工具如wireshark配合这个外置的文件即可以捕获到当前加密的数据包。

5. CA证书干啥用的？

• CA证书防止中间人攻击，可以保证用户端得到服务端正确的公钥。

6. 既然有了Https 那我们接口还要做额外的安全解决吗？

• 当然需要了，Https是作用于协议层面的，一般加解密的工作都是web容器来做的，而接口的加解密取决于具体的业务逻辑。就好比办公室的大门上了锁，个人的抽屉难道就不需要上锁了吗。

水平有限，本文只是对Https做了粗浅的解读，难免有所疏漏，欢迎批评指正。我们下篇文章见…..

话说写文章，真的是费时费力。每次看到个位数的阅读，不禁潸然泪下….

参考文章：
https://baijiahao.baidu.com/s?id=1654225744653405133&wfr=spider&for=pc
https://blog.csdn.net/lengxiao1993/article/details/82771768
https://www.cnblogs.com/fundebug/p/differences-of-tcp-and-udp.html