20 年前打开一个带图片的网页，可能要等 10 秒以上，而现在哪怕是刷高清视频都丝滑流畅 —— 这背后，HTTP 协议的进化功不可没。
HTTP 就像互联网的 “快递系统”，负责把网页、图片、视频等数据从服务器 “送到” 你的电脑 / 手机。从 1991 年诞生到现在，它经历了 5 次重大升级，每一次都让 “快递” 更快、更高效。今天就用大白话讲透 HTTP 各版本的核心变化，看完你会明白：为什么现在上网这么快？
一、HTTP 0.9（1991）：只能寄 “明信片” 的原始时代
核心特点：只能传文字，连图片都送不了
HTTP 最早的版本非常简单，主要用于在网络之间传递 HTML 超文本的内容，当时主要用于学术交流。
- 只能发
GET请求（相当于 “我要拿东西”）； - 服务器只能返回 HTML 文本（纯文字网页），连图片、CSS、JS 都无法传输；
- 没有请求头 / 响应头（相当于快递单上没有地址、电话，只能默认送到一个地方）。
举个例子：当时打开一个网页，只能看到黑底白字的文字，想加张图片？不可能 —— 因为 HTTP 0.9 根本不支持图片传输。
问题：功能太单一，完全满足不了 “带图片的网页” 需求。
二、HTTP 1.0（1996）：终于能寄 “包裹” 了，但效率极低
HTTP/1.0 是 HTTP 协议的第一个正式版本
核心升级：支持多种数据类型，引入请求头 / 响应头
- 新增
POST、HEAD等请求方法：（不仅能 “拿东西”，还能 “寄东西”） 丰富了客户端与服务器之间的交互方式。 - 包含请求头和响应头：为了支持多种类型文件的下载，让客户端和服务器能更深入地交流，HTTP/1.0 引入了请求头和响应头，它们以 Key - Value 形式保存。例如，请求头中可以包含浏览器类型、语言、接受的内容类型等信息，服务器返回的响应头中可以包含数据类型、压缩方法等信息。
- 状态码机制：引入了状态码，通过响应行的方式来通知浏览器服务器最终处理该请求的情况，如 200 表示请求成功，404 表示资源未找到等。
状态码小知识：
2xx（成功）：200（成功）、201（创建资源成功，比如提交表单后新建了用户）；4xx（客户端错）：400（请求格式错）、403（服务器拒绝访问，比如没权限）；5xx（服务器错）：500（服务器崩溃）、503（服务器忙，稍后再试）。
但问题来了：每次发快递都要 “重新约快递员”—— 每次请求都要重新建立 TCP 连接，用完就断开。比如打开一个带 3 张图的网页，要建立 4 次连接（1 次网页 + 3 次图片），每次连接都要 “打招呼”（三次握手），非常耗时。
举个例子：1998 年打开一个带 5 张图的网页，浏览器要和服务器建立 6 次连接，光握手就要花 2-3 秒，加上传输数据，整个页面加载可能要 10 秒以上。
三、HTTP 1.1（1999）：长连接 + 更多 “沟通细节”，上网快了一倍
核心升级：长连接、管道化，状态码体系完善
这是 HTTP 史上最重要的升级，解决了 “重复连接” 的痛点：
-
长连接（
Connection: keep-alive） ：一次 TCP 连接可以处理多个请求（比如网页、图片、CSS 用同一个连接），不用反复握手，节省时间； -
管道化：浏览器可以同时发多个请求（比如同时要图片 1 和图片 2），不用等前一个响应完再发下一个；
-
状态码扩容：新增了更具体的状态码，比如：
304 Not Modified：缓存生效，你要的资源没变化，直接用本地缓存吧；409 Conflict：请求冲突（比如两个人同时改同一个文件）；413 Payload Too Large：你发的数据太大了，服务器收不下。
举个例子：打开带 5 张图的网页，HTTP 1.1 只需 1 次连接，加上管道化，加载时间从 10 秒缩到 3 秒。
但新问题：管道化有 “队头阻塞”—— 服务器必须按请求顺序响应。比如先请求的大图片还没传完，后面的小图片就算准备好了，也得等着，像 “堵车时救护车也过不去”。
四、HTTP 2.0（2015）：“快递拆成小包裹”，状态码更智能
核心升级：多路复用、二进制帧，状态码适配新传输方式
HTTP 2.0 像 “智能快递系统”，把数据拆成带编号的 “帧”（小包裹），彻底解决队头阻塞：
- 多路复用：一个连接里，多个请求的帧可以交错传输，服务器按编号重组。大图片和小图片的帧能混着传，小图片先到先显示；
- 头部压缩：重复的请求头（比如
Cookie）会被压缩，减少传输量； - 服务器推送：服务器知道你要首页后，主动把依赖的 CSS、JS 推过来，不用等你再请求；
- 状态码兼容：沿用 1.1 的状态码，但通过 “帧” 里的 “流 ID”，能精准定位哪个请求出了问题（比如第 3 个请求返回
404，不影响其他请求）。
举个例子：刷朋友圈时，HTTP 2.0 能让文字先显示，图片随后慢慢加载，不会因为一张大图没加载完就卡住整个页面。
五、HTTP 3.0（2022）：换 “更快的车”，状态码应对网络波动
核心升级：基于 QUIC 协议（UDP），状态码更适应不稳定网络
HTTP 1.1 和 2.0 都基于 TCP 传输，但 TCP 有个毛病：只要丢了一个帧，就必须停下来重传，导致所有请求卡住（像 “货车队里一辆车坏了，全队都得等”）。
HTTP 3.0 改用QUIC 协议（基于 UDP），更灵活：
- 丢包不阻塞：丢了一个帧，只重传这一个，其他帧继续传输；
- 连接建立快：TCP 要三次握手，QUIC 一次搞定；
- 状态码适配：新增
451 Unavailable For Legal Reasons（因法律原因无法访问，比如网页被下架），并优化了网络波动时的状态反馈（比如504 Gateway Timeout会更精准地提示 “是 QUIC 连接超时”）。
举个例子：在地铁里刷视频，HTTP 3.0 能让视频卡顿时快速恢复，不会像以前那样 “一卡就黑屏”，状态码会清晰提示 “网络波动，正在重试”。
总结：HTTP 的进化 =“更快传输”+“更清晰沟通”
从 0.9 到 3.0，HTTP 的升级逻辑很明确：
- 能传的东西越来越多：从纯文字到图片、视频、3D 模型；
- 传输速度越来越快：从每次重建连接到多路复用，再到换用 QUIC 协议；
- 沟通越来越清晰：从没有状态码到能精准说明 “为什么失败”“怎么解决”。
下次看到404时，你就知道：这是 HTTP 1.0 时代就定下的 “行话”，告诉你 “服务器找不到你要的东西”；而304则是 HTTP 1.1 的智慧，帮你用缓存加快网页加载 —— 这些数字背后，都是 HTTP 不断进化的痕迹。
