HTTP协议&HTTP框架｜ 字节青训营笔记

HTTP协议&HTTP框架

HTTP

超文本 传输协议（HTTP， HyperText Transfer Protocol) 是一种用于传输超文本和多媒体内容的协议，主要是为 Web 浏览器与 Web 服务器之间的通信而设计的。当我们使用浏览器浏览网页的时候，我们网页就是通过 HTTP 请求进行加载的。

HTTP 使用客户端-服务器模型，客户端向服务器发送 HTTP Request（请求），服务器响应请求并返回 HTTP Response（响应），整个过程如下图所示。

HTTP 协议基于 TCP 协议，发送 HTTP 请求之前首先要建立 TCP 连接也就是要经历 3 次握手（断开连接，四次挥手） 。目前使用的 HTTP 协议大部分都是1.1。在 1.1 的协议里面，默认是开启了Keep-Alive的，这样的话建立的连接就可以在多次请求中被复用了。

1. 在浏览器中输入指定网页的 URL。
2. 浏览器通过 DNS 协议，获取域名对应的 IP 地址。
3. 浏览器根据 IP 地址和端口号，向目标服务器发起一个 TCP 连接请求。
4. 浏览器在TCP 连接上，向服务器发送一个HTTP请求报文，请求获取网页的内容。
5. 服务器收到 HTTP 请求报文后，处理请求，并返回 HTTP 响应报文给浏览器。
6. 浏览器收到 HTTP 响应报文后，解析响应体中的 HTML 代码，渲染网页的结构和样式，同时根据HTML中的其他资源的URL（如图片、CSS、JS 等），再次发起 HTTP 请求，获取这些资源的内容，直到网页完全加载显示。
7. 浏览器在不需要和服务器通信时，可以主动关闭 TCP 连接，或者等待服务器的关闭请求。

TCP三次握手四次挥手

为了保证客户端和服务器端的可靠连接，TCP建立连接时必须要进行三次会话，也叫TCP三次握手，进行三次握手的目的是为了确认双方的接收能力和发送能力是否正常。

举个例子

公安局长王哥 和 陈某打电话

公安局：你好！陈某，听得到吗？（一次会话）

陈某：听到了，王哥，你能听到吗 （二次会话）

公安局：听到了，你过来自首吧 （开始会话）（三次会话）

通过这个例子我们可以知道三次会话的目的就是为了确保双方的连接正常，同理，TCP三次握手也是这个过程，下面用图文形式来解释一下TCP三次握手。

TCP建立连接过程

最开始的时候客户端和服务器都是处于CLOSED关闭状态。主动打开连接的为客户端，被动打开连接的是服务器。

TCP服务器进程先创建传输控制块TCB，时刻准备接受客户进程的连接请求，此时服务器就进入了 LISTEN 监听状态

SYN是同步位，SYN=1，表示进行一个连接请求；

ACK是确认位，ACK=1，确认有效；ACK=0，确认无效。

ack是确认号，=对方序列号＋1；

seq是序列号；

第一次握手 TCP客户进程也是先创建传输控制块TCB，然后向服务器发出连接请求报文，这是报文首部中的同步位SYN=1，同时选择一个初始序列号 seq=x ，此时，TCP客户端进程进入了 SYN-SENT 同步已发送状态

第二次握手 TCP服务器收到请求报文后，如果同意连接，则会向客户端发出确认报文。确认报文中应该 ACK=1，SYN=1，确认号是ack=x+1，同时也要为自己初始化一个序列号 seq=y，此时，TCP服务器进程进入了 SYN-RCVD 同步收到状态

第三次握手 TCP客户端收到确认后，还要向服务器给出确认。确认报文的ACK=1，ack=y+1，自己的序列号seq=x+1（初始是x,自增1），此时，TCP连接建立，客户端进入ESTABLISHED已建立连接状态 触发三次握手

有人可能会很疑惑为什么要进行第三次握手？

主要原因：防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误

第一次握手： 客户端向服务器端发送报文

证明客户端的发送能力正常

第二次握手：服务器端接收到报文并向客户端发送报文

证明服务器端的接收能力、发送能力正常

第三次握手：客户端向服务器发送报文

证明客户端的接收能力正常

如果采用两次握手会出现以下情况：

