开发: C++知识库 Java知识库 JavaScript Python PHP知识库人工智能区块链大数据移动开发嵌入式开发工具数据结构与算法开发测试游戏开发网络协议系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑笔记本显卡显示器固态硬盘硬盘耳机手机 iphone vivo oppo 小米华为单反装机图拉丁

-> 网络协议 -> HTTP和HTTPS简单介绍(TCP三次握手四次挥手和TLS 2或4 次握手) -> 正文阅读

[网络协议]HTTP和HTTPS简单介绍(TCP三次握手四次挥手和TLS 2或4 次握手)

这里只是让自己更好的理解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 的正常情况一致