HTTP/3展望、我应该迁移到HTTP/2吗

1. HTTP/3展望

  1. HTTP/3 基于 QUIC 协议,完全解决了“队头阻塞”问题,弱网环境下的表现会优于 HTTP/2;
  2. QUIC 是一个新的传输层协议,建立在 UDP 之上,实现了可靠传输;
  3. QUIC 内含了 TLS1.3,只能加密通信,支持 0-RTT 快速建连;
  4. QUIC 的连接使用“不透明”的连接 ID,不绑定在“IP 地址 + 端口”上,支持“连接迁移”;
  5. QUIC 的流与 HTTP/2 的流很相似,但分为双向流和单向流
  6. HTTP/3 没有指定默认端口号,需要用 HTTP/2 的扩展帧“Alt-Svc”来发现。

1.1. HTTP/2 的“队头阻塞”

HTTP/2 虽然使用“帧”“流”“多路复用”,没有了“队头阻塞”,但这些手段都是在应用层里,而在下层,也就是 TCP 协议里,还是会发生“队头阻塞”。

在 HTTP/2 把多个“请求 - 响应”分解成流,交给 TCP 后,TCP 会再拆成更小的包依次发送(其实在 TCP 里应该叫 segment,也就是“段”)。

在网络良好的情况下,包可以很快送达目的地。但如果网络质量比较差,像手机上网的时候,就有可能会丢包。而 TCP 为了保证可靠传输,有个特别的“丢包重传”机制,丢失的包必须要等待重新传输确认,其他的包即使已经收到了,也只能放在缓冲区里,上层的应用拿不出来,只能“干着急”。

举例:

客户端用 TCP 发送了三个包,但服务器所在的操作系统只收到了后两个包,第一个包丢了。那么内核里的 TCP 协议栈就只能把已经收到的包暂存起来,“停下”等着客户端重传那个丢失的包,这样就又出现了“队头阻塞”。

“HTTP over QUIC”就是 HTTP 协议的下一个大版本,HTTP/3。它在 HTTP/2 的基础上又实现了质的飞跃,真正“完美”地解决了“队头阻塞”问题。

1.2. QUIC 协议

QUIC 最早是由 Google 发明的,被称为 gQUIC。而当前正在由 IETF 标准化的 QUIC 被称为 iQUIC。两者的差异非常大。

gQUIC 混合了 UDP、TLS、HTTP,是一个应用层的协议。而 IETF 则对 gQUIC 做了“清理”,把应用部分分离出来,形成了 HTTP/3,原来的 UDP 部分“下放”到了传输层,所以 iQUIC 有时候也叫“QUIC-transport”。

以下说的 QUIC 都是指 iQUIC,它与早期的 gQUIC 不同,是一个传输层的协议,和 TCP 是平级的。

QUIC 的特点

1. 基于UDP的高效传输

QUIC使用UDP作为底层协议,避免了TCP协议因中间设备(如防火墙、路由器)的僵化导致的部署难题,同时绕开了TCP的队头阻塞问题

2. 多路复用与消除队头阻塞(HOL Blocking)

独立逻辑流:QUIC支持在单个连接上并行传输多个独立的逻辑数据流(Stream),每个流的数据包可乱序传输且互不影响。即使某个流的数据包丢失,其他流仍可正常处理,彻底解决了TCP层和应用层的队头阻塞问题。

与HTTP/2的对比:HTTP/2虽支持多路复用,但仍依赖TCP,一旦发生丢包,所有流需等待重传;而QUIC通过UDP和流隔离机制,仅影响丢失的流。

3. 快速握手与低延迟

4. 内置安全性与加密

5. 连接迁移与网络适应性

QUIC连接通过64位Connection ID标识,而非TCP的四元组(源IP、端口等)。即使设备切换网络(如WiFi转4G),连接仍可保持不断,适合移动场景。

6. 可靠性与流控机制

QUIC 内部细节

QUIC 的基本数据传输单位是(packet)和(frame),一个包由多个帧组成,包面向的是“连接”,帧面向的是“流”。

QUIC 使用不透明的“连接 ID”来标记通信的两个端点,客户端和服务器可以自行选择一组 ID 来标记自己,这样就解除了 TCP 里连接对“IP 地址 + 端口”(即常说的四元组)的强绑定,支持“连接迁移”(Connection Migration)。

QUIC 的帧里有多种类型,PING、ACK 等帧用于管理连接,而 STREAM 帧专门用来实现流。

QUIC 里的流与 HTTP/2 的流非常相似,也是帧的序列,你可以对比着来理解。但 HTTP/2 里的流都是双向的,而 QUIC 则分为双向流和单向流