客户端向服务器端发送的请求报文由于网络等原因滞留，未能发送到服务器端，此时连接请求报文失效，客户端会再次向服务器端发送请求报文，之后与服务器端建立连接，当连接释放后，由于网络通畅了，第一次客户端发送的请求报文又突然到达了服务器端，这条请求报文本该失效了，但此时服务器端误认为客户端又发送了一次连接请求，两次握手建立好连接，此时客户端忽略服务器端发来的确认，也不发送数据，造成不必要的错误和网络资源的浪费。

如果采用三次握手的话，就算那条失效的报文发送到服务器端，服务器端确认并向客户端发送报文，但此时客户端不会发出确认，由于客户端没有确认，由于服务器端没有接收到确认，就会知道客户端没有请求连接。

TCP四次挥手

建立TCP连接需要三次握手，终止TCP连接需要四次挥手

举个例子

张三和李四的对话

张三：好的，那我先走了

李四：好的，那你走吧

李四：那我也走了？

张三：好的，你走吧

数据传输完毕后，双方都可释放连接。最开始的时候，客户端和服务器都是处于ESTABLISHED状态，然后客户端主动关闭，服务器被动关闭。

第一次挥手 客户端发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态

第二次挥手 服务器端接收到连接释放报文后，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT 关闭等待状态

第三次挥手 客户端接收到服务器端的确认请求后，客户端就会进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文，服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。

第四次挥手 客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态，但此时TCP连接还未终止，必须要经过2MSL后（最长报文寿命），当客户端撤销相应的TCB后，客户端才会进入CLOSED关闭状态，服务器端接收到确认报文后，会立即进入CLOSED关闭状态，到这里TCP连接就断开了，四次挥手完成

为什么客户端要等待2MSL？

主要原因是为了保证客户端发送那个的第一个ACK报文能到到服务器，因为这个ACK报文可能丢失，并且2MSL是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃，这样新的连接中不会出现旧连接的请求报文。

HTTP和HTTPS有什么区别？

端口号：HTTP 默认是 80，HTTPS 默认是 443。

URL 前缀：HTTP 的 URL 前缀是 http://，HTTPS 的 URL 前缀是 https://。

安全性和资源消耗：HTTP 协议运行在 TCP 之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS 是运行在 SSL / TLS 之上的 HTTP 协议，SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS 高，但是 HTTPS 比 HTTP 耗费更多服务器资源。

SEO （ 搜索引擎优化 ） ：搜索引擎通常会更青睐使用 HTTPS 协议的网站，因为 HTTPS 能够提供更高的安全性和用户隐私保护。使用 HTTPS 协议的网站在搜索结果中可能会被优先显示，从而对 SEO 产生影响。

HTTP 协议是”无状态”的协议，它无法记录客户端用户的状态，一般我们都是通过 Session 来记录客户端用户的状态

HTTP 是一种不保存状态，即无状态（stateless）协议。也就是说 HTTP 协议自身不对请求和响应之间的通信状态进行保存。那么我们如何保存用户状态呢？Session 机制的存在就是为了解决这个问题，Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了（一般情况下，服务器会在一定时间内保存这个 Session，过了时间限制，就会销毁这个 Session）。

在服务端保存 Session 的方法很多，最常用的就是内存和数据库(比如是使用内存数据库 redis 保存)。既然 Session 存放在服务器端，那么我们如何实现 Session 跟踪呢？大部分情况下，我们都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪。

Cookie 被禁用怎么办?

最常用的就是利用 URL 重写把 Session ID 直接附加在 URL 路径的后面。

URI 和 URL 的区别是什么?

• URI(Uniform Resource Identifier) 是统一资源标志符，可以唯一标识一个资源。（相当于身份证）
• URL(Uniform Resource Locator) 是统一资源定位符，可以提供该资源的路径。它是一种具体的 URI，即 URL 可以用来标识一个资源，而且还指明了如何 locate 这个资源。
• URI 的作用像身份证号一样，URL 的作用更像家庭住址一样。URL 是一种具体的 URI，它不仅唯一标识资源，而且还提供了定位该资源的信息。

HTTP 常见状态码总结（应用层）

HTTP 状态码用于描述 HTTP 请求的结果，比如 2xx 就代表请求被成功处理。

• 200 OK：请求被成功处理。比如我们发送一个查询用户数据的 HTTP 请求到服务端，服务端正确返回了用户数据。这个是我们平时最常见的一个 HTTP 状态码。
• 201 Created：请求被成功处理并且在服务端创建了一个新的资源。比如我们通过 POST 请求创建一个新的用户。
• 202 Accepted：服务端已经接收到了请求，但是还未处理。
• 204 No Content：服务端已经成功处理了请求，但是没有返回任何内容。

