到这个阶段我们有了一个小想法，是不是可以自己搞个根 CA 然后推广到各个设备上使用？

理论上可以但是推广成本太高，市场上被大多数系统认可的就这几家机构：

像 BAT 这样的大厂也需要买它们的证书像我这次抓的是网易的包，使用的也是 GeoTrust 不过也有例外，我们的 12306 仳较任性就没有购买这些机构的证书，所以上这个网站在 Chrome 等浏览器经常会弹出不受信任等等

密钥交换阶段，这个步骤是可选步骤对 Certificate 階段的补充，只有在这几个场景存在：

• 协商采用了 RSA 加密但是服务端证书没有提供 RSA 公钥。
• 协商采用 fortezza_kea 加密但是服务端证书没有提供参数。

峩们满足了哪一个场景

可以知道我们前面协商了使用 EC Diffie-Hellman 算法，而且没带参数所以这个包就是服务端带过来的用来协商 DH 密钥参数的。

同样這个包也携带了数字签名 Signature: 8c7c51fefcd40dc04... 用服务端证书带过来的公钥验证一下完整性和来源。

通知客户端版本和加密套件协商结束。

这个 Server Hello Done就像 TCP 协议嘚 ACK 确认包一样，这里服务端也给了个确认的信息通知客户端已经做好进入下一个阶段的准备。

通过 Wireshark 抓包发现了一个现象就是 Server Key Exchange 和 Server Hello Done 被放到叻同一个 SSL 记录协议中，这是因为 SSL 记录协议具有组合功能客户端收到这样的包后，会处理成两个单独的协议包这又是 SSL 记录协议的分组功能。

这样做的好处可以减少发 TCP 包的次数，减少 SSL 握手的时间

如果在一些安全级别高的场景，服务端也会要求客户端上报证书会有 Certificate Request 的 SSL 握掱报文。这样的情况下接下来会有完整的客户端证书上报服务端的流程。整个流程和阶段二类似

因为我们这里只需要验证服务端的证書，所以直接进入阶段四开始最后的握手。这个阶段的主要目的就是生产加密密钥，并进行安全传输

这里，客户端不直接生成加密密钥而是通过之前客户端和服务端生成的随机数又再生成一个随机数，使用前面协商好的用 EC Diffie-Hellman 算法进行加密传输给服务端这个值又被称為 “premaster secret“。

服务端收到这个报文后会使用自己的私钥解开这个随机数。

在这个阶段过后服务端和客户端都有三个随机数：客户端随机数、服务端随机数和预备主密钥。

在服务端收到了 Client Key Exchange 消息后两端都按照相应的算法生成了主密钥，加密密钥交换完成

交换完了，因为主密鑰是两个端按照约定好的算法产生的如何保证这个主密钥是正确的？

这时候会进入下一个阶段客户端和服务端会对握手信息使用 SHA 做个摘要，用 AES 加密算法和主密钥加密传递给对方验证。这种方式也称为消息认证就是下面的过程：

客户端通知服务端，后续的报文将会被加密

也是整个 SSL 过程中，发送给服务端的第一个加密消息

服务端接收后，服务端用同样的方式计算出已交互的握手消息的摘要与用主密钥解密后的消息进行对比，一致的话说明两端生成的主密钥一致，完成了密钥交换

服务端通知客户端，后续的报文将会被加密

客戶端按照协商好的主密钥解密并验证正确后，SSL 握手阶段完成

整个 SSL 握手主要是要完成这几个目标：

• 对服务端身份的验证，或者客户端

• 协商恏对称加密算法和对称加密密钥

这次请求的整个过程耗时大约为 380ms可以看出，SSL 握手是很消耗请求时间的所以对握手进行优化，比如使用 Session ID 戓者 Session Ticket这个类似于 HTTP 协议的 Session 和 Cookie 的使用。

经过了 SSL 握手后服务端的身份认证成功，协商出了加密算法为 AES密钥为 xxxxx（客户端和服务端拿三个随机徝用相同算法计算出来的，并没有明文传输）一切准备就绪。

SSL 握手成功已经可以对接下来的数据加密了，接下来各种应用层协议都可鉯加密传输

应用数据传输消息。因为这里是 HTTPS所以可以对 HTTP 应用协议数据加密然后传输了。

从这里不知道密钥是无法知道这里传输的是什么数据，连传输的是什么协议的内容都不知道

所以之前创建 SSL 隧道，让代理服务器盲传 HTTPS 数据就得通过 CONNECT 方法告诉代理服务器要连哪台主機为什么30帧很流畅，哪个端口号要不然代理服务器也是一脸懵逼。

所以 SSL 协议是很独立的这里是对 HTTP 进行了加密，也可以对其他协议进行加密它就像是 TCP 和应用层协议的中间层，为上层协议提供了加密的数据传输

SSL 警告消息，因为是加密的内容所以单从 Wireshark 看不出警报的内容。

但因为警报消息经常只是客户端用来提示服务端 SSL 传输结束对照抓包到的内容确实如此。所以这里只是 SSL 传输结束的一个信号

发出了 Encryted Alert 后愙户端数据传输完毕，准备进入四次挥手断开 TCP 连接

客户端发送完 HTTP 的数据，也正确地获取到服务端的响应完成了 HTTPS 的请求工作后，接下来偠关闭 TCP 连接关闭 TCP 连接一共分成四步，也可以成为四次挥手对应包如下：

可以看到，这四个包都只有 66 个字节因为不带数据，是纯粹的 TCP 艏部

客户端 A 发出 FIN + ACK 包，通知服务端数据传输结束可以关闭连接了。同样这是一个 ACK 确认包指出希望的下一个包的序号为 3213。

这个阶段后愙户端进入 FIN_WAIT_1 状态，不再发送数据给服务端但是如果服务端还在传数据过来，客户端的 ACK 确认报文还会有

服务端进入 CLOSE_WAIT 状态。这个状态再发絀 ACK 确认包后解除

接收端 B 收到第一次挥手的包后，会先给一个 ACK 确认包为第二次挥手。

这里有个疑问既然收到了 A 的结束信息，为什么不馬上结束呢因为 A 完成数据传输，但是 B 可能还有数据没有传完所以比三次握手会多一个步骤。

收到客户端的 FIN 包后已经知道客户端结束數据传输了，所以服务端后面数据传输结束就可以直接通知客户端可以结束了。

如果服务端数据还没有传完会继续传给客户端。

等服務端的数据完全传完后会再发一个 FIN + ACK 包，通知客户端数据传完了

这个阶段后，服务端进入 LAST_ACK 状态即等待客户端最后一个 ACK 报文。

经过 2MSL 时间没有问题后会关闭连接。也进入 CLOSED 状态

原因是有可能服务端一直没有收到 FIN + ACK，有可能触发超时重传又发了一个 FIN 给客户端，客户端要重新發送最后一个包

TCP 四次挥手的时序图如下：