HTTP/2和HTTP/3

最新推荐文章于 2025-04-08 10:17:24 发布

梅兰肉肉的粉丝

最新推荐文章于 2025-04-08 10:17:24 发布

阅读量169

点赞数

CC 4.0 BY-SA版权

分类专栏：网络协议文章标签：服务器网络协议 http

本文链接：https://blog.csdn.net/m0_70432049/article/details/128775847

网络协议专栏收录该内容

16 篇文章

订阅专栏

本文介绍了HTTP/2和HTTP/3的主要特性，包括二进制格式、多路复用、头部压缩、服务器推送、连接迁移等。HTTP/2通过多路复用解决了HTTP/1.1的队头阻塞问题，HTTP/3则基于QUIC协议，旨在进一步降低握手延迟和提高连接迁移的效率，但面临CPU负载和操作系统内核支持的挑战。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

队头阻塞（head of line blocking）

本文参照小码哥的网络协议视频记录

HTTP协议的不足（HTTP/1.1）

上面说的HTTPS也属于HTTP/1.1。同一时间，一个连接只能对应一个请求。意思是建立的连接可以复用，但同一时间一个连接不可对应多个请求，需要排队。针对同一个域名，大多数浏览器允许同时最多6个并发连接。只允许客户端主动发起请求。

只能是请求应答模式，一个请求只能对应一个响应。而且请求只能由客户端主动发起。

同一个会话的多次请求中，头信息会被重复传输（如每次都要带上相同的cookie）。通常会给每个传输增加500~800字节的开销，如果使用Cookie，增加的开销有时会达到上千字节。

SPDY

SPDY（speedy的缩写），是基于TCP的应用层协议，它强制要求使用SSL/TLS。2009年11月，Google宣布将SPDY作为提高网络速度的内部项目。

SPDY与HTTP的关系：SPDY并不用于取代HTTP，它只是修改了HTTP请求与响应的传输方式。只需增加一个SPDY层，现有的所有服务端应用均不用做任何修改。SPDY是HTTP/2的前身。2015年9月，Google宣布移除对SPDY的支持，拥抱HTTP/2。

HTTP/2

HTTP/2，于2015年5月以RFC 7540正式发表。根据W3Techs的数据，截至2019年6月，全球有36.5%的网站支持了HTTP/2。

HTTP/2在底层传输做了很多的改进和优化，但在语意上完全与HTTP/1.1兼容。比如请求方法（如GET、POST）、Status Code、各种Headers等都没有改变。因此，要想升级到HTTP/2，开发者不需要修改任何代码，只需要升级服务器配置，升级浏览器。

特性

二进制格式

HTTP/2采用二进制格式传输数据，将头信息和请求体分成两段打散转成二进制帧，而非HTTP/1.1的文本格式。

二进制格式在协议的解析和优化扩展上带来更多的优势和可能。

一些基本概念

数据流：已建立的连接内的双向字节流，可以承载一条或多条消息，是一个逻辑概念。

同一时间，所有通信都在一个TCP连接上完成。此连接可以承载任意数量的双向数据流。

消息：与逻辑HTTP请求或响应消息对应，由一系列帧组成。

帧：HTTP/2通信的最小单位，每个帧都包含帧头（会标识出当前帧所属的数据流）。

来自不同数据流的帧可以交错发送，然后再根据每个帧头的数据流标识符重新组装。

多路复用（Multiplexing）

客户端和服务器可以将HTTP消息分解为互不依赖的帧，然后交错发送，最后再在另一端把它们重新组装起来。并行交错地发送多个请求，请求之间互不影响。并行交错地发送多个响应，响应之间互不干扰。使用一个连接并行发送多个请求和响应，不必再为绕开HTTP/1.1限制而做很多工作（尽量减少请求数量），比如image sprites、合并CSS\JS、内嵌CSS\JS\Base64图片、域名分片等。

补充：base64是把图片每个像素什么颜色等信息转成"data:image/..."这样的字符串格式，可以直接放入图片标签的src里。

image sprites（也叫做CSS Sprites），将多张小图合并成一张大图。最后通过CSS结合小图的位置、尺寸进行精准定位。最后通过CSS结合小图的位置，尺寸进行精准定位。