这里格外提一下 204 状态码，平时学习/工作中见到的次数并不多。

简单来说，204 状态码描述的是我们向服务端发送 HTTP 请求之后，只关注处理结果是否成功的场景。也就是说我们需要的就是一个结果：true/false。

举个例子：你要追一个女孩子，你问女孩子：“我能追你吗？”，女孩子回答：“好！”。我们把这个女孩子当做是服务端就很好理解 204 状态码了。

3xx Redirection（重定向状态码）

• 301 Moved Permanently：资源被永久重定向了。比如你的网站的网址更换了。
• 302 Found：资源被临时重定向了。比如你的网站的某些资源被暂时转移到另外一个网址。

4xx Client Error（客户端错误状态码）

• 400 Bad Request：发送的 HTTP 请求存在问题。比如请求参数不合法、请求方法错误。
• 401 Unauthorized：未认证却请求需要认证之后才能访问的资源。
• 403 Forbidden：直接拒绝 HTTP 请求，不处理。一般用来针对非法请求。
• 404 Not Found：你请求的资源未在服务端找到。比如你请求某个用户的信息，服务端并没有找到指定的用户。
• 409 Conflict：表示请求的资源与服务端当前的状态存在冲突，请求无法被处理。

5xx Server Error（服务端错误状态码）

• 500 Internal Server Error：服务端出问题了（通常是服务端出 Bug 了）。比如你服务端处理请求的时候突然抛出异常，但是异常并未在服务端被正确处理。
• 502 Bad Gateway：我们的网关将请求转发到服务端，但是服务端返回的却是一个错误的响应

GET与POST请求的区别

在Web开发中，GET和POST是两种最常见的HTTP请求方法，它们在发送数据到服务器时有一些本质的区别。

GET请求通常用于获取数据。当你使用GET请求时，请求的参数会附加在URL之后，形成查询字符串，通过URL传送。这种方式的特点是可见性高，因为参数直接显示在地址栏中，但这也意味着对于敏感信息来说安全性较低。此外，GET请求可以被缓存，保留在浏览器历史记录中，甚至可以被收藏为书签。但GET请求对URL长度有限制，通常在1KB到2KB之间，这限制了可以发送的数据量。GET请求只支持URL编码，不支持像POST请求那样的多种编码方式。

POST请求通常用于提交数据。与GET不同，POST请求的数据不会附加在URL之后，而是放在HTTP消息的主体中，这使得数据的大小没有限制，同时提高了数据的隐私性，因为它不会显示在地址栏中。POST请求不会被缓存，也不会保留在浏览器历史记录中，不能被收藏为书签。POST支持多种编码方式，包括二进制编码，因此它适用于文件上传等操作。

从技术角度来看，GET和POST都是基于TCP/IP的HTTP协议的请求方式。GET请求通常只产生一个TCP数据包，而POST请求可能产生两个TCP数据包（虽然某些浏览器如Firefox只发送一个数据包）。对于GET请求，浏览器会将HTTP头和数据一起发送，服务器响应200表示成功。而对于POST请求，浏览器先发送头部，服务器响应100继续，然后浏览器发送数据，服务器再次响应200表示成功。

总结来说，GET请求适用于请求数据，而POST请求适用于提交数据。在处理敏感信息或大量数据时，应优先考虑使用POST请求。

WebSocket

WebSocket 是一种基于 TCP 连接的全双工通信协议，即客户端和服务器可以同时发送和接收数据。

WebSocket 协议在 2008 年诞生，2011 年成为国际标准，几乎所有主流较新版本的浏览器都支持该协议。不过，WebSocket 不只能在基于浏览器的应用程序中使用，很多编程语言、框架和服务器都提供了 WebSocket 支持。

WebSocket 协议本质上是应用层的协议，用于弥补 HTTP 协议在持久通信能力上的不足。客户端和服务器仅需一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。

WebSocket 和 HTTP 两者都是基于 TCP 的应用层协议，都可以在网络中传输数据。

WebSocket 和 HTTP二者的主要区别

