很多人第一次听到这句话时，都会有点懵：
HTTP/2 更强调在少量长期存在的连接上复用和并发多个流。
每个字好像都认识，但连起来就不太明白了。
尤其很多后端开发一开始都会有一个很强的旧印象：
HTTP 不就是请求一下、返回一下、然后就断开吗？
这篇不从术语出发，直接从生活类比讲清楚这句话到底是什么意思。
先说结论
你可以先把它粗暴记成一句话：
HTTP/1.x 更像一条窄路，很多车要排队。HTTP/2 更像一条长期保留的多车道高速公路，很多车可以同时跑。
这里面有三个关键词：
- 少量连接
- 长期存在
- 多个流并发
下面一个一个拆。
先把”连接”想成一条路
我们先不要想代码，也不要想浏览器。
你就想象你公司和仓库之间要一直运输货物。
这时候最重要的基础设施是什么？
路。
在网络世界里，这条”路”你可以先理解成一条连接。
所以：
- 连接 = 路
- 请求 = 一次运输任务
- 响应 = 货送回来
早期那种”HTTP 很像短连接”的感觉，从哪来的
你以前会觉得 HTTP 是短连接，是因为它很像这种低效模式：
每送一次货，就临时修一条路
比如今天要送 10 批货。
最蠢的做法是：
- 修一条路
- 送第 1 批货
- 路拆掉
- 再修一条路
- 送第 2 批货
- 再拆掉
这样做的问题非常明显：
- 修路成本高
- 每次准备工作都很重
- 真正送货的时间反而占比不高
这就是很多人脑子里”HTTP 很短”的来源：
- 请求来了就连一下
- 处理完就断
- 下次再重新连
这个印象不是完全错，只是已经不适合拿来理解现代 HTTP 了。
后来优化了一点：路别老拆
后来大家发现，老这么修路太浪费，于是变成：
路修好后，尽量反复使用
比如：
- 修好一条路
- 第 1 批货走这条路
- 第 2 批货也走这条路
- 第 3 批货还走这条路
这就比”每次都重修”强很多。
这相当于：
连接建立后，不要立刻关掉，而是尽量复用。
到这里，其实已经不是传统意义上的”短连接”了。
但问题还没彻底解决：车还是容易堵
即便这条路可以反复用，如果它太窄，还是会有问题。
比如：
- 订单数据要传
- 图片要传
- 聊天消息要传
- 文件也要传
如果这条路一次基本只能让一辆车顺畅通过，那么就会变成：
- 第一辆车先走
- 第二辆车排队
- 第三辆车继续等
- 第四辆车还得等
这时候虽然”路”不用反复修了，但任务之间还是会互相阻塞。
这就是老式通信里一个典型问题：
连接能复用，但并发能力不够好。
HTTP/2 的思路：不是修更多路，而是修一条更强的高速公路
HTTP/2 的核心思路，不是说：
“你有 100 个请求，那就建 100 条连接。”
它更像是：
我不修很多条小破路，我就保留少量几条高质量的大路，而且这些路长期都在。
比如你公司和仓库之间，不再是：
- 送一次货修一次路
- 或者只有一条又窄又堵的小道
而是直接修一条大型高速公路。
这条高速公路平时就一直存在，后面各种运输任务都走它。
这就对应那句话里的前半句：
少量长期存在的连接
什么意思？
就是：
- 不靠”大量新建连接”解决问题
- 而是保留”少数几条稳定连接”
- 这些连接长时间复用，不轻易断
说白了就是：
路不用每次重修，长期放在那儿用。
那”并发多个流”又是什么意思
这个是最关键的点。
如果高速公路只有 1 条车道，那再好的路也还是容易堵。
HTTP/2 真正强的地方在于：
同一条连接里，不是只能串行地处理一个任务，而是可以同时跑多个独立任务。
还是拿高速公路来讲。
一条大路，但有很多车道
比如这条高速公路上有 8 条车道。
现在同时有 4 个任务：
- A 车送订单信息
- B 车送用户头像
- C 车送聊天消息
- D 车送商品详情
它们不用这样排：
- A 先过完
- B 再过
- C 再过
- D 最后过
而是可以这样：
- A 在 1 号车道跑
- B 在 2 号车道跑
- C 在 3 号车道跑
- D 在 4 号车道跑
它们都在同一条高速公路上，但彼此是相对独立的。
这就是：
在一条连接上并发多个流
这里的”流”，你暂时可以把它理解成：
同一条大连接里的独立任务通道。
再换一个更生活化的比喻：电梯
如果你觉得高速公路还是有点抽象，那再换成电梯。
老式低效模式：每个人都单独造一台电梯
10 个人上楼。
最蠢的办法是：
- 张三上楼，造一台电梯
- 张三到了，电梯销毁
- 李四再上楼，再造一台
- 王五再来，再造一台
这就是典型的”每次都重新建连接”。
显然很浪费。
稍微好一点：一台电梯反复用，但一次只送一个人
这比前面强一些：
- 先送张三
- 电梯回来
- 再送李四
- 再回来
- 再送王五
问题是：
虽然电梯复用了，但大家还是排队。
这就像”连接可复用，但请求之间还是容易互相阻塞”。
HTTP/2 更像什么
HTTP/2 更像是一台大型智能电梯。
它不是每次只服务一个人，而是：
- 张三去 8 楼
- 李四去 12 楼
- 王五去 15 楼
- 赵六去 18 楼
这几个人可以在同一趟运输过程中一起被安排。
这就对应：
- 一条连接里
- 同时存在多个任务
- 各自有自己的通道和节奏
所以”多个流”你也可以简单理解成：
同一台大电梯里的多个乘客任务。
为什么 HTTP/2 不强调”建很多连接”
很多人会本能地想：
“既然有很多请求，那多建几条连接不就行了吗？”
理论上可以，但这通常不是最优解。
因为每建一条连接，都有成本：
- 建立连接有开销
- 维护连接有开销
- 连接多了，管理成本也上来
- 反复创建和销毁，本身也浪费资源
所以现代协议更喜欢的是：
连接数量尽量少，但单条连接的利用率尽量高。
这就是”少量长期存在连接”的工程价值。
这和 gRPC 有什么关系
如果你后面接触 gRPC，就会更常看到这种设计。
因为 gRPC 很多场景不是偶尔请求一次，而是：
- 高频调用
- 持续通信
- 低延迟要求
- 还可能有流式交互
这时候最合适的模型，就是：
- 先把连接建立好
- 长时间复用这条连接
- 在这条连接里跑很多调用
所以 gRPC 跑在 HTTP/2 上，是很自然的选择。
因为 HTTP/2 天然适合：
- 长期复用连接
- 同一连接并发多个任务
- 减少排队和重复建链路的成本
再回到最初那句话
现在你再看这句话：
HTTP/2 更强调在少量长期存在的连接上复用和并发多个流。
就可以翻译成普通人能听懂的话：
不要每个请求都重新建一条连接，而是保留少数几条长期可用的大连接，让很多请求像不同车道上的车一样同时跑。
这才是它真正的意思。
最后用一句话记住
如果你只想记一句最短的话，那就记这个：
HTTP/1.x 更像单车道小路，车容易排队；HTTP/2 更像长期存在的多车道高速公路，很多任务可以同时通过。
理解到这里，“长连接""多路复用""多个流并发”这几个词，基本就不会再绕了。
评论 / 0
共 0 条你可能是第一个留下评论的人