前言
做Web后台开发的，基本都知道自己用到了http协议，对于HTTP协议的三板斧（协议起始行、请求头、请求体）可以说是无比熟悉。但是对于HTTP协议版本可能并没有过多的去了解。本篇文章会对HTTP的三个重要版本的特性进行介绍，总结新版本的协议优势以及如何在项目中进行应用，希望对各位读者有所帮助。
HTTP1.0、HTTP1.1和HTTP2是HTTP协议的不同版本，它们在性能、功能和特性上有一些重要区别。
需要注意的是，HTTP1.0版本之前，还有一个HTTP0.9版本，不过因为HTTP0.9版本只支持GET请求，协议十分简单，很快就被后面的1.0版本给取代了。下面我们就正式来介绍这三个版本的协议。，是第一个广泛应用的HTTP协议版本。它引入了多个HTTP方法（GET、POST等），支持请求头和响应头，以及状态码等特性。
一、 HTTP1.0（于1996年推出）
- 引入了多个HTTP方法（GET、POST等），支持请求头和响应头，以及状态码等特性
- 建立连接后，每个请求都需要单独的TCP连接。
- 不支持持久连接，每个请求/响应周期后都会关闭连接。
- 不支持请求的优先级和流控制。
- 不支持请求头压缩，每个请求都会发送完整的头部信息。
- 不支持服务端推送。
我们可以看到，HTTP1.0虽然可以支持我们做一些日常场景的通信，但是通信的成本比较高。主要的原因有两点：①是每次请求都需要经过三次握手四次挥手，延长了总体的通信时间，这才加载前端资源的时候尤为明显（以前没有异步请求的概念，每次网络请求消耗的资源估计要更高） ②大部分请求的请求头都是一样的，每次请求都要带重复的信息是一种资源浪费
二、 HTTP1.1（于1997年推出）
- 引入了持久连接，多个请求可以通过同一个TCP连接进行处理，减少了连接建立的开销。
- 支持请求的优先级和流控制。
- 引入了请求头压缩（例如gzip），减少了重复的头部信息传输。
- 支持使用管道（pipelining）发送多个请求，但仍然存在头阻塞问题。
- 仍然存在同一时间只能处理一个请求的限制。
HTTP1.1的新特性是相对于HTTP1.0来说的，下面我们来具体说说这些特性吧。
1、持久连接
HTTP/1.1引入了持久连接的概念，允许在同一个TCP连接上发送多个请求和接收多个响应。这样可以避免为每个请求都建立新的连接，从而减少了连接的建立和拆除开销，提高了性能和效率。简单来说，持久连接使得客户端和服务端交互的时候，可以不用频繁进行握手挥手操作，减少因为重复建立和拆除连接而产生的时间和资源消耗。这对于网页加载速度和性能有着明显的改进，特别是在多个资源（如图像、样式表、脚本等）需要从服务器请求的情况下。
使用持久连接的过程如下：
（1）客户端发送一个请求到服务器，并在请求头中包含Connection: keep-alive字段，表示希望保持连接。
（2）服务器接收到请求后，发送相应的响应给客户端，并在响应头中也包含Connection: keep-alive字段，表示服务器同意保持连接。
（3）在保持连接的状态下，客户端可以继续发送其他请求到服务器，而不需要重新建立连接。
（4）服务器接收到这些额外的请求后，分别处理请求并发送相应的响应。
需要注意的是，即使使用了持久连接，HTTP/1.1仍然存在队头阻塞（Head-of-line blocking）的问题。由于在一个TCP连接上只能同时处理一个请求，如果前面的请求耗时较长，后续的请求必须等待。
2、请求的优先级
在HTTP/1.1中，每个请求都可以带有一个优先级（priority）信息，用于指示请求的重要性或紧急程度。这样可以确保重要的请求获得更高的优先级，从而更早地得到服务和响应。
请求的优先级通过在请求头部添加Priority字段来指定。该字段的值可以是urgency（紧急）或immediacy（即时），用于表示请求的相对优先级。例如，一个重要的资源请求可以设置为紧急优先级，而其他次要的请求可以设置为即时优先级。服务器可以根据请求的优先级来调度处理请求，优先处理具有更高优先级的请求，以确保重要请求的及时响应。
3、流控制机制
流控制机制，个人感觉可以理解为是根据实际网络情况动态调整数据包大小的能力
HTTP/1.1引入了流控制机制，以避免在网络拥塞或高负载情况下过载服务器或网络链路。在HTTP/1.1中，客户端和服务器之间的连接被视为一个流（stream），并且每个流都可以设置一个窗口大小（window size）。窗口大小表示在不接收确认之前，可以发送的字节数量。
客户端和服务器可以通过在请求或响应头部中添加Window-Size字段来设置窗口大小。这允许控制在网络传输中的数据流量，以避免过多数据发送导致拥塞。通过流控制，发送方（客户端或服务器）会根据接收方的窗口大小来调整发送数据的速率，以确保在网络链路上的平衡和稳定的数据传输。
4、管道发送请求
当使用HTTP/1.1协议时，可以使用管道（pipelining）机制在单个TCP连接上发送多个请求，而无需等待每个请求的响应。这意味着客户端可以在发送一个请求后立即发送下一个请求，而无需等待前一个请求的响应返回。
管道机制的优势在于减少了请求的延迟。在非管道化的HTTP/1.1中，每个请求都需要等待前一个请求的响应返回后才能发送下一个请求，这会导致较高的延迟。而通过使用管道机制，多个请求可以连续发送，服务器可以按照请求的顺序处理它们，并将响应按照相同的顺序返回。
但事实上，管道机制并没有被大量的使用。理由如下：
（1）请求的幂等性要求: 管道化请求要求每个请求都是幂等的，即多次执行相同的请求操作不会产生不同的结果。这是因为服务器可能无法保证多个非幂等请求的处理顺序。
（2）不受支持的服务器端: 并非所有的服务器都完全支持HTTP/1.1的管道机制。某些服务器可能会忽略或不正确处理管道化请求，因此客户端需要在与特定服务器进行通信时谨慎使用管道化功能
三、HTTP2（于2015年推出）
- 引入了二进制协议，将HTTP消息分割为帧并进行二进制传输，提高了解析效率。
- 支持多路复用，多个请求可以在同一个TCP连接上同时进行，避免了连接建立和拆除的开销。
- 引入了请求头压缩（HPACK算法），显著减少了头部信息的传输大小。
- 支持服务器主动推送（server push），服务器可以在客户端请求之前主动发送相关资源。
- 引入了流量控制和优先级，允许对请求进行更精确的控制。
- 支持头部字段的压缩、优先级和推送等特性，提供了更高的性能和效率。
总体而言，HTTP/2相对于HTTP/1.1在性能和效率方面有显著的改进。HTTP/2通过多路复用、请求头压缩和服务器推送等功能，提供更快的页面加载速度和更高的性能。它减少了网络延迟、提高了吞吐量，并优化了资源利用率。然而，具体的性能和支持程度可能因浏览器、服务器和网络环境而异。
网友评论