这里只是让自己更好的理解HTTP和HTTPS的区别，HTTPS在HTTP的基础上做了什么，介绍也非常简单，大家可以去看HTTP 与 HTTPS 的区别
，下面很多图也是复制上面链接的
文章目录
0、HTTP请求在网络七层协议中如何传输的
为什么单独写这个呢？还是0？
原本没有这个，受同事的启发，感觉重新梳理一下HTTP请求和七层协议非常有必要，有助于大家更好理解下面后面的东西
(1)七层、五层和四层协议模型每层之间的对应关系。
网络7层协议，4层，5层？理清容易混淆的几个概念
下面的图是复制里面的图，大家可以去看一下
五层协议模型是把OSI七层中应用层、表示层、会话层合并成应用层，但是既然能合并，当然也能拆分，所以不要过于钻牛角尖，
四层协议模型也叫TCP/IP模型，通过图你可以理解成运输层的协议不同，导致的，并且把数据链路层和物理层合并成网络接口层(只是这归纳成一层，实际机器上还是两层，因为数据链路层和物理层的各自负责不同决定的)。
(2)两台机器如何进行数据的交互(0和1信号的交互)
这里用五层协议模型来说明，当然我不会说是因为我截的百度百科视频截图是五层
下面的解释只是初步的解释，物理层和数据链路层详细的特性这里不进行说明
物理层:绿色双向箭头，物理层主要是两台机器之间用什么介质传导数据，就像图片中两台电脑的传输媒体介质可以有多种
数据链路层:绿色双向箭头中的01010101…，机器只能识别0和1，数据链路主要是把需要传输的数据包根据某种规则分组生成0和1，这些0和1在物理层传输，在另一端的数据链路层把这些0和1根据某种规则转成数据包
(3) 发送端到接收端一次数据全流程，
可以先看下面这张图(图中传输层=运输层，链路层=网络接口层)
这里不要误解认为一次请求就是上面这种，那是错误的
举个例子: HTTP三次握手中第一握手，客户端发送SYN报文，如果报文被分成了三个数据包，那第一次握手至少会经历上面三次流程
1、HTTP三次握手
首先看一张图
上面的图解很详细的介绍了三次握手每次请求发生客户端和服务端的状态的变化，在请求中的数据也有画。
下面看一个画风稍微漫画风的三次握手
注意: 在三次握手过程中，只是客户端和服务端网络层进行连接的过程，像请求中的报文，body，header是不会在握手前两次携带数据，第三次可不可以携带数据需要看通讯协议和双方是否支持
2、HTTPS中的S是在HTTP的三次握手后进行协商加解密
所以HTTPS响应速度肯定是比HTTP慢的，因为HTTP没有后续客户端和服务端加解密协商这几步
当然在特殊情况下，TLS也是可以绕过TCP三次握手的，记住是绕过
下面看一张图，下面这张图是TLS的四次握手，出现下面这张图之前，HTTP三次握手已经完成
（1）TLSv1.2
给面试官上一课：HTTPS是先进行TCP三次握手，再进行TLS四次握手
这里不管是TLSv1.2还是TLSv1.3，都是必须先完成HTTP三次握手之后再进行TLS的握手，只是TLS握手1.2是四次，1.3是两次。前提是TLSv1.3不开启Fast Open
所以在TLSv1.2版本是先三次握手，再4次TLS握手，也可以结合下面的TLS1.2 交互图一起看
（2）TLSv1.3
从TLSv1.2升级到TLSv1.3，只需要 1-RTT 就能完成 TLS 握手，而TLSv1.2 握手过程需要经过 2-RTT 才能完成握手（下面两个交互图最后两条交互是请求报文和响应，不归属与TLS）
看一下TLSv1.2和TLSv1.3版本交互的区别
（3）TLSv1.3开启了 TCP Fast Open 功能，TCP三次握手和TLS同步执行
上面也说了，可以TCP三次握手和TLS一起进行，当然需要特殊情况，满足下面两个条件
1、客户端和服务端都开启了 TCP Fast Open 功能，且 TLS 版本是 1.3；
2、客户端和服务端已经完成过一次通信。
3、Linux 3.7 内核版本之后，提供了 TCP Fast Open 功能
1)首先看一下开启TCP Fast Open后第一次通信
- 客户端发送
SYN报文，该报文包含Fast Open选项，且该选项的Cookie为空，这表明客户端请求Fast Open Cookie； - 支持
TCP Fast Open的服务器生成Cookie，并将其置于SYN-ACK报文中的Fast Open选项以发回客户端； - 客户端收到
SYN-ACK后，本地缓存Fast Open选项中的Cookie
2)再看一下开启TCP Fast Open并且已经通信一次的前提下后续的通信
- 客户端发送 SYN 报文，该报文可以携带「应用数据」以及此前记录的 Cookie；
- 支持 TCP Fast Open 的服务器会对收到 Cookie 进行校验：如果 Cookie 有效，服务器将在 SYN-ACK 报文中对 SYN 和「数据」进行确认，服务器随后将「应用数据」递送给对应的应用程序；如果 Cookie 无效，服务器将丢弃 SYN 报文中包含的「应用数据」，且其随后发出的 SYN-ACK 报文将只确认 SYN 的对应序列号
- 如果服务器接受了 SYN 报文中的「应用数据」，服务器可在握手完成之前发送「响应数据」，这就减少了握手带来的 1 个 RTT 的时间消耗
- 客户端将发送 ACK 确认服务器返回的 SYN 以及「应用数据」，但如果客户端在初始的 SYN 报文中发送的「应用数据」没有被确认，则客户端将重新发送「应用数据」
- 此后的 TCP 连接的数据传输过程和非 TCP Fast Open 的正常情况一致
3)结论
所以，如果客户端和服务端同时支持 TCP Fast Open 功能，那么在完成首次通信过程后，后续客户端与服务端 的通信则可以绕过三次握手发送数据，这就减少了握手带来的 1 个 RTT 的时间消耗
4)TLSv1.3会话恢复机制
这里不和TLSv1.3开启Fast Open的比较，因为开启Fast Open的相当于在TCP三次握手阶段就传输数据了，这里比较的都是必须先进正常TCP三次握手后，减少TLS握手的次数
TLSv1.2需要4次握手(2-RTT)，
TLSv1.3(不开启Fast Open)需要2次握手(1-RTT)，
TLSv1.3开启会话恢复机制可以0次TLS握手(0-RTT)
会话恢复依赖于在初始握手期间传递给客户端设备的标识符，并且因为这个标识符（会话ID、会话记录单、PSK身份）在浏览器的TLS缓存中持续存在，所以可以像跟踪任何其他数字标识符一样对其进行跟踪，在 TCP 连接后立即就建立安全连接发送加密消息。
下面是TLSv1.3不开启和开启会话恢复机制的比较图
4、TCP四次挥手
TCP三次握手四次挥手详解下面的图是我复制这个链接里的，我也懒得自己去抓包了
下面是抓包的图，我复制的