域名分片：由于一个域名只能同时建立6个连接，所以将一些资源分给多个域名。

优先级

HTTP/2 标准允许每个数据流都有一个关联的权重和依赖关系，可以决定谁先发送，谁晚发送。可以向每个数据流分配一个介于1至256之间的整数。每个数据流与其他数据流之间可以存在显式依赖关系。

客户端可以构建和传递“优先级树”，表明它倾向于如何接收响应。

服务器可以使用此信息通过控制CPU、内存和其他资源的分配设定数据流处理的优先级。在资源数据可用之后，确保将高优先级响应以最优方式传输至客户端。

应尽可能先给父数据流分配资源，同级数据流（共享相同父项）应按其权重比例分配资源。

① A、B依赖于隐式“根数据流”，A获得的资源比例是12/16，B获得的资源比例是4/16。

② D依赖于根数据流，C依赖于D，D应先于C获得完整资源分配。

③ D应先于C获得完整资源分配，C应先于A和B获得完整资源分配，B获得的资源是A所获资源的1/3。

④ D应先于E和C获得完整资源分配，E和C应先于A和B获得相同的资源分配，B获得的资源是A所获资源的1/3。

头部压缩

HTTP/2会跟踪以前发过的所有请求，如把近段时间的请求缓存下来。它发现有些头信息上一次请求已经发过了，这次就用一些方法压缩掉不会发了。HTTP/2使用HPACK压缩请求头和响应头，可以极大减少头部开销，进而提高性能。早期版本的HTTP/2和SPDY使用zlib压缩。可以将所传输头数据的大小减小85%~88%。但在2012年夏天，被攻击导致会话劫持，后被更安全的HPACK取代。

大概的图↓

细节↓

图中间这张表客户端和服务器都会保留一张，如客户端在发请求时，发现有些请求头在这张表中已经记录过了，就只发索引号过去。

服务器推送（Server Push）

服务器可以对一个客户端请求发送

队头阻塞（head of line blocking）

一旦前面的包丢失了，就会一直等重发，导致队头阻塞。

QUIC不会阻塞，因为底层用了UDP协议。

握手延迟

RTT(Round Trip Time)：往返时延，可以简单理解为通信一来一回的时间。

HTTP/3

Google觉得HTTP/2仍然不够快，于是就有了HTTP/3。

HTTP/3由Google开发，弃用TCP协议，改为使用基于UDP协议的QUIC协议实现。

QUIC(Quick UDP Internet Connections)，译为：快速UDP网络连接，由Google开发，在2013年实现。与2018年从HTTP-over-QUIC改为HTTP/3。

HTTP/3仍在试验的过程中，不像HTTP/2已经成为标准得到广泛使用。

疑问

HTTP/3基于UDP，如何保证可靠传输？

由QUIC来保证。在QUIC编码，决定丢包时的操作，相当于QUIC完成了一部分TCP层的功能。

目前世界上的网络设备基本只认TCP、UDP。如果要修改传输层，意味着操作系统的内核也要修改。另外，由IETF标准化的许多TCP新特性都因缺乏广泛支持而没有得到广泛的部署和使用。因此，要想开发并应用一个新的传输层协议，是极其困难的一件事情。

特性

连接迁移

TCP基于4要素（源IP、源端口、目标IP、目标端口）。

切换网络时至少会有一个要素发生变化，导致连接发生变化。当连接发生变化时，如果还使用原来的TCP连接，则会导致连接失败，就得等原来的连接超时后重新建立连接。所以我们有时候发现切换到一个新网络时，即使新网络状况良好，但内容还是需要加载很久。如果实现得好，当检测到网络变化时立刻建立新的TCP连接，即使这样，建立新的连接还是需要几百毫秒的时间。

QUIC的连接不受4要素的影响，当4要素发生变化时，原连接依然维持。QUIC连接不以4要素作为标识，而是使用一组Connection ID（连接ID）来标识一个连接。即使IP或者端口发生变化，只要Connection ID没有变化，那么连接依然可以维持。比如当设备连接到Wi-Fi时，将进行中的下载从蜂窝网络连接转移到更快速的Wi-Fi连接。当Wi-Fi连接不再可用时，将连接转移到蜂窝网络连接。