流 ID 还保留了最低两位用作标志,第 1 位标记流的发起者,0 表示客户端,1 表示服务器;第 2 位标记流的方向,0 表示双向流,1 表示单向流。

所以 QUIC 流 ID 的奇偶性质和 HTTP/2 刚好相反,客户端的 ID 是偶数,从 0 开始计数。

1.3. HTTP/3 协议

HTTP/3 把流控制都交给 QUIC 去做。调用的不再是 TLS 的安全接口,也不是 Socket API,而是专门的 QUIC 函数。

HTTP/3 里仍然使用流来发送“请求 - 响应”,但它自身不需要像 HTTP/2 那样再去定义流,而是直接使用 QUIC 的流,相当于做了一个“概念映射”。

由于流管理被“下放”到了 QUIC,所以 HTTP/3 里帧的结构也变简单了。帧头只有两个字段:类型和长度,而且同样都采用变长编码,最小只需要两个字节。

HTTP/3 里的帧仍然分成数据帧和控制帧两类,HEADERS 帧和 DATA 帧传输数据,但其他一些帧因为在下层的 QUIC 里有了替代,所以在 HTTP/3 里就都消失了,比如 RST_STREAM、WINDOW_UPDATE、PING 等。

头部压缩算法在 HTTP/3 里升级成了“QPACK”,使用方式上也做了改变。虽然也分成静态表和动态表,但在流上发送 HEADERS 帧时不能更新字段,只能引用,索引表的更新需要在专门的单向流上发送指令来管理,解决了 HPACK 的“队头阻塞”问题。

HTTP/3的服务发现:

HTTP/3 没有指定默认的端口号,也就是说不一定非要在 UDP 的 80 或者 443 上提供 HTTP/3 服务。

  1. 浏览器需要先用 HTTP/2 协议连接服务器,然后服务器可以在启动 HTTP/2 连接后发送一个“Alt-Svc”帧,包含一个“h3=host:port”的字符串,告诉浏览器在另一个端点上提供等价的 HTTP/3 服务。
  2. 浏览器收到“Alt-Svc”帧,会使用 QUIC 异步连接指定的端口,如果连接成功,就会断开 HTTP/2 连接,改用新的 HTTP/3 收发数据。

2. 应该迁移到HTTP/2吗?

  1. HTTP/2 完全兼容 HTTP/1,是“更安全的 HTTP、更快的 HTTPS”,头部压缩、多路复用等技术可以充分利用带宽,降低延迟,从而大幅度提高上网体验;
  2. TCP 协议存在“队头阻塞”,所以 HTTP/2 在弱网或者移动网络下的性能表现会不如 HTTP/1;
  3. 迁移到 HTTP/2 肯定会有性能提升,但高流量网站效果会更显著;
  4. 如果已经升级到了 HTTPS,那么再升级到 HTTP/2 会很简单;
  5. TLS 协议提供“ALPN”扩展,让客户端和服务器协商使用的应用层协议,“发现”HTTP/2 服务。

2.1. HTTP/2的主要优点

1. 多路复用(Multiplexing)

  • 核心改进:在单个TCP连接上并行传输多个请求/响应,彻底解决HTTP/1.x的“队头阻塞”问题(应用层)。
  • 效果:减少延迟、提升连接利用率,避免浏览器为并发请求建立多个TCP连接(如HTTP/1.1的6~8个连接限制)。

2. 头部压缩(HPACK)

  • 技术:使用HPACK算法压缩HTTP头部,消除冗余字段(如重复的Cookie、User-Agent)。
  • 效果:减少数据传输量,提升弱网环境下的性能(尤其对移动端和小型请求显著)。

3. 服务器推送(Server Push)

  • 功能:服务器可主动向客户端推送资源(如CSS/JS文件),无需等待客户端解析HTML后发起请求。
  • 场景:优化首次页面加载速度,减少往返次数(RTT)。

4. 二进制协议

  • 格式:将HTTP/1.x的文本格式改为二进制分帧(Frame),解析更高效,避免文本歧义(如空格、大小写)。
  • 效果:降低解析复杂度,提升传输可靠性。

5. 流优先级与依赖控制

  • 机制:允许客户端为请求设置优先级(如优先加载HTML/CSS,延迟加载图片)。
  • 效果:优化关键资源的加载顺序,提升用户体验。

2.2. HTTP/2的主要缺点

1. TCP层队头阻塞未解决

  • 问题:HTTP/2依赖TCP协议,若传输层发生丢包,所有流需等待丢失包重传,导致性能下降。
  • 影响:在高丢包率网络(如移动网络)中,HTTP/2可能比HTTP/1.1更慢(后者可多连接规避)。

