随着建站成本的日益降低，使用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不可靠。先上一个完整的对比：

特性	TCP	UDP
面向连接	面向连接	无连接
可靠性	可靠，有拥塞控制和ack	不可靠，没有拥塞控制和ack
连接对象个数	单播	单播，多播，光播
传输方式	字节流	报文
头部开销	20个字节	8个字节
适用场景	可靠性要求高，如文件传输	实时性要求高，可靠性要求不高，如视频电话

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. 客户端发送SYN syn.png
2. 服务端发送SYN,ACK syn,ack.png
3. 客户端发送ACK ack.png
4. Http request http request.png
5. Http response http 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