• WebSocket 是一种双向实时通信协议，而 HTTP 是一种单向通信协议。并且，HTTP 协议下的通信只能由客户端发起，服务器无法主动通知客户端。
• WebSocket 使用 ws:// 或 wss://（使用 SSL/TLS 加密后的协议，类似于 HTTP 和 HTTPS 的关系） 作为协议前缀，HTTP 使用 http:// 或 https:// 作为协议前缀。
• WebSocket 可以支持扩展，用户可以扩展协议，实现部分自定义的子协议，如支持压缩、加密等。
• WebSocket 通信数据格式比较轻量，用于协议控制的数据包头部相对较小，网络开销小，而 HTTP 通信每次都要携带完整的头部，网络开销较大（HTTP/2.0 使用二进制帧进行数据传输，还支持头部压缩，减少了网络开销）。

WebSocket 的工作过程

1. 客户端向服务器发送一个 HTTP 请求，请求头中包含 Upgrade: websocket 和 Sec-WebSocket-Key 等字段，表示要求升级协议为 WebSocket；
2. 服务器收到这个请求后，会进行升级协议的操作，如果支持 WebSocket，它将回复一个 HTTP 101 状态码，响应头中包含 ，Connection: Upgrade和 Sec-WebSocket-Accept: xxx 等字段、表示成功升级到 WebSocket 协议。
3. 客户端和服务器之间建立了一个 WebSocket 连接，可以进行双向的数据传输。数据以帧（frames）的形式进行传送，WebSocket 的每条消息可能会被切分成多个数据帧（最小单位）。发送端会将消息切割成多个帧发送给接收端，接收端接收消息帧，并将关联的帧重新组装成完整的消息。
4. 客户端或服务器可以主动发送一个关闭帧，表示要断开连接。另一方收到后，也会回复一个关闭帧，然后双方关闭 TCP 连接。

另外，建立 WebSocket 连接之后，通过心跳机制来保持 WebSocket 连接的稳定性和活跃性。

使用HTTP协议发送信息

1. 打开彩云小译官网
2. 输入需要查询的单词
3. 点击翻译按钮
4. 等待页面返回结果

查单词是一种服务，词典可以提供这项服务，英语老师可以提供这项服务，电脑也可以提供这项服务。你只要给定单词，就能得到释义。只不过你给出单词的形式不同，得到释义的形式也各不相同。

提供查单词服务的电脑，我们就把它叫做服务器。我们通过自己的电脑查单词，我们的电脑叫做客户端，毕竟客户是上帝。

现在客户端和服务器想要通信，怎么让客户端把单词发到服务器呢？

茫茫网海中，有不止一台服务器提供服务，也有不止一台客户端在消费服务。我们必须明确，需要和哪一台服务器交流。

信件封面（可能是）：彩云小译服务器在网络上的地址

信件内容（可能是）：你好，彩云小译服务器，我想查一下pretty这个单词是什么意思，谢谢。

HTTP协议是什么

HTTP协议是一种约定、一种规范、一种协议。就像你在寄快递时需要填写这些内容。

除了要快递的物品本身，我们还需要附加填写很多信息，并且这些信息都具有一定的格式和约束，归根结底，是为了促进快递的高效流通。那么HTTP协议中又有什么样的约定或者要求呢？

HTTP报文的内容

HTTP报文的结构由报文首部、空行、报文主体组成。

组成部分	作用
报文首部	传递信息时必不可少的一些附加信息	快递包裹表面的快递纸
空行	用于分割报文首部和报文主体	泡沫包装将快递纸和物品隔离开。
报文主体	信息的内容	快递的物品本身

与看得见摸得着的快递包裹不同，HTTP报文的本质是一串字节序列，在网络流中由不同设备进行处理，因此HTTP报文的每一部分都有自己的格式要求，便于设备能够读懂。

下面是请求报文和响应报文的示例：

请求报文

报文结构：

部分	内容
报文首部	POST /form/entry HTTP/1.1
	Host: hackr.jp
	Connection: keep-alive
	Content-Type: application/x-www-form-urlencoded
	Content-Length: 16
空行
报文主体	name=ueno&age=37

其中，报文首部又可以进一步划分。 请求报文的报文首部可划分为以下部分。

• 请求行 POST /form/entry HTTP/1.1

• 请求首部字段

• 通用首部字段

• 实体首部字段

• 其他

请求行

在上面的示例中，请求行就是POST /form/entry HTTP/1.1，分别对应请求行的三个组成部分：方法、URI、HTTP版本。 方法表示客户端访问服务器的类型，在本例中，方法是POST，除了该方法，常用的还有GET等，这些方法都是HTTP协议预先定义好的，只需要选择恰当的方法就可以。在本文中，我不对这些方法进行详细阐述，目前我们只需要暂时记住就可以。 URI表示需要访问的服务器上的资源地址，URI的全称是Uniform Resource Identifier，统一资源标识符，用于在浩瀚如烟的互联网中标记资源的位置，你可以暂时理解为查询单词的服务器所在的地址。 HTTP版本，显而易见，表示我们正在使用的HTTP协议的版本。在HTTP发展的历程中，HTTP的版本也在不断发生变化，不同的HTTP版本，使用的规范也有所不同。我们也暂时只需记住，无需深究。