2. 服务器推送的局限性

  • 实现复杂:需服务器准确预测客户端所需资源,推送错误内容会浪费带宽。
  • 缓存问题:客户端可能已缓存推送资源,导致冗余传输。
  • 实际采用率低:多数网站未广泛使用此功能,部分浏览器已弃用(如Chrome 106+)。

3. 强制依赖HTTPS

  • 现状:主流浏览器(如Chrome、Firefox)仅支持加密的HTTP/2(基于TLS)。
  • 代价:需维护证书和TLS配置,对简单内网服务可能增加复杂度。

4. 协议复杂性提升

  • 实现难度:二进制分帧、流控制、优先级等机制增加了协议栈复杂度,可能引入新类型Bug(如流状态管理错误)。
  • 调试困难:二进制协议需要专用工具(如Wireshark)分析流量,调试门槛高于HTTP/1.x的文本协议。

5. 中间设备兼容性问题

  • 代理与防火墙:部分老旧中间设备(如传统代理服务器)不完全支持HTTP/2,可能导致连接降级或失败。

2.3. 适用场景与替代方案

场景

推荐协议

原因

高延迟、低丢包网络

HTTP/2

多路复用显著减少RTT,头部压缩节省带宽。

高丢包率网络(如4G/5G)

HTTP/3

QUIC解决TCP队头阻塞,适应弱网环境。

简单低频请求

HTTP/1.1

协议简单,兼容性更好,无额外性能负担。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/pingmian/80400.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

【大模型面试每日一题】Day 15:流水线并行的Bubble问题及其缓解方法

【大模型面试每日一题】Day 15:流水线并行的Bubble问题及其缓解方法 📌 题目重现 🌟🌟 面试官:解释流水线并行(Pipeline Parallelism)的bubble问题及其缓解方法。 #mermaid-svg-Uz7WGsO8akW5F…

Windows环境下maven的安装与配置

1.检查JAVA_HOME环境变量 Maven是使用java开发的,所以必须知道当前系统环境中的JDK的安装目录。 搜索栏直接输入“cmd” 或者 WinR 输入cmd 在打开的终端窗口输入“echo %JAVA_HOME”,就可以看到jdk的位置了。 如果没有的话,请参考我的文章&a…

Kubernetes 集群部署应用

部署 Nginx 应用 命令行的方式 1. 创建 deployment 控制器的 pod # --imagenginx:这个会从 docker.io 中拉取,这个网站拉不下来 # kubectl create deployment mynginx --imagenginx# 使用国内镜像源拉取 kubectl create deployment mynginx --imaged…

如何使用依赖注入来实现依赖倒置原则?

依赖注入(Dependency Injection, DI)是实现依赖倒置原则(DIP)的具体技术手段,它通过将依赖对象的创建和管理交给外部容器,从而实现高层模块与低层模块的解耦。下面从原理、实现方式、框架应用及最佳实践四个方面详细解析: 一、依赖倒置原则(DIP)的核心思想 高层模块不…

python使用AES进行加密和解密

