当前位置：首页 > news >正文

计网：http/1.1、http/2和http/3的改变和优化

news 来源：原创 2024/9/20 12:17:46

1、http/1.1相较于http/1的改变

http/1之前使用的是短链接，每一次请求结束都会结束TCP连接，后面再次请求时要重新建立TCP连接，这样没有必要的连接状态的转变导致了通信消耗。
所以http/1.1从原本的短连接改为了长连接，由请求头中的Connection字段来指定连接类型，当它的值为Keep-Alive时就为长连接。开启了 HTTP Keep-Alive 机制后，连接就不会中断，而是保持连接。当客户端发送另一个请求时，它会使用同一个连接，一直持续到客户端或服务器端提出断开连接。当然如果某个 HTTP 长连接超过一定时间没有任何数据交互，服务端就会主动断开这个连接。

之前http/1请求响应模型是要等前一个请求响应回来接收后客户端才能发起下一个请求，这样子会有等待的时间。
http/1.1则是实现了管道化传输，也就是客户端对服务器中A资源发起请求，无需等待A资源的响应回来，直接可以通过此连接直接对B请求发起请求。这样子可以减少整体的请求响应时间，但是客户端对于响应的处理顺序必须和请求发起的顺序一致，也就是必须先处理A请求的响应，才能处理B请求的响应。这样可能就会产生响应头阻塞问题。

很多时候http的请求头中的字段是重复的，那么每次发起请求都将这些重复的部分发送一次，有些消耗资源，拉低效率。
所以在http/2协议中HTTP/2 使用 HPACK 算法来压缩头部信息，这减少了头部的大小。HPACK算法就是客户端和服务端共同维护一张表，将请求头中所有字段存入这个表，并生成一个索引号，这样就不用每次都发相同的字段了，直接发送索引号。这样就减少资源的浪费，提高了传输处理速度了。

HPACK 动态表格是一个有序的列表，其中存储了之前出现过的头部字段。每个条目由一个键值对组成，即头部名称和对应的头部值。HPACK 动态表格具有以下特性：

在http/1.1之前使用的是纯文本形式的报文，在传输过程中要将其转化为二进制才能交由计算机处理，且使用纯文本的形式所需要的报文大小更大。如状态码200，在http/1.1中要使用三个字符表示，再转化为二进制后为00110010 00110000 00110000，使用了三个字节。
所以再http/2中直接使用二进制格式，这样可以减少请求响应头大小，如200，如果直接用二进制表示可以直接为10001000，只用了一个字节。这样也减少了当服务端接收到请求后将其转为二进制的过程。这样使得解析更加高效且错误更少。

在 http/1.1 中，每个请求都需要一个单独的 TCP 连接，或者在一个连接上排队等待前一个请求完成。这意味着即使存在空闲的带宽，由于连接的限制，多个请求也不能同时传输。这种限制导致了网络利用率低下和延迟较高。也就是响应头阻塞问题。
http/2为了解决这个响应头阻塞的问题提出了Stream的概念，当建立好连接之后，客户端和服务端都可以建立一个流，每个流都会由自己唯一的ID，然后再传输信息时，可能会将请求数据分割成帧，分割后的每个帧都带有自己所属的流ID，到达接收方后根据流ID进行请求或响应的组装。所以属于不同请求的帧可以再一个连接中交错传输，就不会存在响应头阻塞的问题了。这样可以对请求和响应进行并发处理，提高了响应速度。Stream ID 也是有区别的，客户端建立的 Stream 必须是奇数号，而服务器建立的 Stream 必须是偶数号。

在http/1.1中还是必须请求响应模型，必须是客户端发起请求，服务端才能给客户端推送资源。当有些资源一直都是相关联的，请求了一个资源，另一个资源肯定会被用到，此时客户端要发起两次请求就有点重复。
再上述情况时再http/2中就有了服务端主动推送，例如当客户端请求HTML后，服务端不用等其再次请求CSS，会直接将CSS文件推送到客户端用于渲染页面。

http/2 是基于 TCP 协议来传输数据的，TCP 是字节流协议，TCP 层必须保证收到的字节数据是完整且连续的，这样内核才会将缓冲区里的数据返回给 HTTP 应用。一旦发生了丢包现象，就会触发 TCP 的重传机制，这样在一个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来，这就是 http/2 队头阻塞问题。
所以http/3将TCP改为UDP协议。UDP发送不管顺序，也不管丢包，他是面向无连接的，所以不会出现http/2中队头阻塞的问题。虽然UPD不是可靠传世，所以是基于QUIC实现UDP可靠传输。所以主要介绍QUIC协议特点。

HTTP/3 中的每个流（Stream）都是独立管理的，这意味着一个流的数据丢失不会影响其他流。当某个流的数据丢失时，只有该流受到影响，其他流的数据可以继续传输，从而避免了队头阻塞。

在 HTTP/1 和 HTTP/2 中，TCP 和 TLS 是分层实现的，分别由内核和 OpenSSL 库处理。这导致了分阶段的握手过程：首先进行 TCP 三次握手以建立连接，然后进行 TLS 握手以协商加密密钥。由于这两个握手过程是分开的，因此至少需要两个往返时间（RTTs）才能完成整个连接建立过程。
HTTP/3 通过 QUIC 协议改进了握手过程。QUIC 在 UDP 之上实现了类似 TCP 的功能，并且内部包含了 TLS。QUIC 的握手过程只需要一个往返时间（RTT），这是因为 QUIC 握手帧中包含了 TLS 记录，这意味着 TLS 密钥交换和加密都在同一个握手过程中完成。由于 QUIC 使用了 TLS 1.3，它可以在一个 RTT 内同时完成连接建立和密钥协商，显著减少了建立连接所需的时间。握手的目的是为确认双方的「连接 ID」，连接迁移就是基于连接 ID 实现的。
当重新建立连接时，甚至可以实现0-RTT建立连接：当客户端尝试重新建立与同一服务器的连接时，如果客户端保存了上次连接的信息（如加密密钥等），则可以在不需要完整握手的情况下立即发送数据。客户端可以通过使用之前握手过程中获取的加密材料来加密数据，并将其发送给服务器。服务器收到这些数据后，可以解密并处理它们，同时继续完成握手过程以更新加密密钥

TCP 传输协议的 HTTP 协议中需要四元组：源IP，源端口，目的IP，目的端口。当本机网络情况发生改变，也就是源IP发生改变，此时就需要进行再次连接。
而http/3使用的是UDP，并不是面向连接的。而QUIC使用的是连接ID这么个概念维护标记两个端点的，所以当网络环境发生改变时，可以复用原有的连接，实现快速迁移。