首部字段

首部字段相当于寄快递所需的附加信息，这些信息绝大部分都不需要我们自己提供，浏览器会自动填写这一切，拿Host: hackr.jp举个例子，表明了HTTP报文前往的目的地，也就是域名为hackr.jp的服务器。该字段和URI结合，便能够准确地将信息发送到我们想要的那台服务器。

报文主体

报文主体就是我们要发送的内容本身，等同于包裹里的物品，信件中的正文，这里不过多解释。

响应报文

报文结构：

部分	内容
报文首部	HTTP1.1 200 OK
	Date: Tue, 10 Jul 2023 15:39:30 GMT
	Content-Type: text/html
	Content-Length: 362
空行
报文主体	...

响应报文的报文首部可划分为以下部分。

• 状态行
• 响应首部字段
• 通用首部字段
• 实体首部字段
• 其他

状态行

状态行由协议版本、状态码（表示请求成功或失败的数字代码）、用以解释状态码的原因短语构成。

状态行开头的HTTP/1.1表示服务器对应的HTTP的版本。紧接着的200 OK表示请求的处理结果的状态码和原因短语。

首部字段

Date表示响应创建的日期和时间，是首部字段内的一个属性。

Content-Type: text/html表示响应报文的报文主体的内容格式，是文本类型中的html文本。除此之外，还可以是图片文件、视频文件、JSON、二进制类型等。

Content-Length: 362表示报文主体的大小。

报文主体

服务器接收到请求报文并处理后，需要返回的内容就在报文主体中，发送给客户端处理。

第一层：应用层(业务层)

第二层：中间件层(服务治理层)

1. 配合 Handler 实现一个完整的请求处理生命周期

   • 在一个典型的网络应用程序中，当客户端发送一个请求时，服务器需要对这个请求进行处理并返回响应。这个处理过程通常涉及多个步骤，从接收请求到最终返回响应。
   • Handler是负责实际处理请求的组件。它接收请求，执行必要的业务逻辑（如查询数据库、执行计算等），然后生成响应。
   • 中间件（Middleware） 则是在请求到达 Handler 之前和 Handler 处理完请求之后执行额外逻辑的组件。中间件与 Handler 协同工作，确保请求在整个生命周期内得到完整处理。
   • 例如，在一个 Web 应用中，当用户请求一个网页时，请求首先经过中间件（如身份验证中间件），然后到达处理该请求的 Handler（如返回网页内容的函数），最后可能再次经过中间件（如日志记录中间件），整个过程构成了一个完整的请求处理生命周期。

2. 拥有预处理逻辑与后处理逻辑

   • 预处理逻辑

     • 预处理逻辑是指在请求到达实际处理程序Handler之前执行的逻辑。它可以用于检查请求的合法性、验证用户身份、设置请求上下文等。
     • 例如，在一个 Web API 中，权限验证中间件可以在请求到达实际的 API 处理函数之前，检查请求中携带的用户令牌是否有效。如果令牌无效，中间件可以直接返回错误响应，阻止请求继续向下传递。

   • 后处理逻辑

     • 后处理逻辑是指在 Handler 处理完请求之后执行的逻辑。它通常用于记录请求处理结果、清理资源、修改响应内容等。
     • 例如，在一个 Web 应用中，日志记录中间件可以在 Handler 返回响应之后，记录请求的处理时间、返回的状态码等信息，以便进行性能分析和故障排查。

3. 可以注册多中间件

   • 在一个复杂的系统中，通常需要多个中间件来处理不同方面的逻辑。系统需要支持注册多个中间件，以便在请求处理过程中依次应用这些中间件。
   • 例如，一个 Web 应用可能同时需要身份验证中间件、日志记录中间件和性能监控中间件。当请求到来时，首先经过身份验证中间件进行身份验证，然后经过性能监控中间件记录请求开始处理的时间，接着到达 Handler 进行实际处理，最后经过日志记录中间件记录请求处理结果和性能数据。
   • 这种多中间件的设计使得系统可以灵活地组合不同的功能模块，满足复杂的业务需求。