如果需要加密和解密功能,可以使用AES算法。以下是使用Python实现AES加密和解密的示例: from Crypto.Cipher import AES from Crypto.Util.Padding import pad, unpad from Crypto.Random import get_random_bytesdef aes_encrypt(data,

SaaS场快订首页的前端搭建【持续更新】

文章目录 一、创建页面二、配置路由三、写接口文件(api)1.定位的接口函数(腾讯地图api)实现代码: 2.获取场馆分类的数据3.获取附近场馆列表的数据 四、开发首页页面1.顶部区域2.搜索框3.场馆分类4.附近场馆列表 五、难…

深入解析 MQTT 协议:物联网通信的基石

在当今物联网蓬勃发展的时代,设备之间高效、可靠的通信变得至关重要。MQTT(Message Queuing Telemetry Transport)协议,作为一种轻量级的消息传输协议,正逐渐成为物联网通信的基石,广泛应用于各种场景中。 …

在Python中计算函数耗时并超时自动退出

更多内容请见: python3案例和总结-专栏介绍和目录 文章目录 方法1:使用装饰器结合信号模块(仅Unix-like系统)方法2:使用多线程(跨平台解决方案)方法3:使用concurrent.futures(Python 3.2+)方法4:使用 multiprocessing + Process(跨平台)​方法5:使用 time 手动计…

理解c++中explicit关键字的作用

理解c中explicit关键字的作用 explicit 关键字的作用是防止构造函数被隐式调用&#xff0c;从而避免意外的类型转换 #include <iostream> class Vec3 { public://构造函数没有被explicit修饰Vec3(float value): x(value), y(value), z(value){}Vec3(float val1, float …

不止是UI库:React如何重塑前端开发范式?

React&#xff1a;引领现代前端开发的声明式UI库 在当今快速发展的前端世界&#xff0c;React以其声明式、组件化和高效的特性&#xff0c;稳坐头把交椅&#xff0c;成为构建交互式用户界面的首选JavaScript库。本文将带你快速了解React的核心魅力、主要优势以及生态发展&…

理解 Token 索引 vs 字符位置

以下是对“理解 Token 索引与字符位置的区别”的内容整理&#xff0c;条理清晰&#xff0c;结构完整&#xff0c;保持技术细节&#xff0c;方便阅读&#xff0c;无多余解释&#xff1a; &#x1f50d; 理解 Token 索引 vs 字符位置 文本分块方法中返回的索引是 token 索引&…

《异常链机制详解:如何优雅地传递Java中的错误信息?》

大家好呀&#xff01;&#x1f44b; 作为一名Java开发者&#xff0c;相信你一定见过各种奇奇怪怪的异常报错。但有没有遇到过这样的情况&#xff1a;明明只调用了一个方法&#xff0c;却看到异常信息像俄罗斯套娃一样一层层展开&#xff1f;&#x1f914; 这就是我们今天要讲的…

vector 常见用法及模拟

文章目录 1. vector的介绍与使用1.1 vector的构造1.2 vector iterator 的使用1.3 有关大小和容量的操作1.4 vector 增删查改1.5 vector 迭代器失效问题&#xff08;重点&#xff09;1.6 vector 中二维数组的使用 2. vector 的模拟实现2.1 拷贝构造和赋值重载的现代写法2.2 memc…

数据结构与算法分析实验11 实现顺序查找表

实现顺序查找表 1.上机名称2.上机要求3.上机环境4.程序清单(写明运行结果及结果分析)4.1 程序清单4.1.1 头文件4.1.2 实现文件4.1.3 源文件 4.2 实现展效果示 上机体会 1.上机名称 实现顺序查找表 顺序查找表的基本概念 顺序查找表是一种线性数据结构&#xff0c;通常用于存储…

实践官方的 A2A SDK Python

内容列表 • 注意• 我的环境• A2A SDK Python 注意 这只是一个原型&#xff0c;并且在快速的变化&#xff0c;本篇教程也随时可能过期&#xff0c;可以在A2AProtocol blog最终更新的文章。 我的环境 • Python 3.13• uv: uv 0.7.2 (Homebrew 2025-04-30)• Warp• Olla…

langchain 接入国内搜索api——百度AI搜索

为什么使用百度AI搜索 学习langchain的过程中&#xff0c;遇到使用search api的时候&#xff0c;发现langchain官方文档中支持的搜索工具大多是国外的&#xff0c;例如google search或bing search&#xff0c;收费不说&#xff0c;很多还连接不上&#xff08;工具 | LangChain…

[强化学习的数学原理—赵世钰老师]学习笔记01-基本概念

[强化学习的数学原理—赵世钰老师]学习笔记01-基本概念 1.1 网格世界的例子1.2 状态和动作1.3 状态转移1.4 策略1.5 奖励1.6 轨迹、回报、回合1.6.1 轨迹和回报1.6.2 回合 1.7 马尔可夫决策过程 本人为强化学习小白&#xff0c;为了在后续科研的过程中能够较好的结合强化学习来…

Java开发经验——阿里巴巴编码规范经验总结2

摘要 这篇文章是关于Java开发中阿里巴巴编码规范的经验总结。它强调了避免使用Apache BeanUtils进行属性复制&#xff0c;因为它效率低下且类型转换不安全。推荐使用Spring BeanUtils、Hutool BeanUtil、MapStruct或手动赋值等替代方案。文章还指出不应在视图模板中加入复杂逻…

Java大师成长计划之第18天:Java Memory Model与Volatile关键字

&#x1f4e2; 友情提示&#xff1a; 本文由银河易创AI&#xff08;https://ai.eaigx.com&#xff09;平台gpt-4o-mini模型辅助创作完成&#xff0c;旨在提供灵感参考与技术分享&#xff0c;文中关键数据、代码与结论建议通过官方渠道验证。 在Java多线程编程中&#xff0c;线程…

js前端分片传输大文件+mongoose后端解析

最近一直在完善mongoose做webserver的项目&#xff0c;其中程序升级要通过前端传输升级包到服务器。 因为第一次写前端代码&#xff0c;分片传输的逻辑&#xff0c;网上一堆&#xff0c;大同小异&#xff0c;而且版本啊&#xff0c;API不一致的问题&#xff0c;导致头疼的很。后…