4. 对上层模块用户逻辑模块易用

   • 中间件的设计应该考虑到上层模块（如用户逻辑模块）的易用性。这意味着中间件应该提供简单、直观的接口，使得上层模块可以方便地使用中间件提供的功能，而不需要复杂的配置或调用过程。
   • 例如，在一个基于框架开发的 Web 应用中，开发者应该能够通过简单的配置或装饰器（decorator）来注册和使用中间件，而不需要深入了解中间件的内部实现细节。
   • 这种易用性设计可以提高开发效率，降低系统的复杂性，使得开发者可以更专注于业务逻辑的实现。

中间件在系统设计中起到了至关重要的作用。它通过预处理和后处理逻辑，可以增强系统的功能（如权限验证、日志记录等）和安全性（如防止非法访问），同时保持系统的易用性，使得上层模块可以方便地使用这些功能。多个中间件的灵活组合可以满足复杂的业务需求，提高系统的可扩展性和可维护性。

路由层是URI进行选择执行的Handler（http在第七层，tcp在第四层）

1. HTTP1：

   • 特点：

     • 队头阻塞：在一个连接中，当前请求未完成时，后续请求会被阻塞。例如，当请求一个网页时，浏览器需要逐个获取 HTML、CSS、JavaScript、图片等资源，容易出现队头阻塞问题，有多个资源需要获取，浏览器通常会打开多个连接（一般为 6 个左右）来并行获取资源，但这仍然受到限制。
     • 传输效率低：数据传输效率不高。
     • 明文传输不安全：数据以明文形式传输，存在安全隐患。

2. HTTP2：

   • 特点：

     • 多路复用：可以在一个连接上同时处理多个请求和响应，提高了效率。没有队头阻塞问题，可以在一个连接上并行地获取网页中的所有资源，大大提高了资源获取的效率。
     • 头部压缩：对 HTTP 头部进行压缩，减少数据量。HTTP1的请求和响应头部没有压缩机制，通常会包含大量重复的信息（如 User - Agent、Cookies 等），这增加了数据传输量。HTTP2采用了HPACK头部压缩算法，对请求和响应头部进行压缩。这种压缩机制可以显著减少头部数据量，通常能减少 50% - 90% 的头部大小，加快了数据传输速度。
     • 二进制协议：采用二进制格式进行数据传输，比文本格式更高效。 二进制格式也使得协议更加健壮，减少了因解析错误导致的性能损耗。 HTTP1 是基于文本的协议，解析文本协议相对较慢，且容易出现错误。
     • 服务器推送：HTTP1 没有服务器推送机制，浏览器只能逐个请求资源。HTTP2 允许服务器在客户端请求之前主动推送资源。例如，当浏览器请求 HTML 文件时，服务器可以主动推送相关的 CSS 和 JavaScript 文件，减少了浏览器等待资源请求的时间。

3. QUIC：

   • 特点：

     • 基于 UDP 实现：使用用户数据报协议（UDP）进行数据传输，避免了 TCP 的一些限制。与 HTTP2 基于 TCP 不同，UDP 没有 TCP 的三次握手和四次挥手等连接建立和关闭的开销。这使得 QUIC 在连接建立速度上有很大优势，尤其是在移动网络和网络切换频繁的场景下。

     • 解决队头阻塞：通过 UDP 的特性，避免了 HTTP1 中的队头阻塞问题。QUIC 在应用层实现了类似 HTTP2 的多路复用功能，并且由于基于 UDP，避免了 TCP 协议中的队头阻塞问题。在 TCP 中，一个丢包可能会导致整个连接的传输阻塞，而 QUIC 能够更灵活地处理丢包情况，只影响单个流而不影响其他流的传输。

     • 加密减少握手次数：数据加密并且减少了连接建立时的握手次数，提高了安全性和效率。 QUIC 从一开始就对数据进行加密，并且采用了 0 - RTT（Round - Trip Time）连接建立机制。 这意味着在某些情况下（如客户端和服务器之前有过连接），客户端可以立即发送数据，无需等待加密握手完成，大大提高了传输效率。

     • 支持快速启动：能够快速建立连接并开始数据传输。

这些协议在网络通信中各有优缺点，HTTP2 和 QUIC 在效率和安全性方面较 HTTP1 有显著提升。QUIC 在连接建立速度和对丢包环境的适应性方面表现更优，而 HTTP2 在现有的基于 TCP 的网络架构中也有很好的性能提升。